[ https://issues.redhat.com/browse/JGRP-2504?page=com.atlassian.jira.plugin... ] Andrew Skalski commented on JGRP-2504: -------------------------------------- I tested TCP and TCP_NIO2, and the throughput issue is now resolved.  Thank you for looking into this! {quote}OK, so I read your comment. I understand socket options are inherited, but what sense does SO_SNDBUF make here? This option cannot be set on a ServerSocket anyway (perhaps this can be done in C?), only SO_RCVBUF, so does this mean the send-buffer cannot be set on a socket returned by accept()? {quote} That part of the documentation didn't make sense to me either.  Reading through the Linux sources and verifying empirically, the SO_SNDBUF option is definitely being honored, even when it is configured on the accepted socket. {quote}Also: {quote}If the application explicitly configures SO_RCVBUF, this automatic management is disabled {quote} Does this mean, the value of SO_RCVBUF is the *max* value a receive window can have? {quote} Yes.  SO_RCVBUF controls the buffer size, which in turn limits the receive window.  (The receive window grows/shrinks over time in response to quantity of data received, congestion and packet loss, the rate at which the receiving application consumes the data, etc.)  To illustrate, I configured both sites with SO_RCVBUF=200000 and graphed the window size over time during a send/receive test. !rcvbuf.png! -- This message was sent by Atlassian Jira (v7.13.8#713008)