From owner-freebsd-current  Wed Jul 30 13:49:10 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id NAA02527
          for current-outgoing; Wed, 30 Jul 1997 13:49:10 -0700 (PDT)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA02519
          for <freebsd-current@FreeBSD.ORG>; Wed, 30 Jul 1997 13:49:08 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA05810; Wed, 30 Jul 1997 13:47:06 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199707302047.NAA05810@phaeton.artisoft.com>
Subject: Re: Who is working on the TCP stack?
To: marcs@znep.com (Marc Slemko)
Date: Wed, 30 Jul 1997 13:47:06 -0700 (MST)
Cc: terry@lambert.org, freebsd-current@FreeBSD.ORG
In-Reply-To: <Pine.BSF.3.95.970730132848.19785J-100000@alive.znep.com> from "Marc Slemko" at Jul 30, 97 01:34:16 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > 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.

I have never heard of this one, actually.

I do know for a fact that you can end up with thousands of sockets
in "WAIT FIN" with MS clients, effectively locking up UNIX servers.

I guess this is just another toy surprise in a long line of toy
surprises... 8-|.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.