ec5d0edf
From: rick.jones2@hp.com
lmike wrote:
> OK, so it is implementation dependent (I am only talking about
> blocking sockets)?
Even then it could depend on the stack :)
> What about linux, any one can verify whether a write() call on a
> blocking socket on linux will return when the whole data is ACKed or
> it is copied to the TCP stack's buffer?
I'm going to ask what I perceive to be the question behind the
question.
You should presume the write() returns when the data is copied into
the buffers used by TCP. Put the other way, you should presume a
return from a write() call says nothing about the ACK status of the
data from that write() call.
Now, depending on the application having knowledge of the socket
buffer sizes and whether or not there can be "slop" beyond them, some
of what is mentioned in this old writeup on HP-UX 9.X copy avoidance
can be used to know the ACK status of data in a *previous* write()
call. Linux's "autotuning" of the socket buffers complicates
matters...
However, even then it does not say anything about what the remote
application may or may not have done with the data. For that, you need
application-level messages (at least implicit ones) flowing-back from
the remote application.
> Just curious, on Windows, how do you set "copy avoidance" for a
> windows TCP socket?
Well, one way I've heard of is to set the socket buffer size to 0 via
a setsockopt() call - the only reason I know about that though is it
forced a change in the value netperf uses to say "use the system's
default socket buffer size" from 0 to -1 :)
rick jones
--
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
