HDTenEightyP/NetNews huggingface dataset:
From: trier@slc6.ins.cwru.edu (Stephen C. Trier)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TCP congestion/Nagle's algorithm
Date: 25 Jan 1993 19:09:55 GMT
Organization: Case Western Reserve University, Cleveland OH (USA)
NNTP-Posting-Host: slc6.ins.cwru.edu

In article <1993Jan23.113544.5652@nmsu.edu> amolitor@moink.nmsu.edu (Andrew Molitor) writes:
>	Second, Nagle seems to be saying that a TCP should not
>send new data while unack'd data is outstanding, while Karn's
>code seems to not send new data while unack'd data is outstanding
>*unless* there is a max segment sized chunk to go out.

I thought the latter is what Nagle said, too, but I just went and reread
it, and I think you're right.  He doesn't talk about sending immediately
when one can send a full packet.  RFC 1122 amends the 896, though, and
1122 does say that one should not wait for an ack before sending an MSS-
sized packet.

Perhaps what happened is Jacobson's Slow Start and Congestion Avoidance
algorithms provided a better way to solve the broader congestion problem,
so Nagle's algorithm is now used only for smaller-than-MSS packets.

RFC 1122 has a nice description of how all of the different "when to send"
algorithms, including Nagle's, fit together.

-- 
Stephen Trier                      "We want to offer you a price that you
Network software type               just can't afford to take advantage of."
Case Western Reserve University         - Sales blurb from HSC Software
trier@ins.cwru.edu
Newsgroups: comp.protocols.tcp-ip
From: Steinar.Haug@delab.sintef.no (Steinar Haug)
Subject: Re: What is TCP/IP ?
Organization: SINTEF DELAB, Trondheim, Norway.
Date: Tue, 26 Jan 1993 09:15:12 GMT

TOVSRUD@gribb.hsr.no writes:
> Can sombody out there give me a better discription about TCP/IP ?
> I have to learn what this is !!!

Better than what?

My favorite starting point is Comer's "Internetworking with TCP/IP",
available from Prentice Hall. Get it from your nearest bookstore...

Steinar Haug, system/networks administrator
SINTEF DELAB, University of Trondheim, NORWAY
Email: Steinar.Haug@delab.sintef.no, 
	sthaug@idt.unit.no, steinar@tosca.er.sintef.no
Newsgroups: comp.protocols.tcp-ip
From: rypma@waterloo.hp.com (Ted Rypma)
Subject: Re: query about 2 subnets/1 segment and directed bcast
Date: Thu, 28 Jan 1993 03:55:36 GMT
Organization: HP Panacom Div Waterloo ON Canada
X-Newsreader: TIN [version 1.1.4 PL6]

James Binkley (jrb@rigel.cs.pdx.edu) wrote:
: Back to 2 subnets on 1 segment again:
: 
: ...
: 
: We have an experimental server on zymurgy that is sending 
: out a directed broadcast on net 2 as 140.140.2.255. 
: Zymurgy has the capability to have 2 ip addresses
: attached to a single enet device.
: 		140.140.1.240
: 		140.140.2.240
: It is sending the directed bcast out to 2.255 as an
: ethernet bcast.
: 
: For "no apparent reason" an aix box and an hp X terminal too 
: (both on net 1 with 1 interface and 1 ip address on that
: interface)
: are picking up the directed broadcast and forwarding it
: ...
: Any insights here?  Mine is: "Life with 2 subnets
: in the presence of buggy tcp/ip implementations can be
: interesting :->"

BSD 4.3 networking code bites again... 

An IP implementation shouldn't forward a frame that comes in with a
broadcast (or multicast, for that matter) LLA. Unfortunately, 4.3
networking code throws away the information that the frame came in
on a broadcast link address, so ... If for any reason it is decided
by IP that the frame should be forwarded, then it will be if there's
a default or appropriate route.

I don't know about the AIX box, but the HP Xterminal does have two
network interfaces, even if you aren't using it ... the SLIP interface
on the serial port is 'attached', even though it isn't active. Having
2 interfaces and finding that a frame has been sent to it which has an
IP address that isn't any kind of broadcast address that it understands
(in fact, the address isn't even for its subnet), it forwards to the
default gateway, the Cisco box. You're lucky that the gateway was the
default or an ICMP redirect would also have been sent out.

The AIX box is probably doing something similar - it's something that
plagues this vintage of TCP/IP software.  Berkeley's Networking Release
2 fixed this by keeping a LLA broadcast/multicast flag in the mbuf header
that follows the frame around. Forwarding can thus be prevented for LLA
broadcasts (and 2 subnets on the same wire will be safer :-)

Incidentally, the most recent software release for the HP X terminal has
the network code modified so that forwarding to the same interface is never
done - the frame is just dropped. Check around on the AIX box and see if
there is any indication of 2 interfaces being attached (lo0, loopback
doesn't count). The forwarding code should never be called if there is
only one interface (in BSD 4.3/Tahoe code anyway).

Regards,

Ted Rypma
HP Panacom Division

(Any opinions, etc. expressed are entirely my own.)
even for its 

Newsgroups: comp.protocols.tcp-ip
From: jswanson@csfb1.fir.fbc.com (James Swanson)
Subject: Re: Distributed NFS
Keywordsubject: Re: Distributed NFS
Followup-To: Re: Distributed NFS
Reply-To: uunet!csfb1!jswanson
Organization: First Boston Corporation
Date: Fri, 22 Jan 1993 19:23:50 GMT

|>> Looking for a method of replicating NFS file systems...
!>
|> There's already a product available that does this called  the Isis Reliable
Network File System
|> from Isis Distributed Systems Inc.  Their mail address is ids@isis.com.
|>

Thsnks for your suggestion.  I already reviewed the ISIS product.  It has
several shortcomings:
        It will only export 1 file system for the entire network.
        It will not premit any other NFS mounted systems to be exported from
          the same server.
        It still has some nasty bugs.

I need to be able to use the "automounter" and "secure NFS" packages as well.
I think the best solution will include a mechanism to maintain synchroni-
zation without imposing too many non-standard restrictions.  As I mentioned
before, I would like to find a way to use the BIOD or NFSD daemons to
s: 

Subject: Re: Distributed NFS

|>> Looking for a method of replicating NFS file systems...
!>
|> There's already a product available that does this called  the Isis Reliable
Network File System
|> from Isis Distributed Systems Inc.  Their mail address is ids@isis.com.
|>

Thanks for your suggestion.  I already reviewed the ISIS product.  It has
several shortcomings:
        It will only export 1 file system for the entire network.
        It will not premit any other NFS mounted systems to be exported from
          the same server.
        It still has some nasty bugs.

I need to be able to use the "automounter" and "secure NFS" packages as well.
I think the best solution will include a mechanism to maintain synchroni-
zation without imposing too many non-standard restrictions.  I would like to 
find a way to use the BIOD or NFSD daemons to provide this funcitonality.

-- 
Jim Swanson
First Boston Corporation
5WTC - 9th floor
New York, NY 10048
(212)322-1085
Newsgroups: comp.protocols.tcp-ip
From: jswanson@csfb1.fir.fbc.com (James Swanson)
Subject: Re: Help with termcap/terminfo needed 
Reply-To: uunet!csfb1!jswanson
Organization: First Boston Corporation
Date: Fri, 22 Jan 1993 18:32:07 GMT

|> I have an application running on 2 different flavours of Unix.  The applicati
on
|> uses function keys F1 to F4.  The are defined as generating ESC-@ ESC-A ESC-B
|> ESC-C.  On one system they are passed in to the application as the appropriat
e
|> function keys and on the other arrive separately as ESC and then @/B/C etc.
|> All the terminal definitions are exactly the same.
|> This looks like a timing problem.  Is there a code that can be modified to
|> fix this or is my problem somewhere else ? (Like in the application which is
|> Informix and about which I know sweet **??!!)
|>
|> AdvThx
|>
|> --
|> Jo Baker, D9                        |email: jo@siesoft.co.uk
|> Siemens Nixdorf, Oldbury,           |Tel:   +44 344 850450
|> Bracknell, Berks, RG12 4FZ          |Fax:   +44 344 850096

I had this exact problem using Informix on AIX 2.0.  This symptom would
occur only when I was accessing AIX through a psuedo terminal (telnet or
rlogin).  I tried to get help from Informix and AIX, but each said the other
was crewing up (suprise!).
The problem is caused by timing, as you suspected, in the AIX pseudo-
terminal driver.  If the ESC and the @/A/etc. are received in separate
packets, they will be delivered separately to the application.  The application
is supposed to wait long enough after an ESC for the following character
to determine if it is an escape sequence (there must be a better way).  In
the case of AIX, and possibly other systems, the time between delivery of
the 2 packets is too long.

Finally, I solved this by writting a "wrapper" around the Informix application.
The wrapper would read from stdin and "bunch-up" any escape sequences before
delivering them to the application in one "write()".

The wrapper:
        opened the "tty" in a mode that allowed all cahracters to pass
        Forked a child which exec()'d the Informix application
        The wrapper tied its stdout to the child's stdin
        The wrapper passed every character to the application
        if the wrapper saw an ESC, it checked for a follow-on character
          with a reasonable timeout
        If none came, the ESC was passed
        If one did come, the ESC and the follow-on were passed together
          in the same buffer.

The wrapper can be tweeked to get the best timeout value, optimize character
throughput by reading with NOWAIT, etc.

I wish I still had the code to share with you, but this was two jobs ago
and I have lost track of it.

Hope this helps.




-- 
Jim Swanson
First Boston Corporation
5WTC - 9th floor
New York, NY 10048
(212)322-1085
Newsgroups: comp.protocols.tcp-ip
From: maritza@espresso.bae.bellcore.com (Maritza Ramirez)
Subject: Re: Determining Port Numbers & The RPC Portmapper
Organization: Bell Communications Research
Date: Fri, 22 Jan 93 00:42:03 GMT

In article <1993Jan21.155457.27880@panther.mot.com>, ronf@panther3.panther.mot.com (Ron Feigen) replies:
|> 
|> [text deleted, see earlier posting]
|> 
|> 
|> registerrpc will register a prog#/ver# with portmapper. Portmapper assigns the
|> port #.  svc_unregister() removes the entry.  pmap_getport() looks up a prog#/
|> version# on a host.  You must of course know the host name, prog# and version#
|> in advance.  Be careful about having the same prog# with different version #s.
|> Portmapper returns the port of a program with a match on prog #, but will give
|> you the latest (I believe) version # if it doesn't find an exact match.
|> 
|> 
|> [text deleted, see earlier posting]
|> 
|> Ron
|> 


I was just wondering if it is possible to connect and send commands to the 
RPC portmapper without using RPC calls (svc_xxx or pmap_xxx) but tli or 
socket calls. That approach of connecting and sending commands is possible
when working with some services. For example, I have some source code that 
sends commands to an ftp server after establishing a connection with it on 
its well known port 21. That program follows the same approach as when we 
use a telnet connection to send control commands to ftp (see example).

--o--

Example:
                    ___________________ ftp's well known port
                   /
$ telnet itsname 21
Trying 128.96.133.64 ...
Connected to itsname.
Escape character is '^]'.
220 itsname FTP server ready.  _____________ ftp server accepts connection
USER maritza
331 Password required for maritza.
PASS mypass123
230 User maritza logged in.
HELP
214-The following commands are recognized (* =>'s unimplemented).
   USER     PORT     RETR     MSND*    ALLO     DELE     SITE*    XMKD     CDUP
   PASS     PASV     STOR     MSOM*    REST*    CWD      STAT*    RMD      XCUP
   ACCT*    TYPE     APPE     MSAM*    RNFR     XCWD     HELP     XRMD     STOU
   REIN*    STRU     MLFL*    MRSQ*    RNTO     LIST     NOOP     PWD
   QUIT     MODE     MAIL*    MRCP*    ABOR     NLST     MKD      XPWD
QUIT
221 Goodbye.
Connection closed by foreign host.
$

Note that when using this approach, the commands that the ftp server
recognize are the low level commands described on the RFC959 (e.g.,
PORT, PASV, RETR, STOR).

--o--

The question is: Is it possible to connect and send commands to the RPC 
portmapper using tli or socket calls ?

The protocol specifications for the portmapper (appendix A of the RFC1057) 
does not say anything about the low level commands that the portmapper 
recognizes.

Does anyone knows which low level commands must be given to the portmapper
server after a connection is established to (1) register an application, 
and (2) get the assigned port from a client application ?


Thanks,

Maritza
Newsgroups: comp.protocols.tcp-ip
From: geertj@ica.philips.nl (Geert Jan de Groot)
Subject: Re: Moving from coax to 10BaseT
Organization: Philips Consumer Electronics, Eindhoven, The Netherlands
Date: Mon, 25 Jan 1993 09:51:34 GMT

Frank@mindlink.bc.ca (Frank I. Reiter) writes:

>In a recent column in OST James Gaskin suggests that system administrators
>should be converting ethernets from coax to 10BaseT and *not* investing
>anything more in coax.  I put two questions to the readers of this group:
>1) Do you concur with Mr. Gaskin that coax is dead or dying?

No, most certainly not. 10baseT is point-to-point. Which means that you
have to have a separate connection between the HUB and every apparatus
in your office. In my case, this would mean that I'd fill more than one
hub, just for my own equipment!

Coax has the big advantage that a new tap can be easily made by adding
another T and a piece of coax to the existing wiring.

10baseT is best if you have to run an office of non-technical people that
move around a lot and don't know they have to jumper their ethernet tap
if they move. Also, if they are sluggish about their cables and break
one once a while, 10baseT can be a lifesaver. (coax would mean that you
have to hunt for the defective tap every time, like a defect light bulb
in a christmas tree).

However, for an office of techies, often having more than one device
on their bench, I still very much prefer coax.

And then, one should not make an ethernet string too long anyway.
No more than 5 people depend on a single string to work here. Also, those
five are able to fill that segment quite severely so it's no use putting
up much machines.

Coax isn't 'dead'. It's just that for some applications, there are 
alternatives these days.

Geert Jan
Newsgroups: comp.protocols.tcp-ip
Subject: LPR and Fortran flow control RFC 1179
From: robin@vax1.mankato.msus.edu
Date: 22 Jan 93 17:00:24 -0600
Organization: Mankato State University

*********   Help    ********   Help   ********    Help    ********
I am trying to implement an LPR client using RFC 1179.  When trying to 
send fortran flow control to the server machine, I send a control file
with an 'r'+file+LF.  What exactly should I be sending as file???
Currently, I am sending the name of the df (same as is being sent by
the 03 (receive data file) subcommand.  So to sumerize I'm sending the
following data:

/*connect to remote host*/
[02]<queue>[LF]
[02]<size of control file> cfA100POJ1[LF]     /*POJ1 = hostname, 100 = JobNo */
CAS400-1.Mankato.MSUS.Edu[LF]
HAS400-1.Mankato.MSUS.Edu[LF]
J<Jobname>[LF]
L<Userid>[LF]
N<Source name>[LF]
P<Userid>[LF]
rdfA100POJ1[LF]
/*wait for ack here*/
[03]<size of data file> dfA100POJ1[LF]
<insert entire data file here>
[0]
/*wait for ack here*/
/*disconnect*/

For output we get a complete printout on the host... but the fortran flow
control is NOT interpreted and the "1" "0" "+".. etc. are printed.

Please reply directly to:

j3gum@vax1.mankato.msus.edu
AND
robin@vax1.mankato.msus.edu



THANKYOU THANKYOU THANKYOU THANKYOU THANKYOU THANKYOU THANKYOU THANKYOU 
Newsgroups: comp.protocols.tcp-ip
From: powell@wraith.netops.gtefsd.com (Mike Powell "GTE FSD Net Mgr")
Subject: Re: Anyone know of a good LPR/LPD Server?
Organization: Contel Federal Systems (Telecom)
Date: Wed, 27 Jan 1993 23:51:00 GMT

In article <16B5BE8CE.MACE@HDQCMS2H.UTSD.ATT.COM> MACE@HDQCMS2H.UTSD.ATT.COM writes:
>We have 10 LaserJet printers which we would like to connect to a LPD
>server, for access by our OS/2, DOS/Windows and IBM VM/CMS users.
> 
>We would rather not use LPD on various machines directly connected to
>the printers, since we would lose access to the printer when the machine
>went down (was re-booted or powered off).
> 
>The connections would be serial (RS-232), with one connection being
>parallel.
> 
>We have looked at the Lantronix equipment, but that does not really
>offer LPD; since we have a diverse user community, we want to use the
>LPR and LPRMON software that is provided with the TCP/IP implementations.
> 
>Does anyone have any suggestions?
Yes,
I am currently looking at three products:
Microplex M200/M201 default config 2 serial and 1 parallel
Axis AX-5 default config 1 serial 1 parallel
Lantronix EPS1 default config 1 serial and 1 parallel

Axis:
I currently have an evaluation unit from Axis. it does true LPD and
Novell print services. It does what it advertises.
508-777-7957 or info@axisinc.com

microplex:
They are next on the list for evaluation. It currently supports
LPD and Novell support has been announced.
604-875-1461, 800-665-7798 or sales@microplex.com

Lantronix:
"Support for Novell, TCP/IP, Ethertalk (Appletalk), LAT"
They are last on the list.
See other postings....
Phone: 714-367-0050 or 800-422-7022
--
Mike Powell PPASEL
"It's hard to find router bits for your cisco"
Disclaimer: I speak for myself. No direct relation to the DUAT folks.
internet: powell@wraith.netops.gtefsd.com  Usenet: uunet!wraith.netops.gtefsd.com!powell
From: wdrdjh@thor.cf.ac.uk (Dr D J Harvey 92)
Newsgroups: comp.protocols.tcp-ip
Subject: tcp/ip address assignments
Date: 26 Jan 93 13:34:34 GMT
Organization: University of Wales College of Cardiff, Cardiff, Wales, UK
X-Mailer: Cardiff Computing Maths PP Mail Open News Gateway

We are currently setting up a small tcp/ip network.

Although there are no plans to connect to the rest of the world at
present, I fell that it would be prudent to use unique, rather than
random, IP addresses, to allow for future possibilities.

How would I go about obtaining a class C network address (254
addresses), and does it cost ?

-- 
Dave Harvey  
(harveydj@cardiff.ac.uk)  tel: +44 222 552588
Dept Radiology, University Hospital of Wales, Heath Park, Cardiff CF4 4XW, UK
From: kate@wavefront.wti.com (Kathy Samec)
Newsgroups: comp.protocols.tcp-ip
Subject: More Slip
Date: 21 Jan 93 23:52:14 GMT
Distribution: usa
Organization: Wavefront Technologies Inc, Santa Barbara, CA

One more enquiry about slip. Is a particular modem necessary??

-- 
*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Kathi Samec			- Everything is beautiful and
Santa Barbara Studios		  Nothing hurt.
kate@wti.com					-Stoney Stevenson
Newsgroups: comp.protocols.tcp-ip
From: merce@xenitec.on.ca (Jim Mercer)
Subject: Re: Moving from coax to 10BaseT
Organization: Reptilian Research, Toronto, Ontario, CANADA
Date: Sun, 24 Jan 1993 23:10:44 GMT

In article Frank@mindlink.bc.ca (Frank I. Reiter) writes:
>In a recent column in OST James Gaskin suggests that system administrators
>should be converting ethernets from coax to 10BaseT and *not* investing
>anything more in coax.  

hmm, how nice of OST.  don't suppose they mentioned that you should kill
your unix boxes and put up OS/2, NT or Netware?  or even better, putting in
an AS/400, cause it so easy to get one, "just point and order".

>I put two questions to the readers of this group:
>
>1) Do you concur with Mr. Gaskin that coax is dead or dying?

for new buildings, dead, except for the possibiliy of backbone pulls of
thick coax to connect wiring centres, but then you might consider fiber.
'
for existing buildings, if you are pulling new cable, pull UTP.  you
will probably save some money on media.  you will spend it later in hubs.

twisted pair gives you more options, ethernet, token ring, CDDI (copper version
of FDDI), etc.

as far as converting coax to twisted pair, it's your call. if what you have
works, keep it.  you can connect 10baseT and thinnet networks.

>2) What options are available for small (less than a dozen nodes) networks
>currently running coax and wanting to move to 10BaseT?  For example, I
>understand that 10BaseT topology has all nodes wired to hubs - are there hubs
>available which are cost effective for small networks?

hubs come in many sizes, 4, 8, 12, 16 port stan alone, racks which take 8/12,
16 port cards, etc.
another selection you can make is "manageable" hubs.  hubs with SNMP management
tend to be almost double the cost (my experience) but worth it.

i find that coax is cool for tabletop/workbecnch testing, or workgroups that
have reasonable airspace around them.

having UTP throughout the building now allows us to wire 10baseT, Starlan1,
tokenring, RS232 and other stuffwith the same wire.  life is much better.

-- 
[ Jim Mercer   Reptilian Research  merce@iguana.reptiles.org  +1 416-506-0654 ]
[                      longer life through colder blood                       ]
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Sequence Numbers in TCP/IP
Date: 23 Jan 93 00:27:37 GMT
Organization: Auspex Systems, Santa Clara

>The window is how much the other end is prepared to accept (65535 implies
>infinite). (this is bigger than the maximum packet size on every network
>I have ever seen)

Yes, but, as far as I know, it's not required that the sending TCP stuff
everything into one packet, and there's a "TCP Big Window" option
mentioned in RFC1106, to increase the maximum window size beyond 64K. 

There's also an RFC, RFC1110, entitled "A Problem with the TCP Big
Window Option"; both date back to mid-1989, and not being a full-time
networking weenie, I don't know what the state of Big Windows in TCP is
(except that I seem to remember Vernon Schryver talking about cranking
the window size up when using FDDI, in order to light the fibre up, so I
suspect there's at least a semi-stable standard for Big Windows).
Newsgroups: comp.protocols.tcp-ip
From: ketil@edb.tih.no (Ketil Albertsen,TIH)
Subject: Re: Info wanted on TCP/IP vs OSI 7 layer
Organization: T I H / T I S I P 
Posting-Front-End: Winix Conference v 92.05.15  1.20 (running under MS-Windows)
Date: Wed, 27 Jan 1993 11:53:12 GMT

In article <SALKIELD.93Jan26224429@csqx.cs.rhbnc.ac.uk>, 
salkield@csqx.cs.rhbnc.ac.uk (Tom Salkield) writes:

>I am posting on behalf of a friend who needs to compare the layers of
>the internet protocol suite with the OSI seven layer model as part of
>his course assignment.

If you find any treatment of this that is both thorough and also 
objective and neutral, please let the rest of us know!

Almost any computer networks textbook will spend a page or two stating
that TCP corresponds to OSI Transport, IP to OSI net, but IP is 
connectionless while OSI is CO. That's about it - sometimes I wonder
how they can spend several pages saying nothing more.

Then you have the fighting young priests, making detailed comparisons
for the sole purpose of showing how useless (wretched or whatever) one
alternative is, compared to the other. For an excellent example of
this approach you may read M.T.Rose's treatment of OSI Session in The
Open Book. (If anyone would like to read my 40-page comment to The Open
Book, give me a hint and I'll mail it to you as a Postscript file.)

If a text exists at M.T.Rose's level of detail, but without his personal
opinions and judgements, I would be *very* happy to know of it!


Ketil Albertsen, 
College lecturer in computer communication courses