Re: Setting size limit of data while reading or writing from sockets

On Jul 5, 7:26 pm, "guent...@xxxxxxxxx" <guent...@xxxxxxxxx> wrote:

On Jul 5, 6:44 pm, David Schwartz <dav...@xxxxxxxxxxxxx> wrote:

No, this is incorrect. The size of the receive buffer is *NOT*
guaranteed to be measured in application data bytes.

You're correct: for some underlying protocols, the receive buffer may
include stuff other than application data. Somewhere along the way I
made the mistake of assuming the OP was talking about TCP, in which
case the receive buffer is limited to application data (yes, including
the OOB data, if present), at least that's how I understand the Single
Unix Spec's description of the socket receive queue.

The receive buffer is not limited to application data. And even if it
was, it might well at least need to store whether data is OOB or not,
and there's no particular limit to how many bytes that might or might
not take.

If the transport involved isn't TCP then other rules apply. My
apologies for not qualifying my original statements.

They apply to TCP as well. An application no way of knowing what the
implementation keeps in the receive queue.

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.

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, the next version of an implementation, or in
some strange corner case with a proxy and a remote Windows client with
a low-memory TCP implementation.

The networking stack has every right to refuse to receive any
more data until the application receives the data the stack has
already received.
No, it must not stop accepting bytes from the sender if there's
space in the receive buffer.

Why must it not? Did you just make that up?

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.

DS

.

Relevant Pages

  • Increasing TCP buffer and window for more throughput
    ... What's the relationship between TCP buffer and window? ... We modified rsync code to set socket send and receive buffer to 512k ...
    (comp.unix.solaris)
  • Re: Setting size limit of data while reading or writing from sockets
    ... the stack may wait for the application, ... With TCP, the available room in the socket receive buffer is ... Since he has no idea what window TCP advertises to the other end ... ... existing implementations *DO* shrink their windows. ...
    (comp.unix.programmer)
  • Re: ioctl(2) FIONREAD
    ... Your read may be needed for the stack to make further forward ... > state machine and waits for the next 10ms iteration. ... > there's space for a few more bytes in the output buffer. ... buffer the data yourself if for some reason the TCP stack won't take it. ...
    (comp.unix.programmer)
  • Re: Low FTP transfer rate when enabling Jumbo frames.
    ... My NIC is an Intel Pro 1000, and the possible setting for Jumbo frames ... the TCP windows size is 64K. ... window size to 128K and that doesn't change anything. ... copy of the user's buffer, and then schedules DMA from that copy. ...
    (comp.dcom.lans.ethernet)
  • Re: Set TCP_MAXSEG (OS buffering) on Win32? How?
    ... The problem is that the operating system is trying to open up the window to be efficient and I need to close it down because I'm buffering to talk over a pipe which speaks 20KB per minute!! ... The standard window is about a 4 *minute* buffer and this causes problems with the apps we are trying to proxy for. ... into tcp segments and sent over the wire. ... the problem I am having is controlling the advertised receive window on new connections - if there is a better way to set this via perl then I am looking for a solution - right now I believe that on win32 at least that the TCP_MAXSEG is the setting which controls this? ...
    (comp.lang.perl.misc)
Loading