jbvb@FTP.COM (James B. Van Bokkelen) (01/09/91)
On 4bsd Unix, if you write 8K to a UDP socket (through RPC or otherwise), you will generate an 8K + 8 byte UDP datagram. This will in turn generate an 8K + 28 byte IP datagram, which will get carved up into N IP fragments because the MAC layer won't be able to send it intact. 4bsd doesn't treat this as an error. Some other UDP implementations do. Many people (myself included) would suggest that, if you need to move large amounts of data using RPC, you use TCP as the transport layer instead of UDP. At one stroke, you get retransmission with backoff, end-to-end data integrity checking, congestion avoidance, and little or no IP fragmentation. This will make you many friends if your application runs over WANs (e.g. the Internet). James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
TAYBENGH@NUSDISCS.BITNET (01/09/91)
Hi netlander,
I am always puzzled about 8K limitation imposed by Sun UDP-based RPC
implementation. After reading the source code, I realized that the 8K
is actually imposed by RPC itself when creating buffer for XDR_MEM.
However, I wondered is it possible to send all 8K data in ONE single socket
sendto() as shown in Sun RPC source code? As most of the people pointed out,
sendto() NORMALLY can only send 1-2K (implementation dependent) of data.
What if the sendto() can NOT send all 8K data in one single UDP message, will
there be errors like RPC_CANTSEND ?
If I modified the library such that large data is sent using several sendto()
call, will several UDP message generated for each sendto() call? If so,
will the various messages splited from of ONE UDP-RPC call mix with other
UDP-RPC call message (I think it is likely, am I rite?)?
Could anybody please shed some light on me, please? I am deperate to know!
Thanks a lot.
p/s: I corssed post it to some other lists, if u see it more than once,
please forgive me.
Regards.
- Beng Hang Tay (email: taybengh@nusdiscs.bitnet)