🚀 go-pugleaf

	I think we've got a good discussion going here.  News working at
its best.  Thanks to mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin) for
the SR language reference.  I'll have to check into it at some point to
learn more about the asynchronous world.  With appropriate language
support it sounds as if the asynchronous model can be both convenient
and efficient.  Writing an asynchronous system without language support
(which has been my experience) is still clumsy, but it's never smart to
use the wrong tool for the job.

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

> John Dilley <jad@nsa.hp.com> writes (not to me, but I have some comments):
> 
> 	I find it [sequencing] 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?

	Clearly a rhetorical question, but you have a good point.  In
this case I would have used a single thread, as I described below:

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

	In the synchronous (DCE RPC) model I would have created a single
thread that calls TellMeAbout some number of times, blocking to await
the reply to each, then called StopTellingMeAbout prior to exiting the
thread.  As you and rcbc@honir.cs.cornell.edu (Robert Cooper) correctly
point out, this will cause my thread to block awaiting each reply from
the server.  I agree that an asynchronous, sequenced communication
system could significantly improve the efficiency of this call sequence.

	However, with DCE RPC if I have multiple client threads all
talking to the same server they can share a socket (I have no magic
protocols :-).  RPC handles the multiplexing of the packets and handles
the details of managing the underlying communication channel.  So if
parallelism is important I would create multiple threads all requesting
TellMeAbout with the server (or servers: I could bind to one or more
servers).  When they all complete (when all the threads have been
joined) I issue the StopTellingMeAbout.

	The point is that multiple threads can talk to the same server,
and the details of sockets are not something I need to worry about as an
application developer using DCE RPC.  Note that I'm not stating that the
synchronous way is "better" than asynchronous; they both have their time
and place.

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

	No bet here ;-).

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

	I don't have any (recent) data to support my claim.  I failed to
state in my post that the RPCs are brief request/response transactions
with small amounts of data to many servers on different hosts.  In this
case I believe UDP will be more efficient: it does not need to do the
socket setup (SYN/ACK) or teardown (FIN/ACK) that TCP does.  I simply
send a packet and await the single packet response.  If I were making
many calls to the same server then the setup and teardown costs could be
amortized over all the calls, perhaps making TCP more efficient than
UDP.  Using TCP would obviously be better if a lot of data is being sent
or received, or if sequencing or reliable delivery were desired; or if
the network is congested as you point out.  You're absolutely right that
applications should let the protocol do its job.  It's just that in my
case UDP is the more appropriate protocol for my application's needs.

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

	In this case the entire packet consists of headers and a small
amount of data (fits within a single frame).  In a sufficiently loaded
network TCP might work better for this single packet transaction, but
this is a point I do not want to belabor.

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

	In which case your application clearly should choose TCP.  DCE
will allow multiplexing of multiple client RPCs over a single (TCP)
socket, provided the requests are going to the same server (or the same
host; this point is not clear to me).  Regardless, I agree that DCE over
TCP has its time and place in applications where delivery is important
or where network congestion can be an issue *and* where the transactions
consist of more than a simple request/response with small data units.

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

	I stand corrected ... I can't believe I said that :-).

	Thanks for the thoughtful and enlightening post.  I hope this
useful exchange will continue.  Regards,

			 --       jad       --
		    John A. Dilley <jad@nsa.hp.com>

Hewlett-Packard				-- Networked Systems Architecture
19410 Homestead Road			-- Mailstop 43UA
Cupertino, CA  95014-9810		-- USA
(408) 447-2419				-- Fax: (408) 447-4928