Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!well!nagle
From: nagle@well.UUCP (John Nagle)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Nagle algo. in Unix-TCP
Message-ID: <13688@well.UUCP>
Date: 18 Sep 89 16:22:39 GMT
References: <8909162241.AA03169@tien.Wellfleet.Com>
Reply-To: nagle@well.UUCP (John Nagle)
Lines: 29

In article <8909162241.AA03169@tien.Wellfleet.Com> pprindev@wellfleet.com (Philip Prindeville) writes:
>You could also use writev() for doing scatter/gather writes.
>...
>If this were a disk-based application, you would want transactions
>to occur atomically, and hence would use writev()s.  This way, if
>the program were interrupted or the system crashed, you would have
>the best chances of the operation completing.  (As opposed to taking
>a signal between the first and second write.)  So "packets" are not
>conceptually different from "records".

      First, bear in mind that TCP really is a stream protocol.  You're
guaranteed that the bytes you write get to the other end in the same
order, but you are definitely not guaranteed that a unit of data
written with one write shows up as a single unit at the receive end.
If you need atomic transactions, a suitable protocol must be constructed
for that purpose, either on top of TCP or in some other way, such as
on top of UDP.  Sun's NFS, for example, is implemented on top of UDP.

      Second, given that we were discussing writes of small amounts of
data, copying cost isn't a big issue.  So "writev" isn't particularly
useful.

      I'd still recommend going through the standard I/O package and
doing "flush" operations at the appropriate time as the most effective
way of dealing with the problems described here.  Attempts to "increase
efficiency" by bypassing the standard I/O package generally make things
worse, rather than better, unless very large blocks are involved.

					John Nagle