murthy@thir.cs.cornell.edu (Chet Murthy) (10/01/89)
I have some questions about SUNRPC (the UDP transport layer) that I can't figure out the answers to from the documentation or source. Perhaps somebody out there can answer them. First, does SUNRPC/UDP allow arbitrary-length messages? If not, what is the maximum-length message? Second, if SUNRPC/UDP does allow arbitrary (or long) length messages, does it allow multiple messages to be read in at the same time, so that, for example, if one server is receiving two UDP messages simultaneously, and one of them client machines dies in the middle of the message, the server can still read the rest of the other message - it doesn't hang waiting for the message from the other client, and it doesn't need to wait for a timeout. Basically, I'm trying to find out if SUNRPC is suitable for operation in an environment where machines can crash pretty often, without degrading performance for those machines which are still left running. Thanks in advance. murthy@cs.cornell.edu
barmar@think.com (Barry Margolin) (10/02/89)
In article <1843@brazos.Rice.edu> murthy@thir.cs.cornell.edu (Chet Murthy) writes: >X-Sun-Spots-Digest: Volume 8, Issue 148, message 4 of 10 >Second, if SUNRPC/UDP does allow arbitrary (or long) length messages, does >it allow multiple messages to be read in at the same time, so that, for >example, if one server is receiving two UDP messages simultaneously, and >one of them client machines dies in the middle of the message, the server >can still read the rest of the other message - it doesn't hang waiting for >the message from the other client, and it doesn't need to wait for a >timeout. I don't know offhand if it allows arbitrary length messages, but it does allow long messages. They are packed into a single UDP packet, which is packed into a single IP datagram, so the limit is on the size of the receiver's IP datagram reassembly buffer. The higher layers (UDP, RPC, application) don't see partial RPC messages; they see nothing until the entire message has been received. There's no blocking of messages when partial datagrams have been received; datagrams are filled in as packets are received, and when a datagram is complete it is forwarded to the higher layers. Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
murthy@thir.cs.cornell.edu (Chet Murthy) (10/02/89)
Well, I got some answers back. It seems that SUN has a limit of 8kBytes on the size of a UDP packet. The SUNRPC implementation encapsulates an RPC message into a single UDP packet, so if your implementation doesn't support large enough packets (the PC-NFS implementation apparently only supports 1KByte UDP packets) then your RPC implementation won't do reassembly, etc, to allow you to do large size RPC's. Also, from the paper that someone posted to the net about recently (about comparing different RPC implementations), I infer that at some point above 8kbytes (I think it was 12Kbytes) using TCP becomes cheaper than UDP (in terms of time). So the thing to do, I suppose, is to add a minimal functionality to SUNRPC to do packet fragmentation/reassembly for meduim-length (8-16Kbytes) messages, and for longer messages, use TCP. Does that sound right? murthy@cs.cornell.edu
joshua@athertn.Atherton.COM (Flame Bait) (10/03/89)
murthy@thir.cs.cornell.edu (Chet Murthy) writes: >X-Sun-Spots-Digest: Volume 8, Issue 148, message 4 of 10 > >I have some questions about SUNRPC (the UDP transport layer) that I can't >figure out the answers to from the documentation or source. > >First, does SUNRPC/UDP allow arbitrary-length messages? If not, what is >the maximum-length message? Sun UDP does not allow arbitrary-length messages. The documentation claims that RPC/UDP can handle calls with up to 8K of data. In fact, it can support data up to the size of a UDP packet (not surprizing). This is not always 8K! I've used a version of AIX, which supported Sun RPC, but the UDP packets were only 2K. >Basically, I'm trying to find out if SUNRPC is suitable for operation in >an environment where machines can crash pretty often, without degrading >performance for those machines which are still left running. This is pretty hard to do with an RPC system. I suspect that if you make an RPC call to a machine that is down, it will take awhile for the calling machine to time out. You might want to look at broadcast systems, like Sun's RBT (Reliable Broadcast Toolkit). Talk to Raj Benjaram or Saul Wold at Sun about getting a copy. Joshua Levy joshua@atherton.com home:(415)968-3718 {decwrl|sun|hpda}!athertn!joshua work:(408)734-9822
davis@groucho.ucar.edu (Glenn P. Davis) (10/05/89)
You can select TCP transport for a given program/procedure under SUNRPC. Last time I checked, rpcgen gave you UDP transport by default, so minor editing of the generated code was necessary. Nice thing about TCP transport beyond no size limit is that the client doesn't have to wait for a return. This is called 'batched rpc'.
ag@cel.co.uk (10/20/89)
In article <1903@brazos.Rice.edu> murthy@thir.cs.cornell.edu (Chet Murthy) writes: >X-Sun-Spots-Digest: Volume 8, Issue 151, message 2 of 15 > >Well, I got some answers back. It seems that SUN has a limit of 8kBytes >on the size of a UDP packet. >So the thing to do, I suppose, is to add a minimal functionality to SUNRPC >to do packet fragmentation/reassembly for meduim-length (8-16Kbytes) >messages, and for longer messages, use TCP. >Does that sound right? It seems as though Sun are already doing this with yellow pages. Most of the YP interogation routines use UDP, as any single YP entry is rarely more than a few hundred bytes long. However the "yp_all" call ( retrieves entire contents of a map ) apparently uses TCP due to the potential length of maps. I have found this out the hard way as our network is experiencing problems with the "ypcat" command when running in a YP domain with multiple servers. When a client is bound to a slave server the ypcat sometimes fails reporting: "yp_all - RPC clnt_call (TCP) failure: RPC: Unable to receive; errno = Connection reset by peer" None of the other YP functions are affected in anyway when this occurs. As Sun haven't come up with much I wondered if some bright spark out there has ever seen anything like this before. Thanks in advance for any help. Andrew R. Gray --- Crosfield Electronics Tel: 0442 230000 ext 3406 e-mail: ag@cel.uucp,ag@cel.co.uk