Re: Setting size limit of data while reading or writing from sockets
- From: Rainer Weikusat <rweikusat@xxxxxxxxxxx>
- Date: Fri, 06 Jul 2007 10:51:20 +0200
David Schwartz <davids@xxxxxxxxxxxxx> writes:
[...]
It is this simple: Either the application may wait for the stack or
the stack may wait for the application, but not both. Since the stack
may wait for the application, the application may not wait for the
stack. It really is that simple.
The point of having a receive buffer is that both of these 'conceptual
things' that may wait for each other can avoid doing so whenever
possible.
SO_RCVLOWAT
Sets the minimum number of bytes to process for socket input
operations. The default value for SO_RCVLOWAT is 1. If SO_RCVLOWAT
is set to a larger value, blocking receive calls normally wait
until they have received the smaller of the low water mark value
or the requested amount. (They may return less than the low water
mark if an error occurs, a signal is caught, or the type of data
next in the receive queue is different from that returned; for
example, out-of-band data.) This option takes an int value. Note
that not all implementations allow this option to be set.
At least BSD-derived stacks allow this to be set and have always done
so.
2) the application protocol doesn't require an application-level
response before that data can all be sent
Nope.
I can't make sense of what your disagreement with my statement is.
You are assuming that the five bytes of application data will always
fit in the receive buffer and the stack will never refuse to accept
new data when there are fewer than five bytes in the receive buffer.
These are all simply assumptions. They may or may not be true on a
given implementation,
Presumably, this would then be an implementation where setting
SO_RCVLOWAT to a value larger than 1 should not be possible.
[...]
In the case of TCP (which may not be what the OP is using), I'll cite
Stevens's "UNIX Network Programming, volume 1", section 7.5, wherein
he states:
With TCP, the available room in the socket receive buffer is
the window that TCP advertises to the other end.
Since he has no idea what window TCP advertises to the other end ...
In any event, existing implementations *DO* shrink their windows. This
is bad practice, but it's also bad to break if that happens. So even
if you knew a window size that was advertised at some point, the
window could in fact have shrunk.
This would be something the local TCP has done, which immediatlely
leads to the question which 'local TCPs' shrink there receive windows
such that contraints imposed by previously sucessfull attempts to set
a receive low water mark can no longer be met without posting some
kind of error notification to the application they have just picked
for being starved.
.
- Follow-Ups:
- Re: Setting size limit of data while reading or writing from sockets
- From: David Schwartz
- Re: Setting size limit of data while reading or writing from sockets
- References:
- Setting size limit of data while reading or writing from sockets
- From: osmankhalid2005
- Re: Setting size limit of data while reading or writing from sockets
- From: Mark Holland
- Re: Setting size limit of data while reading or writing from sockets
- From: David Schwartz
- Re: Setting size limit of data while reading or writing from sockets
- From: guenther@xxxxxxxxx
- Re: Setting size limit of data while reading or writing from sockets
- From: David Schwartz
- Re: Setting size limit of data while reading or writing from sockets
- From: guenther@xxxxxxxxx
- Re: Setting size limit of data while reading or writing from sockets
- From: David Schwartz
- Setting size limit of data while reading or writing from sockets
- Prev by Date: Re: Can't undate running process binary in Solaris?
- Next by Date: Re: Can't undate running process binary in Solaris?
- Previous by thread: Re: Setting size limit of data while reading or writing from sockets
- Next by thread: Re: Setting size limit of data while reading or writing from sockets
- Index(es):
Relevant Pages
|
