🚀 go-pugleaf

Nathaniel Mishkin <mishkin@apollo.HP.COM> 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."

	The reason to invent an RPC protocol to run over UDP is to gain
	some advantages from doing so.

Agreed.  Perhaps I'm showing my bias toward the kinds of appliations I
build, but I find the cost of connection establishment cheap compared
to having to deal with retransmissions.  Maybe I'm lucky that my
distributed applications require accuracy and don't require client to
server ratios of any higher than 200 to 1, and are often *much less*?

[ someone mentioned recently needing 60,000 "connections" and I guess
  that makes me shudder, but if you have that many connections, the
  amount of space that connections take in the kernel is probably the
  least ofyour worries :-) ]

Time and again I've seen people claim that the gain to be had from
using UDP as a transport protocol for RPC-like operations is speed and
efficiency, only to have the protocol fall apart when the network is
loaded and packets get dropped.  We see no such degradation using TCP
as a trasnsport, and have loaded the network up to near theoretical
limits.

Again, my bias is to separate systems which require all packets to be
delivered from those that don't.  Even for the example of load
monitoring, can I really afford to not hear from a station?  In
production environments, if I don't hear from an outpost, I *must*
assume the worst, i.e., mark it as "down" and start recovery/backup
proceedures.  I worked for a while at a bank doing Network Management
for ATMs, and if you didn't hear from a branch, you dropped a trouble
card to the telco and fired up the hot spare modems -- hardly a case
where unreliable communications should be used!

Even for "research" oriented systems, consider a distributed
ray-tracer.  If you drop a piece of the image, you might as well not
show to me.

-----

At some point, I suppose you could have messages that are required and
those that can be dropped -- error rate samples in Network Management
would be okay to drop, but wouldn't you think that when you dropped an
update things would be at their worst?  Sure, it could be a network
blip, but do you want to wait until the next update interval to find
out for sure?  But then your application level would have to tell your
transport level which messages were of which class?  It sounds so messy
to me.

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

/jordan