UDP pro's and con's (fwd)

[sheer@saraf.com]

I've noticed the mailing list sometimes ignores/delays my mails,
particularly when they're CCed to it so here's a repost, sorry if it shows
up again in a little while: 

It strikes me as slightly incongruous to even be considering UDP in a
system where we will _definately_ have to verify transactions (ie a
registrar _must_ know if a domain registration went through or not) and
thus need to develop/adapt some intermediate transaction layer (which TCP
provides) while at the same time using XML as the protocol language and
rejecting out of hand any binary conversion.  This is not a disguised
rallying cry for a XML-binary conversion, just a call for some
perspective.  I think we've already made some implicit performance
descisions in adopting XML for the protocol and we should be consistent in
the level of performance we're demainding.

In addition I think TCP overhead is going to be very light compared to
the encryption systems we're considering (TLS, BEEP) and TCP (or the
gaurantees it provides) will be necassary for any transport-level
encryption that I know of (though of course we could take the encryption
into the protocol and ignore the transport layer).

If UDP has a place I thinks its in the "Check Domain" command that we
descided we might have to consider as a special case since its
requirements are vastly different from the rest of the protocol's.

Regards,
Sheer

On Wed, 21 Mar 2001, Brian W. Spolarich wrote:

> 
> | Is there an example of a UDP-based transport protocol that might 
> | be applicable?
> 
>   Rx, which was part of the CMU AFS work, was a UDP-based RPC
> protocol with some of the characteristics that are required
> here.
> 
>   Do folks really think the TCP overhead is that big of a 
> problem?  Memory and CPU is much cheaper these days, and I haven't
> seen a requirement stated that would necessitate going down
> the UDP road.
> 
>   -bws
>