Re: "Binary XML" proposals

["Stephen D. Williams" <sdw@lig.net>]

"Al B. Snell" wrote:
> 
> On Thu, 12 Apr 2001, Vassilis Papadimos wrote:
> 
> > > Three-way handshake before you even send the request, the
> > > connection teardown? *retch*!
> >
> > The three-way handshake is part of any TCP-based protocol, right?
> 
> Yep
> 
> > Plus, with HTTP versions > 1.1, you can amortize the connection
> > overhead over multiple connections.
> 
> Mmmm, but who implements this in practice? Some Web clients are starting
> to, but which SOAP clients/servers?
> 
> And there are big problems with that model, too. You can't do asynch
> RPCs. You do send, wait, reply, send, wait, reply. You need to start
> opening more connections if you want to issue parallel requests.
> 
> > Are there any reasonable alternatives?
> 
> Sure; UDP. Look at existing RPC protocols and learn from them.
> 
> ONC RPC allows UDP and TCP transports.
> 
> The UDP one has a maximum message size, 64k, and doesn't guarantee
> delivery (so you have to retransmit manually; I wish it'd automate it!)

A) UDP has no mechanism for handling fragments, so it's maximally 1500
because of Ethernet and less if someone decides to lower the MTU.  The
server may be able to unfragment, but it's not clear to me how this
would work.

B) With UDP, you are limited to a single thread or process that actually
recieves the packets on a particular IP address port combination.

C) Because you don't have the session guaruntees that TCP sequence
numbers or an encryption layer give you, you have to waste an already
small payload with repeated authentication information to avoid
spoofing.

D) Generally each message is a UDP packet which is highly wasteful of
network/router/server resources.

You could implement something like TCP over UDP, but that's only really
needed, usually, for streaming applications.

> The TCP one is good if you expect a long conversation, and don't mind the
> conversation being synchronous.

There is no reason that TCP implies synchronous.  That's just the naive,
old fashioned, and generally inappropriate implementation.  TCP is
perfect for a full async message oriented system.  In fact Imap is a
good example of this, I believe.  I have had a lot of experience at
several companies using async messages over TCP as far back as 1986.  It
appears to have been known in the mainframe world for a very long time.


> Eg, the RPC protocol for NIS (aka YP) recommends that you use UDP for just
> asking simple questions of the NIS database (it works like LDAP or DNS as
> a first approximation), but if you're a backup server wishing to take a
> database replica, consider opening a TCP connection and using that.
> 
> Read RFCs - http://RFC.net/rfc998.html would be nice if it was widely
> implemented.
> 
> http://RFC.net/search.php3?phrase=RPC
> 
> >
> > 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

sdw
-- 
sdw@lig.net  http://sdw.st
Stephen D. Williams
43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax 
Dec2000