🚀 go-pugleaf

In article <JAD.92Oct26125449@pimlico.nsa.hp.com> jad@nsa.hp.com (John Dilley) writes:

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

This is not going to give maximum throughput between the client and server.
The RPC system will not be able to send back-to-back packets on
next-generation networks where more than one packet can be on the wire
between sender and receiver. (Under this definition, Ethernet is a previous
generation network.) Instead it's required to wait after each RPC request
for the reply before sending the next request.

To get maximum throughput with RPCs you'd have to have several parallel
threads send the RPCs to the destination. At the destination the receiving
threads would have to sort themselves out, i.e. recover the original
ordering, using application level sequence numbers. This isn't difficult 
for distributed systems types, but I've seen quite intelligent people
building applications who'd rather have the system do this for them, so
they can concentrate on their own application. 


>   >   to do this is using multiple RPCs issued in parallel (using threads),
>   >   probably layered over a stream protocol like TCP. Tuning is a bit tricky
>
>           Why do you say parallel RPC threads would make calls over TCP?
>   In one of my clients, a system load monitor, I make RPCs in threads over
>   UDP (to use the more efficient transport).  I realize UDP may lose a few
>   packets now and again, but the RPC runtime will handle this for me.
>   Using TCP implies you want to make many calls to the same server.
>   Perhaps there is a better mechanism for this.

I was begin lazy when I said TCP. Many RPC implementations use UDP and
provide their own retry mechanism. The tradeoff between TCP and UDP on Unix
is a bit tricky. TCP is better at flow
control than UDP, but has a longer setup time, and more importantly, you
can quickly run out of socket descriptors at the server with TCP under Unix.
On the other hand, UDP has flow control problems. Its a connectionsless,
datagram protocol, but nevertheless it ends up fragmenting large packets,
and therefore does some flow control. Also, you can consistenly lose
packets because of buffering limits and not know about it. When this
happens you have to back way off until the problem clears. This isn't a
problem with UDP, its a problem with the software layers between your code
and the wire in most Unix implementations.

>           I agree that threads cost something, both in terms of their
>   runtime cost and their cost at design and implementation time.  But you
>   must admit that ANSA and the other schemes have a similar runtime cost
>   to do its sequencing: this is something you can't get away from.

My point here is that the cost of using parallel threads to arrange for
N packets to be in flight between client and server is N thread stacks.
The cost in a stream protocol implementation is, hopefully, two or three
thread stacks. 

        -- Robert Cooper rcbc@cs.cornell.edu
--
--