HDTenEightyP/NetNews huggingface dataset:
From: booloo@framsparc.ocf.llnl.gov (Mark Boolootian)
Newsgroups: comp.protocols.tcp-ip
Subject: Silly windows, PERSIST timers, and ACKs
Date: 5 Oct 92 22:12:21 GMT
Organization: Lawrence Livermore National Laboratory

Greetings,

I am seeing what I believe is Silly Window Syndrome in action, and I would
like to ask a couple of questions.  The behaviour I see is something like:

	Receiver advertising 16 KB window, sender filling it with single
	packet.  At some point, receiver advertises 5KB window, then follows
	immediately with window update of 13 KB	.  Sender delays for 5 
	seconds before sending, then fills offerred window.  Receiver acks
	and offers 16 KB window again, etc.

If I have read the TCP code correctly (I've looked at Ultrix 3.0 and UTS 2.1.3
which is running Lachman & Assoc TCP, I think), it appears that when a 
sender sees a window which is less than half the size of the largest window
it has ever seen, it delays.  The sender uses the PERSIST timer for this
delay.  It also appears to me that the minimum value of the PERSIST timeout
is 5 seconds, at least on these systems.

According to comments in tcp_timer.h and tcp_output.c, when a sender is
delaying as a result of silly window syndrome, it will only send a packet
if (1) the timer expires, or, (2) a window update is received.  In the 
above rather terse example, the receiver sends an ACK with a small window,
but immediately follows it up with an ACK which updates the window to a much
more reasonable size.  Yet, there is still a 5 second delay before the sender
finally gets the data off.

Is this sender behaving badly by not responding to the window update?  The
receiver, when offering the small window, always follows it up immediately
(usually < .5 msec on our LAN) with a window update.  Is this receiver
not behaving well?

For what it's worth, the sender is an Amdahl running UTS 2.1.3 (Lachman net)
and the receiver is a Cray X/MP running Unicos 6.something.

Any information would be greatly appreciated (including corrections to anything
I said above).

regards,
mb
-- 
Mark Boolootian		booloo@llnl.gov		+1 510 423 1948
Newsgroups: comp.protocols.tcp-ip
From: bob@MorningStar.Com (Bob Sutterfield)
Subject: Re: Internet routing software for Sun
Organization: Morning Star Technologies
Date: Mon, 28 Sep 1992 00:44:22 GMT

In article <1694@eagle.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes:
   We hope to join the Internet soon and to start off we're looking
   for routing software to run on a SUN Sparcstation II.

It's not always necessary for hosts to participate in the routing
protocol fabric of the network.  You may be able to get by with static
routes pointing at the nearest router along the path outward from your
Sun to the rest of the world.

If you're using RIP between the routers on your network, then you can
use the Route Daemon (in.routed), which ships with SunOS.

If you're using some other routing topology protocol, then you'll
probably do well running the Gate Daemon on your Sun.  Get
gated.cornell.edu:pub/gated/gated-2.1.tar.Z and the three accompanying
patches, or get gated-alpha.tar.Z.
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: what does completion of write() really mean?
Keywords: TCP Nagle
Date: 5 Oct 92 19:26:42 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <921005125457@cream.ftp.com>, jbvb@vax.ftp.com (James B. VanBokkelen) writes:
>     
> With Nagle's algorithm, TCP can almost always Do The Right Thing when
> presented with a short write (e.g. either send it immediately or wait
> until previously transmitted data is ACKed).  The only case where overriding
> Nagle is reasonable is on the local net, where the application developer
> (or better, the sysadmin) decides that smoother throughput is worth more
> packets.  Overriding Nagle will seriously *reduce* both throughput and
> smoothness on a WAN connection through one or more heavily-loaded routers.


It's not just minor smoothing.  Some applications like to do

    for (;;) {
	write(small); write(small); read();
    }

The Nagle algorithm causes amazingly bad performance for such applications.

I think I've been told that common, standard X implementations like to
do such things.  And so common X over TCP (instead of various local
stuff) turns off the Nagle algorithm.

Never mind that combining the write()'s is the obvious thing to do.
The X guys say they have good reasons.


Vernon Schryver,  vjs@sgi.com
From: nelson@crynwr.com (Russell Nelson)
Newsgroups: comp.protocols.tcp-ip
Subject: CMU/MIT PC/IP source code
Date: 27 Sep 92 08:47:30 GMT
Organization: Crynwr Software

In article <1992Sep25.204104.21108@kronos.com> richb@kronos.com writes:

   Where might one find the CMU PC/IP source code for MS-DOS?  I know it
   used to be on husc6.harvard.edu, but that machine has been decommissioned.

hsdndev.harvard.edu

-russ <nelson@crynwr.com>  I'm proud to be a humble Quaker!
Crynwr Software            Crynwr Software sells packet driver support.
11 Grant St.               315-268-1925 Voice
Potsdam, NY 13676          315-268-9201 FAX
From: steve@dsnsun.ericsson.se (Steve Reynolds)
Newsgroups: comp.protocols.tcp-ip
Subject: IPX tunneling via rfc1234
Date: 1 Oct 92 15:46:37 GMT
Organization: Ericsson Telecom, Stockholm, Sweden

Can anyone help me with information on RFC1234 for tunneling of IPX traffic
through IP networks?

I have been asked to carry some IPX traffic over an IP net and this spec looks
too simple to be true!

Questions

Is anyone else implementing this?
Does it really work or are the constraints imposed by address mappings a
problem?

Thanks in advance 

Steve Reynolds
mail steve@dsnsun.ericsson.se
Newsgroups: comp.protocols.tcp-ip
From: bharvey@gandalf.ca (Brian Harvey)
Subject: genric print spooler wanted
Organization: Gandalf Data Ltd.
Distribution: w
Date: Fri, 25 Sep 1992 20:19:46 GMT

Can anybody help me find a source for a generic print spooler which
will redirect a print job to a network connected printer. Specifically a 
printer connected via a terminal server which does not have a resident 
spooler itself.

Thanks,

Brian Harvey 
harvey@gandalf.ca
Newsgroups: comp.protocols.tcp-ip
From: rob@icarus.inmos.co.uk (Robin Pickering)
Subject: Re: How to write TCP/IP specs in a procurement
Reply-To: rob@inmos.co.uk (Robin Pickering)
Organization: INMOS Limited, Bristol, UK
Date: Thu, 1 Oct 1992 08:48:47 GMT

shafer@CS.ColoState.EDU (spencer shafer) writes:
>
>  1. Does it make sense to reference the RFC's, i.e. does it do
>     anything?
>     2. What RFC's should I use?

The overiding standards for TCP/IP implementations are:

RFC1122  Braden, R.T.,ed.  Requirements for Internet hosts - communication 
         layers.  1989 October; 116 p. (Format: TXT=295992 bytes)
and
RFC1123  Braden, R.T.,ed.  Requirements for Internet hosts - application and
         support.  1989 October; 98 p. (Format: TXT=245503 bytes)
         
The former covering the operation of the TCP/IP stack itself and the latter
covering the operation of ``standard'' applications (FTP, MAIL, TELNET etc).

The standards contain two levels of specification for the operation of the 
protocol: MUST (MUST NOT) and SHOULD (SHOULD NOT). To be fully compliant
an implementation must obey all of these specifications. In certain
applications, because of their nature and the device
on which they are implemented, there may well be a good justification for not
implementing one or more of the SHOULD directives. In this case,
the implementation is said to be conditionally compliant.

All this is fully explained in the above documents.

--
   Rob.
Newsgroups: comp.protocols.tcp-ip
From: hsiung@csie.nctu.edu.tw (guest-user)
Subject: is there FAQ for this group 
Organization: Computer Science & Information Engin., Chiao-Tung U, Taiwan, ROC
X-Newsreader: TIN [version 1.1 PL6]
Date: Fri, 2 Oct 1992 02:10:57 GMT

Hello there,
    Sorry that I didn't see any information regarding the FAQ for this
group since I am new to this group.
    Can any one out there tell me where to get one?
Thanks in advance.
hsiung@csie.nctu.edu.tw

Newsgroups: comp.protocols.tcp-ip,aus.wanted
From: merce@xenitec.on.ca (Jim Mercer)
Subject: Re: AS400s and Suns together
Organization: Reptilian Research, Kitchener, ON, CANADA
Date: Mon, 05 Oct 1992 16:08:06 GMT

In article <3283@peking.gdwb.oz.au> was@gdwb.oz.au (Warren Stokes) writes:
>IBM are telling us all about how great the TCP/IP suite is for the
>AS400.  We are sceptical.  The interconnectivity between our Sun
>network and this replacement machine is essential.
>
>Are there any sites our there which are doing this kind of thing with
>Unix boxes and AS400s?  Does anyone have any comment on the quality of
>the IBM AS400 TCP/IP suite?

we have an AS/400, several AT&T 3B2's and a CP SysVR4 box here, with a
bunch of PC's on novell, using NCSA/CUTCP telnet to access the unix boxes.

IBM's TCP on the 400 works.  it is a bit ugly, and some things are broken,
by as far as FTP is concerned it works pretty well.

telnet into the AS/400 requires tn3270 or tn5250 (the latter is hard to find).

telnet from the AS/400 into the unix boxes is line mode only.

(i'm told that the next release will address this and allow vt100 in/out)

the SMTP stuff into OfficeVision is hideous.  mail does go from A to B,
but the headers are totally munged, and watch out for extraneous control
characters (my favourite being messages ending in "  \000\n" which
busts every MUA we have on the unix side)

given all of that, there are API's that look kinda berkeleyesque for 
RPG and Pascal (and i believe C).

i would encourage others to pick it up and run with it.  if we can get some
kind of cooperative code sharing thing going, we might be able to show
some of the traditional IBM shops what networking is really about.

personally i think an AS/400 would make an excellent news server. 8^)
(they tend to have oodles of memory and disk space)



-- 
[ Jim Mercer   Reptilian Research  merce@iguana.reptiles.org  +1 519 893-6085 ]
[             I don't want to work for a company that has a CIO.              ]
[              Disclaimer! I don't need no stinking Disclaimer!               ]
From: booloo@framsparc.ocf.llnl.gov (Mark Boolootian)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Silly windows, PERSIST timers, and ACKs
Date: 6 Oct 92 21:13:51 GMT
Organization: Lawrence Livermore National Laboratory

In article <1992Oct6.082044.4126@ericsson.se> etxmesa@eos.ericsson.se (Michael Salmon) writes:
>
>The original BSD code may well have had problems but it doesn't seem to
>apply here as the original poster stated that the destination site sent
>a gratuitous window update.
>

I would like to comment a little on this.  In my previous message, I stated
I observed the following:  Normally, the receiver advertises a window of 
16 KB.  At some point, the receiver advertises a 5 KB window (even though it 
acks all the data), then immediately follows with an ACK advertising a window 
of about 13 KB.  The result is the sender delays 5 seconds.  Is it possible
the sender is going to delay until the receiver offers another 16 KB window?

The reason I ask this is as follows:  Elswhere in the trace I took, there are 
exchanges where, after acking all the data in the previous packet sent, the 
receiver advertises first an 4 KB window, followed immediately by 12 KB, and 
then 16 KB (a total of three ACKs).  After the third ACK, the sender goes ahead
and sends 16 KB.

In the second scenario, we have no delay.  The only difference (I detect) from
the first case is that the receiver sends an ACK advertising a window of 16 KB,
a window equal in size to the largest window we have ever advertised.  Is it
possible this is what the sender is waiting for?

This is a rather nasty problem for us, as we are in the process of migrating
a Cray from HYPERchannel to FDDI, but are being held up (in part) by this
little oddity (which kills performance).

>Michael Salmon

regards,
mb
-- 
Mark Boolootian		booloo@llnl.gov		+1 510 423 1948
From: tmhoff@oogoody.Corp.Sun.COM (Todd Hoff)
Newsgroups: comp.protocols.tcp-ip
Subject: Network Topology Deducer Needed
Date: 29 Sep 1992 17:54:09 GMT
Organization: Sun Microsystems, Inc.
Distribution: world
Reply-To: tmhoff@oogoody.Corp.Sun.COM
NNTP-Posting-Host: oogoody.corp.sun.com

I'm not exactly sure what to call it, but are there any programs
out there than can determine what hosts are on a network, when
they change IP addresses, go down, come up, etc.. It was be nice
if was multi-protocol, that is work on Mac networks, etc..

Thanx for any help.
From: jordan@IMSI.COM (Jordan Hayes)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Nonblocking socket blocking on write
Date: 28 Sep 92 17:35:50 GMT
Organization: Investment Management Services Inc., NYC

Phil Romig <romig@cse.unl.edu> writes:

	When I call send() several times very quickly with small (aprox
	4096 bytes) buffers, after the fourth or fifth send the socket
	select() statement reports that the socket I want is blocked.
	It remains blocked for between 5 and 10 seconds, and then
	allows four or five more quick sends.

The other end is not reading fast enough.

/jordan
Newsgroups: comp.protocols.tcp-ip
From: hofer@rchland.vnet.ibm.com (Kent Hofer)
Subject: socket shutdown() - what's the deal
Date: Tue, 29 Sep 1992 18:39:28 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester
Keywords: shutdown

Help!

The semantics of shutdown() continue to completely elude me, even after much study/testing.  As I understand it, shutdown() allows you to shutdown the read side, the write side, or both sides of a TCP conversation.  Thus, if you shutdown the write side, a FIN will travel, and a read on the other side can complete with 0 (end of file).  If you shutdown the read side, on the other hand, no network traffic results.  Other reads on the same socket should no longer hang when no data is available, they sho




mplete with ???.  

I believe that the sematics of shutdown() also relate to multiple processes sharing the same socket.  If one of the processes has a read() or write() outstanding which is blocked, the appropriate shutdown will "break them loose" with EPIPE for write side and 0 for read side.  (BTW, do any applications actually use this particular semantic?)
  

Ok, so what's my problem?  Two things:

1) I want to know why anyone would use shutdown at all - 
 a) for the uni-directional "close" capability?
 b) for the "break em loose" capability?  (Do any socket applications actually share a socket across multiple processes?) 
 c) for some other reason that I haven't dreamed of yet?


2) What am I supposed to expect on a read(sd...) after issuing a shutdown(sd, read side)?  Please read the following two scenarios because they seem to give completely incosistent answers to this question!

   

SCENARIO 1:
	
application 1 issues shutdown(ns,read side) on its new just accepted socket descriptor (first operation on the new socket descriptor)

application 2 (the client) sends lots of data until it blocks on a send()
application 1 now issues a read(ns,...) and actually gets what seems to be a random amount of data - WHY should the read be able to get data?

SCENARIO 2:

application 2 (the client) sends lots of data until it blocks on a send()
application 1 issues a shutdown (ns, read side) on its new just accepted socket 
descriptor
application 1 now issues a read() and will get 0 back every time.  

Summary of question 2 and the scenarios:

From the results of the above scenarios, it appears to me that if data was already available to be read when the shutdown(read_side) was issued, it was discarded.  That seems reasonable.

Yet, if there is no data available to be read, a shutdown(read) is then issued, data is then received by TCP, and then the read() is issued... well then it seems that the application is actually given some data instead of the 0 for end of file.  This seems really strange to me, am I off in the outfield exporing things that no stable socket programmer would do?  Am I seeing a bug?  

THANKS for reading this, do me an even bigger favor and explain it to me!!!


-- 
Kent Hofer             hofer@rchland.vnet.ibm.com
(my opinions are my own and have nothing to do with my employer)

Xref: sparky comp.protocols.tcp-ip:4633 comp.protocols.snmp:680
From: mc@math.math.mv.dupont.com (Matt Cunningham-Software Development)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.snmp
Subject: Broadcasting - SLIP (Serial Line Internet Protocol)
Keywords: slip tcp/ip
Date: 5 Oct 92 18:00:39 GMT
Followup-To: poster
Distribution: usa
Organization: DuPont EOP, Morrisville, NC

A problem has been encountered in using SLIP to be the protocol to communicate
between two TCP/IP hosts.  The problem observed seems to be that packets
addressed for broadcasting to a particular SLIP network (such as SNMP traps)
do not appear to be transmitted like other SLIP packets that have a full IP
address instead of the broadcast address.  Is this a limitation of SLIP?  Do the
packets have to have a particular hosts' IP address in the packet and not just
the broadcast address of the network?  Is there any documentation available on
SLIP and how it works (limitations, features) besides the RFC1055?

Any information would be helpful.

							Thanks
							Matt Cunningham
							Software Engineer
							EOP Group
From: nelson@crynwr.com (Russell Nelson)
Newsgroups: comp.protocols.tcp-ip
Subject: SLIP and the PC 
Distribution: world
Date: Wed, 30 Sep 92 01:30:08 GMT
Organization: Crynwr Software

In article <1497@airgun.wg.waii.com> dla@se05 writes:

   I am having a heck of a time trying to get SLIP configured between my PC and
   my XYPLEX terminal server.

Serial links are fun to configure.  Lots of mistakes to make, lots of
things to learn.

   On my XYPLEX, if its on 145.144.100.3, I can configure my PC for
   145.144.100.213  right?

Extremely likely, but not necessarily.  It depends your netmask.
Also, the XYPLEX needs to know which port ...213 is on, and of
course, you have to be connected to that port.

   On my PC, I am trying to use the SLIP8250 or ETHERSL packet drivers, but I
   can't get the two machines to talk to each other.

Try 'ping'ing the machine from the XYPLEX and watching the modem
lights, or if it's direct connect, get a RS-232 monitor (one of those
cheapie $10 LED boxes will do).  If you don't get any characters into
the PC after pinging, then the problem is not in the PC.

After you're sure characters are being received, use pktstat to see
if any packets are being received.

Good luck!

-russ <nelson@crynwr.com>  I'm proud to be a humble Quaker!
Crynwr Software            Crynwr Software sells packet driver support.
11 Grant St.               315-268-1925 Voice
Potsdam, NY 13676          315-268-9201 FAX
From: lchiu@animal.gcs.co.nz (Laurence Chiu)
Newsgroups: comp.protocols.tcp-ip
Subject: Network Print under TCP/IP
Keywords: Printing UNIX Ethernet
Date: 5 Oct 92 22:35:14 GMT
Organization: GCS Limited, Wellington, New Zealand

This may be answered in the FAQ (if there is one) or trivially easy (I
am a neophyte in the area) so please bear with me.

We have an application which will run on a UNIX box. All users will
access the application via TCP/IP (on PC's) via ethernet (they will
also be connected to a Novell Netware 3.11 server for E-mail).
There will be no printers connected to the Unix box, rather we would
like printers to be either LAN attached or attached to LAN workstations.
Is it possible to print from Unix (or better from the application) to
a printer connected like this?
Would a network type printer like a HP Laserjet IISI work - i.e. if
it had TCP/IP connectivity?

Thanks for any assistance in this.


=========================================================================== 
 Laurence Chiu                      |
 Principal Consultant               |
 GCS Ltd, Wellington, New Zealand   |
 Tel: +64 4 801 0012                | Internet    : lchiu@animal.gcs.co.nz
 Fax: +64 4 801 0095                | Compuserve  : 71750,1527

 Disclaimer: I speak only for myself - usual caveats apply!
===========================================================================
Newsgroups: comp.protocols.tcp-ip,aus.wanted
From: elogan@mistxt.oc.com (Ernie Logan)
Subject: Re: AS400s and Suns together
Organization: OpenConnect Systems, Dallas, TX
Date: Mon, 5 Oct 1992 16:57:59 GMT

merce@xenitec.on.ca (Jim Mercer) writes:
>In article <3283@peking.gdwb.oz.au> was@gdwb.oz.au (Warren Stokes) writes:
>>IBM are telling us all about how great the TCP/IP suite is for the
>>AS400.  We are sceptical.  The interconnectivity between our Sun
>>network and this replacement machine is essential.
>>Are there any sites our there which are doing this kind of thing with
>>Unix boxes and AS400s?  Does anyone have any comment on the quality of
>>the IBM AS400 TCP/IP suite?

>telnet into the AS/400 requires tn3270 or tn5250 (the latter is hard to find).

Well, Jim, I tend to agree with most of what you said, except that TN5250
is hard to come by. You only need to email info@oc.com, or call or write:

OpenConnect Systems
2711 LBJ Freeway
Dallas, TX 75234
+1 214 484-5200

TN5250 is available for most *IX, VMS, and DOS platforms, including
MS-Windows. Try it, you'll like it! :)
Newsgroups: comp.protocols.tcp-ip
From: jbvb@vax.ftp.com  (James B. VanBokkelen)
Subject: Re: what does completion of write() really mean?
Nntp-Software: PC/TCP NNTP
Reply-To: jbvb@ftp.com
Organization: FTP Software, Inc., Wakefield, MA
Distribution: na
Date: Thu, 01 Oct 1992 17:31:11

In article <BvEGM1.6Kq@watserv1.uwaterloo.ca> erick@demorgan.uwaterloo.ca (Erick Engelke) writes:

    In article <920928162413@cream.ftp.com> jbvb@ftp.com writes:
    >
    >... In PC/TCP for DOS, it means that all the data has been transmitted,
    >but not necessarily acknowleged by the receiving TCP.  
    
    So does that mean you satisfy Nagle by blocking on subsequent writes?

I should have said "...except for any partial segment which may be delayed
due to the Nagle algorithm".

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488

Newsgroups: comp.protocols.tcp-ip
From: rdk@cc.gatech.edu (Bobby Krupczak)
Subject: Free user-space TCP/IP implementations?
Keywords: TCP/IP, user-space, free
Organization: College of Computing
Date: Fri, 2 Oct 1992 19:47:25 GMT

Hi!

I was wondering if anyone reading the list knew of a public domain TCP/IP
implementation that runs in user-space?  If so, would you email me a pointer to
the source?

I am working on a project where we are parallelizing protocol stacks to measure
performance speedup.  Anyway, we want to try to obtain some sort of comparison of
results.

Thanks in advance,

Bobby

-- 
rdk@cc.gatech.edu
From: yau@cs.utexas.edu (David K.Y. Yau)
Newsgroups: comp.protocols.tcp-ip
Subject: rlogin client
Date: 5 Oct 1992 23:47:39 -0500
Organization: CS Dept, University of Texas at Austin
NNTP-Posting-Host: godzilla.cs.utexas.edu

Hi,

I've compiled the rlogin client in Stevens' UNIX Network Programming.
When I tried to run it, I got `rcmd: socket: Permission denied'. On 
reading the book, the reason seems pretty obvious: rresvport, which is 
called inside rcmd, which is in turn called inside rlogin, checks for
superuser privileges before it returns a reserved port. Since I have
no problem doing an rlogin using the original rlogin program, which is
by the way /usr/ucb/rlogin, that means the original rlogin isn't 
compiled from the source in Stevens' book. So how is it different?
Can anyone give me a reply, preferably by email?

Thanks in advance,
David Yau (yau@cs.utexas.edu)

Newsgroups: comp.protocols.tcp-ip,comp.sys.sun.misc