🚀 go-pugleaf

In comp.protocols.misc mishkin@apollo.HP.COM writes:

>    Of course, Sun RPC has gotten by (or maybe not gotten by :-) for
>    years with limitations of this sort (and more).  E.g., if you use
>    Sun RPC over UDP/IP, you're limited to 8K worth of data and the call
>    semantics are unpredicatble.  "Use Sun RPC over TCP/IP", you might
>    say.  Oh well, then the number of concurrent calls I'm allowed to
>    have is limited by the number of TCP connection I can (effectively)
>    have open at a time.  Seems like a pretty arbitrary limitation to
>    put on a distributed applications programmer.  The load of having,
>    oh, 100 clients doing lightweight things may be low.  It's just the
>    poorly chosen requirement the RPC package made on the system that's
>    preventing me from doing what I want.


I have been reading with interest your discussions on RPCs.  I do not
have much documentation on NCS2.0 and hence have some difficulty in
understanding lots of NCS issues and policies.  For example,
 - how does the NCS library decide which transport to use.  Say, I have
   both TCP and UDP on both client and the server machine.  Are there any
   heuristics in place upon which you decide which transport has to be used?
   Do you prefer one over the other?
 - Using UDP for hundreds of connections is a good idea, but I wonder whether
   to support streaming on top of that is  a good idea because it can lead
   to all sorts of rate-flow problems.  TCP is great at backing off in
   stormy and overloaded networks, while UDP just exacerbates the problem.

Any comments?

Vipin Samar.

Disclaimer: I speak for none but myself.

vipin@Eng.sun.com || sun!Eng!vipin