From owner-freebsd-current Wed Jul 30 12:33:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA27583 for current-outgoing; Wed, 30 Jul 1997 12:33:47 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA27576 for ; Wed, 30 Jul 1997 12:33:43 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.8.5) with UUCP id NAA26355; Wed, 30 Jul 1997 13:32:40 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id NAA21104; Wed, 30 Jul 1997 13:34:17 -0600 (MDT) Date: Wed, 30 Jul 1997 13:34:16 -0600 (MDT) From: Marc Slemko To: Terry Lambert cc: freebsd-current@FreeBSD.ORG Subject: Re: Who is working on the TCP stack? In-Reply-To: <199707282114.OAA01641@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 28 Jul 1997, Terry Lambert wrote: > > 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. Erm... no. That has absolutely nothing to do with this issue. This particular issue is a disagreement in the slow-start implementation. Slow-start is documented after-the-fact in RFC2001 for anyone interested. The difference revolves around who should send what when; one box is expecting the other to send something, the other is expecting the first to send something, so they deadlock until one times out and retramsmits. Don't have the exact details offhand and I don't know if FreeBSD is impacted.