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

Re: [decentralization] Async RPC and callbacks

Expand Messages
  • coderman
    ... 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.
    Message 1 of 10 , Sep 30 8:53 PM
    • 0 Attachment
      "Eric M. Hopper" wrote:
      >
      > On Sat, 2001-09-29 at 09:20, Todd Hoff wrote:
      > > Our protocols usually contain in the request a context identifier for
      > > the protocol implementation
      > > and context identifier for the application which allow mapping back to
      > > handling code for the response(s)
      > > at each layer. Support for these identifiers in the protocol makes it
      > > easy to implement sync and async
      > > behaviour in multithreaded or singlethreaded model.
      >
      > Isn't that kind of an unnatural mapping to a function call model? You
      > don't usually supply a callback context when you call functions in your
      > own address space. :-)



      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.

      For example, in one peice of software I used the underlying protocol was
      all asynch messaging. When a higher level client request was made through
      and API that appeared synchronous, the calling thread blocked until all
      the asynch events required for this request completed.

      ClientThread ReactorThread
      | |
      request -> sendRequestPacket ->
      . |
      . recvRequestPacket <-
      . |
      . <- returnResult
      requestEnd |
      | ...

      During the (...) the client thread is blocked (you can do this a few ways,
      mutexes, sleeping, etc) while the lower level events are processed in an
      asynch manner.

      If you dont want to use a synchronous model, use callbacks and asynch event
      notification. However, either method is supported.



      > As someone else pointed out, this doesn't work well with NATs or
      > firewalls, but, of course, no protocol that allows either side to send
      > messages at random times works with those, unless you can somehow
      > establish a continuing connection through the firewall. *sigh*
      >


      Well, if you rely on a new TCP connection to return a reply, then you are
      correct. However, the better way to implement this in a Firewall/NAT
      situation is to have the client open a connection, and then leave it open.
      (the continuous connection you mention)

      Requests and replies are sent bi-directionally over this single connection.

      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.

      * This is not entirely true. There are some small percentage of NAT
      routers which cause problems, however, due to the popularity of UDP
      for network gaming, these tend to be old, seldom used devices.
    • 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 2 of 10 , Oct 1, 2001
      • 0 Attachment
        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 3 of 10 , Oct 1, 2001
        • 0 Attachment
          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.