The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: TCP-IP Distribution List - Archives (1993)
DOCUMENT: TCP-IP Distribution List for June 1993 (587 messages, 317251 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1993/06.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Jun 1993 03:48:19 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <C7wIq9.9pH@watserv1.uwaterloo.ca>, erick@sunee.uwaterloo.ca (Erick Engelke) writes:
> 
>  vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> > donp@novell.com (don provan) writes:
> >> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> >>
> >> I'm not sure what i ever did to you to illicit this tone
> >
> >What did you do? You played the same old game that regularly and
> >justifiably makes you Novell guys so hot.  That is to make
> >authoritative, prejorative, and wrong statements about protocols or
> >implementations you evidently know little about.  I would have not
> >snarled so if this lapse had been your only first, second or even tenth.
> 
> Ignoring all that, Don may have inadvertently reminded us that many 
> people such as he and I and many other TCP implementors may have never 
> inspected BSD code for inspiration, just the RFCs, relevant papers and
> packet dumps.  So sometimes it's not as political as one may think, just
> a different reference point.  In those cases non-BSDers are not prejudiced
> by the same references as you.  In some cases, like the discussion on 
> 'Urgent' vs. OOB, the Noveller's alternative viewpoint turned out to be
> inline with the original definition of the protocol.
> 
> But thanks for the authoritative answer.  


Hey! wait a minute.  No one in the netnews is really authoritative.
And it's not a matter of "politics."

Everyone who claims technical competence or just familiarity with TCP
and has with FTP access to the Internet must spend the hour or two to
get their own copy of the 4.3BSD-NET2 source from Uunet or elsewhere.
Everyone else should spend $25 and get one of the CDROMs with 
4.3BSD-NET2 source.

No one should go around repeating decade old, no longer true charges
("BSD wastes vast amounts of bandwidth with frequent keepalives")
without at least spending 10 minutes trying to check.

I rather doubt many people have figured out 4.3BSD's keepalive tactics
from packet traces.  Someone with too little patience to check the
source is not likely sit and watch an idle TCP circuit for 2 hours.

Anyone who cares about urgent data must look at both the new BSD and
the old BSD source.  You must look at the old BSD source to understand
what everyone agrees was the wrong way to do it, if only to ensure that
your implementation does die when it meets a wrong implemenation, and
to have a good answer when your customers call to complain.  You must
look at the new BSD source, if only to see what you'll be up against.

The unassailable TCP dogma "be liberal in what you accept" means being
right is an insufficient excuse for failing to interoperate.

How can you deal with the idle timeouts from BSD's FTP without looking
at the only good specifiation of them?  If you don't look at it, you'll
use keepalives instead, and make some of your customers angry for
"wasting bandwidth."

To fail to look at your competition would be dangerous and dumb.  Like
Detroit's reaction to Japanese cars, but worse, since you can't hope
for Congress to loan you a few $100M to fix the results of your hubris.


Vernon Schryver,

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Jun 1993 03:57:43 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple ether interfaces on the same subnet, revisited

In article <1993May31.165450.3798@mtu.edu>, bacon@mtu.edu (Jeff Bacon) writes:
> ...
> b. The main reason ethernet doesn't ever go at full wire speed is because
> of collisions - Jacobsen showed that a sun could drive an le interface
> at near wire speed, if the traffic was unidirectional and there were only
> two stations on the wire. ...

That's not what he showed, back in those distant times.  He showed that
TCP could run at nearly wire speed between such a of pair machines.
TCP is not "unidirectional."  If it were, no one would have been
impressed, since I trust no one would ever have claimed that it is
impossible to transmit at full ethernet speed without collisions.

Van Jacobson evidently did not do those measurements on wires with only
two stations.  Consider his discovery that VAX's would go crazy if they
suffered too many collisions.

The NFS traffic from clients to servers is not much more than the TCP
ACK's.  A hundred or so bytes of NFS request is not much different in
its effects on the wire than 54 bytes of TCP ACK.

In any case, most NFS servers don't do much more than 1 MByte/sec even
over much faster media than Ethernet.  The bottlenecks in NFS are
usually not in the medium itself.


Vernon Schryver,  vjs@sgi.com

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 1993 05:50:20 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Tunnelling or encapsulation?

In article <738877347snz@peeras.demon.co.uk> proyse@peeras.demon.co.uk writes:
    
    Can anybody give a simple mind a simple explanantion of the 
    difference between tunnelling and encapsulation?
    
Hmmph.  Well, this is a blurry line at best.  The basic operation is the
same in both cases.  You have a datagram at some level.  You wrap it in
some more "stuff".  It's encapsulation if the wrapper is at a lower level
than the payload (e.g., IP on Ethernet), and tunnelling if the wrapper is
at the same level (e.g., IPX in IP) or higher (e.g., X.25 in TCP/IP).

    This is with regard to sending IP packets over an X.25 subnet?
    
Well, I consider X.25 to be layer 2, so I would claim that this is
encapsulation.  I know others who feel that X.25 is more of a layer 3
protocol, so they would probably claim that it's tunnelling.  Ain't
networking grand?  ;-)

    Don't normal routers (Cisco et al.) wrap the fragments of an 
    IP packet in standard X.25 packets, once a virtual circuit
    has been set up?  

Well, I don't think that cisco routers are normal.  ;-)

But yes, that's the mechanism.

    Is this encapsulation or tunelling?
    
Yes.  ;-)

Tony

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 93 08:38:34 GMT
From:      tom@wcc.oz.au (Tom Evans)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.protocols.appletalk
Cc:        pug@wixer.bga.com@munnari
Subject:   Re: MacTCP 1.1.1 and DNS...

In article <1993May20.184813.2879@wixer.bga.com>, pug@wixer.bga.com (Pug) writes:
>    We have an ethernet network with a lot of Mac's on it. We have MacTCP
> 1.1.1 running on them and generally use NCSA Telnet 2.5. This is
> happening on all of our Macs so I don't think it's System dependant.
> What the problem is is this - When using MacTCP and having more then one
> server per domain, which is rather standard to have a primary and
> secondary server incase the primary is down, if the primary *is* down,
> it will not use the secondary for the domain.

There's been a lot of discussion on this thread, but I haven't seen
any (yet) answering the original question. From the archives:

> Article: 7445 of comp.protocols.appletalk
> From: resnick@cogsci.uiuc.edu (Pete Resnick)
> Subject: Re: MacTCP DNR+2 nameservers for same domain
> Date: 11 Feb 92 20:12:06 GMT <<<<<<<<<<<        Yup, from 16 months ago.
> Organization: University of Illinois at Urbana

anthes@geocub.greco-prog.fr writes:

>We have 2 nameservers for our local TCP/IP domain (1 primary+1secondary).
 
>In MacTCP, I configure the addresses of both nameservers, and choose the
>primary nameserver as the default.
 
>Everything works just fine, until the primary nameserver goes down...
>Then no Mac users using the DNS can connect anymore, because
>the secondary nameserver is never queried for the information.

The silly DNR again. What you need to do is make the domain name which
the secondary domain name server serves "." (i.e. just a dot, leave out
the quotes). Here's what's happening:

The domain name you type in the box to the left is the domain that the
domain name server serves. That means that this is the *only* domain
which the server knows anything about. An exception is made for the
default server, which is assumed to know about everything and is used
in every domain name lookup. Also, the domain name specified for the
default domain is used as the Macintosh's own domain, just to confuse
things even further. In any event, if you specified your domain as the
domain for the secondary server (which I'll bet you did), that server
will only be used if the name you are looking up is in your domain.
What you want is for the secondary server to serve *all* domains.  To
specify all domains, you use a single ".". Don't specify "." for your
primary nameserver domain, as that name is used as your default domain
as well.

Dumb enough for you?

pr
--
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: resnick@cogsci.uiuc.edu



-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Jun 1993 08:48:48 GMT
From:      keith@comp.lancs.ac.uk (Mr K C Craig)
To:        comp.protocols.tcp-ip
Subject:   re: MacTCP and DNS and Bootp


Thanks to all those who replied to my Mac TCP/IP post.  I think I have enough info now 
to fix my problems.

Keith Craig
MicroComputer Consultant
Lancaster University

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Jun 1993 09:32:43 GMT
From:      chou@csd.hku.hk (Chou Sui Lin)
To:        comp.dcom.lans.token-ring,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Print server box on token ring

Is there any print server box on token ring like those on Ethernet
such as Lantronix ...

Thanks
chou@sunmp.csd.hku.hk

-- 
-----------------------------------------------------------------------
Sui Lin CHOU                                     Email: chou@csd.hku.hk
Standard Chartered Securities			 Voice: 852-8016869
						 Fax:   852-8450971

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 1993 16:15:52 -0400
From:      xxronr@convx1.lerc.nasa.gov (Ron Rivett)
To:        comp.protocols.tcp-ip
Subject:   lpr/lpd public domain ?



Does anyone know if there is public domain version of the all of the software
for the lpr/lpd print spooling system ?  If so, could you let me know how to
access it (e.g. if its on an anonymous ftp site, the host name or IP address,
and the directory/file name) ?  

Thanks

================================================================================
Ronald R. Rivett                            voice: (216) 433-8281
Sverdrup Technology                 
NASA Lewis Research Center          NASA LeRC FAX: (216) 433-8000 
21000 Brook Park Road                      E-mail:  xxronr@convx1.lerc.nasa.gov
Cleveland, Ohio 44135                              rrivett@lerc.nasa.gov
Mail Stop 142-2               
================================================================================


-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 93 16:54:07
From:      kerch@reynaldo.PARC.Xerox.Com (Berry Kercheval)
To:        comp.protocols.tcp-ip
Subject:   Re: lpr/lpd public domain ?

In article <1uggqrINN341@nsat.ipp-garching.mpg.de> kld@nsat.ipp-garching.mpg.de (Klaus Desinger) writes:
   xxronr@convx1.lerc.nasa.gov (Ron Rivett) writes:

   >Does anyone know if there is public domain version of the all of the software
   >for the lpr/lpd print spooling system ?

   It's in the BSD sources, available almost everywhere. Try archie to
   find your nearest ftp site.

But it is not public domain, at least not as far as U.S.A. Copyright
law goes.  Just to make sure I went to ftp.uu.net and looked at lpr.c
in /systems/unix/bsd-sources/usr.sbin/lpr/lpr and found that it had a
standard BSD copyright header on it.

It *is* free though.

  --berry
--
Berry Kercheval :: kerch@parc.xerox.com 


-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Jun 1993 13:00:47 GMT
From:      vwelch@ncsa.uiuc.edu (Von Welch)
To:        comp.protocols.tcp-ip
Subject:   Re: Rare (but nasty) BSD TCP problem

In article <1u6bk8$2dm@genesis.ait.psu.edu>, barr@pop.psu.edu (Dave Barr) writes:
|> In article <1993May28.191300.21994@ns.network.com> hgv@herring.network.com (Harry G. Varnis) writes:
|> >I recently stumbled across an admittedly weird case of socket misuse
|> >that locks up SunOS 4.1 tighter than a drum.
|> 
|> Sure does.  I ran it on a 4.1.1B (plus lots of patches) machine and it
|> locked up real tight.  But, I ran it on a 4.1.3 machine and it was fine.
|> 
|> --Dave
|> -- 
|> System Administrator, Penn State Population Research Institute
|> End of article 2565 (of 2565)--what next? [npq]

Locks up 4.1.2 as well.

-- 
Von Welch (vwelch@ncsa.uiuc.edu)	NCSA Networking Development Group

 "It is better to not post and appear stupid than to post and prove it."
     - I speak only for myself and those who think exactly like me -

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Jun 1993 15:12:50 GMT
From:      bjbl@cdc.cdc.dk (Bjarne Blichfeldt)
To:        comp.protocols.tcp-ip
Subject:   HELP with isolan products

I am trying to access a printer connected to an Isolan terminalserver.
It seems that the Isolan TS is not transparent at all.
Does anybody know how to control such a thing.

The name of the box is : Isolan ESC/4 1210-0
I am using a C-program connecting via sockets (unix) to the box.

Please, any help is appreciated
thanks

email to bjbl@cdc.dk

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Jun 1993 15:25:48 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Rare (but nasty) BSD TCP problem

In article <1993May29.193018.2701@novell.com>, donp@novell.com (don provan) writes:
> Just for the record, although i concur that this is a rare and
> probably useless operation, it is not a "misuse".  There's nothing
> about this operation that violates any TCP principle, and the
> resulting TCP connection should be entirely legal and usable.
> 

	If we're talking about the same thing, then I think there very much
*is* an implicit restriction against it in TCP. TCP saves its state in a TCB
and that information will be different on each side of the connection. The
server side goes through different states than the client side, and the
"first close" side goes through different states than the "last close" side.
	So, first, an implementation that allowed it would have to allow
multiple TCB's for the same descriptor.
	But connection endpoints are identified by the <local IP, local port>,
<remote IP, remote port> pair. Those will be identical for the two TCB's in
the case where one endpoint is connecting to itself (and also listening on
the same address/port pair). Since it's not unique, TCP could deliver a
received packet to either, which obviously won't give you the results you
want. Packets you send may be delivered to yourself acting as receiver, but
they may also be delivered to yourself acting as sender-- ie, they can bounce
back to the originating TCB.
	So, the *protocol* does *not* allow it to work. If you're saying
an implementation should check for it and deliver the data properly, that's
not in any RFC that I know of, and I'm not sure that it can be done at all
through ordinary TCP.  I think the problem is inherent in the protocol
and "right" behaviour is to disallow it. Having schizophrenic TCB's isn't
such a great feature.
	I'd be interested in seeing an implementation where this works like
a loopback. But perhaps not just after lunch. :-)
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 93 16:43:09 GMT
From:      swaltner@donald.WichitaKS.NCR.COM (Steve Waltner)
To:        comp.unix.aix,comp.unix.admin,comp.protocols.tcp-ip
Subject:   rarpd/bootpd with AIX3.2/NCSA PC Telnet 2.3.06


   I am trying to get either rarpd or bootpd running on a RS/6000 model
320 running AIX 3.2 that has PCs running NCSA Telnet 2.3.06 connected to
it. I am having lots of problems with this.
   I tried bootpd first since AIX does not come with a rarpd. I modified
the bootptab file and tried telneting from the PC to the RS6K. This
failed when the CONFIG.TEL file had myip=BOOTP, but worked correctly
when myip was assigned to the IP address of the PC. The PC gave the
following output:
	Error 2 from sendbootp
	Error initializing network or getting configuration file
	BOOTP failed!!
   By looking at the debug output on the RS6K, I can tell that the
system found the IP address in the bootptab file and replied using the
RFC1024 format of reply. I tried compiling bootpd from the source I
ftp'd, but the same problem happens.
   I have also tried getting rarpd running. Since AIX doesn't have
rarpd, I ftp'd two different versions of source code for it. One
required a pup library, and the other required some device drivers named
bpfX, both of which do not come with AIX and I can not find.
   I would like to get either bootp or rarpd running so that the
CONFIG.TEL files can be exactly the same for all the PCs on the network.
Any help on running either package would be greatly appreciated.

--
Steve Waltner     | Steve.Waltner@WichitaKS.NCR.COM
NCR Corporation   | uunet!ncrcom!ncrwic!donald!swaltner
3718 N. Rock Road | Phone: (316) 636-8498 FAX: 636-8889
Wichita, KS 67226 |

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Jun 93 16:56:26 GMT
From:      skibo@florida.wpd.sgi.com (Thomas Skibo)
To:        comp.protocols.tcp-ip
Subject:   Re: Rare (but nasty) BSD TCP problem

In article <C7y873.8Lo@mentor.cc.purdue.edu>, dls@mentor.cc.purdue.edu (David L Stevens) writes:
|> 	I'd be interested in seeing an implementation where this works like
|> a loopback. But perhaps not just after lunch. :-)
|> -- 
|> 					+-DLS  (dls@mentor.cc.purdue.edu)

Try it on an SGI (before lunch?).

I think this problem gets pointed out every year or so.  I saw it pointed
out on this newsgroup a little over a year ago when I was in school.
IRIX handled it back then too so somebody around here knows how to fix it.

The problem apparantly has something to do with receiving SYN|ACK in
SYN_RECEIVED.  The TCP sends off a SYN and puts itself in SYN_SENT,
receives the SYN and puts itself in SYN_RECEIVED and sends SYN|ACK,
receives SYN|ACK in SYN_RECEIVED and decides that the SYN|ACK is
duplicate (it has already received the SYN) and drops it without
further processing and immediately ACKs it.  But then that ACK has
an incorrect ACK value because rcv_nxt isn't properly initialized
when the first SYN was received in SYN_SENT (a bug?).  That incorrect
ACK probably fires off another incorrect ACK etc. etc.

...or something like that.  :-)

-- 
---
Thomas Skibo     skibo@sgi.com     Advanced Networking, Silicon Graphics, Inc.

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 93 17:07:06 GMT
From:      bill@cs.uofs.edu (Bill Gunshannon)
To:        comp.sys.att,u3b.tech,comp.unix.admin,comp.protocols.tcp-ip
Subject:   Re: SLIP for 3B2

In article <1993May29.023338.25844@cobber.cord.edu>, tjohnson@cobber.cord.edu (Protius) writes:
|> 
|> About a year ago, I tried a system V port of KA9Q that I found on
|> wuarchive on a 3b2/300.  It worked... sort of.  I could telnet to
|> another machine, and login, but if I got lots of characters at once,
|> like a longish ls, the 3b2 couldn't keep up and KA0Q would lock up.
|> 

That's interesting.  I currently use KA9Q on a 3B2 as a router and file server.
I have 3 9600 baud connections (to a PC and 2 3B1's) and a 2400 baud port to
a TNC (radio link) and it works fine.  I even transfer multi-megabyte files.
On the radio link, it is painfully slow, but it works. And on the SLIP lines it's
just fine.  I even used to have a router to ethernet (a pc) on this hookup as well
with no problems.  If I ever get the time, I would love to try and hack ethernet
support for the 3B2 in the KA9Q code.  Oh well, maybe someday'

bill

-- 
Bill Gunshannon          | "There are no evil thoughts, Mr. Reardon" Francisco
bill@cs.uofs.edu         |  said softly, "except one; the refusal to think."
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 93 17:07:31 GMT
From:      ercm20@festival (Sam Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: Tunnelling or encapsulation?

Phil Royse (proyse@peeras.demon.co.uk) wrote:

: Can anybody give a simple mind a simple explanantion of the 
: difference between tunnelling and encapsulation?

Not me!  I wouldn't have thought there was a standard definition, but I
wouldn't know for sure.

: This is with regard to sending IP packets over an X.25 subnet?

Could be!

: Don't normal routers (Cisco et al.) wrap the fragments of an 
: IP packet in standard X.25 packets, once a virtual circuit
: has been set up?  Is this encapsulation or tunelling?

RFC 877 (2 pages!) which describes a minimal standard for carrying IP
over X.25.  It's what almost everyone who does IP over X.25 does. 
There's an update, RFC 1356 (?) which goes into much greater detail and
is more general.  RFC 877 doesn't seem to use either term (though I
don't have it on line and I'm not too confident in my ability to grep
paper) and I don't have a copy of the later RFC to hand, though this
technique is commonly called tunnelling.  

What is also called tunnelling is carrying X.25 traffic over IP, usually
in a TCP stream.  Cisco also do this.  There is no standard for this
kind of thing and the techniques are generally proprietary (Cisco's is
apparently 'not secret but undocumented'). 

Sam Wilson
Network Services Division
Computing Services, The University of Edinburgh
Edinburgh, Scotland, UK


-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Jun 1993 17:33:13 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Rare (but nasty) BSD TCP problem

In article <C7y873.8Lo@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>In article <1993May29.193018.2701@novell.com>, donp@novell.com (don provan) writes:
>> Just for the record, although i concur that this is a rare and
>> probably useless operation, it is not a "misuse".  There's nothing
>> about this operation that violates any TCP principle, and the
>> resulting TCP connection should be entirely legal and usable.
>
>	If we're talking about the same thing, then I think there very much
>*is* an implicit restriction against it in TCP. TCP saves its state in a TCB
>and that information will be different on each side of the connection. The
>server side goes through different states than the client side, and the
>"first close" side goes through different states than the "last close" side.

Nope.  Think again.  TCP is *symmetric*, so it's perfectly legal for
both sides to do exactly the same thing at exactly the same time.
Imagine two independent machines establishing a connection with each
other.  Both just happen to pick the same local port.  Both just
happen to send the initial SYN at exactly the same time.  The
connection should come up and be usable, right?  Admittedly, this is
because of the odd ability of TCP to successfully establish a
connection if two nodes at the same time attempt *actively* to
establish the same TCP connection.  This feature isn't clearly useful,
and i don't think it's used in real life, but none-the-less, there it
is, even diagramed on page 32 of RFC-793.  An implementation that
can't handle it would technically be in violation of TCP, although no
one would particularly care in practice (unless it lets evil forces
hang their system, of course :-).

OK, now think a little harder and you'll realize that a single node
talking to itself looks exactly like this.  When the local node sends
a SYN, the "remote" node also sends a SYN.  When the local node ACKs
the SYN, the "remote" node also ACKs the SYN.  As amazing as it seems,
the connection should get established.  Data transmitted on the
connection is received *by the same connection endpoint it was
transmitted on*.  Completely counterintuitive, but great fun!

The single TCB isn't a problem, mainly because TCP is duplex, so there
are values for both transmit and receive.  If a TCP implementation
hangs in the self-looping case, then i predict it will also hang in
the simultaneous connect case when the two nodes are sufficiently
synchronized.

The key is to recognize the in the loopback case, there's only one end
point, so there's only one TCB.  It's also interesting to note that
there is no "listen" involved in etablishing this connection.  That's
something many people don't realize is possible.  This causes the
little used state transition from SYN-SENT to SYN-RCVD which sometimes
causes implementors problems.
					don provan
					donp@novell.com

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Jun 1993 18:17:08 GMT
From:      cvh@space.physics.uiowa.edu (Chuck Herscovici)
To:        comp.protocols.tcp-ip
Subject:   Request for FAQ

Could someone tell me where I can find a copy of the FAQ for this group.  
Thanks in advance,

				Chuck


Charles Herscovici
Dept. of Physics and Astronomy
University of Iowa




-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 93 19:09:17 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Tunnelling or encapsulation?

In article <738877347snz@peeras.demon.co.uk> proyse@peeras.demon.co.uk writes:
>
>Can anybody give a simple mind a simple explanantion of the 
>difference between tunnelling and encapsulation?
>
>This is with regard to sending IP packets over an X.25 subnet?
>
>Don't normal routers (Cisco et al.) wrap the fragments of an 
>IP packet in standard X.25 packets, once a virtual circuit
>has been set up?  Is this encapsulation or tunelling?

I would call this encapsulation.  My definitions run something like the
following:

encapsulation -	Transmission of a packet using the services of a
		protocol of an architecturally lower layer.

tunneling -	Transmission of a packet using the services of a
		protocol of an architectural level equal to, or
		higher than that of the packet.

In the IP/X.25 example, I consider X.25 to be a link level service and
thus this is encapsulation.  Sending IPX over IP or X.25 over TCP, I
would consider tunneling.  This can all degenerate to splitting semantic
hairs, since it's all just stuffing packets into other packets.

Art

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Jun 1993 19:40:40 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Rare (but nasty) BSD TCP problem

	You're right. At first glance, I think it actually does the right
thing in my implementation, too. I'd say "by accident," but it's because
I followed the state machine carefully.
	Moral of the story: "TCP is bigger than the client-server paradigm."

-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 93 21:38:08 GMT
From:      eb@felix.Sublink.Org (Enrico Badella)
To:        comp.protocols.tcp-ip,comp.protocols.snmp
Subject:   Searching for hosts on a network.

Lately I was discussing with a friend a way of discovering all the host on 
a network; we came up with the idea of using ping and instead of 
specifying the host name use network_address.255. While trying the idea out
on a class C network made up of Suns (3 and 4), 386 PC (SCO, ISC, Linux,
386BSD) and no routers, bridges or other devices apparently evry host 
answers to the ping. Doing the same trick on a class B network nothing
would happen most of the times, once in a while a cisco router would
answer.
How can this be explained?
On this same subject, how do the variuos SNMP managers discover the host
on a net/subnet/subsubnet? I cannot believe they poll every possible 
address, which could be reasonable for class C networks but not on class
A or B ones.
Thank for your LIGHT!

-- 
Enrico Badella				Internet: eb@felix.sublink.org
Soft*Star s.r.l.			          eb@icnucevx.cnuce.cnr.it
Via Camburzano 9			Phone:    +39-11-746092
10143 Torino, ITALY			Fax:      +39-11-746487

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 1993 22:08:37 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Tunnelling or encapsulation?

In article <1993Jun1.190917.18916@acc.com> art@acc.com (Art Berggreen) writes:
>I would call this encapsulation.  My definitions run something like the
>following:
>
>encapsulation -	Transmission of a packet using the services of a
>		protocol of an architecturally lower layer.
>
>tunneling -	Transmission of a packet using the services of a
>		protocol of an architectural level equal to, or
>		higher than that of the packet.

That is roughly the definition I sent in e-mail, except that I would
define encapsulation without the level restriction: "transmission of a
packet using the services of the same or another protocol".  (As an
example of this usage, note that IP-IP is described as "encapsulation".)

Tunneling is a special case of encapsulation, matching your
definition.  When talking about that special case, the two terms are
equivalent.

I'd consider "encapsulation" to be a formal term, "tunneling" to be
more informal or slang.

Just my $.02.  I doubt _anyone_ is going to entirely agree on this
one.  Everyone knows what the words mean, but can we define them?  :-)

-- 
Stephen Trier (trier@ins.cwru.edu - MIME OK)   
Network Software Engineer              
IRIS/INS/T                               
Case Western Reserve University             

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jun 1993 00:45:00 GMT
From:      ira@plaza.ds.adp.com (Ira Hill)
To:        comp.protocols.tcp-ip
Subject:   Re: TN3270 HLLAPI or TelAPI?

HLLAPI does not affect the host communicating with
the remote unit. HLLAPI allows the user a standard interface
to 3270 data stream, which is dependent on the remote device
getting a 3270 data stream.

I have worked with several (well many) different HLLAPI packages. For
the most part they all provide a mostly seamless interface to the 3270
data stream. I have worked under OS/2 using comm manager and TCP/IP, 
I believe that Wall Data, Attachmate, and SSI all either have PC
TCP/IP packages or are going to be offering them soon. I have done
HLLAPI to a 9370 also using OS/2 and TCP/IP.

I have never seem completely seamless support, almost all packages
have different ways of handling multiple session interfaces, debugging
utilies, and session control start up and shut down. However any
of the above mentioned vendors are at or headed for OS/2 HLLAPI
compatability and seem to offer as much functionality as one
could ever hope to get from 3270. Happy HLLAPIing.

(Look at the Win NT support, I have talked to them in passing
and with the second vendor supplier with MS providing the
engine it looks very usable.)

--
Ira E Hill      A  DDDD   P P P 
ADP Dealer     AA  D   D  P    P     My postings are my
Services     A  A  D   D  P P P      own strange thoughts.
            A A A  D   D  P  
           A    A  DDDD   P          ira@plaza.ds.adp.com

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 1993 23:14:03 +0200
From:      kld@nsat.ipp-garching.mpg.de (Klaus Desinger)
To:        comp.protocols.tcp-ip
Subject:   Re: lpr/lpd public domain ?

xxronr@convx1.lerc.nasa.gov (Ron Rivett) writes:

>Does anyone know if there is public domain version of the all of the software
>for the lpr/lpd print spooling system ?  If so, could you let me know how to
>access it (e.g. if its on an anonymous ftp site, the host name or IP address,
>and the directory/file name) ?  

It's in the BSD sources, available almost everywhere. Try archie to
find your nearest ftp site.

-- 
Klaus Desinger                     kld@uts.ipp-garching.mpg.de
Rechenzentrum Garching                   Tel: +49 89-3299-2168

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jun 1993 03:24:29 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

 vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> erick@sunee.uwaterloo.ca (Erick Engelke) writes:
>> 
>> Ignoring all that, Don may have inadvertently reminded us that many 
>> people such as he and I and many other TCP implementors may have never 
>> inspected BSD code for inspiration, just the RFCs, relevant papers and
>> packet dumps.  So sometimes it's not as political as one may think, just
>> a different reference point.  
>> ...
>> But thanks for the authoritative answer.  
>
>Hey! wait a minute.  No one in the netnews is really authoritative.

Perhaps 'researched' answer.  It ill behooves me to practice the
guise of extensive vocabulary to express ideas which are contextually 
obvious.  I guess you must spend a lot more brain cycles writing your 
answers than do I.

>To fail to look at your competition would be dangerous and dumb.  

Sure, but have you inspected Novell's TCP source?  You better, they
ship more TCP than you or I do!

>Like
>Detroit's reaction to Japanese cars, but worse, since you can't hope
>for Congress to loan you a few $100M to fix the results of your hubris.

You're darn right, that money is needed in your country.

Erick
-- 
----------------------------------------------------------------------------
Erick Engelke				 	            WATTCP Architect
erick@development.uwaterloo.ca     TCP/IP was easy but i still can't work VI

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 93 13:57:19 -0600
From:      bartont@next1.msci.memst.edu (Tom Barton)
To:        comp.protocols.tcp-ip
Subject:   unix tcp/ip configuration via BOOTP

A particular question and a general question: Can someone point me to a BOOTP
client code buildable under popular unixes? With unix machines populating
desktops and being portable on a scale becoming commensurate with PCs and
Macs, why isn't configuration of the basic ip network parameters by BOOTP a
selectable default? I'm referring principally to non diskless machines.

I imagine the problem I'd like to address is already familiar to many who
manage largish ip networks. A user buys a desktop unix machine and simply
plugs it in to the handy data outlet. Eventually the ensuing trouble prompts
the user to discover who s/he should've contacted earlier to set it up
properly. A while later the user moves his/her office location and the cycle
repeats. A similar situation occurs with students (say) bringing their 3/486
portables in with 386BSD or equivalent and plugging in to a public lab
outlet. And it would be nice to be able to use BOOTP to reduce field time
necessary to reconfigure machines when ip network changes occur.

It would be wonderful if unix system vendors would support configuration by
BOOTP, as is typical for many popular PC and Mac tcp/ip apps/stacks.

In the meanwhile, I'd like to provide at least some users with special
portability requirements a mod to their rc files to accomplish this. A BOOTP
client that emits the info in the BOOTP response in parsable ascii on stdout
ought be sufficient for creating such mods. Does anybody have such a thing?

-- 
Tom Barton
t-barton@memst.edu
Dept of Math Sciences, Memphis State University, Memphis TN 38152

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jun 93 05:22:22 GMT
From:      paul@frcs.Alt.ZA (Paul Nash)
To:        comp.protocols.tcp-ip
Subject:   Re: TN3270 HLLAPI or TelAPI?

ira@plaza.ds.adp.com (Ira Hill) writes:

> I believe that Wall Data, Attachmate, and SSI all either have PC
> TCP/IP packages or are going to be offering them soon. I have done

CSIRO in Australia have written a fine tn3270 with HLLAPI for DOS,
which is available for free, and comes with source.  It is well
worth looking at if you want to use tn3270/HLLAPI on DOS.  FTP from
comsun.its.csiro.au (if memory serves).  Written by Kent Fitch, and
uses Erik Engelke's WATTCP stack.  Thanks, both of you!
 
 Paul Nash                    network grunt and bit-pusher extraordinaire
 paul@frcs.alt.za          PO Box 12475, Onderstepoort, 0110 South Africa

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Wed,  2 Jun 1993 13:56:40 -0400
From:      "Joshua M. Sabloff" <jsa5+@andrew.cmu.edu>
To:        comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Educational software

Is anyone aware of any educational software (CAIs, Hypercard stacks,
etc.) for routing (algorithms, general theory, etc.)?  If I'm not justin
taking a shot in the dark, please e-mail to jsa5@andrew.cmu.edu.  

If there is enough interest, I will post the results.

Thanks in advance!


Josh Sabloff
[ Term:  sabloff@husc.harvard.edu ]
[ Summer:  jsa5@andrew.cmu.edu    ]

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Wed, 02 Jun 1993 12:46:18
From:      jbvb@lard.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   RE: DECnet & TCP/IP. Can they co-exist???

In article <1tth3o$iak@lll-winken.llnl.gov> oberman@ptavv.llnl.gov writes:

    In Article <1993May25.092634@cantabria.cber.nih.gov>
    ramon@cantabria.cber.nih.gov (Ramon J. Hontanon) writes:
    >
    >We have the need to do FTP file transfer from/to a PC that is currently
    > running a  DECnet client in an all-DECnet ethernet.  My question is:
    >
    >- Will we need to reboot the machine to load the TCP/IP drivers after
    >    having run DECnet for awhile?
    
    Shouldn't need to. (I can't speak for all packages, but those using NDIS
    drivers (or any properly written ones) should have no trouble talking
    both.

As far as I know, you can still run PC DECNet using DEC's old "DLL" drivers,
as well as NDIS.  If you're using DLL drivers, PC/TCP has a kernel that can
co-exist with that too.

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


-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jun 1993 07:53:09 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <i7qd35m@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <1993May30.071840.14806@novell.com>, donp@novell.com (don provan) writes:
>> I'm not sure what i ever did to you to illicit this tone
>
>What did you do? You played the same old game that regularly and
>justifiably makes you Novell guys so hot.  That is to make
>authoritative, prejorative, and wrong statements about protocols or
>implementations you evidently know little about.  I would have not
>snarled so if this lapse had been your only first, second or even tenth.

You must have be confused with someone else.

>>       in that half a dozen years, i've never had the slightest
>> interest in finding or retrieving the BSD sources, let alone studying
>> them well enough to find the one line you tell me i'd be looking for:
>
>Then how do you presume to make statments about how 4.3BSD TCP works or
>what it does?

What i said was, "I'm hearing that BSD is brisk enough with its
keepalives to detect a failed node within minutes."  My intention was
to phrases this so it clearly wasn't an authoritative statement, and i
had no intention whatsoever of being critical of 4.3BSD.  I'm sorry
you took it the wrong way.

>The "studying well enough" consists of starting with
>`grep -i 'keep.*alive' *.[ch]`, skimming the code and comments
>that unearths, and repeating the process about 4 times.
>Given on-line source, this effort requires less than 10 minutes.
>How do I know it takes less than 10 minutes?  Guess how.
>...
>> I take it this makes the default time two hours?  How is the default
>> time overridden, and how many installations or applications override it?
>
>That depends on details of the 4.3BSD port.

So much for the behavior being defined by the 4.3BSD source: now you
tell me that it could be different for different ports.  How was the
4.3 source going to tell me what was typical of all the 4.3 ports?

>In other words, in answer to your implicit charge, practially no
>one changes or overrides the default, 2 hour 4.3BSD keepalive.

Thank-you.  I made no charge, but this is the information i needed.

						don provan
						donp@novell.com

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Wed, 02 Jun 93 20:52:52 -0400
From:      "Andrew Luck" <p00078@psilink.com>
To:        comp.protocols.tcp-ip
Subject:   Win-sockets w/ NIS (Was PCeudora)

Well, a number of folks had suggestions for what to look at, but
the bottom line is this:

When I'm not running PC-NFS over NIS (no DNS), everything works fine.

By changing only the network.bat file to invoke NIS, everything goes awry.

A couple of folks told my that there is a bug in the getservent functions,
which causes problems when trying to resolve a services entry through NIS.

I checked this by logging directly onto the SUN IPX which is our central
server.

ypmatch  aluck passwd    gives back the expected information.
ypmatch  structur group  gives back the expected information.

ypmatch  pop3 services

gives back:  Can't match key pop3 in map services.byname  Reason: No such key in map.

BUT,  ypmatch 110/tcp services

gives back:   pop3  110/tcp  pop # Post Office Protocol Ver. 3

This is very weird, since if I boot up a PC DOS 6.0 with Windows 3.1
and go into PC-NFS v5.0 and query the Network Information Icon with
pop (partial string), I get back both information on pop2 and pop3.

I get the same kind of funkyness with networks, hosts, and protocols files.

If there is a known bug in windows sockets apps or the getservbyname which
is causing this problem, is it getting worked on?  Is there a patch?

Sun IPX  Sun OS 4.1.2

Thanks to all those who responded.  Everything else checked out.
Other popmail clients (2 & 3) are not having this problem (except 
WINQVT for PC-NFS, I think.  I get the same response on this.)

I like the idea of windows apps with sockets, 
but I have to have NIS (w/o DNS, for now)



-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 93 14:41:50 GMT
From:      mike@galt.osd.mil (Mike Dertinger)
To:        comp.protocols.tcp-ip
Subject:   Command for getting ethernet addr

Is there a Unix command for getting the Ethernet address
on the localhost?  I use the arp tables to get Internet
and Ethernet addresses of everything in a subnet, but
the arp tables do not hold localhost information.

Any help would be appreciated.  Either post to this group
or email me at mike@galt.osd.mil.

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jun 1993 15:08:29 GMT
From:      gwhite@inetg1.ARCO.COM (Gary White)
To:        comp.protocols.tcp-ip
Subject:   how to reconfigure Sun 4.1.3 kernel for more TCP/IP space

Hi-
I keep getting "mbuf map full" fatal error messages on a rather busy SS2
and would like to reconfigure my kernel to allow more buffer space.  Does
anybody have an idea what to change to accomplish this?  This is one 
area where AIX has made life really easy, by comparison.  Thanks!!
-Gary

-- 
Gary White				voice...(214) 754-6554
ARCO             			PRC-E1136B
2300 W Plano Parkway                    fax...(214) 754-3017
Plano, Texas  75075

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jun 1993 15:26:58 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <C7z5Gu.BzD@watserv1.uwaterloo.ca>, erick@sunee.uwaterloo.ca (Erick Engelke) writes:
>  ...
> >> But thanks for the authoritative answer.  
> >
> >Hey! wait a minute.  No one in the netnews is really authoritative.
> 
> Perhaps 'researched' answer.  It ill behooves me to practice the
> guise of extensive vocabulary to express ideas which are contextually 
> obvious.  I guess you must spend a lot more brain cycles writing your 
> answers than do I.

I like "researched", provided enough citations, bibliography, or whatever
are included so that a reader can check the real authorities.

Too many people think the netnews is literally authoritative.  Maybe
that's just the reverse of the oddity of refusing to admit that
anything except the Writings of Accredited Standards Committees can be
authoritative.


> >To fail to look at your competition would be dangerous and dumb.  
> 
> Sure, but have you inspected Novell's TCP source?  You better, they
> ship more TCP than you or I do!

I doubt that there are as many Novel TCP/IP installations than BSD
based installations, but that does not seem relevant.

There's a relevant difference.  Novell's code is not free, freely
available, or freely redistributable.  Even if you had a copy of
Novell's code, you'd need to use "clean rooms" to avoid contaminating
your own code.  BSD's code is free.

Anyone who sits down to write a PPP implemenation and does not
peak at Drew Perkins' code and its successors on uunet is sick.
So is anyone who starts to write a C compiler without knowing a lot
about pcc, and maybe now gcc.  Such is worse than simply the Not
Invented Here syndrome.


> >Like
> >Detroit's reaction to Japanese cars, but worse, since you can't hope
> >for Congress to loan you a few $100M to fix the results of your hubris.
> 
> You're darn right, that money is needed in your country.

You mean for Industrial Policies?  E.g. to save the computer
businesses of IBM, Apollo, RCA, Xerox, and Borroughs?


Vernon Schryver,  vjs@sgi.com

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jun 1993 15:27:07 GMT
From:      raghu@scs.carleton.ca (raghunath govindachari)
To:        comp.protocols.tcp-ip
Subject:   Formal specs of Internet suite

Is any one aware of formal specification of TCP/IP suite of protocols and other protocols in the internet suite? If so I would appreciate some references to papers etc. If not, I would like to know why there is none? 
What is the current thinking on need for formally specifying protocols in a manner similar to that have been done in OSI.

I have gone through formal specs of OSI services and protocols in LOTOS.

Thanks in advance

Raghunath Govindachari
School of Computer Science
Carleton University
Ottawa, Canada.
email : raghu@scs.carleton.ca





-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jun 1993 16:03:11 GMT
From:      ira@plaza.ds.adp.com (Ira Hill)
To:        comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.ibm
Subject:   Re: CPI-C over TCP/IP

MACE@HDQCMS2H.UTSD.ATT.COM wrote:
: In article <C7r3LJ.E9M@magna.com>
: yefim@magna.com (Yefim V. Natis) writes:
:  
: >I am looking for communications software with CPI-C (or near) API to use on
: >a TCP/IP-connected network.  The hardware involved is the major flavors of
: >UNIX servers, the IBM mainframes, and Bull (Honeywell) mainframes.
: >

We are using the SSI Express product on our Motorola machines. Express 2.0
will support both CPI-C and TCP/IP and I know that they support many other
platforms. The phone number for the resp. desk is 212-279-1515. I do not
know if they are supporting mainframes or not.

I talked to Wall Data about a year ago and at that time they were working
on a UNIX version of there system and I know they were also working on 
9370 stuff with IBM. They are in the phone book for Sea??? WA. These are
very good people to work with.

--
Ira E Hill      A  DDDD   P P P 
ADP Dealer     AA  D   D  P    P     My postings are my
Services     A  A  D   D  P P P      own strange thoughts.
            A A A  D   D  P  
           A    A  DDDD   P          ira@plaza.ds.adp.com

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 93 16:15:26 GMT
From:      haysg@bcsaic.boeing.com (Garve Hays)
To:        comp.protocols.tcp-ip
Subject:   SLIP:  slattach gets segmentation fault (core dumped)

Hi,

I have installed the driver and have running the unsupported SLIP utility
under ULTRIX 4.2a.  It runs great between two DECstation 5000/25 nodes I
have set up at a remote site we support.  The problem occurs when I
attempt to establish a master from my site to a slave at the remote site.  After
I enter the pertinent information in the /etc/sliphosts file and then attempt to
make the connection (/usr/new/slattach dax - where dax is the label in my
sliphosts file), it immediately bombs:  segmentation fault (core
dumped).  It barfs so fast that I suspect it is choking on something in
the sliphosts file, but other than the phone number and node name this
entry is identical to the working ones.  Anyone have any ideas or seen
this behavior before?  Thanks in advance.

-Garve

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jun 1993 17:01:19 GMT
From:      amundson@yukawa.uchicago.edu (James Amundson)
To:        comp.protocols.tcp-ip
Subject:   Personal SLIP or PPP

Can someone please tell me if I can do this? I would like to install either
SLIP or PPP on my unix account *for my own use only.* I am not the system
adminstrator and I do not have root privileges. I would like to install an
implementation of SLIP or PPP that allows me to log in to my account and
then fire up a program that allows me to do IP over a serial line.

I've been looking at lists of frequently asked questions and installation
instructions for PPP, but I can't determine if what I want to do is even
possible. Can someone tell me?

Thanks,

Jim Amundson

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jun 93 17:04:26 GMT
From:      sondre@brosme.dhmolde.no (Sondre Haugen)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: Internetworking book (solution)

Jeffrey S. Curtis (curtis@achilles.ctd.anl.gov) wrote:
: curtis@achilles.ctd.anl.gov (Jeffrey S. Curtis) writes:
: }I've searched high and low for a copy of the book _Internetworking:
: }Bridges and Routers_ to no avail. [...]
 
: I've been informed that the correct title is _Interconnections:
: Bridges and Routers_ by Radia Perlman for Addison-Wesley, ISBN
: 0-201-56332-0.  Thanks to Greg Dobrich for this info.
 
: Jeff
: --
: Jeffrey S. Curtis - curtis@anl.gov     / Argonne National Laboratory
: Research Assistant, Network Section    / Electronics and Computing Technologies
: Polk - Phase Linear - Sanyo - Proton   / 9700 South Cass Avenue
: Jensen - Sony - StreetWires - Sennet   / Argonne, IL 60439      +1 708/252-4750 

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Wed, 02 Jun 93 14:17:55 +0200
From:      bg@tnis.fr.mugnet.org (Bernard.Guillaumot)
To:        comp.protocols.tcp-ip,comp.protocols.snmp
Subject:   Re: Seeking advise on EPILOGUE's software

dberry@csa.cs.technion.ac.il (Dan Berry) writes:

> (Orna Berry-Keren using Dan Berry's account).
> I would like to ask whether people have experience in integrating
> Epilogue's software (UDP/IP/TCP/telnet/SNMP...).
> Can any one compare it (in quality and ease of integration) with other
> available packages?

We are also interested by same informations..

Bernard.


--
| E.mail: bg@tnis.fr.mugnet.org - bg@tctel.fr.mugnet.org (Bernard.Guillaumot)
| Server: (33)-{1}46-085-205 - V23/V22bis - (33)-{1}46-211-912 - V32/PEP

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jun 1993 17:41:38 GMT
From:      ohd@ornl.gov (OLIVE D H)
To:        comp.protocols.tcp-ip
Subject:   Request for this groups FAQ

I've seen other requests for the FAQ but no responses telling how to get it.

Please send me one  O-FAQ-GOD.



-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jun 1993 17:54:24 GMT
From:      ohd@ornl.gov (OLIVE D H)
To:        comp.protocols.tcp-ip
Subject:   Where to start?

Obviously the FAQ is a good place to start but I'll ask the question anyway.

I'm trying to install slip on a Decstation 5000.  

Where do I begin?  
Is cslip-2.6 only for suns?  
Is cslip the best?  
What is ppp?
How do you setup hardware flow control?

Please help.


-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 1993 17:55:19 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.protocols.tcp-ip
Subject:   Re: Command for getting ethernet addr

Mike Dertinger (mike@galt.osd.mil) wrote:
> Is there a Unix command for getting the Ethernet address
> on the localhost?  I use the arp tables to get Internet
> and Ethernet addresses of everything in a subnet, but
> the arp tables do not hold localhost information.

If your local host supports SNMP and supports the Interface portion of
MIB-II, then ask for ifPhysAddress (object ID=1.3.6.1.2.1.2.2.1.6.*,
where * is the index for the network attachment on the local host).

- Steve Kao

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 1993 18:12:04 GMT
From:      jrose@mtgy.gtegsc.com (Joe Rose (4710))
To:        comp.protocols.tcp-ip
Subject:   MLS TCP/IP



--
We're looking for an MLS TCP/IP package that will operate on a VAX 6620 running
SEVMS 5.5.1


Joe S. Rose
GTE Government systems Corp.
201 Technacenter Dr.
Montgomery, AL 36117 
(V) 205-215-5594
(F) 205-215-5533
(E) jrose@.mtgy.gtegsc.com

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 93 20:36:09 GMT
From:      karthik@informix.com (Karthikeyan Guruswamy)
To:        comp.sys.novell,comp.protocols.tcp-ip
Subject:   Mail server for RFCs ...

Hi,
I don't have access to Internet and I'm trying to get some
RFCs. I used to know a mail address where you can send a
mail and it'll send an  RFC back to you. I don't have the
email address with me. Can someone please send me the email
address of this site ?

Thanks in advance,
Karthik

---------------------------------------------------------------
Karthik						Why doesn't my
Infosoft Inc, (Contractor to INFORMIX Inc.)	NET WORK ?
Cupertino, CA

All the views expressed here are solely mine and they dont 
represent those of my organization.
---------------------------------------------------------------

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jun 1993 21:44:42 GMT
From:      hoang1@litwin.com (Ted Hoang)
To:        comp.protocols.tcp-ip
Subject:   Examples use inetd superserver

Hi,
Could someone tell me where I can get source codes of any programs which 
execute by inetd daemon.

Thanks in advance,
Ted

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 93 21:52:42 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Tunnelling or encapsulation?

In article <1ugk15$c7p@usenet.INS.CWRU.Edu> trier@odin.ins.cwru.edu (Stephen C. Trier) writes:
>That is roughly the definition I sent in e-mail, except that I would
>define encapsulation without the level restriction: "transmission of a
>packet using the services of the same or another protocol".  (As an
>example of this usage, note that IP-IP is described as "encapsulation".)
>
>Tunneling is a special case of encapsulation, matching your
>definition.  When talking about that special case, the two terms are
>equivalent.
>
>I'd consider "encapsulation" to be a formal term, "tunneling" to be
>more informal or slang.
>
>Just my $.02.  I doubt _anyone_ is going to entirely agree on this
>one.  Everyone knows what the words mean, but can we define them?  :-)

"I can't define tunneling, but I know it when I see it..."  ;>}

I agree with your sentiments that these are not precisely defined terms
that are universally agreed upon.  That's why I stated that it all comes
down to just "stuffing packets inside other packets".  It's just a matter
of sematics whether you call it encapsulation or tunneling.

But I am kind of fond of the physical analogy of a tunnel as being a
path which passes through an obstacle which rises to a high level.

Art

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jun 1993 22:52:41 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Examples use inetd superserver

In article <1993Jun2.214442.1117@litwin.com>, hoang1@litwin.com (Ted Hoang) writes:
> Hi,
> Could someone tell me where I can get source codes of any programs which 
> execute by inetd daemon.


Send email to Joel@InfoMagic.com asking about their $50 CDROM of 386bsd 0.1
and their $50 "Internet CD".

FTP from uunet.


Vernon Schryver,  vjs@sgi.com

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Jun 1993 22:56:17 GMT
From:      gsa@mercury.udev.cdc.com (gary s anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: Rare (but nasty) BSD TCP problem

When this thrilling debate ended last year, it seemed that no
consensus was drawn on what is mandated (recommended??) by the
standards in place.  It seems that any user who had indeed wrote
an application depending on this feature (if anyone such user exists)
would benefit from a common implementation.  Since RFC 793 is being
held in such high esteem, let's see if there is in fact a subtle
definition which may serve as a guideline.

It seems that RFC 793 likes to use the term "pair of sockets" to
define a connection.  Many people would read that to mean to physically
distinct objects, however, liberal readers may in fact see two logical
objects sharing a physical object.  A connection is defined as
a <local socket, foreign socket>.  It does not explicitly say whether
or not the "local socket" may be identical to the "foreign socket", however,
inferring that they are not identical doesn't seem unreasonable.

Let's assume that the authors of 793 really meant "logical socket pairs" 
and not "physical socket pairs".  It would seem to me that any
service that can be provided with two logical sockets must work whether
you have a single physical socket or two physical sockets.  This clearly
cannot happen because you would need to support two physical sockets on
the same system with identical addresses/ports.  Using proof by negation
would say that the original assumption is wrong and that the authors
did not mean "logical socket pairs".  

The single TCB connection seems to work (although all end cases
have surely not been validated) and it shook out at least one subtle
BSD bug.  Does this mean vendors must support it?  The potential 
downfall is wasted time chasing problems which are associated with
a seemingly useless capability (there are many ways to send data
to yourself) and potential hardspots for vendors with innovative
code.  What do we gain by supporting this novel feature?  I probably
need a greater imagination, but I just don't understand the value.

The issue at hand is whether or not a user interface is required to 
provide such a service (i.e. a single TCB connection).  I'm certainly
willing to bow to the RFC 793 authors who claim that this was clearly
an intended feature.  Some reasonable IETF consensus might also be
useful.

Any authoratative answer would be of value....


   Gary


In article <1993Jun1.173313.3113@novell.com>, donp@novell.com (don provan) writes:
|> In article <C7y873.8Lo@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
|> >In article <1993May29.193018.2701@novell.com>, donp@novell.com (don provan) writes:
|> >> Just for the record, although i concur that this is a rare and
|> >> probably useless operation, it is not a "misuse".  There's nothing
|> >> about this operation that violates any TCP principle, and the
|> >> resulting TCP connection should be entirely legal and usable.
|> >
|> >	If we're talking about the same thing, then I think there very much
|> >*is* an implicit restriction against it in TCP. TCP saves its state in a TCB
|> >and that information will be different on each side of the connection. The
|> >server side goes through different states than the client side, and the
|> >"first close" side goes through different states than the "last close" side.
|> 
|> Nope.  Think again.  TCP is *symmetric*, so it's perfectly legal for
|> both sides to do exactly the same thing at exactly the same time.
|> Imagine two independent machines establishing a connection with each
|> other.  Both just happen to pick the same local port.  Both just
|> happen to send the initial SYN at exactly the same time.  The
|> connection should come up and be usable, right?  Admittedly, this is
|> because of the odd ability of TCP to successfully establish a
|> connection if two nodes at the same time attempt *actively* to
|> establish the same TCP connection.  This feature isn't clearly useful,
|> and i don't think it's used in real life, but none-the-less, there it
|> is, even diagramed on page 32 of RFC-793.  An implementation that
|> can't handle it would technically be in violation of TCP, although no
|> one would particularly care in practice (unless it lets evil forces
|> hang their system, of course :-).
|> 
|> OK, now think a little harder and you'll realize that a single node
|> talking to itself looks exactly like this.  When the local node sends
|> a SYN, the "remote" node also sends a SYN.  When the local node ACKs
|> the SYN, the "remote" node also ACKs the SYN.  As amazing as it seems,
|> the connection should get established.  Data transmitted on the
|> connection is received *by the same connection endpoint it was
|> transmitted on*.  Completely counterintuitive, but great fun!
|> 
|> The single TCB isn't a problem, mainly because TCP is duplex, so there
|> are values for both transmit and receive.  If a TCP implementation
|> hangs in the self-looping case, then i predict it will also hang in
|> the simultaneous connect case when the two nodes are sufficiently
|> synchronized.
|> 
|> The key is to recognize the in the loopback case, there's only one end
|> point, so there's only one TCB.  It's also interesting to note that
|> there is no "listen" involved in etablishing this connection.  That's
|> something many people don't realize is possible.  This causes the
|> little used state transition from SYN-SENT to SYN-RCVD which sometimes
|> causes implementors problems.
|> 					don provan
|> 					donp@novell.com

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Jun 1993 00:30:48 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Rare (but nasty) BSD TCP problem

In article <C80npt.AIK@raistlin.udev.cdc.com> gsa@mercury.udev.cdc.com (gary s anderson) writes:
>The single TCB connection seems to work (although all end cases
>have surely not been validated) and it shook out at least one subtle
>BSD bug.  Does this mean vendors must support it?  The potential 
>downfall is wasted time chasing problems which are associated with
>a seemingly useless capability (there are many ways to send data
>to yourself) and potential hardspots for vendors with innovative
>code.  What do we gain by supporting this novel feature?  I probably
>need a greater imagination, but I just don't understand the value.

First let me agree with you that this feature isn't important enough to
worry about supporting in itself.  Having said that, i should point out
that this problem might also occur using two different nodes activally
connecting to each other.  The case of connecting a socket to itself
just happens to be a trivial way to automatically synchronizes the "two"
ends of the connection so the initial SYNs cross.  (Well, there's
actually only one SYN, but it "crosses" in the way a ball bouncing off a
mirror appears to cross with its reflection.)  With two nodes, they need
to be synchronized in some other way.  In our testing, we found that
manual synchronization (i.e., "Ready?  1, 2, 3, go!") was often
sufficient to reproduce the problem on one TCP implementation with this
problem.

In short, this problem can also prevent a normal, two TCB, non-loopback
connection from being established.  At the same time, i know of no TCP
application which would ever attempt a mutual, simultaneous, active
connection between two nodes, so it's probably still no big deal if it
isn't supported.  I personally wouldn't knowingly allow such a flaw,
inconsequential though it is, in a TCP implementation i was responsible
for, but i'm a perfectionist.  In this case, though, i'd say the
deciding factor is that TCP hangs.  Most people don't like that type of
hole in their products.
						don provan
						donp@novell.com

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Thu, 03 Jun 1993 00:56:59 GMT
From:      debiso@westfield.win.net (Joe DeBiso)
To:        comp.protocols.tcp-ip
Subject:   Print Redirector for DOS

Does anyone know of a public domain or shareware print redir for
DOS?  I'm using Clark Drivers.  Please let me know if there is any
such thing!
Thanx!
Joe DeBiso
 


-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Jun 1993 02:55:19 GMT
From:      ccjim@vax.cns.muskingum.edu (Jimmy Buddenberg)
To:        comp.protocols.tcp-ip
Subject:   newsreader

Anyone know of a good newsreader preferably for windows?  I am currently
using WinVN and it doesn't have some features that I enjoyed on our VAX/VMS
reader such as a count of new messages and marking messages read.
thanks

jimmy

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 1993 04:41:04 GMT
From:      herrera@athena.mit.edu (Ramon F Herrera)
To:        comp.protocols.tcp-ip
Subject:   Re: How to convert ethernet hard. addr. to IP addr.? ARP?

You are very close, but not quite correct, Phil.

> The device, in effect says "Hey, somebody on this ethernet, as you
> can see from this frame, my MAC address is AA BB CC DD EE FF

The high-level software cannot necessarily see the MAC address.
For this reason, and to allow the general form of a machine
'A' asking machine 'B' for the address of machine 'C',
the protocol is impemented with four fields encapsulated in
the Ethernet data area:

    Sender Hardware Address          Sender IP Address
    Target Hardware Address          Target IP Address

There is also an "Operation field" in the ARP packet:

      (1) ARP request
      (2) ARP response
      (3) RARP request
      (4) RARP response

(1) and (3) are generally, but not necessarily sent to the broadcast
addess (i.e., to everybody on the same Ethernet).

regards,

-Ramon Herrera

------

      "On an Ethernet, having a field for the hardware sender address may
       seem redundant because the information is also contained in the
       Ethernet frame header.  However, not all Ethernet hardware provides
       the operating system with access to the physical frame header"

                    Internetworking with TCP/IP by Douglas E. Comer



-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Jun 1993 06:02:18 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: Searching for hosts on a network.

In article <1261@felix.Sublink.Org> eb@felix.Sublink.Org writes:

>On this same subject, how do the variuos SNMP managers discover the host
>on a net/subnet/subsubnet? I cannot believe they poll every possible 
>address, which could be reasonable for class C networks but not on class
>A or B ones.

Yes, its known as a "ping sweep"  or "discovery".

There would normally be no need to sweep the whole of a class B
address space, as 254x253 pings, at one per second would take 
about 17 hours.  Most Class B spaces are subdivided into many
subnets, with lots of unused address space.  So you need only
sweep the known, allocated subnet space, given any subnet mask.


-- 
Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      | (networking & OSI specialists)
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Jun 1993 07:45:09 GMT
From:      Colin Helliwell <colh@lincoln.gpsemi.com>
To:        comp.protocols.tcp-ip
Subject:   H/ware handshake with SLIP lines

I am intending to set up a hardwired (no modem) slip line from a pc 
to a Sparc Workstation running SunOS 4.1.3 

Can anyone tell me whether the SLIP standard defines the use of 
hardware handshaking or whether it is up to the implementation.
If it is defined, what are the cabling requirements ie which 
h/shake lines are used - CTS? RTS? DTR? etc etc

Any recommendations for good slip software at the SunOS end would 
also be welcome - preferably Shareware/PD.

=============================================================
Colin Helliwell
(colh@lincoln.gpsemi.com)
GEC Plessey Semiconductors
Lincoln 
ENGLAND
=============================================================

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 1993 21:31:21 -0700
From:      lyndon@unbc.edu (Lyndon Nerenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: unix tcp/ip configuration via BOOTP

fitz@wang.com (Tom Fitzgerald) writes:

>bartont@next1.msci.memst.edu (Tom Barton) writes:
 
>> I imagine the problem I'd like to address is already familiar to many who
>> manage largish ip networks. A user buys a desktop unix machine and simply
>> plugs it in to the handy data outlet. Eventually the ensuing trouble prompts
>> the user to discover who s/he should've contacted earlier to set it up
>> properly.

When you say "data outlet" I get the feeling you're talking 10Base-T? If that's
the case, why don't you disable all unused ports on the hubs. That way the 
person *has* to contact you for a connection, at which point you can
verify they have their software configured properly. Most hubs will let you
enable/disable a port using SNMP, or via a telnet session to the hub.

>> And it would be nice to be able to use BOOTP to reduce field time
>> necessary to reconfigure machines when ip network changes occur.
 
>Now, this sounds good.  It's rare enough that I wouldn't force a change to
>every Unix system on the net, though.....

For this, BOOTP is a godsend! In about 12 months when we relocate from our
temporary facilities to the new campus I will be moving about 400
PC's/X terminals. Not one of the hardware devices will have to be reconfigured.
All the changes will be made in the BOOTP and DNS config files. This means
that during the move I can keep the network support staff in one central
location rather than spread throughout seven buildings fiddling PROM
settings (tough to do with only three people).

--lyndon

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Jun 1993 11:19:13 GMT
From:      evansmp@uhura.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: unix tcp/ip configuration via BOOTP

Tom Barton (bartont@next1.msci.memst.edu) wrote:
: I imagine the problem I'd like to address is already familiar to many who
: manage largish ip networks. A user buys a desktop unix machine and simply
: plugs it in to the handy data outlet. Eventually the ensuing trouble prompts
: the user to discover who s/he should've contacted earlier to set it up
: properly. A while later the user moves his/her office location and the cycle
: repeats. A similar situation occurs with students (say) bringing their 3/486
: portables in with 386BSD or equivalent and plugging in to a public lab
: outlet. And it would be nice to be able to use BOOTP to reduce field time
: necessary to reconfigure machines when ip network changes occur.

I managed to get a bootp client working with Linux, though it took a few
kernel changes, which are not against the current kernel networking code.

What is needes is some way for a program to find out the ethernet address
of an interface.
And to be able to turn off any filtering of incoming datagrams by destination
address (otherwise the machine will never see the response).

It the client I wrote I also had it set the hostname as well, by simply
doing a DNS lookup.

If I get the time I'll look into adapting the code to the current kernel.

--
-------------------------------------------------------------------------
Mark Evans                                   |evansmp@uhura.aston.ac.uk
+(44) 21 429 9199  (Home)                    |evansmp@cs.aston.ac.uk
+(44) 21 359 6531 x4039 (Office)             |

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Jun 1993 11:44:20 GMT
From:      drolling@lincoln.gpsemi.com (Dave Rollings LDC x 2392)
To:        comp.protocols.tcp-ip
Subject:   Help with Networking problem wanted

I wonder if any body can help me.

I have a networking problem to suss out for an assignment, on my course,
that requires linking fifty sites with LANS to a Central UNIX Computer System
at a head office which again is connected on a LAN.

I have decided to base the LANS on Ethernet, using the Bus Topology, with
a central UNIX machine at each site which receives monitoring info from 
other machines on the LAN. The central machines at each site will be 
logged into at head office,using Telnet and Ftp TCP utilities.

The questions I have is this, do I need to have a remote bridge at each site,
with a modem and high speed line, and fifty lines from each site going into 
remote bridges and modems at the head office, or is there a neater and 
cheaper way?

I don't know that much about WAN Technology so if anybody has any suggestions,
I would appreciate replies via E-Mail if possible.

Many Thanks.

--------------------------------------------------------
Dave Rollings
GEC Plessey Semiconductors
Lincoln.
United Kingdom.

E-Mail  drollings@lincoln.gpsemi.com  (VAX/VMS Account)
E-Mail  drolling@lincoln.gpsemi.com   (UNIX Account)
---------------------------------------------------------

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 1993 12:41:43 GMT
From:      mckenzie@bbn.com (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re: Rare (but nasty) BSD TCP problem

Let me first state that I have never read the Berkeley UNIX code for
TCP, and I don't recall whether I'm an author of RFC793, but I seriously
doubt it.  Nevertheless, I believe I can state semi-authoritatively that
the group which defined TCP/IP believed that it was necessary for the
four numbers <local host address>, <local socket number>, <remote host
address>, <remote socket number> to uniquely define a connection, for
the purpose of deciding to what local port on which local process to
deliver arriving data. It was expected that no two simultaneous
connections would have all 4 of these identifiers the same.  Don
Provan's case of the same socket on two different hosts is explicitly
allowed.  I doubt that anyone considered the case where a process wanted
to open a connection to itself using the same socket for both ends of
the connection, but if it was considered I can see no reason why the
designers would have wanted to prohibit it, since the place to deliver
arriving data is unambiguous.  [Naturally that same process would be
prohibited from opening a second simulaneous connection to itself using
the same socket as the first connection, but that doesn't seem to be the
issue in this thread.]  I hope this is helpful.

    __   
   /  | /\                  Alex McKenzie
  /   | \/                  mckenzie@bbn.com
  \__/|_/\_&_/~X_           617/873-2962
 

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Jun 93 14:23:34 GMT
From:      davidh@Harston.CV.COM (Dave Hill)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple ether interfaces on the same subnet, revisited

Jeff Bacon (bacon@mtu.edu) wrote:
: ethernets, all on the same subnet (obviously). Of course, the two sun
: interfaces will have different MAC addrs (no spanning-tree).

Hmm, we have two suns with two ethernets and in both cases they have the
SAME MAC address. The kernel takes the MAC address of the primary
interface and loads it into all the others - there is a warning to that
effect in the  documentation.

One is a 4/280 with a second VME e'net (ie2) and the other is a SS1 with
second Sbus e'net (le1).

asterix# ifconfig -a
ie0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
        inet 130.21.130.10 netmask ffffff00 broadcast 130.21.130.0
        ether 8:0:20:6:ac:ad 
ie2: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
        inet 192.9.200.1 netmask ffffff00 broadcast 192.9.200.0
        ether 8:0:20:6:ac:ad 
lo0: flags=49<UP,LOOPBACK,RUNNING>
        inet 127.0.0.1 netmask ff000000 
asterix# 

medusa# ifconfig -a
le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
        inet 130.21.130.137 netmask ffffff00 broadcast 130.21.130.0
        ether 8:0:20:7:cd:d0 
le1: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
        inet 130.21.214.1 netmask ffffff00 broadcast 130.21.214.0
        ether 8:0:20:7:cd:d0 
lo0: flags=49<UP,LOOPBACK,RUNNING>
        inet 127.0.0.1 netmask ff000000
medusa# 
				
: -bacon
: --
: = Jeffery Bacon       General Systems Hack, Michigan Technological University =
: = bacon@mtu.edu       ph-(906)487-2197 fax-(906)487-2822    Printing is Evil. =

--
Dave Hill                                 NEW NEW NEW -->>davidh@Harston.CV.COM
Computervision R&D Ltd                                      +44 223 872377 x352
Harston Mill, Harston, CB2 5NH, UK

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 1993 14:46:39 GMT
From:      benchoff@groupw.cns.vt.edu (Phil Benchoff)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: IP Routing Questions on Subnet Masks and Multicasting

Don Weston (don@lclark.edu) wrote:
: I understand that most people out there stick with class C addresses, but
: these are not quite big enough for what we need to do.  Has anyone
: experienced pitfalls with going to a nonstandard netmask?  Does this
: particular scheme look right?  Is multicasting really better?
: Do the nonstandard netmasks confuse some implementations of IP software such 
: as MacIP, NCSA Telnet, SunOS, etc? 

We use 6 bits of subnet on our class-B network and don't experience
any problems that are directly related to that.  We also have multiple
subnets on some of the interfaces.

You can use different size subnets on some of the routers if you
want to.  The trick to this is to break up a particular 6-bit
subnet on only one router.  This will minimize confusion since
a host on any of the nets can behave like all of the nets use
the same mask.

      Netmask 255.255.252.0              Netmask 255.255.255.0
                            +----------+
                            |          |--------- x.y.8
                  x.y.[4-7] |          |--------- x.y.9
                   ---------| Router   |--------- x.y.10
                            |          |--------- x.y.11
                            +----------+
In this configuration, a host on the 4-7 subnet sees a gateway
to the 8-11 subnet.  If you had broken up the 8-11 subnet
on several routers, hosts would have to deal with multiple
routes to what they think are the same subnet.  You could
probably make this work, but it wouldn't be pretty.

I do have one problem related to multiple subnets on the same
interface:  routes to the secondary address do not appear in
RIP updates.

Don, your network sounds a lot like ours.  We started in about 1985
with no experience.  We built one logical ethernet on the campus
without subnetting.  We re-addressed and re-netmasked with 6-bits
of subnetting.  We still have a lot of hosts on the original
ethernet and run two subnets on the backbone.  As we convert
buildings to being routed, we run their new subnet on the backbone
as a secondary until all of the hosts are converted and the
building network can be put on a router.  It is a bit messy,
but about the best we can do without starting again from
0.  We'll probably have everything in good order when we
need to convert to IP version 7.  :-)

Phil

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Jun 1993 15:43:21 GMT
From:      evansmp@uhura.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Rare (but nasty) BSD TCP problem

Alex McKenzie (mckenzie@bbn.com) wrote:
: Provan's case of the same socket on two different hosts is explicitly
: allowed.  I doubt that anyone considered the case where a process wanted
: to open a connection to itself using the same socket for both ends of
: the connection, but if it was considered I can see no reason why the
: designers would have wanted to prohibit it, since the place to deliver
: arriving data is unambiguous.  [Naturally that same process would be
: prohibited from opening a second simulaneous connection to itself using
: the same socket as the first connection, but that doesn't seem to be the
: issue in this thread.]  I hope this is helpful.

If I remember correctly, the problem is that this would halt the
machine.

If if just halted the process, tough.

If an ordinary user can run a process which halts the machine then
the Operating system IS broken!

--
-------------------------------------------------------------------------
Mark Evans                                   |evansmp@uhura.aston.ac.uk
+(44) 21 429 9199  (Home)                    |evansmp@cs.aston.ac.uk
+(44) 21 359 6531 x4039 (Office)             |

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Jun 1993 15:57:06 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: How to convert ethernet hard. addr. to IP addr.? ARP?

In article <1ujvd0INNian@senator-bedfellow.MIT.EDU>, herrera@athena.mit.edu (Ramon F Herrera) writes:
> ...
> The high-level software cannot necessarily see the MAC address.
> For this reason, and to allow the general form of a machine
> 'A' asking machine 'B' for the address of machine 'C',
> the protocol is impemented with four fields encapsulated in
> the Ethernet data area:
> 
>     Sender Hardware Address          Sender IP Address
>     Target Hardware Address          Target IP Address
> ...
 
>       "On an Ethernet, having a field for the hardware sender address may
>        seem redundant because the information is also contained in the
>        Ethernet frame header.  However, not all Ethernet hardware provides
>        the operating system with access to the physical frame header"
> 
>                     Internetworking with TCP/IP by Douglas E. Comer


There is also proxy-ARP.


Vernon Schryver,  vjs@sgi.com

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 1993 16:35:45 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Searching for hosts on a network.

In article <1261@felix.Sublink.Org> eb@felix.Sublink.Org (Enrico Badella) writes:
>Lately I was discussing with a friend a way of discovering all the host on 
>a network; we came up with the idea of using ping and instead of 
>specifying the host name use network_address.255. While trying the idea out
>on a class C network made up of Suns (3 and 4), 386 PC (SCO, ISC, Linux,
>386BSD) and no routers, bridges or other devices apparently evry host 
>answers to the ping. 

I tried it out here a couple of days ago, and noticed that I didn't get a
response from a Tektronix X terminal.  This is permitted by RFC 1122;
section 3.2.2.6 says, "An ICMP Echo Request destined to an IP broadcast or
IP multicast address MAY be silently discarded."

Also, we have some devices here that don't respond to pings at all (old
Bridge CS/1 terminal servers).  However, it's probably not worth worrying
too much about such systems.

>		      Doing the same trick on a class B network nothing
>would happen most of the times, once in a while a cisco router would
>answer.
>How can this be explained?

Do you mean an unsubnetted class B network?  Or were you trying to find all
the hosts on all the subnets of a class B network?

>On this same subject, how do the variuos SNMP managers discover the host
>on a net/subnet/subsubnet? I cannot believe they poll every possible 
>address, which could be reasonable for class C networks but not on class
>A or B ones.

They probably send out SNMP broadcasts rather than ICMP broadcasts.  Unlike
broadcast pings, these should not be ignored.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Jun 1993 18:17:07 GMT
From:      billn@netmanage.com
To:        comp.protocols.tcp-ip
Subject:   Re: Info on programming SOCK_RAW type sockets


In article <93144.084916U37127@uicvm.uic.edu>, <U37127@uicvm.uic.edu> writes:
> Path: > >
> >>I am looking for information or examples on programming SOCK_RAW
> >>type sockets.
> >
>> 
> Thank you!  Yep, I wanted to see how to write my own IP datagrams.
> The traceroute sources were great, but is there a more definitive
> treatment of raw sockets available in a book form perhaps?  Thanks again,
> Satish Movva
> Univ. Of Illinois at Chicago
> 
> >
> > Rich Stevens

Check out  "Internetworking with tcp/ip volume II" by 
Douglas Comer. It describes implementing tcp/ip and has alot of code 
examples. Another is "Unix Network Programming" by W. Richard Stevens.

Bill Nolde		NetManage
billn@netmanage.com	20823 Stevens Creek Blvd.
			Cupertino, CA. 95014
			phone (408)-973-7171
			fax   (408)-257-6405



-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Jun 1993 18:55:36 GMT
From:      jsl@world.std.com (Jonathan S Levinson)
To:        comp.protocols.tcp-ip
Subject:   SO_KEEPALIVE - any ideas?

We are thinking of using the SO_KEEPALIVE option to tell if
connections go down.  Does anyone have any experience with this option
they would like to share?  Also, is the timeout value settable?
-- 
-------------------------------------------------------------------------
Jonathan Samuel Levinson - jsl@world.std.com    phone: (617) 492 - 8860
Computer Corporation of America                 fax:   (617) 497 - 1072
4 Cambridge Center                              Cambridge MA 02142

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 1993 21:03:23 GMT
From:      mckenzie@bbn.com (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re: Rare (but nasty) BSD TCP problem

Earlier today I sent a message to this list in response to a posting
which seemed to be asking what the authors of RFC 793 had in mind AT THE
TIME OF WRITING.  I tried to answer that question from a historical
perspective, since I was there.  My answer was only intended as oral
history, not as endorsement or condemnation of any particular
implementation or interpretation of the specification, nor as a
suggestion that in 1993 implementations "should" work any particular
way.  At least a few people have understood my message to be endorsing
or promoting the idea that TCP implementations "should" allow a
connection from a given socket to itself.  I don't have a position on
that issue.

    __   
   /  | /\                  Alex McKenzie
  /   | \/                  mckenzie@bbn.com
  \__/|_/\_&_/~X_           617/873-2962
 

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Jun 1993 21:43:37 GMT
From:      evansmp@uhura.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Searching for hosts on a network.

Barry Margolin (barmar@think.com) wrote:
: 
: I tried it out here a couple of days ago, and noticed that I didn't get a
: response from a Tektronix X terminal.  This is permitted by RFC 1122;
: section 3.2.2.6 says, "An ICMP Echo Request destined to an IP broadcast or
: IP multicast address MAY be silently discarded."

This is probably a very good idea, it might be ok if all of the machines are
on the same piece of ethernet.

But doing it to a remote site is probably not a good idea, if all the
machines respond.
(it could jam some links)


--
-------------------------------------------------------------------------
Mark Evans                                   |evansmp@uhura.aston.ac.uk
+(44) 21 429 9199  (Home)                    |evansmp@cs.aston.ac.uk
+(44) 21 359 6531 x4039 (Office)             |

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Jun 1993 22:28:01 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

> Second, people really need keepalives in many circumstances.  If they
> didn't they wouldn't continually ask about them in this newsgroup.
> That they usually don't use the right jargon, and instead ask about
> determining if a link has died is not their fault.

Most of the people who think they need keepalives, really need application-
level timeouts instead.

Too often, the posts about "how do I find if the link is dead" are followed
a few days later by "the keepalive timeout is two hours - how do I set it
to just a minute or two?"  That gets back into the traffic level problems.

Even if programmers do get their keepalives working, they eventually
discover that they want variable timeouts even during a single session -
long timeouts (2 hours or so) when the client application is in an idle
state, but much shorter ones (a few minutes at most) when files are locked
for updating or the client app is in the middle of a single user-level
command.

Application timeouts are always better than keepalives.  The only
disadvantage is a little extra code, and that's not worth the cost or
inflexibility of keepalives.

-- 
Tom Fitzgerald   Wang Labs       fitz@wang.com   "I went to the universe today;
1-508-967-5278   Lowell MA, USA                   It was closed...."


-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Jun 1993 22:35:52 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: unix tcp/ip configuration via BOOTP

bartont@next1.msci.memst.edu (Tom Barton) writes:

> I imagine the problem I'd like to address is already familiar to many who
> manage largish ip networks. A user buys a desktop unix machine and simply
> plugs it in to the handy data outlet. Eventually the ensuing trouble prompts
> the user to discover who s/he should've contacted earlier to set it up
> properly.

I know the problem well, but I don't see how a bootp client fixes this.
For bootp to work at all, the admin has to have added the MAC/IP mapping to
a bootptab file somewhere, and your scenario assumes that the admin is
totally ignorant of the new system (until the net starts storming....).

> A while later the user moves his/her office location and the cycle
> repeats.

Bootp would be no help here either, since the bootp server is still going
to pass back the old IP address.

Bootp is an advantage with PCs, since it lets you put together a single PC
configuration that can be installed unchanged on every PC - only the
bootptab file needs to know about them all.  This doesn't seem like it
would be any advantage at all for Unix systems.

> And it would be nice to be able to use BOOTP to reduce field time
> necessary to reconfigure machines when ip network changes occur.

Now, this sounds good.  It's rare enough that I wouldn't force a change to
every Unix system on the net, though.....

--
Tom Fitzgerald   Wang Labs       fitz@wang.com   "I went to the universe today;
1-508-967-5278   Lowell MA, USA                   It was closed...."

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 93 08:41:07 -0600
From:      bartont@next1.msci.memst.edu (Tom Barton)
To:        comp.protocols.tcp-ip
Subject:   Re: unix tcp/ip configuration via BOOTP

In article <C82HFt.63x@wang.com> fitz@wang.com (Tom Fitzgerald) writes:
>bartont@next1.msci.memst.edu (Tom Barton) writes:
>> A user buys a desktop unix machine and simply
>> plugs it in to the handy data outlet. Eventually the ensuing trouble prompts
>> the user to discover who s/he should've contacted earlier to set it up
>> properly.
>
>I know the problem well, but I don't see how a bootp client fixes this.
>For bootp to work at all, the admin has to have added the MAC/IP mapping to
>a bootptab file somewhere, and your scenario assumes that the admin is
>totally ignorant of the new system (until the net starts storming....).

It's true that, as with BOOTP itself, there's a chicken-and-egg issue here.
However, with a pre-installed BOOTP client the network admin is spared having
to go to the user's site to supervise manual configuration.

>> A while later the user moves his/her office location and the cycle
>> repeats.
>
>Bootp would be no help here either, since the bootp server is still going
>to pass back the old IP address.

See above.

>Bootp is an advantage with PCs, since it lets you put together a single PC
>configuration that can be installed unchanged on every PC - only the
>bootptab file needs to know about them all.  This doesn't seem like it
>would be any advantage at all for Unix systems.

That's more or less what I had in mind for unix systems, too.

>> And it would be nice to be able to use BOOTP to reduce field time
>> necessary to reconfigure machines when ip network changes occur.
>
>Now, this sounds good.  It's rare enough that I wouldn't force a change to
>every Unix system on the net, though.....

In all cases, the idea is to reduce field time and increase accuracy and
hence network reliability. In my opinion, these goals are worthy enough to
(hopefully) attract some attention from vendors.

Thanks for your opinions.

-- 
Tom Barton
t-barton@memst.edu
Dept of Math Sciences, Memphis State University, Memphis TN 38152

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Jun 1993 22:51:00 GMT
From:      karl@empirical.com  (Karl Auerbach)
To:        comp.protocols.tcp-ip,comp.protocols.snmp
Subject:   Re: Searching for hosts on a network.

> Lately I was discussing with a friend a way of discovering all the host on 
> a network; we came up with the idea of using ping and instead of 
> specifying the host name use network_address.255. While trying the idea out
> on a class C network made up of Suns (3 and 4), 386 PC (SCO, ISC, Linux,
> 386BSD) and no routers, bridges or other devices apparently evry host 
> answers to the ping. Doing the same trick on a class B network nothing
> would happen most of the times, once in a while a cisco router would
> answer.
 _
> How can this be explained?
> I cannot believe they poll every possible 
> address, which could be reasonable for class C networks but not on class
> A or B ones.
_
Believe it or not some implementations do poll the entire address space,
even of a class A!
_
If you broadcast, even on a class C, you will almost certainly miss
some of the avalanch of replies.
_
On a true, flat, unbridged class B or A you ought to see the same
effect as on a class C.  However, few large nets are without routers
which may not propogate all-subnets-broadcasts, or without bridges
which may choke on the mass of traffic which suddenly appears.
-
(We have a class B here with relatively few impediments to broadcasts,
and it works just find.)
_
My own code does some limited broadcasting to elicit responses, but then
takes some more sophisticated methods to find out who was missed.
_
NetWare has a cute trick.  They have a broadcast mechanism in which the
packet contains a list of the addresses which are *not* to respond
(presumably because the engine doing the broadcast already knows about
them.)  This helps avoid the massive avalance, or rather reduces the
situation to a series of avalanches of decreasing size.
_
I believe that the resource discovery stuff being discussed in an
IETF working group uses a similar mechanism.  (It may only have
been suggested rather than adopted.)
_
			--karl--

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 93 23:13:51 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Searching for hosts on a network.

In article <1261@felix.Sublink.Org> eb@felix.Sublink.Org (Enrico Badella) writes:
>Lately I was discussing with a friend a way of discovering all the host on 
>a network; we came up with the idea of using ping and instead of 
>specifying the host name use network_address.255. While trying the idea out
>on a class C network made up of Suns (3 and 4), 386 PC (SCO, ISC, Linux,
>386BSD) and no routers, bridges or other devices apparently evry host 
>answers to the ping. Doing the same trick on a class B network nothing
>would happen most of the times, once in a while a cisco router would
>answer.
>How can this be explained?

Is the class B all on one cable, or is it subnetted across multiple cables?
If the class B is subnetted and you used the "allsubnets" IP broadcast
address, I'd not be suprised that the packet didn't get very far.  Many
router won't normally forward allsubnets broadcasts.  And any host on the
subnet may not have recognised the broadcast address as belonging to
their subnet (and not responded).  The cisco probably recognises the
broadcasts and answers, but will rate limit the answers. If on a class B
subnet, try using a subnet IP broadcast (class-b.subnet.all-ones).

>On this same subject, how do the variuos SNMP managers discover the host
>on a net/subnet/subsubnet? I cannot believe they poll every possible 
>address, which could be reasonable for class C networks but not on class
>A or B ones.

There are many techiques and smarter managers use more than one.  Included
are using ARP cache info, using routing packet info, sending various forms
of broadcast packets (SNMP queries, Pings).  This kink of thing is usually
done for local cables.  To find things further afield, finding other routers
and looking in their routing tables os sometimes done.  Then directed subnet
broadcast might be used to probe that cable.

But anytime you let things like that lose, be careful, and employ mechanisms
to limit the damage they can do to your network.

>Thank for your LIGHT!
>
>-- 
>Enrico Badella				Internet: eb@felix.sublink.org
>Soft*Star s.r.l.			          eb@icnucevx.cnuce.cnr.it
>Via Camburzano 9			Phone:    +39-11-746092
>10143 Torino, ITALY			Fax:      +39-11-746487

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Jun 1993 00:25:45 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <C82H2q.5tC@wang.com>, fitz@wang.com (Tom Fitzgerald) writes:
> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> 
> > Second, people really need keepalives in many circumstances.  If they
> > didn't they wouldn't continually ask about them in this newsgroup.
> > That they usually don't use the right jargon, and instead ask about
> > determining if a link has died is not their fault.
> 
> Most of the people who think they need keepalives, really need application-
> level timeouts instead.
> 
> Too often, the posts about "how do I find if the link is dead" are followed
> a few days later by "the keepalive timeout is two hours - how do I set it
> to just a minute or two?"  That gets back into the traffic level problems.
> 
> Even if programmers do get their keepalives working, they eventually
> discover that they want variable timeouts even during a single session -
> long timeouts (2 hours or so) when the client application is in an idle
> state, but much shorter ones (a few minutes at most) when files are locked
> for updating or the client app is in the middle of a single user-level
> command.
> 
> Application timeouts are always better than keepalives.  The only
> disadvantage is a little extra code, and that's not worth the cost or
> inflexibility of keepalives.


Keepalives done by the TCP protocol code involve less network bandwidth
as well as fewer end-point CPU cycles than application probes.
Keepalives done by the TCP code consume no bandwidth when the link is
active.  Application probing of the other liveness of the other end
always uses more bandwidth than TCP keepalives, if only because the
application must send user data, and cannot send 0-length TCP segments.

Few plausible applications would consume measurable, not to mention
significant bandwidth even with application-level probes every 2
minutes.  An ethernet is good for almost 1,500,000 100 Byte packets
every 2 minutes.  How can any plausible number of applications doing 
either 2 minute application probes or keepalives be significant?

Of course, if you are running over a 14.4Kbit/sec link, you don't have
many packets to spare, but you're not likely to be running such
applications over such links.  (Before anyone explains low speed links
to me, note that I spend about 60 hours/week using a 14.4kb/s link, and
move from 20-200MByte/week over it.)

Imagine a system where the application could tune the keepalive rate,
down to seconds when things are supposed to be happening and up to days
when things are idle, just as described above.  That would require a
trivial addition to the 4.3BSD data structures, trivial changes
to tcp_timer.c and tcp_input.c, and a trivial new setsockopt().

Saying that keepalives are evil because applications writers cannot be
trusted to not misuse them is elitist nonsense.  The most costly
network abominations have been perpetrated by self-proclaimed "protocol
designers."  Consider, for example, the Ethertalk 5-second broadcasts.

Keepalives should not be used everywhere.  Sometimes simple activity
timers are best.  Sometimes application level probing is best.
Sometimes TCP keepalives are the most efficient, with efficiency
measured in any of the reasonable ways.


Vernon Schryver,  vjs@sgi.com

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Jun 1993 00:50:01 GMT
From:      mike@gordian.com (Michael A. Thomas)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <C82H2q.5tC@wang.com>, fitz@wang.com (Tom Fitzgerald) writes:
> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> 
> > Second, people really need keepalives in many circumstances.  If they
> > didn't they wouldn't continually ask about them in this newsgroup.
> > That they usually don't use the right jargon, and instead ask about
> > determining if a link has died is not their fault.
> 
> Most of the people who think they need keepalives, really need application-
> level timeouts instead.

  This may or may not be. If you are talking about like an RFC
standard protocol, you may be screwed. (However, even something
like telnet, the usual complaint, could be hacked to send IAC
data to figure out the circuit's state)

> Even if programmers do get their keepalives working, they eventually
> discover that they want variable timeouts even during a single session -
> long timeouts (2 hours or so) when the client application is in an idle
> state, but much shorter ones (a few minutes at most) when files are locked
> for updating or the client app is in the middle of a single user-level
> command.

  This seems rather implementation specific. If you can implement
keepalives at all, I can't imagine the overwhelming difficultly
in making them variable (even within the context of the same 
circuit at different times). If BSD4.3 doesn't support them,
that is only because they didn't either care or want to, not
because it wasn't possible.
 
> Application timeouts are always better than keepalives.  The only
> disadvantage is a little extra code, and that's not worth the cost or
> inflexibility of keepalives.

  An application timeout (like the one most FTP's implement) is
not really the same as a keepalive. A keepalive is testing the 
circuit's state, whether or not a user is using it. An application
timeout is more akin to a inactivity timeout, which is based
on the *user* not the circuit's state.
-- 

		Michael Thomas	(mike@gordian.com)
	"I don't think Bambi Eyes will get you that flame thrower..."  
		-- Hobbes to Calvin
		USnail: 20361 Irvine Ave Santa Ana Heights, Ca,	92707-5637
		PaBell: (714) 850-0205 (714) 850-0533 (fax)

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 1993 00:55:36 GMT
From:      paulf@gsfc.nas.gov (Paul Fischer;OpenAge(SWR))
To:        comp.protocols.tcp-ip
Subject:   How can I do a rotery Telnet?


REPLIES To: paul@openage.com

Hi All,

A customer of mine wants to setup several DOS machines that will each handle
one incoming telnet session.  He wants to setup some sort of an alias for
these in the nameserver so that if the first one is busy it will connect
to the second one, and so on.

Any ideas?


-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 1993 02:01:18 GMT
From:      doyle@cs.umass.edu (Jim Doyle)
To:        comp.protocols.tcp-ip,comp.protocols.ppp,comp.sys.sun.misc
Subject:   Dedicating a Sun as a central SLIP/PPP server ??

Our department is considering dedicating a machine as a CSLIP & PPP dialup
server for faculty and staff. In the outset - we'd like to provide the
capacity for up to 30 simultaneous dialup PPP/SLIP connections via a shared
campus terminal server. The use of the dedicated machine would basically be
an interim solution until a Terminal Server implementation of these protocols
is available.


For this sort of usage - what is the least amount of CPU horsepower we can
get away with?  We have a Sun 3/280 available - will that handle the load?
Or do we need a SPARC..

Has anyone used SLIP-4.1 or DP-2.3 in a configuration with as many as 30
network interfaces?

.... Jim Doyle	(doyle@cs.umass.edu)




-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 1993 03:03:11 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: IP Routing Questions on Subnet Masks and Multicasting

In article <1ul2sf$97n@vtserf.cc.vt.edu> benchoff@groupw.cns.vt.edu (Phil Benchoff) writes:

    I do have one problem related to multiple subnets on the same
    interface:  routes to the secondary address do not appear in
    RIP updates.
    
More recent code provides "no ip split-horizon" to change this.

Tony

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Jun 1993 03:59:28 GMT
From:      colinm@max.carleton.ca (Colin McFadyen)
To:        comp.protocols.tcp-ip,comp.protocols.ppp,comp.sys.sun.misc
Subject:   Re: Dedicating a Sun as a central SLIP/PPP server ??

In <1umadeINNc4f@ymir.cs.umass.edu> doyle@cs.umass.edu (Jim Doyle) writes:

>Our department is considering dedicating a machine as a CSLIP & PPP dialup
>server for faculty and staff. In the outset - we'd like to provide the
>capacity for up to 30 simultaneous dialup PPP/SLIP connections via a shared
>campus terminal server. The use of the dedicated machine would basically be
>an interim solution until a Terminal Server implementation of these protocols
>is available.


>For this sort of usage - what is the least amount of CPU horsepower we can
>get away with?  We have a Sun 3/280 available - will that handle the load?
>Or do we need a SPARC..
 
>Has anyone used SLIP-4.1 or DP-2.3 in a configuration with as many as 30
>network interfaces?

You could always consider buying an Annex terminal server.  We have a couple
running at our site and they do PPP and SLIP quite well.  They are a breeze
to set up and maintain also.  If more info is required, let me know.

Colin.

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Jun 1993 04:18:30 GMT
From:      greg@serveme.chi.il.us (Gregory Gulik)
To:        comp.protocols.tcp-ip
Subject:   Questions about Telnet internals...


First, a little about my application.

I'm writing a program that allows a user to telnet to a machine
on a network and connect to a TTY.  In most cases, the TTY will
have a modem attached.

The program mostly works.  I can start a UUCP session through
this program, and it works dandy, but if I try to use Sun's
telnet program to telnet to the program, and use a modem
interactively, odd things start to happen.

First of all, the local telnet puts itself into line by line
mode.  I then use the telnet escape character and put it into
character by character mode.  Why does telnet put itself into
this mode?  It normally doesn't appear to do this when I just
simply telnet to a remote node normally.

This is where things get really messed up.  While in line-by-line mode,
when I hit CR, the sequence 0D0A (CR/LF) is sent to the TTY.
This is correct.  But, when I switch the telnet into character
at a time mode and hitting a CR makes my program received the sequence
0D00 (CR/NULL).  The NULL makes logging into other systems using
the modem almost impossible.  Most systems simply hang up their
end when they receive that NULL.

The final question is, when I manually switched telnet into character
at a time mode, my program received the following sequence of
characters: 61740D0D0A4F4B0D0A

What does this all mean?

-greg

-- 
Gregory A. Gulik                                 Call Gagme, a public access
       greg@serveme.chi.il.us                    UNIX system at 312-282-8606
   ||  gulik@rtsg.mot.com                        For information, drop a note
                                                 to info@gagme.chi.il.us

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Jun 1993 04:28:31 GMT
From:      ben@datacomm.ucc.okstate.edu (Ben James)
To:        comp.protocols.tcp-ip
Subject:   Re: How can I do a rotery Telnet?

In article <1um6i8$327@skates.gsfc.nasa.gov> paulf@gsfc.nas.gov (Paul Fischer;OpenAge(SWR)) writes:
>
>REPLIES To: paul@openage.com
>
>Hi All,
>
>A customer of mine wants to setup several DOS machines that will each handle
>one incoming telnet session.  He wants to setup some sort of an alias for
>these in the nameserver so that if the first one is busy it will connect
>to the second one, and so on.
>
>Any ideas?
>

Usually I trash all bounced mail but once and a while I make an exception.

(Message inbox:245)
 -- using template mhl.format --
Date:    Thu, 03 Jun 1993 23:20:31 CDT
To:      ben

From:    Mailer-Daemon (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown

Return-Path: ben
Return-Path: <Mailer-Daemon>

   ----- Transcript of session follows -----
550 paulf@gsfc.nas.gov... Host unknown

   ----- Unsent message follows -----
Return-Path: <ben>
Received: by datacomm.ucc.okstate.edu (4.1/SMI-4.1)
	id AA28986; Thu, 3 Jun 93 23:20:31 CDT
Date: Thu, 3 Jun 93 23:20:31 CDT
From: ben (Ben James)
Message-Id: <9306040420.AA28986@datacomm.ucc.okstate.edu>
To: paulf@gsfc.nas.gov
Subject: Re: How can I do a rotery Telnet?
Newsgroups: comp.protocols.tcp-ip
In-Reply-To: <1um6i8$327@skates.gsfc.nasa.gov>
Organization: Oklahoma State University, Stillwater, OK
Cc: 

In article <1um6i8$327@skates.gsfc.nasa.gov> you write:
>
>REPLIES To: paul@openage.com
>
>Hi All,
>
>A customer of mine wants to setup several DOS machines that will each handle
>one incoming telnet session.  He wants to setup some sort of an alias for
>these in the nameserver so that if the first one is busy it will connect
>to the second one, and so on.
>
>Any ideas?
>

Feel free to prove me wrong but I think this is impossible.  I know of know 
product which answers domain name lookups baised on if another machine is busy
or not.  Although it would be possible to write such code I sure wouldn't do
it.  I do know that we have some 3Com Communications Servers (for serial 
communications) which allow you to assign an ip_number to a specific port
and then they also allow a rotory to be set up with say 8 other ports and you
can also write in automatic scripts for each port which would telnet to 
different machines.   I know thats not what your looking for and for A couple 
of thousand I don't consider its worth it but I think if all else fails this may
get the job done.  I would like to hear other sugestions.

Ben James

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Jun 93 06:22:24 GMT
From:      ddl@burrhus.harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: Rare (but nasty) BSD TCP problem

I just took a look at the code in question and it appears that this
is a case of tcp_input's being a bit too clever for its own good.
Whenever all of the data in a segment is dropped (and this is distinct
from there being no data to begin with), received ACK processing is
skipped (except in two special cases).  For the particular case of the
self-connecting socket, the ``data'' to be dropped is the duplicate SYN.
After (correctly) trimming the SYN, tcp_input sees nothing left, counts
a duplicate packet, acks, and quits.

At first, I had the urge to add more special-case code to prevent
a SYN-trim from tripping the heuristic.  (The comment about FIN wars
suggests that this is how one of the existing special cases came to
exist.)  But then I realized that the bug would recur the first time
a self-connected socket dropped an ACK packet.  (Yes, this may be
unlikely, but it would still hang...)  Moreover, unless I'm missing
something, the clever heuristic doesn't do a whole lot of good anyway.

The patch below simply removes the cleverness, treating all supposedly-
duplicate packets alike.  With it applied to 4.3ish code, I can connect
a socket to itself and even send data through.  I'd be interested in
any negative side-effects that I have missed.  In particular, the code
for 4.2-compatible keepalive responses is in effect always enabled
(it was the second special case).  But did it do the right thing to
begin with?  In any case, use the patch with care.  It has been only
lightly tested and more study may be in order. :)

				Dan Lanciani
				ddl@harvard.*


*** tcp_input.old
--- tcp_input.c
**************
*** 637,642
  		    todrop == ti->ti_len && (tiflags&TH_FIN) == 0) {
  			tcpstat.tcps_rcvduppack++;
  			tcpstat.tcps_rcvdupbyte += ti->ti_len;
  			/*
  			 * If segment is just one to the left of the window,
  			 * check two special cases:
--- 637,643 -----
  		    todrop == ti->ti_len && (tiflags&TH_FIN) == 0) {
  			tcpstat.tcps_rcvduppack++;
  			tcpstat.tcps_rcvdupbyte += ti->ti_len;
+ #ifdef	ORIG
  			/*
  			 * If segment is just one to the left of the window,
  			 * check two special cases:
**************
*** 652,657
  			  || (tiflags & TH_RST && ti->ti_seq == tp->rcv_nxt - 1)
  #endif
  			   ) {
  				todrop = ti->ti_len;
  				tiflags &= ~TH_FIN;
  				tp->t_flags |= TF_ACKNOW;
--- 653,659 -----
  			  || (tiflags & TH_RST && ti->ti_seq == tp->rcv_nxt - 1)
  #endif
  			   ) {
+ #endif
  				todrop = ti->ti_len;
  				tiflags &= ~TH_FIN;
  				tp->t_flags |= TF_ACKNOW;
**************
*** 655,660
  				todrop = ti->ti_len;
  				tiflags &= ~TH_FIN;
  				tp->t_flags |= TF_ACKNOW;
  			} else
  				goto dropafterack;
  		} else {
--- 657,663 -----
  				todrop = ti->ti_len;
  				tiflags &= ~TH_FIN;
  				tp->t_flags |= TF_ACKNOW;
+ #ifdef	ORIG
  			} else
  				goto dropafterack;
  #endif
**************
*** 657,662
  				tp->t_flags |= TF_ACKNOW;
  			} else
  				goto dropafterack;
  		} else {
  			tcpstat.tcps_rcvpartduppack++;
  			tcpstat.tcps_rcvpartdupbyte += todrop;
--- 660,666 -----
  #ifdef	ORIG
  			} else
  				goto dropafterack;
+ #endif
  		} else {
  			tcpstat.tcps_rcvpartduppack++;
  			tcpstat.tcps_rcvpartdupbyte += todrop;

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 93 12:22:42
From:      jim@cs.strath.ac.uk (Jim Reid)
To:        comp.protocols.tcp-ip
Subject:   Re: Personal SLIP or PPP

In article <amundson-020693115511@jfi2-mac-20.uchicago.edu> amundson@yukawa.uchicago.edu (James Amundson) writes:

   Can someone please tell me if I can do this? I would like to install either
   SLIP or PPP on my unix account *for my own use only.* I am not the system
   adminstrator and I do not have root privileges. I would like to install an
   implementation of SLIP or PPP that allows me to log in to my account and
   then fire up a program that allows me to do IP over a serial line.

   I've been looking at lists of frequently asked questions and installation
   instructions for PPP, but I can't determine if what I want to do is even
   possible. Can someone tell me?

It can be done in theory, but in practical terms you need the
co-operation and assistance of the system administrator. For all sorts
of reasons - efficiency, code simplification - SLIP and PPP works best
when it is installed in the kernel. The packets can come off the tty
driver and get fed into the TCP/IP code in the kernel, just like any
packets coming from an ethernet interface (say).

Now it's possible to do this in user-level code, but it is very, very
messy. Your SLIP/PPP packets would get passed to a daemon which then
fed them back into the kernel to go through the TCP/IP code and then
out to the user-level application like say telnet. [Even then, this
SLIP/PPP daemon would probably need root permissions to get at a raw
socket anyway.]

Conventional SLIP/PPP implementations work by having the SLIP or PPP
code installed in the kernel. SLIP/PPP users get special accounts
added to the password file. When they login, the login program execs a
special program instead of a conventional shell. This program does
some "black magic" to the tty line, converting it from a conventional
tty line to a network interface. In technical terms, this is done by
replacing the tty line discipline with one for SLIP or PPP. Data from
the tty interface gets run through the SLIP or PPP code and then
squirted into the TCP/IP code instead of the tty driver.

To set this up requires system administrator privileges. Firstly, a new
kernel has to be configured and booted. Extra entries have to be added
to the password file. A special SLIP/PPP login "shell" has to be
installed.

		Jim

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Jun 1993 08:23:41 GMT
From:      rps@matuc2.mat.uc.pt (Rui Pedro Mendes Salgueiro)
To:        comp.protocols.tcp-ip
Subject:   Re: Win-sockets w/ NIS (Was PCeudora)

p00078@psilink.com ("Andrew Luck") writes:
: A couple of folks told my that there is a bug in the getservent functions,
: which causes problems when trying to resolve a services entry through NIS.
 
: I checked this by logging directly onto the SUN IPX which is our central
: server.
 
: ypmatch  pop3 services
: 
: gives back:  Can't match key pop3 in map services.byname  Reason: No such key in map.
: 
: BUT,  ypmatch 110/tcp services
: 
: gives back:   pop3  110/tcp  pop # Post Office Protocol Ver. 3
: 
: This is very weird, since if I boot up a PC DOS 6.0 with Windows 3.1

Well, the reason seems to be that the KEY in the map services.byname
is the "110/tcp".

ypcat -k services show all the map for services with the key on the
begginning of the line:

ypcat -k services | grep pop
110/tcp pop             110/tcp         postoffice pop-3# Post Office
109/tcp pop-2           109/tcp
^^^^^^^
KEY

It seems that SUN has a strange notion of what is the name of a service.
There is only one map services.by*  so the only querys you can make is
to look for the name of a service given a port number or make a exaustive
search.

getservbyname should do a exaustive search.
Anyone know why does SUN don't use the name of the service as the key ?

: and go into PC-NFS v5.0 and query the Network Information Icon with
: pop (partial string), I get back both information on pop2 and pop3.
 
: I get the same kind of funkyness with networks, hosts, and protocols files.

For all these maps there are two versions:

	networks -> networks.byaddr and networks.byname
	hosts -> hosts.byaddr and hosts.byname
	protocols -> protocols.byname and protocols.bynumber

the defaults maps used by ypmatch are:
	% ypmatch -x
	Use "passwd" for map "passwd.byname"
	Use "group" for map "group.byname"
	Use "networks" for map "networks.byaddr"
	Use "hosts" for map "hosts.byname"
	Use "protocols" for map "protocols.bynumber"
	Use "services" for map "services.byname"
	Use "aliases" for map "mail.aliases"
	Use "ethers" for map "ethers.byname"

: If there is a known bug in windows sockets apps or the getservbyname which
: is causing this problem, is it getting worked on?  Is there a patch?

--
   Rui Salgueiro     |   Dpt. de Matematica    |"Why do I smile at people
rps@matuc2.mat.uc.pt | Universidade de Coimbra | I much rather kick in the eye"
   rps@inescc.pt     |    Portugal - Europe    |     Morrissey 

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 93 16:49:09 MST
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: How can I do a rotery Telnet?

In article <1993Jun4.042831.13633@osuunx.ucc.okstate.edu>, ben@datacomm.ucc.okstate.edu (Ben James)
writes:
| In article <1um6i8$327@skates.gsfc.nasa.gov> paulf@gsfc.nas.gov (Paul Fischer;OpenAge(SWR))
| writes:
| >
| >A customer of mine wants to setup several DOS machines that will each handle
| >one incoming telnet session.  He wants to setup some sort of an alias for
| >these in the nameserver so that if the first one is busy it will connect
| >to the second one, and so on.
| >
| >Any ideas?
| >
| 
| Feel free to prove me wrong but I think this is impossible.  

Contra Ben, what Paul suggests is not only possible but downright probable.

Just set up a domain name (say, "DosPile.Widgets.COM") with one A record 
corresponding to each PC telnet server.  Make sure the telnet server code 
issues a "connection refused" if it is already serving its one connection.   
ASSUMING that the telnet client(s) are competently implemented (in that
they comply with the "should" in sec. 2.3 in RFC-1123, which says that
applications should try each IP address in order, till they achieve success), 
then any user telnetting to DosPile.Widgets.COM will be connected to the 
first available TELNET server.

Sounds like the customer has pretty good sense ... unless you stop to think
about the concept of a rack of PCs, each running one telnetd ...

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
 

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 93 16:52:28
From:      swen@uni-paderborn.de (Swen Thuemmler)
To:        comp.dcom.lans,comp.dcom.lans.misc,comp.dcom.lans.novell,comp.protocols.misc,comp.protocols.novell,comp.protocols.tcp-ip,comp.sys.sun.wanted
Subject:   Software to route IPX-Packets over TCP/IP subnets?

Dear Networld,

we have a large campus network, divided into subnets (ethernet).
Connected to this network are mainly sun-workstations and some PC's.
The suns speak TCP/IP and the PC's speak TCP/IP (PC-NFS) and (some)
Novell. We have a backbone net with Novell-servers and Sun' connected
to it.

Our problem is, that in order to use Novell we have to connect the
PC's to the backbone, since the novell packets are not routed into
subnets. Now we are looking for a way to get access to the
novell-server (in a subnet or on backbone) from a PC connected to
another subnet - preferably a software solution (and preferably free
:)).

Now comes the question(s): 
 (1) Does such a solution exist, is it possible, that there is a
     solution or do I have a horribly wrong idea of the
     Novell-concept?
 (2) Can you point me to information about Novell (IPX) network
     structure?

Thank you for your attention, please don't mind my bad english.

   Swen

--
 Swen Thümmler             # mail:    <swen@uni-paderborn.de>
 Uni-GH Paderborn, FB17    # phone:   +49 5251 60-2656
 Warburger Str. 100        # fax:     +49 5251 60-3853
 4790 Paderborn            # office:  D3.310
 +++ pgp public key at pgp-public-keys@toxicwaste.mit.edu +++

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      04 Jun 93 13:45:34 GMT
From:      puhuri@snakemail.hut.fi (Markus Peuhkuri)
To:        comp.protocols.tcp-ip,comp.sys.amiga.programmer,comp.sys.amiga.datacomm
Subject:   AmiTCP/IP - TCP/IP protocol stack as Amiga shared library

TITLE

	AmiTCP/IP - TCP/IP protocol stack as Amiga shared library

VERSION

	Distribution version 1.0

AUTHORS

	AmiTCP/IP group in Programming Project Course in
	Helsinki University of Technology. Futher on just
	AmiTCP/IP-Group.

	Tomi Ollila	<Tomi.Ollilate@cs.hut.fi>
	Pekka Pessi	<Pekka.Pessi@hut.fi>
	Jarno Rajahalme	<Jarno.Rajahalme@hut.fi>
	Markus Peuhkuri	<Markus.Peuhkuri@hut.fi>

	E-mail address: amitcp@hut.fi

DESCRIPTION

	AmiTCP/IP is the first publicly available TCP/IP protocol
	stack for the SANA-II interface. It has a BSD-compatible
	socket interface as a Amiga shared library.

FEATURES	

	1. Standard SANA-II network device driver interface.
	2. BSD-compatible socket interface as a Amiga shared library.
	3. ARexx port for configuration and statistics.
	4. Over 200 pages of documentation including:
		- Installation and configuration
		- ARexx port commands
		- Programmer's manual based on the BSD IPC manual. It
		  is a fairly complete tutorial for developing powerful
		  client/server applications
		- Internal description of the implementation
		- API function reference guide in AutoDoc form.
	5. Basic applications with source included.
	6. Based on the BSD Net/2 release.
	7. Full source code included.


SPECIAL REQUIREMENTS

	AmiTCP/IP can be run from floppy and with one
	megabyte of memory.

	OS release 2.04 or newer is required.

	Sana-2 device drivers for the network interfaces.

	Distribution is archived with lha so program to
	un-archive them is needed. 

HOST NAME

	Software has been uploaded to the Aminet
	(amiga.physik.unizh.ch, 130.60.80.80) and will be
	readily available on other Aminet sites.

	For convenience of Finnish users, AmiTCP/IP is also
	uploaded to the ftp.funet.fi.

	The authoritative version of AmiTCP/IP is located in
	kampi.hut.fi, but this archive is not meant for massive
	downloading. All new versions will be announced and
	distributed to other archives, too.

DIRECTORY

	In Aminet: comm/net
	ftp.funet.fi: pub/amiga/communication/tcpip
	kampi.hut.fi: AmiTCP

FILE NAMES

	AmiTCP/IP is distributed in 3 archives:
	AmiTCP-bin-10.lha	AmiTCP/IP binaries
	AmiTCP-doc-10.lha	Documentation for AmiTCP
	AmiTCP-src-10.lha	Source for AmiTCP/IP

	If you just want to use AmiTCP/IP, you need just bin and
	doc. To develop your own applications or AmiTCP/IP you
	need src, too. Number in the name corresponds to
	distribution revision. 10 means revision 1.0

PRICE

	Free. Contributions are accepted.

DISTRIBUTABILITY

	AmiTCP/IP is distributed under Gnu Public License.

OTHER

	Note, that this is not a final version but a
	"gamma" version that is given to Amiga community to
	find out and identify bugs that are still left in
	code. 

	E-mail address for bug reports and fixes:
	amitcp-bug@hut.fi

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Jun 1993 15:10:43 GMT
From:      cleelacj@agedwards.com (Chris Cleeland)
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   IGRP/RIP2 in a gated?

Does anybody know if a version of gated exists which supports the
IGRP/RIP2 protocols?  I'm not very literate on these issues yet 
(posting for someone else), so enlighten me if I'm asking a stupid
question.  As I understand it, RIP announces the entire routing
table every 30 seconds, and RIP2 only announces any changes.  Since
we're going over a satellite, minimizing traffic is of utmost
importance.

If a gated exists with this capability, has anybody ported it to
HP-UX 9.x (on an 800, specifically)?

Thanks!
-cj

-- 
==============================================================================
Chris Cleeland 	       	       	|  Internet:   cleelacj@agedwards.com
BOS Dev. Team                   |  USnail:     3878 Connecticut St. Louis 63116
                                |  BellNet:    (314) 289-5372

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 93 16:38:48 GMT
From:      vincent@cc.und.ac.za (Russell Vincent)
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   Tcpdump for HP 715

Hi,

Has anyone ported tcpdump (ethernet packet display/filter) to the HP7xx
series. If so, please drop me a note.

I have managed to compile the software, but can't figure out how to
configure the bpf stuff into the kernel.

Thanks in advance
 -Russell

--
Russell Vincent,  Computer Services, Univ. of Natal, Durban, South Africa
vincent@cc.und.ac.za

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Jun 1993 17:23:38 GMT
From:      mcginn@cu11.crl.aecl.ca (Timothy McGinn)
To:        comp.protocols.tcp-ip
Subject:   examples of socket level programming?

I am learning network programming on Silicon Graphics and Sparc workstations.

Does anyone have any examples of client/server apps writen at the socket level?
Something like the code for the echo server or 'simple' telnet or ftp.

I am interested in how the server waits for the clients commands and responds
to them.

for example

client connects to TCPMUX to service 'testd'
server responds with '+Online\r\n' then waits for client commands
client sends 'msg1'
server should respond with text message 1 then waits.
client sends 'msg2'
server should respond with text message 2 then waits.
client sends 'quit'
server sends 'ok' and ends.
client quits.

This may be simple but the man pages and the network programming guide for
the SGIs aren't helping me alot. I desperately need some examples. Just point
me in the right direction or ftp site.

Thanks,

-- 
Tim McGinn                /*
mcginn@crl.aecl.ca         *
AECL Research, Canada      */

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 93 20:35:47 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   Re: IGRP/RIP2 in a gated?

In article <C83rHv.5Jr@agedwards.com> cleelacj@agedwards.com (Chris Cleeland) writes:
>Does anybody know if a version of gated exists which supports the
>IGRP/RIP2 protocols?  I'm not very literate on these issues yet 
>(posting for someone else), so enlighten me if I'm asking a stupid
>question.  As I understand it, RIP announces the entire routing
>table every 30 seconds, and RIP2 only announces any changes.  Since
>we're going over a satellite, minimizing traffic is of utmost
>importance.

Sorry, but RIP-2 has the same dynamical behavior as RIP.  It only
defines fields to carry much more information about each route
(netmask, route tag, routing domain).  It also defined an authentication
option and supports multicasting.

There is a draft of a proposal for carrying RIP type protocol information
across WANs where only route changes need to be exchanged (after peer
initialization).  This work is really too new to expect implementations.

Art

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Jun 1993 20:37:49 GMT
From:      ramon@cantabria.cber.nih.gov (Ramon J. Hontanon)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   550 "Socket  not connected". Any experiences???


Hello all,

I finally got QVTnet 3.3 to run in concert with PATHWORKS on a PC here, 
and it works OK for the most part, but after FTP'ing about 100k it
slows down, gives the following message:
         
              550 MYFILE.DAT Socket not connected

and locks me up. Has anybody gotten this message before?

I run DIS_PKT9 on top of the NDIS driver for the EtherlinkII (ELNKII.SYS)

All comments are appreciated, E-mail or post!



Thanks in advance,

Best regards,

Ramon
___________________________________________________________________
                     Ramon J. Hontanon,  KE8SF                    
                        ramon@helix.nih.gov
          CBER FDA, 8800 Rockville Pk. Bethesda, MD 20892           
                          (301) 496 0718 


-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Jun 1993 20:51:50 GMT
From:      philip@cs.vu.nl (Philip Homburg)
To:        comp.protocols.tcp-ip
Subject:   Re: Rare (but nasty) BSD TCP problem

In article <C7yJzs.Eut@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
%	You're right. At first glance, I think it actually does the right
%thing in my implementation, too. I'd say "by accident," but it's because
%I followed the state machine carefully.
%	Moral of the story: "TCP is bigger than the client-server paradigm."

It does work in my TCP/IP implementation too, both connections using
the IP address of the machine and connections with localhost act like talking
to an echo server.

My implementation also follows the state machine in the RFC closely and has a 
simple hack in the IP layer to implement localhost.




						Philip Homburg



Philip Homburg 			   			<philip@cs.vu.nl>
Vrije Universiteit / Dept. of Math. & Comp. Sci.	+31 20 5483546
Amoeba project / De Boelelaan 1081A
1081 HV Amsterdam / The Netherlands

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 93 21:57:03 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   NCSA TCP bug


	I am using a 2-year old version of the NCSA TELNET code set
	and was wondering if the latest version (available via anon
	ftp) is worth upgrading to.  Specifically, are there major bug
	fixes included in the release that would mandate an upgrade?

	On another note, concerning an anomaly in our version of the
	NCSA code, it is possible for an application to receive a
	CLOSE event before all of the data has been read from the
	network buffers.  This can cause data loss problems too numerous
	to mention in this post but I was wondering if the new NCSA
	code fixes this.  I am assuming that this anomaly is possible
	since the NCSA TCP module does not segment reordering before
	delivering buffers to the application...

	Can anyone confirm the above info?

	Thanks in advance!
			Randy

-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 93 00:36:51 GMT
From:      brucek@Ingres.COM (Bruce Kleinman)
To:        comp.protocols.tcp-ip
Subject:   TIME_WAIT state transition

I'm seeking insight into TCP state transitions at connection shutdown.
Specifically, how long does a connection remain in the TIME_WAIT
state?

I'm looking at a situation where on one machine, connections move out
of TIME_WAIT after a few seconds, while on another machine (same
hardware and for all I can tell same OS version) it takes several
minutes, during which time you cannot bind to the same local port again
(you get EADDRINUSE).

Anyone aware of an explanation for this?  Any pointers would be much
appreciated.

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 93 11:25:48 GMT
From:      j.laidman@cowan.edu.au (Jeremy Laidman)
To:        comp.dcom.lans,comp.dcom.lans.misc,comp.dcom.lans.novell,comp.protocols.misc,comp.protocols.novell,comp.protocols.tcp-ip,comp.sys.sun.wanted
Subject:   Re: Software to route IPX-Packets over TCP/IP subnets?

swen@uni-paderborn.de (Swen Thuemmler) writes:

>Dear Networld,
 
>we have a large campus network, divided into subnets (ethernet).
>Connected to this network are mainly sun-workstations and some PC's.
>The suns speak TCP/IP and the PC's speak TCP/IP (PC-NFS) and (some)
>Novell. We have a backbone net with Novell-servers and Sun' connected
>to it.
 
>Our problem is, that in order to use Novell we have to connect the
>PC's to the backbone, since the novell packets are not routed into
>subnets. Now we are looking for a way to get access to the
>novell-server (in a subnet or on backbone) from a PC connected to
>another subnet - preferably a software solution (and preferably free
>:)).
 
>Now comes the question(s): 
> (1) Does such a solution exist, is it possible, that there is a
>     solution or do I have a horribly wrong idea of the
>     Novell-concept?
> (2) Can you point me to information about Novell (IPX) network
>     structure?
 
>Thank you for your attention, please don't mind my bad english.
 
>   Swen
 
>--
> Swen Thümmler             # mail:    <swen@uni-paderborn.de>
> Uni-GH Paderborn, FB17    # phone:   +49 5251 60-2656
> Warburger Str. 100        # fax:     +49 5251 60-3853
> 4790 Paderborn            # office:  D3.310
> +++ pgp public key at pgp-public-keys@toxicwaste.mit.edu +++

If you use Lan Workplace I think you should be able to achieve this
using IPTunnelling.  To set it up you should refer to the Novell TCP/IP
System Admin guide.

I'd sure like to see a packet driver version of this so I don't have to
lose heaps of memory on the ODI drivers.

---------------------------------------------------------------------
Jeremy Laidman, Analyst Programmer
Academic Computing Services                    Phone: (61 9) 370 6366
Edith Cowan University                         Fax:   (61 9) 370 2910
Perth, Western Australia                  Jeremy.Laidman@Cowan.edu.au
--
---------------------------------------------------------------------
Jeremy Laidman, Analyst Programmer
Academic Computing Services                    Phone: (61 9) 370 6366
Edith Cowan University                         Fax:   (61 9) 370 2910

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 93 17:18:48
From:      amoss@picton.cs.huji.ac.il (Amos Shapira)
To:        comp.protocols.tcp-ip
Subject:   Re: How can I do a rotery Telnet?

paulf@gsfc.nas.gov (Paul Fischer;OpenAge(SWR)) writes:

   REPLIES To: paul@openage.com

   Hi All,

   A customer of mine wants to setup several DOS machines that will each handle
   one incoming telnet session.  He wants to setup some sort of an alias for
   these in the nameserver so that if the first one is busy it will connect
   to the second one, and so on.

   Any ideas?

What about giving all of them the same name in the DNS space or otherwise make
the outside world believe they are all the same machine?  This way Telnet will
try each address thinking it is trying different addresses of the same machine.

Hope this helps,

--Amos
--
--Amos Shapira (Jumper Extraordinaire) |  "It is true that power corrupts,
C.S. System Group, Hebrew University,  |   but absolute power is better!"
Jerusalem 91904, ISRAEL                |
amoss@cs.huji.ac.il                    |          -- the Demon to his son

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Jun 1993 09:25:28 GMT
From:      ben@datacomm.ucc.okstate.edu (Ben James)
To:        comp.protocols.tcp-ip
Subject:   Re: How can I do a rotery Telnet?

In article <1993Jun4.164917.4610@arizona.edu> Leonard@Arizona.EDU writes:
>In article <1993Jun4.042831.13633@osuunx.ucc.okstate.edu>, ben@datacomm.ucc.okstate.edu (Ben James)
>writes:
>| In article <1um6i8$327@skates.gsfc.nasa.gov> paulf@gsfc.nas.gov (Paul Fischer;OpenAge(SWR))
>| writes:
>| >
>| >A customer of mine wants to setup several DOS machines that will each handle
>| >one incoming telnet session.  He wants to setup some sort of an alias for
>| >these in the nameserver so that if the first one is busy it will connect
>| >to the second one, and so on.
>| >
>| >Any ideas?
>| >
>| 
>| Feel free to prove me wrong but I think this is impossible.  
>
>Contra Ben, what Paul suggests is not only possible but downright probable.
>
>Just set up a domain name (say, "DosPile.Widgets.COM") with one A record 
>corresponding to each PC telnet server.  Make sure the telnet server code 
>issues a "connection refused" if it is already serving its one connection.   
>ASSUMING that the telnet client(s) are competently implemented (in that
>they comply with the "should" in sec. 2.3 in RFC-1123, which says that
>applications should try each IP address in order, till they achieve success), 
>then any user telnetting to DosPile.Widgets.COM will be connected to the 
>first available TELNET server.
>
>Sounds like the customer has pretty good sense ... unless you stop to think
>about the concept of a rack of PCs, each running one telnetd ...
>
>Aaron
>
>Aaron Leonard (AL104), <Leonard@Arizona.EDU>
>University of Arizona Network Operations, Tucson AZ 85721
> 

I'm curious would this still work if one of the machines was out of order.
Here we have 3 machines which do the same thing and it requires us to quite a 
bit of juggleing when we have to take one out of service or if one crashes.

Also could you still have different names defined to them for diagnostic 
purposes.

Ben James


-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Jun 1993 11:58:54 GMT
From:      andr@elvis.sovam.com (Andrei Arkhipov)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   ftp through firewalls

How can I do ftp through the firewall? What soft is need to be
installed?

Thank you,
       Andrei.


-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 93 13:55:54 GMT
From:      starner@HAN.Paramax.COM (Mark Starner)
To:        comp.protocols.tcp-ip
Subject:   4.3BSD-tahoe and SunOS 4.1.2

I just installed the current version of cslip onto my Sun4c/4.1.2. Works
great. The README said to install the 4.3BSD-tahoe networking code
from gatekeeper.dec.com to make slip lines run better.

I retrieved the code. gor most of it to compile... but the sections
(uipc_*) that deal with inodes/vnodes, i dont know how to make compile.

Has anyone got a version of the tahoe code that will work in SunOS 4.1.2 or
have a pointer to a version that will work?


Thanks
Mark

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Jun 1993 13:58:23 GMT
From:      AlexYu@chaosbbs.nchu.edu.tw (Alex Yu)
To:        comp.protocols.tcp-ip
Subject:   Is there a FAQ for SLIP?

	Is anybody out there kind enough to tell me where to
find the FAQ for SLIP?

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1993 02:01:55 -0700
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.dcom.lans,comp.dcom.lans.misc,comp.dcom.lans.novell,comp.protocols.misc,comp.protocols.novell,comp.protocols.tcp-ip,comp.sys.sun.wanted
Subject:   Re: Software to route IPX-Packets over TCP/IP subnets?

In article <1993Jun6.185114.22837@kth.se>, regebro@linnea-grind.stacken.kth.se
 (Lennart Regebro) wrote:
>Most modern routers have IPX support. 

Yes, but many modern enterprise networks' administrators decide
not to enable IPX routing on their backbone routers.

IP tunnels are useful in coping with what you can't change.

...Sam
-- 
<skl@wimsey.bc.ca> -- Connectivity Technology Inc.

"NetNews on CD's" product information: <NewsCD@CDPublishing.COM>


-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 1993 17:05:24 GMT
From:      mjr@tis.com (Marcus J Ranum)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: ftp through firewalls

>How can I do ftp through the firewall? What soft is need to be
>installed?

	Take a look on the firewalls mailing list archives, which
are stored on ftp.greatcircle.com. There is a perl-based FTP proxy
server that might solve your problem. There are also discussions
of various other ways of doing it. For example, at TIS, we permit
FTP data return connections over a small number of ports, and have
modified the FTP client to bind only ports in that region.

mjr.

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 93 17:50:59 GMT
From:      manne@Minsk.docs.uu.se (Magnus L|vkvist)
To:        comp.protocols.tcp-ip,bit.listserv.ibmtcp-l
Subject:   Any book suggestions???

I don't know very much about TCP/IP so now I'm looking for some good
books to read.

One or perhaps a few books that will (together with a lot of coding,
trial and errors) transform me from a novice to someone who can
write my own FTP server or even better my own SLIP.

So I could walk into my local bookstore and get some books that
probably will be very bad or I could get some book suggestions from
the all you TCP/IP gurus out there in net land. Please help!

Thanks in advance!

/Magnus

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 93 18:51:14 GMT
From:      regebro@linnea-grind.stacken.kth.se (Lennart Regebro)
To:        comp.dcom.lans,comp.dcom.lans.misc,comp.dcom.lans.novell,comp.protocols.misc,comp.protocols.novell,comp.protocols.tcp-ip,comp.sys.sun.wanted
Subject:   Re: Software to route IPX-Packets over TCP/IP subnets?

In article <SWEN.93Jun4165228@blitz.uni-paderborn.de> swen@uni-paderborn.de (Swen Thuemmler) writes:
>Dear Networld,
>
>Our problem is, that in order to use Novell we have to connect the
>PC's to the backbone, since the novell packets are not routed into
>subnets. Now we are looking for a way to get access to the
>novell-server (in a subnet or on backbone) from a PC connected to
>another subnet - preferably a software solution (and preferably free
>:)).
>
>Now comes the question(s): 
> (1) Does such a solution exist, is it possible, that there is a
>     solution or do I have a horribly wrong idea of the
>     Novell-concept?

If the novell servers are not availiable from your subnets I would suspect
that the routers connecting the subnets to the backbone is filtering out
the IPX packets. There could be other easons of course, but this should be the
most common. The solution then, would be to check if your routers have IPX
support, and then enable it. IF they don't you probably have to buy new ones...
Or you could connect the subnets to the Netware servers, which if they are 3.11
servers can act as routers of both IPX and TCP/IP.

Most modern routers have IPX support. 

-- 
Lennart Regebro             regebro@stacken.kth.se
Stacken Computer Club
Any Opinion expressed above is (c) Rent-An-Opinion(tm). It is not an Opinion
of either Lennart Regebro or the Stacken Computer Club. 
Now you also can get an Opinion. Call Welcome To Reality(tm) +1 (800) NO-CLUES.

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 93 18:56:50 GMT
From:      regebro@linnea-grind.stacken.kth.se (Lennart Regebro)
To:        comp.dcom.lans,comp.dcom.lans.misc,comp.dcom.lans.novell,comp.protocols.misc,comp.protocols.novell,comp.protocols.tcp-ip,comp.sys.sun.wanted
Subject:   Re: Software to route IPX-Packets over TCP/IP subnets?

In article <jeremy.739279548@scorpion.ac.cowan.edu.au> j.laidman@cowan.edu.au (Jeremy Laidman) writes:
>
>If you use Lan Workplace I think you should be able to achieve this
>using IPTunnelling.  To set it up you should refer to the Novell TCP/IP
>System Admin guide.
>
>I'd sure like to see a packet driver version of this so I don't have to
>lose heaps of memory on the ODI drivers.

How would a packet driver version help? You still need the ODI drivers for
the Netware part. And the packet driver would not use less memory compared
to the ODI driver.
-- 
Lennart Regebro             regebro@stacken.kth.se
Stacken Computer Club
Any Opinion expressed above is (c) Rent-An-Opinion(tm). It is not an Opinion
of either Lennart Regebro or the Stacken Computer Club. 
Now you also can get an Opinion. Call Welcome To Reality(tm) +1 (800) NO-CLUES.

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 93 05:18:04 GMT
From:      j.laidman@cowan.edu.au (Jeremy Laidman)
To:        comp.dcom.lans,comp.dcom.lans.misc,comp.dcom.lans.novell,comp.protocols.misc,comp.protocols.novell,comp.protocols.tcp-ip,comp.sys.sun.wanted
Subject:   Re: Software to route IPX-Packets over TCP/IP subnets?

regebro@linnea-grind.stacken.kth.se (Lennart Regebro) writes:

>In article <jeremy.739279548@scorpion.ac.cowan.edu.au> j.laidman@cowan.edu.au (Jeremy Laidman) writes:
>>
>>If you use Lan Workplace I think you should be able to achieve this
>>using IPTunnelling.  To set it up you should refer to the Novell TCP/IP
>>System Admin guide.
>>
>>I'd sure like to see a packet driver version of this so I don't have to
>>lose heaps of memory on the ODI drivers.
 
>How would a packet driver version help? You still need the ODI drivers for
>the Netware part. And the packet driver would not use less memory compared
>to the ODI driver.

Currently I have a packet driver providing both IP and IPX support.  I load
an IPX bound to the packet driver (thanks to BYU) to give me the Netware
part - without ODI drivers.  I envisage a packet driver IPTUNNEL would replace 
the IPX support currently provided by BYU's IPX.

Where we have the routing problem, I can use ODI and IPTUNNEL, but I'd rather 
use packet driver and a 'PDTUNNEL' if it existed.

--
---------------------------------------------------------------------
Jeremy Laidman, Analyst Programmer
Academic Computing Services                    Phone: (61 9) 370 6366
Edith Cowan University                         Fax:   (61 9) 370 2910

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1993 05:30:51 GMT
From:      smc1@Ra.MsState.Edu (Steven M. Carter)
To:        comp.protocols.tcp-ip,comp.pcnet,comp.sys.novell,comp.sys.sun.hardware,comp.sys.sun.misc,unix.questions,alt.internet.services
Subject:   Linking Two Networks.

	I am the system's administrator at Raspet Flight Research Laboratories
at Mississippi State University.  I have an Ethernet with a Sparc 2 and a
bunch of PC's on it.  I would like to tie in a bunch of PC's in a building
around 300 yards away.  My first choice would be to do it with an RF link,
but I would like to hear any ideas anyone might have.  I'm not sure whether
to install a stand alone network at the other building or to install a 
gateway or what.  It would be helpful if you could include the manufacturer
of the hardware in your solution and where to find it.  Thanks in advance
for your help.  Send replies to:

		smc1@Ra.MsState.edu

--
Steven M. Carter  
smc1@Ra.MsState.edu              	Mississippi State University
scarter@Hecate.Raspet.MsState.edu	Raspet Flight Research Laboratory
Home : (601) 324-2915

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1993 18:06:32 -0700
From:      lyndon@unbc.edu (Lyndon Nerenberg)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Why we need OSI

ag129@ucs.cam.ac.uk writes:

>It is probably not misrepresenting OSI to say that it is based on
>extending successful telephone network principles to data networks.

And that goes a long ways towards explaining why ISO data networking doesn't
work well. They are two very different beasts.

Ever tried doing a directed broadcast over the telephone system? We do
quite a few every week. For a multicast group of 10 or so nodes it takes the
conference call operator about 15 minutes to set it up :-)

--lyndon

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 93 16:17:51 MST
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: How can I do a rotery Telnet?

In article <1993Jun6.092528.22321@osuunx.ucc.okstate.edu>, ben@datacomm.ucc.okstate.edu (Ben James)
writes:

| I'm curious would this still work if one of the machines was out of order.

Should.  When the TELNET client tries to reach that IP address, it will 
timeout (after 2 minutes or so) waiting for it to show signs of life,
then continue on with the next address.

| Here we have 3 machines which do the same thing and it requires us to quite a 
| bit of juggleing when we have to take one out of service or if one crashes.

Could well be.

| Also could you still have different names defined to them for diagnostic 
| purposes.

Sure.  You can have an arbitrarily large number of domain names
mapping to any given IP address (and also a domain name can map
to an arbitrarily large number of IP addresses.)  (However, an IP address
can usefully only map to a single domain name.
| 
| Ben James

Aaron

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1993 10:32:31 GMT
From:      ballhaus@mikro.ee.tu-berlin.de (Susan Ballhausen)
To:        comp.protocols.tcp-ip
Subject:   WinNT over NetWare TCP-IP Router

Hi,

I'm trying to connect different Windows NT/Windows for
Workgroups machines on a NetWare-Network.

Since NETBEUI is not routeable, I'm using TCP/IP as
the transfer protocol. I have configured my NetWare-server
to route IP-Packets wich works fine so far.

I can ping from each side to the other side, so TCP/IP is
definitely installed correct.

But the FileManager (Computer-Browser) will not recognize
any NT-Machine on the other side of the NetWare Router.

I think, I'll have to configure something on my Windows
machines like NETBIOS on TC/IP but I really cannot figure
out the correct parameters.


Has anybody established such an TCP/IP connection via 
a NetWare-Router and can help me further?

Please do not reply but mail to triest@mikro.ee.tu-berlin.de
Thanks!


-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Mon, 07 Jun 1993 15:41:48
From:      fks@lard.ftp.com  (Frances K. Selkirk)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS Alternative for Wide Area Networks

In article <michael.ward-260593160505@47.86.0.13> michael.ward@nt.com (Michael Ward) writes:

> Hi,
>
>    Does anyone know about an alternative to NFS mounts for unix servers.  I
> am looking at several unix machines that use NFS to mount drives across the
> network and since NFS uses UDP to transmit information is proves to be very
> un-reliable across mutiple Wide Area serial links.  This proves especially
> so with low speed links like 56K.

NFS over TCP does exist, but I'm not sure there is a UNIX
implementation.  The NFS client in version 2.2 of our PC/TCP package
can use TCP, and TGV makes a TCP NFS server, but I don't know of any
other currently available implementations. (The client and server
must, of course, match in protocol.)

Anyone else with more information?

--
Frances K. Selkirk		fks@ftp.com		(508) 685-3600
FTP Software, Inc.		2 High Street, North Andover, MA 01845


-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 93 17:20:15 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: Software to route IPX-Packets over IP

>>In article <jeremy.739279548@scorpion.ac.cowan.edu.au> j.laidman@cowan.edu.au (Jeremy Laidman) writes:
>>>
>>>If you use Lan Workplace I think you should be able to achieve this
>>>using IPTunnelling.  To set it up you should refer to the Novell TCP/IP
>>>System Admin guide.
>>>
>>>I'd sure like to see a packet driver version of this so I don't have to
>>>lose heaps of memory on the ODI drivers.
 
>>How would a packet driver version help? You still need the ODI drivers for
>>the Netware part. And the packet driver would not use less memory compared
>>to the ODI driver.
>
>Currently I have a packet driver providing both IP and IPX support.  I load
>an IPX bound to the packet driver (thanks to BYU) to give me the Netware
>part - without ODI drivers.  I envisage a packet driver IPTUNNEL would replace 
>the IPX support currently provided by BYU's IPX.
>
>Where we have the routing problem, I can use ODI and IPTUNNEL, but I'd rather 
>use packet driver and a 'PDTUNNEL' if it existed.
>
>--
>---------------------------------------------------------------------
>Jeremy Laidman, Analyst Programmer
>Academic Computing Services                    Phone: (61 9) 370 6366
>Edith Cowan University                         Fax:   (61 9) 370 2910
--------
Jeremy,
	Perhaps knowing how IPTUNNEL really works would change your mind.

		Applications (including IPX)  +--------------------+
			|                     |                    |
			v                     v                    |
		---------------------------------                  |
			ODI                                        |
		---------------------------------                  |
		MLIDs (board drivers)  IPTUNNEL as an MLID         |
		board		         TCP stack                 |
                  |                     (acting as another app-->--+
                 wire

	If you can follow around on the picture, IPX goes to ODI for a board
driver and gets IPTUNNEL. The latter uses the LWP/DOS TCP/IP stack to form
nice IP packets, and it turns around and hands them to ODI for coupling to
the real board. Clever, eh? Unwound it looks like this:
		IPX
		ODI
		IPTUNNEL MLID
		TCP/IP stack
		ODI
		board MLID
		wire

	This means the system must have a real, full, TCP/IP protocol stack,
and one which can behave in this Byzantine fashion. Packet Drivers are not
protocol stacks so there is no hope for a TCP/IP Packet Driver (a contradiction
in terms if nothing else).
        Joe D.

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Jun 1993 11:45:23 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Why we need OSI

  I guess I pretty strongly disagree with Tony.  There is no real 
advantage to having the IETF pass stuff along to ISO for ratification,
particularly since ISO has such a horrible track record of taking
what might have been a decent spec and mangling it at the ISO level
(the most recent example is the transformation of SP3 from a readable
solid specification into NLSP which is wholly unreadable even by experts
in the field).

  As to SIP focusing on solving Internet problems, I think that is the
correct focus.  Understand that the Internet is by far the largest 
operational network the world has ever seen and that the Internet includes
both high speed and low speed links and both noisy (RF) links and very
clean (fiber) links.  If there is some particular technical shortcoming
that you see, I am certain that the SIP Working Group would very much
like to hear about it.  If your problem can't be made very technically
specific, then it probably isn't a real problem.

  I think the liaison status of IETF with ISO is silly.  The US Government
and most commercial customers already recognise the Internet Society as
the forum wherein Internet Standards are developed.  This is similar to
how the IEEE most usually works in areas outside IEEE 802.* and IEEE 1003.*;
in most areas the IEEE writes its own standards and there are more IEEE
standards that have never been blessed by ANSI, ISO, IEC than there are
IEEE standards that have been blessed in that way.  Moreover, the IETF
already has full international participation (e.g. Christian Huitema of
INRIA in France is on the IAB).  

  Any connection between the IETF and the ANSI/ISO world is likely to
cause the IETF process to become broken.  There is significant historical
precedence for this (e.g. IEEE 1003.* before it became involved with ISO).

Ran
atkinson@itd.nrl.navy.mil
Naval Research Laboratory
Washington, DC, USA

PS: Followups are redirected to comp.protocols.tcp-ip since this discussion
    is about the IETF...

PPS: We actually probably need to create comp.org.ietf for these discussions.

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 93 17:32:31
From:      rpb@psy.ox.ac.uk (Ray Bellis)
To:        comp.dcom.lans,comp.protocols.misc,comp.protocols.tcp-ip,comp.sys.sun.wanted,comp.dcom.lans.misc
Subject:   Re: Software to route IPX-Packets over TCP/IP subnets?

In article <SWEN.93Jun4165228@blitz.uni-paderborn.de> swen@uni-paderborn.de (Swen Thuemmler) writes:

   Dear Networld,

   we have a large campus network, divided into subnets (ethernet).
   Connected to this network are mainly sun-workstations and some PC's.
   The suns speak TCP/IP and the PC's speak TCP/IP (PC-NFS) and (some)
   Novell. We have a backbone net with Novell-servers and Sun' connected
   to it.

It's not clear whether you're using your Sun machines as gateway routers
or not.  If you are, then Mark Bush of the Oxford University Computing
Laboratory has written an IPX router for SunOS which uses the STREAMS
`nit' interface.  His e-mail address is Mark.Bush@comlab.ox.ac.uk

Ray.

--
------------------------------------------------------------------------------
R. P. Bellis				E-Mail:	<rpb@psy.ox.ac.uk>
Dept. of Experimental Psychology	Whois:	(RB83)
University of Oxford			Tel:	+44 865 271419
South Parks Road			Fax:	+44 865 310447
Oxford OX1 3UD
------------------------------------------------------------------------------

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 93 12:47:51 GMT
From:      sp_ppm@space.alcbel.be (Paul Moore)
To:        comp.protocols.tcp-ip
Subject:   Problem: How to provide a packet service over TCP/IP?

Hello,

We have a space ground-link application which involves providing a packet-oriented
service across TCP/IP, using variable-sized packets. Our problem is to decide how 
to organise the client to best send packets, and then to easily delimit packets 
received by the server.

Since TCP/IP is a stream-oriented service, it isn't aware about application message
boundaries, so for example, four send() calls by the client to send four packets
may result in a single TCP frame being transmitted to the server, which then needs
extra processing to extract the four packet from the data received. This is a simple
matter if the packets are always guaranteed to be of equal length, but a non-trivial
problem otherwise.

As I see it, there are three ways to solve this problem:
1. Use the TCP_NODELAY option to push each packet onto the network as soon as 
   possible. This will be inefficient for small-length packets.
2. Always send a standard-sized application packet that is padded if it is not
   filled. This doesn't solve the problem, as the useful packet data still has to 
   be somehow extracted from the received packets.
3. Send a fixed-length control packet with each data packet. This control 
   packet indicates the length the following data packet, to simplify packet data
   extraction by the server. This is obviously an extra transmission overhead.

I'm sure that this problem has been encountered and solved before, for example with
RPC, and even with bog-standard FTP. 

Does anyone have any advice on how best to solve this particular problem?

Thanks in advance.

Paul.

----
Paul Moore,                email: sp_pm@space.alcbel.be
Alcatel Bell Telephone,
Space Dept. TS664,         phone: (+32) 3/829.5024
Berkenrodelei 33,
2660 Hoboken,
Belgium.


-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 93 12:51:26 GMT
From:      sp_ppm@space.alcbel.be (Paul Moore)
To:        comp.protocols.tcp-ip
Subject:   Errata list requested for Stevens' "UNIX Network Programming"

Hello,

I read somewhere that there is an errata list for W. R. Stevens' book 
"UNIX Network Programming".

As I don`t have FTP access, could someone email me this list?

Thanks in advance,
Paul 

----
Paul Moore,                email: sp_pm@space.alcbel.be
Alcatel Bell Telephone,
Space Dept. TS664,         phone: (+32) 3/829.5024
Berkenrodelei 33,
2660 Hoboken,
Belgium.


-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Jun 1993 13:26:44 GMT
From:      stuarts@apertus.com (Stuart Stanley)
To:        comp.protocols.tcp-ip
Subject:   Re: How can I do a rotery Telnet?

Aaron Leonard (leonard@telcom.arizona.edu) wrote:
: In article <1993Jun4.042831.13633@osuunx.ucc.okstate.edu>, ben@datacomm.ucc.okstate.edu (Ben James)
: Contra Ben, what Paul suggests is not only possible but downright probable.
 
: Just set up a domain name (say, "DosPile.Widgets.COM") with one A record 
: corresponding to each PC telnet server.  Make sure the telnet server code 
: issues a "connection refused" if it is already serving its one connection.   
: ASSUMING that the telnet client(s) are competently implemented (in that
: they comply with the "should" in sec. 2.3 in RFC-1123, which says that
: applications should try each IP address in order, till they achieve success), 
: then any user telnetting to DosPile.Widgets.COM will be connected to the 
: first available TELNET server.

The bad side of this is that alot of telnet client WON'T do this. *sigh*.
The problem is two fold:  First there is software that just plain doesn't
look at multiple addresses (bad bad software.  Go to your room).  The
second problem is that the remaining software tends to look for
connection timed out errors before trying the next server.  A "connection
refused" on our Svr4 boxs and our SUNs all cause the resolve to stop.

There is another solution that is a little grosser, but will do the
job regardless of how compliant the clients are.  Heres what'cha do:

    1)  Setup a NS entry in your main DNS servers refering references
	of "DosPile.Widgets.Com." to another machine, say DosServe.Widgets.Com.

    2)  Get another machine to act as a "Dos Name Server".  Get a copy
	of the BSD DNS and configure it with all the machine names
	in the form:  machine1.DosPile.Widgets.Com.  You may want to
	leave the in-addr.arpa addressing in the real DNS. 

    3)  Hack the BSD code to do the following:
	a)  When it sees a request to "DosServe.Widgets.Com.", hijack the
		request and "determine"*1 which machines have a free connection.

	b)  Fill in the name of the free machine into the to request and
		fall back into normal processing.  (ie, change the
		name being resolved from DosPile.Widgets.Com. to
		FreeMachine.DosPile.Widgets.Com. and let'er rip.

	c)  The Hacked DNS finishes resolving that name to its proper
		IP addr and your client is happy.

	(You will need to set TTL to 0 and such in the DNS config files so
	that noone decides to cache your data.)

	*1 ->  Determining the "load" of your PC's is the real trick.  I
	  have run through a couple of different tecniques, none of which
	  are perfect.  The fact that the PC will only take 1 connection
	  makes this even trickier.  If this is the route that you decide
	  might have _some_ promise, I will post more.

Well, theres a real good ugly solution.  You can shoot me now ;)

: Sounds like the customer has pretty good sense ... unless you stop to think
: about the concept of a rack of PCs, each running one telnetd ...
*snort*  That picture just _made_ my morning!

: Aaron
 
: Aaron Leonard (AL104), <Leonard@Arizona.EDU>
: University of Arizona Network Operations, Tucson AZ 85721
:  

--
 "Part catastrophe and part chaos," said Rosa.  !    Stuart Stanley
       "Sounds pretty human to me."             !    stuarts@apertus.com
               Pat Cadigan, _Synners_           !    Apertus Technologies
                             (612)-828-0391    <->   Eden Prairie, Minnesota

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1993 13:31:49 GMT
From:      ctk@dirty.doc.ic.ac.uk (Christos T Karamanolis)
To:        comp.protocols.tcp-ip
Subject:   IP multicasting

I am interested in using the new (as far as I know) multicasting primitives (IGMP) of the
TCP/IP family of protocols.

The only sources of information I have managed to find are just the relative RFCs (1112, 
1075, etc.).

Has anyone worked with IGMP so that he could give me information about current TCP/IP products,
if any, that implement multicasting (versions, operating systems, etc)? Any other information
concerning multicasting is also welcome.

Thanks,
Christos

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 93 21:32:00 +1000
From:      effeneyp@topaz.ucq.edu.au
To:        comp.protocols.tcp-ip
Subject:   NETBIOS over SLIP

We are trying to run LanManager over SLIP, but are having problems.
We are using the PC\TCP protocol stack into an Emulex terminal 
server. SLIP seems to work OK, including NFS etc. But as soon as 
we try to get NETBIOS over SLIP we have problems. Should this
be possible to do? Any help would be appreciated.

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Jun 1993 15:19:28 GMT
From:      ag129@ucs.cam.ac.uk
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Why we need OSI

In article <C891zn.7v3@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
> Understand that the Internet is by far the largest 
>operational network the world has ever seen

The telephone network is larger by many orders of magnitude.  
It is probably not misrepresenting OSI to say that it is based on
extending successful telephone network principles to data networks.

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1993 15:21:25 GMT
From:      whalenm@tsg.com (Matthew Whalen)
To:        comp.protocols.tcp-ip
Subject:   Re: How can I do a rotery Telnet?

In article <1um6i8$327@skates.gsfc.nasa.gov> paulf@gsfc.nas.gov (Paul  
Fischer;OpenAge(SWR)) writes:
> >Hi All,
> >
> >A customer of mine wants to setup several DOS machines that will each  
 handle
> >one incoming telnet session.  He wants to setup some sort of an alias  
 for
> >these in the nameserver so that if the first one is busy it will  
 connect
> >to the second one, and so on.
> >
> >Any ideas?
> >

I heard a rumour that this is what uunet does for their ftp.  I don't know  
if it's really true or  not.  I would image that someone could write (if  
very motivated) some type of router for this.  If there are 5 telnet  
sessions into machine A, redirect future telnet requests to machine B. 


Just a thought.


-matthew           ____      
whalenm@tsg.com    \  /    equal rights, not special rights      
(NeXTMail OK)       \/      
----------------------------------------------------------------
"Thus conscience does make cowards of us all, and thus the native hue of  
resolution is sicklied o'er with the pale cast of thought, and enterprises  
of great pith and moment with this regard their currents turn awry,and  
lose the name of action."
----------------------------------------------------------------

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Jun 1993 15:23:31 GMT
From:      ag129@ucs.cam.ac.uk
To:        comp.dcom.lans,comp.dcom.lans.misc,comp.dcom.lans.novell,comp.protocols.misc,comp.protocols.novell,comp.protocols.tcp-ip,comp.sys.sun.wanted
Subject:   Re: Software to route IPX-Packets over TCP/IP subnets?

In article <1uv063$6tr@vanbc.wimsey.com> skl@wimsey.bc.ca (Samuel Lam) writes:
>In article <1993Jun6.185114.22837@kth.se>, regebro@linnea-grind.stacken.kth.
 se> (Lennart Regebro) wrote:
>>Most modern routers have IPX support. 

On Novell-supported media, yes.  However, routers are usually connected
together via e.g. fibre, and many vendors haven't yet standardised on
Novell's IPXWAN standard.  So if you have two different routers you have
to bridge IPX, not route. 

>Yes, but many modern enterprise networks' administrators decide
>not to enable IPX routing on their backbone routers.
>IP tunnels are useful in coping with what you can't change.

Quite so.  Apropos of this, has anyone heard any hard details of NWIP,
the new NCP-over-IP solution from Novell?

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Jun 1993 15:37:33 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: IP multicasting

In article <1uvg05INNnpg@frigate.doc.ic.ac.uk>, ctk@dirty.doc.ic.ac.uk (Christos T Karamanolis) writes:
> I am interested in using the new (as far as I know) multicasting
> primitives (IGMP) of the TCP/IP family of protocols.
> 
> The only sources of information I have managed to find are just the
> relative RFCs (1112, 1075, etc.).
> 
> Has anyone worked with IGMP so that he could give me information
> about current TCP/IP products,
> if any, that implement multicasting (versions, operating systems,
> etc)? Any other information concerning multicasting is also welcome.


IGMP is several years old.

At least one vendor has been shipping it for years.

There are patches to make it work on some versions of Sun's system.

The by now famous Internet Mbone uses it.

There are several public-domain or freely re-distributable packages
for putting audio over UDP/IP.


Vernon Schryver,  vjs@sgi.com

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Jun 1993 15:43:53 GMT
From:      dawkins@bnr.ca (Spencer Dawkins)
To:        comp.protocols.tcp-ip,bit.listserv.ibmtcp-l
Subject:   Re: Any book suggestions???

In article <manne.739389059@Minsk> manne@Minsk.docs.uu.se (Magnus L|vkvist) writes:
>I don't know very much about TCP/IP so now I'm looking for some good
>books to read.
>
>Thanks in advance!
>
>/Magnus

If it was me (at at one time, it was) I would start with Douglas Comer's
Interworking with TCP/IP trilogy (Prentice Hall). Make sure you get the second
edition of volume 1; it covers lots of stuff like SNMP that's not in the first
edition. I'd also look at UNIX Network Programming by Stevens, also Prentice
Hall. 

These will keep you busy for a while, anyway!
-- 
------------------------------------------------------------------------------
-  Spencer Dawkins			Bell-Northern Research	             -
-  (214) 684-4827			P.O. Box 833871                      -
-  Internet: dawkins@bnr.ca		Richardson TX 75083-3871             -

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Jun 1993 16:50:35 GMT
From:      ldr@mv.mv.com (Lee Rothstein)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Why we need OSI

In article <ag129.35.739462716@ucs.cam.ac.uk> ag129@ucs.cam.ac.uk writes:

>In article <C891zn.7v3@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
>> Understand that the Internet is by far the largest 
>>operational network the world has ever seen
 
>The telephone network is larger by many orders of magnitude.  
>It is probably not misrepresenting OSI to say that it is based on
>extending successful telephone network principles to data networks.

Yes, but they are two different kinds of networks that evolved over
considerably different periods of time and rate of expenditures relative
to "aggregate GNPs".

This view that "we built the telephone network so data networking will be
easy" was quite prevalent at Bell Labs when I worked there. There are two
things wrong with that attitude. The first is what I stated above. The
second is that "No YOU didn't!", whoever "YOU" (BTL or otherwise) is. Why?
Most of the people who were really key to creating the global telephone
network are dead. This is not a trivial point. Much of the knowledge of
running the telephone and Internet networks resides in the organization of
participating enterprises and roles of people. No one is smart enough to
put it back together, again, if the physical network and the organizations
fall apart.

Notice that in the above argument that trial and error played a big role
in both networks. It is not a trivial point that Marshall Rose makes when
he says that empirical test is still required. (I think this is what
the folks like Steve Kille and Harald Alvestrand are trying to do with OSI
protocols. They are creating reference implementations of OSI applications
that can be tested on the Internet before adopting them universally. The
"reference implementations" also will be free (or low cost--which?)
providing a competitive source of code.

If OSI is to succeed, they (Kille et al.) must succeed in the
implementations, tests, and deployment. And they must progress faster than
the random alternative efforts such as MUSE, et al. 
-- 
                  <> Lee D. Rothstein <> ldr@veritech.com <>
     <> VeriTech <> 7 Merrymeeting Drive <> Merrimack, NH 03054-2934 <>
                    <> 603-424-2900 <> Fax: 603-424-8549 <>
            <> Information Technology Verification & Leadership <>

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Jun 1993 18:00:23 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: How can I do a rotery Telnet?

 Leonard@Arizona.EDU writes:
> paulf@gsfc.nas.gov (Paul Fischer;OpenAge(SWR)) writes:
>| >
>| >A customer of mine wants to setup several DOS machines that will each handle
>| >one incoming telnet session.  He wants to setup some sort of an alias for
>| >these in the nameserver so that if the first one is busy it will connect
>| >to the second one, and so on.
>| >
>| >Any ideas?
>| >
 
>Contra Ben, what Paul suggests is not only possible but downright probable.

Yes, it definately works with any decent TELNET client implementation.  I 
have set up a few this way.  If you encounter a rogue client which can't
do this, have them telnet into a Unix box and then telnet out to the PC
rack.

>Just set up a domain name (say, "DosPile.Widgets.COM") with one A record 
>corresponding to each PC telnet server.  

Yep, lots of people think a multihomed host and its multiple A records have
to be on different subnets.  That is not true as long as they do not attempt
to route between the two, so it works beautifully here.

>Sounds like the customer has pretty good sense ... unless you stop to think
>about the concept of a rack of PCs, each running one telnetd ...

... I'm thinking but I just don't see the problem.  What is wrong with it?


Erick
-- 


-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1993 19:16:08 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem: How to provide a packet service over TCP/IP?

There are three standard ways to do this:

  1. Send a word of length before each "packet",
  2. Use a delmiter byte or bytes after each "packet", or
  3. Use UDP.

Any will work.  (1) is how DNS works over TCP, (2) is how SMTP and
other line-oriented protocols work, and (3) is how DNS, NTP, rwho, and
many other services work.

Don't use UDP unless you can afford to lose data once in a while.

Don't use the TCP push function, because it is not a record delimiter.
Using it as one will stop working as soon as your transmitter gets a
little ahead of the receiver.

       Stephen

(BTW, Please use lines of 80 columns or less.  Many of us out here do
not have wide screens.  Thanks.)
-- 
Stephen Trier (trier@ins.cwru.edu - MIME OK)   
Network Software Engineer              
IRIS/INS/T                               
Case Western Reserve University             

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1993 19:50:03 GMT
From:      nessett@framsparc.ocf.llnl.gov (Dan Nessett)
To:        sci.crypt,alt.security,comp.protocols.tcp-ip
Subject:   2nd CFP - ISOC Symp. on Net. and Dist. Sys. Security


                             CALL FOR PAPERS
                    The Internet Society Symposium on
                 Network and Distributed System Security

        3-4 February 1994, Catamaran Hotel, San Diego, California

The symposium will bring together people who are building software and
hardware to provide network or distributed system security services.
The symposium is intended for those interested in practical aspects of
network and distributed system security, rather than in theory.  Symposium
proceedings will be published by the Internet Society.  Topics for the
symposium include, but are not limited to, the following:

*  Design and implementation of services--access control, authentication,
   availability, confidentiality, integrity, and non-repudiation
   --including criteria for placing services at particular protocol layers.

*  Design and implementation of security mechanisms and support
   services--encipherment and key management systems, authorization
   and audit systems, and intrusion detection systems.

*  Requirements and architectures for distributed applications and
   network functions--message handling, file transport, remote
   file access, directories, time synchronization, interactive
   sessions, remote data base management and access, routing, voice and
   video multicast and conferencing, news groups, network management,
   boot services, mobile computing, and remote I/O.

*  Special issues and problems in security architecture, such as
   -- very large systems like the international Internet, and
   -- high-speed systems like the gigabit testbeds now being built.

*  Interplay between security goals and other goals--efficiency,
   reliability, interoperability, resource sharing, and low cost.

GENERAL CHAIR:
   Dan Nessett, Lawrence Livermore National Laboratory

PROGRAM CHAIRS:
   Russ Housley, Xerox Special Information Systems
   Rob Shirey, The MITRE Corporation

PROGRAM COMMITTEE:
   Dave Balenson, Trusted Information Systems
   Tom Berson, Anagram Laboratories
   Matt Bishop, Dartmouth College
   Ed Cain, U.S. Defense Information Systems Agency
   Jim Ellis, CERT Coordination Center
   Steve Kent, Bolt, Beranek and Newman
   John Linn, Geer Zolot Associates
   Clifford Neuman, Information Sciences Institute
   Michael Roe, Cambridge University
   Rob Rosenthal, U.S. National Institute of Standards and Technology
   Jeff Schiller, Massachusetts Institute of Technology
   Ravi Sandhu, George Mason University
   Peter Yee, U.S. National Aeronautics and Space Administration

SUBMISSIONS:  The  committee seeks both original technical papers and
proposals for panel discussions on technical and other topics of general
interest.  Technical papers should be 10-20 pages in length.  Panels
should include three or four speakers.  A panel proposal must name the
panel chair, include a one-page topic introduction authored by the chair,
and also include one-page position summaries authored by each speaker
Both the technical papers and the panel papers will appear in the
proceedings.

Submissions must be made by 16 August 1993.  Submissions should be made
via electronic mail to

                   1994symposium@smiley.mitre.org.

Submissions may be in either of two formats:  ASCII or PostScript.  If
the committee is unable to read a PostScript submission, it will be
returned and ASCII requested.  Therefore, PostScript submissions should
arrive well before 16 August.  If electronic submission is absolutely
impossible, submissions should be sent via postal mail to

                   Robert W. Shirey, Mail Stop Z202
                   The MITRE Corporation
                   McLean, Virginia  22102-3481  USA

All submissions must include both an Internet electronic mail address and
a postal address.  Each submission will be acknowledged through the
medium by which it is received.  If acknowledgment is not received within
seven days, please contact either Rob Shirey <Shirey@MITRE.org> or
Russ Housley <Housley.McLean_CSD@xerox.com>, or telephone Mana Weigand at
MITRE in Mclean, 703-883-5397. 

Authors and panelists will be notified of acceptance by 15 October 1993.
Instructions for preparing camera-ready copy for the proceedings will be
postal mailed at that time.  The camera-ready copy must be received by
15 November 1993.



-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1993 19:57:58 GMT
From:      jkaplen@lupc01.it.luc.edu (Joe Kaplenk)
To:        comp.protocols.tcp-ip
Subject:   Help in converting to routing from bridging

At Loyola we have recently installed routers among our three major campuses. We have been
running TCP/IP for the last 4 years, but bridging it using an  AT&T ISN system. We have 
established our subnet addresses and currently use a subnet mask of 255.255.0.0 and will
go to 255.255.255.0. We would like to make the transition as painless as possible for ourselves
and our users. I am interested in whether anyone has done a large scale transition to
IP routing from ethernet bridging and what information I could get about their plans and 
problems. 

The 2 alternatives we are looking at are:
1-    Using a  temporary dedicated router to ease the transition to subnetting. As we convert hosts to
	the new subnet mask and default route this router would take care of converting
	packets and routing them to the proper destination. We cannot turn routing on
	separately on each of the main routers, but must do them all together. This is necessary
	because the routers talk directly to each other over T1 circuits. Once we 
	have all the hosts converted over we would then turn routing off on the temporary	
	router and turn on routing on the main routers and use the addresses of
	the temporary router as the permanent addresses for routing on our main routers. 
	The routers currently route IPX only.

2-  The second alternative is to just do everything in one day. This means going around to
 	all the hosts and converting them. Since TCP/IP has grown significantly here in the 
	past 2 years here it means a lot of headaches, coordinating of workers 
	and problems where we might need to back out of the whole process and restart
	at another time. Loyola has 3 main campuses and it means a lot of travelling,
	calling and planning. 

	I have tried to make my explanation as simple as possible. Hopefully, I have provided 
	enough information. 

	Please send mail as well as responding to the posting. You can send mail to 
	jkaplenk@lucpul.it.luc.edu. My news feed is still not stable and I am experimenting 
	with different configurations. 

	Thanks for any help anyone can give.

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Jun 1993 20:53:31 GMT
From:      syedk@netcom.com (syed khalid)
To:        comp.protocols.snmp,comp.dcom.cell-relay,comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   ATM, ethernet  SNMP agents



I am looking for information on vendors who have developed or are developing
SNMP agents for ATM and/or ethernet networks. What are the major products
out there? If there are any articles that have covered these areas, I would
appreciate knowing knowing about them.
The other area I am interested in is ATM protocol analyzers in the market place.Please respond by E-mail directly and I will summarize if necessary.
Thanks in advance.

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Jun 1993 21:19:26 GMT
From:      aad@scr.siemens.com (Anthony A. Datri)
To:        comp.protocols.tcp-ip,comp.protocols.ppp,comp.sys.sun.misc
Subject:   Re: Dedicating a Sun as a central SLIP/PPP server ??

I'm moderately sure that Cisco's boxes will handle them now.

-- 

======================================================================8--<

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Jun 1993 22:32:28 GMT
From:      pcg@aber.ac.uk (Piercarlo Grandi)
To:        comp.protocols.tcp-ip
Subject:   Re: Personal SLIP or PPP

>>> On Wed, 2 Jun 1993 17:01:19 GMT, amundson@yukawa.uchicago.edu (James
>>> Amundson) said:

Amundson> Can someone please tell me if I can do this? I would like to
Amundson> install either SLIP or PPP on my unix account *for my own use
Amundson> only.* I am not the system adminstrator and I do not have root
Amundson> privileges.

Well, if you really must: there are two alternatives. One is to use the
Unix hosted version of the KA9Q NOS (wampes version available from
ucsd.edu).

The other alternative, far more palatable, is to use one of the many
quasi-IP protocols around.

In particular 'term' (available from almost any Linux host) supports
both telnet and ftp connections, which is I think is rather cool.

If all you need is fancy remote logins over a serial line, IP is not
necessarily needed; you can use one of many windowing packages, for
example 'layers' (available for Mac and Unix), and so on.

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 93 12:51:25 -0800
From:      mccalld@vax.sonoma.edu
To:        comp.protocols.tcp-ip
Subject:   telnet vs. dialup-modem HELP

I've got a problem with telnet vs. dialup.
Telnet to host, shell to ksh and execute a script containing menus.
Works fine.  Now, dial up that same host, and using say PROCOMM (vt100
emulation), shell to ksh and execute that same script, you get garbage
on the screen after the initial banner page. It would seem that the 
command 'stty cooked', in the ksh script, doesn't like either the modem
or PROCOMM or the vt100 emulation.
So how can I fake out these 3 to get the results which works vi telnet?
Or where can I look to get further information about what is going on
?????????????????????????????????????????????????????????????????????


-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 1993 12:08:23 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <1993Jun8.173044.28294@gordian.com> mike@gordian.com (Michael A. Thomas) writes:
>
>  Which if it is too late (applicationwise), it doesn't 
>do you any good. Real time considerations are not ignorable.

   Unfortunately, the purists most frequently forget that people
   like to buy computers and protocol suites to do a job....not
   argue over fine points of layering and separation of layer
   functions.

>Consider a situation where you need proactive failover 
>capability: ie when a circuit becomes unusable a new circuit
>is automatically started to another machine; something
>like a point of sale situation. Being able to test the 
>circuits "upness" is essential because you want to failover
>*before* the user has to wait rather than in (user) real time. 


>  It doesn't matter whether the circuit non-deterministically
>might ever come up again: from the users standpoint, a long
>time is too long. The problem is that you are dealing with
>people in a situation like this and they just aren't going
>to buy into the aesthetics and purity you are espousing. 

    The above paragraph should be tattooed on a few foreheads...

    Another frequent happening in the client/server world is the use
    of a DOS client and Unix server.  These are connected by a
    private (sql-type) socket.  The DOS end of the connection goes
    out to lunch due to interesting little issues in a
    non-multitasking environment.  

    The server ends up with a socket connection into the database
    which tends to just set there forever consuming resources.  

    You can always configure the server with excess capacity, so the
    client PC can get back in to finish whatever the user was doing,
    but eventually someone or something has to go thru and release
    all the inactive socket connections.  


>  Yes, of course it could be programmed into the application
>but as Vernon points out, it is a lot more efficient (and
>dare I say it, expedient?) to have the kernel provide the
>primitive.
>
    I'd say the only issue is whether the keepalive should be 
    configured (per 1122 which clearly states it must be
    configurable) on a per/services (or application)  basis or a 
    connection (IP address pair) basis....and whether or not
    the application should be given a primitive which allows it to
    change the timing of keepalive dynamically. 

    And I'd much rather trust the TCP implementors to provide this
    type of function in a reasonable, reliable, low-overhead manner
    than the applications implementors...who really shouldn't need
    to be bothered with such networking-specific trivia. 


-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 93 01:00:04 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Errata list requested for Stevens' "UNIX Network Programming"

>I read somewhere that there is an errata list for W. R. Stevens' book 
>"UNIX Network Programming".

All at UUNET in their published/books directory, along with all
the source code from the book.

	Rich Stevens  (rstevens@noao.edu)

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jun 1993 02:32:41 GMT
From:      tsukako@sdl.hitachi.co.jp (Masato Tsukakoshi)
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   Re: IGRP/RIP2 in a gated?

In article <1993Jun4.203547.28523@acc.com> art@acc.com (Art Berggreen) writes:
>In article <C83rHv.5Jr@agedwards.com> cleelacj@agedwards.com (Chris Cleeland) writes:
>>Does anybody know if a version of gated exists which supports the
>>IGRP/RIP2 protocols?  I'm not very literate on these issues yet 
>>(posting for someone else), so enlighten me if I'm asking a stupid
>>question.  As I understand it, RIP announces the entire routing
>>table every 30 seconds, and RIP2 only announces any changes.  Since
>>we're going over a satellite, minimizing traffic is of utmost
>>importance.
>
>Sorry, but RIP-2 has the same dynamical behavior as RIP.  It only
>defines fields to carry much more information about each route
>(netmask, route tag, routing domain).  It also defined an authentication
>option and supports multicasting.
>

Yes, you're right.  RIP-1 and RIP-2 are interoperable if RIP-1 doesn't check
reserved field to be zero.

The newest GateD version is 2.1, but there is also Beta version for 3.0
(GateD Release 3.0 Beta 2: May 18).  This beta version supports RIP-1/2,
OSPF-2, BGP-2/3, EGP and Hello.  IGRP is not supported by GateD.

Anonymous FTP is available at gated.cornell.edu. The filename of this Beta
is pub/gated/gated-R3_0Beta_2.tar.Z.

Masato Tsukakoshi



-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 1993 03:35:10 GMT
From:      emv@garnet.msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip,comp.protocols.ppp,comp.sys.sun.misc
Subject:   Re: Dedicating a Sun as a central SLIP/PPP server ??

Jim Doyle (doyle@cs.umass.edu) wrote:
: Our department is considering dedicating a machine as a CSLIP & PPP dialup
: server for faculty and staff. In the outset - we'd like to provide the
: capacity for up to 30 simultaneous dialup PPP/SLIP connections via a shared
: campus terminal server. The use of the dedicated machine would basically be
: an interim solution until a Terminal Server implementation of these protocols
: is available.

I'd consider two solutions for this sort of situation.

One would be a dedicated Unix system (Sun would be OK) with one of
those SCSI-attached smart serial port boxes on it, and running the
Morning Star PPP.  Your interrupt load would be pretty high, and
I'm not sure how well you could cope with 30 people running flat
out, but it does give you a ton of flexibility in configuraiton and
logging and security and what not.

The other would probably be a Livingston Portmaster terminal server -
we have a 30 port box from them in and servicing our SLIP and PPP
connections, works really quite well.

You might also want to think hard about your modem configurations.
My experience as the owner of a batch of individual modems in a hunt
sequence is that they are kind of icky to deal with one at a time;
some kind of rack mount system, esp. one with some built in diagnostics
and monitoring and what not, is no doubt worth that investment.
US Robotics makes such a box; I hear Hayes has one in the works;
and the high-rent equipment is gear from "Primary Access" in San
Diego.  Rather than bring in n pairs of copper, you just haul a
single T1 into the box.


  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 4562 (fax: 998 4563)


-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 1993 12:09 MST
From:      gavron@spades.aces.com (Ehud Gavron)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <1993Jun8.072847.29164@novell.com>, donp@novell.com (don provan) writes...
#In article <1993Jun4.005001.20670@gordian.com> mike@gordian.com (Michael A. Thomas) writes:
#>> Application timeouts are always better than keepalives.  The only
#>> disadvantage is a little extra code, and that's not worth the cost or
#>> inflexibility of keepalives.
#>
#>  An application timeout (like the one most FTP's implement) is
#>not really the same as a keepalive. A keepalive is testing the 
#>circuit's state, whether or not a user is using it. An application
#>timeout is more akin to a inactivity timeout, which is based
#>on the *user* not the circuit's state.
# 
#I certainly can't argue with that.  Now the only question left to
#decide is whether the circuit's state is of any use at all to an
#application implementation.  I claim it is not.  For one thing, the
#state of connection cannot be reliably determined.  If an intervening
#router is temporarily down, the keepalive mechanism with kill the
#connection even though it would otherwise be perfectly healthy once the
#router comes back up.  On the other hand, the state of the connection
#does not reliably indicate the state of the end-to-end communication
#path between the two applications.  For example, one peer could be dead
#even though its TCP/IP socket continues to respond to keepalives.
# 
#						don provan
#						donp@novell.com

One use we have for keepalives is that we have unidirectional laboratory
instruments connected to terminal server ports and via TCP/IP to ptys on
Unix hosts.

It is imperative for our host to know if the terminal server has rebooted
or power-cycled so that it can reestablish the connection to the particular
port.  The instrument does not respond to commands, and only sends data
when it has some -- thus an application level timeout is inappropriate,
and an application level probe is ineffectual.

The keepalives as implemented in TCP on the terminal server and the host
is what makes the whole thing work correctly.  I encourage anyone to point
me at other such transparent solutions.

Ehud

--
Ehud Gavron        (EG76)     
gavron@aces.com
Yow!  I want to mail a bronzed artichoke to Nicaragua!

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Tue, 08 Jun 1993  10:29 EST
From:      Adriene@maspo2.mas.yale.edu  (ALN)
To:        comp.protocols.tcp-ip
Subject:   Re: How can I do a rotery Telnet?

In Article <1993Jun4.164917.4610@arizona.edu> "leonard@telcom.arizona.edu (Aaron Leonard)" says:
> In article <1993Jun4.042831.13633@osuunx.ucc.okstate.edu>, ben@datacomm.ucc.okstate.edu (Ben James)
> writes:
> | In article <1um6i8$327@skates.gsfc.nasa.gov> paulf@gsfc.nas.gov (Paul Fischer;OpenAge(SWR))
> | writes:
> | >
> | >A customer of mine wants to setup several DOS machines that will each handle
> | >one incoming telnet session.  He wants to setup some sort of an alias for
> | >these in the nameserver so that if the first one is busy it will connect
> | >to the second one, and so on.
> | >
> | >Any ideas?
> | >
> | 
> | Feel free to prove me wrong but I think this is impossible.  
> 
> Contra Ben, what Paul suggests is not only possible but downright probable.
> 
> Just set up a domain name (say, "DosPile.Widgets.COM") with one A record 
> corresponding to each PC telnet server.  Make sure the telnet server code 
> issues a "connection refused" if it is already serving its one connection.   
> ASSUMING that the telnet client(s) are competently implemented (in that
> they comply with the "should" in sec. 2.3 in RFC-1123, which says that
> applications should try each IP address in order, till they achieve success), 
> then any user telnetting to DosPile.Widgets.COM will be connected to the 
> first available TELNET server.
> 
> Sounds like the customer has pretty good sense ... unless you stop to think
> about the concept of a rack of PCs, each running one telnetd ...
> 
Yup, this should work.   
Not a bad idea if you have a stack of old 8086/8088 in your store room.
/A

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jun 1993 06:08:54 GMT
From:      agust@risken.vd.volvo.se (Anders Gustafsson)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   C interface to FTP?


I'm looking for a simple C interface to the FTP protocol, i.e. a
library with routines like FtpConnect(host), FtpLogin(user, passw),
FtpGetFile(remote, local), or something similar.

Anyone know where I can get such a package?

Thanks, Anders




-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jun 1993 07:28:47 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <1993Jun4.005001.20670@gordian.com> mike@gordian.com (Michael A. Thomas) writes:
>> Application timeouts are always better than keepalives.  The only
>> disadvantage is a little extra code, and that's not worth the cost or
>> inflexibility of keepalives.
>
>  An application timeout (like the one most FTP's implement) is
>not really the same as a keepalive. A keepalive is testing the 
>circuit's state, whether or not a user is using it. An application
>timeout is more akin to a inactivity timeout, which is based
>on the *user* not the circuit's state.

I certainly can't argue with that.  Now the only question left to
decide is whether the circuit's state is of any use at all to an
application implementation.  I claim it is not.  For one thing, the
state of connection cannot be reliably determined.  If an intervening
router is temporarily down, the keepalive mechanism with kill the
connection even though it would otherwise be perfectly healthy once the
router comes back up.  On the other hand, the state of the connection
does not reliably indicate the state of the end-to-end communication
path between the two applications.  For example, one peer could be dead
even though its TCP/IP socket continues to respond to keepalives.

						don provan
						donp@novell.com

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 93 16:08:27 MST
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp/ip pad

In article <C8BEIs.LB6@cbnewsj.cb.att.com>, wmasson@cbnewsj.cb.att.com 
(bill.masson) writes:

| Does anyone know if there is a tcp/ip equivalent to an x.25 pad.

A terminal server (aka a "communications server".)

| I have an async. device, not a terminal, that I need to communicate
| with over a lan/wan. A terminal server doesnt quite fit my needs.

In what way doesn't a terminal server (aka a "communications
server") fail to meet your needs?  The ones I'm familiar with can
handle darn near any serial application I know of.

| Any help would be appreciated.

More detailed help will be forthcoming, following a more detailed
description of your requirements.

| 				Thanks,
| 				Bill Masson

Best,

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 1993 11:20:10 GMT
From:      dsc@xray.hmc.psu.edu (David S. Channin)
To:        news.groups,comp.protocols.iso,comp.protocols.misc,comp.protocols.tcp-ip,alt.image.medical,sci.med,sci.med.telemedicine,sci.med.physics,comp.graphics,comp.graphics.visualization,sci.image.processing
Subject:   CFV: comp.protocols.dicom



Having completed a one month period of discussion, this is the first CALL for VOTES:

Proposal: Creation of a new newsgroup: comp.protocols.dicom

The stated charter of the group is:
: Charter:
 
:   The purpose of this group will be to discuss issues surrounding 
:   the American College of Radiology - National Electrical 
:   Manufacturers  (ACR-NEMA)  standard for Digital Imaging and 
:   Communications in Medicine (DICOM). This standard represents 
:   the next step beyond the ACR-NEMA version 2 standard released 
:   in 1988.
:   Postings will include information about progress of the development
:   of the standard, and issues concerning implementation  of the 
:   standard. Periodic postings will be made explaining how to obtain
:   the  latest versions of the available chapters, as well as information 
:   related to  demonstrations of the standard at the RSNA meeting.
:   

This group will not be moderated.

If you are in favor of the creation of such a group, please send a message to:

       dicom-yes@xray.hmc.psu.edu
       
       
If you are opposed to the creation of such a group, please send a message to:

      dicom-no@xray.hmc.psu.edu
      
The voting period will end on July 8, 1993 at midnight. Any votes received after this time
will not be counted. Any votes received at other e-mail addresses will not be counted.

Thank you very much

For off-line discussion concerning this CFV, please contact:
   
   dsc@xray.hmc.psu.edu
   
    David S. Channin
    Department of Radiology
   Section of Radiologic Computing and Imaging Science
   Penn State University
   The Milton S. Hershey Medical Center
   P.O. Box 850
   Hershey, PA 17033
   (717) 531 - 5728
  



-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 93 16:55:20 CDT
From:      leung@turtle.fisher.com
To:        comp.protocols.tcp-ip
Subject:   RPC, with XDR and NDR


Data Representation of SUN RPC is XDR, while that of Apollo RPC
(and OSF DCE RPC) is NDR.

1) what are the differences between these two data representation
   standards? Are there plans to reconcile the differences by
   the responsible parties?

2) if I need to build communication software on two systems that provide
   these two flavors of "RPC" respectively, how much
   (and what) work is needed to make the two systems talk correctly
   if I use RPC, since data representation is different?
   I always wonder how ftp does it.

   Should I even use RPC?


-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 93 13:17:19 GMT
From:      ccdw@kudu.ru.ac.za (Dave Wilson)
To:        comp.protocols.tcp-ip
Subject:   PCRoute subnetting?

I know I've seen this discussed, but didn't take enough interest at the
time...  I'd like to setup the following:

     /-----+------ BACKBONE --------------/
	   |
     PCRouterA
	   |
	   |
	   |
          slip
	  link
	   |
	   |               NOVELL 3.11
	   |                 |      |
     PCRouterB            |A     |B
	   |                 |      |
     /-----+-----------------+-/  /-+---------------------/

Backbone = 146.231.128.0 mask 255.255.248.0
PCRouterA = 146.231.128.200 mask 255.255.0.0
PCRouterB = 192.42.99.130 mask 255.255.255.0

NOVELL server is doing IP forwarding, using: 
interface A = 192.42.99.129 mask 255.255.255.224
interface B = 192.42.99.66 mask 255.255.255.224

Unfortunately, it doesn't work.  Hosts on the 192.42.99.64 segment
cannot reach the backbone.  I've tried using mask 255.255.255.224 on
PCRouterB, but that doesn't seem to make any difference.  BTW, I'm using
PCRoute 2.24.

Thanks for any help.

--
Dave Wilson
Computing Centre, Rhodes University
Grahamstown, South Africa

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jun 1993 14:01:58 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <1993Jun8.072847.29164@novell.com>, donp@novell.com (don provan) writes:
> In article <1993Jun4.005001.20670@gordian.com> mike@gordian.com (Michael A. Thomas) writes:
> >> Application timeouts are always better than keepalives.  The only
> >> disadvantage is a little extra code, and that's not worth the cost or
> >> inflexibility of keepalives.
> >
> >  An application timeout (like the one most FTP's implement) is
> >not really the same as a keepalive. A keepalive is testing the 
> >circuit's state, whether or not a user is using it. An application
> >timeout is more akin to a inactivity timeout, which is based
> >on the *user* not the circuit's state.
> 
> I certainly can't argue with that.  Now the only question left to
> decide is whether the circuit's state is of any use at all to an
> application implementation.  I claim it is not.  For one thing, the
> state of connection cannot be reliably determined.  If an intervening
> router is temporarily down, the keepalive mechanism with kill the
> connection even though it would otherwise be perfectly healthy once the
> router comes back up.  On the other hand, the state of the connection
> does not reliably indicate the state of the end-to-end communication
> path between the two applications.  For example, one peer could be dead
> even though its TCP/IP socket continues to respond to keepalives.


It all depends.

What if you happen to control all of the routers in the path, or if
there are none?  What if any routers are warrented to be more reliable
than the end pionts?  What if the data is bursty?  What if the failure
of the TCP link to the other end is just as bad as the failure of the
other end?

Imagine running a refinery.  You have the central control room sending
instructions to many computers running various vats, columns, or
whatever they are, and the individual controllers talking to each
other.  (I don't know much about refineries.)  The control room
only tells the individual controllers to do something when instructions
change.  The individual controllers talk to each other and central
control only when they have something to say. 
(I.e. no application-level keepalives.)

Wouldn't it be a good idea for everything to run keepalives in this
case?  To start shutting down the reactions or stop pumping stuff to
the next guy in case the communications link to the down-stream
controller dies, and the next guy's tank is full, or getting too
hot or something?  

In this contrived example you'd probably use application-level
keepalives, probably consisting of regular reports even if when nothing
changed, but just imagine if keepalives were configurable.  Kernel
keepalives would use less bandwidth, and it might be easier to "prove"
(i.e. argue convincingly) that their timers are safe.  You might use
both kernel keepalives and application probes to have a better idea
what is wrong and try to pick the smallest explosion, to know whether
the link is down, or the link is up and the controller is letting
the reactor explode.

If you don't like that hypothetical case, imagine a flight simulator or
another kind of "virtual reality" system, where a central device sends
a stream of pictures to a bunch of graphic heads.  It would be nice if
the graphics heads did not have to do their own liveness checks on the
stream from the central machine, if they could just rely on the system
to tell them when their TCP link died.  You can do the checks in the
individual displays, but the people writing the display code have
enough to worry about without keeping timers on incoming data.
(This is not a hypothetical example.)


Of course, there is nothing that kernel keepalives do that cannot be
done by the application, but that applies to all parts of an operating
system not related to resource allocation or "security."  Some of us do
not think DOS is a good way to organize software.  Some of us think it
makes sense to put more than the program loader and most primitive file
system into the "operating system" (including libraries or MACH's or
Multix).


Vernon Schryver,  vjs@sgi.com

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jun 1993 14:05:43 GMT
From:      hughes@logos.ucs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   Re: C interface to FTP?

In article <agust.739519734@risken>, agust@risken.vd.volvo.se (Anders Gustafsson) writes:
|> I'm looking for a simple C interface to the FTP protocol, i.e. a
|> library with routines like FtpConnect(host), FtpLogin(user, passw),
|> FtpGetFile(remote, local), or something similar.

FTP Software has similar library calls in their development kit.  I
highly recommend their dev kit, as it ports BSD-sockets compatible
code with little or no effort.

 //==================================================================\\
||      Larry J. Hughes, Jr.       |        hughes@indiana.edu        || 
||       Indiana University        | "The person who knows everything ||
||  University Computing Services  |        has a lot to learn."      ||
 \\===================================================================//

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jun 1993 14:22:09 GMT
From:      Yves Tremolet <yves.tremolet@gsi.fr>
To:        comp.protocols.tcp-ip
Subject:   FTP with restart on various systems


Hi,

I am looking for an FTP solution either public or commercial which would
support a "restart" command, (ie be fault tolerant) and which would run
on:

HP9000, AS400, and VAX/VMS.

Thanks a lot for any info,

Yves Tremolet,             yves.tremolet@gsi.fr

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 93 20:48:51 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: Netwatch.exe on MS-DOS

In article <1993Jun8.195023.3833@astph>, bob@astph (Bob Ford) writes:
> I have ftp'd Netwatch and the Clarkson Packet drivers from the Net, and
> have them working on our LAN.  Only trouble is, there was no documentation
> to go along with Netwatch!  I got it to run only by trial and error. I
> would appreciate it if someone could point me to some documentation that
> would show me how to do a few things with the program that are not
> obviously explained when I look at the help screen.
> 
> Thanks for your help.
> -- 
> Bob Ford                            Voice:(814)234-8592x36
> INTERNET: astph!bob@attmail.com     UUCP: attmail.com!astph!bob
> Philadelphia Phillies		    FAX:  (814)234-1269
---------------
	Then try anonymous ftp to what was probably the site from whence
that version arose: netlab1.usu.edu, cd pub/netwatch. The "whole thing"
is there, including the docs. It's all Public Domain at this stage.
	Joe D.

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jun 1993 16:13:55 GMT
From:      evan@gandalf.ca (Evan Caves)
To:        comp.protocols.tcp-ip
Subject:   What is RTelnet????


Does anyone know what RTelnet is? Pointing me to a relevant RFC would
be sufficient.

Thanx,


-- 
Evan Caves
Gandalf Data Ltd.
evan@gandalf.ca      

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jun 1993 17:30:44 GMT
From:      mike@gordian.com (Michael A. Thomas)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <1993Jun8.072847.29164@novell.com>, donp@novell.com (don provan) writes:
> I certainly can't argue with that.  Now the only question left to
> decide is whether the circuit's state is of any use at all to an
> application implementation.  I claim it is not.  For one thing, the
> state of connection cannot be reliably determined.  

  Well that is true, but in many circumstances the straightline
heuristic is plenty good enough.

> If an intervening
> router is temporarily down, the keepalive mechanism with kill the
> connection even though it would otherwise be perfectly healthy once the
> router comes back up.

  Which if it is too late (applicationwise), it doesn't 
do you any good. Real time considerations are not ignorable.
Consider a situation where you need proactive failover 
capability: ie when a circuit becomes unusable a new circuit
is automatically started to another machine; something
like a point of sale situation. Being able to test the 
circuits "upness" is essential because you want to failover
*before* the user has to wait rather than in (user) real time. 
  It doesn't matter whether the circuit non-deterministically
might ever come up again: from the users standpoint, a long
time is too long. The problem is that you are dealing with
people in a situation like this and they just aren't going
to buy into the aesthetics and purity you are espousing. 
  Yes, of course it could be programmed into the application
but as Vernon points out, it is a lot more efficient (and
dare I say it, expedient?) to have the kernel provide the
primitive.

>  On the other hand, the state of the connection
> does not reliably indicate the state of the end-to-end communication
> path between the two applications.  For example, one peer could be dead
> even though its TCP/IP socket continues to respond to keepalives.

  Come now, this is a pathological situation and hardly the norm.
-- 

		Michael Thomas	(mike@gordian.com)
	"I don't think Bambi Eyes will get you that flame thrower..."  
		-- Hobbes to Calvin
		USnail: 20361 Irvine Ave Santa Ana Heights, Ca,	92707-5637
		PaBell: (714) 850-0205 (714) 850-0533 (fax)

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jun 1993 17:31:12 GMT
From:      jpoller@novell.com (Jack L. Poller)
To:        comp.protocols.tcp-ip
Subject:   Information conveyed by keepalive/timeout (was Re: RFC for keepalives)

In article <idm4lpe@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com
(Vernon Schryver) writes:

[ don provan's original exposition on keepalive's deleted for brevity ]

[ Vernon Schryver's examples deleted for brevity ]

(Vernon Schryver) writes:
=> Of course, there is nothing that kernel keepalives do that cannot be
=> done by the application, but that applies to all parts of an operating
=> system not related to resource allocation or "security."  Some of us do
=> not think DOS is a good way to organize software.  Some of us think it
=> makes sense to put more than the program loader and most primitive file
=> system into the "operating system" (including libraries or MACH's or
=> Multix).
=> 
=> Vernon Schryver,  vjs@sgi.com

I think there is a problem with your reasoning, Vernon.  There is a
big difference between protocol (your 'kernel') keepalive's and
application timeouts.  Each conveys different information, which is
the key to this whole discussion.  First, the keepalives:

A protocol keepalive conveys a particular set of information.  Upon
successful transmission/receipt of a keepalive, a *protocol stack*
knows:

	* there is a complete, working path, *at this time* between
	  myself and my tcp peer
	* my tcp peer is responding to me, and all of our packet ids
	  are in sync

The protocol stack does *not* know:

	* is the application residing above me alive?
	* is the application residing above my tcp peer alive?
	* have the applications timed out?
	* is there a resource contention problem?
	..... etc.......

Upon *unsuccessfull* transmission/receipt of a keepalive, a *protocol
stack* knows:

	* there is *not* a complete, working path, *at this time* between
	  myself and my tcp peer

	  or

	* my tcp peer is not responding to me

The protocol stack does *not* know:

	* is the application residing above me alive?
	* is the application residing above my tcp peer alive?
	* have the applications timed out?
	* is there a resource contention problem?
	..... etc.......

Now, the application level timeouts:

When an application level timer expires, the *application* knows:

	* my client/peer has not responded.

The application does *not* know:

	* has my client/peer crashed or just gone quiet?
	* is there a working path between myself and my application
	  client/peer?
	* is there a working tcp peer?

If the application chooses to implement a "application keepalive" ,
and the application successfully transmits/receives the "application
keepalive", the application knows:

	* there is a complete, working path, *at this time* between
	  myself and my tcp peer
	* my tcp peer is responding to me, and all of our packet ids
	  are in sync
	* My application peer/client is alive and responding to me
	* application specific information conveyed with the
	  "application keepalive" packet

If the application chooses to implement a "application keepalive" ,
and the application *unsuccessfully* transmits/receives the "application
keepalive", the application knows:
	
	* there is not a complete, working path, *at this time* between
	  myself and my tcp peer

	  or

	* my tcp peer is not responding to me

	  or

	* My application peer/client is not alive and responding to me

So we have four possible 'states', and each conveys a completely 
different set of information.  Now, with a little bit of creative
inter-process communication information that the protocol can
determine (link level information) can be communicated to the
application.  And vice-versa, application level information can
likewise be communicated to the protocol stack.  But in no way are
the data points the same.

I will make the following conclusions:

	* Application level timers and keepalives do *not* convey the
	  same information that protocol/link level timers and
	  keepalives convey.

	* Link level timers/keepalives are useful and provide
	  link level information.

	* Application level timers/keepalives are useful and provide
	  application level information.

	* If an application chooses to use a link level
	  timer/keepalive, the application is doing so for only two
	  reasons:

	    A. The application wishes to know link-level information

	    or 

	    B. The application developers wish to piggy back off of
	       the link level code, and not develop their own.

Now, having dealt with the subject at hand, I will touch upon your
'aside' attack on that which you consider is faulty organization of
software.

=> Of course, there is nothing that kernel keepalives do that cannot be
=> done by the application, but that applies to all parts of an operating
=> system not related to resource allocation or "security."  Some of us do
=> not think DOS is a good way to organize software.  Some of us think it
=> makes sense to put more than the program loader and most primitive file
=> system into the "operating system" (including libraries or MACH's or
=> Multix).

I question why this paragraph is present in this discussion.  Is this
an attack against Don Provan?  Against Novell?  Against Microsoft? 
Regardless, I feel I must address your implicit attacks, and equally implicit
emphasis on the superiority of Unix/TCP/IP.

There will come a time when you will realize that software mimicks
hardware.  Just as in hardware, where there exists no perfect
solution, in software, all solutions are compromises.  Even the
perfect technical solution will have an imperfect implementation
because of time/cost/manpower compromises.

Unix is not the be-all end-all O/S.  NetWare is not the be-all end-all
O/S.  Likewise DOS/Windows/OS-2/VMS/MVS/ITOS .....  Each is a solution
to a particular problem.  Some are more general purpose than others.
Some are very specific in nature.

TCP/IP is not the be-all end-all communications protocol.  IPX is not
the be-all end-all communications protocol.  Neither is
OSI/SNA/X.25/....  Each is a solution to a particular problem.  Some
are more general purpose than others.  Some are very specific in
nature.

The time to realize this is now.

-- Jack L. Poller
---
Jack Noze -- jpoller@novell.com
	"A unix signature isn't a return address, it's the ASCII equivalent of
	a black velvet clown painting. It's a rectangle of carets surrounding
	a quote from a literary giant of weeniedom like Heinlein or Dr. Who."
	-- <cmaeda@cs.cmu.edu>


-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 93 22:39:52
From:      jnicolas@whistler.mit.edu (Julien Nicolas)
To:        comp.protocols.tcp-ip
Subject:   **** (C)SLIP for ULTRIX 4.3? Is there one? ****



hi everyone!

Where can I find a version of SLIP (Serial Line IP) that compiles
reasonably easily under ULTRIX 4.3? I grabbed an old CSLIP version 2.6
from ftp.uu.net, but have had not luck compiling it. I am sure this
question must have been asked before, but since I do not read this
newsgroup very regularly, I was not able to find any information
anywhere. *Any* leads or clues would be greatly appreciated.

Please email me and I shall summarize if there is any interest. Thanks
in advance!

Julien Nicolas
jnicolas@athena.mit.edu


-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 93 18:10:57 GMT
From:      wmasson@cbnewsj.cb.att.com (bill.masson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   tcp/ip pad


Does anyone know if there is a tcp/ip equivalent to an x.25 pad.
I have an async. device, not a terminal, that I need to communicate
with over a lan/wan. A terminal server doesnt quite fit my needs.
Any help would be appreciated.
				Thanks,
				Bill Masson

-- 

William E. Masson
wem@suntoss.smst290.att.com

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jun 1993 18:50:34 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: IP multicasting

>In article <1uvg05INNnpg@frigate.doc.ic.ac.uk>, ctk@dirty.doc.ic.ac.uk (Christos T Karamanolis) writes:
> I am interested in using the new (as far as I know) multicasting
> primitives (IGMP) of the TCP/IP family of protocols.
> 
> The only sources of information I have managed to find are just the
> relative RFCs (1112, 1075, etc.).
> 
> Has anyone worked with IGMP so that he could give me information
> about current TCP/IP products,
> if any, that implement multicasting (versions, operating systems,
> etc)? Any other information concerning multicasting is also welcome.

  Vern is quite right.  IP Multicasting is OLD rather than NEW.  If
you look at the dates on the RFCs, you'll see this clearly.  The IP
Multicast technology is quite stable and has proven its value in
experiments over the Multicast Backbone (MBONE).

  Reportedly both Sun and SGI ship it in their current OS releases as
a standard part of the OS.  DEC is rumoured to be including it in
their OSF/1.2 release for the Alpha.  Patches to SunOS 4.1.x and
Ultrix for MIPS are freely available on the net.

  Freely distributable audio/video conferencing applications have also
been available for some time.  BBN sells a commercial product "Picture
Window" which provides audio/video conferencing over IP multicast.

  IGMP and Multicast OSPF are currently implemented by at least one
major router vendor.  Two other router vendors are building
implementations right now.

Ran
atkinson@itd.nrl.navy.mil


-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jun 1993 19:50:23 GMT
From:      bob@astph (Bob Ford)
To:        comp.protocols.tcp-ip
Subject:   Netwatch.exe on MS-DOS

I have ftp'd Netwatch and the Clarkson Packet drivers from the Net, and
have them working on our LAN.  Only trouble is, there was no documentation
to go along with Netwatch!  I got it to run only by trial and error. I
would appreciate it if someone could point me to some documentation that
would show me how to do a few things with the program that are not
obviously explained when I look at the help screen.

Thanks for your help.
-- 
Bob Ford                            Voice:(814)234-8592x36
INTERNET: astph!bob@attmail.com     UUCP: attmail.com!astph!bob
Philadelphia Phillies		    FAX:  (814)234-1269

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jun 1993 23:46:37 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Information conveyed by keepalive/timeout (was Re: RFC for keepalives)

In article <1993Jun8.173112.6367@novell.com>, jpoller@novell.com (Jack L. Poller) writes:
> ...
> Now, the application level timeouts:
> ...
> 	* my tcp peer is responding to me, and all of our packet ids
> 	  are in sync
> 	* My application peer/client is alive and responding to me
> ....

You do not know those two points.  You know only that your peer
responded to your application keepalive.  It may be fair to infer the
rest, but it is only an optimistic inference.

Ever have "ayt" work after a telnet session is hung?

> ....
> So we have four possible 'states', and each conveys a completely 
> different set of information.  Now, with a little bit of creative
> inter-process communication information that the protocol can
> determine (link level information) can be communicated to the
> application.  And vice-versa, application level information can
> likewise be communicated to the protocol stack.  But in no way are
> the data points the same.

I agree that an application-to-application probe conveys more
information than an appplication-to-remote-system probe (i.e. kernel
keepalives).

However, there is no law that prohibits applications from using UDP or
other means to probe.  Once you allow the applications out-of-band
probing, the application probing becomes a strict superset of
kernel in-band TCP keepalives.


> I will make the following conclusions:
> 	* Application level timers and keepalives do *not* convey the
> 	  same information that protocol/link level timers and
> 	  keepalives convey.
> 	* Link level timers/keepalives are useful and provide
> 	  link level information.
> 	* Application level timers/keepalives are useful and provide
> 	  application level information.
> 	* If an application chooses to use a link level
> 	  timer/keepalive, the application is doing so for only two
> 	  reasons:
> 	    A. The application wishes to know link-level information
> 	    or 
> 	    B. The application developers wish to piggy back off of
> 	       the link level code, and not develop their own.

I agree with all of that, except that application keepalives
can convey a stricy superset.


> Now, having dealt with the subject at hand, I will touch upon your
> 'aside' attack on that which you consider is faulty organization of
> software.
> 
> => Of course, there is nothing that kernel keepalives do that cannot be
> => done by the application, but that applies to all parts of an operating
> => system not related to resource allocation or "security."  Some of us do
> => not think DOS is a good way to organize software.  Some of us think it
> => makes sense to put more than the program loader and most primitive file
> => system into the "operating system" (including libraries or MACH's or
> => Multix).
> 
> I question why this paragraph is present in this discussion.  Is this
> an attack against Don Provan?  Against Novell?  Against Microsoft? 
> Regardless, I feel I must address your implicit attacks, and equally implicit
> emphasis on the superiority of Unix/TCP/IP.
> 
> There will come a time when you will realize that software mimicks
> hardware.  Just as in hardware, where there exists no perfect
> solution, in software, all solutions are compromises.  Even the
> perfect technical solution will have an imperfect implementation
> because of time/cost/manpower compromises.
> 
> Unix is not the be-all end-all O/S.  NetWare is not the be-all end-all
> O/S.  Likewise DOS/Windows/OS-2/VMS/MVS/ITOS .....  Each is a solution
> to a particular problem.  Some are more general purpose than others.
> Some are very specific in nature.
> 
> TCP/IP is not the be-all end-all communications protocol.  IPX is not
> the be-all end-all communications protocol.  Neither is
> OSI/SNA/X.25/....  Each is a solution to a particular problem.  Some
> are more general purpose than others.  Some are very specific in
> nature.
> 
> The time to realize this is now.


Why do I keep pointing out the DOS orientation I see?  Because those
who have it do not see it.

Why do you take my attack on DOS personally?  How should I know or care
whether or not you have a personal or ego investment in DOS?

Of course UNIX is not the end.  It's about 10 years farther along than
program loaders (1965 instead of 1955), but it is showing its age.
30 years is, or should have been, a long, long time on operating system
years.  (Yes, I know UNIX was after 1965, but much of its novelty was in
what it did not have.)

The DOS blindness permeates much of what is written by many people.
Applications fail differently with real operating systems than with
DOS.  The failure modes with operating systems tend to be more
complicated, but somewhat more benign.  (I think a dead application is
more benign than having to press CTRL-ALT-DEL or the red button.)  I
have the gut feeling that keepalives tell you more when you have a real
operating system, if only because you have more than a TSR sitting
around ready to answer as if the application were healthy.  On the
other hand, with DOS, if the application dies, chances are fair even
the interrupt vectors are hosed and the TSR won't be able to answer.

Why do I keep writing about "DOS" and "real operating systems" and
others, include you, write about "DOS" and "UNIX"?  I'm not talking
only about UNIX; most of my career has had nothing to do with UNIX
(not suprising given my age).  No one who knows that an operating
system is confuses DOS with one.  DOS is not bad at what it is.  DOS is
better than CP/M or ISIS.  That does not make DOS into an operating
system.

I've been told Don Proven knows about TOPS-10 or TOPS-20.  Ask him to
compare a real operating system to DOS.

I suspect one of the reasons those who run DOS so dislike keepalives is
that they are more difficult to implement.  DOS telnet, rlogin, etc
servers are more difficult to implement than in a real system.  What
you do with in such a server when a keepalive goes off is yet another
complication.

(Of course, many who dislike keepalives would never run DOS or think
DOS is an operating system.)


Vernon Schryver, vjs@sgi.com

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Jun 1993 23:52:03 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <1993Jun8.173044.28294@gordian.com>, mike@gordian.com (Michael A. Thomas) writes:
> ...
> >  On the other hand, the state of the connection
> > does not reliably indicate the state of the end-to-end communication
> > path between the two applications.  For example, one peer could be dead
> > even though its TCP/IP socket continues to respond to keepalives.
> 
>   Come now, this is a pathological situation and hardly the norm.


That's my gut feeling as well, based on several years experience with
4.3BSD TCP/IP.  If anything, you're understating the exceptional nature
of such failures.  If anything, a 4.3BSD UNIX application is as likely
to keep on answering application level keepalives than to just go dead
in a way that keeps its sockets open and so keeps keepalives ticking.

However, people at Novell continue to raise that point.  So, is it
common for DOS TCP/IP applications to fail in this fashion?  Where
TCP keepalives report things are fine, but the application is kaput?


Vernon Schryver,  vjs@sgi.com

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Jun 1993 00:27:44 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <8JUN199312090327@spades.aces.com>, gavron@spades.aces.com (Ehud Gavron) writes:
>
> One use we have for keepalives is that we have unidirectional laboratory
> instruments connected to terminal server ports and via TCP/IP to ptys on
> Unix hosts.
> 
> It is imperative for our host to know if the terminal server has rebooted
> or power-cycled so that it can reestablish the connection to the particular
> port.  The instrument does not respond to commands, and only sends data
> when it has some -- thus an application level timeout is inappropriate,
> and an application level probe is ineffectual.
> 
> The keepalives as implemented in TCP on the terminal server and the host
> is what makes the whole thing work correctly.  I encourage anyone to point
> me at other such transparent solutions.


Please re-read what this person has written.

It's no doubt obvious that it could have been implemented using
application probes, possibly putting better code on the terminal
server, and possibly new firmware for the instruments.  I would have
used UDP (less overall connection state), a bunch of timers, select(2),
and so on without even considering keepalives, even if they were not
stuck at 2 hours.  The whole package, including a hand-rolled terminal
server sounds like less than 3-6 months for one good person.

However, this person is not interested in hacking network code for the
pure fun of it.  System facilities that handle some boring, ugly stuff
in a way that is good enough, but not as good as the obvious custom
code is of real value.

For crying out loud!  Pty's are being used.  (one of my many irritants
is the inappropriate use of pty's--never mind who wrote SGI's pty code.)


Vernon Schryver,  vjs@sgi.com

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Jun 1993 00:37:20 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <1v2o37$i8t@pyrnova.mis.pyramid.com>, lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:
> ...
>     And I'd much rather trust the TCP implementors to provide this
>     type of function in a reasonable, reliable, low-overhead manner
>     than the applications implementors...who really shouldn't need
>     to be bothered with such networking-specific trivia. 


Exactly right.

My flight simulator example is completely real and not solitary, as is
no doubt obvious from my address.

You wouldn't guess how many times I've found it necessary to explain
incredibly deep subjects (sarcasm alert) like how to use select() to
handle graphics and network stuff at the same time to people
implementing flight simulators at major airline makers and government
aireospace agencies.

Those people seem to have other things to spend their thoughts on than
implementing the rudiments of a scheduler--which is what is needed to
both keep painting pictures in synchrony with other machines and to
know that the painting is syncrhonized and alive.  You really don't want
the picture to freeze; instead you want a message to the "pilot"
saying the system is sick.

It's much simpler to just try to keep up, and paint whatever comes over
the wire.

Of course you or I would always build in dead-server detectors, but I
and probably you don't build simulators for a living.

Of course, SGI's 4.3BSD TCP only does 2 hour keepalives.  We've long
known that's a bug, but have long had more pressing worries.



Vernon Schryver,  vjs@sgi.com

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 1993 08:18 MST
From:      gavron@vesta.sunquest.com (Ehud Gavron)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <idva05s@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes...
#In article <8JUN199312090327@spades.aces.com>, gavron@spades.aces.com (Ehud Gavron) writes:
#>
#> One use we have for keepalives is that we have unidirectional laboratory
#> instruments connected to terminal server ports and via TCP/IP to ptys on
#> Unix hosts.
#> 
#> It is imperative for our host to know if the terminal server has rebooted
#> or power-cycled so that it can reestablish the connection to the particular
#> port.  The instrument does not respond to commands, and only sends data
#> when it has some -- thus an application level timeout is inappropriate,
#> and an application level probe is ineffectual.
#> 
#> The keepalives as implemented in TCP on the terminal server and the host
#> is what makes the whole thing work correctly.  I encourage anyone to point
#> me at other such transparent solutions.
# 
# 
#It's no doubt obvious that it could have been implemented using
#application probes, possibly putting better code on the terminal
#server, and possibly new firmware for the instruments.
	
	It "could have" but then IP "could have" had large
	addresses, and we "could have" elected a good president.

#System facilities that handle some boring, ugly stuff
#in a way that is good enough, but not as good as the obvious custom
#code is of real value.

	Yes!

#Vernon Schryver,  vjs@sgi.com

	Ehud

--
Ehud Gavron        (EG76)     
gavron@vesta.sunquest.com

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Jun 1993 02:36:05 GMT
From:      johnl@iecc.cambridge.ma.us (John R. Levine)
To:        comp.unix.pc-clone.32bit,comp.protocols.tcp-ip
Subject:   Terrible ISC TCP/IP 1.3 performance problems

I'm running ISC UNIX 3.0.1 with TCP/IP 1.3.  Recently, I attached my home
network to the Internet via a pair of PCs running PCROUTE, connected by a
wireless LAN.  (The other PC is at a friend's house, where there's a 56K
leased line to the outside world.)  The wireless lan is near the limit of
its range, so it loses some packets.  I will put in better antennas to
improve that, but there is of course still packet loss elsewhere in the net.

The problem is that ISC's TCP seems totally unable to cope with packet loss.
An xterm or rlogin session will perk right along, then suddenly it hangs.
Netstat always shows that there is some stuff queued up on the send queue,
but it can take minutes to get send, usually so long that the other end
gives up and assumes we're dead.  The other end of these connections are
at the computers at the friend's house, one of which is an old RT PC running
ACIS BSD Unix and the other is a Sun.  My suspicion is that most ISC Unix
systems are on Ethernets which are always fast and never lose packets.

Does this sound at all familiar?  Is there any way to tweak the timers in
TCP?  Is there are newer or repaired version of ISC TCP?

If you want to see the problem for yourself, FTP to chico.iecc.com, log in
as anonymous, and try to retrieve something.

-- 
John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 492 3869
johnl@iecc.cambridge.ma.us, {ima|spdcc|world}!iecc!johnl
"Time is Money!  Steal some today!"

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 1993 17:11:09 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <idup8rs@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>
>However, people at Novell continue to raise that point.  So, is it
>common for DOS TCP/IP applications to fail in this fashion?  Where
>TCP keepalives report things are fine, but the application is kaput?

  That has not been my experience.  I have a couple of these in work
  right now.  One is a sql type socket between a database front-end
  in DOS and the back-end in UNIX.  

  The other is a [creative misuse of, IMHO] application using the
  rlogin socket between DOS and Unix.

  In both instances, a tcp keepalive fails...the [application using
  the] socket itself has appeared to have taken a nap or gone to the
  great bit-bucket in the sky.  

  However, a PING to the icmp layers of the DOS machine from Unix
  does get a echo response.              

  The FTP code is from two different vendors, and there doesn't
  appear to be anything wrong with it.  


>
>
>Vernon Schryver,  vjs@sgi.com



-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 1993 06:19:12 GMT
From:      ckfoong@iss.nus.sg (Foong Chhe Khoing - fair)
To:        comp.protocols.tcp-ip
Subject:   PCTCP enquiry?

 I need to do a communication link from Unix (Silicon Graphic Machine) to PC.
I try to use PCTCP Developing Kit(version 2.04). However this software only supports Microsofti C  compiler. It only supports Borlan C and Turbo C++ compilers with some modifications to the software. I do not know what are the modifications. If anyone who know about the modifications, please mail me the solution. I need the help urgently. Thank You.
 In addition, I like to know whether the new version of PCTCP Developing Kit supports Borlan C and Turbo C++.
 

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Jun 1993 09:26:14 GMT
From:      schwartz@latour.cs.colorado.edu (Mike Schwartz)
To:        comp.protocols.tcp-ip
Subject:   Re: Searching for hosts on a network.

In article <1261@felix.Sublink.Org> eb@felix.Sublink.Org (Enrico Badella) writes:
>Lately I was discussing with a friend a way of discovering all the host on 
>a network; we came up with the idea of using ping and instead of 
>specifying the host name use network_address.255...

Broadcast pings have at least 2 problems:
        - too many hosts can respond at once, causing collisions and lost
          responses.  I have seen 50% of the host responses lost on our
          networks
        - they can cause broadcast storms in some situations

The University of Colorado Fremont system uses a careful form of
broadcast ping, as well as a number of other mechanisms, to discover the
hosts in a network (plus other information about the network).

The Fremont source code is available by anonymous FTP from
ftp.cs.colorado.edu, in the directory pub/cs/distribs/fremont.
 - Mike Schwartz
   Dept. of Computer Science
   Univ. of Colorado - Boulder

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Jun 1993 09:31:48 GMT
From:      david@osi.curtin.edu.au (David Taylor)
To:        comp.protocols.tcp-ip
Subject:   PC Networking Software for OSI ?

Does anyone know of any software, public domain, commercial or otherwise, that
will provide an OSI transport level 4 stack capability on a PC running either 
DOS or Windows ?

I am looking for the equivalent of TCP/IP+NFS with OSI support.

Any ideas would be of interest. Please e-mail my on david@osi.curtin.edu.au.

Thanks in advance.




-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Wed, 09 Jun 1993 15:43:48
From:      jbvb@lard.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: PCTCP enquiry?

In article <1v3vd0$a7q@nuscc.nus.sg> ckfoong@iss.nus.sg (Foong Chhe Khoing - fair) writes:

    ...I like to know whether the new version of PCTCP Developing Kit
    supports Borlan C and Turbo C++.

V2.21 (currently in production) of the PC/TCP Development Kit supports
Microsoft C v6, 7 and 8, and Borland C v3.0 and 3.1.

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


-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Jun 1993 12:48:39 GMT
From:      jfjr@mbunix.mitre.org (Freedman)
To:        comp.protocols.tcp-ip
Subject:   Re: PC Networking Software for OSI ?

In article <david.739618308@osi> david@osi.curtin.edu.au (David Taylor) writes:
>Does anyone know of any software, public domain, commercial or otherwise, that
>will provide an OSI transport level 4 stack capability on a PC running either 
>DOS or Windows ?
>
>I am looking for the equivalent of TCP/IP+NFS with OSI support.
>
>Any ideas would be of interest. Please e-mail my on david@osi.curtin.edu.au.
>
>Thanks in advance.
>
    I believe ther is a company called Emerging Technologies,Inc from
somewhere in New York state (I have some xeroxed documentation but no
address on it) might have something for you

                                  Jerry Freedman,Jr



-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Jun 1993 13:40:19 GMT
From:      CDLatham@cen.ex.ac.uk (C.D.Latham)
To:        comp.protocols.tcp-ip,comp.sys.acorn.tech
Subject:   Is a pre-login banner for ftp `legal'?

The subject says it all really, but the problem in a little more
detail is this.  I have an Acorn A5000 computer running RISC OS 3 and
the Acorn TCP/IP suite.  The University Computer Unit here at Exeter
puts a vast banner, which basically says unauthorised use is
prohibited, *before* the ftp login prompt.  My little personal
computer can't cope with this and ftp crashes.  Without the banner
it all works nicely.  Large messages after login are alright too.

Can anyone please tell me if a pre-login banner is permitted in the
ftp protocol?  (I looked for an FAQ list for comp.protocols.tcp-ip,
but couldn't find one.)

To see the banner do "ftp cen.exeter.ac.uk".  Please email direct
and I'll post a summary to comp.protocols.tcp-ip.

Thanks,

Christopher.                        C.D.Latham@exeter.ac.uk


-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Jun 1993 14:27:21 GMT
From:      hughes@logos.ucs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <idup8rs@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
|> However, people at Novell continue to raise that point.  So, is it
|> common for DOS TCP/IP applications to fail in this fashion?  Where
|> TCP keepalives report things are fine, but the application is kaput?

Not in my experience.  However, it is common in our environment
(university campus) that many PCs and Macs crash semi-regularly
for various reasons (i.e. they're running MS-Windows and MacOS,
respectively :-), and that many users frequently reboot their
machines or just turn them off when they feel like it.

This results in a lot of half-open connections to our timesharing
hosts (UNIX and VMS alike).

In an environment like ours, where the average timesharing login
session is about 20 minutes (and we have about 10,000 logins per
day), keepalives are one of the things that help us stay sane.
Without them, we'd have to reboot the machines on a daily basis,
to free the phantom process slots.

In fact, we've set the keepalives to 15 minutes (down from the
normal 2 hours) and are quite pleased with the results.

 //==================================================================\\
||      Larry J. Hughes, Jr.       |        hughes@indiana.edu        || 
||       Indiana University        | "The person who knows everything ||
||  University Computing Services  |        has a lot to learn."      ||
 \\===================================================================//

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Jun 1993 15:00:42 GMT
From:      hughes@logos.ucs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   new pop3 rfc1460

I'm curious what implementors of POP3 clients and servers think
about RFC1460 (June 1993), in particular the APOP option.

Will you implement, or not?  If so, how will you implement the
shared secret database on the server side?

As co-author of a pop3 server (iupop3 for vms), I'm considering
something semi-standard like DES-encrypting the database of
passwords.  Any better ideas?  I've even thought about doing an
encrypted Kerberos transaction to a password server (using
mutual authentication of course), but Kerberos isn't yet prevalent
enough for this approach to work for all or even most sites.

Also, the RFC mentions APOP is "operational use in at least three 
implementations" but does not mention the implementations.  Does
anybody know what/where they are?

 //==================================================================\\
||      Larry J. Hughes, Jr.       |        hughes@indiana.edu        || 
||       Indiana University        | "The person who knows everything ||
||  University Computing Services  |        has a lot to learn."      ||
 \\===================================================================//

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 1993 15:59:41 GMT
From:      spurgeon@ccwf.cc.utexas.edu (Charles Spurgeon)
To:        comp.protocols.tcp-ip
Subject:   Announcing: Rev 4.0, Network Reading List

A new version of the document "Network Reading List: TCP/IP, UNIX, and
Ethernet" is now available from the Network Information Center at the
University of Texas at Austin. 

The list may be found on host ftp.utexas.edu (128.83.185.16).  This is
version 4.0 of the reading list, dated June, 1993.

-- What is it? --

The network reading list is an annotated list of books and other
resources focusing on three networking technologies that are in wide
use: TCP/IP, UNIX, and Ethernet.  A mix of resources is presented
ranging from introductory information to in-depth technical details.

Version 4.0 of the list has been completely rewritten and updated, and
now includes over 80 items.  The list is weighted towards resources
that cover the territory well, and that deal with real-world problems
found on growing networks.  A copy of the table of contents is
included below.

-- How do I get a copy? --

You can retrieve a copy of the list in either PostScript format or as
a plain ASCII text file.  The PostScript format is recommended.  

Copies of the list may be retrieved using anonymous FTP or a
mail-based archive server program.  

-- Via FTP --

The hostname for anonymous FTP is ftp.utexas.edu, and the files are in
the pub/netinfo/docs and pub/netinfo/ps directories as net-read.txt
and net-read.ps respectively.  

-- Via Electronic Mail --

The address of the archive server program is
"archive-server@ftp.utexas.edu". You can retrieve copies of the list
by sending the archive server program a command line in the body of an
electronic mail message.  The command line:

send ps net-read.ps

will cause the archive server program to send you a copy of the
PostScript file, while the command line:

send docs net-read.txt

will retrieve the ASCII text file.  The command line should be placed in
the body of an mail message sent to archive-server@ftp.utexas.edu.
The archive server is just a simple program, so make sure to send the
command line exactly as shown here. 

NOTE!  Due to slow links and other problems some mailers will not
accept files larger than 100KB.  The PostScript version of the reading
list is over 260KB, and the text version is approximately 154K.

If your mailer limits the size of files, you can get around this
limitation by retrieving the following files:

docs: net-read-1.txt, net-read-2.txt

ps: net-read-1.ps, net-read-2.ps, net-read-3.ps

All of these files are smaller than 100KB.  You will have to use an
editor to restore the PostScript files to one large file in order to
get the correct output on a PostScript printer.

-- Table of Contents --

Section 1 -- TCP/IP
Guides To The Internet ................................  1.1
Electronic Mail and the Internet ......................  1.2
TCP/IP Network Administration .........................  1.3
The Request for Comments (RFCs) .......................  1.4
Some Useful RFCs ......................................1.4.1
Electronic Mail and FTP Access to the RFCs ............1.4.2
Hard Copies of the RFCs ...............................1.4.3
Internet Registration Service .........................  1.5
Other InterNIC Services ...............................  1.6
TCP/IP Protocols ......................................  1.7

Section 2 -- UNIX
UNIX In General .......................................  2.1
UNIX Security .........................................  2.2
UNIX Networking In Detail .............................  2.3

Section 3 -- Ethernet
Introduction  To LAN Concepts .........................  3.1
Introduction to Three Ethernet Varieties ..............  3.2
Vendor Guides .........................................  3.3
Hewlett-Packard Manuals ...............................3.3.1
DEC Manuals ...........................................3.3.2
MOD-TAP ...............................................3.3.3
Ethernet Hardware and Vendors .........................  3.4
Network and LAN Troubleshooting Guides ................  3.5
Ethernet Standards ....................................  3.6
The DIX Standard ......................................3.6.1
The  IEEE 802.3 Standard (ISO 8802.3) .................3.6.2
Twisted-Pair Ethernet Specifications ..................3.6.3
Ethernet Numbers ......................................  3.7
Ethernet Performance Analysis .........................  3.8

Section  4  --  Interest  Groups,  Periodicals,  and
                Conferences
Interest Groups .......................................  4.1
BITNET ................................................4.1.2
Usenet Groups .........................................4.1.3
Periodicals ...........................................  4.2
Conferences ...........................................  4.3
Access to the Internet ................................  4.4
Access to Resources ...................................  4.5


-- 

Charles Spurgeon		Computation Center Networking Services
c.spurgeon@utexas.edu		University of Texas at Austin
(512) 471-3241 ex 265		Room COM1, Austin TX 78712

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Jun 1993 17:07:58 GMT
From:      cornutt@lambda.msfc.nasa.gov (David Cornutt)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Why we need OSI

ag129@ucs.cam.ac.uk writes:

>In article <C891zn.7v3@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
>> Understand that the Internet is by far the largest 
>>operational network the world has ever seen
 
>The telephone network is larger by many orders of magnitude.  

True, but a large percentage (30%?  50%?) of the telephone network's
bandwidth is lying around unused at any given moment...

>It is probably not misrepresenting OSI to say that it is based on
>extending successful telephone network principles to data networks.

This I agree with totally -- and this is much of the problem.  They
aren't the same thing.  Telephony principles simply do not lend
themselves that well to packet networks.  But more to the point, the
*people* involved haven't demonstrated (at least not to my satisfaction)
an appreciation of packet networking principles.  (As an example, look
at what some RBOCs are planning to charge for sending packets over the
D-channel on an ISDN basic rate link.  It would cost you hundreds, maybe
thousands, of dollars for one night's worth of Usenet feed.) 

But enough philosophical stuff.  I can give you one very practical,
hard-nosed reason why OSI hasn't taken off in the marketplace.
Say that you are running a small software house, and you are looking
at developing network apps.  Consider:

OSI standards are copyrighted and are very expensive.
TCP/IP standards are free.

Nuff said.

-- 
David Cornutt, New Technology Inc., Huntsville, AL  (205) 461-4517
(cornutt@lambda.msfc.nasa.gov; some insane route applies)
"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 93 17:23:01 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <C8CytM.vp@usenet.ucs.indiana.edu>, hughes@logos.ucs.indiana.edu (larry hughes) writes:
> ...
> In fact, we've set the keepalives to 15 minutes (down from the
> normal 2 hours) and are quite pleased with the results.

Someone will probably scream about the terrible waste of bandwidth that
implies, so let's do some arithmetic.  I know nothing of the number of
servers involved, but upper bounds can be picked:

    Assume Mr. Hughes has 100 VMS and UNIX timesharing servers,
    and each supports 1000 simultaneous sessions.  (Both numbers
    are probably 10 times too high.)  That's a total of 100,000
    simultaneous sessions, which sounds kind of high for a single
    university, but who knows?  Maybe he also supports some junior
    colleges and k-through-12's.

    That means he is adding 200,000 40 byte TCP/IP packets to his
    internetwork every 15 minutes (one keepalive and one response
    per session per 15 minutes).  Assume he's running Ethernet instead
    of IBM Token Ring or FDDI to get largest physical packet size of 64
    bytes.  (It would be 58 but for the minimum packet size.)

    That is 222 packets/second, or about 1.1% of a single ethernet.

    Ignoring the MAC overhead, that is 8880 bytes of TCP/IP per second.


Assume there are 10,000,000 simultaneous telnet, ftp, and rlogin sessions 
in the Internet, which sounds like about the right order of magnitude.
Even if all of them used 15 minute keepalives, they would be wasting
only half of a single ethernet.

There are a lot of seconds in 15 minutes and a lot of packets in a second.

I agree that 15 minutes is too frequent for a switched line.  60
seconds of connect time every 15 minutes is only a 7% duty cycle, but
amounts to as much as $1.00/day in the U.S. (for a switched <= 64Kb/s line).
I'd rather see an exponenial backoff, starting at ~ 5 minutes and
growing to ~1440 minutes or 1 day.


Vernon Schryver, vjs@sgi.com

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 1993 19:09:46 GMT
From:      gsteckel@harpoon.East.Sun.COM (Geoff Steckel - Sun BOS Hardware CONTRACTOR)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Why we need OSI

In article <1993Jun9.170758.2013@lambda.msfc.nasa.gov>
cornutt@lambda.msfc.nasa.gov (David Cornutt) writes:
>ag129@ucs.cam.ac.uk writes:
>>In article <C891zn.7v3@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
>>> Understand that the Internet is by far the largest 
>>>operational network the world has ever seen
>>The telephone network is larger by many orders of magnitude.  

There's a terminology disfunction here - the telephone network is
a (relatively) homogenous net run by a (relatively) small number
of controlling entities.  The INTERnet is an INTERnetwork of networks.
It is an extremely inhomogenous network with each section run by
many different entities.

The OSI/ISO stack reflects the bias of the telephone company.
Most of the world's telephone companies are still government entities
with government attitudes.  They don't comprehend the idea of
peer-to-peer cooperative networking in a uncaring-to-hostile
environment.

They expect to own and control naming, routing, bandwidth allocation,
billing, etc.  All of these _hard_ networking problems are not
dealt with adequately (or weren't the last time I looked a year
or so ago).  The OSI concept of INTERnetworking is very deficient.

The TCP/IP family _had_ to address all of these problems (except
billing, thank Murphy!) from very early days.  The solutions are
a bit dated, but have been continuously updated.
The gateway protocols, ICMP redirects, etc. of this family are
an example.

>>It is probably not misrepresenting OSI to say that it is based on
>>extending successful telephone network principles to data networks.
>
>This I agree with totally -- and this is much of the problem.  They
>aren't the same thing.  Telephony principles simply do not lend
>themselves that well to packet networks.  But more to the point, the
>*people* involved haven't demonstrated (at least not to my satisfaction)
>an appreciation of packet networking principles.  (As an example, look

Agreed.  Telco people (I've talked with a number of NYNEX people here,
for example) do not comprehend data networking.  The concept of a
user level error recovery other than hanging up & trying again hurts
their heads, for instance.  The concept that any undetected
end-to-end error rate other than zero is intolerable, but a high
detected error rate and variable delay is tolerable and correctable
is another difficult one.

Despite what OSI/ISO folks _say_, the concept of a human-to-human
voice conversation over a government owned and controlled network
still seems to be their model.
-- 
	geoff steckel (gwes@trilobyte.com, gwes@wjh12.harvard.EDU)
Disclaimer: I am not affiliated with Sun Microsystems, despite the From: line.
This posting is entirely the author's responsibility.

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Jun 1993 19:58:42 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Information conveyed by keepalive/timeout (was Re: RFC for keepalives)

> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>
>Why do I keep writing about "DOS" and "real operating systems" and
>others, include you, write about "DOS" and "UNIX"?  
>...
>DOS telnet, rlogin, etc
>servers are more difficult to implement than in a real system.


I'll bite on that one.  I wrote a simple DOS TELNET server on a rainy 
weekend a few years ago.  Periodically we still see people writing about
it on this group so I'll suppose that it's not unknown.

My network and session code was 15,416 bytes of C compared with 
27,168 bytes in the BSD 4.3 version.  So the length is comparable.

Maybe I'm just brilliant, but I didn't think the network part was terribly 
hard to do.  Maybe you are referring to the lack of termcap facility, but
that has little to do with this group and is very dated to text-only
applications - hardly a great basis for separating operating systems
from the scrap pile.

Erick

-- 


-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Jun 1993 21:28:54 GMT
From:      bossert@claircom.com (John Bossert)
To:        comp.protocols.tcp-ip
Subject:   rarpd for SVR4

Does anyone have a version of rarpd (Reverse ARP daemon) that will
run under SVR4?  Using Streams?

Alternatively, could someone take me by the hand and explain:

1) Is there a specific socket(oops!)/port rarpd should use?

2) How do I filter all NON-RARP packets from my application?

It's been *several* years since I wrote any Berkeley-style networking code.
Code_Samples would be greatly appreciated.

Please e-mail and I'll redistribute to anyone else interested...

        John Bossert
        bossert@claircom.com
        +1 206.389.7157

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Wed, 09 Jun 1993 21:38:42 GMT
From:      palvarez@daniel.conicyt.cl (Pablo Alvarez G.)
To:        comp.protocols.tcp-ip
Subject:   TELNET for SYSV  R4

I'm need the program source telnet to unix sysv r4, NCR3000 machine.

Any information please send me via e-mail to:

Pablo Alvarez Gonzalez
palvarez@daniel.conicyt.cl


-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 1993 22:09:53 GMT
From:      ctw@aero.org (Charles Wolverton)
To:        comp.protocols.tcp-ip
Subject:   OSI stack perf. over a WAN

Any suggestions for a starting point reference that addresses the
performance (bandwidth efficiency, etc.) of OSI upper layers over a "high
speed" (the higher the better) datalink layer, either absolute or compared
to TCP/IP et. al. ??

Tnx - chas

Charles T. Wolverton                  The Aerospace Corporation
Information Technology Department     P.O. Box 92957 MS M1-107
Ph. 310.336.0354                      Los Angeles, CA 90009
FAX 310.336.5833                      ctw@aero.org

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 1993 22:23:21 GMT
From:      kusuma@delphi.umd.edu (Nono Kusuma)
To:        comp.protocols.tcp-ip
Subject:   HELP: Build On-line Info Server


OBJECTIVE: To build On-line Physics Lecture Demonstration Interactive
Database (hypercard like) which can be accessed from network PC and
Mac (at least) and maybe Dec station.

DATABASE SIZE and CONTENT:
*1,500 Physics demonstrations
* Four cards per demonstration
* One to two (mostly one) grayscale photo per demonstration
   photo size: approximately 3/4 of 14inch screen size
   photo quality (minimum): 16level grayscale, Mac and VGA display
* Cross referencing between Demonstration and indexing for the
   whole content will be used heavily

TYPE OF DATA STORAGE USED IN SERVER:
Since every demonstration will have a size of approximately 500K
to 700K, the whole documentation will mount up to 1,200 MB.
-----OPTION:
*2gig SCSI-2 hard drive for the multi protocol server.
*Put everything in the CD-ROM (ISO format) for further distribution

INFO NEEDED FROM YOU ALL: If you can only answer one or two question
below, please do so - I still need your expertise (badly)

MULTIPLATFORM DATA BASE:
*My only option is to use FrameMaker and FrameViewer (multiplatform=
  Unix, Macintosh and MS-Window.  FrameMaker has build in hypertext to
  navigate through its long document with full crossreferencing, table of
  content and indexing.  FrameViewer will allow anyone from PC(window),
  Mac and unix station to view (only) and navigate through.  There are many
  corporate giant that use the same system.
*Is there any other software that will do the same or better job?

PHOTO:
*Unit of Frame grabber for the photo recording.  What is the
  best price performance B&W camera(CCD?) and the frame grabber
  card combination that is suitable for grayscale photo recording.
*What is the suitable graphic file format (TIFF?) for multiplatform use

CD-ROM Production:
*Currently I am looking at a new device from PinnacleMicro for MAC
  and PC called Recordable CD Maker ($3,595.00 educational pricing). 
  It supports Mac HFS format and ISO format.  It can also create master
  copy for mass production.
*Is there any other better way (proven technology) to do this?

SERVER PLATFORM:
*We already have DEC server (NFS) running Pathwork and many Macs
  loaded with NFS/Share to access FrameMaker document on the server.
  What would be the option for the PC running window to access the
  FrameMaker document from NFS server.  Do they have NFS/Share
  equivalent for PC that is less complicated than Pathwork for PC.
*Do you have any other suggestion for other platform for the server.
  (maybe 486 machine or Mac).  If yes please specify the detail including
  the multiprotocol server software and the client software on the Mac,
  PC and maybe Dec station.  Preferably one that use TCP/IP so that client
  from outside building can have access too.

PLEASE SEND YOUR SUGGESTIONS DIRECTLY TO MY EMAIL ADDRESS, I DO NOT READ
THIS NEWSGROUP

THANKS,

Nono Kusuma
Illustration Service - Dept. of Physics
University of Maryland @ College Park
____________________________________________________________
Treat others as you would like to be treated - Jesus Christ

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 01:06:47 GMT
From:      ggm@brolga.cc.uq.oz.au (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   Re: PC Networking Software for OSI ?

In article <david.739618308@osi> david@osi.curtin.edu.au (David Taylor) writes:
>Does anyone know of any software, public domain, commercial or otherwise, that
>will provide an OSI transport level 4 stack capability on a PC running either 
>DOS or Windows ?

Edinburgh University developed an OSI stack for PC's under a JANET grant.
Its not freely available but may be licencable. (if it IS freely available
they certainly aren't trumpeting it...)

try ?@*.ed.ac.uk. people...

-George
--
                         George Michaelson
G.Michaelson@cc.uq.oz.au The Prentice Centre      | There's no  market for
                         University of Queensland | hippos in Philadelphia
Phone: +61 7 365 4079    QLD Australia 4072       |          -Bertold Brecht

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 93 01:07:23 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: Searching for hosts on a network.

In Article <1993Jun10.114916.32220@clam.com>
krodgers@steamer.clam.com (Kevin Rodgers) writes:

>I'm fairly positive that sending replies to broascast ICMP ECHO
>resuests (pings) are an optional part of the internet RFC. This means
>that the above method only works if the host or device support sending
>replies to broadcast ICMP ECHO requests.

You better go back to the bookshelf. RFC-1122, Internet Host Requirements,
Section 3.2.2.6:

"Every host MUST implement an ICMP Echo server function that receives Echo
Requests and sends corresponding Echo Replies."

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov		(510) 422-6955

Disclaimer: Being a know-it-all isn't easy. It's especially tough when you
don't know that much. But I'll keep trying. (Both)

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 1993 13:45:40 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   FTP Software Telnet and MS Windows performance???? !!!!!

Does anyone out there have direct experience or fixes for running
FTP Software's Telnet through a MS Windows 3.1x window?
It appears that the Windows stuff is buffering (for quite some time)
data between the Telnet and the user's screen.  

When run thru Windows, the user (testing echo time) just holds down
a typematic key.  The FIRST character is painted to the window with
undetectable delay.  The rest of the echoe'd characters appear in
small bursts, with delays of 3 seconds between bursts being typical.

The Telnet host sets the Push flag on any retransmission (there are
none) or whenever all buffered writes() are completed...but there is
no correlation with Push and the delay...which is entirely within
the PC. 

There are no delays over a couple milliseconds anywhere in the
Telnet server, the FTP layers in the PC....

If the FTP Telnet is run WITHOUT Windows (directly from DOS),
performance is blisteringly fast--characters appear within
milliseconds.  In other words, it certainly doesn't seem to be an
FTP Software issue.  

Is there some kind of magical option that can tell the Windows
layers to say "excuse me lizardbreath, but would you mind passing this
data to the user's window NOW!!!!???".  




-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 02:58:57 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC, with XDR and NDR

In article <C8DsJ0.2KK@atria.com>, mishkin@atria.com writes:
> In article <1993Jun8.165520.416@turtle.fisher.com> leung@turtle.fisher.com writes:
> >Data Representation of SUN RPC is XDR, while that of Apollo RPC
> >(and OSF DCE RPC) is NDR.
> >
> >1) what are the differences between these two data representation
> >   standards? Are there plans to reconcile the differences by
> >   the responsible parties?
> 
> The protocols are trying to do roughly the same things, although the details
> of the wire encodings are complete different.  I haven't heard of
> anyone trying to reconcile the two....

Well, not since the penultimate (or maybe anti-penultimate) Network
Computing Foundation meeting in Ann Arbor in about May, 1989, when Sun
and Apollo agreed to disagree.

Remember that consortium of practically all computer companies?
The grand unification of NCS and RPC?
In which Apollo was trying to apply Sun's very successful strategy
of "define a protocol, give way the specification and almost give
away an implementation"?


Vernon Schryver,  vjs@sgi.com

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 93 06:40:48 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: Searching for hosts on a network.

In Article <1v7in5$96l@lll-winken.llnl.gov>
oberman@ptavv.llnl.gov writes:
>In Article <1993Jun10.114916.32220@clam.com>
>krodgers@steamer.clam.com (Kevin Rodgers) writes:
>
>>I'm fairly positive that sending replies to broascast ICMP ECHO
>>resuests (pings) are an optional part of the internet RFC. This means
>>that the above method only works if the host or device support sending
>>replies to broadcast ICMP ECHO requests.
>
>You better go back to the bookshelf. RFC-1122, Internet Host Requirements,
>Section 3.2.2.6:
>
>"Every host MUST implement an ICMP Echo server function that receives Echo
>Requests and sends corresponding Echo Replies."

Mea culpa! I must learn to read someday.

Somehow I totally missed the word "broadcast". My apologies to Kevin. He
obviously reads better than I do.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov		(510) 422-6955

Disclaimer: Being a know-it-all isn't easy. It's especially tough when you
don't know that much. But I'll keep trying. (Both)

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 07:44:31 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <idup8rs@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>However, people at Novell continue to raise that point.  So, is it
>common for DOS TCP/IP applications to fail in this fashion?  Where
>TCP keepalives report things are fine, but the application is kaput?

Since the "people at Novell" particpating in this conversation -- you
know, the two you've been bombarding with accusations of DOS bias? --
probably have between us a sum total of 3 days experience developing
DOS software and do not have anything to do with the DOS based Novell
products, a rational person would have a hard time drawing any such
conclusions unless he were intent on doing a little mudslinging.

It takes the simplest of bugs -- say, an infinite loop in the
application -- in UNIX to cause the condition where the kernal
continues to respond to keepalives even though the application is
incapacitated.  That's the type scenerio i was imagining.  I'm not
even sure there's a comparable case under DOS.

					don provan
					donp@novell.com

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 07:48:27 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <idva05s@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>It's no doubt obvious that it could have been implemented using
>application probes, possibly putting better code on the terminal
>server, and possibly new firmware for the instruments.  I would have
>used UDP (less overall connection state), a bunch of timers, select(2),
>and so on without even considering keepalives, even if they were not
>stuck at 2 hours.  The whole package, including a hand-rolled terminal
>server sounds like less than 3-6 months for one good person.

An application to send one byte every N seconds to the standard TCP
discard port on the terminal server.  It'd take 10 minutes to
implement, 12 if you wanted to be able to specify N on the command
line.  And you only send a single packet to check for the failure of
the entire terminal server instead of one for each connection.

						don provan
						donp@novell.com

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 93 13:45:52 EDT
From:      MACE@HDQCMS2H.UTSD.ATT.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Sockets on IBM VM ???

In article <1v4vrj$38n@spock.dis.cccd.edu>
markb@spock.dis.cccd.edu (Mark Bixby) writes:
 
>
>We're embarking on a project to exchange data using Berkeley sockets with a
>remote site running IBM VM.  So I don't remain totally ignorant, could some
>kind IBM-er please give me a _brief_ outline of how sockets is implemented
>under VM?
>
>We used to run VM here, but never got the chance to do sockets.  I suspect
>there's some disconnected server virtual machine that manages the connections,
>and that any other virtual machines wishing to do sockets must communicate with
>the server through something like the IUCV facility?  Yes?  No?
>--
>Mark Bixby                         Internet: markb@cccd.edu
>Coast Community College District   1370 Adams Avenue
>District Information Services      Costa Mesa, CA, USA  92626
>Technical Support                  (714) 432-5064
>"You can tune a file system, but you can't tune a fish." - tunefs(1M)
 
There is a socket API that comes with the VM TCP/IP product, that you
can use with C, PASCAL and Assembler (basically a set of function calls).
 
CUNY has the RXSOCKET REXX function package, which allows you to code
socket applications in REXX (since it's interpreted, it's very fast and
easy to develop an application, then you compile it for production use!).
 
The RXSOCKET package is (I think) available for FTP from ksuvm.ksu.edu,
and works very reliably (the NNR VM newsreader is implemented in REXX
with RXSOCKET).
 
------------------------------------------------------------------------------
Mace Moneta, AT&T VM Product Engineering, Piscataway, NJ - mmoneta@attmail.com
------------------------------------------------------------------------------

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 09:55:32 GMT
From:      ag129@ucs.cam.ac.uk
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Why we need OSI

In article <1993Jun9.170758.2013@lambda.msfc.nasa.gov> cornutt@lambda.msfc.nasa.gov (David Cornutt) writes:
>This I agree with totally -- and this is much of the problem.  They
>aren't the same thing.  Telephony principles simply do not lend
>themselves that well to packet networks.  But more to the point, the
>*people* involved haven't demonstrated (at least not to my satisfaction)
>an appreciation of packet networking principles.  (As an example, look
>at what some RBOCs are planning to charge for sending packets over the
>[IDSN D-channel]

But wouldn't those RBOCs charge you the same rate if those packets
were IP packets over an Ethernet?  And if you bought ISDN from a highly
competitive cable TV company instead, there is nothing to say you 
wouldn't get a much cheaper rate?  (I can buy a phone line from my
local cable TV company, perhaps there is more of a monopoly in other
countries.)

I don't think the Internet has shown much appreciation of those telephony
issues that do apply to data networks, notably tarriffing and interworking
between multiple administrative domains.  I'm not saying OSI's solution is 
perfect but at least it has always been factored in, and is responsible
for some of the perceived 'complexity'.  (If you think the Internet handles
multiple administrative domains, tell me how a country at war with the US
can allocate IP network numbers for itself.) 

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 11:49:16 GMT
From:      krodgers@steamer.clam.com (Kevin Rodgers)
To:        comp.protocols.tcp-ip
Subject:   Re: Searching for hosts on a network.


In article <1261@felix.Sublink.Org>, eb@felix.Sublink.Org (Enrico Badella) writes:
|> Lately I was discussing with a friend a way of discovering all the host on 
|> a network; we came up with the idea of using ping and instead of 
|> specifying the host name use network_address.255. While trying the idea out
|> on a class C network made up of Suns (3 and 4), 386 PC (SCO, ISC, Linux,
|> 386BSD) and no routers, bridges or other devices apparently evry host 
|> answers to the ping. Doing the same trick on a class B network nothing
|> would happen most of the times, once in a while a cisco router would
|> answer.
|> How can this be explained?

I'm fairly positive that sending replies to broascast ICMP ECHO
resuests (pings) are an optional part of the internet RFC. This means
that the above method only works if the host or device support sending
replies to broadcast ICMP ECHO requests.
-- 
Kevin F. Rodgers        |   Internet: krodgers@clam.com
Clam Associates, Inc.   |   Phone: (617) 621-2542
101 Main Street         |   Fax: (617) 252-0820
Cambridge, MA 02142     |   Standard disclaimers apply.

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 14:08:20 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <1993Jun10.074431.16514@novell.com>, donp@novell.com (don provan) writes:
> In article <idup8rs@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> >However, people at Novell continue to raise that point.  So, is it
> >common for DOS TCP/IP applications to fail in this fashion?  Where
> >TCP keepalives report things are fine, but the application is kaput?
> 
> Since the "people at Novell" particpating in this conversation -- you
> know, the two you've been bombarding with accusations of DOS bias? --
> probably have between us a sum total of 3 days experience developing
> DOS software and do not have anything to do with the DOS based Novell
> products, a rational person would have a hard time drawing any such
> conclusions unless he were intent on doing a little mudslinging.
> 
> It takes the simplest of bugs -- say, an infinite loop in the
> application -- in UNIX to cause the condition where the kernal
> continues to respond to keepalives even though the application is
> incapacitated.  That's the type scenerio i was imagining.  I'm not
> even sure there's a comparable case under DOS.
> 
> 					don provan
> 					donp@novell.com


Sheesh.  You don't even allow a polite question.

After repeatedly being told by implication that such failure modes are
common, contrary to my personal experience, I figured you had relevant
information I didn't.  Since Novell products are (I thought) most
commonly used with DOS, and since your colleague was so emphatic about
the wonderfulness of DOS, I made what is evidently an unjustified
inference.  I am not knowledgable about DOS, and figured there was
something about DOS and TCP/IP that I didn't know that would make DOS
TCP/IP applications fail that way.  What is "mud slinging" about that?
Is it an insult to be associated DOS?  I guess I should be careful,
since I've spent more than 3 days hacking on DOS stuff.

Will you allow a rephrasing of the question?

Do you find such failures of applications to be common?  Are there any
common characteristics of these looping or otherwise autistic
applications, whether operating system, implementation language,
purpose, state of completion, or anything else?  Maybe looping
applications would seem more likely with more information.

If a good case were made that (say) 37.2% of a reasonable selection of
application system failures would have been detected by application
peer-to-peer probing by not BSD-style keepalives, then the case for
BSD-style keepalives would be significantly weakened.  Or even "of the
relevant complaints from customers I recall over the last 6 months,
many involved ..."


Vernon Schryver,  vjs@sgi.com

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 14:30:39 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <1993Jun10.074827.16620@novell.com>, donp@novell.com (don provan) writes:
> 
> An application to send one byte every N seconds to the standard TCP
> discard port on the terminal server.  It'd take 10 minutes to
> implement, 12 if you wanted to be able to specify N on the command
> line.  And you only send a single packet to check for the failure of
> the entire terminal server instead of one for each connection.
> 
> 						don provan
> 						donp@novell.com


Good thought, but how is using the discard port for keepalives is
different from using BSD style keepalives?

Using the discard port does 
    -require some application code
	=some socket or TLI stuff that the original author might not
	    otherwise had to understand.  (There was mention of "pty",
	    which makes it sound rather like there was no explicit network
	    code needed.)
	=a small scheduler to stop waiting on data or error indications
	    from the data connections and send the bytes
	=care to ensure that the application doesn't get stuck waiting
	    for output to drain on the discard connection instead
	    of processing incoming data.

    -require the terminal server to implement the discard port, and
	allow long term connections to it.

    -is not an application keepalive, since the "application" is the
	code watching the serial port on the terminal server, not the
	code in the terminal server that handles the TCP discard port.

If probing the discard port fails, you know the terminal server has
crashed or the network is kaput.  If the probe succedes, you know the
terminal server and network are alive, but you do not know if the
instrument has hung up the phone.  If the instrument has hung up,
you're likely to have received the FIN and all is fine.  In that case
you don't need keepalives of any sort.  (There are other obvious
failure modes, but they seem to me too unlikely to worry about.)

Are there reasons to prefer the use of the discard port when BSD
keepalives are available and suitable?

Is a fair summary that if you do not have BSD keepalives or their
timing is inappropriate, then the discard port is a good solution?


Vernon Schryver,  vjs@sgi.com

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 93 21:40:22 PDT
From:      Michel.Davidoff@sonoma.edu (Michel.Davidoff)
To:        comp.protocols.tcp-ip
Subject:   What is a New Bridge dataline multiplexer

What is this ?
What does it do ?

Michel Davidoff
E-Mail Michel.Davidoff@Sonoma.edu

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 14:43:04 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Information conveyed by keepalive/timeout (was Re: RFC for keepalives)

In article <C8DE5v.42E@watserv1.uwaterloo.ca>, erick@sunee.uwaterloo.ca (Erick Engelke) writes:
> ...
> I'll bite on that one.  I wrote a simple DOS TELNET server on a rainy 
> weekend a few years ago.  Periodically we still see people writing about
> it on this group so I'll suppose that it's not unknown.
> 
> My network and session code was 15,416 bytes of C compared with 
> 27,168 bytes in the BSD 4.3 version.  So the length is comparable.
> 
> Maybe I'm just brilliant, but I didn't think the network part was terribly 
> hard to do.  Maybe you are referring to the lack of termcap facility, but
> that has little to do with this group and is very dated to text-only
> applications - hardly a great basis for separating operating systems
> from the scrap pile.


Why do you seem to associate DOS with "scrap pile"?  I didn't.  DOS is
a reasonable program loader with a simple file system.  It's worst
warts are the many layers of backward compatibility, the zillion ways
to do any single system request, but that happens to all successful
software with time.

I don't know much about DOS, but I have the impression that a telnet
server, not a client, is more difficult with DOS because it is
inconvenent to have two command.com's running at once.  Not one started
from within another, but both running at once.  How do you connect the
DOS shell to a TCP port without stopping all other activity on the
machine?  How do you allow clients of you telnet server to use the
machine to do anything normally allowed if you connect the DOS shell to
com1 (i.e. ASCII stuff), and still allow any use of the screen and
keyboard?

You could build your own multitasker--there is some precedent--but that
rather begs the issue.

Let me put it another way, how many simultaneous clients can your
telnet server handle?


Vernon Schryver,  vjs@sgi.com

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 93 15:29:47 GMT
From:      tony@scotty.dccs.upenn.edu (Anthony Olejnik)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Request for FAQ on (commercial) PC TCP/IP implementations

Recently, a FAQ/summary on a number of various DOS/Windows
TCP/IP implementations was sent to these lists (I think).
I didn't save the post and am unable to find it by scanning
the previous articles (that my news server archives). 

Would it be possible for someone to please send it to me?
(I`m sorry to bother the whole group for this request)

Thank you.

--tony

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 1993 15:51:44 GMT
From:      wei@col.hp.com (Bill Ives)
To:        comp.protocols.tcp-ip
Subject:   RFC site??


   Would someone please tell me where a public site for RFCs is ....
   we just lost our internal site due to "streamlining". 

   Thanks in advance.

   Bill Ives
   Hewlett-Packard, Network Test Division.
   Colorado Springs.


-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 16:03:10 GMT
From:      heimlich@watson.ibm.com (Steve Heimlich)
To:        comp.protocols.tcp-ip
Subject:   Re: Searching for hosts on a network.

In article <1v7in5$96l@lll-winken.llnl.gov> oberman@ptavv.llnl.gov writes:
>In Article <1993Jun10.114916.32220@clam.com>
>krodgers@steamer.clam.com (Kevin Rodgers) writes:
>
>>I'm fairly positive that sending replies to broascast ICMP ECHO
>>resuests (pings) are an optional part of the internet RFC. This means
>>that the above method only works if the host or device support sending
>>replies to broadcast ICMP ECHO requests.
>
>You better go back to the bookshelf. RFC-1122, Internet Host Requirements,
>Section 3.2.2.6:
>
>"Every host MUST implement an ICMP Echo server function that receives Echo
>Requests and sends corresponding Echo Replies."

No, you stopped reading too soon.  Kevin is correct.

Steve

         3.2.2.6  Echo Request/Reply: RFC-792

            Every host MUST implement an ICMP Echo server function that
            receives Echo Requests and sends corresponding Echo Replies.
            A host SHOULD also implement an application-layer interface
            for sending an Echo Request and receiving an Echo Reply, for
            diagnostic purposes.

            An ICMP Echo Request destined to an IP broadcast or IP
            multicast address MAY be silently discarded.

            DISCUSSION:
                 This neutral provision results from a passionate debate
                 between those who feel that ICMP Echo to a broadcast
                 address provides a valuable diagnostic capability and
                 those who feel that misuse of this feature can too
                 easily create packet storms.


-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 17:11:40 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Searching for hosts on a network.

In article <1v7in5$96l@lll-winken.llnl.gov>, oberman@ptavv.llnl.gov writes:
> In Article <1993Jun10.114916.32220@clam.com>
> krodgers@steamer.clam.com (Kevin Rodgers) writes:
> 
> >I'm fairly positive that sending replies to broascast ICMP ECHO
> >resuests (pings) are an optional part of the internet RFC. This means
> >that the above method only works if the host or device support sending
> >replies to broadcast ICMP ECHO requests.
> 
> You better go back to the bookshelf. RFC-1122, Internet Host Requirements,
> Section 3.2.2.6:
> 
> "Every host MUST implement an ICMP Echo server function that receives Echo
> Requests and sends corresponding Echo Replies."


The next paragraph bears more directly on the question:

	An ICMP Echo Request destined to an IP broadcast or IP
	multicast address MAY be silently discarded.


I've long been a supporter of ping`ing the broadcast address, or even
flood-pinging it to stress the network, but even I must conceded that
reasonable people might choose to not respond to broadcast ECHO-REQUESTS.  

There are plenty of TCP/IP machines that never respond to broadcast
ECHO-REQUESTS.


Vernon Schryver,  vjs@sgi.com

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 17:30:41 GMT
From:      stuarts@apertus.com (Stuart Stanley)
To:        comp.protocols.tcp-ip
Subject:   Getting a Telnet Option # allocated

We are looking at implementing an addition to a TN3270 telnet session that
would allow a server to function a client in and out of SARTS character
display mode.  The best way would be to use an option negotiation.  What
is the prescribed method for requesting a number.  (I could just see
someone just "grabbing" a number to do something like this... Server: DO SARTS
Client WILL Encrypt....)

On the aside, by chance is this already a known option that I haven't
heard of?  Heaven forbid something could happen this week that would
make my life easier ;)

						Cheers & Thank you
							Stuart
--
 "Alerted Snakes of Consequence" - Pat Cadigan  !    Stuart Stanley
	--Mind Players--			!    stuarts@apertus.com
						!    Apertus Technologies
                             (612)-828-0391    <->   Eden Prairie, Minnesota

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 17:57:50 +0000
From:      c.h.morledge@larc.nasa.gov (Clarke Morledge)
To:        comp.protocols.tcp-ip,comp.windows.x
Subject:   X-terminal lockups - Caused by broadcasts??

I am trying to find some information about X-terminals that lock-up and 
freeze whenever they see a spike of broadcast packets on an ethernet.  Can 
anyone offer some thoughts about any dedicated X-terminal products that show 
this behavior??  In particular, anyone have these problems with Tektronix??

Our situation is that we have a rather large bridged network.  We have an 
FDDI backbone ring with FDDI-to-Ethernet bridges linking the different 
building ethernets together on our campus.  One drawback to this 
configuration is that it makes us very suspectible to problems with broadcast 
and multicast traffic.  Bursts of broadcasts and multicasts go everywhere.

We recently upgraded some of our FDDI-to-Ethernet bridges from Fibronics 
8210's to DEC 500's, which have a higher rate of FDDI-to-Ethernet throughput.  
As a result, we have more broadcast "mini-storms" that are having a greater 
impact on our network.  At the same time, several folks with X-terminals on 
our ethernet segments report that they lock-up whenever one of these 
broadcast spikes hit them.  I am looking for some info that can substantiate 
this claim.

Any help would be greatly appreciated.  Thanks.





-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 18:20:20 GMT
From:      jfjr@mbunix.mitre.org (Freedman)
To:        comp.protocols.tcp-ip
Subject:   NIS login queries



   When an NIS client is accepting a log-in it sends a number of ypmatch 
requests to the NIS server including the expected request for passwd.byname
where the key is the user name. It then steps through all the groups - I can 
sorta see what that is about but it eventually sends a passwd.byuid query. 
    WHY????


                              Jerry Freedman,Jr

PS I guess I am looking for a detailed narrative protocol description.

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 19:12:19 GMT
From:      heka@ppvku.ericsson.se (Hedie Kamoun)
To:        comp.protocols.tcp-ip
Subject:   Status of connection

Hello netters!
	I have a question regarding sockets which I hope some good soul out
there could help me out with.

	I want to be able to check the status on the link between my client
and server process before I do any sending. How can I achieve this with sockets.
I have tried just checking the return value from send, but it turns out it
returns success (i.e non -1 result) even though the connection to the other
process have been terminated. I guess it is reasonable to expect that the 
socket would "stay open" a while after the process have been killed but at the
same time I would have thought the ACK side from the other process wouldn't get
there. So is it possible to derive if the socket is OK to send on by just watching
a combination (which) of errno:s or perhaps the getsockopt() function, or do I
have to wait until the trashed socket "time-outs"?

	Sure would be nice with some help here.
Best Hedie

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 19:38:22 GMT
From:      barker2w@fiu.edu (Warren Barker)
To:        comp.protocols.tcp-ip
Subject:   How can a TCP/IP machine (UNIX) speak DECnet?

Dear Net,

I need to solve a connectivity problem which involves communicating
with a VAX that speaks DECnet.  I have heard of two software products
which supposedly enable this: TSSnet and KineNet (sp?).  Does anyone
have experience with either of these products, or have recommendations
for a better solution?  I know that it is possible to enable the VAX
to speak TCP/IP, but I am constrained to find a solution that does not
depend on altering the VAX system. 

Thanks in advance.

J. Shane Kippenhan, PhD
Mt. Sinai Medical Center
jkippen@newssun.med.miami.edu

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 19:45:35 GMT
From:      brail@bnr.ca (Siva Arunthavanathan)
To:        comp.protocols.tcp-ip
Subject:   Sockets - Where to start?

Hi everyone!

I am just a beginner in the TCP/IP world and I have a big project to do.
I need to intercept a communication between a client (Macintosh) and a
Server (Unix). The reason is to add some functionality before reaching the
Server. The way we decide to do, is to have a socket in between the  client
and the server.

Typical diagram


Mac   ------>   SERVER
      <-----

Modified diagram 


Mac   ------>  SERVER ------> SERVER_ORIG
      <-----   (Ours) <-----  


unfortunately I can't modify or view the source codes for either Mac or the
server. All I know is Mac (software) issusing a request to inetd in the
unix server to run the server(software). inetd runs the server by  issuing
"server TCPIP usrid passwd ip_of_client port_of_client 00000000 0000". Then
it  acknowlege the client about the server and provide the information
about location of the server so that client can connect directly to the
server.
Note :- Modification has to be done in the server side so that we don't
need
to do it for every client. Modification has to be done before data reaching
the Server(original). Modification is done by running a lex (c like) code 
and it will catch the stream of data and replace the appropreate ones. 
How should I start?
any ideas, suggestions, etc!


thanks in advance!
siva arun

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 93 20:11:34 GMT
From:      manne@Minsk.docs.uu.se (Magnus L|vkvist)
To:        comp.protocols.tcp-ip
Subject:   Where can I buy books on TCP/IP?

I'm thinking of buying some books about TCP/IP.

Can anyone recommend a good bookstore in the US from which I can order
books to be delivered to me in Sweden? Phone and fax numbers?

(US books are too expensive here in Sweden)
 

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 21:51:10 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: Where can I buy books on TCP/IP?

manne@Minsk.docs.uu.se (Magnus L|vkvist) writes: 

>I'm thinking of buying some books about TCP/IP.
>
>Can anyone recommend a good bookstore in the US from which I can order
>books to be delivered to me in Sweden? Phone and fax numbers?
>
>(US books are too expensive here in Sweden)

One of the best places in Silicon Valley is Computer Literacy.  From the
Bookmarks they give out is an advertisement which reads:

"NOT IN SILICON VALLEY?
 WE SHIP WORLD WIDE

 ASK FOR FREE NEWSLETTER
 Next day shipment guaranteed on all books in stock"

...so this may be what you're looking for.

Voice Phone (U.S.A.)	408-435-0744

Fax			408-435-1823

E-Mail			info@clbooks.com

Snail-Mail		2950 North First St.
			San Jose, CA (USA)   95131

Fred

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 21:55:53 GMT
From:      evansmp@uhura.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip,comp.sys.acorn.tech
Subject:   Re: Is a pre-login banner for ftp `legal'?

C.D.Latham (CDLatham@cen.ex.ac.uk) wrote:
: The subject says it all really, but the problem in a little more
: detail is this.  I have an Acorn A5000 computer running RISC OS 3 and
: the Acorn TCP/IP suite.  The University Computer Unit here at Exeter
: puts a vast banner, which basically says unauthorised use is
: prohibited, *before* the ftp login prompt.  My little personal
: computer can't cope with this and ftp crashes.  Without the banner
: it all works nicely.  Large messages after login are alright too.

The banner does look somewhat dodgy.
If it had every line prefixed by 220- it might be a bit better.

--
-------------------------------------------------------------------------
Mark Evans                                   |evansmp@uhura.aston.ac.uk
+(44) 21 429 9199  (Home)                    |evansmp@cs.aston.ac.uk
+(44) 21 359 6531 x4039 (Office)             |

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 23:22:22 +0000
From:      martin@wleaf.demon.co.uk (Martin Cockerell)
To:        comp.protocols.tcp-ip
Subject:   Re: Sockets - Where to start?

In article <brail-100693153328@47.201.0.2> brail@bnr.ca writes:

>Hi everyone!
>.......
>.......
>Note :- Modification has to be done in the server side so that we don't
>need
>to do it for every client. Modification has to be done before data reaching
>the Server(original). Modification is done by running a lex (c like) code 
>and it will catch the stream of data and replace the appropreate ones. 
>How should I start?
>any ideas, suggestions, etc!
>
>
>thanks in advance!
>siva arun
>
If you edit the /etc/inetd.conf file - or the equivalent on your system - 
you can define the process which is started for a particular socket 
request from the client.

You can then make inetd run your special script, and pipe the output to 
the real process.

Hope this helps,

Martin
-- 

---------------------------------------------------
Martin Cockerell         - martin@wleaf.demon.co.uk
Whiteleaf Technology Ltd - Compuserve:  100025,2625
Whiteleaf, Bucks., UK    - Voice:  (+44) 844 347482

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 23:39:09 GMT
From:      tannend@source.asset.com (David Tannen)
To:        comp.protocols.tcp-ip
Subject:   PD TCP/IP w/Source

Is there are repository where I can find PD/Shareware
Source code for TCP/IP.  If anyone knows were I can
get the source in Pascal that would be perfect.  Please
send me info via my email address: 
	tannend@source.asset.com

Thanks in advance.

David Tannen
tannend@source.asset.com

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 1993 11:29:00 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS Alternative for Wide Area Networks

In article <930607154148@whip.ftp.com> fks@ftp.com writes:
>
>
>NFS over TCP does exist, but I'm not sure there is a UNIX
>implementation.  The NFS client in version 2.2 of our PC/TCP package
>can use TCP, and TGV makes a TCP NFS server, but I don't know of any
>other currently available implementations. (The client and server
>must, of course, match in protocol.)
>
>Anyone else with more information?
>
 
   We don't specifically disable the ability to run NFS over
   (tcp/ip on) X.25 in our SVR4 flavor of Unix.  In other words, it
   can be done.  

   It works best on a nice high speed private X.25 connection....but
   if you know how to tune the time-outs of NFS it can even be done
   over a Public Packet Network.  If the access link is slow or
   there is much network latency, performance is "somewhat slow"...

   You wouldn't want to do rpc type stuff over a PPN, but copying
   files back and forth is ok.


-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Jun 1993 23:50:22 GMT
From:      njonker@cs.vu.nl (Jonker N)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP: Specs, Ms-Dos Packetdriver Specs?

Hello,

A group of three people is getting into writing a TCP/IP interface
Unit for Turbo pascal programmers on the PC. We have a almost total
lack of information that is usable at this point. Can any people on
this group give me pointers on where and how to find information on:

- TCP/IP itself,
- PC-Packetdrivers and how they relate to networks and programs,
- Related stuff to any of the above stuff, including sample source?

Please email responses, I will likely have a hard time reading this
group. Many thanks in advance!

Niels
-- 
Niels Jonker, n_jonker@sacam.oren.ortn.edu, njonker@cs.vu.nl

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 1993 00:09:32 GMT
From:      tomv@cssc-syd.tansu.com.au (Tom Vasak)
To:        comp.protocols.tcp-ip
Subject:   Secure TCP/IP

Can someone give me some pointers on packages that implement secure data transfer
across TCP/IP networks. Such packages should perform DES encryption or similar,
and run under SunOS.

Thanks

Tom

------------------------------------------------------------------------------------
Tom Vasak
Telecom Australia
tomv@cssc-syd.tansu.com.au


-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 93 00:10:14 GMT
From:      harvey@indyvax.iupui.edu
To:        comp.protocols.tcp-ip,comp.sys.acorn.tech
Subject:   Re: Is a pre-login banner for ftp `legal'?

In article <1993Jun10.215553.25083@aston.ac.uk>, evansmp@uhura.aston.ac.uk (Mark Evans) writes:
> C.D.Latham (CDLatham@cen.ex.ac.uk) wrote:
> : The subject says it all really, but the problem in a little more
> : detail is this.  I have an Acorn A5000 computer running RISC OS 3 and
> : the Acorn TCP/IP suite.  The University Computer Unit here at Exeter
> : puts a vast banner, which basically says unauthorised use is
> : prohibited, *before* the ftp login prompt.  My little personal
> : computer can't cope with this and ftp crashes.  Without the banner
> : it all works nicely.  Large messages after login are alright too.
>
> The banner does look somewhat dodgy.
> If it had every line prefixed by 220- it might be a bit better.

There is no need to prefix every line.  See RFC 959 section 4.2.
It's SMTP that requires a reply code and hyphen at the beginning of
every line except the last line of the reply.  It does seems odd that
FTP and SMTP have different specs for multi-line replies.

As a practical matter, at least one FTP server used frequently by anonymous
FTP sites doesn't make you put up with multi-line replies before the login,
and gives you a way to suppress multi-line replies on anonymous logins by
giving an anonymous password that starts with a hyphen.  But the site in
question here may require the long banner for legal reasons.  The bottom
line is that the FTP client is broken.

If it's any consolation, this isn't the only FTP client that is broken by
multi-line replies.
--
James Harvey    IUPUI OIT Technical Support -- VMS/Unix/Networks
harvey@iupui.edu  uucp:iugate!harvey  bitnet:harvey@indyvax

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jun 1993 01:49:13 GMT
From:      John Matthews <matthews@mis.uswest.com>
To:        comp.protocols.tcp-ip
Subject:   FTP w/adjustable TCP MSS & Window?

Does anyone know of an existing version of FTP for SunOS 4.1.2 that
has command line options for changing the TCP MaxSegSize and
the TCP Window?  We need to experiment with these to try to optimize
the weekly 55 gigabyte file transfers that go across our WAN to our
mainframe here in Denver.  Since they run in the middle of the night,
we want to try and use all available bandwidth so the transfers finish
sooner.  I figured I'd ask before I start hacking on the ftp source
that I already have.
			Thanks in advance,
				John Matthews
				matthews@mis.uswest.com

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 1993 13:37:00 -0400
From:      dsc@xray.hmc.psu.edu (David S. Channin)
To:        news.announce.newgroups,news.groups,sci.med,sci.med.physics,sci.med.telemedicine,sci.image.processing,comp.graphics,comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   CFV: comp.protocols.dicom

                 CALL FOR VOTES --- NEW USENET GROUP

Name: comp.protocols.dicom

Charter:

The purpose of this group will be to discuss issues surrounding 
the American College of Radiology - National Electrical 
Manufacturers  (ACR-NEMA)  standard for Digital Imaging and 
Communications in Medicine (DICOM). This standard represents 
the next step beyond the ACR-NEMA version 2 standard released 
in 1988.

Postings will include information about progress of the development
of the standard, and issues concerning implementation  of the 
standard. Periodic postings will be made explaining how to obtain
the  latest versions of the available chapters, as well as information 
related to  demonstrations of the standard at the RSNA meeting.

This group will not be moderated.

If you are in favor of the creation of such a group, please send a message to:

       dicom-yes@xray.hmc.psu.edu
       
If you are opposed to the creation of such a group, please send a message to:

      dicom-no@xray.hmc.psu.edu
      
The voting period will end on July 8, 1993 at midnight. Any votes
received after this time will not be counted. Any votes received at
other e-mail addresses will not be counted. 

Thank you very much.

For off-line discussion concerning this CFV, please contact:
   
   dsc@xray.hmc.psu.edu
   
   David S. Channin
   Department of Radiology
   Section of Radiologic Computing and Imaging Science
   Penn State University
   The Milton S. Hershey Medical Center
   P.O. Box 850
   Hershey, PA 17033
   (717) 531 - 5728

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jun 1993 07:39:21 GMT
From:      edwin@cs.ruu.nl (Edwin Kremer)
To:        comp.protocols.tcp-ip
Subject:   Re: Announcing: Rev 4.0, Network Reading List

In <1v51dd$fqg@geraldo.cc.utexas.edu> spurgeon@ccwf.cc.utexas.edu
(Charles Spurgeon) writes:

   | A new version of the document "Network Reading List: TCP/IP, UNIX, and
   | Ethernet" is now available from the Network Information Center at the
   | University of Texas at Austin. 

Much appreciated! However, users in Europe should probably pick it up
from our archive site. Details follow. Thank you.

						--[ Edwin ]--

________________________________________________________________________
  We, Computer Science department, Utrecht University,  are  running  an
anonymous  FTP  server  on  one  of  our systems. In addition to the FTP
service we're also running a mail  server,  for  those  of  you  without
direct Internet access.


--> How to get 'Network Reading List' via anonymous FTP:

    Site:     ftp.cs.ruu.nl  [131.211.80.17]
    Login:    "anonymous" or "ftp"
    Password: your own email address (you@your_domain)
    file:
      /pub/DOC/net-read.ps.Z
      /pub/DOC/net-read.txt.Z


--> How to get 'Network Reading List' via e-mail from our mail-server:

    NOTE: In the following I have assumed that your mail address is
	  "fred_flintstone@stone.age.edu"; of course you must substitute
	  your own address for this.

	  | Please use a VALID DOMAIN ADDRESS.
	  | Use 'hip!hop!user' if you must.
	  | Never use an address which has both '!' and '@' in it.
	  | Bitnetters use user@host.bitnet


    Send the following message to
		mail-server@cs.ruu.nl
    or the old-fashioned path alternative
		uunet!mcsun!sun4nl!ruuinf!mail-server


    begin
    path fred_flintstone@stone.age.edu (SUBSTITUTE _YOUR_ ADDRESS)
    send DOC/net-read.ps.Z
    send DOC/net-read.txt.Z
    end


The path command can be deleted if we receive a valid from address in your
message. If this is the first time you use our mail server, we suggest you
first issue the request:

      send HELP


  A complete "ls-lR" listing of the archive is  kept  in  the  top-level
directory, it will be updated every night. To get it, issue the command:

     send ls-lR.Z



  That's all for now. If you encounter problems using  the  FTP  service
and/or the mail-server, feel free to drop me a line (by e-mail, please).



--
Edwin H. Kremer, systems- and network manager.    [NIC-Whois handle: EHK3]
  Department of Computer Science,    Utrecht University,   The Netherlands
  Internet: Edwin.Kremer@cs.ruu.nl   NeXTmail: Edwin.Kremer@edge.cs.ruu.nl
  X.400   : G=Edwin;S=Kremer;OU=cs;O=ruu;PRMD=surf;ADMD=400net;C=nl

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 93 08:32:10 GMT
From:      tazawa@ymtl01.yamato.ibm.co.jp (Takashi Tazawa)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: new pop3 rfc1460


  I rearranged the paragraphs of the original article..

In article <C8D0D6.4Bx@usenet.ucs.indiana.edu> hughes@logos.ucs.indiana.edu (larry hughes) writes:
> Also, the RFC mentions APOP is "operational use in at least three 
> implementations" but does not mention the implementations.  Does
> anybody know what/where they are?

  I know one. The POP3 implementaion of MH6.8 has APOP(and may also
have KPOP, but I don't try it yet).

> As co-author of a pop3 server (iupop3 for vms), I'm considering
> something semi-standard like DES-encrypting the database of

  Above implementaion uses MD5(RFC1321).

> passwords.  Any better ideas?  I've even thought about doing an
> encrypted Kerberos transaction to a password server (using

  I guess this may be KPOP.
--
                                                          Takashi Tazawa

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jun 1993 11:53:24 GMT
From:      stewart@oin.cis.udel.edu (John Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC site??

In article <1v7lag$cr0@hp-col.col.hp.com> wei@col.hp.com (Bill Ives) writes:
>   Would someone please tell me where a public site for RFCs is ....
>   we just lost our internal site due to "streamlining". 

ftp.nisc.sri.com is a good choice

/jws

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jun 1993 17:40:10
From:      fks@lard.ftp.com  (Frances K. Selkirk)
To:        comp.protocols.tcp-ip
Subject:   Re: PCTCP enquiry?

In article <1v3vd0$a7q@nuscc.nus.sg> ckfoong@iss.nus.sg (Foong Chhe Khoing - fair) writes:

> In addition, I like to know whether the new version of PCTCP
> Developing Kit supports Borlan C and Turbo C++. 

Version 2.2 of the PC/TCP Development Kit support Borland C++ in
addition to MS C. 


--
Frances K. Selkirk		fks@ftp.com		(508) 685-3600
FTP Software, Inc.		2 High Street, North Andover, MA 01845


-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jun 93 13:50:29 GMT
From:      clyde@hitech.com.au (Clyde Smith-Stubbs)
To:        comp.windows.x,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Who has XVision/Winsock beta version?

Does anyone out there have the beta Winsock version of XVwcomms for Visionware's
XVision X-server? Visionware admitted (reluctantly) that they have the Winsock
support in beta, but have refused to let us have it.

We urgently need to run XVision (which we've bought and paid for) over Winsock,
and Visionware are being less than helpful.
--
 Clyde Smith-Stubbs       | HI-TECH Software,       | Voice: +61 7 300 5011
 clyde@hitech.com.au      | P.O. Box 103, Alderley, | Fax:   +61 7 300 5246
 ...!nwnexus!hitech!clyde | QLD, 4051, AUSTRALIA.   | BBS:   +61 7 300 5235
 HI-TECH Software: C Compilers for all manner of machines

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jun 1993 14:17:08 GMT
From:      bob1@cos.com (Bob Blackshaw)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Why we need OSI

In <1v5chq$qq@dr-pepper.East.Sun.COM> gsteckel@harpoon.East.Sun.COM (Geoff Steckel - Sun BOS Hardware CONTRACTOR) writes:

>In article <1993Jun9.170758.2013@lambda.msfc.nasa.gov>
>cornutt@lambda.msfc.nasa.gov (David Cornutt) writes:
>>ag129@ucs.cam.ac.uk writes:
>>>In article <C891zn.7v3@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
>>>> Understand that the Internet is by far the largest 
>>>>operational network the world has ever seen
>>>The telephone network is larger by many orders of magnitude.  
 
>There's a terminology disfunction here - the telephone network is
>a (relatively) homogenous net run by a (relatively) small number
>of controlling entities.  The INTERnet is an INTERnetwork of networks.
>It is an extremely inhomogenous network with each section run by
>many different entities.
 
>The OSI/ISO stack reflects the bias of the telephone company.
>Most of the world's telephone companies are still government entities
>with government attitudes.  They don't comprehend the idea of
>peer-to-peer cooperative networking in a uncaring-to-hostile
>environment.

Sorry, but this is completely wrong. OSI started in ISO by computer
jocks. We folks in the telephone business (well, I was then) got
into it in self-defense. We thought that fat boundary line (it was
in the original docs) between Transport and Network made a false
but ideal yardstick for regulators to judge whether we could
offer a service or not. Also, working in a country where we had
competition, the word 'Interconnection' was somewhat akin to
cursing in chirch.

As to peer-to-peer cooperative networking, this was why X.25 was
designed using the initial 'balanced' version of HDLC (ISO later
changed their minds and so we got LAP-B). It was our customers
that were terrified of anything that was not a master-slave
polling protocol. So we stuck in those stupid PVC's to give them
the warm and fuzzies. Biggest damn mistake we made.


>They expect to own and control naming, routing, bandwidth allocation,
>billing, etc.  All of these _hard_ networking problems are not
>dealt with adequately (or weren't the last time I looked a year
>or so ago).  The OSI concept of INTERnetworking is very deficient.
 
>The TCP/IP family _had_ to address all of these problems (except
>billing, thank Murphy!) from very early days.  The solutions are
>a bit dated, but have been continuously updated.
>The gateway protocols, ICMP redirects, etc. of this family are
>an example.
 
>>>It is probably not misrepresenting OSI to say that it is based on
>>>extending successful telephone network principles to data networks.
>>
>>This I agree with totally -- and this is much of the problem.  They
>>aren't the same thing.  Telephony principles simply do not lend

Sorry, not the case, but see above.

>>themselves that well to packet networks.  But more to the point, the
>>*people* involved haven't demonstrated (at least not to my satisfaction)
>>an appreciation of packet networking principles.  (As an example, look
 
>Agreed.  Telco people (I've talked with a number of NYNEX people here,
>for example) do not comprehend data networking.  The concept of a
>user level error recovery other than hanging up & trying again hurts
>their heads, for instance.  The concept that any undetected
>end-to-end error rate other than zero is intolerable, but a high
>detected error rate and variable delay is tolerable and correctable
>is another difficult one.
 
>Despite what OSI/ISO folks _say_, the concept of a human-to-human
>voice conversation over a government owned and controlled network
>still seems to be their model.
>-- 
>	geoff steckel (gwes@trilobyte.com, gwes@wjh12.harvard.EDU)
>Disclaimer: I am not affiliated with Sun Microsystems, despite the From: line.
>This posting is entirely the author's responsibility.

And so is this one.

Ciao;

Bob.


-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 1993 14:26:59 GMT
From:      roadkill@wam.umd.edu (Mike Kindle)
To:        comp.protocols.tcp-ip
Subject:   PD/SHAREWARE TCP/IP FOR DOS????

    HELP????
    ^^^^^^^^

  I am putting together a small network I have a 486 w/ SCO UNIX and OS2 2.0
  with TCP/IP and NFS.  I would like to find a shareware or cheap version
  of tcp/ip to use on a 286 running dos 5.0 to network the two.  I also am
  curious... Can I use the NFS from IBM and NFS for the dos machine together???

  ANY help would be great:-)

					Thanks in advance
						Mike %)

PS:Email is best but as above ANY help is good.

roadkill@wam.umd.edu
University of Maryland at College Park
Computer Science (just one more semester)!!!


-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jun 1993 16:15:48 GMT
From:      CDLatham@cen.ex.ac.uk (C.D.Latham)
To:        comp.protocols.tcp-ip,comp.sys.acorn.tech
Subject:   ftp pre-login banner (Thanks)

Thanks to all those who replied to my question "is a pre-login banner
`legal'?"

The consensus view is that it isn't expressly prohibited hence it is
the Acorn ftp software which is at fault.  I have reported this to
Acorn, but have received no reply.

One final point made by one observant individual; the machine which
I gave as an example, cen.exeter.ac.uk, is a Silicon Graphics IRIX
machine and the banner is an IRIX-specific feature.

--Christopher.                        C.D.Latham@exeter.ac.uk


-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 1993 23:06:08 -0400
From:      darreld@access.digex.net (ddavis)
To:        comp.protocols.tcp-ip
Subject:   need help starting with tcp-ip

I am a competent C programmer who has just been handed my first
assignment writing an app for a network.  I will be inserting items
from a PC to a database on a UNIX server across a tcp-ip network.  My 
question is a basic one, and I hope, an answerable one.  What mechanisms 
do i need to start familiarizing myself with?  Will I need to use BSD 
sockets or some other way of getting the data across.  I realize this may 
be a simplistic question, but generally I've learned what I've needed to 
for 'the project'.

Any direction or suggested reading appreciated.


--------------------------------------------------------------
* Darrel L. Davis - darreld@access.digex.net   (301)670-6722 *
*                                                            *
--------------------------------------------------------------
-- 
--------------------------------------------------------------
* Darrel L. Davis - darreld@access.digex.net   (301)670-6722 *
*                                                            *
--------------------------------------------------------------

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 1993 18:04:11 GMT
From:      markl@llnl.gov (Mark Levinson)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Using my PC from home.

Hello,

I am currently using unix-windows from home. It is a nice package that 
allows multiple unix sessions from MS-WIN 3.1 over a-synchronous 
communications to my Sun WorkStation. I have been trying to talk my Boss 
into letting me purchase a software package that will allow me to use TCP/IP 
over the modem. 

I have heard about slip, and x-remote and other software that will allow 
me to do this. I do not know very much about them, but I want to accomplish 
the following:

* Running Multiple vt220 session from windows.  
* Running an X-server from ms-windows with reasonable performance over 
  9600-14,400 modems.
* Using File Transfer Protocol from my PC at home to download files from my 
  Sun.
* Maybe even using a news program from my PC at home with windows?

Do any of you have any good ideas or experience with doing this?
If so, can you recommend some software to purchase or anonymous ftp from 
somewhere? And, are the any caveats I should be aware of in setting up such a
configureation?

Please E-Mail me as I don't always have time to read all the articles in this 
group. (My boss likes to see me code.)

My apologies if this is an FAQ, I don't have time to read all the postings.

Thanks in advance, 

----------------------------------------------------------------------------
  ___       ___       ___  ___   ___      | Mark Levinson                  
 /_ /|     /_ /|     /_ /\/_ /| /_ /|     | Lawrence Livermore National Lab 
 | | |     | | |     | \  | | | | | |     | 
 | | |___  | | |___  |  \ | | | | | |___  | Internet:   markl@llnl.gov
 | |/__ /| | |/__ /| | \ \| | / | |/__ /| | Fax:        (510) 422-3396
 |_____|/  |_____|/  |_|\___|/  |_____|/  | Voice:      (510) 422-1794
----------------------------------------------------------------------------
                                 _____..---========+^+=========---.._____
    ______________________ __,-='=====____  ================== _____=====`=
   (._____________________I__) - _-=_/    `--------=+=--------'
       /      /__...---===='---+---_'
      '------'---.___ -  _ =   _.-'    "Make it so..."
                     `--------'                - Captain Jean-Luc Picard
                                                 USS Enterprise, NCC-1701D



-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jun 1993 19:23:37 GMT
From:      hughes@logos.ucs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: new pop3 rfc1460

In article <TAZAWA.93Jun11173210@beppu.aix.yamato.ibm.com>, tazawa@ymtl01.yamato.ibm.co.jp (Takashi Tazawa) writes:
|> > passwords.  Any better ideas?  I've even thought about doing an
|> > encrypted Kerberos transaction to a password server (using
|> 
|>   I guess this may be KPOP.

No, I don't think so.  KPOP is a Kerberized POP3 transaction between
the POP3 client and the POP3 server, making APOP unnecessary.  

I was talking about how the POP3 server stores/accesses it's database of 
shared secrets (i.e. user passwords).

 //==================================================================\\
||      Larry J. Hughes, Jr.       |        hughes@indiana.edu        || 
||       Indiana University        | "The person who knows everything ||
||  University Computing Services  |        has a lot to learn."      ||
 \\===================================================================//

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 93 19:33:06 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS Alternative for Wide Area Networks

In article <930607154148@whip.ftp.com>, fks@lard.ftp.com  (Frances K. Selkirk) writes:
> 
> NFS over TCP does exist, but I'm not sure there is a UNIX
> implementation.  The NFS client in version 2.2 of our PC/TCP package
> can use TCP, and TGV makes a TCP NFS server, but I don't know of any
> other currently available implementations. (The client and server
> must, of course, match in protocol.)


Look at the free source in 386bsd or NetBSD on agate.berkeley.edu.
There is also BSDI's 386/BSD.
And of course the 4.4BSD beta releases.


Vernon Schryver,  vjs@sgi.com

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jun 1993 19:39:03 GMT
From:      ldr@mv.mv.com (Lee Rothstein)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Re: Using my PC from home.

In article <1vaher$70e@lll-winken.llnl.gov> markl@llnl.gov writes:

>I am currently using unix-windows from home. It is a nice package that 
>allows multiple unix sessions from MS-WIN 3.1 over a-synchronous 
>communications to my Sun WorkStation. I have been trying to talk my Boss 
>into letting me purchase a software package that will allow me to use TCP/IP 
>over the modem. 
 
>I have heard about slip, and x-remote and other software that will allow 
>me to do this. I do not know very much about them, but I want to accomplish 
>the following:
>
>* Running Multiple vt220 session from windows.  
>* Running an X-server from ms-windows with reasonable performance over 
>  9600-14,400 modems.
>* Using File Transfer Protocol from my PC at home to download files from my 
>  Sun.
>* Maybe even using a news program from my PC at home with windows?
>
>Do any of you have any good ideas or experience with doing this?
>If so, can you recommend some software to purchase or anonymous ftp from 
>somewhere? And, are the any caveats I should be aware of in setting up such a
>configureation?
>
>Please E-Mail me as I don't always have time to read all the articles in this 
>group. (My boss likes to see me code.)

And my dog has flees. But nobody cares! Please post the responses, here. I for
one would like to see them.
-- 
                  <> Lee D. Rothstein <> ldr@veritech.com <>
     <> VeriTech <> 7 Merrymeeting Drive <> Merrimack, NH 03054-2934 <>
                    <> 603-424-2900 <> Fax: 603-424-8549 <>
            <> Information Technology Verification & Leadership <>

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jun 93 19:56:31 GMT
From:      don@mars.dgrc.doc.ca (Donald McLachlan)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.iso,comp.dcom.lans,comp.dcom.lans.ethernet,comp.dcom.lans.misc
Subject:   unknown 802.2 DSAP

I am writing my own network watching program (mostly as a learning exercise) and I
have come across a DSAP code that I cannot decode.

The specific DSAP I cannot decode is 0x42.  Does anyone know what this stands for,
and which LLC header type it uses? (It appears to use the SNAP header.)

Better yet, is there a compiled list of DSAP codes and their corresponding LCC
header types?

Please reply to me by e-mail, and I will post a summary.

Thanks.

---
Donald McLachlan			e-mail	don@mars.dgrc.doc.ca
Communications Research Centre / DRL	office	613-998-2845
3701 Carling Ave.,			lab	613-998-2423
Ottawa, Ontario				fax	613-990-7987
K2H 8S2




-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jun 93 20:07:39 GMT
From:      don@mars.dgrc.doc.ca (Donald McLachlan)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   unknown IP protocol

I am writing my own network watching program (mostly as a learning exercise) and I
have come across an IP protocol that I cannot decode.

The specific IP protocol I cannot decode is 0x09.  Does anyone know what this is?

Is there a compiled list of the IP protocol codes available somewhere?

If you are interested, here is the output of my program ...

	ff:ff:ff:ff:ff:ff <- aa:00:04:00:01:04 ether IP 8e.5c.26.0b -> ff.ff.ff.ff 
	unknown ip_proto=9

I know that the IP address of the originator is a cisco router, but it is using a
dec vendor code for the src ethernet address.

Please reply to me be email, and I will post a summary.

---
Donald McLachlan			e-mail	don@mars.dgrc.doc.ca
Communications Research Centre / DRL	office	613-998-2845
3701 Carling Ave.,			lab	613-998-2423
Ottawa, Ontario				fax	613-990-7987
K2H 8S2




-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 93 20:25:46 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   NE2000 Device driver


	Does anyone know where I might find some technical info for
	writing a device driver for the NE2000 (or compatible) PC-ISA
	ethernet adapter?

	The board I want to code a driver for is an Asante board but
	the folks at Asante said that it is NE2000 compatible, as far
	as drivers go.

	I would even be interested in finding public domain drivers
	already in existence for Unix, DOS, 386bsd, etc...

	Thanks!
		Randy
-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jun 1993 21:19:00 GMT
From:      debiso@westfield.win.net (Joe DeBiso)
To:        comp.protocols.tcp-ip
Subject:   QNX with TCP/IP & NFS

Help!!!

I have to network my SCO systems running tcp/ip and nfs with several
QNX systems.  Can anyone give me any idea of what I'm up
against??  Is NFS even available for QNX??  Please let me know by
news or mail.

thanx!!
Joe D.
Plantrol Systems, Ltd. 


-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jun 1993 21:46:06 GMT
From:      cmx@netcom.com (CMX Editing Systems)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP runs very slowly from Sun-4. Why?

I have a TCP/IP based file server that works OK on a Sun-3 and a 386,
but doesn't work right on a Sun-4,

The server was writtten in-house.  It waits for a TCP/IP request on a
particular port, then connects and sends a file to the remote machine.
(The remote machine is a development station used for testing embedded code.
The file is an executable, and the development station wants it so it can
boot; in other words, this is an ordinary "boot from the net" operation.)

When the server is running on a Sun-3 (SunOS 4.0) or a 386 (Interactive UNIX),
the transfer rate is limited only by how fast the development station can
accept data (around 50 Kbytes/sec).  But when I compile exactly the same
server C-code on a Sun-4 (SunOS 4.1) and run it there, the file is transfered
at around 2 Kbytes/sec -- about 25 times slower.  This behavior is
very consistent. It happens regardless of the level of ethernet traffic,
and it's the same on two different ethernets (with two different Sun-4s).
The development stations are the same in all cases.  They use CMC ethernet
boards (type ENP-10).

Does this suggest that there's something broken (or "improved") in the
network libraries that come with SunOS 4.1?  Something strange about the
ethernet hardware on Sun-4s?  Something else?

Any suggestions on how to debug this?  (I don't have any network monitoring
tools other than etherfind.)

--

Greg Chalfin
CMX Editing Systems
2230 Martin Ave.
Santa Clara, CA 95050
(408) 988-2000


-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Jun 93 21:46:12 GMT
From:      rich@bostech.com (Richard Baughman)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   can't get pop2d to run

I am trying to get the pop2d daemon to run to service our PC mail clients.
However, inetd refuses to accept the entry in the inetd.conf file, giving
the message "inetd[160]: pop2/tcp: unknown service".  Here are the lines
in the config files:

/etc/inetd.conf:

pop2    stream  tcp     nowait  root    /usr/etc/in.popd

/etc/services:

pop2              109/tcp                         # Post Office

The following lines in /usr/etc/in.popd print the error message:

    if ((sp = getservbyname("pop2", "tcp")) == 0) {
	fprintf(stderr, "?%s: pop2/tcp: unknown service\n", av[0]);
	exit(1);
    }

What am I doing wrong?  Is there some sort of support in the kernal required?

-- 
Rich Baughman / Boston Technology / Wakefield, MA
rich@bostech.com

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Jun 1993 00:48:49 GMT
From:      jim@gordian.com (Jim Van Vorst)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.iso,comp.dcom.lans,comp.dcom.lans.ethernet,comp.dcom.lans.misc
Subject:   Re: unknown 802.2 DSAP

In article <1993Jun11.195631.2530@clark.dgim.doc.ca>, don@mars.dgrc.doc.ca (Donald McLachlan) writes:
> I am writing my own network watching program (mostly as a learning exercise) and I
> have come across a DSAP code that I cannot decode.
> 
> The specific DSAP I cannot decode is 0x42.  Does anyone know what this stands for,
> and which LLC header type it uses? (It appears to use the SNAP header.)
> 
> Better yet, is there a compiled list of DSAP codes and their corresponding LCC
> header types?
> 
> Please reply to me by e-mail, and I will post a summary.
> 
> Thanks.
> 
> ---
> Donald McLachlan			e-mail	don@mars.dgrc.doc.ca
> Communications Research Centre / DRL	office	613-998-2845
> 3701 Carling Ave.,			lab	613-998-2423
> Ottawa, Ontario				fax	613-990-7987
> K2H 8S2
> 
> 
> 

That'd be the bridge (BPDU) SAP.  Bridges use this to send hello messages
to each other and configure a bridge spanning tree topology
-- 
@-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+@
   jim@gordian.com

   "If builders built buildings the way programmers write code
    then the first woodpecker to come along would destroy
    civilization."
@-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+@

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Jun 1993 05:07:12 +0000
From:      speedy@speedy.demon.co.uk (Jeffrey Holdgate)
To:        comp.protocols.tcp-ip
Subject:   Class D addess

Could someone please explain Class D addressing please ? I understand
that this is IP Multicast, which is fine, but :
Does the IP multicast address map onto a Hardware multicast address at all ?
If so, what happens when your hardware runs out of addresses ?
If there is no hardware multicast then is IP multicast just IP broadcast 
with software demultiplexing in the Kernel ?
If so which bit of the kernel ?
-- 
--------------------------------------------------
Jeffrey Holdgate  | Voice & FAX (44)(0)81 883 8181
--------------------------------------------------


-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 1993 05:09:43 GMT
From:      emv@garnet.msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Re: Using my PC from home.

Mark Levinson (markl@llnl.gov) wrote:

: I am currently using unix-windows from home. It is a nice package that 
: allows multiple unix sessions from MS-WIN 3.1 over a-synchronous 
: communications to my Sun WorkStation. I have been trying to talk my Boss 
: into letting me purchase a software package that will allow me to use TCP/IP 
: over the modem. 

Hie thee over to "alt.winsock", the Windows Sockets newsgroup, and
locate the Frequently Asked Questions posting.  Then head over to
"comp.infosystems.gopher" and "comp.infosystems.wais" where people
are running nice GUI internet front ends as clients. 

Find someone who sounds happy with what they have over a dial line
and work from there !

--Ed


-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Jun 1993 07:53:38 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <if0o45c@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <1993Jun10.074827.16620@novell.com>, donp@novell.com (don provan) writes:
>> An application to send one byte every N seconds to the standard TCP
>> discard port on the terminal server.  It'd take 10 minutes to
>> implement, 12 if you wanted to be able to specify N on the command
>> line.  And you only send a single packet to check for the failure of
>> the entire terminal server instead of one for each connection.
>
>Good thought, but how is using the discard port for keepalives is
>different from using BSD style keepalives?

Time for a little recap.  My position is that an application's
reaction to inactivity is application specific.  Further, i claim that
the behavior of TCP keepalives is never really very close to what any
application wants.

The response to my position was two or three specific applications which
have complications which seem to be smoothed out by TCP keepalives.
Presenting these examples appears to concede that TCP keepalives aren't
particularly valuable for general purpose applications, but, if i'm
following the arguments correctly, the examples are presented as
justifications for either reducing the system's keepalive probe time or
enhancing the TCP keepalive mechanism to allow control of the keepalive
time for each connection.  In one case, the example was subsequently
enhanced by your post suggesting a true application based solution, and
clearly showing that it would take an inappropriately large development
effort, if it were possible at all.

My counter to this example was a proposal for a trivial utility,
practical and effective in almost any TCP/IP environment, that takes
very little time to develop and provides effectively the same
information that a TCP keepalive facility would.  Because the solution
is so trivial to implement -- probably as easy as either rebuilding the
kernel or enhancing the primary utility to use a new function to control
the TCP keepalive time (and *much* easier than arguing about TCP
keepalives for days on end :-) -- it shows that there is at least one
practical solution to this problem which doesn't require TCP keepalives.

Actually, i think it's a superior solution since it controls the probe
time explicitly.  Without per connection control of the probe time, using
the TCP keepalive depends on the OS to generate the desired behavior.
This is particularly bothersome since the OS behavior might change if
someone recompiles or updates the OS without remembering this
application's specific requirements for the probe time.  Even if the
application could set the probe time with some new API (and never mind
the effort involved in coming up with that API and implementing it, since
the producer of the TCP/IP stack would have to bear that cost), the
implementation of the TCP keepalive probe timeout may not be suitably
accurate to satisfy the specific requirements of the application.

And, of course, this simple minded implementation would work even on a
system that performs no TCP keepalives at all.

>Is a fair summary that if you do not have BSD keepalives or their
>timing is inappropriate, then the discard port is a good solution?

Not particularly fair, no.  I'd say the point is that you can easily
implement a solition which requires no particular keepalive behavior
at all.  If, as you suggest, this guy's using an off-the-shelf telnet
utility in this environment, acceptence of the value of TCP keepalives
in this situation implies that all telnet utilities should enable TCP
keepalives just in case they happen to be used for this type of
application.  I cannot justify polluting the networks with TCP
keepalive packets just to handle the odd ball application.  I think my
simple proposed utility shows that such pollution is not required to
handle this odd ball case.

Of course, this is just one example, so perhaps it's just a bad one.
Let's talk about that oil refinery example you suggested.  Given a huge,
dangerous environment that would take out half the city if it exploded,
i want to talk to the guy that thought it was a good idea to automated
it using off-the-shelf, general purpose utilities, without any safe
guards against undetected failures occuring above the transport layer.
("The frobnits just blew up and killed 200 people, but at least the TCP
connection to it is still alive!" :-)
						don provan
						donp@novell.com

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Jun 1993 11:08:38 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: Class D addess

In article <739861632snz@speedy.demon.co.uk> speedy@speedy.demon.co.uk writes:

>Could someone please explain Class D addressing please ? I understand
>that this is IP Multicast, which is fine, but :

Class D addreses have the first 3 bits as 1s, so the first
octet is 244 to 255, signifying 31x254x254x254 networks but no
hosts.  Reserved, yes.  Also some IP entities stop a class D
appearing in a source field.

>Does the IP multicast address map onto a Hardware multicast address at all ?

Yes, I think so, only of course in the destination Ethernet address,
and broadcast, not multicast (I think).

>If so, what happens when your hardware runs out of addresses ?

I don't understand the question?  How can the seklection of a 
broadcast Ethernet address run out?

>If there is no hardware multicast then is IP multicast just IP broadcast 
 
>with software demultiplexing in the Kernel ?
>If so which bit of the kernel ?

Sorry, pass, don't understand kernels...


-- 

Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      | (networking & OSI specialists)
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 93 19:47:35
From:      ojr@itk.unit.no (Ornulf Rodseth)
To:        comp.protocols.tcp-ip
Subject:   Re: TIME_WAIT state transition


In article <1993Jun5.003651.2007@pony.Ingres.COM> brucek@Ingres.COM (Bruce Kleinman) writes:

> I'm seeking insight into TCP state transitions at connection shutdown.
> Specifically, how long does a connection remain in the TIME_WAIT
> state?
> ...

I too is interested in this problem. We are writing an application
that needs to rebind its socket *fast* (within ~10 seconds)
after a crash. Is there any way to move the connection out of
TIME_WAIT faster than its hardwired timeout?

An even worse problem occurs when PC's or other "simple" TCP/IP nodes
connected to the application crashes together with the application.
Under some circumstances the connection ends up in FIN_WAIT(2?) and
can't be rebound until the PC or whatever has started up again. Is it
possible to move the connection out of this state?

Any pointers or answers will be received with utmost interest!

Regards,

--
Ornulf Jan Rodseth M.Sc.	ojr@itk.unit.no
SINTEF Automatic Control	+(47 7) 594351 (direct) / 594375 (switchboard)
N-7034 TRONDHEIM, NORWAY	+(47 7) 594399 (fax)

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Jun 1993 14:55:33 +0000
From:      vadim@cix.compulink.co.uk (Vadim Lebedev)
To:        comp.protocols.tcp-ip
Subject:   Re: Why we need OSI


In-Reply-To: <ag129.44.739702482@ucs.cam.ac.uk> ag129@ucs.cam.ac.uk

In article <ag129.44.739702482@ucs.cam.ac.uk>  ag129@ucs.cam.ac.uk
writes:

[ ... text deleted ]

> for some of the perceived 'complexity'.  (If you think the Internet handles
> multiple administrative domains, tell me how a country at war with the US
> can allocate IP network numbers for itself.) 
> 
> 

Sign a peace treaty :)

Vadim.



-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Jun 1993 15:06:13 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Class D addess

In article <739861632snz@speedy.demon.co.uk>, speedy@speedy.demon.co.uk (Jeffrey Holdgate) writes:
> Could someone please explain Class D addressing please ? I understand
> that this is IP Multicast, which is fine, but :
> Does the IP multicast address map onto a Hardware multicast address at all ?
> If so, what happens when your hardware runs out of addresses ?
> If there is no hardware multicast then is IP multicast just IP broadcast 
> with software demultiplexing in the Kernel ?
> If so which bit of the kernel ?



Read RFC-1054.

Some systems have very limited hardware multicast filtering.  I guess
if you hardware can listen for any 5 multicast addresses, and you need
more than 5 (quite likely), then you'd best hope your hardware
also has a "receive all multicasts" facility.


Vernon Schryver,  vjs@sgi.com

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Jun 1993 15:06:25 GMT
From:      beame@maccs.mcmaster.ca (Carl Beame)
To:        comp.protocols.tcp-ip
Subject:   Re: Information conveyed by keepalive/timeout (was Re: RFC for keepalives)

In article <if0tu8u@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>
>Let me put it another way, how many simultaneous clients can your
>telnet server handle?

	Well, our Telnet server (which has file and directory protections) 
supports a single user under DOS, but up to 20 users under MS Windows.

	Though I fail to see what this has to do with keepalives?

Carl Beame
Beame & Whiteside Software Ltd.
beame@bws.com

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 1993 01:35:29 -0400
From:      tmg@panix.com (Thomas Genereaux)
To:        comp.protocols.tcp-ip
Subject:   Re: QNX with TCP/IP & NFS

In <32@westfield.win.net> debiso@westfield.win.net (Joe DeBiso) writes:

>Help!!!
 
>I have to network my SCO systems running tcp/ip and nfs with several
>QNX systems.  Can anyone give me any idea of what I'm up
>against??  Is NFS even available for QNX??  Please let me know by
>news or mail.
 
>thanx!!
>Joe D.
>Plantrol Systems, Ltd. 


NFS is currently in beta, and running nicely. TCP/IP is available *now* -
I'm using it. 4.2 should be shipping early next month - that will provide
the full 32 bit POSIX compatible system. I'm typing this from a 4.2 beta
with SLIP/PPP built into the driver. Configuration is about what you'd
expect - very clean, and not too difficult. Give the folks at Quantum
a call - (613) 591 0931. Indeed, NFS for 4.1 may be shipping now.
                    Tom G.G.

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Jun 1993 19:37:55 GMT
From:      beame@maccs.mcmaster.ca (Carl Beame)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <if0dlba@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <1993Jun10.074431.16514@novell.com>, donp@novell.com (don provan) writes:
>
>Do you find such failures of applications to be common?  Are there any
>common characteristics of these looping or otherwise autistic
>applications, whether operating system, implementation language,
>purpose, state of completion, or anything else?  Maybe looping
>applications would seem more likely with more information.
>
>If a good case were made that (say) 37.2% of a reasonable selection of
>application system failures would have been detected by application
>peer-to-peer probing by not BSD-style keepalives, then the case for
>BSD-style keepalives would be significantly weakened.  Or even "of the
>relevant complaints from customers I recall over the last 6 months,
>many involved ..."
>
>
>Vernon Schryver,  vjs@sgi.com

	The most common case where an application "fails to respond", but the
TCP/IP continues to respond to keepalives, occurs when you are running 
MS Windows. Windows is a cooperative multiprocessing system, an application 
"hangs" anytime another process does not release the CPU. This occurs 
fairly often when the disk is accessed or heavy processing occurs or
ANY TIME a "System Model Dialog Box" is displayed. If the Model Box is displayed
no application will execute until the user repsonds to the box. During these
"hangs" the TCP/IP is still active and responding to all incoming packets.

	If the application has a "General Protection Fault" (eg. it accessed
memory from a NULL or invalid pointer), the application will terminate without
closing the TCP/IP socket. This is true for all or most TCP/IP implimentations.

Carl Beame
Beame & Whiteside Software Ltd.
beame@bws.com

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Jun 1993 03:41:11 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <1993Jun12.193755.21180@mcshub.dcss.mcmaster.ca>, beame@maccs.mcmaster.ca (Carl Beame) writes:
> ...
> 	The most common case where an application "fails to respond", but the
> TCP/IP continues to respond to keepalives, occurs when you are running 
> MS Windows. Windows is a cooperative multiprocessing system, an application 
> "hangs" anytime another process does not release the CPU. This occurs 
> fairly often when the disk is accessed or heavy processing occurs or
> ANY TIME a "System Model Dialog Box" is displayed. If the Model Box
> is displayed
> no application will execute until the user repsonds to the box. During these
> "hangs" the TCP/IP is still active and responding to all incoming packets.

Ouch.

I was just speculating that one might make a real(TM) multi-client
Telnet server for DOS by using Windows, and running one server in each
of several windows.

I take it that such hangs are best treated as transient problems, that
the applications almost always resumes running.  This seems to imply
that a BSD style Keepalive is much better than application probing of
any sort including the echo port for Windows applications, to avoid
spuriously killing the TCP connection during one of these seizures.

Is that true?


> 	If the application has a "General Protection Fault" (eg. it accessed
> memory from a NULL or invalid pointer), the application will terminate without
> closing the TCP/IP socket. This is true for all or most TCP/IP implimentations

This seems to imply that a BSD style keepalive will fail to detected
application deaths, and with the first implication, that there is no
hope for any kind of keepalive or probing that detects enough failures
and does not have too many false alarms, at least for DOS with Windows.

This this true?

If true, should one just give up, or just not worry about DOS?
Obviously, if you don't give up, you must honor the H.R. RFC
and default keepalives to off.


(Obvious rant about the usefulness of real operating systems that
implement multitasking and that reclaim resources when threads of
control end deleted.  Well not entirely deleted.  What does an 
uni-processor schedular take?--300 lines of C and 80*86 asm?
And a definition of "file" that includes arbitrary device drivers so one
could do a kludge like the old "socket libraries" for System V, release
0?--100 lines of C?  Of course, only if you're not burdened with
compatibility and the need to run on 80286's, not to mention 8088's.)


Vernon Schryver,  vjs@sgi.com

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Jun 1993 09:07:51 GMT
From:      bolwidt@fwi.uva.nl (Erwin Bolwidt)
To:        comp.protocols.tcp-ip
Subject:   Re: Why we need OSI

vadim@cix.compulink.co.uk (Vadim Lebedev) writes:

>In article <ag129.44.739702482@ucs.cam.ac.uk>  ag129@ucs.cam.ac.uk
>writes:
>[ ... text deleted ]
 
>> for some of the perceived 'complexity'.  (If you think the Internet handles
>> multiple administrative domains, tell me how a country at war with the US
>> can allocate IP network numbers for itself.) 
>Sign a peace treaty :)
In Europe, ask the RIPE-NCC :)

>Vadim.
 Erwin.
-- 
<Erwin.Bolwidt@LOESJE.ORG> `O-O'
         "Yes!"            (_U_) (From the Netherlands)


-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Jun 93 15:48:37 EDT
From:      johnl@iecc.uucp (John R. Levine)
To:        comp.protocols.tcp-ip
Subject:   Source code for nslookup?

Is the source for nslookup available on-line somewhere?  My system comes with
a working DNS bind, but, oddly, no nslookup.

Regards,
John Levine, johnl@iecc.com, {spdcc|ima|world}!iecc!johnl

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 1993 20:09:17 -0400
From:      mju@mudos.ann-arbor.mi.us (Marc Unangst)
To:        comp.protocols.tcp-ip
Subject:   Re: How can I do a rotery Telnet?

stuarts@apertus.com (Stuart Stanley) writes:
>	a)  When it sees a request to "DosServe.Widgets.Com.", hijack the
>		request and "determine"*1 which machines have a free connection.

Unfortunately there is really no way you can do this.  The obvious way
is for the DNS server to attempt a TCP connection to some port on the
DOS box and determine its state that way.  Unfortunately this then
leads to a race condition: suppose two clients, A and B, both ask to
have dospile.widgets.com resolved at the same time.  The DNS server
sees the request from A, discovers the machine1.dospile.widgets.com is
free, and returns machine1's IP address.  The DNS server then sees the
request from B, and goes out to find a free machine.  Unfortunately,
since the requests arrived back-to-back, A hasn't yet had a chance to
connect to machine1, and so the DNS server finds that machine1 is
still free and returns its IP address to B.  You now have two clients,
A and B, both of whom are going to try to connect to machine1.  One of
the two, by definition, is going to lose.

There are a couple of ways you can work around this problem.  The most
obvious is to have the DNS server use the DOS machines in a
round-robin fashion.  This won't work well, though, if you have a
small number of machines, or all the machines but one are free.
Another method would be for the DNS server to start a timer when it
returns machine1's IP address, and not use that machine again for a
"reasonable" amount of time (5-10 seconds, probably).

Another problem with the DNS implementation is deciding what to do if
there are no machines available, or if a machine doesn't answer
connections (i.e., has been crashed by some crappy DOS software).  All
in all, I think it would probably be easier to lean on your TCP vendor
for a correctly-implemented telnet client.

--
Marc Unangst, N8VRH         | "People who love sausage and respect the law
mju@mudos.ann-arbor.mi.us   |  should never watch either one being made."
                            |     -The Sausage Principle

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 93 13:47:23 GMT
From:      jordan@IMSI.COM (Jordan Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: TIME_WAIT state transition

On the server side, in a BSD-ish environment, look for the socket
option SO_REUSEADDR ...

/jordan

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 1993 15:07:34 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip,comp.sys.acorn.tech
Subject:   Re: Is a pre-login banner for ftp `legal'?

The banner is perfectly legal, but that doesn't mean all clients can
handle it.

Some clients handle long messages entirely correctly.  Others will
handle them only if every line is prefixed with "nnn-", and still
others don't handle them at all.

Can you compile the BSD FTP client on the Acorn?  That might be a way
to get around the problem while you wait for the vendor to fix the
bug.

-- 
Stephen Trier (trier@ins.cwru.edu - MIME OK)   
Network Software Engineer              
IRIS/INS/T                               
Case Western Reserve University             

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Jun 1993 17:08:52 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

> beame@maccs.mcmaster.ca (Carl Beame) writes:
>	The most common case where an application "fails to respond", but the
>TCP/IP continues to respond to keepalives, occurs when you are running 
>MS Windows. 
>...
>
>	If the application has a "General Protection Fault" (eg. it accessed
>memory from a NULL or invalid pointer), the application will terminate without
>closing the TCP/IP socket. This is true for all or most TCP/IP implimentations.

One small point, GPF's are trappable and so are other abnormal application
shutdowns, so a windows TCP implementation could determine when the application  
is trashed and close the socket immediately or at a slightly later and more
stable instant.

However, in most TCP implementations, the sockets are actually implemented as
globally accessible connections and lack a VM number.  (The API may hide this
reality, but it's true for most of them)  This practice increases utility by 
allowing multiple apps to share a single socket, but for those systems the 
the VM shutdown trapping and fault isolation has limited merit.

Erick
-- 


-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Jun 1993 18:16:06 +0000
From:      wookie@wookie.demon.co.uk (John Beardmore)
To:        comp.protocols.tcp-ip
Subject:   AS/400 to Vax

I want to link some AS/400s to a vax using a dial up TCP/IP link.

I've not yet seen documentation for any of the VAX TCP/IP products, but it
seems that they ought to be able to talk, at least over X25.

My problem is this. From my internet experience, I know that TCP/IP can link
using a protocol like slip, cslip or TCP/IP over a dial up link. It seems
however that IBMs TCP/IP offering does not provide these.

Does anybody know if any third party TCP/IPs providing these and can anybody
confirm that they are available for VAX VMS TCP/IPs ?

Failing that, any thought on how to implement good dial up links ?  I assume
that the PSTN environment in the UK will be pretty much like that in the US...
-- 
John Beardmore.                  |  Wookie like Wookie in Star Wars.
wookie@wookie.demon.co.uk        |  I don't blame my teachers...
wookie@cix.compulink.co.uk       |  Ill educated but mostly self taught !

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Jun 1993 20:53:14 GMT
From:      mb@cs.tulane.edu (Mark Benard)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Solaris 2.2 & gethostbyname

For whatever reason, when you put the simple name of a local host in the
h_name field when using gethostbyname() under SunOS, it will return with that
simple name (like rex) still in that field.  Under SunOS 4.1.3, you can force
it to return the FQDN in the h_name field by giving it a name ending in a dot
(like rex.).

I have installed SunOS 5.2 (Solaris 2.2) on a few systems and have noticed
that using the dot no longer forces gethostbyname to return the FQDN on
systems running 5.2.  Does anyone know if the behavior of gethostbyname has
been changed with this respect?  Or do I have a configuration problem?

In our network, the NIS server and the Domain Name server are both still
running 4.1.3.  I have tried 3 different "domain" lines in the resolv.conf
file, and all have the same effect w.r.t. gethostbyname; I have tried
just "domain", "domain .", and "domain cs.tulane.edu".

Incidentally, I discovered this behavior when trying to install the INN news
software on a 5.2 system.  It has a function (GetFQDN) which depends on the
old gethostbyname behavior.
-- 
Mark Benard
Department of Computer Science     INTERNET & BITNET: mb@cs.tulane.edu
Tulane University                  USENET:   rex!mb
New Orleans, LA 70118

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Jun 1993 21:19:00 GMT
From:      rgallen@muug.mb.ca (Rennie Allen)
To:        comp.protocols.tcp-ip
Subject:   Re: QNX with TCP/IP & NFS

In <32@westfield.win.net> debiso@westfield.win.net (Joe DeBiso) writes:

>Help!!!
 
>I have to network my SCO systems running tcp/ip and nfs with several
>QNX systems.  Can anyone give me any idea of what I'm up
>against??  Is NFS even available for QNX??  Please let me know by
>news or mail.

QNX NFS is in beta; I am using it right now. If I had to guess on a release date
I would say 2-3 weeks, but I can't speak for QNX Software Systems, so take that
for what it's worth.

As for what your up against, not much.  I have used QNX TCP/IP with SCO,
Unixware, and SuperTCP for Windows; and the QNX TCP/IP was the easiest to setup,
although none of them were difficult.

email: rgallen@muug.mb.ca              mail:  Expert Technology Corporation   
QUICS: rgallen (613) 591-0934                 502-52 Albert St. 
Voice: (204) 958-5676                         Winnipeg, Manitoba, Canada R3B 1E8
Fax:   (204) 958-5678

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jun 1993 00:05:53 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Source code for nslookup?

In article <m0o4y2f-00025GC@chico.iecc.com>, johnl@iecc.uucp (John R. Levine) writes:
> Is the source for nslookup available on-line somewhere?

Yes, in the usual places for 4.3BSD source:  Uunet, CDROMs,
agate.berkeley.edu, many other places.


Vernon Schryver,  vjs@sgi.com

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jun 1993 04:43:02 GMT
From:      luke@kaiwan.kaiwan.com (  Luke  )
To:        comp.protocols.tcp-ip,comp.protocols.ppp,comp.sys.sun.misc
Subject:   Re: Dedicating a Sun as a central SLIP/PPP server ??

In article <1umadeINNc4f@ymir.cs.umass.edu> doyle@cs.umass.edu (Jim Doyle) writes:
=Our department is considering dedicating a machine as a CSLIP & PPP dialup
=server for faculty and staff. In the outset - we'd like to provide the
=capacity for up to 30 simultaneous dialup PPP/SLIP connections via a shared
=campus terminal server. The use of the dedicated machine would basically be
=an interim solution until a Terminal Server implementation of these protocols
=is available.
=

There has a Nupon TS(see Ads on UNIX world) who claims to do PPP/SLIP/IPX
stuff. We are currently testing their 16 ports TS now.


=
=For this sort of usage - what is the least amount of CPU horsepower we can
=get away with?  We have a Sun 3/280 available - will that handle the load?
=Or do we need a SPARC..
=
=Has anyone used SLIP-4.1 or DP-2.3 in a configuration with as many as 30
=network interfaces?
=
=.... Jim Doyle	(doyle@cs.umass.edu)
=
=
=



-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jun 1993 10:36:34 GMT
From:      schaeff@wega.heidelbg.ibm.com (Ulrich Schaeffer)
To:        comp.protocols.tcp-ip
Subject:   PD MTP implementation wanted

Is there any ftp site which is offering a public domain implementation of
the Multicast Transport Protocol as defined by RFC 1301?
Target environment is a RS/6000 under AIX, but every UNIX implementation
would be fine, too.

Thanks,
Ulrich Schaeffer
IBM European Networking Center
Vangerowstr. 18, W-6900 Heidelberg, Germany
Email: schaeff@dhdibm1.bitnet


-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jun 93 14:25:10 GMT
From:      enter_your_userid_here@csi.uottawa.ca (Your name)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and OSI

I am mixed up between two different protocols , OSI and  TCPIP . I don't  
know how these two protocols work together. Please give me information  
about the general structure of TCPIP and its relation to osi

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 93 15:56:55 GMT
From:      tony@microware.co.uk (Tony Mountifield)
To:        comp.sys.ibm.pc.hardware,comp.dcom.lans.ethernet,comp.periphs,comp.protocols.tcp-ip
Subject:   Ethernet cards - difference between WD8003 and WD8013?


Hi Folks,

Please could anyone explain to me the differences between the WD8003 and
WD8013 Ethernet cards? I understand that one is a 16-bit bus and the
other isn't, but need to know the differences at the software level.

I have used 8003 drivers under DOS to talk to an 8013, but now need to
go the other way round on a non-DOS operating system. I have the source
to a driver written for the 8013, and need to know how I might need to
change it in order to run on the 8003.

Thanks in advance, email replies requested.

Tony.

-- 
Tony Mountifield     (G4CJO)       | Microware Systems (UK) Ltd.
-----------------------------------| Leylands Farm, Nobs Crook,
Email:  tony@microware.co.uk       | Colden Common, WINCHESTER, SO21 1TH.
(or:  ...!uknet!mwuk!tony)         | Tel: 0703 601990   Fax: 0703 601991
------------------------------------------------------------------------
** Any opinions are mine, not Microware's - but you knew that anyway. **
------------------------------------------------------------------------

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jun 1993 16:58:48 GMT
From:      neerma@nosc.mil (Merle A. Neer)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP runs very slowly from Sun-4. Why?

In article <cmxC8H8Gv.Etv@netcom.com> cmx@netcom.com (CMX Editing Systems) writes:
>I have a TCP/IP based file server that works OK on a Sun-3 and a 386,
>but doesn't work right on a Sun-4,
>
>The server was writtten in-house.  It waits for a TCP/IP request on a
>particular port, then connects and sends a file to the remote machine.
>(The remote machine is a development station used for testing embedded code.
>The file is an executable, and the development station wants it so it can
>boot; in other words, this is an ordinary "boot from the net" operation.)
>
>When the server is running on a Sun-3 (SunOS 4.0) or a 386 (Interactive UNIX),
>the transfer rate is limited only by how fast the development station can
>accept data (around 50 Kbytes/sec).  But when I compile exactly the same
>server C-code on a Sun-4 (SunOS 4.1) and run it there, the file is transfered
>at around 2 Kbytes/sec -- about 25 times slower.  This behavior is
>very consistent. It happens regardless of the level of ethernet traffic,
>and it's the same on two different ethernets (with two different Sun-4s).
>The development stations are the same in all cases.  They use CMC ethernet
>boards (type ENP-10).
>
>Does this suggest that there's something broken (or "improved") in the
>network libraries that come with SunOS 4.1?  Something strange about the
>ethernet hardware on Sun-4s?  Something else?
>
>Any suggestions on how to debug this?  (I don't have any network monitoring
>tools other than etherfind.)
>
>--
>
>Greg Chalfin
>CMX Editing Systems
>2230 Martin Ave.
>Santa Clara, CA 95050
>(408) 988-2000
>

Faced with a similar problem in the past, we discovered that the advertised
window on the client invited the faster host (the SUN server) to transmit
back-to-back packets faster than the clients slow interface could accommodate.
Therefore, the server consistently had to retransmit the second packet in
any pair...solution: cut the advertised window down so the server could send
only one packet (ethernet in our case) at a time...i.e. we reduced it to a
simple lock-step send a packet, get an ack, send a packet. etc. Throughput
improved considerably since the server did not have to spend its time
retransmitting.  You might want to check this out.


Merle



-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jun 1993 17:03:00 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: How can I do a rotery Telnet?

> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes:
>stuarts@apertus.com (Stuart Stanley) writes:
>>	a)  When it sees a request to "DosServe.Widgets.Com.", hijack the
>>		request and "determine"*1 which machines have a free connection.
>
>Unfortunately there is really no way you can do this.  

There are two easy ways to functionally address the rotary.

'Free way': you can set up a Unix account that executes a simple
PERL script using semaphores and which opens the connection.  A
semaphore in /spool doesn't solve the problem if the PC died, instead
you have timeouts.

'Preferred way': SNSI have demonstrated exactly what you need by making
a rotary box called EAGATE which runs on a 286 or better with a single 
Ethernet card.

		+--------+			PC's running Everywhere Access 
 TELNET ------->|        |--------> PC + EA	(EA for short), SNSI's TELNET
                | EAGATE |          		hosting software for DOS 
 TELNET ------->|        |--------> PC + EA	computers.
		|	 | 
		|        |--------> PC + EA
    ...		|	 |
		+--------+

You simply give EAGATE a list of PCs in order of their desireability
(486's first, then downhill) and EAGATE will hand the best available
machine to the next caller.  It supports up to 32 concurrent users
per EAGATE and can display which machines are failing to come up.

When all connections are in use, new users are given a quick message
to that effect.  It's just like a 'real' OS.

The user never has to wait for a timeout because EAGATE pre-establishes
the connections and knows and only offers connections which are up
and working.  It also logs long-dead machines and can send a mail message
to someone if the dead PC does not come to life after a period of time.

From another discussion, keepalives from the TELNET session to EAGATE
give no indication whether the client PC is alive, because that is
a separate TCP connection and executing on a different machine.

>Another problem with the DNS implementation is deciding what to do if
>there are no machines available, or if a machine doesn't answer
>connections (i.e., has been crashed by some crappy DOS software).  All
>in all, I think it would probably be easier to lean on your TCP vendor
>for a correctly-implemented telnet client.

EAGATE removes the need to do that.  At the cost of a 25 MHz 286 +
CRYNWR packet driver compatible ethernet card, it can make a
very fast/inexpensive solution when compared with the pain of
demanding fixes to all your broken TELNET implementations on 
all your platforms.  (don't forget terminal servers, mac's, and
freeware which gets updated only at whim.)

Erick

-- 


-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jun 1993 17:11:40 +0000
From:      scs@vectis.demon.co.uk ("Stuart C. Squibb")
To:        comp.protocols.tcp-ip
Subject:   SCO Unix & Bind DNS

Hi All,

I have a query regarding SCO Unix's TCP/IP and NFS. We have our SCO box
configured as a DNSon our internal network; we are also runing NFS. I'm having
a problem getting the server to accept mounts from clients unless I set the 
access to 'everbody'. After running 'showmount' on the server the names of 
clients who have mounted appear as (for client pc2, 198.10.10.21):

			pc2.10.10.198.in-addr.arpa

This appears to me (in my ignorance) to suggest that our DNS is not set up
properly, although I think I've followed the manual correctly. Can anybody
give me a suggestion as to what I've done wrong? Feel free to e-mail me 
direct if your answer is long.

Hope someone out there can help.

Stuart
-- 
|Stuart Squibb                   |e-mail: stu_squibb@cix.compulink.co.uk     |
|I.T. Systems Administrator      |        scs@vectis.demon.co.uk (preferred) |
|Isle of Wight Health Commission |-------------------------------------------|
|PO30 3ED, England.              |"Yield to temptation; it may not pass your |
|+44-983-526011 Ext. 242         | way again."  -- Lazurus Long              |

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jun 1993 17:47:54 GMT
From:      gerryw@hpwin052.uksr.hp.com (Gerry Winsor)
To:        comp.protocols.tcp-ip
Subject:   Re: Sockets on IBM VM ???

In the March and April '93 editions of "Enterprise Systesm Journal", Ron Lane
of the IBM TCP/IP Development Labs, describes TCP/IP Socket Programming for
MVS, using the IUCV Interface (the TCP/IP for MVS software is TCP/IP for
VM running in a VM emulator for MVS).  This may be of use.

Gerry Winsor
Network Specialist

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jun 1993 18:46:39 GMT
From:      UC512052@mizzou1.missouri.edu (David K. Drum)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

Hi everyone,
 
This is a repost from comp.dcom.lans.ethernet; someone told
me that I might get some help on this group and in this
thread specifically.  I have to admit that most of what is
discussed in this thread is over my head - I am just looking
for an existing solution.  Thanks.
 
* begin forwarded message *
 
I need some code that will check to see if a machine is actually
operational.  I say this because I have seen ping return packets
when the machine is actually locked up.  I need this for a
distributed ray-tracing front end that will determine which
machines are available for rendering.  Your help would be greatly
appreciated.
 
Followup or email ok.
 
Regards,
 
David K. Drum uc512052@mizzou1.missouri.edu

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jun 1993 20:18:44 GMT
From:      wied@animal.sps.mot.com (Bill Wied)
To:        comp.protocols.tcp-ip
Subject:   Need help implementing a multiplexed UDP program.

Hello World,

I'm not sure if this is a totally appropriate group to ask my question, but
I thought I would give it a shot.

I am writing a "socket" program which acts as a UDP super-server (like inetd). I
want the program to be able to receive UDP connections and spawn off individual
sessions for each connection. Unlike a similar TCP application, I can not just
use the 'accept()' command to get an individual multiplexed connection. The
problem is that after I spawn a child session, the parent process still receives
UDP packets that I want to go to the child. 

Is there a way to created individual UDP sessions. One thing I tried was to use
the 'connect()' command to establish a session from the UDP server back to the
client. I thought by doing this that only that child server session, that did
the 'connect()' command, would receive packets from the client. Does this sound
like it would work?  Has anyone done something similar?

I would appreciate any help I can get!
Please respond to my via email: wied@animal.sps.mot.com`

Thanks,
-- 
 _ __               _     _         Bill Wied - wied@animal.sps.mot.com
' /__)  o /  / ___ ' )   / o   __/  2100 E. Elliot Rd MD:EL512 Tempe, Az 85284
_/___)_/_/_ / (o o) /_/_/_/_E_/_/_  Phone:602-897-4266  Fax:602-897-3822
-----------ooO-(_)-Ooo------------' Network Applications Group, Motorola SPS

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jun 1993 20:32:03 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <16BEDC1C0.UC512052@mizzou1.missouri.edu>, UC512052@mizzou1.missouri.edu (David K. Drum) writes:
> Hi everyone,
>  
> This is a repost from comp.dcom.lans.ethernet; someone told
> me that I might get some help on this group and in this
> thread specifically.  I have to admit that most of what is
> discussed in this thread is over my head - I am just looking
> for an existing solution.  Thanks.
>  
> * begin forwarded message *
>  
> I need some code that will check to see if a machine is actually
> operational.  I say this because I have seen ping return packets
> when the machine is actually locked up.  I need this for a
> distributed ray-tracing front end that will determine which
> machines are available for rendering.  Your help would be greatly
> appreciated.


The answer in comp.dcom.lans.ethernet is right.  The only thing anyone
can say based on the information available is "it depends."

`ping` tells you the remote system is alive enough to reply to an
unsolicited ICMP ECHO-REQUEST.  Depending on the remote system, that
tells you a lot or a little about the state of its operating system and
hardware.  Depending on how TCP is implemented, that might also tell
you about one or more "applications" in the remote system.

There are many ways for a ray tracer to "lock up," ranging from
infinite loops in the ray tracer, to running out of resources to start
new jobs ("process control blocks", "clists," "file table entries",
"STREAMS buffers", "partitions", "control points"), to running out of
resources to handle larger packets (ping's are small), to strange
interrupt states (e.g. BSD style code handles pings in the splnet
handler and so does not need to awaken the main scheduler), to heavy
load from other programs (e.g. the ray tracer has low cpu priority and
the system is too busy running other jobs).

BSD style keepalives might or might not tell you more than `ping`.
Adding "application probes" to the ray tracing protocol would tell more.


The old Apollo NCS/NCA/NCF location broker Mandelbrot demo had good
idea for this kind of problem.  The client would contact the "location
broker" to farm out chunks of the job to as many systems as were
willing to play.  The client then used normal RPC timeouts to keep
things running.  Successors to that scheme might be useful.  Perhaps
something useful can be found in DCE.


Vernon Schryver,  vjs@sgi.com

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jun 1993 20:42:33 +0000
From:      wookie@wookie.demon.co.uk (John Beardmore)
To:        comp.protocols.tcp-ip
Subject:   Re: PD MTP implementation wanted

In article <C8LxGy.t0x@hawnews.watson.ibm.com> schaeff@dhdibm1.bitnet writes:

>Ulrich Schaeffer
>IBM European Networking Center

Hey you may be just the man I want to talk to !!

Is there a way of dialing into AS/400 TCP/IP with something like slip, cslip
or ppp ?

Dial up is the issue. X25 and fixed links are something that we are really
keen to avoid here !

Are there any third party offerings that we might use if IBM have nothing
to offer ?

Any thoughts appreciated ?
-- 
John Beardmore.                  |  Wookie like Wookie in Star Wars.
wookie@wookie.demon.co.uk        |  I don't blame my teachers...
wookie@cix.compulink.co.uk       |  Ill educated but mostly self taught !

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 93 21:45:46 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Anonymous FTP config


	Is there a document on the net somewhere that discusses the
	installation and configuration of an anonymous FTP server
	for SunOS? (or typical BSD machine)?

	Thanks!
		Randy

-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jun 1993 22:59:07 GMT
From:      palvarez@daniel.conicyt.cl (Pablo Alvarez G.)
To:        comp.protocols.tcp-ip
Subject:   Anonymous FTP configuration


	I would like know the configuration needed to suport a anonymous ftp
service.
	When the messages are displayed when a user in ( anonymous user using ftp)
for instance :
" Welcome to anonymous ftp from Chile , this services is experimental....."

and when the people get file using the .Z extension.

if you have time to  respond via  mail  to 

palvarez@daniel.conicyt.cl
System Administrator
CONICYT
CHILE


-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Jun 1993 23:48:03 GMT
From:      hughes@logos.ucs.indiana.edu (larry hughes)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   virtual network interfaces

Is it possible to have more than one IP address associated with a UNIX
host that has only one physical interface?

Say I have a UNIX machine with one interface, address 129.79.100.200.  
I'd like for it to also accept connections for several other addresses 
on that subnet, say 201-203.

What we have in mind is to have that machine advertise routes to these 
other addresses, and then have a software driver (like loopback?)
that delivers the packets locally.

The idea is to share a select group of network ports, in a way that lets 
one daemon be invoked if the connection arrived for host 200, and another 
if it arrived for host 201, etc.

On the select ports, inetd could invoke a multiplexing daemon that uses 
getsockname(), to see on which address the connection arrived.  It in turn
would start the appropriate daemon.

The multiplexing daemon is the easy part; we're already using one on some 
machines with multiple physical interfaces.  It'd be nice to employ it 
on top of virtual interfaces.

 //==================================================================\\
||      Larry J. Hughes, Jr.       |        hughes@indiana.edu        ||
||       Indiana University        | "The person who knows everything ||
||  University Computing Services  |        has a lot to learn."      ||
 \\===================================================================//

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 93 09:44:39 GMT
From:      ercm20@festival (Sam Wilson)
To:        comp.dcom.sys.cisco,comp.dcom.sys.wellfleet,comp.protocols.tcp-ip
Subject:   BGP Experience Anyone?

I'd like to garner some information from people who use BGP in earnest,
particularly as an IGP and with equipment from multiple vendors.  Please
mail me directly if you're willing and able to talk about it.

Sam Wilson
Network Services Division
Computing Services, The University of Edinburgh
Edinburgh, Scotland, UK

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 93 12:00:31 GMT
From:      ercm20@festival (Sam Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: SCO Unix & Bind DNS

Stuart C. Squibb (scs@vectis.demon.co.uk) wrote:
: [...] After running 'showmount' on the server the names of 
: clients who have mounted appear as (for client pc2, 198.10.10.21):
 
: 			pc2.10.10.198.in-addr.arpa
 
: This appears to me (in my ignorance) to suggest that our DNS is not set up
: properly, although I think I've followed the manual correctly. Can anybody
: give me a suggestion as to what I've done wrong? Feel free to e-mail me 
: direct if your answer is long.

Your DNS is definitely maladjusted! Sounds like you have A records,
something like [1] below, in your reverse domain (the in-addr.arpa one)
instead of PTR records, like [2].

pc2	IN	A	198.10.10.21		[1]

21	IN	PTR	pc2.<rest-of-domain>.	[2]

Lines like [1] should be in your forward zone file(s) (in our case the
ones that are for 'ed.ac.uk.') and lines like [2] in your reverse zones,
the ones for '10.10.198.in-addr.arpa'.  If you need more info feel free
to mail me. 

By the way, you're using addresses belonging to the NASA Ames Research
Centre...


Sam Wilson
Network Services Division
Computing Services, The University of Edinburgh
Edinburgh, Scotland, UK


-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 1993 14:36:56 GMT
From:      whalenm@tsg.com (Matthew Whalen)
To:        comp.protocols.tcp-ip
Subject:   mcast on sparc

I am trying to get my sparc kernels upgraded to support multicast under  
SunOS 4.1.2.  I only have a problem on one machine.  When I try to start  
up an application that uses mcast (for example, sd) I get the following  
error:

IP_ADD_MEMBERSHIP: Can't assign requested address

Since I don't really understand mcast, I'm not sure what I should be  
looking for to track down this error.  Does anyone have any suggestions?   
I used the script from Jim Culbert at MIT to perform the installation, and  
everything looks ok as far as I can tell.

-matthew           ____      
whalenm@tsg.com    \  /    equal rights, not special rights      
(NeXTMail OK)       \/      
----------------------------------------------------------------
"Thus conscience does make cowards of us all, and thus the native hue of  
resolution is sicklied o'er with the pale cast of thought, and enterprises  
of great pith and moment with this regard their currents turn awry,and  
lose the name of action."
----------------------------------------------------------------

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Jun 1993 17:14:58 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

 vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>
>I was just speculating that one might make a real(TM) multi-client
>Telnet server for DOS by using Windows, and running one server in each
>of several windows.
>
>I take it that such hangs are best treated as transient problems, that
>the applications almost always resumes running.  This seems to imply
>that a BSD style Keepalive is much better than application probing of
>any sort including the echo port for Windows applications, to avoid
>spuriously killing the TCP connection during one of these seizures.
>
>Is that true?
>

Excuse my tardiness Vernon, but I think a summary would be useful.

Several of the commercially available TELNETable DOS application 
servers I know of may implement the TCP/IP subsystem on a different 
CPU than the user applications, this can be true even if Windows
is used to multiprocess DOS machines.

Eg. implement load balancing by doing this:
Allocate m sessions on n windows machines, but hand out sessions
so that all n windows machines must be hosting at least one session
before using up a second session on a Windows machine.  That way
the performance is kept near optimal.  It's not symetric processing,
but better than a kick in the head and available today.

In several of these implementations, portions of the system can
be taken down or crashed (all systems can crash) without affecting
others.  The total user capacity is decreased but that just means
fewer people can log in, or perhaps they get lower performance 
because you are using fewer machines to service the same number
of people.

So that leaves us back with the general rule set that is applicable
to PCs as well as any other RFC compliant system.

A ping will tell you if the TCP/IP system is alive.
A keepalive will say if the TCP/IP system is alive and doesn't think
	the server code is dead.
A TELNET AreYouThere will tell you if the TCP/IP system is alive and
	the TELNET server is alive.

None of these tell you if the application has died in an infinite
loop, but a good TELNET server will also support Interrupt Process
within that system's definition of how to abort a process.  And
of course plain old Close is always an effective recourse if the
application has bit the big one.

>(Obvious rant about the usefulness of real operating systems that
>implement multitasking and that reclaim resources when threads of
>control end deleted.  Well not entirely deleted.  

Actually, there are some implementations which do exactly that.
I'm talking about implementing a decent scheduler and doing system
cleanup when the user exits gracefully or abruptly.  Someone must 
have been thinking the same thing you were, well at least for a 
second or two :-)

Erick
-- 


-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Jun 1993 18:08:56 GMT
From:      ae915@Freenet.carleton.ca (Kenneth Matthew Francis McGrath)
To:        comp.protocols.tcp-ip
Subject:   Re: Secure TCP/IP


I have not as yet seen anything commercially available that does this and
at the same time I suspect a secure facility for TCP/IP exists. If your
simply transmitting secure documents, you may want to have them encrypted
prior to transmission in a RADIX-ASCII format or simliar and then you can
use unsecure lines to transmit. Another option to safeguard lines might
include physical countermeasures... Secure phone lines for example that
employ scrambling technologies may provide added security if your commun-
ications are extremely sensitive. These days phone scramblers are inexpen-
sive and readily available - particularly the key coded variety. For more
information of that sort E-Mail me. Otherwise, I wish you the best of luck
and I caution you that DES isn't necessarily the most secure encryption
standard despite its popular use. The CIA for example can crack it wide
open in relatively a short period of time. A combination of physical and
encryption technologies with an awareness of the potential threat of in-
duction tapping is essential to a "secure" communications link.

If you find anything commercially available for TCP/IP that handles the
encryption at the com session level, let me know - I'd love to test it.

Cheers,
-- 
:K:::: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::M::: : Kenneth Matthew Francis McGrath : Voice / Fax / Data Accessible :
:::F:: :    ae915@FreeNet.carleton.ca    : (613)565-8173 14,000bps N,8,1 :
::::M: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Jun 1993 18:19:04 GMT
From:      brail@bnr.ca (Siva Arunthavanathan)
To:        comp.protocols.tcp-ip
Subject:   Please Help! - TCP/IP (sockets)

Hi everyone!



I am trying to intecept a connection between a Mac application and a Unix
machine. 


Mac                 My Unix Program               Unix Server

Client (real)       Server                     
                      
                    Client                         Server (real)      


As shown in the diagram above, Our program will pretend to be a Unix Server
for the MAC Client (real) and a MAC Client for the  Unix Server (real). The
reason is to catch the stream of data before reaching the server and doing
some modifications.

The sequences of execution is

 Mac Client  ask inetd to executes My program 
 then Mac Client can connect to my program, meanwhile  Iexecute  the
original server before connecting to it. The code for this is given below.
Can someone tell me is there anything wrong in doing this? Could you please
tell me the sequece of doing things? 

NOTE: (I AM JUST A BEGINNER IN THE SOCKET WORLD )

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

#define SERV_HOST_ADDR "47.201.0.174"
#define MAXLINE 512
#define SERV_TCP_PORT 1501
#define SERV_TCP_NPORT 1500
char *pname;

main(argc, argv)
int argc;
char *argv[];
{
  int     sockfd, newsockfd, cli_sockfd, clilen, childpid;
  struct sockaddr_in   cli_addr, serv_addr, nclient_addr;
  pname = argv[0];

switch(fork ()) {
case -1:
   {
     printf("fork error");
     exit(1);
     }
case 0:
  {  /* EXECUTING THE ORIGINAL SERVER */
   execlp("PATH/server_orig",
   "server_orig", "TCPIP" ,"USERID", "PASSWD" , "HOSTIP", "HPORT",
   "00000000", "0000" , NULL);

   }
/* CLIENT PORTION OF MY PROGRAM */
bzero((char * ) &cli_addr, sizeof(cli_addr) );
cli_addr.sin_family = AF_INET;
cli_addr.sin_addr.s_addr = SERV_HOST_ADDR;
cli_addr.sin_port = htons(SERV_TCP_NPORT);
if (( cli_sockfd = socket(AF_INET, SOCK_STREAM, 0 )) < 0 )
 {
  printf(" can't create socket cli_sockfd");
  exit(0);
  }

if (connect (cli_sockfd, (struct sockaddr_in  *)&cli_addr,
sizeof(cli_addr)) < 0 )
{
  printf("Can't connect to the real server ");
  exit(0);
}
printf("connected to the server");


/*  SERVER PORTION OF MY PROGRAM */
 
  if (( sockfd = socket(AF_INET, SOCK_STREAM, 0 )) < 0 )
   {
   printf( "Can't Create a Socket");
   exit(0);
   }

  bzero((char * ) &serv_addr, sizeof(serv_addr) );
  serv_addr.sin_family = AF_INET;
  serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
  serv_addr.sin_port = htons(SERV_TCP_PORT);
  printf("I am here");
if(bind(sockfd,(struct sockaddr_in *)&serv_addr,sizeof(serv_addr)) < 0 )
 {
 printf("Can't Bind ");
 exit(0);
 }
listen(sockfd , 5);

for(;;) {
 clilen = sizeof(nclient_addr);
 newsockfd = accept(sockfd, (struct sockaddr_in  *) &nclient_addr,
 &clilen);

  if (newsockfd <0)
   {
   printf("No new sockfd ");
   exit(0);
   }
/* CALL A PROCEDURE THAT WILL READ FROM A SOCKET AND WRITE TO OTHER AND
VICE -VERSA */
str_echo(newsockfd, cli_sockfd);  
close(cli_sockfd);
close(newsockfd);
exit(0);
}
close(sockfd);


}

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Jun 1993 18:46:03 GMT
From:      Siva Arunthavanathan
To:        comp.protocols.tcp-ip
Subject:   Please Help!!  TCP/IP sockets

Hi Everyone!
I am trying to intecept a connection between a Mac application and a Unix
machine. 


Mac                   My Unix Program              Unix Server

Client (real)   <-->    Server                     
                      
                        Client     <-->            Server (real)      

As shown in the diagram above, Our program will pretend to be a Unix Server for
the MAC Client (real) and a MAC Client for the  Unix Server (real). The reason
is to catch the stream of data before reaching the server and doing some
modifications.

The sequences of execution is

 Mac Client  ask inetd to executes My program 
 then Mac Client can connect to my program, meanwhile  Iexecute  the
original server before connecting to it. The code for this is given below. Can
someone tell me is there anything wrong in doing this? Could you please tell me
the sequece of doing things? 

NOTE: (I AM JUST A BEGINNER IN THE SOCKET WORLD )

THANKS IN ADVANCE

SIVA ARUN

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

#define SERV_HOST_ADDR "47.201.0.174"
#define MAXLINE 512
#define SERV_TCP_PORT 1501
#define SERV_TCP_NPORT 1500
char *pname;

main(argc, argv)
int argc;
char *argv[];
{
  int     sockfd, newsockfd, cli_sockfd, clilen, childpid;
  struct sockaddr_in   cli_addr, serv_addr, nclient_addr;
  pname = argv[0];

switch(fork ()) {
case -1:
   {
     printf("fork error");
     exit(1);
     }
case 0:
  {  /* EXECUTING THE ORIGINAL SERVER */
   execlp("PATH /server_orig",
   "server_orig", "TCPIP" ,"USERID", "PASSWD" , "HOSTIP", "HPORT",
   "00000000", "0000" , NULL);

   }
/* CLIENT PORTION OF MY PROGRAM */
bzero((char * ) &cli_addr, sizeof(cli_addr) );
cli_addr.sin_family = AF_INET;
cli_addr.sin_addr.s_addr = SERV_HOST_ADDR;
cli_addr.sin_port = htons(SERV_TCP_NPORT);
if (( cli_sockfd = socket(AF_INET, SOCK_STREAM, 0 )) < 0 )
 {
  printf(" can't create socket cli_sockfd");
  exit(0);
  }

if (connect (cli_sockfd, (struct sockaddr_in  *)&cli_addr,
sizeof(cli_addr)) < 0 )
{
  printf("Can't connect to the real server ");
  exit(0);
}
printf("connected to the server");


/*  SERVER PORTION OF MY PROGRAM */
 
  if (( sockfd = socket(AF_INET, SOCK_STREAM, 0 )) < 0 )
   {
   printf( "Can't Create a Socket");
   exit(0);
   }

  bzero((char * ) &serv_addr, sizeof(serv_addr) );
  serv_addr.sin_family = AF_INET;
  serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
  serv_addr.sin_port = htons(SERV_TCP_PORT);
  printf("I am here");
if(bind(sockfd,(struct sockaddr_in *)&serv_addr,sizeof(serv_addr)) < 0 )
 {
 printf("Can't Bind ");
 exit(0);
 }
listen(sockfd , 5);

for(;;) {
 clilen = sizeof(nclient_addr);
 newsockfd = accept(sockfd, (struct sockaddr_in  *) &nclient_addr,
 &clilen);

  if (newsockfd <0)
   {
   printf("No new sockfd ");
   exit(0);
   }
/* CALL A PROCEDURE THAT WILL READ FROM A SOCKET AND WRITE TO OTHER AND
VICE -VERSA */
str_echo(newsockfd, cli_sockfd);  
close(cli_sockfd);
close(newsockfd);
exit(0);
}
close(sockfd);


}
 

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Jun 1993 20:38:05 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   RFC 1323 support ?

What vendors support these RFC 1323 extensions?  I know the
soon-to-be-released 4.4BSD has them, and I would guess
SGI and Cray support them, but want to check.

	Rich Stevens  (rstevens@noao.edu)

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Jun 1993 21:14:47 GMT
From:      stuarts@apertus.com (Stuart Stanley)
To:        comp.protocols.tcp-ip
Subject:   Re: How can I do a rotery Telnet?

Erick Engelke (erick@sunee.uwaterloo.ca) wrote:
: > mju@mudos.ann-arbor.mi.us (Marc Unangst) writes:
: >stuarts@apertus.com (Stuart Stanley) writes:
: >>	a)  When it sees a request to "DosServe.Widgets.Com.", hijack the
: >>		request and "determine"*1 which machines have a free connection.
: >
: >Unfortunately there is really no way you can do this.  
I would beg to differ on that to some degree, since I am testing a
solution set to this right now.  However, while it is not impossible,
there will always be some lag between the DNS rollover server and
it sub-servers (I love it when your server has servers, but they are
not the same server type as the server. Did I say that right? ;).
In any case, my method probably doesn't work well on the "DOS Rack"
(sounds like a torture device ;), since you have to have a "session
server" running on the target machine.  If the DOS box can only
handle 1 TCP connection at a time, the server would have nothing
to listen on.  ooops!

: 'Free way': you can set up a Unix account that executes a simple
 
: 'Preferred way': SNSI have demonstrated exactly what you need by making

[info on product that telnets for you before you connect and then has
 a single IP address and passes the connection through]

Cool!  I like that one.  In particular it makes alot of sense where you
have a bunch of PC's or such on the far side of the box.  The only
problem is if you have _alot_ of sessions.  I would guess the 286 box would
start to feel a bit light headed if you ran 60,000 sessions thru it.
(yipes!).  Note that I am not knocking EAGATE in any way, just pointing
out what I _think_ the makers intended:  That it is for hooking single
session servers or reasonable session count servers such together 
and is not for mongo-end apps.

: EAGATE removes the need to do that.  At the cost of a 25 MHz 286 +
: CRYNWR packet driver compatible ethernet card, it can make a
: very fast/inexpensive solution when compared with the pain of
: demanding fixes to all your broken TELNET implementations on 
: all your platforms.  (don't forget terminal servers, mac's, and
: freeware which gets updated only at whim.)

Can this handle Tn3270?  What is the session limit (I would guess a
486 or above might be able to get more...what practical limit have you
found?)  Can you send me some info on this system?

You could have told me this when I posted the same basic question about
a year ago.  You might have been able to save me some serious brain-drain ;)

Incidently, a fun method to think about (as an excersize, but if you
want to implement it - cool).  Make you self a "single-protocol" router.
Have a machine listening for Telnet connection.  When it sees one, it
checks its connection table and decides who is less loaded.  It then
plays router and swaps the MAC address or whatever and tosses the packet
back out onto the network.  However, now the packet is destined towards
its loaded host.  Packets are returned along the same path and you swap
MACS again and forward the packet back to the client.  Since you see
all the TCP traffic, you are able to detect session termination and such
and update your tables.  A Caveat is that you double the network traffic.
I am not sure if it is really possible, but it seems like it might work
to me.  (glaring lack of knowledge probably being why I don't see any
reason why it might not...)

: Erick
Thanks for the Info on EAGATE Erick.  Thats a great solution.

Let me know if anyone see holes in my"pet router" idea.  I am curious if 
its possible or not.

Cheers, Stuart

--
       "Sometimes you're the windshield,        !    Stuart Stanley
        Sometimes you're the bug...."           !    stuarts@apertus.com
               Dire Straights, "The Bug"        !    Apertus Technologies
                             (612)-828-0391    <->   Eden Prairie, Minnesota

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 93 21:28:05 GMT
From:      rcs1@crux3.cit.cornell.edu (R Craig Stevenson)
To:        comp.protocols.tcp-ip,comp.protocols.ppp,comp.protocols.tcp-ip.ibmpc
Subject:   What universities provide SLIP/CSLIP or PPP services?

I would like to know what universities or colleges currently provide
(or are in the process of making available) SLIP/CSLIP or PPP
connectivity to their students, staff and faculty.

If so, do they provide Mac or PC networking and applications software to the
students/faculty/staff?

Approximately how large of a modem pool is provided?  Is there a fee
for using the high speed modem pool?


Thanks.
Craig Stevenson




-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Jun 93 00:54:57 GMT
From:      skibo@florida.wpd.sgi.com (Thomas Skibo)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1323 support ?

In article <1993Jun15.203805.26622@noao.edu>, rstevens@noao.edu (W. Richard Stevens) writes:
|> What vendors support these RFC 1323 extensions?  I know the
|> soon-to-be-released 4.4BSD has them, and I would guess
|> SGI and Cray support them, but want to check.
|> 
|> 	Rich Stevens  (rstevens@noao.edu)

SGI has RFC 1323 as of IRIX 5.0.

-- 
---
Thomas Skibo
Advanced Networking, Silicon Graphics, Inc.
skibo@sgi.com

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 93 03:23:04 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: unknown IP protocol

In article <1993Jun11.200739.2733@clark.dgim.doc.ca> don@mars.dgrc.doc.ca writes:
>I am writing my own network watching program (mostly as a learning exercise) and I
>have come across an IP protocol that I cannot decode.
>
>The specific IP protocol I cannot decode is 0x09.  Does anyone know what this is?
>
>Is there a compiled list of the IP protocol codes available somewhere?

From RFC1060 (Assigned Numbers):

	9     IGP         any private interior gateway

It doesn't look like a very standard usage to me...

Art

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Jun 1993 06:49:07 GMT
From:      Dominik Hoffmann <hoffmann@macc.wisc.edu>
To:        comp.protocols.tcp-ip
Subject:   How to use SLIP or ppp through terminal server?

Currently I log into my UNIX account from a Mac that is connected to a
DEC Terminal Server (DECserver 100 Terminal Server V2.0 (BL23) - LAT
V5.1). This terminal server does not provide any facilities for SLIP or
ppp.

Given that the UNIX machine, a DECStation running ULTRIX V4.2A (Rev. 47),
could be set up do become a SLIP or ppp server, is there anyway I could
take advantage of this? Could I do SLIP or ppp through the terminal
server, even though my Mac is not connected to the DECStation's serial
port directly?

Dominik Hoffmann (hoffmann@macc.wisc.edu)
-----------------------------------------------------------------------
----
Work: University of Wisconsin-Madison, Department of Physics
1150 University Ave., Madison, WI  53706-1302, Tel. (608) 265-3647
Home: 910 Delaplaine Ct., Madison, WI  53715-1836, Tel. (608) 258-1617
Internet: hoffmann@macc.wisc.edu             Bitnet: Hoffmann@WiscMACC

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 1993 09:27:41 GMT
From:      S_URIARTE@iravcl.ira.uka.de (|S| Juan Uriarte)
To:        comp.protocols.tcp-ip
Subject:   IP & ICMP Checksum question.

	Hi.
	   Im  trying to  implement ip and icmp 
	and after RTFRFC i still can understand
	how the checksum algorithm works. Could
	a kind soul  explain it to me in  terms
	of assembler? Thanks in advance.    Yon


-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Jun 1993 10:16:18 GMT
From:      paris@zygon.dev.cdx.mot.com (Gregory M. Paris)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   sensible routing on host with multiple interfaces

Here's the basics of our network configuration:  3 buildings; in each,
a Sun-4/670 (SunOS-4.1.2) NFS server an ethernet interface for each
subnet in the building; in "parallel" to each Sun, a router, with a
port on each subnet and, additionally, ports connecting point-to-point
to other routers.  We're part of a vastly larger corporate network, so
we've got WAN connections to distant sites as well.  Most traffic
to/from the Suns is local to the building in question, but inevitably,
the cross-building traffic and WAN-related traffic to/from the Suns has
grown.

The problem: using in.routed (with -q) to manage routes results in a
single interface being chosen for all remote traffic.  (This is a
separate problem from the one caused by using NIS or DNS on clients,
which results in a single interface being preferred by all clients
because it's first in the list.  I'm not asking about that problem.)
The result is that there's no balancing of remote network traffic among
the Sun's interfaces; all remote traffic gets sent to the router, via a
single interface, dumping all such traffic onto one subnet.  Even
though the Sun could talk to the same router on each of its interfaces,
it ends up talking to it over only one.

I realize now that what we need is to have an interface on each Sun
dedicated to talking only to the router.  I could turn off in.routed
and just set a default route to use that interface.  In effect, we're
sort of going this way anyway, as we're going to be connecting our
routers and Suns via FDDI.  Unfortunately, we're talking about August
or September before FDDI is in place.  What that means is getting
another interface in the short term (i.e., until September) is out.
The current situation leaves the hosts on the subnet with all the
remote traffic feeling blue (and the users seeing red).

Is there a known fix to this problem of dumping all remote traffic onto
a single interface?  I've got ideas for something I could kludge up,
but if anybody's solved this problem, I'm willing (twist my arm) to
accept the benefits of their work. :-)

Thanks in advance!

Greg

-- 
Greg Paris <paris@merlin.dev.cdx.mot.com>
Motorola Codex, 20 Cabot Blvd C1-30, Mansfield, MA  02048-1193
"Your Plastic Pal who's fun to be with." TM Sirius Cybernetics

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 1993 22:24:31 -0700
From:      warlock@ecst.csuchico.edu (John Kennedy)
To:        comp.protocols.tcp-ip,comp.protocols.ppp,comp.protocols.tcp-ip.ibmpc
Subject:   Re: What universities provide SLIP/CSLIP or PPP services?

In article <rcs1.740179685@crux1.cit.cornell.edu> Craig Stevenson writes:

-->  I would like to know what universities or colleges currently provide
-->  (or are in the process of making available) SLIP/CSLIP or PPP
-->  connectivity to their students, staff and faculty.

  CSU Chico is about to offer this.  Probably some or all of those,
depending on what a NetBlazer can offer.

  I think students are the most likely to use serial IP.  Faculty and
staff tend to use ARA (if they have macs).  We're looking into IPX via
PPP, but the usual setup (loading files that you don't have on the local
PC, for the most part) is _very_ miserable.

  Probably everything (other than AppleTalk/EtherTalk) will be fairly
unrestricted.

-->  If so, do they provide Mac or PC networking and applications software
-->  to the students/faculty/staff?

  The software certainly isn't provided free, unless it's found on the
net.  Things like ARA might be available at less than street price.  I
don't know what kind of a deal the students will get, although some
software will definitly be recommended.

-->  Approximately how large of a modem pool is provided?  Is there a
-->  fee for using the high speed modem pool?

  No fee.  Right now, probably ~16 student-ready modems.  Some of our
estimates run as high as ~100.  It really depends on how much of what
kind of use we see.  If it's IPX, it'll be high.  IPX is so bloated
it's pretty impossible to "scale it down" so it'll work reasonably
over even V.32bis modems.  You pretty much have to load everything
you use locally and pray that the data is small.

-- 
Windows/NT - From the people who brought you EDLIN

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Jun 1993 11:12:12 GMT
From:      gb@dfv.rwth-aachen.de (Goetz Brasche)
To:        comp.protocols.tcp-ip
Subject:   Performance

Hi everybody,

I'm working on an evaluation and performance analysis of the TCP (in comparison
to the OSI TP4) and want to know where to get useful information on this 
topic (papers, publications, etc., eventually including information on a 
comparison of the two protocols.)  
It would be nice if someone can support me with this stuff.

Thank you in advance

Goetz

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

       _/_/_/_/_/_/   _/_/_/_/_/_/     Goetz Brasche 
      _/        _/     _/      _/     Communication Networks
     _/               _/      _/     RWTH Aachen (University of Technology)
    _/  _/_/_/_/     _/_/_/_/_/     Kopernikusstr. 16, D-5100 Aachen, Germany
   _/  _/    _/     _/      _/      E-Mail: gb@dfv.rwth-aachen.de  
  _/        _/     _/      _/      Telefax: ++49-241-84964
 _/_/_/_/_/_/   _/_/_/_/_/_/      Phone: ++49-241-807954  
                      
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
-- 

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

      _/_/_/_/_/_/   _/_/_/_/_/_/      Goetz Brasche 

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 93 13:32:43 GMT
From:      bourkej@ul.ie
To:        comp.protocols.tcp-ip
Subject:   Tuning TCP/IP for high delay circuits ?

Howdy

Are there any papers on tuning TCP/IP for use over networks with high delays ?

Thanks


john


-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Jun 1993 14:19:14 GMT
From:      hol@research.ptt.nl
To:        comp.protocols.tcp-ip
Subject:   Q on TCP/IP traffic characteristics

Hi,

At the moment I want to run simulations of different networks but I'm still
looking for representative traffic parameters. Can someone give me any 
references, FTP sites or FAQ's where I can retrieve traffic parameters for 
a TCP/IP network? I'm interested in packet size distributions and inter-
arrival time intensities/distributions, in particular those for gateways 
to MAN's and WAN's.

Please e-mail any suggestions to me.

Many thanks in advance,

Kees Hol,
HOL@research.ptt.nl

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Jun 1993 15:58:18 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: How can I do a rotery Telnet?

stuarts@apertus.com (Stuart Stanley) writes:
>Erick Engelke (erick@sunee.uwaterloo.ca) wrote:
>: > mju@mudos.ann-arbor.mi.us (Marc Unangst) writes:
>: >stuarts@apertus.com (Stuart Stanley) writes:
>: >>	a)  When it sees a request to "DosServe.Widgets.Com.", hijack the
>: >>		request and "determine"*1 which machines have a free connection.
 
>: 'Free way': you can set up a Unix account that executes a simple...
 
>: 'Preferred way': SNSI have demonstrated exactly what you need by making...
>
>Cool!  I like that one.  In particular it makes alot of sense where you
>have a bunch of PC's or such on the far side of the box.  The only
>problem is if you have _alot_ of sessions.  I would guess the 286 box would
>start to feel a bit light headed if you ran 60,000 sessions thru it.
>(yipes!).  

Actually 32 through (thru for americans) sessions work fine.  Suppose 
you were running fully loaded with 32 TELNET sessions (32 in, 32 out) 
and weren't doing file transfers through them.

An interactive application shouldn't be generating more than roughly 
five or ten kilobytes per second (usually much much less), and the user 
keystokes will be a negligable fraction of that. 

So the rough numbers are 32ses x 2 (in+out) x 10 kB/s or 640 kB/s as
an UPPER maximum and much less on the norm.  This is easily achived, 
even on 16 bit PC hardware.  I think a 286-25 would suffice but you 
could always upgrade it.

(A common misconception is to believe the total system TCP performance 
is limited to the speed of an FTP transfer, but that is incorrect
because the single FTP connection spends much of its time waiting 
for acknowledgements, doing file i/o, etc.  Multiple sessions make
better use of that dead time.)

I would personnally expect to throw a 386DX or better if sporting more
than a few sessions, it's still darn cheap.

>... just pointing
>out what I _think_ the makers intended:  That it is for hooking single
>session servers or reasonable session count servers such together
>and is not for mongo-end apps.

They made it for racks and racks of CPUs whether in normal PC chasis 
or as processor cards in a multi-processor box.  So you are typically
talking about 5, 10, 20 or more machines.  

>Can this handle Tn3270?  What is the session limit (I would guess a
>486 or above might be able to get more...what practical limit have you
>found?)  Can you send me some info on this system?

Hmmmm, I don't think it does today, it was designed to complement 
Everywhere Access which supports VTxxx terminals, and I have seen
it work with other VTxxx hosting TELNET servers, but I seem to recall 
some differences in Push flags when speaking 3270.

>You could have told me this when I posted the same basic question about
>a year ago.  You might have been able to save me some serious brain-drain ;)

I don't think any such product was commercially available, as least 
not with this level of integration.

>Incidently, a fun method to think about (as an excersize, but if you
>want to implement it - cool).  Make you self a "single-protocol" router.
>Have a machine listening for Telnet connection.  When it sees one, it
>checks its connection table and decides who is less loaded.  It then
>plays router and swaps the MAC address or whatever and tosses the packet
>back out onto the network.  However, now the packet is destined towards
>its loaded host.  Packets are returned along the same path and you swap
>MACS again and forward the packet back to the client.  Since you see
>all the TCP traffic, you are able to detect session termination and such
>and update your tables.  
>I am not sure if it is really possible, but it seems like it might work
>to me.  (glaring lack of knowledge probably being why I don't see any
>reason why it might not...)

You are talking about a super-intelligent bridge.  It would be a lot
of work because you end up coverring a lot of problems... like the
fact that those PCs will all respond to ARPs and get everything confused
and many TCPs won't start up if someone else has the same IP number.
So then you have to use separate IP numbers for each and have to
fiddle with the header and re-checksum the data.  So you're not
any further ahead.

Also, there are benefits to moving up the protocol ladder as EAGATE does.
First, remember that the remote host may be less 'well' connected, 
so it may require retransmits and other pains.  By handling the 
remote TCP connection itself, EAGATE offloads the extra retransmits 
from the application PC.  It can also perform monitoring, logging, etc.

There are other details, but I think the most compelling argument is this:
The most important thing I and the rest of the industry have learned in 
the last decade is that one is better off to use the approach which 
relies on standards rather than inventions which may look to offer  
slight advantages in the short term.

Erick
-- 


-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 93 16:17:43 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Class D addess

In article <739861632snz@speedy.demon.co.uk> speedy@speedy.demon.co.uk writes:
>Could someone please explain Class D addressing please ? I understand
>that this is IP Multicast, which is fine, but :
>Does the IP multicast address map onto a Hardware multicast address at all ?

That is media specific, but for Ethernet, the IETF has an IEEE assigned
multicast prefix.  The low 23 bits of the Class D address are placed in
the lower 23 bits of the multicast address for transmission.
(I believe this is in the multicast RFC)

>If so, what happens when your hardware runs out of addresses ?

Most hardware has some way of receiving all multicast packets and then
checking the specific multicast destination in software.  (in fact the
LANCE and 82596 requires this check because of the way they do multicast
filtering)

>If there is no hardware multicast then is IP multicast just IP broadcast 
>with software demultiplexing in the Kernel ?

Did you mean media broadcast?  If a media only supported full broadcast,
then that's what IP multicast has to use.

>If so which bit of the kernel ?

Depends on who's kernel.  ;>}

Art

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Jun 1993 16:31:38 GMT
From:      mark@alias.com (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1323 support ?

In <1993Jun15.203805.26622@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:

>What vendors support these RFC 1323 extensions?  I know the
>soon-to-be-released 4.4BSD has them, and I would guess
>SGI and Cray support them, but want to check.
 
>	Rich Stevens  (rstevens@noao.edu)

Silicon Graphics has support for window scaling and time stamp echoing
in IRIX 4.0.5H and higher level releases. It also appears to have
PAWS support.

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Jun 1993 17:03:26 GMT
From:      manoj@manoj.austin.ibm.com (Manoj N. Kumar)
To:        comp.protocols.tcp-ip
Subject:   Novell Lan Workplace for DOS not responding to out of sequence packets

I observed a strange sequence of events in some sniffer traces
collected of a Risc 6000 communicating to a machine running
Novell Lan workplace for DOS and was curious whether this
was a known problem with that package.

Essentially each time the DOS receives a packet out-of-sequence
it does not respond with an ACK. (i.e. two packets arrive
at the DOS, the first with a seq # greater than the second,
the second one is ACKed, but not the first).  The packets
are arriving out of sequence due to a CISCO brouter doing
load balancing on a per-packet basis.


-- 
Manoj Kumar 				| No witty saying here yet
Internet: manoj@austin.ibm.com   	| 
Ph: 512-823-8415			|

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 1993 17:04:14 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: How to use SLIP or ppp through terminal server?

In article <1993Jun16.064907.9428@cs.wisc.edu>, Dominik Hoffmann 
<hoffmann@macc.wisc.edu> writes:

| Currently I log into my UNIX account from a Mac that is connected to a
| DEC Terminal Server (DECserver 100 Terminal Server V2.0 (BL23) - LAT
| V5.1). This terminal server does not provide any facilities for SLIP or
| ppp.

Wow!  A DECserver 100!  Pretty ancient, but I love those diagonal DB25s!

| Given that the UNIX machine, a DECStation running ULTRIX V4.2A (Rev. 47),
| could be set up do become a SLIP or ppp server, is there anyway I could
| take advantage of this? Could I do SLIP or ppp through the terminal
| server, even though my Mac is not connected to the DECStation's serial
| port directly?

This is theoretically possible.  We've set up SLIP running thru a DECserver 200
to a LAT application port on a VMS system, and gatewayed the SLIP via
MultiNet TCP/IP.  Although this configuration is "not supported", it worked fine.

I don't know whether the DS100 and Ultrix LAT have what it takes.  The 
general idea is to set up the serial port on the DECserver so that it yields
"eight bits clean" - no XON/XOFF flow, no local/forward/backward escape
characters.  It's also a good idea to set the LAT circuit timer down as low
as it'll go (30ms usually), in order to minimize latency.  

On the host, make the port non-interactive (I guess this would
be getty-less on Unix) and eight bits clean also.  Then do all the usual
IP routing configuration which I won't get into here.

For more details, you can look at my (rather jumbled) notes on the 
subject, which can be found in [.multinet.slip-hints]slip-over-lat.* 
on Arizona.EDU.

| Dominik Hoffmann (hoffmann@macc.wisc.edu)

Good luck,

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Jun 1993 17:36:16 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: Satellite link - what protocols?

In article <memo.330359@cix.compulink.co.uk> jkas@cix.compulink.co.uk (John Stewart) writes:
   A comapny has asked me what underlying protocol they should run
   over an intercontrinental satellite link (high propagation delay).

   We decided that UUCP was out :-)

Actually, a UUCP with large enough windows might not do too badly.
Try using a Telebit modem with PEP or TurboPEP and UUCP "g" protocol
spoofing.  Or turn off the in-modem "g" spoofing and use some of
Taylor UUCP's accessible protocol tuning parameters to increase the
window size.  I haven't played with this very much...

   but do SLIP or PPP offer the right characteristics to optimise
   transfer speeds for the bandwidth/error rate/propagation delays
   associated with this medium.

Either SLIP or PPP should do fine over an async link.  On general
principles, use an implementation that includes RFC-1144 "VJ" TCP
header compression, to conserve a little bandwidth and to offer a
slight improvement to the unavoidably abysmal latency.  A modem with
V.42 error correction will nearly eliminate any errors attributable to
the satellite link itself, but (as with any async serial IO) you'll
still need to make sure your end systems can handle the data stream.
On a PC-based UNIX system, install NS16550 UARTs and a driver that
knows how to use them.

If you have a synchronous link (56K or T1 or whatever) through the
satellite network, then PPP is your only choice.  It works fine in
such a configuration, and FCS error detection will drop any damaged
frames before passing them up to IP for routing to the destination.

But so far, all these considerations are the same as over any
terrestrial link.

   Assume a Unix to Unix transfer over the link - either E-mail (SMTP)
   or FTP.

The biggest factor that will affect your throughput is whether the end
systems on any given transaction - the ones running the FTP or SMTP
server and client, not the routers between - implement the TCP
speedups described in RFC 1323 or its predecessors, 1072 or 1185.  In
particular, it's critical that the system on the *sending* end of the
TCP stream implement Slow Start, Window Scale, and the like.  Some
UNIX-like systems (and other systems too) don't do this yet, and
they're unable to fill the bandwidth of a high-latency link.

   Anyone with any practical experience want to share it. 

Here's a common scenario, describing an encounter with end systems
lacking those TCP extensions: You'll get the whole setup working
between two systems on your bench, over a local phone call.  You'll be
pleased with the throughput (V.32bis/V.42/V.42bis yields a little over
2 Kbytes/sec for binary data, a little over 3 Kbytes/sec for text
data) and you'll get approval from the project manager to progress to
the next stage of the pilot, and use up some satellite time.  Then
you'll discover that with the same configuration, your FTP throughput
will drop to less than half what you saw before.  You'll be tempted at
first to attribute the slowdown to the line's basic error rate, but
then you'll notice that your modem carrier isn't retraining much, and
its connection statistics indicate a pretty clean line.  You call the
satellite company and they say the circuit meets the spec.  Plus, your
modem's TxD light isn't very busy, and it's not flow-controlling your
sending UNIX box very much, which indicates low line utilization.  You
should call your UNIX vendor to ask when they plan to get around to
implementing 1323.

I'll crosspost this followup to comp.protocols.tcp-ip, in hopes that
the really knowledgeable people there will correct any errors.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221-2856      +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 1993 18:48:55 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Novell Lan Workplace for DOS not responding to out of sequence packets

In article <C8q4pr.3Kqn@austin.ibm.com> manoj@manoj.austin.ibm.com (Manoj N. Kumar) writes:
>Essentially each time the DOS receives a packet out-of-sequence
>it does not respond with an ACK. (i.e. two packets arrive
>at the DOS, the first with a seq # greater than the second,
>the second one is ACKed, but not the first).

This sounds normal.  An ACK says "I have received _all_ packets up to
this point".  If a packet ahead of rcv.nxt arrives, it gets queued
silently.  When the intermediate packet(s) arrive, the queued packet is
unqueued, used, and acked.

Have you watched any other boxes under the same circumstances?  If I
understood you correctly, I would expect all (correct) TCPs to behave
this way.

-- 
Stephen Trier (trier@ins.cwru.edu - MIME OK)   
Network Software Engineer              
IRIS/INS/T                               
Case Western Reserve University             

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Jun 93 19:33:24 GMT
From:      rich@bostech.com (Richard Baughman)
To:        comp.protocols.tcp-ip
Subject:   inetd error: server failing (looping) ?

Can anyone suggest what this message means?

    inetd[156]: 100068/rpc/udp server failing (looping), service terminated

It is occurring from the Open Look Calendar Manager, I assume.  There is a
line in the /etc/inetd.conf file controlling this service:

    100068/2-3  dgram  rpc/udp wait root /usr/openwin3/bin/rpc.cmsd   rpc.cmsd

I can't understand why this is failing - it was running fine until yesterday.
Now it dies after one or two accesses from the cm_lookup command (the cm tool
window continues to function ok).

Any ideas?

-- 
Rich Baughman / Boston Technology / Wakefield, MA
rich@bostech.com

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Jun 1993 19:58:46 GMT
From:      gregc@eagle.fsl.noaa.gov (Greg Compestine)
To:        comp.protocols.tcp-ip
Subject:   Need help finding WATTCP developers or documentation


Greetings:

    I've been doing a bit of contract work for a networking
shop.  I've been trying to build some test bench software
using the PD wattcp software, which provides a public domain
implementation of TCP-IP for PC clones.

    A couple months ago, my client ordered the programmer's
guide by sending off a $40 check to the developers, per the
instructions in the readme files.  Nothing ever came back,
and the check was never cashed.  

    My client has no intention of canceling the check, as
long as we can somehow obtain a copy of that document.
Is there anyone working with wattcp that would be willing to
spin a copy of the document our way?  Or can anyone put me
directly in touch with the wattcp developers?


    If anyone is interested in helping me with the specific
problem we've encountered with wattcp, a discussion of that
follows.

    I had tried to modify the program so that wattcp allowed
for buffers considerably larger than a single packet size.
(The whole idea of the exercise was to experiment with the
effect of buffers on throughput).  After performing these
modifications, throughput dropped to a single packet per
second (which is very discouraging to observe).  I may have
mistakenly modified the semantics of the tcp_Socket member
rmaxdatalen in the process of modifying my code.  I've
begun to think it may have something to do with window manage-
ment, since under normal conditions this may be a portion of
wattcp that doesn't get exercised very much.  I've been
working with the latest Microsoft version available from the
uwaterloo ftp site.

Thanks in advance,
Greg

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1993 11:15:30 -0700
From:      crowed@noc.osshe.edu (David Crowe-Jr.)
To:        comp.protocols.tcp-ip
Subject:   Re: How can I do a rotery Telnet?

Tom Fitzgerald (fitz@wang.com) wrote:
:> Aaron Leonard (leonard@telcom.arizona.edu) wrote:
 
:> Just set up a domain name (say, "DosPile.Widgets.COM") with one A record 
:> corresponding to each PC telnet server.  Make sure the telnet server code 
:> issues a "connection refused" if it is already serving its one connection.   
:> ASSUMING that the telnet client(s) are competently implemented (in that
:> they comply with the "should" in sec. 2.3 in RFC-1123, which says that
:> applications should try each IP address in order, till they achieve success),
:> then any user telnetting to DosPile.Widgets.COM will be connected to the 
:> first available TELNET server.
 
:I suspect that you're interpreting RFC 1123 in a way different from the way
:the writers meant it.  It was probably intended (and is almost certainly
:always coded) so that the client keeps trying addresses as long as they
:keep timing out, but as soon as it gets a RST for a connection attempt, it
:will forget about the rest of the list and immediately return failure.

I would argue the other direction on this one for a couple of reasons. First
of all having a multihomed host isn't the only reason for having more than one
address in the list for a domain name (the original question is a good example
of this).  Second of all the RST on the TCP connection through a particular
address may, for one reason or another, be subject to access control lists - 
one address (multiple addresses does not necessarily mean multiple interfaces) 
may deny access while another may accept. If you make the assumption that a 
RST on one address is valid for the entire list of addresses you may be
denying functionality to end users.

:If you can hack the servers so that they ignore incoming connections when
:they're busy, then this might work.  But it relies on timeouts, so it might
:take a LONG time for a client to get through to an idle server.  Plus, it's
:ugly.

Unfortunately you are right that many clients do not try all of the addresses.
Some of them don't even notice that more than one address was returned.  Some
notice but don't do anything about it.  Such is the world of
interoperability... :-)

There is a recent note in comp.protocols.tcp-ip.domains with a pointer to a
document discussing Shuffle Records (which is slightly along the same topic as
this) and some implementation notes for BIND (4.8.3 and possibly 4.9).  Those
interested might take a look.  Sorry I don't have the reference handy here.

David

--
David Crowe, Jr.                                  Email: crowed@osshe.edu
OSSHE Network Engineer                            Phone: (503) 737-2868
AdS B211L                                         FAX:   (503) 737-0850
Corvallis, OR 97331

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Jun 1993 00:27:02 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: How can I do a rotery Telnet?

> Aaron Leonard (leonard@telcom.arizona.edu) wrote:
 
> Just set up a domain name (say, "DosPile.Widgets.COM") with one A record 
> corresponding to each PC telnet server.  Make sure the telnet server code 
> issues a "connection refused" if it is already serving its one connection.   
> ASSUMING that the telnet client(s) are competently implemented (in that
> they comply with the "should" in sec. 2.3 in RFC-1123, which says that
> applications should try each IP address in order, till they achieve success),
> then any user telnetting to DosPile.Widgets.COM will be connected to the 
> first available TELNET server.

I suspect that you're interpreting RFC 1123 in a way different from the way
the writers meant it.  It was probably intended (and is almost certainly
always coded) so that the client keeps trying addresses as long as they
keep timing out, but as soon as it gets a RST for a connection attempt, it
will forget about the rest of the list and immediately return failure.

If you can hack the servers so that they ignore incoming connections when
they're busy, then this might work.  But it relies on timeouts, so it might
take a LONG time for a client to get through to an idle server.  Plus, it's
ugly.

-- 
Tom Fitzgerald   Wang Labs       fitz@wang.com   "I went to the universe today;
1-508-967-5278   Lowell MA, USA                   It was closed...."

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Jun 93 02:04:03 GMT
From:      kbkim@conan.snu.ac.kr (Ki-Byoung Kim)
To:        comp.protocols.tcp-ip
Subject:   Questions about SLIP


I'd like to connect pc and sun's with SLIP connection.
Which programs and packet drivers do I need on either side,
pc and sun?
My PC is 386/33. Sun is sun4c, SOLARIS 1.0.1.

Any informations are welcome. 

Thanks.

KB Kim.
Seoul National Univ.
Seoul, KOREA


-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1993 02:30:06 GMT
From:      t933093@minyos.xx.rmit.OZ.AU (Hamish Glen Coleman)
To:        comp.protocols.tcp-ip
Subject:   Help!  - Calculating header chksums on an IBM PC

Help! --
I am writing a TCP-IP protocol stack in Turbo Pascal on an IBM PC
and I am having problems coming to grips with the header checksums.  The
information in the RFC's tells me that it is ones-complement summing the
words in the header, *but* I dont know how to do ones-complement.  I have
tried just summing them, or even summing them with added carry, but neither
of those methods give me a checksum that is accepted as valid.  I have though
found an interesting anomaly that wasnt mentioned in the RFC that i have, that
if the checksums are set to zero, they are assumed to be unimplemented!
(sure makes me happy, but I WANT CHECKSUMS!).

Hamish Coleman
t933093@minyos.xx.rmit.oz.au


-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 93 11:17:03
From:      jim@cs.strath.ac.uk (Jim Reid)
To:        comp.protocols.tcp-ip
Subject:   Re: Source code for nslookup?

In article <m0o4y2f-00025GC@chico.iecc.com> johnl@iecc.uucp (John R. Levine) writes:

   Is the source for nslookup available on-line somewhere?  My system
   comes with a working DNS bind, but, oddly, no nslookup.

Source for nslookup and other DNS lookup tools is included in the
latest release (4.9) of bind. Earlier source distributions of bind
(such as the BSD Net2 tape) had nslookup bundled in. Check your
nearest archive site.

		Jim

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1993 08:16:48 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Solaris 2.2 & gethostbyname

mb@cs.tulane.edu (Mark Benard) writes:

>For whatever reason, when you put the simple name of a local host in the
>h_name field when using gethostbyname() under SunOS, it will return with that
>simple name (like rex) still in that field.  Under SunOS 4.1.3, you can force
>it to return the FQDN in the h_name field by giving it a name ending in a dot
>(like rex.).

This is a bug in Solaris 2.1 and 2.2

>Incidentally, I discovered this behavior when trying to install the INN news
>software on a 5.2 system.  It has a function (GetFQDN) which depends on the
>old gethostbyname behavior.

Not ``old''. The right behaviour. The bug is caused by the fact that
the gethostbyname routine is based on the netdir_getbyname routine.
This routine has no provisions for returing the aliases and the
real (canonical) name. Remeber that a host has only a single name. 
It is obvious that the h_name field should contain that name.

A fix is in the works, they tell me. (I hope they don't do a reverse lookup
with the addresses they get with netdir_getbyname(). That wuldn't
give the right result).

In the mean time, there's a work around.

#define gethostbyname __switch_gethostbyname
#define gethostbyaddr __switch_gethostbyaddr /* symmetry, not needed */
/* define before: */
#include <netdb.h>
/* so the prototypes are right */

Casper

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Jun 1993 13:17:25 GMT
From:      pjmg1@fel.tno.nl (Peter van Oosterom)
To:        comp.protocols.tcp-ip,bit.listserv.tcpip-l
Subject:   dial-up IP connectivity


I'm posting this message for a friend who doens't have news, so
please react to his e-mail address: assem@guest.surfnet.nl
and not to this group.

Hello netters,

We're a small organisation in the Netherlands that wants to set up
Internet connectivity. We intend to have dial-up IP connectivity
since this is probably the most attractive service for us.
However, we're entirey Mac based and I'm not familiar with
any products on Macs to do things like:
- setting up a news server and clients (with NNTP support)
- setting up a SMTP mail hub, to be connected to our Quickmail server
- providing 'on-demand' set-up of external IP connectivity.

We have our Macs connected on an Ethernet and we're running Netware.
Our potential service provider indicates that they want to 'see'
only one IP-address for manageability reasons.

Who can give me some pointers / solutions and possible products?
Shouls we get a UNIX workstation or can we do without it?

Please react to:

Rene van den Assem,
assem@guest.surfnet.nl
+31 79 522225 tel
+31 79 522481 fax

Thanx.



-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Jun 1993 15:10:38 GMT
From:      dcarr@gandalf.ca (Dave Carr)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: Satellite link - what protocols?

In <BOB.93Jun16133611@roughy.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes:

>In article <memo.330359@cix.compulink.co.uk> jkas@cix.compulink.co.uk (John Stewart) writes:
>   A comapny has asked me what underlying protocol they should run
>   over an intercontrinental satellite link (high propagation delay).
 
>If you have a synchronous link (56K or T1 or whatever) through the
>satellite network, then PPP is your only choice.  It works fine in
>such a configuration, and FCS error detection will drop any damaged
>frames before passing them up to IP for routing to the destination.

PPP is not the only route.  LAPB with modulo 128 sequencing, plus data
compression is a viable option.  (Of course, my opinion may be biased
somewhat by the fact we make compression bridges).

>   Assume a Unix to Unix transfer over the link - either E-mail (SMTP)
>   or FTP.

Ethernet or serial port?

>The biggest factor that will affect your throughput is whether the end
>systems on any given transaction - the ones running the FTP or SMTP
>server and client, not the routers between - implement the TCP
>speedups described in RFC 1323 or its predecessors, 1072 or 1185.  In
>particular, it's critical that the system on the *sending* end of the
>TCP stream implement Slow Start, Window Scale, and the like.  Some
>UNIX-like systems (and other systems too) don't do this yet, and
>they're unable to fill the bandwidth of a high-latency link.

Yes.  Slow start is critical.  Without it, the system may keep the
link full, but it will be mostly retransmissions.

>   Anyone with any practical experience want to share it. 
 
>pleased with the throughput (V.32bis/V.42/V.42bis yields a little over
>2 Kbytes/sec for binary data, a little over 3 Kbytes/sec for text
>data) 

Or better, with real compression :-)

>will drop to less than half what you saw before.  You'll be tempted at
>first to attribute the slowdown to the line's basic error rate, but
>then you'll notice that your modem carrier isn't retraining much, and
>its connection statistics indicate a pretty clean line.  You call the

True.  The same thing can happen without the satellite delays.  Just
try PC/TCP over a 56K link.
-- 
Dave Carr               | dcarr@gandalf.ca       | It's what you learn, 
Principal Designer      | TEL (613) 723-6500     | after you know it all,
Gandalf Data Limited    | FAX (613) 226-1717     | that counts. 

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Jun 1993 16:32:00 GMT
From:      manoj@manoj.austin.ibm.com (Manoj N. Kumar)
To:        comp.protocols.tcp-ip
Subject:   Re: Novell Lan Workplace for DOS not responding to out of sequence packets

In article <1vnpun$jv5@usenet.INS.CWRU.Edu> trier@slc6.ins.cwru.edu (Stephen C. Trier) writes:
>
>This sounds normal.  An ACK says "I have received _all_ packets up to
>this point".  If a packet ahead of rcv.nxt arrives, it gets queued
>silently.  When the intermediate packet(s) arrive, the queued packet is
>unqueued, used, and acked.
>
>Have you watched any other boxes under the same circumstances?  If I
>understood you correctly, I would expect all (correct) TCPs to behave
>this way.

I am not talking about normal TCP behaviour. What I was trying to
say that the packet that was supposed to get queued never did.
The intermediate packet did arrive and was the very next packet
and was acknowledged.
The out-of-sequence packet seemed to have been thrown away by the
DOS station. This packet had to be retransmitted by the sender
for the DOS to acknowledge it. BTW it is Novell Lan Workplace for
DOS 4.01. I am not sure whether the problem still exists at vers 4.1.


-- 
Manoj Kumar 				| No witty saying here yet
Internet: manoj@austin.ibm.com   	| 
Ph: 512-823-8415			|

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 93 16:52:39 GMT
From:      karthik@informix.com (Karthikeyan Guruswamy)
To:        comp.protocols.tcp-ip
Subject:   Re: Need help finding WATTCP developers or documentation

In article <gregc.740260726@eagle.fsl.noaa.gov> gregc@eagle.fsl.noaa.gov (Greg Compestine) writes:
>
>Greetings:
>
>    I've been doing a bit of contract work for a networking
>shop.  I've been trying to build some test bench software
>using the PD wattcp software, which provides a public domain
>implementation of TCP-IP for PC clones.
>
>    A couple months ago, my client ordered the programmer's
>guide by sending off a $40 check to the developers, per the
>instructions in the readme files.  Nothing ever came back,
>and the check was never cashed.  

Hi,
Well, it did happen to me - One of my friends lost his Wattcp
manual and I remember Erick@Watstar sending him a Postscript
manual within two days of email request. There must've been
some mistake. 

Karthik
---------------------------------------------------------------
Karthik						Why doesn't my
Infosoft Inc, (Contractor to INFORMIX Inc.)	NET WORK ?
Cupertino, CA

All the views expressed here are solely mine and they dont 
represent those of my organization.
---------------------------------------------------------------

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1993 17:46:16 GMT
From:      t933093@minyos.xx.rmit.OZ.AU (Hamish Glen Coleman)
To:        comp.protocols.tcp-ip
Subject:   THANKS - found how to checksum IP headers

I have now found how to checksum IP headers, thanks to the several replies
that I recieved to my previous post.

To anybody interested I direct them to RFC-1071 which goes into header
checksums.

Thanks to all those who replied and helped me.

Hamish Coleman
t933093@minyos.xx.rmit.oz.au


-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Jun 93 19:28:57 GMT
From:      stu@mav.com (Stu Donaldson)
To:        comp.unix.pc-clone.32bit,comp.protocols.tcp-ip
Subject:   ISC TCP 1.3, PCRoute and segment size

I've been running PCRoute between two networks for a couple
of years now.  Things have been working fine until recently.
Something must have changed in our configuration, either with
PCRoute, or with the ISC Unix systems (running TCP 1.3)

All Unix systems are on network A, several PC's running
NCSA Telnet, WATTCP, and POPMAIL are on network B.

When a PC on network B, tries to send data to a Unix system on
network A, it is hanging.  The problem goes away if I set
the Maximum Segment Size (MSS) in the configuration to be
512 bytes, rather than the default of 2048.

Any ideas on what could cause this?

Around the same time, this started occuring, I installed a
Novell NE2000 boards in one of the Unix systems.  NFS between
that system, and the others would hang when transfering large
blocks of data to the NE2000 equiped system.  When changing
rsize, and wsize in the NFS mount to be 1024, from 2048, it
fixed this problem.

Where do I go in my configuration to find the problem here?
Shouldn't TCP be able to handle this?  Shouldn't the NFS
setting of rsize/wsize=2048 vs 1024 be an optimization issue?

Any help would be appreciated.

	-- Stu --
-----------------------------------------------------------------------
Stu Donaldson                   "Can't you understand what I'm saying?" 
stu@mav.com                     "What happened?  Did you Fail Telepathy?"


-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Jun 1993 20:20:43 GMT
From:      Deven
To:        comp.protocols.tcp-ip
Subject:   Questions regarding METRIC in IFCONFIG and ROUTE(D)


Hi,

	I have a few questions related to METRIC as used in the
	IFCONFIG and ROUTE commands, as also how it compares with 
	the METRIC in a dynamic route.

Background:
	The man page for IFCONFIG states that the metric argument
	"Sets the routing metric of the interface to n, default 0.  Higher 
	metrics have the effect of making a route less favorable; metrics 
	are counted as additional hops to the destination network or host."

	The man page for the ROUTE command states that "The metric 
	argument indicates the number of "hops" to the destination.
	The metric is required for add commands; it must be zero
	if the destination is on a directly-attached network,
	and nonzero if the route utilizes one or more gateways."

Question 1: 
	What is the relationship between the metric (hops) in the ROUTE 
	command and what is placed in the IP TTL field?

Question 2: 
	What is the maximum value that can be specified for METRIC
	in the IFCONFIG command?

Question 3:  
	What is the difference between the METRIC argument for the 
	IFCONFIG command and the METRIC argument for the ROUTE command?

Question 4:
	I understand that ROUTED  makes use of the metric specified 
	for a given interface.   Let us say that the route propagated by 
	ROUTED has a metric of x (after allowing for the metric for that 
	particular interface).  Would it be possible to override the metric 
	of the route given by ROUTE by adding a static route with a metric 
	of y (where y < x)?  

	If so, what would be the effects if some administrator (of another 
	network) sets up an arbitrarily high value for an interface on his 
	machine (which is a gateway), to prevent others from using it as a 
	gateway?  Would a static route on the originating machine, if 
	installed with a lower metric, take precedence?
	

Thanks for any information.
-Deven 
--
"To learn, and at due times to repeat what one has learned, is that not,
 after all, a pleasure?"		-- Confucius

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1993 22:30:31 GMT
From:      andrewm@macadam.mpce.mq.edu.au (Andrew Myles)
To:        comp.protocols.tcp-ip
Subject:   Mobile Protocols

I have been involved in the analysis of mobile protocols for IP during the
lasy year or so.  This has mainly involved paper studies but I did an 
implementation of the Columbia Mobile IP by hacking NCSA Telnet and so the 
code in a commercial router that I had access to.

I now would like to do a public domain implementation of a variant of one 
of the IBM mobile IP proposals.  My problem is that I need a good platform to 
do this.  The NCSA Telnet code is too messy to use and in any case it only
provides one application (ok, it also has ftp) which is not really sufficient
to test all the concepts of mobile IP.

I really need to modify the underlying network code in a real operating system.
Unix would be an obvious choice as would Windows NT.  But to do so I need
access to the networking code.  This really means public domain, I suppose unless
one of the major companies wants to support me.

Does anyone have any suggestions for a good platofrm that I could use to achieve
my goals?

What piblic domains UNIXs are available and what do they run on and where do I
get them?

What about the possibility of modifying Windows NT.  Are the appropriate hooks
available?

Thanks,

Andrew Myles
Macquarie University,
Sydney, Australia

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Jun 1993 22:37:28 GMT
From:      vheng@hpcuhe.cup.hp.com (Veasna Heng)
To:        comp.protocols.tcp-ip
Subject:   Re: inetd error: server failing (looping) ?

>/ hpcuhe:comp.protocols.tcp-ip / rich@bostech.com (Richard Baughman) / 12:33 pm  Jun 16, 1993 /
>Can anyone suggest what this message means?
>
>    inetd[156]: 100068/rpc/udp server failing (looping), service terminated
>
>
>Any ideas?
>
>-- 
>Rich Baughman / Boston Technology / Wakefield, MA
>rich@bostech.com
>----------

You get "the server failing (looping) message" from inetd when 
too many occurences of this particular server have been requested within
a one-minute interval.  



-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 1993 00:37:54 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1323 support ?

>In <1993Jun15.203805.26622@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:
>What vendors support these RFC 1323 extensions?  I know the
>soon-to-be-released 4.4BSD has them, and I would guess
>SGI and Cray support them, but want to check.

According to "High Performance TCP/IP for OSF/1 Alpha AXP Workstations"
(which is available via anonymous FTP from gatekeeper.dec.com as
/pub/DEC/DECinfo/whitepaper/hiperf-tcp.ps)

    "[The] DEC OSF/1 implementation provides features from RFC 1323."

I know that includes window-scaling; I can't remember if that includes
PAWS.  Here's part of a tcpdump trace showing the establishment of a
telnet connection between two Alpha OSF/1 systems:
    actitis.1048 > venus.telnet: S 295744000:295744000(0) win 32768
	<mss 1460,nop,wscale 0> [tos 0x10]
    venus.telnet > actitis.1048: S 1185344000:1185344000(0) ack 295744001
	win 33580 <mss 1460,nop,wscale 0>
    actitis.1048 > venus.telnet: . ack 1 win 33580 [tos 0x10]
Note that the telnet implementation doesn't use a large window size,
but the code is there and works (see the white paper).

If anyone needs more detail, I can probably track it down.

-Jeff

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 1993 02:14:30 GMT
From:      roy@mchip00.med.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Why no even ports?

	I was just looking at my /etc/services file, and it occurred to me
that most of the low-numbered standard port numbers are odd (i.e. echo = 7,
discard = 9, ftp = 21, etc).  Any particular reason why this is so?
-- 
Roy Smith <roy@nyu.edu>
Hippocrates Project, Department of Microbiology, Coles 202
NYU School of Medicine, 550 First Avenue, New York, NY 10016
"This never happened to Bart Simpson."

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Jun 1993 08:17:09 GMT
From:      gemini@geminix.in-berlin.de (Uwe Doering)
To:        comp.unix.pc-clone.32bit,comp.protocols.tcp-ip
Subject:   Re: ISC TCP 1.3, PCRoute and segment size

stu@mav.com (Stu Donaldson) writes:

>When a PC on network B, tries to send data to a Unix system on
>network A, it is hanging.  The problem goes away if I set
>the Maximum Segment Size (MSS) in the configuration to be
>512 bytes, rather than the default of 2048.
>
>Any ideas on what could cause this?
>
>Around the same time, this started occuring, I installed a
>Novell NE2000 boards in one of the Unix systems.  NFS between
>that system, and the others would hang when transfering large
>blocks of data to the NE2000 equiped system.  When changing
>rsize, and wsize in the NFS mount to be 1024, from 2048, it
>fixed this problem.

I'm rather sure that the culprit is the NE2000 card, or rather the
ISC TCP/IP driver for this card. I had the same problem once. If I recall
this correctly there is a note in the release notes for NFS that warns
about using NE2000 cards together with NFS because of "some know problems".
My experience, however, is that you should not only avoid the NE2000 card
for NFS but for TCP/IP in general. The ISC driver for it just seems to
be broken, at least the driver that comes with TCP/IP 1.3. It even crashed
the whole system frequently. At least the crashes vanished as soon as I
replaced the NE2000 card with a WD8013 card. I really wonder why ISC
doesn't either fix or drop this driver when they apparently know that it
is broken. :-(

Just try a WD8003 (8-bit) or WD8013 (16-bit) ethernet card. This did it
for me. I'm sure that your problems will go away, too.

     Uwe
-- 
Uwe Doering  |  INET : gemini@geminix.in-berlin.de
Berlin       |----------------------------------------------------------------
Germany      |  UUCP : ...!unido!fub!geminix.in-berlin.de!gemini

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 1993 08:30:39 GMT
From:      mama@rbg.informatik.th-darmstadt.de (Matthias Malsy)
To:        comp.protocols.tcp-ip
Subject:   RFC

Where can i obtain RFC's.


Matthias Malsy        

---- live and learn, die and forget, except you are an AI --------------------
---- mama@rbg.informatik.th-darmstadt.de ------ Thanx for the fish !---------



-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 1993 15:13:28 -0400
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Why no even ports?

In article <1vr8e6$lr5@calvin.NYU.EDU> you write:
>	I was just looking at my /etc/services file, and it occurred to me
>that most of the low-numbered standard port numbers are odd (i.e. echo = 7,
>discard = 9, ftp = 21, etc).  Any particular reason why this is so?

The TCP/UDP port numbers were copied from the NCP socket numbers.  In NCP,
sockets were simplex, so you needed two connections to make a duplex
stream.  Each service was assigned two adjacent socket; the client would
contact the odd socket and listen on the even socket, while the server
would listen on the odd socket and then open a connection to the even
socket.  This was called the "Initial Connection Protocol".

In TCP and UDP only one port needs to be reserved for a server; they copied
the odd port numbers from NCP, and the even ports became available for
reassignment.  But since most of the common protocols in use today are
descended from the NCP protocols, you still mostly see odd ports in use.

I believe the above use of pairs of sockets is also why FTP uses port 20 as
the default source port for data connections.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 1993 21:17:30 -0700
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: unknown IP protocol

In article <1993Jun16.032304.2700@acc.com>, art@acc.com (Art Berggreen) wrote:
>In article <1993Jun11.200739.2733@clark.dgim.doc.ca> don@mars.dgrc.doc.ca
> writes:
>>... I have come across an IP protocol that I cannot decode.
>>The specific IP protocol I cannot decode is 0x09.
>
>	9     IGP         any private interior gateway

Seeing that the IP datagram in question came from a Cisco router,
I would say that the protocol used in this particular case is IGRP
(Cisco's proprietory routing protocol).

...Sam
-- 
<skl@wimsey.bc.ca> -- Connectivity Technology Inc.

"NetNews on CD's" product information: <NewsCD@CDPublishing.COM>


-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Jun 1993 12:30:46 GMT
From:      gnn@cs.utwente.nl (George Neville-Neil)
To:        comp.windows.open-look,comp.windows.x.apps,comp.protocols.tcp-ip,comp.dcom.lans,comp.dcom.lans.misc
Subject:   New Version of xv_ping for anonymous ftp

Hi Folks,

	I've just placed the latest version of xv_ping, an XView client that
manages a list of machines that it will send ICMP messages to at regular
intervals.  The new version has a Ping Now feature, sent to me by Richard 
Golding (golding@cs.vu.nl), and a couple of bug fixes.  The program has
been tested on DECstation 5000s running Ultrix (up to and including version
4.3) as well as Sun 3 and Sparc machines with SunOS 4.1.* .  It should run
on any machine that has XView and the select() system call.

	It is available for anonymous ftp from pegasus.cs.utwente.nl in
the directory pub/bandwidth as xv_ping.tar.Z .

	Please email any bugs or improvements to gnn@cs.utwente.nl

Later,
George

--
Once you get to 25 you can rent a car anywhere in the world, and
nothing else matters.
-- Max Rochlin

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Jun 1993 14:21:26 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Why no even ports?

In article <1vr8e6$lr5@calvin.NYU.EDU> roy@mchip00.med.nyu.edu (Roy Smith) writes:
>	I was just looking at my /etc/services file, and it occurred to me
>that most of the low-numbered standard port numbers are odd (i.e. echo = 7,
>discard = 9, ftp = 21, etc).  Any particular reason why this is so?

Back then, the thought of a single protocol being supportted on
many vendor's computers, independant of operating system or 
physical networking hardware, and the whole thing having free
specifications and implementations...

Of course it was most odd.

Erick
-- 


-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Jun 1993 14:31:03 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Need help finding WATTCP developers or documentation

>>    I've been doing a bit of contract work for a networking
>>shop.  I've been trying to build some test bench software
>>using the PD wattcp software, 

Thanks for everyone who has been passing this message onto me,
We've gotten in touch out-of-band on Email.

BTW, please remember to not limit news posts distribution to 
just the states.  There is a whole world out there...

While I'm on the topic, postage to Canada is slightly higher, a 
lot of physical mail I get has been slowed down incredibly because 
some postie gets irate over a 2 cent difference.  When they get
around to it, they send me the letter with a 2 cent invoice.

Erick
-- 


-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Jun 1993 15:11:04 GMT
From:      moore@esseye.si.com (David Moore)
To:        comp.protocols.tcp-ip
Subject:   file dates within ftp

When I transfer files using ftp, the date changes to todays date. How
can I retain the date of the file being transferred?

Thanks

-- 
David Moore                    | moore@si.com
Smiths Industries              |
Grand Rapids Michigan          | my comments are my own -- not my employers'.

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Jun 1993 15:15:59 GMT
From:      rws@cs.brown.edu (Richard W. Sabourin)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Solaris 2.2: obscure TCP/IP difference


This is kind of a bizarre IP occurrence, has anybody else noticed it?

We have a few Solaris 2.2 hosts (all Model 41's) on our mostly-Sun network
here in the CS department. I notice that they set the IP Don't Fragment (DF)
bit in _every_ packet they send. (tcpdump is god!) Scanning some of the
relevant RFCs (791,792,1122) I don't see any compelling reason to set it or
not set it. A gateway host might reply with Dest Unreachable/Fragmentation
Needed, but that's about it.

Anyway, we only noticed this trivia because we have an Abekas digital frame
store that ignores all traffic from just those four Solaris hosts, and the
DF flag is the only difference I can see. Its firmware is pretty old, so I
lean towards blaming it.

So, does anybody know anything more specific about this on the Solaris end?
Maybe I configured something incorrectly, or it's an SVR4 thing?


Thanks,
	Rick Sabourin
	(Not a TCP/IP expert, but playing one on the net)


-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 93 16:14:08 GMT
From:      frisk@complex.is (Fridrik Skulason)
To:        comp.protocols.tcp-ip
Subject:   Print server software ...

I'm sure that there are several solutions to the problem I have, but
unfortunately I have not been able to find anything that fits my solution
perfectly...

I have a Unix workstation (DecStation 5000, running Ultrix), which I would
like to use as a print server for the PCs here.  I have the Clarkson packet
drivers on the PCs, and use the KA9Q program for Telnet and FTP from there.
Ideally I would like to see the PC part of the package use those drivers too.

I could install PC-NFS, but I don't need the complete package, and besides,
it takes up too much of my valuable memory :-) - all I need is a simple print
server ....can anybody suggest some software - PD, shareware or commercial
that will do the job ?

-frisk
-- 
Fridrik Skulason      Frisk Software International     phone: +354-1-694749
Author of F-PROT      E-mail: frisk@complex.is         fax:   +354-1-28801

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Jun 93 16:15:02 GMT
From:      skibo@florida.wpd.sgi.com (Thomas Skibo)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Solaris 2.2: obscure TCP/IP difference

In article <1993Jun18.151559.21255@cs.brown.edu>, rws@cs.brown.edu (Richard W. Sabourin) writes:
|> 
|> This is kind of a bizarre IP occurrence, has anybody else noticed it?
|> 
|> We have a few Solaris 2.2 hosts (all Model 41's) on our mostly-Sun network
|> here in the CS department. I notice that they set the IP Don't Fragment (DF)
|> bit in _every_ packet they send. (tcpdump is god!) Scanning some of the
|> relevant RFCs (791,792,1122) I don't see any compelling reason to set it or
|> not set it. A gateway host might reply with Dest Unreachable/Fragmentation
|> Needed, but that's about it.

It's Path MTU Discovery.  See RFC 1191.

-- 
---
Thomas Skibo
Advanced Networking, Silicon Graphics, Inc.
skibo@sgi.com

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Jun 1993 16:21:42 GMT
From:      evansmp@uhura.aston.ac.uk (Mark Evans)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Solaris 2.2: obscure TCP/IP difference

Richard W. Sabourin (rws@cs.brown.edu) wrote:

: We have a few Solaris 2.2 hosts (all Model 41's) on our mostly-Sun network
: here in the CS department. I notice that they set the IP Don't Fragment (DF)
: bit in _every_ packet they send. (tcpdump is god!) Scanning some of the
: relevant RFCs (791,792,1122) I don't see any compelling reason to set it or
: not set it. A gateway host might reply with Dest Unreachable/Fragmentation
: Needed, but that's about it.

The theory is that you set it only if you have a machine which you know cannot
accept fragments.

Though I'm not sure how it is ment to find this out.
Maybe try first with the flag off and if it gets an error from the remote 
machine set it on.

--
-------------------------------------------------------------------------
Mark Evans                                   |evansmp@uhura.aston.ac.uk
+(44) 21 429 9199  (Home)                    |evansmp@cs.aston.ac.uk
+(44) 21 359 6531 x4039 (Office)             |

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Jun 1993 16:43:36 GMT
From:      rws@cs.brown.edu (Richard W. Sabourin)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Solaris 2.2: obscure TCP/IP difference


Thanks go to dls@mentor.cc.purdue.edu (David L Stevens) and
skibo@florida.wpd.sgi.com (Thomas Skibo) who pointed out that Solaris is
doing RFC 1191 path MTU discovery.

	Rick S.

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 1993 23:50 MST
From:      gavron@spades.aces.com (Ehud Gavron)
To:        comp.protocols.tcp-ip
Subject:   Re: Why no even ports?

In article <1vr8e6$lr5@calvin.NYU.EDU>, roy@mchip00.med.nyu.edu (Roy Smith) writes...
#	I was just looking at my /etc/services file, and it occurred to me
#that most of the low-numbered standard port numbers are odd (i.e. echo = 7,
#discard = 9, ftp = 21, etc).  Any particular reason why this is so?

Of course!  The even ports have the low bit clear...

shees...

#-- 
#Roy Smith <roy@nyu.edu>

Ehud

--
Ehud Gavron        (EG76)     
gavron@aces.com
Yow!  And then we could sit on the hoods of cars at stop lights!

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 1993 15:32:46 +0100
From:      tim@pipex.net (Tim Goodwin)
To:        comp.protocols.tcp-ip
Subject:   TP/IX: The Next Internet

Ok, I'm confused.  I haven't been following this as closely as I
should.

There's SIP.  There's TUBA.  There's PIP.

And now there's RFC 1475 ("TP/IX: The Next Internet").

Is this it?  *The* one?  Is all the agonising and the acrimony over?
Is it time to go forth and implement?

Or is this yet another proposal, perhaps designed to pour Alka Seltzer
on troubled waters?

Tim.
-- 
Tim Goodwin | tim@pipex.net  or | OSI is now more of a problem than
PIPEX Ltd   | tim@unipalm.co.uk | a solution - Marshall T Rose.

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 1993 18:57:34 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Solaris 2.2: obscure TCP/IP difference

In article <1993Jun18.151559.21255@cs.brown.edu> rws@cs.brown.edu (Richard W. Sabourin) writes:
>We have a few Solaris 2.2 hosts (all Model 41's) on our mostly-Sun network
>here in the CS department. I notice that they set the IP Don't Fragment (DF)
>bit in _every_ packet they send. (tcpdump is god!) Scanning some of the
>relevant RFCs (791,792,1122) I don't see any compelling reason to set it or
>not set it. A gateway host might reply with Dest Unreachable/Fragmentation
>Needed, but that's about it.

See RFC1191, "Path MTU Discovery."  Solaris 2.2 apparently implements
the mechanism described in that RFC, which currently has the status
of "Draft Standard."

The idea is to start with a reasonably large packet, and always set
DF.  Then, if the packet is too large to fit through a link, instead of
fragmenting the packet, the router in question returns the ICMP message
that you mentioned.  Routers in compliance with RFC1191 return, as part
of this message, the size of the largest packet that would be forwarded
unfragmented.  The sending host can then immediately adjust its packet
size to avoid further problems.  Older routers return zero in this
field; this causes the sender to go through a quick "search" for the
right packet size.  The RFC describes mechanisms for dealing with
other issues, including increases in the allowable packet size.

Expect to see other vendors implement RFC1191, especially once it
becomes a full standard (probably in the next year or so).

>Anyway, we only noticed this trivia because we have an Abekas digital frame
>store that ignores all traffic from just those four Solaris hosts, and the
>DF flag is the only difference I can see. Its firmware is pretty old, so I
>lean towards blaming it.

Solaris should let you turn off Path MTU Discovery.  Contact SunWhatever
to find out about that.  If doing this cures the problem, then your
frame store is buggy ... but if Abekas can't fix it, then you might
be better off not using MTU Discovery in the hosts that talk to the
frame store.

As the chair of the IETF working group that wrote RFC1191, I would
appreciate receiving reports of systems that cannot deal with the "DF"
bit being set.  This probably won't prevent RFC1191 from advancing to
Standard status, but it would be useful to know.

-Jeff

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Jun 1993 19:55:02 GMT
From:      jwd@stone.ucs.indiana.edu (Jon Dunn)
To:        comp.os.ms-windows.programmer.win32,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   NT networking across routers


Is it possible to use NT's peer-to-peer networking with
NetBIOS-over-IP on a routed network?  I've taken a look at RFC's 1001
and 1002 on NetBIOS over IP and done a bit of sniffing of the IP
traffic produced by the March beta of NT, and it seems that NT is
operating as a "B node" (in RFC 1001 terminology), and therefore would
not be able to make use of NetBIOS name servers and NetBIOS datagram
distribution servers to do NetBIOS between machines on IP subnets.

Are there any existing implementations of NBNS or NBDD servers?  Can
Windows NT make use of them?  I would appreciate it if someone could
clue me in on how NT networking over IP is supposed to work across
routers.

Thanks!

-- 
Jon Dunn                      Network Services Development
jwd@indiana.edu               University Computing Services
                              Indiana University, Bloomington

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 1993 20:24:57 GMT
From:      Scott Brim <Scott_Brim@cornell.edu>
To:        comp.protocols.tcp-ip
Subject:   Re: TP/IX: The Next Internet

In article <1vsjme$s7k@tank.pipex.net> Tim Goodwin, tim@pipex.net
writes:
>Or is this yet another proposal, perhaps designed to pour Alka Seltzer
>on troubled waters?

Yes.

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Jun 1993 20:33:59 GMT
From:      faust@x1sun13.ccl.itri.org.tw (Jiunn-Chen Lin X-terminal)
To:        comp.protocols.tcp-ip
Subject:   Re: Questions about SLIP


>>I'd like to connect pc and sun's with SLIP connection.
>>Which programs and packet drivers do I need on either side,
>>pc and sun?


	In Sun, install cslip-2.6.
	In PC, packet driver (slip8250) + ncsa telnet

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Jiunn-Chen Lin
Industrial Technology Research Institute
Computer & Communication Research Labs. 
  
X100, Bldg.14, 195 Sec. 4. Chung Hsing Rd.,    _ ,
Chutung, Hsinchu, Taiwan 31015, R.O.C.       ,- -                     ,
Tel: 886-35-917623                          _||_    _                ||
Fax: 886-35-917503                         ' ||    < \, \\ \\  _-_, =||=
                                             ||    /-|| || || ||_.   ||
                                             |,   (( || || ||  ~ ||  ||
                                           _-/     \/\\ \\/\\ ,-_-   \\,
Email: faust@x1sund.ccl.itri.org.tw

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 1993 21:26:31 GMT
From:      guru@camelot.bradley.edu (Jerry Whelan)
To:        comp.unix.programmer,comp.sys.att,comp.unix.internals,comp.unix.misc,comp.unix.sys5.r4,comp.protocols.snmp,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   How to do ioctl()s on a socket in SVR4?

	I'm working on porting the CMU snmp agent to our AT&T SVR4
machines and have run into a major problem.
	I'm interested in getting network interface information
from the OS.  The normal way one would do this is via nlist()ing
the kernel and pulling out the right variables.  However, under
SVR4, there are at least two seperate tcp/ip products (Wollongong
and Lachman) which are going to have different kernel objects,
so the nlist approach won't be portable.
	There is another method for acquiring the data.  There
are a number of STREAMS ioctls that can retrieve the information
I'm interested in.  In fact, the snmpd that is shipped with
SVR4 uses the ioctls rather than nlisting the kernel (I know this
fact from using truss, I do not have source for snmpd).  However,
when I try to use the ioctls, I get errors.
	Apparently, the ioctls for interface statistics need to
be passed through the STREAMS layer via the I_STR ioctl.  (Kind
of an ioctl, encapsulated within the I_STR ioctl).  So, to do
an SIOCGIFCONF ioctl, first I package it up in a `struct strioctl'
and then call ioctl(fd, I_STR, `struct strioctl').  When I do this,
I keep getting an error of invalid arguement.  I've tried the same
approach with other ioctls, such as SIOCGIFADDR with the same sort
of result.
	The only information I have to work with is the file
<sys/sockio.h> and thus I'm pretty sure I'm doing something wrong.

	If anyone has a working snippet of code that uses I_STR
on a STREAMS device, I'd be grateful for your help.

-------------------------------------------------------------------------------
``written by a drunken insane pathological liar''        guru@stasi.bradley.edu

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Jun 1993 21:38:26 GMT
From:      sekine@gumby.dsd.trw.com (Nancy Y. Sekine)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   SNA Tunneling, SNA over Ethernet, etc.


Does anyone out there know of any books/references/info on SNA tunneling 
or running SNA over Ethernet?

Please send replies to me directly at sekine@gumby.sp.trw.com.

Thanks!

Nancy Sekine
TRW S&EG
Redondo Beach, CA 90278

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Jun 1993 22:10:37 GMT
From:      johnl@chico.iecc.com (John R. Levine)
To:        comp.unix.pc-clone.32bit,comp.protocols.tcp-ip
Subject:   Re: ISC TCP 1.3, PCRoute and segment size

>I'm rather sure that the culprit is the NE2000 card, or rather the
>ISC TCP/IP driver for this card. ...
>Just try a WD8003 (8-bit) or WD8013 (16-bit) ethernet card. This did it
>for me. I'm sure that your problems will go away, too.

Here's a counter-data-point: I also use ISC TCP 1.3 with packets passing
though a pair of PCROUTE pc's to get to the outside world.  I was having
problems with strange long pauses and attributed it to the NE2000 card.
So I yanked it out and put in a WD8003E card instead.  With the WD8003E
card, TCP worked great for about 15 seconds, then hung (not the whole
system, just the network connections.)  I put the NE2000 card back in
another slot and now it seems to work OK.

I have no idea what the problem with the WD card is.  The card is OK: it
passes the SMC diagnostics and works OK in another PC with PC-NFS.  Earlier
versions of Lachman TCP worked OK with another WD8003E card.

-- 
John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 492 3869
johnl@iecc.com, {ima|spdcc|world}!iecc!johnl
"Time is Money!  Steal some today!"

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 93 18:52:18
From:      amoss@picton.cs.huji.ac.il (Amos Shapira)
To:        comp.protocols.tcp-ip
Subject:   Re: TP/IX: The Next Internet

In article <1vsjme$s7k@tank.pipex.net> tim@pipex.net (Tim Goodwin) writes:

|Ok, I'm confused.  I haven't been following this as closely as I
|should.
 
|There's SIP.  There's TUBA.  There's PIP.
 
|And now there's RFC 1475 ("TP/IX: The Next Internet").
 
|Is this it?  *The* one?  Is all the agonising and the acrimony over?
|Is it time to go forth and implement?

Read the F*** (i.e. Funny) Comment :)

Here is what it says:

                        TP/IX: The Next Internet

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
                        ^^^^^^^^^^^^^^^^^^^^^
   community.  It does not specify an Internet standard.  Discussion and
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   suggestions for improvement are requested.  Please refer to the
   current edition of the "IAB Official Protocol Standards" for the
   standardization state and status of this protocol.  Distribution of
   this memo is unlimited.

|Or is this yet another proposal, perhaps designed to pour Alka Seltzer
|on troubled waters?

The answers seems pretty clear to me.

|Tim.
|--
|Tim Goodwin | tim@pipex.net  or | OSI is now more of a problem than
|PIPEX Ltd   | tim@unipalm.co.uk | a solution - Marshall T Rose.

Cheers,

--Amos
--
--Amos Shapira (Jumper Extraordinaire) |  "It is true that power corrupts,
C.S. System Group, Hebrew University,  |   but absolute power is better!"
Jerusalem 91904, ISRAEL                |
amoss@cs.huji.ac.il                    |          -- the Demon to his son


-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Jun 1993 16:00:33 GMT
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.unix.internals,comp.sys.sun.admin,comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Re: TCP/IP

> Small packets: SunOS 4.1.1 can shove 50% more around
> Large packets: Solaris 2.2 can move 50-70% more data.

I don't think that I can agree with your conclusions for large packets,
at least not yet. I have measured 1020 KB/s between two IPCs running
4.1.1, slightly more between two ELCs running 4.1.3. So an ELC is quite
capable of saturating an Ethernet.

The *interesting* measurement here is going to be ttcp with Solaris 2.2
over FDDI, since SunOS 4.1.x has notoriously lousy FDDI performance. The
numbers I have seen indicate that SunOS 4.1.x can only fill about 1/3 of
the full FDDI bandwidth, while HP, SGI and DEC are all capable of running
at full bandwidth.

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Jun 1993 20:57:36 GMT
From:      rawn@Seagull.RTD.COM (Rawn Shah)
To:        comp.protocols.tcp-ip,comp.protocols.ppp,comp.protocols.tcp-ip.ibmpc
Subject:   Re: What universities provide SLIP/CSLIP or PPP services?

The University of Arizona has an ANNEX terminal server which supports SLIP
and it is provided on a semi-official basis to students, staff and faculty
for the price of $147.50 for unlimited usage per month or 1 cent per second.
I'm not sure what modems are used by UofA Telcom though. 

It used to be an unsupported free service, but administration has jumped on
them, so now they charge.

You can probably mail the Postmaster@arizona.edu for more information.

Disclaimer: I do not speak for the Univ. of Arizona and all these opinions
are mine alone.

-- 
-------------------------------------------------------------------------------
Rawn Shah		RTD Systems & Networking, Inc.
System Consultant	2601 N Campbell Ste 202B, Tucson AZ 85719
rawn@rtd.com		(602) 318-0696  FAX: (602) 318-0695

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20 Jun 1993 01:03:11 GMT
From:      ACU00JTF@UNCCVM.UNCC.EDU
To:        comp.protocols.tcp-ip
Subject:   Super TCP/IP, CUT/CP, NCSA Telnet (need advice)

I am very new to all of this, but my department is looking at using either
CUPCT or SUPER TCP/IP ro access our mainframe.  I have the following
questions regarding these products:
1.  Is CUTCP coming out with a Windows version?  I heard they were and would li
like to verify.
2.  Super TCP/IP will allow you to hot key between mainframe sessions and
pc apps.  Will CUPCP Windows version allow you to do the same?
3.  It has been recommended that we use NCSA Telnet for our Macs.  Does this
also allow hotkeying?
4.  Finally, I would appreciate hearing from anyone who is using these products
-good points, negatives, etc.
Thanks.
 
Judy Freed
Computer System Administrator
Bonnie E. Cone University Center
The University of North Carolina at Charlotte
Charlotte, NC  28223
                                   Phone:  704-547-2267
                                   Internet: ACU00JTF@UNCCVM.UNCC.EDU

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20 Jun 1993 09:08:34 GMT
From:      hmchen@fcom.ee.ntu.edu.tw (Hung-ming Chen)
To:        comp.protocols.tcp-ip
Subject:   Q: how to shorten timeout time

Dear netter;

  In socket library I use connect function to setup a TCP
socket channel to remote site. When the remote site did not
run the server program or it shutdowned, I musr wait for a
long time for the response with connection refuse message.
Could I shorten the period of time out?

Fred Chen

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20 Jun 1993 10:35:12 GMT
From:      jos@bull.nl (Jos Vos)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Equal hostnames for multiple interfaces?

When a system has more than one interface, each with its own
IP address, should the /etc/hosts file than contain the same
hostname for each IP address, or should each IP address has
its own unique name?

-- 
--    Jos Vos <jos@bull.nl>   (UUCP: ...!{uunet,mcsun,sun4nl}!nlbull!jos)
--    Bull Netherlands, Professional Services, Amsterdam, The Netherlands

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 93 14:35:34 GMT
From:      d90-jkr@juodas.nada.kth.se (Johan Krisar)
To:        comp.protocols.tcp-ip,comp.lang.c++
Subject:   Socket++; C++ stream socket library


ANNOUNCE: Socket++ version 0.25 - A C++ stream socket library


What is Socket++?

Socket++ is a simple C++ library for handling stream (TCP) sockets. It
was put together to make network programming easier by surrounding
sockets by an object oriented layer.

This is version 0.25, and should be considered a Beta-version, meaning
there might still be a lot of bugs and nasty inconsistancies in the
package.


Will I be able to use it?

Socket++ has so far been compiled and run on the following platforms:

        Platform:        OS:             Compiler:
        ~~~~~~~~         ~~              ~~~~~~~~
        Sun3            4.3BSD Reno     GNU g++ 2.4.3.1
        Sun4            SunOS 4.1.3     GNU g++ 2.3.2
        Sun4            SunOS 4.1.3     Sun C++ 3.0.1

Please note that templates have been used in several container
classes, so if your C++ compiler does not support templates, some
list-classes will have to be re-written.


How to get it:

As this is the first public version and I don't know if anyone out
there will be interested, I will not put it up for FTP unless
explicitly asked. Instead, mail me at d90-jkr@nada.kth.se, and I will
send you the gzipped and tarred source code (unless you request
otherwise).

Note that Socket++ is distributed under the General Public License,
WITHOUT ANY WARRANTY.


 /// Johan Krisar, Octavus          //                                /
 // d90-jkr@nada.kth.se (Sweden)   //     Did I say 2?  I lied.      //
 / Royal Institute of Technology  //                                ///

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20 Jun 1993 14:56:24 +0000
From:      vadim@cix.compulink.co.uk (Vadim Lebedev)
To:        comp.protocols.tcp-ip
Subject:   Re: sensible routing on host w


In-Reply-To: <paris.740225778@zygon.dev.cdx.mot.com> paris@zygon.dev.cdx.mot.com (Gregory M. Paris)


In article  <paris.740225778@zygon.dev.cdx.mot.com>
   : paris@zygon.dev.cdx.mot.com (Gregory M. Paris)
 writes:
> 
> Here's the basics of our network configuration:  3 buildings; in each,
> a Sun-4/670 (SunOS-4.1.2) NFS server an ethernet interface for each
> subnet in the building; in "parallel" to each Sun, a router, with a
> port on each subnet and, additionally, ports connecting point-to-point
> to other routers.  We're part of a vastly larger corporate network, so
> we've got WAN connections to distant sites as well.  Most traffic
> to/from the Suns is local to the building in question, but inevitably,
> the cross-building traffic and WAN-related traffic to/from the Suns has
> grown.
> 
> The problem: using in.routed (with -q) to manage routes results in a
> single interface being chosen for all remote traffic.  (This is a
> separate problem from the one caused by using NIS or DNS on clients,
> which results in a single interface being preferred by all clients
> because it's first in the list.  I'm not asking about that problem.)
> The result is that there's no balancing of remote network traffic among
> the Sun's interfaces; all remote traffic gets sent to the router, via a
> single interface, dumping all such traffic onto one subnet.  Even
> though the Sun could talk to the same router on each of its interfaces,
> it ends up talking to it over only one.
> 
> I realize now that what we need is to have an interface on each Sun
> dedicated to talking only to the router.  I could turn off in.routed
> and just set a default route to use that interface.  In effect, we're
> sort of going this way anyway, as we're going to be connecting our
> routers and Suns via FDDI.  Unfortunately, we're talking about August
> or September before FDDI is in place.  What that means is getting
> another interface in the short term (i.e., until September) is out.
> The current situation leaves the hosts on the subnet with all the
> remote traffic feeling blue (and the users seeing red).
> 
> Is there a known fix to this problem of dumping all remote traffic onto
> a single interface?  I've got ideas for something I could kludge up,
> but if anybody's solved this problem, I'm willing (twist my arm) to
> accept the benefits of their work. :-)
> 
> Thanks in advance!
> 
> Greg
> 
> -- 
> Greg Paris <paris@merlin.dev.cdx.mot.com>
> Motorola Codex, 20 Cabot Blvd C1-30, Mansfield, MA  02048-1193
> "Your Plastic Pal who's fun to be with." TM Sirius Cybernetics
> 
> 

Greg, 
 I suppose that one possible solution is to install permanent routes,
 to the router on each client machine using 'arp' command...

Vadim.
-----------------------------------------------------------------------
Vadim Lebedev                      |   Kortex International
vadim@cix.compulink.co.uk          |   139-147 av. Paul-Vaillant Couturier
vadim@bix.com                      |   93126 La Courneuve - CEDEX, France



-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20 Jun 1993 15:58:35 GMT
From:      gerryw@hpwin052.uksr.hp.com (Gerry Winsor)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: unknown IP protocol

Samuel Lam (skl@wimsey.bc.ca) wrote:
: In article <1993Jun16.032304.2700@acc.com>, art@acc.com (Art Berggreen) wrote:
: >In article <1993Jun11.200739.2733@clark.dgim.doc.ca> don@mars.dgrc.doc.ca
: > writes:
: >>... I have come across an IP protocol that I cannot decode.
: >>The specific IP protocol I cannot decode is 0x09.
: >
: >	9     IGP         any private interior gateway
 
: Seeing that the IP datagram in question came from a Cisco router,
: I would say that the protocol used in this particular case is IGRP
: (Cisco's proprietory routing protocol).
 
: ...Sam
: -- 
: <skl@wimsey.bc.ca> -- Connectivity Technology Inc.
 
: "NetNews on CD's" product information: <NewsCD@CDPublishing.COM>

Hi Sam, yep, initially I thought IGRP ..... trouble is according to RFC 1340
IGRP is supposed to be IP Protocol 88 !!  Anyone from  Cisco care to comment
on this ??

Confused,
Gerry Winsor,
Network Consultant

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 1993 16:17:10 GMT
From:      hagmanti@cps.msu.edu
To:        comp.protocols.tcp-ip,comp.protocols.ppp,comp.protocols.tcp-ip.ibmpc
Subject:   Re: What universities provide SLIP/CSLIP or PPP services?

In article <rcs1.740179685@crux1.cit.cornell.edu> rcs1@crux3.cit.cornell.edu (R Craig Stevenson) writes:
>I would like to know what universities or colleges currently provide
>(or are in the process of making available) SLIP/CSLIP or PPP
>connectivity to their students, staff and faculty.

I can't speak for all the universities that do, but Michigan State 
University has gone to great lengths very recently to make 
such services availabe to all students, staff, and faculty...

MSU uses a Xylogics 3 Annex Terminal server to provide SLIP and PPP.

>If so, do they provide Mac or PC networking and applications software to the
>students/faculty/staff?

They do not provide software, but it is fairly simple (or was for
me) to get the software via anonyous FTP from any number of sources...

>Approximately how large of a modem pool is provided?  Is there a fee
>for using the high speed modem pool?

I believe that 60 modems (high-speed) are now supported at no charge 
(other than University tuition :), and plans are in the works
for adding another 120-200 2400 baud and 1200 baud connections...

MSU is a university of approximately 40,000 undergrad students...

>Thanks.

You're welcome.

>Craig Stevenson

						Me
--
Disclaimer:  Anything I said, writ, or thought in my life should not
necessarily be held or thought to imply any view, opinion, or idea
of mine, any organization I have chosen to associate  with, or those
people who choose to associate with me. - hagmanti@student.msu.edu

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 1993 16:26:46 GMT
From:      hagmanti@cps.msu.edu
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: unknown IP protocol

In article <1993Jun16.032304.2700@acc.com> art@acc.com (Art Berggreen) writes:
>
>From RFC1060 (Assigned Numbers):

RFC1340 obseletes RFC1060

						Me
--
Disclaimer:  Anything I said, writ, or thought in my life should not
necessarily be held or thought to imply any view, opinion, or idea
of mine, any organization I have chosen to associate  with, or those
people who choose to associate with me. - hagmanti@student.msu.edu

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Jun 1993 05:08:38 GMT
From:      dboyes@is.rice.edu (David E Boyes)
To:        comp.protocols.tcp-ip
Subject:   Re: Sockets on IBM VM ???


somebody at spock.dis.cccd.edu said:

>>We're embarking on a project to exchange data using Berkeley sockets with a
>>remote site running IBM VM.  So I don't remain totally ignorant, could some
>>kind IBM-er please give me a _brief_ outline of how sockets is implemented
>>under VM?

The socket API with FAL 2.2 is very similar to the BSD sockets
library. There are minimal semantic changes - if you're familiar
with BSD sockets, you won't have any trouble.

Someone at AT&T replied:

>CUNY has the RXSOCKET REXX function package, which allows you to code
>socket applications in REXX (since it's interpreted, it's very fast and
>easy to develop an application, then you compile it for production use!).

I can't emphasize this more. RXSOCKET is an absolutely brilliant
piece of work -- using RXSOCKET, we were able to prototype and
field a large network application in a week that took our
colleagues on another platform several months to get to the
testing stage. 

Rumor has it that IBM will be shipping RXSOCKET with the next
major release of FAL. I'm all for it. Now, if they only had it
for OS/2 .... Arty, are you listening?

-- 
David Boyes      In the event I am captured or killed, Rice University
dboyes@rice.edu  and the Office of Networking and Computing Systems
                 will deny any knowledge of my opinions.

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1993 08:42:56 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: unknown IP protocol

In article <C8xGDo.J0w@hpwin052.uksr.hp.com> gerryw@hpwin052.uksr.hp.com
(Gerry Winsor) writes:
    : >	9     IGP         any private interior gateway
    
    Hi Sam, yep, initially I thought IGRP ..... trouble is according to RFC
    1340 IGRP is supposed to be IP Protocol 88 !!  Anyone from Cisco care
    to comment on this ??
    
It's IGRP.  The usage of protocol number 9 predates the allocation of
protocol number 88.

Tony Li
cisco Systems, Inc.


-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 93 10:09:25 GMT
From:      d90-jkr@juodas.nada.kth.se (Johan Krisar)
To:        comp.protocols.tcp-ip,comp.lang.c++
Subject:   Re: Socket++; C++ stream socket library


>  ANNOUNCE: Socket++ version 0.25 - A C++ stream socket library
>
>  What is Socket++?
>
>  Socket++ is a simple C++ library for handling stream (TCP) sockets. It
>  was put together to make network programming easier by surrounding
>  sockets by an object oriented layer.

My apologies to Gnanasekaran Swaminathan, whose name I seem to have
pinched. 'socket++' is already a working product, which you might
access through anonymous FTP from cs.ucl.ac.uk: ~ftp/coside/gnu. It
seems I will have to come up with another name. Thanks to Gordon Joly
for setting me straight so soon.

The original 'socket++' can be described as a C++ incapsulation of
stream and UNIX sockets and pipes. The package announced here is
different, in that I have tried to create objects to hide network
calls to internet stream sockets, thereby implementing a layer of
abstraction around the networking part of a program. This might come
in handy when developing a 'Client-Serv:ish' application from scratch,
but might require major changes if you already have a working
application.

I'll repeat that requests for the announced package can be made by
mailing d90-jkr@nada.kth.se.

Regards:

- Johan

 /// Johan Krisar, Octavus          //                                  /
 // d90-jkr@nada.kth.se (Sweden)   //     Did I say 2?  I lied.        //
 / Royal Institute of Technology  //                                  ///

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 93 11:12:28 GMT
From:      christoh@microsoft.com (Christoph Hochstaetter)
To:        comp.os.ms-windows.programmer.win32,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Re: NT networking across routers

In article <C8u1zr.1u0@usenet.ucs.indiana.edu> jwd@stone.ucs.indiana.edu wrote:
> 
> Is it possible to use NT's peer-to-peer networking with
> NetBIOS-over-IP on a routed network?  I've taken a look at RFC's 1001
> and 1002 on NetBIOS over IP and done a bit of sniffing of the IP
> traffic produced by the March beta of NT, and it seems that NT is
> operating as a "B node" (in RFC 1001 terminology), and therefore would
> not be able to make use of NetBIOS name servers and NetBIOS datagram
> distribution servers to do NetBIOS between machines on IP subnets.
> 
Currently, you must have a valid LMHOSTS file to do NETBIOS-Networking
over TCP/IP.

Christoph

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1993 17:55:38 -0400
From:      mike@meiko.com (Mike Stok)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?

In article <C8x1Eq.Mu7@bull.nl> jos@bull.nl (Jos Vos) writes:
>When a system has more than one interface, each with its own
>IP address, should the /etc/hosts file than contain the same
>hostname for each IP address, or should each IP address has
>its own unique name?

It's a useful idea to give each interface the same canonical name, but to
have an alias which you can use to refer to a specific interface should
you ever need to diagnose problems.  For example, one of our hosts has 3
interfaces and the hosts file entries look like:

192.131.107.19  nelson nelson-le0       # mk401
192.233.56.249  nelson nelson-le1
192.233.57.254  nelson nelson-le2

This you can address each interface by name if necessary and users only
have to remember one name, and if you ever put it into DNS then the "right
thing" will happen...

Mike
-- 
The "usual disclaimers" apply.    | Meiko
Mike Stok                         | Reservoir Place
Mike.Stok@meiko.waltham.ma.us     | 1601 Trapelo Road
Meiko tel: (617) 890 7676         | Waltham, MA 02154

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Jun 1993 11:51:33 GMT
From:      karl@netcom.com (Karl Nicholas)
To:        comp.protocols.tcp-ip,comp.protocols.ppp,comp.sys.sun.misc
Subject:   Re: Dedicating a Sun as a central SLIP/PPP server ??


	 Hello all you netters 

	I am running the old free ware PPP on a sun sparc 10 with
sunos 4.1.3, and am having no major problems other than ...

	Seems when I go home and come back in in the morning, I cannot
do an rlogin or telnet to the other machine. Ping says that machine
is alive and well, but alas, no rlogin. There is mail sometimes
going between the sites, via SMTP, but I have not attempted to determine
if this works or not "in the morning". Shutting down the ppp connection
and starting it up again fixes things.

Setup:

sparc10: sunos 4.1.3 -> /dev/cua0 @ 38400 ->US/Robotics ///
sparc 2: sunos 4.1.2 -> /dev/cua0 @ 38400 ->US/Robotics
ppp : ppp-sunos4.1.pl6.tar.Z

I am having the sparc 10 call the sparc 2, login to a Pkarl account ...

Any suggestions/clues would be a help. I have not in the past attempted
to keep a ppp link running ad infinitum.

Caveat: Have but have not yet installed SUN version of PPP. Do you
think this would work better than the PPP freeware version?


-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Jun 1993 13:39:58 GMT
From:      siva@bnr.ca (Siva Arunthavanathan)
To:        comp.protocols.tcp-ip
Subject:   need example code for Read and Write in Sockets

Hi everyone!

I am looking for some typical read and write procedures in the
client-server archtecture (TCP-IP domain). If anyone has similar example
code, would you please post as a reply to me (I don't have access to
external mail yet). 

Thanks in Advance

Siva Arun

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Jun 1993 14:35:27 GMT
From:      pwilson@world.std.com (Pete Wilson)
To:        comp.unix.programmer,comp.sys.att,comp.unix.internals,comp.unix.misc,comp.unix.sys5.r4,comp.protocols.snmp,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Re: How to do ioctl()s on a socket in SVR4?

In article <1vtbu7$pp3@bradley.bradley.edu> guru@camelot.bradley.edu (Jerry Whelan) writes:
>	I'm working on porting the CMU snmp agent to our AT&T SVR4
>machines and have run into a major problem.

PFA, Inc. distributes a reference port of its UNIVERSAL SNMP AGENT to SVR4/386
platform as part of the product. Our educational discount is 100% :).
It is free for universities.

>there are at least two seperate tcp/ip products (Wollongong
>and Lachman)

Our refernce port is performed for SVR4/386 with Lachman Streams TCP/IP.

>-------------------------------------------------------------------------------
>``written by a drunken insane pathological liar''        guru@stasi.bradley.edu

If you (or anybody) are interesting, Drop me a line.

Pete


-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 93 15:08:35 GMT
From:      devdjn@space.alcbel.be (Dennis Newport)
To:        comp.protocols.tcp-ip
Subject:   Silly Window Syndrome


Some time ago I saw an article in one of the magazines about the
Silly Window Syndrome. I can't see to find it now and most of the
documentation that we have doesn't really talk about it too much.

I would appreciate any input that the group has on this. We
essentially understand the problem but if anyone has any experience
of this, especially in connection with using TCP_NODELAY, then we
would be grateful.

---
Dennis Newport,                  email: devdjn@space.alcbel.be
Alcatel Bell Telephone,
Berkenrodelei 33,                phone: (+32) 3/829.5488
2660 Hoboken,
Belgium.


-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 93 15:13:00 GMT
From:      rhee@sgtech.UUCP (tai rhee)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   needs TCP/OLTP, Ideas for reverse TELNET


Dear UNIX and TCP Engineers :

I am looking for a solution to connect a specific pseudo tty of the host
to RS-232 port of a terminal server.  

I heard that HP, Wollongong and Datability submitted Telnet/OLTP protocol
to the Internet Engineering Task Force.  Do you think it has pseudo tty
capability?  How can I get a copy of it? How can I join the IETF activity?

If I have to write unix drivers to solve this problem, I like to write the 
following drivers.
  PROTOCOL
    TCP_MUX_DATA port(s):
      <packet> = <header> <pdata>
      <pdata>  = <pdatum> [ <pdatum> ]
      <pdatum> = <tty_number> <byte_size> <telnet_data>
    TCP_MUX_CONTROL port(s):
      <read_remote_capability>
      <read_remote_tty_table>
      <write_remote_tty_table>
  HOST_tty_table
    remote ip, remote rs-232 number, remote session number <=> tty_number
  Remote_tty_table
    host ip, tty_number <=> remote rs-232 number, remote session number

This (de)mux works like LAT with the gateway capability.
I like to hear any your idea about this.

Thanks in advance.
Tai Rhee
Internet: rhee@sgtech.com
-- 
Tai Rhee (adnan@sgtech.com)
Star Gate Technologies
29300 Aurora Rd, Solon, OH, 44139, USA, +1 216 349 1860

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 93 15:21:02 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   RFC 1191 compliance


	There was a question posted here recently regarding the fact
	that Solaris 2.2 uses RFC 1191 to obtain the most efficient
	Path MTU (PMTU).  I wasn't aware that all systems (routers
	especially) conformed to RFC 1191...I thought it was still a
	draft internet standard?  Can anyone confirm this ?  

	Thanks!
		Randy

-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Jun 93 14:56:03 BST
From:      bwhittak (Brian Whittaker)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Solaris 2.2: obscure TCP/IP difference

|See RFC1191, "Path MTU Discovery."  Solaris 2.2 apparently implements
|the mechanism described in that RFC, which currently has the status
|of "Draft Standard."

Both 2.1 and 2.2 implement Path MTU Discovery.

|>Anyway, we only noticed this trivia because we have an Abekas digital frame
|>store that ignores all traffic from just those four Solaris hosts, and the
|>DF flag is the only difference I can see. Its firmware is pretty old, so I
|>lean towards blaming it.

We were recently bitten by the same problem with Solaris and our Cisco router.
It turns out that if you set "ip nounreachables" in the Cisco config (which we
have for reasons beside the immediate point which I am pursuing with the
maintainers of our box) you also turn off Path MTU Discovery support.  Typical
symptoms include TCP with the Solaris machine getting established OK, then
hanging as soon as the Solaris has any significant data to send (we first
noticed it with mail SMTP).

|Solaris should let you turn off Path MTU Discovery.  Contact SunWhatever
|to find out about that.

Only 2.2 - you do it like this (and put it in some appropriate place to be done
at every bootup):

	ndd -set /dev/ip ip_path_mtu_discovery 0

			Brian

 | Brian Whittaker, Computervision, High Wycombe, HP11 1JU, UK      |
 | bwhittak@cvedg.CV.COM                phone: +44 494 474477 x 321 |
 | bwhittak@uk.co.cv.edg                  fax: +44 494 440303       |

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Jun 1993 15:59:09 GMT
From:      billn@netmanage.com
To:        comp.protocols.tcp-ip
Subject:   Suns Talk Protocol


Hello,
	Does anybody know where I could get the specification if it exists of
Suns  Talk program.  Thanks.


Bill Nolde		NetManage
billn@netmanage.com	20823 Stevens Creek Blvd.
			Cupertino, CA. 95014
			phone (408)-973-7171
			fax   (408)-257-6405



-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 93 17:18:10 GMT
From:      michaelg@Xenon.Stanford.EDU (Michael Greenwald)
To:        comp.protocols.tcp-ip
Subject:   Re: Silly Window Syndrome

devdjn@space.alcbel.be (Dennis Newport) writes:


>Some time ago I saw an article in one of the magazines about the
>Silly Window Syndrome. I can't see to find it now and most of the
>documentation that we have doesn't really talk about it too much.

Have you looked at RFC 813?  I'm not sure how helpful it will be, but
it's a start.

>I would appreciate any input that the group has on this. We
>essentially understand the problem but if anyone has any experience
>of this, especially in connection with using TCP_NODELAY, then we
>would be grateful.

TCP_NODELAY shouldn't affect Silly Window Syndrome, since the system
will still send out all the buffered data when it does send.
TCP_NODELAY can introduce other lossage, (i.e. clogging a slow line
with small packets (and relatively large headers)).

>---
>Dennis Newport,                  email: devdjn@space.alcbel.be
>Alcatel Bell Telephone,
>Berkenrodelei 33,                phone: (+32) 3/829.5488
>2660 Hoboken,
>Belgium.


-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Jun 1993 17:19:36 GMT
From:      rhealey@ssesco.com (Rob Healey)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Solaris 2.2: obscure TCP/IP difference

In article <1993Jun18.151559.21255@cs.brown.edu>, rws@cs.brown.edu (Richard W. Sabourin) writes:
|> We have a few Solaris 2.2 hosts (all Model 41's) on our mostly-Sun network
|> here in the CS department. I notice that they set the IP Don't Fragment (DF)
|> bit in _every_ packet they send. (tcpdump is god!) Scanning some of the
	
	Since you have Solaris 2.2 snoop might yeild more information on
	packets of all sorts than tcpdump. See snoop man page for details.

	-Rob

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1993 18:02:28 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?

In article <C8x1Eq.Mu7@bull.nl>, jos@bull.nl (Jos Vos) writes:

| When a system has more than one interface, each with its own
| IP address, should the /etc/hosts file than contain the same
| hostname for each IP address, or should each IP address has
| its own unique name?

We used to use separate names for each interface, but changed
to using one hostname for all interfaces.  The point of a hostname
is to gloss over ephemeral physical details of network connectivity.
As interfaces will change around more frequently than (logical)
hosts, it makes sense to present the single hostname to users.

When there's a need to talk to a specific interface (which is very
rare, in my experience), you can always just use the IP address.

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 93 18:55:05 GMT
From:      karthik@informix.com (Karthikeyan Guruswamy)
To:        comp.protocols.tcp-ip
Subject:   UUNET naming conventions ...


Hi,
Where can I find documentation on UUNET naming conventions ?
I checked up the RFC list and I believe it has something to
do with UNIX mostly (I know little about UNIX networking
scenario). Any pointers most welcome ..

Karthik
---------------------------------------------------------------
Karthik						Why doesn't my
Infosoft Inc, (Contractor to INFORMIX Inc.)	NET WORK ?
Cupertino, CA

All the views expressed here are solely mine and they dont 
represent those of my organization.
---------------------------------------------------------------

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1993 19:02:16 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1191 compliance

In article <rturner.740676062@imagen> rturner@imagen.com (Randy Turner) writes:
    
    	There was a question posted here recently regarding the fact
    	that Solaris 2.2 uses RFC 1191 to obtain the most efficient
    	Path MTU (PMTU).  I wasn't aware that all systems (routers
    	especially) conformed to RFC 1191...I thought it was still a
    	draft internet standard?  Can anyone confirm this ?  
    
MTU discovery is (as of RFC 1360) a proposed standard.  Many router vendors
rely on customer input rather than standards track progress for
implementing features.

Tony


-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Jun 1993 19:26:07 GMT
From:      gulik@rtsg.mot.com (Gregory Gulik)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   TLI


Are there any TLI experts out there?

I have a couple questions about it.

1.  Is TLI any faster than sockets, in general, and specifically on
    a 3B2 running System V.3.2

2.  Is there a way, using TLI, to do the equivalent of a select
    on more than 1 file descriptor?  My specific application will
    be watching a serial port and a socket.  I looked in the Stevens
    book and couldn't find what I need.

Thanks.

-greg

-- 

gulik@rtsg.mot.com  (Gregory Gulik)  [NeXT]

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Jun 1993 19:48:11 GMT
From:      M21816@MBVM.Mitre.Org (Paul Campbell)
To:        comp.unix.misc,comp.protocols.tcp-ip,comp.lang.perl
Subject:   lpd to ftp filter

hi all,
 
i am interested in obtaining information regarding a FTP filter i am
planning for LPD.  i would like to provide remote job submittal to
our MVS machine from various Unix environments.  in my preliminary
tests i have found a way to drive the UNIX FTP package using Perl but
i am not sure of the kinds things i should be sensitive to regarding
the interface with LPD.  it is my understanding that it should be
possible to drive processes other than printing with LPD.  in my
scheme i would like to add a printer that would use my output filter
to drive the FTP connection.
 
Ideally, i would like the filter to be a Perl script (or maybe
envelope the script in a more secure "C" driver) but i am open to
suggestions.  i plan to have a dummy device (:lp=/dev/null), a
spooling directory, the output filter and a logging file as part of the
printcap entry.  can anyone think of any problems with doing this?
many thanks /pc

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Jun 1993 21:39:56 GMT
From:      heimlich@watson.ibm.com (Steve Heimlich)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1191 compliance

In article <rturner.740676062@imagen> rturner@imagen.com (Randy Turner) writes:
>
>	There was a question posted here recently regarding the fact
>	that Solaris 2.2 uses RFC 1191 to obtain the most efficient
>	Path MTU (PMTU).  I wasn't aware that all systems (routers
>	especially) conformed to RFC 1191...I thought it was still a
>	draft internet standard?  Can anyone confirm this ?  
>
>	Thanks!
>		Randy

According to RFC 1410, the latest IAB Official Protocol Standards RFC,
1191 is currently a Draft Standard.  1191 does address backward 
compatibility issues, however, and a reasonable implementation will
allow PMTU discovery to be disabled (as suggested in the text) on a
per route basis.

Steve


-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 93 22:05:45 GMT
From:      pccl@cbnewsd.cb.att.com (paul.c.liu)
To:        comp.protocols.tcp-ip
Subject:   tcpdump for solaris 2.x

I am looking for the "latest" tcpdump 
that will run on Solaris 2.x (i.e. SVR4)
SPARC platforms.  An attempt in running 4.x style
as is resulted "Bad system call".

Pointers are appreciated!

Paul.LiuATT.COM

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Jun 1993 22:17:25 GMT
From:      richk@grebyn.com (Richard Krehbiel)
To:        comp.unix.pc-clone.32bit,comp.protocols.tcp-ip
Subject:   Re: ISC TCP 1.3, PCRoute and segment size

In article <1993Jun18.221037.4882@chico.iecc.com> johnl@chico.iecc.com (John R. Levine) writes:

>   >I'm rather sure that the culprit is the NE2000 card, or rather the
>   >ISC TCP/IP driver for this card. ...
>   >Just try a WD8003 (8-bit) or WD8013 (16-bit) ethernet card. This did it
>   >for me. I'm sure that your problems will go away, too.
>
>   Here's a counter-data-point: I also use ISC TCP 1.3 with packets passing
>   though a pair of PCROUTE pc's to get to the outside world.  I was having
>   problems with strange long pauses and attributed it to the NE2000 card.
>   So I yanked it out and put in a WD8003E card instead.  With the WD8003E
>   card, TCP worked great for about 15 seconds, then hung (not the whole
>   system, just the network connections.)  I put the NE2000 card back in
>   another slot and now it seems to work OK.

I had this same problem when I installed ISC TCP/IP version 1.3.
netstat would show a certian number of packets transferred, then it
all came to a halt.  I solved it by reducing by half the amount of
shared memory configured for the board.  Apparently the default
configuration is for the 8013 board, a 16 bit card with 16K of shared
memory, whereas the 8003 only has 8K.

>   I have no idea what the problem with the WD card is.  The card is OK: it
>   passes the SMC diagnostics and works OK in another PC with PC-NFS.  Earlier
>   versions of Lachman TCP worked OK with another WD8003E card.

If you have a chance, check the shared memory size with kconfig.
-- 
Richard Krehbiel                                 richk@grebyn.com
OS/2 2.0 will do for me until AmigaDOS for the 386 comes along...

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Jun 1993 22:37:51 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.unix.pc-clone.32bit,comp.protocols.tcp-ip
Subject:   Re: ISC TCP 1.3, PCRoute and segment size

> johnl@chico.iecc.com (John R. Levine) writes:
>
>Here's a counter-data-point: I also use ISC TCP 1.3 with packets passing
>though a pair of PCROUTE pc's to get to the outside world.  I was having
>problems with strange long pauses and attributed it to the NE2000 card.
>So I yanked it out and put in a WD8003E card instead.  With the WD8003E
>card, TCP worked great for about 15 seconds, then hung (not the whole
>system, just the network connections.)  I put the NE2000 card back in
>another slot and now it seems to work OK.
>
>I have no idea what the problem with the WD card is.  The card is OK: it
>passes the SMC diagnostics and works OK in another PC with PC-NFS.  Earlier
>versions of Lachman TCP worked OK with another WD8003E card.

Yes the card is probably alright, you have a buggy driver.

If you were using PCROUTE with the 8003PKDR packet driver, simply download
the CRYNWR packet driver named WD8003.COM, it solves the problem.

Western Digital released a packet driver which did not block whilst 
sending packets, so two packets in quick succession would confuse 
the card and it would be useless for about a second or so and then
recover.

Erick
-- 


-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Jun 1993 23:32:51 GMT
From:      rhealey@ssesco.com (Rob Healey)
To:        comp.protocols.tcp-ip
Subject:   Re: tcpdump for solaris 2.x

In article <C8zs1p.352@cbnewsd.cb.att.com>, pccl@cbnewsd.cb.att.com (paul.c.liu) writes:
|> I am looking for the "latest" tcpdump 
|> that will run on Solaris 2.x (i.e. SVR4)
|> SPARC platforms.  An attempt in running 4.x style
|> as is resulted "Bad system call".
|> 
|> Pointers are appreciated!

	Use the snoop command under Solaris 2.x. See man page. It is VERY
	complete and has most if not all of the fuctionality of tcpdump.

	-Rob

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1993 23:34:23 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1191 compliance

In article <rturner.740676062@imagen> rturner@imagen.com (Randy Turner) writes:
>	There was a question posted here recently regarding the fact
>	that Solaris 2.2 uses RFC 1191 to obtain the most efficient
>	Path MTU (PMTU).  I wasn't aware that all systems (routers
>	especially) conformed to RFC 1191...I thought it was still a
>	draft internet standard?  Can anyone confirm this ?  

According to RFC 1360, the latest "IAB OFFICIAL PROTOCOL STANDARDS" RFC,
Path MTU is in the Proposed Standard state with Elective status.  But
proposed standards generally don't move up the standards track unless
people actually try to use them (the whole point of proposed and draft
standards is to encourage people to implement them before they're cast in
stone).

Hosts that use PMTU discovery don't require that the routers implement the
"Next-Hop MTU" extension in RFC 1191.  That extension makes PMTU more
accurate and efficient, but hosts can get by without it, and RFC 1191
explicitly mentions this:

   Hosts MUST be able to deal with Datagram Too Big messages that do not
   include the next-hop MTU, since it is not feasible to upgrade all the
   routers in the Internet in any finite time.  A Datagram Too Big
   message from an unmodified router can be recognized by the presence
   of a zero in the (newly-defined) Next-Hop MTU field.  (This is
   required by the ICMP specification [7], which says that "unused"
   fields must be zero.)

The PMTU discovery protocol was designed to allow interoperability between
hosts and routers that don't agree on their conformance.  There could be
problems if an old-style host (erroneously) rejects a "Datagram Too Big"
message with a non-zero "unused" field (which is now used for the Next-Hop
MTU field).

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1993 00:51:50 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1191 compliance

To clear up some confusion: on 8 March 1993, RFC1191 was advanced from
Proposed Standard to Draft Standard, along with a little extra advice:

  The IESG has approved the Internet Draft "Path MTU Discovery" RFC1191
  as a Draft Standard. This document is the product of the concluded
  MTU Discovery Working Group. The IESG recommends that a companion
  document "IESG Advice from Experience with Path MTU Discovery"
  describing operational experience with the protocol in the Internet
  be published as an Informational document. The IESG contact persons
  are Philip Almquist, Stev Knowles and Dave Piscitello.

That "advice" was published as RFC1435.

According to the rules as I understand them, RFC1191 is eligible to
be advanced to Standard in September 1993.  I have heard little
negative comment on the design, so I expect this will happen more
or less on schedule.

-Jeff

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 93 08:35:20 CDT
From:      leung@turtle.fisher.com
To:        comp.protocols.tcp-ip
Subject:   socket and select limits

        1a Can anyone tell me how to find out the maximum amount
           of sockets that can open at the same time, in a process
           or overall? Is there a .h file for this?
           Can this limit be modified?

           If there are no general answers, I would welcome any hints
           for a specific system.

        1b Any figures that illustrate the effect of
           having many sockets open at
           the same time? or, can anyone point me to a book or a study?

        2a A similar question: is there a way to
           find out (preferably during run-time) the
           maximum number of file descriptors that can be tested by
           select()? Again, is this limit configurable?

        2b Any performance figures, when select()
           has to test many file descriptors?

        Appreciate your answers


-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 93 08:43:48
From:      towfiq@Microdyne.COM (Mark Towfiq)
To:        comp.protocols.tcp-ip
Subject:   Re: Project= c/c++ plus nw/tcp/ip

>>>>> On 22 Jun 1993 03:48:47 GMT, vsrangan@whale.st.usm.edu (Vidya
>>>>> Sagar Ranganathan) said:

vsr> Hello netters, I am a CS grad student.  I am looking for a
vsr> project kind of stuff to do on and familiarize with tcp/ip and
vsr> networking aspects.  I would also like to work on c++/c.

  Since you mentioned TCP/IP and C++, why don't you pull down the
Berkeley NET-2 release and see how the protocol code could be moved to
a C++ architecture, defining classes like "protocol" which would
advertise functions like PacketIn(), PacketOut(), IOCtl(), etc.... you
would learn about TCP/IP really quick that way ...

Mark
--
Mark TOWFIQ | Business/Urgent: towfiq@Microdyne.COM  +1 508 392 9953 (fax 9962)
	    | Other:   towfiq@Justice.Medford.MA.US  +1 617 488 2818

"The earth is but one country, and mankind its citizens." -- Baha'u'llah

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1993 03:48:47 GMT
From:      vsrangan@whale.st.usm.edu (Vidya Sagar Ranganathan)
To:        comp.protocols.tcp-ip
Subject:   Project= c/c++ plus nw/tcp/ip

Hello netters,
I am a CS grad student.  I am looking for a project kind of stuff to do
on and familiarize with tcp/ip and networking aspects.  I would also like
to work on c++/c.

Available resources: RS/6000 runnin Aix v3.1 and two other m/c running
SVr4.  We do not have any network environment dedicated for research 
purposes.  All I have is the access to the internet. Since there is not
much research going on right now, I am running out of topics.

My basic idea is to get a good exposure on network and c++ programming.

Some of the ideas I thought about are:(comments expected!!)
1. Implementing a keyword search in the archie which searches for keywords
   in the 'readme' files at different sites.  This, along with the regular
   archie search would give us a better report.
2. Adding a file search facility to the fsp and build an integrated user
   interface for the archie and the file transfer clients using curses.
   (enabling the ascii terminal users to be benefited)

I would highly appreciate anyone who could throw some light on other small
projects in the areas I had mentioned above.  
Thank You in Advance

vidya 

Vidya Sagar Ranganathan
vsrangan@whale.st.usm.edu

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 93 05:34:27 GMT
From:      alex@netdev.comsys.com (Alex Huppenthal)
To:        comp.protocols.tcp-ip,bit.listserv.ibmtcp-l,bit.listserv.ibm-nets
Subject:   Survey Questions for ProTools - ProTools plants a tree

Dear network manager:

I've attached the following survey for your consideration. As compensation
for filling this form out and sending it back, ProTools, a 
Pacific NW startup will plant a tree.  (up to a maximum of 500 trees). 
Save a tree, email the filled out form back instead of paper mail. 

Please return to:  ProTools Customer Survey
14976 NW Greenbrier Parkway, Beaverton, OR 97006

---------------------------------------------------------------------------





 Survey attached

---------------------------------------------------------------------------
 

ProTools is conducting a survey of network users and would like your 
input.  Please complete this survey about your organization's use of 
network analysis products or pass it on to the person in charge of 
network management and troubleshooting.  Thank you.

	Name	_____________________________________________________________
	Address	_____________________________________________________________
		_____________________________________________________________
		_____________________________________________________________
	Phone	_____________________________________________________________
	Fax	_____________________________________________________________


Assume:  A network is defined as the physical segment between routers 
and/or bridges.  

1.	(a) Number of users you're supporting: ____________________
	(b) Number of networks you are responsible for:  ___________
	(c) Typical size of each network (by # nodes, devices, etc.):  
________________
	(d) Are these networks interconnected (e.g., attached to a 
backbone)?  _______

2.	How large is your organization?
	(a) Department size	________________________
	(b) Division size	________________________
	(c) Entire organization	________________________

3.	(a) What are your organization's main lines of business?
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________

	(b) What are your department's key business goals for the next 12-
15 months?
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________

4.  Does your organization use or plan to use one of the leading 
network management platforms?

	(a) ___ Already use  
		___ HP OpenView	___ SunNet Manager   
		___ NetView/6000	___ UB NetDirector	
		___ Other _________________________
  
	(b) ___ Plan to use
		___ HP OpenView	___ SunNet Manager   
		___ NetView/6000	___ UB NetDirector	
		___ Other _________________________

 
5.  What products to you actively use to monitor, troubleshoot and 
analyze these networks? (Check all that apply.)

	___ ProTools Foundation Manager
	___ ProTools Cornerstone Agent
	___ Network General Sniffer (portable)
	___ Network General Distributed Sniffer 
	___ Novell LANalyzer
	___ Novell LANtern
	___ Hewlett-Packard NetAdvisor
	___ Hewlett-Packard LANprobe
	___ Metrix Netmetrix
	___ Frontier Netscout
	___ Concord Trakker
	___ Triticom
	___ Other ______________________


6.  Use of ProTools Products
	(a)	How many ProTools products are currently in use at you 
organization?
	___ # Foundation Manager	___ # Cornerstone Agent
	(b)	For how long have you been a ProTools customer? 
____________________
(c)	How often do you use the products?
	___ Every day	___ Once a week
	___ Once a month	___ Less than once a month

(d)	Are you using the products in a distributed fashion (i.e., 
monitoring remote networks from a central location) or are you 
using them as standalone analyzers (monitoring a single network at 
a time)?
___ Distributed	___ Stand-alone	___ Both


7.  What topologies are you supporting currently? (Ethernet, Token 
Ring, FDDI, etc.)	
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________


8.  Explain how you most use the ProTools products in each of the 
following areas:

(a) Baselining (Capturing a representation of 'normal' behavior, 
setting 'normal' thresholds, etc.):
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________

(b) Ongoing Monitoring (Continuous monitoring of performance and 
threshold variables):
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
 
(c) Troubleshooting and Analysis (Protocol decoding, searching for 
problems, etc.):
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________

(d) Reporting (On-screen and written reports of network behavior):
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________

(e) Load Simulation (Traffic generation to test network behavior 
under various scenarios):
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________

(f) Network Consultant, Online Help, Online Reference Guide:
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________

(g) Written Documentation (Getting Started Guide, User's Guide, 
Reference Guide, Using NetDirector with NCS Products)
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________

9.	(a) What problem have you recently solved with a network analyzer?
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________

	(b) How much do you think it saved your organization (in $$, time, 
efficiency, productivity)  
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________


10.  What are the three most common types of events or problems you 
encounter or monitor for on a regular basis.  Think of these as your 
biggest headaches.  (e.g., duplicate IP addresses)

(a)__________________________________________________________________
_
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________

(b)__________________________________________________________________
_
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
 
(c)__________________________________________________________________
_
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________


11.  On a scale of 1 to 5, where 1=Very Important and 5=Not 
Important, rate the following in terms of importance to your 
organization in purchase decision for network monitoring and analysis 
products:
	Very	Somewhat	Not
	I M P O R T A N T	

Performance Monitoring
a.	Able to do real-time and post-capture	1	3	5
	analysis
b.	Able to generate a baseline of 		1	3	5
	statistics 
c.	Able to generate Mac layer statistics	1	3	5
d.	Able to generate application layer 	1	3	5
	statistics
e.	Able to set thresholds and alarms	1	3	5
f.	Able to perform response time analysis	1	3	5
g.	Able to perform long term trend analysis	1	3	5
h.	Able to measure internetwork		1	3	5
	 performance corresponse time

User Interface and Ease of Use
g.	Graphical user interface (GUI)		1	3	5
h.	Able to import/export data to other	1	3	5
	applications
i.	Online help system			1	3	5

Platforms and Standards
j.	Integration with other network mgmt 	1	3	5
	platforms (e.g., HP OpenView, SunNet Manager)
k.	Support for standards (e.g., SNMP, CMIP)	1	3	5
l.	Supports a distributed environment	1	3	5
m.	Support for Unix	1	3	5
n.	Support for Windows 3.1	1	3	5
o.	Support for Windows/NT	1	3	5
p.	Support for OS/2	1	3	5
q.	Support for DOS	1	3	5
r.	Support for Macintosh	1	3	5

Fault Management
s.	Able to diagnose hardware failures	1	3	5
t.	Able to diagnose applications failures	1	3	5
u.	Able to solve multi-segment problem	1	3	5

Configuration Management
v.	Able to connect/disconnect devices 	1	3	5
	from the network from a single location
w.	Able to configure devices	1	3	5

Troubleshooting and Analysis
x.	Able to decode most popular protocols 	1	3	5
	through layers 1-4
y.	Able to decode most popular protocols	1	3	5
	through layers 1-7
z.	Able to find events/problems 	1	3	5
	automatically
aa.	Allows users to customize which events 	1	3	5
	they consider "problems" to search for	1	3	5
bb.	Recommends solutions to problems	1	3	5
 
Reporting
cc.	Generates reports on-line	1	3	5
dd.	Generates printed reports	1	3	5
ee.	Allows report data to be manipulated by 	1	3	5
	other applications (e.g., spreadsheets)
ff.	Supports generation of reports over time 	1	3	5
	(e.g., trend analysis reports, history logging)
gg.	Supports method of charge-back or cost 	1	3	5
	 accounting based on network usage

Inventory Management
hh.	Able to discover nodes/devices on the 	1	3	5
	network
ii.	Able to map Mac addresses to network 	1	3	5
	addresses or names

Other
jj.	Company reputation	1	3	5
kk.	Product reputation	1	3	5
ll.	Price	1	3	5
mm.	Potential savings to company	1	3	5
nn.	Customer support 	1	3	5
oo.	Installation and training	1	3	5
pp.	Customizability	1	3	5


12.  Which three of the above characteristics (or any others you may 
think of) are most important to your departmental/division goals when 
purchasing products of this type?
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________


13.  In what areas would you like to see ProTools products improved?
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________


14.  For your ProTools products, which adapters are you using?
	Ethernet
3Com:	___ 503 (EtherLink II)	___ 507 (EtherLink 16)
	___ 523 (EtherLink/MC)
Novell/Eagle:	___ NE2000	___ NE/2
	___ NE3200
Ungermann-Bass:	___ NIUpc	___ NIUpc/EOTP
		___ NIUps	___ NIUps/EOTP
		___ EtherNext NIC-16 	___ EtherNext NIC-MC
		(NetWorth)		(NetWorth)
Racal-Datacom:	___ NI9210-10BT	___ ES3210
SMC (Western Digital):	___ SMCLAN-EPRE	___ SMCLAN-E10T
	___ SMCLAN-ET16	___ SMCLAN-ET16C
		___ SMCLAN-EP/A	___ SMCLAN-E10T/A

	Token Ring Adapters
Compaq:	___ 16/4 Mbps Dual Speed Token Ring Controller 
IBM:	___ 16/4 Mbps Trace and Performance (TAP)
Olicom:	___ 16/4 Mbps OC 3104 (Pkg # OC3115)
		___ 16/4 Mbps OC 3138 (Pkg # OC3129)
		___ 16/4 Mbps OC 3139 (Pkg # OC3133)
Proteon:	___ P1347 (4 Mbps)	___ P1840 (4 Mbps)
 
Racal-Datacom:	___ 16/4 Mbps 625-0138-00	___ 16/4 Mbps 163-
3136-00
Racore:	___ 16/4 Mbps M8113	___ 16/4 Mbps M8114
			___ 16/4 Mbps M8113	___ 16/4 Mbps M8116 
RAD:	___ 16/4 Mbps TRIC-16/AT	___ 16/4 Mbps TRIC-16/XT 
		___ 16/4 Mbps TRIC-16/MCB
Ungermann-Bass:	___ Access/ISA 16/4 Mbps	
			___ Access/MC 16/4 Mbps
		___ Access/EISA 16/4 Mbps

Wireless Adapters
NCR:	___ WaveLAN (ISA)

Broadband Adapters
IBM:	___ Network Adapter II MCA
Ungermann-Bass:	___ 3270 NIUpc Broadband
			___ NIUps Broadband


15.	Some of these adapters are no longer supported by their 
manufacturers and some do not support all of the standard 
functionality required for network analysis.  There is a practical 
limit to the number of adapters ProTools can adequately support, and 
newer, faster adapters are being introduced to the market regularly.  
In order for ProTools to add support for new adapters, it is likely 
that we will soon have to drop support for the least popular 
adapters.  

(a)	For which of the adapters you're currently using would 
you feel comfortable if ProTools dropped support?
_________________________________________________________
_________________________________________________________
_________________________________________________________
_________________________________________________________

(b)	For which adapters is it critical for ProTools 
to continue to support?
_________________________________________________________
_________________________________________________________
_________________________________________________________
_________________________________________________________


(c)	Which adapters would you like to see ProTools support in 
the future?  (Be as specific as possible.)
_________________________________________________________
_________________________________________________________
_________________________________________________________
_________________________________________________________



16.  Would you be interested in purchasing Foundation Manager or 
Cornerstone Agent if they were available on other operating system 
platforms?  If so, which platforms are of interest to you?
	___ DOS	___ Windows 3.1	___ Windows/NT
	___ Unix	___ Macintosh	
	___ Other ____________________

 
17.  Would you be interested in becoming a beta test site for future 
ProTools releases?

	___ Yes	___ No
	
	If "yes," 	
	___ I would like to test new functionality (e.g., expert analysis 
capability)
	___ I would like to test the products on new platforms
	___ DOS	___ Windows 3.1	___ Windows/NT	___ Unix


18.	Product Training:
	(a)	Have you taken, or are you planning to take ProTools training 
courses?
	___ Yes	___ No
	___ Planning to take 	___ Not planning to take
	(b)	Have you received training on other network analysis products?
	___ Yes	___ No


19.  Customer Support:
	(a)	How many times have you contacted our Customer Support 
department?
	___ Never	___ Once
	___ 2-5 times	___ More than 5 times

(b)	How many contacts with the Customer Support team does it 
typically take before your questions are resolved?
	___ Never	___ Once
	___ 2-5 times	___ More than 5 times

	(c)	How would you describe the timeliness with which your issues 
are resolved?
	___ Excellent	___ Good
	___ Fair	___ Poor
	___ Very poor

	(d)	How would you describe the knowledge and helpfulness of our 
staff?
	___ Excellent	___ Good
	___ Fair	___ Poor
	___ Very poor

(e)	Would you prefer to have the product support fees based on the 
number of incidents, hours of support, or a period of time 
(e.g., annual fees)
	___ Number of incidents
	___ Hours of support
	___ Period of time (please specify) ____________________

(f)	Should various levels of support be offered?  (e.g., varying 
response time commitments, upgrades, BBS support, installation 
support, extended hours, etc.)

	___ Yes	___ No
 
(g)	If you answered "yes" to item (f) above, which services would 
you be interested in and how should we charge for them?

	Interested?		Charge By
	Yes	No	Support Service	By usage	Annual Fee
	___	___	Telephone hotline during 	_______	_______
				ProTools business hours (8am-5pm, PST)
	___	___	Extended hours for telephone 	_______	_______
				support
	___	___	On-site installation 	_______	_______
	___	___	BBS support	_______	_______
	___	___	Remote control support	_______	_______
	___	___	Product upgrades	
				___ Priced and purchased separately each time  	
			$_________ each
				___ One-time annual fee covers all upgrades  	
			$__________ per year


Thank you for your time in completing this survey.  We look forward 
to your comments and welcome the opportunity to work with internet managers
in the future.

Please return to:  ProTools Customer Survey
14976 NW Greenbrier Parkway, Beaverton, OR 97006

6


-- 
				Communications Systems
				Research Corporation
				Dallas, Texas, 75252 US

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 93 06:28:52 GMT
From:      dutfield@sumax.seattleu.edu (Stewart Dutfield)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.dcom.lans.token-ring,comp.dcom.lans.ethernet
Subject:   Re: any "middleware" API products


I have recently been pursuing this chimera. There are some APIs out
there which do the right sort of thing, but they are not widely
available:

TLI appears in UNIX Network Programming by Stevens (Prentice Hall 1990).
Novell are pushing it as an industry standard.

MQI is IBM's message queueing interface, which aims to support transaction
processing as well as store-and-forward. As I understand it, it's a bit
like UNIX IPC messages but the processes may be on different--and 
widely separated--machines.

CPI/C--IBM again--is at a slightly lower level. Most implementations assume
APPC/LU6.2 underneath, though CPI/C is at a higher level and makes no
assumptions about the network layer. I read today that X/Open has adopted
CPI/C, but maybe this is just for APPC communication on UNIX boxes.

I have resigned myself to proposing two APIs for my employer's systems:
APPC for IBM host access, and sockets (or maybe WINSOCK--I'm prepared to
bend with the breeze :-)) for a real protocol, probably IP. This makes
it difficult to move data or services between IBM and other platforms, and
requires that applications know about how each other behave. Insh' Allah,
a higher-level API will one day come, so that we can bolt it on top of
these two.

-- 


Stewart Dutfield                          dutfield@seattleu.edu

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Jun 93 06:37:05 GMT
From:      andrewsc@runx.oz.au (Andrew Schonberger)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.dcom.lans.token-ring,comp.dcom.lans.ethernet
Subject:   any "middleware" API products

    I'm posting this on behalf of a friend, who does not have Usenet access.
He is looking for products (commercial or public domain), to implement
multi-protocol PC connectivity. What he needs, is some sort of universal 
API, which will work transparently with all sorts of protocols like
Ethernet, token-ring, NFS, SNA, etc. he wants to develop his own PC based
application, which needs to talk to various networks.

    If you know of any such product, please reply to him directly, at:
                                  Derek Miller
                                    fax: +61-2-387-4784

    Andrew Schonberger

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Jun 1993 12:01:23
From:      stickel@newsserver.tasc.com  (Terry Stickel)
To:        comp.protocols.tcp-ip
Subject:   running netbios over tcp/ip

I am looking for commercially available software that will support
running Netbios over TCP/IP.  I specifically need this for the
HP-9000 but would be interested in other platforms as well.
Thanks.

--
*--------------------------------------------------------------------------*
*Terry Stickel                                                             *
*Manager, Information Systems Development Section                          *
*TASC                                                                      *
*55 Walkers Brook Drive                           E-Mail:TSTICKEL@TASC.COM *
*Reading, MA   01867                                                       *
*--------------------------------------------------------------------------*


-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1993 18:18:06 -0500
From:      esanchez@mmrree.gov.ec ()
To:        comp.protocols.tcp-ip
Subject:   Looking for POP3 server

Hello, I'm not sure this the correct place to put this request so I apologize
in advance. Could someone point me to a POP3 server that works under
SCO Unix System V v3.2.4 or v3.2.2. Any hint will be most welcomed!

Please reply to my e-mail address (esanchez@mmrree.gov.ec)
================================================================
Edgar Sanchez                             esanchez@mmrree.gov.ec
Division of Information                   All opinions expressed
Ministry of Foreign Affairs               here are my own and not
Quito - Ecuador - Southamerica            those of the Ministry


-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 93 18:37:00 -0500
From:      harvey@indyvax.iupui.edu
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?

In article <1993Jun22.184900.25821@nntpxfer.psi.com>, alun@huey.wst.com (Alun Jones) writes:
> In article <C912Jz.57I@sadis01.kelly.af.mil> donr@sadis05.kelly.af.mil (DONALD G. RUEBENSON II - SCST) writes:
>>Jos Vos (jos@bull.nl) wrote:
>>: When a system has more than one interface, each with its own
>>: IP address, should the /etc/hosts file than contain the same
>>: hostname for each IP address, or should each IP address has
>>: its own unique name?
>>
>>One host, one hostname.  It is possible and allowable to belong to more than
>>one domain (e.g. sadis01.kelly.af.mil, class B and, sadis01.af.mil,
>>class A) but not required.
>>
>>If you are going to have more than one interface on a host, I woudl
>>recommend implementing Domain Name Service, as most /etc/hosts name
>>resolution mecanisms are 'top-down' searches and can lead to some
>>interesting "can't get there from here" problems.  DNS is a little more
>>intuitive about the resources available.
>>
>>Good Hunting,
>>  -- donr
>
> If you're implying something like:
>
> host.domain.net		IN	A	555.126.3.1
> host.domain.net		IN	A	555.198.64.198
>
> in the named.hosts file and in the named.rev file:
>
> 1.3.126.555.IN-ADDR.ARPA	IN	PTR	host.domain.net
> 198.64.198.555.IN-ADDR.ARPA	IN	PTR	host.domain.net
>
> I can guarantee that isn't going to be liked.

I can guarantee that this is perfectly valid, we do it all the time.
I assume the 555 is here as an example.

> Also, if only one reverse mapping is set up, then many ftp servers
> won't accept your logins if they go through the other network, since
> they take your address, resolve it into a name, and then resolve the
> name back to an address, which they then compare with your first
> address.  (Subtract the number you first thought of...)

If they bother to do all this but don't handle a name resolving to multiple
addresses, the code is severely broken.

> I'll stick with one host name for each IP address.

I'll stick with one host name for each host.
--
James Harvey    IUPUI OIT Technical Support -- VMS/Unix/Networks
harvey@iupui.edu  uucp:iugate!harvey  bitnet:harvey@indyvax

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1993 17:21:54 -0400
From:      mfraser@dssdev2.med.osd.mil (Mike Fraser)
To:        comp.protocols.tcp-ip
Subject:   tcpdump for non-BSD systems (eg System V, SCO/ODT)

Has anyone ported 'tcpdump' to non-BSD based unix?  Specifically SCO/ODT
V2 which is SysV3.2.4 based.  If so, can you provide a pointer to it?

If not, can you recommend a similar tool that does run in the SysV world?

Thanks

-----------------------------------------------------------------------
 L. Michael Fraser, Ph.D.            Electronic Data Systems/SIDDOMS     
 Pitts Management Associates, Inc.   13600 EDS Drive,      MS: A4S-D12
 2200 Clarendon Blvd., Suite 1204    Herndon, VA  22071                   
 Arlington, VA  22201-3331           (703) 733-3613  FAX (703) 742-2749
   (703) 527-3333  FAX 527-337       Email: mfraser@dssdev2.med.osd.mil  


-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Jun 1993 11:52:42 GMT
From:      pjb@rudi.23kgroup.com (Paul J. Bell)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?

In article <204t3k$6hv@zippy.Telcom.Arizona.EDU>, leonard@telcom.arizona.edu (Aaron Leonard) writes:
|> In article <C8x1Eq.Mu7@bull.nl>, jos@bull.nl (Jos Vos) writes:
|> 
|> | When a system has more than one interface, each with its own
|> | IP address, should the /etc/hosts file than contain the same
|> | hostname for each IP address, or should each IP address has
|> | its own unique name?
|> 
|> We used to use separate names for each interface, but changed
|> to using one hostname for all interfaces.  The point of a hostname
|> is to gloss over ephemeral physical details of network connectivity.
|> As interfaces will change around more frequently than (logical)
|> hosts, it makes sense to present the single hostname to users.
|> 
|> When there's a need to talk to a specific interface (which is very
|> rare, in my experience), you can always just use the IP address.
|> 
|> Aaron
|> 
|> Aaron Leonard (AL104), <Leonard@Arizona.EDU>
|> University of Arizona Network Operations, Tucson AZ 85721

each ip address should have it's own, unique hostname. also, be sure to 
modify rc and/or rc.local to ifconfig both addresses.

cheers,
	paul

-- 
                                               They Think I'm "ONE OF THEM" 

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Jun 1993 12:23:09 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        comp.protocols.tcp-ip,comp.sys.acorn.tech
Subject:   Re: Is a pre-login banner for ftp `legal'?

evansmp@uhura.aston.ac.uk (Mark Evans) writes:

>C.D.Latham (CDLatham@cen.ex.ac.uk) wrote:
>: I have an Acorn A5000 computer running RISC OS 3 and
>: the Acorn TCP/IP suite.  The University Computer Unit here at Exeter
>: puts a vast banner, which basically says unauthorised use is
>: prohibited, *before* the ftp login prompt.  My little personal
>: computer can't cope with this and ftp crashes.
 
>The banner does look somewhat dodgy.
>If it had every line prefixed by 220- it might be a bit better.

Many servers use this convention, but RFC 959 is clear:

         Thus the format for multi-line replies is that the first line
         will begin with the exact required reply code, followed
         immediately by a Hyphen, "-" (also known as Minus), followed by
         text.  The last line will begin with the same code, followed
         immediately by Space <SP>, optionally some text, and the Telnet
         end-of-line code.

The Exeter greeting conforms to this, so your client software is broken.
Raise a bug report with your vendors.

BTW - neither Sun's FTP client nor that in PC/TCP has any problem with the
greeting, although neither allowed me easily to DISCONNECT NOW - I ended
up quoting an invalid user name. I hope the Exeter Thought Police don't
come for me :-)

Ian
-- 
Ian Phillipps, Unipalm Ltd, 216 Science Park,		Phone +44 223 250100
Milton Road, Cambridge, CB4 4WA, England.		Phax  +44 223 250101
PIPEX Ltd. is a wholly-owned subsidiary of Unipalm Ltd. - phone 0223 250120

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Jun 93 13:10:25 GMT
From:      bebeada@elof.iit.edu (Adam Beberg)
To:        comp.protocols.tcp-ip
Subject:   HELP - problem with 2 way comm.

( i appologize if this is in the wrong group, but i'm sure you can help )

ARG!...

basicly i'm writing a client/server type app, using the standard unix 
port-system for communication..

i have two procedures ( C of course ) one for net input one for output

the guts of output() 
{
	write an unsigned long(length) to port;
	write an int(type) to port;
	write length bytes of data to port;
}

the guts of input() 
{
	read an unsigned long(length) from port;
	read an int(type) from port;
	read data until length bytes are read;
}

basiclly my problem is that the unsigned long and int seem to disappear into 
nothingness, both ends use the same I/O functions..

a normal telnet to the port gets the data, but length and type are missing..

so basicly i figure i need to add something to input() or output().....
WHAT?????

-
Multa renascentur quae iam cecidere, cadentque     | Adam Beberg
Quae nunc sunt in honore vocabula, si volet usus,  |
Quem penes arbitrium est et ius et norma loquendi. | bebeada@elof.iit.edu
        ))) In Sterio Where Available (((          | NeXTMail Welcome.


-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1993 13:40:11 GMT
From:      mjo@iao.ford.com (Mike O'Connor)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.dcom.lans.token-ring,comp.dcom.lans.ethernet
Subject:   Re: any "middleware" API products

In article <1993Jun22.063705.6507@runx.oz.au> andrewsc@runx.oz.au
(Andrew Schonberger) writes:

:    I'm posting this on behalf of a friend, who does not have Usenet access.
:He is looking for products (commercial or public domain), to implement
:multi-protocol PC connectivity. What he needs, is some sort of universal 
:API, which will work transparently with all sorts of protocols like
:Ethernet, token-ring, NFS, SNA, etc. he wants to develop his own PC based
:application, which needs to talk to various networks.

No such products exist.  A lot of players in the computer industry --
BIG players -- wish such tools existed.  They simply do not.  People
claiming to have the one thing that rules them all, the one thing to
bind them, will lead you off on a road to ruin and in the darkness
blind you.  Or something like that.  There are a lot of technologies
out there to do particular things, but no working omni-protocols
exist.  The commentary from the Usenix conference terminal room is to
use either two tin cans and a string, or Novell.  

       						...Mike

-- 
 Michael J. O'Connor           |  Internet:  mjo@fmsrL7.srL.ford.com
 Ford Motor Company, OPEO      |  UUCP:      ...!fmsrl7!opeo!mjo
 20000 Rotunda, Bldg. 1-3001   |  Phone:     +1 (313) 248-1260
 Dearborn, MI  48121           |  Fax:       +1 (313) 323-6277

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Jun 93 18:13:28 EDT
From:      edimg@willard.atl.ga.us (Ed pimentel)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.dcom.lans.token-ring,comp.dcom.lan
Subject:   Re: any "middleware" API products

andrewsc@runx.oz.au (Andrew Schonberger) writes:

>     I'm posting this on behalf of a friend, who does not have Usenet access.
> He is looking for products (commercial or public domain), to implement
> multi-protocol PC connectivity. What he needs, is some sort of universal 
> API, which will work transparently with all sorts of protocols like
> Ethernet, token-ring, NFS, SNA, etc. he wants to develop his own PC based
> application, which needs to talk to various networks.
> 
>     If you know of any such product, please reply to him directly, at:
>                                   Derek Miller
>                                     fax: +61-2-387-4784
> 
>     Andrew Schonberger


-- 
edimg@willard.atl.ga.us (Ed pimentel)
gatech!kd4nc!vdbsan!willard!edimg
emory!uumind!willard!edimg
Willard's House BBS, Atlanta, GA -- +1 (404) 664 8814

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Jun 1993 14:29:04 GMT
From:      jos@bull.nl (Jos Vos)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   How to relate PCB's (netstat -A) to processes?

With netstat -A (available on at least several System V systems and
on AIX) you can see addresses of Protocol Control Blocks
belonging to an IP session.

Is there a possibility (maybe by digging into the kernel-tables)
to relate a PCB address to a process-id?

The reason for this is that I want to find the processes using
sessions on a specific port.

Please mail me any suggestions or solutions.
Thanks.

-- 
--    Jos Vos <jos@bull.nl>   (UUCP: ...!{uunet,mcsun,sun4nl}!nlbull!jos)
--    Bull Netherlands, Professional Services, Amsterdam, The Netherlands

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 93 14:50:22 GMT
From:      donr@sadis05.kelly.af.mil (DONALD G. RUEBENSON II - SCST)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?

Jos Vos (jos@bull.nl) wrote:
: When a system has more than one interface, each with its own
: IP address, should the /etc/hosts file than contain the same
: hostname for each IP address, or should each IP address has
: its own unique name?
 
: -- 
: --    Jos Vos <jos@bull.nl>   (UUCP: ...!{uunet,mcsun,sun4nl}!nlbull!jos)
: --    Bull Netherlands, Professional Services, Amsterdam, The Netherlands

One host, one hostname.  It is possible and allowable to belong to more than
one domain (e.g. sadis01.kelly.af.mil, class B and, sadis01.af.mil,
class A) but not required.

If you are going to have more than one interface on a host, I woudl
recommend implementing Domain Name Service, as most /etc/hosts name
resolution mecanisms are 'top-down' searches and can lead to some
interesting "can't get there from here" problems.  DNS is a little more
intuitive about the resources available.

Good Hunting,
  -- donr

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1993 23:38:56 -0500
From:      tar@sam.ksu.ksu.edu (Tim Ramsey)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

rturner@imagen.com (Randy Turner) writes:

>	I can understand Steve and others opinions regarding turning off
>	checksumming in any case.  However, if you can verify that the
>	two hosts are communicating over the same LAN, and the underlying
>	data link layer (Ethernet in my case) is already performing a
>	reliable datacheck operation, then I feel that the checksum operation
>	is redundant.

Not true.  I have seen data errors caused by a bad Ethernet interface cause
UDP corruption.  Even if the data link layer does perform checksumming
this does not help if you have a bad interface.

-- 
Tim Ramsey, tar@matt.ksu.ksu.edu
  PGP2.2 public key available via keyserver, finger, or email.
  MIME mail accepted (eagerly :)
  Member of the League for Programming Freedom and the ACLU.

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Jun 1993 15:35:32 GMT
From:      wrolf@csfb1.uucp (Wrolf Courtney)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.dcom.lans.token-ring,comp.dcom.lans.ethernet
Subject:   Re: any "middleware" API products

In article <20723rINNq15@ope001.iao.ford.com> Mike O'Connor <mjo@fmsrL7.srL.ford.com> writes:
>In article <1993Jun22.063705.6507@runx.oz.au> andrewsc@runx.oz.au
>(Andrew Schonberger) writes:
 ...
>:API, which will work transparently with all sorts of protocols like
>:Ethernet, token-ring, NFS, SNA, etc. he wants to develop his own PC based
>:application, which needs to talk to various networks.
>
>No such products exist.  A lot of players in the computer industry --
>BIG players -- wish such tools existed.  They simply do not.  People
>claiming to have the one thing that rules them all, the one thing to
>bind them, will lead you off on a road to ruin and in the darkness
>blind you.

Will they blind you in both LUs, or just the one LU?

:-) for the humor impaired.

Wrolf


-- 
Wrolf Courtney               First Boston Corporation    My employer thinks
(212) 322-7017               Park Avenue Plaza           I'm crazy.
uunet!csfb1!wrolf            New York, NY 10055

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Jun 1993 16:24:41 GMT
From:      vo@iro.umontreal.ca (Si Nguyen Vo)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: How to relate PCB's (netstat -A) to processes?

Jos Vos (jos@bull.nl) wrote:

: The reason for this is that I want to find the processes using
: sessions on a specific port.

Hello,

I'm very interested in this kind of mapping process - port too,
if some unix-guru can help, it would be greatly appreciated 8-)

Vo

-----------------------------------------------------------------------------
 | Vo@iro.umontreal.ca     | Apprendre Sans Penser Est Inutile             |
 | I.R.O - U de Montreal   |    Mais Penser Sans Apprendre Est Dangereux   |
 -------------------------------------------------------------- Confusius ----

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 93 16:28:27 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1191 compliance

mogul@pa.dec.com (Jeffrey Mogul) writes:

>To clear up some confusion: on 8 March 1993, RFC1191 was advanced from
>Proposed Standard to Draft Standard, along with a little extra advice:
 
>  The IESG has approved the Internet Draft "Path MTU Discovery" RFC1191
>  as a Draft Standard. This document is the product of the concluded
>  MTU Discovery Working Group. The IESG recommends that a companion
>  document "IESG Advice from Experience with Path MTU Discovery"
>  describing operational experience with the protocol in the Internet
>  be published as an Informational document. The IESG contact persons
>  are Philip Almquist, Stev Knowles and Dave Piscitello.
 
>That "advice" was published as RFC1435.
 
>According to the rules as I understand them, RFC1191 is eligible to
>be advanced to Standard in September 1993.  I have heard little
>negative comment on the design, so I expect this will happen more
>or less on schedule.
 
>-Jeff


	Thanks for all the replies.  The reason I asked is that if there
	is not a considerable number of machines out there that support it
	then I cannot justify the development effort to add it to our current
	IP code.  I am trying to draw up a project to add several enhancements
	to our our current (albeit outdated) IP implementation, and the
	performance enhancements possible with PMTU discovery would definitely
	help, but only if the majority of the networks we are installed in
	support RFC 1191.  I also understand that vendor inclusion of proposed
	standards help move the standards process along, but in my case I 
	have a political battle if I use that reasoning. 

	At the moment, we are contemplating IP multicasting, header prediction,
 	and we are also looking at bypassing the TCP checksum calculation for
	packets sent to and received from hosts on the same network (or subnet).	Has anyone else considered bypassing checksum calculations for for TCP
	connections on the same network?

	Thanks!
		Randy

-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Jun 1993 18:49:00 GMT
From:      alun@huey.wst.com (Alun Jones)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?

In article <C912Jz.57I@sadis01.kelly.af.mil> donr@sadis05.kelly.af.mil (DONALD G. RUEBENSON II - SCST) writes:
>Jos Vos (jos@bull.nl) wrote:
>: When a system has more than one interface, each with its own
>: IP address, should the /etc/hosts file than contain the same
>: hostname for each IP address, or should each IP address has
>: its own unique name?
>
>One host, one hostname.  It is possible and allowable to belong to more than
>one domain (e.g. sadis01.kelly.af.mil, class B and, sadis01.af.mil,
>class A) but not required.
>
>If you are going to have more than one interface on a host, I woudl
>recommend implementing Domain Name Service, as most /etc/hosts name
>resolution mecanisms are 'top-down' searches and can lead to some
>interesting "can't get there from here" problems.  DNS is a little more
>intuitive about the resources available.
>
>Good Hunting,
>  -- donr

If you're implying something like:

host.domain.net		IN	A	555.126.3.1
host.domain.net		IN	A	555.198.64.198

in the named.hosts file and in the named.rev file:

1.3.126.555.IN-ADDR.ARPA	IN	PTR	host.domain.net
198.64.198.555.IN-ADDR.ARPA	IN	PTR	host.domain.net

I can guarantee that isn't going to be liked.

Also, if only one reverse mapping is set up, then many ftp servers
won't accept your logins if they go through the other network, since
they take your address, resolve it into a name, and then resolve the
name back to an address, which they then compare with your first
address.  (Subtract the number you first thought of...)

I'll stick with one host name for each IP address.

Alun.
~~~~


-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Jun 1993 19:50:52 GMT
From:      royc@rbdc.wsnc.org (Roy Crabtree)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   Re: TLI

In article <1993Jun21.192607.14647@lmpsbbs.comm.mot.com> gulik@rtsg.mot.com (Gregory Gulik) writes:
>
>Are there any TLI experts out there?
>
>I have a couple questions about it.
>
>1.  Is TLI any faster than sockets, in general, and specifically on
>    a 3B2 running System V.3.2

	Per se, no difference.  Given TLI and AT&T SW efficiency, no.
	On most 3B2s, RFS, TLI is in general going to be slower than
	the equivalent sockets.

>
>2.  Is there a way, using TLI, to do the equivalent of a select
>    on more than 1 file descriptor?  My specific application will
>    be watching a serial port and a socket.  I looked in the Stevens
>    book and couldn't find what I need.

	yes.  If at all possible, avoid
	using the netowkr calls; stuff your connections to look like
	file desriptors, and use async IO calls.

	You can do it using NSU calls, but you will not like it.

>
>Thanks.
>
>-greg
>
>-- 
>
>gulik@rtsg.mot.com  (Gregory Gulik)  [NeXT]


	What in the world is soeone at NexT doing to/with a 3B2?


		Stehen would have a hemmy!


royc

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Jun 1993 20:08:28 GMT
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: How to relate PCB's (netstat -A) to processes?

> With netstat -A (available on at least several System V systems and
> on AIX) you can see addresses of Protocol Control Blocks
> belonging to an IP session.
> 
> Is there a possibility (maybe by digging into the kernel-tables)
> to relate a PCB address to a process-id?

No *portable* way, as far as I know. But have a look at how 'ofiles' and
'lsof' does it by digging through the kernel data structures. Example of
use:

% ofiles tcp.25
user     process command        port(s)
root     261     inetd          25 

% lsof -i tcp:25
COMMAND     PID     USER   FD   TYPE     DEVICE   SIZE/OFF  INODE/NAME
inetd       261     root   36u  inet 0xff651c8c          0    TCP *:25

Both ofiles and lsof available through the net; check with your nearest
archie server.

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Jun 1993 20:08:48 GMT
From:      heimlich@watson.ibm.com (Steve Heimlich)
To:        comp.protocols.tcp-ip
Subject:   bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <rturner.740766507@imagen> rturner@imagen.com (Randy Turner) writes:
> 	and we are also looking at bypassing the TCP checksum calculation for
>	packets sent to and received from hosts on the same network (or subnet).	
>	Has anyone else considered bypassing checksum calculations for for TCP
>	connections on the same network?

This is a really bad idea.

Steve

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Jun 1993 20:13:32 GMT
From:      bryan@cmhcsys.com (Bryan M. Beck)
To:        comp.protocols.tcp-ip
Subject:   Why dosen't route provide this route

I have an SCO Unix system running Morning Star's PPP and am using it to
gain dialin access to my ethernet. Presently my ethernet interface on the
PPP dialin server is 101.1.21.1.  And I want my dialin PC's to that PPP server 
to be on another another network (such as 103.xxx.xxx.xxx).   

What I would like to do is add a route on the PPP server (route add 103.0.0.0
101.1.21.1) to route the traffic between the serial interface and the ethernet
interface.  By adding this route I was hoping that through RIP is route would
be added to the routing tables of my other systems, but no such luck.

If I add a static route (route add 103.0.0.0 101.1.21.1) on my other system
everything seems to work fine.

Why isn't routed providing this info? Or is there a better way to do this
without adding the static routes to all my hosts.

Please e-mail all responses.

Thanks,
Bryan
--

Bryan M. Beck                                                 CMHC Systems, Inc.
Systems Engineer                                              5500 Frantz Road
INTERNET: bryan@cmhcsys.com                                   Dublin, Ohio 43017
UUCP:     ..!uupsi5!cmhcsys!bryan                              (614) 764-0143

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1993 21:46:58 GMT
From:      D.Nash@utexas.edu (Donald L. Nash)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)


In article <rturner.740766507@imagen> rturner@imagen.com (Randy Turner) writes:
> 	and we are also looking at bypassing the TCP checksum calculation for
>	packets sent to and received from hosts on the same network (or subnet).	
>	Has anyone else considered bypassing checksum calculations for for TCP
>	connections on the same network?

This very illegal according to the TCP specification and the Host
Requirements RFC, not to mention being a patently bad idea.  Section
4.2.2.7 of RFC 1122 (Host Requirements part 1), says it quite nicely:

         4.2.2.7  TCP Checksum: RFC-793 Section 3.1

            Unlike the UDP checksum (see Section 4.1.3.4), the TCP
            checksum is never optional.  The sender MUST generate it and
            the receiver MUST check it.

To do otherwise would be to compromise TCP's guarantee of reliable data
delivery.

Although I'm not an implementor, do I know that much work has gone into
optimizing the TCP checksum algorithm.  I believe that Dave Borman at
Cray Research Inc. vectorized the checksum algorithm and got some, ah,
interesting results out of that, but QMS and/or Imagen printers probably
don't have vector processors in them. :-)  Short of that, there are
other techniques which I am sure someone more knowledgable than I would
be happy to share with you.  I'm passingly familiar with some of the
techniques, but not enough to describe them well enough for you to
implement.

On the other hand, are your printers really so fast that the TCP
checksum code is a bottleneck, or is this for something other than a
printer?  If your TCP implementation is capable of delivering data to
your print engine faster than the engine can process the data, then you
probably don't need to worry about speeding up your TCP.

                                ++Don Nash

Internet:  D.Nash@utexas.edu    The University of Texas System
THEnet:    THENIC::DON          Office of Telecommunication Services

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 93 22:20:55 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

heimlich@watson.ibm.com (Steve Heimlich) writes:

>In article <rturner.740766507@imagen> rturner@imagen.com (Randy Turner) writes:
>> 	and we are also looking at bypassing the TCP checksum calculation for
>>	packets sent to and received from hosts on the same network (or subnet).	
>>	Has anyone else considered bypassing checksum calculations for for TCP
>>	connections on the same network?
 
>This is a really bad idea.
 
>Steve


	I can understand Steve and others opinions regarding turning off
	checksumming in any case.  However, if you can verify that the
	two hosts are communicating over the same LAN, and the underlying
	data link layer (Ethernet in my case) is already performing a
	reliable datacheck operation, then I feel that the checksum operation
	is redundant.  Since TCP does not currently support turning off
	checksumming, an earlier implementation would just not bother to
	checksum inbound packets.  It would still checksum outbound packets.
 
	This approach is also discussed in a paper given at the 1993 Usenix
	West Symposium titled:
		"Measurement, Analysis, and Improvement of UDP/IP 
		 Througput for the DECStation 5000"

		By Jonathan Kay (jkay@cs.ucsd.edu) and
		   Joseph Pasquale (pasquale@cs.ucsd.edu)

	In their paper, they also discuss how the probability of data
	corruption during I/O bus transfers can be effectively ignored,
	given the fact that disk I/O transfers are not datacheck'd by
	the OS prior to delivery of data to user space.

	The only real problem I see in eliminating the TCP inbound checksum
        is making sure that a particular TCP connection is established
	between two hosts on the same LAN.


	Randy
-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1993 00:03:15 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <207uki$2le@geraldo.cc.utexas.edu> D.Nash@utexas.edu (Donald L. Nash) writes:
>On the other hand, are your printers really so fast that the TCP
>checksum code is a bottleneck, or is this for something other than a
>printer?

As a side point, as Vernon Schryver likes to point out ;-), it is
possible to write a one-copy TCP in Unix.  If this is a printer or
other dedicated box and you have Ethernet hardware that can handle it,
you could even do a zero-copy TCP.

Every copy you remove will add roughly as much performance as disabling
checksums, but without putting data at risk.

RFC 1071 has a discussion of fast checksum techniques and sample code.

      Stephen

-- 
Stephen Trier (trier@ins.cwru.edu - MIME OK)   
Network Software Engineer              
IRIS/INS/T                               
Case Western Reserve University             

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 93 01:17:10 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In Article <rturner.740803663@imagen>
rturner@imagen.com (Randy Turner) writes:
>D.Nash@utexas.edu (Donald L. Nash) writes:
>>This very illegal according to the TCP specification and the Host
>>Requirements RFC, not to mention being a patently bad idea.  Section
>>4.2.2.7 of RFC 1122 (Host Requirements part 1), says it quite nicely:
 
>>         4.2.2.7  TCP Checksum: RFC-793 Section 3.1
 
>>            Unlike the UDP checksum (see Section 4.1.3.4), the TCP
>>            checksum is never optional.  The sender MUST generate it and
>>            the receiver MUST check it.
>
>/*
>    True, that's what it says.  However, RFC-793 was published before there
>    were sophisticated data-link layer services such as Ethernet or FDDI.
>    Since these data-link/MAC-layer services provide a more robust error
>    checking method (CRC-16/CRC-32), I would think if RFC-793 was written
>    today, there would probably be some type of clause that 
>    included a per-connection optional checksum method.
>*/

It never ceases to amaze me how far people are willing to go to rationalize
stupid behavior. (I don't exclude myself from that...I've pulled some lulus in
my time.)

First, there are LOTS of ways for data corruption to occur outside of the
Ethernet FCS.

Second, this section is from RFC1122, not 793. 1122 was written in 1989, long
after Ethernet became dominant and even after the introduction of FDDI. When
Bob and company put a "MUST" in 1122, they meant it. I do disagree with some
things in 1122, but skipping the checksum in TCP would NEVER be one of them. I
have little doubt that it 1122 was written today, it would read exactly the
same on this issue.

More important, 1122 compliance is a requirement in a lot of specs. It's in
every one that I put out with if it involves IP. If I ever receive a bid that
does not include 1122 compliance, I would probably reject it. This is called
negative sales impact or losing money, hardly something a business would want.
This can also impact severely on performance reviews of the programmers
involved.

Finally, please tell me just how you can be sure that the two systems are on
the same LAN? And if there is a bridge between them, they are NOT on the same
LAN. I've seen broken bridges corrupt packets and give them the correct FCS.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov		(510) 422-6955

Disclaimer: Being a know-it-all isn't easy. It's especially tough when you
don't know that much. But I'll keep trying. (Both)

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1993 10:36:06 -0500
From:      esanchez@mmrree.gov.ec ()
To:        comp.protocols.tcp-ip
Subject:   Looking for POP3 server

Hello, I'm not sure this the correct place to put this request so I apologize
in advance. Could someone point me to a POP3 server that works under
SCO Unix System V v3.2.4 or v3.2.2. Any hint will be most welcomed!

Please answer to my personal e-mail address (esanchez@mmrree.gov.ec)
================================================================
Edgar Sanchez                             esanchez@mmrree.gov.ec
Division of Information                   All opinions expressed
Ministry of Foreign Affairs               here are my own and not
Quito - Ecuador - Southamerica            those of the Ministry


-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 1993 02:24:27 GMT
From:      marka@syd.dms.CSIRO.AU (Mark Andrews)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?

In article <1993Jun22.184900.25821@nntpxfer.psi.com> alun@huey.wst.com (Alun Jones) writes:
>In article <C912Jz.57I@sadis01.kelly.af.mil> donr@sadis05.kelly.af.mil (DONALD G. RUEBENSON II - SCST) writes:
>>Jos Vos (jos@bull.nl) wrote:
>>: When a system has more than one interface, each with its own
>>: IP address, should the /etc/hosts file than contain the same
>>: hostname for each IP address, or should each IP address has
>>: its own unique name?
>>
>>One host, one hostname.  It is possible and allowable to belong to more than
>>one domain (e.g. sadis01.kelly.af.mil, class B and, sadis01.af.mil,
>>class A) but not required.
>>
>>If you are going to have more than one interface on a host, I woudl
>>recommend implementing Domain Name Service, as most /etc/hosts name
>>resolution mecanisms are 'top-down' searches and can lead to some
>>interesting "can't get there from here" problems.  DNS is a little more
>>intuitive about the resources available.
>>
>>Good Hunting,
>>  -- donr
>
>If you're implying something like:
>
>host.domain.net		IN	A	555.126.3.1
>host.domain.net		IN	A	555.198.64.198
>
>in the named.hosts file and in the named.rev file:
>
>1.3.126.555.IN-ADDR.ARPA	IN	PTR	host.domain.net
>198.64.198.555.IN-ADDR.ARPA	IN	PTR	host.domain.net
>
>I can guarantee that isn't going to be liked.

	I will be if the zone is 555.IN-ADDR.ARPA.
>
>Also, if only one reverse mapping is set up, then many ftp servers
>won't accept your logins if they go through the other network, since
>they take your address, resolve it into a name, and then resolve the
>name back to an address, which they then compare with your first
>address.  (Subtract the number you first thought of...)
>
	You compare ALL addresses in the list for a match. If ANY
	match then it can be said to be a valid PTR record.

>I'll stick with one host name for each IP address.
>
>Alun.
>~~~~
>

There is nothing wrong with one host name having multiple A
records on different {sub}nets. The DNS handles this quite
well. In the above case there are 3 zone in use.

A real life example.

nsw.gw.csiro.au.	A	130.155.32.4
nsw.gw.csiro.au.	A	139.130.128.2
nsw.gw.csiro.au.	A	152.83.240.2
nsw.gw.csiro.au.	A	130.155.208.100
nsw.gw.csiro.au.	A	130.155.144.1
nsw.gw.csiro.au.	A	192.82.140.254

The PTR records for this machine are in 6 different zone,
each of which is administered by a different person.

The examples given in the early DNS documents assumed
that the was only 1 net involved, hence named.host and
named.rev.

Run gethostbyaddr() on any of these addresses and it works,
even on SunOS which does the SPOOF check internally.

Mark.

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 93 02:47:43 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

D.Nash@utexas.edu (Donald L. Nash) writes:


>In article <rturner.740766507@imagen> rturner@imagen.com (Randy Turner) writes:
>> 	and we are also looking at bypassing the TCP checksum calculation for
>>	packets sent to and received from hosts on the same network (or subnet).	
>>	Has anyone else considered bypassing checksum calculations for for TCP
>>	connections on the same network?
 
>This very illegal according to the TCP specification and the Host
>Requirements RFC, not to mention being a patently bad idea.  Section
>4.2.2.7 of RFC 1122 (Host Requirements part 1), says it quite nicely:
 
>         4.2.2.7  TCP Checksum: RFC-793 Section 3.1
 
>            Unlike the UDP checksum (see Section 4.1.3.4), the TCP
>            checksum is never optional.  The sender MUST generate it and
>            the receiver MUST check it.

/*
    True, that's what it says.  However, RFC-793 was published before there
    were sophisticated data-link layer services such as Ethernet or FDDI.
    Since these data-link/MAC-layer services provide a more robust error
    checking method (CRC-16/CRC-32), I would think if RFC-793 was written
    today, there would probably be some type of clause that 
    included a per-connection optional checksum method.
*/

>To do otherwise would be to compromise TCP's guarantee of reliable data
>delivery.
 
>Although I'm not an implementor, do I know that much work has gone into
>optimizing the TCP checksum algorithm.  I believe that Dave Borman at
>Cray Research Inc. vectorized the checksum algorithm and got some, ah,
>interesting results out of that, but QMS and/or Imagen printers probably
>don't have vector processors in them. :-)  Short of that, there are
>other techniques which I am sure someone more knowledgable than I would
>be happy to share with you.  I'm passingly familiar with some of the
>techniques, but not enough to describe them well enough for you to
>implement.

/* 
	We already use an algorithm similar to RFC-1071 that combines
	a data copy with the checksum calculation, and also is written
        in assembly language (68020) with extensive loop unrolling

	Actually, the fact that we are using a 16Mhz 68020 implementation,
	and the fact that we have to handle multiple protocol stacks
	(TCP/IP, DECNet, EtherTalk, Novell) is part of the reason I am
	seeking to squeeze every thing I can out of the code.
*/

>On the other hand, are your printers really so fast that the TCP
>checksum code is a bottleneck, or is this for something other than a
>printer?  If your TCP implementation is capable of delivering data to
>your print engine faster than the engine can process the data, then you
>probably don't need to worry about speeding up your TCP.

/*
	You would be surprised to find out what our network requirements
	are.  And it is not only the print engine that determines the
	producer/consumer ratio in our printers......
*/
>                                ++Don Nash
 
>Internet:  D.Nash@utexas.edu    The University of Texas System
>THEnet:    THENIC::DON          Office of Telecommunication Services


	Thanks for the replies!
				Randy
-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1993 11:30:44 -0500
From:      mgriffin@matt.ksu.ksu.edu (Mark Griffin)
To:        comp.protocols.tcp-ip
Subject:   Why can I make some connections, but not all of them?

We are running AT&T TCP/IP WIN/3B Rel. 3.0.1 on an AT&T 3b2/1000 with
Unix Sys V. Rel. 3.2.3.  We just setup Name Service, which seems OK.
We can do an nslookup on any host and it always comes back with the
correct IP address.  However, when we telnet or ftp to these other
hosts, some connections are made while others time out without getting
a connection.  For example, we can telnet or ftp to the following hosts:
wuarchive.wustl.edu, matt.ksu.ksu.edu, archie.unl.edu, archie.au,
gatekeeper.dec.com.  We cannot make these connections: nic.funet.fi,
rs.internic.net, nic.ddn.mil.  Of course, there are numerous others
that fall in either category.  What else is strange is that if we
supply the actual IP address (eg. 198.41.0.5) we still cannot make the
ftp or telnet connection.  I know these hosts are up and running because
I can connect to them from another host that is not in this domain (fhsu.
edu).  Someone suggested that I run traceroute, but our tcp does not have
such a command.  Can anyone offer any help or suggestions as to what
may be the cause of this.  Any info. would be greatly appreciated.

-- 
.   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .  .
Mark Griffin, Sys Admin, Fort Hays State University      |It is always better to
Internet:mgriffin@matt.ksu.ksu.edu Bitnet:mgriffin@ksuvm |do, than be done to.
.   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .  .

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 1993 03:15:01 GMT
From:      heimlich@watson.ibm.com (Steve Heimlich)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <rturner.740787655@imagen> rturner@imagen.com (Randy Turner) writes:
>
>	The only real problem I see in eliminating the TCP inbound checksum
>        is making sure that a particular TCP connection is established
>	between two hosts on the same LAN.

Tell me how you plan to do this.  It's kind of like describing how
to be a millionaire:

first, get a million dollars...

Apologies for ripping off an old Steve Martin line.  

I've seen two examples of equipment failures which were detected
only by end to end checksum.  The first we noticed after discovering
that our NFS data was screwed up and our data was hosing us down
(then we noticed that this particular NFS had disabled checksums in
its UDP, a practice which thankfully seems to be falling into disfavor).
The second we noticed when some routing protocols delivered completely
bogus routes.  Neither were fun.

As someone else mentioned, there are many things you can
do to improve a TCP implementation which do not put the data integrity
at risk.  It really doesn't matter how fast that schematic gets to
the print engine if it has wires missing somewhere.

Steve


-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 1993 03:42:12 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

Do the checksums. 

I know of one TCP/IP product that can negotiate "no TCP checksums" for
"local" lan connections between cooperating nodes, and I have seen at
least one instance of lan cards going bad in such a way as to silently
corrupt data. Besides, with all these brouters, proxy-arp, and Knuth
knows what else you have really *no* way of knowing beyond a
reasonable doubt that your connection is really a local one.

It's a big, bad network - let's be careful out there... ;-)

rick jones
Just because I'm paranoid doesn't mean the network isn't out to get me...

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 1993 04:46:05 GMT
From:      dsiebert@icaen.uiowa.edu (Doug Siebert)
To:        comp.protocols.tcp-ip
Subject:   Current TCP implementations (was Re: bypassing TCP checksum)

raj@cup.hp.com (Rick Jones) writes:

>Do the checksums. 
 
>I know of one TCP/IP product that can negotiate "no TCP checksums" for
>"local" lan connections between cooperating nodes, and I have seen at
>least one instance of lan cards going bad in such a way as to silently
>corrupt data. Besides, with all these brouters, proxy-arp, and Knuth
>knows what else you have really *no* way of knowing beyond a
>reasonable doubt that your connection is really a local one.
 
>It's a big, bad network - let's be careful out there... ;-)


Don't most modern TCP implementations, especially on RISC processors, do the
checksum in parallel with the data copy anyway, and thus waste no processing
power doing the checksum anyway?  I seem to recall this being discussed a while
back...  Or was it the case that *theoretically* this can be done, but the
implementations the poster had talked about (in particular he had done it on
a Sparc and an i486) were just experimental and not real-world production
code?

I'm sure some people here would know if real-world implementations do this,
since you are from HP, Rick, I'll pick on you and ask you if HP's TCP does
this?  It does seem to be very quick (of course HP's hardware is quick so it
could cover up a slow TCP implementation underneath :-) )  How about Sun, DEC,
SGI, IBM, and the rest of the vendors?

-- 
Doug Siebert                             |  "I don't have to take this abuse
Internet:  dsiebert@isca.uiowa.edu       |   from you - I've got hundreds of
NeXTMail:  dsiebert@chop.isca.uiowa.edu  |   people waiting in line to abuse
    ICBM:  41d 39m 55s N, 91d 30m 43s W  |   me!"  Bill Murray, Ghostbusters

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 93 10:20:19
From:      fkittred@spchp13.BBN.COM (Fletcher Kittredge)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.dcom.lans.token-ring,comp.dcom.lans.ethernet
Subject:   Re: any "middleware" API products

In article <20723rINNq15@ope001.iao.ford.com> mjo@iao.ford.com (Mike O'Connor) writes:

   In article <1993Jun22.063705.6507@runx.oz.au> andrewsc@runx.oz.au
   (Andrew Schonberger) writes:

   :    I'm posting this on behalf of a friend, who does not have Usenet access.
   :He is looking for products (commercial or public domain), to implement
   :multi-protocol PC connectivity. What he needs, is some sort of universal 
   :API, which will work transparently with all sorts of protocols like
   :Ethernet, token-ring, NFS, SNA, etc. he wants to develop his own PC based
   :application, which needs to talk to various networks.

   No such products exist.  A lot of players in the computer industry --
   BIG players -- wish such tools existed.  They simply do not.  People
   claiming to have the one thing that rules them all, the one thing to
   bind them, will lead you off on a road to ruin and in the darkness
   blind you.  Or something like that.  There are a lot of technologies
   out there to do particular things, but no working omni-protocols
   exist.  The commentary from the Usenix conference terminal room is to
   use either two tin cans and a string, or Novell.  

Humm, I would be wary of PC connectivity expertise from the terminal
room of a Usenix conference terminal room ;-).  Besides, you don't
seem to be answering the question, which was about APIs not protocols.

The WinSock API is designed to be such an API.  WinSock is in version
1.1.  Many vendors are shipping support for WinSock, including all of
the major TCP-IP vendors.  For example, Windows NT will come with
winsock support for:

TCP/IP
Novell (IPX)
Appletalk

Further, other vendors have committed to support for:

OSI
DECnet

in the near future.  If you are interested in learning more, you can
subscribe to the winsock mailing list via:

winsock-request@Microdyne.COM

and the Sun RPC on Windows mailing list via:

rpc4win-request@wco.ftp.com

regards,
fletcher
--
/* Fletcher Kittredge
 * BBN Software Products
 * 150 CambridgePark Dr,  Cambridge, MA. 02140
 * 617-USE-FINK  /  fkittred@bbn.com  /  fkittred@das.harvard.edu
 */

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 1993 05:25:21 GMT
From:      jim@reptiles.org (Jim Mercer)
To:        comp.protocols.tcp-ip
Subject:   Re: AS/400 to Vax

In article <739995366snz@wookie.demon.co.uk> wookie@wookie.demon.co.uk writes:
>My problem is this. From my internet experience, I know that TCP/IP can link
>using a protocol like slip, cslip or TCP/IP over a dial up link. It seems
>however that IBMs TCP/IP offering does not provide these.
>
>Failing that, any thought on how to implement good dial up links ?  I assume
>that the PSTN environment in the UK will be pretty much like that in the US...

one solution would be to put a router of some flavour attached to the AS/400
via ethernet.

one such router could be a 286 single floppy PC running KA9Q
(ucsd.edu:/pub/packet/tcp-ip or something like that) running slip or PPP.


-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1993 06:16:21 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1191 compliance

In article <rturner.740766507@imagen> rturner@imagen.com (Randy Turner) writes:

    	Thanks for all the replies.  The reason I asked is that if there
    	is not a considerable number of machines out there that support it
    	then I cannot justify the development effort to add it to our current
    	IP code.  I am trying to draw up a project to add several enhancements
    	to our our current (albeit outdated) IP implementation, and the
    	performance enhancements possible with PMTU discovery would definitely
    	help, but only if the majority of the networks we are installed in
    	support RFC 1191.  

If it helps, cisco implemented PMTU discovery in version 8.3 of our
software.  This code has been available for about 1.5 years now.  By my
best guesstimate, that code or more recent is running in about 90% of our
customers networks.

Tony

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 1993 06:21:13 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1191 compliance

In article <rturner.740766507@imagen>, rturner@imagen.com (Randy Turner) writes:
> ...
> 	Thanks for all the replies.  The reason I asked is that if there
> 	is not a considerable number of machines out there that support it
> 	then I cannot justify the development effort to add it to our current
> 	IP code....

We care about MTU discovery because it's so ugly to use 1500 byte packets
over FDDI rings.  Not to mention HIPPI.  Not to mention 500 byte packets.


It seems to me that systems that only deal with ethernets could get by
with a hack-switch that would override the H.R. RFC rules about using
500 byte packets to distant networks.  Several years ago, when we
couldn't drive ethernets to saturation, such a switch named
"allnetsarelocal", after the 4.3BSD "subnetsarelocal", made some
customers happy.


> packets sent to and received from hosts on the same network (or subnet).
> Has anyone else considered bypassing checksum calculations for for TCP
> connections on the same network?

One IP (or TCP/IP) host cannot reliably tell if the other host is
"on the same network".  Besides hassles with subnets, there are
bridges and switching hubs which make it impossible to define
the notion "same network" in a useful sense in this context.


Vernon Schryver,  vjs@sgi.com

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 1993 14:21:30
From:      djmiller@newsserver.tasc.com  (Dean J. Miller)
To:        comp.dcom.lans,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Netbios over TCP/IP on HP-9000

	We are porting a windows application to motif on a HP-9000 unix
platform.  It is a communications-based application and uses
"home-grown" gateway software, running on a DOS-based PC, over Netbios
to provide communications functions to the individual PCs.  In the
timeframe that has been allocated to perform the port, it is not
possible to both port the windows application to unix and port the
gateway to run over TCP/IP.  What I need to know is: is there an
implemenation of Netbios that runs over TCP/IP for the HP-9000?
	I have asked HP this question and gotten the following
responses.  They have an implementation of Netbios over TCP/IP to
support their LAN Manager/X product, but it is only for that limited use
and is not a commercial product.  They then gave me the name of a vendor
who they thought had a Netbios implementation which ran over TCP/IP. 
They do, but not yet, and it won't be available until after we are
supposed to be delivering our Unix application. 
	Are there any other implementations of Netbios on a HP-9000? If
not, can anyone direct me to a source for a generic unix C
implementation which could be ported to the HP-9000?
	Please contact me if you have any information.  Thanks. 

====================
Dean J. Miller
TASC
(617)942-2000 x2769
djmiller@tasc.com


-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 93 09:45:43 GMT
From:      mvbr@se.alcbel.be (Marc Verbruggen)
To:        comp.protocols.tcp-ip
Subject:   Answers to exercises in Comers book


--
I'm currently reading Comers book "Internetworking with TCP/IP vol.1 "
Has anyone ever solved the exercises, collected the answers and is 
prepared to distribute them ? 

-----------------------------------------------------------
Marc Verbruggen                 tel : 03.240.94.19
Alcatel Bell Telephone          fax : 03.240.99.50
F. Wellesplein 1                email : mvbr@se.alcbel.be
B-2018 Antwerp
Belgium
 
"System Manager's Headaches Are Not Cured With Aspirin,
 There Is A Better Way ..."

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 93 12:44:54 GMT
From:      tomiii@mtu.edu (Thomas Dwyer III)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?

Paul J. Bell (pjb@rudi.23kgroup.com) wrote:

>each ip address should have it's own, unique hostname. also, be sure to 
>modify rc and/or rc.local to ifconfig both addresses.

Oh really?  Seems odd, then, that a root nameserver (ns.nasa.gov for
example, but there are others) would not follow that rule...


Tom.III
tomiii@mtu.edu

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 1993 13:50:43 GMT
From:      peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

rturner@imagen.com (Randy Turner) writes:

>>         4.2.2.7  TCP Checksum: RFC-793 Section 3.1
 
>>            Unlike the UDP checksum (see Section 4.1.3.4), the TCP
>>            checksum is never optional.  The sender MUST generate it and
>>            the receiver MUST check it.
 
>/*
>    True, that's what it says.  However, RFC-793 was published before there
>    were sophisticated data-link layer services such as Ethernet or FDDI.
>    Since these data-link/MAC-layer services provide a more robust error
>    checking method (CRC-16/CRC-32), I would think if RFC-793 was written
>    today, there would probably be some type of clause that 
>    included a per-connection optional checksum method.
>*/

I wouldn't rush to judgement so quickly. The old Arpanet was
essentially an X.25 network, and most of the hosts at one point were
on this net. The same arguments could have been made then - if they
were, they were rejected. (in notable comparison to TP0 over X.25...) 

However, it does come to mind that printer output data (as opposed to
e.g.  downloading software or fonts) has a particularly transient
characteristic - a printer is a write-only device, so if you get a
data error it only affects that single printout. It's not like a
source file getting transfered with FTP, where an error can result in
unrecoverable bit-rot for the rest of time.

In fact, if you had data on packet error frequencies, you could
compare that to the probability of mucking up a printout due to e.g. a
paper jam, and possibly conclude that a printer is nowhere near
reliable enough to worry about an e.g. 10^-10 rate of undetected
packet errors. And if you only turned off checksums in the receive
direction it would be transparent to external devices.

I still think it would be a bad idea, though.

				Peter Desnoyers
-- 

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 93 14:06:57 GMT
From:      phil@it56.bull.it (Filippo Tripiciano )
To:        comp.dcom.lans,comp.dcom.lans.misc,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Ethernet Rev. question

Anybody could help me in finding out the difference between Rev 1 and Rev 2
of Ethernet specs.

Thanks a lot.
Filippo
-------

Filippo Tripiciano
Bull HN Italia                      INTERNET: f.tripiciano@it56.bull.it
Via del Parlamento 33                  VOICE: +39-2-6779 2553
20098 Borgolombardo (MI)                 FAX: +39-2-6779 2439
ITALY
-- 
====================================================================
Filippo Tripiciano
BULL HN Italia                      Voice:+39-2-6779 2553
Via del Parlamento 33                 FAX:+39-2-6779 2439

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 1993 14:22:03 GMT
From:      jnicolas@image.mit.edu (Julien Nicolas)
To:        comp.unix.ultrix,comp.protocols.tcp-ip
Subject:   *** PPP for ULTRIX?? ***


Hi 

Is there a public-domain PPP package that would compile under ULTRIX
4.3? Any recommendations? Thanks in advance for any replies.

Julien Nicolas 
jnicolas@image.mit.edu

PS: Could the answer to this question be placed in the FAQ?

-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 93 14:50:10 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

tar@sam.ksu.ksu.edu (Tim Ramsey) writes:

>rturner@imagen.com (Randy Turner) writes:
 
>>	I can understand Steve and others opinions regarding turning off
>>	checksumming in any case.  However, if you can verify that the
>>	two hosts are communicating over the same LAN, and the underlying
>>	data link layer (Ethernet in my case) is already performing a
>>	reliable datacheck operation, then I feel that the checksum operation
>>	is redundant.
 
>Not true.  I have seen data errors caused by a bad Ethernet interface cause
>UDP corruption.  Even if the data link layer does perform checksumming
>this does not help if you have a bad interface.
 
>-- 
>Tim Ramsey, tar@matt.ksu.ksu.edu
>  PGP2.2 public key available via keyserver, finger, or email.
>  MIME mail accepted (eagerly :)
>  Member of the League for Programming Freedom and the ACLU.


/*
	Normally a bad ethernet interface will cause error statuses
	to be returned by the ethernet device driver.  This is one way
	to detect packet failure.  If the interface is malfunctioning
	in any other way so as to preclude the problem from being
	reflected through status bits, then you will probably never even
	get your TCP connection started.  Hardware errors at the NIC
	are really not very common, and if they were, then detection of
	the problem should not be relegated to TCP checksum failures,
	rather, you would be having other problems long before that, such
	as ARP queries being trashed.                 
*/



-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1993 14:50:56 GMT
From:      D.Nash@utexas.edu (Donald L. Nash)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)


In article <rturner.740803663@imagen>, rturner@imagen.com (Randy Turner)
writes:
>    True, that's what it says.  However, RFC-793 was published before there
>    were sophisticated data-link layer services such as Ethernet or FDDI.
>    Since these data-link/MAC-layer services provide a more robust error
>    checking method (CRC-16/CRC-32), I would think if RFC-793 was written
>    today, there would probably be some type of clause that 
>    included a per-connection optional checksum method.

RFC 1122 re-affirms what was written in RFC 793, and 1122 was published in
October 1989.  Sophisticated data-links were very much in existence in
1989, but this did not encourage anyone to relax the checksum requirement
when 1122 was written.  And as others have pointed out, even Ethernet's
error checking method is open to failure if the network interface is bad.
Also as others have pointed out, there is no reliable way to tell when
your peer is on the same LAN as you are.  End-to-end checksums are *the*
only way to guarantee data integrity.

>	You would be surprised to find out what our network requirements
>	are.

I'll take your word on this, although you have piqued my curiosity with
this statement.

				++Don

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 93 15:54:33 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

oberman@ptavv.llnl.gov writes:


>First, there are LOTS of ways for data corruption to occur outside of the
>Ethernet FCS.

/*
	Probably.  But if you go to extremes of providing case histories
	of intricate hardware failure, then even the validity of RFC1122
	starts to break down.  There are assumptions made about the 
	reliability of hardware for a particular protocol specification.
	There are limits of tolerability in the specs.  Even for an
	implementation that fully conforms to RFC793 and RFC1122, you
	can still get blown away by memory parity errors when transferring
	the buffer from TCP to the socket layer. 
*/

>Second, this section is from RFC1122, not 793. 1122 was written in 1989, long
>after Ethernet became dominant and even after the introduction of FDDI. When
>Bob and company put a "MUST" in 1122, they meant it. I do disagree with some
>things in 1122, but skipping the checksum in TCP would NEVER be one of them. I
>have little doubt that it 1122 was written today, it would read exactly the
>same on this issue.

/*
	I am still talking about providing full RFC793 and 1122 support, but
	also adding the option, on a per-connection basis, of disabling
	inbound checksums, if the system has apriori knowledge that a
	particular connection from a particular host is on the same LAN.
	For a connection of this type, alot of the robustness provided by
	TCP would go unused (e.g. packet reordering) and the connection 
	would probably be making use of TCP flow control only.
*/

>More important, 1122 compliance is a requirement in a lot of specs. It's in
>every one that I put out with if it involves IP. If I ever receive a bid that
>does not include 1122 compliance, I would probably reject it. This is called
>negative sales impact or losing money, hardly something a business would want.
>This can also impact severely on performance reviews of the programmers
>involved.
 
>Finally, please tell me just how you can be sure that the two systems are on
>the same LAN? And if there is a bridge between them, they are NOT on the same
>LAN. I've seen broken bridges corrupt packets and give them the correct FCS.

/*
	If you've got a bridge that can corrupt packets and give them the 
	correct FCS, then chances are there is failure mode in this
	configuration that would break even the RFC1122 assumptions.
	Not to mention wreak havoc of all kinds with other network 
	activity.  The permutations of that kind of failure are pretty
	staggering.
*/
>R. Kevin Oberman			Lawrence Livermore National Laboratory
>Internet: koberman@llnl.gov		(510) 422-6955
 
>Disclaimer: Being a know-it-all isn't easy. It's especially tough when you
>don't know that much. But I'll keep trying. (Both)


	Randy
-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 1993 15:59:55 GMT
From:      berlin@is.morgan.com (Alexander Berlin)
To:        comp.protocols.tcp-ip
Subject:   Re: How to detect connect() failure with non-blocking I/O?

In article <209suc$inf@lll-winken.llnl.gov>, booloo@framsparc.ocf.llnl.gov (Mark Boolootian) writes:
|> If I have a socket descriptor which has been set for non-blocking I/O and I 
|> perform a connect(), under normal conditions I will receive an error 
|> (EINPROGRESS).  At that point, I can then issue a select() and wait for the 
|> connection to complete.
|> 
|> However, if I have connected to a non-existent port, the select() will pay off 
|> indicating the socket is ready for both reading and writing, but gives no 
|> indication that the connect() actually failed until I try writing the socket
|> and find it isn't connected.
|> 
|> Is there some mechanism for discovering that the connect() failed without
|> actually trying to read/write the socket?
|> 
|> thnx and regards,
|> mb

When select() pops call connect() on that socket again and check errno.
If the first connect() failed errno will be EBADF. If it was successful
errno will be EADDRINUSE.

|> -- 
|> Mark Boolootian		booloo@llnl.gov		+1 510 423 1948
|> Disclaimer:  booloo speaks for booloo and no other.
 
-- 
Alex Berlin                     
berlin@is.morgan.com

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 1993 16:37:33 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

    True, that's what it says.  However, RFC-793 was published before there
    were sophisticated data-link layer services such as Ethernet or FDDI.
    Since these data-link/MAC-layer services provide a more robust error
    checking method (CRC-16/CRC-32), I would think if RFC-793 was written
    today, there would probably be some type of clause that 
    included a per-connection optional checksum method.

Not true.  Ethernet existed long before RFC-793 came out.  The TCP checksum
is needed by the End-To-End Argument.

Note the whole question of bypassing TCP checksums, and ways to make TCP go
fast and do the checksum at little or no cost, was discussed in late March '93
on this newsgroup.

Craig

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 1993 16:53:23 GMT
From:      hyder@mrbean.scd.ucar.edu (Paul Hyder)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?

This topic is starting to go back and forth, and the reasons behind
the different perspectives are important, so it is time to add my two
cents worth.  [Flames to /dev/null, comments by email please.]

1.  It is critical to note that most host queries (gethostbyname, etc.)
    return a hostent struct that includes a >LIST< of IP addresses.
    [N.B. NIS limits this behavior, watch out.  Where DNS and NIS are
    used locally careful control of which hosts are found in each
    is important.]

2.  UNIX network utilities (rcp, rlogin, telnet, ...) are supposed
    to look at this list and connect to an optimal IP address based on
    the attached network interfaces.  If no direct interface matches
    the utility will use the first IP address in the list.  [Older
    IP implementations (like some kludges into SysVr3) may just use
    the first entry.]
    
    BTW if the connection to the primary address selection times out
    many utilities will cycle through the list trying some or all of
    the others.

3.  Only when you ifconfig interfaces do you have to watch out for
    duplicate names.  This means the host with multiple interfaces
    indeed must know how to attach the IP addresses to the correct
    interfaces.  All other network attached devices trying to reach
    the multiple networked host should not be confused.  {I use IP
    addresses instead of names in ifconfigs.  There are lots of equally
    effective practices.}

The combination of proper utility behavior and good list sequencing 
makes one DNS host name mapping to multiple IP addresses a very powerful
access and load control tool.  It also makes permissions on hosts with
lots of network interfaces infinitely easier.

As one other message pointed out a combination of one host one name
and individual names for each interface may work better for you.  My
practice is to use the IP address directly when I need to access a
specific interface so one host one name is cleanest.

Unless your network is very simple or very rigidly constrained, putting
only individual names on each interface and proliferating them via DNS
is a long term mistake.
	Paul Hyder
	Network Engineer
	NCAR

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 1993 16:59:21 GMT
From:      rhealey@ssesco.com (Rob Healey)
To:        comp.protocols.tcp-ip
Subject:   Re: tcpdump for non-BSD systems (eg System V, SCO/ODT)

In article <207t5iINNjml@dssdev2.med.osd.mil>, mfraser@dssdev2.med.osd.mil (Mike Fraser) writes:
|> Has anyone ported 'tcpdump' to non-BSD based unix?  Specifically SCO/ODT
|> V2 which is SysV3.2.4 based.  If so, can you provide a pointer to it?
|> 
|> If not, can you recommend a similar tool that does run in the SysV world?
|> 
	You'll probably have to write the program yourself using the DLPI
	interface spec available from usl.com. Most SysV UNIXi follow the
	DLPI interface for their ethernet and token ring adapter drivers.

	-Rob

-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 1993 01:45:15 -0500
From:      tar@sam.ksu.ksu.edu (Tim Ramsey)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

matt% netstat -s
ip:
        0 bad header checksums
icmp:
        0 bad checksums
tcp:
       21036149 packets received
               144 discarded for bad checksums
udp:
       0 bad checksums

This is on a Solbourne running 4.1A.3 (akin to 4.1.1).  The running kernel
apparently has UDP checksums disabled. :(

-- 
Tim Ramsey, tar@matt.ksu.ksu.edu
  PGP2.2 public key available via keyserver, finger, or email.
  MIME mail accepted (eagerly :)
  Member of the League for Programming Freedom and the ACLU.

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 1993 17:28:21 GMT
From:      artman@vpnet.chi.il.us (Wilfred A Artman)
To:        comp.protocols.tpcp-ip,comp.protocols.tcp-ip.domains
Subject:   Network Information

I am looking for a point of contact for information on obtaining Class 3
Internet address(s). The old point of contact, NIC, is now devoted
soley to Defense Department type stuff. That much I know.

Any help will be greatly appreciated!

AtDhVaAnNkCsE

==========================================================================
Wil Artman
Senior Systems Administrator
Millward Brown, Inc.
Naperville, IL

voice: (708) 505-0066
email: artman@vpnet.chi.il.us
CompuServe: 72203,707

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 1993 17:55:31 GMT
From:      gandalf@Csli.Stanford.EDU (Juergen Wagner)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?

In article <1993Jun22.184900.25821@nntpxfer.psi.com> alun@huey.wst.com (Alun Jones) writes:
...
>
>If you're implying something like:
>
>host.domain.net		IN	A	555.126.3.1
>host.domain.net		IN	A	555.198.64.198
>
>in the named.hosts file and in the named.rev file:
>
>1.3.126.555.IN-ADDR.ARPA	IN	PTR	host.domain.net
>198.64.198.555.IN-ADDR.ARPA	IN	PTR	host.domain.net
>
>I can guarantee that isn't going to be liked.
...

Why is that so? Is that so?

RFC1034 mentions under "Inverse Queries" (3.7.2:
   
   Inverse queries may not return the proper TTL, and do not indicate cases
   where the identified RR is one of a set (for example, one address for a
   host having multiple addresses).  Therefore, the RRs returned in inverse
   queries should never be cached.
   
   Inverse queries are NOT an acceptable method for mapping host addresses
   to host names; use the IN-ADDR.ARPA domain instead.

Also notice the example at the end of the RFC. SRI-NIC.ARPA is a host with 
two addresses which are mapped back via PTR records to the same name.

RFC1035 mentions explicitly under 3.4.1

   Hosts that have multiple Internet addresses will have multiple A
   records.

A little later (3.5), an example of gateways is given.


Personally, I would recommend using both models (single/non-unique and
multiple/unique names) at the same time:

The canonical name of a host should be mentioned with both addresses
which in turn map back to the host name via PTR.

In addition to that, interface-specific names would specify only
information for a single interface, allowing users to name interfaces
explicitly. This can be done by using different host names (e.g.,
host_le0.foo.bar.edu and host_le1.foo.bar.edu) or different domain
suffixes (e.g., host.sub1.foo.bar.edu and host.sub2.foo.bar.edu). The
second alternative is especially useful in cases where some hosts have
two interfaces two networks of different speed (e.g., X.25 and
Ethernet, or Ethernet and FDDI). You would have one domain for the
fast side and one for the slower side of each host.

Just my DM 0.03 (= approx. $ 0.02)...

--Juergen Wagner

J_Wagner@iao.fhg.de
gandalf@csli.stanford.edu

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1993 19:39:04 GMT
From:      mjo@iao.ford.com (Mike O'Connor)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.dcom.lans.token-ring,comp.dcom.lans.ethernet
Subject:   Re: any "middleware" API products

In article <FKITTRED.93Jun23102019@spchp13.BBN.COM>
fkittred@spchp13.BBN.COM (Fletcher Kittredge) writes:

:Humm, I would be wary of PC connectivity expertise from the terminal
:room of a Usenix conference terminal room ;-).  Besides, you don't

<laughs>  

:seem to be answering the question, which was about APIs not protocols.
:The WinSock API is designed to be such an API.  WinSock is in version

Under Windows, this is to some extent true, but I'm not going to rely
on Winsock or any other omnipresent, omnipotent protocol to seamlessly
"do" NFS and SNA.  As far as how an API relates to multiple protocols,
I'd have to say that the protocols are stacked against the API, since,
particularly with legacy protocols, the ability of the protocols
themselves to interoperate with other networks is limited.  And once
you get to the point where you have the network seamlessness, then you
have to worry about things like optimal performance and theoretical
vs. practical implementations.

-- 
 Michael J. O'Connor           |  Internet:  mjo@fmsrL7.srL.ford.com
 Ford Motor Company, OPEO      |  UUCP:      ...!fmsrl7!opeo!mjo
 20000 Rotunda, Bldg. 1-3001   |  Phone:     +1 (313) 248-1260
 Dearborn, MI  48121           |  Fax:       +1 (313) 323-6277

-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1993 20:43:03 GMT
From:      bob@comlab.gtri.gatech.edu (Bob Baggerman)
To:        comp.dcom.lans,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Re: Netbios over TCP/IP on HP-9000

djmiller@tasc.com writes:
>	Are there any other implementations of Netbios on a HP-9000? If
>not, can anyone direct me to a source for a generic unix C
>implementation which could be ported to the HP-9000?

Contact Syntax of Auburn, Washington, USA and ask about their LMserver
NetBIOS product.  They can be reached in the US at 206-838-2626.

Bob

-- 
Bob Baggerman                         !  bob.baggerman@gtri.gatech.edu
Communications Laboratory             !  bob@comlab.gtri.gatech.edu
Georgia Tech Research Institute       !  qseclrb@prism.gatech.edu
Atlanta, GA  30332  USA               !  404-894-3525

-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 1993 21:08:29 GMT
From:      alun@huey.wst.com (Alun Jones)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?


In a previous article, I stated that I could guarantee that using multiple
IP addresses mapped to the same host name was not going to be liked.

I have since been told that due to host name mappings returning a list of
IP addresses, this is a perfectly valid thing to do.

However, I'll guarantee you there's someone out there who doesn't like it.
:-)

Okay, I was wrong - I'm sorry.

Alun.
~~~~

-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 1993 22:00:21 GMT
From:      mwitt@kentrox.com (Michael Witt)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

Consider this case: you have a single IP "subnet", which is actually
a number of bridged Ethernets.  As far as I can see, there is no way
TCP could ever know about the bridges.

Now you have lost end-to-end reliability.  Bad memory in any of the
bridges could cause corrupted data to be accepted by TCP.

There are probably other more "interesting" cases.  Especially if you
allow subnets other than Ethernet.

-Mike

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1993 22:06:33 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

| From: peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
| 
| However, it does come to mind that printer output data (as opposed to
| e.g.  downloading software or fonts) has a particularly transient
| characteristic - a printer is a write-only device, so if you get a data
| error it only affects that single printout. It's not like a source file
| getting transfered with FTP, where an error can result in unrecoverable
| bit-rot for the rest of time.

  I understand your point, but I'd hate to be the person talking to the
president of an advertising agency that lost a multimillion dollar
contract because the printer silently corrupted an ad layout which was
then unknowningly sent on to a customer.  Not a good thing at all.

  Again, I understand that you yourself are not backing any move to allow
a non-checksum option on a protocol advertised as being reliable.  You
were just trying to think up some circumstance where it *might* be okay.
Unfortunately your write-once throw away printout of a letter from Mom is
someone else' bread and butter.

  I think the bottom line is that TCP is advertised as a reliable
protocol.  Throwing away the checksum is akin to fraudulent advertisement.

Casey

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 93 22:13:22 GMT
From:      donr@sadis05.kelly.af.mil (DONALD G. RUEBENSON II - SCST)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?

Alun Jones (alun@huey.wst.com) wrote:
: In article <C912Jz.57I@sadis01.kelly.af.mil> donr@sadis05.kelly.af.mil (DONALD G. RUEBENSON II - SCST) writes:
: >Jos Vos (jos@bull.nl) wrote:
: >: When a system has more than one interface, each with its own
: >: IP address, should the /etc/hosts file than contain the same
: >: hostname for each IP address, or should each IP address has
: >: its own unique name?
: >
: >One host, one hostname.  It is possible and allowable to belong to more than
: >one domain (e.g. sadis01.kelly.af.mil, class B and, sadis01.af.mil,
: >class A) but not required.
: >
: >If you are going to have more than one interface on a host, I woudl
: >recommend implementing Domain Name Service, as most /etc/hosts name
: >resolution mecanisms are 'top-down' searches and can lead to some
: >interesting "can't get there from here" problems.  DNS is a little more
: >intuitive about the resources available.
: >
: >Good Hunting,
: >  -- donr
 
: If you're implying something like:
 
: host.domain.net		IN	A	555.126.3.1
: host.domain.net		IN	A	555.198.64.198
 
: in the named.hosts file and in the named.rev file:
 
: 1.3.126.555.IN-ADDR.ARPA	IN	PTR	host.domain.net
: 198.64.198.555.IN-ADDR.ARPA	IN	PTR	host.domain.net
 
: I can guarantee that isn't going to be liked.
 
: Also, if only one reverse mapping is set up, then many ftp servers
: won't accept your logins if they go through the other network, since
: they take your address, resolve it into a name, and then resolve the
: name back to an address, which they then compare with your first
: address.  (Subtract the number you first thought of...)
 
: I'll stick with one host name for each IP address.
 
: Alun.
: ~~~~

I did not mean to implying anything.  This is precisely the configuration
we have been running, quite successfully, for several years.  Selection
of which interface outbound is determined by the route table based on
the address of the destination, and the packets sent are addressed per the
interface.  RARP queries resolve correctly to the host name, and queries
by hostname (ala nslookup) return all possible IP addresses, leaving it
as an exercise to the reader to try them as needed.

Really, unique Fully Qualified Domain Names vs. non-unique is a matter
of administrative preference.  I prefer one FQDN per host, and hide as
much of the details as possible from my user community.  Calling the
same machine by more than one name is the kind of "detail" that really
confuses some poor l_users!

The fact that the IP system is flexible enough to support this
difference of opinion is a tribute to the many hours and talents that
contributed to its design and refinement.

Can we call an end to this Jihad, now?
  -- donr

-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 1993 23:29:40 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <rturner.740850873@imagen>, rturner@imagen.com (Randy Turner) writes:
> ...
> 	I am still talking about providing full RFC793 and 1122 support, but
> 	also adding the option, on a per-connection basis, of disabling
> 	inbound checksums, if the system has apriori knowledge that a
> 	particular connection from a particular host is on the same LAN.
>...


You really ought to pay a little more attention to who is saying
turning off checksums is a bad idea.  They include (in overlapping
groups):

    -people with some experience as designers, implemenators and
	maintainers of fast network stuff, including TCP checksums.
    -people with a lot of experience as users, including using
	NFS/UDP implementations with checksums off.
    -big customers.

Note particularly that last catagory.  

Many people would reflexively and permanently disqualify any
printer-controller vendor that even optionally turns off TCP/IP
checksums.  Besides the obvious difficulties of being confident the
option is disabled on a black box like a printer, many people would
decide that a vendor that doesn't know better than to turn off TCP
checksums probably doesn't know better than to make other, more
interesting performance "improvements", and that the fun of discovering
those "improvements" is not enough to make up for the hassles of
eventually throwing out the vendor and getting products that work.

It might be different if turning off the TCP checksum could gain you 2X
in performance.  However, assuming your printer cannot do more than 5
pages/sec, and doesn't need more than one or two MByte/page (i.e. less
than 100Mbit/sec), the TCP checksum does not amount to 25% of the work,
and that work can be made to disappear into hardware for a low price.
All it takes is some 16-bit summers in the incoming data path.

If you're talking about a piddling 10 Mbit/sec ethernet controller for
a 5 page/minute postscript printer that needs a few 100Kbit/sec ...
well, enough.


Vernon Schryver,  vjs@sgi.com

-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Jun 1993 23:52:23 GMT
From:      len@forge.Tandem.COM (Len Fishler)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <peterd.740843443@pjd.dev.cdx.mot.com>, peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:

... stuff deleted

>However, it does come to mind that printer output data (as opposed to
>e.g.  downloading software or fonts) has a particularly transient
>characteristic - a printer is a write-only device, so if you get a
>data error it only affects that single printout. It's not like a
>source file getting transfered with FTP, where an error can result in
>unrecoverable bit-rot for the rest of time.

Gee, I think I'd like to get checks from that printer (:-)).  A single bit
error could make me a rich man.

>I still think it would be a bad idea, though.

Agreed.

- Len Fishler -
fishler_len@tandem.com

-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Jun 93 01:25:56 GMT
From:      mischler@norman.li.Cubic.COM (Dave Mischler)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

To all vendors of products that implement TCP:

If your product *ever* fails to calculate and check the TCP checksum,
please put this info in your ad so I can remember not to buy your
product.

Thanks.

Dave Mischler
mischler@cubic.com


-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 1993 02:07:35 GMT
From:      ah442@cleveland.Freenet.Edu (Erik C. Orange)
To:        comp.protocols.tcp-ip
Subject:   Software Question: using bind() and orphaned port addresses


Hi,

I have 2 programs that I wrote which SUCCESSFULLY communicate
with each other via sockets of type AF_INET, SOCK_STREAM.  One
program (the "server", if you will) goes through the normal
sequence of:

socket()
bind()
listen()
accept()

and then

send()
recv()

...and so on.  This program assigns a port address of N to the
socket.

Now, the question:  when I cause the program to end ungracefully
by terminally interrupting its execution, and I try to run it
again, the bind() call fails...due to an "address already in
use" error.  It seems that because a shutdown() and close() were
not applied to the socket, the address N is still allocated and
hanging around somewhere.

How can I re-use the address?  The socket option "reuse address"
doesn't seem to work.  By the way, this is using DEC's TCP/IP
services v2.0.  The old socket/address binding will reset after a
while (time is controllable by doing a $UCX SET PROTOCOL TCP/PROBE=<time>),
but that is too kludgy.

Any way I can reset an orphaned socket and re-use the address?


Thanks in advance,
Erik
-- 
Erik C. Orange                        FRD Industrial Automation
Computer Engineering                  Avery-Dennison Corporation
ah442@cleveland.Freenet.Edu           Concord, OH

-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 93 04:15:55 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)


	Sigh.  Looks like it's time for the quarterly argumentathon on
this.
	OK, let's take a closer look at this data that's SO precious
that we have to spend half our software processing time to calculate a
SECONDARY checksum.  First off, even I don't believe that Ethernet
interfaces or bridges always work, nor that the Ethernet CRC
catches every error.  My argument is that having this awfully
expensive checksum doesn't buy very much in overall system
reliability.
	From the basic structure of the way things tend to be done on
modern systems, it seems safe to conclude that the data came from a
disk.  Even if it didn't come directly from a disk, the data was
generated based on data that did come from a disk.  Like networks,
disks have reliability problems.  Probably the most common problem is
that media can go bad.  Well, that's OK.  On each sector of almost
every disk in existence there's a ECC or CRC covering the contents
of the sector.  The controller hardware embedded in the disk drive
checks or generates it each time a sector is read or written from
disk.  
	BUT - that ECC is only seen by the controller in the disk
drive.  It is NOT passed out beyond there.  The host disk interface
doesn't see it.  The host software never sees it.  That ECC on the
host controller is the only effort made at a checksum in the entire
process of disk I/O.  When I asked a file systems expert if anybody
even thought about doing checksumming in software on file system
blocks (the moral equivalent), he made noises like I was crazy.  As
far as I am aware, the closest anybody's ever come to such a thing
for a filesystem for a general-purpose machine is the checksum over
a four bytes out of each entire block in LFS.  Thus, in theory, if
the disk controller, host interface, memory interface, or CPU goes
bad, they could merrily corrupt disk blocks without being detected.
And that's where most network data comes from.  
	In that kind of world, why on earth is a secondary checksum
so important?  You can put dozens of checksums on the network data
and there's little reason to believe that it would have any impact
on resistance to data corruption overall, because after traveling
over the safe network, the data will get corrupted on the way to
the disk drive.
	I would still agree that an additional checksum would do no
harm if it were cheap.  But it isn't.  Even if you do the checksum and
copy combination work that Craig Partridge mentioned, the checksum
only becomes cheap if your memory system is slow enough to cover
the latency of the extra summing instructions - if your processor
architecture happened to have a sum-with-carry instruction, that 
helped.  A 68020 has a sum-with-carry instruction, but the 68020 is
*SO* much hopelessly slower than its memory system that I don't
expect it'd be anything like enough to make checksumming cheap.
	It has been pointed out that a broken bridge can corrupt
packets.  True.  However, the chance that any given packet will be
corrupted is not a boolean, but rather a fraction.  Since the chance
that a bridge itself will have problems is small, if you put a
bridge into a network, it would probably raise the chance of
corruption, overall by an extremely tiny amount, the more so
since a bridge should not recalculate FCSs but rather pass them
through.  In any case, I expect that the resulting reliability will
still be serious orders of magnitudes better than disk reliability.

craig@sics.se (Craig Partridge) writes
> The TCP checksum is needed by the End-To-End Argument.

	But TCP/IP does not implement an end-to-end checksum.  The
data comes from sockets, which got it from a user process, which in
turn probably got it from disk, where the checksum is no longer in
evidence.  The data goes to a different user process, which in turn
is going to put it on a disk.  The user processes and disk
interface and controllers are free to scribble all over that data
without fear of detection.

> This very illegal according to the TCP specification and the Host
> Requirements RFC ...

Near as I can tell, the strictures against checksumming were
considered in an atmosphere of blanket switches controlling whether
checksumming was done at all, ever.  If you completely turn off
checksumming, then start sending packets across the Internet, you
are likely to be unhappy.  Redundant checksum avoidance is a very
different beast, as it is able to detect such things.

> You really ought to pay a little more attention to who is saying
> turning off checksums is a bad idea.  They include (in overlapping
> groups):
> 
>     -people with some experience as designers, implemenators and
>         maintainers of fast network stuff, including TCP checksums.
...notably Vernon Schryver, who has put gobs of time into doing
the Internet checksum in hardware, and thus seems to have a
particular hatred for this scheme, even though he doesn't implement
an end-to-end checksum either.  
	Those who are considering boycotting poor Randy should
boycott SGI too.  It is true that SGI lives up to the letter of
RFC1122 (the checksums ARE calculated, no question), but SGI
violates the original end-to-end spirit of protecting packets from
host memory to host memory, raising the chance that corrupt packets
will go undetected.

Examining the role of checksums in the network has long been
unfashionable in certain circles.  Yet I cannot seem to locate any
actual studies on the subject, even though the actual impact of
turning off checksums does not seem like an obvious issue at all.

So far, only one person has provided any numbers:
heimlich@watson.ibm.com (Steve Heimlich) says:
> I've seen two examples of equipment failures which were detected
> only by end to end checksum. 
How many years have you been working in networking?  Remember that
for each of those failures, half of the entire packetload going
across networks you were responsible for would have been processed
faster; your user community would have seen prompts coming back
faster and thus been that much happier and more productive.  How many
disk failures resulting in corrupt data occurred during the same
period?  In my own decade in this business, I've been hit by disk
problems more times than I can easily count.  The misprinted check is
going to happen because of a bad disk controller, not because of the
network.

							Jon

-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 1993 11:31:23 -0400
From:      dsc@xray.hmc.psu.edu (David S. Channin)
To:        news.announce.newgroups,news.groups,sci.med,sci.med.physics,sci.med.telemedicine,sci.image.processing,comp.graphics,comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   2nd CFV and VOTE ACK: comp.protocols.dicom

                       SECOND  CALL for VOTES:

Proposal: Creation of a new newsgroup: comp.protocols.dicom

The stated charter of the group is:
Charter:

The purpose of this group will be to discuss issues surrounding 
the American College of Radiology - National Electrical 
Manufacturers  (ACR-NEMA)  standard for Digital Imaging and 
Communications in Medicine (DICOM). This standard represents 
the next step beyond the ACR-NEMA version 2 standard released 
in 1988.

Postings will include information about progress of the development
of the standard, and issues concerning implementation  of the 
standard. Periodic postings will be made explaining how to obtain
the  latest versions of the available chapters, as well as information 
related to  demonstrations of the standard at the RSNA meeting.

This group will not be moderated.

If you are in favor of the creation of such a group, please send a message to:

       dicom-yes@xray.hmc.psu.edu

If you are opposed to the creation of such a group, please send a message to:

      dicom-no@xray.hmc.psu.edu
      
The voting period will end on July 8, 1993 at midnight. Any votes
received after this time will not be counted. Any votes received at
other e-mail addresses will not be counted. 

Thank you very much.

For off-line discussion concerning this CFV, please contact:
   
   dsc@xray.hmc.psu.edu
   
   David S. Channin
   Department of Radiology
   Section of Radiologic Computing and Imaging Science
   Penn State University
   The Milton S. Hershey Medical Center
   P.O. Box 850
   Hershey, PA 17033
   (717) 531 - 5728
 
The following individuals have already voted:

"Cor Posch, Automatisering, AZUA - AMC, Amsterdam." <POSCH@amc.uva.nl>
"Eric J. Olson" <ejo@kaja.gi.alaska.edu>
"Fred Prior, Ph.D." <prior@radmail.xray.hmc.psu.edu>
"Gerald Q. Maguire" <maguire@cs.columbia.edu>
"Paul Picot" <ppicot@irus.rri.uwo.ca>
"Umberto Tachinardi, MD" <TACHINARDI@incor.hc.usp.ansp.br>
93CRBM@npd1.ufpe.br
<NAM110@PSUVM.PSU.EDU>
Alan R. Bleier <bleier@NORMAN.VI.RI.CMU.EDU>
Alan Strassberg <alan@lscruz.scf.lmsc.lockheed.com>
Allan Noordvyk <allan@blue>
Andrew Schmidt <schmidt@cs.uiuc.edu>
Andy Hewett <Andy.Hewett@arbi.informatik.uni-oldenburg.de>
Bill Bennett <Bill_Bennett@qmserver.vortech.com>
Bill Owens <owens@desperado.cc.rochester.edu>
Brendan Forsyth <bff@csn.org>
Brian F Long <bflong@convex.csd.uwm.edu>
Chet Mazur <chet@spock.retix.com>
Dan Ritt <danritt@csn.org>
Dan Ritt <danritt@csn.org>
David Haynor <haynor@u.washington.edu>
Eric LaPresto <lapresto@bme.ri.ccf.org>
Georg Schwarz <georg@marie.physik.tu-berlin.de>
Hedley Bond <bond@scanner.hosp.utk.edu>
INFOMED@ccvax.unicamp.br
James Harrison <james@hplb.hpl.hp.com>
John.B.Weaver@Dartmouth.EDU (John B. Weaver)
KATER@WSUHUB.UC.TWSU.EDU
Keith Sklower <sklower@vangogh.CS.Berkeley.EDU>
Ken Krippner <kek@cms-stl.com>
Khanh Ly <k.ly@trl.oz.au>
Lutz Kleinholz <lutz@enterprise.DHZB.DE>
Marc Moorcroft <smarry@zooid.guild.org>
Mark Wofford <mgw@cool.vortech.com>
Martin Ohly <mjo@enterprise.DHZB.DE>
McBride_Brian/pinewood_lab_hpopd@hpopd.pwd.hp.com
Merge Technologies Inc. <Merge.Tech@mixcom.mixcom.com>
Murray Nesbitt <pseudo!mjn>
Paul Mockapetris <pvm@ISI.EDU>
Peter Hauke <se92psh@brunel.ac.uk>
Peter Hauke <se92psh@brunel.ac.uk>
RAY DEININGER <R_DEININGER@uvmvax.uvm.edu>
Randolph Gladish <randy@topaz.bds.com>
Richard L. Morin Ph.D. <morin@mayo.edu>
T.CASEY@cardiff-institute.ac.uk
TALLANTJ.DFP@mhs.unc.edu (TALLANTJ)
Trevor Cradduck <trevorc@uwovax.uwo.ca>
Zenon Fortuna <zenon@resonex.com>
add@philabs.Philips.Com  (Aninda Dasgupta)
alex@vuse.vanderbilt.edu (Alexander P. Zijdenbos)
andress@penfold.siemens.com (Keith M Andress)
arneny@mikrosys.no (Arne Nylund)
asw2s@palm.cs.virginia.edu
berman@nlm.nih.gov (Lewis Berman)
bogstad@blaze.cs.jhu.edu (Bill Bogstad)
chassign@lix.polytechnique.fr (Chassignet Philippe)
cjoa@fciad3.bsd.uchicago.edu
clay@cool.vortech.com (Clay Luther)
cmarble@fenris.claremont.edu (Chris Marble)
curran@stereo.medphysics.nemc.org (Bruce Curran)
dclunie@pax.tpa.com.au (David Clunie)
dgb@mrindigo.utmb.edu
diegert@cs.sandia.gov (Carl F. Diegert)
diro@edison.Phone.North.DE (Dirk Rode)
dsc@xray.hmc.psu.edu (David S. Channin)
elang@cs.unsw.oz.au (E   Setiawan)
ewert@nasse.cb.uu.se
frank@frank.vortech.com (Frank Ely)
gargulak@colossus.med.ge.com (Anthony Gargulak 5-4308)
gary@maestro.mitre.org (Gary Bisaga)
gerrit@isgtec.com (Gerrit Visser)
gerry@cs.tamu.edu (Gerald J Creager)
giorgos@cs.rochester.edu
gpmcdona@cats.UCSC.EDU (Glenn McDonald)
gt0670e@prism.gatech.edu (Brennan Tennesen Price)
hagmanti@cps.msu.edu
herbison@lassie.ucx.lkg.dec.com (B.J.)
hlavac@prip.tuwien.ac.at
jbono@atl.com
jfurr@polaris.async.vt.edu (Joel Furr)
jhoben@jwh.win.net (John W. Hoben)
jkippen@newssun.med.miami.edu (Jonathan Kippenhan)
jkkjasio@psk2.am.lod.edu.pl (jan k.kaminski)
jlc@adaclabs.com (Jean-Luc Chatelain)
jperser@pluto.vortech.com (John Perser)
jpower@atl.com
jvpardo@vapet.uucp@cs.umn.edu (Jose V. Pardo)
kelly@simvax.labmed.umn.edu
kevino@nmgw.nm.nasu.toshiba.co.jp (Kevin O'Donnell)
lsven@uckbv1.ece.uc.EDU (Sven Loncaric)
maj%mdis1@wdl1.wdl.loral.com (Michael A Johnston)
mct@philabs.Philips.Com  (Mark C. Tucker)
minmail@mindymail.win.net (MINDY NEMON)
mitchell@alydar.crd.ge.com (Robert Mitchell)
mitrakos@cperi.forth.gr (Dimitris Mitrakos)
mjb@cs.brown.edu (Manish Butte)
nam@modu.etri.re.kr (Nam Ji-Seung)
nightowl@brimston.apana.org.au (Leanne Taylor)
nrd@lenti.med.umn.edu
parisot@mmi3.med.ge.com (Charles Parisot 5-5857)
ph@physiology.oxford.ac.uk (Patrick Haggard)
ploeger@aplki.toppoint.de (Andreas Ploeger)
rick@crick.ssctr.bcm.tmc.edu (Richard H. Miller)
rob horn <horn%temerity@leia.polaroid.com>
robday@uniwa.uwa.edu.au (Robert Day)
shin@nop.han.de (Hoen-oh Shin)
shukky@acs.bu.edu (Joshua Blume)
sippel@mallet.med.ge.com (Teri Sippel 5-5045)
smm@wuerl.WUstl.EDU (Steve Moore)
srl@wdl1.wdl.loral.com (Steve Lennon)
srogers@tad.eds.com (Steve Rogers)
srogers@tad.eds.com (Steve Rogers)
stanley@kpc.com (Stanley Guan)
steve.strother@vapet.uucp@cs.umn.edu (Steven Strother)
swire@Kodak.COM (Alan Swire)
vezina@jupiter.drev.dnd.ca (Guy Vezina)
wbrand@lehman.com (Willy Brandsdorfer)
weinhous@alpha.hahnemann.edu (Martin S. Weinhous Ph.D.)
wes@wes.win.net (Wes Rishel)
wmihalo@rdth2.rdth.luc.edu (William E. Mihalo, PhD)

-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Jun 93 05:34:54 GMT
From:      slester@vetmed.wsu.edu (Sam Lester)
To:        comp.unix.misc,comp.protocols.tcp-ip,comp.lang.perl
Subject:   Re: lpd to ftp filter



  HP uses tftp to drive some of its jet-direct cards.  It works fine.

  The /usr/spool/lp/interface/TFTPPRINTER script calls the model
orginal script (IE HP-LaserJetIIISi) located in
/usr/spool/lp/interface/model.orginal/TFTPPRINTER.  The scripts work
very well taking what would normally go directly to the printer and 
piping it,storing it, and/or transporting it to the final destination.

  I used there scripts to print to portable netware printers and to 
print to disk-files...(Batch night-print of large jobs).  


   Quickie diagram of what goes on-->

 User command
lp -A$OPTS <filename>
    --->lpd which calls /usr/spool/lp/interface/A 
       with $OPTS and filename
         --> this calls the model original/A and stores
            output.. 
          -->transport (found in /usr/spool/lp/interface/A) to
             destination(physical printer).



Sam Lester 
slester@vetmed.wsu.edu
Paul Campbell (M21816@MBVM.Mitre.Org) wrote:
> hi all,
>  
> i am interested in obtaining information regarding a FTP filter i am
> planning for LPD.  i would like to provide remote job submittal to
> our MVS machine from various Unix environments.  in my preliminary
> tests i have found a way to drive the UNIX FTP package using Perl but
> i am not sure of the kinds things i should be sensitive to regarding
> the interface with LPD.  it is my understanding that it should be
> possible to drive processes other than printing with LPD.  in my
> scheme i would like to add a printer that would use my output filter
> to drive the FTP connection.
>  
> Ideally, i would like the filter to be a Perl script (or maybe
> envelope the script in a more secure "C" driver) but i am open to
> suggestions.  i plan to have a dummy device (:lp=/dev/null), a
> spooling directory, the output filter and a logging file as part of the
> printcap entry.  can anyone think of any problems with doing this?
> many thanks /pc

-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Jun 1993 05:37:49 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <51179@sdcc12.ucsd.edu>, jkay@cs.ucsd.edu (Jon Kay) writes:
> ...
>          In my own decade in this business, I've been hit by disk
> problems more times than I can easily count.  The misprinted check is
> going to happen because of a bad disk controller, not because of the
> network.


How many of those disk problems produced undetected errors?

In other words, how many of those disk problems were similar to the
undetected and undetectalbe network problems we're talking about?

In other words, how many of those disk problems did not involve reading
and writing the medium (since, as you note, that's protected with an
ECC), but involved undetected errors while transfering data between the
controller and main memory?


Vernon Schryver,  vjs@sgi.com

-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 93 05:54:21 GMT
From:      claude@bauv.unibw-muenchen.de (Claude Frantz)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?

jos@bull.nl (Jos Vos) writes:

>When a system has more than one interface, each with its own
>IP address, should the /etc/hosts file than contain the same
>hostname for each IP address, or should each IP address has
>its own unique name?

Every Internet address refers to a specific host which can have
zero or more names in the DNS.

A hostname in the DNS can refer to one ore more Internet
addresses. Multiple addresses are common when refering to
routers.

This is not specific to UNIX, but it is simpler to use
one address for one interface when using UNIX.
--

Claude F.

This message may contain opinions which are not shared by my employer.

-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 93 16:47:01 CST
From:      cuadrasola@kuhub.cc.ukans.edu
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for DesQview/X


Are there any public domain TCP/IP kernels that will allow me to set up
a 486 running DesqView/X as an X terminal, so that X programs can be run
remotely?  The DesqView/X documentation gives a list of commercial 
packages that can be used (like PC-NFS, FTP's TCP/IP, and some others).
I was wondering if there would be a public domain one that will do the job
and if not which would be the cheapest commercial product that I could
use.

--- Juan Cuadra-Sola
    cuadrasola@kuhub.cc.ukans.edu  

-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 93 18:17:24 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum

$ netstat -s
ip:
        1707065 total packets received
        0 bad header checksums
icmp:
        180 calls to icmp_error
        0 bad checksums
        0 messages with bad length
tcp:
        total packets sent: 881440
        data packets sent: 743044
        data bytes sent: 340182740
        total packets received: 754947
        bytes received in sequence: 50072550
        packets received with cksum errs: 7 	<<<
        packets received with bad offset: 0
        packets received too short: 0
udp:
        0 incomplete headers
        0 bad data length fields
        0 bad checksums

	Dell Unix SVR4.04, Lachman TCP/IP, Ethernet. This too probably has UDP 
checksums off (gets a lot of NFS work). Might we speculate the probabilty of 
an error is somewhat proportional to packet length from these figures (no IP 
chksum errors, 7 for TCP)? 
	Joe D.


-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 93 14:07:38 GMT
From:      jordan@IMSI.COM (Jordan Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: How to detect connect() failure with non-blocking I/O?

Alexander Berlin <berlin@is.morgan.com> writes:

	When select() pops call connect() on that socket again and
	check errno.  If the first connect() failed errno will be
	EBADF. If it was successful errno will be EADDRINUSE.

Are you sure?  For me, it returns EINVAL if the connect() failed, and
EISCONN if it succeeded.  Which BSD-ish system are you on?

/jordan

-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 93 14:27:29 GMT
From:      torrico@arfaduke (Thomas V Torrico)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <208mp0INN13m@sam.ksu.ksu.edu> tar@sam.ksu.ksu.edu (Tim Ramsey)  
writes:
> rturner@imagen.com (Randy Turner) writes:
> 
> >	I can understand Steve and others opinions regarding turning off
> >	checksumming in any case.  However, if you can verify that the
> >	two hosts are communicating over the same LAN, and the underlying
> >	data link layer (Ethernet in my case) is already performing a
> >	reliable datacheck operation, then I feel that the checksum  
 operation
> >	is redundant.
> 
> Not true.  I have seen data errors caused by a bad Ethernet interface  
 cause
> UDP corruption.  Even if the data link layer does perform checksumming
> this does not help if you have a bad interface.
> 
> -- 
> Tim Ramsey, tar@matt.ksu.ksu.edu
>   PGP2.2 public key available via keyserver, finger, or email.
>   MIME mail accepted (eagerly :)
>   Member of the League for Programming Freedom and the ACLU.
This whole thread is rather interesting. I've been in a situatuion where  
no checksumming is particularly desirable.
Using a 'smart' adapter to offload physical transport for HIPPI (High  
Performance Parallel Interface) at 100 MBytes/Sec (yes bytes) the  
calculation of the checksum takes about the same time as the packet  
transmission.
The hardware guarantees acurate delivery plus the adapter has both data  
and parity checking. Why checksum on the same local net?
Using UDP without checksumming we could only achieve aroung 19 MBytes/sec.
Without checksumming, it jumped to 27MBytes/sec.
--
Make all things as simple as possible but no simpler. -- Albert Einstein

-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Jun 1993 14:47:47 GMT
From:      peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

Just to add a few more flames to the fire, I thought I would ask how
many of us use printers which are connected over serial ports (with no
end-to-end check) rather than via TCP over e.g. Ethernet? 

Continuing, though -

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>It might be different if turning off the TCP checksum could gain you 2X
>in performance.  However, assuming your printer cannot do more than 5
>pages/sec, and doesn't need more than one or two MByte/page (i.e. less
>than 100Mbit/sec), the TCP checksum does not amount to 25% of the
>work,

Assuming that there is one CPU in the printer, you are going to have
to spend cycles on both I/O (TCP) and imaging. If the printer running
flat-out uses (for example) 50% of its cycles on imaging and 50% on
TCP, then cutting TCP cycles by half increases the printing speed by
50%. If TCP takes 10%, though, it will hardly be worth it.

>and that work can be made to disappear into hardware for a low price.
>All it takes is some 16-bit summers in the incoming data path.

For the cost of that much hardware they could probably change the '020
to a 29K or R3000 and speed up the imaging software to boot. 

>If you're talking about a piddling 10 Mbit/sec ethernet controller for
>a 5 page/minute postscript printer that needs a few 100Kbit/sec ...
>well, enough.

Another way to ask this question - in the most I/O intensive use of
the printer (bit-map data in some form, I assume) how many
instructions per byte does it take to take the data from TCP and print
it? Is the overhead of an add for every other byte (i.e. the checksum
overhead) significant in comparison to this?

				Peter Desnoyers
-- 

-----------[000453][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Jun 1993 14:58:14 GMT
From:      a2824ab@sunmanager.LRZ-Muenchen.DE (Werner Spirk)
To:        comp.protocols.tcp-ip
Subject:   search for POP3 daemon for HP-UX

I am searching for a POP3D version ( version of University
of California at Davis ) for HP-UX.
In general I am searching for routines or a description 
for changing flock to lockf routines inclusive parameters.

Thanks in advance

Werner Spirk
email: spirk@lrz-muenchen.de


-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 93 15:24:11 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>In article <rturner.740850873@imagen>, rturner@imagen.com (Randy Turner) writes:
>> ...
>> 	I am still talking about providing full RFC793 and 1122 support, but
>> 	also adding the option, on a per-connection basis, of disabling
>> 	inbound checksums, if the system has apriori knowledge that a
>> 	particular connection from a particular host is on the same LAN.
>>...


>You really ought to pay a little more attention to who is saying
>turning off checksums is a bad idea.  They include (in overlapping
>groups):
 
>    -people with some experience as designers, implemenators and
>	maintainers of fast network stuff, including TCP checksums.
>    -people with a lot of experience as users, including using
>	NFS/UDP implementations with checksums off.
>    -big customers.
 
>Note particularly that last catagory.  
 
>Many people would reflexively and permanently disqualify any
>printer-controller vendor that even optionally turns off TCP/IP
>checksums.  Besides the obvious difficulties of being confident the
>option is disabled on a black box like a printer, many people would
>decide that a vendor that doesn't know better than to turn off TCP
>checksums probably doesn't know better than to make other, more
>interesting performance "improvements", and that the fun of discovering
>those "improvements" is not enough to make up for the hassles of
>eventually throwing out the vendor and getting products that work.
 
>It might be different if turning off the TCP checksum could gain you 2X
>in performance.  However, assuming your printer cannot do more than 5
>pages/sec, and doesn't need more than one or two MByte/page (i.e. less
>than 100Mbit/sec), the TCP checksum does not amount to 25% of the work,
>and that work can be made to disappear into hardware for a low price.
>All it takes is some 16-bit summers in the incoming data path.
 
>If you're talking about a piddling 10 Mbit/sec ethernet controller for
>a 5 page/minute postscript printer that needs a few 100Kbit/sec ...
>well, enough.


>Vernon Schryver,  vjs@sgi.com


	We have no intention of releasing a product that is not fully
	compliant with all of the host requirements as specified in
	RFC 1122, as well as all of the other RFCs to which our network
	software corresponds, whether it be TCP,UDP,IP,ICMP, ARP, etc.

	The discussion was purely hypothetical and was meant to generate
	a discussion on potential optimizations that might be applied
	to a TCP implementation to increase throughput.

	Further, we would not initiate such modifications to our product
	without adequate industry-wide backing and approval of such a 
	change, since interoperability is what we are trying to achieve.

	Currently, it seems, there is no guaranteed way of verifying the
	conditions (topology) for a particular connection so as to allow
	a TCP implementation to make shortcuts, so it seems that the
	original suggestion is not currently possible. 

	I would like to point out that we are constantly being asked by
	customers if there is some way to increase throughput since 
	these customers are not only sending data to a print engine, but
	also to a spool device.  So for our larger departmental type
	printers with high-end throughput (32 ppm+), we are required to
	spool incoming data to local disk(s) with some files in the 10's
	of megabytes in size.  These customers choose to let the printer
	spool the jobs rather than the host computer.  So our throughput
	requirements are based more on disk-to-disk transfers rather than
	disk-to-print-engine tranfers. 

	Randy



-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000455][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Jun 1993 15:41:13 GMT
From:      bhati@plains.NoDak.edu (Amit Bhati)
To:        comp.protocols.tcp-ip
Subject:   Installing Sun RPCSRC4.0... & the initd() deamon. Help.

I have been in the process of installing the RPCSRC4.0 on our computer and
came upon the initd deamon program. I do not know how well the RPC stuff
will work because I think it needs to be started at boot time before the
inetd program.
Will initd interfere? Or am I just dreaming problems? Anything, that a
fairly novice user/installer like me should take care of (in perticular)?

Appreciate replies be e-mail.

Many thanks,
amit


-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 93 16:05:01 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)


	Since bypassing checksums is out, someone mentioned in an earlier
	discussion that there was a tech.paper or RFC that contains the
	latest draft proposals for TCP/IP performance enhancements. Does 
	 anyone know which document this was?

	Thanks!
		Randy 
-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000457][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Jun 1993 16:43:57 GMT
From:      imp@boulder.parcplace.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <51179@sdcc12.ucsd.edu>, jkay@cs.ucsd.edu (Jon Kay) writes:
>          In my own decade in this business, I've been hit by disk
> problems more times than I can easily count.  The misprinted check is
> going to happen because of a bad disk controller, not because of the
> network.

It has been my experience, both as a product tester and as a customer,
that network problems happen an order of magnitude more often than
disk problems (except floppies, which don't count).  The TCP checksums
make these transient network problems invisible to me so I don't have
to worry about them.  Removing the checksums removes one more layer
of assurances that the data will get there safely.  It effectively
eliminates the network layer from hosing packets.

The problems were especailly severe when we were on a network that had
a bridge that would munch the ends of packets every 100,000 packets or
so.  The checksums were recomputed in this bridge, so the ethernet
hardware on the other side didn't detect the error.  The problem showed
up with odd NFS corruption (this was back in the bad old days of
disabled UDP checksums), but FTP would alway be fine, even on multiple
megabyte files.

I haven't had an undetected disk failure that showed up.  All the disk
failures that have bitten me have been detected.  I would think after
all the years I've been around that I might notice at least one glitch
after the fact.

Granted, this isn't "hard evidence," but it has been my experience and
my judgement that checksums are indeed worth it.  They are there so
that people with slight flaky networks can still mostly use them
effectively.  Given the kinds of networks I've seen people build, I
certainly would never purchase something that disabled TCP checksums,
nor would I design something without them.

Oh well, just my two cents worth.

Warner
-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.

-----------[000458][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 93 17:58:28 GMT
From:      ken@Bridge.COM (Ken Hardy)
To:        comp.protocols.tcp-ip
Subject:   PCRoute Status ??

It's my (perhaps flawed) understanding that LANPort, Inc., took PCRoute
commercial to at least some degree in order to be able to dedicate the
necessary resources to enhance and support it.  I sent email to
Lanport@cup.portal.com asking for information on what they have
available, but never got any response.  What is the status of this
product?  I'm running the last version with the source available via
FTP.  Is this the latest available?


-----------[000459][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Jun 1993 18:12:49 GMT
From:      jos@bull.nl (Jos Vos)
To:        comp.windows.x,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Speed of X using modem-connections (SLIP, PPP, X-remote, ...)

Can anyone supply me with some (relative) performance figures
about using X over an ordinary phone-line?

-  What about SLIP versus PPP?
-  And when using Xremote (NDC)?
-  The usefulness of V.42bis compression, both when
   using plain SLIP/PPP and when using Xremote.
-  Speed differences between various PC-Xservers (Hummingbird,
   PC-Xview, Xvision, ...).

Specifically I'm asking for speed-comparisons between (mixtures of)
the above methods.

Please send responses via e-mail.
Thanks. 

-- 
--    Jos Vos <jos@bull.nl>   (UUCP: ...!{uunet,mcsun,sun4nl}!nlbull!jos)
--    Bull Netherlands, Professional Services, Amsterdam, The Netherlands

-----------[000460][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Jun 1993 18:58:11 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

jkay@cs.ucsd.edu (Jon Kay) writes:
>	Sigh.  Looks like it's time for the quarterly argumentathon on
>this.
>	OK, let's take a closer look at this data that's SO precious
>that we have to spend half our software processing time to calculate a
>SECONDARY checksum.  First off, even I don't believe that Ethernet
>interfaces or bridges always work, nor that the Ethernet CRC
>catches every error.  My argument is that having this awfully
>expensive checksum doesn't buy very much in overall system
>reliability.

Your argument assumes that the Ethernet card (like the disk controller)
correctly does its own CRC and the network driver does the intelligent
thing with the packet.  The world needs the hopeful, but I'm more
of a realist.

A year ago, someone on our site bought a truckload of DEC's new
Ethernet cards for PCs.

We installed the cards, used the supplied drivers, and all my  TCP
code worked but the non-TCP based filesystem was constantly getting
corrupted.  Adding a software checksum made the system work instantly.

It was 1992, the manufacturer was DEC, the quantities sold were
probably significant, and the CRC didn't work.  I don't care if
your software runs on PCs, Crays or Sinclair ZX-81's, you NEED
to be able to interoperate with all those broken cards!

Add all the people who are using non-Ethernet hardware which emulates
Ethernets at the driver levels.  On PCs, for example, most SLIP
implementations have an Ethernet emulation mode so the software
doesn't know the difference.  Do you want your stuff to appear 
broken to them too?

Erick
-- 


-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Jun 1993 18:59:30 GMT
From:      berlin@is.morgan.com (Alexander Berlin)
To:        comp.protocols.tcp-ip
Subject:   Re: How to detect connect() failure with non-blocking I/O?

In article <7881@bacon.IMSI.COM>, jordan@IMSI.COM (Jordan Hayes) writes:
|> Alexander Berlin <berlin@is.morgan.com> writes:
|> 
|> 	When select() pops call connect() on that socket again and
|> 	check errno.  If the first connect() failed errno will be
|> 	EBADF. If it was successful errno will be EADDRINUSE.
|> 
|> Are you sure?  For me, it returns EINVAL if the connect() failed, and
|> EISCONN if it succeeded.  Which BSD-ish system are you on?
|>

Sorry, I should have checked the codes before posting. It is EINVAL and
EISCONN (22 and 56) on Sun4 I'm using.

|> /jordan
 
-- 
Alex Berlin                     
berlin@is.morgan.com

-----------[000462][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Jun 1993 19:54:23 GMT
From:      gsa@mercury.udev.cdc.com (gary s anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

The list of testimonials from individuals saved by checksums or burned
by disabled checksums is extremely large.  This is quite obvious from
the posts in this thread.   The bottom line is that the checksum has
significant value and as a general rule should be used at all times.

There are two things, that have not been mentioned in this thread, 
which deserve some mention.

1)	The TCP (UDP) checksum has a number of holes.  The most prevalent
	is the inability to detect word transpositions.   There are other
	subtle hardware problems which corrupt messages that still pass the
	checksum test, but I'll leave an opportunity for others to tell their
	old war stories.  Also, it has been pointed out that TCP checksums
	are only between the transport layers (I'm not going to even get into
	transparent transport layer gateways).  Consequently, the data may
	have many unprotected data paths outside the scope of the TCP
	connection.  My point is that individuals with extremely high data
	integrity requirements write application protocols to guarantee 
	reliability and do not rely on the presence of lower layer 
	checksumming.  Assuming said application was sufficiently
	reliable this MIGHT be a case where TCP checksums are not needed.

2)	When the entire data path is known (either a priori or via
	negotiation), including both end systems and the connecting
	media, there MAY be some cases where TCP checksums MIGHT not
	be needed (or wanted):

	a)	If addding a checksum phase would increase the probability
		of an error.  "Loopback" is a possible example.  Effectively,
		anything which moves data unnecessarily (especially through
		less secure paths), in order to checksum, may be a candidate.

	b)	A "performance" case where the added wild card is that
		the application may tolerate some error loss (e.g. image
		which can be "touched up" later).

	c)	A "performance" case where a highly reliable point-to-point
		link is used.

	NOTE - "performance" simply means pressing the envelope of the
	available technology.

WARNING - in all of these "MIGHT" cases there is a HUGE assumption
that a desired level of reliability can be maintained between the peer
transport entities.

The fundamental problem with an Ethernet Printer application (or most any
peer-to-peer Ethernet applications) is that you do know the level of
integrity of the entire path (bridges, adapters, memory, OS's, peer
applications, etc.).  Consequently, you can not make any justifyable
determinations on the inherent reliability.  Unless you are writing your
own extremely reliable application, disabling the checksum will
open up a new hole for potential failures.  Your customers and 
other vendors (who might be errantly blamed for data integrity errors)
are not likely to look very favorably on your solution if this hole
is ever hit.

My simple rule is to use the checksums unless you are absolutely sure
you can deliver a sufficient level of reliability.

     Gary

-----------[000463][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Jun 1993 20:36:53 GMT
From:      mack23@avalon.eecs.nwu.edu (Chris Walsh)
To:        comp.protocols.tcp-ip,comp.sys.novell,comp.dcom.lans.misc,alt.flame
Subject:   IP over Arcnet MTU hassles...who is doing what wrong?

Howdy.

A week or so ago I posted a question regarding some problems I have been
experiencing when attempting to use the CUTCP ftpbin.exe executable to
transfer files from a PC attached to an Arcnet Novell LAN, thru a Novell
3.11 router/fileserver, to an ethernetted machine.  Here's a brief summary.

FTP "put" from Arcnet PC to ethernetted Unix box:   *fails* after 4K
FTP "get" from ethernetted Unix box to Arcnet PC:	*works*
FTP "put" from Arcnet PC to Arcnet PC on same wire: *works*
FTP "get" from Arcnet PC to Arcnet PC on same wire: *works*
FTP "get" from ethernetted Unix box to Arcnet PC:	*fails* after 4k
FTP "get" from ethernetted Unix box to ethernet PC: *works*
FTP "put" from ethernetted Unix box to ethernet PC: *works*

Using another DOS FTP executable, namely Lan Workplace for DOS's works all
the time.

It has been suggested to me that CUTCP's ftpbin.exe is hosed:

> I think you will be out of luck. CUTCPs TCP-code is most unforgiving
> to slow links and harware. I suppose it overruns the arcnet card in
> your novell-server, because the TCP window advertised by the target 
> system is usually > 2*MSS and simple arcnet cards are not able to 
> buffer back to back packets. CUTCPs error recovery is not too good 
> either. You could verify this by tweaking TCP parameters on the 
> targed to throttle CUTCP.

I strongly suspect that this is part of the problem.  The other part was
homed in on by my other respondent, who said:

> If i'm understanding the failing scenerio correctly -- a PC on Arcnet
> trying to put a file to a UNIX box on Ethernet, with one NetWare v3.11
> server between them -- then that would mean the PC is sending Arcnet
> packets that are larger than the NetWare node is prepared to accept.
> Since i don't know anything about the FTP TCP/IP implementation, i
> don't know what you could do about it on that end.  You might try
> playing around with the NetWare console parameter Maximum Physical
> Receive Buffer Size, since the NetWare Arcnet drivers always send and
> receive packets of that size.  Unfortunately, that parameter can only
> be changed by rebooting the server, and all the other Arcnet nodes --
> the ones that are currently working fine -- would need to change their
> MTUs to make them agree with it.  But perhaps you could at least set
> it very high for a test to see if you can do the transfer then.  If
> so, the MTU is definitely the problem, and all you need to do is
> figure out how to restrict its size on the FTP PC.

What I want to know is this: 

1) If my Novell server has both ethernet and arcnet interfaces, how 
do I tell it what MTU to use on the Arcnet side, while leaving the 
ethernet interface alone?  I am experiencing no ethernet difficulties.  
If my reading of RFC 1051 is correct, I want to use an MTU of 508 on 
the Arcnet side, and also set the MSS to this value.

2) Am I correct in assuming that I should set have a line in my
Arcnet'ed PCs CONFIG.TEL which says "mtu=508", and one that says
"maxseg=508"?  If not, what values should I use?

3) Does anyone know of a utility similar to tcpdump which I could
run on the Arcnet'ed PC to snarf all packets on the Arcnet wire and
see what the heck is going on on the Arcnet side of the Novell
router?

And finally...

4) It appears to me that CUTCPs package does not know how to cope
with fragments.  This strikes me as a Bad Thing(TM).  Am I in left
field on this?

BTW:  I did not attribute the quoted material, since it was sent to me in
private e-mail.  I do not mean to somehow cloak the identities of those who
contacted me for any reason other than to maintain their privacy.

Many thanks for anyone who can answer 1) and 2).  3) would be nice,
and I'll take anyone's opinion on 4) as a reality check.  Sorry to
have made such a long posting, but this is driving me NUTS and I
need some help to *smash* this problem into submission.  If I have
betrayed my ignorance of the Novell/Arcnet world, I apologize, but I
am trying to learn, believe me.  If I am somehow out to lunch on how
I think TCP works, then I *really* apologize, but I am pretty sure I
know what should be going on there. 

Post or email your responses.  You may want want to remove alt.flame
from the Newsgroups line.  I put it there as a spleen-venting
exercise, rather than littering this posting with bile.

Thanks again!

Chris


-----------[000464][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Jun 1993 23:09:39 GMT
From:      pjb@rudi.23kgroup.com (Paul J. Bell)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?

In article <1993Jun23.124454.23834@mtu.edu>, tomiii@mtu.edu (Thomas Dwyer III) writes:
|> Paul J. Bell (pjb@rudi.23kgroup.com) wrote:
|> 
|> >each ip address should have it's own, unique hostname. also, be sure to 
|> >modify rc and/or rc.local to ifconfig both addresses.
|> 
|> Oh really?  Seems odd, then, that a root nameserver (ns.nasa.gov for
|> example, but there are others) would not follow that rule...
|> 
|> 
|> Tom.III
|> tomiii@mtu.edu

perhaps not so odd. for every good reason for doing almost anything, there
are as many good reasons for doing the same thing some other way. in this
case, i expect the reasom may have something to do with what the designer
was trying to achieve by using multiple network connections.


cheers,
	paul

-- 
                                               They Think I'm "ONE OF THEM" 

-----------[000465][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 00:11:40 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip,comp.sys.novell,comp.protocols.tcp-ip.ibmpc
Subject:   Re: IP over Arcnet MTU hassles...who is doing what wrong?

(I'm transfering this to comp.protocols.tcp-ip.ibmpc, since it's
starting to sound like that's the place for it.)

In article <1993Jun24.203653.7060@eecs.nwu.edu> mack23@avalon.eecs.nwu.edu (Chris Walsh) writes:
>1) If my Novell server has both ethernet and arcnet interfaces, how 
>do I tell it what MTU to use on the Arcnet side, while leaving the 
>ethernet interface alone?  I am experiencing no ethernet difficulties.  
>If my reading of RFC 1051 is correct, I want to use an MTU of 508 on 
>the Arcnet side, and also set the MSS to this value.

RFC1051 is obsolete.  The RFC for the NetWare v3.11 implementation of
IP over Arcnet is RFC1201.  (Those of you that follow the IETF may
notice a descrepancy between this statement and a recent action by the
IESG.  I am working to sort out that little misunderstanding...)

The newer encapsulation described in RFC1201 allows arbitrarily large
packets.  NetWare v3.11, as i'll explain in a second, allows you to
send Arcnet packets as large as 4202 bytes.  I don't know what limits
the DOS TCP/IP stack you are using has.

Anyway, to answer your question, assuming you're using the standard
issue Arcnet driver, TRXNET.LAN, the only way to control the MTU of
the Arcnet Packets is via the settable NetWare console parameters,
Maximum Physical Receive Packet Size.

In your case, it must be set to at least 1514 because your Ethernet
needs packet buffers that large, so 1514 is the smallest MTU you will
be able to use on that Arcnet.  You can, if you want, set the Maximum
Physical Receive Packet Size higher than 1514.  That would cause the
Arcnet driver to send bigger Arcnet packets.

>2) Am I correct in assuming that I should set have a line in my
>Arcnet'ed PCs CONFIG.TEL which says "mtu=508", and one that says
>"maxseg=508"?  If not, what values should I use?

I don't know config.tel, but assuming these parameters are doing what
you think they are, they should be set to agree with your NetWare
server's Maximum Physical Receive Packet Size.

>4) It appears to me that CUTCPs package does not know how to cope
>with fragments.  This strikes me as a Bad Thing(TM).  Am I in left
>field on this?

It would be a Bad-But-Expedient Thing, but there's no evidence that
IP level fragmentation is playing any role in your problem.  The PC's
TCP/IP's ability to deal with IP fragments is immaterial if the problem
is, in fact, a mismatch of MTUs.  Even a fragmented IP packet will tend
to be transmitted in MTU sized chunks.  If the transmitting Arcnet
node's idea of the MTU is bigger than the receiving Arcnet node can
handle, fragments won't arrive any better then whole packets would.

>BTW:  I did not attribute the quoted material, since it was sent to me in
>private e-mail.  I do not mean to somehow cloak the identities of those who
>contacted me for any reason other than to maintain their privacy.

Thanks, since i certainly do like to keep a low profile. ;-)

						don provan
						donp@novell.com

-----------[000466][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 00:43:56 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <rturner.740935451@imagen>, rturner@imagen.com (Randy Turner) writes:
> ...
> 	                   ....  So for our larger departmental type
> 	printers with high-end throughput (32 ppm+), we are required to
> 	spool incoming data to local disk(s) with some files in the 10's
> 	of megabytes in size.  These customers choose to let the printer
> 	spool the jobs rather than the host computer.  So our throughput
> 	requirements are based more on disk-to-disk transfers rather than
> 	disk-to-print-engine tranfers. 

Disk-to-disk over ethernet or something faster?

One would hope that any file transfer protocol at or below ethernet
speeds would be entirely limited by the speed of the medium.  The
cycles needed for the TCP/IP checksum should be insignificant today.

Depending on various things, an ethernet runs TCP/IP between
~850KByte/sec and ~1150KByte/sec.  That's a sizable variation,
and is in principle controllable.


Vernon Schryver,  vjs@sgi.com

-----------[000467][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 00:56:14 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?

pjb@rudi.23kgroup.com (Paul J. Bell) writes:

> each ip address should have it's own, unique hostname. also, be sure to 
> modify rc and/or rc.local to ifconfig both addresses.

Could you expand on this a little?  The one-name-per-host advocates have
posted believable explanations for their viewpoint; one-name-per-interface
fans seem to be posting bald statements with no explanation.

One-name-per-host works fine here.  I can see why "sortlist" might be
needed in some /etc/named.boot files, to prevent X.25 interfaces from being
favored over FDDI interfaces, but that works.  (In fact, I use sortlist all
over the place, listing networks from fastest to slowest.)

-- 
Tom Fitzgerald   Wang Labs       fitz@wang.com   "I went to the universe today;
1-508-967-5278   Lowell MA, USA                   It was closed...."

-----------[000468][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 03:28:27 GMT
From:      tim@sporran.uucp (Tim Fry)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   Re: TLI

In article <1993Jun21.192607.14647@lmpsbbs.comm.mot.com> gulik@rtsg.mot.com (Gregory Gulik) writes:
>
>Are there any TLI experts out there?
>
>I have a couple questions about it.
>
>2.  Is there a way, using TLI, to do the equivalent of a select
>    on more than 1 file descriptor?  My specific application will
>    be watching a serial port and a socket.  I looked in the Stevens
>    book and couldn't find what I need.

Since the TLI is layered on top of streams, you can use poll(2) to check for 
events on multiple file descriptors. Check the man page. I believe there
is an example in the standard AT&T TLI programmers guide.

Tim


-- 
Tim Fry      tim@sporran.uucp

-----------[000469][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 93 03:50:19 GMT
From:      mischler@cubic.com (Dave Mischler)
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   Gateway between TCP/IP and LU 6.2?

Somebody in my company has about 160 OS/2 boxes that run LU 6.2 over
low speed multi-point SDLC lines.  He now wants these machines to talk
to an HP box, and he says the HP box should run TCP/IP to a gateway
box, and the gateway box should convert between TCP/IP and LU 6.2.
Ideally, he wants the gateway to speak TCP/IP over ethernet, and LU
6.2 over SDLC directly on 10-20 low-speed multi-point lines.

Anybody know of a good solution?

Please reply by mail.

Dave Mischler
mischler@cubic.com

-----------[000470][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 93 04:06:07 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>Depending on various things, an ethernet runs TCP/IP between
>~850KByte/sec and ~1150KByte/sec.  That's a sizable variation,
>and is in principle controllable.

	I'm assuming that the 850K to 1150KByte/sec numbers you
	mention are the theoretical maximums based on media speed
	and protocol overhead-vs-max-data per pkt...(?)

	And I have heard of some TCP/IP implementations approaching
	these figures when benchmarked on an end-to-end basis.  However
	usually the case with TCP/IP throughput (in my experience) has
	been the protocol and application processing at either end of
	the medium.  Unfortunately in my case I do not have what most 
	would term "a bitchin' processor" by todays standards.  Our
	current implementation uses a 16mhz 68020, and it also has to
	handle up to 3 other protocol stacks simultaneously over the 
	same medium, and not a whale of alot of RAM to use for buffering
	either (i.e. large window sizes.., etc).

	We are maintaining adequate data rates however across each of the
	protocol stacks to keep most of our print engines busy.  However,
	there are print engines coming down the pipe that will definitely
	be able to process data at 100Kbytes/sec in the future (as our
	friends at Xerox will tell you, they already exist...).  These
	printers will possess 32ppm+ (and I do mean +) which is why I am
	trying to look ahead at ways we can maximize our data rates 
	through our current 68020-based implementation without requiring
	a new hardware design.

	Randy


-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000471][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 04:38:27 GMT
From:      andy@research.canon.oz.au (Andy Newman)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
>
>However, it does come to mind that printer output data (as opposed to
>e.g.  downloading software or fonts) has a particularly transient
>characteristic - a printer is a write-only device, so if you get a
>data error it only affects that single printout. It's not like a
>source file getting transfered with FTP, where an error can result in
>unrecoverable bit-rot for the rest of time.

To quote yourself "I wouldn't rush to judgement so quickly". Printers
are no longer simple output-only things. A printer these days is a network
service that offers PDL interpretation. Usually, but not always, the PDL
program has a side-effect of spitting a page out of the engine.

-- 
Andy Newman (andy@research.canon.oz.au)

-----------[000472][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 93 10:58:53
From:      bataller@dogie.macc.wisc.edu (Erik Bataller)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip,comp.unix.admin
Subject:   dynamic bootp

Hello Y'all,
	I am interested in dynamically assigning IP numbers from my sun
workstation, I have looked at the packages: bootp.2.1, bootp.2.2alpha
which were in the end from Wimer and Perkins at Carnegie Mellon.  They
are either undocumented or unsupported.  Mainly I would like to give
the block of IP's and the block of ethernet addresses and have it allocate
the next free one.  KA9Q on the pc does this.  Any help would be greatly
appreciated.  We currently have about 1500 pc's and are a class B net and
would like to paln for the future.


Thanks in advance.  If you could reply directly that would be easier and
I will post a summary ASAP.

Thanks again.

Erik

 
--
!!  Erik M. Bataller | Phone: (414) 242-0347 | Univ. of Wi., Osh Kosh 
!!  Academic Computing Services | 800 Algoma Blvd., 307 Dempsey, 
!!  Osh Kosh, Wi. 54901-8602 | Internet: Bataller@sol.acs.uwosh.edu 
!!  Bitnet: Bataller@oshkoshw.bitnet


-----------[000473][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 06:18:52 GMT
From:      mathias@solomon.technet.sg (Mathias Koerber)
To:        comp.protocols.tcp-ip
Subject:   Firewall FAQ?

My local organization might (or might now, who knows) connect to Internet
in the near or distant future. (How's that for a certain statement? :-))

Should that happen, I'd like to put a PC-Type machine (Linux?) to handle
routing and act as a firewall. Is there such a thing as a firewall FAQ,
that serves as introsdction to what a firewall can do, should do and
how to best configure that stuff? I'm sure many people have done these
things before, so the knowledge must be out there somewhere.

I'm basically thinking along these lines:
	-Incoming connections either only go up to the firewall 
	 and NOT FURTHER.
	 (conservative, could be easily done by the routing algorithm)
	 or: incoming connections are tested for IP-address, and certain
	 machines out there are allowed to connect up to certain machines
	 on the internal net. This would be harder to configure and
	 monitor.
	-Outgoing connections are allowed from any host, the router would
	 have to monitor that a connection goes out, and then conditionally
	 allow the return packets in, until such time as traffic died for
	 a certain time, when the connection is considered "closed", and
	 more incoming packets from the same host/port for the same host/port
	 will not be allowed to past. Is this possible? If so, which routing
	 software will I need?
	-E-mail should either sit on the firewall for the local people to
	 collect from there, or be conditionally forwarded (ie our 
	 mail-addresses would be on the firewall, and another program
	 would do the forwarding according to some checks).

	Do these considerations make sense?

	What software would I need to set up such a thing on a PC running
	Linux or some other Unix?

Any help appreciated

Mathias

PS: could the same firewall act as a bridge between two local LAN-segments
	(same address, only want to separate traffic) while acting as router
	to the outside world?
--
Mathias Koerber	                    | Tel: +65 / 7780066 ext 29
SW International Systems Pte Ltd    | Fax: +65 / 7779401
14 Science Park Drive #04-01        |
The Maxwell, Singapore Science Park | email: mathias@solomon.technet.sg
Singapore 0511                      |        swispl@solomon.technet.sg
-------------------------------------------------------------------------------
* Eifersucht ist eine Leidenschaft, die mit Eifer sucht, was Leiden schafft *

-----------[000474][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 07:27:02 GMT
From:      csgoh@ncb.gov.sg (Goh Cheng-Seng)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.dcom.lans.token-ring,comp.dcom.lans.ethernet
Subject:   Re: any "middleware" API products

fkittred@spchp13.BBN.COM (Fletcher Kittredge) writes:

>In article <20723rINNq15@ope001.iao.ford.com> mjo@iao.ford.com (Mike O'Connor) writes:
 
>The WinSock API is designed to be such an API.  WinSock is in version
>1.1.  Many vendors are shipping support for WinSock, including all of
>the major TCP-IP vendors.  For example, Windows NT will come with
>winsock support for:
 
>TCP/IP
>Novell (IPX)
>Appletalk
 
>Further, other vendors have committed to support for:
 
>OSI
>DECnet
 
>in the near future.  If you are interested in learning more, you can
>subscribe to the winsock mailing list via:

Hi,

How does WinSock differ from the standard Sockets available in SunOS? 
Since it is an API, am I right to say that a program using WinSock(TCP/IP) 
on a PC can communicate with another program using the TCP/IP sockets on 
a Sun?

What happen if I have machines of different platform (eg. DEC VAX, Sun Sparc,
PC, Mac, etc), running different protocols (eg. DECNET/LAT, TCP/IP, NetBIOS,
AppleTalk, etc)? Is there a standard API (or "MiddleWare") across all these 
platform that shield the programmer from the underlying transport protocols 
and yet allow the application programs to communicate with one another?

BTW, can any one define "MiddleWare"? I think it has been used to refer
to different things in different occasions. I am confused!

Thanks for your attention.
Good Day!

-----------[000475][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 1993 07:37:34 GMT
From:      elefante@flash.ATC.Olivetti.Com (GUEST Massimo Barontini)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <rturner.740937901@imagen>, rturner@imagen.com (Randy Turner) writes:
> 
> 	Since bypassing checksums is out, someone mentioned in an earlier
> 	discussion that there was a tech.paper or RFC that contains the
> 	latest draft proposals for TCP/IP performance enhancements. Does 
> 	 anyone know which document this was?
> 
> 	Thanks!
> 		Randy 
> -- 
> -----------------------------------------------------------------------------
> Randy Turner
> QMS, Inc.
> rturner@aqm.com

I think the technical paper is  an article from 1993 Winter  USENIX :

"Measurement, Analysis, and Improvement of
UDP/IP Throughput for the DECstation 5000"
                                                                              
J.Kay & J.Pasquale - University of California, San Diego

                                              
                                              
Massimo Barontini
                                                            
maxb@king.ico.olivetti.com
                                                      

-----------[000476][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 1993 09:11:01 GMT
From:      placroix@sun.com (Philippe Lacroix - SunSelect SE)
To:        comp.protocols.tcp-ip
Subject:   Looking for pop2 and pop3 daemons copies for UNIX SCO

I'm looking for pop2 and pop3 daemons copies for UNIX SCO.
Who could send me a copy of them or give me an ftp server address to get them.

Thanks in advance.

_______________________________________________________________________________
 
     /\         Philippe Lacroix
    \\ \        Southern Europe Pre-Sales Engineer
   \ \\ /        
  / \/ / /      SunSelect France
 / /   \//\     BP 62 -
 \//\   / /     13 av. Morane Saulnier
  / / /\ /      78142 Velizy Cedex
   / \\ \          
    \ \\        Telephone: (1) 30.67.50.85
     \/         Fax:       (1) 30.67.54.73
                E-Mail:    placroix@France.Sun.COM
_______________________________________________________________________________




-----------[000477][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 93 14:34:50 CDT
From:      dana@taurus.cray.com (Dana J. Dawson)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?


In article <C95Jxq.8Go@wang.com>, fitz@wang.com (Tom Fitzgerald) writes:
> pjb@rudi.23kgroup.com (Paul J. Bell) writes:
> 
> > each ip address should have it's own, unique hostname. also, be sure to 
> > modify rc and/or rc.local to ifconfig both addresses.
> 
> Could you expand on this a little?  The one-name-per-host advocates have
> posted believable explanations for their viewpoint; one-name-per-interface
> fans seem to be posting bald statements with no explanation.
> 
> One-name-per-host works fine here.  I can see why "sortlist" might be
> needed in some /etc/named.boot files, to prevent X.25 interfaces from being
> favored over FDDI interfaces, but that works.  (In fact, I use sortlist all
> over the place, listing networks from fastest to slowest.)
> 
> -- 
> Tom Fitzgerald   Wang Labs       fitz@wang.com   "I went to the universe today;
> 1-508-967-5278   Lowell MA, USA                   It was closed...."

We've tried both approaches over the years, and we've settled on using one
unique name for each separate IP address.  The argument of using addresses
rather than names for the cases when you want to specify a particular interface
sounds nice, but in practice it is not feasible, especially if your networks
change much (ours do).  We have many systems that don't run routing daemons
and that must install static default routes.  In this case, you need to
specify a local (i.e. directly attached) gateway address.  Using a single
name for all addresses does not guarantee that this will be the case (not all
our systems are "DNS smart", and not all our DNS servers run the same version
of bind, so "sortlist" is not a dependable feature).  Also, the argument that
applications should all accept and process multiple addresses returned for a
given hostname is a nice theory, but this is also not yet a universally supported
feature.  While we don't find our current scheme to be ideal, it at least allows
us to give absolutely clear and correct answers to users who have questions
about where they should point routes, etc.  We consider it to be the less
confusing and vague of the two options, and only slightly less convenient.

Dana J. Dawson
Sr. Network Analyst
Cray Research, Inc.
dana@cray.com

-----------[000478][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 93 14:53:39 CDT
From:      olsondavidsc@bvc.edu
To:        comp.protocols.tcp-ip
Subject:   Windows for Workgroup & PC/TCP problems

Need Help:

	I am having trouble getting FTP PC/TCP and Windows for Workgroups 
to work together.  I first loaded Windows for Workgroups, and it works 
beautifuly by itself.  Then, I loaded PC/TCP on the PC.  I have all of the 
files for PC/TCP:  Hosts, Services, and have modified The Autoexec.bat, and 
Config.sys files by adding the needed lines.  After completing all of this 
everything works just fine from DOS.  I can ping, and telnet.  Then I load 
Windows for Workgroups.  At first I can ping and telnet with no problem.    
Then eventualy I will not be able to ping, telnet, or access any of the WFW 
virtual services, I won't be able to access anything past my PC.  Another 
strange thing that happens is if I boot the maching and go directly into 
WFW, and then try to ping I imediatly loose everything, and possibly lock 
up the machine.  I don't know but it appears that if the gateway address is 
not in the ARP table at the time I enter WFW I will not be able to ping or 
telnet out.
	Has anyone else experienced these or similar problems, and what did 
yo do to solve them?
	The main goal of what I am trying to do is to use WFW on the PC's, 
then use PC/TCP to allow me to log onto a SQLServer through Q+E(a database 
editor) to allow me to do queries and other database operations.  
	If anyone has done this or anything similar to this with success 
please let me know.  I know this is feasible, but am having some trouble 
with the technical support at FTP.  Any help would be greatly appreciated.

Thanks in advance,
Scott Olson

-- 
*****************************************************************************
Scott Olson 
E-Mail:  olsondavidsc@bvc.edu
*****************************************************************************

-----------[000479][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 10:39:42 GMT
From:      kleiner@uci.agh.edu.pl (Adam Kleiner)
To:        comp.protocols.tcp-ip
Subject:   How to get archives?

Where can I find archives of this news group?
(Perhaps this is a question of FAQ, but is there a strandard place
to find FAQs?).

Adam Kleiner

kleiner@ii.uj.edu.pl 

-----------[000480][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 11:24:25 GMT
From:      Robert.Turner@brunel.ac.uk (Robert Turner)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.dcom.lans.token-ring,comp.dcom.lans.ethernet
Subject:   Re: any "middleware" API products

csgoh@ncb.gov.sg (Goh Cheng-Seng) writes:
% How does WinSock differ from the standard Sockets available in SunOS? 
% Since it is an API, am I right to say that a program using WinSock(TCP/IP) 
% on a PC can communicate with another program using the TCP/IP sockets on 
% a Sun?

I'll bite. WinSock sits on top of 'normal' sockets. It's a DLL, run-time
library, that means that you can write code which is network independent
on a PC, and the network vendor will (perhaps) supply a DLL so sit
between your app and his own code for sockets.

That's about it. It's a addition to 'normal' sockets, not a replacement.

Robert

-- 
 _________________________________________________________________________
/                            |                                            \
|   Rob Turner, PC Support   |     email : Robert.Turner@brunel.ac.uk     |
|   Brunel University        |                                            |
|   London, England          |   Goldfish shoals nibbling at your toes    |
\____________________________|____________________________________________/

-----------[000481][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 93 12:59:40 GMT
From:      devdjn@space.alcbel.be (Dennis Newport)
To:        comp.protocols.tcp-ip
Subject:   ARP cache timeout


There is a timeout on the ARP cache that contains the INET/ENET address
mappings. This is obviously required but does anyone know where it is
defined, how it is defined or how to modify the timeout period. 

We are using a SPARC II with SunOS 4.1.2.

The RFC says that it is outside the scope of the spec.

All info gratefully received.

---
Dennis Newport,                  email: devdjn@space.alcbel.be
Alcatel Bell Telephone,
Berkenrodelei 33,                phone: (+32) 3/829.5488
2660 Hoboken,
Belgium.


-----------[000482][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 13:16:32 GMT
From:      heimlich@watson.ibm.com (Steve Heimlich)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <rturner.740981167@imagen> rturner@imagen.com (Randy Turner) writes:
>vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>
>>Depending on various things, an ethernet runs TCP/IP between
>>~850KByte/sec and ~1150KByte/sec.  That's a sizable variation,
>>and is in principle controllable.
>
>	I'm assuming that the 850K to 1150KByte/sec numbers you
>	mention are the theoretical maximums based on media speed
>	and protocol overhead-vs-max-data per pkt...(?)

Nope, this is measured.  Here are the results for an ftp over
a busy ethernet.  I get this speed all the time, more at night
when the ether is less busy.  I get about 800KB/sec through a 
router and 2 busy ethernets.

Steve

# ftp kingbee
Connected to kingbee.watson.ibm.com.
220 kingbee.watson.ibm.com FTP server (Version 4.1 Sat Nov 23 12:52:09 CST 1991)
 ready.
Name (kingbee:root): heimlich
331 Password required for heimlich.
Password:
230 User heimlich logged in.
ftp> bin
200 Type set to I.
ftp> append
(local-file) /unix
(remote-file) /dev/null
200 PORT command successful.
150 Opening data connection for /dev/null.
226 Transfer complete.
1498122 bytes sent in 1.574 seconds (929.5 Kbytes/s)


-----------[000483][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 13:39:09 GMT
From:      de5@ORNL.GOV (Dave Sill)
To:        comp.protocols.tcp-ip,comp.sys.sgi.admin
Subject:   HELP: bizarre FTP problem

Two SGI systems in the same building here are exhibiting the most bizarre
networking problems I've seen in my life.  Both machines are able to
communicate with, as far as I can tell, the rest of the systems here...they
only have trouble talking to each other.

Before you say "oh, routing problem" or "oh, network configuration problem",
hear me out.

Although X and NFS between the two are unusable, I've concentrated my testing
on FTP.  My first test was to try to transfer a large file (the bash binary)
between the two.  The first few kbytes were very slowly transferred, but it
eventually timed-out.

Next I tried a small text file (.profile), and it worked fine.

Assuming the problem was related to the size of the files being transferred, I
created a 1 kbyte file consisting entirely of "x" characters--no newlines at
all.  I repetitively transferred and doubled the file all they way up to 1
megabyte, and they transferred successfully, although slower than they should
have (12 KB/s).

At this point I had two files approximately the same size: one transferred
slowly, the other couldn't be transferred at all.  Not believing that the
contents of a file could affect its transferrabilty by FTP, I tried renaming
the files--no change.

The only other thing I could think to do was trim the "bad" file down to see if
size was a factor.  At about 4k it started transferring reliably, though
transfer times vary widly from 1.44 seconds to 478 seconds.  My 4k test file
takes from 0.07 seconds to 0.16 seconds.

If anybody can shed any light at all on this problem, I'd really appreciate it!

Both systems are running IRIX 4.0.5 with pretty generic configurations, and I'm
not a networking hardware person, but if you need more details or would like a
copy of my 4k "bad" file, just ask.

I also had our network services people monitor some of these transfers, and all
they could say was that the system retrieving the file wasn't acknowledging
some of the packets sent to it.

I've called SGI, but they haven't called me back yet.

-- 
Dave Sill (de5@ornl.gov)                 Computers should work the way beginners
Martin Marietta Energy Systems           expect them to, and one day they will.
Workstation Support                                                -- Ted Nelson

-----------[000484][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 13:47:27 GMT
From:      pirey@relay.nswc.navy.mil (Phil Irey 703.663.1582)
To:        comp.protocols.tcp,comp.protocols.misc,comp.protocols.nfs
Subject:   NFS Specification


 Does anyone know where to get a copy of the current specification of NFS?
 I know that RFC-1094 provides such a specification, but it is my understanding
 that this has been obsoleted by current implementations.
 
 thanks,
             phil

-----------[000485][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 1993 13:52:51 GMT
From:      mjr@tis.com (Marcus J Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall FAQ?

>Should that happen, I'd like to put a PC-Type machine (Linux?) to handle
>routing and act as a firewall. Is there such a thing as a firewall FAQ,
>that serves as introsdction to what a firewall can do, should do and
>how to best configure that stuff? I'm sure many people have done these
>things before, so the knowledge must be out there somewhere.

	Most of that knowledge is on the firewalls mailing list
and archives. Take a look on ftp.greatcircle.com or send mail to
majordomo@greatcircle.com saying "subscribe firewalls"

mjr.

-----------[000486][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 93 21:29:35 PDT
From:      doc@crash.cts.com (Mitch Evans)
To:        comp.protocols.tcp-ip
Subject:   PPP Help Needed


Howdy!

   I am attempting to run PPP on a Sun Sparcstation 1+ ... I am using 
dp-2.3 (demand PPP).  I have compiled all the stuff into the kernel,
and the rest of the support files.  My problem now seems to be with
my login script.  There was MINIMAL documentation on the login script
landuage included in the distribution.  Any help getting the link to
work would be greatly appreciated.  The expect sequence never seems to
pick up the "ogin:"  Thanks in advance for your help!

		Mitch

--
|             doc@crash.cts.com  

-----------[000487][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 15:03:22 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <rturner.740981167@imagen>, rturner@imagen.com (Randy Turner) writes:
> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> 
> >Depending on various things, an ethernet runs TCP/IP between
> >~850KByte/sec and ~1150KByte/sec.  That's a sizable variation,
> >and is in principle controllable.
> 
> 	I'm assuming that the 850K to 1150KByte/sec numbers you
> 	mention are the theoretical maximums based on media speed
> 	and protocol overhead-vs-max-data per pkt...(?)

Not theoretical, but measured with `ttcp` on workstations I'm paid
to care about.  (ttcp.c is available on sgi.com)

The variation is a function of collision rates, and involves what some
consider a bug in the Ethernet protocol.  Under saturation, one station
or the other tends to suffer more collisions, and to back-off into the
weeds, instead of resetting its backoff counter as soon as it notices
some other station won the medium.


> 	And I have heard of some TCP/IP implementations approaching
> 	these figures when benchmarked on an end-to-end basis.  However
> 	usually the case with TCP/IP throughput (in my experience) has
> 	been the protocol and application processing at either end of
> 	the medium.  Unfortunately in my case I do not have what most 
> 	would term "a bitchin' processor" by todays standards.  Our
> 	current implementation uses a 16mhz 68020, and it also has to
> 	handle up to 3 other protocol stacks simultaneously over the 
> 	same medium, and not a whale of alot of RAM to use for buffering
> 	either (i.e. large window sizes.., etc).

A 16MHz 68020 running UNIX should be able to do at least 400KByte/sec
through TCP/IP over ethernet even if you must talk to a slow VME board
with the ethernet hardware, and must copy bytes from mbufs to or from
user space.  (How I know that?  Hint: look at the insides of an old
Silicon Graphics IRIS 2000 or 3000.)  A dedicate 16MHz 68020 system
without those handicaps should be able to run at Ethernet medium
speeds.

Van Jacobson reported making 68000 based Sun's saturate ethernets
as measured in 1988 or 1989.

As has often been reported, a TCP/IP-packet requires less than 400
instructions to handle, exclusive of checksumming and byte copying,
assuming a reasonable C compiler, and reasonable care in UNIX style
protocol code.

You need only about 800 packets/sec to saturate an ethernet (~600 1500
Byte data packets, and 200-300 ACKs).  800*400 instructions/sec at
16Mhz is less than 10%.

A printer controller should not have to copy the bytes.  A system with
a 68020 is not likely to have the cache problems that are the real
bottleneck in modern systems.  (Checksumming is a complete, utter
irrelevance if you are forced to byte-copy and take 100-cycle cache
misses.  Think what 150MHz superscaler CPU's suffer with typical DRAM
access times.)


> 	We are maintaining adequate data rates however across each of the
> 	protocol stacks to keep most of our print engines busy.  However,
> 	there are print engines coming down the pipe that will definitely
> 	be able to process data at 100Kbytes/sec in the future (as our
> 	friends at Xerox will tell you, they already exist...).  These
> 	printers will possess 32ppm+ (and I do mean +) which is why I am
> 	trying to look ahead at ways we can maximize our data rates 
> 	through our current 68020-based implementation without requiring
> 	a new hardware design.

At least 3 workstation vendors are shipping systems that do than
80Mbit/sec or 10,000 Byte/sec over TCP/IP/FDDI.  100KB/s is slooooow.


Vernon Schryver,  vjs@sgi.com

-----------[000488][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 15:05:55 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <20e9vu$80l@olivea.ATC.Olivetti.Com>, elefante@flash.ATC.Olivetti.Com (GUEST Massimo Barontini) writes:
> 
> I think the technical paper is  an article from 1993 Winter  USENIX :
> 
> "Measurement, Analysis, and Improvement of
> UDP/IP Throughput for the DECstation 5000"
>                                                                               
> J.Kay & J.Pasquale - University of California, San Diego


There have been many papers about TCP/IP performance over the years.
It would be smart to also look for "Van Jacobson" in bibliographies.


Vernon Schryver,  vjs@sgi.com

-----------[000489][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 15:30:06 GMT
From:      gulik@rtsg.mot.com (Gregory Gulik)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   Re: TLI

In article <1993Jun25.032827.8335@sporran.uucp> tim@sporran.uucp (Tim Fry) writes:
>
>Since the TLI is layered on top of streams, you can use poll(2) to check for 
>events on multiple file descriptors. Check the man page. I believe there
>is an example in the standard AT&T TLI programmers guide.

poll() only works on streams devices.
I need to be able to watch for input on a serial port.

-greg

-- 

gulik@rtsg.mot.com  (Gregory Gulik)  [NeXT]

-----------[000490][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 15:33:41 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <C96I7p.8zq@yktnews.watson.ibm.com>, heimlich@watson.ibm.com (Steve Heimlich) writes:
> In article <rturner.740981167@imagen> rturner@imagen.com (Randy Turner) writes:
> >vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> >
> >>Depending on various things, an ethernet runs TCP/IP between
> >>~850KByte/sec and ~1150KByte/sec.  That's a sizable variation,
> >>and is in principle controllable.
> >
> >	I'm assuming that the 850K to 1150KByte/sec numbers you
> >	mention are the theoretical maximums based on media speed
> >	and protocol overhead-vs-max-data per pkt...(?)
> 
> Nope, this is measured.  Here are the results for an ftp over
> a busy ethernet.  I get this speed all the time, more at night
> when the ether is less busy.  I get about 800KB/sec through a 
> router and 2 busy ethernets.
> 
> Steve
> 
> # ftp kingbee
> Connected to kingbee.watson.ibm.com.
> 220 kingbee.watson.ibm.com FTP server (Version 4.1 Sat Nov 23 12:52:09 CST 1991)
>  ready.
> Name (kingbee:root): heimlich
> 331 Password required for heimlich.
> Password:
> 230 User heimlich logged in.
> ftp> bin
> 200 Type set to I.
> ftp> append
> (local-file) /unix
> (remote-file) /dev/null
> 200 PORT command successful.
> 150 Opening data connection for /dev/null.
> 226 Transfer complete.
> 1498122 bytes sent in 1.574 seconds (929.5 Kbytes/s)



Caveats:

FTP tends to measure performance of the file systems at the source and the
destination more than the performance network hardware or software.

A benchmark of less than 10 or 20 seconds is often misleading because
of start up and shut down transients.  I bet in this particular case
the bytes were still going over the wire when FTP decided things were
finished and computed its number.


Vernon Schryver,  vjs@sgi.com

-----------[000491][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 1993 15:41:06 GMT
From:      holland@godiva.ne.ksu.edu (Rich Holland)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

tar@sam.ksu.ksu.edu (Tim Ramsey) writes:

>matt% netstat -s
>ip:
>        0 bad header checksums
>icmp:
>        0 bad checksums
>tcp:
>       21036149 packets received
>               144 discarded for bad checksums
>udp:
>       0 bad checksums
 
>This is on a Solbourne running 4.1A.3 (akin to 4.1.1).  The running kernel
>apparently has UDP checksums disabled. :(


godiva% netstat -s
ip:
        10452170 total packets received
        0 bad header checksums
icmp:
        0 bad checksums
tcp:
        10062681 packets received
                0 discarded for bad checksums
udp:
        0 bad checksums

This is on an IBM RS/6000 320h running AIX 3.2.3.  The running kernel
aparantly has UDP cheksums enabled.  :-)

--
Rich Holland  (holland@godiva.ne.ksu.edu)
723 Allison Ave, #8, Manhattan, KS  66502
(913) 776-5789

-----------[000492][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 15:59:24 GMT
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: ARP cache timeout

devdjn@space.alcbel.be (Dennis Newport) writes:
> There is a timeout on the ARP cache that contains the INET/ENET address
> mappings. This is obviously required but does anyone know where it is
> defined, how it is defined or how to modify the timeout period. 
> 
> We are using a SPARC II with SunOS 4.1.2.
> 
> The RFC says that it is outside the scope of the spec.

Actually RFC 1122 says quite a bit about the ARP cache, see section 2.3.2.1,
'ARP Cache Validation'. Among other things, it says:

            An implementation of the Address Resolution Protocol (ARP)
            [LINK:2] MUST provide a mechanism to flush out-of-date cache
            entries.  If this mechanism involves a timeout, it SHOULD be
            possible to configure the timeout value.

As far as I remember, SunOS 4.1.x does *not* timeout ARP cache entries, but
they *do* provide 'arp -d' to delete entries explicitly. I do wish they had
a timeout mechanism, though...

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000493][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 16:20:17 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

>rturner@imagen.com (Randy Turner) writes
>
>       And I have heard of some TCP/IP implementations approaching
>       these figures when benchmarked on an end-to-end basis.  However
>       usually the case with TCP/IP throughput (in my experience) has
>       been the protocol and application processing at either end of
>       the medium.
 
I'm sorry, but this particular comment gets my goat.  Taken to its essentials
it says "my experience with j-random implementation of protocol Y allows
me to make general comments about the possible performance of protocol Y."
The networking field has been plagued with these sorts of incautious
evaluations of protocols.  Trying another tack, it is sort of like
someone saying "my experience with the PDP-10 entitles me to be an
expert in computer and processor design."  Certainly working with the PDP-10
will teach someone a lot, but it doesn't make them an expert on all things.
 
>       Unfortunately in my case I do not have what most 
>       would term "a bitchin' processor" by todays standards.  Our
>       current implementation uses a 16mhz 68020, and it also has to
>       handle up to 3 other protocol stacks simultaneously over the
>       same medium, and not a whale of alot of RAM to use for buffering
>       either (i.e. large window sizes.., etc).
 
The first TCP/IP that was benchmarked at full Ethernet speeds ran on a similar
platform -- a SUN 2 workstation using a Lance chipset in 1988.  Observe that
the number of protocol stacks you handle should have almost no impact on
performance (if it does, you've done something wrong).  Since then, protocol
implementations have improved further, so that 1990 vintage workstations
(e.g., HP Snake) have been benchmarked doing TCP/IP at 100+ Mb/s (e.g.,
about 13 Mbyte/s).

The point here is that the best TCP/IP implementations currently available
can easily achieve the performance you're looking for, on your processor.

Craig

-----------[000494][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 93 18:44:32 GMT
From:      srounsle@sdcc3.ucsd.edu (S R)
To:        comp.protocols.tcp-ip
Subject:   SLIP beginner

I have a very basic question for anyone who is knowledgable about
such matters.  I have a PC clone at home with a 14.4K modem.  I also
have access to an ethernet dial-in line which supports SLIP
connections.  I would like to set up a gopher client on my home
machine, so that I can work from home more easily.  My question is
what do I need?  I can find no basic FAQ-like info for such
software, so I decided to post to this group.
	I have seen various telnet like programs, popmail etc.  I
can't find out much info about the SLIP drivers themselves.  How
does one set about making a connection?  Do you need other
communication software to make the connection?  I just need some
basic info regarding how to get started with this stuff..
	thanks is advance,
		Steve


-----------[000495][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 19:07:54 GMT
From:      hughes@logos.ucs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: search for POP3 daemon for HP-UX

In article <a2824ab.740933894@sunmanager>, a2824ab@sunmanager.LRZ-Muenchen.DE (Werner Spirk) writes:
|> I am searching for a POP3D version ( version of University
|> of California at Davis ) for HP-UX.
|> In general I am searching for routines or a description 
|> for changing flock to lockf routines inclusive parameters.

I did this once a while ago, with the Berkeley popper.  I think what 
you want is this one line, to replace the flock():

   lockf(fd, F_LOCK, 0);

assuming the file pointer is still at the beginning of the file.

 //==================================================================\\
||      Larry J. Hughes, Jr.       |        hughes@indiana.edu        || 
||       Indiana University        | "The person who knows everything ||
||  University Computing Services  |        has a lot to learn."      ||
 \\===================================================================//

-----------[000496][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 93 20:41:20 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

heimlich@watson.ibm.com (Steve Heimlich) writes:


>Nope, this is measured.  Here are the results for an ftp over
>a busy ethernet.  I get this speed all the time, more at night
>when the ether is less busy.  I get about 800KB/sec through a 
>router and 2 busy ethernets.
 
>Steve
 
># ftp kingbee
>Connected to kingbee.watson.ibm.com.
>220 kingbee.watson.ibm.com FTP server (Version 4.1 Sat Nov 23 12:52:09 CST 1991)
> ready.
>Name (kingbee:root): heimlich
>331 Password required for heimlich.
>Password:
>230 User heimlich logged in.
>ftp> bin
>200 Type set to I.
>ftp> append
>(local-file) /unix
>(remote-file) /dev/null
>200 PORT command successful.
>150 Opening data connection for /dev/null.
>226 Transfer complete.
>1498122 bytes sent in 1.574 seconds (929.5 Kbytes/s)


/*
	I think the performance numbers for FTP are skewed somewhat and
	don't give an accurate measure of the throughput that a 
	particular TCP/IP implementation is capable of.  Or maybe I
	should say that it cannot be reliably used as a basis for
	comparison.  I say this cause when we send small files from
	Sun IPC to Sun IPC using FTP we get huge throughput numbers
	because of FTP's rounding up to the nearest second for data
	transfer, something on the order of like 2.5Mb/sec. when we
	know for a fact that the sustained throughput of TCP/IP running
	on SunOS 4.1 is something like 260KBytes/sec.

*/
-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000497][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 20:46:14 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   Re: TLI

In article <1993Jun25.153006.20899@lmpsbbs.comm.mot.com>, gulik@rtsg.mot.com (Gregory Gulik) writes: > In article <1993Jun25.032827.8335@sporran.uucp> tim@sporran.uucp (Tim Fry) writes:
> >
> >Since the TLI is layered on top of streams, you can use poll(2) to check for 
> >events on multiple file descriptors. Check the man page. I believe there
> >is an example in the standard AT&T TLI programmers guide.
> 
> poll() only works on streams devices.
> I need to be able to watch for input on a serial port.
> 

	Both of these say things that just aren't true.

	First, whether TLI is on top of STREAMS or not depends entirely on the
implementation, which I don't believe was specified. It has nothing to do with
TLI per se.
	Second, the system V poll() system call works on any type of file
descriptor. But in fact, implementations that use STREAMS at all probably
use it for everything, or at least most things.
	And, third, if you're using Solaris, you can also use select(2). It
may work on other platforms too; worth a try.

-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000498][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 21:26:15 GMT
From:      cmclal@lizzie.arh.cdc.com (A. Sudhakarlal)
To:        comp.protocols.tcp-ip
Subject:   ###### Public Domain TCP/IP source #####

I am looking for Public Domain TCP/IP source(Unix version). Please let me know
the anonymous ftp sites which have this source.

Thanks in advance for your time.

Regards


-----------[000499][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Jun 1993 22:51:35 GMT
From:      dsiegel@Seagull.RTD.COM (Dave Siegel)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?

From article <C8x1Eq.Mu7@bull.nl>, by jos@bull.nl (Jos Vos):
> When a system has more than one interface, each with its own
> IP address, should the /etc/hosts file than contain the same
> hostname for each IP address, or should each IP address has
> its own unique name?

The correct answer is that it really doesn't matter.  If you've got different
names for each IP number, the most that will happen is that on finger, who,
netstat and such, you'll get some wierd hostnames and connection stats.

On the other hand, there is no reason *not* to make the names the same.  I'm
running SLIP as an internet connection to a local network, and for a time,
I had called the slip interface (sl0 in this case) slip.rtd.com, but I have
since changed it to Seagull.rtd.com with ip of 198.102.68.20 which is the same
name as 198.102.68.2 (eth0).

-dave
-- 
Dave Siegel   (DS4)                        |   Network Consulting
President, RTD, Systems & Networking, Inc. |   Custom Software Design
dsiegel@rtd.com (602)318-0696  318-0695fax |   creators of SpectraGraph(tm)

-----------[000500][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 93 23:23:13 GMT
From:      jthill@us.oracle.com (Jim Hill)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum

Huh.  I'm only a part-time UN*X user, and I've been burned by bad disk
interfaces and such delivering trash unannounced on "server"s.  I've
never, never been burned by TCP.  I don't think I'm alone.
 
You're proposing shutting off checksums for speed, but *only* when the
network administrator *knows* that there are no bridges.  Fine.  The
administrator shuts off checksums.  The administrator moves on.  Someone
new comes in and expands the net.  Obscenities ensue.
 
Imagine describing this possibility to a potential customer (minus the
obscenities).  Imagine _not_ describing this possiblity to a potential
customer.
 
I guess if this is only on a printer, and you have a big red flashing sign,
readable from two feet in a well lit room, saying "caution:  this device
becomes less reliable with every network change", it's marginally ok.
Anything less is, IMHO, skirting ethical issues.
 
Jim
--
Jim Hill                              * Protect Your Right to not be offended!
jthill@us.oracle.com                  * Help Stamp Out Life in our time.

-----------[000501][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 93 23:49:46 GMT
From:      switt@pterodactyl.scg.hac.com (Steve Witt)
To:        comp.protocols.tcp-ip
Subject:   BSD Networking Software Availability

I've been working through W. Richard Stevens' book "UNIX Network
Programming".  In this book he mentions that the BSD Networking
Software is available for use (though not PD and copyrighted by 
UC Berkeley) and contains the complete source code to TCP/IP.
I've looked at the usual USENET archive sites (at least usual
for me) and other places and haven't been able to track it down.
Is there some kind soul out there who might be able to shed some
light on how this code may be obtained?

Thanks in advance!!




-----------[000502][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26 Jun 1993 00:14:59 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <rturner.741040880@imagen>, rturner@imagen.com (Randy Turner) writes:
> ...
> 	                                                    when we
> 	know for a fact that the sustained throughput of TCP/IP running
> 	on SunOS 4.1 is something like 260KBytes/sec.


I trust you mean "disk-to-disk file transfers over TCP/IP (probably via
FTP)" only get 260KB/s.  It would boggle my mind to hear that Sun has
reduced their performance by almost a factor of 4.  For that matter,
I'm only slightly less boggled to hear that they only get 260KB/s
through FTP.  Something closer to 1MByte/sec is what I would expect.

Are you sure of that number?  Is there any chance that something was
broken in the network?  Terrible packet loss rates perhaps?  Bad
ethernet terminations?  Late collisions?  Could it have been a file
transfer from one diskless machine to another, so that the data would
go over the wire 4 times?


Vernon Schryver,  vjs@sgi.com

-----------[000503][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 93 05:55:38 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

craig@sics.se (Craig Partridge) writes:

>>rturner@imagen.com (Randy Turner) writes
>>
>>       And I have heard of some TCP/IP implementations approaching
>>       these figures when benchmarked on an end-to-end basis.  However
>>       usually the case with TCP/IP throughput (in my experience) has
>>       been the protocol and application processing at either end of
>>       the medium.
> 
>I'm sorry, but this particular comment gets my goat.  Taken to its essentials
>it says "my experience with j-random implementation of protocol Y allows
>me to make general comments about the possible performance of protocol Y."
>The networking field has been plagued with these sorts of incautious
>evaluations of protocols.  Trying another tack, it is sort of like
>someone saying "my experience with the PDP-10 entitles me to be an
>expert in computer and processor design."  Certainly working with the PDP-10
>will teach someone a lot, but it doesn't make them an expert on all things.

/*
	Sorry for getting your goat, but the first part of your comment
	"my experience with j-random implementation of protocol Y" is
	basically what I was saying.  It's the second part of your comment
	"make general comments about the possible performance of protocol
	Y" that I don't find in my earlier comment.  I was merely expressing
	my opinion, given my experiences with benchmarking and profiling
	two or three TCP/IP implementations, of where I thought some end-to
	end throughput is constrained.  Benchmarks like "ttcp" I would think
	would be less constrained.
> 
>The first TCP/IP that was benchmarked at full Ethernet speeds ran on a similar
>platform -- a SUN 2 workstation using a Lance chipset in 1988.  Observe that
>the number of protocol stacks you handle should have almost no impact on
>performance (if it does, you've done something wrong).  Since then, protocol
>implementations have improved further, so that 1990 vintage workstations
>(e.g., HP Snake) have been benchmarked doing TCP/IP at 100+ Mb/s (e.g.,
>about 13 Mbyte/s).
>
>
Craig

/*
	The number of protocol stacks in our case makes more of a difference
	than usual because we are running in an embedded system with RAM
	constraints.  Since we have to adequately support multiple,
	simulataneous connections over multiple protocols, we have to
	limit the TCP receive window sizes, thus, limiting the pipeline
	capability, and it certain circumstances causing zero-window probes
	to be generated under heavily loaded conditions.  

	Also, I'm assuming that the 13Mbyte/sec number is running over
	something that is not Ethernet, which opens up a whole other can
	of worms for performance enhancements (e.g. Path MTU discovery).   
*/

	Randy
-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000504][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26 Jun 1993 06:31:48 GMT
From:      pledge@netcom.com (Alan McLachlan)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Dialing one network into another...

Ok.... I am trying to find a solution to the following.

I have a small set of MAC's networked and would like to connect
this small network to the Internet with PPP (or maybe slip)
but you can connect MacTCP to *EITHER* PPP or Ethernet....

So is there a way of doing this?

Sorry if this is a FAQ... I haven't found it in the FAQ's yet...

Any help is appreciated...


-- 
                                               | Alan McLachlan
                                               | Consultant/Programmer
                                               | INTERNET: pledge@netcom.com



-----------[000505][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26 Jun 1993 11:59:38 GMT
From:      gandalf@Csli.Stanford.EDU (Juergen Wagner)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <rturner.741040880@imagen> rturner@imagen.com (Randy Turner) writes:
>heimlich@watson.ibm.com (Steve Heimlich) writes:
>
>>Nope, this is measured.  Here are the results for an ftp over
>>a busy ethernet.  I get this speed all the time, more at night
>>when the ether is less busy.  I get about 800KB/sec through a 
>>router and 2 busy ethernets.
>
 ...
>/*
>	I think the performance numbers for FTP are skewed somewhat and
>	don't give an accurate measure of the throughput that a 
>	particular TCP/IP implementation is capable of.  Or maybe I
>	should say that it cannot be reliably used as a basis for
>	comparison.  I say this cause when we send small files from
>	Sun IPC to Sun IPC using FTP we get huge throughput numbers
>	because of FTP's rounding up to the nearest second for data
>	transfer, something on the order of like 2.5Mb/sec. when we
>	know for a fact that the sustained throughput of TCP/IP running
>	on SunOS 4.1 is something like 260KBytes/sec.
>
>*/

It seems to me there are -- at least to some extent -- religuous
issues involved here. I have read quite a number of different figures,
all characterizing TCP throughput on some network in some
configuration. Although I believe to have followed the discussion from
its beginning, I am not sure I remember what exactly was the idea
behind dropping TCP checksums and the thus evolving throughput numbers
discussion. Could you clarify your original objective? Were you
concerned about building printers printing faster than Ethernet
transmission speed? Maybe you need an ATM interface for that printer
then :-) :-)?

Being somewhat interested in those figures myself, I ran a few tests
on our network (a busy backboned network with heavy Decnet/IP/Apple
traffic during normal work time). All connections (with the exception
of those to the same host) were through two learning DEC bridges. I
also ran a test between a SPARC 10/30 and a SPARC 2 over several
bridges and at least four routers (number in kBytes/s measured with
ttcp -t -s/ttcp -r -s, mean over 10 trials, 2048 packets with 8192
bytes each, all machines with SunOS 4.1.3). 

	Receiver: 10/30	IPX	1	self	localhost
Sender:
Sparc 10/30	  780	570	670	2860	3210

Sparc IPX	  587	392	397	1230	1332	

Sparc 1		  779	644	680	950	1010

What you seem to know as a fact (260 KBytes/s max between two SunOS
4.1.3 machines) surprised me, so I tried myself...

I also tried ftp and nfs in comparison with ttcp figures between two
10/30s separated by a single learning bridge (transfer for a 32 MByte
file from one machine to the other):

ttcp	810
nfs	944
ftp	970

To my big surprise, these figures were much better for nfs and ftp
than for ttcp. Anybody can explain this? I don't see where we have
overhead with a simple ttcp connection in comparison with ftp (the
timings were done by "time", including program startup times). NFS
might be faster by using UDP.

--Juergen

J_Wagner@iao.fhg.de
gandalf@csli.stanford.edu

-----------[000506][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26 Jun 1993 13:40:03 GMT
From:      evansmp@uhura.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum

Jim Hill (jthill@us.oracle.com) wrote:
:  
: You're proposing shutting off checksums for speed, but *only* when the
: network administrator *knows* that there are no bridges.  Fine.  The
: administrator shuts off checksums.  The administrator moves on.  Someone
: new comes in and expands the net.  Obscenities ensue.

So you need something like the MTU discovery protocol before you
even think of doing this.

--
-------------------------------------------------------------------------
Mark Evans                                   |evansmp@uhura.aston.ac.uk
+(44) 21 429 9199  (Home)                    |evansmp@cs.aston.ac.uk
+(44) 21 359 6531 x4039 (Office)             |

-----------[000507][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 1993 13:50:56 GMT
From:      roy@mchip00.med.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> I trust you mean "disk-to-disk file transfers over TCP/IP (probably via
> FTP)" only get 260KB/s.

	Vernon points out a good point -- if you are going to run an
experiment to measure something, you have to know what you're measuring.
Clocking FTP transfer times is not a very good way to measure TCP
throughput.  I just tried a little experiment.  I wrote a small client which
opens a TCP connection to port 9 (the discard port) and proceeds to write
some number of 1k blocks of data to it and times how long it takes.  I don't
even generate any real data; I just allocate a "char buf[1024]" and then do:

     for (i = 0; i < count; i++)
	 write (s, buf, 1024);

	I tried it with 3 machines.  The first was a SGI 4D/320-GTX, which
gave about 980 kb/sec (something like 80% of the theoretical ethernet
maximum), the second was a SGI 4D/25 (or maybe it's even a 4D/20?), which
gave 550 kb/sec.  Both of these machines are on the same ethernet segment as
my client, a DECStation 5000/240.  Presumably at this time of day the
ethernet is pretty idle (as are the hosts in question).  The third machine I
tried was a vax (don't remember which model, a 6000-series, I think) running
VMS.  The vax is on an ethernet segment a couple of bridges away from me.
That machine yielded 460 kb/sec.  I ran each test a few times, and the
results were pretty consistant (not quite consistant enough to really
justify 2 significant figures, but close).  The results also scaled well
(i.e. writting 10 times as many packets took 10 times as long; the figures
above were for 10000 packets).

	While all of these machines have a fairly hefty amount of processing
power, they are hardly nothing special compared to commodity hardware that's
available today at affordable prices for the desktop (I'd bet as far as pure
integer MIPS go, the mid-range Macintoshes already beat the poor little
4D/25).  And, as somebody already pointed out, Van Jacobson was saturating
ethernets with Sun-3/50's years ago (essentially the same hardware as what's
in a Mac-IIcx).  Bottom line is, I don't see TCP checksumming as being a
major bottleneck, and certainly not in a printer.
-- 
Roy Smith <roy@nyu.edu>
Hippocrates Project, Department of Microbiology, Coles 202
NYU School of Medicine, 550 First Avenue, New York, NY 10016
"This never happened to Bart Simpson."

-----------[000508][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26 Jun 1993 14:09:52 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <1993Jun26.115938.23221@Csli.Stanford.EDU>, gandalf@Csli.Stanford.EDU (Juergen Wagner) writes:
>                     ....          (number in kBytes/s measured with
> ttcp -t -s/ttcp -r -s, mean over 10 trials, 2048 packets with 8192
> bytes each, all machines with SunOS 4.1.3). 
> ...
 
> 	Receiver: 10/30	IPX	1	self	localhost
> Sender:
> Sparc 10/30	  780	570	670	2860	3210
> Sparc IPX	  587	392	397	1230	1332	
> Sparc 1	  779	644	680	950	1010
> ...

Does "self" mean using the machine's name with the sending ttcp?  While
"localhost" means using "localhost"?  If so, there should be little
difference in BSD style network code, because the ethernet driver
should never be involved.  A BSD style kernel should notice that the
local name is being used and use the "loopback driver", regardless of
whether "localhost" or the machine's name is used.

There is a lot of variation in those numbers.  The ~400KB/s numbers
strike me as strangely low.  `netstat` should be used to see if there
is some problem on the ethernet for those machine.  Look for TCP
retransmissions and "duplicate acks".  (Duplicate acks are often a sign
of retransmissions.)  Collision counts might be illuminating.


> I also tried ftp and nfs in comparison with ttcp figures between two
> 10/30s separated by a single learning bridge (transfer for a 32 MByte
> file from one machine to the other):
> ttcp	810
> nfs	944
> ftp	970
> 
> To my big surprise, these figures were much better for nfs and ftp
> than for ttcp. Anybody can explain this? I don't see where we have
> overhead with a simple ttcp connection in comparison with ftp (the
> timings were done by "time", including program startup times). NFS
> might be faster by using UDP.
> ...

In my experience, on fast media and fast CPU's, UDP is generally slower
than TCP for several reasons that are best explained with kernel profiles.

Three samples of {810,944,970} for 16MByte strike me as about the
"same" value.

Also, numbers above 800KB/s for Ethernet are in the regime of Ethernet
protocol bug I keep talking about.  If you do anything to reduce the
number of collisions, you can increase the result from `ttcp`, up to
1150KB/s on hardware I know about.  Ways to decrease `ttcp` collisions
and increase speed on at least some non-solar workstations include:
    -reduce the TCP window to ~10K.
    -fiddle with the TCP delayed ACK code to reduce the number of ACKs.
    -use a "polite" (a.k.a. "broken") AMD 7990 LANCE ethernet chip.

The 7990 delays starting to transmit after an Ethernet deferral by up
to about 25 microseconds.  If another packet is seen early enough
during that time, the LANCE will simply defer again, not increase its
back-off counter, and not force a collision.  Not increasing its
backoff counter is the important part.


Vernon Schryver,  vjs@sgi.com

-----------[000509][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26 Jun 1993 14:24:34 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum

In article <1993Jun26.134003.12150@aston.ac.uk>, evansmp@uhura.aston.ac.uk (Mark Evans) writes:
> Jim Hill (jthill@us.oracle.com) wrote:
> :  
> : You're proposing shutting off checksums for speed, but *only* when the
> : network administrator *knows* that there are no bridges.  Fine.  The
> : administrator shuts off checksums.  The administrator moves on.  Someone
> : new comes in and expands the net.  Obscenities ensue.
> 
> So you need something like the MTU discovery protocol before you
> even think of doing this.


MTU discovery generally tells you nothing about the prsense of bridges.
Consider 
    -two ethernets bridged together
    -two ethernets bridged over a serial line (any of a number of ways,
	including ISDN)
    -two ethernets bridged to a common "FDDI backbone"

You cannot detect bridges by any extra latency in the path, since some
bridges use cut-through routing, and claim to add only a few
microseconds of latency.


Vernon Schryver,  vjs@sgi.com

-----------[000510][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26 Jun 1993 16:12:24 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <20hk80$okr@calvin.NYU.EDU>, roy@mchip00.med.nyu.edu (Roy Smith) writes:
> ...
>              I just tried a little experiment.  I wrote a small client which
> opens a TCP connection to port 9 (the discard port)...
 
> 	I tried it with 3 machines.  The first was a SGI 4D/320-GTX, ...
 
>                                                    ...  The third machine I
> tried was a vax ...

With ttcp, you can vary user buffer size, TCP window, user buffer
alignment, use UDP instead of TCP, and so on, on both the sender and
the receiver.  Ttcp also tries to compute elapsed time and CPU cycles.
Ttcp ports easily to any machine with sockets or a "socket
compatibility library."

Anyone writing applications needing network speed should pay attention to
those parameters.  The effects of changing the alignment of the buffer,
for example, might be surprising.

Silicon Graphics ships a ttcp binary and the source, ttcp.c.  It is the
same as the "improved" version on sgi.com, not official Naval
Ballistics Research Lab version on brl.mil and also sgi.com.  (I never
remember where ttcp is in the CDROMs.  Find it by mounting a CDROM and
`grep ttcp *.idb`.)  SGI is also shipping Cray's test, named something
like netperf or nettest, perhaps not until IRIX 5.something.


>  ...	While all of these machines have a fairly hefty amount of processing
> power,...

I'd rather implement the TCP checksum on a commodity 25MHz 80486 mother
board, one that runs its DRAMs in burst mode, than on a 12MHz 4D/20, or
even a 20MHz 4D/25.  For that matter, a 25MHz 80486 motherboard can
beat a 33MHz 4D/33 doing the checksum.  Besides the handy carry bit
which allows a 0.25 cycle/byte 1's-complement add instead of 0.5
cycle/byte, burst mode is useful on data not in the cache, which is
rather likely when computing the checksum.

As I keep saying, cache effects are far more important in most modern
hardware than the CPU cycles needed to compute the checksum.


Vernon Schryver,  vjs@sgi.com

-----------[000511][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26 Jun 1993 16:42:51 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

In article <20f6ai$dk7@newserv.ksu.ksu.edu>, holland@godiva.ne.ksu.edu (Rich Holland) writes:
> tar@sam.ksu.ksu.edu (Tim Ramsey) writes:
  [netstat numbers]


Based on the excellent idea of looking at `netstat`, I looked at two
servers (mostly netnews), and found in the two days they've been up,
they had a total of 57 TCP packets with bad checksums, in about
5,000,000 TCP packets.  Three other machines used mostly for UNIX
source serving had a total of 11 TCP packets with bad checksums in
about 60,000,000 TCP packets.  There were fewer UDP checksum errors,
but more than 0.

Each of those bad TCP checksums would have been an undetected error.
No one cares about netnews, but people are paid to care about UNIX source.


With a few more reports about other vendor's hardware, I hope we can
declare the idea of turning off TCP checksums officially dead.


Vernon Schryver,  vjs@sgi.com

-----------[000512][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 93 20:42:18 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>In article <rturner.741040880@imagen>, rturner@imagen.com (Randy Turner) writes:
>> ...
>> 	                                                    when we
>> 	know for a fact that the sustained throughput of TCP/IP running
>> 	on SunOS 4.1 is something like 260KBytes/sec.


>I trust you mean "disk-to-disk file transfers over TCP/IP (probably via
>FTP)" only get 260KB/s.  It would boggle my mind to hear that Sun has
>reduced their performance by almost a factor of 4.  For that matter,
>I'm only slightly less boggled to hear that they only get 260KB/s
>through FTP.  Something closer to 1MByte/sec is what I would expect.
 
>Are you sure of that number?  Is there any chance that something was
>broken in the network?  Terrible packet loss rates perhaps?  Bad
>ethernet terminations?  Late collisions?  Could it have been a file
>transfer from one diskless machine to another, so that the data would
>go over the wire 4 times?


>Vernon Schryver,  vjs@sgi.com

	Sorry, I forgot to mention this is on Sun-3 hardware. 
	We obtained these numbers from an engineer at Sun in order to
	compare our implementation performance against.  And I believe his
	comments were this is a sustained aggregate data rate from one
	host to another from application layer to application layer over an
	Ethernet at 15% utilization. He didn't mention any adverse network
	conditions, but that's not to say there weren't any. His application
	may have been disk-related, I don't know.  However, our implementation
	is disk related, except when printer-local spooling is disabled.

	Randy
 
-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000513][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 93 20:56:23 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)


	I think your numbers are considerably higher than the numbers
	I quoted due to the hardware you are running.  I forgot to
	mention that my numbers were generated on a Sun-3 box which
	is probably an order of magnitude (ok, maybe an exaggeration)
	slower than a Sparc 10.

	Randy

-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000514][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 93 20:59:26 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

roy@mchip00.med.nyu.edu (Roy Smith) writes:

>And, as somebody already pointed out, Van Jacobson was saturating
>ethernets with Sun-3/50's years ago (essentially the same hardware as what's
>in a Mac-IIcx).  Bottom line is, I don't see TCP checksumming as being a
>major bottleneck, and certainly not in a printer.
>-- 
>Roy Smith <roy@nyu.edu>
>Hippocrates Project, Department of Microbiology, Coles 202
>NYU School of Medicine, 550 First Avenue, New York, NY 10016
>"This never happened to Bart Simpson."

	Now wait a minute...I didn't say is was a major bottleneck, just
	another possible performance issue that shows up during TCP/IP
	profiling.....

	Randy

-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000515][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26 Jun 1993 22:14:38 GMT
From:      heimlich@watson.ibm.com (Steve Heimlich)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <rturner.741040880@imagen> rturner@imagen.com (Randy Turner) writes:
>heimlich@watson.ibm.com (Steve Heimlich) writes:
>
>
>>Nope, this is measured.  Here are the results for an ftp over
>>a busy ethernet.  I get this speed all the time, more at night

[...]
>	I think the performance numbers for FTP are skewed somewhat and
>	don't give an accurate measure of the throughput that a 

Sorry for not clarifying that.  You're right.  In this case, however,
the numbers are ok (I have an independent monitor which I watch
during the transfer).  A 66MB transfer from a mapped file gave about
the same results.  ttcp would be a better tool (and a sniffer better yet).

In some private mail, I mentioned that I'd be interested in using
something like Jon Kay's work to negotiate a >stronger< checksum than
TCP currently uses.  

Steve

-----------[000516][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26 Jun 1993 23:15:21 GMT
From:      tim@sporran.uucp (Tim Fry)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   Re: TLI

In article <C97313.8zx@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>In article <1993Jun25.153006.20899@lmpsbbs.comm.mot.com>, gulik@rtsg.mot.com (Gregory Gulik) writes: > In article <1993Jun25.032827.8335@sporran.uucp> tim@sporran.uucp (Tim Fry) writes:
>> >
>> >Since the TLI is layered on top of streams, you can use poll(2) to check for 
>> >events on multiple file descriptors. Check the man page. I believe there
>> >is an example in the standard AT&T TLI programmers guide.
>> 
>> poll() only works on streams devices.
>> I need to be able to watch for input on a serial port.
>> 
>	Both of these say things that just aren't true.
>
>	First, whether TLI is on top of STREAMS or not depends entirely on the
>implementation, which I don't believe was specified. It has nothing to do with
>TLI per se.

I concur that the TLI may not be implemented on top of STREAMS, but I have to
say that I've yet to see an implementation where it wasn't.

>	Second, the system V poll() system call works on any type of file
>descriptor. 

Where is it documented that poll() will work on any type of file descriptor?
The poll() man page states that: "The poll system call provides users with 
a mechanism for multiplexing input/output over a set of file desriptors that
reference open *streams* [see intro(2)]." [my emphasis].

Sorry to quote the no-doubt familiar manual text but an fd obtained 
by using open() to a serial port doesn't qualify as a stream. Please correct 
me if I'm totally wrong.

Tim
-- 
Tim Fry      			tim@sporran.uucp
Toronto, Canada


-----------[000517][next][prev][last][first]----------------------------------------------------
Date:      Sun, 27 Jun 1993 13:13:04
From:      hadfield@storm.greta.cri.nz (Mark Hadfield)
To:        comp.protocols.tcp-ip
Subject:   TCP problem & window setting


I've run into a problem on some FTP client/server combinations. It goes
like this...

The ftp client logs onto the server, changes to the right directory,
retrieves directory information OK. I set hash marks on and try to 'get'
some files. A small file (a few hundred bytes) comes across fine. When I
try to get a larger file (several kB or more) the transaction hangs: no
hash marks appear and either the client or server eventually times out.
There is a 0-byte file in the local directory.

I ran into this problem recently while using the FTP client on my PC (the
TCP/IP software is PC/TCP version 2.2) and a particular server, let's
call it 'X'. X also has a news (NNTP) server. A very similar problem
arose when first trying to run the PC's NNTP client with X's server: the
login & initial exchange of information went OK, but the NNTP client
eventually timed out trying to retrieve the newsgroup list (approx 40kB).
This suggests that the problem is in the transport layer rather than at
application level.

Before you mutter "Bloody unreliable DOS-based software" I should point
out that a _real_ computer (a Sun running SunOS 4.1.3) is also unable to
get multi-kB files from server X. To all intents & purposes its FTP
client behaves identically to the PC's.

With a little experimentation on the PC (they wouldn't let me play with
the Sun) I established that the problem can be avoided (i.e. multi-kB
files can be fetched from X) if PC/TCP's "window" setting is
reduced: it works with window=1400 but not with window=1460.

The PC/TCP manual describes the "window" setting thus: "window ...
specifies the maximum amount of TCP data (in bytes) a remote host can
send your system before the system responds with an acknowledgement." It
suggests that the window size be set to a multiple of the Maximum Segment
Size of the network interface, which (it says) is 1460 for Ethernet.

A colleague, more knowledgeable than I about these things, says the
manual is misleading on this point and that the TCP window size is "used
to tell the sender how much data it can transmit before it has to wait
for an acknowledgment from the recipient.  This allows a fast sender to
send off several packets in quick succession without having to wait for
each one to be individually acknowledged."

Now I don't understand the exchange of information that goes on between
machines in a TCP transaction, but it seems clear that the problem above
arises when the server sends the client a packet then waits for an
acknowledgement which never comes. And they both just wait for the other
to make the next move ............... (I saw a play like that once.)

Anyway, although I can now acquire files from server X, the low value of
the window setting is slowing down transfers from other servers. Eg for a
connection to an ftp distribution site in Australia, for a file of approx
10 kB, the dependence of the transfer rate on window size is:

      TCP window size (byte)        transfer rate (byte/s)
            1400                           571
            1460                           571
            2920                           879
            4380                          1270
            5840                           381

(The transfer rates are all rather low because of the transmission delay
on the line. It takes 1400 ms to ping a packet off this server.)

I have run into the problem described above on only 3 FTP servers (out of
perhaps 50??). Two of the servers are in NZ, 1 overseas, but all outside
our local net.

Does this problem imply some sort of malfunction or wrong setting? If so,
where: at the server? at the client? somewhere in the middle, eg the
router?

I would appreciate any advice or relevant information.


 Mark Hadfield          hadfield@storm.greta.cri.nz
 NIWA Oceanographic (Taihoro Nukurangi)
 Wellington, New Zealand
 Phone: (+64-4) 386-1189      Fax: (+64-4) 386-2153


-----------[000518][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 1993 09:13:30 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   Re: TLI

tim@sporran.uucp (Tim Fry) writes:

>Where is it documented that poll() will work on any type of file descriptor?
>The poll() man page states that: "The poll system call provides users with 
>a mechanism for multiplexing input/output over a set of file desriptors that
>reference open *streams* [see intro(2)]." [my emphasis].

This may have been the case in System V.3. It is not the case in System V.4.
The SVR4 manual page no longer says ``reference open streams''. It says
``reference open files''. The manual page goes on to mention
a number of possible events, usually followed by a sentence like:
``For STREAMS, this flag is set even if the message is of zero length'',
further indicating thet poll(2) isn't there just for STREAMS.

It does work for instance on files in /proc. A debugger can debug a number
of processes/threads at the same time, and catch event by event by calling
poll(2) with the filedescriptors refering to those processes.

>Sorry to quote the no-doubt familiar manual text but an fd obtained 
>by using open() to a serial port doesn't qualify as a stream. Please correct 
>me if I'm totally wrong.

In SVR4 an fd optained from opening a serial port is a STREAM.

Casper

-----------[000519][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 1993 11:33:09 GMT
From:      hugibaz@hugis.nbg.sub.org (Ingo Kraupa)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   Re: TLI

tim@sporran.uucp (Tim Fry) writes:

>Sorry to quote the no-doubt familiar manual text but an fd obtained 
>by using open() to a serial port doesn't qualify as a stream. Please correct 
>me if I'm totally wrong.

Depends on your serial device driver. On machines supporting streams it is
most probably a stream.

-Ingo
--
/dev/sd0g             275824  260391    1641    99%    /usr
/dev/sd2a             299621  284300    3336    99%    /usr2
`was heisst hier oh man? das ist effiziente plattenplatzausnutzung...'
							(Lutz Birkhahn)

-----------[000520][next][prev][last][first]----------------------------------------------------
Date:      Sun, 27 Jun 1993 14:52:47 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   Re: TLI

	From SVID, volume I [3rd edition], poll(BA_OS):

	"poll() provides users with a mechanism for multiplexing input/output
over a set of file descriptors." [note: no "STREAMS" modifier]

	"....For STREAMS file descriptors, a user can also receive messages
using getmsg() and..."

	Which clearly indicates STREAMS fd's aren't the only ones it supports.
This is dated 1992, so implementations prior to that may have different
documentation, and so may not support it, but up-to-date implementations should
support poll() on any file descriptor that supports a read/write interface.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000521][next][prev][last][first]----------------------------------------------------
Date:      Sun, 27 Jun 93 23:21:48 GMT
From:      cliffb@cjbsys.bdb.com (cliff bedore)
To:        comp.protocols.tcp-ip
Subject:   Re: search for POP3 daemon for HP-UX

In article <a2824ab.740933894@sunmanager> a2824ab@sunmanager.LRZ-Muenchen.DE (Werner Spirk) writes:
>I am searching for a POP3D version ( version of University
>of California at Davis ) for HP-UX.
>In general I am searching for routines or a description 
>for changing flock to lockf routines inclusive parameters.
>
>Thanks in advance
>
>Werner Spirk
>email: spirk@lrz-muenchen.de
>

Since I just did this for SCO XENIX using the locking routines stolen from the
HP programming FAQ, what I did should be readily adaptable to HP.  Randy Bush
as psg.com was kind enough to make it available via ftp so I'm enclosing the
ftp address below for the sources for 1.8.3 as modified for SCO XENIX.  Hope
they help.

Cliff



cliffb@cjbsys.bdb.com (cliff bedore) writes:
> I hesitate to post the sources (140K compressed and uuencoded)  If someone
> has a site that I can upload them to, I'd be happy to.

As Cliff sent the sources to me, and they seem to work, I have made them
available for FTP as follows:

    ftp.psg.com:~/pub/unix/netware/xenixpop.tar.Z

> Be advised that you need the TCP/IP DEVSYS in addition to the TCP/IP
> RUNTIME to compile.  I think the executable is machine independent so I
> could upload that for those that don't have the DEVSYS (~50K).

If folk wish, I can make binary available for FTP.

I am still having problems getting it to work with shadow passwords.  If
anyone has clues ...
--
randy@psg.com   ...!uunet!m2xenix!randy



-- 
Cliff Bedore
7403 Radcliffe Dr. College Park MD 20840
cliffb@cjbsys.bdb.com


-----------[000522][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Jun 1993 01:14:17 GMT
From:      royc@rbdc.wsnc.org (Roy Crabtree)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   Re: TLI

In article <20k0hl$h8d@impger.nbg.sub.org> hugibaz@hugis.nbg.sub.org (Ingo Kraupa) writes:
>tim@sporran.uucp (Tim Fry) writes:
>
>>Sorry to quote the no-doubt familiar manual text but an fd obtained 
>>by using open() to a serial port doesn't qualify as a stream. Please correct 
>>me if I'm totally wrong.
>
>Depends on your serial device driver. On machines supporting streams it is
>most probably a stream.

	Aftyer version 3.1 or 3.2, yes.  But poll support file descs
	in general.

	Prior to 3.1 the kernel was a real plaid mixture internally.

royc
>
>-Ingo
>--
>/dev/sd0g             275824  260391    1641    99%    /usr
>/dev/sd2a             299621  284300    3336    99%    /usr2
>`was heisst hier oh man? das ist effiziente plattenplatzausnutzung...'
>							(Lutz Birkhahn)



-----------[000523][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Jun 1993 02:45:10 GMT
From:      obert@rchland.vnet.ibm.com (Carl Obert)
To:        comp.protocols.tcp-ip
Subject:   IP Addresses and Subnetwork Masks

Folks:

Section 3.2.1.3 of RFC-1122 states the following:

"IP addresses are not permitted to have the value 0 or
 -1 for any of the <Host-number>, <Network-number>, or
<Subnet-number> fields........... This implies that each
of these fields will be at least two bits long."

Other than the brute force method of counting bits, does
anybody know of a slick way to validate an IP address based on
the above rules given only the address and its associated subnet
mask.  In most cases, it seems to me that what really is under 
scrutiny is the mask and associated address, not the address
alone.

Thanks in advance.

CFO

-----------[000524][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Jun 1993 04:09:23 GMT
From:      thurlow@convex.com (Robert Thurlow)
To:        comp.protocols.tcp,comp.protocols.misc,comp.protocols.nfs
Subject:   Re: NFS Specification

In <1993Jun25.134727.11979@relay.nswc.navy.mil> pirey@relay.nswc.navy.mil (Phil Irey 703.663.1582) writes:

> Does anyone know where to get a copy of the current specification of NFS?
> I know that RFC-1094 provides such a specification, but it is my understanding
> that this has been obsoleted by current implementations.

While there is some incidental behaviour that is not described by
RFC 1094, the over the wire protocol has NOT changed in all that time.
It may; a new protocol and a much better-and-more-complete document
is in the works.  That protocol will take come time indeed to become
important because of the installed base, so I suggest you use the
RFC you already know about and backfill with archived traffic from
comp.protocols.nfs.

Rob T
--
Rob Thurlow, thurlow@convex.com
"Love between two people should be built on understanding,
 Until that's true you'll find your things all stacked out on the landing."
 -- Valentine's Day Is Over, Billy Bragg

-----------[000525][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 1993 08:17:31 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Addresses and Subnetwork Masks

In article <1993Jun28.024510.23116@rchland.ibm.com>
obert@rchland.vnet.ibm.com (Carl Obert) writes: 
    
    Section 3.2.1.3 of RFC-1122 states the following:
    
    "IP addresses are not permitted to have the value 0 or
     -1 for any of the <Host-number>, <Network-number>, or
    <Subnet-number> fields........... This implies that each
    of these fields will be at least two bits long."
    
    Other than the brute force method of counting bits, does
    anybody know of a slick way to validate an IP address based on
    the above rules given only the address and its associated subnet
    mask.  In most cases, it seems to me that what really is under 
    scrutiny is the mask and associated address, not the address
    alone.
    
You are correct.  And in fact, bit twiddling with the address and the mask
will do exacatly what you want.  Enjoy...

Tony


-----------[000526][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Jun 1993 12:18:37 GMT
From:      tim@sporran.uucp (Tim Fry)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   Re: TLI

In article <20jobq$9kp@mail.fwi.uva.nl> casper@fwi.uva.nl (Casper H.S. Dik) writes:
>tim@sporran.uucp (Tim Fry) writes:
>
>>Where is it documented that poll() will work on any type of file descriptor?
>> ...
>>
>This may have been the case in System V.3. It is not the case in System V.4.
>The SVR4 manual page no longer says ``reference open streams''. It says
>``reference open files''. The manual page goes on to mention
>a number of possible events, usually followed by a sentence like:
>``For STREAMS, this flag is set even if the message is of zero length'',
>further indicating thet poll(2) isn't there just for STREAMS.
>
>...
>
>>Sorry to quote the no-doubt familiar manual text but an fd obtained 
>>by using open() to a serial port doesn't qualify as a stream. Please correct 
>>me if I'm totally wrong.
>
>In SVR4 an fd optained from opening a serial port is a STREAM.
>
Several similar responses deleted...

OK, I sit corrected, I suppose it's time I got a more up-to-date manual 
if I'm going to quote blindly from it :-)

Tim

-- 
Tim Fry      			tim@sporran.uucp
Toronto, Canada


-----------[000527][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Jun 1993 14:16:58 GMT
From:      dcarr@gandalf.ca (Dave Carr)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In <1993Jun23.220021.24701@kentrox.com> mwitt@kentrox.com (Michael Witt) writes:

>Now you have lost end-to-end reliability.  Bad memory in any of the
>bridges could cause corrupted data to be accepted by TCP.

Buzzt!  Wrong.  A bridge will/should preserve the original FCS of the frame
according to 802.1d.  A router however does not.  
-- 
Dave Carr               | dcarr@gandalf.ca       | It's what you learn, 
Principal Designer      | TEL (613) 723-6500     | after you know it all,
Gandalf Data Limited    | FAX (613) 226-1717     | that counts. 

-----------[000528][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Jun 1993 14:23:25 GMT
From:      smb@cc.purdue.edu (Scott M. Ballew)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?

In article <1993Jun25.143450.16367@walter.cray.com> dana@taurus.cray.com (Dana J. Dawson) writes:
>
>We've tried both approaches over the years, and we've settled on using one
>unique name for each separate IP address.  The argument of using addresses
>rather than names for the cases when you want to specify a particular interface
>sounds nice, but in practice it is not feasible, especially if your networks
>change much (ours do).  We have many systems that don't run routing daemons
>and that must install static default routes.  In this case, you need to
>specify a local (i.e. directly attached) gateway address.  Using a single
>name for all addresses does not guarantee that this will be the case (not all
>our systems are "DNS smart", and not all our DNS servers run the same version
>of bind, so "sortlist" is not a dependable feature).  Also, the argument that
>applications should all accept and process multiple addresses returned for a
>given hostname is a nice theory, but this is also not yet a universally supported
>feature.  While we don't find our current scheme to be ideal, it at least allows
>us to give absolutely clear and correct answers to users who have questions
>about where they should point routes, etc.  We consider it to be the less
>confusing and vague of the two options, and only slightly less
convenient.

Why choose one or the other?  We have handled this for years by
registering a multi-interface host as follows:

    z.cc.purdue.edu    	in  a   128.210.xxx.1
    	    	    	in  a   128.210.yyy.1
    z-xxx.cc.purdue.edu	in  a   128.210.xxx.1
    z-yyy.cc.purdue.edu	in  a	128.210.yyy.1

    1.xxx.210.128.in-addr.arpa.	in  ptr	z.cc.purdue.edu.
    1.yyy.210.128.in-addr.arpa.	in  ptr	z.cc.purdue.edu.

This has the following advantages:

    z.purdue.edu will resolve to both addresses
    reverse lookups (PTR) of either address results in z.purdue.edu --
    	makes any hosts.equiv or .rhosts mappings work well
    references to the individual interfaces can be made for routing
    	choices, preferred interface for NFS, etc.

The only disadvantage we have encountered is that we store two extra A
records that we have to keep track of when a host moves or retires.
This has been minimal.

Scott M. Ballew
PUCC Hostmaster


-----------[000529][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 93 15:57:37 GMT
From:      gdmr@dcs.ed.ac.uk (George Ross)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

In article <20f6ai$dk7@newserv.ksu.ksu.edu>, holland@godiva.ne.ksu.edu (Rich Holland) writes:
> udp:
>         0 bad checksums
> 
> This is on an IBM RS/6000 320h running AIX 3.2.3.  The running kernel
> aparantly has UDP cheksums enabled.  :-)

Remember this is counting received checksum errors.  If the other end has
checksums disabled then it will send you a plus-zero instead, so your end won't
check the received checksum.  You would only see this counter incrementing
if both ends had checksums enabled and there were packet corruption.
-- 
George D M Ross, Department of Computer Science, University of Edinburgh
     Kings Buildings, Mayfield Road, Edinburgh, Scotland, EH9 3JZ
Mail: gdmr@dcs.ed.ac.uk      Voice: 031-650 5147      Fax: 031-667 7209

-----------[000530][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 93 19:07:52 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Path MTU Discovery


	I was curious to know if the Path MTU discovery technique as
	described in RFC 1191 has any impact on the Maximum-Segment-Size
	negotiation (MSS) done during TCP connection establishment?

	I thought there might some impact since the main rationale for
	RFC 1191 was to avoid fragmention?

	Randy
-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000531][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 1993 21:10:35 GMT
From:      vern@daffy.ee.lbl.gov (Vern Paxson)
To:        comp.protocols.tcp-ip
Subject:   tech report available on analytic models of WAN TCP connections

The following paper is now available via anonymous ftp to ftp.ee.lbl.gov;
retrieve WAN-TCP-models.{1,2}.ps.Z.  Each file uncompresses to a bit over
500KB of PostScript.

		Vern


	Vern Paxson				vern@ee.lbl.gov
	Systems Engineering		        ucbvax!ee.lbl.gov!vern
	Lawrence Berkeley Laboratory		(510) 486-7504


------------------------------------------------------------------------

		   Empirically-Derived Analytic Models of
		 Wide-Area TCP Connections: Extended Report

				Vern Paxson
		      Lawrence Berkeley Laboratory and
	     EECS Division, University of California, Berkeley
			      vern@ee.lbl.gov
				 LBL-34086

	We analyze 2.5 million TCP connections that occurred during
	14 wide-area traffic traces.  The traces were gathered at
	five "stub" networks and two internetwork gateways, providing
	a diverse look at wide-area traffic.  We derive analytic
	models describing the random variables associated with
	telnet, nntp, smtp, and ftp connections, and present a
	methodology for comparing the effectiveness of the analytic
	models with empirical models such as tcplib \cite{Danzig91}.
	Overall we find that the analytic models provide good
	descriptions, generally modeling the various distributions as
	well as empirical models and in some cases better.

------------------------------------------------------------------------

While I'm at it, I'll again plug its (considerably shorter) companion
paper, which you can get as WAN-TCP-growth-trends.ps.Z:


		 Growth Trends in Wide-Area TCP Connections

				Vern Paxson
		      Lawrence Berkeley Laboratory and
	     EECS Division, University of California, Berkeley
			      vern@ee.lbl.gov

	We analyze the growth of a medium-sized research laboratory's
	wide-area TCP connections over a period of more than two years.
	Our data consisted of six month-long traces of all TCP connections
	made between the site and the rest of the world.  We find that
	smtp, ftp, and X11 traffic all exhibited exponential growth in the
	number of connections and bytes transferred, at rates significantly
	greater than that at which the site's overall computing resources
	grew; that individual users increasingly affected the site's
	traffic profile by making wide-area connections from background
	scripts; that the proportion of local computers participating in
	wide-area traffic outpaces the site's overall growth; that use of
	the network by individual computers appears to be constant for some
	protocols (telnet) and growing exponentially for others (ftp,
	smtp); and that wide-area traffic geography is diverse and
	dynamic.

-----------[000532][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 93 21:15:20 GMT
From:      jerry@octopus (Jeremy Norbury)
To:        comp.protocols.tcp-ip,comp.client-server,comp.protocols.ibm
Subject:   Wanted : XDR ported to MVS (not IBM's)


	Wanted : XDR written in C, ported to MVS (not IBM's)
	====================================================

	Anybody  ported  XDR  and "rpcgen", knows where they live or
	knows whether it is an easy task ?

	Any advice would be appreciated.

		Cheers


+-------------------------------------------------------------------------+
|           My opinions, probably not those of my employer.               |
 +-------------------------------------------------------------------------+
|             Jerry Norbury - a Displaced Yorkshireman                    |
| Xerox PSD, El Segundo, LA, Calif.      voice work : [1] (310) 333 3370  |
|        jeremy_norbury.lax1b@xerox.com OR jarnold@wrc.xerox.com          |
+-------------------------------------------------------------------------+

-----------[000533][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1993 00:48:11 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1191 compliance

In article <rturner.740766507@imagen> rturner@imagen.com (Randy Turner) writes:
>	Thanks for all the replies.  The reason I asked is that if there
>	is not a considerable number of machines out there that support it
>	then I cannot justify the development effort to add it to our current
>	IP code.  I am trying to draw up a project to add several enhancements
>	to our our current (albeit outdated) IP implementation, and the
>	performance enhancements possible with PMTU discovery would definitely
>	help, but only if the majority of the networks we are installed in
>	support RFC 1191.  I also understand that vendor inclusion of proposed
>	standards help move the standards process along, but in my case I 
>	have a political battle if I use that reasoning. 

The end-host mechanism described in RFC1191 was specifically designed to
work whether or not any or all of the routers support RFC1191.  The router
support is only there to make the process more efficient.

In other words: all IP routers that have *ever* conformed to the
specifications, past or present, support RFC1191.  Period.  Read the
RFC again if you don't understand this.

Of course, there are probably routers out there that don't conform to the
original ICMP specification.  If you run into one of these, Path MTU
Discovery could cause trouble.

-Jeff

-----------[000534][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1993 01:00:13 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

In article <ipk632k@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>Based on the excellent idea of looking at `netstat`, I looked at two
>servers (mostly netnews), and found in the two days they've been up,
>they had a total of 57 TCP packets with bad checksums, in about
>5,000,000 TCP packets.  Three other machines used mostly for UNIX
>source serving had a total of 11 TCP packets with bad checksums in
>about 60,000,000 TCP packets.  There were fewer UDP checksum errors,
>but more than 0.
>
>With a few more reports about other vendor's hardware, I hope we can
>declare the idea of turning off TCP checksums officially dead.

Although I do not entirely agree with Jon Kay's argument in favor
of turning TCP checksums off, your netstat-based argument (in the
form given here) does not rule it out.  That is, you have made an
error in logic, or at least have left out a step in the proof.

Jon clearly argues for turning off checksums only when the underlying
path is highly reliable (e.g., with uninterrupted CRC protection).
One could debate whether it is ever possible to guarantee this, but let's
assume that this can be done by magic (or administrative means).

None of the netstat numbers posted so far have distinguished between
local-LAN and remote-LAN checksum errors (nor could they, as far as
I am aware, because BSD-based systems don't keep separate statistics).
Unless you can provide some sort of evidence that some of those 57
bad TCP checksums came from "local" packets, then these numbers don't
support your side of the argument.

Remember, I am not saying that your position is wrong.  I am saying
that your evidence is less than it appears to be.  It might be an
interesting research mini-project to collect the right set of numbers.

-Jeff

-----------[000535][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1993 01:04:42 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: Path MTU Discovery

In article <rturner.741294472@imagen> rturner@imagen.com (Randy Turner) writes:
>	I was curious to know if the Path MTU discovery technique as
>	described in RFC 1191 has any impact on the Maximum-Segment-Size
>	negotiation (MSS) done during TCP connection establishment?
>
>	I thought there might some impact since the main rationale for
>	RFC 1191 was to avoid fragmention?

A host using PMTU Discovery would normally advertise an MSS equal to
the first-hop MSS; that is, the MTU of the directly connected LAN
interface, less the TCP+IP header sizes.  Hosts that use RFC1191
will avoid fragmentation through that mechanism.  Older hosts, at
least those that comply with RFC1122, will use MIN(received-MSS, 512)
[I could have the constant wrong] for "non-local" peers, and so
will not do anything too awful.

-Jeff

-----------[000536][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Jun 1993 02:40:56 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

In article <20o46t$5d6@usenet.pa.dec.com>, mogul@pa.dec.com (Jeffrey Mogul) writes:
> Although I do not entirely agree with Jon Kay's argument in favor
> of turning TCP checksums off, your netstat-based argument (in the
> form given here) does not rule it out.  That is, you have made an
> error in logic, or at least have left out a step in the proof.
> 
> Jon clearly argues for turning off checksums only when the underlying
> path is highly reliable (e.g., with uninterrupted CRC protection).
> One could debate whether it is ever possible to guarantee this, but let's
> assume that this can be done by magic (or administrative means).
> 
> None of the netstat numbers posted so far have distinguished between
> local-LAN and remote-LAN checksum errors (nor could they, as far as
> I am aware, because BSD-based systems don't keep separate statistics).
> Unless you can provide some sort of evidence that some of those 57
> bad TCP checksums came from "local" packets, then these numbers don't
> support your side of the argument.
> 
> Remember, I am not saying that your position is wrong.  I am saying
> that your evidence is less than it appears to be.  It might be an
> interesting research mini-project to collect the right set of numbers.
> 
> -Jeff


You're right, except that the hassles you refer to in collecting the
right set of numbers must be considered as part of the proof.

Depending on magic or admininstrative means might be ok, if both the
consequences and likelihood of the magic failing or the spell being
uttered wrong were low.  Given evidence that failures are quite likely
with bad magic (or maybe even with good magic, should some of those 57
errors be local), and given the difficulties of ensuring something
equivalent to uninterrupted CRC protection, and given that computing
the TCP checksum takes such small number of cycles, don't you think the
case is proven?

  ----

Some have mentioned that genuine, 802.whatever briges to do not
recompute the ethernet CRC when forwarding packets.  Does that mean
that no FDDI-ethernet or Tokenring-Ethernet bridge is compliant?  Such
devices have no alternative except to recompute the CRC, albeit one
hopes only after checking it.


Vernon Schryver,  vjs@sgi.com

-----------[000537][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 93 08:42:44 CDT
From:      olsondavidsc@bvc.edu
To:        comp.protocols.tcp-ip
Subject:   TCP/IP / Workgroups / SQLServer

Hello,
	I am having trouble getting connected to Microsoft SQLServer.  I am 
running Windows for workgroups on the workstation, and using FTP PC/TCP to 
get connected to the SQLServer.  I have everything loaded, and am able to 
ping to the server.  But, when I go into my database editor(Q+E 5.0.2) and 
try to log onto the server I get the error that the server is not there or 
is unreachable.  What does this mean?  I can ping the server and it 
responds, but I can not make the connection to the SQLServer with the 
database editor.  If you, or someone you know has had these or similar 
problems please let me know.


	If you are running Windows for Workgroups, FTP PC/TCP, and 
Microsoft SQLServer, HOW DID YOU DO IT?
-- 
*****************************************************************************
Scott Olson 
E-Mail:  olsondavidsc@bvc.edu
*****************************************************************************

-----------[000538][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Jun 1993 04:09:09 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

imp@boulder.parcplace.com (Warner Losh) writes:

> I haven't had an undetected disk failure that showed up.

While I'm not sure I 100% understand that sentence, I'd have to agree with
the spirit.  A salesman who offered me a general-purpose TCP/IP
implementation where TCP checksums could be disabled would be treated like
a disk salesman who promised great disk performance by disabling ECC.  He'd
be asked to leave.

I can see why it would be tempting to treat a smart printer controller as a
special case: the data is going onto paper and will never be seen by
software again; if the user sees a printo on the paper, he can have it
re-printed.  But I just can't accept my own explanation - we're talking
about print output that will, *occasionally*, be going to a typesetter for
distribution as customer docs; purchase orders, paychecks, employee
reviews, etc, and I don't want my users to even *think* about getting in
the habit of doing any kind of printing with checksums disabled.  I don't
even want it to be an option, because if it is, someone will use it at the
wrong time and we'll all be burned.  It just isn't worth it.

There's a relevant line from some book on software performance (maybe one
of the Programming Pearls books): you can get amazing performance
improvements, as long as you don't care if the answer is right.

-- 
Tom Fitzgerald   Wang Labs       fitz@wang.com   "I went to the universe today;
1-508-967-5278   Lowell MA, USA                   It was closed...."

-----------[000539][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1993 11:37:43 -0400
From:      jspencer@cass.ma02.bull.com (Joel Spencer)
To:        comp.protocols.tcp-ip
Subject:   NFS on MVS

I am aware that tcp/ip access is available to IBM mainframes (that
run MVS) via a special FEP (is it a 3172???).  My question is, what applications
are available?  More to the point, is NFS available?  i.e. Can I "mount" an
MVS "filesystem" on a unix box?

Many thanks, Joel.

-- 

=============================================================================
|	Joel Spencer				| "excusez-moi, je pense    |
|	Bull HN Worldwide Information Systems	|  ma bouchon d'essence     |
|	Billerica, Massachusetts USA		|  est mal..."              |
|	Email: J.Spencer@Bull.Com		|                           |
=============================================================================

-----------[000540][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 93 07:02:42 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: Path MTU Discovery

mogul@pa.dec.com (Jeffrey Mogul) writes:

>In article <rturner.741294472@imagen> rturner@imagen.com (Randy Turner) writes:
>>	I was curious to know if the Path MTU discovery technique as
>>	described in RFC 1191 has any impact on the Maximum-Segment-Size
>>	negotiation (MSS) done during TCP connection establishment?
>>
>>	I thought there might some impact since the main rationale for
>>	RFC 1191 was to avoid fragmention?
 
>A host using PMTU Discovery would normally advertise an MSS equal to
>the first-hop MSS; that is, the MTU of the directly connected LAN
>interface, less the TCP+IP header sizes.  Hosts that use RFC1191
>will avoid fragmentation through that mechanism.  Older hosts, at
>least those that comply with RFC1122, will use MIN(received-MSS, 512)
>[I could have the constant wrong] for "non-local" peers, and so
>will not do anything too awful.
 
>-Jeff

/*
	Shouldn't the MIN() function in the above paragraph be a
	MAX()??  since RFC1122 requires an intermediate gateway or router
	to support at least a 576 byte packet (or 500-and-something byte
	packet, I forget the exact number)

	(?)

	Randy
*/
 
-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000541][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Jun 1993 14:23:44 EDT
From:      Peter M. Weiss <PMW1@psuvm.psu.edu>
To:        comp.protocols.tcp-ip
Subject:   Re: NFS on MVS

You can send the following to listserv@pucc.princeton.edu
to review the ibmtcp-l notebook archives:

/* --------------------- clip and save ---------------- */
//ListSrch JOB Echo=no
Database Search DD=Rules OUTLIM=5000
//Rules DD *
S nfs (mvs or hal) in ibmtcp-l from 92
index date.8 sender.30 subject.40
print
/*
//  EOJ
/* --------------------- clip and save ---------------- */

-----------[000542][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Jun 1993 15:44:05
From:      u16250@speedy.aero.org  (George A. Valencia)
To:        comp.protocols.tcp-ip
Subject:   Subnetting Question

     Attention Subnetting Experts -
                  
     We have a TCP/IP Class B network that runs over a large bridged
     Ethernet backbone.  The subnet mask on this network is 5 and all
     IP addresses are in the range 130.221.128.1 to 130.221.135.255.

     This network is connected to other subnets via routers.  Our main 
     concern is that we have recently exhausted the above address space.
     We have been planning to reorganize the subnet by adding more routers,
     moving systems on the 130.221.128.xxx subnet to 130.221.136.xxx, etc..  
     This is has not been done yet for various reasons.

     Recently, we started using the 130.221.136.xxx subnet on the same 
     backbone as the 130.221.128.xx subnet by configuring a router (with a 
     spare Ethernet interface) as the IP gateway for subnet 130.221.136.xxx.
     Although this seems to work, we are curious about unknown side-effects,
     particularily with regard to ARP.

     Network performance is the big issue here and it seems like the amount
     of traffic on the backbone is always increasing.  Would the conversion 
     to 'real' routed (not bridged) subnets help much?  We know some devices
     on the network currently detect ARP requests with 'invalid subnet' but 
     this seems mostly informative.  Are there network devices (X-Terminals,  
     etc) that are sensitive to multiple subnets on the same wire?  Would
     we be better off converting to a subnet mask of 0?.

     Responses to this group or email are appreciated.

 .-.. . - ...   ... - .- .-. -   .-   -.-. .--   -. . .-- ... --. .-. .--.  
George Valencia                                      valencia@mve.aero.org    


-----------[000543][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Jun 1993 10:50:03 GMT
From:      bygg@sunic.sunet.se (Johnny Eriksson)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <1993Jun28.141658.353@gandalf.ca> dcarr@gandalf.ca (Dave Carr) writes:

! >Now you have lost end-to-end reliability.  Bad memory in any of the
! >bridges could cause corrupted data to be accepted by TCP.
! 
! Buzzt!  Wrong.  A bridge will/should preserve the original FCS of the frame
! according to 802.1d.  A router however does not.  

If the bridge is broken it enjoys the privilige of ignoring 802.1d as much
as it wants, which may be plenty...

--Johnny

-----------[000544][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1993 11:37:49 GMT
From:      jogl@merry.imib.rwth-aachen.de (Joachim Glaubrecht  #Alwd#)
To:        comp.protocols.tcp-ip
Subject:   PROBLEM: telnet thrue Novell-Server


Hi,

maybe one of the Net-Work-Wizards out there can help us.

The problem:
we have a PC-LAN running (Netware 3.x) with some Novell-Servers,
routing tcp/ip.
from this PCs we like to contact to our VAXes. the PCs are
running NCSA-Telnet the VAXes UCX (1.3 and 2.0).
the configuration looks like this:

          ! EtherNet                                 =
          !        ____                              =  FDDI
          !       !PC B!                             =
      _______     !____!                          _______
     !Novell-!      !                            !FDDI-  !
     !Server !------+--+--------------+----------!BROUTER!
     !_______!       __!____        __!____      !_______!
          !         !AIX    !      !VAX    !         =
          !  ____   !       !      !UCX 2.0!         =
          ! !PC A!  !_______!      !_______!         =
          +-!____!
          !

the FDDI-BROUTER is configured as default gateway for alle
Unix and VMS stations. The Novell-Server ist default gateway
for all PCs "behind" it (not for "PC B").

if we now try to connect to the stations form the "PC B" all works
fine, BUT if we try to connect to the VAXes form "PC A" the
following happens:

---------- VAX/VMS - EHS102 - IPT/FhG - (Tel.: 0-241/8904-120) ----------

Username: XXXXXX
Password: YYYYYY
        Welcome to VAX/VMS version V5.4 on node EHS102


THATS IT. no more text. so, i CAN enter Name and Password, the
Vax starts to send the "hello" screen, BUT THEN ... nothing.

the line is o.k., the user IS logged in, but there is no more output.

the funny thing: connecting "PC A" to "AIX" or to other VAXes
(over the FDDI) work FINE. absolutly no problems.

does anyone know WHY this can happen ?
is there a problem because the VAX "hears" the packages twice ?
(once when the Novell-Server sends it to the BRouter and once when
it came back from the BRouter to the VAX ?)

ANY hint is wellcome !

-- 
    ___            _____________________________________ 
   /  /  _____    !  jogl@tolkien.imib.rwth-aachen.de   !
   __/__/_/ Gl    !    RWTH-Aachen, Germany, Europe     !
  /_/             !_Never_send_a_boy_to_do_a_man's_job__!

-----------[000545][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 93 12:17:16 GMT
From:      ian@spider.co.uk (Ian Heavens)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   Re: TLI

In article <20k0hl$h8d@impger.nbg.sub.org> hugibaz@hugis.nbg.sub.org (Ingo Kraupa) writes:
>tim@sporran.uucp (Tim Fry) writes:
>
>>Sorry to quote the no-doubt familiar manual text but an fd obtained 
>>by using open() to a serial port doesn't qualify as a stream. Please correct 
>>me if I'm totally wrong.
>
>Depends on your serial device driver. On machines supporting streams it is
>most probably a stream.

Now, yes - but many V.3 systems did not implement the serial device driver
in Streams.  Similarly, V.3 poll() could only be used on a Streams
device.


ian

---
	 Ian Heavens			ian@spider.co.uk                 
 	 Spider Software
 	 Spider Park, Stanwell Street		
	 Edinburgh, EH6 5NG, Scotland	+44 31 555 5166 (Ext 4347)
--

-----------[000546][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Jun 1993 12:18:32 GMT
From:      jbowyer@cis.vutbr.cz (Bowyer Jeff)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip.ibmpc,comp.protocols.time.ntp
Subject:   International Software


Please share your protocol experience with our mailing list.


INSOFT-L on LISTSERV@CIS.VUTBR.CZ   Internationalization of Software
                                    Discussion List

   Internationalization of software relates to two subjects:

        1. Software that is written so a user can easily change the
           language of the interface;

        2. Versions of software, such as Czech WordPerfect, whose
           interface language differs from the original product.

   Topics discussed on this list include:

        -- Techniques for developing new software

        -- Techniques for converting existing software

        -- Internationalization tools

        -- Announcements of internationalized public domain software

        -- Announcements of foreign-language versions of commercial
           software

        -- Calls for papers

	-- Conference announcements

	-- References to documentation related to the
           internationalization of software
	
   This list is moderated.

   To subscribe to this list, send an electronic mail message to
   LISTSERV@CIS.VUTBR.CZ with the body containing the command:

      SUB INSOFT-L Yourfirstname Yourlastname

   Owner:

      Center for Computing and Information Services
      Technical University of Brno
      Udolni 19, 602 00 BRNO
      Czech Republic

      INSOFT-L-REQUEST@CIS.VUTBR.CZ


-----------[000547][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1993 13:11:45 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

Steinar.Haug@runit.sintef.no (Steinar Haug) writes:

>> udp:
>>         0 bad checksums
>> 
>> This is on an IBM RS/6000 320h running AIX 3.2.3.  The running kernel
>> aparantly has UDP cheksums enabled.  :-)
 
>We run all our Suns with NFS checksums enabled. I just made a quick check.
>One fileserver (11 days uptime) had 2 UDP checksum errors; one fileserver
>(25 days uptime) had 3 UDP checksum errors. Not exactly huge numbers, but
>having the checksum turned on makes me sleep much better at night!

One probable generator of bad checksums with UDP is DNS. We have most
bad checksums on our nameservers.

Some bad checksums occur on clients. They could have been the result
of a packet from far away, but I wouldn't bet on it.

Casper

-----------[000548][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 93 13:36:06 GMT
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

> udp:
>         0 bad checksums
> 
> This is on an IBM RS/6000 320h running AIX 3.2.3.  The running kernel
> aparantly has UDP cheksums enabled.  :-)

We run all our Suns with NFS checksums enabled. I just made a quick check.
One fileserver (11 days uptime) had 2 UDP checksum errors; one fileserver
(25 days uptime) had 3 UDP checksum errors. Not exactly huge numbers, but
having the checksum turned on makes me sleep much better at night!

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000549][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1993 12:15:11 +0100
From:      cudep@csv.warwick.ac.uk (Ian Dickinson)
To:        comp.unix.internals,comp.sys.sun.admin,comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Re: TCP/IP

In article <STEINAR.HAUG.93Jun19170033@runit.sintef.no>,
	Steinar.Haug@runit.sintef.no (Steinar Haug) writes:
>The *interesting* measurement here is going to be ttcp with Solaris 2.2
>over FDDI, since SunOS 4.1.x has notoriously lousy FDDI performance.

Unfortunately, ttcp isn't going to be quite as fair as it used to be since
sockets are emulated under SunOS 5.x, rather than being real system calls.

Having said that I'm looking forward to seeing some carefully produced
figures, since the stuff I've done doesn't cut it.

ftp between two SS2000s using FDDI/S cards with an MTU of 1500:

134217728 bytes received in 48 seconds (2.7e+03 Kbytes/s)

Receiver:
$ uptime
 12:11pm  up 5 day(s), 18:14,  18 users,  load average: 0.71, 1.62, 1.23
$ uname -a
SunOS crocus 5.2 Beta_1.0 sun4d sparc


Sender:
$ uptime 
 12:11pm  up 6 day(s), 32 mins,  5 users,  load average: 0.00, 0.01, 0.02
$ uname -a
SunOS lupin 5.2 SunOS_Development sun4d sparc

BTW, does anyone know the model numbers for various configurations of SS2000?

Cheers,
-- 
\/ato - Ian Dickinson - NIC handle: ID17          This article is dedicated to
vato@csv.warwick.ac.uk  ...!uknet!warwick!vato        those who disapprove but
/I=I/S=Dickinson/OU=CSV/O=Warwick/PRMD=UK.AC/ADMD= /C=GB/          continue to
@c=GB@o=University of Warwick@ou=Computing Services@cn=Ian Dickinson      read

-----------[000550][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1993 14:11:45 GMT
From:      lane@callisto.read.tasc.com (Russel Lane)
To:        comp.protocols.tcp-ip
Subject:   HELP - Looking for 'Introduction to IP'


I ran across a reference to 'Introduction to the Internet Protocols' in
a September 1989 version of Ed Krol's 'Hitchhiker's Guide to the Internet'.
In that document, Mr. Krol gives topaz.rutgers.edu as the anonymous ftp
site for 'Introduction to the IP', stating that it can be found in 
directory '/pub/tcp-ip-docs'.

Unfortunately, that directory no longer exists at that ftp site.  Can 
anyone tell me if 'Introduction to the Internet Protocols' is still 
available, and if so, where I can get it?  If it is no longer available,
or has become obsolete in the last four years, can anyone recommend
an alternative??  

P.S. - the author cited for 'Introduction to the Internet Protocols' is
C. Hedrick.

I don't normally monitor this group, so please RSVP via email.  You can
reach me at:

		lane@callisto.read.tasc.com

Thanks a lot!!!

RL

-----------[000551][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Jun 1993 17:42:05 GMT
From:      mwr@eng.tridom.com (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: 802.1d Bridges and CRCs

Some bridge vendors have used hardware that does not support
transmitting an ethernet packet with the CRC in memory and
instead require recomputing it on transmit.  Other vendors
have controllers that have to be reset to switch modes and
since the bridge needs to have a CRC on the spanning tree packets
they leave it on.  This has caused a heated discussion in some
bridge groups because few vendors want to throw out current
product to support this requirement.

Note I am not arguing as to the whether the preservation of the
original CRC is proper or correct.  I am instead pointing out
that not all vendors necessarily comply.  

-- 
_____________________________________________
Mark Reardon   AT&T Tridom   (404-514-3383)
email: mwr@tridom.eng.tridom.com, attmail!tridom!mwr

-----------[000552][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Jun 1993 17:46:52 GMT
From:      dboyes@is.rice.edu (David E Boyes)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS on MVS

In article <20pnk7$qg4@cass.ma02.bull.com> jspencer@cass.ma02.bull.com (Joel Spencer) writes:
>I am aware that tcp/ip access is available to IBM mainframes (that
>run MVS) via a special FEP (is it a 3172???).  My question is,
>what applications 
>are available?

From IBM: Telnet, FTP, SMTP, SNMP, NFS, socket programming interface.
Available from the net at large: gopher client/server,
vt100-compatible telnet, other good stuff.

>More to the point, is NFS available?  i.e. Can I "mount" an
>MVS "filesystem" on a unix box?

Yes. There are some oddities due to having to supply some
identification tokens, but it works. Performance is OK -- not
incredibly fast, but usable. It doesn't deal very well with VSAM
files yet. 

You probably should check out IFS (Institutional File System)
developed by Univ of Michigan. It's NFS compatible, and allows
direct participation in DFSMS and all the other MVS data
management goodies.


>|	Joel Spencer				| "excusez-moi, je pense    |
>|	Bull HN Worldwide Information Systems	|  ma bouchon d'essence     |


-- 
David Boyes      In the event I am captured or killed, Rice University
dboyes@rice.edu  and the Office of Networking and Computing Systems
                 will deny any knowledge of my opinions.

-----------[000553][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Jun 1993 18:30:43 GMT
From:      evans@ralvmm.vnet.ibm.com (tjevans@ralvmm.vnet.ibm.com)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS on MVS

In article <20pnk7$qg4@cass.ma02.bull.com>, jspencer@cass.ma02.bull.com (Joel Spencer) writes:
|> I am aware that tcp/ip access is available to IBM mainframes (that
|> run MVS) via a special FEP (is it a 3172???).  My question is, what applications
|> are available?  More to the point, is NFS available?  i.e. Can I "mount" an
|> MVS "filesystem" on a unix box?
|> 
|> Many thanks, Joel.
IBM V2.2.1 has TELNET,FTP, NFS(server only), etc...answer=yes.

-- 
Tom Evans  TCP/IP Development
TOMEVANS@VNET.IBM.COM; (919) 254-4097
Normal disclaimer applies...

-----------[000554][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 1993 03:24:27 -0500
From:      tar@sam.ksu.ksu.edu (Tim Ramsey)
To:        comp.protocols.tcp-ip
Subject:   UDP checksums (was Re: bypassing TCP checksum)

gdmr@dcs.ed.ac.uk (George Ross) writes:

>Remember this is counting received checksum errors.  If the other end has
>checksums disabled then it will send you a plus-zero instead, so your end won't
>check the received checksum.  You would only see this counter incrementing
>if both ends had checksums enabled and there were packet corruption.

Actually, you should see this counter incrementing iff the remote end had
checksums enabled and there were packet corruption.  From RFC1122 (Host
Requirements -- Communication Layers):

         4.1.3.4  UDP Checksums
         ...
            If a UDP datagram is received with a checksum that is non-
            zero and invalid, UDP MUST silently discard the datagram.

The local end must detect UDP datagrams with invalid checksums even if it
has UDP checksums disabled.

-- 
Tim Ramsey, tar@matt.ksu.ksu.edu
  PGP2.3 public key available via keyserver, finger, or email.
  Member of the League for Programming Freedom and the ACLU.
"We're opposed to gratuitous whacking-off." -- Geoff Collyer

-----------[000555][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Jun 1993 23:17:09 GMT
From:      henryl@nyssa.coyote.trw.com (Henry Lee)
To:        comp.protocols.tcp-ip
Subject:   Windows API for Ethernet drivers?


	I am new to this news group. Please pardon me if my question is too trivial.
Any help is appreciated.

	Does any one know how a Microsoft Windows Application can access or interface 
to the packet driver, ODI driver, or NDIS driver? 

	Recently we might have needs to provide some kind of ethernet monitor function 
inside one of our Windows applications. We would like to use those drivers without 
any protocol stack. We have experiences in using the packet drivers under DOS.
And, we have specifications of packet driver and ODI driver.  What else do we
need?  Is there any Windows API of packet driver, ODI driver, or NDIS driver
available in the pusblic domain?

-----------[000556][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1993 23:41:19 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: Path MTU Discovery

In article <rturner.741337362@imagen> rturner@imagen.com (Randy Turner) writes:
>>>	I was curious to know if the Path MTU discovery technique as
>>>	described in RFC 1191 has any impact on the Maximum-Segment-Size
>>>	negotiation (MSS) done during TCP connection establishment?
 
>>A host using PMTU Discovery would normally advertise an MSS equal to
>>the first-hop MSS; that is, the MTU of the directly connected LAN
>>interface, less the TCP+IP header sizes.  Hosts that use RFC1191
>>will avoid fragmentation through that mechanism.  Older hosts, at
>>least those that comply with RFC1122, will use MIN(received-MSS, 512)
>>[I could have the constant wrong] for "non-local" peers, and so
>>will not do anything too awful.
>
>	Shouldn't the MIN() function in the above paragraph be a
>	MAX()??  since RFC1122 requires an intermediate gateway or router
>	to support at least a 576 byte packet (or 500-and-something byte
>	packet, I forget the exact number)

No.  Your facts and your reasoning are both confused.  The MIN is to
avoid sending a packet that is likely to be fragmented.  The constant
is arbitrary (actually, I think it is 536, not 512) but it seemed like
a good choice at the time (almost a decade ago).  The MIN is also to
avoid exceeding the MSS offered by the remote peer.

The "must accept at least 576 bytes in a datagram" rule applies to end
hosts.   All routers must support packets at least as large as the
MTU of any attached subnet.

-Jeff

-----------[000557][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 93 00:13:26 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

Vernon Schryver, vjs@sgi.com,  enunciates:
> In article <51179@sdcc12.ucsd.edu>, jkay@cs.ucsd.edu (Jon Kay) writes:
> > ...
> >          In my own decade in this business, I've been hit by disk
> > problems more times than I can easily count.  The misprinted check is
> > going to happen because of a bad disk controller, not because of the
> > network.
> 
> How many of those disk problems produced undetected errors?

	I ran into one just last week on our server.  I found a bogus
directory that had been copied by tar from another directory without
passing over a network.  What produced it?  So long as it's not the
network (which it wasn't), my argument remains intact.  It was
undetected for months; I only ran noticed it by sheer accident.  
	I have also had a Sun 3/60 with a bad on-disk controller for
years and seen all sorts of fun errors crop up.  I suppose in a sense
they weren't undetected, since it was possible to figure out WHEN they
happened - just not WHERE.

Vernon Schryver, vjs@sgi.com, continues:
> In other words, how many of those disk problems did not involve reading
> and writing the medium (since, as you note, that's protected with an
> ECC), but involved undetected errors while transfering data between the
> controller and main memory?

	I'm sure you have all seen gobs of disk problems not caused by
media, especially those of you living in areas with lots of lightning
storms - e.g., results of crashes.  Only a limited amount of stuff
gets written out, and often it gets written inaccurately.  Running
SunOS 4.0.1 on the East Coast, I could count on my 'C' shared library
(libc.so.whatever) being crunched by every thunderstorm that beat me
to the 'halt' command.  Thank God fsck is as good as it is!


imp@boulder.parcplace.com (Warner Losh) declares:
> In article <51179@sdcc12.ucsd.edu>, jkay@cs.ucsd.edu (Jon Kay) writes:
> I haven't had an undetected disk failure that showed up.  All the disk
> failures that have bitten me have been detected.  I would think after
> all the years I've been around that I might notice at least one glitch
> after the fact.

	I'm sure you've at least run into a crashed filesystem.
Remember, it is possible to have data corruption that you don't know
about even if you know something bad happened.  Fsck cannot diagnose
corrupt data blocks, nor does it always even do the correct thing with
inodes, though it tries quite hard.
	But this raises an interesting question.  How often DO
truly undetected disk failures occur?  By definition, it's hard to
tell, since they are, well, undetected.  When one does see a munged
file, the tendency is to assume that operator error produced it;
there's really no way to tell.  It gets harder and harder to tell as
one tends to have more and more gigabytes of data in which an error
might be hiding.  It would be a fascinating exercise to add a checksum
at the filesystem level and see how many errors are caught.
	But I think that it's possibly that a lot of you *have* seen
the results of "undetected" disk failures.  Let's think about this 
for a second. If a corruption did occur, what sort of disk access
would it occur in?  Read, write, metadata read, metadata write?  Well,
a lot of recent filesystem work (Keith Muller's MFS, the trace-driven
FS analysis that led to LFS, etc.) has shown that metadata writes are
the most common kind of disk access, so assuming a random
distribution, they should be the most commonly corrupted accesses as
well.  So, are they happening?  Well, many of those of you who are or
have been sysadmins have probably noticed that when you bring machines
down that have been up for months or more, they tend not to fsck
cleanly.  Of course, on such occasions, one tends to be more
interested in getting the machine running than in diagnosing the
problem, but this is completely consistent with the idea that metadata
writes get corrupted occasionally.

							Jon

-----------[000558][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 93 00:18:31 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)


vjs@rhyolite.wpd.sgi.com (Vernon Schryver) articulates:
> One would hope that any file transfer protocol at or below ethernet
> speeds would be entirely limited by the speed of the medium.  

	Most of the installed base today is neither Alpha nor SGI
Crimson.  In fact, even a lot of relatively recent low-end machines on
peoples' desks today (IPCs, 5000/20s, etc.) cannot fill up an Ethernet
using the software they've got.  Of course, even if every vendor
started shipping Checksum Redundancy Avoidance today, the machines
shipped would be able to fill Ethernets easily.  On the other hand,
more and more FDDI networks are being sold, and I'm sure 100baseT
variants will sell like hotcakes when they come out.
	Maybe more to the point, though one needs cycles to run the
application programs driving the network.

Vernon Schryver,  vjs@sgi.com sez:
> The
> cycles needed for the TCP/IP checksum should be insignificant today.

That's why you put a hardware checksummer onboard your FDDI interfaces
despite the added risk to customers.

 
craig@sics.se (Craig Partridge) writes:
> The first TCP/IP that was benchmarked at full Ethernet speeds ran on a similar
> platform -- a SUN 2 workstation using a Lance chipset in 1988.  Observe that
 ^3!!
> the number of protocol stacks you handle should have almost no impact on
> performance (if it does, you've done something wrong).  Since then, protocol
> implementations have improved further, so that 1990 vintage workstations
> (e.g., HP Snake) have been benchmarked doing TCP/IP at 100+ Mb/s (e.g.,
> about 13 Mbyte/s).
 
> The point here is that the best TCP/IP implementations currently available
> can easily achieve the performance you're looking for, on your processor.

From Jacobson's posting back in '88:
    |              3/60 to 3/60   |  3/280 to 3/60   |
    |            (LANCE to LANCE) | (Intel to LANCE) |
    | socket                      |                  |
    | buffer     task to          | task to          |
    |  size       task      wire  |  task      wire  |
    |(packets)   (KB/s)    (Mb/s) | (KB/s)    (Mb/s) |
    |    1         384      3.4   |   337      3.0   |
 ...
    |   12        1001      8.9   |   715      6.3   |

This is 91% Ethernet speed (not saturation, though quite close,
especially for a 3/60), on a 20% faster processor than Randy has.
So if he has 17k of memory for TCP windows and spends no time at all
on application-level processing (NOT!), and installed the 4.3Reno
networking code (a tidy couple months' work), and is using a LANCE, he
could hope for 800 MBps.  If nothing else goes wrong.  It's easy to
see why he's so interested in TCP improvements.  Especially
easy-to-install ones.  A 4.3-Tahoe-based OS on a 3/60, SunOS 4.1.1,
could only do about 600 MBps with the wind behind it, immense socket
buffers, and nothing else happening.  Randy probably has a Tahoe-based
OS (600 * 0.8 = 480.  And he may not have room for the 64k socket
buffers with which that measurement was taken).
	I think this raises an interesting point.  4.3 Reno (the OS
which those numbers come from) is available to Randy, but the more
recent implementations are not, and may never be if 4.4 BSD is
released without the newest networking code (and maybe not even then
if "4.4-Lite" doesn't happen).  And there was no mention of newer
networking code in the 4.4 announcement that went out today.

							Jon

-----------[000559][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Jun 1993 02:26:14 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

In article <51378@sdcc12.ucsd.edu>, jkay@cs.ucsd.edu (Jon Kay) writes:
> ...
>                   It would be a fascinating exercise to add a checksum
> at the filesystem level and see how many errors are caught. ...

About 24 years ago, I helped to exactly that to a file system not so
very different from UNIX's, on an SDS-940, to eventually find a
hardware problem in a channel.  There were enough spare bits in each
slot of the equivalent of an indirect block to add a checksum.  Every
midnight the system spent hours checksumming and de-fragmenting files.
The operator would deal with any discovered problems in the morning.

More recently, I saw people at Silicon Graphics do something
functionally similar to catch a bug that was messing up some rather
active, ~30GByte file systems used for UNIX source.  (Yeah, 30GB of
UNIX source trees.  Disgusting, isn't it?)  I think they've turned
off the nightly checks since the checks stopped discovering anything.

My point is that errors happen, in networks more than with disks,
because network data is fondled more often.  No check that is effective
and available should be discarded or turned off without a large
improvement in performance or system-cost.

The TCP checksum is effective, as shown by detected errors.  The TCP
checksum is cheap, as shown by systems that are cheap and fast and
compute it.

Some have said that the hardware assistance for the TCP checksum I like
is expensive.  I do not understand that.  How much do 2 or 3 16-bit
adders cost?  Can you even quantify their parts cost?  From another
direction, the SGI Indigo FDDI board uses a 16MHz 29030 to compute the
checksum, handle the MAC and PHYs, run the host DMA, and keep the MAC's
DMA going.  The bus is available to it 30-80% of the time, being tied
up by DMA the rest of the time.  In other words, it is a puny and
bus-starved processor by today's standards, but has no trouble
computing TCP and UDP checksums at full FDDI speeds, as well as all of
the rest of what it must do.

Once again, the performance cost of computing the checksum by the main
CPU is insignificant compared to cache effects in modern systems.

The only reason to do much work on the TCP checksum is if the work
can let the CPU avoid the cache costs of computing it.  If you must
byte-copy the data, there is no reason to worry about the checksum,
because the cache costs of the copies will be where you're spending
most of your time.


Vernon Schryver,  vjs@sgi.com

-----------[000560][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 93 02:47:14 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: Path MTU Discovery


>>>A host using PMTU Discovery would normally advertise an MSS equal to
>>>the first-hop MSS; that is, the MTU of the directly connected LAN
>>>interface, less the TCP+IP header sizes.  Hosts that use RFC1191
>>>will avoid fragmentation through that mechanism.  Older hosts, at
>>>least those that comply with RFC1122, will use MIN(received-MSS, 512)
>>>[I could have the constant wrong] for "non-local" peers, and so
>>>will not do anything too awful.
>>
>>	Shouldn't the MIN() function in the above paragraph be a
>>	MAX()??  since RFC1122 requires an intermediate gateway or router
>>	to support at least a 576 byte packet (or 500-and-something byte
>>	packet, I forget the exact number)
 
>No.  Your facts and your reasoning are both confused.  The MIN is to
>avoid sending a packet that is likely to be fragmented.  The constant
>is arbitrary (actually, I think it is 536, not 512) but it seemed like
>a good choice at the time (almost a decade ago).  The MIN is also to
>avoid exceeding the MSS offered by the remote peer.
 
>The "must accept at least 576 bytes in a datagram" rule applies to end
>hosts.   All routers must support packets at least as large as the
>MTU of any attached subnet.
 
>-Jeff

	Wow, that seems awfully inefficient.  Something must be missing
	from this equation, either that, or one of us is talking about
	hosts and the other intermediates.  Our MSS algorithm just selects
	the MIN(my-MSS, remote-MSS).  There are no constants involved.

	Randy

-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000561][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Jun 1993 03:39:00 GMT
From:      pthomas@netcom.com (Phillip Thomas)
To:        comp.protocols.tcp-ip
Subject:   multiple subnet masks

Hi,

I have some questions about subnetting that I hope the TCP/IP experts
out there can help with. Sorry if this is faq but I've never seen a faq
summary for this newsgroup.

Let's say that I have an IP network with a class B address. This leaves
16 bits to subnet with. Some subnets here require a large number of hosts
with no routers in between. Other subnets require a small number of hosts.

---------------------------------------------------------------------------
The main question is:

Can different subnets within the same IP network use different subnet masks?
---------------------------------------------------------------------------

For instance, can one subnet use a mask of 10 bits for the net part and 
6 bits for the host part while another subnet (within the same IP network)
use a subnet mask of 8 bits for the net part and 8 bits for the host part?

The idea is that the router between the two subnets would have a different
subnet mask on each of it's network interfaces.

How would routing work (or not work) in this situation? In particular,
what if the subnet with the 8 bit and 8 bit mask is subnet 255 and the
subnet with the 10 and 6 bit mask is some subnet above 255?

Thanks for all help,
Phil Thomas
pthomas@netcom.com


-----------[000562][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Jun 1993 03:52:55 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

In article <51380@sdcc12.ucsd.edu>, jkay@cs.ucsd.edu (Jon Kay) writes:
> 
> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) articulates:
> > One would hope that any file transfer protocol at or below ethernet
> > speeds would be entirely limited by the speed of the medium.  
> 
> 	Most of the installed base today is neither Alpha nor SGI
> Crimson.  In fact, even a lot of relatively recent low-end machines on
> peoples' desks today (IPCs, 5000/20s, etc.) cannot fill up an Ethernet
> using the software they've got.  Of course, even if every vendor
> started shipping Checksum Redundancy Avoidance today, the machines
> shipped would be able to fill Ethernets easily...

You are wrong to say that turning off the TCP checksum is necessary or
sufficent to make such systems saturate ethernets--regardless of
whether you turn it off smart or dumb.  Just as a dumb experiment, test
your throughput, then take the nearest such machine, and using adb or
dbx patch the subroutine call to in_cksum() in the 4.3BSD tcp_input.c
to jump around the bad-checksum-drop code, and re-test your
throughput.  I just now tried that on a pair of 20MHz R3000 based
systems using 4.3BSD-Net2 TCP code.

You are wrong to say that IPCs and 5000/20s were slower than the
machines Van Jacobson used to saturate ethernets in the dim past.


> Vernon Schryver,  vjs@sgi.com sez:
> > The
> > cycles needed for the TCP/IP checksum should be insignificant today.
> 
> That's why you put a hardware checksummer onboard your FDDI interfaces
> despite the added risk to customers.

Please read my preceding note tonight about the costs of that
checksummer, and the puny hardware it uses.

That outboard checksumming is worthwhile, but only because I also fixed
things to prevent byte copies.  0.5 cycles/byte is measurable, but not
significant compared to the cache costs, which are 10 to 500 times
higher than 0.5cycle/B, even on old R3000 based systems like DEC's.



> From Jacobson's posting back in '88:
>     |(packets)   (KB/s)    (Mb/s) | (KB/s)    (Mb/s) |
>     |   12        1001      8.9   |   715      6.3   |
> 
> This is 91% Ethernet speed (not saturation, though quite close,

If you read Van's old notices, you'll notice that he used an oscilliscope
to determine how hard he was driving the wire.  He was saturating it.

1001KByte/sec is more than ethernet speed or less, depending on the
number of collisions you suffer, which depends on many things, from the
TCP window size to bugs in the Ethernet MAC (without the right bugs,
you can be limited to ~850KByte/sec).  The maximum speed on an ethernet
is an interesting subject.


>                   ...  A 4.3-Tahoe-based OS on a 3/60, SunOS 4.1.1,
> could only do about 600 MBps with the wind behind it, immense socket
> buffers, and nothing else happening.

SunOS 4.1.1 is "4.3-Tahoe-based"?  That's interesting news.

Last I checked, a lot of Van Jacobson's code was in recent 4.3BSD.
That Sun's code did not perform the same as real 4.3-Tahoe does not
mean that Sun did anything wrong, but neither does it say much about
4.3-Tahoe.


> 	I think this raises an interesting point.  4.3 Reno (the OS
> which those numbers come from) is available to Randy, but the more
> recent implementations are not, and may never be if 4.4 BSD is
> released without the newest networking code (and maybe not even then
> if "4.4-Lite" doesn't happen).  And there was no mention of newer
> networking code in the 4.4 announcement that went out today.

The source on UUNET for years, as well as other places including CDROMs
has header prediction, et al.  It does not have the "squashed stack",
but it is fast enough to drive an FDDI ring at speed.

The limits to TCP/IP are almost never in the TCP/IP or checksum code,
but in uipc_socket*.c.


vjs

-----------[000563][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 1993 06:49:44 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple subnet masks

In article <pthomasC9F0t1.K3D@netcom.com> pthomas@netcom.com (Phillip
Thomas) writes: 

    Can different subnets within the same IP network use different subnet
    masks? 

Yes.  You will need a router that is capable of supporting this.  There are
many.  If you have multiple routers within that network, you will need a
routing protocol that supports this.  Still lots of choices...
    
    How would routing work (or not work) in this situation? In particular,
    what if the subnet with the 8 bit and 8 bit mask is subnet 255 and the
    subnet with the 10 and 6 bit mask is some subnet above 255?
    
Routing works by performing "longest match".  Basic algorithm:

for all masks, starting from longest to shortest
   apply mask against original destination
   search for a matching route
   if found, use it
end

A subnet with all ones in the subnet field is illegal.  I don't understand
what you mean by "above".

Tony

-----------[000564][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 1993 06:53:52 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting Question

In article <930629154405@veperfm.aero.org> George.A.Valencia@mve.aero.org
writes: 

         Network performance is the big issue here and it seems like the
         amount of traffic on the backbone is always increasing.  Would the
         conversion to 'real' routed (not bridged) subnets help much?  

Assuming you mean that that you would go to separate physical pieces of
copper, and that you have traffic patterns which have some locality, yes.

	 We
         know some devices on the network currently detect ARP requests
         with 'invalid subnet' but this seems mostly informative.  Are
         there network devices (X-Terminals, etc) that are sensitive to
         multiple subnets on the same wire?  

Yes, many.

	 Would we be better off
         converting to a subnet mask of 0?.
    
No, this would only confuse the issue more.

Tony

-----------[000565][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Jun 1993 07:52:32 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Path MTU Discovery

In article <rturner.741408434@imagen>, rturner@imagen.com (Randy Turner) writes:
> ...
> 	Wow, that seems awfully inefficient.  Something must be missing
> 	from this equation, either that, or one of us is talking about
> 	hosts and the other intermediates.  Our MSS algorithm just selects
> 	the MIN(my-MSS, remote-MSS).  There are no constants involved.


Does your algorithm comply with section 3.3.3 of RFC-1122 by using
those constants earlier, while computing my-MSS?


Vernon Schryver,  vjs@sgi.com

-----------[000566][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Jun 1993 13:02:40
From:      u16250@speedy.aero.org  (George A. Valencia)
To:        comp.protocols.tcp-ip
Subject:   Subnetting Question

     I have a question regarding subnetting.  We have a subnet with a 
     large number of hosts running on a bridged Ethernet backbone.  All 
     the systems on this subnet use class B addresses with a subnet mask 
     of 5.  We have recently exhausted this address space (with a subnet
     mask of 5, only 2048 host numbers are available).

     The original plan was to reorganize the subnet by splitting it in half.
     Half the systems would retain the old subnet number and the other half
     would have addresses on a new subnet.  The two subnets would then be
     connected through a router (not a bridge).

     This reorganization has not yet occured although it is still planned.
     As an interim step, the router which connects this subnet to the rest
     of the network was reconfigured as the IP gateway for the new subnet 
     (I think this required using a spare Ethernet interface in the router).

     Today, we have the old subnet (>2000 hosts) and the new subnet
     (>100 hosts) all running on the same bridged backbone.  In general,
     everything works but network performance is an issue.  Does anyone
     have experience with a similar configuration?  Does using multiple
     subnets on the same network have any adverse effects? Would we be 
     better off using a subnet mask of 0 until the routers are in place?


--
 .-.. . - ...   ... - .- .-. -   .-   -.-. .--   -. . .-- ... --. .-. .--.  
George Valencia                                           CIS: 76010,2020


-----------[000567][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Jun 1993 14:21:17
From:      u16250@speedy.aero.org  (George A. Valencia)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting Question

In article <930630130240@veperfm.aero.org> u16250@speedy.aero.org  (George A. Valencia) writes:

>     I have a question regarding subnetting.  We have a subnet with a 
>     large number of hosts running on a bridged Ethernet backbone.  All 
>     the systems on this subnet use class B addresses with a subnet mask 
>     of 5.  We have recently exhausted this address space (with a subnet
>     mask of 5, only 2048 host numbers are available).

     Someone has already noted that the way I described subnet mask
     above is confusing.  By 'subnet mask' I was refering to the number of
     bits in the address devoted to the the subnet number (5) not including
     the number of bits required for a class B network number (16).  So
     our real subnet mask is 21 bits or 255.255.248.0.  
     
>
>     The original plan was to reorganize the subnet by splitting it in half.
>     Half the systems would retain the old subnet number and the other half
>     would have addresses on a new subnet.  The two subnets would then be
>     connected through a router (not a bridge).
>
>     This reorganization has not yet occured although it is still planned.
>     As an interim step, the router which connects this subnet to the rest
>     of the network was reconfigured as the IP gateway for the new subnet 
>     (I think this required using a spare Ethernet interface in the router).
>
>     Today, we have the old subnet (>2000 hosts) and the new subnet
>     (>100 hosts) all running on the same bridged backbone.  In general,
>     everything works but network performance is an issue.  Does anyone
>     have experience with a similar configuration?  Does using multiple
>     subnets on the same network have any adverse effects? Would we be 
>     better off using a subnet mask of 0 until the routers are in place?
>

     By 'subnet mask of 0' I really mean 255.255.0.0 (16 bits).


George Valencia                            valencia@mve.aero.org


-----------[000568][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Jun 1993 10:12:13 GMT
From:      etstjan@dutepp2.et.tudelft.nl (Jan van Oorschot)
To:        comp.protocols.tcp-ip
Subject:   IP multicasting <-> AIX 2.2.1 problem

Hello,

We are having a problem running  IP-multicast traffic on our campus
ethernet network. This problem is caused by IBM RT Unix PC's running
AIX 2.2.1. Our configuration is roughly as follows.


            ----        ----
            |RT|  ....  |RT|
            ----        ----
              |           |
	   -----------------------	   		-------------
           |			 |    -----------	|	    |
	   |  Campus		 |    |	IP router	|	    |
	   |  Ethernet		 |----| CISCO	|-------| Internet  |
	   |  (bridged,          |    -----------	|	    |
	   |   no subnets)	 |			|	    |
 -----------------------			-------------
		 |					
               -------
	      |IPMULTI|
	      |router |
	       -------

When using IP multicast, an IP node will send frames with the
following characteristics:

	  - ethernet-destination-addres: <some ethernet multicast address>
	  - ip-destination-address:      <some IP multcast address>
	  - ip-source-addres:		 <some real IP address>
	  - time-to-live (TTL):		 1

Every node on our campus network receiving such frame, but not
supporting IP multicasting should drop such a frame, and generate no
reply because:

      	  - the TTL has expired
	  - the frame was received from an ethernet MULTI/BROAD-cast
	    address, so no ICMP reply should be send to avoid 
	    broadcast storms

The mentioned RT pc's reply with and ICMP 'network unreachable'
message, causing a very heavy, illegal IP workload. This is a bug in
the AIX 2.2.1 software, they should keep silent !
Because of this bug, we are forced to shut down our IP Multicast
services, so we are not able to receive the Video/Audio  coverage of
the upcoming IETF meeting.

My questions are:

   - is this a known problem ?
   - is there a bug fix for AIX 2.2.1 that solves this problem ?
   - are there other IP implementations that have the same problem ?

Jan




-- 
-- Ir. Jan van Oorschot.          --- Email: J.P.M.vOorschot@et.tudelft.nl --
-- Data Network Performance Analysis Project                               --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --

-----------[000569][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Jun 1993 17:16:06
From:      adrian@cursci.co.uk (Adrian Hall)
To:        comp.protocols.tcp-ip,comp.mail.misc
Subject:   Re: SMTP: "500" error message closing connection

In article <20rqqp$j9n@grasp1.univ-lyon1.fr> Christophe.Wolfhugel@grasp.insa-lyon.fr (Christophe Wolfhugel) writes:
>5 [12:14] wolf@grasp1:~> telnet gate1.pbi.nrc.ca smtp
>Trying...
>Connected to gate1.pbi.nrc.ca.
>Escape character is '^]'.
>220 All set, fire away
>ehlo blah
>500 Huh?
>Connection closed.

A classic case of connecting to a Microsoft Mail SMTP Gateway....
It's braindead - Microsoft are seemingly not going to fix it, so we
are stuck with it.

Regards,

Adrian

-----------[000570][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Jun 1993 13:40:39 GMT
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was Re: RFC 1191 compliance)

> 	Most of the installed base today is neither Alpha nor SGI
> Crimson.  In fact, even a lot of relatively recent low-end machines on
> peoples' desks today (IPCs, 5000/20s, etc.) cannot fill up an Ethernet
> using the software they've got.  Of course, even if every vendor

Depends on your definition of "the software they've got". An IPC can fill
an Ethernet quite nicely when running ttcp. That doesn't mean it'll be able
to fill the same Ethernet running FTP...

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000571][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 1993 14:23:27 GMT
From:      roy@mchip00.med.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> The TCP checksum is effective, as shown by detected errors.

	Just to pick a nit, all that the statistics people have quoted over
the past week or so show is that TCP checksuming catches *some* errors.
They give no indication as to how effective it is at catching all errors, or
even most of the errors.  It's well known that there are certain kinds of
errors which will corrupt a packet yet still pass checksum (i.e. transposed
quadwords).  I have no reason to believe that errors like that actually
occur with any significant frequency, but lacking any hard evidence to the
contrary, it remains a possibility.  Has anybody ever instrumented a system
to check for things like this?

	Not that I'm actually suggesting anybody turn off TCP checksums.
I'm just being pedantic.  The vast body of evidence and logic certainly says
that the cost/benefit ratio is so low turning them off would be just plain
silly.
-- 
Roy Smith <roy@nyu.edu>
Hippocrates Project, Department of Microbiology, Coles 202
NYU School of Medicine, 550 First Avenue, New York, NY 10016
"This never happened to Bart Simpson."

-----------[000572][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Jun 93 15:00:06 GMT
From:      slava@nac.ts.kiev.ua (Slava Adeev local area)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP beginner

S R (srounsle@sdcc3.ucsd.edu) wrote:
: I have a very basic question for anyone who is knowledgable about
: such matters.  I have a PC clone at home with a 14.4K modem.  I also
: have access to an ethernet dial-in line which supports SLIP
: connections.  I would like to set up a gopher client on my home
: machine, so that I can work from home more easily.  My question is
: what do I need?
First question is what kind of OS you have?
For DOS, you may use ka9q packet to use both sleep and packet driver.
Here is enough documentation to configure software.With use of ka9q you
may gopher client from your office computer or maybe get Gopher client from
any ftp server.


-----------[000573][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 1993 15:38:18 GMT
From:      roy@mchip00.med.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   New Yorker cartoon

	It would seem the Internet has finally really made it into the
popular press.  The 1993 July 5th New Yorker has a cartoon (page 61) of two
dogs.  One is sitting at a computer terminal, saying to the other, "On the
Internet, nobody knows you're a dog".
-- 
Roy Smith <roy@nyu.edu>
Hippocrates Project, Department of Microbiology, Coles 202
NYU School of Medicine, 550 First Avenue, New York, NY 10016
"This never happened to Bart Simpson."

-----------[000574][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 1993 12:44:41 +0200
From:      Christophe.Wolfhugel@grasp.insa-lyon.fr (Christophe Wolfhugel)
To:        comp.protocols.tcp-ip,comp.mail.misc
Subject:   SMTP: "500" error message closing connection

With the appearance of the ESMTP protocol, it appears that many sites
just can't handle it.

The SMTP RFC suggests following dialog which is supported by
most transfer agents:

>> EHLO bah
 << 500 Unrecognized
>> HELO blah

From time to time (every day I discover new ones !) I get that:

5 [12:14] wolf@grasp1:~> telnet gate1.pbi.nrc.ca smtp
Trying...
Connected to gate1.pbi.nrc.ca.
Escape character is '^]'.
220 All set, fire away
ehlo blah
500 Huh?
Connection closed.

RFC-821 is
not particularly explicit on whether the server may or may not close
the connection (I would tend to say no from the way I understood it
a 421 should be issued before closing).

--
Christophe Wolfhugel    |    Email: Christophe.Wolfhugel@grasp.insa-lyon.fr

-----------[000575][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Jun 1993 16:20:18 GMT
From:      peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>Some have said that the hardware assistance for the TCP checksum I like
>is expensive.  I do not understand that.  How much do 2 or 3 16-bit
>adders cost? 

Remember that we were originally talking about a laser printer, not a
workstation. At the very minimum, that adder will cost you a board
rev. More likely it will cost you a gate array where you used to have
just an unbuffered bus, and at least 48 or 64 pins.

That's easily more expense than you want to deal with in a laser
printer, especially when it would be cheaper to upgrade the processor,
and the resulting machine would run probably TCP faster. 

As far as I can tell, a separate adder only makes sense in something
like a high-end workstation, where there are few options left for
increasing processor speed, and the cost of a few adders (and the
logic to read their results, etc.) is minor in comparison to the cost
of any other speedups.

				Peter Desnoyers
-- 

-----------[000576][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 1993 16:26:44 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP checksums (was Re: bypassing TCP checksum)

In article <20rijrINN958@sam.ksu.ksu.edu> tar@sam.ksu.ksu.edu (Tim Ramsey) writes:
>The local end must detect UDP datagrams with invalid checksums even if it
>has UDP checksums disabled.

Unfortunately, that's not what 4.3bsd and earlier do, and I suspect that's
the kind of system his examples were on.  The BSD udp_cksum flag controls
both sending and checking.  It's really annoying, since it's much easier
for us to make sure that our file servers are properly configured than all
the workstations, but it only takes one misconfigured workstation with a
buggy ethernet interface to screw up a whole bunch of files.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000577][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 1993 16:28:48 GMT
From:      rice@access.digex.net (Mike Rice)
To:        comp.protocols.tcp-ip
Subject:   Network Engineer Needed (Job)

CornerStone is seeking talent to fill several positions to one
of our customers.  The environment will be technically intense
and should provide a tremedous opportunity for growth.

The following is a description of skill set :


Needed : 

	Network Engineer

Experience level in the following disciplines necessary : 

	DNS, ROUTING (BGP, IGP, EGP, RIP, IGRP, IS-IS, OSPF), 
	TFTP, CISCO Product Line, SNMP, 

	UNIX SUNOS and Silicon Graphics, 

	Cisco router configurations.

Applicants must show the following qualities : 

	Good personal skills dealing with customers.
	Low Learning Curve.

Other :

	The target project will provide an intense technical 
	environment, will be fast paced and could potentially 
	demand long hours.  The project is cutting edge and 
	could expand into several R&D initiatives.

Area :

	Northern Virginia

Note :

	NO "HEAD CASES", PLEASE !! 

Please send your resume via e-mail to rice@access.digex.net

Look forward to talking with you,

H. Mike Rice
 
--
|       CornerStone Alliance, Inc.| --------------------    __o 
|_|___               H. Mike Rice | InterActive Learning  _`\<,_ 
  |_____    rice@access.digex.net |       Networks !     (*)/'(*)

-----------[000578][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Jun 1993 16:41:03 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: turning off checks (Jacobson in 1988)

> >From Jacobson's posting back in '88:
>     |              3/60 to 3/60   |  3/280 to 3/60   |
>     |            (LANCE to LANCE) | (Intel to LANCE) |
>     | socket                      |                  |
>     | buffer     task to          | task to          |
>     |  size       task      wire  |  task      wire  |
>     |(packets)   (KB/s)    (Mb/s) | (KB/s)    (Mb/s) |
>     |    1         384      3.4   |   337      3.0   |
> ...
>     |   12        1001      8.9   |   715      6.3   |
> 
> This is 91% Ethernet speed (not saturation, though quite close,
> especially for a 3/60), on a 20% faster processor than Randy has.
> So if he has 17k of memory for TCP windows and spends no time at all
> on application-level processing (NOT!), and installed the 4.3Reno
> networking code (a tidy couple months' work), and is using a LANCE, he
> could hope for 800 MBps.

Uh, actually 8.9 Mb/s is closer to 99% Ethernet speed, after you account
for Ethernet timing rules, etc.  Depends on packet size and number of
hosts on the wire (See Boggs, et. al. in SIGCOMM '88).  And while my
recollection is clearly faulty (I'd remembered Van's work on a SUN 2),
I'll risk it and note that I recall Van saying when he presented
this work at SIGCOMM '88 (after his paper presentation) that the SUN
was "loafing".  It was not running flat out.

My point was THIS IS 5 YEAR OLD TECHNOLOGY!  All it had was header prediction
and (again, trusting my memory) a little improvement to avoid an unnecessary
context switch.  No attempt to reduce memory copies, no attempt to reduce
the number of procedure calls, etc....
 
Putting this idea a bit more strongly, most major computer companies have
at least one person in their staff that could straightforwardly replicate
Jacobson's work.  Several have.  To demonstrate this view, here's a brief list
off the top of my head: DEC (Mogul and Ramakrishnan), SGI (Schryver), HP
(Banks, et. al.), SUN (Hinden's group), IBM (Heimlich), NSC (Hughes),
and Cray (Borman).  To this you can add a bunch of researchers who don't
work for computer manufacturers: Jacobson, Torek, Partridge, Pink,
Crowcroft, Lynn, Kay.... (deepest apologies to folks left out -- but I
think the list is long enough for illustration).

Craig

-----------[000579][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Jun 1993 18:29:51 GMT
From:      veloovet@silver.ucs.indiana.edu (Katongkid)
To:        comp.protocols.tcp-ip
Subject:   Request for FAQ

Hi...
I'm new here and i was wondering whether someone
could either post the faq or send me a copy. it
would be much appreciated. thanx.

mohan


-----------[000580][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 93 18:32:07 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: Path MTU Discovery

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>In article <rturner.741408434@imagen>, rturner@imagen.com (Randy Turner) writes:
>> ...
>> 	Wow, that seems awfully inefficient.  Something must be missing
>> 	from this equation, either that, or one of us is talking about
>> 	hosts and the other intermediates.  Our MSS algorithm just selects
>> 	the MIN(my-MSS, remote-MSS).  There are no constants involved.


>Does your algorithm comply with section 3.3.3 of RFC-1122 by using
>those constants earlier, while computing my-MSS?


>Vernon Schryver,  vjs@sgi.com


	If you are talking about whether or not the remote-host is on
	a different network, then we do make adjustments to avoid
	fragmentation, but that check happens in another part of the 
	code.  We rely on this check to avoid fragmentation along the
	path (like the RFC says).  But this is even more important for
	us since our implementation does not support fragmenting of
	outbound IP packets....(yet, not sure if we will in the future).

	Randy
	
-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000581][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Jun 1993 20:08:26 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

In article <peterd.741457218@pjd.dev.cdx.mot.com>, peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> 
> >Some have said that the hardware assistance for the TCP checksum I like
> >is expensive.  I do not understand that.  How much do 2 or 3 16-bit
> >adders cost? 
> 
> Remember that we were originally talking about a laser printer, not a
> workstation. At the very minimum, that adder will cost you a board
> rev. More likely it will cost you a gate array where you used to have
> just an unbuffered bus, and at least 48 or 64 pins.

agreed.

> That's easily more expense than you want to deal with in a laser
> printer, especially when it would be cheaper to upgrade the processor,
> and the resulting machine would run probably TCP faster. 

agreed.

> As far as I can tell, a separate adder only makes sense in something
> like a high-end workstation, where there are few options left for
> increasing processor speed, and the cost of a few adders (and the
> logic to read their results, etc.) is minor in comparison to the cost
> of any other speedups.

I don't quite buy this.  If you were starting a printer controller
today, you'd need an Ethernet MAC, something to move packets (either
DMA or a CPU like a 29K doing loadm/storem) between the ethernet and
some memory, a CPU to control that stuff, a CPU to make pixels out of
Ethernet packets, something (perhaps DMA or a CPU loadm/storem) to move
pixels from memory to the laser, LED, even parallel printer port.
(Of course, you'll not have >1 CPU)

If you use a CPU get the packets from the Ethernet chip, you probably
could hide add instructions in the delay slots of an unrolled loop of
loads and stores, thereby computing the TCP checksum for free.

If you build some kind of PAL or ASIC or gate array to run the ethernet
DMA, couldn't you hide an adder?  Wouldn't you naturally build silicon
for a new printer controller, just to keep the cost down on what should
be a high volume product, shipped with printers for years to come?

I just realized that I've been saying 2-3 adders because I've been told
it's hard to make cheap 16-bit adders run at FDDI or HIPPI speeds.
Ethernet is sloooow; you only need a single, 16-bit end-around-carry
adder that cycles in 1.6 microseconds.  That's trivial, isn't?

Hardware assist for TCP checksumming is a bit of a hassle on output,
because you need to stuff the checksum for the whole packet into the
front of the same packet.  Hardware assist for received packets is
trivial, and requires no more than the 16-bit sum of the entire
packet.  Clear the adder at the start of the packet, and fetch its
contents at the end.  If you have an odd byte, don't bother to add it,
or zero fill and add it.  (Yes, all that sums too much or too
little, but is no problem.  Everyone please think about how the TCP
checksum works before arguing with me about that detail.)


Vernon Schryver,  vjs@sgi.com

-----------[000582][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Jun 93 20:43:47 GMT
From:      jepperso@vdoe386.vak12ed.edu (Jay Epperson)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?

Scott Ballew writes concerning single vs. multiple hostnames for multihomed
hosts:
> 
> Why choose one or the other?  We have handled this for years by
> registering a multi-interface host as follows:
> 
>     z.cc.purdue.edu    	in  a   128.210.xxx.1
>     	    	    	in  a   128.210.yyy.1
>     z-xxx.cc.purdue.edu	in  a   128.210.xxx.1
>     z-yyy.cc.purdue.edu	in  a	128.210.yyy.1
> 
>     1.xxx.210.128.in-addr.arpa.	in  ptr	z.cc.purdue.edu.
>     1.yyy.210.128.in-addr.arpa.	in  ptr	z.cc.purdue.edu.
> 
> This has the following advantages:
> 
>     z.purdue.edu will resolve to both addresses
>     reverse lookups (PTR) of either address results in z.purdue.edu --
>     	makes any hosts.equiv or .rhosts mappings work well
>     references to the individual interfaces can be made for routing
>     	choices, preferred interface for NFS, etc.
> 
> The only disadvantage we have encountered is that we store two extra A
> records that we have to keep track of when a host moves or retires.
> This has been minimal.
> 
Can someone explain this to us (or is it just me)?  My ARPA Services/DNS doc
does not explain the significance of the "xxx", "yyy", and "cc" conventions,
although the "xxx" and "yyy" appear to be symbolic substitutions here for
subnets.  The described advantages are just what we'd like, but I don't
understand the setup.

Although I prefer the idea of one host-one hostname (it IS the same machine,
aren't it?), I've had problems with a hp-ux DNS server going out of its
gourd when it got requests from other machines.  It seemed perfectly happy
resolving everything including references to itself when I used nslookup on the
DNS server, but any request from another machine, on or off our net, seemed to
send it on an endless quest querying root servers and such.  Never figured out
what was happening, it just stopped when I gave the interfaces different
names in the db-dot files (I have HP support, but after re-creating the
problem twice and running traces for them, they wanted yet another 
disruptive trace done on this production server.  Forget it.).

W.C. Epperson
epperson@vdoehp.vak12ed.edu



-----------[000583][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 93 21:20:45 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: bypassing TCP checksum (was RFC 1191 compliance)

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>In article <peterd.741457218@pjd.dev.cdx.mot.com>, peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
>> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>> 
>> >Some have said that the hardware assistance for the TCP checksum I like
>> >is expensive.  I do not understand that.  How much do 2 or 3 16-bit
>> >adders cost? 
>> 
>> Remember that we were originally talking about a laser printer, not a
>> workstation. At the very minimum, that adder will cost you a board
>> rev. More likely it will cost you a gate array where you used to have
>> just an unbuffered bus, and at least 48 or 64 pins.
 
>agreed.
 
>> That's easily more expense than you want to deal with in a laser
>> printer, especially when it would be cheaper to upgrade the processor,
>> and the resulting machine would run probably TCP faster. 
 
>agreed.
 
>> As far as I can tell, a separate adder only makes sense in something
>> like a high-end workstation, where there are few options left for
>> increasing processor speed, and the cost of a few adders (and the
>> logic to read their results, etc.) is minor in comparison to the cost
>> of any other speedups.
 
>I don't quite buy this.  If you were starting a printer controller
>today, you'd need an Ethernet MAC, something to move packets (either
>DMA or a CPU like a 29K doing loadm/storem) between the ethernet and
>some memory, a CPU to control that stuff, a CPU to make pixels out of
>Ethernet packets, something (perhaps DMA or a CPU loadm/storem) to move
>pixels from memory to the laser, LED, even parallel printer port.
>(Of course, you'll not have >1 CPU)
 
>If you use a CPU get the packets from the Ethernet chip, you probably
>could hide add instructions in the delay slots of an unrolled loop of
>loads and stores, thereby computing the TCP checksum for free.
 
>If you build some kind of PAL or ASIC or gate array to run the ethernet
>DMA, couldn't you hide an adder?  Wouldn't you naturally build silicon
>for a new printer controller, just to keep the cost down on what should
>be a high volume product, shipped with printers for years to come?
 
>I just realized that I've been saying 2-3 adders because I've been told
>it's hard to make cheap 16-bit adders run at FDDI or HIPPI speeds.
>Ethernet is sloooow; you only need a single, 16-bit end-around-carry
>adder that cycles in 1.6 microseconds.  That's trivial, isn't?
 
>Hardware assist for TCP checksumming is a bit of a hassle on output,
>because you need to stuff the checksum for the whole packet into the
>front of the same packet.  Hardware assist for received packets is
>trivial, and requires no more than the 16-bit sum of the entire
>packet.  Clear the adder at the start of the packet, and fetch its
>contents at the end.  If you have an odd byte, don't bother to add it,
>or zero fill and add it.  (Yes, all that sums too much or too
>little, but is no problem.  Everyone please think about how the TCP
>checksum works before arguing with me about that detail.)


>Vernon Schryver,  vjs@sgi.com

	The thing that really complicates the issue of optimizing the
	checksum through means described above is the fact that a
	pseudo-header has to be formed and checksummed first.....
	It's not just a straightforward summing of a packet as an 
	additional bit of logic in an ASIC for Ethernet DMA...

	Randy


-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000584][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Jun 1993 21:24:38 GMT
From:      smb@cc.purdue.edu (Scott M. Ballew)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Equal hostnames for multiple interfaces?

In article <1993Jun30.204347.11311@vdoe386.vak12ed.edu> jepperso@vdoe386.vak12ed.edu (Jay Epperson) writes:
>Scott Ballew writes concerning single vs. multiple hostnames for multihomed
>hosts:
>> 
>> Why choose one or the other?  We have handled this for years by
>> registering a multi-interface host as follows:
>> 
>>     z.cc.purdue.edu    	in  a   128.210.xxx.1
>>     	    	    	in  a   128.210.yyy.1
>>     z-xxx.cc.purdue.edu	in  a   128.210.xxx.1
>>     z-yyy.cc.purdue.edu	in  a	128.210.yyy.1
>> 
>>     1.xxx.210.128.in-addr.arpa.	in  ptr	z.cc.purdue.edu.
>>     1.yyy.210.128.in-addr.arpa.	in  ptr	z.cc.purdue.edu.
>> 
>> This has the following advantages:
>> 
>>     z.cc.purdue.edu will resolve to both addresses
>>     reverse lookups (PTR) of either address results in z.cc.purdue.edu --
>>     	makes any hosts.equiv or .rhosts mappings work well
>>     references to the individual interfaces can be made for routing
>>     	choices, preferred interface for NFS, etc.
>> 
>> The only disadvantage we have encountered is that we store two extra A
>> records that we have to keep track of when a host moves or retires.
>> This has been minimal.
>> 
>Can someone explain this to us (or is it just me)?  My ARPA Services/DNS doc
>does not explain the significance of the "xxx", "yyy", and "cc" conventions,
>although the "xxx" and "yyy" appear to be symbolic substitutions here for
>subnets.  The described advantages are just what we'd like, but I don't
>understand the setup.

"xxx" and "yyy" are symbolic substitutions for subnets.  You didn't
think I was necessarily going to publish examples on our network and
have someone cut and paste into their database files thus flooding one
or more of our hosts with misdirected traffic, did you? :-)

"cc"  is the subdomain of purdue.edu (yes, I know it is really a
domain) that houses machines in the Purdue University Computing
Center.  I also made the mistake in my original of using the
cc.purdue.edu domain and just using the purdue.edu domain in
inconsistent ways.  I have corrected the text of my original post,
above, to make it correct.  Sorry for the confusion.

Scott

-----------[000585][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 1993 18:19:39 +0200
From:      bortz@cnam.cnam.fr (Stephane Bortzmeyer)
To:        comp.protocols.tcp-ip
Subject:   Re: How to relate PCB's (netstat -A) to processes?


In article <C911KH.C46@bull.nl>, jos@bull.nl (Jos Vos) writes:
...
> The reason for this is that I want to find the processes using
> sessions on a specific port.

The best way, to me, is to use the 'pident' software. pident is an
implementation of the RFC 931 "Authentication Server" (obsoleted recently
by 1413 "Identification Protocol").
RFC 931 describes a service to obtain the name associated with a connection.
It's used, for instance, by the log_tcp security package. This allow a
server to know who (and not only which machine) used it.
You give to the RFC 931 server the two ports, and it sends you the login
name. You can use it like that, or hack the code (it runs on any Unix 
Berkeley).
Here is an example where foobar wanders who on the machine client connects
to X Window:

foobar% telnet client ident
Trying x.x.x.x...
Connected to client.
Escape character is '^]'.
1480, 6000
1480, 6000: USERID: UNIX: smith

pident can be found on peanuts.pst.informatik.uni-muenchen.de:-
/pub/next/Unix/network/pidentd-2.1.tar.Z and some others. 

Stephane Bortzmeyer           Conservatoire National des Arts et Metiers	
bortzmeyer@cnam.cnam.fr       Laboratoire d'Informatique
                              292, rue Saint-Martin			
tel: +33 (1) 40 27 27 31      75141 Paris Cedex 03
fax: +33 (1) 40 27 27 72      France	

"C'est la nuit qu'il est beau de croire a la lumiere." E. Rostand

					
	

-----------[000586][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Jun 1993 23:25:43 GMT
From:      gls@cirrus.com (Gary L. Schaps)
To:        comp.protocols.tcp-ip
Subject:   ONC RPC Library function clnt_control()

I am having a problem trying to shorten the total timeout of 
an RPC client with clnt_control().  Would any of the astute
readers of this newsgroup who have successfully done this 
like to take a look at my code? 

Thanks.

Gary L. Schaps
gls@cirrus.com

END OF DOCUMENT