Something like asynchronous XML-RPC possible?

[Andrew McGregor]

--On Friday, January 24, 2003 06:04:06 -0800 Will Stuyvesant 
<hwlgw at hotmail.com> wrote:

> I *know* I am not tied to UDP but to convince my boss I would have to
> use UDP since he knows that is asynchronous.  Otherwise I would have
> to convince him that what I am doing is also okay.  Using UDP would
> save me from lengthly explanations and discussions.  I can foresee not
> being able to convince them that the "components" I build have an
> asynchronous semantics unless they communicate via UDP.  You know
> bosses...
>
> "Sounds interesting, but why don't you just use UDP like we asked you
> to".

"Because if I do it'll only work 99% of the time in the lab, and about 30% 
of the time in real life, and it'll cost us about ten times as much in the 
long run, by which time I'll have reinvented TCP.  Badly."

UDP is the *Unreliable* Datagram Protocol, whatever the official 
definition.  It is supposed only to be used in cases where you can be 
extremely error and loss tolerant; there isn't even a guarantee that the 
sending host ever emits any particular UDP packet, let alone that it gets 
to the destination.

If you can afford to build most of TCP (which you can't), go ahead, but it 
is better just to use it.  There is a reliable datagram protocol in the 
IETF process called DCCP, but AFAIK there are no implementations yet; if 
there were, it would be a reasonable suggestion.

Use NFS as an example: an asynchronous and stateless protocol that 
nevertheless, for good real world reasons, has been migrated from UDP to 
TCP to get the reliability up to something tolerable.

The DNS has mandatory TCP fallback for similar reasons: try UDP, but if you 
prove you can't because the request is too big, or the answer is too big, 
or you don't get an answer in reasonable time, try again with TCP.

Like Laura said, the difficulty of convincing your boss is far lower than 
solving this problem properly; the IETF has been trying to improve on TCP 
for a very, very long time, and is only now getting some success.  Like 
others have pointed out, TCP does not imply synchronous behaviour, nor even 
necessarily blocking behaviour in the sending thread.

If you want automagic connection reestablishment and broking, how about 
XMLRPC over Jabber rather than HTTP?  That's more of a message oriented 
environment (and thus better for asynchronous style), but still built on 
top of TCP.

Andrew