Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!brutus.cs.uiuc.edu!lll-winken!ncis.tis.llnl.gov!helios.ee.lbl.gov!nosc!crash!simpact!jeh From: jeh@simpact.com Newsgroups: comp.mail.uucp Subject: Re: RR0 on initial packet Message-ID: <813.25a1f357@simpact.com> Date: 3 Jan 90 19:43:03 GMT References: <1989Dec24.080341.11406@polyslo.CalPoly.EDU> Organization: Simpact Associates, San Diego CA Lines: 26 In article , greg@cheers.uucp (Greg Onufer) writes: > Yes, one minor detail you left out is that the message may be sent in > more than one packet if it is longer than the packet size (_not_ the > window size). You must read (and ACK) packets until one contains a > NULL character. These together make up the message. Yup! An interesting corollary is that if you send a message that is exactly long you must send another packet with the required NUL. > Also, the message packet is not, I believe, guaranteed to be padded > with NULLs, only one NULL at the end of the message is guaranteed. > The rest of that final packet may very well be garbage. > > Cheers!greg From a theoretical standpoint, I agree. But when I was bringing up VMS uucp, I found at least one Unix uucp that insisted that the "messages" I send it be padded with NULs out to the end of the packet. The "safe approach", clearly, is to expect only one NUL when receiving messages, but to send as many as necessary to pad out the packet. --- Jamie Hanrahan, Simpact Associates, San Diego CA Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG Internet: jeh@simpact.com, or if that fails, jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!jeh