Path: utzoo!attcan!utgpu!watmath!iuvax!purdue!mentor.cc.purdue.edu!mace.cc.purdue.edu!abe From: abe@mace.cc.purdue.edu (Vic Abell) Newsgroups: comp.sys.next Subject: Re: buggy tcp interactions Message-ID: <2968@mace.cc.purdue.edu> Date: 23 Aug 89 13:50:08 GMT References: Reply-To: abe@mace.cc.purdue.edu (Vic Abell) Distribution: comp Organization: Purdue University Lines: 19 In article mdixon@thelonius.PARC.xerox.com (Mike Dixon) writes: >i spend a fair amount of time rlogin'd from my next to a nearby sun, >and occasionally get into problems where the connection seems to go >"out of sync" -- the last packet worth of output isn't displayed until >i type another character or a couple of seconds goes by (making it >feel as if the sun has suddenly become rather slow). We reported this problem to NeXT some time ago and were told that it is the fault of a TCP/IP bug in the kernel and will not be fixed until the 1.0 release. Our analysis suggests that the NeXT TCP/IP is employing delayed ACKs - wherein an ACK is not sent immediately but is queued for possible piggyback on a following transmission, or after a timer expires and forces its solo transmission. Without kernel sources we were unable to determine the exact nature of the kernel bug. The current, unpopular workaround most of us use is to type ^V. That forces the NeXT to send a packet to the remote peer in which the ACK can ride. Often it helps to reboot the NeXT work station (another, even more unpopular workaround).