🚀 go-pugleaf

John Dilley <jad@nsa.hp.com> writes (not to me, but I have some comments):

	how often is the sequencing of the actual transmission
	important to you at the user level?

I expect that if I instantiate a request at time t0, and then another
at time t1, that the one sent at t0 will get to the server before t1
given that they are headed to the same destination.

	I find it of little concern as long as the results are the
	same.

That's exactly what needs to be preserved.  Consider the two types of
requests TellMeAbout and StopTellingMeAbout ... if the
StopTellingMeAbout message shows up before the TellMeAbout in a quick
transaction, what happens?

	If sequencing is important I would create a thread that makes
	multiple, sequenced RPCs.

In this example, you wouldn't want multiple threads talking to the same
socket.  Somewhere you'd have to preserve message boundries, and that
would be the control point.  Unless you have some magic TCP-based
transaction protocol that you're not sharing with us, it's
thread-per-socket these days.

Besides, given non-blocking sockets and select(), I will beat any
threads package out there in terms of time and space :-).

	In one of my clients, a system load monitor, I make RPCs in
	threads over UDP (to use the more efficient transport).

Since when is UDP "more efficient" at full system load?  In the past
few years, TCP has become a much more efficient protocol that it was,
perhaps to the point where picking UDP over TCP "for performance
reasons" may be a thing of the past.  Consider there are two cases: the
first, where the number of messages is low and the network is lightly
loaded, the extra effort to do TCP is not noticed.  The second, where
the network is congested, allows you to take advantage of sophisticated
congestion avoidance in more modern TCP implementations.  When the
network is congested and the transport is UDP, the application
programmer (whom I pity :-) must make up for this on her own.

Suddenly, you have systems programmers (usually not very good ones at
that :-) doing things your kernel (or more rightly your protocol)
should be doing.  This is also the part of the code that gets tested
less.  That sounds bad to me.  You know why?  Because I've seen it all
to many times, and they simply don't work.  Our TCP-based message
system stays calm all the way up to the limits of the network.  I can't
say the same about UDP-based solutions we've seen.

Besides, it's when the network is at full load that you are most
concerned about performance and accuracy.

	I realize UDP may lose a few packets now and again, but the RPC
	runtime will handle this for me.

Yes, usually by retransmitting the *entire packet*.  Since the RPC
runtime doesn't have access to "what part of the message got dropped"
it has no choice but to resend everything.  In effect, you are asking
to re-implement (poorly) everything that TCP does for you.

In addition, some of us can't afford to drop packets.  There are real
applications out there (system load monitoring isn't one of them) where
dropping packets means that you don't have the whole picture.  Not
having the whole picture means not being able to perform the
computation.

	Using TCP implies you want to make many calls to the same
	server.

Maybe it implies that to you, but for me it means I want an ordered,
reliable byte stream.

/jordan