Date: Tue, 18 Mar 2014 23:34:38 -0400 From: George Neville-Neil <gnn@neville-neil.com> To: Vijay Singh <vijju.singh@gmail.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: socket receive buffer size & window updates Message-ID: <91ECA466-61D8-4F7C-ABAD-D7565B8034DF@neville-neil.com> In-Reply-To: <CALCNsJTkQk41eXT0TLwVhHTuqbvk4iMsRttxwCsoWDTqbDVesA@mail.gmail.com> References: <CALCNsJTkQk41eXT0TLwVhHTuqbvk4iMsRttxwCsoWDTqbDVesA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 11, 2014, at 13:58 , Vijay Singh <vijju.singh@gmail.com> wrote: > The socket option handler currently doesn't prevent connecting or connected > sockets from changing their receive buffer sizes. In particular, I ran into > a an application that sets the receive buffer size lower than what it > originally was. > > In tcp_output(), if no data is being sent, there is code that is trying to > decide if a window update is needed. > > If the socket receive buffer size was reduced after a larger window was > already advertized, or perhaps even when there is data in the receive > buffer, it seems to me that the computation in 592 could go -ve, and be > interpreted as a large window update. > > I was led to this issue after observing in packet traces that duplicate > FINs were being sent on close. I tracked it down to this check. Should this > be changed to a check like such? > Interesting. Do you have a bit of test code? Best, George
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?91ECA466-61D8-4F7C-ABAD-D7565B8034DF>