Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!cs.utexas.edu!sun-barr!newstop!sun!samsun!vipin From: vipin@samsun.Sun.COM (Vipin Samar) Newsgroups: comp.protocols.misc Subject: Re: RPC Technologies Keywords: NCS Threads Preemption Message-ID: <142133@sun.Eng.Sun.COM> Date: 10 Sep 90 22:51:51 GMT References: <1990Sep5.194621.11656@athena.mit.edu> <1990Sep7.153710@apollo.HP.COM> Sender: news@sun.Eng.Sun.COM Lines: 34 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