Re: [decentralization] Async RPC and callbacks
- coderman wrote:
>Exactly, i call this the rendezvous pattern. The sync call uses the
>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.
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.
>My callbacks are usually a base MsgHandler object the usually connects
>If you dont want to use a synchronous model, use callbacks and asynch event
>notification. However, either method is supported.
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
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.
>Most of our stuff is TCP, but we do use some UDP. We go in trouble for
>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
using UDP because it
appears a lot of our customers filter out UDP completely at the
firewall because it is difficult
- 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 isWhat the binding needs to accomplish is a way to map arbitrary events to
> > 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.
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.