🚀 go-pugleaf

In article <5504@bacon.IMSI.COM> jordan@IMSI.COM (Jordan Hayes) writes:


>	It's just that it's not like people have been holding as trade
>	secrets the knowledge gained about TCP.  Thus, I can apply that
>	experience to my RPC protocol that runs over UDP.
>
>Indeed.  But why would you want to?  Or have to?  Also, are you sure
>that you have enough information in User Space to make the kinds of
>decisions that TCP makes for you in the kernel?  I'm not convinced that
>it's "six of one, half dozen of the other."

Exactly. Also, theres the other point that TCP is a continually evolving
protocol. For instance, there are proposals underway to increase TCP window
size, to do selective transmissions etc. These are intended to function
well over long-bandwidth/high delay networks. I'm sure there will be
further enhancements in the future as well (for instance, there is some effort
underway to experiment with faster setup of a TCP connection, which would
remove another main gripe that RPC designers have with using TCP). Sure, you
can always track these in the RPC layer, but this involves additional complex-
ity and possible duplication of code. Also, this may require an RPC protocol
revision (if your RPC protocol doesnt support options). 

My belief is that its worthwhile rolling your own transport if you want some
significant feature or facility not provided by extant transport protocols.
An example might be reliable multicast which is supported by some research 
transport protocols, but not by any protocol which is widely deployed
and available. If you wish to provide some form of "multicast" rpc, then
you might want/need to write your own protocol over UDP to provide reliable
multicast. On the other hand, for unicast reliable sequenced operations,
TCP  + server and client resource  management (to prevent excessive use of
connections/file descriptors) should be sufficient. Fast TCP setup would be
nice, but its just an optimization. 


>Anybody have a good example of a real-life application that can be
>tolerant of dropped messages?

Well, this is wandering slightly off the topic of this discussion, but
multimedia applications (voice and video) are classic examples of
applications that may be concerned more with timely delivery than 
with reliability and may indeed prefer that a packet be dropped
if its too late. Also, some encoding techniques may enable partial
recovery of a lost packet, or may enable an image or signal to
be reconstructed with a slight degradation even with a dropped packet.
Sure, reliability would be nice, but for some applications its not
the primary metric for evaluating network service.


Abhijit