Something like asynchronous XML-RPC possible?

[Stuart Bishop]

On Saturday, January 25, 2003, at 02:51  AM, Laura Creighton wrote:

> I get the sinking feeling, reading this thread, that the problem is 
> that
> Will Stuyvesant's boss has heard the word 'UDP' and the word 
> 'asynchronous'
> at the same time, and thinks that he has found a known solution for 
> what
> he wants Will Stuyvesant to do.  He has no idea of the horrible 
> complexity
> he is asking for.
>
> In this case, it might be well to implement an 'it is easier to get
> forgiveness than permission' policy. 'Convincing the boss that this is
> a bad idea' is a better plan than 'doing it anyway even though it is
> a bad plan because it is too hard to explain this to the boss'.  This 
> is
> due to the difficulty of 'doing it anyway' regardless of the difficulty
> of 'explaining to the boss'.

Hmm.... UDP is unreliable, so we need to fix that. And UDP packets can 
arrive
out of sync, so we need to fix that. Thankfully someone has already 
implemented
this for me, bundled it up and called it 'TCP'. And it can even go 
through
firewalls without rewriting the company security policy using an even 
higher
level package called 'HTTP'. And I can buy a 'layer 4 switch', plug it 
in, and
get transparent wire speed load balancing making my application 
scalable. And
if I use a standard RPC mechanism like XML-RPC, then my application is
implementation agnostic and future proofed. And I can plug in SSL to get
industry standard peer-to-peer encryption in case we need to start 
talking
with nodes via untrusted networks.

Or I could reimplement the wheel, although we will never be able to sell
this product because it isn't standards or buzzword compliant and won't
pass acceptance tests as the Network Manager of Target Corporation will
sabotage the process so they don't have to reconfigure all their 
routers.

I think UDP's usage to real applications is for real-time stuff over
networks, where I need to handle my own retransmissions because the
data I originally tried to send is already out of date. Like real time 
games.
Or where I never want to retransmit because the data wasn't that 
important
anyway. Like streaming audio, where a few percent of the packets will 
never be
missed. If you have the 'I want to know the data actually arrived' and
'My requests/responses don't fit into a single UDP packet', you are 
already
better off using TCP.

Have fun with the boss. If there are legitimate reasons for using UDP,
it sounds like they are not doing particularly well communicating them 
to
you.

And if you havn't already guessed, I don't think that there are any
RPC mechanisms that use UDP as their transport protocol. RPC mechanisms
are usually designed so they can return a result, which is not what UDP
is good at. So you'll have to write your own and make the square peg
fit the round hole.

-- 
Stuart Bishop <zen at shangri-la.dropbear.id.au>
http://shangri-la.dropbear.id.au/