----MESSAGE-BEGIN---- <1983070606535100> Return-path: Received: from BBN-VAX by SRI-NIC via DDN; 6 Jul 83 11:47:24-PDT Date: 6 Jul 1983 10:53:51 EDT (Wednesday) From: Dennis Rockwell Subject: retransmit overtaking persist bug To: tcp-ip@brl-vgr, tcp-ip@nic, bbn-tcp@bbn-vax Cc: drockwel@bbn-vax There is a bug in the BBN TCP timer code which causes connections with large delays to hang. The symptom is that the sender will continually send single-octet packets which are one octet past the receiver's advertised window. The cause is that the persist timer (used for probing closed windows) was fixed, which the retransmit timer is adaptive (variable). When the persist timer goes off, it resets the retransmit timer. Thus, when the retransmit timer exceeds the persist timer, you hang. The fix is to replace the token T_PERS in tcp_procs.c (about line 250) with tp->t_xmtime*2. This is the only instance of T_PERS except for its definition (which you can delete if you wish). This guarantees that the persist timer is always greater than the retransmit timer. If you know of any system running the BBN software that doesn't receive one of these mailing lists, please inform either them or me. Sorry to send this out to such a wide audience, but this bug will bite more systems as the Internet grows. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983070808150000> Return-path: Received: from USC-ISIB by SRI-NIC via DDN; 8 Jul 83 16:57:00-PDT Date: 8 Jul 1983 1515-PDT Sender: CHASE at USC-ISIB Subject: Re: Possible ISIB TCP bug From: CHASE at USC-ISIB To: tcp-ip at SRI-NIC Message-ID: <[USC-ISIB] 8-Jul-83 15:15:05.CHASE> In-Reply-To: Your message of 18 June 1983 02:31 EDT The problem reported by KLH with Ftp between ISIB and MIT-MC has been fixed. The bug was in the Tops20 monitor code. Basically, Tops20 couldn't send a Fin at the time the Ftp process did its Close% because there was still data queued from a previous Send%, and by the time the data went out, the check for needing to send a Fin was missed. Much thanks to Ken for his accurate error reports and assistance in tracking this down. The fix inserts new check after PKZ23A. If the send side of the connection is still open but the user has done a Close%, ENCPKT is called to "encourage" a packet later, when the Fin can be sent. ========== PKZ23A: LOAD T1,TSSYN,(TCB) ; Get send state ;;;LDB T1,[110314,,13] CAIE T1,SYNCED ; Connection synchronized? ;;;CAIE T1,7 JRST PKZ24B ; No. No FIN can be sent. JN TSUOP,(TCB),PKZ24B ; Jump if connection still OPEN by user ; ;;;MOVE CX,13(14) ; ;;;TRNE CX,400 ; ;;;JRST PKZ24B MOVEI T1,^D200 ; Try to send FIN later, we must have been CALL ENCPKT ; unable to send it this time through ; (ie, due to presence of q'd snd data) PKZ24B: ========== While putting this problem to rest, it would be appropriate to put to rest some misconceptions that came out of the discussion of this problem. The TCPSIM package from BBN running at ISI does not just abort data connections in place of trying to close them properly. A Close% is done, and only after the Close% fails to take effect after a timeout period is an Abort% done to clean things up. I'm sure that the above bug caused it to appear to certain sites that only the abort was done. But although the package does have its shortcomings (the case in question is an example of its skimpy error reporting), it does the best that can be done in this case. The characterization of Tops20's TCP implementation as record oriented is not quite accurate. A user program can send one byte, two, ten or a whole page worth, without any kind of record or segment considerations. The monitor will buffer these bytes until there are enough of them for efficient transmission, or until the user program does a push. The real fault with the user interface is that it requires a different set of monitor calls instead of the Bin/Bout flavor, and that these calls are very clumsy to use. Now, however, the just released DEC user interface will hopefully restore consistency and simplicity to network i/o, and remove the need for simulation packages altogether. <>Dale Chase ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983071108595800> Return-path: Received: from UCLA-LOCUS by SRI-NIC via DDN; 11 Jul 83 16:34:20-PDT Date: Mon, 11 Jul 83 15:59:58 PDT From: Rich Wales To: tcp-ip@SRI-NIC Subject: XNS for 4.1BSD UNIX? Has anyone implemented the Xerox Network Systems (XNS) protocol in Berkeley UNIX (4.1BSD)? -- Rich Wales ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983071110140000> Return-path: Received: from RAND-UNIX by SRI-NIC via DDN; 11 Jul 83 17:28:57-PDT Date: Monday, 11 Jul 1983 17:14-PDT To: Rich Wales Cc: tcp-ip@SRI-NIC Subject: Re: XNS for 4.1BSD UNIX? From: guyton@rand-unix Yes, contact Network Research Corp (213)474-7717. Just fyi, I can't vouch for them or their implementation(s). -- Jim ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983072604454400> Return-path: Received: from PURDUE by SRI-NIC via DDN; 26 Jul 83 07:44:53-PDT Date: 26 Jul 1983 09:45:44-EST From: Paul McNabb Reply-to: pam@purdue.ARPA To: tcp-ip@nic Subject: TCP/IP for VMS I am looking for an implementation of TCP/IP under VMS. Any leads would be appreciated. Thanks in advance. Paul McNabb (pam@purdue) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983072613550000> Return-path: Received: from MIT-MULTICS by SRI-NIC via DDN; 26 Jul 83 15:13:16-PDT Date: 26 July 1983 17:55 edt From: Vinograd.Multics at MIT-MULTICS Subject: Re: TCP/IP for VMS To: pam at PURDUE cc: tcp-ip at SRI-NIC In-Reply-To: Message of 26 July 1983 10:45 edt from Paul McNabb See TCP-IP digest Vol 2: Issue 12 for a complete desc of same being done at UWISC. It includes IBM and UWISC contact names. DACU box is available from IBM 60/120 days ARO and costs about $15K. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983072701350000> Return-path: Received: from JPL-VAX by SRI-NIC via DDN; 27 Jul 83 08:48:19-PDT Date: 27 Jul 1983 0835-PDT From: Eric P. Scott Subject: TCP/IP for Data General MV/4000, MV/8000, or MV/10000 To: TCP-IP at SRI-NIC Reply-To: EPS at JPL-VAX If you know of any implementations for these machines, please reply to the list. Thanks in advance. -=EPS=- ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983072702030000> Date: 27 Jul 1983 0903-PDT From: Francine Perillo Subject: Re: TCP/IP for VMS To: pam at PURDUE, tcp-ip cc: PERILLO In-Reply-To: Your message of 26-Jul-83 0745-PDT There is yet another VMS TCP/IP implementation written by some people at Tektronix. The code is not completely Internet-compatible for example, they have not implemented gateway or internet control protocols. It was designed with Tektronix' internal needs in mind but it is available upon request. Contact Tim Fallon or Stan Smith in Beaverton, Oregon at (503) 627-5347 or try timf.tek@rand-relay or stans.tek@rand-relay. -Francine /NIC ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983072702350000> Return-path: Received: from SU-SCORE by SRI-NIC via DDN; 27 Jul 83 09:36:43-PDT Received: from Shasta by Score with Pup; Wed 27 Jul 83 09:37:50-PDT Received: from decwrl by Shasta with UUCP; Wed, 27 Jul 83 09:38 PDT Date: Wednesday, 27 Jul 1983 09:35-PDT To: Shasta!"tcp-ip@Sri-nic" Subject: Re: Re: TCP/IP for VMS In-reply-to: Your message of 27 Jul 1983 10:39:01-EST Wed, 27 Jul 83 11:08:56 EDT. From: Chris Kent Message-ID: <34.428171759@decwrl> Kashtan's stuff works and seems to be available from the Wollongong Group. It's full 4.1c networking code. The people at Rice that did the Phoenix Unix under VMS emulator are also reported to have the Berkeley TCP/IP running under their system, but I don't know details. Cheers, chris (Hope the header isn't too munged -- someone along the way is hacking mailers this week. Reply to cak@purdue if you must.) ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983072707085600> Return-path: Received: from BRL-VGR by SRI-NIC via DDN; 27 Jul 83 08:11:43-PDT Date: Wed, 27 Jul 83 11:08:56 EDT From: Mike Muuss To: pam@purdue.arpa cc: tcp-ip@sri-nic Subject: Re: TCP/IP for VMS I've heard of 2: *) Compion (aka DTI) has a product called ACCESS/T. Netmail a request to . *) Kashtan has ported the Berkeley UNIX TCP/IP to VMS. I don't know the availibility. Try or thereabouts. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983072805590000> Return-path: Received: from MIT-MULTICS by SRI-NIC via DDN; 28 Jul 83 07:01:15-PDT Date: 28 July 1983 09:59 edt From: DClark.INP at MIT-MULTICS Subject: Re: TCP/IP for Data General MV/4000, MV/8000, or MV/10000 To: EPS at JPL-VAX cc: TCP-IP at SRI-NIC In-Reply-To: Message of 27 July 1983 11:35 edt from Eric P. Scott Folks, The Data General division in Research Triangle Park, N.C., has recently taken on the task of doing TCP/IP for some DG machines. Unfortunately, I cannot remember which ones. Nor do I remember the name of the project manager of that effort. But the DG RTP office is small, and you could get a long way just calling, I expect. If that does not work, I could reconstruct the name with some effort; let me know. Dave Clark ----MESSAGE-END----