Date: Sat, 9 Jan 2016 10:11:07 -0500 From: "Jonathan T. Looney" <jtl@freebsd.org> To: Sam Kumar <samkumar99@gmail.com> Cc: "freebsd-transport@freebsd.org" <freebsd-transport@freebsd.org> Subject: Re: TCP_HAVERCVDFIN Message-ID: <D2B685A4.4F28E%jlooney@juniper.net> In-Reply-To: <CAGtMfeBWzGAmt2Kq9bejon54xiz%2BHBOEjho1z=NZe_0fqG5Z2g@mail.gmail.com> References: <CAGtMfeBWzGAmt2Kq9bejon54xiz%2BHBOEjho1z=NZe_0fqG5Z2g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/8/16, 4:45 PM, "owner-freebsd-transport@freebsd.org on behalf of Sam Kumar" <owner-freebsd-transport@freebsd.org on behalf of samkumar99@gmail.com> wrote: >I am working with the code for the TCP Stack. Thanks for choosing FreeBSD! :-) >In summary I suspect that the TCPS_HAVERCVDFIN macro needs to be >redefined, >but I'm not sure whether that is actually the case. I wanted to open a >discussion about this to explore whether this is a legitimate issue. In short, it appears you are correct that the macro name does not match the reality of what it checks. This is likely to cause a problem at some point, so it is legitimate to suggest it be fixed. However, this is non-trivial for at least several reasons: A) Changing this will require thoroughly testing all the impacted code. That requires both a thorough conformance-testing suite, as well as thorough performance tests (in case the change impacts performance). However, I don't think the FreeBSD project itself has such things at the moment. (gnn@ might have more to say on this topic. :-) ) B) Even if the code you reference made an erroneous assumption, others may have written other code that assumes the current behavior. Changing the current behavior to be "more correct" might impact other code in subtle ways. (Hence, the need for testing: see (A).) C) Even if we can fully qualify that *our* code works correctly after changing this, third parties may have extended our system in ways that rely on the current behavior. (Hence the need for testing. They "own" that to some extent. But, we owe them some duty to be careful about changing basic building blocks they may use.) D) Changing this may make it harder to port code from other OSs. For example, OpenBSD uses the same definition of TCPS_HAVERCVDFIN that we do. On the other hand, it looks like NetBSD updated theirs (17 years ago!) to something closer to what you suggest. So, porting code from other OSs may already be problematic. Because we now have some level of TCP stack modularity, we *should* be able to build a TCP module that does what you suggest and let people try it out while maintaining the option to fallback to the main stack if things go haywire. However, that is more complicated than I wish it were because it currently requires *copying* code rather than just compiling the same code a second time. I have a proposal to address that, but need to circulate it and get feedback. In the meantime, we can talk through some of these obstacles and see how we want to handle this. We can always define two macros (the old and new one) and change the macro usage from the old to the new one as we feel comfortable. If there is desire to proceed, I would recommend that as the way forward, assuming we can satisfy the testing concerns. Jonathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D2B685A4.4F28E%jlooney>