Re: "Binary XML" proposals

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

On Fri, 13 Apr 2001, Stephen D. Williams wrote:

> 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.

Fragmentation works at the IP level... IP packets can be up to 65536 bytes
incl. headers, so that sets the limit for UDP packets. The fact that UDP
doesn't do fragmentation (like TCP does) merely means that it's
constrained by the layer beneath (IP), which handles fragmentation for it. 

http://RFC.net/std0005.html

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

Same with TCP. The usual design choices apply; maintain a child pool which
the parent fires requests off to or if the RPC is a very fast operation or
you are lazy, just handle it in a single threaded loop.

> 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.

TCP doesn't provide encryption either, and is not exactly hard to
spoof. You need security on top of TCP too.

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

Why? The same happens with TCP, except there are more headers per
packet. You will only get multiple messages in a packet if they are issued
very fast, since TCP for RPC will usually have the ToS set to request
minimum latency rather than minimum cost.

> > 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. 

...that HTTP 1.1 will enforce :-)

> 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.

TCP can only offer partial asynch operation - the system will delay
packets if one needs to be retransmitted, since it doesn't *know* that the
layer above supports asynch operation. It will force ordering on the
replies, basically - putting effort into doing something that's
undesirable; it's a sledgehammer to crack a nut.

But this debate has been had before amongst the Internet protocols
community...

RDP and NetBLT are the "correct" solutions, but they're not widely (at
all?) implemented :-(

> 
> sdw
> 

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