Date: Mon, 28 Jul 1997 14:14:21 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: root@bmccane.uit.net (Wm Brian McCane) Cc: wollman@khavrinen.lcs.mit.edu, larse@usc.edu, freebsd-current@FreeBSD.ORG Subject: Re: Who is working on the TCP stack? Message-ID: <199707282114.OAA01641@phaeton.artisoft.com> In-Reply-To: <199707281725.MAA11701@bmccane.uit.net> from "Wm Brian McCane" at Jul 28, 97 12:25:33 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Has anyone checked into the reported incompatiblities with MS > Winsock? I read in some 'Zine (Lan Times?) that Microsoft did > not follow the RFC, and that Sun has chosen to accept and work > with this incompatibility rather than wait for Microsoft to > correct their software. From what I read, the implementation > bug causes performance problems with non-MS Web servers (and > as such was probably on purpose, it wouldn't be the first > time). Anyway, I was just wondering if FreeBSD is affected > and/or if it has already been addressed. The problem is that the client applications, specifically the nono-Internet Explorer applications, do not call the WinSock function "shutdown( s, 3);" and then "recv( s, ...);" all the packets until the remote side close the connection. If the WinSock client does not call "shutdown( s, [2,3]);", then the PC will not send a FIN to the server. Note that there is some bias in the specification here for Microsoft WinSock implementations; specifically, if you call "shutdown( s, 3);", you can't also call "shutdown( s, 2);", and a number of non-Microsoft WinSock implementations will not correctly close down the connection (or send the FIN) with the "3" parameter. This basically means that if you use a non-Microsoft browser or client software, where they originators were primarily UNIX geeks (like NetScape), or if you use a non-Microsoft proxy server or WinSock implementation that doesn't act correctly on a "3" parameter and a client that uses a "3" parameter instead of a "2" parameter, then you are screwed. The Sun response was to implement a timeout in "FIN WAIT", just as there is a timeout in "FIN WAIT" in FreeBSD. This is not really a big deal, and it's not a failure to implement the TCP RFC, it's a failure of the client to trigger TCP RFC compliant behaviour. Clearly, the MS web servers run on MS OS's, and expect this common bug (and deal with it at the server stack level). As to whether FreeBSD is affected: it was, but it has timeouts (controllable via sysctl) now, so it's not an issue (the same soloution that Sun implemented). As far as the implication of collusion: I think it's more an artifact of the WinSock code being implemented as a DLL than any intent to make it screwed up: DLL's are an inherently screwed up architecture for implementing OS services, but they were the only viable way to jam socket services into the Windows 3.11 framework, before the MPR implementation in Windows 95 became widespread. Now there's a legacy issue of Windows 3.11 target software to support on Windows95, and the bogosity lives on... References: Windows(tm) Sockets Network Programming Bob Quinn, Dave Shute Addison-Wesley ISBN 0-201-63372-8 Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707282114.OAA01641>