Loading ...
Sorry, an error occurred while loading the content.
 

Re: [decentralization] Async RPC and callbacks

Expand Messages
  • Todd Hoff
    ... Exactly, i call this the rendezvous pattern. The sync call uses the underlying async call mediated by a semaphore. When the async call completes/times-out
    Message 1 of 10 , Oct 1, 2001
      coderman wrote:

      >
      >You dont need to implement callbacks, as these would be asynch. If you want
      >something to appear synchronous, you block until the operation is complete.
      >
      Exactly, i call this the rendezvous pattern. The sync call uses the
      underlying async call
      mediated by a semaphore. When the async call completes/times-out it
      gives the sender's semaphore
      after having set the sender's reply status. This makes it trivial to
      support sync and async
      models. Turning sync into async is a bit more work but can be done.

      >
      >If you dont want to use a synchronous model, use callbacks and asynch event
      >notification. However, either method is supported.
      >
      My callbacks are usually a base MsgHandler object the usually connects
      to an Actor that is a
      thread and queue. The actor's thread is woken up and the message is
      handled in the actor's
      thread so there are no threading issues to deal with. The messaging
      layer context ID allows
      the messaging layer to map back responses to the MsgHandler. The
      application context ID
      allows the application/MsgHandler layer to map back the response to a
      handling context.
      But as most people hate async the rendezvous pattern is used so the
      context is still on the
      stack on the application context ID isn't used. This of course
      singlethreads the actor and
      the actor can only handle one request/response at a time although it can
      have many requests
      being queued to it while it doing other things. The queued requests may
      time out. If the
      actor is doing something that takes a lot of time. Using this model
      there are no threading
      issues. Multiple threads of activity can be independently going on at
      the same time. And
      developers can do sync and async.

      >
      >I am working on a project that uses UDP, and in this case, you can also
      >send and receive from either end, and any time without worry about NAT
      >problems*. Firewall's are still an issue (if they filter UDP) and then a
      >fallback, like the single TCP connection method mentioned above can be
      >used.
      >
      Most of our stuff is TCP, but we do use some UDP. We go in trouble for
      using UDP because it
      appears a lot of our customers filter out UDP completely at the
      firewall because it is difficult
      to filter.

      >
    • Lucas Gonze
      The key is getting event notifications of stuff you really aren t expecting. Some of the time you can just open a socket from the client side and wait for all
      Message 2 of 10 , Oct 1, 2001
        The key is getting event notifications of stuff you really aren't expecting.
        Some of the time you can just open a socket from the client side and wait for
        all events to come through, as with an IM session that you initiate. But at
        other times you had no idea that some event was going to arrive. EG, in
        relation to apps like ICQ and Audiogalaxy which I don't use much but do use here
        and there, I do want to be able to use the network but I don't want to give them
        fulltime CPU and bandwidth. There's no way to keep an open client-initiated
        session running for each possible source of events.

        That's where presence services like XP Messenger, Jabber-RPC, or KnowNow come
        in. The client initiates a single event stream to a well known rendezvous point
        and from that point on unexpected events can pass through that rendezvous point.
        EG ICQ can send an event to my rendezvous that my ICQ node should call into the
        master server to initiate a full session.

        > > Or maybe not - what that would effectively achieve is
        > > the creation of the bi-directional transport based on HTTP,
        > > and then - since you're going to bind the XML-RPC/SOAP to
        > > this trasport anyway, (message IDs or message boundaries
        > > and all that) then maybe this RSS stuff could be used
        > > as is, but only for these special bindings...
        > >
        > > Best wishes -
        > > Oso.

        What the binding needs to accomplish is a way to map arbitrary events to
        handlers. EG if foo (ICQ) format arrives, this is intended for foo (ICQ)
        message consumer. The stream handler/demuxer running on my PC should be able to
        activate services in response to callbacks. That's what WSDL on the client side
        is doing -- mapping remote events to local handlers.

        - Lucas
      Your message has been successfully submitted and would be delivered to recipients shortly.