Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Messaging Module

    We are using SmartClient 7.0rc4 power edition.

    When using the Messaging module on the client side, is there a way to be notified that the request to subscribe to a channel has been processed on the server and that the client is now subscribed? I know there is the getSubscribedChannels() method which returns the list of subscribed channels, but I think this methods returns the channel as subscribed as soon as the Messaging.subscribe() is called even if the request has not been processed yet.

    On the server side, what is the difference between ISCMessageDispatcher.send() and ISCMessageDispatcher.deliver()?

    Thanks,

    Ranko

    #2
    Messaging.subscribe() has a callback for notification (second argument).

    Call dispatcher.send() only. deliver() is not documented.

    Comment


      #3
      That callback seems to be called only when something is actually sent to that channel. Am I mistaking?

      Comment


        #4
        Yes, that's true, but typically data starts arriving immediately or you wouldn't have a reason to use real-time messaging - why is this coming up? What are you trying to do?

        Comment


          #5
          ok, I'm trying to integrate with an existing system. This system produces user specific updates. You can register yourself with this system and it will return to you a unique identifier for your registration. You can tell this system to start/stop sending updates for your registration. I'm trying to use the unique registration identifier that the system returns as my channel. So, when the browser gets this channel name i have to do two things: 1) subscribe to the channel , 2) tell the system to start sending updates. I'm encountering a race between Messaging.subscribe() and the DMI call to tell the system to start sending updates. If the call to start sending updates is processed before Messaging.subscribe(), messages are missed. If there was a "subscribed callback" I could issue a start publishing call from that callback. I am currently getting around this on the serverside by storing any updates the system has produced before there is a subscriber to the channel ,and forwarding them to that channel once there is a subscriber.

          Comment


            #6
            Sorry if this is obvious and you've already considered it, but why wouldn't you delay the call to Messaging.subscribe() until after the DMI to start sending updates has completed?

            Comment


              #7
              You mean the other way around?

              I need the client subscribed to the channel before the DMI call to start sending updates is processed. Otherwise, the system (system i'm integrating with, not smartclient messaging module) is sending updates while no one is subscribed to the channel in the messaging module. I was delaying the DMI call to start sending updates trying to give Messaging.subscribe() time to complete, but this would work sometimes and sometimes not, depending on several factors... That's why it would be good to get a callback when subscribe() is complete, so that the DMI call is issued afterward without trying to relay on an arbitrary delay...

              But here is another question. Smartclient messaging module reconnects from the browser to the server at some specified interval. During the time it is reconnecting, is it still subscribed to all the channels it was subscribed to? That is, if i send a message from the server to a channel, and the browser subscribed to that channel is reconnecting, will the message be delivered? And i'm talking about the Smartclient internal reconnect, the one to defeat any intervening proxies and such.

              Comment


                #8
                On your prior question, probably the best approach is to override subscribe() such that you immediately send a special confirmation message when the connection is established.

                As far as dropped messages - reconnect works by establishing the new connection before tearing the old connection down, so there is no interval during which messages would be lost.

                Comment


                  #9
                  Thank you.

                  Comment

                  Working...
                  X