Re: "Binary XML" proposals

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

"Al B. Snell" wrote:
> 
> On Fri, 13 Apr 2001, Stephen D. Williams wrote:
...
> > 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.

No, the difference is that after connection, the rest of the
session/conversation can be handled by another thread/process/cpu with
TCP.  You can't do that with UDP since there is no way to know at the
kernel/driver level what logical process an incoming UDP packet is bound
for.

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

TCP, with truly random sequence start numbers, can't be spoofed.  Once
you authenticate a TCP connection, it is far safer to handle further
data on the same connection.  Because of this, layered encryption is far
cheaper since you can assume a certain encryption stream state.  Most of
what current firewalls do relies on this.  Lack of this is why UDP is
blocked at nearly all firewalls.

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

I'm talking about application headers needed to authenticate.  Optimized
applications and servers will buffer requests in TCP to avoid extra
packets and read/writes.

> 
> > > 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 :-)

HTTP does allow pipelining...  What do you mean?

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

Retransmit is only needed in the case of dropped packets which is likely
to cause retransmit of fragments somewhere.  With enough work queued,
the retransmit gets absorbed.  The replies are only ordered after they
are put into TCP buffers.  A true message oriented system will support
reordering when requests go to different work queues internally.

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

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