Re: [OT] 8.0.x / 7.0.x progress

[Christopher Schultz <ch...@christopherschultz.net>]

Niki,

On 10/7/13 11:24 AM, Niki Dokovski wrote:
> On Mon, Oct 7, 2013 at 5:39 PM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
> 
>> Konstantin,
>>
>> On 10/7/13 10:24 AM, Konstantin Preißer wrote:
>>>> -----Original Message-----
>>>> From: Christopher Schultz [mailto:chris@christopherschultz.net]
>>>> Sent: Monday, October 7, 2013 3:29 PM
>>>> To: Tomcat Developers List
>>>> Subject: Re: 8.0.x / 7.0.x progress
>>>>
>>>> Konstantin,
>>>>
>>>>
>>>> Note that it's not Tomcat sending the ACKs, but the TCP/IP stack in the
>>>> OS running underneath the JVM. I wanted to point that out because it
>>>> means that Tomcat may be entirely unaware that data exists for reading
>>>> for some reason. If Tomcat itself were sending the ACKs, it would mean
>>>> that Tomcat was at least conceptually aware of the data, but refusing to
>>>> read it for some reason.
>>>
>>> Yes, that's correct. I guess there is some buffering in the various
>>> layers (TCP/IP stack of OS, Sockets in the JVM etc) so that when sending
>>> data, the client receive ACKS with a new window size even if the remote
>>> java code might not be reading the data.
>>
>> Exactly.
>>
>>> However, the buffering will not be endlessly so at some point TCP
>>> will advertise a window of 0 if the java code does not read from the
>>> Socket (at least this will be the case with blocking IO - though I do
>>> not exactly know how the non-blocking IO is implemented so I may as
>>> well be wrong here). This would mean that Firefox will have to wait
>>> until there is more window available to continue sending data.
>>
>> I'm not sure how big the average TCP/IP receive buffer size is. I'd
>> suspect a few MBs at least. It's bufferbloat at its finest ;)
>>
> 
> The SO_RCVBUF and SO_SNDBUF are system dependent socket options and
> typically are in range of 8Kb up to 60Kb. Those are socket level options
> though.

I wrote a quick program to check a simple PF_INET/SOCK_STREAM socket's
default buffer sizes.

On my Mac OS X 10.8.5:
SNDBUF=131072 (128k)
RCVBUF=131072 (128k)

On my 64-bit Linux 2.6 kernel:
SNDBUF=16384 (16k)
RCVBUF=87380 (85k)

I don't have a Windows compiler handy, so I couldn't check there.

-chris

PS here's the program in case anyone cares to try it:

#include <stdio.h>
#include <sys/socket.h>

int main(int argc, char *argv[]) {
  int sock;
  int value;
  socklen_t len;

  sock = socket(PF_INET, SOCK_STREAM, 0);

  len = sizeof(int);
  getsockopt(sock, SOL_SOCKET, SO_SNDBUF, &value, &len);
  printf("SNDBUF=%d (%dk)\n", value, value/1024);

  len = sizeof(int);
  getsockopt(sock, SOL_SOCKET, SO_RCVBUF, &value, &len);
  printf("RCVBUF=%d (%dk)\n", value, value/1024);

  return 0;
}