Re: "Binary XML" proposals

["Al B. Snell" <alaric@alaric-snell.com>]

On Thu, 12 Apr 2001, Vassilis Papadimos wrote:

> > Sure; UDP. Look at existing RPC protocols and learn from them.
> 
> I know about UDP; but for most applications I can think of, we 
> want reliable messages, with no restrictions in size, arriving in order.
> 
> If you implement these on top of UDP, I think you'll end up 
> reinventing TCP, only with more bugs :-)

TCP is fine as long as you:

1) Actually reuse the connection

2) Perform at least 2 or 3 RPCs to the same host

...but if you're going to use TCP for RPCs, for God's sake don't use port
80; that's for transferring hypertext. We have 65,000 or so port numbers
to choose from. If we use different port numbers for different things,
firewall administrators can make networks secure by controlling what does
and doesn't get let through. If Web browsing and RPCs all go over the same
port, then it's hard to disallow or control RPCs without affecting web
browsing.

We use HTTP for RPCs, anyway? Being able to reuse Apache isn't a great
win. It's easy to listen on a port, perform some kind of authentication on
incoming connections, then just choose a scheme for delimiting requests
and an error-signalling system for use in response. Voila!

One thing TCP does that's annoying is emulating a serial stream when you
really do want a packetized RPC interface. Basically, the implementation
goes to a lot of effort buffering - including delaying the delivery of
arrived packets to the userland code until a lost packet is retransmitted
- which you then undo by shoving in delimeters.

> 
> Vassilis.
> 

ABS

-- 
                               Alaric B. Snell
 http://www.alaric-snell.com/  http://RFC.net/  http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software