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 March 1993 (486 messages, 266978 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1993/03.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 93 03:09:59 GMT
From:      gould@pilot.njin.net (Brian Jay Gould)
To:        comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc
Subject:   Looking for LAT <-> Telnet conversion box

I am looking for a box that can recieve Telnet and automagically
translate to LAT for a LAT based host,  It seems to me that I 
shouldn't need a milking machine arrangement, somewhere this
can be done completely in software.  Hopefully on something much
smaller than an Ultrix system.

Please respond via e-mail.  Thanks.
-- 
--
Any disclaimers made for me, by me, or about me - may or may not accurately
reflect my failure to be reflecting the opinions of myself or anyone else.
********************************************
*  Brian Jay Gould - gould@pilot.njin.net  *
*                    609-799-2706          *
********************************************

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1993 04:20:39 GMT
From:      emv@msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP client (new; easier to use) available?

Karl Denninger (karl@ddsw1.MCS.COM) wrote:
: A couple of months ago someone posted a pointer to a freely available,
: easier-to-use FTP client package which was on the net somewhere. 

The 'ncftp' package is nicer than the usual 'ftp'.  I wouldn't say
spectacular bells-and-whistles GUI, but it does have a number
of features for frequent ftp'ers that are well worth getting.
It was posted to comp.sources.misc, and an archie search for 'ncftp'
will find it.

Here's their blurb:

Subject:  ncftp - Alternative User Interface for FTP, Part01/01

Archive-name: ncftp/part01
Environment: UNIX, ANSI-C, getopt

ncftp - Alternative user interface for FTP
version 1.0 by Mike Gleason, NCEMRSoft.

ncftp was created out of disgust with using the regular 'ftp'
command found on many brands of Unix.  People who spend a lot
of time in ftp will want to install ncftp.

Features:

 * No more typing 'anonymous' and your email address every time
   you want to ftp anonymously.  You don't need to have the
   site in your .netrc.
   
 * No more typing complete site names.  Sites in your .netrc
   can be abbreviated.  Type 'o wuar' to call wuarchive.wustl.edu.
 
 * Use your pager (like 'more') to read remote files (and also
   compressed files).

 * Use your pager to view remote directory listings.

 * Transfers feature a progress meter.
 
 * Implicit cd.
 
 * Fancy prompts.
 
 * You can keep a log of your actions.  See what the path was of
   that file you downloaded yesterday so you don't have to
   look for it today.
 
 * Built-in mini-nslookup.
 
 * The 'ls' command is ls -CF.  Some ftp's ls was identical to 'dir.'
 
 * You can 'redial' a remote host until you connect.

 * Don't need to 'close' a site, just open a new one.
 
 * Don't feel like typing a long filename?  Use a wildcard in single
   file commands like get and page.
 
 * You can create empty remote files.

 * Supports 'colon mode', so you can type 'ncftp cse.unl.edu:/pub/foo',
   to copy foo into your current directory.

 * You can re-display the last directory listing without getting it
   across the network.

 * Detects when new mail arrives.

 * ncftp is quieter by default -- who cares if the PORT command was
   successful (if you do, turn verbose on :-).

  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)


-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1993 06:26:25 GMT
From:      vicka@wrq.com (the Littlest Orc)
To:        comp.protocols.tcp-ip
Subject:   name resolution mystery

Help!  I'm 'way confused....

To summarize: Machines out there on the net can't resolve names in this
domain to addresses, but given the addresses, they are apparently able to
find out the names.

For example, let's say there's a machine in the broken domain called
"bug.foo.com", with IP address 2.3.4.5.

If I'm logged into a machine outside the broken domain ("vax.bar.com"),
and I give a command like "telnet bug.foo.com", I get an error: Can't 
resolve hostname.

On the other hand, if I give the command "telnet 2.3.4.5" it succeeds --
and, moreover, netstat on vax.bar.com quite cheerfully says: local address
vax.4000; foreign address bug.foo.com.telnet.  <-- It's somehow resolved
the address into a name!

Now, I've looked at the traffic (from the broken-domain end, alas), and
I'm pretty certain that the information isn't going from bug.foo.com.
Obviously, it's not local to vax.bar.com or available via ordinary DNS
channels, either (or it would have been able to connect by hostname in
the first place, right?).  So what's going on?  

I'd appreciate responses posted to the net, since there's a bit of trouble
getting email through to me right now :)

ignorant but curious,
--Nerd Girl						Vicka Corey
  Walker, Richer, & Quinn				vicka@wrq.com
	   "More fun than a barrel of monkey wrenches!"

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Mon, 01 Mar 1993 16:46:50
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP, retry timer, RF extension

In article <1993Feb27.180930.4270@gandalf.ca> dcarr@gandalf.ca (Dave Carr) writes:

    In <C3478s.2sD@watserv1.uwaterloo.ca> erick@sunee.uwaterloo.ca (Erick Engelke) writes:
    
    >> chuckb@babbage.csus.edu (Chuck Bland) writes:
    >>
    >>The problem is with the TCP retry timer. Is it not true that EXISTING
    >>nets and hosts have much shorter retry timers, since connectivity is
    >>so much better, bits rates are higher, etc ? 
 
    >A modern TCP has a few default constants, but it adapts to the data
    >rates of the connection and all intermediate lines.  So before resending
    >data, the TCP uses statistics to say it is unlikely that the previous
    >packet worked.  To do this, it keeps constant track of a few run-time
    >statistics.
    
    Yes.  But PC/TCP has the above mentioned problem.  I ran into it testing
    wide-area bridges over 64K pipes.  PC/TCP would not adjust it's timers,
    or at least not make them long enough. 

Dave and I have been over this before, both privately and in other forums.

The issue at the bottom is "reliable link layers".  Some people decide that
they need to implement protocols at/below the MAC layer which *guarantee*
that a packet sent into their medium is ultimately delivered to the exit
point, eventually.

This is great, if you're using the medium to transport packets from
lightweight protocols (which typically don't have sophisticated retransmit
timers) - otherwise they'd fail due to excess packet loss.  However, if you
have a sophisticated retransmit timer, the "reliable link layer" is more of
a hindrance than a help.  The sophisticated protocol is prepared for packet
loss, but it has great trouble dealing with round-trip-times that vary by
a factor of 4 or more (20:1 in one "wireless LAN" scheme I'm aware of).

Slow-start helps, but only for bulk data transfers.  Byte-count sensitive
rate calculations help, too, where the time to send a packet and its
likelihood of encountering an error are greatly affected by its length.
However, I don't know how to solve the whole problem, so it looks to me
like "reliable link layer" isn't as useful in catenets as some people think.

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


-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Mar 1993 13:40:36 GMT
From:      rob@icarus.inmos.co.uk (Robin Pickering)
To:        comp.protocols.tcp-ip
Subject:   Re: Automatic running of processes in TCP/IP

In article <1993Feb26.152616.11373@aston.ac.uk> j.williams@aston.ac.uk (John Williams) writes:
>I would like to set up a system which allows users to call a TCP port and then
>automatically run a process,

Try:

man inetd

--
    Rob.

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Mar 1993 15:30:46 GMT
From:      dij@afp.com (Didier Jouan)
To:        comp.protocols.tcp-ip
Subject:   How determine network configuration

Hi,

We are working on ESIX V.4.0 and we need to determine network configuration.

So, we use the SIOCGIFCONF ioctl call which is given in example in the 
"ESIX SYSTEM V Release 4 Programmer's guide : Networking Interfaces page 3-53".

Here it is :

int         iSocket, NbInt, n;
struct      ifconf  ifc;
struct      ifreq   *ifr;
char        buf[BUFSIZ];

iSocket = socket( AF_INET, SOCK_DGRAM, NULL );

ifc.ifc_len = sizeof( buf );
ifc.ifc_buf = buf;
if ( ioctl(iSocket, SIOCGIFCONF, (char *) &ifc ) < 0 ) {
	......
}

ifr = ifc.ifc_req;
NbInt = ifc.ifc_len / sizeof( struct ifreq );
for( n=NbInt; --n >= 0 ; ifr++ ) {
	if ( ifr->ifr_addr.sa_family != AF_INET ) continue;
	if ( ioctl( iSocket, SIOCGIFFLAGS, (char *) ifr ) < 0 ) {
		.....
	}
	if ( ifr->ifr_flags & IFF_BROADCAST ) {
		if ( ioctl( iSocket, SIOCGIFBRDADDR, (char *) ifr ) < 0 ) {
			...
		}
	}
}

The SIOCGIFCONF ioctl seems to work, but the ifc.ifc_buf and ifc.ifc_req
fields remain unchanged. Is it the right way to determine the network configuration?
This problem has occured when compiling the bootpd sources from the uunet distrib on a i486 machine running a SVR4 unix.

Any suggestions will be appreciated.

Thanks in advance!

-- 
Didier Jouan,		Agence France Presse, +33 1 40414855
Mail :			13, Place de la Bourse 75012 PARIS FRANCE
Email:			dij@afp.com




-- 
Didier Jouan,		Agence France Presse, +33 1 40414855
Mail :			13, Place de la Bourse 75012 PARIS FRANCE
Email:			dij@afp.com

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Mar 1993 15:32:25 GMT
From:      erick@demorgan.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP NetUnreachable and TCP behaviour?

In article <C32H9n.Got@signet.com> sen@signet.com (Siddhartha Sen) writes:
>Dear Friends,
>
>	In all the discussion on TCP's behavior on net unreachable messages,
>I find nobody asked the natural question that should TCP care about ICMP  
>in the first place ?
>
>	TCP is a "layer" above IP and its interaction with IP should
>be via the well known procedure calls. 

Poppycock!  A proper stack uses knowledge obtained from all sources
to provide optimal services.  Layering allows us to analyze and talk
about the protocols in ISOlation, but there are many references from
the masters reminding us that this separation is conceptual and little
more.

Here's a passage from RFC 1122, Requirements for Internet Hosts,
Communication Layers.
         4.2.3.9  ICMP Messages

            TCP MUST act on an ICMP error message passed up from the IP
            layer, directing it to the connection that created the
            error.

BTW, your comment of well known procedure calls is an implementation
issue.  Check out the RFCs, they describe protocols and leave the
implementation up to the implementor.

>	Am I missing something ? 

Get a bunch of RFCs and work from there, don't assume sales literature
or a book will give you a very clear picture of how it really works,
especially the books by people who haven't done the work!

Erick

-- 
Networking is the concept of having data, finding it somewhere else and 
thinking that it's a good thing.  A distributed environment just means 
you are less picky about where it ends up before calling the whole 
process a success.  Plumbers call it a leak.

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1993 15:57:52 GMT
From:      cs_e404@dcs.king.ac.uk (Sean Batten)
To:        comp.protocols.tcp-ip
Subject:   TELNET help

I need information of how to implement a TELNET program in C under MSDOS. In particular I need to know how
to connect to a remote server, how to send keystrokes and how to receive output.

Regards,

	Sean Batten




-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Mar 93 16:13:29 GMT
From:      agulbra@flipper.pvv.unit.no (Arnt Gulbrandsen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP, retry timer, RF extension

In article <1993Feb26.230427.18246@sics.se> craig@sics.se (Craig Partridge) writes:
>> NCSA PING ---ethernet--- Karn RF Gateway---RF link--- Karn Remote Host
>>  
>> NCSA FTP FLOODED the rf channel with connect requests.
>
>Try doing an FTP across the wire -- you'll see an initial load of packets
>as the round-trip time estimator adapts, then all should be fine.

But don't use NCSA FTP, it has some retry bugs.  The people here who
used it to FTP across on an ethernet - 64kbps - ethernet route were,
ahem, told to stop a while ago.  Up to 99% packet loss and so many
retries tha the first router choked.

--Arnt

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Mar 93 16:30:31 GMT
From:      agulbra@flipper.pvv.unit.no (Arnt Gulbrandsen)
To:        comp.protocols.tcp-ip
Subject:   Re: name resolution mystery

In article <1msaahINN553@shelley.u.washington.edu> vicka@wrq.com (the Littlest Orc) writes:
>To summarize: Machines out there on the net can't resolve names in this
>domain to addresses, but given the addresses, they are apparently able to
>find out the names.

Which means that there is a name server for domain
215.150.in-addr.arpa., but none for wrq.com.  It's no worse than that.

--Arnt


-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Mar 1993 16:38:55 GMT
From:      evans@tsd.arlut.utexas.edu (Eric Evans)
To:        comp.protocols.tcp-ip
Subject:   Zombie UDP ports?

I have a program that uses a UDP port for both sending and receiving.  It 
uses the TLI library instead of sockets.  This program crashes frequently,
which is another problem (I think).  The strange thing is that after the 
program crashes and is gone, the UDP port that it was bound to (via t_bind) 
remains unavailable for other processes to bind to.  "netstat -a" shows the 
following entry for the zombie port, just like all the other active ports:

Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
.
.
.
udp        0      0  *.3200                 *.*                   
.
.
.

where 3200 is the port number (we've gone through several).  It seems that 
the kernel doesn't properly clean up all of the resources that were 
allocated to the ill-fated process.

After a while, anywhere up to 15 minutes or so, the port becomes available 
again.  We're not certain exactly when or why this happens.

Does anyone have a clue about this behavior? 

-------------------------------------------------------------------------
Eric Evans                        evans@titan.tsd.arlut.utexas.edu
Applied Research Laboratory
University of Texas at Austin



-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1993 18:42:30 GMT
From:      crawdad@fncent (Matt Crawford)
To:        comp.protocols.tcp-ip
Subject:   Re: name resolution mystery

To elaborate, the servers for COM say that hanna.cac.washington.edu
and marge.cac.washington.edu are the servers for WRQ.COM, but those
two machines have not been configured to be servers.
_________________________________________________________
Matt Crawford       crawdad@fncent.fnal.gov      Fermilab


-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Mar 1993 18:56:41 GMT
From:      sameer@atlastele.com ()
To:        comp.protocols.tcp-ip
Subject:   Duplicate IP address detection

Hi,
I would like to get information on how to find a machine that 
may have an IP address that is a duplicte of a legit machine. 
I remember some time back there was a way to force every machine
on a network to send its ethernet table to a host. I have forgotton
how and would appreciate it if someone could shed light on this.
Thanks in advance
Sameer..

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Mar 1993 19:22:49 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP NetUnreachable and TCP behaviour?

In article <C37v62.96v@watserv1.uwaterloo.ca> erick@demorgan.uwaterloo.ca (Erick Engelke) writes:
>Here's a passage from RFC 1122, Requirements for Internet Hosts,
>Communication Layers.
>         4.2.3.9  ICMP Messages
>
>            TCP MUST act on an ICMP error message passed up from the IP
>            layer, directing it to the connection that created the
>            error.

Well, this is a little misleading in the context of destination
unreachable.  Further reading of the specific recommendations reveals
that the required action for handling destination unreachable is
"[TCP] SHOULD make the information available to the application"
(RFC1122, page 104).  And, in particular, "TCP MUST NOT abort the
connection" (ibid.).  In other words, although TCP "MUST" act, in some
cases, including network and host unreachable, the required action is
quite minimal.

Still, i agree with your basic point, which i might paraphrase as "A
slavish adherence to layering is the hobgoblin of little minds."

						don provan
						donp@novell.com

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Mar 1993 21:38:00 GMT
From:      jek5036@ultb.isc.rit.edu (J.E. King)
To:        comp.protocols.tcp-ip
Subject:   FTP source code

Could somebody direct me to the latest copy of source code for ftp
server and client?  I want to implement a new feature that may gain
worldwide acceptance.

Thanks.

- Jim


-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1993 23:12:27 GMT
From:      mfitz@folio.West.Sun.COM (Mark Fitzpatrick - Systems Engineer)
To:        comp.protocols.tcp-ip
Subject:   Re: alarm() and connect() question

You're close.... you need to do a setjmp/longjmp combo to break out of the
connect().

#include <setjmp.h>

jmp_buf env;

void timedout ()
{
	longjmp (env,1);
}

(void) signal(SIGALRM, timedout);
(void) alarm(10);
if (setjmp (env) == 0) {
	if (connect(sd, (struct sockaddr *)&me, sizeof(me)) != 0){
		singal (SIGALRM, SIG_IGN);
		perror("connect");
		return 0;
	}
}
signal (SIGALRM, SIG_IGN);

If you use a smaller alarm value alarm(1) or ualarm (100000, ) you might want
to de-install (SIG_IGN) SIGALRM first thing after a successful or unsuccessful
connect because you may go back into your handler.

Mark

In article 2795@tredysvr.Tredydev.Unisys.COM, tom@tredysvr.Tredydev.Unisys.COM (Tom Albrecht) writes:
>
>I writing an application that uses sockets in SVR4.  I would like to
>timeout a connect() request after some period of time using the alarm()
>function.
>
>[code fragment begin]
>
>	(void) signal(SIGALRM, timedout);
>	(void) alarm(10);
>
>	if (connect(sd, (struct sockaddr *)&me, sizeof(me)) != 0){
>		perror("connect");
>		return 0;
>	}
>
>	(void) alarm(0);
>
>[code fragment end]
>
>It seems that once into the connect() function, the alarm signal is ignored.
>The system just times out the connect and returns ETIMEDOUT.
>
>The default value for timeout is 177 seconds.  There doesn't seem to be any
>way to adjust this on a per socket basis, hence the need to try something
>else.
>
>Is there some other way to do this?
>
>-- 
>Tom Albrecht




-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1993 23:17:25 GMT
From:      mfitz@folio.West.Sun.COM (Mark Fitzpatrick - Systems Engineer)
To:        comp.protocols.tcp-ip
Subject:   Re: Zombie UDP ports?

If you have the rpc library you can call pmap_unset() to unset a port.
I don't think the port has to be set via an RPC call to be unset by
pmap_unset().

    bool_t pmap_unset(prognum, versnum)
     u_long prognum, versnum;

          Deregisters   all   mappings   between    the    triple
          [prognum,versnum,*]  and  ports  on the local machine's
          portmap service. It is called by servers to  deregister
          themselves   with  the  local  portmap.   This  routine
          returns TRUE if it succeeds, FALSE otherwise.


In article 23314@titan.tsd.arlut.utexas.edu, evans@tsd.arlut.utexas.edu (Eric Evans) writes:
>I have a program that uses a UDP port for both sending and receiving.  It 
>uses the TLI library instead of sockets.  This program crashes frequently,
>which is another problem (I think).  The strange thing is that after the 
>program crashes and is gone, the UDP port that it was bound to (via t_bind) 
>remains unavailable for other processes to bind to.  "netstat -a" shows the 
>following entry for the zombie port, just like all the other active ports:
>
>Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
>..
>..
>..
>udp        0      0  *.3200                 *.*                   
>..
>..
>..
>
>where 3200 is the port number (we've gone through several).  It seems that 
>the kernel doesn't properly clean up all of the resources that were 
>allocated to the ill-fated process.
>
>After a while, anywhere up to 15 minutes or so, the port becomes available 
>again.  We're not certain exactly when or why this happens.
>
>Does anyone have a clue about this behavior? 
>
>-------------------------------------------------------------------------
>Eric Evans                        evans@titan.tsd.arlut.utexas.edu
>Applied Research Laboratory
>University of Texas at Austin





-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Mar 1993 05:12:45 GMT
From:      kpeckyin@trantor.dso.gov.sg (Kee Peck Yin)
To:        comp.protocols.tcp-ip
Subject:   remote access of ka9q NOS

Anyone know how to set up the remote access of KA9Q NOS?
On the server end, I started the remote using the start command.
On the client end, I issue the remote command. However, there is
no response. How do I set up the port number and password that 
are need for the remote access??

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Mar 1993 07:53:30 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP, retry timer, RF extension

In article <930301164650@cream.ftp.com> jbvb@ftp.com writes:
>Dave and I have been over this before, both privately and in other forums.

I was probably taking a powder, since this is new to me.

>This is great, if you're using the medium to transport packets from
>lightweight protocols (which typically don't have sophisticated retransmit
>timers) - otherwise they'd fail due to excess packet loss.  However, if you
>have a sophisticated retransmit timer, the "reliable link layer" is more of
>a hindrance than a help.  The sophisticated protocol is prepared for packet
>loss, but it has great trouble dealing with round-trip-times that vary by
>a factor of 4 or more (20:1 in one "wireless LAN" scheme I'm aware of).

It strikes me that packet-by-packet variations in round trip time of 4
to 1 or even 20 to 1 are likely to become more and more common as our
internets get more and more complicated for reasons having nothing to
do with how hard a link layer is working to be reliable.  In other
words, "reliable link layers" are only the harbinger of highly
variable round trip times, so even if you could stomp them out,
something else will spring up shortly with the same characteristics.
Besides, we all know that TCP's performance drops like a rock as the
link layers become less and less reliable, so i suspect these
reliability efforts are a net gain for the transfer rates.

What i'm saying is that perhaps we could focus on TCP a little more to
see if it can adapt to these links with highly variable transit times.
I'll have to leave it up to you experts since i can bearly remember
how to spell "TCP", but i'm vaguely thinking that in a connection
which appears to be very reliable, it might be prudent to focus on the
RTT spikes and average them rather than averaging all round trip
times.  Perhaps the variation in RTT could be used to calculate the
number to multiply the current average RTT by to get the
retransmission time.  In other words, observe the actual slop in order
to determine how much slop to build into the retransmission time.

Apologies if this has all been hashed through before.  Now that i've
written it, i get the feeling i've already seen it in print somewhere...

						don provan
						donp@novell.com

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 93 13:18:00 EDT
From:      bamon@ocvaxc.cc.oberlin.edu
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   TWG TCP/IP, MAC to VAX delay problem

Hi,

We're using Wollongong's TCP/IP on VAX/VMS machines and MacTCP on Apple
Macintoshes running system 7. (I hope I said that right. I'm new to all
of this.)

We notice a substantial delay/pause in the communications between the 
Macs and the Vaxes. The screen paints some data and stops for a second
or two, then continues again, etc.

Apple says it's Wollongong's problem. Wollongong says it's Apple's problem.

Wollongong sent us a patch to fix the problem. There was no noticeable
difference after the installation of the patch. Supposedly, we're the only
people to have reported such a problem.

I just want to know if anyone else out there has seen such a delay, etc.

Thanks,
_____________________________________________________________________
Jennifer R. Amon            PHONE: (216) 775-6987   
Houck Computing Center        FAX: (216) 775-8573    
Oberlin College          
Oberlin, OH 44074        INTERNET: bamon@ocvaxc.cc.oberlin.edu
_____________________________________________________________________


-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Mar 1993 13:08:11 GMT
From:      evansmp@uhura.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP NetUnreachable and TCP behaviour?

don provan (donp@novell.com) wrote:
: In article <C37v62.96v@watserv1.uwaterloo.ca> erick@demorgan.uwaterloo.ca (Erick Engelke) writes:
: >Here's a passage from RFC 1122, Requirements for Internet Hosts,
: >Communication Layers.
: >         4.2.3.9  ICMP Messages
: >
: >            TCP MUST act on an ICMP error message passed up from the IP
: >            layer, directing it to the connection that created the
: >            error.
: 
: Well, this is a little misleading in the context of destination
: unreachable.  Further reading of the specific recommendations reveals
: that the required action for handling destination unreachable is
: "[TCP] SHOULD make the information available to the application"
: (RFC1122, page 104).  And, in particular, "TCP MUST NOT abort the
: connection" (ibid.).  In other words, although TCP "MUST" act, in some
: cases, including network and host unreachable, the required action is
: quite minimal.

The obvious action is to treat as a source quench. i.e. send less and
smaller packets, less frequently. Untill the other end says it is
OK.

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

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Mar 1993 15:02:44 GMT
From:      erick@demorgan.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: TELNET help

 hart@flash.pax.tpa.com.au (Leigh M Hart) writes:
>cs_e404@dcs.king.ac.uk (Sean Batten) writes:
>
>>I need information of how to implement a TELNET program in C under MSDOS.
>>In particular I need to know how to connect to a remote server, how to
>>send keystrokes and how to receive output. 

Basically, how to do TELNET...

>I had a similar task to perform a few years ago.  Firstly, you need to find
>a reliable TCP/IP library for your C compiler.  I used Turbo C and found
>WATTCP to be the best for the task.
>
>Secondly, you have to understand that telnet is not just a simple "lets
>send a character or two and wait for something to come back" protocol.
>
>I suggest you get the RFC (Request for Comments) documentation on TELNET
>(ftp'able from nic.ddn.mil in /rfc - there is an index file).

A few years ago I wrote a simple INT14 redirector which provided
TELNET to programs like Kermit, and it lets you send a byte and receive
a byte like comm programs expect.  This was just after I had written
WATTCP and it was mostly a fun exercise, but Joe Doupnik picked it
up and really enhanced the TELNET portion and then put it into MS-Kermit.

There are some labourious parts:
>TELNET connections involve a lot of protocol negotiations, eg: will this
>(my end) do the local echoing of characters? will I operate in line or
>character mode? etc.  it's a bit of a nightmare when you first look at it,
>but a simple state table will sort out the negotiation part of it.

We gleened much of the logic from Frank DaCruz's C-Kermit but simplified
it to work in a PC's tsr.

So pick up msntel.c (or something like that) from the kermit distribution.
Watsun.cc.columbia.edu is a good start.  And get WATTCP from 
sunee.uwaterloo.ca in pub/wattcp/wattcp.zip

And try to piece them together.  (Take a look at TCPPORT.C for ideas)

Erick

>
>The rest is sockets.
>
>Leigh
>
>-- 
>Leigh M Hart                     _-_|\
>C/- PO Box 758                  /     \               hart@flash.pax.tpa.com.au
>North Adelaide 5006             \_.-* /
>AUSTRALIA                            v                     Work: +61-8-267-5966


-- 
Networking is the concept of having data, finding it somewhere else and 
thinking that it's a good thing.  A distributed environment just means 
you are less picky about where it ends up before calling the whole 
process a success.  Plumbers call it a leak.

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Mar 1993 15:15:31 GMT
From:      dcarr@gandalf.ca (Dave Carr)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP, retry timer, RF extension

In <930301164650@cream.ftp.com> jbvb@vax.ftp.com  (James B. VanBokkelen) writes:

>Dave and I have been over this before, both privately and in other forums.
 
>The issue at the bottom is "reliable link layers".  Some people decide that
>they need to implement protocols at/below the MAC layer which *guarantee*
>that a packet sent into their medium is ultimately delivered to the exit
>point, eventually.
 
>This is great, if you're using the medium to transport packets from
>lightweight protocols (which typically don't have sophisticated retransmit
>timers) - otherwise they'd fail due to excess packet loss.  However, if you
>have a sophisticated retransmit timer, the "reliable link layer" is more of
>a hindrance than a help.  The sophisticated protocol is prepared for packet
>loss, but it has great trouble dealing with round-trip-times that vary by
>a factor of 4 or more (20:1 in one "wireless LAN" scheme I'm aware of).

I fail to see the connection between a reliable link layer and this problem.
The fact is, all my testing was performed on an error-free link with no
retranmissions at the link layer.  If fact, the reliable link layer allows
us to run compression, and reduce the delay, almost to the point where your
FTP stops retranmitting.  I believe your problem is just the upper range of
the retransmit timer, not the algorithm.
-- 
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. 

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Mar 1993 15:34:50 GMT
From:      Hendrik.Klompmaker@beheer.zod.wau.nl (Hendrik Klompmaker)
To:        comp.protocols.tcp-ip
Subject:   3c509 version 10.1 packet driver problem in fast pc's

Hi all,

I've been using Russ Nelson's packetdriver for the 3c509 (ETHERLINK III) 
since the first beta and thought now the Alpha release is out (10.1) all 
problems would be gone. Well most of them are but still some remain. I would 
like some help from you out there because I don't know anymore.
I have a 486 DX2 50Mhz ISA clone machine that misses his 3c509 5 out of 10 
times when the packet driver is loaded. It complains about no 3c509 card 
found and suggest to use a different id_port value. 
The bus speed was configured as bus/4 (what would be 6.25 Mhz). I modified 
the setup to bus/3 (what would be 8.33Mhz) and since then the card is found 
more often (8 out of 10 times).
Can anybody out there tell me whats the relation between bus speeds and the 
3c509 and its packet driver. I would asume the a lower bus speeds would be 
more reliable then higher ones but the opposite seems to be true.

BTW. I didn't load the driver high and used Io port 300, Irq 5 and packet  
     driver int 7f.


Bye

Hendrik.

===============================================================================
|******** Wageningen Agricultural University. Animal Production Group ********|
-------------------------------------------------------------------------------
Hendrik Klompmaker		Internet : Hendrik.Klompmaker@Beheer.Zod.Wau.Nl
System Manager			Bitnet	 : KLOMPMAKER@HWALHW50.BITNET
Phone : +31 (0)8370-83934	Fax	 : +31 (0)8370-83962
Snail : Marijkeweg 40, 6709 PG	WAGENINGEN, The Netherlands
===============================================================================

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Mar 1993 16:03:11 GMT
From:      harker@harker.com (Robert Harker)
To:        ba.seminars,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Class: Building a TCP/IP Wide Area Network, UCSC Extension

		   Building a TCP/IP Wide Area Network
		**** Monday & Tuesday March 8 & 9 ****

X418.2 Computer and Information Sciences (1)

Connecting groups of Local Area Networks (LAN) into campus Metropolitan Area
Networks (MAN) or global Wide Area Networks (WAN) allow users in one part of
an organization to share information and files with users in another part of
the organization. The TCP/IP protocol suite was designed to handle the
inter-connection of LANs into a Wide Area Internet. The issues involved in
connecting groups of LANs together are different than the issues of connecting
computers to a LAN. Issues of routers, reliability, performance, and network
security become important.

This course was designed for the MIS professional or UNIX system administrator
who want to understand the technologies used in building a Wide Area Network
(WAN) using TCP/IP routers, dial-up phone lines, and leased lines. The cisco
router is used to explain how to configure and install a dedicated router.
Building a Metropolitan Area Network (MAN) by connecting small Ethernet LANs
using a fiber optic FDDI backbone is covered. Connecting a corporate WAN to
the world wide Internet is explained. Network security implications and how to
build a firewall router is covered.

Topics covered include:
	TCP/IP protocols used with WANs
		Point to Point Protocol (PPP)
		Exterior Gateway Protocol (EGP)
		Boarder Gateway Protocol (BGP)
		Open Shortest Path First (OPSF)
	Leased line circuits types and services
		Analog 9.6 Kb and 56 Kb
		Digital 56 Kb and fractional T1
		T1, T3, DS-1, and DS-4
		SONET, Frame Relay, SMDS
	FDDI
	Understanding TCP/IP routers
	Building a campus network using FDDI
	Building a WAN using leased lines
	Building a WAN using dial-up phone lined lines
	Connecting to the Internet
	Building a firewall router
	WAN network security
	Working with your long distance service provider

Prerequisites: "The TCP/IP Protocol Suite, X410.5". Attendees should have a
working knowledge of UNIX system administration and managing TCP/IP networks
or should have taken the "Managing a UNIX TCP/IP Network, X410.6" class

Suggested texts: Internetworking, A Guide to Network Communications by Mark A.
Miller, published by M&T Books and Internetworking with TCP/IP, Volume I by
Dr. Douglas Comer, published by Prentice Hall. These books are available at
the Computer Literacy Bookstore in San Jose


Fee:  $325.  Enrollment limited.
EDP number: 923D21
Time and dates: Monday & Tuesday March 8 & 9, 9 a.m. to 5 p.m.
Location: UC Extension, 3120 De la Cruz Blvd (Trimble @ 101).

To enroll --

You may enroll by telephone or FAX using your Visa or MasterCard.
Call 1-800-660-UNEX (8639) or (408) 427-6608, Monday-Friday,
8 a.m.-5 p.m.  You may also register at the class.



The "Building a UNIX TCP/IP Wide Area Network" course is part of a series of
five two-day classes is designed for the MIS professional or UNIX system
administrator who wishes to install, configure, and debug Ethernet TCP/ IP
networks.  This series of classes provide a through grounding in the concepts
behind installing and managing a TCP/IP network, as well as practical
suggestions and pitfalls of managing TCP/IP networks

Each course covers a different area of UNIX TCP/IP networking:

"Ethernet Local Area Networks" covers the physical wiring of the network,
Ethernet data packets, Ethernet addressing, and Ethernet debugging
Two Saturdays, April 17 & 24, Fee: $325, EDP number: 924D23

"The TCP/IP Protocol Suite" covers routing protocols, the TCP and UDP
protocols, Berkeley sockets, connecting a UNIX workstation to the network, and
the common user network applications, Telnet. FTP, rlogin, rsh, and rcp.
Two Saturdays, May 8 & 15, Fee: $325, EDP number: 924D24

"Network File System (NFS) and Network Information Service (NIS)" covers the 
Sun Network File System including setting up and managing NFS and NIS, the 
automounter, PC NFS, and NFS debugging.
Two Saturdays, March 6 & 13, Fee: $325, EDP number: 923D20

"Managing a UNIX TCP/IP Network" covers the issues and responsibilities of 
managing a UNIX TCP/IP network. The Simple Network Management Protocol 
(SNMP) and the domain naming system (named) are covered.
Two Saturdays, Summer 93, Fee: $325

"Building a TCP/IP Wide Area Network" covers technologies for building a Wide
Area Network (WAN) using TCP/IP routers, dial-up phone lines, and leased
lines.  Building a Metropolitan Area Network (MAN) by connecting small
Ethernet LANs using a fiber optic FDDI backbone is also covered.
Monday & Tuesday March 8 & 9, Fee:  $325, EDP number: 923D21

While these seminars are designed as a series to give a thorough understanding
of TCP/IP networking, it is not necessary to enroll in the whole series. With
the proper prerequisites, students are free to pick and choose any of the
seminars to meet their particular needs on the subject.


Instructor: Robert Harker is a consultant specializing in networking and
system administration issues with large networks of Sun workstations. Mr.
Harker has 7 years of networking and system administration with Sun
workstation and was involved the initial introduction of NFS and the first
show wide TCP/IP network at Uniforum, 1985. Mr. Harker was formerly with
National Semiconductor where he designed and implemented a network of 100 Sun
workstations.


-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Mar 1993 19:28:48 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP NetUnreachable and TCP behaviour?

In article <1993Mar2.130811.6909@aston.ac.uk> evansmp@uhura.aston.ac.uk (Mark Evans) writes:
>The obvious action is to treat [host or net unreachable] as a source
>quench. i.e. send less and smaller packets, less frequently. Untill
>the other end says it is OK.

I suppose you could do that, but since the packet stream is now being
dropped, you'll be into retransmission mode soon enough anyway which
will have about the same effect.
						don provan
						donp@novell.com

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Mar 1993 20:39:06 GMT
From:      bradley@mdd.comm.mot.com (Michael Bradley)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP, retry timer, RF extension

In article <930301164650@cream.ftp.com> jbvb@ftp.com writes:
[Discussion deleted]
>Dave and I have been over this before, both privately and in other forums.
>
>The issue at the bottom is "reliable link layers".  Some people decide that
>they need to implement protocols at/below the MAC layer which *guarantee*
>that a packet sent into their medium is ultimately delivered to the exit
>point, eventually.
>
>This is great, if you're using the medium to transport packets from
>lightweight protocols (which typically don't have sophisticated retransmit
>timers) - otherwise they'd fail due to excess packet loss.  However, if you
>have a sophisticated retransmit timer, the "reliable link layer" is more of
>a hindrance than a help.  The sophisticated protocol is prepared for packet
>loss, but it has great trouble dealing with round-trip-times that vary by
>a factor of 4 or more (20:1 in one "wireless LAN" scheme I'm aware of).
>

The other issue with link layer reliability is that often they are
accompanied by a stop and wait protocol rendering TCP's flow and 
congestion control strategies somewhat moot. 

>Slow-start helps, but only for bulk data transfers.  Byte-count sensitive
>rate calculations help, too, where the time to send a packet and its

Does PC/TCP support this?

>likelihood of encountering an error are greatly affected by its length.
>However, I don't know how to solve the whole problem, so it looks to me
>like "reliable link layer" isn't as useful in catenets as some people think.
>
>James B. VanBokkelen		2 High St., North Andover, MA  01845
>FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488
>



-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Mar 1993 22:41:28 GMT
From:      junki@lut.fi (Juha Nurmela)
To:        comp.protocols.tcp-ip,comp.periphs
Subject:   Re: Terminal Servers

In article <id.ZEZX.PSG@ferranti.com>, peter@ferranti.com (Peter da Silva) writes:
|> A friend of mine has just about given up on getting a new comm card to
|> work in his PC under Unix, and wants to buy a terminal server. Can anyone
|> recommend a good 16-port box for a reasonable price (probably O($1000))?
|> -- 
|> Peter da Silva                                            `-_-'
|> Ferranti International Controls Corporation                'U` 
|> Sugar Land, TX  77487-5012 USA
|> +1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"

16 ports ? How about 8 usual com-cards sharing irq's 2,3,4,10,11 and/or 15,
such cards that can be jumpered to various locations (0x220 etc).
Might be a lot cheaper ?

-- 
         juha nurmela, Adr. 54430 Hujakkala, Finland. Tel. 953 78022
                  eiku: skinnarilank. 28d10, Tel. 953 26292

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Mar 1993 01:35:26 GMT
From:      shmuel@mapsut.einstein.com (Shmuel Einstein)
To:        comp.protocols.tcp-ip
Subject:   NCSA ftp performance problems

I recently connected two pc's on an ether net and attempted to transfer
files between them.  Both were fast machines, and the net was pretty quiet.
Both had identical versions of NCSA telnet, gotten in its latest version
recently from U of Illinois.  I ran telnet on one machine to start the server,
but did not log into any other host.  Then i ran ftp on the other pc to login
to the server'ed pc.

Once the connection was established, I started transferring files, but they
went extremely slowly, at the rate of about 512 bytes every second.  I watched
the activity lights on the ethernet boards, and, in fact, one 512 byte buffer
was being sent every second.

Can anyone help me?  Please send email.  Thanks in advance.



-- 
Shmuel Einstein, shmuel@einstein.com
Shmuel Einstein & Associates, Inc.
9100 Wilshire Blvd, Suite 235 E
Beverly Hills, CA  90212
310/273-8971 FAX 310/273-8872

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1993 15:57:28 +1030
From:      hart@flash.pax.tpa.com.au (Leigh M Hart)
To:        comp.protocols.tcp-ip
Subject:   Re: TELNET help

cs_e404@dcs.king.ac.uk (Sean Batten) writes:

>I need information of how to implement a TELNET program in C under MSDOS.
>In particular I need to know how to connect to a remote server, how to
>send keystrokes and how to receive output. 

Sean,

I had a similar task to perform a few years ago.  Firstly, you need to find
a reliable TCP/IP library for your C compiler.  I used Turbo C and found
WATTCP to be the best for the task.

Secondly, you have to understand that telnet is not just a simple "lets
send a character or two and wait for something to come back" protocol.

I suggest you get the RFC (Request for Comments) documentation on TELNET
(ftp'able from nic.ddn.mil in /rfc - there is an index file).

TELNET connections involve a lot of protocol negotiations, eg: will this
(my end) do the local echoing of characters? will I operate in line or
character mode? etc.  it's a bit of a nightmare when you first look at it,
but a simple state table will sort out the negotiation part of it.

The rest is sockets.

Leigh

-- 
Leigh M Hart                     _-_|\
C/- PO Box 758                  /     \               hart@flash.pax.tpa.com.au
North Adelaide 5006             \_.-* /
AUSTRALIA                            v                     Work: +61-8-267-5966

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 1993 11:30:27 +0100
From:      szymon@galaxy.uci.agh.edu.pl (Szymon Sokol)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over packet radio

Could some point me to a solution for running TCP/IP over packet radio
*without* KA9Q? Yes, I know that KA9Q is a good solution, written with
ham-radio in mind, but it needs a dedicated PC. I want to establish 
a radio network with a Sun running as a (non-dedicated) gateway to "normal"
(i.e. Ethernet)  IP network. I assume I need a special driver for the serial
port in the Sun, but is it available anywhere?
-- 
U     U  M     M  M     M  Szymon Sokol -- Network Manager
U     U  MM   MM  MM   MM  University of Mining and Metallurgy, Computer Center
U     U  M M M M  M M M M  ave. Mickiewicza 30, 30-059 Krakow, POLAND
 UUUUU   M  M  M  M  M  M  TEL. +48 12 338100 EXT. 2885    FAX +48 12 338907

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 93 13:26:49 GMT
From:      jrz0@roger.gte.com (John Zavgren)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP, retry timer, RF extension

In article <1993Mar2.075330.18221@novell.com>, donp@novell.com (don provan) writes:
|> In article <930301164650@cream.ftp.com> jbvb@ftp.com writes:
|> >Dave and I have been over this before, both privately and in other forums.
|> 
|> I was probably taking a powder, since this is new to me.
|> 
|> >This is great, if you're using the medium to transport packets from
|> >lightweight protocols (which typically don't have sophisticated retransmit
|> >timers) - otherwise they'd fail due to excess packet loss.  However, if you
|> >have a sophisticated retransmit timer, the "reliable link layer" is more of
|> >a hindrance than a help.  The sophisticated protocol is prepared for packet
|> >loss, but it has great trouble dealing with round-trip-times that vary by
|> >a factor of 4 or more (20:1 in one "wireless LAN" scheme I'm aware of).
|> 
|> It strikes me that packet-by-packet variations in round trip time of 4
|> to 1 or even 20 to 1 are likely to become more and more common as our
|> internets get more and more complicated for reasons having nothing to
|> do with how hard a link layer is working to be reliable.  In other
|> words, "reliable link layers" are only the harbinger of highly
|> variable round trip times, so even if you could stomp them out,
|> something else will spring up shortly with the same characteristics.
|> Besides, we all know that TCP's performance drops like a rock as the
|> link layers become less and less reliable, so i suspect these
|> reliability efforts are a net gain for the transfer rates.
One reason the throughput can "drop like a rock" is the retransmission timer
granularity used by many implementations is very large, e.g., a half second
(allegedly, because the code executes faster when packets are not being dropped).
In these cases, even if the retransmission timer were estimated accurately, it
could be rounded up to a ridiculously large number which results in a very large
error recovery time, i.e., throughput goes down dramatically with moderate packet
dropping rates. The effect is quite noticeable when two more more hosts write
data to one host on an FDDI ring and the combined streams generate a flux that
can exhaust the buffers in the destination host adapter. In this case you'd
want a timer granularity of about a millisecond or less. Perhaps this is an
argument for moving transport layer functions from host software to a specialized
board that drives the datalink?
|> 
|> What i'm saying is that perhaps we could focus on TCP a little more to
|> see if it can adapt to these links with highly variable transit times.
|> I'll have to leave it up to you experts since i can bearly remember
|> how to spell "TCP", but i'm vaguely thinking that in a connection
|> which appears to be very reliable, it might be prudent to focus on the
|> RTT spikes and average them rather than averaging all round trip
|> times.  Perhaps the variation in RTT could be used to calculate the
|> number to multiply the current average RTT by to get the
|> retransmission time.  In other words, observe the actual slop in order
|> to determine how much slop to build into the retransmission time.
|> 
|> Apologies if this has all been hashed through before.  Now that i've
|> written it, i get the feeling i've already seen it in print somewhere...
|> 
|> 						don provan
|> 						donp@novell.com

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Mar 1993 14:18:40 GMT
From:      peter@ferranti.com (peter da silva)
To:        comp.protocols.tcp-ip,comp.periphs
Subject:   Re: Terminal Servers

In article <C3A9p4.B74@lut.fi> junki@lut.fi (Juha Nurmela) writes:
> 16 ports ? How about 8 usual com-cards sharing irq's 2,3,4,10,11 and/or 15,
> such cards that can be jumpered to various locations (0x220 etc).
> Might be a lot cheaper ?

Right. He's going to run a commercial BBS system off a bunch of hand-
hacked cheapo com ports. Even with 16550s, they're going to be a dog.
I wouldn't even do that on my own system, and it's just for hobbies.
Plus, where do you get the extra 8 slots? Let's see:

	8 dumb cards with 16550s at $50 each		 $400
	New motherboard with an extra 8 slots		$1000

You can get an 8-port terminal server for $800, so for certain you're
only saving $200 over a terminal server, and nothing at all over, say,
a Digiboard.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 93 17:12:07 GMT
From:      SYSNET@engvax.picker.com (Leonard A. Visconti)
To:        comp.protocols.tcp-ip
Subject:   Ip Addressing Question

A sister company of ours is looking to get an internet address and has been
told, as I understand, that it can only get a class C address. They are 
planning on having more nodes than can be supported by class C. I am thinking
about suggesting they submit for an offical class C address and use it for 
their gateway and firewall systems --- any system that links to the outside.
Internally, they can pick their own ip address and keep it isolated from the 
outside. I'm looking for potential problems. or a more viable solution.  
Thank you.

-------------------------------------------------------------------------------
|  Leonard A. Visconti 			Picker International                  |
|  Network Analyst			595 Miner Road			      |
|  visconti@picker.com			Highland Heights, Ohio  44143         |
|					(216)473-4801                         |
 -------------------------------------------------------------------------------

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Mar 1993 17:25:16 GMT
From:      anders@spip.cc.uit.no (Anders Baardsgaard)
To:        comp.protocols.tcp-ip
Subject:   Re: IP address locator

In article <1993Feb23.193405.12528@mis.mi04.zds.com>, rmorley@mis.mi04.zds.com (Ron Morley) writes:
|> Does anyone know of a tool that will allow me to find out what IP addresses
|> exist on our network?

Do you have routers on your network? And do they "speak" SNMP?
If so, let your router(s) do the work, and download their ARP
caches at regular intervals...

#!/usr/local/bin/perl
#
# .1.3.6.1.2.1.4.22.1.2 is (rfc 1213)
# iso.org.dod.internet.mgmt.mib-2.ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaPhysAddress
#
foreach $Router ("router1","router2") {
  open(F,"/usr/local/bin/snmpwalk $Router public .1.3.6.1.2.1.4.22.1.2 |");
    while (<F>) {
      chop;
      if (/ipNetToMediaPhysAddress/) {
        ($name,$ip,$ipNTMT,$ipNTME,$ipNTMPA,$one,$IPAddress)=split(/\./,$_,7);
      } elsif (/OCTET STRING/) {
        ($octet,$string,$hex,$MACAddress)=split(/[ \t\n]+/,$_,4);
        $MACAddress =~ tr/A-F/a-f/;
        $MACAddress =~ tr/ /:/;
        write;
      }
    }
 close(F);
}
#
format STDOUT =
@<<<<<<<<<<<<<< @<<<<<<<<<<<<<<<<
$IPAddress,$MACAddress
.
###

I use snmpwalk from the CMU SNMP distribution, available from
ugle.unit.no (and CMU, of course ;-)  I run this via cron every
couple of hours, and merge the results.

|> Also, I know that some of our users have "black" IP    
|> addresses that they have assigned themselves.  I would like to be able to
|> find them so that I can give them legitimate addresses.

How are you going to solve the problem: given a "black" IP
address and the corresponding ethernet address, track down the
box that uses it? :-)


-- 
Anders Baardsgaard         # anders@cc.uit.no
University Computer Center # C=no;ADMD= ;PRMD=uninett;O=uit;OU=cc;S=anders
N-9037 Tromso              # +47-83-44105
NORWAY                     # +47-83-44100 (fax)

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 93 15:46:06 +0100
From:      weis@mvax.uakom.cs
To:        comp.protocols.tcp-ip
Subject:   *** How Ethernet card works ? ***

Hi,
Can anyone tell me please how does Ethernet card work and how packets are
processed there? I would appreciate some hints on handbook as well(anonymous
ftp servers). Many thanks.

Regards

Tibor


-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 1993 18:26:12 GMT
From:      southbay@garnet.berkeley.edu ()
To:        comp.sys.novell,comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Berkeley Short Courses on Internetworking Technology

U.C. Berkeley
Continuing Education in Engineering
Announces 2 Short Courses on
Internetworking Technology and Management


INTERNETWORK TECHNOLOGY
(April 13-14, 1993)

This 1 1/2 day course unravels the mystery of bridges and routers
and explains the operation of internetworking devices from a
technology perspective.  Practical problems in interconnecting
dissimilar systems and compatibility problems encountered with
widely used protocols and applications are discussed and
demonstrated in real-world situations.

Lecturer: Rich Seifert, M.S.E.E., M.B.A, president, Networks
and Communications Consulting.  Seifert was responsible for the
design and specification of the Ethernet physical layer and Token
Bus Factory LAN products.  He is co-author of the IEEE 802.1,
802.3, and 802.4 standards.

INTERNETWORK MANAGEMENT
(April 14-15, 1993)

This  1 1/2 day course provides an understanding of major
internetworking hardware and software for local and wide area
communication as well as useful information on network
management architectures, protocol, and interoperation.

Lecturer:  Victoria Marney-Petix, M.S. is a consultant with
Marpet Technical Services.  Marney-Petix is the author of
"Client/Server Computing'" "Network and Data Communications,"
and "Mastering Internetworking."


PLEASE NOTE:  Courses are scheduled so that both can be taken
during the three day period: April 13-15.


For more information (complete course descriptions, outlines,
instructor
bios,
etc.) contact:

Harvey Stern
U.C. Berkeley Extension/Southbay
800 El Camino Real Ste. 150
Menlo Park, CA 94025
Tel: (415) 323-8141
Fax: (415) 323-1438

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Mar 1993 21:05:02 GMT
From:      dave@netmgr.mmc.com (David A. Rageth)
To:        comp.protocols.tcp-ip
Subject:   netmasking and HP workstations

We have a class B address we are looking at subnetting with a mask of
255.255.255.128 to get 500+ subnet numbers.  When we set the netmask
value on many other workstations (Sun, Dec, mac, etc.) the machines
are able to function quite well on the network and communicate through
routers to other hosts without a glitch.  However, when we use this netmask
on an HP workstation and the network happens to be on the low end of the
range, e.g. 160.205.2.0, 160.205.3.0, 160.205.4.0, ... the HP does not
function.  If, however, I place this workstation on the high end of the
next network, e.g. 160.205.2.128, 160.205.3.128, ..., the HP will work.
I have a suspicion that the HP thinks that a network of 160.205.2.0 is
the zero network for 160.205.2.128 with a mask of 255.255.255.128.

Can anyone shed some light on this or has anyone seen this and solved
the problem?

Thanks.


-- 
x++++++++++++++++++++++++++++++++++++++++x
 x            David Rageth                x
  x   Internet : dave@netmgr.mmc.com       x
   x   voice    : (303)977-4584             x
    x   fax      : (303) 977-2765            x
     x   USMail   : Martin Marietta           x
      x              P.O. Box 179 m/s 1084     x
       x              Denver, Colorado          x
        x                               80201    x
         x++++++++++++++++++++++++++++++++++++++++x


-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Mar 1993 21:38:30 GMT
From:      agiraud@hpgnux65.grenoble.hp.com (Armand Giraud)
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate IP address detection

AHello
try with snmp and mib II

Armand

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 93 21:59:55 GMT
From:      jbvb@vax.ftp.com (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP, retry timer, RF extension

In article <1993Mar2.075330.18221@novell.com> donp@novell.com (don provan) writes:

    I'll have to leave it up to you experts since i can bearly remember
    how to spell "TCP", but i'm vaguely thinking that in a connection
    which appears to be very reliable, it might be prudent to focus on the
    RTT spikes and average them rather than averaging all round trip
    times.  Perhaps the variation in RTT could be used to calculate the
    number to multiply the current average RTT by to get the
    retransmission time.  In other words, observe the actual slop in order
    to determine how much slop to build into the retransmission time.

This sounds like a good direction to pursue.  If you're right about a
trend towards reliable link layer, the worst period is going to be when
half of the world is reliable (and equipped with routers with tremendous
tolerance for congestion), and half isn't.  This gives you packet loss
combined with enormous dynamic range in the RTT, which is going to kill
throughput one way or another.  I still think that reliable link-layer
might be a dead-end, because that's more or less the same problem X.25
tried to solve, and it appears that economics work against the kind of
system-wide overcapacity necessary to eliminate RESETs.

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

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 93 22:31:12 GMT
From:      kate@wavefront.wti.com (Kathy Samec)
To:        comp.protocols.tcp-ip
Subject:   Nameserver question

Newsgroups: comp.protocols.tcp-ip.domains
Subject: Addendum to "What the $#@! am I doing wrong?"
Summary: 
Followup-To: 
Distribution: usa
Organization: Wavefront Technologies Inc, Santa Barbara, CA
Keywords: 

background: I know about root servers and named.root and I have the 
stuff working in house.
Problem: I can't get information beyond my LAN about other hosts:

Diagram:
                           198.17.17.0
-------------------------------------------------------------
      |                 |              |
   Nameserver        Router          RS6000
    Sun 4.1.1         Cisco
    sbst.com            |
                        |             144.253.0.0
--------------------------------------------------------------
                                 |                |
                              Nameserver          |
                               Sun 4.1.1          |
                               wti.com            |
                                                  |
                                               Router
                                                cisco
                                                  |
                                                  <
                                                   >
-------------------------------------------------------------
                 Internet via serial to ucsb


So, with this configuration, why can't I nslookup hosts on the wti.com
net? Does it's nameserver need to know something about mine? If I set
my(sbst.com) server up to be a secondary of wti.com, I can get info
about wti hosts. That makes sense. But the RS6000 can't. I don't want
to be secondary.

Any suggestions?

-- 
*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Kathi Samec			- Everything is beautiful and
Santa Barbara Studios		  Nothing hurt.
kate@wti.com					-Stoney Stevenson

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 93 22:44:35 GMT
From:      kate@wavefront.wti.com (Kathy Samec)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Yet another question on DNS

I have the nameserver working on the sun as least as far as nslookup 
is concerned. I ask for a name and I get it's address. I ask for a name
listed in the secondary files, and I get it's address. If I try to telnet
to one of these found names, I get an invalid host error or host not found.
This is on a Sun 4.1.1. Am I nuts to think it's not supposed to be this
hard?

-- 
*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Kathi Samec			- Everything is beautiful and
Santa Barbara Studios		  Nothing hurt.
kate@wti.com					-Stoney Stevenson

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 1993 23:03:56 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Ip Addressing Question

In article <1993Mar3.171207.16047@picker.com> SYSNET@engvax.picker.com (Leonard A. Visconti) writes:
>A sister company of ours is looking to get an internet address and has been
>told, as I understand, that it can only get a class C address. They are 
>planning on having more nodes than can be supported by class C. I am thinking
>about suggesting they submit for an offical class C address and use it for 
>their gateway and firewall systems --- any system that links to the outside.
>Internally, they can pick their own ip address and keep it isolated from the 
>outside. I'm looking for potential problems. or a more viable solution.  
>Thank you.

If they use internal addresses that duplicate existing outside addresses,
then the gateway systems won't be able to communicate with those outside
addresses.  And should they ever decide to allow direct communication
between their internal machines and outside nets, rather than shoehorning
everything through gateways (do they have proxy servers for all the network
services their users will need?), the address duplication will be a real
problem.

If one class C subnet isn't enough, would two suffice?  One of the
proposals for dealing with routing table explosion on the backbone networks
is "supernetting", where blocks of adjacent class C addresses are treated
as a single network for backbone routing purposes.  This will make it more
feasible to give several class C nets to a medium-sized organization.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Mar 1993 23:48:40 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.protocols.tcp-ip
Subject:   Re: netmasking and HP workstations

David A. Rageth (dave@netmgr.mmc.com) wrote:
> We have a class B address we are looking at subnetting with a mask of
> 255.255.255.128 to get 500+ subnet numbers.

I can't answer for the main HP systems (3000's and 9000's), but this
mask is illegal for the HP networking cards that fit into PCs.  The 128
octet has only one bit set.  Therefore, any address in this octet will
contain either all zeros or all ones in the subnet portion of the octet.
This is illegal.

Either change the subnet mask for the octet to 192 (128+64) so that you
have two bits set, or change it to zero so that the octet is not masked.

- Steve Kao

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 93 01:11:30 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP, retry timer, RF extension

In article <930303165955@cream.ftp.com> jbvb@ftp.com writes:
>In article <1993Mar2.075330.18221@novell.com> donp@novell.com (don provan) writes:
>    Perhaps the variation in RTT could be used to calculate the
>    number to multiply the current average RTT by to get the
>    retransmission time.  In other words, observe the actual slop in order
>    to determine how much slop to build into the retransmission time.
>
>This sounds like a good direction to pursue.

Mr. Partridge has pointing out privately that Mr. Jacobson's TCP
retransmission estimator does pretty much what i suggested.  (I thought
it sounded like too good to be original.)  Unfortunately, Mr. Partridge
neglected to provide the actual reference, no doubt making the
reasonable assumption that i'd be bright enough to already know it...

>If you're right about a trend towards reliable link layer...

Actually, i was suggesting a trend towards widely varying round trip
times from a number of sources in addition to varying transit times of
specific links.  I don't know anything about retransmitting link
layers, so i couldn't say if there's a trend in that direction.
If there is a trend towards reliable link layers, i'd expect error
correction, not retransmission, to be the more common approach.

						don provan
						donp@novell.com

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Mar 1993 13:38:50 GMT
From:      skaggs@nsslsun.nssl.uoknor.edu (Gary Skaggs)
To:        comp.protocols.tcp-ip
Subject:   OSPF subnet routing on a Wellfleet

I'm trying to not waste my subnet resources (two boxes on one interface)
and need to know a nuts and bolts way to configure OSPF on my Wellfleet 
router so that I can use its 'creative' subnetting.  Could someone point me
to a resource, or just give me the keystrokes for the config file?

Thanks,
Software Impaired
______________________________________________________________________________
Gary Skaggs - WB5ULK				skaggs@nssl.nssl.uoknor.edu
	"Neither my employer, The University of Oklahoma,
	 nor The National Severe Storms Laboratory, where I work,
	 know that I even have any opinion, much less this one."

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Mar 1993 14:37:20 GMT
From:      dcarr@gandalf.ca (Dave Carr)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP, retry timer, RF extension

In <930303165955@cream.ftp.com> jbvb@vax.ftp.com  (James B. VanBokkelen) writes:

>This sounds like a good direction to pursue.  If you're right about a
>trend towards reliable link layer, the worst period is going to be when
>half of the world is reliable (and equipped with routers with tremendous
>tolerance for congestion), and half isn't.  This gives you packet loss
>combined with enormous dynamic range in the RTT, which is going to kill
>throughput one way or another.  I still think that reliable link-layer
>might be a dead-end, because that's more or less the same problem X.25
>tried to solve, and it appears that economics work against the kind of
>system-wide overcapacity necessary to eliminate RESETs.

I happen to have the opposite view.  

Only when the packet actually gets queued to go over the link, well after 
congestion control is envoked, does error correction factor into the transfer.  
On current digital links, the error rate is very low.  The odds of a 
retransmission being required are almost nil.  

In the absence of transmission errors, the LAPB error corrected link is
a definite win since it is the only way IMHO of doing data compression.
Data compression is a viable method to reduce congestion.

I'm not saying that ever data link should be error-corrected, but you seem
to be blaming the wrong part of the equation.  A reliable data link should
be up to the lower layer devices to use, and the upper layers are rarely
going to notice the difference.  Perhaps the RTT isn't a perfect solution.  

-- 
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. 

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Mar 1993 15:23:19 GMT
From:      SYSNET@engvax.picker.com (Leonard A. Visconti)
To:        comp.protocols.tcp-ip
Subject:   Re: Ip Addressing Question

In <1n3dgsINNf0f@early-bird.think.com> barmar@think.com writes:

> In article <1993Mar3.171207.16047@picker.com> SYSNET@engvax.picker.com (Leonard A. Visconti) writes:
> >A sister company of ours is looking to get an internet address and has been
> >told, as I understand, that it can only get a class C address. They are 
> >planning on having more nodes than can be supported by class C. I am thinking
> >about suggesting they submit for an offical class C address and use it for 
> >their gateway and firewall systems --- any system that links to the outside.
> >Internally, they can pick their own ip address and keep it isolated from the 
> >outside. I'm looking for potential problems. or a more viable solution.  
> >Thank you.
> 
> If they use internal addresses that duplicate existing outside addresses,
> then the gateway systems won't be able to communicate with those outside
> addresses.  And should they ever decide to allow direct communication
> between their internal machines and outside nets, rather than shoehorning
> everything through gateways (do they have proxy servers for all the network
> services their users will need?), the address duplication will be a real
> problem.
> 
Yes, you're exactly right and I should have known this. I ran into this same
problem some time ago.

> If one class C subnet isn't enough, would two suffice?  One of the
> proposals for dealing with routing table explosion on the backbone networks
> is "supernetting", where blocks of adjacent class C addresses are treated
> as a single network for backbone routing purposes.  This will make it more
> feasible to give several class C nets to a medium-sized organization.
> -- 
Thanks. I will suggest they try to get a class B, but if they cannot, this is
the approach I'll suggest.

-------------------------------------------------------------------------------
|  Leonard A. Visconti 			Picker International                  |
|  Network Analyst			595 Miner Road			      |
|  visconti@picker.com			Highland Heights, Ohio  44143         |
|					(216)473-4801                         |
 -------------------------------------------------------------------------------

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Mar 1993 15:25:53 GMT
From:      rob@icarus.inmos.co.uk (Robin Pickering)
To:        comp.protocols.tcp-ip
Subject:   Re: netmasking and HP workstations

In article <C3C7H4.4xG@hpchase.rose.hp.com> k@hprnd.rose.hp.com (Steve Kao) writes:
>David A. Rageth (dave@netmgr.mmc.com) wrote:
>> We have a class B address we are looking at subnetting with a mask of
>> 255.255.255.128 to get 500+ subnet numbers.
>
>I can't answer for the main HP systems (3000's and 9000's), but this
>mask is illegal for the HP networking cards that fit into PCs.  The 128
>octet has only one bit set.  Therefore, any address in this octet will
>contain either all zeros or all ones in the subnet portion of the octet.

I don't understand, this is a class B address so the subnet field is 9
bits wide. The only restriction on the value of subnet fields contained
in the RFC's is (RFC1122):

            IP addresses are not permitted to have the value 0 or -1 for
            any of the <Host-number>, <Network-number>, or <Subnet-
            number> fields (except in the special cases listed above).
            This implies that each of these fields will be at least two
            bits long.

As the subnet field in question is 9 bits long, this should not be a problem.

>This is illegal.

It most certainly is not, see above.

It may be that HP software is broken and does not perform correctly with legal
subnet fields. Octet boundaries are completely irrelevant in subnet fields (or
should be unless your vendor sells a broken TCP/IP implementation).

--
    Rob.

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 93 17:22:02 GMT
From:      kjmiller@mitre.org (Kevin Miller)
To:        comp.protocols.tcp-ip
Subject:   ASN.1 Ada Compiler Wanted

I am looking for information on ASN.1 compilers that compile to the Ada
language, as opposed to C.  We are developing a prototype and would like to
define our message formats in ASN.1 and develop the prototype in Ada.  A
fall-back position is to use an existing C ASN.1 compiler and use or
develop a wrapper or interface to the C routines and data structures: a
messy and more difficult solution in my opinion.  Any information on
products, sources, prices, etc would be appriciated.  Thanks.

p.s. We also plan on using ISODE on top of TCP/IP and doing our development
on an SGI system with the Verdix Ada compiler.

p.p.s  Please reply via e-mail (kjmiller@mitre.org) as I don't regular read
this newsgroup.


-----------------------------------------------------
Kevin Miller       | MITRE's lawyers can't moan,    |
MITRE Corporation  | 'Cause what's stated up there, |
Bedford, MA        | Is my opinion alone,           |
(617) 271-4520     | And not MITRE's to bear.       |
kjmiller@mitre.org |                                |
-----------------------------------------------------

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Mar 1993 17:46:09 GMT
From:      erick@demorgan.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP, retry timer, RF extension

 jbvb@ftp.com writes:
> donp@novell.com (don provan) writes:
>
>    Perhaps the variation in RTT could be used to calculate the
>    number to multiply the current average RTT by to get the
>    retransmission time.  In other words, observe the actual slop in order
>    to determine how much slop to build into the retransmission time.

It should sound familiar because it's in RFC1122 4.2.3.1.  You've 
pretty much described Van Jacobson's algorithm.  The only major 
difference is the use of standard error (simpler to compute than 
std.dev./variation and generally less optimistic)

How often we kick ourselves saying, "of course, now I remember!" 
Either that or you are showing my ignorance.  The only reasonable
enhancements I have seen in RTT estimation have been algorithmic, 
not computational, maybe I've missed them.

>If you're right about a trend towards reliable link layer, 
>half of the world is reliable (and equipped with routers with tremendous
>tolerance for congestion), and half isn't.  This gives you packet loss
>combined with enormous dynamic range in the RTT, which is going to kill
>throughput one way or another.  

Here is one way it kills performance that I haven't seen 
mentioned.

These variances are probably causing retransmits from the
TCP layer, and those are effectively shutting down the 
transmit window in keeping with Van's slow start window 
algorithm.  

The net result is that your performance may vary
in relation to the RTT which is probably quite large for
this media depending on the data rate and other
characteristics, and wont have the benefit a larger
TCP window.

And there can be some confusion depending on what the 
remote peer does when it receives second copies of the 
data, etc.  Yes, I know what is supposed to happen, but
some parts of many TCP implementations are written but 
never tested simply because the situation is never found in
the lab.  I'm certainly as guilty as anyone else for that.

I'll probably be the only person who misses our 56 kbps
line when it gets upgraded this month, it was one of the
most conjested in Canada and offerred great opportunity
to test congestion ideas.

Erick

-- 
Networking is the concept of having data, finding it somewhere else and 
thinking that it's a good thing.  A distributed environment just means 
you are less picky about where it ends up before calling the whole 
process a success.  Plumbers call it a leak.

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Mar 1993 18:15:35 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet usage

Steve Kao (k@hprnd.rose.hp.com) wrote:
> Charles Ganzhorn (ccg@tcdsp1.mmm.com) wrote:
> > Is it legal to have a class B subnet which is either all 1's or 0's?
> > We have a class B network assigned our company.  Lets say it is 130.99.0.0 .
> > We use RIP and a subnet mask of 255.255.255.0.  Can we assign the subnets
> > 130.99.0 and 130.99.255?
> 
> This is illegal.  Both the "0" and "255" are illegal octets in a subnet
> address.  Note that an octet having a one-bit subnet mask is also
> illegal, and any subnet address for that octet will be either all ones
> or all zeros, both of which are illegal.

I screwed up.  The subnet mask is applied to all 32-bits of the IP
address.  It is possible to have a single bit of the subnet mask set in
any particular octet.  Sorry about that.  I apologize to the net for
displaying my ignorance.

As someone pointed out to me via e-mail, the host portion of a device's
IP address cannot be all ones or all zeros either.  Thus, 130.99.0.0 is
still illegal as the lower seven bits of the 4th octet, which is the
host portion of the address, are all zeros.

- Steve Kao

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Mar 1993 18:19:04 GMT
From:      daylan@baker.ds.boeing.com (Daylan B Darby)
To:        comp.protocols.tcp-ip
Subject:   Enet adr hash digest

I wrote:

Anyone know of studies as to which hash function to use for ethernet addresses?
What's your favorite one?  Why do you think it's better?  If there's enough
interest I'll post a digest.

Digest:

From: dcarr@donut.gandalf.ca (Dave Carr)
Depends on your processor.  If you have a fast divide, divide by a prime
number.  Otherwise, treat the address as 3 16-bit numbers XORed together.
There is a paper called "A Comparison of Hashing Schemes for Address
Lookup in Computer Networks", IEEE Transactions on Communications, Oct 92.

From ching@brahms.amd.com Sat Feb 27 13:14:23 1993
I don't know if it has any virtue besides being implemented in hardware
but the most widely used function is probably the one used by the 7990
LANCE chip.

From lyndon@unbc.edu Sun Feb 28 14:43:55 1993
Someone at DECWRL did a paper on this about four years ago. I can't
remember the title or author (said TR being packed in one of about
15 boxes) however a search of the DEC TR library on gatekeeper.dec.com
should prove useful.




-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Mar 1993 19:27:59 GMT
From:      wunder@hpl.hp.com (Walter Underwood)
To:        comp.protocols.tcp-ip
Subject:   Re: netmasking and HP workstations

Robin Pickering (rob@icarus.inmos.co.uk) wrote:
:             IP addresses are not permitted to have the value 0 or -1 for
:             any of the <Host-number>, <Network-number>, or <Subnet-
:             number> fields (except in the special cases listed above).
:             This implies that each of these fields will be at least two
:             bits long.
 
: As the subnet field in question is 9 bits long, this should not be a problem.

The problem is in the host number, not the subnet number.

The host number is 7 bits wide and all zeros.  This is forbidden by the
text you quoted.  A 7 bit host number gives you 126 addresses, not 128.

Walter Underwood
HP Labs



-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 93 20:46:47 GMT
From:      schmidt@net1.ics.uci.edu (Douglas C. Schmidt)
To:        comp.protocols.tcp-ip,comp.unix.internals
Subject:   Semantics of non-blocking "passive"-mode SOCK_STREAM sockets

Hi,

	I've got a brief question regarding the semantics associated
with non-blocking "passive"-mode SOCK_STREAM sockets (i.e., sockets
that are only used to accept(2) connection requests).

	If I set a passive-mode socket to be non-blocking, is this
suppose to have the side-effect of making all new sockets returned by
an accept(2) call also be set as non-blocking?

	For example, consider the following C code fragment:

	int server_fd;
	int new_fd;

	server_fd = socket (PF_INET, SOCK_STREAM, 0);
	bind (server_fd, ...);
	listen (server_fd, ...);

	while ((new_fd = accept (server_fd, ...)) )
		if (read (new_fd, ...) == -1)
			if (errno == EWOULDBLOCK)
				;

	Do I need to code my application to handle EWOULDBLOCK on the
read(2)?  I don't see why non-blocking status should be "inherited" by
the new_fd, but I've seen this behavior occur before under Sun OS
4.1.2.  Is this correct behavior?

	Thanks,

		Doug
--
His life was gentle, and the elements so            | Douglas C. Schmidt
Mixed in him that nature might stand up             | schmidt@ics.uci.edu
And say to all the world: "This was a man."         | ucivax!schmidt
   -- In loving memory of Terry Williams (1971-1991)| (714) 856-4101

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 1993 20:47:44 GMT
From:      roy@mchip00.med.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Ip Addressing Question

-> One of the proposals for dealing with routing table explosion on the
-> backbone networks is "supernetting", where blocks of adjacent class C
-> addresses are treated as a single network for backbone routing purposes.

Sounds just like AppleTalk Phase-II net ranges.
-- 
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."

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Mar 1993 21:27:31 GMT
From:      mahmood@lambda.msfc.nasa.gov (Rafique Mahmood)
To:        comp.sys.sun.admin,comp.sys.sgi.admin,comp.protocols.tcp-ip
Subject:   HOW TO CONFIGURE TCP/IP TO DISABLE ROUTER


I need to find out how to disable routing in the TCP/IP configuration.
In our setup and configuration we need to make sure noone can setup a 
router. 

I like to know how to do this. Please let me know. I also
need the documentation where it says the way to do it. We need to put
it in our security document.

I need this as sson as I can.

Thanks,
Please email me the response.

Rafique
email: mahmood@lambda.msfc.nasa.gov


-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 1993 08:07:57 -0600
From:      rrsum@matt.ksu.ksu.edu (Rick Summerhill)
To:        comp.protocols.tcp-ip
Subject:   Re: OSPF subnet routing on a Wellfleet

skaggs@nsslsun.nssl.uoknor.edu (Gary Skaggs) writes:

>I'm trying to not waste my subnet resources (two boxes on one interface)
>and need to know a nuts and bolts way to configure OSPF on my Wellfleet 
>router so that I can use its 'creative' subnetting.  Could someone point me
>to a resource, or just give me the keystrokes for the config file?

I have a related question!  RIP puts out routing information that is
understood by Unix boxes running routed.  Does routed also understand
the routing information put out by OSPF, or can OSPF be configured to
output similar information?

--Rick

-- 
Rick Summerhill                          Internet:  rrsum@hermzel.ksu.ksu.edu
CNS, Cardwell Hall                       Bitnet:    rrsum@ksuvm
Kansas State University                  Phone:     (913)532-4907
Manhattan, KS 66506                      FAX:       (913)532-5914

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 93 22:29:06 GMT
From:      nkumar@HP-UX (Niranjan Kumar)
To:        comp.protocols.tcp-ip
Subject:   Hints required for a beginner in socket programming

Hi,
	This may be a pretty basic question for many of you out there, but 
	can you help out a beginner like me?

	I want to know how exactly to go about programming a broadcast from 
	a client (in UDP of course). 

	All I know about the theory is this. The client basically does a 
	socket() and then a  sendto() with the address of the host to be sent 
	to. The address is generally got, by doing a gethostbyname() on the host
	which usually is a parameter to the client. If a broadcast is to be 
	done on the subnet, then all the bits in the subnetid should be 1s,
	right? What about the hostid bits? I heard something about wild-carding
	the address with spaces or an asterisk. But, I am totally unclear about
	it to say the least. 

	Can any of you throw more light on the subject? Better still as an 
	example can any of you send me a working piece of code, which I can 
	manipulate and do some experiments on.

	My e-mail address is cimshop!mtview!nkumar@uunet.uu.net

	Thanks.

Niranjan

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 93 22:35:11 GMT
From:      dave@netmgr.mmc.com (David A. Rageth)
To:        comp.protocols.tcp-ip
Subject:   Re: netmasking and HP workstations

|> We have a class B address we are looking at subnetting with a mask of
|> 255.255.255.128 to get 500+ subnet numbers.  When we set the netmask
|> value on many other workstations (Sun, Dec, mac, etc.) the machines
|> are able to function quite well on the network and communicate through
|> routers to other hosts without a glitch.  However, when we use this netmask
|> on an HP workstation and the network happens to be on the low end of the
|> range, e.g. 160.205.2.0, 160.205.3.0, 160.205.4.0, ... the HP does not
|> function.  If, however, I place this workstation on the high end of the
|> next network, e.g. 160.205.2.128, 160.205.3.128, ..., the HP will work.
|> I have a suspicion that the HP thinks that a network of 160.205.2.0 is
|> the zero network for 160.205.2.128 with a mask of 255.255.255.128.

I understand the situation with host numbers, the numbers above are network
numbers.  The hosts are assigned in the range:

    for network 160.205.2.0, hosts = 160.205.2.1 - 160.205.2.126
        broadcast = 160.205.2.127, netmask = 255.255.255.128;

    for network 160.205.2.128, hosts = 160.205.2.129 - 160.205.2.254
        broadcast = 160.205.2.255, netmask = 255.255.255.128.

The problems is that even when the hosts are assigned in the low order set,
and the netmask is assigned as 255.255.255.128, they
cannot communicate, even in their own subnet.  However, if I change the
netmask to 255.255.255.0 on the HP, it is fat, dumb, and happy, but will
have problems communicating with hosts in the network 160.205.2.128 (hosts
of 160.205.2.129 - 160.205.2.254) on a different subnet.

|> 
|> Can anyone shed some light on this or has anyone seen this and solved
|> the problem?
|> 
-- 
x++++++++++++++++++++++++++++++++++++++++x
 x            David Rageth                x
  x   Internet : dave@netmgr.mmc.com       x
   x   voice    : (303)977-4584             x
    x   fax      : (303) 977-2765            x
     x   USMail   : Martin Marietta           x
      x              P.O. Box 179 m/s 1084     x
       x              Denver, Colorado          x
        x                               80201    x
         x++++++++++++++++++++++++++++++++++++++++x

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 93 22:46:31 GMT
From:      nkumar@HP-UX (Niranjan Kumar)
To:        comp.protocols.tcp-ip
Subject:   programming hint reqd. for a beginner.

Hi,	
	This may be pretty basic to many of you guys but I have a doubt 
	regarding broadcasting from a client (using UDP of course.).

	The theory I know about it is this. After the socket() before the 
	sendto() is done, the address that the sendto has should be a broadcast
	address. I read in some books that a broadcast address has to have all 
	1s in the hostid part. My aim is to broadcast in a sub-net here. So 
	what do I do with the subnet id??? I heard about wildcarding the 
	address by using spaces or an asterisk. 

	Can you guys tell me more about this??? It will be more helpful if you
	can send a working piece of code so that that will serve as an example
	to me and I can do whatever experimnents on it.

	My e-mail address is cimshop!mtview!nkumar@uunet.uu.net

	You can respond either to the net or to my address.

	Thanks,
Niranjan.

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 93 23:01:21 GMT
From:      marmary@kaa.informatik.rwth-aachen.de (Mahmoud-Reza Nazeman)
To:        comp.protocols.tcp-ip
Subject:   [Jacobsen90c]?

In RFC 1323 there is the following reference:

[Jacobsen90c] Jacobsen, V.,"Modified TCP Congestion avoidance algorithm",
	      Message to end2end-interest mailing list, April 1990

Does anyone know, where this article can be obtained from (FTP site?) ?

Thanks in advance.

			marmary


-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Mar 1993 23:27:04 GMT
From:      cazier@gothamcity.jsc.nasa.gov (David J. Cazier [I-NET], 244-5750, exp. - 10/31/93)
To:        comp.protocols.tcp-ip
Subject:   LWP for DOS

I'm having a little difficulty with a Phoenix board ET200-T driver suite
and have a couple of questions.

The NET.CFG file is set up correctly as far as I'm concerned ...

LSL, NE2000, IPXODI and NETX all load OK.  I can even communicate with a NetWare
server. BUT ... when I load tcpip and telapi, I get no error messages during the
load , except when Windows begins to load and then I get some message about
wrong version ... I HAVE mixed software from one disk with another ... are
versions so critical?  

I think I've also not answered the correct questions about thick net versus
T-based - questions asked during the install I believe - unless I'm mixing 
software products up.

Do I have to go through another reinstall to reset the thick vs. thinnet vs. T ?

I don't think Windows has anything to do with the error message.

While all seems to bind correct, ping cannot ping. ftp doesn't connect, etc...

ANy suggestions welcome. 


-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 1993 15:17:06 -0800
From:      dmitzel@pollux.usc.edu (Danny Mitzel)
To:        comp.protocols.tcp-ip
Subject:   Wanted: PC TCP/IP package supporting priority queueing


Does anyone know of a PC TCP/IP package that supports some form of simple
priority queueing mechanism.  By priority queueing I mean giving certain data 
streams [identified by port #, protocol, etc.] priority over others.  I'm 
interested in public domain and commercial products.  Or suggestions of how
to hack it into an existing driver.

thanks,
danny (mitzel@usc.edu)

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 93 07:40:15 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip
Subject:   Re: anyone using UDP?

jbvb@vax.ftp.com (James B. VanBokkelen) sez:
> In article <1993Feb22.190228.24321@mdd.comm.mot.com> bradley@mdd.comm.mot.com (M
> ichael Bradley) writes:
> 
>      One may have little choice depending on requirements. We are working
>     in an environment where bandwidth is low and expensive (wireless).
>     TCP header overhead (assuming you cant use header compression) and
>     connection setup and tear down are an expense one may or may not be
>     able to deal with. Not everybody has the luxury of megabit - 
>     essentially for free bandwidth.
>      
> And meanwhile FDDI-based speed freaks are voicing hopes that the
> end-to-end checksum can be avoided in *their* use of TCP.
	I'm not sure which FDDI-based speed freak you're talking about
here.  I guess I fit the description above; my advisor and I came
out with a scheme that avoids checksums in the case in which two
communicating machines are both on the same LAN, and that LAN supports
a hardware CRC or checksum (e.g., the Internet checksum is directly
redundant with the hardware CRC).  It  has nothing to do with wireless
networking, though, so I figured this it wasn't aimed at me.
	Unfortunately, for whatever reason, Vernon Schryver, an
FDDI-based speed freak (I assume you'll take that as a compliment,
Vernon? :-)) who posts here far more frequently than I, has apparently
taken this as an opportunity to dig at some unnamed FDDI-based speed
freak that looks to have the initials "Jon Kay:"

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) unfairly states:
> In article <930226174157@cream.ftp.com>, jbvb@vax.ftp.com (James B. VanBokkelen)
>  writes:
> >      
> > And meanwhile FDDI-based speed freaks are voicing hopes that the
> > end-to-end checksum can be avoided in *their* use of TCP.
> 
> Not all of us.
> 
> > Some of us are completely saturating the ring with a single TCP virtual
> > circuit, pushing the token latency as high as you might wish, with
> > valid and checked checksums, with what are advertised as "low cost"
> > UNIX boxes.  (well, not quite as "low cost" as a generic 386SX PC, but
> > less than a "mid-priced" car.)
	Advertising or no, SGI equipment, especially when equipped
with an FDDI interface, is a lot more expensive than even a high-end
'486/66 PC.  You have avoided doing the checksum in the CPU by moving
the checksum computation to the device.  While that is quite clever,
and definitely faster than doing the checksum on the host, your FDDI
adapter would be cheaper by some amount if it didn't have to do the
checksum at all.  I don't know what percentage of the cost of your
adapter is due to that, but it has to be something.  And as FDDI
adapters get cheaper, such modifications will be a larger percentage
of the cost of the adapter.  The software solution is essentially
free, especially since the software to do it is already freely
available, and the modifications involved are pretty trivial.  The
software solution also works on the hundreds of existing LAN adapters
that don't implement Internet checksumming.
	I still don't see what this has to do with wireless
networking.

> > 
> > Recall that at Interop92 there were two different vendors showing
> > machines doing >= 95Mbit/sec.
> > 
> > The TCP checksum is too easy to do in hardware to worry about bending
> > the RFC.
Now this is just plain unfair.  The algorithm described is
EXPERIMENTAL.  It says so clearly and up front in the distribution.
By definition, an experimental version of TCP/IP does not have to
follow RFC's.

							Jon

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 1993 10:03:17 GMT
From:      van@vs.ee.lbl.gov (Van Jacobson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP, retry timer, RF extension


> Unfortunately, Mr. Partridge neglected to provide the actual reference,

Don,

I suspect the paper Craig was refering to was "Congestion Avoidance
and Control" which was published in the proceedings of SIGCOMM '88.
The modified RTT estimation algorithm is briefly described in
section 2 and analyzed to death in appendix A.  If you don't happen
to have ancient SIGCOMM proceedings handy, the postscript of the
paper is available for anonymous ftp from host ftp.ee.lbl.gov,
file congavoid.ps.Z.

 - Van

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 93 20:21:32 GMT
From:      callv@sx.ac.uk (Dr V Callaghan)
To:        comp.protocols.tcp-ip
Subject:   SLIP with Half-Duplex ?

Does anyone know if SLIP will (or can be made to) work with half-duplex ?

We want to use SLIP for some mobile robot work using radio modems. All the  
radio modems we have come across only provide a RS232 half-duplex mode (passing  
data in both directions alternatively, rather than simultaneously as with  
full-duplex).

Any advice will be appreciated,

Vic Callaghan

---------------------------------------------------------------------------
Dr. V. Callaghan, University of Essex, UK       Internet: callv@essex.ac.uk

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 93 21:56:56 GMT
From:      sklower@diva.Berkeley.EDU (Keith Sklower)
To:        comp.protocols.tcp-ip
Subject:   Re: Automatic running of processes in TCP/IP

In article <1993Feb26.152616.11373@aston.ac.uk> j.williams@aston.ac.uk (John Williams) writes:
>I would like to set up a system which allows users to call a TCP port and then
>automatically run a process, like the way X.25 subaddresses are used.
>Is there a way or a piece of software that can do this?

I'm not sure whether Mr. Williams wants to have different users call
the same port, and initiate different services depending on some further
inband negotiation, which I believe is  what RFC 1078 was designed to do,
or have a specific service initiated upon receipt of the connection request,
which inetd already does.

1078  Lottor, M.  TCP port service Multiplexer (TCPMUX).  1988 November; 2 p.
      (Format: TXT=3248 bytes)



-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6 Mar 1993 02:00:53 GMT
From:      spatel@aplcenmp.apl.jhu.edu (Patel sanjay v 410-381-9362)
To:        comp.protocols.tcp-ip
Subject:   Berkeley sockets question???

 I am having problem with a c program written iZZ

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6 Mar 1993 02:07:17 GMT
From:      spatel@aplcenmp.apl.jhu.edu (Patel sanjay v 410-381-9362)
To:        comp.protocols.tcp-ip
Subject:   Berkeley Sockets Question (attempt #2)

 I am having problems with a application written on AIX (and SCO UNIX)
which is basically client-server using Berkeley reads and writes.
I using a non blocking read with the timeout set to 300 sec on the socket
.
The socket options set are SO_LINGER and SO_REUSEADDR. My client will
write a request and read back a reply from the server. On the first
call to read, it works beautifully and it keeps working as long as
I keep the client requesting and the server sending stuff. But if I 
stop sending, and I let the two processes sit idle for 5+ minutes
the next time I send, the read on the socket fails and returns a
-1. I read in SCO manual that this means we should consult errno,
but I haven't got a handle on that yet. Do you think SO_KEEPALIVE 
will help?? Any other ideas. I know this is not very specific. I have
tried this with AIX client to SCO server and SCO client to SCO server.
THANKS A LOT for any help!!!

Sanjay Patel

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6 Mar 1993 14:10:47 GMT
From:      artman@vpnet.chi.il.us (Wilfred A Artman)
To:        comp.protocols.tcp-ip
Subject:   Modems and terminal servers

Newsgroups: comp.protocols.tcpip
Subject: Modems and terminal servers
Distribution: world
Organization: Vpnet Public Access

HELP! acutally, that was a good way to get your attention... What I
really need is some information from anyone who is currently using
modems attached to a terminal server. In my case, I have Telebit T1600's
and Telebit T1000's that I will be attaching to an Xylogics Annex III. I
currently have one in use as a dial out modem and it functions about 60%
of the time without error. This is when it is used with UUCP (generic
Sun version). When 'tip' is used to access the modem, there is a 90%
chance that the modem/port will require a reset after completion of the
call. The current plan is to place a number of modems on the server,
but, the current problem is causing a wait. Another thing I have noticed
is that the psuedo port that is created with the rtelnet process for the
port will not remain under the ownership of root, in other words, if the
modem is free and another user logs in through the server from a
terminal, if the port is free and the next on the list, it will attach
to the port previously allocated to the modem. Am I making any
sense?????

Configuration:

Solbourne Series 600 and Series 700 hosts with MP/OS 4.1A.3
Xylogics Annex IIe and III's with v7.0 softwaree
Modems: Telebit T1600 set at factory defaults (local dialout)
        Telebit T1600's and T1000's at remote sites set at
            second available setting (unattended answer mode)

I have tried the UUCP/Xmodem setting and that was so tempermental that I
finally gave up and went back to the modem settings stated above.

Any discussion, information, etc. would be greatly beneficial and
graciously shared on the net!

AtDhVaAnNkCsE

Wil Artman

artman@vpnet.chi.il.us

============================================================================
No neat .signature!
============================================================================


-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6 Mar 1993 19:22:39 GMT
From:      smisra@eos.ncsu.edu (SAURABH MISRA)
To:        comp.protocols.tcp-ip
Subject:   Need SLIP Documentation Help

I need a reference on writing a SLIP terminal program.  Does anyone
have a good recommendation they can point me to?

Thanks,
Saurabh.

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Sun, 7 Mar 1993 10:33:41 GMT
From:      deraadt@fsa.ca (Theo de Raadt)
To:        comp.protocols.tcp-ip
Subject:   Re: ka9q for unix?

In article <l?s1Huiktc@atlantis.psu.edu> barr@pop.psu.edu (David Barr) writes:
   All it takes is a packet radio driver.  ka9q was written for packet
   radio, but with any clarkson (crynwr) driver, will work with anything
   from Ethernet to Token Ring.  (For PC's, that is).  Thus, the answer
   is NOT to have ka9q for UNIX (which is re-porting the wheel), but
   having a packet radio driver.

   No, don't ask me where you can find one.

fsa.ca:/pub/ax25.shar	(or newt.fsa.ca)

Runs under sunos4.1.x. Tested on a sun3 and sun4. May still have a few
latent bugs, since I've received only a few bug reports..

Share and Enjoy.
 <tdr.
--

This space not left unintentionally unblank.		deraadt@fsa.ca

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Sun, 7 Mar 1993 10:37:16 GMT
From:      deraadt@fsa.ca (Theo de Raadt)
To:        comp.protocols.tcp-ip
Subject:   Re: ka9q for unix?

In article <l?s1Huiktc@atlantis.psu.edu> barr@pop.psu.edu (David Barr) writes:
   All it takes is a packet radio driver.  ka9q was written for packet
   radio, but with any clarkson (crynwr) driver, will work with anything
   from Ethernet to Token Ring.  (For PC's, that is).  Thus, the answer
   is NOT to have ka9q for UNIX (which is re-porting the wheel), but
   having a packet radio driver.

   No, don't ask me where you can find one.

Well, perhaps I can point out another solution: There is an ax25 device
driver for SunOS. Loosely based on PPP and cslip code for SunOS streams,
this seems to do the trick.

    fsa.ca:/pub/ax25.shar	(or newt.fsa.ca)

Runs under sunos4.1.x. Tested on a sun3, sun4, and sun4c kernel
architectures. May still have a few latent bugs, since I've received
only a few bug reports..

Share and Enjoy.
 <tdr.
--

This space not left unintentionally unblank.		deraadt@fsa.ca

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Sun, 7 Mar 1993 21:19:22 GMT
From:      ptrubey@netcom.com (Phil Trubey)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   MacTCP doesn't do Fast Retransmit??

I am having some problems with MacTCP v1.1.1. using NCSA Telnet v2.5.
As near as I can figure out with a protocol analyzer, MacTCP does not
implement the Fast Retransmit algorithm, *and* it either has or generates
very long retransmit timers.  To give you an example of a trace...

Time      Mac                             Internet Host
394.749   Data: "t", Seq: 790d     --->                 [presumably lost]
...
395.005   Data: "e", Seq: 780e     --->
395.055                            <---    Ack: 780d

<Mac continues sending stuff>
<Host continues acking just 780d, in fact it does this 13 times>

401.633                            <---    Ack: 780d
422.668   Data: "te...", Seq: 790d --->

It took the Mac 27.663 seconds for its retransmit timer to
trip, while it was ignoring the useful information in the host's 
repeated ACKs.

Does anyone know if this indicative of how MacTCP works?  If so,
does anyone know if Apple is planning to sell (since they are charging
a lot of money for this now) a *real* TCP/IP implementation for
the Mac?

-- 

Phil Trubey                   | Internet: ptrubey@netcom.com
Systemhouse Inc.              | Voice:    415-327-8337
                              | Fax:      415-243-0471

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Mar 1993 02:49:31 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.sys.sun.admin,comp.sys.sgi.admin,comp.protocols.tcp-ip
Subject:   Re: HOW TO CONFIGURE TCP/IP TO DISABLE ROUTER

In article <1993Mar7.164649.7126@aristo.tau.ac.il>, yaron@aristo.tau.ac.il (Yaron Zabary) writes:
> Rafique Mahmood (mahmood@lambda.msfc.nasa.gov) wrote:
> 
> > I need to find out how to disable routing in the TCP/IP configuration.
> > In our setup and configuration we need to make sure noone can setup a 
> > router. 
> 
>   I am not sure I got you right, but if you ment you want to prevent a
> machine which has two interfaces to act as a gateway (that is the term
> which is usualyy used by RFCs), you need to go to /usr/sysgen/master.d
> and look into a file named bsd . In that file you will find a line with
> ipforwarding. You need to turn it off, create a new kernel (lboot or 
> autoconfig) and reboot.


Note that despite the newsgroups, which include comp.sys.sun.admin
and comp.protocols.tcp-ip, this procedure is appropriate only for
Silicon Graphics' boxes.

When you do this, don't forget to make `routed` quiet with '-q' in 
/etc/config/routed.options.  Otherwise, other people will curse
you for creating a black hole.

In a benign environment, quieting `routed` is sufficient to
stop a machine from acting as a router, since only manual
static routes and evil hacks will use a silent gateway.


Vernon Schryver,  vjs@sgi.com

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Mar 93 09:20:48 EST
From:      thomas@mvac23.UUCP (Thomas Lapp)
To:        comp.protocols.tcp-ip
Subject:   Info wanted on OCS to MVS gotchas

I'm thinking about implementing tn/3270 gateway using OCS and would like
to know about any 'gotchas' that I might look out for when installing
or running the system.  (PS: likely it will be OCS-II on Unix platform).

If you've installed that and are willing to talk with me about it, 
send me e-mail and I'll call you (ie. my nickel).

thanks,
                         - tom
--
internet     : mvac23!thomas@udel.edu  or  thomas%mvac23@udel.edu (home)
             : lapp@cdhub1.dnet.dupont.com (work)
OSI          : C=US/A=MCI/S=LAPP/D=ID=4398613
uucp         : {ucbvax,mcvax,uunet}!udel!mvac23!thomas
Location     : Newark, DE, USA


-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 93 09:54:43 EST
From:      newwave@desire.wright.edu
To:        comp.protocols.tcp-ip,comp.sys.sgi
Subject:   Wanted: TCP/IP DLI interface.


Netters:

 I am looking for any information (or even code) on TCP/IP device drivers for
the following platforms: Motorola Delta Series and Silicon Graphics.  I
especially need the DLI interface.  If I can find them at any sites, please
specify the whole site name.  Thanking you in advance.

K. Desai

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Mon,  8 Mar 1993 15:36:15 -0500
From:      amanda@intercon.com (Amanda Walker)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Re: MacTCP doesn't do Fast Retransmit??

ptrubey@netcom.com (Phil Trubey) writes:
> Does anyone know if this indicative of how MacTCP works?

Well, it's my theory as well.  MacTCP's retransmission timing algorithm is
prone to glitch up over every network medium I've tried it on.  Its delayed 
ACK algorithm also seems to be badly tuned (the two problems may even be 
related).

> If so, 
> does anyone know if Apple is planning to sell (since they are charging 
> a lot of money for this now) a *real* TCP/IP implementation for 
> the Mac? 

So far as I know, Apple's plans are only to add to MacTCP, not overhaul its 
internals.  While I sympathize with the folks in ESD who have to deal with 
MacTCP, the status quo leaves something to be desired.


Amanda Walker
InterCon Systems Corporation



-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Mar 1993 09:39:53 GMT
From:      s920715@hp9000.csc.cuhk.hk (LI CHUNG YUEN)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Parameters of PATHWAY SLIP.EXE ??

Can anyone tell me the parameter of Pathway slip.exe ??
Please return your reply to s920715@hp9000.csc.cuhk.hk.

Thanks



-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Mar 1993 14:03:56 GMT
From:      carlson@steam.Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: Modems and terminal servers

>Sun version). When 'tip' is used to access the modem, there is a 90%
>chance that the modem/port will require a reset after completion of the

Which Sun operating system are you using?  We've got newer versions of
rtelnet that should fix these problems.

(In general, you can get technical information and help from
annex-support@xylogics.com.)

--
James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
Annex Software Support / Xylogics, Inc.               +1 800 225 3317
53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 3159

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Mar 1993 15:42:05 GMT
From:      mark@alias.com (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: [Jacobsen90c]?

In <marmary.731286081@kaa> marmary@kaa.informatik.rwth-aachen.de (Mahmoud-Reza Nazeman) writes:

>In RFC 1323 there is the following reference:
 
>[Jacobsen90c] Jacobsen, V.,"Modified TCP Congestion avoidance algorithm",
>	      Message to end2end-interest mailing list, April 1990
 
>Does anyone know, where this article can be obtained from (FTP site?) ?
 
>Thanks in advance.
 
>			marmary

Here it is (2 messages):

From van@helios.ee.lbl.gov Mon Apr 30 01:44:05 1990
To: end2end-interest@ISI.EDU
Subject: modified TCP congestion avoidance algorithm
Date: Mon, 30 Apr 90 01:40:59 PDT
From: Van Jacobson <van@helios.ee.lbl.gov>
Status: RO

This is a description of the modified TCP congestion avoidance
algorithm that I promised at the teleconference.

BTW, on re-reading, I noticed there were several errors in
Lixia's note besides the problem I noted at the teleconference.
I don't know whether that's because I mis-communicated the
algorithm at dinner (as I recall, I'd had some wine) or because
she's convinced that TCP is ultimately irrelevant :).  Either
way, you will probably be disappointed if you experiment with
what's in that note.

First, I should point out once again that there are two
completely independent window adjustment algorithms running in
the sender:  Slow-start is run when the pipe is empty (i.e.,
when first starting or re-starting after a timeout).  Its goal
is to get the "ack clock" started so packets will be metered
into the network at a reasonable rate.  The other algorithm,
congestion avoidance, is run any time *but* when (re-)starting
and is responsible for estimating the (dynamically varying)
pipesize.  You will cause yourself, or me, no end of confusion
if you lump these separate algorithms (as Lixia's message did).

The modifications described here are only to the congestion
avoidance algorithm, not to slow-start, and they are intended to
apply to large bandwidth-delay product paths (though they don't
do any harm on other paths).  Remember that with regular TCP (or
with slow-start/c-a TCP), throughput really starts to go to hell
when the probability of packet loss is on the order of the
bandwidth-delay product.  E.g., you might expect a 1% packet
loss rate to translate into a 1% lower throughput but for, say,
a TCP connection with a 100 packet b-d p. (= window), it results
in a 50-75% throughput loss.  To make TCP effective on fat
pipes, it would be nice if throughput degraded only as function
of loss probability rather than as the product of the loss
probabilty and the b-d p.  (Assuming, of course, that we can do
this without sacrificing congestion avoidance.)

These mods do two things: (1) prevent the pipe from going empty
after a loss (if the pipe doesn't go empty, you won't have to
waste round-trip times re-filling it) and (2) correctly account
for the amount of data actually in the pipe (since that's what
congestion avoidance is supposed to be estimating and adapting to).

For (1), remember that we use a packet loss as a signal that the
pipe is overfull (congested) and that packet loss can be
detected one of two different ways:  (a) via a retransmit
timeout or (b) when some small number (3-4) of consecutive
duplicate acks has been received (the "fast retransmit"
algorithm).  In case (a), the pipe is guaranteed to be empty so
we must slow-start.  In case (b), if the duplicate ack
threshhold is small compared to the bandwidth-delay product, we
will detect the loss with the pipe almost full.  I.e., given a
threshhold of 3 packets and an LBL-MIT bandwidth-delay of around
24KB or 16 packets (assuming 1500 byte MTUs), the pipe is 75%
full when fast-retransmit detects a loss (actually, until
gateways start doing some sort of congestion control, the pipe
is overfull when the loss is detected so *at least* 75% of the
packets needed for ack clocking are in transit when
fast-retransmit happens).  Since the pipe is full, there's no
need to slow-start after a fast-retransmit.

For (2), consider what a duplicate ack means:  either the
network duplicated a packet (i.e., the NSFNet braindead IBM
token ring adapters) or the receiver got an out-of-order packet.
The usual cause of out-of-order packets at the receiver is a
missing packet.  I.e., if there are W packets in transit and one
is dropped, the receiver will get W-1 out-of-order and
(4.3-tahoe TCP will) generate W-1 duplicate acks.  If the
`consecutive duplicates' threshhold is set high enough, we can
reasonably assume that duplicate acks mean dropped packets.

But there's more information in the ack:  The receiver can only
generate one in response to a packet arrival.  I.e., a duplicate
ack means that a packet has left the network (it is now cached
at the receiver).  If the sender is limitted by the congestion
window, a packet can now be sent.  (The congestion window is a
count of how many packets will fit in the pipe.  The ack says a
packet has left the pipe so a new one can be added to take its
place.)  To put this another way, say the current congestion
window is C (i.e, C packets will fit in the pipe) and D
duplicate acks have been received.  Then only C-D packets are
actually in the pipe and the sender wants to use a window of C+D
packets to fill the pipe to its estimated capacity (C+D sent -
D received = C in pipe).

So, conceptually, the slow-start/cong.avoid/fast-rexmit changes
are:

  - The sender's input routine is changed to set `cwnd' to `ssthresh'
    when the dup ack threshhold is reached.  [It used to set cwnd to
    mss to force a slow-start.]  Everything else stays the same.

  - The sender's output routine is changed to use an effective window
    of min(snd_wnd, cwnd + dupacks*mss)  [the change is the addition
    of the `dupacks*mss' term.]  `Dupacks' is zero until the rexmit
    threshhold is reached and zero except when receiving a sequence
    of duplicate acks.

The actual implementation is slightly different than the above
because I wanted to avoid the multiply in the output routine
(multiplies are expensive on some risc machines).  A diff of the
old and new fastrexmit code is attached (your line numbers will
vary).

Note that we still do congestion avoidance (i.e., the window is
reduced by 50% when we detect the packet loss).  But, as long as
the receiver's offered window is large enough (it needs to be at
most twice the bandwidth-delay product), we continue sending
packets (at exactly half the rate we were sending before the
loss) even after the loss is detected so the pipe stays full at
exactly the level we want and a slow-start isn't necessary.

Some algebra might make this last clear:  Say U is the sequence
number of the first un-acked packet and we are using a window
size of W when packet U is dropped.  Packets [U..U+W) are in
transit.  When the loss is detected, we send packet U and pull
the window back to W/2.  But in the round-trip time it takes
the U retransmit to fill the receiver's hole and an ack to get
back, W-1 dup acks will arrive (one for each packet in transit).
The window is effectively inflated by one packet for each of
these acks so packets [U..U+W/2+W-1) are sent.  But we don't
re-send packets unless we know they've been lost so the amount
actually sent between the loss detection and the recovery ack is
U+W/2+W-1 - U+W = W/2-1 which is exactly the amount congestion
avoidance allows us to send (if we add in the rexmit of U).  The
recovery ack is for packet U+W so when the effective window is
pulled back from W/2+W-1 to W/2 (which happens because the
recovery ack is `new' and sets dupack to zero), we are allowed
to send up to packet U+W+W/2 which is exactly the first packet
we haven't yet sent.  (I.e., there is no sudden burst of packets
as the `hole' is filled.)  Also, when sending packets between
the loss detection and the recovery ack, we do nothing for the
first W/2 dup acks (because they only allow us to send packets
we've already sent) and the bottleneck gateway is given W/2
packet times to clean out its backlog.  Thus when we start
sending our W/2-1 new packets, the bottleneck queue is as empty
as it can be.

[I don't know if you can get the flavor of what happens from
this description -- it's hard to see without a picture.  But I
was delighted by how beautifully it worked -- it was like
watching the innards of an engine when all the separate motions
of crank, pistons and valves suddenly fit together and
everything appears in exactly the right place at just the right
time.]

Also note that this algorithm interoperates with old tcp's:  Most
pre-tahoe tcp's don't generate the dup acks on out-of-order packets.
If we don't get the dup acks, fast retransmit never fires and the
window is never inflated so everything happens in the old way (via
timeouts).  Everything works just as it did without the new algorithm
(and just as slow).

If you want to simulate this, the intended environment is:

    - large bandwidth-delay product (say 20 or more packets)

    - receiver advertising window of two b-d p (or, equivalently,
      advertised window of the unloaded b-d p but two or more
      connections simultaneously sharing the path).

    - average loss rate (from congestion or other source) less than
      one lost packet per round-trip-time per active connection.
      (The algorithm works at higher loss rate but the TCP selective
      ack option has to be implemented otherwise the pipe will go empty
      waiting to fill the second hole and throughput will once again
      degrade at the product of the loss rate and b-d p.  With selective
      ack, throughput is insensitive to b-d p at any loss rate.)

And, of course, we should always remember that good engineering
practise suggests a b-d p worth of buffer at each bottleneck --
less buffer and your simulation will exhibit the interesting
pathologies of a poorly engineered network but will probably
tell you little about the workings of the algorithm (unless the
algorithm misbehaves badly under these conditions but my
simulations and measurements say that it doesn't).  In these
days of $100/megabyte memory, I dearly hope that this particular
example of bad engineering is of historical interest only.

 - Van

-----------------
*** /tmp/,RCSt1a26717	Mon Apr 30 01:35:17 1990
--- tcp_input.c	Mon Apr 30 01:33:30 1990
***************
*** 834,850 ****
  				 * Kludge snd_nxt & the congestion
  				 * window so we send only this one
! 				 * packet.  If this packet fills the
! 				 * only hole in the receiver's seq.
! 				 * space, the next real ack will fully
! 				 * open our window.  This means we
! 				 * have to do the usual slow-start to
! 				 * not overwhelm an intermediate gateway
! 				 * with a burst of packets.  Leave
! 				 * here with the congestion window set
! 				 * to allow 2 packets on the next real
! 				 * ack and the exp-to-linear thresh
! 				 * set for half the current window
! 				 * size (since we know we're losing at
! 				 * the current window size).
  				 */
  				if (tp->t_timer[TCPT_REXMT] == 0 ||
--- 834,850 ----
  				 * Kludge snd_nxt & the congestion
  				 * window so we send only this one
! 				 * packet.
! 				 *
! 				 * We know we're losing at the current
! 				 * window size so do congestion avoidance
! 				 * (set ssthresh to half the current window
! 				 * and pull our congestion window back to
! 				 * the new ssthresh).
! 				 *
! 				 * Dup acks mean that packets have left the
! 				 * network (they're now cached at the receiver) 
! 				 * so bump cwnd by the amount in the receiver
! 				 * to keep a constant cwnd packets in the
! 				 * network.
  				 */
  				if (tp->t_timer[TCPT_REXMT] == 0 ||
***************
*** 853,864 ****
  				else if (++tp->t_dupacks == tcprexmtthresh) {
  					tcp_seq onxt = tp->snd_nxt;
! 					u_int win =
! 					    MIN(tp->snd_wnd, tp->snd_cwnd) / 2 /
! 						tp->t_maxseg;
  
  					if (win < 2)
  						win = 2;
  					tp->snd_ssthresh = win * tp->t_maxseg;
- 
  					tp->t_timer[TCPT_REXMT] = 0;
  					tp->t_rtt = 0;
--- 853,864 ----
  				else if (++tp->t_dupacks == tcprexmtthresh) {
  					tcp_seq onxt = tp->snd_nxt;
! 					u_int win = MIN(tp->snd_wnd,
! 							tp->snd_cwnd);
  
+ 					win /= tp->t_maxseg;
+ 					win >>= 1;
  					if (win < 2)
  						win = 2;
  					tp->snd_ssthresh = win * tp->t_maxseg;
  					tp->t_timer[TCPT_REXMT] = 0;
  					tp->t_rtt = 0;
***************
*** 866,873 ****
  					tp->snd_cwnd = tp->t_maxseg;
  					(void) tcp_output(tp);
! 
  					if (SEQ_GT(onxt, tp->snd_nxt))
  						tp->snd_nxt = onxt;
  					goto drop;
  				}
  			} else
--- 866,879 ----
  					tp->snd_cwnd = tp->t_maxseg;
  					(void) tcp_output(tp);
! 					tp->snd_cwnd = tp->snd_ssthresh +
! 						       tp->t_maxseg *
! 						       tp->t_dupacks;
  					if (SEQ_GT(onxt, tp->snd_nxt))
  						tp->snd_nxt = onxt;
  					goto drop;
+ 				} else if (tp->t_dupacks > tcprexmtthresh) {
+ 					tp->snd_cwnd += tp->t_maxseg;
+ 					(void) tcp_output(tp);
+ 					goto drop;
  				}
  			} else
***************
*** 874,877 ****
--- 880,890 ----
  				tp->t_dupacks = 0;
  			break;
+ 		}
+ 		if (tp->t_dupacks) {
+ 			/*
+ 			 * the congestion window was inflated to account for
+ 			 * the other side's cached packets - retract it.
+ 			 */
+ 			tp->snd_cwnd = tp->snd_ssthresh;
  		}
  		tp->t_dupacks = 0;
*** /tmp/,RCSt1a26725	Mon Apr 30 01:35:23 1990
--- tcp_timer.c	Mon Apr 30 00:36:29 1990
***************
*** 223,226 ****
--- 223,227 ----
  		tp->snd_cwnd = tp->t_maxseg;
  		tp->snd_ssthresh = win * tp->t_maxseg;
+ 		tp->t_dupacks = 0;
  		}
  		(void) tcp_output(tp);

From van@helios.ee.lbl.gov Mon Apr 30 10:37:36 1990
To: end2end-interest@ISI.EDU
Subject: modified TCP congestion avoidance algorithm (correction)
Date: Mon, 30 Apr 90 10:36:12 PDT
From: Van Jacobson <van@helios.ee.lbl.gov>
Status: RO

I shouldn't make last minute 'fixes'.  The code I sent out last
night had a small error:

*** t.c	Mon Apr 30 10:28:52 1990
--- tcp_input.c	Mon Apr 30 10:30:41 1990
***************
*** 885,893 ****
  			 * the congestion window was inflated to account for
  			 * the other side's cached packets - retract it.
  			 */
! 			tp->snd_cwnd = tp->snd_ssthresh;
  		}
- 		tp->t_dupacks = 0;
  		if (SEQ_GT(ti->ti_ack, tp->snd_max)) {
  			tcpstat.tcps_rcvacktoomuch++;
  			goto dropafterack;
--- 885,894 ----
  			 * the congestion window was inflated to account for
  			 * the other side's cached packets - retract it.
  			 */
! 			if (tp->snd_cwnd > tp->snd_ssthresh)
! 				tp->snd_cwnd = tp->snd_ssthresh;
! 			tp->t_dupacks = 0;
  		}
  		if (SEQ_GT(ti->ti_ack, tp->snd_max)) {
  			tcpstat.tcps_rcvacktoomuch++;
  			goto dropafterack;

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Mar 1993 16:30:25 GMT
From:      saunders@theory.TC.Cornell.EDU (Kevin Saunders)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP doesn't do Fast Retransmit??


In article <1993Mar7.211922.19317@netcom.com> ptrubey@netcom.com (Phil Trubey) writes:
>I am having some problems with MacTCP v1.1.1. using NCSA Telnet v2.5.
>As near as I can figure out with a protocol analyzer, MacTCP does not
>implement the Fast Retransmit algorithm, *and* it either has or generates
>very long retransmit timers.  To give you an example of a trace...
>
BINGO!

Yes, MacTCP's resend timer, esp. 1.1.1, is hopelessly corrupt; it
tends to be off the expected value by a couple of orders of
magnitude.  If you have a lossy subnetwork (like some of Cornell's,
with our "famous" home-brewed AT-based IP/AppleTalk gateways) your
performance will be miserable.

Yes, MacTCP doesn't resend outstanding data even when the host is
responding to new data packets by returning ACKs with an old, old
sequence number, which obviously indicates that the host DIDN'T GET
IT, and wishes that you would RESEND IT.

MacTCP:  "Doesn't have it.  Never will."
bonze
_______________________
Kevin Eric Saunders (a/k/a bonze blayk!), CometMonger
Cornell Information Technologies/Network Resources
Internet:  kes1@cornell.edu             Phone: 607-255-0525
Mail:  B52A Caldwell Hall, Cornell U., Ithaca, NY 14853

I'm appending the notes on MacTCP from Comet's release notes
for 2.1.6D5:


             MacTCP notes:  

   Several versions of MacTCP are available; unfortunately, none of them
works properly on all machines.  Herewith are the advantages and
drawbacks of each:

   1.1.1:  Apple strongly advises that 1.1.1 be used with System 7.1;
however, 1.1 seems to work OK as long as Virtual Memory is off.  This
version fixes several bugs in previous versions:  e.g., it displays the
LocalTalk icon properly in the Control Panel, does not crash on the Mac+,
and apparently handles asynchronous sends correctly .  Unfortunately, it
waits ~5 seconds to resend a lost packet, which makes it irritating to
use with ASCII hosts on networks with high rates of packet loss.

     1.1:  Required for System 7 up to 7.1.  This version crashes on the
Mac+.  The LocalTalk icon does not always appear in the MacTCP control
panel when LocalTalk is the selected Network device.

   1.0.2:  A special version of MacTCP 1.0.1 released to improve the
performance of MacX.  This version is known to cause crashes on some
machines.

   1.0.1:  The first functional release version of MacTCP.  Asynchronous
sends under LocalTalk are definitely hazardous with this release,
resulting in machines hanging with the cursor frozen.  1.0.1 works under
System 7, but only if Virtual Memory is off and a copy or alias is placed
in the System Folder so that Domain Name Resolution will work properly. 
Using 1.0.1 with System 7 is not recommended.

___________________

-- 
________________________________________
Kevin Eric Saunders (a/k/a bonze blayk!), CometMonger--"NeXT, please!"
   saunders@nmc.cit.cornell.edu

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1993 17:00:53 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Can TCP/IP have backup routes

In article <1kqgi6INN9e6@cronkite.cisco.com> tli@cisco.com (Tony Li) writes:
>- Use IRDP (Router discovery protocol).  Client software is available on
>ftp.cisco.com.  cisco support is in our 9.1 release.

I found GDP client software there, but not IDRP.  What's the filename for
the IDRP client?  

-- 
Stephen Trier                      "They didn't seem to be acting out of
Network software type               malice, but they were, at best,
Case Western Reserve University     differently clued."
trier@ins.cwru.edu                        - John Perry Barlow

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Mar 1993 17:06:05 GMT
From:      Theodore M.P. Lee <tmplee@TIS.COM>
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP doesn't do Fast Retransmit??

In article <1993Mar8.163025.26233@tc.cornell.edu> Kevin Saunders,
saunders@theory.TC.Cornell.EDU writes:
> Yes, MacTCP's resend timer, esp. 1.1.1, is hopelessly corrupt
 ... If you have a lossy subnetwork  your
> performance will be miserable.

Could that explain why every now and then what is normally
quite a good connection seems to "freeze up" for 5-10
seconds?  I'm using MacTCP 1.1.1 with SLIP into a dialup Cisco server
and thence half way across the country.  I haven't been able to
observe any particular pattern to the apparent service degradation,
nor do the local site managers have any particular insights.

Ted Lee <tmplee@mr.net> or <tmplee@tis.com>

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Mar 93 17:49:54 GMT
From:      walker@ceb.nlm.nih.gov (Frank L. Walker)
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Re: Help with 3COM 3c50? EtherLink II/16 TP ?

In article <1n8epoINNoto@fmsrl7.srl.ford.com> probert@fires1.srl.ford.com writes:
>I've got three of these boards now with no documentation or software.
>Normally these would come with NDIS drivers, which I will need with
>PC-NFS.  I have the Crynwr packet driver collection, but I don't
>know which one to use and how to configure it?
>
>Thanks.
>
>
>-- 
>-------------------------------------------------------------------------------
>    FORD       | Neal W. Probert   E3154 SRL    | probert@fires1.srl.ford.com
> SCIENTIFIC    | Ford Scientific Research Labs  | 313-845-8178 FAX 313-845-8202
>RESEARCH LABS  | Dearborn, MI 48121-2053        | Disclaimer: I'm innocent!

I had the same problem last week with a 3C507 board.  What you have to do
is use the 3C507.EXE program that is needed for configuring the board
(since there are no hardware jumpers on the board).  This comes with the
board from the manufacturer.  Then you can need to install the appropriate
driver for the board.  I used a packet driver for the 3C507 that I 
downloaded from vax.ftp.com (that allows anonymous login).  The command line
for installing this packet driver is:
3c507.com 0x66 9 0x300 0xc800
where 0x66 is the software interrupt used by your application software;
	9 is the hardware interrupt
	0x300 is the board hardware address
	0xc800 is the memory address 
These values will differ, depending on how you set up the board using
3c507.exe.
Hope this was of some help.

Frank Walker
National Library of Medicine
National Institutes of Health

walker@nlm.nih.gov








-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 93 18:53:15 GMT
From:      kulkarni@giga.cs.umn.edu (Srinivas R. Kulkarni)
To:        comp.os.vxworks,comp.unix.questions,comp.protocols.tcp-ip,comp.realtime,comp.protocols.iso
Subject:   MULTICAST solution under VxWorks


 I am looking for a (inexpensive or public-domain) Multicast solution 
 that will run under the VxWorks real-time OS. 

 
 Although i can modify network driver sources in VxWorks to acheive this, i 
 would prefer a more generic and portable solution.  Furthermore, I would 
 like to use the same solution under SunOS if possible. The Sun nodes 
 as well as the VxWorks nodes are on the same network.


 Some of the options suggested to me are:
	1) VMTP
	2) XTP
	3) ISIS

 Are there any other solutions beside these that i should be considering?
 Has anybody ported VMTP to VxWorks?  

 Any info/pointers etc. will be appreciated.
 
					Srinivas R. Kulkarni
					kulkarni@cs.umn.edu

					(612) 951-7722  (voice)
					(612) 951-7438 (fax)

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Mar 1993 20:33:08 GMT
From:      rens@lorax.shearson.com (Rens Troost)
To:        comp.protocols.tcp-ip
Subject:   Re: OSPF subnet routing on a Wellfleet



In article <1n7mrtINN4q9@matt.ksu.ksu.edu> rrsum@matt.ksu.ksu.edu (Rick Summerhill) writes:


   I have a related question!  RIP puts out routing information that is
   understood by Unix boxes running routed.  Does routed also understand
   the routing information put out by OSPF, or can OSPF be configured to
   output similar information?

No. Use gated; it participates in OSPF.

-Rens
--
  __   ___  ,    __  
 /__) /__  /| / (    |  J. Laurens Troost    Lehman Brothers Technical Services
/  \ (___ / |/ __)   |  *Opinions expressed herein are mine. Mine, I tell you!*
-------------------------------------------------------------------------------
INET: rens@shearson.com        VOICE: (212) 464-3705        FAX: (212) 464-2040

  If trees could scream, would we be so cavalier about cutting them down?  We
     might, if they screamed all the time, for no good reason. -Jack Handey

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Mar 1993 20:50:29 GMT
From:      fillmore@emr1.emr.ca (Bob Fillmore 992-2832)
To:        comp.protocols.tcp-ip
Subject:   IP fragment reassembly timer in FTP Software Inc.

We are having problems with a site in Australia sending us SMTP mail.
The SMTP message IP packet gets fragmented somewhere between Australia
and us in Canada, and our cc:Mail-to-SMTP mail gateway times out waiting
for some of the fragments to arrive.  Our gateway is using the TCP/IP
protocol stack from FTP Software, Inc., version 2.05.
Is there any way to increase the IP fragment reassembly timer so that we
will wait longer for the fragments to arrive?

Thanks for any information you can provide.

-- 
Bob Fillmore, Technical Services Division          email: fillmore@emr.ca
  Information Management Branch,                   BIX:   bfillmore      
  Energy, Mines, & Resources Canada                Voice: (613) 992-2832
  580 Booth St., Ottawa, Ontario, Canada  K1A 0E4  FAX:   (613) 996-2953    

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 93 21:35:09 GMT
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip,comp.sys.ibm.pc.hardware
Subject:   Re: Gateway 8-bit ethernet cards

In article <1993Mar7.012429.2478@netcom.com> pjk@netcom.com (Phil Koenig) writes:
>
>Peter, GATEWAY COMMUNICATIONS is alive and well, somewhere in California..
>sorry I don't have an exact address.  Their cards happen to have an *excellent*
>reputation, from what I know.  One of our products (Novell to TCP/IP Gateway)
>uses the 16-bit version.
>
    
      Admittedly this is an old number I haven't used for some
      time...

      I think they are near Irvine in case it doesn't get you
      anywhere.

      Gateway   714-553-1555

      They also used to have a sales office at 818-713-0070



-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Mar 1993 23:20:26 GMT
From:      sdorner@qualcomm.com (Steven Dorner)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP doesn't do Fast Retransmit??

Amanda Walker wrote:
> So far as I know, Apple's plans are only to add to MacTCP, not overhaul its 
> internals.  While I sympathize with the folks in ESD who have to deal with 
> MacTCP, the status quo leaves something to be desired.

MacTCP was a wonderful thing when it was cheap.  Yes, it had some warts,
but it was still wonderful.

Now that Apple wants big bux for it, it's ABSOLUTELY LUDICROUS that they're
going to bundle SNMP (SNMP?  Who gives a damn?) but not fix all these
problems.

I really don't know what planet those people are from, but it sure ain't
Earth.
--
Steve Dorner, Qualcomm Inc.

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Mon, 08 Mar 1993 23:29:59 GMT
From:      obert@rchland.vnet.ibm.com (Carl Obert)
To:        comp.protocols.tcp-ip
Subject:   IP Limited Broadcast Addressing

Folks:

Section 3.2.1.3 of RFC1122 defines the limited broadcast address as follows:

(c)  { -1, -1 }

Limited broadcast.  It MUST NOT be used as a source address.

A datagram with this destination address will be received by every host on the connected physical
network but will not be forwarded outside that network.

Furthermore, that same section of RFC1122 also states the following:

"For most purposes, a datagram addressed to a broadcast or multicast destination is processed as if
it had been addressed to one of the host's IP addresses; we use the term "specific-destination
address" for the equivalent local IP address of the host.  The specific-destination address is defined
to be the destination address in the IP header unless the header contains a broadcast or multicast
address, in which case the specific-destination is an IP address assigned to the physical interface on
which the datagram arrived."


As such, I have a few questions that I hope somebody can answer:

1). It appears to me that multihomed hosts i.e., hosts with more than one IP address assigned to a
physical interface (Multiple Logical Hosts and Multiple Logical Interfaces) may have a problem
receiving datagrams containing the limited broadcast address since they would not be able to
determine the "specific-destination address".  Do any other RFCs define this, or is the rule "choose
the first address" assigned to the physical interface?

2). Under what conditions would the limited broadcast address be used over a directed broadcast
address?

3).  Why was the limited broadcast address defined anyway?

4).  Does the definition of the limited broadcast address imply that directed broadcast addresses can
be forwarded? My initial thought on this one is yes.


Thanks in advance.

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 93 00:52:44 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Limited Broadcast Addressing

In article <1993Mar08.232959.16946@rchland.ibm.com> obert@rchland.vnet.ibm.com (Carl Obert) writes:
>As such, I have a few questions that I hope somebody can answer:
>
>1). It appears to me that multihomed hosts i.e., hosts with more than one IP address assigned to a
>physical interface (Multiple Logical Hosts and Multiple Logical Interfaces) may have a problem
>receiving datagrams containing the limited broadcast address since they would not be able to
>determine the "specific-destination address".  Do any other RFCs define this, or is the rule "choose
>the first address" assigned to the physical interface?

Since limited broadcast is not supposed to be forwarded, it should have
originated on the local wire.  The source IP address could be used to
discriminate amoung possible recipients (the idea being that only a
logical IP interface on the same subnet as the source should get the
packet)  This does have problems if the source address is 0.0.0.0.

>2). Under what conditions would the limited broadcast address be used over a directed broadcast
>address?

Either old TCP/IP code, in cases where your IP address is not yet known
(i.e. BOOTP), or where you want to insure that the broadcast remains local
to the wire.

>3).  Why was the limited broadcast address defined anyway?

Partly for above and partly historical.

>4).  Does the definition of the limited broadcast address imply that directed broadcast addresses can
>be forwarded? My initial thought on this one is yes.

Directed broadcast (AKA "letter bombs") may be forwarded depending on the
capabilities and configuration of the routers.  In a subnetted environment,
Directed Subnet Broadcasts are valid, but "Allsubnets Broadcast" has been
deprecated in favor of real IP multicast.

>Thanks in advance.

Art

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 93 02:36:02 GMT
From:      kotmire@net2.ics.uci.edu (Girish Kotmire)
To:        comp.protocols.tcp-ip
Subject:   White-box metrics for network software performance

Hi,
        This is a question regarding measuring performance of network software.
Network software performance can be expressed as two types of metrics:
Black-box (e.g. application throughput, delay) and white-box metrics (e.g.
protocol function execution times, # of retransmissions, packet loss). Hence,
white-box metrics differ in the fact that they reflect the internals of
network software (protocols and their implementation).
        A lot of past work exists on black-box metrics, mainly work on
protocol benchmarks, network promiscuous taps, protocol analyzers. However,
the only work on white-box metrics that I am aware of is the paper by
D. Clark et. al. "An analysis of TCP processing overhead" but this work only
provides instruction counts for protocol functions rather than offering
a tool to measure white-box metrics.
        I am interested in other related work about how people have collected
white-box metrics, and for what purposes. If you are aware of any such work,
especially tools that have been built for this purpose, I would appreciate
hearing from you.
        Thanks,
                Girish

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Mar 1993 04:35:37 GMT
From:      deraadt@fsa.ca (Theo de Raadt)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP NetUnreachable and TCP behaviour?

In article <C31ABt.5oz@watserv1.uwaterloo.ca> erick@demorgan.uwaterloo.ca (Erick Engelke) writes:
>  While TCP offers inherent scalability, the benefits of the system
>  can be greatly enhanced if we allow the TCP to participate in
>  the management of connections based on knowledge of their costs
>  and well selected constants after investigating connectivity patterns.
>
>  Imagine having a file which lists defaults including on and offsite
>  retransmit defaults, on/offsite SYN timeouts, etc.
>  Add to that a second file which lists well known ports and a few 
>  operating characteristics including TTL, timeouts (if any) and 
>  overrides on the above file.  Making these values SNMP queryable
>  will one day help with management and comparing two systems.
>
>  Why should we lower our TCPs to react differently to different
>  connections?  There are several good reasons which come to mind
>  immediately, I hope they are as obvious to others as to me.
>	   - different expectations - X vs. FTP, remote MAN vs. SMTP
>	   - the same issues as source routing for traffic 
>	   - the addition of TCP level security parameters
>	   - the same issues as prioritized routing

I have some experience with Ham radio TCPIP, well, not as a HAM, but
I wrote an AX25 device driver for SunOS.. 

The TNC modems that HAM people are a little bit like ethernet -- they
are capable of listening on the air before they attempt a transmit. But,
they are not capable of listening at the same time as they transmit.

When a collision does happen, and they happen, all the stations know
to backoff for a certain amount of time -- just like ethernet. This
parameter is configurable.

Guess what uses set their own for? They set it low. So low that anyone
who has that parameter set higher loses out (remember, this is a low
bandwidth channel they are operating over). As the parameter starts
being set lower and lower in a region (ie. a city), collisions handling
starts getting worse and worse. People naturally will set it low, because
they want to get a better slice of time. As they do this, everyone starts
to lose.

I myself fear the same thing would happen with TCP. Look, if you give
me parameters like you describe above, I'm going to configure my
machine so that I can ship data faster: I won't have to care if Joe's
rlogins runs slower as long as my ftp's are nice and fast... In it's
current implimentation, TCP is fairshare -- I like that. Let's keep it
that way.
 <tdr.
--

This space not left unintentionally unblank.		deraadt@fsa.ca

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Mar 1993 04:39:16 GMT
From:      deraadt@fsa.ca (Theo de Raadt)
To:        comp.lang.postscript,comp.protocols.tcp-ip
Subject:   Re: HP JetDirect for Unix

In article <C30q76.Hz6@hpchase.rose.hp.com> k@hprnd.rose.hp.com (Steve Kao) writes:
   Jeff Hakner (hak@alf.cooper.edu) wrote:
   > Yeah, wouldn't it be nice if HP did something standard, like LPD or
   > TELNET??  What's so great about their canned software, anyway?

   If the printer has an IP address, you can "telnet <ip_addr> 9100" and
   have whatever you send to that telnet connection printed.  SunOS uses
   LPD and the canned software supports it.  The code was written to run on
   a SunSPARC station.  If you can get a copy of the source, you can
   recompile it for your machine.  The older tapes HP distributed had the
   source on it.  Many people have gotten it to work.

Anyone have one of these printers not behind a router so that I can print
some of rude message on it? porno gifs, etc. :-)

I hope it's got at least some sort of security built into it.......
 <tdr.
--

This space not left unintentionally unblank.		deraadt@fsa.ca

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1993 07:16:52 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: OSPF subnet routing on a Wellfleet

In article <RENS.93Mar8163308@lorax.shearson.com> rens@cs.columbia.edu
(Rens Troost) writes: 
    
    In article <1n7mrtINN4q9@matt.ksu.ksu.edu> rrsum@matt.ksu.ksu.edu (Rick
	Summerhill) writes: 
    
       I have a related question!  RIP puts out routing information that is
       understood by Unix boxes running routed.  Does routed also understand
       the routing information put out by OSPF, or can OSPF be configured to
       output similar information?
    
    No. Use gated; it participates in OSPF.
    
Running OSPF on your hosts is probably NOT a good idea.  Using router
discovery or advertising default with RIP is probably a better idea.
-- 
abyss \*-'bis\ n 
  1 : the bottomless gulf, pit, or chaos of the old cosmogonies  2 a : an 
  immeasurably deep gulf or great space  b : intellectual or spiritual 
  profundity; also : vast moral depravity 3 a Border Intermediate System

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Tue, 09 Mar 1993 14:24:08
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP fragment reassembly timer in FTP Software Inc.

In article <1993Mar8.205029.2221@emr1.emr.ca> fillmore@emr1.emr.ca (Bob Fillmore 992-2832) writes:

    ... Our gateway is using the TCP/IP protocol stack from FTP Software,
    Inc., version 2.05.  Is there any way to increase the IP fragment
    reassembly timer so that we will wait longer for the fragments to arrive?

A couple of points: 2.05 only handled 2 fragments - if the packet was
split into more than 2 fragments, it would not be reassembled.  This changed
in v2.1, and we now handle as many fragments as RFC 791 allows.  We still
won't reassemble an incoming IP packet larger than the MTU of the attached
network, though.

When a fragment was received, v2.05 waited 60 seconds for subsequent
fragments to arrive.  I'd normally assume that if a 2nd fragment
hadn't arrived in that time, it was probably lost.  At any rate the
timeout isn't settable.  You might want to try a v2.1 kernel and see
if your problem isn't in fact multiple fragments, rather than a
too-short timeout.  If the problem is that the foreign host isn't
honoring the TCP Maximum Segment Size option we send, this is hard to
fix on our end...

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


-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 93 09:24:28 GMT
From:      ARAGON@Materna.DE (Jorge Aragon-Garcia)
To:        comp.protocols.tcp-ip
Subject:   tn3270 spec ??

Hello,

I am searching for a tn3270 specification. Can anyone please point to a 
documentation or a place where to find stuff about it??

Thanks, Jorge
_____________________________________________________________________________
   \                     /   work: +49 231 5599 303   \    To boldly     /
    )   Jorge Aragon    (     fax: +49 231 5599 100    )   go where     (
   /  aragon@Materna.DE  \   home: +49 2304 14222     /    no man has    \
  /                       \  home: +49 2304 15427    /     gone before!   \

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1993 20:33:59 -0600
From:      karl@genesis.MCS.COM (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   Re: Guaranteed Unused IP Network?

In article <1993Mar9.235009.978@aio.jsc.nasa.gov> poirot@widget.jsc.nasa.gov (Daniel Poirot) writes:
>In article <mam-090393121426@192.158.86.2> mam@gvgspd.gvg.tek.com (Mark A. Matthews) writes:
>>
>>Is there a network number reserved that should be used for isolated
>>networks which are never supposed to be connected to the Internet itself,
>>yet would allow for easy detection and isolation if someone
>>accidently/ignorantly did so?
>
>I think that the 129.0.0 subnet is reserved for testing.  Our Silicon
>Graphics machines come out of the box with IP numbers like 129.0.0.x.

I've always liked "2." myself.  Just don't let it out of your own systems,
or you will <definately> raise some eyebrows :-)

--
Karl Denninger (karl@genesis.MCS.COM) 	| You can never please everyone except
Data Line: [+1 312 248-0900]		| by bankrupting yourself.
         	   LIVE Internet in Chicago; an MCSNET first!


-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 93 18:55:24 -0500
From:      harvey@indyvax.iupui.edu
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Re: MacTCP doesn't do Fast Retransmit??

In article <sdorner-080393171648@192.17.5.2>, sdorner@qualcomm.com (Steven Dorner) writes:
> Amanda Walker wrote:
>> So far as I know, Apple's plans are only to add to MacTCP, not overhaul its
>> internals.  While I sympathize with the folks in ESD who have to deal with
>> MacTCP, the status quo leaves something to be desired.
>
> MacTCP was a wonderful thing when it was cheap.  Yes, it had some warts,
> but it was still wonderful.
>
> Now that Apple wants big bux for it, it's ABSOLUTELY LUDICROUS that they're
> going to bundle SNMP (SNMP?  Who gives a damn?) but not fix all these
> problems.

Well, a couple of years ago I was inquiring about alternative TCP/IP stacks
for the Mac (we needed IP over token ring, which MacTCP didn't support yet)
and was told by a certain third-party TCP/IP stack vendor that there weren't
any simply because Apple sold MacTCP so cheaply that none of the network
software companies could compete with it.

Perhaps this may change?  It might be too late for it now though...

> I really don't know what planet those people are from, but it sure ain't
> Earth.
--
James Harvey    IUPUI OIT Technical Support -- VMS/Unix/Networks
harvey@iupui.edu  uucp:iugate!harvey  bitnet:harvey@indyvax

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 93 13:50:41 GMT
From:      marmary@kaa.informatik.rwth-aachen.de (Mahmoud-Reza Nazeman)
To:        comp.protocols.tcp-ip
Subject:   Experiments with TCP Extensions (RFC1072/RFC1185/RFC1323 or RFC1106)

Has anyone made some experiments or research with the TCP Extensions proposed
in RFC1072/RFC1185 [RFC1323] or the (almost) forgotten RFC1106 [NAK Option]?
From where can the test results/papers be obtained from?

(I have already got the technical report of Thomas Skibo from the University of
 Illinois, available via anonymous ftp:

	Host: uxc.cso.uiuc.edu
	File: /pub/tcplw.shar.Z

It's a shar file containing a PostScript file of the tech report as
well as a patch file for Net-2 BSD TCP.)

-marmary		Technical University of Aachen, Germany



-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Mar 1993 13:51:35 GMT
From:      tek@ms.uky.edu (Thomas E. Kunselman)
To:        comp.protocols.tcp-ip
Subject:   How do I convert tcpip software that uses NDIS to packet drivers

Could someone give me a pointer to where I can get some software that
will allow me to convert this NDIS thing to use packet drivers.  The
documentation I got with the tcp-ip software merely said that there is
a program available to do this in the public domain.  However, checking
archie with ndis didn't get me anything.  

I have LAN software that uses packet drivers, so I need this tcp-ip stuff
to do the same so I can use both at the same time.

Direct e-mail will be summarized for the net.

Thanks.
-- 
Thomas Kunselman                               {rutgers,uunet}!ukma!tek 
Office of Planning & Assessment          	bitnet: vaatek@ukcc.bitnet
#8 Administration Building			internet:tek@ms.uky.edu
University of Kentucky

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Mar 1993 15:40:07 GMT
From:      rmorley@mis.mi04.zds.com (Ron Morley)
To:        comp.protocols.tcp-ip
Subject:   Need help installing SLIP on Bull DPX/2

Hi netters,
    I need to setup SLIP on a Bull DPX/2 using BOS 2.0.45 (Bull's version of
UNIX).  I have never done anything like this and would appreciate any pointers
you might have.  I plan on running SLIP over a 9600 baud modem if that makes
any difference.

Thanks in advance,
Ron Morley
Zenith Data Systems
St. Joseph, MI.


Disclaimer: My opinions are my own...no one else wants them.

"Never underestimate the power of human stupidity"  Lazarus Long


-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Mar 93 17:00:11 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on OCS to MVS gotchas

We have the OCS II product on an RS6000.  Currently, we don't have
enough memory and the process crashes once and a while.  Supposedly,
this will be resolved when we buy boxes with 64MB of memory.  Other than
that, response time is good and the users generally like the service.

We use the IBM 3172 for file transfer and program to program.  The OCS
box is a telnet server only.

Charles.

--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IS&DP Network Services		AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 93 20:02:12 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Ip Addressing Question

In article <1n5ptg$fca@calvin.NYU.EDU> roy@mchip00.med.nyu.edu (Roy Smith) writes:
>Sounds just like AppleTalk Phase-II net ranges.

It's not.  Supernets can be expressed with a bitmask that is remarkably
similar to a subnet mask.  ATalk net ranges are defined with two network
numbers, not a bitmask.

Side-effects of the bitmap approach include the following:
 - Host implementations can already deal with it thanks to the existing
   netmask mechanism.  (Implementations that sanity-check the netmask
   might need tweaking, but the changes are not major.)
 - The network range must start on a power of 2.  Its length must be a
   power of 2.

You're right that they are similar, at least in intent, but the decision
to use a mask instead of a range does make the mechanics different.

-- 
Stephen Trier                      "They didn't seem to be acting out of
Network software type               malice, but they were, at best,
Case Western Reserve University     differently clued."
trier@ins.cwru.edu                        - John Perry Barlow

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1993 20:14:47 GMT
From:      mam@gvgspd.gvg.tek.com (Mark A. Matthews)
To:        comp.protocols.tcp-ip
Subject:   Guaranteed Unused IP Network?


Is there a network number reserved that should be used for isolated
networks which are never supposed to be connected to the Internet itself,
yet would allow for easy detection and isolation if someone
accidently/ignorantly did so?


-Mark

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Tue, 09 Mar 1993 20:38:11 GMT
From:      matt@lachman.com (Matt Harper)
To:        comp.protocols.tcp-ip
Subject:   Sockets Test Suite

Hi,

Does anyone know of a public domain sockets test suite?


Thanks in advance,

-- 
Matthew Harper                                  Telephone: 708-505-9555 X317
Lachman Technology Inc.                         Fax:       708-505-9574
1901 N. Naper Blvd.                             Internet:  matt@lachman.com
Naperville, IL 60563 USA


-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 93 21:11:09 GMT
From:      jbvb@vax.ftp.com (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Guaranteed Unused IP Network?

In article <mam-090393121426@192.158.86.2> mam@gvgspd.gvg.tek.com (Mark A. Matthews) writes:

    Is there a network number reserved that should be used for isolated
    networks which are never supposed to be connected to the Internet itself,
    yet would allow for easy detection and isolation if someone
    accidently/ignorantly did so?
    
A lot of sites that started off with Excelan code wound up using net
89.0.0.0, which Excelan didn't formally own, but I don't know the whole
history.  Likewise, a lot of Sun sites use 192.9.1.0 (which Sun does
own).  The examples in our own manuals all use a "reserved" subnet of
our own Class B, and we occasionally see incoming packets.  If it wasn't
for 4bsd's internal use of net 127.0.0.0, the fact that routers aren't
supposed to ever forward packets to/from it would make it ideal...

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

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 93 22:23:12 GMT
From:      carr@acsu.buffalo.edu (David J. Carr)
To:        comp.protocols.tcp-ip
Subject:   Terminal Emulation



	I am looking for a full color IBM terminal emulator (3179 or
similar) which also has local printing and file transfer capabilities.
Presently we are using Novell's wslan SNA gateway product; what I
would like is a solution that uses IP instead of IPX and preferably
runs on both DOS and Unix (SunOS) platforms.  I've been told that the
solution I am looking for doesn't exist, so any pointers will be
useful...



-- 

David Carr                                               104D Computing Center 
carr@acsu.buffalo.edu                        University of New York at Buffalo

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 93 22:44:01 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Guaranteed Unused IP Network?

In article <mam-090393121426@192.158.86.2>, mam@gvgspd.gvg.tek.com (Mark A. Matthews) writes:
> 
> Is there a network number reserved that should be used for isolated
> networks which are never supposed to be connected to the Internet itself,
> yet would allow for easy detection and isolation if someone
> accidently/ignorantly did so?


Besides 127, there is 192.0.2 which is officially registered and intended
for just such uses.

In case you don't believe me (and you should not believe anything
you read in the netnews without substantial independent confirmation),
try whois:

]  whois 192.0.2
]  IANA (NET-TEST)
]  
]     Netname: TEST
]     Netnumber: 192.0.2.0
]  
]     Coordinator:
]        Reynolds, Joyce K.  (JKR1)  JKRey@ISI.EDU
]        (310) 822-1511
]  
]     Record last updated on 03-Jan-91.



Vernon Schryver,  vjs@sgi.com

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 93 00:00:06 GMT
From:      mischler@norman.li.cubic.com (Dave Mischler)
To:        comp.protocols.tcp-ip
Subject:   Re: OSPF subnet routing on a Wellfleet

In article <1nhg94INN855@cronkite.cisco.com> tli@cisco.com (Tony Li) writes:

> Running OSPF on your hosts is probably NOT a good idea.  Using router
> discovery or advertising default with RIP is probably a better idea.

Could you please elaborate, or point the unenlightened at some documents
to help enlighten them?

Thanks.

Dave Mischler
mischler@cubic.com

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1993 00:15:38 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Limited Broadcast Addressing

In article <1993Mar08.232959.16946@rchland.ibm.com> obert@rchland.vnet.ibm.com (Carl Obert) writes:
>1). It appears to me that multihomed hosts i.e., hosts with more than one IP address assigned to a
>physical interface (Multiple Logical Hosts and Multiple Logical Interfaces) may have a problem
>receiving datagrams containing the limited broadcast address since they would not be able to
>determine the "specific-destination address".  Do any other RFCs define this, or is the rule "choose
>the first address" assigned to the physical interface?

That seems as reasonable as any.  Another possibility would be for the host
to treat the packet as multiple logical packets, one for each address
connected to the interface.

>2). Under what conditions would the limited broadcast address be used over a directed broadcast
>address?

A host that doesn't yet know its subnet number might use it, for instance
in its BOOTP broadcast or a TFTP broadcast looking for a boot image.

It's also sometimes used to get around other limitations.  For instance,
when we had an interface on our cisco configured with multiple logical
subnets, we couldn't configure it to send directed broadcasts on that
interface because only one broadcast address could be configured (not one
for each logical subnet).  So we configured it to send the limited
broadcast address instead.

>3).  Why was the limited broadcast address defined anyway?

See answer to 2.

>4).  Does the definition of the limited broadcast address imply that directed broadcast addresses can
>be forwarded? My initial thought on this one is yes.

I think they're supposed to be.  In general, any packet whose
network/subnet portion is not the local subnet should be forwarded without
looking at the host portion.  In particular, a host/gateway outside a
network should not be able to recognize subnet broadcast addresses, since
it doesn't know the subnet mask on that network, so it should at least be
forwarded as far as the gateway that enters that subnetted network.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Mar 1993 01:02:15 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Guaranteed Unused IP Network?

In article <ghu8cnu@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>Besides 127, there is 192.0.2 which is officially registered and intended
>for just such uses.
>
>In case you don't believe me (and you should not believe anything
>you read in the netnews without substantial independent confirmation),
>try whois:
>
>]  whois 192.0.2
>]  IANA (NET-TEST)
>]  
>]     Netname: TEST
>]     Netnumber: 192.0.2.0
>]  
>]     Coordinator:
>]        Reynolds, Joyce K.  (JKR1)  JKRey@ISI.EDU
>]        (310) 822-1511
>]  
>]     Record last updated on 03-Jan-91.

I fail to see how this confirms your statement.  So there's a net
192.0.2.0 named TEST coordinated by Joyce.  So what?  If this address
is so special, why isn't it *documented* anywhere?  Just the kind of
insider information that gives TCP/IP a bad name....

						don provan
						donp@novell.com

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Mar 1993 01:22:38 GMT
From:      Christopher.Vance@adfa.oz.au (Christopher JS Vance)
To:        comp.protocols.tcp-ip
Subject:   Re: Guaranteed Unused IP Network?

In article <mam-090393121426@192.158.86.2> mam@gvgspd.gvg.tek.com (Mark A. Matthews) writes:
| Is there a network number reserved that should be used for isolated
| networks which are never supposed to be connected to the Internet itself,
| yet would allow for easy detection and isolation if someone
| accidently/ignorantly did so?

That sounds like a good idea.  Maybe it's even been done.  If not,
perhaps somebody should apply to the NIC to have a class A network
dedicated to this use (say 126.0.0.0?).  Then when the NIC stops
allocating class B addresses to lots of places and says `you can have
a class C address and hide everything else behind it', things will be
guaranteed to work.  (Until you connect two of these together....)

-- Christopher

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Mar 1993 02:00:57 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Guaranteed Unused IP Network?

In article <1993Mar9.235009.978@aio.jsc.nasa.gov>, poirot@widget.jsc.nasa.gov (Daniel Poirot) writes:
> In article <mam-090393121426@192.158.86.2> mam@gvgspd.gvg.tek.com (Mark A. Matthews) writes:
> >
> >Is there a network number reserved that should be used for isolated
> >networks which are never supposed to be connected to the Internet itself,
> >yet would allow for easy detection and isolation if someone
> >accidently/ignorantly did so?
> 
> I think that the 129.0.0 subnet is reserved for testing.  Our Silicon
> Graphics machines come out of the box with IP numbers like 129.0.0.x.
> -- 
> Daniel Poirot           poirot@aio.jsc.nasa.gov
> NASA JSC                "The mind is a terrible thing."
> ER3                     tel: (713)483-8793
> Houston, TX 77058       fax: (713)483-3204



I really hope (and think) that that's wrong, that all Silicon Graphics
machines come out of the box with /etc/sys_id containing "IRIS\n" and
the following line in /etc/hosts:

192.0.2.1       IRIS

There is supposed to be code in various places (e.g.  /etc/init.d/network)
to keep the system from turning on the network stuff if the IP address
is 192.0.2.1


vjs

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1993 02:10:45 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP doesn't do Fast Retransmit??

In article <C3Ky65.5pF@riverside.mr.net> tmplee@TIS.COM (Theodore M.P. Lee) writes:
>Could that explain why every now and then what is normally
>quite a good connection seems to "freeze up" for 5-10
>seconds?

Into every connection some bit-errors will fall.  ;-)

If the MacTCP retransmission timer is as bad as some have said, that 5-10
second delay would be perfectly accounted for by an error somewhere along
your link which causes a TCP packet to get dumped because of a bad checksum.
It then takes 5-10 seconds for MacTCP to figure out that the packet was
lost and retransmit.

I'd expect such occurences to be rare but randomly distributed.  It's really
nothing to worry about -- everything is working as it should.  If it is
irritating, try improving the connection by using V.42, shortening and
shielding the serial connection, and using hardware flow control if you are
not already.

-- 
Stephen Trier                      "They didn't seem to be acting out of
Network software type               malice, but they were, at best,
Case Western Reserve University     differently clued."
trier@ins.cwru.edu                        - John Perry Barlow

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 93 04:05:56 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Guaranteed Unused IP Network?

In article <1993Mar10.010215.16958@novell.com>, donp@novell.com (don provan) writes:
> 
> I fail to see how this confirms your statement.  So there's a net
> 192.0.2.0 named TEST coordinated by Joyce.  So what?  If this address
> is so special, why isn't it *documented* anywhere?  Just the kind of
> insider information that gives TCP/IP a bad name....


You mean like the bad name given a certain PC protocol because its
corporate proprietor is somewhat reticent?


Yeah, someone should add text to the successor of RFC 1166 about 192.0.2.

Do you think that would affect the number of people who don't know
about 192.0.2?--I don't.  If you think to ask the question and look at
RFC-1166, you do get a broad hint from the only network labeled
unqualifiedly "TEST".  One could look up "JBP", and drop him a note
asking if you've guessed right.

It's been only about 3 months since the same question about 192.0.2
last came up, and several people answered it, including Jon Postel.


Vernon Schryver,  vjs@sgi.com

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Mar 1993 05:36:26 GMT
From:      hachec@ERE.UMontreal.CA (Greg Patterson)
To:        comp.protocols.tcp-ip
Subject:   Socket connections failing.

Hello,

I have been learning as much as I can about sockets (and TCP/IP) and I have
a program which I have *working* but it will eventually lose the connection
over long periods of time.  I've tried everything I can think of but I am
unable to figure out program wise when the connection has been lost.  When
the connection is lost, the program gets hung on the read() call.  I've
setup the socket to SO_KEEPALIVE with:

  setsockopt(s, SOL_SOCKET, SO_KEEPALIVE, 0, 0);
  signal(SIGPIPE, sig_timeout);

but it doesn't seem to help.  I haven't seen my handler called yet.

What is required in order for me to detect when the connection has been 
lost?  Is it in errno or what?  Any source code examples would be
appreciated..

Thanks. 
-- 
############################################################################
# Christina Hache    IRC: Chrystina # Internet:                            #
# & Greg Patterson        Wizard    #   hachec@tornade.ere.umontreal.ca    #
############################################################################

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Mar 1993 05:43:05 GMT
From:      ptrubey@netcom.com (Phil Trubey)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP doesn't do Fast Retransmit??

In article <1njin5INNt4l@usenet.INS.CWRU.Edu> trier@odin.ins.cwru.edu (Stephen C. Trier) writes:
>In article <C3Ky65.5pF@riverside.mr.net> tmplee@TIS.COM (Theodore M.P. Lee) writes:
>>Could that explain why every now and then what is normally
>>quite a good connection seems to "freeze up" for 5-10
>>seconds?
>
>Into every connection some bit-errors will fall.  ;-)
>
>If the MacTCP retransmission timer is as bad as some have said, that 5-10
>second delay would be perfectly accounted for by an error somewhere along
>your link which causes a TCP packet to get dumped because of a bad checksum.
>It then takes 5-10 seconds for MacTCP to figure out that the packet was
>lost and retransmit.
>
>I'd expect such occurences to be rare but randomly distributed.  It's really
>nothing to worry about -- everything is working as it should.  If it is
>irritating, try improving the connection by using V.42, shortening and
>shielding the serial connection, and using hardware flow control if you are
>not already.

Won't help.  The *other* reason for dropped packets is congestion
on the internetwork.  Congestion is a fact of life on the 
Internet, so MacTCP will always be horrible to use for telnet over
the Internet until this problem is fixed.

Kind of makes you wonder why Apple even bothered to make MacTCP a standard.
-- 

Phil Trubey                   | Internet: ptrubey@netcom.com
Systemhouse Inc.              | Voice:    415-327-8337
                              | Fax:      415-243-0471

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Mar 1993 05:44:18 GMT
From:      eliotb@rpi.edu (Brian Eliot)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP doesn't do Fast Retransmit??

In article <1njin5INNt4l@usenet.INS.CWRU.Edu> trier@odin.ins.cwru.edu (Stephen C. Trier) writes:
>If the MacTCP retransmission timer is as bad as some have said, that 5-10
>second delay would be perfectly accounted for by an error somewhere along
>your link which causes a TCP packet to get dumped because of a bad checksum.
>It then takes 5-10 seconds for MacTCP to figure out that the packet was
>lost and retransmit.
>
>I'd expect such occurences to be rare but randomly distributed.  It's really
>nothing to worry about -- everything is working as it should.  If it is
>irritating, try improving the connection by using V.42, shortening and
>shielding the serial connection, and using hardware flow control if you are
>not already.

Except that 5-10 second delay is not reasonable if the TCP RTT on a SLIP
connection is two seconds or less.  Actually the MacTCP retransmission
timeout is more on the order of 20-30 seconds as suggested previously.

Even if your SLIP serial connection is perfect, packets do get lost once
they get onto an Ethernet on the other side of the SLIP server.  Even a
1% packet loss rate is intolerable with this length of retransmission
timeout.

The problem is in fact worse than described up to now.  If you continue
to type, e.g., into a Telnet window following a lost packet and while
waiting for MacTCP to resynchronize its sequence numbers, eventually the
TCP send queue fills with single-keystroke packets and the entire Mac
hangs up.  At that point nothing--not your keyboard, not your mouse--
works.

Brian Eliot
Information Technology Services
Rensselaer Polytechnic Institute

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Mar 1993 07:46:02 GMT
From:      Theodore M.P. Lee <tmplee@TIS.COM>
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP doesn't do Fast Retransmit??

In article <qav4wpr@rpi.edu> Brian Eliot, eliotb@rpi.edu writes:
> 
> Even if your SLIP serial connection is perfect, packets do get lost once
> they get onto an Ethernet on the other side of the SLIP server.  Even a
> 1% packet loss rate is intolerable with this length of retransmission
> timeout.
> 
I don't know if it's comforting to know what the problem is, and
not be able to do anything about it, or not to know and keep
wondering!  After having read this chain I turned on HydePark's
netstat and watched the counters as I was transferring a couple
of large files with Fetch.  Sure enough, the behaviour is exactly
as described.  The packets would flow nicely for awhile, then
stop.  After almost precisely 18 seconds the sendTries counter
would step up to 2, 3, 4  and maybe even 5 or 6 once or twice and
then things would proceed.   It was almost uncanny how precise
the 18 second delay was;  I probably observed it a half dozen times.
carefully.  When it was all done the connection showed 
325K bytes/624 packets sent, 10K bytes/18 packets
resent.  The total tcp statistics from whenever the counters
started was 680K bytes/5600 packets sent, 36K bytes/82 packets
resent.   Can't somebody ask Apple where the "18" (or whatever number
it is that generates the delay) is in the code and try patching it
to, say, something like 2-5 (or the equivalent)?

Ted Lee <tmplee@tis.com or tmplee@mr.net>

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1993 08:10:35 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: OSPF subnet routing on a Wellfleet

    In article <1nhg94INN855@cronkite.cisco.com> tli@cisco.com (Tony Li)
    writes: 
    
    > Running OSPF on your hosts is probably NOT a good idea.  Using router
    > discovery or advertising default with RIP is probably a better idea.
    
    Could you please elaborate, or point the unenlightened at some documents
    to help enlighten them?
    
Sure.  First I should be really careful about my wording.  There are two
cases that you can make use of.  First, hosts can simply wiretap on OSPF
packets to determine where the routers are.  OSPF exchanges hello packets
between routers periodically to determine adjacency.  Just sniffing these
and pointing default at a router that you learn this way is probably not a
big deal.  

What you _don't_ want to do is to have your singly homed hosts (i.e.,
definitely NOT routers) participate in the OSPF system.  OSPF is much more
complex than RIP, and all routers on a subnet have to know about all others
and maintain a routing database and adajency information for each neighbor.
What this means is that your host would have to spend more cycles and burn
more memory than with RIP.  It would also impact on your routers, which
would also have to store adjacency information.  

In short, it's a solution that doesn't scale.  You can put hundreds of
hosts on an Ethernet and have them listen to RIP without a problem.
Hundreds of hosts running OSPF on a single Ethernet is extremely unlikely
to ever work.

-- 
abyss \*-'bis\ n 
  1 : the bottomless gulf, pit, or chaos of the old cosmogonies  2 a : an 
  immeasurably deep gulf or great space  b : intellectual or spiritual 
  profundity; also : vast moral depravity 3 a Border Intermediate System

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 93 08:16:00 GMT
From:      evans@ubvmsb.cc.buffalo.edu (Doug Evans - CIT Communication Systems)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibm.pc
Subject:   Re: 3c509 version 10.1 packet driver problem in fast pc's

In article <Hendrik.Klompmaker.1.731086490@beheer.zod.wau.nl>, Hendrik.Klompmaker@beheer.zod.wau.nl (Hendrik Klompmaker) writes...

[Stuff deleted]

>I have a 486 DX2 50Mhz ISA clone machine that misses his 3c509 5 out of 10 
>times when the packet driver is loaded. It complains about no 3c509 card 
>found and suggest to use a different id_port value. 

[Stuff deleted]

>BTW. I didn't load the driver high and used Io port 300, Irq 5 and packet  
>     driver int 7f.

This may answer your question, it's a portion of Russ Nelson's read.me 
file that comes with ver 10.1:

{
  The driver needs an initial ID port to access the 3C509 hardware. The
  driver uses a default of 0x110 for the ID port.  If you have a
  conflict at port 0x110 (very few machines do), the packet driver will
  be unable to initialize the adapter, so try specifying a different
  value as the second parameter.  ID port must be 0x100, 0x110, 0x120,
  ..., 0x1f0.
}

You should change the id_port setting.  



Doug
--
                                  |                              Doug Evans
                                  | State University of New York at Buffalo
                                  |             evans@ubvmsb.cc.buffalo.edu

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1993 22:10:39 -0800
From:      allyn@sdd.hp.com (Allyn Fratkin)
To:        comp.lang.postscript,comp.protocols.tcp-ip
Subject:   Re: HP JetDirect for Unix

> Anyone have one of these printers not behind a router so that I can print
> some of rude message on it? porno gifs, etc. :-)
>
> I hope it's got at least some sort of security built into it.......

it does.  you can define access lists of networks and/or hosts that
can connect to the printer.  unacceptable hosts receive a connection
refused message, i believe.

of course, who knows how many people actually bother to set up
the access lists...

not an official statement of hp.
-- 
 From the virtual mind of Allyn Fratkin            allyn@sdd.hp.com
                          San Diego Division       - or -
                          Hewlett-Packard Company  uunet!ucsd!hp-sdd!allyn

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 93 08:52:58 GMT
From:      matheys@online.cern.ch (Jean-Pol Matheys)
To:        comp.protocols.tcp-ip
Subject:   Re: Socket connections failing.


In article <1993Mar10.053626.6777@cc.umontreal.ca>, hachec@ERE.UMontreal.CA (Greg Patterson) writes:

>I have been learning as much as I can about sockets (and TCP/IP) and I have
>a program which I have *working* but it will eventually lose the connection
>over long periods of time.  I've tried everything I can think of but I am
>unable to figure out program wise when the connection has been lost.  When
>the connection is lost, the program gets hung on the read() call.  I've
>setup the socket to SO_KEEPALIVE with:
>
>  setsockopt(s, SOL_SOCKET, SO_KEEPALIVE, 0, 0);
>  signal(SIGPIPE, sig_timeout);
>
>but it doesn't seem to help.  I haven't seen my handler called yet.
>

This is a problem I've had as well. I haven't found any simple solution yet.
One solution,  which I consider non-simple (and which I cannot use on OS-9),
was suggested by R. Stevens (whose "Unix Network Programming" I recommend to
everyone):  add a server-like behavior to your client  i.e. use the select()
call to find-out when data arrives on the socket (from the server) and check
for EOF when attempting to read that data (this EOF means that the other end
has died or aborted).  Now, as select()  either introduces a delay (when its
timeout parameter is non-NULL)  or blocks your program (when this timeout is
NULL), this mechanism adds (most probably) unwanted delays or it changes the
overall behavior of your program.  To avoid this, you may fork a sub-process
to handle this, which signals its parent whenever it sees that the other end
has died. This is what I consider a non-simple solution. 

As far as SO_KEEPALIVE is concerned, I have found no use for it yet. Just as
you say, I've never seen SIGPIPE generated independently of program activity
(i.e. SIGPIPE is generated only upon a socket-related function failure). I'd
like to know if anyone has seen it being generated spontaneously, within any
reasonable time of the other end severing the connection.

I would be more than happy if somebody can provide a simple solution to this
problem, or explain how to make good use of SO_KEEPALIVE to me.

--
Jean-Pol Matheys

CERN - European Laboratory for Particle Physics    |   Jean-Pol.Matheys@cern.ch
ECP Division  /  Data-acquisition Systems Group    |   matheys@online.cern.ch
CH-1211 Geneva 23                   Switzerland    |   online::matheys

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Mar 1993 09:03:37 GMT
From:      scornd5@solomon.technet.sg (Ng Wee Teck)
To:        comp.protocols.tcp-ip
Subject:   Control of IP address

I am looking for some means which can be done to prevent users from

changing the IP address of his/her PC and workstations. This is to

facilitate a central control of IP address assignment. Pls email to me

at scornd5@solomon.technet.sg. Thanks in advance.



-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 93 10:27:54 GMT
From:      simatic@aar.alcatel-alsthom.fr (Michel Simatic)
To:        comp.protocols.tcp-ip
Subject:   Rate of undetected errors with TCP (and UDP)

Hi,

I am looking for figures giving the rate of undetected errors with TCP
and UDP used on an Ethernet.

Let me explain my problem : both protocols use checksums to detect
data corrupted during transfer from one process to another. Now, how
many errors (compared to the number of bytes transfered) are not
detected by those checksums ?

Thanks in advance.



======================================================              __
| Michel SIMATIC                                     |              \/
| Alcatel Alsthom Recherche                          |       +--------------+
| Route de Nozay, 91460 MARCOUSSIS, FRANCE           |       |A L C /\ T E L|
| Voice : +33 1 64 49 13 73   Fax: +33 1 64 49 17 89 |       +--------------+
| E-mail: simatic@aar.alcatel-alsthom.fr             |        A L S T  H O M
|                                                    |       ================
| Always look at the bright side of life !           |           RECHERCHE	
|                             Monty Python           |     
======================================================

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Mar 1993 10:33:00 GMT
From:      elelko@nuscc.nus.sg (Kwok-Onn Looi)
To:        comp.protocols.tcp-ip
Subject:   WinQVT/Net 3.22

[ Article crossposted from comp.protocols.tcp-ip.ibmpc ]
[ Author was Kwok-Onn Looi ]
[ Posted on Wed, 10 Mar 1993 10:31:38 GMT ]


To those who have managed to get their QVT working, perhaps you can help
clarify the following observations. Is posting supported on this
version, despite the being documented in the readme ? In addition,
binary printing does not seem to work yet for this version even though
the switches have been included .. gave a 'lpr: write_err block'
message.

But I must say the features here are good improvements from the previous
ver 3.16.

Pls respond by email or posting. Thanks.

 
=========================================================================

Looi Kwok Onn
National University of Singapore.      "Jim, I have no ego to satisfy",
elelko@nuscc.nus.sg                     Spock.
elelko@nusvm.bitnet

=========================================================================


-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Mar 93 19:02:19 PST
From:      kevin@netlink.cts.com (Kevin Dorne)
To:        comp.protocols.tcp-ip
Subject:   Internet FTP

I have telnet access on the Internet, but not the FTP program.  I can 
type : 
Telnet wuarchive.wustl.edu ftp, and it connects me to the ftp port of the
archive server.  How can I get files?  These are the available commands: 
help 
214-The following commands are recognized (* =>'s unimplemented).
   USER    PORT    STOR    MSAM*   RNTO    NLST    MKD     CDUP 
   PASS    PASV    APPE    MRSQ*   ABOR    SITE    XMKD    XCUP 
   ACCT*   TYPE    MLFL*   MRCP*   DELE    SYST    RMD     STOU 
   SMNT*   STRU    MAIL*   ALLO    CWD     STAT    XRMD    SIZE 
   REIN*   MODE    MSND*   REST    XCWD    HELP    PWD     MDTM 
   QUIT    RETR    MSOM*   RNFR    LIST    NOOP    XPWD  214 Direct 
comments to
ftp-bugs@wuarchive.wustl.edu.

This is my status, if it helps you: stat 211-wuarchive.wustl.edu FTP 
server
status:
     Version 1.2WU(50) Tue Mar 9 09:40:50 CST 1993
     Connected to sdacs.ucsd.edu (132.239.50.100)
     Logged in anonymously
     TYPE: Image; STRUcture: File; transfer MODE: Stream
     No data connection 211 End of status
 
to
contact me is to send e-mail to  kevin@netlink.cts.com            or to 
send me
mail on Admiral Amiga bbs. Thank you.

--                    
INTERNET:  kevin@netlink.cts.com (Kevin Dorne)
UUCP:   ...!ryptyde!netlink!kevin
NetLink Online Communications * Public Access in San Diego, CA (619) 453-1115

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Mar 1993 13:42:09 GMT
From:      jtw@mbunix.mitre.org (Wittbold)
To:        comp.protocols.tcp-ip
Subject:   Unrecognized options

  Does anyone know the gateway reponses to unregnized options? They
should be silently ignored according to some sources however I am not
sure that that is what really happens. Since I am new to this please
respond via email.

                             Todd Wittbold
                             jtw@mbunix.mitre.org

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 93 15:55:36 GMT
From:      marmary@tschil.informatik.rwth-aachen.de (Mahmoud-Reza Nazeman)
To:        comp.protocols.tcp-ip
Subject:   SATNET Measurement Taskforce on TCP/IP performance?

"Crowcroft, J., draft report of the SATNET Measurement Taskforce on TCP/IP
 performance over the SATNET, University College London, London, 1988   "

Can anyone help me?
Does anyone know how I can receive this report?

Thanks in advance,

-marmary		Technical University AACHEN, Germany
			e-mail: marmary@brand.informatik.rwth-aachen.de


-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 93 16:17:47 GMT
From:      dricejb@drilex.dri.mgh.com (Craig Jackson)
To:        comp.protocols.tcp-ip
Subject:   Re: Guaranteed Unused IP Network?

In article <930309161109@cream.ftp.com> jbvb@ftp.com writes:
>In article <mam-090393121426@192.158.86.2> mam@gvgspd.gvg.tek.com (Mark A. Matthews) writes:
>
>    Is there a network number reserved that should be used for isolated
>    networks which are never supposed to be connected to the Internet itself,
>    yet would allow for easy detection and isolation if someone
>    accidently/ignorantly did so?
>    
>A lot of sites that started off with Excelan code wound up using net
>89.0.0.0, which Excelan didn't formally own, but I don't know the whole
>history.  Likewise, a lot of Sun sites use 192.9.1.0 (which Sun does
>own).  The examples in our own manuals all use a "reserved" subnet of
>our own Class B, and we occasionally see incoming packets.  If it wasn't
>for 4bsd's internal use of net 127.0.0.0, the fact that routers aren't
>supposed to ever forward packets to/from it would make it ideal...
>
>James B. VanBokkelen

Isn't 126.0.0.0 normally characterized as "Marsnet"?  I've seen more
than one product which used that number.

Actually, it would be good to standardize such a usage.  We're using
a perfectly legal Class B here, but you'll never see packets for
152.64 on the Internet.  That's because we're behind an application-level
firewall which doesn't pass packets.  However, we could just as easily
use 126.0.0.0 for everything behind the firewall, and we could talk to
anybody except that particular net.  (The firewall isn't that fancy,
and couldn't distinguish an "inside" 126 packet from an "outside" 126
packet.  I believe that such a firewall could be written, however.)

If we were using net 126 behind our firewall, we could still talk to another
site using net 126 internally, as long as they were behind a similar
firewall.

I believe that at least one of the proposals to enlarge the IP address
space is similar to this.  However, simply standardizing on a net like
126 as a behind-nonforwarding-firewall net right now might solve some
problems.

BTW, our firewall is ANS' Interlock product.
-- 
Craig Jackson -- cjackson@mgh.com (Straight Internet)
dricejb@drilex.dri.mgh.com (uucp-forwarded)
{bbn,alliant,redsox}!drilex!{dricej,dricejb}

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1993 16:22:18 GMT
From:      alpham@nic.cerf.net (John Riblett)
To:        comp.protocols.tcp-ip
Subject:   Handling 8-bit chars in telnet?

Could someone point me to the document which deals with 8-bit international
characters in TELNET?  I'm sure it's been discussed before.  I need to know
the proper (or most often encountered) method for our overseas customers.
As far as I can tell the choices are 1) just pass 'em through, which is
not to spec although may be the way it's been done, or 2) negotiate a binary
session, which may have other ramifications.  Thanks!


-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Mar 1993 16:58:16 GMT
From:      ptrubey@netcom.com (Phil Trubey)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP doesn't do Fast Retransmit??

Well, Intercon, or whoever else, this is a perfect opportunity to make
some money in the Macintosh TCP market here.  If someone were to
come across with a commercial version of a TCP stack that had the same
APIs as MacTCP (so that it would be compatible with TheNews, Eudora,
Nuntius, etc), and it fixed the severe TCP problems that macTCP has,
I would buy it in a second.  Alternatively, such a company could come out
with another API (hopefully easier to use) and port the PD programs to
the new API - this would still work, and I predict many people would
buy it (since they have to buy MacTCP now anyways, why not buy a superior
product).
-- 

Phil Trubey                   | Internet: ptrubey@netcom.com
Systemhouse Inc.              | Voice:    415-327-8337
                              | Fax:      415-243-0471

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 93 17:48:00 GMT
From:      jms@opus1.com (Joel M-for-Vnews Snyder)
To:        comp.protocols.tcp-ip
Subject:   Re: Guaranteed Unused IP Network?

In article <mam-090393121426@192.158.86.2>, mam@gvgspd.gvg.tek.com (Mark A.
Matthews) writes...

>Is there a network number reserved that should be used for isolated
>networks which are never supposed to be connected to the Internet itself,
>yet would allow for easy detection and isolation if someone
>accidently/ignorantly did so?

Aside from the test number (already mentioned here), whenever I do paper
documentation I always use network number 555 and host number 1212.  It's
not only illegal, most people can figure out that it's a guaranteed bogus
number because of the telephone company association. 

jms

Joel M Snyder, 1103 E Spring Street, Tucson, AZ, 85719 
Phone: 602.882.4094 (voice)  .4095 (FAX)  .4093 (data)
Internet: jms@Arizona.EDU          BITNET: jms@Arizona  
Yow!  I want my nose in lights!

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 93 18:30:35 GMT
From:      tmplee@TIS.COM (Theodore M.P. Lee)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP doesn't do Fast Retransmit??

In article <1993Mar8.163025.26233@tc.cornell.edu> Kevin Saunders,
saunders@theory.TC.Cornell.EDU writes:
> 
>    1.1.1:  Apple strongly advises that 1.1.1 be used with System 7.1;
> however, 1.1 seems to work OK as long as Virtual Memory is off.  This
> version fixes several bugs in previous versions:  e.g., it displays the
> LocalTalk icon properly in the Control Panel, does not crash on the
 Mac+,
> and apparently handles asynchronous sends correctly .  Unfortunately, it
> waits ~5 seconds to resend a lost packet, which makes it irritating to
> use with ASCII hosts on networks with high rates of packet loss.
> 
>      1.1:  Required for System 7 up to 7.1.  This version crashes on the
> Mac+.  The LocalTalk icon does not always appear in the MacTCP control
> panel when LocalTalk is the selected Network device.
> 

I didn't follow the previous chains about 1.1 vs 1.1.1 very closely, since
they quickly degenerated into flames, probably justified, but flames
never-the-less, about pricing and licensing policies.  Could someone
summarize exactly under what conditions 1.1 works and doesn't work and
clarify whether the above seems to say, as I read it, that it does *not*
suffer from the retransmit bug of 1.1.1?    If it turns that in fact it
does
work under most cases, does anyone have any suggestions of how one
goes about getting a copy of it since I assume you can no longer get it
from APDA or Apple.

Ted Lee <tmplee@tis.com or tmplee@mr.net>

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Mar 1993 18:48:35 GMT
From:      knox@netnews.jhuapl.edu (Schepleng Dawn B. F2C x4170 )
To:        comp.protocols.tcp-ip
Subject:   Re: Socket connections failing.

matheys@online.cern.ch (Jean-Pol Matheys) writes:


>In article <1993Mar10.053626.6777@cc.umontreal.ca>, hachec@ERE.UMontreal.CA (Greg Patterson) writes:
 
>>I've setup the socket to SO_KEEPALIVE with:
>>
>>  setsockopt(s, SOL_SOCKET, SO_KEEPALIVE, 0, 0);
>>  signal(SIGPIPE, sig_timeout);
>>
>>but it doesn't seem to help.  I haven't seen my handler called yet.
>>
 
> OTHER SOLUTION
 
>As far as SO_KEEPALIVE is concerned, I have found no use for it yet. Just as
>you say, I've never seen SIGPIPE generated independently of program activity
>(i.e. SIGPIPE is generated only upon a socket-related function failure). I'd
>like to know if anyone has seen it being generated spontaneously, within any
>reasonable time of the other end severing the connection.
 
>I would be more than happy if somebody can provide a simple solution to this
>problem, or explain how to make good use of SO_KEEPALIVE to me.
 
>--
>Jean-Pol Matheys
 
>CERN - European Laboratory for Particle Physics    |   Jean-Pol.Matheys@cern.ch
>ECP Division  /  Data-acquisition Systems Group    |   matheys@online.cern.ch
>CH-1211 Geneva 23                   Switzerland    |   online::matheys


Looking first at the setsockopt() call, I wanted to forward this tid-bit to
anyone looking at using SO_KEEPALIVE:


@ Specify the SO_KEEPALIVE option, and the transport protocol (TCP)  initiates  a
@ timer to detect a dead connection:

@ setsockopt (sock, SOL_SOCKET, SO_KEEPALIVE, &value, sizeof (value));

@ This prevents an application from  hanging on an invalid connection. The  vari-
@ able value is an integer  that contains either 1 (on) or 0 (off).

@ The integrity of a connection is verified by transmitting  zero-length TCP seg-
@ ments  triggered by a timer  to force a response from a peer node.  If the peer
@ doesn't respond after repeated transmissions of  the  KEEPALIVE  segments,  the
@ connection  is  dropped,   all   protocol  data  structures  are reclaimed, and
@ processes sleeping on the connection are awakened with an ETIMEDOUT error.

@ The ETIMEDOUT timeout can happen in two ways.  If the  connection  is  not  yet
@ estab   lished,    the   KEEPALIVE   timer   will   expire   after  idling  for
@ TCPTV_KEEP_INIT.  If the connection is established, the KEEPALIVE  timer   will
@ start  up  when  there  is  no  traffic for TCPTV_KEEP_IDLE.  If no response is
@ received from the peer after sending KEEPALIVE segment TCPTV_KEEPCNT times with
@ interval  TCPTV_KEEPINTVL,  TCP will assume that the connection is invalid. The
@ parameters TCPTV_KEEP_INIT, TCPTV_KEEP_IDLE, TCPTV_KEEPCNT, and TCPTV_KEEPINTVL
@ are defined in the file include/netinet/tcp_timer.h.

Looking at the little bit of code from above, you were turning KEEPALIVE off, so
it makes sense that you wouldn't see anything. However, looking at the above
description, I don't know if KEEPALIVE will keep a connection alive, or if it
will tell you when it isn't alive anymore. I couldn't tell you because the
time-outs are much too long for us to worry about them in our system.

I can suggest that you set up in your code what we have called a "pinger" to
send ping messages occasionally. Every so often, the server side sends the client
side a "ping," which the client side has to answer back to. This is how we detect
our dead connections, and it also serves the purpose of keeping inactive
connections alive. Of course, you could put the "pinger" generator on either
side.

Hope this helps,
Eric Knox
knox@aplexus.jhuapl.edu

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 93 19:38:51 GMT
From:      markb@spock.dis.cccd.edu (Mark Bixby)
To:        biz.comp.telebit,comp.dcom.modems,comp.protocols.tcp-ip
Subject:   Price for minimal Telebit NetBlazer?

We need to provide dial-up SLIP/PPP access to our LAN (and the Internet) for
certain remote users.  It's my understanding that a Telebit NetBlazer would be 
an easy hardware solution to allow this.  How much can I expect to pay for a 
minimal configuration, i.e. 1 ethernet port, 1 modem port?

References for products by other vendors would also be welcome.

Thanks.
-- 
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)

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1993 20:50:22 GMT
From:      Gilles-AndrŽ Morin <gamorin@shl.com>
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP doesn't do Fast Retransmit??

Re: MacTCP doesn't do Fast Retransmit??

Has anyone given some thoughts at writing a "plug-compatible" replacement
for MacTCP
that would work properly?

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 93 23:02:41 GMT
From:      harvey@indyvax.iupui.edu
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP doesn't do Fast Retransmit??

In article <1nlkaeINNgjm@technet1.shl.com>, Gilles-Andr Morin <gamorin@shl.com> writes:
> Re: MacTCP doesn't do Fast Retransmit??
>
> Has anyone given some thoughts at writing a "plug-compatible" replacement
> for MacTCP
> that would work properly?

Beside "plug-compatible" and "works properly" (whatever that means to a
vendor :-) another handy sales pitch would be an indication of how compliant
it is with the Internet Hosts Requirements RFCs (in this case RFC1122).

:-)
--
James Harvey    IUPUI OIT Technical Support -- VMS/Unix/Networks
harvey@iupui.edu  uucp:iugate!harvey  bitnet:harvey@indyvax

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 93 23:13:23 GMT
From:      csehm@knuth.mtsu.edu (Mr. Erik Moe)
To:        comp.protocols.tcp-ip
Subject:   RIP


To any TCP/IP guru:

I'm having trouble with routed deleting entries in my routing table. Using
a protocol analyser and looking at the routedlog have figured out what is
happening, but I'm not sure who is at fault or how to fix it!  Here is how
my host system looks when it boots up:

Routing tables
Destination      Gateway            Flags     Refs     Use  Interface
127.0.0.1        127.0.0.1          UH          1     2772  lo
192.73           192.73.0.152       U           1    14683  wd3e1
192.73.1         192.73.1.152       U           1     9953  wd3e0

I have two ethernet adapters installed, wd3e0 and wd3e0.  The routed daemon
is running and /etc/gateways is empty.  Simple enough.

I have a router (PCRoute) out there at 192.73.0.201, which is connected to
another net: 192.73.20.0.  I would expect my host and the router to exchange
RIP packets and see a new entry in the routing table:

192.73.20        192.73.0.201       UG          1        0  wd3e1

Wrong!  Looking at the routedlog I see the following:

route in unsupported address family (512), from 192.73.0.201 (af 2)
route in unsupported address family (512), from 192.73.0.201 (af 2)
route in unsupported address family (512), from 192.73.0.201 (af 2)

After a few of these messages I get the following:

deleting route to interface wd3e0 (timed out)

Now, lets forget for a minute that the wrong route has just been deleted, and
look at the RIP packets. Here is a RIP response from the router:

      ========== User Datagram Protocol 8 Bytes at Offset 34 ==========
UDP:
UDP:   Src Port: RIP (520)
UDP:   Dest Port: RIP (520)
UDP:   Length: 32
UDP:   Checksum: 0000
UDP:  
      ========== Router Information Protocol Header 4 Bytes at Offset 42 ==========
RIP:
RIP:   Command: Response (2)
RIP:   Version: 1
RIP: 
      ========== RIP Network Information 20 Bytes at Offset 46 ==========
RIP:
RIP:   Family: 0002
RIP:   Network: 192.73.20.0
RIP:   Hops: 1
RIP: 

That looks ok, now here is a RIP response from my host:

      ========== User Datagram Protocol 8 Bytes at Offset 34 ==========
UDP:
UDP:   Src Port: RIP (520)
UDP:   Dest Port: RIP (520)
UDP:   Length: 32
UDP:   Checksum: B58E
UDP:  
      ========== Router Information Protocol Header 4 Bytes at Offset 42 ==========
RIP:
RIP:   Command: Response (2)
RIP:   Version: 1
RIP: 
      ========== RIP Network Information 20 Bytes at Offset 46 ==========
RIP:
RIP:   Family: 0200
RIP:   Network: 192.73.0.0
RIP:   Hops: 1
RIP: 

The address family indentifer of the router packet is 2 while the address
family identifer in the host is 0x200.  Reading RFC-1058 the address family
identifer for IP is 2, and at the time of the writing (June 1988) no other
RIP implemetations available to the author implement any other type of
address.  My question, after this lengthy intro, is this:

Does my host have a bug, or is this some new type of address family
identifier?

At the present time, to keep my host running, I have disabled routed and
added a static route in my routing table, but I sure would like to be
able to point the finger of blame!


Erik Moe
csehm@knuth.mtsu.edu

P.S. I don't have time to create a fancy signature, I have to work for a
living...

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Mar 1993 23:43:35 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Guaranteed Unused IP Network?

In article <gi2v92e@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>You mean like the bad name given a certain PC protocol because its
>corporate proprietor is somewhat reticent?

What's AppleTalk got to do with this?

>Do you think that would affect the number of people who don't know
>about 192.0.2?--I don't.  If you think to ask the question and look at
>RFC-1166, you do get a broad hint from the only network labeled
>unqualifiedly "TEST".  One could look up "JBP", and drop him a note
>asking if you've guessed right.

Oh, darn the luck.  Wouldn't you know it?  I stopped reading RFCs from
cover to cover at RFC-1165.  All the same, if i'd seen "TEST" assigned
to Postel or Reynolds, with the number being the second of all possible
class C networks, i just would have assumed it was some test network
they assigned to themselves a long, long time ago, probably for some
purpose they've completely forgotten.  It would never occur to me that
such an innocuous entry had such global significance.

>It's been only about 3 months since the same question about 192.0.2
>last came up, and several people answered it, including Jon Postel.

I consider myself extremely well informed about IP, having been involved
with TCP/IP development for more than a decade now (yeow!).  That
discussion a few months ago was the first time i'd ever heard of 192.0.2
even though it was assigned at least four years ago.  Even the last
revision of the rewrite of "Requirements for IP Routers" (October 1991)
makes no mention of it.  Since this is the obvious place to document
something like that, this tells me that a bunch of *real* IP experts had
never heard of it, either (or, at least, had forgotten about it).

						don provan
						donp@novell.com

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1993 23:47:03 GMT
From:      rarupani@dal.mobil.com (Raj Rupani)
To:        comp.protocols.tcp-ip
Subject:   snmp source code

[ Article crossposted from comp.protocols.snmp ]
[ Author was Raj Rupani ]
[ Posted on 10 Mar 1993 17:15:15 GMT ]

I was wondering if anybody could help knows of any public domain snmp server
source code written in C/C++ (preferably C++).  Any help would be greatly
appreciated.

Thanks in advance

Raj Rupani

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Mar 1993 00:39:14 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Guaranteed Unused IP Network?

In article <1993Mar10.234335.8736@novell.com>, donp@novell.com (don provan) writes:
> 
> >Do you think that would affect the number of people who don't know
> >about 192.0.2?--I don't.  If you think to ask the question and look at
> >RFC-1166, you do get a broad hint from the only network labeled
> >unqualifiedly "TEST".  One could look up "JBP", and drop him a note
> >asking if you've guessed right.
> 
> Oh, darn the luck.  Wouldn't you know it?  I stopped reading RFCs from
> cover to cover at RFC-1165.

gotcha again.  Check RFC-1117.
But it's not in 1020.  It was about 1987 when it was registered.

>                              All the same, if i'd seen "TEST" assigned
> to Postel or Reynolds, with the number being the second of all possible
> class C networks, i just would have assumed it was some test network
> they assigned to themselves a long, long time ago, probably for some
> purpose they've completely forgotten.  It would never occur to me that
> such an innocuous entry had such global significance.
>
> >It's been only about 3 months since the same question about 192.0.2
> >last came up, and several people answered it, including Jon Postel.
> 
> I consider myself extremely well informed about IP, having been involved
> with TCP/IP development for more than a decade now (yeow!).  That
> discussion a few months ago was the first time i'd ever heard of 192.0.2
> even though it was assigned at least four years ago.  Even the last
> revision of the rewrite of "Requirements for IP Routers" (October 1991)
> makes no mention of it.  Since this is the obvious place to document
> something like that, this tells me that a bunch of *real* IP experts had
> never heard of it, either (or, at least, had forgotten about it).


I agree that it should be documented; the more places the merrier.


Vernon Schryver,  vjs@sgi.com

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 93 10:00:36 MST
From:      mcrobert@bmcw.com
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and remotes

HELP

I am in need of some advise concerning communications options.
My configuration is as follows:

I have a VAX 4200 running VMS in our corporate office and I want to connect to my 32 remote locations through TCP/IP. I have a copy of TGV MultiNet for my VAX but I'm not sure what to put on my remote location machines. The remotes will consist of a UNIX box and an IBM clone. I would like to be able to connect both of them to corporate.

I have heard of PPP and SLIP but I'm not sure how to connect all the pieces together. The UNIX I will be running at the remotes will be SCO UNIX. It would be nice if I could find the pieces I need at no cost but I will consider all options.

Any ideas?????

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Mar 1993 06:20:44 GMT
From:      marsh@aristo.tau.ac.il (Marshall Rapaport)
To:        comp.protocols.tcp-ip
Subject:   Tracking down collisions

Hi,
   As of lately our network has been bombarded with collisions.  Using 
commands like "netstat -i"  you can see hundreds of collisions per minute 
at certain times and then at other times the rate goes down.  The problem
is tracking this down - I guess it could be caused by a number of things
like a faulty tranceiver or cable - but we haven't had much success in 
finding it.  We tried using the sniffer - which seemed to point to a couple
of computers - but after disconnecting them, replacing tranceivers etc.., the
problem still remains.  Does anyone out there have any program/utility in
helping to track down where collisions are coming from?  I think some sort
of program which can track down bad packets and do statistics on the source
and destination is needed/ or possible to check the packets which have been
retransmitted.  I'm sure I'm not the only one who has had this problem, so
if anyone has any suggestions please mail me.

                         Regards,
                         Marshall Rapaport
                         email: marsh@aristo.tau.ac.il

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 93 08:07:17 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Limited Broadcast Addressing

In article <1993Mar9.005244.8677@acc.com> art@acc.com (Art Berggreen) writes:
>In article <1993Mar08.232959.16946@rchland.ibm.com> obert@rchland.vnet.ibm.com (Carl Obert) writes:
>>2). Under what conditions would the limited broadcast address be
>>used over a directed broadcast address?
>
>Either old TCP/IP code, in cases where your IP address is not yet known
>(i.e. BOOTP), or where you want to insure that the broadcast remains local
>to the wire.

Do you have a case in mind where one would *not* want to insure a
broadcast remained on the local wire?  RFC1122, "Requirements for
Internet Hosts -- Communication Layers", is pretty clear that limited
broadcasts should always be used because of the potential confusion
that can be caused by two nodes not agreeing on what is and isn't a
broadcast address.  You make it sound like it's the exception.

						don provan
						donp@novell.com

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1993 18:52:40 -0500
From:      berry@bigbird.csd.scarolina.edu (Berry Mobley)
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Re: Help with 3COM 3c50? EtherLink II/16 TP ?

The Etherlink II/16 and II/16 TP are both 3C503's.  Drivers can be found
at FTP.3COM.COM in a drivers subdirectory.  

Good Luck,

Berry
  

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Mar 1993 13:24:14 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP doesn't do Fast Retransmit??

In article <1993Mar10.165816.11078@netcom.com> ptrubey@netcom.com (Phil Trubey) writes:
>If someone were to [sell] a commercial version of [TCP/IP] that had the same
>APIs as MacTCP (so that it would be compatible with TheNews, Eudora,
>Nuntius, etc), and it fixed the severe TCP problems that macTCP has,
>I would buy it in a second.

I second this comment.  

  We've got a kazoo of MacTCP users locally and the file transfer
rates are pitiful because of TCP window size adaptation problems in
MacTCP.  We'd upgrade a building full of Macs (maybe the whole NRL
site license if a good offer were made) if the alternative stack were
plug-compatible and reasonably priced.

  As for myself, I'm too stupid to use a Mac.  I have to have a decent
UNIX system to be productive (PDP-11/73 with Research UNIX V7 would be
fine :-).

Ran
atkinson@itd.nrl.navy.mil

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 93 13:25:37 GMT
From:      mckenzie@bbn.com (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re: Rate of undetected errors with TCP (and UDP)

Here's a way to think about the problem which gives you a bound on the
number of _packets_ containing undetected errors.

Suppose you make up an n-bit "checksum" at random, and compare it bit by
bit with the checksum which will be generated by the proper checksum
algorithm.  There is a 1/2 probability that they will match in the first
bit position, a 1/2 probability that they will match in the second bit
position, ... , and a 1/2 probability that they will match in the n-th
bit position.  So the probability that they will match in all positions
is 1 over 2 to the n-th.  In other words, for an n-bit checksum you
should expect that random errors could produce a packet with a correct
checksum once out of every 2**n packets.  Therefore, in your network
take the percentage of packets with DETECTED errors, divide by 2**n, and
you will find the percentage of packets with undetected errors.  Note
that this is probably one to 3 orders of magnitude smaller than 1/2**n.

You can do worse than this with a badly-designed checksum algorithm.

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

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1993 13:28:24 GMT
From:      fradin@irisa.fr (Marc Fradin)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Network control "Acess Lists" on SUN used like an IP router ?

I'm using a Sun Server (SunOS 4.1.2 with Sunlink 7.0) like
a router between my local (ethernet) network and INTERNET
(via french PDN/X25) !

I would like to control "outgoing" TCP/IP traffic (something
like "access lists" on Cisco routers ?) AND make "user accounting"
for telnet and ftp protocols !

Does a solution exist (using TUNNEL or something like that) ?
If no, I would need any advice !

Thanks in advance !

marc

Marc Fradin                        Marc.Fradin@rennes.enst-bretagne.fr 
ENST BRETAGNE                      Phone : (33) 99 12 70 24
B.P. 78                            Fax   : (33) 99 12 70 30
35512 CESSON SEVIGNE - FRANCE      Telex : 741 906


-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Mar 1993 13:53:50 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip
Subject:   Re: IP over ATM

In article <1993Mar10.203135.23465@afterlife.ncsc.mil> cawilco@afterlife.ncsc.mil (Chris A. Wilcox) writes:

>I disagree. When you have changed the characteristics of the physical
>and data link layers, it is a good idea to revisit the upper layer
>protocols and see if they need to be changed. I submit that with the
>advent of SONET over fiber and ATM, the assumptions IP makes about
>the characteristics of the transmission medium (with regards to
>lossiness, reliability, etc) are no longer valid assumptions. Therefore
>IP may not be the best protocol to be running over ATM.

Chris,

  I have to run a single internetwork over channels with widely
varying characteristics.  Whilst some land links will be fiber with
ATM/SONET, I will still have to run my network over 2.4k tactical
communications RF links (we don't have any way to run fiber out to
ships in the middle of the Pacific Ocean).  IP is _known_ to work fine
over ATM/SONET and also _known_ to work fine over my tactical comm
links (empirical evidence).

  Now other folks don't have to deal with diverse channel
characteristics and perhaps don't have to be compatible with existing
systems and networks.  Those folks will legitimately reach different
conclusions than I do.  However, the Navy as a whole is not even
moving towards OSI at any visible rate.  We have a HUGE TCP/IP
installed base and we are installing more and more of that.  So its
important for the Navy to be sure that we can run TCP/IP effectively
over ATM/SONET and get the right properties from the network to meet
operational Navy needs.

>I disagree again. ATM will be at the heart of a lot of country's
>national data networks, simply because that is what the carriers of
>the world are standardizing on, and it is getting too expensive to
>build your own wide-area data network. Now that doesn't mean that ATM
>will be "everywhere" (never met a cure-all yet), but it will be a lot
>of places. Even now there are products coming out for LANs and
>enterprise-wide networks that are gaining approval.

The above tells me that worrying about IP over ATM is worrying about
the Right problem.  You acknowledge that ATM is not a cure all.  When
you figure out how to run fiber to my mobile ships, I'll listen to
proposals that I abandon IP.  Now for other folks, other conclusions
will be reached.  For mixed channel characteristics similar to what
the Navy has, ATM doesn't make sense as a universal protocol.  IP will
work as a universal protocol over diverse links (we do it now so we
are confident of this conclusion).

Followups are redirected to comp.protocols.tcp-ip...

Ran
atkinson@itd.nrl.navy.mil

 



-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1993 16:07:10 GMT
From:      wls@magrathea.csd.uwm.edu (Bill Stapleton)
To:        comp.protocols.tcp-ip
Subject:   Re: HP JetDirect for Unix

In article <DERAADT.93Mar8213916@newt.fsa.ca>, deraadt@fsa.ca (Theo de Raadt) writes:
> In article <C30q76.Hz6@hpchase.rose.hp.com> k@hprnd.rose.hp.com (Steve Kao) writes:
>    Jeff Hakner (hak@alf.cooper.edu) wrote:
>    > Yeah, wouldn't it be nice if HP did something standard, like LPD or
>    > TELNET??  What's so great about their canned software, anyway?
> 
>    If the printer has an IP address, you can "telnet <ip_addr> 9100" and
>    have whatever you send to that telnet connection printed.  SunOS uses
>    LPD and the canned software supports it.  The code was written to run on
>    a SunSPARC station.  If you can get a copy of the source, you can
>    recompile it for your machine.  The older tapes HP distributed had the
>    source on it.  Many people have gotten it to work.
> 
> Anyone have one of these printers not behind a router so that I can print
> some of rude message on it? porno gifs, etc. :-)
> 
> I hope it's got at least some sort of security built into it.......

Actually, in HP's defense, it's a damn smart little card.  It does bootp &
tftp for it's initial configuration, the telnet stuff, snmp, syslog,
and yes, it has access lists.

On the other hand, we run HP's software on DEC machines, a choice that would
*NOT* be available to us now, as I understand it.  I hope they get their act
together and at least go back to sending out source.  It's not that tricky
to get running, and one certainly shouldn't be forced to run HP or Sun just
to use a printer.  C'mon HP, lighten up!

[For those who don't know, the software is basically two different programs
for sending to the printer.  One is a daemon that makes a 2-way link via a
pty/tty pair, so software can talk to the printer just like it talks to
a tty.  (The link is only truly both ways on the IIIsi, good for PostScript)
The other program simply sends to the printer (and has it's own master/slave
capability).  There's also a bunch of wrapper scripts to make this work with
a "normal" LPD set-up.]

--
Bill Stapleton
     wls@csd4.csd.uwm.edu
     uwmcsd4!wls

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 93 16:21:25 GMT
From:      jc@minya.UUCP (John Chambers)
To:        comp.protocols.tcp-ip
Subject:   Why the sporadic SIGTSTP+SIGQUIT on telnet link?

What I have is an application that connects  to  the  telnet  port  on
another  machine,  logs  in,  and runs its cohort on the other system.
Sometimes this works just fine,  but  sometimes  the  process  on  the
receiving  end  gets  SIGTSTP and SIGQUIT signals, both of them within
the same second, right after it puts the pty into raw mode and  writes
its  first  message.  (The message is received, BTW, and several other
messages have been exchanged in cooked mode as part of the startup.)

This behavior is quite sporadic; it seems that the link works  roughly
half  the time, and half the time it fails (because the program, being
well-behaved, exits gracefully when it  gets  the  QUIT  signal).   It
doesn't seem to have anything to do with how long since the last link,
and since the programs on both ends are being run  from  parameterless
scripts,  there isn't any apparent difference (other than the phase of
the moon ;-) in how they're being called or what's  set  up  in  their
environments.

This happens on several different releases of Unix.  I  have  handy  a
S5R4  (ESIX),  a  S5R3  (Tandem),  and a SunOS 4.1.2 (Tadpole), and it
seems to happen on all of them.  So it's either "proper"  behavior  of
the pty, or it is a bug in the code that's common to all of them.

Does anyone know a possible explanation for  this?   I'm  thinking  of
having  my  program ignore the QUIT interrupt in desperation, but this
doesn't seem like a desirable way of dealing with the problem.

TFM doesn't give any clues, of course,  as  to  why  either  of  these
signals is being sent.  Also, there seems to be no clue as to what the
origin might be, though I expect that the culprit is the pty driver.

-- 
Unix trivia question of the day:  What does the following command do:
	find . '*.bak' -exec rm -f {} ';'
Bonus question: Is there any way to undo the damage?

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Mar 1993 16:25:20 GMT
From:      ralex@world.std.com (Aleksey Y Romanov)
To:        comp.protocols.tcp-ip
Subject:   routing



I am puzzled by routing algorithm used by a number of UNIX boxes.

Let us consider a following situation:

The computer has a single ethernet interface,  address 192.9.200.23
and mask 255.255.255.0 . (a) One can create local route to
the network other than 192.9.200 (say 192.9.201) through this
interface: route add net 192.9.201 192.9.200.23 0
will succeed, and if one has a host with address 192.9.201.xxx
attached to the local ethernet it will be accessible.
(b) One cannot use the host on the 192.9.201 network
as a gateway: route add net 192.10.123 192.9.201.5 1 will fail
with a diagnostics "Network unreachable".

What puzzles me is: why (a) is allowed and (b) is not. It seems reasonable
to me either to allow or to prohibit both operations.

I am writing a user interface to the routing mechanism and I am going
to prohibit both these operations. Is it too restrictive ?

Aleksey




-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 93 16:56:26 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Limited Broadcast Addressing

In article <1993Mar11.080717.18759@novell.com> donp@novell.com (don provan) writes:
>In article <1993Mar9.005244.8677@acc.com> art@acc.com (Art Berggreen) writes:
>>Either old TCP/IP code, in cases where your IP address is not yet known
>>(i.e. BOOTP), or where you want to insure that the broadcast remains local
>>to the wire.
>
>Do you have a case in mind where one would *not* want to insure a
>broadcast remained on the local wire?  RFC1122, "Requirements for
>Internet Hosts -- Communication Layers", is pretty clear that limited
>broadcasts should always be used because of the potential confusion
>that can be caused by two nodes not agreeing on what is and isn't a
>broadcast address.  You make it sound like it's the exception.

Well, I have heard of applications that folks have built on top of
directed broadcasts.  These are expected to be able to traverse a
router.  Until IP multicast is widely supported, these applications
probably won't go away.

Art

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 93 17:03:38 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet FTP

In article <ky98ZB2w165w@netlink.cts.com> kevin@netlink.cts.com (Kevin Dorne) writes:
>I have telnet access on the Internet, but not the FTP program.  I can 
>type : 
>Telnet wuarchive.wustl.edu ftp, and it connects me to the ftp port of the
>archive server.  How can I get files?  These are the available commands: 
>help 
>214-The following commands are recognized (* =>'s unimplemented).
>   USER    PORT    STOR    MSAM*   RNTO    NLST    MKD     CDUP 
>   PASS    PASV    APPE    MRSQ*   ABOR    SITE    XMKD    XCUP 
>   ACCT*   TYPE    MLFL*   MRCP*   DELE    SYST    RMD     STOU 
>   SMNT*   STRU    MAIL*   ALLO    CWD     STAT    XRMD    SIZE 
>   REIN*   MODE    MSND*   REST    XCWD    HELP    PWD     MDTM 
>   QUIT    RETR    MSOM*   RNFR    LIST    NOOP    XPWD  214 Direct 
>comments to
>ftp-bugs@wuarchive.wustl.edu.
>
>This is my status, if it helps you: stat 211-wuarchive.wustl.edu FTP 
>server
>status:
>     Version 1.2WU(50) Tue Mar 9 09:40:50 CST 1993
>     Connected to sdacs.ucsd.edu (132.239.50.100)
>     Logged in anonymously
>     TYPE: Image; STRUcture: File; transfer MODE: Stream
>     No data connection 211 End of status

Sorry, you've only reached the command half of an FTP transaction.  To
transfer a file, FTP expects to open another TCP connection to a port
specified as one of the commands.  Your best bet is try to get hold
of sources for the FTP client program, or find an email based archive
server.

Art

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Mar 1993 17:07:42 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.lang.postscript,comp.protocols.tcp-ip
Subject:   Re: HP JetDirect for Unix

Allyn Fratkin asks:
> of course, who knows how many people actually bother to set up
> the access lists...

Very few!  I support the card, and have yet to talk to someone using the
access lists.

> not an official statement of hp.

Me neither.

- Steve Kao

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1993 17:13:48 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Handling 8-bit chars in telnet?

In article <1nl4jqINNeh0@news.cerf.net> alpham@nic.cerf.net (John Riblett) writes:
>As far as I can tell the choices are 1) just pass 'em through, which is
>not to spec although may be the way it's been done, or 2) negotiate a binary
>session, which may have other ramifications.  Thanks!

There has been a fair amount of discussion about this in the past.  I
know of 4 ways to do it, two of which you already mentioned:

3) Negotiate a terminal type that handles 8-bit characters.

4) Combine options 2 and 3.

Options 1 and 3 are remarkably similar.  The only real difference is whether
you will support 8-bit traffic when in NVT mode.

Regarding the BINARY option: Berkeley telnet messed up when it equated BINARY
with RAW.  The RFC's are about as clear as mud here, but I think RFC 1123
sections 3.2.5 and 3.2.6 state it pretty clearly as long as you ignore the
bits about newline handling.  :-)  They indicate that BINARY mode should be
used, but that in some circumstances you can get away without using it.
The bits about newline handling, as far as I can tell, simply mean that the
terminal should use its own native newline conventions, rather than matching
the NVT-standard CR LF.  In many cases, CR LF will still work fine, but
some terminals might prefer CR alone, LF alone, or might require padding,
etc.

I picked option 1, along with implementing (but ignoring) the binary option.
This maximizes interoperability.  (I picked option 1 over 3 only because it
was easier to implement.)  This implementation is not strictly correct, but
it works well enough.

-- 
Stephen Trier                      "They didn't seem to be acting out of
Network software type               malice, but they were, at best,
Case Western Reserve University     differently clued."
trier@ins.cwru.edu                        - John Perry Barlow

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 93 17:28:03 GMT
From:      bjaspan@GZA.COM (Barry Jaspan)
To:        comp.protocols.tcp-ip
Subject:   Typo in RFC793?

I *must* be confused, but I do not understand how.

RFC793, Page 32, figure 8, "Simultaneous Connection Synchronization", appears
to contain a mistake.  The segment transmitted by TCP A in line 5 is different
from the segment received by TCP B in line 7.

Is this a known typo?  I cannot believe no one else has noticed this error
since 1981, but I am unaware of an RFC that corrects it.

-- 
Barry Jaspan, bjaspan@gza.com
Geer Zolot Associates

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 93 17:47:01 GMT
From:      paul@tivoli.UUCP (Paul Greenspan)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   TLI and the streams "tirdwr" module


Has anyone ever seen problems with TLI transport endpoints associated with when you
I_PUSH the "tirdwr" module into the stream.  We are having problems with using the
call with t_bind() and t_connect().

We used to have the following order:

	t_open()
	t_bind()
	ioctl(fd, I_POP, (char *) 0);
	ioctl(fd, I_PUSH, "tirdwr");
	t_accept()                       /* or t_connect() */


This had a problem where the t_accept() would fail with "protocol error."
By playing around with this we fixed the problem by putting the I_POP and I_PUSH
ioctl's before the t_accept() call.

Now the t_connect() will fail if it is before the ioctl's and the ioctl(I_PUSH)
will fail if it comes before the t_connect().

This is on USL SVR4.3 on a 486DX.

I'd appreciate any help.

Paul
-- 
Paul Greenspan              paul@tivoli.com 
Tivoli Systems              6034 West Courtyard, Suite 210
Austin, Texas  78730        (512) 794-9070  /  FAX (512) 794-0623

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 93 17:57:29 GMT
From:      erick@demorgan.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP NetUnreachable and TCP behaviour?


 deraadt@fsa.ca (Theo de Raadt) writes:
> erick@demorgan.uwaterloo.ca (Erick Engelke) writes:
>>  ...
>>  <...brilliant perspective deleted for brevity...>
>>  ...
>>  Why should we lower our TCPs to react differently to different
>>  connections?  
>>	   - different expectations - X vs. FTP, remote MAN vs. SMTP
>>	   - the same issues as source routing for traffic 
>>	   - the addition of TCP level security parameters
>>	   - the same issues as prioritized routing
>
>I have some experience with Ham radio TCPIP, well, not as a HAM, but
>I wrote an AX25 device driver for SunOS.. 
>
> <...interesting experience and argument deleted for brevity...>
>
>...As the parameter starts
>being set lower and lower in a region (ie. a city), collisions handling
>starts getting worse and worse. People naturally will set it low, because
>they want to get a better slice of time. As they do this, everyone starts
>to lose.
>
>I myself fear the same thing would happen with TCP. Look, if you give
>me parameters like you describe above, I'm going to configure my
>machine so that I can ship data faster: I won't have to care if Joe's
>rlogins runs slower as long as my ftp's are nice and fast... In it's
>current implimentation, TCP is fairshare -- I like that. Let's keep it
>that way.

TCP is not currently fairshare.  A good implementation can melt the
wire as others sit by confused.

I'm not suggesting everyone be like Van Jacobson and steal a full 10 MB
from the Ethernet and several hundred miles of FDDI while everyone else 
scratches their heads wonderring what the heck's gone wrong with the 
darned network.  (Afterwards, who could really be angry with him for
conducting his test at such a perfect moment.)

But if you work on a machine Van touched, you may be getting a 64 K
pipe for every long remote connection you open, so *NOT* offerring
configurability on a tuned machine will make it operate more greedily
than adding configurability.  (Would you really want background things
like NNTP traffic using the same options as RLOGIN?)

And yes I'm certainly familiar with that argument.  My PC based FTP
client really cooks on local networks, but I tuned it to be far less
greedy on longer RTTs so I wouldn't develop to many enemies.

Erick
-- 
Networking is the concept of having data, finding it somewhere else and 
thinking that it's a good thing.  A distributed environment just means 
you are less picky about where it ends up before calling the whole 
process a success.  Plumbers call it a leak.

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 93 19:45:21 GMT
From:      ajf@intiar.EDU.ar (Alejandro_Jose_Formichelli)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   IP over ARCNET boards


	I am trying to install ARCNET boards in SCO XENIX 386 and SCO UNIX 386
	based machines. I need software drivers to use this board with TCP/IP.
	If anyone know where can I get this kind of software, in source or
	object form, please mail the information to this address:


							negro@intiar.edu.ar

	Thanks in advance

	P.S: Please, do not send the answers to the news groups.

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 93 20:52:18 GMT
From:      shuenn@tora.swdc.stratus.com (serene2)
To:        comp.protocols.tcp-ip
Subject:   rfc 1301 (MTP)

Hi,
	If you know about RFC 1301 or has implemented it, I'd be
appreciate if you can answer some questions for me.

1. It is not clear to me exact where MTP reside in TCP/IP stack,
is it under IP above LLC/enet or is it above TCP?

2. If MTP is unde TCP, I presume other hosts on the net would
need to support MTP too for the two TCP port to communicate, right?

3. Is there any implementation and what's the performance result?

Thanks,

Shuenn Hwang

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 93 21:56:20 GMT
From:      tmplee@TIS.COM (Theodore M.P. Lee)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP doesn't do Fast Retransmit??

By the way, did the rest of you following this chain see the following
excerpted
from another thread:

> Newsgroups: comp.sys.mac.comm
> Subject: Re: MacTCP's bootp packet is incorrect
> Message-ID: <veizades-100393125812@90.224.14.16>
> Date: 10 Mar 93 20:25:12 GMT
> Sender: news@gallant.apple.com
> Followup-To: comp.sys.mac.comm
> Organization: Apple Computer, Inc.
> Lines: 15
> 
 
> > We've been having problems with getting our router (a Wellfleet CN)
 to pass 
> > bootp packets that have been generated by MacTCP.  Using Lanalyzer to 
> > capture packets, the most obvious problem with MacTCP's bootp packet
 is that 
> > it starts out with a gateway hops value of 3 instead of 0.  This
 means the 
> 
> 
> This problem has been  corrected in MacTCP 2.0 which will be out shortly
> (April-May time frame).
> 
> John Veizades...
> MacTCP Lead Engineer
> Apple Computer, Inc.

What is intriguing, to say the least, is that Mr. Veizades hasn't said
anything
regarding the retransmission problem topic.  Have there been any other
hints
as to what is or is not to be in 2.0?

Ted Lee <tmplee@tis.com or tmplee@mr.net>

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Mar 1993 23:25:22 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Typo in RFC793?

In article <1nnsr3INNolu@pad-thai.aktis.com> bjaspan@GZA.COM (Barry Jaspan) writes:
>RFC793, Page 32, figure 8, "Simultaneous Connection Synchronization", appears
>to contain a mistake.  The segment transmitted by TCP A in line 5 is different
>from the segment received by TCP B in line 7.

The packet on line 7 is simply what the packet on line 5 looks like after
it has been "idealized" as described in the first paragraph on page 70.

>Is this a known typo?  I cannot believe no one else has noticed this error
>since 1981, but I am unaware of an RFC that corrects it.

I don't recall this coming up before, and i don't know whether or
not it was intentional.  I agree it's confusing as heck.

						don provan
						donp@novell.com

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1993 23:35:49 GMT
From:      spp@zabriskie.berkeley.edu (Steve Pope)
To:        comp.protocols.tcp-ip
Subject:   Re: Rate of undetected errors with TCP (and UDP)

mckenzie@labs-n.bbn.com (Alex McKenzie) writes:

>Here's a way to think about the problem which gives you a bound on the
>number of _packets_ containing undetected errors.
 
>Suppose you make up an n-bit "checksum" at random, and compare it bit by
>bit with the checksum which will be generated by the proper checksum
>algorithm.  There is a 1/2 probability that they will match in the first
>bit position, a 1/2 probability that they will match in the second bit
>position, ... , and a 1/2 probability that they will match in the n-th
>bit position.  So the probability that they will match in all positions
>is 1 over 2 to the n-th.  In other words, for an n-bit checksum you
>should expect that random errors could produce a packet with a correct
>checksum once out of every 2**n packets.  Therefore, in your network
>take the percentage of packets with DETECTED errors, divide by 2**n, and
>you will find the percentage of packets with undetected errors.

The above probability computation lies somewhere between
highly approximate and completely misleading.

A checksum such as is used in TCP will detect ANY single
bit error in a packet.  If we assume a digital channel with a low
uniform distribution of random errors (assumption number
one), most packets have zero bit errors.  The second most
common case is a packet with a single bit error, which 
the TCP checksum will always catch.

The third most common case is a packet with 2 bit errors,
and unfortunately the TCP checksum does not always catch
all of these.  In fact, there are some easily constructed
pathological cases where 2-error cases are not flagged...
and it's my understanding that such cases have occured,
pathologically, in certain networks, leading to much
frustration.

Most of the time, on a not-to-errorful channel, there is
no problem.  If not, using some sort of added CRC at
the datalink layer is not a bad idea.

Steve

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1993 23:37:51 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: routing

In article <C3qGA9.1y8@world.std.com> ralex@world.std.com (Aleksey Y
Romanov) writes: 
    
    I am puzzled by routing algorithm used by a number of UNIX boxes.
    
    Let us consider a following situation:
    
    The computer has a single ethernet interface,  address 192.9.200.23
    and mask 255.255.255.0 . (a) One can create local route to
    the network other than 192.9.200 (say 192.9.201) through this
    interface: route add net 192.9.201 192.9.200.23 0
    will succeed, and if one has a host with address 192.9.201.xxx
    attached to the local ethernet it will be accessible.
    (b) One cannot use the host on the 192.9.201 network
    as a gateway: route add net 192.10.123 192.9.201.5 1 will fail
    with a diagnostics "Network unreachable".
    
    What puzzles me is: why (a) is allowed and (b) is not. It seems reasonable
    to me either to allow or to prohibit both operations.
    
b) requires another recursive routing lookup.

    I am writing a user interface to the routing mechanism and I am going
    to prohibit both these operations. Is it too restrictive ?
    
Well, many other routing implementations are more liberal.

-- 
abyss \*-'bis\ n 
  1 : the bottomless gulf, pit, or chaos of the old cosmogonies  2 a : an 
  immeasurably deep gulf or great space  b : intellectual or spiritual 
  profundity; also : vast moral depravity 3 a Border Intermediate System

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 93 04:13:03 GMT
From:      jc@minya.UUCP (John Chambers)
To:        comp.protocols.tcp-ip
Subject:   Re: ka9q for unix? (with answer and flame)

In article <1993Feb26.230404.11676@iguana.uucp>, merce@iguana.uucp (Jim Mercer) writes:
> In article <1mc3qh$jo2@leps5.phys.psu.edu> kenh@leps5.phys.psu.edu (Ken Hornstein) writes:
> >
> >"You stupid shithead, get a clue.  If you had any brains for all, you'd know
> >that Unix comes with everything you need!"
> 
> You stupid shithead, get a clue. ... not all unix's have TCP/IP, and
> even  some of those don't have serial drivers for free or any amount
> of money.

Meanwhile, some of us are still interested in where one might get  the
code. To be more specific, suppose that I were someone whose Unix came
without Internet connectivity, and I  didn't  have  sufficiently  many
spare  Kbucks after paying the mortgage to install an Internet hookup.
Or suppose that I were working for some folks who think that "ftp"  is
the  name  of a DOS program that copies files across modem links.  How
might such a benighted person get ahold of ka9q?

Saying where to ftp it from is not a responsive answer. If that method
worked,  I  probably  wouldn't need ka9q, and neither would the fellow
who started this whole string, I'd guess.  Well, maybe I would anyway,
but maybe you get the point.

-- 
Unix trivia question of the day:  What does the following command do:
	find . '*.bak' -exec rm -f {} ';'
Bonus question: Is there any way to undo the damage?

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Mar 1993 08:48:33 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   CRLF in Telnet (was Re: Handling 8-bit chars in telnet?)

In article <1nns0cINN6l9@usenet.INS.CWRU.Edu> trier@slc6.ins.cwru.edu (Stephen C. Trier) writes:
>The bits about newline handling, as far as I can tell, simply mean that the
>terminal should use its own native newline conventions, rather than matching
>the NVT-standard CR LF.  In many cases, CR LF will still work fine, but
>some terminals might prefer CR alone, LF alone, or might require padding,
>etc.

I'm not sure what *you* meant, but what RFC1123 means (at least, the way
i read it) is that for some hosts, <CR>, <LF>, and <CRLF> all mean
different things when received as input, so a good telnet client
application will allow the user to indicate each of these separately in
his input stream.  It goes on to say that some telnet clients don't do
this correctly and, in fact, some can't transmit <CRLF> at all.
Consequently, a good telnet server application will try to accommodate
such defective clients by treating <CR>, and possibly even <LF>, the same
as <CRLF> if that's at all practical in the server's user interface.

By the way, using a term like "terminal", whose meaning is unclear in
the context of TELNET, is just what got us into this mess.

						don provan
						donp@novell.com

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 93 09:18:51 GMT
From:      ruud@prl.philips.nl (Ruud Hendricksen)
To:        comp.sys.sun.misc,comp.protocols.tcp-ip
Subject:   Using IP-options in an IP-header of a UDP/IP-datagram


Can anyone tell me how to set IP-options in an IP-packet for outgoing
UDP-datagrams and how to read IP-options from incoming UDP-datagrams?
The system I work on is a Sun SPARC-station with the SunOS Release 4.1
environment.

Do I have to open raw-sockets for this? The manuals do not give me
enough to work on.

Please reply direct.
	Thanks in advance. - Ruud.

==========================================================================
    Rudeboy Hendricksen			internet: ruud@prl.philips.nl
	(A virgo in distress)
==========================================================================

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Mar 1993 12:05:54 GMT
From:      fmcgnnss@unix2.tcd.ie (Fergal McGuinness)
To:        comp.protocols.tcp-ip
Subject:   Ftp sites for RFC's

Can anyone give me the names of any ftp sites where I can obtain RFCs.
The RFC's that I am looking for are not online at nic.ddn.mil, and so
I am looking for some alternative sites.

Fergal

--
	Fergal McGuinness                             fmcgnnss@unix2.tcd.ie
	Dept. Of Microelectronic Engineering
	Trinity College Dublin
	Ireland.  

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Mar 1993 12:33:28 GMT
From:      ruediger@ramz.ing.tu-bs.de (Ruediger Helsch)
To:        comp.dcom.lans,comp.protocols.tcp-ip,alt.sources
Subject:   Major modifications to PCROUTE available for FTP

A set of patches to PCROUTE is available for anonymous FTP
from ramz.ing.tu-bs.de (134.169.27.10) in directory pub/pcroute.
These solve many problems we had with PCROUTE including
dropped packets, hanging or lost connections, arbitrary failures
to reach certain internet addresses and suboptimal Proxy ARP.
The patches also add host routing and security enhancements,
dropping packets based on their sender address and the interface
that received them.
The patched version of PCROUTE is running at several places
on our campus since half a year, without any problems besides
one bug I fixed four weeks ago.

If you don't know, PCROUTE is some software running on a PC
with ethernet cards, converting the PC into an internet router.

This directory pub/pcroute contains the original source for PCROUTE
(pcroute2.23.src.tar.Z), a patch file (pcroute2.23h.patch.Z) and
the original binary distribution (pcroute2.23.tar.Z), which includes
some documentation on how to install and run PCROUTE.
Here is the README:

-------------------- README ------------------


Modifications to PCROUTE2.23 by Ruediger Helsch

HOW TO USE:

To apply these patches, you should first load pcroute2.23.src.tar.Z into
the destination directory. Then, from the destination directory, use the
patch program with this pcroute2.23h.patch as standard input. The following
programs are needed to compile PCROUTE:

	compress/zcat/uncompress	to uncompress pcroute2.23*.Z
	tar				to untar pcroute2.23.src.tar.Z
	patch				to install pcroute2.23h.patch
	tasm,tlink (Turbo Assembler)	to compile the router

BINARY DISTRIBUTION:

The Copyright on PCROUTE (in pcroute2.23.tar.Z) does not allow distribution
of enhanced versions. I am sorry, but I have to respect this restriction
and cannot provide a binary distribution or sources with patches applied.

CHANGES:

Added proper proxy ARP. Now the router answers ARP request for itself and
for all addresses that the router a) knows a route to and b) which route
points to a different interface than the one that received the ARP request.

Modified the ARP tables to keep ARP information in a LRU chain. Previously
the ARP information was indexed by the least significant byte of the
internet address. This resulted in arbitrary failures to reach certain
internet addresses and in dropped packets, leading to hanging connections.

Modified routing to allow not only subnet routes but also a default route
for the local unsubnetted network .

Added security enhancment. Packets are dropped depending on the SENDER
address if the router a) knows a route to the sender and b) the route to
the sender points to a different interface than the one that received the
packet. This makes local internet addresses reliable, because packets from
the outside that say they originated from the local net are dropped. 
When a packet is dropped, a message is displayed on the console.

Converted RIP and ARP tables to use full 32-bit internet addresses.
Previously, only the lower 16 bits of internet addresses were kept.
This resulted in errors if ARP (Proxy ARP) was used on one network
for different IP-Addresses with the same lower 16 bits.
The changes necessary were extensive and are not consistently documented in
the code. The Appletalk interface could not be tested after the changes
because the hardware was not available.

Enabled host routing. Now four different routes can be specified. For
a host 134.169.27.10 and a subnet mask of 255.255.255.0 they are, in the
order searched by PCROUTE: Host route (134.169.27.10), Subnet route
(134.169.27.0), Network route (134.169.0.0) and Default route (0.0.0.0).

Removed restrictions on routing gateways. Previously they had to be hosts
on the same subnet as one of the router's interfaces. Now, only a route
to the gateway with metric zero must be defined.


Ruediger Helsch <ruediger@ramz.ing.tu-bs.de>

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Mar 1993 14:19:03 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.protocols.tcp-ip
Subject:   Re: Asynchronous Transfer Mode

In article <5@permian.win.net>, kbomar@permian.win.net (Kevin B. Bomar) 
writes:

>Does anyone know where I can get info on the Asynchronous Transfer 
 Mode 
>protocol? What it is, what it can do, who is using it?

There is a newsgroup dedicated to ATM, comp.dcom.cell-relay.
(ATM is the only cell-relay technique having any chance to survive;
I suppose that at the time when the name was selected, there were
a number of other contenders.)

In the c.d.cell-relay conference you will find a lot of references to
ATM articles that are available online. For giving you one reference
right now: At ftp.magic.net, you'll find a file called 
pub/magic/ip-atm.ps that both gives an introduction to ATM in general
and a discussion of how to run IP over ATM.

Recent editions of college textbooks on computer communication also 
tend to include some info on ATM. You may look for eg. W.Stallings'
book 'ISDN and Broadband ISDN', Macmillan Publishing Company - my
copy is at home so I don't have the ISBN handy. A more technical
book (eg. it compares switching fabric technologies) is M.dePrycker's
'Asynchronous Transfer Mode, solutions for broadband ISDN',
Ellis Horwood Ltd, ISBN 0-13-053513-3. 1991 - somewhat 'old', but
it contains some of the discussions and rationale for decisions in
ATM, which may help explain it.

Until you get hold of these: 

What is it?  ATM is an STDM technique, like packet switching, but 
using small 'cells' (5 bytes header, 48 bytes data) rather than 
variable length packets - no need for link level flag bytes, bit 
stuffing and all that! Simpler buffer management due to fixed size.
Designed with bit rates of 155 and 620 Mbits/s in mind. Virtual
Connection oriented, not datagram switched. Common Channel 
signalling, no addressing info in the packet (beyond the connection 
ID). The net is sequencing, but not reliable, although the error 
rate is expected to be very low. No retransmission, no flow control,
two levels of priority: For a call you may reserve (and pay for!) 
a certain quanta of prioritized traffic that is protected under
saturation conditions, but beyond this you may use whatever is free 
as unprioritized capacity. ATM is intended both for fixed bitrate 
channels like phone and uncompressed video, variable like compressed 
video and very bursty traffic like remote paging.

What can it do? Give you a standardized (they all seem to agree,
believe it or not!) high-speed WAN. Looks like lots of people 
consider it for LANs, too. Compared to existing nets: Far simpler
(read: faster) switching, less latency, better suited for multimedia
data. Note: It cannot replace IP; it can carry IP. But some people
argue that running IP on top of ATM will give a very poor utilization
of the net (there has recently been a long discussion of this on 
c.d.cell-relay). Mapping eg. TCP directly to ATM would be much
better - but then, gatewaying to a TCP/IP net becomes difficult.
Lots of fascinating problems...

Who uses it? Commercially: Noone yet. There aren't that many prototype
systems out, either, although some of them are being tried in fairly
large scale setups. Expect it to come within a couple years, though!
The ATM variant of cell relay was defined by CCITT for use in B-ISDN
(broadband ISDN), so that is one sure application area, but it
seems like others are going very much in that direction, too.

For more details, follow c.d.cell-relay or check out some of the
books. I could list some more here, but I think the cell-relay
newsgroup is a more suitable forum.

Ketil.



-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Mar 1993 15:47:30 GMT
From:      pug@wixer.cactus.org (Pug)
To:        comp.protocols.tcp-ip
Subject:   Re: Ftp sites for RFC's

In article <fmcgnnss.731937954@unix2.tcd.ie> fmcgnnss@unix2.tcd.ie (Fergal McGuinness) writes:
>Can anyone give me the names of any ftp sites where I can obtain RFCs.
>The RFC's that I am looking for are not online at nic.ddn.mil, and so
>I am looking for some alternative sites.

Try ftp.nisc.sri.com. I believe this is the most complete list. Atleast
I hope it is!

Ciao,

-- 
Richard Bainter          Mundanely     |       "Teachers are supposed to
Phelim Utred Gervas      Society       |        teach you *HOW* to learn 
Pug                      Generally     |        not *WHAT* to learn."   
 miss059@uxa.ecn.bgu.edu  |  pug@ccwf.cc.utexas.edu  |  pug@wixer.cactus.org

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 93 16:34:51 GMT
From:      paul@tivoli.UUCP (Paul Greenspan)
To:        comp.protocols.tcp-ip
Subject:   TLI and the tirdwr streams module


We are developing some code which uses TLI, and have come
across a problem we cannot seem to solve. The call sequence
we are using on the client side is:

	f = t_open(DEV_TCP, O_RDWR | O_NONBLOCK, (struct t_info *) 0);

	t_bind(f, (struct t_bind *) 0, (struct t_bind *) 0);

	callptr = t_alloc(f, T_CALL, T_ADDR);

	t_connect(f, callptr, (struct t_info *) 0);

Since we wish to use read and write on this stream, we
immediately follow the t_connect with:

	ioctl(f, I_POP, (char *) 0);

	ioctl(f, I_PUSH, "tirdwr");

Frequently, this will work just fine. Only a race condition
will cause problems. Said condition occurs if a message is
put on the stream queue after the t_connect() but prior to the
I_PUSH. When this happens, the I_PUSH fails (errno = EPROTO).

We cannot figure out how to prevent the race. We cannot
simply move the ioctls in front of the t_connect, because
I_POP'ing the "timod" module fouls up the t_connect(). What
we'd like to find is a way to t_connect() AND hold incoming
messages until after we can I_PUSH the "tirdwr" module. Does
anybody know how to do this?

Paul

-- 
Paul Greenspan              paul@tivoli.com 
Tivoli Systems              6034 West Courtyard, Suite 210
Austin, Texas  78730        (512) 794-9070  /  FAX (512) 794-0623

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 93 16:56:40 GMT
From:      cawilco@afterlife.ncsc.mil (Chris A. Wilcox)
To:        comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: IP over ATM

In article <C3q99r.18L@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
[...]
>
>Chris,
>
>  I have to run a single internetwork over channels with widely
>varying characteristics.  Whilst some land links will be fiber with
>ATM/SONET, I will still have to run my network over 2.4k tactical
>communications RF links (we don't have any way to run fiber out to
>ships in the middle of the Pacific Ocean).  IP is _known_ to work fine
>over ATM/SONET and also _known_ to work fine over my tactical comm
>links (empirical evidence).
>
>  Now other folks don't have to deal with diverse channel
>characteristics and perhaps don't have to be compatible with existing
>systems and networks.  Those folks will legitimately reach different
>conclusions than I do.  However, the Navy as a whole is not even
>moving towards OSI at any visible rate.  We have a HUGE TCP/IP
>installed base and we are installing more and more of that.  So its
>important for the Navy to be sure that we can run TCP/IP effectively
>over ATM/SONET and get the right properties from the network to meet
>operational Navy needs.
>

As I said in my earlier posting, it is both meet and right to run IP
over ATM right now, because there is an operational requirement to do
so. My assertion was that IP might not be the best protocol to run in
the future. It shouldn't be followed slavishly just because there is
"a HUGE TCP/IP installed base". After all, for the most part it *is*
only software, and software is rather easily replaced.

>>I disagree again. ATM will be at the heart of a lot of country's
>>national data networks, simply because that is what the carriers of
>>the world are standardizing on, and it is getting too expensive to
>>build your own wide-area data network. Now that doesn't mean that ATM
>>will be "everywhere" (never met a cure-all yet), but it will be a lot
>>of places. Even now there are products coming out for LANs and
>>enterprise-wide networks that are gaining approval.
>
>The above tells me that worrying about IP over ATM is worrying about
>the Right problem.  You acknowledge that ATM is not a cure all.  When
>you figure out how to run fiber to my mobile ships, I'll listen to
>proposals that I abandon IP.  Now for other folks, other conclusions
>will be reached.  For mixed channel characteristics similar to what
>the Navy has, ATM doesn't make sense as a universal protocol.  IP will
>work as a universal protocol over diverse links (we do it now so we
>are confident of this conclusion).

I don't have to run fiber to your ships to take advantage of protocols
other than IP. All you are saying is that IP should be run over your
tactical links. Since I don't know anything about the characteristics
of such links, I am willing (for the sake of argument) to concede that
what you say is correct. However, that says nothing about what the
correct protocol is once the data hits your ship, nor does it say
anything about the correct protocol once the data has reached land.
The right answer might be to run IP over the tactical link, then
convert it to XTP when it hits the ship, or VMTP when it hits land.
The point is, I don't know that the above statement is wrong. I don't
think anybody definitively knows, and I think that people who step up
and say that IP has to be the right solution for everything isn't
looking at the whole problem. Right now, IP may be the one true
way. A year from now, that might be entirely wrong. Let's not throw out
possibilities just yet simply because we have one solution.

-- 
Chris Wilcox                |"The guy sure looks like plant food to me"
Dept. of Defense            |                     Seymour and Audrey II
cawilco@afterlife.ncsc.mil  |                  'Little Shop of Horrors'
The views represented here probably aren't held by the DoD. Get over it.

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Mar 1993 19:02:53 GMT
From:      nrchanne@morse.uwaterloo.ca (Neil R Channen)
To:        comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   TCP/IP "states"

I'm looking for a "TCP/IP state transition diagram" table.  As I understand
it, TCP/IP sockets have a state such as TIME_WAIT, CLOSE_WAIT,
ESTABLISHED, etc. (shown in the "netstat" command).  What I would like
to know is what states will go to what other states, and what actions
(remote client closes socket, time-out occurs, shutdown() called, etc.)
causes each state transition.

Is this information available anywhere (there doens't seem to be a FAQ for
this group)?  I've read the man pages that seem relevent, but can't find
this information.  All I've found out is the list of states:
    CLOSED, LISTEN, SYN_SENT, SYN_RECEIVED, ESTABLISHED, CLOSE_WAIT,
    FIN_WAIT_1, CLOSING, LAST_ACK     (am I missing any?)

Any replies would be appreciated; please reply by mail and I'll summarize.
-- 
   +------------------------------------------------------------------------+
   | Neil Channen   Undergrad, Computer Engineering, University of Waterloo |
   |    Email:  nrchannen@sunee.uwaterloo.ca  -or-                          |
   |            nrchannen@electrical.watstar.uwaterloo.ca                   |

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Mar 1993 19:57:08 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Limited Broadcast Addressing

In article <1993Mar11.165626.2719@acc.com> art@acc.com (Art Berggreen) writes:
>Well, I have heard of applications that folks have built on top of
>directed broadcasts.  These are expected to be able to traverse a
>router.  Until IP multicast is widely supported, these applications
>probably won't go away.

Right.  These are exceptions.  My point was that, in general, limited
broadcasts are the way to go unless an application has a specific
requirement for something more complicated.  Such an application would
need to have some code that understood directed broadcasts and could
deal with them correctly, while a more run-of-the-mill application
could just send to 255.255.255.255 and be done with it.  I took your
original statement to imply a subnet specific broadcast address was
more appropriate in that case.
						don provan
						donp@novell.com

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Mar 93 20:03:01 GMT
From:      paul@frcs.Alt.ZA (Paul Nash)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip,biz.comp.telebit
Subject:   Router advice wanted


I am looking for recommendations about reliable routers.  I need to 
link a number of slow serial links (9600bps) to two high-speed backbone
(64kbps).  The routers at the far end of the slow links will most 
likely be PC-Route or ka9q, but the router on the 64kbps lines must
be something solid and fast.

The first idea that I had was to use a Cisco to drive the 64kbps lines,
with an ethernet segment attatched, and to put a bunch of PC-Routers 
or ka9q machines onto this ethernet segment.  Each of these would have
a 9600bps line attatched, so they _should_ be able to cope.  If a PC
based router were to fall over, only that particular link would be 
affected.

However, I believe that the Telebit NetBlazer can be configured with 
lots of serial ports (we'll probably need 16 or more), and can talk
flavours of SL/IP and PPP that PC-Route and ka9q can understand.  

Does anyone have any thoughts on this?  Has anyone had major hassles
with either?  Are there other manufacturers whose equipment is better
and cheaper?  The backbone router will have to route between the two
64kbps lines, as well as to the slow lines, and must be manageable 
with SNMP.  Can a NetBlazer cope with the load?  Does it have SNMP?

Phew!  All and any comments will be most gratefully accepted.  I keep
a fairly close eye on the net, but my newsfeed is erratic, so I would
prefer e-mail.  However, reply in whatever medium you feel is most
appropriate.  "Junk mail" is most welcome as well :-)
 
 Paul Nash                                         paul@frcs.Alt.ZA
 Free Range Computer Systems CC                 Specialist Software
 Box 12475, Onderstepoort, 0110 South Africa         +27-12-5611879

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Mar 1993 20:05:35 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: IP over ATM

In article <1993Mar12.165640.264@afterlife.ncsc.mil> cawilco@afterlife.ncsc.mil (Chris A. Wilcox) writes:
>As I said in my earlier posting, it is both meet and right to run IP
>over ATM right now, because there is an operational requirement to do
>so. My assertion was that IP might not be the best protocol to run in
>the future. It shouldn't be followed slavishly just because there is
>"a HUGE TCP/IP installed base". After all, for the most part it *is*
>only software, and software is rather easily replaced.

I think you're reading this argument backwards.  The point isn't that
there's a huge installed base, so we can't change.  The point is that
there's a huge installed base because TCP/IP can handle so many
different types of networks so well, while isolating the TCP client
entirely from the any consideration at all of the topology required to
actually support his connection.  You might be able to do better over
ATM, but i really don't think you'll be able to do any better over an
Internet that is using, among other things, ATM.

Although i did find it very amusing that you think it's easy to
replace a network because it's "only software".  Ah, to be young and
innocent again.
						don provan
						donp@novell.com

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Mar 1993 21:18:43 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: TCP and gigabit networking - are we fooling ourselves?

Mark Boolootian writes:

> ....  Borman et al were able to get near-HIPPI speeds
> for memory-to-memory TCP transfers between two Crays (> 700 Mbits/sec).
>
> There has been a lot of debate recently about TCP's ability to function at
> gigabit rates, that there isn't anything inherently wrong with the protocol
> itself that would keep it from working in high speed nets.  And Borman's work
> is often sited as proof of this.  But I worry over this.

Let's be careful.  What Borman's work proves is that TCP can run at gigabit
speeds.  There are no impediments in the spec to going at gigabit speeds.
That doesn't mean Dave's wonderful implementation is the prototype of how
you'd do things on other systems.  As is pointed out, Crays are strange
beasts.  
 
> To be useful, TCP will have to perform in a production environment.  The
> resource requirements to allow TCP to operate at near-gigabit speeds, at
> least in the case of the Crays, are excessive.  Production crays don't
> have a single CPU available for checksumming, and setting aside many, many
> megabytes of memory for the kernel is an expensive proposition (particularly
> on Crays running Unicos, which doesn't offer virtual memory).
 
Megabytes of memory are cheap.  I have no problem with the idea of a 6
megabyte window on my SUN workstation -- it comes pretty much standard with
20 meg.  And memory prices are going down.  Let's keep in mind that gigabits
to our desktops are a few years away -- memory is not a problem.
 
And, on RISC cpus, the checksum comes for free.  What one does is put
the checksum additions in between the loads and store instructions of data
into memory, or do it as part of the DMA cycle (using hardware registers
on the interface).   
 
Current state of the art is a TCP implementation that receives and sends data
at a speed approximately equal to the memory-CPU bandwidth (or memory-interface
bandwidth, whichever is slower), plus around 100 instruction cycles.
 
Given that you have to get the data from the interface to the CPU for
processing (which means one data copy required), I don't think you can hope
to do much better than this.

Furthermore, this processing doesn't look so bad.  Take, for example, the
new 200 MHz DEC Alpha processor, which has a memory-CPU interface clocked
at 66 MHz (actually there are multiple speeds but I'm told this is the
rate DEC is shipping workstations with).  The TCP and IP headers easily
fit into the Alpha registers, so we put the TCP/IP header into registers
and manipulate the header (either generating one for sending, or checking
it on the receiving side).  We then copy the data.  Suppose we have 512
byte packets (probably the minimum size you'd use to send at gigabit rates).
The cache line is 128 bits, at 66 MHz, so that's 32 memory cycles plus
3 cycles for the header or 35 cycles.  Ballpark, that means TCP processing
is 100 instructions + 35 memory cycles, or about 200 instruction cycles,
per 512 bytes (4096 bits of data).  At about 195,000 packets per second
to send at say 800 Mb/s (HIPPI rates), that's 39 million instruction cycles
per second, or about 1/5 of the Alpha's bandwidth.  Yes we'll lose more to
operating system overhead (beware interrupts in particular) but this initial
budget certainly makes TCP plausible at high speeds.
 
Craig

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 1993 21:30:50 GMT
From:      spp@zabriskie.berkeley.edu (Steve Pope)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

booloo@framsparc.ocf.llnl.gov (Mark Boolootian) writes:

[ regarding the protocol and implentation work of
  Jacobson and Borman ]

> Borman et al were able to get near-HIPPI speeds
> for memory-to-memory TCP transfers between two Crays 
> (> 700 Mbits/sec).

Cool.

> But at what cost?  These were dedicated machines and, as I understand 
> it, an entire CPU was consumed just performing checksum operations.  
> Furthermore, as I recall (I can't find the bloody paper so this 
> is from memory), the window being used was somewhere around 6 
> Megabytes in size.  That requires 6 megabytes of kernel space be 
> set aside for that one connection.  
 
>There has been a lot of debate recently about TCP's ability to function at
>gigabit rates, that there isn't anything inherently wrong with the protocol
>itself that would keep it from working in high speed nets.  And Borman's work
>is often sited as proof of this.  But I worry over this.

As I recall, the Jacobson extended TCP was extended with larger 
windows and selective acknowledgements.  Having performed
many simulations of trasport protocol throughput under
various condition, I concur that these two extensions are
essential for next-generation performance.

The fact that Jacobson came up with a way to do this
in a fashion that is backwards compatible, rather than
designing an entire new transport protocol, seems a big
advantage to me.

As for the compute time involved in checksumming, there's
really no way to avoid this by redesigning the protocol, is there?  
One would assume that for production platform designers will provide
hardware assist for the checksumming if users demand the
performance.  This really shouldn't be considered a problem.

I also don't see much way of avoiding the need for large (6 meg)
windows by protocl redesign either... but the 6 megs is
not really "set aside for that one connection", it can be
dynamically allocated.  Perhaps more clever window negotiation
schemes could be devised, and this might again require
some protocol redesign... has there been much work done
on that front??

Steve

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Mar 1993 22:06:39 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking

In article <1993Mar12.211843.10381@sics.se> craig@sics.se (Craig Partridge) writes:


>Let's be careful.  What Borman's work proves is that TCP can run at gigabit
>speeds.  There are no impediments in the spec to going at gigabit speeds.
>That doesn't mean Dave's wonderful implementation is the prototype of how
>you'd do things on other systems.  As is pointed out, Crays are strange
>beasts.  

  I was kind of sad when PEI went under, not because of their
favourite protocol, but rather because their chips could also be used
to help speed up a TCP implementation.  I hear of two other commercial
firms fooling around with VLSI acceleration of TCP and IP processing,
though neither is going to be offering chip sets commercially anytime
soon. 
 
>Current state of the art is a TCP implementation that receives and 
>sends data at a speed approximately equal to the memory-CPU bandwidth 
>(or memory-interface bandwidth, whichever is slower), plus around 
>100 instruction cycles.
>
>Given that you have to get the data from the interface to the CPU for
>processing (which means one data copy required), I don't think you can hope
>to do much better than this.

  This probably is the real bottleneck -- or maybe the network to host
interface is -- depending on what quality of folks you have working on
that problem.  Modern systems often have faster memory busses than I/O
busses.  Someone here has benchmarked a number of commercial systems'
I/O and memory bus bandwidths within the past year and their
assessment is that those busses will be the network bottleneck.  The
work of Vern Schryver and others at SGI on TCP/IP/FDDI also tends to
confirm this.

  Ran
  atkinson@itd.nrl.navy.mil



-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Mar 1993 22:51:18 GMT
From:      mbeyer@zamboni.cpd.tandem.com (Mark D Beyer)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over ATM

In article 264@afterlife.ncsc.mil, cawilco@afterlife.ncsc.mil (Chris A. Wilcox) writes:

>... It shouldn't be followed slavishly just because there is
>"a HUGE TCP/IP installed base". After all, for the most part it *is*
>only software, and software is rather easily replaced.

I would have to take the opposing viewpoint.  I have never seen any kind of software
easily replaced.  Perhaps I'm missing the context here, but why do you think 
replacing IP would be easy ?  Evolve yes, replace, no.

>The right answer might be to run IP over the tactical link, then
>convert it to XTP when it hits the ship, or VMTP when it hits land.

Sounds like a debugging nightmare.

$.02

Mark Beyer
mbeyer@cpd.tandem.com

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Mar 1993 23:01:28 GMT
From:      John Andrusiak <umandru1@umanitoba.ca>
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP doesn't do Fast Retransmit??

In article <j-norstad-110393223931@mac174.acns.nwu.edu> John Norstad,
j-norstad@nwu.edu writes:
>However, I have to give MacTCP and the Apple developers credit for
>providing the foundation for what I consider to be nothing less than a
>revolution in computing in academia. MacTCP made possible the development
>of a wonderful suite of free and shareware applications which have
 brought
>the benefits of the Internet to an enormously wider audience than was
>previously possible. Here at NU, I consider this to be the single most
>important development in campus computing in the last several years, and
 I
>consider MacTCP to be the single most important piece of non-core system
>software for the Mac in our environment. Here at NU, MacTCP and the
>MacTCP-based Internet client programs have made the Mac the computer of
>choice for internetworking. If it weren't for MacTCP, we would still be
>providing access to Internet services via the old timesharing model, and
 as
>a result we'd reach only a tiny fraction of the campus computing
community.

Exactly! The Macintosh is now the the premier machine for end-user
internetworking. For network maintenance you'll still want a UNIX
machine, but for an end user the Mac is the best. Programs like Eudora
and Nuntitus blow away any unix based implemention I've ever seen. Just
about every type of internet user service is now availible as shareware
or freeware on the Mac, and the implementations are generally very good.
A big thank you to all the people who have developed programs!

Now if they could develop a cheaper, more reliable version of MacTCP it
would be heaven!

The only rumor I've heard about MacTCP 2.0 (which is 100% totally
unsubstantiated) is that SLIP or PPP support may be a part of it.
(Warning: The above statement has a semantic comment of zero.)

>So there. I will now don my flame retardant suit and await the followups.

Hot enough for you?

--------------------------------------
John Andrusiak - umandru1@umanitoba.ca

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 93 23:29:06 GMT
From:      trt@duke.cs.duke.edu (Tom Truscott)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?


If the round-trip time is small and the receiving machine can
read the data soon after it arrives then kernel buffers should
not become that large.
But the point remains valid, in a world with 6 Mbyte window sizes,
why must that buffer space be pinned into physical memory.
The answer is, it doesn't, it was just easier that way.
(I am talking about the typical BSD sockets/TCP implementation.)
An overhaul of the "mbuf" system certainly seems in order.

As for checksumming, well that is an emotional topic.
Checksumming can usually be made about as fast as copying the data.
And unless the Cray is being used simply as an expensive I/O device
then the processing of the data will dwarf the checksum time.
Still, I think TCP/IP could suppress checksumming on reliable connections.
If the interface were marked "reliable" (e.g. by ifconfig)
then ungatewayed packets sent over the interface need not be checksummed.
This would only work between consenting systems as the TCP standard
insists that the packets be checksummed.
Non-checksumming of UDP packets is already supported, by setting the checksum
field to 0 (which is pretty stupid in my opinion, it should have been ~0).

One problem I worry about as a result of rfc1323 is collapse of routers
due to congestion.  Or maybe the router's use of ICMP_SOURCEQUENCH
will suffice?  Do routers use this feature to avoid packet loss,
or do they just wait until it is too late?

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 93 00:05:23 GMT
From:      harvey@indyvax.iupui.edu
To:        comp.protocols.tcp-ip
Subject:   Default route on subnet with two routers?

Hi.  I have a Sun workstation on a subnet connected to our campus backbone
network by two routers (Ciscos running IGRP, with proxy ARP enabled).  The
Sun is running SunOS 4.1.3.  The best route off campus is router A, and the
best route to the campus backbone is router B.  This machine is the primary
nameserver for IUPUI.EDU, so it gets a lot of traffic from on and off campus.
Is it better to:

o   Set the default route to the Sun's interface and depend on proxy ARP.

o   Set the default route to router A.

o   Set the default route to router B.

o   Or something else I haven't thought of? (but see below)

I tried setting the default route to router A and a route for our class
B net (134.68.0.0, the Sun treats 134.68 as 134.0.0.68) to router B, which
is accepted but never used.
--
James Harvey    IUPUI OIT Technical Support -- VMS/Unix/Networks
harvey@iupui.edu  uucp:iugate!harvey  bitnet:harvey@indyvax

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Mar 93 00:12:46 GMT
From:      maritza@espresso.bae.bellcore.com (Maritza Ramirez)
To:        comp.protocols.tcp-ip
Subject:   file permissions criteria on FTP




Does anyone know how is it determined - in Unix - the permissions 
that a given file will have in the receiving end ?

That is, if I send a file using FTP from machine A to machine B,


	-----		-----
	|   |---------->|   |
	-----		-----
          A               B


... how do I know the file permissions that the file will have on 
machine B ? (I mean the read/write/execute permissions for the user, 
group, and others).

I will appreciate any information,

Maritza

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 1993 01:26:26 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

In article <731978945@romeo.cs.duke.edu> trt@duke.cs.duke.edu (Tom
Truscott) writes: 
    
    One problem I worry about as a result of rfc1323 is collapse of routers
    due to congestion.  Or maybe the router's use of ICMP_SOURCEQUENCH
    will suffice?  Do routers use this feature to avoid packet loss,
    or do they just wait until it is too late?

ICMP Source Quenches are (will be?) deprecated in the current router
requirements draft.  Routers which become congested drop packets.  One
would assume (wrongly, of course ;-) that any implementation that did 1323
would do slow start too.


-- 
abyss \*-'bis\ n 
  1 : the bottomless gulf, pit, or chaos of the old cosmogonies  2 a : an 
  immeasurably deep gulf or great space  b : intellectual or spiritual 
  profundity; also : vast moral depravity 3 a Border Intermediate System

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 1993 01:29:27 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Default route on subnet with two routers?

In article <1993Mar12.190523.494@indyvax.iupui.edu> harvey@indyvax.iupui.edu writes:
    Hi.  I have a Sun workstation on a subnet connected to our campus backbone
    network by two routers. Is it better to:

    o   Set the default route to the Sun's interface and depend on proxy ARP.
    
    o   Set the default route to router A.
    
    o   Set the default route to router B.
    
    o   Or something else I haven't thought of? (but see below)
    
o   Run a router discovery protocol.

-- 
abyss \*-'bis\ n 
  1 : the bottomless gulf, pit, or chaos of the old cosmogonies  2 a : an 
  immeasurably deep gulf or great space  b : intellectual or spiritual 
  profundity; also : vast moral depravity 3 a Border Intermediate System

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 1993 15:02:34 +1000
From:      james@cssc-woll.tansu.com.au (James Winterbottom)
To:        comp.protocols.tcp-ip
Subject:   Does anyone use VMTP?

We are considering using VMTP for performing transactions over a wide 
area network. Does anyone out there use VMTP in a commercial system?
Any experiences to share?

Thanks in advance.

James Winterbottom
james@cssc-woll.tansu.com.au








-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 93 13:04:55 GMT
From:      Conrad_Nobili@Harvard.EDU (Conrad C. Nobili)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP doesn't do Fast Retransmit??

In article <j-norstad-110393223931@mac174.acns.nwu.edu>, j-norstad@nwu.edu
(John Norstad) wrote:

> However, I have to give MacTCP and the Apple developers credit for
> providing the foundation for what I consider to be nothing less than a
> revolution in computing in academia. MacTCP made possible the development
> of a wonderful suite of free and shareware applications which have brought
> the benefits of the Internet to an enormously wider audience than was
> previously possible.

Well, I basically agree with what you say John.  Especially about the
outrageous new MacTCP licensing scheme for large sites.  (Somewhat of a
bait-and-switch deal there....)

> MacTCP-based Internet client programs have made the Mac the computer of
> choice for internetworking.

Yeah, so we have sold a real lot of Macs for Apple.  And this is the thanks
we get...?!  I *might* be better able to accept this if at least MacTCP
were a high-quality product....

Hrmmmmph!

Conrad C. Nobili  N1LPM  Conrad_Nobili@Harvard.EDU  Harvard University OIT

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Mar 1993 13:11:52 GMT
From:      larry@gator.rn.com (Larry Snyder)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip,biz.comp.telebit
Subject:   Re: Router advice wanted

paul@frcs.Alt.ZA (Paul Nash) writes:


>I am looking for recommendations about reliable routers.  I need to 
>link a number of slow serial links (9600bps) to two high-speed backbone
>(64kbps).  The routers at the far end of the slow links will most 
>likely be PC-Route or ka9q, but the router on the 64kbps lines must
>be something solid and fast.

Here is some information on the nethopper which is very reasonably
priced considering it's features:

Here is the info on the Rockwell International Net Hopper.  I received
this information in the mail and thought it looked interesting.  I don't
own one and have no experience with this unit.  All of the information in
this posting came from their information.

Two models are available -- Part Number 117103-0 retails for 3495 and connects
TCP/IP network users to their remote backbone using standard telephone lines.  
3 internal v.32bis/v.42bis modems are included.

The second model is part number 117101-0 and the list price is 1995.  This unit
is the same as above but includes only one v.32bis/v.42bis internal modem.

Features -
 o Simple five step configuration requires only the addition of a network
   number, phone number, subnet mask and password information

 o Integraded v.32bis/v.42bis modem requires no modem configuation and 
   provides auto-dial and auto-answer capabilities and can operate in either 
   syncronous or asynchronous modes
  
 o Transparent operation allows user to send mail, ftp files and access
   remote databases without extraneous modem commands, terminal emulation 
   problems or addressing ad hoc file transport mechanisms

 o Auto-sense, triple media LAN interface automatically detects cable type:
   10 BaseT, AUI or Thinnet

 o Configuration infomation provided on floppy disk to allow for configuration
   at central site priot to installation at remote site

 o Lowest cost of any IP router on todays market
 
 o Uses ordinary phone lines to allow users to pay only for what they use
   eliminating high leased line charges

 o Interal modems makes it unnecessary to buy and configure troublesome 
   and expensive additional modems

 Processor: 386SX
 Modem: ROckwell RC96/114AC-P 16550 internal ISA bus with v.32bis/v.42bis/MNP5
 Routing Protocol: IP class A, B and C addressing
 Protocols: TCP/IP, PPP (RFC 1331, 1332, 1333) with CHAP (MDS) security

For more info - contact CMC Network Products
                        125 Cremona Drive
                        Santa Barbara, CA   93117
                        1-800-CMC-8023
         
                        or
                        Centra House, 3 Lampton Road
                        Hounslow, Middlesex, England TW3 1HY
                        (+44) 81 751 6804

               
 
>However, I believe that the Telebit NetBlazer can be configured with 
>lots of serial ports (we'll probably need 16 or more), and can talk
>flavours of SL/IP and PPP that PC-Route and ka9q can understand.  

The Netblazer uses Digiboard products to increase serial ports.  I don't
know of the Digiboards are enhanced by Digi for Telebit in any way
(custom ROM's or PALs) nor if drivers for the Digiboard are included in
the base Netblazer product.

-- 
Larry Snyder                               
larry@gator.rn.com

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Mar 1993 16:06:28 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip,biz.comp.telebit
Subject:   Re: Router advice wanted

In article <1993Mar12.200301.10476@frcs.Alt.ZA> paul@frcs.Alt.ZA (Paul Nash) writes:
>
>I am looking for recommendations about reliable routers.  I need to 
>link a number of slow serial links (9600bps) to two high-speed backbone
>(64kbps).  The routers at the far end of the slow links will most 
>likely be PC-Route or ka9q, but the router on the 64kbps lines must
>be something solid and fast.

  We have never had a problem with our Cisco boxes and we have a large
number of them (they are the current router available to us on the
Navy TAC-3 contract).  Folks I know are also quite pleased with
Wellfleet and Proteon equipment.

>However, I believe that the Telebit NetBlazer can be configured with 
>lots of serial ports (we'll probably need 16 or more), and can talk
>flavours of SL/IP and PPP that PC-Route and ka9q can understand.  

  Telebit has very solid modems.  We are consider a NetBlazer
ourselves for connecting two small Ethernets via dialup high-speed
modems.  My experience with Telebit is that they are a good vendor.

Ran
atkinson@itd.nrl.navy.mil

DISCLAIMER: Opinion's are the author's not his employers.



-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Mar 1993 16:08:09 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

In article <731978945@romeo.cs.duke.edu> trt@duke.cs.duke.edu (Tom Truscott) writes:

>Still, I think TCP/IP could suppress checksumming on reliable connections.
>If the interface were marked "reliable" (e.g. by ifconfig)
>then ungatewayed packets sent over the interface need not be checksummed.

It isn't clear to me that the end system can dependably know that 
traffic will only travel over "reliable" links if it isn't directly
connected to the same local LAN.




-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Mar 1993 18:32:35 GMT
From:      j-norstad@nwu.edu (John Norstad)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP doesn't do Fast Retransmit??

In article <Conrad_Nobili-130393075353@128.103.61.127>,
Conrad_Nobili@Harvard.EDU (Conrad C. Nobili) wrote:

> Well, I basically agree with what you say John.  Especially about the
> outrageous new MacTCP licensing scheme for large sites.  (Somewhat of a
> bait-and-switch deal there....)

Kind of like selling heroin - the first time is free.
 
> Yeah, so we have sold a real lot of Macs for Apple.  And this is the thanks
> we get...?!  I *might* be better able to accept this if at least MacTCP
> were a high-quality product....

I think my disagreement here is that I feel that MacTCP is basically a
high-quality product, with a few bugs which need to be fixed.

See my posting in comp.protocols.appletalk for more discussion on this and
on the new volume purchasing fees.

John Norstad
Academic Computing and Network Services
Northwestern University
j-norstad@nwu.edu

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Mar 1993 20:15:34 GMT
From:      beast@world.std.com (Donald E Eastlake III)
To:        comp.protocols.tcp-ip
Subject:   Re: Guaranteed Unused IP Network?

karl@genesis.MCS.COM (Karl Denninger) writes:

>In article <1993Mar9.235009.978@aio.jsc.nasa.gov> poirot@widget.jsc.nasa.gov (Daniel Poirot) writes:
>>In article <mam-090393121426@192.158.86.2> mam@gvgspd.gvg.tek.com (Mark A. Matthews) writes:
>>>Is there a network number reserved that should be used for isolated
>>>networks which are never supposed to be connected to the Internet itself,
>>>yet would allow for easy detection and isolation if someone
>>>accidently/ignorantly did so?
>>I think that the 129.0.0 subnet is reserved for testing.  Our Silicon
>>Graphics machines come out of the box with IP numbers like 129.0.0.x.
>I've always liked "2." myself.  Just don't let it out of your own systems,
>or you will <definately> raise some eyebrows :-)

I believe 192.0.2.* is reserved for testing.  It should be possible to
check this with the latest reserved numbers RFCs.

Donald

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Mar 1993 20:48:35 GMT
From:      visser@convex.com (Lance Visser)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

In <1nqfm1$sb2@lll-winken.llnl.gov> booloo@framsparc.ocf.llnl.gov (Mark Boolootian) writes:

>In article <C293zD.3r4@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
>>  Van Jacobson & Dave Borman wrote an RFC on TCP extensions related to
>>high speed networks.  There are several implementations of that high
>>speed Van J TCP and it works well.  Tom Skibo, formely of somewhere
>>else and currently of SGI, wrote a freely distributable implementation
>>of that kind of TCP.  I forget where the Skibo source code is kept for
>>anonymous ftp though, so don't bother asking me...
 
>I'm very interested in the issue of high speed networking and TCP.  The 
>comment that there are several implementations of TCP with the Van Jacobson
>extensions which work well intrigues me.  I have copies of Dave Borman's
>slides from an IETF presentation which give some observed TCP rates between
>a couple of Crays.  I believe these may be the highest throughput numbers
>ever claimed for TCP.  Borman et al were able to get near-HIPPI speeds
>for memory-to-memory TCP transfers between two Crays (> 700 Mbits/sec).

+>But at what cost?  These were dedicated machines and, as I understand it,
+>an entire CPU was consumed just performing checksum operations.  Furthermore,
+>as I recall (I can't find the bloody paper so this is from memory), the
+>window being used was somewhere around 6 Megabytes in size.  That requires
+>6 megabytes of kernel space be set aside for that one connection.  

	When your talking about transfer rates of 700 Mbits/sec, 6 Meg of
buffer space is nothing.  Its the price of doing business at that sort
of speed.  You can put any sort of protocol in place of tcp and your 
still going to have massive memory requirements.


+>There has been a lot of debate recently about TCP's ability to function at
+>gigabit rates, that there isn't anything inherently wrong with the protocol
+>itself that would keep it from working in high speed nets.  And Borman's work
+>is often sited as proof of this.  But I worry over this.

	

+>To be useful, TCP will have to perform in a production environment.  The 
+>resource requirements to allow TCP to operate at near-gigabit speeds, at
+>least in the case of the Crays, are excessive.  Production crays don't
+>have a single CPU available for checksumming, and setting aside many, many
+>megabytes of memory for the kernel is an expensive proposition (particularly
+>on Crays running Unicos, which doesn't offer virtual memory).

	You have to understand what these high-speeds are wanted for.  they
are typically being used to pipe massive amounts of data in and results
out.....not for running telnet or xterms.  If your bringing in bulk
data either for computational processing, file storage/retreval, or acting
as a front end to fast tape or video, you dont really care how much of 
the machine your using.


+>It seems to me that, in order to really offer the possibility of gigabit
+>speeds to users in a production environment, something somewhere is going
+>to have to undergo some sort of fundamental change.  Perhaps it is the
+>transport protocol itself or maybe it is a complete rethinking of how 
+>existing transport protocols (i.e. TCP) are implemented.  Maybe we need
+>dedicated network processors to completely offload compute processors.

	From my experence over the past year with these problems, I will
tell you that the problems far more often than not are:

	1. The speed of the memory system

	2. The buffer management scheme used by the protocols

	3. The non-protocol overhead in networking.

	4. File system performance/operation.

	Dedicated network processors dont solve the problem because 
they always introduce more delay and dont solve the memory contention
problem.


	The biggest pain that tcp/ip has given me personally with regard
to Hippi is the 64k ip message limit.  Now there are issues, (espcically
in going across muliple switches) in dominating switches when you
go beyond 64k packets, but its a limitation that hurts one switch lan
performance or point-to-point performance in select situations.  Window
scale solved the problem for tcp, but I believe that IP has to be addressed.

	In fact, I believe that IP is in need of a very serious overhaul
in most respects and is more of an overall "pain factor" for networking
than tcp is going to be.

+>I am personally unconvinced (at least, this morning...) that TCP can actually
+>be used to provide true gigabit speeds in a production environment.  I'd
+>certainly like to hear other's views on this matter.

	I am very interested in knowing what you want to use gigabit speeds
for.  The closer you get to gigabit speeds, the sorts of applications you
run and the interaction of those applications changes greatly.  With
gigabits speeds, everything seems to tend more and more toward "staging"
of tons of data locally rather than constantly going back and forth 
across the network.


	


-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Mar 93 21:09:37 GMT
From:      dotytr@nscultrix2.network.com (Ted Doty)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

In article <1nqfm1$sb2@lll-winken.llnl.gov> booloo@framsparc.ocf.llnl.gov (Mark Boolootian) writes:
>
>I'm very interested in the issue of high speed networking and TCP.  The 
>comment that there are several implementations of TCP with the Van Jacobson
>extensions which work well intrigues me.  I have copies of Dave Borman's
>slides from an IETF presentation which give some observed TCP rates between
>a couple of Crays.  I believe these may be the highest throughput numbers
>ever claimed for TCP.  Borman et al were able to get near-HIPPI speeds
>for memory-to-memory TCP transfers between two Crays (> 700 Mbits/sec).
>
>But at what cost?  These were dedicated machines and, as I understand it,
>an entire CPU was consumed just performing checksum operations.  Furthermore,
>as I recall (I can't find the bloody paper so this is from memory), the
>window being used was somewhere around 6 Megabytes in size.  That requires
>6 megabytes of kernel space be set aside for that one connection.  
>
I was a member of a receintly completed TCP benchmark test using Cray
YMP-2e and YMP-8e TCP socket transfers (i.e. memory-memory) over a HiPPI
network.  On unloaded systems, we achieved 640 Mbps single stream and
1.25 Gbps aggregate (2 simultaneous, opposite-ditrection streams).  We
used pretty much a plain-jane Cray config - 7.0c with a single kernel
mod to allow windows greater than 400k.

It looked from the results that there wasn't too much improvement for
windows larger than 512k, but this might be dependent on the test
network.  We had a HiPPI switch fabric consisting of 4 NSC PS32 switches
with a couple of extended links (maybe 1000 feet each) over BCP fiber
extenders.  My guess is that a bigger network with more latency, such as
the network run at the Supercomputing '92 show, would need a larger
window.  But that's only a guess.

[ stuff deleted ]

>To be useful, TCP will have to perform in a production environment.  The 
>resource requirements to allow TCP to operate at near-gigabit speeds, at
>least in the case of the Crays, are excessive.  Production crays don't
>have a single CPU available for checksumming, and setting aside many, many
>megabytes of memory for the kernel is an expensive proposition (particularly
>on Crays running Unicos, which doesn't offer virtual memory).

Ours was a production environment, using production hosts.  We did kick
the users off to get clean CPU loading numbers (not excessive), but we
didn't add memory or anything like that.

>It seems to me that, in order to really offer the possibility of gigabit
>speeds to users in a production environment, something somewhere is going
>to have to undergo some sort of fundamental change.  Perhaps it is the
>transport protocol itself or maybe it is a complete rethinking of how 
>existing transport protocols (i.e. TCP) are implemented.  Maybe we need
>dedicated network processors to completely offload compute processors.

I disagree.  The load just wasn't that high.  Granted, a YMP-8e has a
LOT of guts for checksumming, but the 2e did just fine, too.  I wouldn't
expect this kind of data rate from a workstation real soon, but I
wouldn't be too surprised to see it is a couple of years (especially if
Sun gets their OC-12 chipset done).

>I am personally unconvinced (at least, this morning...) that TCP can actually
>be used to provide true gigabit speeds in a production environment.  I'd
>certainly like to hear other's views on this matter.

The government will be publishing the test results.  If you (or anyone
else) are interested, send me email, and I'll find out how you can get a
copy.

- Ted

--------------------------------------------------------------------------
Ted Doty, Network Systems Corporation | phone:      +1 301 596-2270
8965 Guilford Road, Suite 250         | fax:        +1 410 381-3320
Columbia, MD, 21046 USA               | voice mail: (800) 233-1485
--------------------------------------------------------------------------
These opinions are my own, not necessarially those of Network Systems.

DISCLAIMER: I do not speak for the US government on this subject.  I
just know what I saw.

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Mar 93 23:44:26 GMT
From:      murray@src.dec.com (Hal Murray)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

In article <C3u4tL.Eyn@ra.nrl.navy.mil>, atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
|> In article <731978945@romeo.cs.duke.edu> trt@duke.cs.duke.edu (Tom Truscott) writes:
|> 
|> >Still, I think TCP/IP could suppress checksumming on reliable connections.
|> >If the interface were marked "reliable" (e.g. by ifconfig)
|> >then ungatewayed packets sent over the interface need not be checksummed.
|> 
|> It isn't clear to me that the end system can dependably know that 
|> traffic will only travel over "reliable" links if it isn't directly
|> connected to the same local LAN.
|> 
|> 


Even if you think you are talking to a machine on the local net there is no
guarantee that the link is reliable.  Somebody could have added a "smart"
bridge while you weren't looking.

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 1993 00:09:24 GMT
From:      mjr@tis.com (Marcus J Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

>Still, I think TCP/IP could suppress checksumming on reliable connections.

	Wouldn't it be easier to move that stuff onto the ethernet
controller if your application justified the expense?

mjr.

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 93 00:19:25 GMT
From:      ddl@burrhus.harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: RIP

In article <csehm.731805108@knuth.mtsu.edu>, csehm@knuth.mtsu.edu (Mr. Erik Moe) writes:

[...]
| route in unsupported address family (512), from 192.73.0.201 (af 2)
[...]

| Does my host have a bug, or is this some new type of address family
| identifier?

It's been a long, long time since I've seen this behavior.  So long, in
fact, that I'll probably remember the details incorrectly (and be flamed :).
In any case, there was some confusion about the byte order of sa_family
in older versions of routed.  I seem to think that there was even some
confusion about the *size* of the field at that time; perhaps it was treated
as a single byte in certain contexts.  If you take a look at current routed
sources, you will probably see remnants of the confusion.  Maybe it
has come back...

				Dan Lanciani
				ddl@harvard.*

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Mar 1993 00:37:52 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Ftp sites for RFC's

In article <1993Mar12.154730.29269@wixer.cactus.org> pug@wixer.cactus.org (Pug) writes:
>In article <fmcgnnss.731937954@unix2.tcd.ie> fmcgnnss@unix2.tcd.ie (Fergal McGuinness) writes:
>>Can anyone give me the names of any ftp sites where I can obtain RFCs.
>>The RFC's that I am looking for are not online at nic.ddn.mil, and so
>>I am looking for some alternative sites.
>
>Try ftp.nisc.sri.com. I believe this is the most complete list. Atleast

Negative.  

The set of RFCs at nic.ddn.mil is guaranteed to be complete and
nic.ddn.mil is the primary official source for all RFCs.




-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Mar 93 02:17:06 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   3c509 version 10.1 packet driver problem in fast pc's

In an article Hendrik.Klompmaker@Beheer.Zod.Wau.Nl writes:

   I've been using Russ Nelson's packetdriver for the 3c509 (ETHERLINK III) 
   since the first beta and thought now the Alpha release is out (10.1) all 
   problems would be gone. Well most of them are but still some remain. I would 
   like some help from you out there because I don't know anymore.
   I have a 486 DX2 50Mhz ISA clone machine that misses his 3c509 5 out of 10 
   times when the packet driver is loaded. It complains about no 3c509 card 
   found and suggest to use a different id_port value. 
   The bus speed was configured as bus/4 (what would be 6.25 Mhz). I modified 
   the setup to bus/3 (what would be 8.33Mhz) and since then the card is found 
   more often (8 out of 10 times).

   Can anybody out there tell me whats the relation between bus
   speeds and the  3c509 and its packet driver. I would asume the a
   lower bus speeds would be  more reliable then higher ones but the
   opposite seems to be true.

I'm guessing that there's a port conflict between the default 3c509
ID port and some other device.  The reason it gets better when you
run faster is because (guessing here) the 3c509 wins the conflict
more often when you run the bus faster.

Try a different ID port (e.g. 140):
	3c509 0x7f 0x140

-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Mar 1993 02:42:36 GMT
From:      jek5036@ultb.isc.rit.edu (J.E. King)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?


Has anyone thought of a transfer protocol that doesn't use ACKs but only
requests a resend of damaged packets such as Zmodem does?  Please excuse
my ignorance; I'm a young networking student and I don't know much about
anything at this point..

- Jim

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 1993 05:38:10 GMT
From:      spp@zabriskie.berkeley.edu (Steve Pope)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

jek5036@ultb.isc.rit.edu (J.E. King) writes:

>Has anyone thought of a transfer protocol that doesn't use ACKs but only
>requests a resend of damaged packets such as Zmodem does?  Please excuse
>my ignorance; I'm a young networking student and I don't know much about
>anything at this point..

Yes, this type of protocol is called a "negative acknowledgement"
protocol, and they do exist.  One that is used, somewhat, in
an internet environment is NETBLT.

TCP is a "positive acknowledgement" protocol.  Either type can be
made to work well.


Steve

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 1993 14:41:52 +1000
From:      g8902705@wampyr.cc.uow.edu.au (Bernard John Giannetti)
To:        comp.protocols.tcp-ip
Subject:   Channel Aggregator

I have heard a rumour of the existance of a Channel Aggregator Chipset for the
ISDN B-Channels. Perhaps AT&T make it, or someone else.

If anyone has any information about this, please drop me a line at my email
address below.

                        Thankyou in advance,
					Bernard Giannetti,



Department of Electrical & Computer Engineering
University of Wollongong
Northfields Avenue
Wollongong NSW 2522
Australia
FAX: 61 42 213236
TELEPHONE: 61 42 213065
EMAIL: bernard@snrc.uow.edu.au

PS: I'm sorry if this is the wrong newsgroup to post to. I'm indesperate need
of this info.

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Mar 1993 13:00:08 GMT
From:      jshaw@actrix.gen.nz (Jim Shaw)
To:        comp.protocols.tcp-ip
Subject:   Router IF down delay


Can anyone tell me how long a router ( we have HP CR and ER routers) should take
to detect a line going down? 

We are trying to improve the time taken to re-route traffic in the case of 
a sync line failure. It seems that it takes the router about a minute to 
detect the fact that an interface is down eg if I turn off the NTU or unplug
the line from  the router.

I am polling the router using SNMP to find its interface status to check this.

Seems to me that loss of carrier should be detected immediately and an 
alternate route found.

Thanks, Jim

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Mar 1993 15:06:33 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

craig@sics.se (Craig Partridge) writes:

}Megabytes of memory are cheap.  I have no problem with the idea of a 6
}megabyte window on my SUN workstation -- it comes pretty much standard with
}20 meg.  And memory prices are going down.  Let's keep in mind that gigabits
}to our desktops are a few years away -- memory is not a problem.

BTW, that's 6MB per connection.  On my mostly idle workstation:
pooh.cc> netstat -a | grep ^tcp | wc -l
      19
that would be 114MB (hmmm, seems I'm about 90MBs short).

}And, on RISC cpus, the checksum comes for free.  What one does is put
}the checksum additions in between the loads and store instructions of data
}into memory, or do it as part of the DMA cycle (using hardware registers
}on the interface).   

Well, it would have been nice if they had put the darn checksum at the
end of the packet!!  (Kind of hard to sneak the checksum computation
into the write-to-the-net-device-loop if it's not after all the bytes to
be checksummed!)

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 1993 18:32:52 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Router IF down delay

In article <1993Mar14.130008.9626@actrix.gen.nz> jshaw@actrix.gen.nz (Jim
Shaw) writes: 
    
    Seems to me that loss of carrier should be detected immediately and an 
    alternate route found.
    
You are correct.



-- 
abyss \*-'bis\ n 
  1 : the bottomless gulf, pit, or chaos of the old cosmogonies  2 a : an 
  immeasurably deep gulf or great space  b : intellectual or spiritual 
  profundity; also : vast moral depravity 3 a Border Intermediate System

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 1993 18:48:21 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

In article <C3vwMy.Gw3@news.iastate.edu> john@iastate.edu (John Hascall)
writes: 
    
    BTW, that's 6MB per connection.  On my mostly idle workstation:
    pooh.cc> netstat -a | grep ^tcp | wc -l
          19
    that would be 114MB (hmmm, seems I'm about 90MBs short).
    
No, it's still 6MB.  Assuming that you want that level of aggregate
performance, you simply pool the unused memory.  If you are talking 19
times Cray performance, then yes, I think 114MB is reasonable.  ;-)

I can still recall people thinking that a 2K buffer in the BIOS for floppy
buffering was a waste of memory.  ;-)

    Well, it would have been nice if they had put the darn checksum at the
    end of the packet!!  (Kind of hard to sneak the checksum computation
    into the write-to-the-net-device-loop if it's not after all the bytes to
    be checksummed!)
    
Assuming you have a moderately intelligent controller, you copy the packet
down to the interface and then inject the checksum just before pushing
SEND.  The location is irrelevant.

-- 
abyss \*-'bis\ n 
  1 : the bottomless gulf, pit, or chaos of the old cosmogonies  2 a : an 
  immeasurably deep gulf or great space  b : intellectual or spiritual 
  profundity; also : vast moral depravity 3 a Border Intermediate System

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Mar 1993 19:23:27 GMT
From:      visser@convex.com (Lance Visser)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

In <C3vwMy.Gw3@news.iastate.edu> john@iastate.edu (John Hascall) writes:

+>craig@sics.se (Craig Partridge) writes:

+>}Megabytes of memory are cheap.  I have no problem with the idea of a 6
+>}megabyte window on my SUN workstation -- it comes pretty much standard with
+>}20 meg.  And memory prices are going down.  Let's keep in mind that gigabits
+>}to our desktops are a few years away -- memory is not a problem.

+>BTW, that's 6MB per connection.  On my mostly idle workstation:
+>pooh.cc> netstat -a | grep ^tcp | wc -l
+>      19
+>that would be 114MB (hmmm, seems I'm about 90MBs short).

	What your overlooking is that different sorts of connections
dont require the same amount of buffer.  Your not going to need 
6MB of socket buffer for lets say a telnet connection or any other
sort of interactive connection (like an xterm).
	If your going to do big bulk data transfers, the you reserve the
necessary memory to "do" them with via existing socket options for setting
the window size.


-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Mar 1993 20:06:40 GMT
From:      peram@eceyv.ncsu.edu (Peram Marimuthu)
To:        comp.protocols.tcp-ip
Subject:   Network Time Protocol

Is an implementation of NTP  available in public domain? Where can I find it?

--peram

peram@eceyv.ncsu.edu



-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Mar 1993 22:08:57 GMT
From:      visser@convex.com (Lance Visser)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

In <1nvullINNqb2@cronkite.cisco.com> tli@cisco.com (Tony Li) writes:

+>Assuming you have a moderately intelligent controller, you copy the packet
+>down to the interface and then inject the checksum just before pushing
+>SEND.  The location is irrelevant.

	Your also assuming something along the lines of FDDI-size packets.
With 64k Hippi blocks, it becomes very difficult to pull off without 
introducing delays, having immense amounts of buffer space or going to 
trailers(never!).  When the packet is huge, the location becomes very relievant.




-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Mar 1993 22:39:56 GMT
From:      dmm0t@rincewind.mech.virginia.edu (David Meyer)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Time Protocol

In article <1993Mar14.200640.21883@ncsu.edu> peram@eceyv.ncsu.edu (Peram Marimuthu) writes:
>Is an implementation of NTP  available in public domain? Where can I find it?

louie.udel.edu:/pub/ntp/xntp3-export.tar.Z

See also comp.protocols.time.ntp

		Dave
-- 
David M. Meyer                             Mechanical & Aerospace Engineering
dmm0t@rincewind.mech.virginia.edu          University of Virginia
NeXTmail ok

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Mar 93 10:14:46 CST
From:      EM306965@itesmvf1.rzs.itesm.mx
To:        comp.protocols.tcp-ip
Subject:   Help on implementing FTP

Help.
 
   I'm implementing a sheel for FTP on Smalltalk for a school proyect and
I've encountered the following problem; although I have opened my control
well and have access to the server ( I can Logon give the account etc)
I can't initate a data transfer.
Is there a standard port to transfer data?
Do I have to use the port command and then listen to that port?
 
Can someone explain me how to initate a data transfer?
 
+Gus Cavazos
+em306965@itesmvf1.rzs.itesm.mx
+alex@sunserv.cem.itesm.mx
 

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Mar 1993 16:28:18 -0500
From:      Richard Romero <rickr+@CMU.EDU>
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Wanted: authorization server for heterogenous IP environment

A keyserver equivalent doesn't exist for Unix.  (If I'm wrong, please
tell me--it'd be great news, but we haven't been able to find one.) Lots
of problems in doing this sort of thing for unix, considering all the
different types of executables and run-time libraries that come from
different vendors.   Software makers have been moving towards the use of
this sort of licensing scheme, though, as there are commercial products
to do this that they can plug in to their software, the most popular of
which is FlexLM from Highland Software.  Novell (I believe) has built in
procedures for this, but the software has to be served over the net.

-rick romero

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Mar 1993 16:42:06
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Default route on subnet with two routers?

In article <1nrddnINNcj4@cronkite.cisco.com> tli@cisco.com (Tony Li) writes:

    o   Run a router discovery protocol.
    
Sometime soon (April, I hope), PC/TCP for DOS v2.2 will be out, with
support for RFC 1256 (ICMP Router Discovery Messages).

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


-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Mar 1993 13:42:55 GMT
From:      jfjr@mbunix.mitre.org (Freedman)
To:        comp.protocols.tcp-ip
Subject:   unrecognized IP options

  What are gateways/routers required to do when encountering
unrecognized IP options (I believe CISCO gives up and returns and
ICMP). What do they do in real life?

                                     Jerry Freedman,Jr

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Mar 1993 13:47:36 GMT
From:      ydavid@dxds04.cern.ch (David Yann)
To:        comp.protocols.tcp-ip
Subject:   FAQ?


Is there an FAQ to this newsgroup? If yes, where can I find it 
(ftp sites, etc.)? I am most interested in asynchrounous TCPIP
communications, notably between OS\9 and UNIX systems.

Please email answers, since I am not a regular reader of this newsgroup.

Thanks in advance!

Yann David
ydavid@dxcern.cern.ch

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 93 14:59:07 GMT
From:      skibo@florida.wpd.sgi.com (Thomas Skibo)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

In article <1nqfm1$sb2@lll-winken.llnl.gov>, booloo@framsparc.ocf.llnl.gov (Mark Boolootian) writes:
|> 
|> I'm very interested in the issue of high speed networking and TCP.  The 
|> comment that there are several implementations of TCP with the Van Jacobson
|> extensions which work well intrigues me.  I have copies of Dave Borman's
|> slides from an IETF presentation which give some observed TCP rates between
|> a couple of Crays.  I believe these may be the highest throughput numbers
|> ever claimed for TCP.  Borman et al were able to get near-HIPPI speeds
|> for memory-to-memory TCP transfers between two Crays (> 700 Mbits/sec).
|> 
|> But at what cost?  These were dedicated machines and, as I understand it,
|> an entire CPU was consumed just performing checksum operations.  Furthermore,
|> as I recall (I can't find the bloody paper so this is from memory), the
|> window being used was somewhere around 6 Megabytes in size.  That requires
|> 6 megabytes of kernel space be set aside for that one connection.  

6 Megabytes is dirt cheap.  I just put another 32 Meg in my personal
workstation.  It didn't break the group budget.

Besides, I don't think 6 Meg windows were used in Dave's experiments.
I thought 6 megabytes was just the number batted around the gigabit
workshops as the amount of windowing needed to do a gigabit across the U.S.

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Mar 1993 14:59:40 GMT
From:      ddean@sapphire.risc.uni-linz.ac.at (Drew Dean)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

In article <C3vwMy.Gw3@news.iastate.edu> john@iastate.edu (John Hascall)  
writes:
> BTW, that's 6MB per connection.  On my mostly idle workstation:
> pooh.cc> netstat -a | grep ^tcp | wc -l
>       19
> that would be 114MB (hmmm, seems I'm about 90MBs short).

Note:  this was orginally in the context of a Cray.  The last Cray  
installation I heard about (a couple years back, I think) I believe had  
512 MB RAM.  I don't know what Crays ship with today.

Now, it's already been pointed out that not all TCP connections will need  
this much memory.  If you're really trying to go fast on a 1 GB RAM  
machine, why are you griping about 6 MB (ie. 6% of RAM) ?  You probably  
care about getting your job done in a hurry -- that's why someone bought  
you this really expensive & fast computer.

I don't expect 1 Gb/s on my desktop any time soon (OK, so it's maybe 5  
years out :-)).  Ethernet is fast enough for many things (especially with  
800+ KB/s transfers from a modern TCP), and desktop workstations tend not  
to have the memory bandwidth to do much at 100 Mb/s speeds (yes, SGI, HP,  
and others that I don't know about can do 90+ Mb/s TCP, but you don't get  
to do much with the data if you want to keep up that speed).
--
Drew Dean
ddean@risc.uni-linz.ac.at
Not speaking for RISC, of course.

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Mar 1993 15:14:19 GMT
From:      bwarner@mentor.cc.purdue.edu (Bill Warner)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

In article <1993Mar14.024236.23833@ultb.isc.rit.edu> jek5036@ultb.isc.rit.edu (J.E. King) writes:
>
>Has anyone thought of a transfer protocol that doesn't use ACKs but only
>requests a resend of damaged packets such as Zmodem does?  Please excuse
>my ignorance; I'm a young networking student and I don't know much about
>anything at this point..
>
>- Jim

One thing to keep in mind is that in TCP ACKs have more than one function.  A
TCP ACK does more than simply acknowledge that data has been received, it is
also part of TCPs flow control mechanism.



-- 
Bill Warner						(317)494-1787
General Consultant					bwarner@cc.purdue.edu
Purdue University Computing Center			bwarner@PURCCVM.BITNET

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 93 13:46:20 +0100
From:      weis@mvax.uakom.cs
To:        comp.protocols.tcp-ip
Subject:   ** What is better TCP/IP or X.25 ?**

Hi networkers,

We have problem. We have some LAN (ethernet) in different towns.
In our LANs are connected PC with QNX. LAN in Bratislava (town)
 we have connect VAX with ULTRIX 4.2. Our LAN we want join to private
network.

Which protocol will be used ? X.25 or TCP/IP ?
Which is better and why ?

Many thanks for help.

		Tibor

==========================================================
Tibor WEIS
Computer Center                      tel: ++42 855 268 68
Technical University                 fax: ++42 855 200 27
Masarykova 24
960 53 ZVOLEN                     E-mail: tibor@tuzvo.cs
S L O V A K I A
==========================================================

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 93 16:55:06 GMT
From:      cawilco@afterlife.ncsc.mil (Chris A. Wilcox)
To:        comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: IP over ATM

In article <1993Mar12.200535.23926@novell.com> donp@novell.com (don provan) writes:
>In article <1993Mar12.165640.264@afterlife.ncsc.mil> cawilco@afterlife.ncsc.mil (Chris A. Wilcox) writes:
>>As I said in my earlier posting, it is both meet and right to run IP
>>over ATM right now, because there is an operational requirement to do
>>so. My assertion was that IP might not be the best protocol to run in
>>the future. It shouldn't be followed slavishly just because there is
>>"a HUGE TCP/IP installed base". After all, for the most part it *is*
>>only software, and software is rather easily replaced.
>
>I think you're reading this argument backwards.  The point isn't that
>there's a huge installed base, so we can't change.  The point is that
>there's a huge installed base because TCP/IP can handle so many
>different types of networks so well, while isolating the TCP client
>entirely from the any consideration at all of the topology required to
>actually support his connection.  You might be able to do better over
>ATM, but i really don't think you'll be able to do any better over an
>Internet that is using, among other things, ATM.

I agree with your statements, because up to now that is the case. Don't
get me wrong, I like TCP/IP. It is a very flexible interface that works
well on a lot of things. The issue I am worried about is people are going
to go out and say "Well, TCP/IP works really well today, a lot of folks
use it, so let's just run that on ATM." and that is the "solution". There
are alternatives out there, and I don't think that there has been a lot
of experimental work done on live comparisons of various protocols (TCP/IP
included). TCP/IP might still end up being the winner, and if so, that's
great. If not, then that is something we have to consider.

>Although i did find it very amusing that you think it's easy to
>replace a network because it's "only software".  Ah, to be young and
>innocent again.

Yeah, my youthful innocence/eternal optimist button was stuck in the
"ON" position that day. Sorry... :-)
-- 
Chris Wilcox                |"The guy sure looks like plant food to me"
Dept. of Defense            |                     Seymour and Audrey II
cawilco@afterlife.ncsc.mil  |                  'Little Shop of Horrors'
The views represented here probably aren't held by the DoD. Get over it.

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 93 17:47:56 GMT
From:      millerl@wharton.upenn.edu
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Wanted: authorization server for heterogenous IP environment

I'm looking for a generic authorization server that runs over IP like 
KeyServer works over Appletalk. The idea is that you embed an authorization 
client in an application program so that when the application starts up it 
requests a ticket to run the application from the authorization server. If 
there is a free slot on the authorization server to run that application and 
the client fits other arbitrary restrictions (such as being from the correct 
subnet) then the ticket is granted. Every hour or x amount of time the 
ticket expires and the client asks the server for a new ticket so it can 
continue. It is not necessary for the authorization server to be the source 
of the applications. Applications can be installed locally, but the 
authorization comes from the server. I'm looking for such a program, with 
client stubs (to be prepended to applications) for Macintosh, DOS, Windows, 
OS/2, various Unixes, or any other arbitrary operating system.

Do you know of a program that would fit my description or come close?

Thanks,
Loren

-- 
whoah,
+++++++++++++++++++++++23
Loren Miller                           internet: MILLERL@wharton.upenn.edu
S sign lists littles what wetland received in phire bonuse    --1M Monkeys

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Mar 1993 19:23:33 GMT
From:      rps@matuc2.mat.uc.pt (Rui Pedro Mendes Salgueiro)
To:        comp.protocols.tcp-ip,comp.windows.x.apps
Subject:   graphical monitoring IP traffic

I am looking for a X application that monitors the network and display
that information using X (something similar to traffic on a SUN).

If you know of such an application mail me (I'll sumarize).

--
   Rui Salgueiro     |   Dpt. de Matematica    | "I wear black on the outside
rps@matuc2.mat.uc.pt | Universidade de Coimbra | cause black is how I feel on
   rps@inescc.pt     |    Portugal - Europe    | the inside" - Morrissey

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1993 19:48:29 GMT
From:      spp@zabriskie.berkeley.edu (Steve Pope)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

Thomas Skibo:

> Besides, I don't think 6 Meg windows were used in Dave's 
> experiments.  I thought 6 megabytes was just the number batted 
> around the gigabit workshops as the amount of windowing needed 
> to do a gigabit across the U.S.

I would regard this number as fairly scientific.

It's about 20% greater than the round-trip-time at .8 c --
anything less than that would degrade performance with
any nontrivial packet loss rate.

Steve

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 93 19:54:36 GMT
From:      schmidt@net1.ics.uci.edu (Douglas C. Schmidt)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

In article <1993Mar15.145940.19539@alijku05.edvz.uni-linz.ac.at> ddean@risc.uni-linz.ac.at writes:
++ and desktop workstations tend not
++ to have the memory bandwidth to do much at 100 Mb/s speeds (yes, SGI, HP,
++ and others that I don't know about can do 90+ Mb/s TCP, but you don't get
++ to do much with the data if you want to keep up that speed).

Hi,

	I'm curious to know what the general trend in memory bandwidth
improvements have been during the past 10 years or so.  For example,
network channel speeds are increasing around 5 to 6 orders of
magnitude (from kbps to Gbps) and micro-processor speeds are
increasing 2 to 3 orders of magnitude (from 1 MIP up to ~100 MIPS).
Does anyone know what the equivalent increases are for memory
bandwidth in general?

	Thanks,

		Doug
--
His life was gentle, and the elements so            | Douglas C. Schmidt
Mixed in him that nature might stand up             | schmidt@ics.uci.edu
And say to all the world: "This was a man."         | ucivax!schmidt
   -- In loving memory of Terry Williams (1971-1991)| (714) 856-4101

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1993 20:23:17 GMT
From:      booloo@framsparc.ocf.llnl.gov (Mark Boolootian)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

In article <visser.732055715@convex.convex.com> visser@convex.com (Lance Visser) writes:
>	You have to understand what these high-speeds are wanted for.  they
>are typically being used to pipe massive amounts of data in and results
>out.....not for running telnet or xterms.  If your bringing in bulk
>data either for computational processing, file storage/retreval, or acting
>as a front end to fast tape or video, you dont really care how much of 
>the machine your using.

I don't agree with your last statement.  I think there are two classes of
machines for which high-speed interfaces are being developed:  single-user
and multi-user.  In the single-user category I would place PCs, Macs, and
workstations.  In the multi-user category, I would place servers and
supercomputers (this is simplistic and overly general but it will suffice
for my point).

In the single-user case, I agree that you don't really care how much of your
machine is consumed doing networking.  If everything else stops while the
network goes, it is acceptable (although, in practice, intolerable).  A given
individual probably does much of their work sequentially, hence the computer
is used, more or less, in a similar fashion.

In the multi-user case, the situation is much different.  Everyone competes
for shared resources.  If your network connection sucks up all the cpu, then
everyone suffers.  In a production environment, it is unacceptable to have
any single user overwhelm system resources.  Thus, you care a great deal
about how big a piece of the machine each user gets and how long they get it.


>>I am personally unconvinced (at least, this morning...) that TCP can actually
>>be used to provide true gigabit speeds in a production environment.  I'd
>>certainly like to hear other's views on this matter.
>
>	I am very interested in knowing what you want to use gigabit speeds
>for.  The closer you get to gigabit speeds, the sorts of applications you
>run and the interaction of those applications changes greatly.  With
>gigabits speeds, everything seems to tend more and more toward "staging"
>of tons of data locally rather than constantly going back and forth 
>across the network.


The specific needs aren't really clear to me at this point.  We certainly have
the need for faster networks here.  In particular, our archival storage
system tends to back up because files can't be moved quickly enough.  However,
we don't need gigabit rates to fix this problem.  I'd be happy with a lousy
three or four hundred megabits/second :-).

One place where gigabit speeds would be very helpful is in the area of
visualization.  The generation of large data sets which can be visually
characterized coupled with gigabit networking opens up the possibility of
playing "movies" of generated data at full speed.  

mb
-- 
Mark Boolootian		booloo@llnl.gov		+1 510 423 1948
Disclaimer:  booloo speaks for booloo and no other.

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1993 20:32:20 GMT
From:      booloo@framsparc.ocf.llnl.gov (Mark Boolootian)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?


In article <1993Mar13.210937.21699@ns.network.com> dotytr@nscultrix2.network.com (Ted Doty) writes:
>It looked from the results that there wasn't too much improvement for
>windows larger than 512k, but this might be dependent on the test
>network.  

After Thomas Skibo explained it, I realized I was misreading Borman's slides.
In one of his slides, Borman says they achieved 781 Mbits/sec using a
kernel buffer of 378K and a window shift of 4.  I took this to mean that 
the window was 378K * 2^4 ~= 6 Megabytes.  But, in fact, the window (which
should be identical with the kernel buffer space) was 24K * 2^4 = 378K.

I apologize for spreading misinformation.

mb
-- 
Mark Boolootian		booloo@llnl.gov		+1 510 423 1948
Disclaimer:  booloo speaks for booloo and no other.

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1993 22:11:58 GMT
From:      gih900@jatz.aarnet.edu.au (Geoff Huston)
To:        comp.protocols.tcp-ip
Subject:   Re: Guaranteed Unused IP Network?

Donald E Eastlake III (beast@world.std.com) wrote:

: I believe 192.0.2.* is reserved for testing.  It should be possible to
: check this with the latest reserved numbers RFCs.

Yup .. to quote Jon Postel in a note to the IETF some weeks back...

  To: ietf@isi.edu
  Subject: Re: illegal use of reserved network numbers

  ...

  As Vernon Schryver points out 192.0.2.x is designated for just this use.

  No real network traffic should be sourced or sinked at this network.

  Vendors which ship an out-of-the-box runnable TCP/IP engine
  are encouraged to ship their products with the factory default
  IP address 192.0.2.1.

  All Internet routers are encouraged to discard any traffic to or from
  network 192.0.2.0


geoff huston

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1993 00:37:18 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: unrecognized IP options

In article <1993Mar15.134255.15796@linus.mitre.org> jfjr@mbunix.mitre.org (Freedman) writes:
      What are gateways/routers required to do when encountering
    unrecognized IP options (I believe CISCO gives up and returns and
    ICMP). What do they do in real life?
    
Actually, a cisco is not supposed to do that.  Have you found a bug for me
to fix?  ;-)


-- 
abyss \*-'bis\ n 
  1 : the bottomless gulf, pit, or chaos of the old cosmogonies  2 a : an 
  immeasurably deep gulf or great space  b : intellectual or spiritual 
  profundity; also : vast moral depravity 3 a Border Intermediate System

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Mar 93 02:54:38 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Of course we're running out of IP addresses!

Of course we're running out of IP addresses -- they're free!  Should
it surprise anyone that if you give away something valuable for
nothing, people will suck them up?

Not only are they valueable in themselves, but they're valuable when
you have lots more than you need (so you can route using bitmasks).

Maybe the NSF should charge a penny per IP address per year, plus $25
minimum.  I'd be more than happy to pay my $27.50 for my class-C
network if HP had to pay $167,000 per year for its class-A IP
addresses.  I wonder how many it's actually using (that is, those on
open subnets...)?

Boy, I bet *that* would free up a lot of class-A networks!  :)

-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Mar 1993 11:51:39 EST
From:      <CANTERO@EVALUN11.BITNET>
To:        comp.protocols.tcp-ip
Subject:   problems with Etherlink II-16

I have Etherlink II-16 and it must work in a pc-xt with bus-8 bit.
I don't know if problems is the packet driver because when I run
the diagnose program never problems is found, but when I run the
packet driver the pc crashed ÙÙÙÙÙÙ
I use the 3c503.com of crynwr.

                   Thanks in advanced

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 93 11:52:42 GMT
From:      jim@cs.strath.ac.uk (Jim Reid)
To:        comp.protocols.tcp-ip
Subject:   Re: ** What is better TCP/IP or X.25 ?**

In article <1993Mar15.134621.36@mvax.uakom.cs> weis@mvax.uakom.cs writes:

   We have problem. We have some LAN (ethernet) in different towns.
   In our LANs are connected PC with QNX. LAN in Bratislava (town)
    we have connect VAX with ULTRIX 4.2. Our LAN we want join to private
   network.

   Which protocol will be used ? X.25 or TCP/IP ?
   Which is better and why ?

It's hard to answer your questions from the information you provided.

If you run TCP/IP on both LANS, it's best to run TCP/IP over the link
between them. This will allow telnets, rlogins, ftps, SMTPs, etc to
work across the two LANS over the link between them. This link would
probably be a serial line (probably 64K or upwards) provided by the
phone company or PTT. Each end of this line would plug into a router
which was attached to the LAN.

Now, the question is what kind of serial lines are provided by the PTT
or phone company? Most PTTs or telecom. carriers provide an X.25
network, charging users on a combination of packet counts and connect
time. The other alternative is a leased line (or private circuit)
which the customer typically pays an annual rental. If you have a
leased line, you can usually run any protocol you choose over it. This
depends on local telecom regulations and the conditions of usage laid
down by your telecom provider.

If the Czech or Slovak PTT only provides X.25, all is not lost. It is
possible to run IP over X.25. There's even an RFC which describes how
to do this. However, this not ideal because of X.25 packet charges and
wasted bandwidth. You have TCP headers inside IP headers inside X.25
headers inside HDLC headers....

		Jim

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Mar 1993 14:18:30 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In article <732250478snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:

>Maybe the NSF should charge a penny per IP address per year, plus $25
>minimum.  I'd be more than happy to pay my $27.50 for my class-C
>network if HP had to pay $167,000 per year for its class-A IP
>addresses.  I wonder how many it's actually using (that is, those on
>open subnets...)?

  Actually, I don't mind HP or GE very much because they actually use
a reasonable portion of their Class A address.  *FORD*, on the other
hand, used to have *3* separate Class A addresses and was wasting lots
and lots of address space.

  A lot of sites have multiple Class B addresses and don't need them
and those are actually even more valuable than the Class As.  To get a
Class B in the modern day you have to have the most amasing
justification.  In the old days, it was "ask and ye shall receive".  A
major "Class B address reclamation effort" by the NIC is needed to
revoke Class Bs from sites that have more than 1 of them.  That alone
would help _tremendously_.

  The NIC is supposedly implementing CIDR and so the address space
problem is not as crushing as it was a year ago.  It still isn't good
and that is the main force behind the next-generation IP efforts.

Ran
atkinson@itd.nrl.navy.mil

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Mar 1993 14:27:57 GMT
From:      Dean.Roth <Dean.Roth@mixcom.mixcom.com>
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In <732250478snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:

>Not only are they valueable in themselves, but they're valuable when
>you have lots more than you need (so you can route using bitmasks).


Question: How is a number reclaimed when the organization it is 
allocated to stops using it or stops operating?

One problem is that the smallest number of addresses one can get
is 256 (O.K., actually 254) - a class C number. Most small 
organizations only need 1 address, not 254.

A service organization can help by having a class B or C number
and allocating addresses to organizations it provides connections to.

Dean

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 93 17:31:30 GMT
From:      ercm20@festival.ed.ac.uk (Sam Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

Dean.Roth@mixcom.mixcom.com (Dean.Roth) writes:
> One problem is that the smallest number of addresses one can get
> is 256 (O.K., actually 254) - a class C number. Most small 
> organizations only need 1 address, not 254.

Err.. a little difficult to know exactly what you'd do with a network of
one machine... :-)  Think again.  I can imagine some things that you
might mean, but I think you'll have to express yourself better!

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

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1993 17:38:41 GMT
From:      emv@msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

Russ,

Who gets the money?

--Ed

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 93 18:55:36 GMT
From:      spp@zabriskie.berkeley.edu (Steve Pope)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

ercm20@festival.ed.ac.uk (Sam Wilson) writes:

>Dean.Roth@mixcom.mixcom.com (Dean.Roth) writes:
 
>> One problem is that the smallest number of addresses one can get
>> is 256 (O.K., actually 254) - a class C number. Most small 
>> organizations only need 1 address, not 254.
>
> Err.. a little difficult to know exactly what you'd do with a network 
> of one machine... :-)  Think again.  I can imagine some things 
> that you might mean, but I think you'll have to express yourself 
> better!

Lots of Class C subnets have exactly one address in use.  For example,
my site at kbr.com has exactly one internet host, which is
mailhost for the rest of our site's network.  The remaining subnet
addresses are unassigned, although we could make use of them
in the future.

Dean Roth's point is correct.  An interesting exercise would
be to scan the nic database and determine just what fraction
of class C subnets have only one or two addresses assigned
to hosts.

Steve

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Mar 1993 20:05:34 GMT
From:      munroe@paradyne.com (Greg Munroe X8390)
To:        comp.protocols.tcp-ip
Subject:   What are the different versions of SLIP?


Hello,

I would like to know what versions of SLIP exist?
So far I have come up with the following:

     o	SLIP derived from RFC 1055
     o	CSLIP that uses RFC 1055, V Jacobson Compression, and tunneling.

If you know of any other versions, please send mail.

Thanks!

Greg Munroe
munroe@pdn.paradyne.com

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 93 20:45:20 GMT
From:      spoelhof@kodak.com (Gordon Spoelhof)
To:        comp.protocols.tcp-ip
Subject:   Re: file permissions criteria on FTP

In article <1993Mar13.001246.4233@walter.bellcore.com>, 
maritza@espresso.bae.bellcore.com (Maritza Ramirez) writes:
> From: maritza@espresso.bae.bellcore.com (Maritza Ramirez)
> Newsgroups: comp.protocols.tcp-ip
> Subject: file permissions criteria on FTP
> Keywords: FTP
> Date: 13 Mar 93 00:12:46 GMT
> Organization: Bell Communications Research
> 
> 
> 
> 
> Does anyone know how is it determined - in Unix - the permissions 
> that a given file will have in the receiving end ?
> 
You don't in all ftp server implementations.  Hopefully, the remote
system (ftp server) will create files on the remote host with the 
umask of the remote system's account.  Unfortunately this is not always
the case.

In general, commercial ftp servers cannot create FILES with any execute
permission(s).  Directories of course are another story %^).

Some ftp servers implement commands local to that type of machine or
site.  These extensions to ftp are usually done via the SITE command.
For example, the Berkeley ftp server (available on ftp.uu.net) and
other archives, allows you to set the remote system umask via a site
command.  And a command which allows you to chmod remotely as well.

As far as I know that is what you are stuck with.  If anyone can find
another avenue, please let me know.

I wish that commercial unix variant platform providers such as Sun
(and many others) would provide a Unix aware ftp server.  By the way,
the SITE command is RFC959 compliant:

         SITE PARAMETERS (SITE)

            This command is used by the server to provide services
            specific to his system that are essential to file transfer
            but not sufficiently universal to be included as commands in
            the protocol.  The nature of these services and the
            specification of their syntax can be stated in a reply to
            the HELP SITE command.

Anyone know which commerical unix variant platform providers do fit this
need?

Gordon Spoelhof
Eastman Kodak Company / Health Sciences Division
25 Edendery Circle / Fairport, NY 14450-1013
Email: spoelhof@kodak.com
Phone: 716-253-9735 / FAX: 716-253-7966
Miopiceconomics: (n) the study of increased system cost through unit optomization.  See short-sighted...

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Mar 1993 20:48:12 GMT
From:      add@is.rice.edu (Arthur Darren Dunham)
To:        comp.protocols.tcp-ip,comp.sys.mac.system,comp.sys.mac.comm
Subject:   MacTCP 1.1.1 woes

A further plea for help.  I'm now going crazy attempting to install
MacTCP on some macs.  The MacTCP (1.1.1), Turbogopher and Telnet (2.5)
all run fine on other machines.  I worked more vigorously on a single
classic this time.  Here's what I did.

Did a fresh install of 6.0.7, put on MacTCP, set up DNS and placed in
SERVER mode (LocalTalk behind a GatorBox).  All TCP apps die on launch
and give me "Address Error (Restart)"

Took System, Finder, and MacTCP and put them in a new folder all by
their lonesome.  Exact same thing occurs.

Put the 3 files back, and tried MultiFinder (Mac has 2M).  App launch
now gives "The Application (whatever) has unxepectedly quit (2)".

Placed MacsBug in the System Folder, tried again.  I flipped into the
debugger in the app TurboGopher (expected).  I don't know anything about
really using MacsBug though, so I just stepped forward a while, then
continued.  TurboGopher proceeded to launch (splash screen) then gave
the error message "MacTCP drivers failed to load (-23004)".  Does anyone
know if the 23004 is significant in MacTCP or is it a dumb "couldn't
load" error?

This is happening to me on 4 machines in one department, when I've never
seen it before on anything.  HELP.

Thanks in advance, e-mail would be nice if I'm being dumb about
something here.  Followups are directed to comp.sys.mac.system.
-- 
Darren Dunham                 		          add@is.rice.edu
MicroConsultant                       		  Rice University
(What is that? A small consultant?)	              Houston, TX
Any resemblance between real opinions and my post is coincidental

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Mar 1993 21:34:12 GMT
From:      peter@ferranti.com (peter da silva)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

In article <1nqvea$l7j@agate.berkeley.edu> spp@zabriskie.berkeley.edu (Steve Pope) writes:
> I also don't see much way of avoiding the need for large (6 meg)
> windows by protocl redesign either...

Given the topic (gigabits per second network traffic), the cost of 6 MB of
RAM (a bit over $200) per connection is probably lost in the noise. You
are going to be *doing* something with that data, right, other than sticking
it in a buffer and overwriting it... once you have hardware capable of
sustaining useful throughput at that rate on multiple connections doing real
work with the data you're probably talking about a system with a lot more
RAM than that.

As for checksumming... if just *checksumming* that data is a killer, how do
you propose to do useful work on it at that rate?
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 93 23:00:58 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In article <732250478snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
>Of course we're running out of IP addresses -- they're free!  Should
>it surprise anyone that if you give away something valuable for
>nothing, people will suck them up?
>
>Not only are they valueable in themselves, but they're valuable when
>you have lots more than you need (so you can route using bitmasks).
>
>Maybe the NSF should charge a penny per IP address per year, plus $25
>minimum.  I'd be more than happy to pay my $27.50 for my class-C
>network if HP had to pay $167,000 per year for its class-A IP
>addresses.

Actually, to recover the real costs, I see the following cost elements:
(1) to the Internet Society and IANA for the addresses ($25 +
    $.01/address seems about right)
(2) to the Routing Authority for advertizing the route ($1000/year per
    route)
(3) to the Local Access Carrier for
	- pipe width ($100/month for 56K)
	- route tax ($100/year per route)
(4) to the local telephone company for the physical wire

With a cost structure like this, it would be interesting to see how many
customers would volunteer to renumber their hosts when changing access
carriers (so they could ride for free on the carrier's core route).

Certainly, the supply of IP addresses would last a few years longer
under rules like these.
-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Mar 1993 01:52:06 GMT
From:      sandhoff@csus.edu (John F. Sandhoff)
To:        comp.dcom.lans,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   PCRoute/PCBridge/Localtalk help needed

I'm looking for some information on compiling and configuring PCRoute
to use Appletalk interfaces in a bridging configuration. What I ultimately
want to do is set up a pair of Enet-ATalk boxes to bridge an ethernet
segment across 2000' of copper. I have to bridge and not route as I'm
trying to pass IPX. I've set up several PCRoutes so I know all the basics
but I've got several questions about this implementation.

Appletalk cards: As far as I can tell I can use either Apple's LocalTalk
cards with the ATALK.EXE driver, or TOPS FlashCards with ATALK.SYS. Can I
use one of each, or do I have to have the same type card on each end? (Yes,
as a matter of fact I *do* have one of each) [Side note: Everex used to make
the SpeedTalk card, model EB2019. This is out of production and unavailable
now. Sun Microsystems still makes the TOPS cards (Sun/Sitka/TOPS are all
the same); special order thru CompUSA and in stock at Inmac (p/n 856520 for
the ISA version)]

Now, that was just the warmup question; here's the real place I need help
with: how to do it? More specifically, the PCBridge code supports WD/SMC,
3Com and packet drivers. But is there a packet driver that will make the
LocalTalk card work? (My understanding is that the localtlk driver
is not type 1 which is ethernet but rather is type ? which is appletalk.
So my untested guess is that I cannot use pcbridge/packet driver to talk
to the card. Does anyone know different?)

Otherwise, has anyone hacked PCBridge to add native support for the TOPS
card? This is a task I'd rather not attempt, but maybe someone else already
has (hey, hope springs eternal, okay?)

The alternative is to use PCRoute, since v2.24 supports bridging as well
as appletalk cards (via atalk driver, of course). I've looked at the
definition file and found the lines to uncomment to compile with bridging
support, but I haven't actually attempted a build yet. Has anyone else? Does
it work? Any gotchas? Tired of listening to me yet?

Thanks in advance,

    John F. Sandhoff, University Network Support
      California State University, Sacramento - USA
        sandhoff@csus.edu


-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Mar 1993 02:28:39 GMT
From:      "Allen Robel" <robelr@mythos.ucs.indiana.edu>
To:        comp.protocols.tcp-ip
Subject:   (none)

Subject: Re: Default route on subnet with two routers?
Newsgroups: comp.protocols.tcp-ip
Distribution: world 
References: <930315164206@cream.ftp.com>
James Harvey writes:

>o   Or something else I haven't thought of? (but see below)

You might try the gateway discovery deamon available from
cisco.com.  It'll listen for routing updates to determine
what routers are out there.  Cisco doesn't allow you to
do a directory of their ftp server, but you can retrieve
the README to find out what's there.  The deamon's file
name is:

gdpd.shar               Gateway Discovery Protocol daemon (Unix). No support;
                        no guarantees.
f
Hope this helps, and good luck!


Allen Robel                      robelr@mythos.ucs.indiana.edu
University Computing Services    ROBELR@IUJADE.BITNET
Network Services Development     voice: (812)855-7171
Indiana University               FAX:   (812)855-8299

"For every difficult and complicated question there is an answer that 
     is simple, easily understood, and wrong" -- H.L. Mencken


-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Mar 1993 04:10:00 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: IP over ATM

cawilco@afterlife.ncsc.mil (Chris A. Wilcox) writes:

> I don't think that there has been a lot
> of experimental work done on live comparisons of various protocols (TCP/IP
> included). TCP/IP might still end up being the winner, and if so, that's
> great. If not, then that is something we have to consider.

My personal take on this is, if TCP/IP doesn't run well over ATM, it will
hurt ATM more than it hurts TCP/IP.  Not that it would kill either of them,
but it will slow down ATM's advance into the LAN market, and ATM's
successor, in 1998 or whatever, will be raved about in magazines "because
it fixes ATM's deficiencies in carrying TCP/IP."

There are too many wierdo TCP/IP implementations, for discontinued-but-
still-supported systems, in the hands of too many customers, for TCP/IP's
installed base to ever even consider switching to another level 3/4
protocol.

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

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1993 11:39:27 +1000
From:      g9066624@wampyr.cc.uow.edu.au (Tippu Hassan)
To:        comp.protocols.tcp-ip
Subject:   Frame Relay

hi


i am working on the interconnection of LANs using frame relay. I would 
greatly appreciate any information in this regard. In perticular, any 
ftp site addresses having software on frame relay would be really helpfull.

thanks


tippu

tippu@snrc.uow.edu.au



-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 93 05:50:05 GMT
From:      antony@ee.uts.edu.au (Antony Richards)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

booloo@framsparc.ocf.llnl.gov (Mark Boolootian) writes:

>After Thomas Skibo explained it, I realized I was misreading Borman's slides.
>In one of his slides, Borman says they achieved 781 Mbits/sec using a
>kernel buffer of 378K and a window shift of 4.  I took this to mean that 
>the window was 378K * 2^4 ~= 6 Megabytes.  But, in fact, the window (which
>should be identical with the kernel buffer space) was 24K * 2^4 = 378K.


A lower bound for the amount of memory required to operate an error control
scheme efficiently (ie no transmitter idle time) of a network is given by
the product of the bandwidth and the round trip delay.  This value represents
the amount of unacknowledged data sitting in the network.

It has been estimated that for a (transport) connection from coast to coast in
America the round trip delay would be 60ms. A 100  Mbps transport connection
would require a error control buffer size of 750 Kbytes at the transmitter
and at the receiver for a selective reject scheme.  A giga-bit transport
connection would require 7.5 Mbytes of memory.

From the discussion, I would have to assume that the experiment was conducted
on equipment that did not have a large round trip delay.  That is, there must
have been few, if any intermediate nodes in the experimental network.  Perhaps
somebody would like to comment on this?

Getting back to the issue of resources.

>From: visser@convex.com (Lance Visser)
>In <C3vwMy.Gw3@news.iastate.edu> john@iastate.edu (John Hascall) writes:
>
>+>craig@sics.se (Craig Partridge) writes:
>
>+>}Megabytes of memory are cheap.  I have no problem with the idea of a 6
>+>}megabyte window on my SUN workstation -- it comes pretty much standard with
>+>}20 meg.  And memory prices are going down.  Let's keep in mind that gigabits
>+>}to our desktops are a few years away -- memory is not a problem.
>
>+>BTW, that's 6MB per connection.  On my mostly idle workstation:
>+>pooh.cc> netstat -a | grep ^tcp | wc -l
>+>      19
>+>that would be 114MB (hmmm, seems I'm about 90MBs short).
>
>	What your overlooking is that different sorts of connections
>dont require the same amount of buffer.  Your not going to need 
>6MB of socket buffer for lets say a telnet connection or any other
>sort of interactive connection (like an xterm).
>	If your going to do big bulk data transfers, the you reserve the
>necessary memory to "do" them with via existing socket options for setting
>the window size.

All the arguments given are still valid as long as they are scaled to
750Kbytes (for a 100 Mbps connection) and 7.5 Gbytes (for a 1 Gbps connection).


-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1993 06:00:05 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Help on implementing FTP

In article <16B929016.EM306965@itesmvf1.rzs.itesm.mx> EM306965@itesmvf1.rzs.itesm.mx writes:
>I can't initate a data transfer.
>Is there a standard port to transfer data?

By default, port 20 is used.

>Do I have to use the port command and then listen to that port?

You don't have to use the PORT command (you can let it default to 20), but
you do have to listen to the data port.  It's often easier to implement it
when you use the PORT command, as you don't have to worry about another
process already listening on port 20.  Most systems have a way to listen on
an unused port (with Unix sockets you specify port 0 in the call to bind(),
and then use getsockname() to find out what was assigned); do that, send
its port number in the PORT command, and then listen for a connection.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Mar 1993 06:55:24 GMT
From:      IJohnston@cmutual.com.au (Ian Johnston)
To:        comp.protocols.tcp-ip
Subject:   TCP keepalive



Can anybody see why I should not adjust my kernel from the default
TCP keepalive idle time of two hours to something like five minutes?

We have a problem with a large PC network that open TCP sockets to
a server (Oracle RDBMS orasrv program) which sets the SO_KEEPALIVE option.
The PC's then reboot (or crash) for some reason leaving the Oracle process
running on the server for two hours until the keepalive takes affect.  This
causes problems with table locks and the like.

I have located the kernel variables I have to change but I wan't to make
sure that I won't break anything.  I suppose there is a reason the default
timeout is so high.

Thanks in advance

Ian J

-- 
Ian Johnston                                 email: IJohnston@cmutual.com.au
UNIX System Admin.                           phone: +61-3-6418548
Colonial Mutual Life Aust. (ACN 004021809)   fax  : +61-3-6076198

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1993 07:18:36 GMT
From:      spp@zabriskie.berkeley.edu (Steve Pope)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

antony@ee.uts.edu.au (Antony Richards) writes:

>booloo@framsparc.ocf.llnl.gov (Mark Boolootian) writes:
 
>>	What your overlooking is that different sorts of connections
>> dont require the same amount of buffer.  Your not going to need 
>> 6MB of socket buffer for lets say a telnet connection or any other
>> sort of interactive connection (like an xterm).
>
> All the arguments given are still valid as long as they are scaled to
> 750Kbytes (for a 100 Mbps connection) and 7.5 Gbytes (for a 1 Gbps 
> connection).

I agree with booloo that you do not need more than 7.5 megabytes
per long-haul gigabit network interface in this example.

Local LAN connections will not need that huge of a buffer because
of the much smaller RTT.  And, you are only going to have one,
at most maybe two or three gigabit WAN's routed to any one 
host ...

My guess is only a very few hosts in a gigabit, North-American
network will need much more than 20 megs of memory supporting
transport protocol windows.  That's peanuts.

Steve

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Mar 1993 10:00:07 GMT
From:      hdavies@rx.xerox.com (Hugh JE Davies)
To:        comp.protocols.tcp-ip
Subject:   Re: Guaranteed Unused IP Network?

In article 10MAR199310483326@opus1.com, jms@opus1.com (Joel M-for-Vnews Snyder) writes:
>In article <mam-090393121426@192.158.86.2>, mam@gvgspd.gvg.tek.com (Mark A.
>Matthews) writes...
>

[snip]

>
>Aside from the test number (already mentioned here), whenever I do paper
>documentation I always use network number 555 and host number 1212.  It's
>not only illegal, most people can figure out that it's a guaranteed bogus
>number because of the telephone company association. 
>

Sigh. More American parochialism. TCP/IP is worldwide, the 555-1212 stuff
isn't.
---


Regards,

Hugh.
------------------------------------------------------------------
Huge.wgc1@rx.xerox.com       Rank Xerox Technical Centre, WGC, UK.
         I don't speak for Xerox, nor they for me.
"If there is anyone here who I have not insulted, I beg his
           pardon." Johannes Brahms (1833-97).


-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 93 13:04:32 GMT
From:      spoelhof@kodak.com (Gordon Spoelhof)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In article <732250478snx@crynwr.com>, nelson@crynwr.com (Russell Nelson) 
writes:
> 
> Maybe the NSF should charge a penny per IP address per year, plus $25
> minimum.  I'd be more than happy to pay my $27.50 for my class-C
> network if HP had to pay $167,000 per year for its class-A IP
> addresses.  I wonder how many it's actually using (that is, those on
> open subnets...)?
> 
> Boy, I bet *that* would free up a lot of class-A networks!  :)
> 
Only $167,000 per year!  Peanuts! Sign us up for a dozen!  The cost
of making the decisions, staffing, and hardware to support a space
that large is MUCH more than $167,000!


Gordon Spoelhof
Eastman Kodak Company / Health Sciences Division
25 Edendery Circle / Fairport, NY 14450-1013
Email: spoelhof@kodak.com
Phone: 716-253-9735 / FAX: 716-253-7966
Miopiceconomics: (n) the study of increased system cost through unit optomization.  See short-sighted...

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Mar 1993 13:12:31 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!

In article <1993Mar16.230018.15764@cmutual.com.au> IJohnston@cmutual.com.au (Ian Johnston) writes:

>Who do I contact if I wan't to give back a Class B IP number?  

The DDN Network Information Center, who handle address issuance.
Their email address is:		nic@nic.ddn.mil

I forget their telephone number.  They have a toll-free 800 number and
a regular number in the (703) area code.

>I know of a few sites that have applied for and recieved IP numbers 
>and then have not used them.

It would be a tremendous service to the community if those folks would
give up their addresses or even just swap a Class B for one or two
Class Cs.  This should be encouraged.


-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 93 13:37:04 GMT
From:      avalon@coombs.anu.edu.au (Darren Reed)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

ddean@sapphire.risc.uni-linz.ac.at (Drew Dean) writes:
[...]
>I don't expect 1 Gb/s on my desktop any time soon (OK, so it's maybe 5  
>years out :-)).  Ethernet is fast enough for many things (especially with  
>800+ KB/s transfers from a modern TCP), and desktop workstations tend not  
>to have the memory bandwidth to do much at 100 Mb/s speeds (yes, SGI, HP,  
>and others that I don't know about can do 90+ Mb/s TCP, but you don't get  
>to do much with the data if you want to keep up that speed).

Point to point transfers through TCP aren't it though.  When you have an
NFS server and a network of clients attached, the ethernet goes pretty
damn quickly, especially when you have a class running of 20 or so people
all loading up and running an animation demo on the latest version of
AutoCad.  Ok, NFS is bad, but a faster network would make it a bit more
bareable :)

Darren

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Mar 93 14:55:10 GMT
From:      dotytr@nscultrix2.network.com (Ted Doty)
To:        comp.protocols.tcp-ip
Subject:   Long distance connect costs will dwarf memory costs.

In article <1o6jcc$cqn@agate.berkeley.edu> spp@zabriskie.berkeley.edu (Steve Pope) writes:
>antony@ee.uts.edu.au (Antony Richards) writes:
>
>>booloo@framsparc.ocf.llnl.gov (Mark Boolootian) writes:
 
>>>	What your overlooking is that different sorts of connections
>>> dont require the same amount of buffer.  Your not going to need 
>>> 6MB of socket buffer for lets say a telnet connection or any other
>>> sort of interactive connection (like an xterm).
>>
>> All the arguments given are still valid as long as they are scaled to
>> 750Kbytes (for a 100 Mbps connection) and 7.5 Gbytes (for a 1 Gbps 
>> connection).
> [stuff deleted]
>Local LAN connections will not need that huge of a buffer because
>of the much smaller RTT.  And, you are only going to have one,
>at most maybe two or three gigabit WAN's routed to any one 
>host ...
>
>My guess is only a very few hosts in a gigabit, North-American
>network will need much more than 20 megs of memory supporting
>transport protocol windows.  That's peanuts.

For any type of public, North America-wide, gigabit network (providing
coast-coast gigabit service to individual hosts), the cost of the
connection will dwarf the $300 you had to pay to get an 8 MB buffer
added to your host.

Unless the government provides this service "for free" ( ;-) ), we will
see continued movement towards gigabit LANs with MUCH slower wide area
connections.

- Ted

--------------------------------------------------------------------------
Ted Doty, Network Systems Corporation | phone:      +1 301 596-2270
8965 Guilford Road, Suite 250         | fax:        +1 410 381-3320
Columbia, MD, 21046 USA               | voice mail: (800) 233-1485
--------------------------------------------------------------------------
These opinions are my own, not necessarially those of Network Systems.

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Mar 1993 15:07:54 GMT
From:      xwang@ncsu.edu (X C Wang)
To:        comp.protocols.tcp-ip
Subject:   Socket: Close one end?

When a socket channel is broken by closing one end abnormally, 'select'
will see this socket as read available infinitely. How to detect a 
socket is closed by the other end?? 
Thanks in advance.








-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Mar 1993 16:34:57 GMT
From:      man@ms.uky.edu (Manish Gupta)
To:        comp.protocols.tcp-ip
Subject:   ICMP Error Message Generation

In ICMP, all error messages include the IP header of the offending 
datagram + 64 bits of data. 

My question is: when a node copies the IP header, does the standard
require that whatever options (if any) were present be also copied?
or is that upto the implentations?

Any light on the above would be very much appreciated.

Manish Gupta

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Mar 1993 16:45:23 GMT
From:      kudzu@netcom.com (Michael Sierchio)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

In article <antony.732347405@ee.uts.EDU.AU> 
    antony@ee.uts.edu.au (Antony Richards) writes:

>All the arguments given are still valid as long as they are scaled to
>750Kbytes (for a 100 Mbps connection) and 7.5 Gbytes (for a 1 Gbps connection).

7.5 Mbytes?

-- 
+--------------------------------------------------------------------------+
|  Michael Sierchio                          1563 Solano Avenue, Suite 123 |
|  kudzu@netcom.com                                Berkeley, CA 94707-2116 |
+--------------------------------------------------------------------------+

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Mar 1993 16:47:39 GMT
From:      ihsan@ferranti.com (jaleel ihsan)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   ECHO and DISCARD services

In article <C3u4qt.Ew4@ra.nrl.navy.mil>, atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
> 
>   We have never had a problem with our Cisco boxes and we have a large
> number of them (they are the current router available to us on the
> Navy TAC-3 contract).  Folks I know are also quite pleased with
> Wellfleet and Proteon equipment.
> 
  We are happy with our Cisco routers too.  But can any one tell
  if TCP/UDP ECHO and DISCARD services (called "Little Services"
  by Ciscoi and) available in the Cisco routers, are available in
  Wellfleet and Proteon routers ?  I posted this question in the
  Proteon news group but did not recieve any response.

  Thanks for you help.

  Jaleel
>
> [stuff deleted]
> 
> Ran
> atkinson@itd.nrl.navy.mil
> 
> DISCLAIMER: Opinion's are the author's not his employers.

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1993 17:10:12 GMT
From:      emv@msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

Lars Poulsen (lars@spectrum.CMC.COM) wrote:
: (1) to the Internet Society and IANA for the addresses ($25 +
:     $.01/address seems about right)
: (2) to the Routing Authority for advertizing the route ($1000/year per
:     route)
: (3) to the Local Access Carrier for
: 	- pipe width ($100/month for 56K)
: 	- route tax ($100/year per route)
: (4) to the local telephone company for the physical wire

This actually makes quite a bit of sense.  Community or metro networks
now start to look like a real good idea, because if you get a bunch
of people to cooperate and share a class B or a few class C nets, hide
dozens or perhpas hundreds of organizations behind one $1000/yr route,
and otherwise conserve address space by increasing the intra-network
administration costs, the money costs go down.

A pricing goal here at least from the USA point of view is to still enable
the "freenet" / "metronet" / "toasternet" idea of local grassroots IP
networking to be able to deliver service to people at $1/user/mo.  My
back of the envelope calculation suggests you could fill up a class C,
hand out 1 address to each of 250 people, and just barely make it; if
you were to go off and intensively cultivate a class B net it looks 
even more promising.  Note that is *exactly* what demon.co.uk is doing,
dunno what their costs structures look like but it has to be a cheaper deal
than getting class C nets for every last little organization attached
to them...


  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)


-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 93 17:27:42 GMT
From:      chris@visionware.co.uk (Chris Davies)
To:        comp.protocols.tcp-ip
Subject:   Re: Guaranteed Unused IP Network?

Joel M-for-Vnews Snyder (jms@opus1.com) wrote:
> Aside from the test number (already mentioned here), whenever I do paper
> documentation I always use network number 555 and host number 1212.  It's
> not only illegal, most people can figure out that it's a guaranteed bogus
> number because of the telephone company association. 

What telephone company association?  You can't assume that people will
know that 555-1212 is something to do with telephones.  People living
in America might possibly make the link, but there are a lot of us
elsewhere.

Just a small point,
Chris
--
            VISIONWARE LTD, 57 Cardigan Lane, LEEDS LS4 2LE, England
  Tel +44 532 788858 x238.  Fax +44 532 304676.  Email chris@visionware.co.uk
---------- "VisionWare:   The home of DOS/SQL/UNIX/X/VMS integration" ---------

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 93 17:33:35 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP Error Message Generation

In article <C41KqA.J8w@ms.uky.edu> man@ms.uky.edu (Manish Gupta) writes:
>In ICMP, all error messages include the IP header of the offending 
>datagram + 64 bits of data. 
>
>My question is: when a node copies the IP header, does the standard
>require that whatever options (if any) were present be also copied?
>or is that upto the implentations?
>
>Any light on the above would be very much appreciated.
>
>Manish Gupta

RFC-792 just states:

	The internet header plus first 64 bits of datagram.

From the Router Requirements draft:

         Every ICMP error message includes the Internet header and at
         least the first 8 data octets of the datagram that triggered
         the error.  More than 8 octets MAY be sent, but the resulting
         ICMP datagram SHOULD have a length of less than or equal to 576
         octets.  The returned IP header (and user data) MUST be
         identical to that which was received, except that (except where
         required by Section [4.3.3.5]) the router is not required to
         undo any modifications to the IP header that are normally
	 performed in forwarding that were performed before the error
	 was detected (e.g. decrementing the TTL, updating options).

Art

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 93 18:02:35 GMT
From:      dsc9hmr@bumed10.med.navy.mil (H. Mike Rice)
To:        comp.protocols.tcp-ip
Subject:   WIN/3B tcplisten and bootp

Hi folks,

We have a 3B2 port of CMU's bootpd.  However, we are experiencing
problems with WIN's tcplisten handling both tftpd and bootpd.

I can launch the tfpt daemon with little problem, however, it will
not work under the control of tcplisten.  BOOTP on the otherhand 
needs an inetd lookalike to handle the socket.  Thus, it will not
run standalone.  I have already tried 'hard coding' the socket/port
into the getsockname, but that didn't work either.

It seems, tcplisten is deaf to the tftp and bootp sockets.  Yes, I
have made the entries into the /etc/services file.

Any thoughts, any help would be appreciated !!

Thanks

-- rice
--
|                    H. Mike Rice    |    elf_______________________
| |  dsc9hmr@bumed10.med.navy.mil    |         Empowerment through
|_|_____    BUMED: (202) 653-0413    |             Education !
  |_________________________________________________________________

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 93 18:55:39 GMT
From:      ercm20@festival.ed.ac.uk (Sam Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

spp@zabriskie.berkeley.edu (Steve Pope) writes:
> ercm20@festival.ed.ac.uk (Sam Wilson) writes:
> >Dean.Roth@mixcom.mixcom.com (Dean.Roth) writes:
 
> >> One problem is that the smallest number of addresses one can get
> >> is 256 (O.K., actually 254) - a class C number. Most small 
> >> organizations only need 1 address, not 254.
> >
> > Err.. a little difficult to know exactly what you'd do with a network 
> > of one machine... :-)  Think again.  I can imagine some things 
> > that you might mean, but I think you'll have to express yourself 
> > better!
> 
> Lots of Class C subnets have exactly one address in use.  For example,
> my site at kbr.com has exactly one internet host, which is
> mailhost for the rest of our site's network.  The remaining subnet
> addresses are unassigned, although we could make use of them
> in the future.

Is this just a firewall or what? What addresses do you use internally?
Or don't you use IP?

> Dean Roth's point is correct.  An interesting exercise would
> be to scan the nic database and determine just what fraction
> of class C subnets have only one or two addresses assigned
> to hosts.

Two addresses I can understand, but one I have difficulty with.  Apart
from this post two people wrote to say that they have or had
single-address networks (or non-networks!).  There's obviously something
I'm missing about the way 'small' IP networks are handled (my background
is in campus-size LANs - no dialups).  I assumed that if you have a
connection to an IP provider you would have a P2P link to that provider. 
That link has an address at each end and those addresses are both in the
provider's address space or both in your own.  If they are both in the
provider's space then, if you have a single machine at your end of the
link, why bother putting another address (your own) on it? If they're
both in your own address space then you have a two-host network.  What
am I getting wrong?

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

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1993 19:05:32 GMT
From:      radle@corp.hp.com (Andy Radle)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In article <732250478snx@crynwr.com>, nelson@crynwr.com (Russell Nelson) writes:


|> Maybe the NSF should charge a penny per IP address per year, plus $25
|> minimum.  I'd be more than happy to pay my $27.50 for my class-C
|> network if HP had to pay $167,000 per year for its class-A IP
|> addresses.  I wonder how many it's actually using (that is, those on
|> open subnets...)?
|> 
In HP's case, we've issued more than 100,000 ip addresses.  I think that's a
legitimate use of a class A address.

|> Boy, I bet *that* would free up a lot of class-A networks!  :)
I don't think so.  I'm just thankful that my predecessors had the foresight to
get a Class A in anticipation of the growth our network has undergone in the
last 7 years.

-Andy

*Disclaimer*  This, of course, isn't an official statement of 
the Hewlett-Packard Company.
|> 
|> -russ <nelson@crynwr.com> What canst *thou* say?
|> Crynwr Software           Crynwr Software sells packet driver support.
|> 11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
|> Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.
 
-- 
----------------------------------------------------------------------------
     //		 Andrew Radle			Hewlett-Packard Company
    //		 Data Networks Group  		Corporate Network Services
   //==\  /===\  Inet: radle@corp.hp.com        3000 Hanover St. M/S 20CX
  //  // //  //	 Desk: Andy Radle/HP0000/UM	Palo Alto, CA 94304
 //  // //==//					1-424-3695	
       //
      //
      

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1993 19:56:17 GMT
From:      curtis@cs.berkeley.edu (Curtis Yarvin)
To:        comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: IP over ATM

In article <fitz.732341400@fnord> fitz@wang.com (Tom Fitzgerald) writes:
>
>There are too many wierdo TCP/IP implementations, for discontinued-but-
>still-supported systems, in the hands of too many customers, for TCP/IP's
>installed base to ever even consider switching to another level 3/4
>protocol.

So do protocol negotiation, like modems.

c

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Mar 1993 20:38:40 GMT
From:      cam@mbunix.mitre.org (McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!

The phone numbers for the NIC are (800)365-3642 and (703)802-4535.

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Mar 1993 20:48:20 GMT
From:      hoffman@cmf.nrl.navy.mil (Eric Hoffman)
To:        comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: IP over ATM


I'm perfectly willing to admit that there is a huge installed base
of applications written to use TCP/IP. For the most part, this
implies that they are using calls such as 'socket',  'bind',
'listen' and 'accept', and use IP endpoint addresses with 
TCP ports to do application multiplexing. 

It is entirely possible that these applications could be supported
transparently over ATM, even if the implementor replaced TCP/IP
as it stands with something containing ATM specific transport. 
The motivation for a new transport could be found in features 
such as selective cell retransmission, adaptive forward error
correction, large transmit window sizes, and dynamic ATM QOS
negotiation. There is also a natrual analogy between TCP connections
and ATM connections, and quite a bit of flexibility is lost 
by travelling over a conectionless protocol. ATM pays a large
price by offloading per-cell headers into network wide connection
state. I don't see any reason to do one's best to ignore this  
simply to support buisness as usual. 

Since current ATM networks require smart bridges to interface
with existing IP networks already, and such a bridge would have
to perform reassembly in any case, there is no extra overhead
in translating between a new transport layer and IP as it stands
today. Of course, whatever features in this new transport that
were tailored for use by ATM networks would no longer function
in the same way if translated into generic IP. 

I'm not suggesting that such a protocol would be a clear win, 
but I find the suggestion that ATM is inherently bad because of 
the existing encapsulation schemes narrow minded and repugnant. 

This is not an official position, but a personal opinion.
In reality, there are* no official DoD opinions concerning ATM. 

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Mar 1993 21:11:18 GMT
From:      messwein@nimbus.worldbank.org (Mark D. Esswein)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP on Unisys A-Series

Does anyone know of any third party TCP/IP software to support REXEC on the
Unisys A-Series machines?  We currently are running the Unisys
implementation of TCP and it only supports FTP and Telnet.
  
We are trying to move away from NJE as a means for transferring files to
and from our VAX and are looking to TCP as the solution.  We can do the
VAX<-->VM,VAX<-->MVS,VAX<-->VAX transfers and job control with TCP but
VAX<-->Unisys is still a problem.  

Ideally we  would like to use NFS, but a combination of FTP and REXEC would
suffice.

Any help on this would be appreciated...

Thanks!

Mark Esswein
messwein@nimbus.worldbank.org

-------------
The opinions expressed are entirely my own and not to be confused with
those of my employer.

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Mar 1993 21:17:27 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: IP over ATM

In article <HOFFMAN.93Mar17154820@tesuji.cmf.nrl.navy.mil> hoffman@cmf.nrl.navy.mil (Eric Hoffman) writes:

>It is entirely possible that these applications could be supported
>transparently over ATM, even if the implementor replaced TCP/IP
>as it stands with something containing ATM specific transport. 

  One obvious problem with the above is that the ATM addressing
schemes are completely different from IP addresses and sockets and TLI
both take in the destination IP address as part of the connection.  In
the case of private network ATM, the ATM Forum has selected an
addressing scheme similar to GOSIP.  In the case of PSTN's ATM
networks, the address looks a lot like a phone number.  Without
modifying the applications to use ATM addressing and new name to ATM
address resolution mechanisms, the application won't work right
directly over ATM.  One can't really just slip ATM underneath in a
completely transparent way -- it isn't technically feasible.

  Now one probably could rewrite the networking parts of the
application code and have the same application run over ATM.  This
would require time and money on the part of each application
developer.  Moreover, ATM is not at all likely to be as widespread as
CLNP or IP simply because the rate of installation of new Ethernets
(and other non-ATM technology) is growing despite newer technologies
arriving.  The Ethernets of the world are not going away and CLNP & IP
already work fine over Ethernet.  People would have to work at ATM
over Ethernet if they wanted to make ATM as ubiquitous as IP.

>Since current ATM networks require smart bridges to interface
>with existing IP networks already, and such a bridge would have
>to perform reassembly in any case, there is no extra overhead
>in translating between a new transport layer and IP as it stands
>today. Of course, whatever features in this new transport that
>were tailored for use by ATM networks would no longer function
>in the same way if translated into generic IP. 

Not true.  

  The semantics of TCP are different from the semantics of ATM, so a
protocol bridge would have both the extra overhead of protocol
conversion (which is much harder than encapsulation) and also be very
difficult to build.  Past experience with protocol bridges has been
uniformly negative.

>I'm not suggesting that such a protocol would be a clear win, 
>but I find the suggestion that ATM is inherently bad because of 
>the existing encapsulation schemes narrow minded and repugnant. 

  I think that ATM clearly has value and I haven't seen _anyone_
suggest that "ATM is inherently bad".  A lot of people have remarked
that ATM was designed to solve a particular problem and is probably a
good solution FOR THAT PROBLEM but not all networking problems.  

  A large part of the value of ATM is its ability to support existing
large internetworks which use IP or CLNP as their universal network
layer protocols.  We need to ensure that it is easy (and tolerably
efficient) to move connectionless datagrams through ATM subnetworks
via encapsulation over something such as ATM AAL5.  We also need to
ensure that the gateways between ATM and non-ATM subnets have some
rational way of establishing and using ATM circuits between other
nodes.

Ran
atkinson@itd.nrl.navy.mil



-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 93 22:09:01 GMT
From:      ajb2213@egbsun6.NoSubdomain.NoDomain (Anthony J. Bogner)
To:        comp.protocols.tcp-ip
Subject:   TCP connection states

I'm new to this news group and am turning to it for some help.  After
reading thru several 100 messages, a few people have raised questions
concerning the TCP connection states returned by the netstat command:
(ie CLOSED, LISTEN, FIN_WAIT_1, CLOSE_WAIT, ...)  I am looking for
the C-system calls that my program can make to determine these states.

I'm not looking to exec a netstat and grep thru it, I'm looking for the
C-function calls that might reveal this information.  The overall problem
relates to determining if the other end of a TCP connection has gone away. 
That is, if the other end is in a "CLOSE_WAIT" state.

I don't want to do a "write" because if the other end is there, it will falsely
interpret the data and crash.  I don't want to do a "read" either because the
other end does not normally send data.

Surely the data must be avialable from some combination of system calls if the
netstat command can figure it out.  

Your help is certainly appreciated!


Tony Bogner
tbogner@draper.com

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Mar 1993 22:56:24 GMT
From:      mike@gordian.com (Michael A. Thomas)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In article <1o57r8$f8@agate.berkeley.edu>, spp@zabriskie.berkeley.edu (Steve Pope) writes:
> Lots of Class C subnets have exactly one address in use.  For example,
> my site at kbr.com has exactly one internet host, which is
> mailhost for the rest of our site's network.  The remaining subnet
> addresses are unassigned, although we could make use of them
> in the future.
> 
> Dean Roth's point is correct.  An interesting exercise would
> be to scan the nic database and determine just what fraction
> of class C subnets have only one or two addresses assigned
> to hosts.

  I wouldn't count on things staying like that. Consider the
not too distant day when *everything* is directly on the net,
managable from some super-duper SNMP client. Your printers,
your modems, your repeaters, your air conditioner, and your 
toaster ;-)
  254 address is going to be painfully small when every little
widget gets its own net address.
-- 

		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)

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 93 23:26:22 GMT
From:      antony@ee.uts.edu.au (Antony Richards)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

kudzu@netcom.com (Michael Sierchio) writes:

>In article <antony.732347405@ee.uts.EDU.AU> 
>    antony@ee.uts.edu.au (Antony Richards) writes:
 
>>All the arguments given are still valid as long as they are scaled to
>>750Kbytes (for a 100 Mbps connection) and 7.5 Gbytes (for a 1 Gbps connection).
 
>7.5 Mbytes?

Sorry about the typo, yes it is 7.5 Mbytes (not 7.5 Gbytes, but just wait for
those tetra(?) bit per second networks in 10 years time :-).


Antony.

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Mar 1993 00:11:44 GMT
From:      hoffman@cmf.nrl.navy.mil (Eric Hoffman)
To:        comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: IP over ATM


thank you for your reasoned response. 

>   One obvious problem with the above is that the ATM addressing
> schemes are completely different from IP addresses and sockets and TLI
> both take in the destination IP address as part of the connection. 

Of course I am aware that ATM call setup uses it's own endpoint address. 
The problem of its resolution from an IP address would be no different
than that of an ATM under IP driver. 

>  One can't really just slip ATM underneath in a completely
> transparent way -- it isn't technically feasible.  

Is there any other reason than the above-mentioned addressing that you
say this?

>   Now one probably could rewrite the networking parts of the
> application code and have the same application run over ATM.  This
> would require time and money on the part of each application
> developer.

I agree completely. There is also no movement towards the definition 
of an ATM application interface.

>  The semantics of TCP are different from the semantics of ATM, so a
>protocol bridge would have both the extra overhead of protocol
>conversion (which is much harder than encapsulation) and also be very
>difficult to build.  Past experience with protocol bridges has been
>uniformly negative.

What I suggested was not 'ATM in the place of TCP', but that there 
could exist a TCP-like protocol designed to sit directly on top
of ATM. While I admit that this is something of an understatment,
bridging between two stream-oriented transport protocols is not an insoluble
problem, and wouldn't present a barrier to network utilization. 
It would provide an application interface exactly the same as the
exising one (with the exception of certain sockio flags), and
also bridge transparently onto the existing network of IP routers.

> We need to ensure that it is easy (and tolerably
> efficient) to move connectionless datagrams through ATM subnetworks
> via encapsulation over something such as ATM AAL5. 

In the history of this group, you and others have raised valid
concerns about the efficacy of sending IP over lossy ATM links
using AAL5, especially with regard to global congestion. I believe 
that without substantially altering the protocol stack, and the
implementation details of the transport layer, one would not be able
to do much better than the proposals that exist today. 
 
There are quite a number of attractive things about a connectionless
network layer. By using ATM, we are already paying the price in 
added endpoint and switch complexity in the form of signalling and
state, why shouldn't we take advantage of it? Why should we bury
the potential QOS, traffic isolation, and multiplexing capabilities of
ATM beneath a single, uniform connectionless interface? 

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Mar 1993 00:33:30 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.benchmarks,comp.protocols.tcp-ip,comp.sys.hp
Subject:   Netperf, a network performance benchmark

Well, the netperf benchmark is now available from four (that I know
of/wrote down) Internet archive sites:

	iworks.ecn.uiowa.edu
	ftp.csc.liv.ac.uk
	ee.utah.edu
	sonygate.sony.com

In case you are curious, netperf is a TCP and UDP performance
benchmark, presently running over BSD sockets. It includes throughput
and request/response tests. A convenience feature is the ability to
run netperf's server process as a child of inetd, or as a standalone
daemon, so you do not have to remember to run the receiver each time.

I recently pushed revision 1.7 towards those sites, it will likely
appear as it goes through those site's normal routines.

The major changes in Revision 1.7 involve fixes to get it to work for
real on AIX and Solaris. It also "mostly" works on DEC OSF (shame on
me for assuming that pointers were 32 bits ;-)

rick jones

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Mar 1993 01:53:10 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: IP over ATM

In article <HOFFMAN.93Mar17191144@tesuji.cmf.nrl.navy.mil> hoffman@cmf.nrl.navy.mil (Eric Hoffman) writes:

[regarding portability of existing applications by emulating IP with ATM
 underneath the sockets interface]

>Of course I am aware that ATM call setup uses it's own endpoint address. 
>The problem of its resolution from an IP address would be no different
>than that of an ATM under IP driver. 

Of course for the application to remain unchanged, you will need to
have a unique IP address for each ATM end point -- which rather
defeats the point of moving to an ATM-only solution and is not at all
trivial to build -- among other problems.

>What I suggested was not 'ATM in the place of TCP', but that there 
>could exist a TCP-like protocol designed to sit directly on top
>of ATM. While I admit that this is something of an understatment,
>bridging between two stream-oriented transport protocols is not an 
>insoluble problem, and wouldn't present a barrier to network utilization.

Actually, folks who have tried to build such bridging between stream
oriented transport protocols (e.g. TP4 and TCP) have reached different
conclusions than you.  If you think you can build one, I'd suggest you
start with the TP4--TCP bridge as it would really help solve a lot of
OSI-Internet interoperability problems.  Such a bridge would probably
sell well commercially.

SSCOP is the CCITT protocol that provides service reliability above
the ATM AAL layer.

Why are you so intent on getting rid of IP/CLNP and running TCP-like
protocols directly over ATM ??  There is not significant complexity in
IP/CLNP, after all either provides unreliable connectionless datagram
service, and both do an outstanding job of glueing various subnetwork
technologies into a single seamless internetwork, thereby providing
greater connectivity and interoperability.
 
>There are quite a number of attractive things about a connectionless
>network layer. 

I agree with this.  Unfortunately, ATM does not provide connectionless
network service.  It only provides connection-oriented circuit service
-- rather like a much much faster version of X.25 circuit service.  By
contrast, both IP and CLNP _do_ provide connectionless datagram
service.

> By using ATM, we are already paying the price in added endpoint and
> switch complexity in the form of signalling and state, why shouldn't
> we take advantage of it? 

We _are_ trying to take advantage of it.  I'd suggest you look at the
ongoing IETF work on resource allocation and reservation algorithms
and flow mechanisms in ordinary off the shelf IPv4.  This work should
fully be able to take advantage of whatever help the available subnet
technology can provide and will also be able to help over subnetworks
that don't have much support for this (via router-based mechanisms, for
example).

> Why should we bury the potential QOS, traffic isolation, and
> multiplexing capabilities of ATM beneath a single, uniform
> connectionless interface?

  Because then I can use those capabilities over _all_ subnetwork
technologies that will support them (e.g. Frame Relay, FDDI-II,
certain kinds of RF links) rather than only over ATM.  I vastly
prefer more general flexible solutions and I can't run ATM fiber
to all of my sites.  I can run IP everywhere, including over ATM.

Ran
atkinson@itd.nrl.navy.mil



-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Mar 1993 02:46:44 GMT
From:      eam@netcom.com (Eam Lo)
To:        comp.unix.sysv386,comp.unix.internals,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   ISC V3.01 system(network) hang with no activities on the system


Software: Interactive UNIX System V/386 Release 3.2.2.1
          TCP/IP V1.2 with UPDATE SSU.4a
          NFS V2.1 with UPDATE SSU.4b
          STREAMS facilities Version 2.2

Sympton : 
  When it happened(It happened intermittent), the kernel was alive
  (By setting a diagnostic terminal connected to the system with 
  u386mon, a kernel monitor software utility. When hung up happened
  the utility displayed the kernel was still active.), but the network 
  was down, which means I could not ping it, NFS mount time out, telnet, 
  ftp all failed. 

  To follow up this problem, I put a script in the cron job
  to create some report of the system activities before it
  hung. There was nothing perticular interested me but the 
  "netstat -m" report. Here is partial report of the "netstat -m" 
  before system hung up. Somehow at some point, the dblocks 
  fail number raise sharply, and it increase in a speed of 
  4500 for every 10 minutes till the network totally hung(die).

		 alloc	 inuse	   total     max    fail
streams:	   256	    99	     923     102       0
queues: 	  2048	   548	    5406     566       0
mblocks: 	  2170	   568	16725347     632       0
dblocks: 	  1736	   568	14161660     632  218936
dblock class:
    0 (   4)	   256	     2	   42905       6       0
    1 (  16)	   256	    49	   26162      69       0
    2 (  64)	   256	   223	 8266563     230  218936
    3 ( 128)	   512	   286	 3310483     344       0
    4 ( 256)	   128	     0	 1798171      17       0
    5 ( 512)	   128	     8	  544497      20       0
    6 (1024)	    64	     0	  158976      12       0
    7 (2048)	    80	     0	   13621      14       0
    8 (4096)	    56	     0	     282       3       0

The last "netstat -m " before it hung:

dblocks: 	  1736	   807	24255181     813  4651552
dblock class:
    0 (   4)	   256	     3	   50422       6       0
    1 (  16)	   256	    49	   29413      69       0
    2 (  64)	   256	   230	10398470     231  4163671
    3 ( 128)	   512	   460	 9045030     460  487881
    4 ( 256)	   128	    32	 3443772      38       0
    5 ( 512)	   128	    32	  996438      34       0
    6 (1024)	    64	     0	  274679      12       0
    7 (2048)	    80	     1	   16533      14       0
    8 (4096)	    56	     0	     424       3       0

  I did some tune up of the kernel parameters related to network
  (For example, NBLK64,NBLK128...) to a much larger
  number. It did not solve the problem (but improved so system
  would not hung every other day).

My question:
  I understand the hung up is because the kernel resources
  is not enough as showed in "netstat -m".  But what I do not
  understand why this happpened even when there were no
  system or network activities? What could trigger the failure? 
  And this hung up seems related to the network traffic. 
  I say this because this system only needs to talk to one other 
  system on the net.  If I used a simple local network to the 
  other system instead of connected to the company's backbone, 
  the system never hung up. I do not understand this. I thought the 
  network board would only pick up the packet on the backbone
  that has it's network physical address. In other words, 
  there should be no differences between putting the system on the 
  backbone or on the local net.  Correct me if I am wrong. 
  Thanks!

  HELP! This problem is killing me, because the system will just
  sit there and die. Any information is welcome.



-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Mar 1993 04:24:30 GMT
From:      johnsonr@ucsu.Colorado.EDU (Richard Johnson)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP doesn't do Fast Retransmit??

j-norstad@nwu.edu (John Norstad) writes:
>I'll probably get yelled at for this posting.
 
>However, I have to give MacTCP and the Apple developers credit for
>providing the foundation for what I consider to be nothing less than a
>revolution in computing in academia. MacTCP made possible the development

Hear Hear!

I have been riding a wave of delighted amazement at programs such as the
MacTCP version of NCSA telnet (using it now), Fetch, Nuntius, and yes,
even MUDDweller :).  As a direct result of MacTCP, my and other Mac labs
here at CU Boulder are full of full internet citizens.  The accessibility
boggles the mind.

Sure, I notice occasional long pauses of about 5 seconds in large ftp
transfers.  But it works, and lets me do things I could only dream about
a few years ago.

Bravo to Apple for enabling it.


Richard
 
-- 
Loudyellnet: Richard Johnson | Sneakernet: ECOT6-29 or ECNT1-6, CU Boulder
Phonenet: +1 303.492.0590    | Internet: johnsonr@Colorado.EDU
PGP 2.0 public key available on request
Speaker to avalanche dragons.   Do you really think they listen?

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 1993 04:41:34 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP keepalive

In article <1993Mar17.065524.25728@cmutual.com.au> IJohnston@cmutual.com.au (Ian Johnston) writes:
>Can anybody see why I should not adjust my kernel from the default
>TCP keepalive idle time of two hours to something like five minutes?

It sometimes takes longer than five minutes to fix network problems.

Some routing protocols can take this long to stabilize on new routes when a
router dies.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Mar 1993 04:51:03 GMT
From:      wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
To:        rec.radio.amateur.packet,comp.protocols.tcp-ip
Subject:   BSD Unix code for IPIP (rfc 1241)?

Does anybody have code for IP-IP encapsulation for a BSD 4.3 system?
Where can I get it from? I'm running a NOS system with this stuff in
use, but I'm planning to upgrade it to 386bsd in the near future.

Many thanks for all your help.

	Warren  wkt@csadfa.cs.adfa.oz.au

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 93 08:01:51 GMT
From:      antony@ee.uts.edu.au (Antony Richards)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.parallel
Subject:   Giga Bit Networks, what are the limiting factors?

Hi,

The current trends in computer technology is that processing power & network
bandwidth have exponential improvement, and the cost of memory is plummeting.
For argument's sake, lets assume that these quantities reach infinite power
for no cost.


What factors will limit the manipulation of data in such a distributed
environment?


There are two factors that I have thought of so far.  Firstly, the memory
access time.  This is evident by looking at the RISC processor architecture.
Once data is in a cache, the manipulation of data is very quick.  But, this
approach is inefficient for calculations that involve touching a lot of data
only once (such as doing character conversions).  The other factor that I have
identified is the bus bandwidth.

I would appreciate other peoples views on this topic.

thanks,
Antony.



-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Mar 1993 16:30:37
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet Driver API

In article <C43J6G.G7t@atlantis.ssd.harris.com> noll@atlantis.ssd.harris.com (Kevin Noll) writes:

    I am trying to find the API for the Packet drivers (clarkson, FTP
    Software,etc)

v1.09 of the Packet Driver specification is available for anonymous FTP from
vax.ftp.com.

    Also... does anyone know if there exists a peer to peer file xfer utility
    that runs w/ the packet drivers?? Sort of like laplink via the network?

If you're going to use the network (I'll assume Ethernet), you need to have
some sort of a protocol to move the data.  Packet Drivers send and receive
packets at the MAC layer.  You could use one of the free or commercial DOS
TCP/IP protocol stacks and the FTP utility for this, or write your own...

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


-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Mar 1993 11:59:58 GMT
From:      rens@lorax.shearson.com (Rens Troost)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In article <1o7m1k$oir@nigel.msen.com> emv@msen.com (Edward Vielmetti) writes:

   Lars Poulsen (lars@spectrum.CMC.COM) wrote:
   : (1) to the Internet Society and IANA for the addresses ($25 +
   :     $.01/address seems about right)
   : (2) to the Routing Authority for advertizing the route ($1000/year per
   :     route)
   : (3) to the Local Access Carrier for
   : 	- pipe width ($100/month for 56K)
   : 	- route tax ($100/year per route)
   : (4) to the local telephone company for the physical wire

   This actually makes quite a bit of sense.  Community or metro networks
   now start to look like a real good idea, because if you get a bunch
   of people to cooperate and share a class B or a few class C nets, hide
   dozens or perhpas hundreds of organizations behind one $1000/yr route,
   and otherwise conserve address space by increasing the intra-network
   administration costs, the money costs go down.

Fundamentally, I oppose charging for allocations. Address space should
be free. Connectivity, routes, etc are a different matter. I like the
idea of collective network purchases.

The (obvious) problems with the above suggestion:

(1) this would turn the IAB into the ISO :)

(2) there is (fortunately) no 'routing authority'

(3,4) we already pay, and through the nose

For what it's worth, these ar _my_ predictions:

In the short term (ie, life of IP) I forsee entrepreneurs grabbing up
address space and then selling the rights to the highest bidder. This
will probably happen just like cattle ranching evolved in the west,
with class-C homesteaders selling out or conglomerating.

In the long term, IP goes away/mutates (hopefully into a
variable-length address network protocol).

Routing _will_ become 'expensive' as more and more class C networks
come online, and tables get bigger. The eventual migration protocol
chosen should support heirarchical routing.

The government will start regulating data networks, and the proce of
connectivity will go up to feed a horde of useless bureaucrats who
only serve to slow down the process.

and this last one is a borrowed prediction (does anyone know the
attribution?): as firewalls proliferate, SMTP will become the
transport protocol on which applications are built :)

-Rens


--
  __   ___  ,    __  
 /__) /__  /| / (    |  J. Laurens Troost    Lehman Brothers Technical Services
/  \ (___ / |/ __)   |  *Opinions expressed herein are mine. Mine, I tell you!*
-------------------------------------------------------------------------------
INET: rens@shearson.com        VOICE: (212) 464-3705        FAX: (212) 464-2040

  If trees could scream, would we be so cavalier about cutting them down?  We
     might, if they screamed all the time, for no good reason. -Jack Handey

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Mar 1993 17:41:30
From:      rodin@vax.ftp.com  (Jonathan Rodin)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet Driver API

In article <C43J6G.G7t@atlantis.ssd.harris.com> noll@atlantis.ssd.harris.com (Kevin Noll) writes:
> I am trying to find the API for the Packet drivers (clarkson, FTP software,etc)

You can find the Packet Driver Specification version 1.09 on:

	vax.ftp.com:pub/packet-d.ascii

Available for anonymous ftp.

--
Jon Rodin                  FTP Software, Inc.            voice: (508) 659-6261
rodin@ftp.com              2 High Street                 fax:   (508) 794-4488
                           North Andover, MA  01845


-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 1993 13:27:55 GMT
From:      zrfp0406@awssn3.rus.uni-stuttgart.de (Joerg Hertzer)
To:        comp.protocols.tcp-ip
Subject:   Re: Default route on subnet with two routers?

In article <1993Mar12.190523.494@indyvax.iupui.edu> harvey@indyvax.iupui.edu writes:
>I tried setting the default route to router A and a route for our class
>B net (134.68.0.0, the Sun treats 134.68 as 134.0.0.68) to router B, which
>is accepted but never used.
write:
route add net 134.68 .....
          ^^^                     !!!!!!

Joerg

Dr.-Ing. Joerg Hertzer                    Phone:  ++49-711-685-5734
Computer Center University Stuttgart      Fax:    ++49-711-682357
Allmandring 30                            E-Mail: Hertzer@rus.uni-stuttgart.de
W-7000 Stuttgart 80
Germany

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 93 14:12:12 GMT
From:      devdjn@nodomain (Dennis Newport)
To:        comp.protocols.tcp-ip
Subject:   Various UDP and TCP questions

We are in the process of creating some applications software using TCP/UDP/IP
and I can't find the answer to the following questions anywhere. Can someone
help me.

When we do a UDP broadcast, the datagrams also appear on the relevant port
on the machine doing the broadcasting. They seem to hang around for a short
time then disappear. Does anyone know how long they hang around and what factors
affect this "time-out" ?  I assume the time-to-live (TTL) specified in udp.h may
have something to do with this but I can't seem the relationship with the value
defaulted on our Sun (SunOS 4.1.2) and the time that the datagrams exist during
our tests.

When I was doing some testing a few years ago on a Sun machine I recall that the
maximum data block I could send over a TCP socket was either 32767 or 65535 bytes.
Does anyone know what the current maximum value is and where the defining factor 
can be found ?

When taking down a TCP connection in a client server application, the client goes
into the TIME-WAIT TCP state for a certain time. This time-out should be 2*MSL where
tcp_timer.h defines this to be 30*PR_SLOWHZ. This should be 60 seconds but we don't
observe this. The time-outs can be the order of minutes in reality. Can anyone offer
me an answer to this.

One final question I would ask is a simple one about using NeWS. This is the first
time I have entered an article and I noticed in the header that the "from" and
"reply-to" address specify "nodomain". Can I automatically set these values in a
start-up file and, if so, how do I do it ?

All answers will be greatly appreciated.


---
Dennis Newport,                  email: devdjn@space.alcbel.be
Alcatel Bell Telephone,
Berkenrodelei 33,                phone: (+32) 3/829.5488
2660 Hoboken,
Belgium.


-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Mar 1993 14:51:58 GMT
From:      hoffman@cmf.nrl.navy.mil (Eric Hoffman)
To:        comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: IP over ATM


what useful role does the IP header have when travelling through a 
single ATM network?

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Mar 1993 15:21:23 GMT
From:      cam@mbunix.mitre.org (McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   Interim Local Managment Interface (ILMI) MIB

Does anyone know the status of this MIB, or where I can get a copy?

Thanks.

Colleen McLaughlin
C2 Communications
The MITRE Corp.


-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Mar 1993 17:08:51 GMT
From:      brooks@usiva.com (Lyle D. Brooks)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject:   TCP/IP vs. IPX/SPX


I'm looking for some documentation that compares the relative merits
of the TCP/IP protocol and IPX/SPX protocol.  In particular, I'm 
interested performance (i.e. throughput ) but also how they diff
in approach.  I'd be interested if anyone could recommend any good
books that treat both protocols.

I know more about TCP/IP and have plenty of text of it, but I'm just
learning about IPX/SPX.

Other questions I have regarding IPX/SPX are:

1) Is this a proprietary protocol of Novell, or it published.  Does
anyone else sell implementations of it?


2) What is the programmer's interface to IPX/SPX?   What is the 
equivalent to Berkeley sockets, TLI, or RPC in the IPX/SPX protocol
suite?  Does Netware support ONC RPC?


3) I have alot of TCP/IP and IPX/SPX traffic on my Ethernet.  Is 
there any tools (PD, preferred) that monitor both?


Thanks for any help.



-- 
Lyle D. Brooks                     UUCP     : uunet!usinet!brooks
Universal Systems Incorporated     Internet : brooks@usiva.com
4350 Fair Lakes Court
Fairfax, VA 22033
(703) 222-7253

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 1993 17:48:58 GMT
From:      glenn@sundeck.usask.ca (Glenn Hollinger)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!

From article <1993Mar16.230018.15764@cmutual.com.au>, by IJohnston@cmutual.com.au (Ian Johnston):
> 
> 
> Here is a different question for everyone.  Who do I contact if
> I wan't to give back a Class B IP number?  I know of a few
> sites that have applied for and recieved IP numbers and then
> have not used them.

Don't give them back!  Save them a few more months, then auction them
off to the highest bidders.  They could be worth a fortune...!

Glenn Hollinger,                    glenn@sundeck.usask.ca
University of Saskatchewan.

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Mar 1993 17:56:40 GMT
From:      noll@atlantis.ssd.harris.com (Kevin Noll)
To:        comp.protocols.tcp-ip
Subject:   Packet Driver API

I am trying to find the API for the Packet drivers (clarkson, FTP software,etc)

Can anyone help??

Also... does anyone know if there exists a peer to peer file xfer utility
that runs w/ the packet drivers?? Sort of like laplink via the network?

--kan--
--
Kevin A. Noll                     internet - noll@atlantis.ssd.harris.com
Information Systems Technician    Voice    - (407) 384 1835
Harris Corporation                Fax      - (407) 380 9877
Orlando, FL                      

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 93 19:00:29 GMT
From:      valentin+@pitt.edu (Shawn V. Hernan)
To:        comp.protocols.tcp-ip,comp.sys.mac.system,comp.sys.mac.comm
Subject:   Re: MacTCP 1.1.1 woes

In article <6084@blue.cis.pitt.edu> Shawn V. Hernan, valentin+@pitt.edu
writes:
>
>
>Once again, violating its own Human Interface Guidelines, Apple makes us 
>run to an external piece of documentation to find an error code. Error 
>-23004 is "Error in getting address from server or the address is
 already 
>in use by another machine."  This is available in the MacTCP developer's 
>Guide, or in the MacTCPCommontypes.h file. 

Netiquette dictates that you should not follow-up your own article. Oh 
well. 

I've recently slammed Apple in several news groups, and I did it again 
here. This particular problem is not Apple's fault. It is a failure of 
TurboGopher to conform to the Human Interface Guidlines. Don't get me 
wrong...I think TurboGopher is a damn fine application. And I don't think 
I've ever seen an app of any significance that conforms to all the HIG's. 
Even the Finder blows it. 

I owe Apple an apology on this one. Sorry, Apple. 

Shawn

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Mar 1993 20:09:07 GMT
From:      eam@netcom.com (Eam Lo)
To:        comp.unix.sysv386,comp.protocols.tcp-ip,comp.protocols.nfs,comp.unix.internals
Subject:   ISC network hung with no activities going on! HELP

Subject : ISC V3.01 System network hung when no one was talking to the system.

Hareware: Intel PC 486/25MHZ
Software: Interactive UNIX System V/386 Release 3.2.2.1
          TCP/IP V1.2 with UPDATE SSU.4a
          NFS V2.1 with UPDATE SSU.4b
          STREAMS facilities Version 2.2

Sympton : 
  When it happened(It happened intermittent), the kernel was alive
  (By setting a diagnostic terminal connected to the system with 
  u386mon, a kernel monitor software utility. When hung up happened
  the utility displayed the kernel was still active.), but the network 
  was down, which means I could not ping it, NFS mount time out, telnet, 
  ftp all failed. 

  To follow up this problem, I put a script in the cron job
  to create some report of the system activities before it
  hung. There was nothing perticular interested me but the 
  "netstat -m" report. Here is partial report of the "netstat -m" 
  before system hung up. Somehow at some point, the dblocks 
  fail number raise sharply, and it increase in a speed of 
  4500 for every 10 minutes till the network totally hung(die).

		 alloc	 inuse	   total     max    fail
streams:	   256	    99	     923     102       0
queues: 	  2048	   548	    5406     566       0
mblocks: 	  2170	   568	16725347     632       0
dblocks: 	  1736	   568	14161660     632  218936
dblock class:
    0 (   4)	   256	     2	   42905       6       0
    1 (  16)	   256	    49	   26162      69       0
    2 (  64)	   256	   223	 8266563     230  218936
    3 ( 128)	   512	   286	 3310483     344       0
    4 ( 256)	   128	     0	 1798171      17       0
    5 ( 512)	   128	     8	  544497      20       0
    6 (1024)	    64	     0	  158976      12       0
    7 (2048)	    80	     0	   13621      14       0
    8 (4096)	    56	     0	     282       3       0

The last "netstat -m " before it hung:

dblocks: 	  1736	   807	24255181     813  4651552
dblock class:
    0 (   4)	   256	     3	   50422       6       0
    1 (  16)	   256	    49	   29413      69       0
    2 (  64)	   256	   230	10398470     231  4163671
    3 ( 128)	   512	   460	 9045030     460  487881
    4 ( 256)	   128	    32	 3443772      38       0
    5 ( 512)	   128	    32	  996438      34       0
    6 (1024)	    64	     0	  274679      12       0
    7 (2048)	    80	     1	   16533      14       0
    8 (4096)	    56	     0	     424       3       0

  I did some tune up of the kernel parameters related to network
  (For example, NBLK64,NBLK128...) to a much larger
  number. It did not solve the problem (but improved so system
  would not hung every other day).

My question:
  I understand the hung up is because the kernel resources
  is not enough as showed in "netstat -m".  But what I do not
  understand why this happpened even when there were no
  system or network activities? What could trigger the failure? 
  And this hung up seems related to the network traffic. 
  I say this because this system only needs to talk to one other 
  system on the net.  If I used a simple local network to the 
  other system instead of connected to the company's backbone, 
  the system never hung up. I do not understand this. I thought the 
  network board would only pick up the packet on the backbone
  that has it's network physical address. In other words, 
  there should be no differences between putting the system on the 
  backbone or on the local net.  Correct me if I am wrong. 
  Thanks!

  HELP! This problem is killing me, because the system will just
  sit there and die. Any information is welcome.



-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 93 20:13:02 GMT
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP keepalive

>In article <1993Mar17.065524.25728@cmutual.com.au> IJohnston@cmutual.com.au (Ian Johnston) writes:
>>Can anybody see why I should not adjust my kernel from the default
>>TCP keepalive idle time of two hours to something like five minutes?
>
 In article <1o8uhuINN8ui@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>It sometimes takes longer than five minutes to fix network problems.
>
>Some routing protocols can take this long to stabilize on new routes when a
>router dies.

   True, but two hours?  

   It wouldn't take that much to test how long a worst-case router
   death would involve in a specific network.  If there are lots of
   LAN/WAN connections in the data paths, it might take a while, but
   for LAN/LAN, ten minutes seems to work most of the time.  

   Without knowing the specific network and why you'd want to
   shorten it, its hard to say whether or not it is a good idea, but
   we do have an extremely large customer who alters all of their
   systems to 10 minutes.  The number of realistic problems this
   causes compared to the number it cures is acceptable to them and
   their users.

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Mar 1993 22:22:57 GMT
From:      dcm@csn.org (David C. Menges)
To:        comp.protocols.tcp-ip
Subject:   Open Expo '93

OPENEXPO '93
March 24-25, 1993
Currigan Exhibition Hall
Denver, CO

Keynote--Dwayne Walker, manager of NT project, Microsoft

Live Open Systems Demonstration--30 open systems vendors interoperating. 
Vendors to include DEC, HP, IBM, NCR, Sun,Unisys, etc.

Technical Track--both days, 5 parallel tracks:  Open systems development
life cycle; business cases; open documents; APIs; new database technology;
SGML; managing open systems; standards; object management; implementation
perspectives; transaction management.

                    Member        Non-Member
Exhibit Only        Free          $25
Technical Program   $75           $125
Membership & Tech-                $200
  nical Program

For more inforamtion, call Jeff Richardson, 620-4777, Ext. 305
Jeff Richardson
Director, Information Technology Programs
Colorado Advanced Technology Institute
(303) 620-4777, Ext. 305
jefr@csn.org

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Mar 1993 22:55:58 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: IP over ATM

In article <HOFFMAN.93Mar18095158@tesuji.cmf.nrl.navy.mil> hoffman@cmf.nrl.navy.mil (Eric Hoffman) writes:
>what useful role does the IP header have when travelling through a 
>single ATM network?

When travelling *through* an ATM network?  It plays no useful role at
all, of course.  But then again, the application's data doesn't play
any useful purpose when travelling through any network, but i don't
think you'd recommend that we leave that out of packets on ATM
networks, would you?  Of course not: that would be pointless.  Just as
the application's data has no useful purpose until it arrives at the
application, the IP header has no useful purpose until it arrives at
an IP node such a router.  Once the packet arrives at an IP router,
though, the IP header becomes critically important.

						don provan
						donp@novell.com

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Mar 1993 22:57:30 GMT
From:      rps@matuc2.mat.uc.pt (Rui Pedro Mendes Salgueiro)
To:        comp.protocols.tcp-ip,comp.windows.x.apps
Subject:   Re: graphical monitoring IP traffic (summary)

I asked:
: I am looking for a X application that monitors the network and display
: that information using X (something similar to traffic on a SUN).

I received answers from 4 persons:
	rvw@math.purdue.edu (Rich Verl Williams)
	Tim Lentz x255 <lentz@pvi.com>
	pjw@sma.usna.navy.MIL (Peter J. Welcher -- math FACULTY)
	Ranen Goren <ranen@CS.HUJI.AC.IL>

	Thank you all.

One suggested a comercial product (NetMetrix from metrix
(contact: jack@metrix.com )). It seems to have a lot of features.

The other two suggestions were:
    XEnetload : this is a X client to rpc.etherd.
	It just display the load in the net.
	I have tried it, and it works ok.
	It is not exactly what I want because it needs
	rpc.etherd, and the multi-home machine I have
	does not have rpc.etherd.

"please check archie for source under xenetload.tar.Z"
	warning: there existes a program called xnetload
	that has a different function (uses rwhod).


    xnetmon: I have downloaded it, but I haven't tried it. 
	It is on cs.huji.ac.il:/pub/X11/contrib/xnetmon2.0.tar.[zZ],
	among other places.
	The documentation says that:

		This is a collection of programs that sampler packets off the
		ethernet and give information about what is there.
		Note:  The sampling programs only run under Ultrix or Sun.

  pjw@sma.usna.navy.MIL (Peter J. Welcher -- math FACULTY)
has sent me a program that he wrote:
	" I wrote a rpc.etherd client that logs data. I then can pipe data
	to xvgr to get plots. I don't try to do it constantly, just plunk up
	a plot several times a day."

None of this is exactly what I want, because I want to monitor a PC
running BSD/386 that is our only UN*X machine 
connected to the departamental net AND the University net.
Maybe I'll try to port xnetmon.

Unfortunately it seems that there isn't a PD rpc.etherd.
Oh well, I have some Suns here (not running Solaris 2.x :-).
        
--
   Rui Salgueiro     |   Dpt. de Matematica    |"It's so easy to laugh
rps@matuc2.mat.uc.pt | Universidade de Coimbra | It's so easy to hate
   rps@inescc.pt     |    Portugal - Europe    | It takes strenght to be gentle
" 'He deserves death'.                         |     and kind" - Morrissey
  'Deserves it! I daresay he does. Many that live deserve death. And some that
die deserve life. Can you give it to them ? Then do not be too eager to deal
out death in judgement. For even the very wise cannot see all ends.' "
	Tolkien - The Lord of the Rings

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Mar 93 22:59:13 GMT
From:      murray@src.dec.com (Hal Murray)
To:        comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: IP over ATM

In article <HOFFMAN.93Mar18095158@tesuji.cmf.nrl.navy.mil>, hoffman@cmf.nrl.navy.mil (Eric Hoffman) writes:
|> 
|> what useful role does the IP header have when travelling through a 
|> single ATM network?


The IP header has source and destination host addresses and some other fields.

If you know that the packet is to or from the host on the end of the ATM VC, then
the dest or source host address can be derived from the VC by table lookup.

If both ends of the VC are routers, then you need both IP addresses.

The other fields are just as useful as they are on an ethernet.

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Mar 1993 03:11:23 GMT
From:      root@c3p0.novell.de (Novell Gmbh - Peter Dennis Bartok - Admin)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject:   Re: TCP/IP vs. IPX/SPX

brooks@usiva.com (Lyle D. Brooks) writes:


>I'm looking for some documentation that compares the relative merits
>of the TCP/IP protocol and IPX/SPX protocol.  In particular, I'm 
>interested performance (i.e. throughput ) but also how they diff
>in approach.  I'd be interested if anyone could recommend any good
>books that treat both protocols.
 
>I know more about TCP/IP and have plenty of text of it, but I'm just
>learning about IPX/SPX.
 
>Other questions I have regarding IPX/SPX are:
 
>1) Is this a proprietary protocol of Novell, or it published.  Does
>anyone else sell implementations of it?


>2) What is the programmer's interface to IPX/SPX?   What is the 
>equivalent to Berkeley sockets, TLI, or RPC in the IPX/SPX protocol
>suite?  Does Netware support ONC RPC?


>3) I have alot of TCP/IP and IPX/SPX traffic on my Ethernet.  Is 
>there any tools (PD, preferred) that monitor both?
The horro of every unix-administrator : Use Lanalyzer for Windows, avail.
from Novell, grabs the packets on your net and decodes them. 
Based on Novell's ODI - Needs no special ethernet-card. 


>Thanks for any help.



>-- 
>Lyle D. Brooks                     UUCP     : uunet!usinet!brooks
>Universal Systems Incorporated     Internet : brooks@usiva.com
>4350 Fair Lakes Court
>Fairfax, VA 22033
>(703) 222-7253
-- 
Peter Dennis Bartok                     Voice : +49 211 5277 744
Univel Support                          FAX   : +49 211 5277 772
Novell European Support Center			CIS   : 75170,124
D-4000 Duesseldorf 11                   INet  : Peter_Dennis_Bartok@novell.de
 - I' speaking (writing ?!?) for myself - not for my company -

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Mar 1993 03:39:37 GMT
From:      kath@nwu.edu (William Kath)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

antony@ee.uts.edu.au (Antony Richards) writes:

> Sorry about the typo, yes it is 7.5 Mbytes (not 7.5 Gbytes, but just wait for
> those tetra(?) bit per second networks in 10 years time :-).
 
> Antony.

You mean terabit (i.e. 1000 Gb/s).  No joke, however.  Mohammed Islam at
the University of Michigan currently has in his lab some all-optical
switches which work at several hundred Gb/s; he's also working on token
ring-like protocols to go along with them.  

I won't try to comment on how much RAM one will need for checksums or
whatever -- I spend most of my time working on what networking types around
here call `the physical layer' :-).

Bill Kath ---------------------------------- kath@nwu.edu
             Engineering Sciences and Applied Mathematics
McCormick School of Engineering,  Northwestern University


-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 93 04:00:37 GMT
From:      ddl@burrhus.harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP connection states

In article <1993Mar17.220901.3988@draper.com>, ajb2213@egbsun6.NoSubdomain.NoDomain (Anthony J. Bogner) writes:

| The overall problem
| relates to determining if the other end of a TCP connection has gone away. 
| That is, if the other end is in a "CLOSE_WAIT" state.
| 
| I don't want to do a "write" because if the other end is there, it will falsely
| interpret the data and crash.  I don't want to do a "read" either because the
| other end does not normally send data.
| 
| Surely the data must be avialable from some combination of system calls if the
| netstat command can figure it out.  

This question comes up from time to time and the answer is apparently obscure
enough to be worth repeating.  The problem usually reduces to this:  you
would like to discover whether a read() would return EOF (0) without actually
performing the read.  Either you don't want to block or you are not prepared
for the data yet.

The problem can be solved on most BSDish systems with a combination of
select() and the FIONREAD ioctl.  Recall that select() will indicate
a socket is ready if there is data available or if the connection is
``closed'' (in the sense that the peer has sent a FIN).  Therefore, perform
a polling select() for read on the socket of interest.  If the socket is
ready, use ioctl(,FIONREAD,) to find the number of available bytes.  If
there no bytes to be read, then the connection is ``closed.''

				Dan Lanciani
				ddl@harvard.*

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Mar 1993 05:18:35 GMT
From:      ben@rex.uokhsc.edu (Benjamin Z. Goldsteen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

avalon@coombs.anu.edu.au (Darren Reed) writes:

>Point to point transfers through TCP aren't it though.  When you have an
>NFS server and a network of clients attached, the ethernet goes pretty
>damn quickly, especially when you have a class running of 20 or so people
>all loading up and running an animation demo on the latest version of
>AutoCad.  Ok, NFS is bad, but a faster network would make it a bit more
>bareable :)

      Am I the only one who finds it some what inefficient that
each machine must request and transfer the same data?  Not that
I would know how to fix this!  It would sure save some traffic
if we could, though...(we have a 24 Mac lab...OK everybody startup
up MacX...)
-- 
Benjamin Z. Goldsteen

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Mar 1993 05:38:02 GMT
From:      arindam banerji <abanerji@bach.helios.nd.edu>
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.parallel
Subject:   Re: Giga Bit Networks, what are the limiting factors?



Possibly much more important than bus-bandwidth (which is quite large for some
of the faster LAN interconnects that are available) is communication latency ie:
the time it takes to put the bits on the wire (a rough definition) or conversely to pick them up from the wire. One of the things that you might want to do on such networks is to access remote memory just like you access local memory. 
For doing such a thing it behooves us to compare the performance of remote memory accesses on a gigabit network to bus-based SMMP. Most measurements show that bus-based SMMP remote-memory access is about 1-2 orders of magnitude faster than 
the same operation on giga-bit links (if you compare the number of processor 
cycles such an operation takes up). To solve this problem, you have to do extensive caching as a prt of your subsystem design and this is a failry well accepted strategy for hiding communication latencies. 

Yet another factor that is incredibly important is the complier support available. The kind of support that the compiler can provide to optimise remote accesses makes a big difference in such interconnections. 

Arindam Banerji 
(axb@cse.nd.edu)


-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Mar 1993 05:58:49 GMT
From:      chip@chinacat.unicom.com (Chip Rosenthal)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In article <732250478snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
>Maybe the NSF should charge a penny per IP address per year, plus $25
>minimum.

Be careful what you ask for, Russ.  You might get it. :-)

The NSF issued a press release on January 5 that announced the award
of a new contract to several companies for an `INTERNIC'.  It stated
that the INTERNIC `may charge users beyond the U.S. research and
education community for any services provided.'  I can dig out a
copy of the press release of y'all are interested.
-- 
Chip Rosenthal  512-482-8260 | Now I only use my gun whenever kindness
Unicom Systems Development   | fails.  - Robert Earl Keen, Jr.
<chip@chinacat.Unicom.COM>   |

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Mar 1993 09:19:35 GMT
From:      sinisa@hprd26a.cern.ch (Sinisa Novosel)
To:        comp.unix.sysv386,comp.protocols.tcp-ip,comp.protocols.nfs,comp.unix.internals
Subject:   Re: ISC network hung with no activities going on! HELP

>> ISC network hung .....

Is gated running ?
We have same problem and removing 'gated' fix it.
Using old 'gated' (from release 2.2, I think) thing never
happened again.

Sinisa

----- Sinisa Novosel, IRB-F, CRO, ---  sinisa@tp1.irb.hr -----


-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 1993 09:40:50 GMT
From:      Martin W Freiss <freiss.pad@sni.de>
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In <732250478snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:

>Of course we're running out of IP addresses -- they're free!  Should
>it surprise anyone that if you give away something valuable for
>nothing, people will suck them up?
 [...]
>Maybe the NSF should charge a penny per IP address per year, plus $25
>minimum.  I'd be more than happy to pay my $27.50 for my class-C

I can see it now. "Let's save $ 100,000 a year and make up our own
addresses". Management will love this idea, and IP service providers
will start to have nightmares.

>Boy, I bet *that* would free up a lot of class-A networks!  :)

Yes, but I bet not in the way you think :-)

-Martin (who has already had to deal with this).

--
 Martin Freiss               | R&D computer center | freiss.pad@sni.de 
 Siemens Nixdorf Infosystems | Dept. STO SI 325    | NIC MF194
"I refuse to have a battle of wits with an unarmed person." - Mr. Boffo


-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Mar 93 11:37:16 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Of course we're running out of IP addresses!

In article <1o7sps$7rh@hpscit.sc.hp.com> radle@corp.hp.com writes:

   In article <732250478snx@crynwr.com>, nelson@crynwr.com (Russell Nelson)    writes:

   |> Maybe the NSF should charge a penny per IP address per year, plus $25
   |> minimum.  I'd be more than happy to pay my $27.50 for my class-C
   |> network if HP had to pay $167,000 per year for its class-A IP
   |> addresses.  I wonder how many it's actually using (that is, those on
   |> open subnets...)?

   In HP's case, we've issued more than 100,000 ip addresses.  I think that's a
   legitimate use of a class A address.

Again, how many of these are you *using*?   If the subnet is not
connected to the Internet, why use up an Internet address?

From where I sit, there's a difference between an IP address and an
Internet address.

-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Mar 1993 13:35:12 GMT
From:      robelr@ucs.indiana.edu (Allen Robel)
To:        comp.protocols.tcp-ip
Subject:   TCP "debugger"

Is there a product out there that could take a trace
(ideally a Sniffer trace) of a TCP connection between 
two hosts, parse it, and provide a graphic display of
the hosts TCP level conversation.  I'm imagining a 
graphic representation of two byte streams with the
respective sliding windows on each end.  This app should
allow you to "step" through the conversion in the same
way that most code debuggers allow you to step through
code.

If you've tried to analyse a TCP connection using the
Sniffer, you'll probably agree that, while doable, it
certainly isn't fun.  I don't think that it would be
all that hard to write and, if there's nothing out there
that does this, may try tackling it myself.

Thanks in advance.

Allen Robel                      robelr@mythos.ucs.indiana.edu
University Computing Services    ROBELR@IUJADE.BITNET
Network Services Development     voice: (812)855-7171
Indiana University               FAX:   (812)855-8299

"For every difficult and complicated question there is an answer that 
     is simple, easily understood, and wrong" -- H.L. Menchen

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Mar 1993 14:41:33 GMT
From:      satam@saathi.ncst.ernet.in (Kirtikumar G. Satam)
To:        comp.protocols.tcp-ip
Subject:   IP multicasting


Hello,

I need some info on IP multicasting.  Could someone point me to the
correct place?  Please reply by email, as my feed is not reliable at
the moment.

Thanks,
Satam
-----------
satam@saathi.ncst.ernet.in
National Centre for Software Technology,
Bombay, India
-----------

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Mar 1993 15:25:41 GMT
From:      larry@palan.uucp (Larry Strickland)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   HELP with DEC DE201 card

HELP!  The college I work for has purchased 75 DEC DE201 cards (don't ask,
it wasn't my suggestion!)  We FINALLY got them working with Novell, but now
I need to find a way to get them to work with TCP/IP into a UNIX system.

Unfortunately, the people I've talked to said I need drivers for these cards
which nobody seems to have or know where they are!

If ANYONE has ANY idea where I can get TCP/IP drivers for these cards or
anything even vaguely similar (I want to Telnet into a  UNIX box across an
Ethernet network running twisted pair), please let me know.

Either Email, Snail mail, or posting would be great.

Thanks for your help.

P.S. Of course, we need this yesterday, but...

-larry

larry@palan.palantir.com

-or, if that doesn't work-

larry@palan.UUCP


-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Mar 1993 16:12:23 GMT
From:      dcarr@gandalf.ca (Dave Carr)
To:        comp.protocols.tcp-ip
Subject:   Re: ** What is better TCP/IP or X.25 ?**

In <JIM.93Mar16115242@hunter.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid) writes:

>In article <1993Mar15.134621.36@mvax.uakom.cs> weis@mvax.uakom.cs writes:
 
>   We have problem. We have some LAN (ethernet) in different towns.
>   Which protocol will be used ? X.25 or TCP/IP ?
>   Which is better and why ?
 
>If the Czech or Slovak PTT only provides X.25, all is not lost. It is
>possible to run IP over X.25. There's even an RFC which describes how
>to do this. However, this not ideal because of X.25 packet charges and
>wasted bandwidth. You have TCP headers inside IP headers inside X.25
>headers inside HDLC headers....

No, you can buy a gateway that converts between TCP/IP and X.25.  Then,
the overhead is a lot LOWER with X.25.  We just happen to make such a box. 
-- 
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. 

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Mar 1993 16:49:34 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

> >Maybe the NSF should charge a penny per IP address per year, plus $25
> >minimum.  I'd be more than happy to pay my $27.50 for my class-C
> >network if HP had to pay $167,000 per year for its class-A IP
> >addresses.

lars@spectrum.CMC.COM (Lars Poulsen) writes:

> Actually, to recover the real costs, I see the following cost elements:
> (1) to the Internet Society and IANA for the addresses ($25 +
>     $.01/address seems about right)

The $25 will give too many people incentive to use illegal network numbers
"temporarily".  $5 + $.01/address would be better; for As and Bs, the $5
disappears in the noise, and Cs are cheap.

ClassA=$150,000, ClassB=$600, ClassC=$5 sounds right to me.

> (2) to the Routing Authority for advertizing the route ($1000/year per
>     route)

Ack!  With the current size of the Internet, the authority would be pulling
in $60M/year!  I think you want to use this to recover costs - RAM in the
core routers, hand-maintenance of the lists at the boundary between the
commercial and noncommercial nets, and the extra bandwidth required by
routing updates.  This probably justifies $100/route/year, but that's it.

> (3) to the Local Access Carrier for
> 	- pipe width ($100/month for 56K)
> 	- route tax ($100/year per route)

May as well make these competitive....  let the carriers fight over them.

> With a cost structure like this, it would be interesting to see how many
> customers would volunteer to renumber their hosts when changing access
> carriers (so they could ride for free on the carrier's core route).

It would be nice to have a domain registration fee and $5/domain/year
maintenance fee to cover disk and RAM in the root nameservers, too.

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

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 93 19:08:15 GMT
From:      chris@visionware.co.uk (Chris Davies)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!

Ian Johnston (IJohnston@cmutual.com.au) wrote:


> Here is a different question for everyone.  Who do I contact if
> I want to give back a Class B IP number?

How about contacting the person or authority who gave it to you in the
first place?

Chris
--
            VISIONWARE LTD, 57 Cardigan Lane, LEEDS LS4 2LE, England
  Tel +44 532 788858 x238.  Fax +44 532 304676.  Email chris@visionware.co.uk
---------- "VisionWare:   The home of DOS/SQL/UNIX/X/VMS integration" ---------

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Mar 1993 19:12:12 GMT
From:      robelr@ucs.indiana.edu (Allen Robel)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In article <732541036snx@crynwr.com> nelson@crynwr.com (Russell Nelson)  
writes:
> Again, how many of these are you *using*?   If the subnet is not
> connected to the Internet, why use up an Internet address?
> 
> From where I sit, there's a difference between an IP address and an
> Internet address.
> 

Agreed, but many organizations, as per advice that you'll
get in several sources (including Comer), apply for Internet
addresses in anticipation of connecting their internets to
the Internet in the future.  Its a REAL hassle to change your
addresses for a lot of hosts after the fact.

The reference to Comer is "Internetworking with TCP/IP" pp.68
and appears below.

"However, experience has shown that it is unwise to create
a private internet using the same network addresses as
the connected Internet because is prevents future interoperability
and may cause problems when trying to exchange software with
other sites.  Thus, everyone using TCP/IP is strongly encouraged
to take the time to obtain official Internet addresses from the 
NIC."

Allen Robel                      robelr@mythos.ucs.indiana.edu
University Computing Services    ROBELR@IUJADE.BITNET
Network Research & Planning      voice: (812)855-7171
Indiana University               FAX:   (812)855-8299

"For every difficult and complicated question there is an answer that 
     is simple, easily understood, and wrong" -- H.L. Menchen

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Mar 1993 20:24:22 GMT
From:      bjork@telebit.com (Steven Bjork)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP WANTED DESPERATELY on IP-options.

In article <1993Mar19.091215.24299@prl.philips.nl> ruud@prl.philips.nl (Ruud Hendricksen) writes:

>Basically I need to know, how I can set the "SERVICE TYPE" field in an IP-
>packet so that I can implement a Data-Link layer with priorities, and who I
>can use "Loose Source Routing" by setting the IP-OPTIONS field.

According to the cslip 2.6 code comments, you can't in sunos.

That's why the cslip 2.6 uses what it calls a "disgusting hack"
to set TOS for telnet and rlogin ports.

../Steven

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Mar 1993 21:03:26 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP WANTED DESPERATELY on IP-options.

>>Basically I need to know, how I can set the "SERVICE TYPE" field in an IP-
>>packet so that I can implement a Data-Link layer with priorities,
>
>According to the cslip 2.6 code comments, you can't in sunos.
>
>That's why the cslip 2.6 uses what it calls a "disgusting hack"
>to set TOS for telnet and rlogin ports.

For SunOS 4.x that's correct.  But, many newer systems (such as SunOS 5
BSD/386, 4.3BSD Reno and above, AIX 3.2, and probably others) allow a
user process to set the TOS field, using setsockopt() and IP_TOS.
But I'd guess most routers ignore the field today?

	Rich Stevens  (rstevens@noao.edu)

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 1993 21:16:01 GMT
From:      scoggin@delmarva.com (John K Scoggin Jr)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!

In article 4897@visionware.co.uk, chris@visionware.co.uk (Chris Davies) writes:
> Ian Johnston (IJohnston@cmutual.com.au) wrote:
> 
> 
> > Here is a different question for everyone.  Who do I contact if
> > I want to give back a Class B IP number?
> 
> How about contacting the person or authority who gave it to you in the
> first place?
> 
> Chris
> --
>             VISIONWARE LTD, 57 Cardigan Lane, LEEDS LS4 2LE, England
>   Tel +44 532 788858 x238.  Fax +44 532 304676.  Email chris@visionware.co.uk
> ---------- "VisionWare:   The home of DOS/SQL/UNIX/X/VMS integration" ---------


At least in the USA, send a memo to hostmaster@nic.ddn.mil for starters...

	- John
---
+---------------------------------------------------------------------+    
|  John K. Scoggin, Jr.			Email: scoggin@delmarva.com   |
|  Supervisor, Network Operations       Phone: (302) 451-5200         |
|  Delmarva Power & Light Company       Fax:   (302) 451-5321         |
|  500 N. Wakefield Drive               NOC:   (800) 388-7076         |
|  Newark, DE 19714-6066		                              |
|  The opinions expressed are not those of Delmarva Power, simply the |
|  product of an over-active imagination...                           |
+---------------------------------------------------------------------+


-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Mar 1993 22:18:53 GMT
From:      byd117@measurex.com (Benjamin Y. Dai)
To:        comp.protocols.ppp,comp.protocols.misc,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Using the LAN across dial-up modem connections


This posting is split into two parts:  SLIP and PPP

1) For past the past week, I've been testing SLIP and have
successfully run various X applications using SLIP via. 
the modem connection.  Unfortunately, the X applications 
runs so SLOW that they're practically useless. 

Are there any things that I should be aware of 
that could have caused these kind of performance problems?   
Will using a higher speed modem  have a dramatic increase
of performance?  In fact, is it even realistic to get
X applications running efficiently over the modem?

The following is the general setup I'm using in this test:


  2 DECstations 5000/133 (one as master and one as slave)
  ULTRIX 4.2a

  Modem brand:		USRobotics
  Modem type setting: 	HAYES_V_9600
  Modem speed: 		9600
  Modem Compression is turned on (I've also tried it with it off)

  I'm currently using SLIP v1.1 from the CD-ROM Freeware software
  kit.  It relies on the ULTRIX unsupported software set UDXINET420,
  the TCP/IIP Networking Util Extension package.


2)  I've been reading in some of the postings that PPP is supposed to
be better than SLIP.  For running X applications, is this true?  
If so, how much performance increase should I expect?  I've already
downloaded all the articles from ftp.uu.net:vendor/MorningStar/papers
and have obtained the PPP FAQ file.  Unfortunately the info seems 
too general.  Does anybody have any first-hand (or second-hand) 
experience with X applications using PPP?  Does it work and is it
usable?  It if is, where can I get the most recent version and
documentation?    


Any help would be greatly appreciated.  Please email to the below
address.


Thanks.

=============================================================
Ben Dai				byd999@unagi.measurex.com
Measurex Corporation
Cupertino, CA

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Mar 1993 23:05:18 GMT
From:      bsrikant@ho17.eng.ua.edu (B. Srikanth)
To:        comp.protocols.tcp-ip
Subject:   THESIS TOPIC WANTED

Greetings,

	I am a graduate student at University of Alabama,doing my masters
in electrical engg.  I am planning to start my thesis in summer. I am
looking for topic in the area of computer networks. Any suggestions for
a possible thesis  topic, is greatly appreciated. Topics in the areas
of TCP/IP, RPC, NFS would interest me.

Thanks in advance
Srikanth. B. 

-- 
--------------
  Srikanth.B.

|----------------------|---------------------------|
|                      |                           |
|Srikanth.B.           |bsrikant@buster.eng.ua.edu |
|University of Alabama |                           |
|----------------------|---------------------------|

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 93 03:31:07 GMT
From:      sob@hsdndev.UUCP (Scott Bradner)
To:        comp.protocols.tcp-ip
Subject:   no - not me

Well, I guess it is about time for my annual "I don't work for Cisco"
posting. 

Some of you may have seen that Cisco is going to hold some sort of user
conference at Harvard University in May and might have jumped to the
conclusion that I might have something to do with it.  I do not.  I learned
about the conference the same way that most people at Harvard did, they got
a copy of the Cisco Packet advertising brochure/newsletter and saw the
notice. 

After some poking around I found that no one in any networking group at
Harvard knew that this was going to happen, except for the ones that had
seen the notice and assumed that the group that I work with (Network
Services) had set it up.  We had not.

It turns out that Cisco went to the Harvard Real Estate office and rented a
Harvard building. (One of the ways that Harvard makes pin money.)  Since
the conference has been announced and the building rented, Network Services
is working with Cisco (for a fee) to help provide Internet connectivity but
I have no plans attend myself or to offer tours through the test lab for
the other attendees.  (Actually I'll be out of town through most of it.)

I'm sorry to have to post this sort of "I never beat my wife" sort of
notice (It would have been easier if Cisco had chosen Yale.) but the
salesdroids from one router vendor or another do seem to want to use
something other than facts to explain their products relative position in
my annual tests. (If I were working for Cisco - or had a bias towards them
I could have arranged for some different results for the bridging and osi
tests in the last round :-) )

So if a vendor's rep approaches you with this sort of rumor, ask yourself
why he (or she) thinks that shooting at the messenger is a worthwhile
pastime.

Scott

PS - for you vendors out there - the next round will start in June and be
reported at the "fall" Interop (in August!)  Send me a note if you want
your bridge or router to be included in the abuse.

PPS - for those of you who have a PowerBits or Tekelec, I have finally
setup the mailing lists and will be using them to distribute the latest
versions of the test software as it is debugged.


-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      Sat, 20 Mar 1993 03:41:53 GMT
From:      a866700@hp9000.csc.cuhk.hk (Wong Siu To)
To:        comp.protocols.tcp-ip
Subject:   Info Wanted: Configurable/Enhanced ftp...

Hi there,

I apologize if this's a FAQ.

I would like to know if there's any ftp implementation (PD versions)
which has enhanced features that are not usually implemented in the ftp
which comes with OS from vendors, like HP-UX, AIX, SUN, DEC OSF/1, etc. 

Would anyone pls advise ?  Thanks in advance.

Regards,

-- 
______________________________________________________________________
S.T. Wong             	            [] BITNET: A866700@CUCSC.BITNET      
Computer Services Centre            [] Internet: st-wong@cuhk.hk 
The Chinese University of Hong Kong [] Tel. No: (852) 609 8825      

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 1993 06:01:18 GMT
From:      mcn@b62103.student.CWRU.Edu (Michael C Neuman)
To:        comp.protocols.tcp-ip
Subject:   Source routing in telnet


  I've been spending some time messing with telnet, and have yet to get
source routing to actually work correctly. According to the source,

 * We fill in the source route option as
 *      hop1,hop2,hop3...dest
 * and return a pointer to hop1, which will
 * be the address to connect() to.

But, in reality:

$ /usr/ucb/telnet @129.22.242.198@129.22.242.151
Trying 129.22.242.151...

  Huh? (The address shown after 'Trying' is the address it's attempting to
connect(2) to). Well, if I wanted to connect directly to 129.22.242.151,
I wouldn't be using source routing!!! And besides, even the documentation for
sourceroute() in commands.c shows that it should return the FIRST address,
instead of the last...

  In any case, I mussed with the code a bit to get the 'correct' behaviour:

./telnet @129.22.242.198@129.22.242.151
Trying 129.22.242.198...

  But both cases return with 'connection timed out' after about a minute...
(and both are directly accessible)

  Does this stuff actually work?

-Mike Neuman
mcn@b62103.student.cwru.edu
-- 
        Mike Neuman                mcn@b62103.student.cwru.edu
  "To make a machine that will be proud of us." - Thinking Machine's motto
==============================================================================
* Maintainer: NeXT netrek archive--b62103.student.cwru.edu:/pub/games/netrek *

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Sat, 20 Mar 1993 18:29:47 GMT
From:      jaimecs@matuc2.mat.uc.pt (Jaime Carvalho Silva)
To:        comp.protocols.tcp-ip
Subject:   MacTCP for SE/30

I wonder if someone could help me.
I am trying to install MacTCP in an SE/30
with an Ethernet Dayna Card 
and using NCSA 2.5 and I can work
only some seconds and then I get a system error
forcing restart with a lot of
different messages including "Bad F-line instruction"
I tried system 7.0.1 and 7.1

Where is the trouble?
What should I change?
Thank you in advance.

Jaime Carvalho e Silva
Dep. Matematica
Univ. Coimbra-Portugal


-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Sat, 20 Mar 1993 18:34:57 GMT
From:      tga@oar.net (Germann Associates)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In article <33117@castle.ed.ac.uk> ercm20@festival.ed.ac.uk (Sam Wilson) writes:
>
>Two addresses I can understand, but one I have difficulty with.  Apart
>from this post two people wrote to say that they have or had
>single-address networks (or non-networks!).  There's obviously something
>I'm missing about the way 'small' IP networks are handled (my background
>is in campus-size LANs - no dialups).  I assumed that if you have a
>connection to an IP provider you would have a P2P link to that provider. 
>That link has an address at each end and those addresses are both in the
>provider's address space or both in your own.  If they are both in the
>provider's space then, if you have a single machine at your end of the
>link, why bother putting another address (your own) on it? If they're
>both in your own address space then you have a two-host network.  What
>am I getting wrong?
>

Not necessarily in the same address space. My dialup link to the service
provider is in their address space and my end of the link is in my address
space.  One of my clients using the same provider has a Class C address
and uses (currently) 1 address.  They may use more later, but who knows?

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


-- 
============================================================================
Eric Germann                "You see things; and you say 'Why'  But I dream
The Germann Associates       things that never were; and I say 'Why not?'"
eric@tga.com                -- "Back to Methuselah"  G.B. Shaw 1921 

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 93 08:16:21 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?


	I apologize for taking so long in responding to this thread.
UCSD's news service has been in sad shape for the last week or so.

> And, on RISC cpus, the checksum comes for free.  What one does is put
> the checksum additions in between the loads and store instructions of data
> into memory, 
	I tried that.  I didn't spend enough time on it that I am
willing to post numbers, but the results that I got were bad enough
that we decided that "checksum avoidance" is a better solution than
checksum/copy ILP.
	This is a result of design constraints for maximizing
checksumming performance on RISCs.  The most important thing in a RISC
processor is to read in as large a chunk as possible.  Typically, that
will be the size of a register.  Now, the Internet checksum is not an
obvious 2's-complement addition, but rather a 16-bit 1's-complement
addition.  That means that overflow bits must be stored in a
meaningful way.  On MIPS processors, anyway, there is no really quick
way to do that.  Four instructions are required to process each word,
and that number of instructions is sufficiently large that the
addition is in the same ballpark of expense as a memory access.
	In other words, while ILP does speed things up, not doing
a checksum makes you even faster.
	A final point is that there is no such point between load and
store in certain scenarios - e.g., NFS on a machine with DMA'ing
network and disk interfaces.

> >Still, I think TCP/IP could suppress checksumming on reliable connections.
> >If the interface were marked "reliable" (e.g. by ifconfig)
> >then ungatewayed packets sent over the interface need not be checksummed.
> It isn't clear to me that the end system can dependably know that 
> traffic will only travel over "reliable" links if it isn't directly
> connected to the same local LAN.
"Checksum avoidance," despite its name, only suppresses checksums on
packets sent over single connections.   In other words, it suppresses
checksums iff two communicating machines are on the same LAN and that
LAN supports a CRC or checksum.  Thus, it is easy to be fairly
certain.

> Even if you think you are talking to a machine on the local net there is no
> guarantee that the link is reliable.  Somebody could have added a "smart"
> bridge while you weren't looking.
So long as the Ethernet CRC is preserved across the bridge, the scheme
is unaffected.  For that matter, even you do have a bridge which does
not preserve the CRC, one or two bridges seem unlikely to produce
serious reductions in reliability. The big reasons why checksum
avoidance doesn't disable checksums across routers have to do with
distance effects.  There are networks out there that don't support
checksums.  Furthermore, packets sent over the NSFnet (never mind
across the world!) are likely to travel through 15-20 gateways, and
overall reliability goes down exponentially with the number of
gateways passed through.

>         Wouldn't it be easier to move that stuff onto the ethernet
> controller if your application justified the expense?
	On the contrary, that is checksum avoidance's major strength.
Checksum avoidance is as close to free as anything ever is.  Changing
hardware is difficult, expensive, and only works on machines where
that hardware is installed.  Checksum avoidance works on the hundreds
of existing 802.X adapters that don't do the Internet checksum.

> You mean terabit (i.e. 1000 Gb/s).
Cool!  Can't wait!

							Jon

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21 Mar 1993 16:45:05 GMT
From:      ejbehr@rs6000.cmp.ilstu.edu (Eric Behr)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   LocalTalk <-> TokenRing

An old question came up again recently. Are there any ways of connecting a
LocalTalk network to Token Ring in a TCP/IP-aware way? That is, is there
any hardware or software gateway/router which would provide conversion
between MacIP (LocalTalk) and TCP/IP (Token Ring)?

If there is no direct solution, I'd also like to hear about more exotic
schemes being used in practice (e.g. connecting the LocalTalk to T/R with
an ordinary AppleTalk-only router, and forcing a Fastpath or some such on a
remote Ethernet to act as a DDP/IP gateway for that LocalTalk; does it
work?)

-- 
Eric Behr, Illinois State University, Mathematics Department
behr@math.ilstu.edu   or   behr@ilstu.bitnet  (please avoid!)

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 93 17:47:11 GMT
From:      helen@shum.cc.huji.ac.il (Helen Zommer)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   WANTED: BOOTP server (TSR) for MSDOS

Hello all,

Does somebody know where to find BOOTP server (TSR) for MSDOS
working on NDIS driver (if possible, with sources) ?

Thank you,
Helen.
helen@hope.cc.huji.ac.il


-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21 Mar 1993 18:28:03 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

In article <46720@sdcc12.ucsd.edu>, jkay@cs.ucsd.edu (Jon Kay) writes:
> ....
> 	A final point is that there is no such point between load and
> store in certain scenarios - e.g., NFS on a machine with DMA'ing
> network and disk interfaces.

As far as I know, all NFS implementations still involve a byte-copy
between mbufs or STREAMS buffers and the file system "buffer cache".
Thus, there is such a position between loads and stores in all systems
I've heard about, although I agree there should not be, that "page
flipping" is far smarter.


> > >Still, I think TCP/IP could suppress checksumming on reliable connections.
> > >If the interface were marked "reliable" (e.g. by ifconfig)
> > >then ungatewayed packets sent over the interface need not be checksummed.
> > It isn't clear to me that the end system can dependably know that 
> > traffic will only travel over "reliable" links if it isn't directly
> > connected to the same local LAN.
>
> "Checksum avoidance," despite its name, only suppresses checksums on
> packets sent over single connections.   In other words, it suppresses
> checksums iff two communicating machines are on the same LAN and that
> LAN supports a CRC or checksum.  Thus, it is easy to be fairly
> certain.

Once again, that statement is WRONG!

> > Even if you think you are talking to a machine on the local net there is no
> > guarantee that the link is reliable.  Somebody could have added a "smart"
> > bridge while you weren't looking.
 
> So long as the Ethernet CRC is preserved across the bridge, the scheme
> is unaffected.  For that matter, even you do have a bridge which does
> not preserve the CRC, one or two bridges seem unlikely to produce
> serious reductions in reliability.

"If wishes were horses, then beggars would ride"

How many bridges receive the entire ethernet packet using any of the
familiar MAC chips, letting the MAC check and discard the checksum, and
then transmit the data packet, letting the output MAC recompute the
checksum?  If the bridge recomputes the Ethernet checksum, then your
"checksum avoidance" is a disaster waiting to happen.

It is simply impossible for some bridges to preserve the MAC level
FCS.  Consider FDDI-Ethernet and Token Ring-Ethernet bridges.  It is
impossible for a pair of TCP/IP hosts to know that they are not on
different media, one on FDDI and one on Ethernet.  It is impossible for
such a pair of hosts to know to not "avoid" the TCP or UDP checksum.

It is impossible for a pair of TCP/IP hosts, both on Ethernets, to know
whether or not their Ethernet segments are separated by a bridged FDDI
backbone.  It is impossible for such a pair of hosts to know to not
"avoid" the TCP or UDP checksum.

In any of those 3 cases, memory errors in the bridges will data errors
that are detectable only by the TCP checksum.  Real life, unhappy
experience with such errors in routers are why people now insist on
running UDP with checksums turned on.  Those real life reports I have
heard involved hosts separated by only 1 or 2 routers, not long
chains.  Bridges are simply MAC-layer routers, and subject to the same
kinds of memory and bus errors as any other routers.  The new
cross-bar-hub-switching-bridges are no doubt pioneering new ways to add
errors that can only be detected by the TCP and UDP checksums.


>                                    The big reasons why checksum
> avoidance doesn't disable checksums across routers have to do with
> distance effects.  There are networks out there that don't support
> checksums.  Furthermore, packets sent over the NSFnet (never mind
> across the world!) are likely to travel through 15-20 gateways, and
> overall reliability goes down exponentially with the number of
> gateways passed through.

I would have guessed reliability would go down geometrically instead
of exponentially.  I.e. P(success)=P(success at G1)*P(success at G2)*...
I would also have guessed that the probability errors not undetected
by the TCP or UDP checksum would go down similarly.

But what has any of this to do with abondoning the ability to detect errors?


> >         Wouldn't it be easier to move that stuff onto the ethernet
> > controller if your application justified the expense?
> 	On the contrary, that is checksum avoidance's major strength.
> Checksum avoidance is as close to free as anything ever is.  Changing
> hardware is difficult, expensive, and only works on machines where
> that hardware is installed.  Checksum avoidance works on the hundreds
> of existing 802.X adapters that don't do the Internet checksum.

Hah!  Tell that to the hundreds of people who get upset about UDP
checksums being turned off for NFS by some vendors.

Again, it is impossible to accurately determine if the other end
of a TCP connection is separated from this host by a bridge that
destroys the (limited) end-to-end nature of the Ethernet or other
MAC layer checksum or FCS.

(The MAC FCS is not really "end-to-end", because it is generated and
checked after and before some sources of error.  Neither is my
preferred solution, handling the TCP checksum in the hardware.  Those
sources of error can be significant in some architectures.)


Vernon Schryver,  vjs@sgi.com

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 93 01:27:26 +0100
From:      fpgroeneveld@et.tudelft.nl
To:        comp.protocols.tcp-ip
Subject:   Is there a FAQ?

See above.


-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 93 03:23:09 GMT
From:      trt@duke.cs.duke.edu (Tom Truscott)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?


About TCP checksum being free on RISC cpus:
Please indicate the *implementation* for which this is true.

It is not true in the Ultrix, SunOS, and AIX systems that I have seen.
Their checksum code is "stand alone", not interleaved with memory copying.
Interleaving the two is quite complex.
And if, as was noted, memory copying were replaced by page mapping,
interleaving would not be possible.

Also note that in a "balanced" system a memory
copy runs at the full speed of the CPU,
so there are no "free" CPU cycles.
Perhaps there exist superscalar CPUs in which such cycles exist.
I don't think IBM makes any.  Does anyone?

Straightforward TCP checksumming is cheap on most RISC systems,
typically 2 bytes/cycle with 32-bit load+add/carry.
It gets better with 64-bit CPUs.
But it isn't free.

Tom Truscott

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Mar 1993 04:55:59 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

In article <732770588@romeo.cs.duke.edu>, trt@duke.cs.duke.edu (Tom Truscott) writes:
> ....
> Also note that in a "balanced" system a memory
> copy runs at the full speed of the CPU,
> so there are no "free" CPU cycles.

That is false.

On all modern systems that I know about, the CPU spends most of its
time waiting for cache misses to be completed during memory copies of
network data.  On any reasonable system, there are many "free" CPU
cycles that can be spent adding the bytes of the previous cache block
while the next one is being filled.

The primary cache miss penalty on modern systems can more than one
might imagine.  Think what a memory system running at microsecond or
even 100 nsec speed does to CPU running at 150 MHz.


> Perhaps there exist superscalar CPUs in which such cycles exist.
> I don't think IBM makes any.  Does anyone?

Yes.  And not just "superscalar".

Read about Van Jacobson's "witless" interface efforts for another opinion.


> Straightforward TCP checksumming is cheap on most RISC systems,
> typically 2 bytes/cycle with 32-bit load+add/carry.
> It gets better with 64-bit CPUs.
> But it isn't free.
> ...

Some RISC CPU's do not have arithmetic status bits, including carry
bits.  It's part of the RISC religion.



Vernon Schryver,  vjs@sgi.com

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Mar 1993 07:48:03 GMT
From:      ben@rex.uokhsc.edu (Benjamin Z. Goldsteen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

paul@atlas.abccomp.oz.au (Paul Brooks) writes:

>In article <C3vwMy.Gw3@news.iastate.edu> john@iastate.edu (John Hascall) writes:
>|craig@sics.se (Craig Partridge) writes:
>|
>|}Megabytes of memory are cheap.  I have no problem with the idea of a 6
>|}megabyte window on my SUN workstation -- it comes pretty much standard with
>|}20 meg.  And memory prices are going down.  Let's keep in mind that gigabits
>|}to our desktops are a few years away -- memory is not a problem.
 
>There are many many more MessyDOS PC's than workstations out there. try
>shoehorning all of TCP/IP and packet buffer memory into a 50Kb total module,
>and see what window you can offer each connection! The number of people with
>20-30Meg of RAM in their desktop machine of any kind is still rather small.

The good news is that these people won't need gigabit networks --
I can't even get near Ethernet speed out of most PC's.  The only non
backbone uses for gigabit speeds at this time are imaginging, file
service to/from supercomputers, metacomputers, etc.  If you 
trying to animate 1280x1024x24 to a frame-buffer, I would recommend
a 32-bit address space...

-- 
Benjamin Z. Goldsteen

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 93 17:27:31 EST
From:      eep300dorair@qut.edu.au
To:        comp.protocols.tcp-ip
Subject:   Info wanted on Novell format


Could anyone direct me where I can get some information on Novell's
IPX,SPX,etc.  

   I am in need of their protocol specifications like those of TCP/IP
with details on the number of bytes occupied by each field.

   Is there any RFC's on these protocol specifications.


   I urgently need them and any help would be much appreciated.
 
Thanks in advance.

kalyan
Queensland university of technology, 
Brisbane, Australia.

email:  eep300dorair@redgum.qut.edu.au



-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 93 13:43:17 GMT
From:      MLYNCH@cmsa.gmr.com
To:        comp.protocols.tcp-ip
Subject:   Terminal Servers for Modems


   I am looking for a terminal server recommendation for attaching dialin and
dialout modems.  I would like a terminal server that supports TCP/IP and LAT,
up to 38400 bps, and PPP.  Thank you!!


                                Mary Lynch
                                mlynch@cmsa.gmr.com

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1993 13:48:25 GMT
From:      mjo@iao.ford.com (Mike O'Connor)
To:        comp.protocols.tcp-ip
Subject:   Re: Info Wanted: Configurable/Enhanced ftp...

In article <1993Mar20.034153.9892@hp9000.csc.cuhk.hk>
a866700@hp9000.csc.cuhk.hk (Wong Siu To) writes:

:I would like to know if there's any ftp implementation (PD versions)
:which has enhanced features that are not usually implemented in the ftp
:which comes with OS from vendors, like HP-UX, AIX, SUN, DEC OSF/1, etc. 

I'm not sure if you're talking about the client end (ftp) or the
server end (ftpd) of the FTP protocol as commonly implemented on Unix
systems.  For an enhanced ftpd, try getting the wuarchive ftpd, which
I figure HAS to be available via anonymous FTP from wuarchive.wustl.edu.
For an enhanced ftp, try getting ncftp, which I figure is available 
in comp.sources or there about and is probably ultimately available
from wuarchive as well.

						...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

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 93 14:51:07 GMT
From:      my00@gte.com (Michael Yuen)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP driver

Can anyone recommend a good book or reference for writing a IP device
driver for UNIX? Thanks

-Mike

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Michael Yuen                   Tel - (617)466-2919
GTE Labs                          Internet - my00@gte.com
40 Sylvan Road                 FAX - (617)466-2130
Waltham, MA 02254

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 93 19:12:14 GMT
From:      agulbra@flipper.pvv.unit.no (Arnt Gulbrandsen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

paul@atlas.abccomp.oz.au (Paul Brooks) writes:
>There are many many more MessyDOS PC's than workstations out there. try
>shoehorning all of TCP/IP and packet buffer memory into a 50Kb total module,
>and see what window you can offer each connection! The number of people with
>20-30Meg of RAM in their desktop machine of any kind is still rather small.

What use is it to shuffle the entire 640k memory across the net in
0.005 seconds, give or take a decimal?  MS-DOS can't use a gigabit
net.

In article <C4A5o3.1qt@rex.uokhsc.edu> benjamin-goldsteen@uokhsc.edu writes:
>The good news is that these people won't need gigabit networks --
>I can't even get near Ethernet speed out of most PC's.

Well, I can't get near ethernet speed either, but the figure I've
heard about the latest Linux drivers is 968k/s on a WD8013 measured
using a hacked ttcp.  (Sorry, I don't know how it was hacked.)

--
Arnt Gulbrandsen
agulbra@pvv.unit.no

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 93 19:28:36 GMT
From:      Karl_Kleinpaste@cs.cmu.edu
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

trt@duke.cs.duke.edu writes:
   About TCP checksum being free on RISC cpus:
   Please indicate the *implementation* for which this is true.

Last Thu/Fri, I participated in a workshop on gigabit TCP in which a
bunch of folk babbled about their current efforts toward 1Gbps.  There
were several mentions of systems for which chksum-is-free-during-copy
is true.  What I specifically remember was Van Jacobson describing it
on the HP Snake, on a slide showing relative bcopy/cksum cost for
several progressively more recent systems including Sun3/60,
HP9000/370, Sparc-1, Sparc-2, and the Snake (9000/720); and Craig
Partridge observed that it was possible on a 386.  Craig noted,
however, that his implementation that did so depended not only on
being a 386, but being on a 386 with an 18-slot instruction cache, so
that the beastie ran the entire loop out of the cache; another 386
with only an 11(?)-slot cache was somewhat doggish.  (Correction, Craig?)

It can be done, though it's by no means necessarily intuitive or trivial.

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 93 19:37:44 GMT
From:      amoss@shuldig.cs.huji.ac.il (Amos Shapira)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

ben@rex.uokhsc.edu (Benjamin Z. Goldsteen) writes:

   (Darren Reed) writes:

   >Point to point transfers through TCP aren't it though.  When you have an
   >NFS server and a network of clients attached, the ethernet goes pretty
   >damn quickly, especially when you have a class running of 20 or so people
   >all loading up and running an animation demo on the latest version of
   >AutoCad.  Ok, NFS is bad, but a faster network would make it a bit more
   >bareable :)

	 Am I the only one who finds it some what inefficient that
   each machine must request and transfer the same data?  Not that
   I would know how to fix this!  It would sure save some traffic
   if we could, though...(we have a 24 Mac lab...OK everybody startup
   up MacX...)
   --
   Benjamin Z. Goldsteen

No,  you are not the only one.  I find it pretty wastefull to have all our
student's NCD's startup in the morning and each TFTP the same file after a
thoughfull security guy though he was doing us a fevor by truning off the main
power switch at night.

Could be really nice if the NCD's prom (or, mac) could talk ISIS/Transis to
exploit the Ethernet's Bus architecture.

What I mean is that solutions for this seem to be pretty available today (i.e.
this field left the theory stage long ago and now is waiting to be exploited),
you just have to do it.

Cheers,
--
--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

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1993 21:35:30 GMT
From:      radle@corp.hp.com (Andy Radle)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In article <732541036snx@crynwr.com>, nelson@crynwr.com (Russell Nelson) writes:
|> In article <1o7sps$7rh@hpscit.sc.hp.com> radle@corp.hp.com writes:
|> 
|>    In article <732250478snx@crynwr.com>, nelson@crynwr.com (Russell Nelson)    writes:
|> 
|>    |> Maybe the NSF should charge a penny per IP address per year, plus $25
|>    |> minimum.  I'd be more than happy to pay my $27.50 for my class-C
|>    |> network if HP had to pay $167,000 per year for its class-A IP
|>    |> addresses.  I wonder how many it's actually using (that is, those on
|>    |> open subnets...)?
|> 
|>    In HP's case, we've issued more than 100,000 ip addresses.  I think that's a
|>    legitimate use of a class A address.
|> 
|> Again, how many of these are you *using*?   If the subnet is not
|> connected to the Internet, why use up an Internet address?
|> 
|> From where I sit, there's a difference between an IP address and an
|> Internet address.
100,000+ are assigned to machines or devices that are up and connected to the
HP Internet and thus the Internet.  This does not mean that every machine/device
is accessible for all services from everywhere in the Internet.  No company 
should be that naive in today's world.  Remember that HP has been part of the
Internet for quite a long time and we followed the "rules" and guidelines that
were in place at the time.  This meant determining the number of hosts that
would eventually reside on the network and picking the appropriate class for
that number of hosts.  We needed a class A by this formula, we requested one,
we received one, and we therefore use a class A.  Could you honestly say that
you wouldn't have made the same decision 7 years ago with the Internetworking
knowledge available 7 years ago?  Hindsight is always 20/20!  ;-)

|> 
|> -russ <nelson@crynwr.com> What canst *thou* say?
|> Crynwr Software           Crynwr Software sells packet driver support.
|> 11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
|> Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.

/* The comments above are my personal opinions and are not official statements
of the Hewlett-Packard Company */

-Andy Radle
 Corporate Network Services
 Hewlett-Packard Company
 radle@corp.hp.com

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Mar 1993 00:23:59 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   getting checksums for free

 
Sorry to be so slow to jump in.  I've been trying to get my office back in
order after two weeks of on and off travel.

I'd like to back up my comment about checksums coming for free.

First, keep in mind that memory speeds are not keeping pace with processor
speeds.  CPU designers deal with this problem in various ways such as
super-scalar processors (2 instructions per cycle), and scoreboarding
(allowing instructions to occur between when a LOAD takes place and when
you actually examine the register that the data was loaded in).  But the
difference continues to grow.  For example, the new 200 MHz Alpha has
an external interface which is typically clocked at 66 MHz, so you expect,
on average to get 3 instructions per memory access.  I heard predictions
last week that the number may get to 10 instructions per access in the
not too distant future.
 
So there are some instruction cycles that can be used between the reading
and writing of registers.  If the processor has a carry bit, doing
the checksum requires 1 or 2 instructions (depends on whether the carry
bit is affected by intermediate instructions between the additions, if so,
you have to do two adds -- the add of the value to checksum, plus adding
the carry to the sum).  Keep in mind that the Internet checksum can be
computed in any word size that's a multiple of 16-bits, so 32-bit processors
actually do 32-bit adds with carry.  If the processor doesn't do carries
but permits 16-bit additions in 32-bit words and keeps the overflow in the
high-16 bits, then you can typically do the checksum in 3 instructions
(add low 16-bits of 32-bit word as a short to cksum, shift hi 16-bits into
low 16-bits, add that to cksum -- allow carries to accumulate in high-16
bits of cksum).  If your processor doesn't have a carry then the costs are
believed to be a little higher -- though I don't think enough investigation
has been done on the topic.

Taking this info into account, it usually makes sense to write a copy and
checksum routine which moves data from application space into kernel buffers.
(I.e. replace the old "copy from user to kernel space" routine with "copy
from user to kernel space and do a checksum while you're at it" routine).
The mismatch between CPU and memory speeds means you'll usually find there's
no cost in putting checksum into the copy loop.  To illustrate this, here
are a few numbers for a few processors (numbers are courtesy of Van
Jacobson, w/ permission):

 
    Machine             bcopy   bcopy&cksum     cost of adding cksum
    --------------------------------------------------------
    HP9000/370          122     144             18%
    Sparcstation1       164     177             8%
    Sparcstation2       109     109             0%
    HP9000/720          54      54              0%
    
Times are in nanoseconds per byte to transfer, using bcopy and then
bcopy combined with the checksum adds.  Note that on faster RISCs, the
incremental cost of the checksum is 0.  (If I got any of this data
wrong, blame me, not Van).

Even on a 386 you can do pretty well.  When Steve Pink and I did some
experimenting, we got the bcopy&cksum code nicely aligned with the cache
size and got it to run faster than the bcopy code did in user space.
Our kernel space numbers are less easy to verify (too many things tromp
through the copy routines and the factors are harder to compare).  But the
code is clearly faster by a factor of at least two than doing cksum and bcopy
separately.

The moral I take from these numbers is that your checksum can come for free
and often does.
 
Craig

PS: One warning - several folks who have experimented with rolling copy and
checksum together have warned that getting the routines to run at maximum
efficiency is often a matter of tuning the routine to each instance of a
chip design (e.g. changes in cache sizes between chip versions can cause
recoding to be required).  But the routine is pretty easy to write.

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Mar 1993 02:37:29 GMT
From:      mike@gordian.com (Michael A. Thomas)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In article <732541036snx@crynwr.com>, nelson@crynwr.com (Russell Nelson) writes:
> Again, how many of these are you *using*?   If the subnet is not
> connected to the Internet, why use up an Internet address?
> 
> From where I sit, there's a difference between an IP address and an
> Internet address.

  Gaaah. Really Russell, think about what you are saying! A company
should *always* assume that its various subnets are going to be
eventually connected both together and to the global internet. 
Taking the tact you are suggesting is an exercise in masochism
of the highest degree. 
  This doesn't mean that companies can't be assigned gobs and
gobs of class C networks as they need them going through routers
though...
-- 

		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)

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Mar 1993 04:37:57 GMT
From:      shawn@nethost1.sciatl.com (Shawn Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

mike@gordian.com (Michael A. Thomas) writes:

>In article <1o57r8$f8@agate.berkeley.edu>, spp@zabriskie.berkeley.edu (Steve Pope) writes:
 
>  I wouldn't count on things staying like that. Consider the
>not too distant day when *everything* is directly on the net,
>managable from some super-duper SNMP client. Your printers,
>your modems, your repeaters, your air conditioner, and your 
>toaster ;-)
>  254 address is going to be painfully small when every little
>widget gets its own net address.

Hopefully by that point will have a new addressing scheme in place.
Also there would have to be some form of automatic address configuration.
Can you imagine having to teach every person how to set up the address
on their latest VCR/toaster/thingabob?  :>
--

Shawn Hayes
shawn@nethost1.sciatl.com

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Mar 1993 04:38:51 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP keepalive

IJohnston@cmutual.com.au (Ian Johnston) writes:

> Can anybody see why I should not adjust my kernel from the default
> TCP keepalive idle time of two hours to something like five minutes?

As Barry noted, 5 minutes is much too short.  This will cause lots of
perfectly good connections to time out and die while someone chases down
a bad connector.

> We have a problem with a large PC network

How large is "large"?  Shortening the keepalive time from 2 hours to even
15 minutes will cause an 8 x increase in the amount of keepalive traffic.
If you've got lots of hosts, it could noticeably hurt performance on your
server.  It might also hurt your net if there are slow-speed links in the
middle.

> that open TCP sockets to
> a server (Oracle RDBMS orasrv program) which sets the SO_KEEPALIVE option.
> The PC's then reboot (or crash) for some reason leaving the Oracle process
> running on the server for two hours until the keepalive takes affect.

The Oracle should probably be using application-level timeouts for this, not
keepalives....

> I have located the kernel variables I have to change but I wan't to make
> sure that I won't break anything.  I suppose there is a reason the default
> timeout is so high.

I imagine the default was designed for traffic crossing the Internet.  A
two hour timeout will keep Internet T1 lines from choking on keepalive
traffic, and will keep applications from dying because of router flapping
on the net.  If you've got a really stable local net with no slow-speed
links anywhere, shortening it shouldn't hurt anything.  The important
variables are 1) how long does it take to replace any one broken component
between a client and the server, and 2) how angry will a user be if you
time him out because of a net problem, when his PC is fine.

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

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 93 09:41:57 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?


	In a sense, this argument is pointless.  It has become clear
over the past few months that neither Vernon Schryver nor I is likely
to succeed in convincing the other.  This is unsurprising, as each of
us has a great deal of emotional investment in our respective schemes.
	My overall position is this: checksum avoidance over CRC'ed
nets is cheap, requires no new hardware (two checksummers in the same
interface board?!?), and results in a very large increase in network
software performance. The increase in performance is sufficiently
large that it justifies the microscopic decrease in overall system
reliability - "checksum avoidance" takes active measures to avoid
the worst data corruption risks by not sending unprotected packets
across gateways.

> How many bridges receive the entire ethernet packet using any of the
> familiar MAC chips, letting the MAC check and discard the checksum, and
> then transmit the data packet, letting the output MAC recompute the
> checksum? 

My guess is, few.  Most "familiar MAC chips" support passing the
Ethernet CRC across a bridge that they might be part of.  

> It is impossible for a pair of TCP/IP hosts, both on Ethernets, to know
> whether or not their Ethernet segments are separated by a bridged FDDI
> backbone. 
Yep.  No doubt about it.  HOWEVER, remember that each of those
networks is CRC-protected, so the only unprotected point is within the
bridge itself.  So at worst we're talking about a pretty durn tiny
source of error.
	Remember that I have good precedent in SGI for trusting an
extra bus or two.

> In any of those 3 cases, memory errors in the bridges will data errors
> that are detectable only by the TCP checksum.  Real life, unhappy
> experience with such errors in routers ... Those real life reports I
> have heard involved hosts separated by only 1 or 2 routers, not long
> chains. 
I have heard similar reports.  All the ones I've seen had one thing in
common: a wide-area network between those routers you're talking
about.
	But this brings up another point.  You are the kettle calling
the pot black.  You yourself pushed a scheme which relaxes system
reliability by a microscopic amount.  Why doesn't it bother you?
Because you are pretty confident that mighty few people are going to
have problems because of it, a number that, in fact, is probably
nothing compared to the number of people who lose data through
thunderstorms or sheer disk drive perversity.  I am making exactly the
same argument.
	This whole argument reminds me of disk drives.  Right now, for
just about any DEC product, you can buy two kinds of disk drives: SCSI
or DSSI.  DSSI has better fault tolerance properties that will help
you out in some nasty situations.  Even so, SCSI sales have whomped
DSSI sales because the SCSI drives are half the price even if you buy
them from DEC.  In fact, people have already voted with their feet on
the checksum issue - Sun continues to outsell everybody else in the
workstation market, even though they use an algorithm that is less
conservative than checksum elimination, and the fact has come out in a
number of forums before.  Checksum elimination, though buying almost
all of the same speedups, would not have caused distress to the guys
with the routers.

> I would have guessed reliability would go down geometrically instead
> of exponentially.  I.e. P(success)=P(success at G1)*P(success at G2)*...
I think we agree on just about all points except this niggling little
detail of what the right way to avoid doing checksumming in the CPU
is.  Whether you say geometrically or exponentially just depends on
how you cast the problem.  Your way of putting it is better - I was
thinking in terms of:

	P{success} = P{success in gateway} ^ (hops traveled)

(e.g., constant P{success} per gateway).


							Jon

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Mar 1993 17:05:56
From:      fks@vaxeline.ftp.com  (Frances K. Selkirk)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Protocols: Minimal Implementation Requirements

In article <1993Mar23.193550.2646@walter.bellcore.com> maritza@espresso.bae.bellcore.com (Maritza Ramirez) writes:

> I was reviewing the RFC 1123: Requirements for Internet 
> Hosts that specifies the requirements for Internet host 
> software.  But, what do they mean by "host" ?

"Host" = any IP entity

I don't know where the tendency to use "host" for "server" comes
from. In the purer (IMHO) sense, my PCs are hosts, the machine that
runs my newsserver is a host, and the router between them is a
specialized host. (I guess Romkey's toaster is a host, too.)
Basically, if it gets at least one IP address, it's a IP host. 


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


-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Mar 93 12:06:36 GMT
From:      jpr@olbela.olivetti.be (Morant Jean-Pierre)
To:        comp.protocols.tcp-ip;,comp.protocols.nfs
Subject:   NIS : usage of multiple domains

Hello !

I'm currently using YP/NIS within a single (and small) test domain but I plan to install it on a major site and I have a few questions regarding how to set up an architecture with multiple domains.

CONTEXT :
========
My main concern is with the possibility to serve more than 1 domain : as YP servers are a vital component of the network, I plan to use "highly available" systems for those functions (for example, machines with dual-host and disk mirroring features) and, as it is quite expensive, I would like to reduce the total number of servers.
Our machines use the following OS:
- ODT 2.0 => SCO Unix 5.3.4, TCP 1.2
- Pyramid DC/OSx 1.1
- AT&T Unix for Intel 5.4 2.x with additions from Olivetti, NCR, ...
some other machines : a few SUNs,...
and some older systems with AT&T 5.3
==> almost NO BSD !


QUESTIONS :
==========
Considering the implementations used here,
1) Is a NIS server allowed to be slave for more than 1 domain ?

2) Is a client allowed to be client for more than 1 domain simultaneously/successively, and how ???

3) Is a NIS server allowed to be master of 1 domain and slave for another domain?

4) Is a NIS server allowed to be master for more than 1 domain ? 

E-mail me; I'll post a summary of the answers.
Thanks for your help

From: jpr@olbela.olivetti.be (Morant Jean-Pierre)
Newsgroups: comp.protocols.tcp-ip
Subject: NIS : usage of multiple domains
Summary: 
Followup-To: 
Distribution: world
Organization: S.A. Olivetti Belgium N.V.
Keywords: 


-- 
Jean-Pierre MORANT
Olivetti Belgium
Voice	: + 32 2 210 9353
Fax	:              87

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Mar 1993 14:39:14 GMT
From:      tracey@tsmnet5.melpar.esys.com (Tracey Serle)
To:        comp.protocols.tcp-ip,biz.sco.general
Subject:   system load with multiple network interface cards

We are preparing to implement routing in our network (better late than
never).  We are running SCO Unix on most of our hosts and primarily use
SMC/Western Digital network interface cards.  Does anyone have any
specific information on what sort of system load increase I can expect
on hosts given a second interface card?  I realize that there are
variables here which may make this impossible to answer (like, how much
memory does the host have?), but I will appreciate any information
(statistics, rules of thumbs, whatever) that is forthcoming.

Tracey

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Mar 1993 15:06:36 GMT
From:      p_metcal@csd.uwe-bristol.ac.uk (P Metcalf)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.parallel
Subject:   Re: Giga Bit Networks, what are the limiting factors?

In article <1993Mar18.135024.14683@hubcap.clemson.edu> antony@ee.uts.edu.au (Antony Richards) writes:
>
>What factors will limit the manipulation of data in such a distributed
>environment?
>
>
>There are two factors that I have thought of so far.  Firstly, the memory
>access time.  This is evident by looking at the RISC processor architecture.
>Once data is in a cache, the manipulation of data is very quick.  But, this
>approach is inefficient for calculations that involve touching a lot of data
>only once (such as doing character conversions).  The other factor that I have
>identified is the bus bandwidth.
>
>Antony.

I do not claim to be an expert in this field.  However, yesterday I was 
listening to a man who was, Professor Kurt Maly of the Old Dominion University,
Virginia, USA.  His team have been investigating the potential of parallel
transmission.

Many people are aware that the output at the application layer is a small
fraction of what is achievable at the physical layer.  Part of the reason for
this is that memory systems have not been designed to optimise file I/O and
cache handling.

Professor Maly has been testing systems with parallel transmission ie several
transputers, each attached to its own cable.  This implies the division of
files into chunks, routed separately.  Different routes enable the data to
avoid being stuck in traffic jams - the success of some packets will provide
information for the retransmission of packets.

The problems involved in this approach include:
  The need to avoid copying, and to optimise buffer management.
  Application level data scheduling
  Protocol data scheduling
  Acknowledgement and retransmission (What time lengths do you time?)
   NB this cannot be done at the transport level
  and others I failed to write down :-)

Professor Maly's tests have included testing different numbers of processors,
with different numbers of network interfaces, both in centralised mode, where a
transputer is used to allocate the data and make choices about which processor
to send the next chunk to and which route the data should take, based on the
speed of success of transmission, and distributed mode, where the data is
divided up initially and each parallel processor fends for itself.  His
studies are based on TCP/IP, as the most common set of standards.

Somewhat surprisingly, he found the distributed mode was faster than the
centralised mode - because he used a reliable channel, and did not have to
retransmit much.  In practice (in the big wide world), the opposite would be
true.  Furthermore, he has found that once parallel processors have been
implemented, and network interfaces are multiplied, the next wall one comes
up against in trying to improve transmission speed is the memory problem.

Hope this answer is of some assistance.



-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Mar 1993 16:15:24 GMT
From:      dds@cnd.hp.com (Darren Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

: Yep.  No doubt about it.  HOWEVER, remember that each of those
: networks is CRC-protected, so the only unprotected point is within the
: bridge itself.  So at worst we're talking about a pretty durn tiny
: source of error.

Actually, without the checksum in TCP (or UDP, etc), there is another
unprotected point -- the  memory copy on both the sending and receiving
hosts.  This actually bit us with NFS between two local hosts on
the same ethernet segment with checksumming turned off to improve
performance.  All memory tests showed memory fine, but in
the process of getting copied from the system memory to the lan card, before
the lan card computed the checksum, the data got corrupted.  This only
happened at one memory location, so it was very nasty to track down since
it only manafested itself with NFS, making it look like a NFS defect.

--
Darren Smith 	dds@cnd.hp.com 	Network and Systems Management Division, HP
--

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 93 18:30:59 GMT
From:      narten@percival.albany.edu (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

In article <46802@sdcc12.ucsd.edu> jkay@cs.ucsd.edu (Jon Kay) writes:

> > In any of those 3 cases, memory errors in the bridges will data errors
> > that are detectable only by the TCP checksum.  Real life, unhappy
> > experience with such errors in routers ... Those real life reports I
> > have heard involved hosts separated by only 1 or 2 routers, not long
> > chains. 
> I have heard similar reports.  All the ones I've seen had one thing in
> common: a wide-area network between those routers you're talking
> about.

I have personal experience in which the Ethernet CRC checksum was
inadequate in catching end-to-end errors across a single (non-bridged)
LAN. A piece of bad hardware somehow mangled packets in such a way
that they still had correct checksums (e.g., the packets were probably
damaged between the CPU and the Ethernet card, where the CRC wasn't
applied).  In our case, the protocol that did not include an
end-to-end checksum was ARP.  The clue that finally pointed us to our
problem was seeing large numbers of totally mangled ARP entries on
large numbers of our machines.  If TCP's checksum had been disabled
under these conditions, life would have been even more interesting
than it was.

For another example that does not involve WANs, see section 2.2 of
Saltzer/Clark/Reed's "End-To-End Arguments in System Design" (TOCS,
November 1984).  In that example, packets were damaged by a gateway
during a copy operation (exchanging pairs of bytes about once every
million bytes).  The error occurred so infrequently, that it was hard
to track down.  I've always enjoyed this example, in which they are
considering the relative costs of place error checking at a particular
point vs. the cost of not doing so:

    "Over a period of time many of the source files of an operating
    system were repeatedly transferred through the defective gateway.
    Some of these source files were corrupted by byte exchanges, and
    their owners were forced to the ultimate end-to-end error check:
    manual comparison with and correction from old listings."
-- 
Thomas Narten
narten@cs.albany.edu

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 93 18:34:20 GMT
From:      trt@duke.cs.duke.edu (Tom Truscott)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

>Actually, without the checksum in TCP (or UDP, etc), there is another
>unprotected point -- the  memory copy on both the sending and receiving
>hosts.  This actually bit us ...

Many years ago, if I recall correctly.
You were on the bleeding edge.
Eight years ago most people were not betting their enterprise
on having a 100% reliable LAN, they were happy just to have one.
Most groups now treat a LAN problem as seriously as a disk failure.
Disks used to go wild and read/write to incorrect addresses,
and some operating systems had software disk block headers.
I do not want to return to those days.

I suspect that if TCP/IP were (re-)designed today, checksumming
would be made an IP option.

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 93 19:09:54 GMT
From:      trt@duke.cs.duke.edu (Tom Truscott)
To:        comp.protocols.tcp-ip
Subject:   Re: getting checksums for free


It is interesting to hear that the checksum can indeed be for free.
I tried quite hard to figure out a way to accomplish that
for the current IBM POWER chips, but gave up.

A related issue is the complexity of using the combined copy/checksum.
In the current BSD sockets/TCP-IP implementation the copy is
"far" from the checksum code, and is logically decoupled from it.

What progress has been made in building a complete implementation?
And how does it compare with the potentially-even-faster alternative
of using page-mapping and neither checksumming nor copying?

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Mar 93 19:35:50 GMT
From:      maritza@espresso.bae.bellcore.com (Maritza Ramirez)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Protocols: Minimal Implementation Requirements

Does the "minimal implementation" requirement for an Internet
protocol - such as FTP - apply just to the set of commands that
a server must implement ? ... or does any tcp/ip client must 
support a minimal set of commands too ?

I was reviewing the RFC 1123: Requirements for Internet 
Hosts that specifies the requirements for Internet host 
software.  But, what do they mean by "host" ?

Maritza

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Mar 1993 20:20:23 GMT
From:      richb@jti.com (Richard Braun)
To:        comp.protocols.tcp-ip
Subject:   One-way SLIP connection (cisco/Xyplex)

Our newly-installed Internet link suffers from a severe case of one-way-itis.
You folks outside can anon-ftp files of any size from our archive.  Sitting
at my desk, I can only ftp files smaller than about 20K from outside,
unless I do it from one specific system I know of and/or use a particular
Windows client on this end.  (The problem has nothing to do with ftp;
any large TCP/IP transfer of data into the site gets throttled, so we're
still running netnews through UUCP.)

The physical link at our end is a Xyplex terminal server, connected over
an async line to a cisco Trouter (terminal server) at our Internet
service provider's site.  Neither vendor has shed any light on the problem;
Xyplex says its mtu (max transfer unit) is hardwired to 512 bytes, and
I've seen no evidence that it does anything at all to the packets it
forwards.  It may just plain not work because it's not smart enough.
The cisco product also seems to be doing something strange with throttling
incoming packets.

The symptom is that a transfer will start out fast for a few packets, and
then get throttled slower and slower, the time lapse roughly doubling
between each packet until the connection times out.  The WinQVT/Net
program is the only client here (among a half-dozen we've tried on as
many platforms) which doesn't exhibit this behavior:  it works flawlessly
at full speed.

Two questions:

  1)  Is it possible to use this combination of terminal servers to run
      a link?  (I'm not convinced it will ever work right.)
  2)  Is there any way to boost the speed to 38.4K?  The line supports up
      to 56K, and the Xyplex unit runs fine with data coming in at 38.4K
      (using the particular client/server implementations which are doing
      something differently, probably having to do with the receive
      window), but the cisco seems to discard packets greater than the
      minimum size if I try to push big files outward.

I really would like to find someone else who is using this same hardware
combination to run an Internet link, before giving up on it and swapping
out the hardware.  We're running a 2-year-old version (3.0) of the Xyplex
software, but nothing Xyplex has told me has convinced me that a newer
version would fix the problem.  I call upon USENET now before starting
to throw money at it.

Methinks I'm doing something unnatural with terminal servers God never
intended mankind to do.

-rich

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 1993 20:41:37 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   TFTP to multiple machines at once, (was Re: TCP and gigabit networking - are we fooling ourselves?)

In article <AMOSS.93Mar22193744@shuldig.cs.huji.ac.il> amoss@shuldig.cs.huji.ac.il (Amos Shapira) writes:
>No,  you are not the only one.  I find it pretty wastefull to have all our
>student's NCD's startup in the morning and each TFTP the same file...

RFC 1235 describes the Coherent File Distribution Protocol, an experimental
protocol which uses broadcast packets in a somewhat TFTP-like manner to send
files to multiple clients simultaneously.

It would be nice if it used multicast instead of broadcast.

CFDP is just an experimental protocol.  You could implement it on a homebrew
X terminal, but vendors aren't likely to have heard of it.

-- 
Stephen Trier                      "It is proposed to reduce the effective
Network software type               data rate further by replacing the
Case Western Reserve University     tanks with shuttle launch vehicles."
trier@ins.cwru.edu                        - V. Cerf, RFC 1217

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Mar 1993 21:18:16 GMT
From:      ldore@gandalf.ca (Luc Dore (Montreal Field Service))
To:        comp.protocols.tcp-ip
Subject:   Re: Terminal Servers for Modems

In <16B997AA6.MLYNCH@cmsa.gmr.com> MLYNCH@cmsa.gmr.com writes:


>   I am looking for a terminal server recommendation for attaching dialin and
>dialout modems.  I would like a terminal server that supports TCP/IP and LAT,
>up to 38400 bps, and PPP.  Thank you!!

	I don't want so place a comment or a sales pitch on purpose, but to
answer your question, Gandalf sells a terminal server that has full-modem
control and supports anything you like (LAT, TCP/IP, PPP, SLIP, etc...).

	They're available in a standalone unit or a card that fits into a
Gandalf Access Hub.


-- 
      //      Luc Dore - Gandalf Data Ltd. (Montreal, Canada)      \\
     //     Email : ldore@gandalf.ca  72677.2037@compuserve.com     \\ 
     \\  *********************************************************  //   
      \\  *********** Hopfen und Malz, Gott erhalts ! ***********  //

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Mar 1993 21:48:12 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Protocols: Minimal Implementation Requirements

In article <1993Mar23.193550.2646@walter.bellcore.com> maritza@espresso.bae.bellcore.com (Maritza Ramirez) writes:
>Does the "minimal implementation" requirement for an Internet
>protocol - such as FTP - apply just to the set of commands that
>a server must implement ? ... or does any tcp/ip client must 
>support a minimal set of commands too ?

In the Internet protocol suite, a client application can implement as
many or as few of a protocol's facilities as it requires, as long as it
can interact correctly with any correct server implementation.  So for
FTP, the client only has to be able to send the commands it needs to do
its job (which, by the way, could be something more specific than
"handle arbitrary user requests").  For any command it does send,
however, it must be able to interpret correctly any responses such a
command might elicit.

(Judging from stories i've heard about OSI conformance testing, this
Internet attitude is different than OSI's.  OSI conformance testing, at
least in the U.S., apparently requires that any given implementation
support all functions from the corresponding profile, regardless of
whether it needs those functions to accomplish its purpose.  Bizarre.)

Specifically for FTP, a client could get away with only sending USER,
PASS, ACCT, RETR, and QUIT, although PORT would probably be a good idea,
as well.

>I was reviewing the RFC 1123: Requirements for Internet 
>Hosts that specifies the requirements for Internet host 
>software.  But, what do they mean by "host" ?

They mean "anything but a router".  In other words, it covers both
servers and clients, although perhaps not with equal emphasis.

						don provan
						donp@novell.com

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Mar 1993 22:07:22 +0000
From:      df@eyrie.demon.co.uk (Derek Fawcus)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In article <1o7m1k$oir@nigel.msen.com> emv@msen.com (Edward Vielmetti) writes:
> A pricing goal here at least from the USA point of view is to still enable
> the "freenet" / "metronet" / "toasternet" idea of local grassroots IP
> networking to be able to deliver service to people at $1/user/mo.  My
> back of the envelope calculation suggests you could fill up a class C,
> hand out 1 address to each of 250 people, and just barely make it; if
> you were to go off and intensively cultivate a class B net it looks 
> even more promising.  Note that is *exactly* what demon.co.uk is doing,
> dunno what their costs structures look like but it has to be a cheaper deal
> than getting class C nets for every last little organization attached
> to them...

Well, 10 UKP per month (+ VAT) for private users, around 700-800 (?) users.
Higher charges for commercial users (who can get a class C net).

	DF
-- 
Derek Fawcus (G7FVS)                                df@eyrie.demon.co.uk

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Mar 1993 23:40:09 GMT
From:      peterd@sarahjane.dev.cdx.mot.com (Peter Desnoyers)
To:        comp.protocols.tcp-ip
Subject:   Re: getting checksums for free

craig@sics.se (Craig Partridge) writes:

> 
>    Machine             bcopy   bcopy&cksum     cost of adding cksum
>    --------------------------------------------------------
>    HP9000/370          122     144             18%
>    Sparcstation1       164     177             8%
>    Sparcstation2       109     109             0%
>    HP9000/720          54      54              0%

An implementation of bcopy+checksum on a Decstation (MIPS) gives:

     5000/133 (R3000)    82.5    99.5            20%
     2100    (R2000)     288     292             1.4%

This is with three extra instructions per word instead of one, since
the MIPS chip doesn't have an add with carry. This is the machine that
Jon Kay is using and which soured him on combining checksumming and
copy; even on this machine the hit isn't very much.

[If you don't have a carry bit, accumulate x and x>>16 with three
instructions per word. When you're done you can recover your checksum
from the two sums.]

				Peter Desnoyers
-- 

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Mar 1993 00:31:12 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   implementing those checksum improvements

 
Several folks asked how real the checksum results are.

Quite real, there are at least two separate BSD implementations that do,
in fact, combine the copy and checksum.  In addition, there are interfaces
that have been implemented to provide buffer memory mapped into the processor's
memory space.  This means that the combined copy and checksum loop is the
*only* copy that gets done in either direction.  I'm told one of the interfaces,called the Medusa, has been written up in the February issue of IEEE Jour.
Selected Areas in Communications (which is supposed to be in the mail) --
it easily achieves full FDDI rates on an HP Snake (a vintage 1990 workstation).

As for the BSD implementation, Steve Pink and I did a fast UDP implementation
under MACH and SUN OS 4.1.1.  Van Jacobson has done a fast TCP and fast UDP 
for 4.4BSD.  Van's was a complete rewrite of the networking code (the system
calls look the same but not much else does).  Steve and I were much more   
conservative -- we tried to improve performance for UDP but weren't willing
to rewrite all the other protocols to get that performance gain.  As a result,
our performance improvements were substantially less than Van's.  (Among
other things, Van got rid of splnet(), which is a *big* win and considerably
simplified a lot of the control paths).

Folding together Van's ideas with some of the stuff Steve and I did, here's
a sketch of how you can quickly get about 40% performance improvement in  
your UDP BSD code.  (TCP is similar but a bit trickier).  Note that if
you throw out your code and rewrite, improvements of 90% or more are apparently
possible (e.g. sending a packet takes 1/10 the time that it used to).
This discussion assumes you really know your way around the BSD networking code.

In the protocol switch table, add two new entry points:

    pr_sosend and pr_soreceive


for protocol specific versions of sosend() and soreceive().  In sendit()
and recvit(), which call sosend() and soreceive() have them check to
see if the protocol specific entries exist.  If so, call those instead of
the generic routines.

Note that by getting rid of the generic routines, you've suddenly chucked
about 150 lines of code that was trying to figure out if the socket was
a datagram or stream socket and if operations were atomic, etc.  You can
embed all that protocol-specific information in pr_sosend() and pr_soreceive().

n pr_sosend() for UDP, you have code that generates the UDP and IP headers,
find a route to the destination, checksums the UDP pseudo-header, and then
calls a routine called in_uiomove() which takes the place of uiomove()
[the routine to copy from user space to kernel space].  In_uiomove() copies
data from user space into mbufs and checksums it at the same time.  Append
the resulting chain to the UDP/IP header, and add the checksum of the data
to the header checksum.  Pass the datagram directly to the output interface
(no need to go through ip_output -- you have your header and have your route).
NOTE: If the interface has buffers in processor space, the packet buffer
should come from the interface memory -- this saves copying from mbufs to
interface memory.
 
On the receive side, IP datagrams get passed through ip_input to udp_input.
Udp_input simply checksums the header, removes the header, and passes the
rest of the data (along with the partial checksum) to be queued in a socket
buffer waiting to be read.  When recv() is called, udp_soreceive (the
protocol specific soreceive) is called.  It calls in_uiomove() to move data
from the socket buffer to user space and confirms that the checksum over
the data, plus the partial checksum passed up by udp_input sum to 0 (i.e.
that the checksum is OK).  If the checksum is OK, udp_soreceive returns
(and the application sees the data), otherwise udp_soreceive waits for
another (valid) datagram.  There are some subtleties related to non-blocking
sockets (you have to return with EWOULDBLOCK if the checksum fails muster)
but no huge problems.

 
TCP is harder than this but not much.  Key trick on the inbound side is
to recognize that more than just the partial checksum needs to be passed up
(e.g. sequence numbers, etc) so the TCP PCB can be updated when the segment's
data is passed up to the user.
 
PLEASE NOTE: This is a sketch of a way to get improved performance doing a
relatively easy rewrite.  This rewrite is nowhere near as fast as Van's
experimental implementation, and *should not* in any way, be taken as
an indication of *how fast* TCP/IP can go.  If you want a rule of thumb,
the basic rule is that if TCP or UDP per-packet processing requires more than
100 instructions + the cost of one memory copy + the cost of one context
switch, you can do better.  ALSO, the views in this note are my perspective
on the work of lots of other folks, so if you are going to beat up on them,
kindly do not attribute the views to anyone else (especially Van and Steve,
 who don't need the grief of having to defend my ideas :-)).
 
Craig
craig@bbn.com

PS: Regarding page-mapping.  The current sense is that page mapping is
not a win unless you manage to map interface buffer memory into the
application space.  (Otherwise you have to copy the data from the page
to the interface memory, and I've sketched how to do that in one copy above).
But interface buffer memory is a precious enough commodity that the application
is going to have to release it when done with it -- which means the application
has to know about network buffering, which most application writers don't want
to know about.
 
PPS: Using interface memory as buffer memory isn't a win if the bus makes it
hard for the processor to directly access interface memory.  In this case,
folks have been experimenting with boards that do a DMA copy + checksum
rolled together.  Again, reports are this works well.

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Mar 1993 00:39:51 GMT
From:      assela@marcus.its.rpi.edu (A. Andre Asselin)
To:        comp.protocols.tcp-ip
Subject:   NIC.DDN.MIL: std directory needs updating

I was ftping stuff from the std directory on NIC.DDN.MIL the other day and
noticed that std2 and std12 are linked to obsolete rfcs.  Who is the
proper person to contact to have the directory updated?  Thanks...
   - Andre Asselin (assela@rpi.edu)

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 93 00:47:01 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

Lars Poulsen (lars@spectrum.CMC.COM) wrote:
>   : (1) to the Internet Society and IANA for the addresses ($25 +
>   :     $.01/address seems about right)
>   : (2) to the Routing Authority for advertizing the route ($1000/year per
>   :     route)
>   : (3) to the Local Access Carrier for
>   : 	- pipe width ($100/month for 56K)
>   : 	- route tax ($100/year per route)
>   : (4) to the local telephone company for the physical wire

In article <1o7m1k$oir@nigel.msen.com> emv@msen.com (Edward Vielmetti) writes:
>   This actually makes quite a bit of sense.  Community or metro networks
>   now start to look like a real good idea, because if you get a bunch
>   of people to cooperate and share a class B or a few class C nets, hide
>   dozens or perhpas hundreds of organizations behind one $1000/yr route,
>   and otherwise conserve address space by increasing the intra-network
>   administration costs, the money costs go down.

In article <RENS.93Mar18075959@lorax.shearson.com>
   rens@cs.columbia.edu (Rens Troost) writes:
>Fundamentally, I oppose charging for allocations.
>Address space should be free.

Clean water should be free; clean air should be free; radio spectrum
should be free .... but all of these are limited resources, and in the
free'st country in the world, we believe in motivating people to make
decentralized decisions about allocations.

If we are worried about running out of Internet addresses, yet less
than 0.03% of the addresses that have been issued are in use, it seems
desirable to motivate people to return the unused addresses so they can
be used by someone else. This is much less painful that moving everybody
to a new network architecture.

>The (obvious) problems with the above suggestion:
> ...
>(2) there is (fortunately) no 'routing authority'

There is ... the NSFnet routing policy database determines who is
reachable from the United States. Part of the "new NSFnet contract"
is operation of a routing policy database.

>For what it's worth, these ar _my_ predictions:
>
>In the short term (ie, life of IP) I forsee entrepreneurs grabbing up
>address space and then selling the rights to the highest bidder. This
>will probably happen just like cattle ranching evolved in the west,
>with class-C homesteaders selling out or conglomerating.

My suggestion is that we let this money benefit the common
infrastructure rather than "entrepreneurs".

>In the long term, IP goes away/mutates (hopefully into a
>variable-length address network protocol).

Those of us who are building routers are painfully aware of the
performance cost of variable length fields in packet headers.

>Routing _will_ become 'expensive' as more and more class C networks
>come online, and tables get bigger. The eventual migration protocol
>chosen should support heirarchical routing.

Ip supports hierachical routing just fine, thank you. - So long as we
assign the addresses in a hierachical fashion.

>The government will start regulating data networks, and the proce of
>connectivity will go up to feed a horde of useless bureaucrats who
>only serve to slow down the process.

If we apply a price to those elements that we want to conserve, the
market can regulate connectivity much better than the bureaucrats.

-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Mar 1993 03:32:18 GMT
From:      ggm@brolga.cc.uq.oz.au (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   Re: implementing those checksum improvements


Dear Skilled network-hackers-with-sourcecode-for-your-flavour-of-Unix:

Please, please oh gurus, supply .o files for binary-only sites who have 
Ultrix 3.x & 4.x, Sunos 3.x & 4.1.x etc etc etc.

If there is a significant performance gain to be had, I am desperate for
one. I'd love to re-make my kernel if the win is there.  This code wants
to be written at most once for each operating system, and by somebody who
knows what they're doing. I am not that person.

-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

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 93 11:18:05 CST
From:      u4944@cray.com (Charles Hubbert)
To:        comp.protocols.tcp-ip
Subject:   ftp in DOS background?

We have a print spooler that runs WINTCP and ftpd in the background.  The
version of ftpd (4.1.1 from Wollongong) is not fully compatible with
the current ftp version on the host.  Specifically we get '502 ALLO command
not implemented' messages when putting from the host mainframe to the print
spooler.  Does anyone know of any ftp servers that run in DOS background?
I'm hoping for something besides an upgrade from Wollongong due to costs
and low priority level of this problem.  

Thanks for any ideas...
-- 
Chuck Hubbert	u4944@techops.cray.com

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Mar 1993 06:28:44 GMT
From:      hstsai@solar.csie.ntu.edu.tw (Hong-Shing Tsai)
To:        comp.protocols.tcp-ip
Subject:   NCSA and SLIP8250.

Hello,

       Anyone out there using the NCSA with the slip8250 as the mean
    to do the telnet via the slip to a terminal server.

       I just can use the 2400 baud to connect to the terminal server
       to do the telnet and ftp, but when I am trying to use the 9600
       baud connection to do the telnet, I just see the message " TCP:
       crc checksum" displayed several times in the screen and then stop.
   
       I have also change the options of the slip8250.com to 9600 speed.
       but in vain.

       Are there any substitution for slip8250 for the slip connection ?

       Any suggestions are appreciated ...



-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Mar 1993 07:31:49 GMT
From:      queloz@bernina.ethz.ch (Ronald Queloz)
To:        comp.protocols.tcp-ip
Subject:   service entry (port number) on remote systems

Hello Netlanders,

I have to write a network application which is distributed over
several nodes.  These "node-servers" communicate with each other over
sockets using udp datagrams.  Each node-server offers a service which
is registrated in /etc/services.  So the node-server gets **its**
portnumber for the service it offers using the getservbyname function
call.

Now my question:

Is there a way for a node-server to get the port number of the
**same** service entry on a **remote** machine (rgetservbyname) or do
I have to make sure that every service entry on every node of my
application uses the same port for the service?  If I have to make
sure that the entries must be the same, which portnumber can I reserve
for my application to make sure nobody else uses the same portnumber?
How is this done with "real-life" network applications?  Any ideas?
Any solutions?

Thanks in advance.

Ron.


-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 93 08:51:53 GMT
From:      devdjn@space.alcbel.be (Dennis Newport)
To:        comp.protocols.tcp-ip
Subject:   Re: Netperf, a network performance benchmark

We have various throughput and transmission delay test programs
written in C and Ada (our application that needs the comms is
in Ada) so I would be very interested in getting a copy of netperf
to compare this with our software and to compare the results. How
do I go about getting my hands on a copy.

All advice greatly appreciated.

---
Dennis Newport,                  email: devdjn@space.alcbel.be
Alcatel Bell Telephone,
Berkenrodelei 33,                phone: (+32) 3/829.5488
2660 Hoboken,
Belgium.


-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Mar 1993 14:56:39 EST
From:      holdrege@dcv4kd.phs.com (Urban Surfer)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

PSI, Alternet and others own huge blocks of class B addresses. It is not hard
to get a class B address from them. Just sign up for their service, tell them 
you have hundreds of nodes, and in a few days, you get your class B address. 
No questions asked.

Matt Holdrege		holdrege@dcv4kd.phs.com

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 93 10:57:19 GMT
From:      jim@cs.strath.ac.uk (Jim Reid)
To:        comp.protocols.tcp-ip
Subject:   Re: implementing those checksum improvements

In article <1993Mar24.003112.25206@sics.se> craig@sics.se (Craig Partridge) writes:

   PS: Regarding page-mapping.  The current sense is that page mapping is
   not a win unless you manage to map interface buffer memory into the
   application space.

Even then, it is not clear if page mapping wins over data copying.
Fiddling with page table entries can cause non-obvious performance
hits by invalidating entries in hardware caches or lookaside buffers.
These could have a global impact on performance and not just affect
the application sending/receiving the data.

In the days of the VAX, I recall Mike Karels saying that in 4.[23]
BSD, it was cheaper to shift data less than 8K was by copying than by
remapping pages.

		Jim

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Mar 93 12:32:53 GMT
From:      ctmg@uuisis.isis.org (Fraser MacKenzie)
To:        comp.protocols.tcp-ip
Subject:   TELNET PROBLEM

Hi all,

This is the first time that I have posted here but I find myself
with a problem and I was wondering if anybody out there could offer
me a solution to it.

I have a 486DX2/66 SMP with 2 CPU's attached to it are 2 1.3 GIG 
SCSI disks, 3 digiboards, an archive tape drive, and a Novell
NE3200 Ethernet card attached.  I am running SCO UNIX, TCP, MPX,
LLI drivers, Digiboard software on it and am having major problems.

I get no error messages that I can find but users get kicked off the
system after about 5 or 6 hours.  Once they have been kicked off they 
cannot get back in.  This is because the users are using telnet from
PCs.  I have found that TELNETing in to the machine does not work but
TELNETing from the machine out works.  Also, RLOGINing in works and so
does RLOGINing out.  All the R functions seem to work both ways.

Please help.  \

If you need more information feel free to E-mail me.


Fraser

---
ctmg@uuisis.isis.org (Fraser MacKenzie)
UUISIS - Nepean, Ontario (613) 823-6539
-- 

----------------------------------------------------------------------
               UUISIS Electronic Mail Service (Ottawa)  
                           613-823-6539

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Mar 1993 12:37:46 GMT
From:      narten@percival.albany.edu (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?

In article <NARTEN.93Mar23133059@percival.albany.edu> narten@percival.albany.edu (Thomas Narten) writes:

> For another example that does not involve WANs, see section 2.2 of
> Saltzer/Clark/Reed's "End-To-End Arguments in System Design" (TOCS,
> November 1984).

One other example that I neglected to mention, though one could argue
that the hardware in question is particular bad (again, bad memory,
not bad links) is found in Eric Rosen's "Vulnerablities of Network
Control Protocols: An Example" (ACM Software Engineering Notes,
January 1981).  This article describes how the lack of end-to-end
checksums brought down the *entire* Arpanet (the routing software went
wild). 
-- 
Thomas Narten
narten@cs.albany.edu

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 93 16:49:44 GMT
From:      srl@terminus.ericsson.se (Steve Langstaff)
To:        comp.protocols.tcp-ip
Subject:   Re: How to tell telnet client not to echo ???

In article 93Mar24171531@shuldig.cs.huji.ac.il, amoss@shuldig.cs.huji.ac.il (Amos Shapira) writes:
:Hello,
:
:I'm writing a programme to run instead of the regular telnetd on a gateway
:machine.  The problem is that I can't tell the client to stop echoing the
:characters when typing the password.  I send it "IAC DONT ECHO" and recieve
:back "IAC WONT ECHO" but still the characters are echoed.
:
:This is both on Sparc under SunOS 4.1.1 and Irix 4.0.5F telnet clients.
:
:I'd appreciate any help or refferences.
:
:Thanks,
:

Try sending "IAC WILL ECHO" from the server to the client, thus informing the
client that the server will be responsible for handling the echoing. Then all
you have to do is NOT echo the characters typed back to the client. At the end
of the password send an "IAC WONT ECHO" to force the client back into being
responsible for the echoing.

---

Steve L.


-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 93 13:39:29 +0200
From:      wvb@sunvax.sun.ac.za
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Quotes on OSI vs TCP/IP

I have to give a talk on TCP/IP vs OSI next week (yes, yet
another), and I am looking for some suitable funnies -
quotes, chestnuts, flames, etc.

Alternatively, if anyone could point me towards archived
copies of debates on the issue (I know some ahave raged in
protoocols.iso and protocols.tcp-ip in the past) I would
appreciate it.

Please mail any answers.

Thanks


-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Mar 1993 17:47:36 GMT
From:      hallam@dscomsa.desy.de (Phill Hallam-Baker)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!


In article <1oacmaINNdvh@access.usask.ca>, glenn@sundeck.usask.ca (Glenn Hollinger) writes:

|>From article <1993Mar16.230018.15764@cmutual.com.au>, by IJohnston@cmutual.com.au (Ian Johnston):
|>> 
|>> 
|>> Here is a different question for everyone.  Who do I contact if
|>> I wan't to give back a Class B IP number?  I know of a few
|>> sites that have applied for and recieved IP numbers and then
|>> have not used them.
|>
|>Don't give them back!  Save them a few more months, then auction them
|>off to the highest bidders.  They could be worth a fortune...!

Only last month I was being flamed for saying that the major flaw of TCP/IP
was the limited address space... 

DECnet phase V anyone ?

Seriously, this problem is going to bite pretty soon, anyone who uses a
campus switch like we do (CISCO router) ends up needing multiple class C
addresses at the very least. If you put more than 16 or so workstations on
the same ethernet segment they can trash it PDQ. Once the killer workstations
start to be replaced by killer PCs it is going to be excrement colliding with
ventilator time.

Thats before you start to consider toasters etc with an internet address.


Phill Hallam-Baker

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Mar 1993 18:15:45 GMT
From:      peter@ferranti.com (peter da silva)
To:        comp.protocols.tcp-ip
Subject:   Re: getting checksums for free

In article <1993Mar23.002359.2090@sics.se> craig@sics.se (Craig Partridge) writes:
> (I.e. replace the old "copy from user to kernel space" routine with "copy
> from user to kernel space and do a checksum while you're at it" routine).

That's if you're doing that extra copy. High speed systems are going to avoid
it, by doing stuff like marking the page with the buffer in it copy-on-write
and then DMA-ing right from user space.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
12808 West Airport Blvd.  Sugar Land, TX  77478  USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 1993 09:50:55 -0800
From:      w1y092@rick.cs.ubc.ca (Steven David Gribble)
To:        comp.unix.wizards,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   SLIP questions..

Hello -

I've been trying to set up a dial-up SLIP connection between a unix workstation
and the local university.  The problem I've been experiencing is that the
SLIP server dynamically assigns the clients' addresses, the gateway address,
the netmask, etc. upon each connection.

I need to be able to get a hold of this information and reconfigure my network
files each time I call up.  Apparently 'BOOTP' protocol may be used to this
effect - can anyone give me any information about how to go about using
this protocol, or any other method to get this configuration information?

Thanks,
Steve Gribble
w1y092@rick.cs.ubc.ca

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Mar 1993 21:43:04 GMT
From:      doug@happy.vf.ge.com (Doug Hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!

In article <C4EMrC.CxA@dscomsa.desy.de>, hallam@dscomsa.desy.de (Phill Hallam-Baker) writes:

> Seriously, this problem is going to bite pretty soon, anyone who uses a
> campus switch like we do (CISCO router) ends up needing multiple class C
> addresses at the very least. If you put more than 16 or so workstations on
> the same ethernet segment they can trash it PDQ. Once the killer workstations
> start to be replaced by killer PCs it is going to be excrement colliding with
> ventilator time.
> 
> Thats before you start to consider toasters etc with an internet address.
> 
> 
> Phill Hallam-Baker

Is there something weird happening on your network? We have about 25-30
workstations on each of our two lans right now (includes Sun's mac's
and PC's running various forms of mail, X, appletalk and NFS.)  Our 
network utilization is typically around 2% (diskless clients with
no swap!)  There are currently two networks with a cisco between
them and two servers (one on each network) acting as file and boot servers.
We have peeks of utilization around 7:30 in the morning, when everybody
logs in, and they only amount to about 7-8% of network capacity.

  utilization = bits/second avg'd over five minutes divided by 10,000,000

If you are trashing your network with only 16 machines, you must be
doing some monstrous application, or there's something else wrong, like
you're using old Ungermann Bass stuff that only provides 3Mbps bandwidth,
or something else entirely.
  On our network people run Interleaf, RDD and teamwork without complaint.

-- 
_____________________________________________________________
Doug Hughes
System/Net Admin - GE Aerospace, Valley Forge, PA
doug@happy.vf.ge.com	or	hughes@sde.mdso.vf.ge.com

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 93 22:53:29 GMT
From:      halp@devnull.mpd.tandem.com (Hal Porter)
To:        comp.protocols.tcp-ip
Subject:   PD NIT (or equivalent) for Streams/SVR4


Is anyone aware of a public domain version of SUN's NIT. I'm interested
in the functionality for an AT&T SVR4 system. 

Alternatively, is there a version of the BSD Packet Filter available for SVR4?

I understand BPF is available through anonymous ftp and if worse comes to 
worse, I can always attempt to "stream-ize" it.

Thanks,

Hal Porter
halp@mpd.tandem.com
Tandem Computers
Austin, TX

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Mar 1993 01:23:58 GMT
From:      pmetzger@snark.shearson.com (Perry E. Metzger)
To:        comp.protocols.tcp-ip
Subject:   Coherent File Distribution Protocol


In Re: all the comments that follow

All these posters seem to be looking for something that already
exists.

There is an RFC out there, specifically rfc1235, for something called
the Coherent File Distribution Protocol, and free source code
implementing it in a Berkeley Unix environment is available. Its
designed for precisely this sort of situation -- large numbers of
people requesting the same file over a limited bandwidth network.

Original messages were:

amoss@shuldig.cs.huji.ac.il (Amos Shapira) writes:
>ben@rex.uokhsc.edu (Benjamin Z. Goldsteen) writes:
>
>   (Darren Reed) writes:
>
>   >Point to point transfers through TCP aren't it though.  When you have an
>   >NFS server and a network of clients attached, the ethernet goes pretty
>   >damn quickly, especially when you have a class running of 20 or so people
>   >all loading up and running an animation demo on the latest version of
>   >AutoCad.  Ok, NFS is bad, but a faster network would make it a bit more
>   >bareable :)
>
>	 Am I the only one who finds it some what inefficient that
>   each machine must request and transfer the same data?  Not that
>   I would know how to fix this!  It would sure save some traffic
>   if we could, though...(we have a 24 Mac lab...OK everybody startup
>   up MacX...)
>   --
>   Benjamin Z. Goldsteen
>
>No,  you are not the only one.  I find it pretty wastefull to have all our
>student's NCD's startup in the morning and each TFTP the same file after a
>thoughfull security guy though he was doing us a fevor by truning off the main
>power switch at night.
>
>Could be really nice if the NCD's prom (or, mac) could talk ISIS/Transis to
>exploit the Ethernet's Bus architecture.
>
>What I mean is that solutions for this seem to be pretty available today (i.e.
>this field left the theory stage long ago and now is waiting to be exploited),
>you just have to do it.

--
Perry Metzger		pmetzger@shearson.com
--
Laissez faire, laissez passer. Le monde va de lui meme.

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 93 09:30:57
From:      amoss@shuldig.cs.huji.ac.il (Amos Shapira)
To:        comp.protocols.tcp-ip
Subject:   Re: How to tell telnet client not to echo ???

srl@terminus.ericsson.se (Steve Langstaff) writes:

|(Amos Shapira) writes:
|:Hello,
|:
|:I'm writing a programme to run instead of the regular telnetd on a gateway
|:machine.  The problem is that I can't tell the client to stop echoing the
|:characters when typing the password.  I send it "IAC DONT ECHO" and recieve
|:back "IAC WONT ECHO" but still the characters are echoed.
|:
|:This is both on Sparc under SunOS 4.1.1 and Irix 4.0.5F telnet clients.
|:
|:I'd appreciate any help or refferences.
|:
|:Thanks,
|:
 
|Try sending "IAC WILL ECHO" from the server to the client, thus informing the
|client that the server will be responsible for handling the echoing. Then all
|you have to do is NOT echo the characters typed back to the client. At the end
|of the password send an "IAC WONT ECHO" to force the client back into being
|responsible for the echoing.

Thanks,  I found it out just after I posted (and cancelled a few minutes
later!) my original message.  Your answer is what I did and things work just
great now.

Thanks very much

(jesus,  these articles DO travel fast...)

Cheers,
--
--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

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 93 09:42:00
From:      amoss@shuldig.cs.huji.ac.il (Amos Shapira)
To:        comp.protocols.tcp-ip
Subject:   Re: TELNET PROBLEM

ctmg@uuisis.isis.org (Fraser MacKenzie) writes:

   I have a 486DX2/66 SMP with 2 CPU's attached to it are 2 1.3 GIG
   SCSI disks, 3 digiboards, an archive tape drive, and a Novell
   NE3200 Ethernet card attached.  I am running SCO UNIX, TCP, MPX,
   LLI drivers, Digiboard software on it and am having major problems.

   I get no error messages that I can find but users get kicked off the
   system after about 5 or 6 hours.  Once they have been kicked off they
   cannot get back in.  This is because the users are using telnet from
   PCs.  I have found that TELNETing in to the machine does not work but
   TELNETing from the machine out works.  Also, RLOGINing in works and so
   does RLOGINing out.  All the R functions seem to work both ways.

I don't have any experience with your configuration but could it be that your
telnet client is trying to use the same port every time it connects?  Try
telling it to use another port if you can.

If it doesn't help then telling us what do you mean by 'does not work' should
help to diagnose the situation (what do you get when you try to telnet? Does
it hang?  Do you get "connection refused"?  Does telnet to another port or
another machine work?)

(possible explenation:  the connection is dropped for some reason or another
but the server still has this <server port><client port> pair in one of the
closing states of TCP (e.g. CLOSE_WAIT) so it ignores your packets which come
from the same port,  that's why UNIX helps you assign a random port number
guarenteed not to have been used for the past few hours).

(I'm not sure about the above explenation,  does anyone care to comment?).

Hope this helps,
--
--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


-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Mar 1993 10:21:45 EST
From:      <CANTERO@EVALUN11.BITNET>
To:        comp.protocols.tcp-ip
Subject:   3com



hi :-)

  Know anyone e-mail for get info of product 3com ?


-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 93 09:19:40 GMT
From:      aamicone@sdcc13.ucsd.edu (Andrew Micone)
To:        comp.protocols.tcp-ip
Subject:   Using SLIP as Gateway

Hi, maybe you can all help me with a little problem I'm having:

Configuration:

SparcStation 370 running SunOS 4.1.2 (BSD Style). We are running
pppd in slip mode connecting to the cerfnet gateway at an address
provided by them, using at netmask of 255.255.255.0 as they
specify. The SparcStation is currently disconnected from our LAN,
but is connected to a Hayes  compatible BOCA technologies modem on
ttyb with a hardware handshaking cable. We are using a SLIP
connection provided by cerfnet to connect to the internet. We are
using MorningStar PPP version 1.4beta with the loadable drivers.

Problem:

We want to use our SLIP connection to cerfnet as a gateway from our
local network, which uses a NIC assigned network IP number, to the
internet. When the interface comes up it sends an IP packet with
the address of  the machine that brought up the interface. The
problem is that cerfnet only seems to acknowledge packets that have
the SLIP IP address in them. So any program that brings up the
interface times out. If you connect during idle time, the packet
goes out with the address of the SLIP interface, and that works
properly. The problem is that this is not the desired  behavior. I
could run my machine with the SLIP IP number, but then I would be
unable to talk to the local network, but if I use the local network
number, the packet that brings up the interface is not
acknowledged. Is there any way to have packets that are routed to
the SLIP interface automatically translated to the SLIP IP number,
and then back to the local IP number when the packet  is
acknowledged? I realize this would probably only support one
machine using SLIP as a gateway at once, but that's more than
acceptable.

I suspect that this might be a job for gated, but I know very
little about how gated works or what it can do for me.

Thanks in advance,

-- Andy
andym@cerf.net

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Mar 1993 10:22:47 GMT
From:      hmchen@fcom.ee.ntu.edu.tw (Hung-ming Chen)
To:        comp.protocols.tcp-ip
Subject:   UDP Broadcast Examples

Dear Netters,
  I am writting a program that uses UDP broadcast facility.
There is very rare example that I can refer to. Can anybody
give me a general one? The most important thing is how to
assign the global address to the structure sockaddr and use it
to send out the data I will broadcast.         

Thanks in advance.
 
Fred Chen

email: hmchen@fcom.ee.ntu.edu.tw       


-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 93 13:13:26 GMT
From:      devdjn@space.alcbel.be (Dennis Newport)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Broadcast Examples


If you look in the Socket Based IPC section of the Network Programming Guide
from Sun, under the heading Broadcasting and Determining Network Configuration,
you will find an example to get you started.

Good luck.

P.S. The example works because I have used it.

---
Dennis Newport,                  email: devdjn@space.alcbel.be
Alcatel Bell Telephone,
Berkenrodelei 33,                phone: (+32) 3/829.5488
2660 Hoboken,
Belgium.


-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Mar 1993 15:54:14 GMT
From:      fmcgnnss@unix2.tcd.ie (Fergal McGuinness)
To:        comp.protocols.tcp-ip
Subject:   Ethernet Multicast Addresses


Can anybody tell me or point me to where I can find out how to configure an
Ethernet interface to accept multicast addresses?

Thanks,
	Fergal

--
	Fergal McGuinness                             fmcgnnss@unix2.tcd.ie
	Dept. Of Microelectronic Engineering
	Trinity College Dublin
	Ireland.  

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 93 16:38:03 GMT
From:      pgreen@aoc.nrao.edu (Philip Green)
To:        comp.protocols.tcp-ip
Subject:   Satellite connections

I am considering connecting  a remote site via satellite but I have no 
clue where to start.   Who provides such services, how do I contact them etc?
Any help is appreciated.

---
Phil Green                           	pgreen@aoc.nrao.edu
NRAO					505.835.7294

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Mar 1993 18:43:59 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.sys.hp,comp.benchmarks,comp.protocols.tcp-ip
Subject:   Fixes for netperf version 1.7

Folks -

If some of you are having difficulties getting the TCP_RR and UDP_RR
tests of netperf working on your systems, here are some fixes from
Jeff Smits which might help. These problems will appear on systems
where the htonl/htons (etc.) calls are not no-ops.

Bug One:
	I did stumble across a minor bug. On line 337 of netlib.c, the
	for loop is running off the end of the array, and, at least on
	Intel SVR4.2, ends up changing "local_recv_align" from an 8 to
	a 0x8000000...(!)...which kept the TCP_RR tests from running.

Bug Two:
	Have since found another one that kept UDP_RR from
	running...on or about line 2885 in nettest.c (function
	send_udp_rr(), the "-" should be an "=":

	nettest.c:2885:    server.sin_port -   htons(server.sin_port);

Many thanks to Jeff. The fixes "will be incorporated into a future
release" ;-) 

rick jones
keep getting bit by ordering...

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 93 18:44:22 GMT
From:      bleimeyp@wolf.mayo.edu (Paul Bleimeyer)
To:        comp.protocols.tcp-ip
Subject:   Looking for a NewsReader for PCNFS



Sometime back, someone posted a message about a port for a usenet news 
reader that would work under MSWindows 3.1 with Sun PCNFS. I would like to  
hear from people who are actually using this software and how they have it
configured. Are you using it with a shim driver or are you running it with
and ndis stack? How well does it work for you? What's your installed base,  
etc?

Sincerely,

--
Paul Bleimeyer
Mayo Foundation
Rochester, MN 55905
bleimeyp@mayo.edu

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Mar 1993 19:32:37 GMT
From:      apfel@tolten.puc.cl (Andres Fernandez-Leon)
To:        comp.protocols.tcp-ip
Subject:   something about 'talk'...


Hello :-)

Who can say me where can i find information about 'talk'???
How it works, at ports level... in a rfc maybe?

Thanks in advance,

Andres Fernandez-Leon
apfel@tolten.puc.cl


--


-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 93 20:13:15 GMT
From:      hwdub@chevron.com (Dub Dublin)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addr

I've listened to several good arguments on both sides of this issue,
and no one has brought up one very important fact:  The IETF botched a
call when they decided the address class boundaries.  There are plenty
of addresses, it's just hard to get them.  

My own company is far from guiltless in this area:  I came to work here
two years ago and was SHOCKED to discover that Chevron had just
received TWENTY-SIX class B addresses from the NIC.  (This was about
the time Stanford found out they were history, and I've always wondered
if it wasn't done just to spite the world...)  Our people at the time
could hardly spell TCP/IP, and they got the twenty-six class B's
because "the Multi-Protocol Internetwork Chevron is planning requires a
class B address at each site."  (This is not an actual quote, but my
paraphrase of the reasoning behind our request to the NIC.  Believe it
or not, they thought this was true because that's what Cisco told
them!)  

These addresses are not particularly well-used: the most crowded uses
only 1220 hosts, the smallest 4, with an average of 227 hosts/class B.
We're currently using just over half of 1% of our assigned address
space.  I'm sure we'll need a lot more space in the future, but I doubt
that we'll ever really require a class B for our sites in Evanston,
Wyoming or Bakersfield, CA.  Giving them back is problematic once
they're already in use, though.  There is a substantial non-trivial
cost associated with wholesale address changes, and I doubt Chevron
would be willing to give up address space for altruistic reasons,
"People Do" notwithstanding.

The reason people are eating up class C's for one or two machines is
really even simpler:  The NIC won't assign a domain name until you have
an IP number assignment.  In many cases, all someone really wants is
the domain name, but they since they have to have the IP address
assignment anyway, they go ahead and use it, even if their connection
method might not require it.  I have noticed that it is much harder
(and more expensive) to get an Internet connection than it should be -
unless you live in the bay area or NE corridor, you can expect to pay
AT LEAST $250-300/mo for a full (routing & domain name) Internet
connection.  Although charging for addresses would clear up the address
space use, there is still plenty out there, and there are ways to
encourage people to give up unused/unneeded addresses without creating
a price structure which would prevent the further spread of the
Internet, especially in the dynamic small companies that are so
beneficial to both the Net and the economy at large.

---
----------------------------------------------------------------
Dub Dublin                      | "Perfection is not when there
hwdub@cyberia.hou281.chevron.com| is nothing left to add, but
Chevron Information Technology  | when there is nothing left to
(713) 596-3199 (work)           | take away."
2811 Hayes Road, Room 2305      |     - Antoine de Saint-Exupery
Houston, Texas  77082-6696      |       early aviator & author
----------------------------------------------------------------
People Don't... (...Speak for Chevron)

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Mar 1993 21:20:04 GMT
From:      hallam@dscomsa.desy.de (Phill Hallam-Baker)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!


In article <1993Mar24.214304.2170@knight.vf.ge.com>, doug@happy.vf.ge.com (Doug Hughes) writes:

|>In article <C4EMrC.CxA@dscomsa.desy.de>, hallam@dscomsa.desy.de (Phill Hallam-Baker) writes:
|>
|>> Seriously, this problem is going to bite pretty soon, anyone who uses a
|>> campus switch like we do (CISCO router) ends up needing multiple class C
|>> addresses at the very least. If you put more than 16 or so workstations on
|>> the same ethernet segment they can trash it PDQ. Once the killer workstations
|>> start to be replaced by killer PCs it is going to be excrement colliding with
|>> ventilator time.
|>> 
|>> Thats before you start to consider toasters etc with an internet address.
|>> 
|>> 
|>> Phill Hallam-Baker
|>
|>Is there something weird happening on your network? We have about 25-30
|>workstations on each of our two lans right now (includes Sun's mac's
|>and PC's running various forms of mail, X, appletalk and NFS.)  Our 
|>network utilization is typically around 2% (diskless clients with
|>no swap!)  There are currently two networks with a cisco between
|>them and two servers (one on each network) acting as file and boot servers.
|>We have peeks of utilization around 7:30 in the morning, when everybody
|>logs in, and they only amount to about 7-8% of network capacity.
|>
|>  utilization = bits/second avg'd over five minutes divided by 10,000,000
|>
|>If you are trashing your network with only 16 machines, you must be
|>doing some monstrous application, or there's something else wrong, like
|>you're using old Ungermann Bass stuff that only provides 3Mbps bandwidth,
|>or something else entirely.
|>  On our network people run Interleaf, RDD and teamwork without complaint.
 
We run heavy duty physics analysis. We are talking about analysing the data
from a physics experiment that writes approx 1Gb of data per second. Obviously
we filter before it hits the local area net, even so the load is *substantialy*
heavier than email!

If you want to trash a network forget diskless workstations and buy X terminals.
they just love net.bandwidth, especialy with X11.

Generally we hit 20% or 30% utilization over sustained periods in our online
system, offline I don't have the figures.

Another good way to thrash a network is to buy killer workstations such as
SGI ingigos, AXPs or such. One of those can really spin data off a central
filestore. Suns Macs and PCs just are not the same. We need FDDI of course
but it's a bit harder than just buying the stuff...


Phill Hallam-Baker

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 1993 14:16:47 -0800
From:      earle@isolar.Tujunga.CA.US (Greg Earle)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Are hosts required to return ICMP Dest Unreachable Bad Port responses?

If a host receives a UDP packet which is addressed to a non-existant (on the
host machine) port, is it required to return an ICMP Dest Unreachable Bad Port
response?  (You can RTFRFC if you like; quote chapter & verse please.)

I noticed that Macintoshes running MacTCP 1.1 and 1.1.1 do not return these,
so, for example, things like "traceroute" to a Macintosh will fail, even if
it is ping-able (for that matter, even if it is both ping-able and running
NCSA Telnet, so I can FTP to it as well):

tehachapi:2:100 % ping local-to-my-subnet-Mac 56 5
PING local-to-my-subnet-Mac.jpl.nasa.gov: 56 data bytes
64 bytes from local-to-my-subnet-Mac.jpl.nasa.gov (128.149.24.40): icmp_seq=0. time=2. ms
64 bytes from local-to-my-subnet-Mac.jpl.nasa.gov (128.149.24.40): icmp_seq=1. time=1. ms
64 bytes from local-to-my-subnet-Mac.jpl.nasa.gov (128.149.24.40): icmp_seq=2. time=2. ms
64 bytes from local-to-my-subnet-Mac.jpl.nasa.gov (128.149.24.40): icmp_seq=3. time=1. ms
64 bytes from local-to-my-subnet-Mac.jpl.nasa.gov (128.149.24.40): icmp_seq=4. time=1. ms

----40.24.149.128.in-addr.arpa PING Statistics----
5 packets transmitted, 5 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 1/1/2

tehachapi:2:101 % ftp local-to-my-subnet-Mac
Connected to local-to-my-subnet-Mac.jpl.nasa.gov.
220 Macintosh Resident FTP server, ready
Name (local-to-my-subnet-Mac:earle): ^C

tehachapi:2:102 % traceroute local-to-my-subnet-Mac
traceroute to local-to-my-subnet-Mac.jpl.nasa.gov (128.149.24.40), 30 hops max, 40 byte packets
 1  * * *
 2  * * *
 3  * * *
^C

All the local UNIX-based hosts here (SunOS, HP-UX, IRIX, etc.) all return
these ICMPs, but the Macs do not.  MacTCP drain-bamage?

-- 
	- Greg Earle
	  Phone: (818) 353-8695		FAX: (818) 353-1877
	  Internet: earle@isolar.Tujunga.CA.US
	  UUCP: isolar!earle@elroy.JPL.NASA.GOV a.k.a. ...!elroy!isolar!earle

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Mar 1993 01:30:32 GMT
From:      peter@cujo.curtin.edu.au (Peter N Lewis)
To:        comp.protocols.tcp-ip
Subject:   Re: getting checksums for free

In article <id.B9OY.E1K@ferranti.com>, peter@ferranti.com (peter da silva)
wrote:
> 
> In article <1993Mar23.002359.2090@sics.se> craig@sics.se (Craig Partridge) writes:
> > (I.e. replace the old "copy from user to kernel space" routine with "copy
> > from user to kernel space and do a checksum while you're at it" routine).
> 
> That's if you're doing that extra copy. High speed systems are going to avoid
> it, by doing stuff like marking the page with the buffer in it copy-on-write
> and then DMA-ing right from user space.

Hmmm, but in that case, wouldn't the reverse be true?  You need to
calculate the checksum anyway, so you get the copy for free (no, I suppose
the copy requires a further memory write, so the checksum would be faster
than checksum+copy, but probably not by much).
   Peter.

_______________________________________________________________________
Peter N Lewis <peter@cujo.curtin.edu.au>             Ph: +61 9 368 2055

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Mar 1993 01:44:03 GMT
From:      peter@cujo.curtin.edu.au (Peter N Lewis)
To:        comp.protocols.tcp-ip
Subject:   Re: something about 'talk'...

In article <1993Mar25.193237.18163@tolten.puc.cl>, apfel@tolten.puc.cl
(Andres Fernandez-Leon) wrote:

> Who can say me where can i find information about 'talk'???
> How it works, at ports level... in a rfc maybe?

From the various source codes around (does anyone know where there is
source code to otalk?).  There is no rfc on it.  There isn't even any good
protocol description as far as I know, probably because the protocol (esp
otalk!) is so brain dead (hey, lets make a protocol thats so machine
dependent it won't even talk between identical machines! I've had cases
where talk won't even work locally!).  I'm about to go thru and write
something up, if I get anywhere, I'll post it.
   Peter.

_______________________________________________________________________
Peter N Lewis <peter@cujo.curtin.edu.au>             Ph: +61 9 368 2055

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Mar 1993 04:48:09 GMT
From:      br.pct@RLG.Stanford.EDU (Peter C. Tam)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.sys.ibm.hardware,comp.periphs
Subject:   Z8530 SCC PC/AT card programmable by KA9Q

  I am looking for companies that offer  Z8530 SCC card for IBM PC/AT or 
Compatible that can be used with KA9Q AX.25..
  Thanks for any INFO in advance....

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Mar 1993 09:00:08 GMT
From:      dave@com15.NoSubdomain.NoDomain (Dave Stafford)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In article <00969FDC.FD4557C0.9100@dcv4kd.phs.com>, holdrege@dcv4kd.phs.com (Urban Surfer) writes:
|> PSI, Alternet and others own huge blocks of class B addresses. It is not hard
|> to get a class B address from them. Just sign up for their service, tell them 
|> you have hundreds of nodes, and in a few days, you get your class B address. 
|> No questions asked.
|> 
|> Matt Holdrege		holdrege@dcv4kd.phs.com


No wonder there's a shortage of addresses. You really only need a class B
address if you have either an awful lot of hosts on a lot of local nets,
or if you have lots of hosts on different sites.

Too many class B addresses are given out when a block of class C addresses
would do.
 	  
Dave 

---------------------------------------------------------------------
Dave Stafford                                    Tel: (31) 1719 84437
Cray Systems Ltd                                 Fax: (31) 1719 85426
European Space Research & Technology Centre
Noordwijk,                                         Opinions:  My OWN!
Holland                                  Email: dstaffor@estec.esa.nl
---------------------------------------------------------------------

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 93 12:02:30 GMT
From:      sandiesg@eu.net (Graeme Sandieson)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.lang.misc,comp.unix.questions
Subject:   Ethernet Network Simluation Tools

I am looking for an application or simluation language to allow a model
to be created for an ethernet lan and its producing/consuming processes.

I need to know anything at all on this subject.


Can anyone help ?



======================================================================

Graeme Sandieson, Nomura Research Institute, London, UK

E-mail :	Graeme.Sandieson@nomura.co.uk

=====================================================================

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 93 09:54:48 +0200
From:      wvb@sunvax.sun.ac.za
To:        comp.protocols.tcp-ip
Subject:   Drivers for Intel iSBX586 Ethernet

I am looking at a project that involves development on
a PC compatible Multibus I board (The iSBC 386/SX board
from Intel) which has a SBX connector onto which plugs
the Ethernet controller (a SBX586 Ethernet Data link
controller from Intel).  I am looking for any driver
for this board that will make FTP's TCP/IP work for
this 386 - packet, NDIS, ODI.  From the data books it
seems that Intel only supplies their Open network 
(the iNet 960 interface).

Has anyone done anything like this with the SBC386?
I would appreciate any pointers.

Thanks


-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Mar 1993 16:08:43 GMT
From:      brian@dxcern.cern.ch (Brian Carpenter   CERN-CN)
To:        comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: IP over ATM

In <HOFFMAN.93Mar18095158@tesuji.cmf.nrl.navy.mil> hoffman@cmf.nrl.navy.mil (Eric Hoffman) writes:


>what useful role does the IP header have when travelling through a 
>single ATM network?

None. That's why I proposed TULIP a while back (TCP and UDP over
Lightweight IP), but nobody took the bait. On a VC between two hosts,
you only need to retain the PROTOCOL field of the IP header.
All the rest of the IP header is redundant. No need to invent a new
transport protocol; TCP and UDP are fine. (TCP with extended windows,
if needed.)

Regards,
	Brian Carpenter CERN, brian@dxcern.cern.ch
			voice +41 22 767 4967, fax +41 22 767 7155

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Mar 1993 17:42:53 GMT
From:      tim@unipalm.co.uk (Tim Goodwin)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addr

hwdub@chevron.com (Dub Dublin) writes:

>...                                                 The IETF botched a
>call when they decided the address class boundaries.  There are plenty
>of addresses, it's just hard to get them.

Not the IETF.  RFC 997 was published in March 1987; according to Comer
the IETF came into existence in the summer of 1989.

And supernetting (RFC 1338) more or less abolishes those boundaries.

>...
>The reason people are eating up class C's for one or two machines is
>really even simpler:  The NIC won't assign a domain name until you have
>an IP number assignment.  ...

Are you sure?  I can't see any mention of this in domain-template.txt.

Tim.

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Mar 1993 17:59:00 +0000
From:      leo@elmail.co.uk ("E.J.Leoni-Smith")
To:        comp.protocols.tcp-ip
Subject:   Application gateways and other possibilities.


This posting is a request for information. Please respond by E-mail if at all 
possible as the news feed to Europe is unreliable at the moment.


Background situation
=====================

An international corporation has 'islands' of TCP/IP networks, more
or less autonomous, most of which are configured with illegal IP
addresses. 

They wish to connect to the Internet more widely than at present
(currently some of the 'islands' have legal class B network addresses
and have low bandwidth feeds to te Internet).

Because the islands are quasi autonomous, most of them would need a 
class B network of their own. The company has been refused allocation
of any further class B networks.

In addition the reconfiguration of their equipment would be massive, and
they cannot impose a network policy on the 'islands'.

So they are looking to give these 'illegal' IP addresses some means to access
the Internet.

What is needed is PRACTICAL solutions.

As I see it there are three possible ways to solve (partially) their
problems. I would welcome any discussion on the technical, and
(Internet) political implications of these.

Solution I
==========

Buuild a private Internet, and somehow configure the routers that 
interfcae to the outside (public) internet to direct packets that
are destined for illegal internal addresses to those internal 
machines. The effect would be to mask the duplicate networks in the
public internet from access by machines within the private network.

This raises the following questions

-  IS this techically feasible - can one configure
   routers to select between known duplicate networks?

-  Are there any known allocated, but unused and 'never-to-be-accessed'
   networks that could be used internally by this organization.

Solution II
===========

Wait for the Internet extended addressing scheme to materialise.
Beyond knowing that this is under discussion, I have little
knowledge of how this works. One question I would defintely
like answered by the IP gurus, is

-  Will it be possible to - say - that this company's network 
   (effectively a mixture of class 'A' 'B' and 'C' nets) could
   be 'legalized' by adding some extra address bits where it 
   interfaces to the public network. That is internally they would
   keep their addresses, but externally these would be mapped to 
   a super class 'A' sized net?

-  And another is - what is the current state of the extended adress
   proposals, and more to the point, when will Cisco, wellfleet, and the
   computer manufacturers have stable systems to support it? 

     Answers to the nearest quarter :-)

Solution III
============

The solution that they have been considering, is to build an 'application
gateway' - essentially I concieve of this as a standard computer equipped
with twin network interfaces spanning the private and public networks.

This machine would alllow internal nodes to connect through to the Inetrnet
by maintaining a pair of sessions - one to each end of the total link.
Neither side would be aware of the other at IP lavel - only at application
level, so that in the case of a simple protocol like Telnet, a session
would be achieved by first telneting over the local link to the gateway
and then invoking a second sessiom from there to the remote node.

This is obviously simple at the Telnet level (or is it? how does one stop
such a machine acting as a router?) and other character based apps
like ping, finger rwho etc would be no problem, but in the case of ftp
it seems that a special daemon would be needed to handle the data channel,
and transfer data between the incoming socket and the outgoing socket.

And they also want to run X-terminals throgh this gateway.....

My question on this - is such a gateawy feasible?

What are the problems associated with implementing it?

Does anything like this exist? Money is not a serious problem with
this customer :-)

I would welcome any information that anyone on the 'net can offer: 
I believe that upwards of a dozen large international corporations 
have similar problems, and there may well be 'gold in them thar hills'
for anyone who has such a beast.

Please send feedback to

E J Leoni-Smith
ElectricMail Ltd
Orwell House
Cowley Road
Cambridge CB4 4WY

+44 223 420193
+44 223 420195 (fax)

leo@elmail.co.uk

*********************************************************************
*Any opinions expressed are most definitely those of my employer :-)*
*********************************************************************

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 1993 19:21:25 GMT
From:      czmax@cats.ucsc.edu (Max C. Pritikin)
To:        comp.protocols.tcp-ip
Subject:   RFC 1278, documentation


	Summary said it all.  I am looking for the RFC 1278 specifications.

If anybody can point me in the correct direction for this please mail me
ASAP.

	thanks in advance,

	-Max Pritikin
	czmax@cats.ucsc.edu

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 93 20:02:46 GMT
From:      hwdub@chevron.com (Dub Dublin,HOU281 2305,CTN-596-3199,)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addr

In article 22724@unipalm.co.uk, tim@unipalm.co.uk (Tim Goodwin) writes:

>Not the IETF.  RFC 997 was published in March 1987; according to Comer
>the IETF came into existence in the summer of 1989.
>
>And supernetting (RFC 1338) more or less abolishes those boundaries.

But these boundaries ARE still used to determine what is handed out,
which was my point.>

>>The reason people are eating up class C's for one or two machines is
>>really even simpler:  The NIC won't assign a domain name until you have
>>an IP number assignment.  ...
>
>Are you sure?  I can't see any mention of this in domain-template.txt.

Mea culpa, and thanks to those who pointed out the my mistake.  What
the domain template actually says is (emphasis mine on the part I
missed):

   * If you are applying for a domain and a network number assignment
   simultaneously AND A HOST ON YOUR PROPOSED NETWORK WILL BE USED
   AS A SERVER FOR THE DOMAIN, you must wait until you receive your
   network number assigment and have given the server(s) a netaddress
   before sending in the domain application.  Sending in the domain
   application without complete information in Sections 7 and 8 of
   this template will result in the delay of the domain registration.


----------------------------------------------------------------
Dub Dublin                      |          "Everything
hwdub@cyberia.hou281.chevron.com|               is
Chevron Information Technology  |             deeply
(713) 596-3199 (work)           |         intertwingled."
2811 Hayes Road, Room 2305      |
Houston, Texas  77082-6696      | - Ted Nelson, in Computer Lib
----------------------------------------------------------------

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 1993 21:56:04 GMT
From:      robert@cpuserver.acsc.com (Robert Grant)
To:        comp.protocols.tcp-ip
Subject:   Sockets and XDR

Hi,

I'm new to this group and have a basic question.

I have an application that uses sockets to communicate over a
network and I would like to make it fit into a heterogeneous
environment. I would anticipate that I would XDR to standardize
the protocol data, but what I don't yet understand is how to
attach XDR to my socket stuff. It seems as though you have
to attach a XDR_ENCODE/DECODE handlers to two different file
descriptors, but my sockets are two-way, on one file descriptor
So what do I do?

Also, my sockets are non-blocking, will this cause a problem
for XDR routines?

Thanks for any help.

Robert.

robert@acsc.com

P.S. If this should go to a different news group, could someone
let me know? Thanks.

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Mar 1993 23:13:32 GMT
From:      guyd@austin.ibm.com (Guy Dawson)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet


In article <1993Mar24.212947.14711@iplmail.orl.mmc.com>, ronaldc@iplmail.orl.mmc.com (Ronald Conkling) writes:
>   I'm new to this news group and maybe this in in a faq, but I'm trying to
> understand Ethernet and it relationship to tcp-ip and how to get 100% reliability
> of transmissions, if that's possible.  Any help is appreciated.
> 

At what level are you looking for 100% reliability?

At the ethernet level - not possible
At the TCP level - that's what it's there for!

>     Thanks Ron
> 

Guy
-- 
-- -----------------------------------------------------------------------------
Guy Dawson - Hoskyns Group Plc.
        guyd@hoskyns.co.uk  Tel Hoskyns UK     -  71 251 2128
        guyd@austin.ibm.com Tel IBM Austin USA - 512 838 3377

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Mar 1993 23:31:50 GMT
From:      deraadt@fsa.ca (Theo de Raadt)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In article <C3zJqv.DAD@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
> A lot of sites have multiple Class B addresses and don't need them
> and those are actually even more valuable than the Class As.  To get a
> Class B in the modern day you have to have the most amasing
> justification.  In the old days, it was "ask and ye shall receive".  A
> major "Class B address reclamation effort" by the NIC is needed to
> revoke Class Bs from sites that have more than 1 of them.  That alone
> would help _tremendously_.

If you are a small group that is just about to allocate some
addresses, you may consider what I did. I knew that a class C was not
enough, so I asked for a block of 16 of them. I insisted that they be
aligned with a netmask of 0xfffff000.

We got the address range 192.197.96-111.X. 96 = 0x60, 111 = 0x6f --
the high nybble stays the same.

Future routing protocols will be able to insert one routing entry for
these kind of addresses, so these are likely to be cheaper than 16
randomly scattered networks.

Unfortunately, it seemed to me that not all the groups engaged in
giving out networks knew that this would be good idea. I suspect there
are still many class C groups being sent out that aren't allocated in
the above way.
 <tdr.
--

This space not left unintentionally unblank.		deraadt@fsa.ca

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 93 09:56:35
From:      fkittred@spchp13.BBN.COM (Fletcher Kittredge)
To:        comp.protocols.tcp-ip
Subject:   Re: Sockets and XDR

In article <1ovu5k$7oi@acsc.com> robert@cpuserver.acsc.com (Robert Grant) writes:

>I have an application that uses sockets to communicate over a
>network and I would like to make it fit into a heterogeneous
>environment. I would anticipate that I would XDR to standardize
>the protocol data, but what I don't yet understand is how to
>attach XDR to my socket stuff. It seems as though you have
>to attach a XDR_ENCODE/DECODE handlers to two different file
>descriptors, but my sockets are two-way, on one file descriptor
>So what do I do?

Its easy. I haven't done this for about 4 years, and I don't have
access to the source any more, so take this with a moderate grain of
salt.  If you have a well designed system, then your non-blocking
sockets read/writes are surrounded by functions you wrote to handle
buffering and asynchronous I/O.  XDR gives you the ability to convert
areas of memory.  In your write function, use the XDR memory encode
function to encode the data before you send it.  In your read
function, use XDR memory function to decode the buffer after it is
read but before it is returned to the user.

You will want to design this so as to be able to replace the XDR stuff
with whatever DCE, OLE, CORBA, etc. offer.  Not that I am saying you
ever will, but the ability to replace should be there.

>Also, my sockets are non-blocking, will this cause a problem
>for XDR routines?

No.

regards,
fletcher
--
/* Fletcher Kittredge
 * BBN Software Products
 * 150 CambridgePark Dr,  Cambridge, MA. 02140
 * 617-USE-FINK  /  fkittred@bbn.com  /  fkittred@das.harvard.edu
 */

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 93 12:49:58 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip
Subject:   Re: getting checksums for free

craig@sics.se (Craig Partridge) writes:
> I'd like to back up my comment about checksums coming for free.

	I'd like to back up my comment about checksums *not*
coming for free.
	Now, first, I want to state up front that I agree
that combining checksums and copies is a big win.  I just want
to try to convince you that avoiding the checksum altogether,
when reasonable, is a still bigger win.  
	I earlier stated that I didn't want to post the
checksum-and-copy numbers I had because they were preliminary.
Well, I have since carefully reimplemented the MIPS
checksum+copy routine in assembly language, with lots of loop
unrolling and related goodies, using Peter Desnoyers' very
clever three-instruction algorithm, and now I'm willing to post
numbers.

craig@sics.se (Craig Partridge) posted some fascinating numbers:
> 
>    Machine             bcopy   bcopy&cksum     cost of adding cksum
>    --------------------------------------------------------
>    HP9000/370          122     144             18%
>    Sparcstation1       164     177             8%
>    Sparcstation2       109     109             0%
>    HP9000/720          54      54              0%
>
> Times are in nanoseconds per byte to transfer, using bcopy and then
> bcopy combined with the checksum adds.  Note that on faster RISCs, the
> incremental cost of the checksum is 0.  (If I got any of this data
> wrong, blame me, not Van).

The magnitude of the bcopy numbers implies that either these
numbers are for copies either from uncached data or to
uncachable memory (e.g., a device).  That makes sense, since Van
Jacobson's implementation is able to copy to directly from user
space to his buffer-heavy special interface.  Things are a
little different, though, for more normal workstations using
either more conventional software or DMA-based interfaces. In
that case, one sees copies between user and kernel buffers. The
sum-and-copy into user space would involve a piece of
as-yet-uncached memory.  However, the copy out of user space is
usually a cache-to-cache transaction.  That said, here are my
numbers, also in ns/byte, for a DECstation 5000/200:

		Kernel->User	User->Kernel 	Kernel<->User
		"Incoming"	"Outgoing"	Combined
----------------------------------------------------------------
bcopy		 79		 24		103
cksum		 84		 44		128
copy'n'cksum	104		 56		160

cost of						
adding cksum	32%		133% (!!)	55%

The "Combined" column is just the result of summing the incoming and
outgoing columns.  32% is a definite loss, but 55%, let alone
133%, is a different story.  Checksum avoidance is a clear
performance win for this machine, anyway, and probably anything
else without a carry bit.

	So what about machines with carry bits?  I don't know
what the numbers are there, but I suspect that even there they
aren't zero.  In particular, it is clear that if a cache can
keep up in bandwidth with its processor, and even now most
processor caches can, there must be some degradation due to
sticking those 'addx' instructions into the instruction stream.

	The new Alpha machines have an interesting architectural
feature which threatens to make the "Incoming" column look more
like the "Outgoing" column: they can DMA directly into into the
second-level cache.

ggm@brolga.cc.uq.oz.au (George Michaelson) writes:
> Please ... supply .o files for binary-only sites
Our implementation of checksum elimination (in both Ultrix 4.2a
binary and source-patch form) is available for anonymous ftp from

ucsd.edu:/pub/csl/fastnet/fastnet.tar.Z

The implementation of Peter Desnoyer's three-instruction
checksum will appear in the same place at some later date.

						Jon

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 93 16:10:34 GMT
From:      mbt@ESD.3Com.COM (Brad Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: 3com

CANTERO@EVALUN11.BITNET writes:

>hi :-)
 
>  Know anyone e-mail for get info of product 3com ?

you can send email to "info@3com.com" and get a response from there. since
our Internet connection is through BARRNET we don't typically do business
over the Internet per say but we'll try and get youn in contact with the
correct people.
--
v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v
Brad Turner | 5400 Bayfront Plaza  | Marketing Engineer   | (408) 764-5261
3Com Corp.  | Santa Clara CA, 95052| mbt@NSD.3Com.Com     | (408) 764-5002 fax

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Mar 1993 18:06:46 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   copy/cksum in-cache numbers

 
John Kaye posted a note that pointed out that the numbers I cited from
Van Jacobson for checksum + bcopy costs were for the non-cache case.
That's right -- it is because the numbers for cache-to-cache transactions
though sometimes less good, don't give wildly different results for
current systems.  But here are the numbers for cache-to-cache:
 
   Machine             bcopy   bcopy&cksum     cost of adding cksum
   --------------------------------------------------------
   HP9000/370          68      97              43%
   Sparcstation1       94      108             15%
   Sparcstation2       42      49              15%
   HP9000/720          20      20              0%

Again, courtesy of Van Jacobson and I take all blame for any inaccuracies
or mis-representation of the numbers.

Craig
craig@bbn.com

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 1993 19:18:52 GMT
From:      spp@zabriskie.berkeley.edu (Steve Pope)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Re: Are hosts required to return ICMP Dest Unreachable Bad Port responses?

earle@isolar.Tujunga.CA.US (Greg Earle) writes:

> If a host receives a UDP packet which is addressed to a 
> non-existant (on the host machine) port, is it required to return 
> an ICMP Dest Unreachable Bad Port response?  

The wording of RFC792 does not require this.

> I noticed that Macintoshes running MacTCP 1.1 and 1.1.1 do not 
> return these, so, for example, things like "traceroute" to a 
> Macintosh will fail, even if it is ping-able [...]

Well, I suppose if "traceroute" et. al. are mandated/recommended
for the hosts in question, since they depend on the "dest unreachable"
control message, then that answers your question for you...

Steve

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 93 22:50:53 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Re: Are hosts required to return ICMP Dest Unreachable Bad Port responses?

In article <1ovvcf$fs8@isolar.Tujunga.CA.US> earle@isolar.Tujunga.CA.US (Greg Earle) writes:
>If a host receives a UDP packet which is addressed to a non-existant (on the
>host machine) port, is it required to return an ICMP Dest Unreachable Bad Port
>response?  (You can RTFRFC if you like; quote chapter & verse please.)

RFC-1122 (Host Requirements) states:

    A host SHOULD generate Destination Unreachable messages with code:

	2    (Protocol Unreachable), when the designated transport
	     protocol is not supported; or

	3    (Port Unreachable), when the designated transport
	     protocol (e.g., UDP) is unable to demultiplex the
	     datagram but has no protocol mechanism to inform the
	     sender.

(i.e recommended, but not required)

Art

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Mar 1993 23:37:50 GMT
From:      keithr@sco.COM (Keith Reynolds)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and gigabit networking - are we fooling ourselves?


I once encountered a situation where packets were getting
corrupted in a way that was not detected by the TCP checksum: a
value of 0x0000 would occasionally get replaced by 0xffff.
Because TCP uses a 16-bit 1's complement sum, the checksum would
match, but the file that was being copied would come out wrong.
It turned out to be a problem with the ethernet controller, so
the packet passed the ethernet CRC and was then corrupted.

I point this out to show that no amount of checksumming can be
perfect.  The TCP checksum provides reasonable assurance that the
data has not been corrupted, but not a guarantee.  Given this, I
think it's okay to forego the TCP checksum in some cases if you
already have such an assurance from the medium, as with ethernet.
However, I don't think it's the place for the vendor to decide
what ``reasonable'' means.  The nature of the ``local'' network
(number of bridges, types of connection between them, etc) and
the nature of the data being sent should be taken into
consideration when deciding whether to perform TCP checksumming,
and there's no way the TCP code can know those things.  It's
essential that the system administrator be able to turn the
feature on and off on at least a per-interface basis.

-- 
Keith Reynolds, Software Engineer, The Santa Cruz Operation, Inc.
keithr@sco.COM or uunet!sco!keithr


-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 1993 01:28:30 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Re: Are hosts required to return ICMP Dest Unreachable Bad Port responses?

In article <1p29as$22e@agate.berkeley.edu> spp@zabriskie.berkeley.edu (Steve Pope) writes:
>The wording of RFC792 does not require this.

RFC 1122, section 4.1.3.1 does, sort of.  Sending an ICMP Port Unreachable
message is a recommended ("SHOULD") item.

-- 
Stephen Trier                      "It is proposed to reduce the effective
Network software type               data rate further by replacing the
Case Western Reserve University     tanks with shuttle launch vehicles."
trier@ins.cwru.edu                        - V. Cerf, RFC 1217

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Mar 1993 02:40:23 GMT
From:      assela@marcus.its.rpi.edu (A. Andre Asselin)
To:        comp.protocols.tcp-ip
Subject:   Re: copy/cksum in-cache numbers

craig@sics.se (Craig Partridge) writes:
>John Kaye posted a note that pointed out that the numbers I cited from
>Van Jacobson for checksum + bcopy costs were for the non-cache case.

Craig,
   Are Van Jacobson's results publicly available somewhere?  Over the
Internet, in a journal, etc.?  Thanks...
        - Andre Asselin  (assela@rpi.edu)

-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 93 05:31:43 GMT
From:      bb31351@bingsuns.cc.binghamton.edu (Rakesh Shetty)
To:        comp.protocols.tcp-ip
Subject:   ifconfig and UDP broadcast examples




Hi netters,

I came across a few articles on broadcast using sockets on UDP in this group.
I have a few doubts in this regard and any clarifications would
be very helpful.

Everything below is with ref. to SUN OS:
1.From what I understand from the man page of ifconfig for 
  each network interface (physical interface I assume ?) one 
  can   associate  different internet addresses and the same
  network interface can have more than 1 internet addr. 
  possibly associated with different address families.

2. Regarding a down interface , the system will not attempt 
   to transmit messages thru that interface. It also says that
   "if possible " the interface will be reset to disable 
   reception as well. What exactly does this mean.

3. In response to : 
   % ifconfig -a
   No ethernet interfaces show up or am I wrong in assuming that
   ethernet interfaces are of the form ie1,ien,..
   I know this is a ethernet setup we have here.
   Also what exactly is the loopback interface used for. Is it for monitoring
   the hosts own data being transmitted.


4. Now coming to actual questions on UDP broadcast:
   
   I was going thru the example in the advanced socket based IPC
   tutorial in the Network programming guide.
   
   a. The Internet domain supports short hand notation for 
      broadcast on a local area network, the addr. INADDR_BROADCAST
      defined  netinet/in.h . Is this the dest. addr parameter in
      the sendto(....)  call.

   b. Also in the structure "struct ifreq" the example refers to
      a "  ifr_broadaddr  " field which is listed under the 
      structure nor is it #defined. Basically what I want to know
      is that if the flag is IFF_BROADCAST i.e. broadcast connection
      how is thye dest. determined.


I guess the best thing would be a source of more examples. Any 
pointers in this direction would be a great help.

Thanx in advance,
Rakesh
e-mail:bb31351@bingsuns.cc.binghamton.edu
       rshetty@cs.binghamton.edu

-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 1993 09:02:56 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Application gateways and other possibilities.

In article <E24EB32B018BC022@elmail.co.uk> leo@elmail.co.uk
("E.J.Leoni-Smith") writes: 
    
    Because the islands are quasi autonomous, most of them would need a 
    class B network of their own. The company has been refused allocation
    of any further class B networks.
    
They should get blocks of class C networks.


-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Mar 1993 09:34:40 GMT
From:      bjl@nanna.research.ptt.nl (Ben Lippolt)
To:        comp.os.linux,comp.protocols.tcp-ip
Subject:   Problem with slip (KA9Q).

Hi,

I need some help with SLIP.

I'm trying to connect my Linux home-machine to one of the Suns at work
via slip and I'm running into some problems. Maybe the problem is caused
by the way I have to log into machine at work. 

- First I have to call a defender system which then calls me back.
- As soon as I establish a connection I'm logged into a DEC terminal-server 
  which only speaks LAT, so I have to connect to a lattelnet daemon on one
  of our Ultrix systems.
- From there I connect to the Sun (so I don't log in via one of the serial
  lines; usually my tty is something like /dev/ttyp0).

I've installed cslip-2.6 on the Sun (SunOS 4.1.3) and use KA9Q (v12) on my
Linux box (which still runs 98.3).

When I log in (9600 baud via kermit) on the Sun with my slip account I 
see the start-up message from cslip. I then return to my Linux system and 
start "net". I then try to telnet to the Sun but nothing happens. On one try
I have seen the login prompt of the Sun, but nothing happened after that.

I can think of several possibilities:

1. My setup is wrong. [I've included several of the most important
     configuration files below.]
2. I can't run slip through a DEC terminal-server or over LAT.
3. My Linux version is way out of date [wouldn't surpise me :-). I haven't
     upgraded since november.]
4. There is a bug in the Sun pty driver. [Last year I tried to connect
     a PC with PC-NFS the same way. I had the same problem (could connect
     a few times, but lost connection after about one minute) but when I
     hooked up the PC to one of the serial ports I had no problem. That
     was with SunOS 4.1.1 and we suspected a bug in the pty-driver.]

Below I've included a log-file of what happens during sliplogin on the Sun
plus some configuration files.

Any tips or solutions are welcome.

Thanks

Ben Lippolt.
--------
Setup (at home): LInux v98.3 on a 486/33
                 KA9Q v12 (tsx-11:binaries/usr.bin/ka9qbin.12.tar.Z, Mar 13)
                 hostname = benslip,  IP-address = 139.63.244.185
      (at work): SunOS 4.1.3 on a SparcStation-2 
                 cslip v2.6
                 hostname = nanna,  IP-address = 139.63.232.171
============= SUN: begin of log (from /etc/slip.login) ========
============= I've included some extra commands, like netstat
============= to get extra information
|| $ stty crtscts 
|| $ /etc/ifconfig.slip sl0 nanna benslip netmask 0xfffffc00 
|| $ route add host benslip nanna 0 
|| add host benslip: gateway nanna: File exists
|| $ /etc/ifconfig.slip sl0 
|| sl0: flags=51<UP,POINTOPOINT,RUNNING>
|| 	inet 139.63.232.171 --> 139.63.244.185 netmask fffffc00 
|| $ netstat -r 
|| Routing tables
|| Destination       Gateway       Flags    Refcnt Use     Interface
|| benslip           nanna         UH       0      0       sl0
|| localhost         localhost     UH       3      267     lo0
|| dnllan1           nanna         U        24     99488   le0
|| default           lsdm01-1      UG       7      9336    le0
|| $ netstat -rs 
|| routing:
|| 	0 bad routing redirects
|| 	0 dynamically created routes
|| 	0 new gateways due to redirects
|| 	0 destinations found unreachable
|| 	330 uses of a wildcard route
|| $ netstat -I sl0 
|| Name  Mtu  Net/Dest  Address   Ipkts  Ierrs Opkts  Oerrs Collis Queue 
|| sl0   552  benslip   nanna     29      0    27      0    0      0     
|| $ /etc/ifconfig.slip sl0 link1 
|| $ /etc/slip/sun4-sunos4.1.1/bin/slstats 
||       in   pack   comp uncomp    err |      out   pack   comp uncomp     ip
||        0     29      0      0      0 |      517     33      0      0     33
||        0      0      0      0      0 |        0      0      0      0      0
||        0      0      0      0      0 |        0      0      0      0      0
===================== end of log ========================

===================== SUN: /etc/slip.hosts ========================
# @(#) $Header: slip.hosts,v 1.2 92/04/02 02:15:31 leres Exp $ (LBL)
#
# name     local-addr      remote-addr     mask
#
benslip	   `hostname`	   benslip         0xfffffc00 auto-comp
================= end of /etc/slip.hosts =====================

================== Linux: startup.net ========================
hostname benslip
ip address [139.63.244.185]
attach asy 0 /dev/ttys4 cslip sl0 2048 1500 9600
route add default sl0
ip ttl 16
tcp mss 64
tcp window 256
start finger
start telnet
================== end of startup.net ========================

================== Linux: domain.txt ========================
benslip.   IN A 139.63.244.185
nanna.     IN A 139.63.232.171
================== end of domain.txt ========================

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 1993 18:24:17 +0930
From:      hart@flash.pax.tpa.com.au (Leigh M Hart)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Broadcast Examples

I've got some code lying around somewhere that's a file transfer protocol
(server/client) written on top of UDP.

It's not the cleanest code, but it's not a bad example use of UDP either.

Bit of a CPU hog tho ;]

Leigh
-- 
Leigh M Hart                     _-_|\
C/- PO Box 758                  /     \                     hart@pax.tpa.com.au
North Adelaide 5006             \_.-* /
AUSTRALIA                            v                     Work: +61-8-267-5966

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Mar 1993 19:07:29 GMT
From:      schlege@lips2.ecn.purdue.edu (Kevin L Schlegelmilch)
To:        comp.protocols.tcp-ip
Subject:   TCP vs. UDP


  For a UNIX process, which protocol (TCP or UDP) can the process
carry on sessions with the greatest number of peer processes?




-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Mar 1993 23:32:33 GMT
From:      sss@scammell.ecos.tne.oz.au (Steve Silver)
To:        comp.dcom.modems,comp.sys.novell,comp.protocols.tcp-ip
Subject:   SPX/IPX and TCP/IP Modem

To anyone that can be of assistance.

Is there a modem on the market that can support TCP/IP and SPX/IPX ?

Specifically, a modem which:

-    has a direct ethernet connection (AUI or coax)
-    can support ODI or packet drivers
-    supports SPX/IPX (Novell)
-    supports TCP/IP
-    speed upto or beyond 14.4KBps compressed
-    Hayes compatiable

One which I have found but does not support TCP/IP directly from the modem
is produced by SHIVA CORPORATION in the USA.

This modem supports ODI (ie lsl.com, ipxodi.com) but not TCP/IP (ie tcpip.exe).

If anyone can assist please reply to Steve Silver (sss@scammell.ecos.tne.oz.au).

-- 
Steve Silver         sss@scammell.ecos.tne.oz.au

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Mar 1993 13:02:31 GMT
From:      ruud@prl.philips.nl (Ruud Hendricksen)
To:        comp.protocols.tcp-ip
Subject:   HELP WANTED on IP-options.

So far so good, but when I tried to fill "optval" and "optlen", I got
stuck (Error: Invalid argument).

Can anyone help me with some sample-code of how to exactly use the
"setsockopt" call ?
   
Please reply direct, via e-mail.
	Thanks in advance. - Ruud.

==========================================================================
    Ruud Hendricksen                   e-mail: ruud@prl.philips.nl
	(A virgo in distress)  
==========================================================================

-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Mar 93 14:35:49 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Drivers for Intel iSBX586 Ethernet

In article <1993Mar26.095449.5723@sunvax.sun.ac.za> wvb@sunvax.sun.ac.za writes:

   I am looking at a project that involves development on
   a PC compatible Multibus I board (The iSBC 386/SX board
   from Intel) which has a SBX connector onto which plugs
   the Ethernet controller (a SBX586 Ethernet Data link
   controller from Intel).  I am looking for any driver
   for this board that will make FTP's TCP/IP work for
   this 386 - packet, NDIS, ODI.  From the data books it
   seems that Intel only supplies their Open network 
   (the iNet 960 interface).

The 82586 is very simple to interface to a system.  The memory is
shared, and an I/O port is used to tug on CA.  If the memory is
shared (no matter how CA is tugged), then you ought to be able to
port the Crynwr 82586 packet driver to this controller.  Look at
ni5210.asm or at&t.asm to see how 82586.asm gets customized for a
particular Ethernet adapter.


-- HOWTOGET.IT

		The Crynwr packet driver collection

Availability

The Crynwr packet driver collection is available by mail, by FTP, by
email, by UUCP and by modem.  The drivers are distributed in three files:
drivers.zip, which contains executables and documentation,
drivers1.zip, which contains the first half of the .ASM files, and
drivers2.zip, which contains the second half of the .ASM files.

Mail:

Columbia University distributes packet drivers on PC diskette by
postal mail.  5.25-inch 360K and 3.5" 720K diskettes are available;
please specify size.  Two diskette sets are available, and two prices
are quoted for each; the first price is for the USA, Canada, and
Mexico; the second price is for shipment to all other countries.  All
prices are in US dollars.  Prepayment by check, MasterCard, or Visa
is accepted.  If your check is not drawn on a US bank, please add $35
check-cashing fee.

  1. Binaries and documentation:        $35  /  $40
  2. Source code:                       $60  /  $68

To order by credit card, please specify MasterCard or Visa, your card
number and expiration date, and sign and date your order.  For further
information, call +1 212 854-3703, or write to:

  Kermit Distribution, Dept PD
  Columbia University Academic Information Systems
  612 West 115th Street
  New York, NY  10025

or send e-mail to kermit@columbia.edu (Internet) or KERMIT@CUVMA
(BITNET/CREN/EARN).

FTP/email:

The packet driver collection has its own directory devoted to it on
simtel20.army.mil, pd1:<msdos.pktdrvr>.  The drivers are there, along
with many free programs that use the packet drivers.

SIMTEL20 files are also available by anonymous ftp from mirror sites
OAK.Oakland.Edu (141.210.10.117), wuarchive.wustl.edu (128.252.135.4),
ftp.uu.net (137.39.1.9), nic.funet.fi (128.214.6.100), src.doc.ic.ac.uk
(146.169.3.7), nic.switch.ch (130.59.1.40), archie.au (139.130.4.6),
nctuccca.edu.tw (140.111.3.21), by e-mail through the BITNET/EARN file
servers.

Modem:

If you cannot access them via FTP or e-mail, most SIMTEL20 MSDOS
files, including the PC-Blue collection, are also available for
downloading from Detroit Download Central (313) 885-3956.  DDC
has multiple lines which support 300/1200/2400/9600/14400 bps
(103/212/V22bis/HST/V32bis/V42bis/MNP).  This is a subscription system
with an average hourly cost of 17 cents.  It is also accessable on
Telenet via PC Pursuit and on Tymnet via StarLink outdial.  New files
uploaded to SIMTEL20 are usually available on DDC within 24 hours.

CD-ROM:

Public, private or corporate institutions and libraries interested in
the SIMTEL20 MS-DOS collection in CD-ROM format bundled with library
card-catalog type access and duplication software can contact Coyote
Data, Ltd. by mail at 1142 N. Main, Rochester, MI 48307 or by FAX at
(313) 651-4071.  Others who do not need the access and duplication
software should send e-mail to: rab@cdrom.com (Robert Bruce), telephone
(800) 786-9907 or (510) 947-5996, or FAX (510) 947-1644 for details on
his CD-ROM offer.


UUCP:

The packet driver files are available from UUNET's 1-900-GOT-SRCS, in
uunet!~/systems/msdos/simtel20/pktdrvr.  Contact UUNET for more details:

UUNET Technologies, Inc.
3110 Fairview Park Drive, Suite 570
Falls Church, VA 22042
+1 703 204 8000 (voice)
+1 703 204 8001 (fax)
info@uunet.uu.net

UK UUCP:

Steve Kennedy's BBS is on +44 71 483 2454 (Telebit T2500 PEP/V32 ...)
                                                2455 (USR HST/DS+)

Files will be in /pub
there will be an anonymous uucp (nuucp) account.

System name is "marvin"

-- end of HOWTOGET.IT

-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Mar 1993 15:07:00 GMT
From:      BWWL@ibm.rz.tu-clausthal.de (Wolfgang Ley)
To:        comp.unix.wizards,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: SLIP questions..

In article <1osrdvINNgsd@gambier.rick.cs.ubc.ca>
w1y092@rick.cs.ubc.ca (Steven David Gribble) writes:
 
>Hello -
>
>I've been trying to set up a dial-up SLIP connection between a unix workstation
>and the local university.  The problem I've been experiencing is that the
>SLIP server dynamically assigns the clients' addresses, the gateway address,
>the netmask, etc. upon each connection.
>
>I need to be able to get a hold of this information and reconfigure my network
>files each time I call up.  Apparently 'BOOTP' protocol may be used to this
>effect - can anyone give me any information about how to go about using
>this protocol, or any other method to get this configuration information?
 
Hello!
 
I am using SLIP for about 2 years now without any problems. Our
terminal-server assigns the addresses dynamically. I have written a small
connect-script, which generates a new file (say 'change.net') with the new
addresss information. This file is then executed by the ka9q 'source' cmd.
 
As far as I know there is no bootp-facility (in the version i use...).
 
Bye,
  Wolfgang.
---------------------------------------------------------------------------
       Wolfgang Ley                               e-mail:
       Teichstrasse 9
W-3392 Clausthal-Zellerfeld                     BWWL@ibm.rz.tu-clausthal.de
       (Germany)                            or  BWWL@sun.rz.tu-clausthal.de
       Phone: +49 5323 82132 (voice)        or  Ley@rz.tu-clausthal.de
---------------------------------------------------------------------------

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 93 00:47:03 PST
From:      cvakg001@vmsb.is.csupomona.edu
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   need help:building a mutiplatform net

Hi, I have recently transfered to CalPoly and live in the residence halls. I my
particular hall, we have a serial link to our vax, but we are looking for more.

I have recently recieved a request on be-half of housing  to assemble a 
hall-wide network. We need to be an equal-oppertunity network provider, that is
the net needs to be equaly freindly to macs and PCs. Additiionally the 
equiptment investment for either platform needs to be of minimal cost. The 
housing office has a Mac IIci that we can dedicate as a server. The hall has a 
maximum capacity of 186 residents. We currently have a need for about 40 users,
about 20 macs (mostly compacts but with sys7.0) and about 25 pc's. We need to 
fullfill the current need and have the capability to expand to accouodate about
150 users.

(BTW, I am far from an expert in this stuff, but it seems I know more than most
around here)

My basic idea: 
Run both Phone net and thin ethernet throughout the building using the mac as a
mail and file server as well as a router between phone net and ethernet. Run 
appletalk (phase 2?) with AppleShare. 

Problems:
I don't know if this is even do able.
I don't know what is involved in using appletalk with PC's. 
I need to keep the cost down (way down). 

Questions:
Is novell a beeter solution?
Is tops a better solution?

Further Complications:
I want to use both Phonenet and Ethernet so that each Platform can use it's 
most-affordable data-link.

I am the entire labor force/ administrator/ installer.

I have to sell this to housing, for they will be paying the bill for cable, and
netware, ethernet card for the IIci, and possibly some loan-out cards.

The Pc people need to be able to afford a ethernet card.

Would like to beable to share commom files (word,excel,other).

Would like to have the capability to future expand to run tcp-ip over the lan 
while running what ever else were running for school-wide access.

I know this is asking a bunch, but as I said, this is low budget at this point,
and I can't pay for advise. Any help, real-life stories of sucessfull 
installations and any other relevant info would be apreciated.

Thanks Thanks Thanks, and once more, Thanks for and help, John
-- 
---
John Ringloff
Email: cvakg001@vmsa.is.csupomona.edu

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Mar 1993 17:08:25 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Solaris 2.1 path MTU discovery "feature"

Is there any documentation at all on the path MTU discovery feature
that seems to be part of Solaris 2.1?  (I've read RFC 1191 and am
familiar with what it does--I'm interested in Sun's implementation.)
I've been scanning man pages and header files and have found very little.

Specifically I've encountered a few problems.  First, if you send a
datagram that ends up needing to be fragmented, IP turns on the
DF (don't fragment) flag whether you like it or not.  Even if an
ICMP TooBig error is returned (with the correct next hop MTU returned
in the error) the kernel still turns on the DF flag for the next
1 or 2 datagrams that you send.  You end up with a lot of datagrams
being dropped on the floor.  Is there any way for the user process
to tell IP *not* to set the DF flag?  Are there any new socket options
or ioctls related to the path MTU?

Next, what are the units of the kernel's ip_ire_pathmtu_interval
variable (that you can look at with ndd)?  The value printed is
30000.  It looks like even after the kernel gets a valid TooBig
ICMP error, with the correct next hop MTU, it times out the entry
far too quickly (10-15 seconds), and then turns on the DF flag
again, causing more datagrams to be dropped.

Any pointers from "anyone in the know" greatly appreciated.

	Rich Stevens  (rstevens@noao.edu)

-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Mar 1993 17:19:24 GMT
From:      simms@ux1.cso.uiuc.edu (dan simms )
To:        comp.unix.wizards,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: SLIP questions..

BWWL@ibm.rz.tu-clausthal.de (Wolfgang Ley) writes:

> 
>>Hello -
>>
>>I've been trying to set up a dial-up SLIP connection between a unix workstat
>>and the local university.  The problem I've been experiencing is that the
>>SLIP server dynamically assigns the clients' addresses, the gateway address,
>>the netmask, etc. upon each connection.
>>
>>I need to be able to get a hold of this information and reconfigure my netwo
>>files each time I call up.  Apparently 'BOOTP' protocol may be used to this
>>effect - can anyone give me any information about how to go about using
>>this protocol, or any other method to get this configuration information?
> 
BOOTP can't be used since it does an IP broadcast, and RARP coudn't be used
since it uses hardware broadcast, and modems don't have hardware addresses.
Even the RFC lists this as a shortcoming.  So ..hack away, and have fun!

-dan

-----

-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 1993 18:36:19 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.unix.wizards,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: SLIP questions..

In article <C4nusr.Eqp@ux1.cso.uiuc.edu> simms@ux1.cso.uiuc.edu (dan simms ) writes:
>BOOTP can't be used since it does an IP broadcast, ...

This is untrue.  BOOTP over SLIP works fine, as long as the SLIP server
itself includes a BOOTP server that can tell which of its SLIP connections
originated the request.

This is neither far-fetched nor theoretical.  Many people use BOOTP for
SLIP configuration every day.

The only "trick" is to ignore the hardware address fields of the BOOTP
request, and for the BOOTP server to know which SLIP connection the request
came from.  The only hardware I've used that can do this are Cisco terminal
servers, but there may be others.

If your SLIP server is a Unix box, you may have a hard time making this work
without hacking BOOTP into the SLIP driver in the kernel.

-- 
Stephen Trier                      "It is proposed to reduce the effective
Network software type               data rate further by replacing the
Case Western Reserve University     tanks with shuttle launch vehicles."
trier@ins.cwru.edu                        - V. Cerf, RFC 1217

-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 93 18:55:28 GMT
From:      exudnw@exu.ericsson.se (Dave Williams)
To:        comp.dcom.lans.misc,comp.protocols.tcp-ip
Subject:   Re: Ethernet Network Simluation Tools


In article 273@euswin.eu.net, sandiesg@eu.net (Graeme Sandieson) writes:
>I am looking for an application or simluation language to allow a model
>to be created for an ethernet lan and its producing/consuming processes.
>
>I need to know anything at all on this subject.

I used this in some work I did a few years ago.

[MacDougall87]
Simulating computer systems : techniques and tools, MacDougall, M. H.,
MIT Press, Cambriage, MA, 1987.

Has a fairly detailed model for ethernet simulation.  


Get a copy of simpack from bikini.ufl.edu - it's a general purpose queing
simulation language for UNIX.

---
= exudnw@exu.ericsson.se                                                =
= David Williams              "You can't win, you can't break even,     =
= Ericsson Network Systems     and you can't quit"                      =
= Richardson, TX 75081                                  my opinions...  =

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 93 18:56:00 GMT
From:      jms@opus1.com (Joel M-for-Vnews Snyder)
To:        comp.protocols.tcp-ip
Subject:   What are typical values for EMTU_R in IP implementations?

At a conference last week, I got involved in a debate about the maximum
allowable UDP datagram size [*].  I'd like to conduct a brief survey of IP
implementers out there.

Please send answers to me, and I'll summarize and post an answer.

What value did you chose for EMTU_R (maximum IP datagram reassembly
buffer size) and EMTU_S (hopefully, the same)?  Is this static, or
configurable?  

jms


Joel M Snyder, 1103 E Spring Street, Tucson, AZ, 85719 
Phone: 602.882.4094 (voice)  .4095 (FAX)  .4093 (data)
Internet: jms@Arizona.EDU          BITNET: jms@Arizona  
Yow!  Did something bad happen or am I in a drive-in movie??

* For those of you who haven't been paying attention, RFC 1122 only
requires that IPs support a reassembly buffer of 576 octets.  Somewhat of a
rude shock to programmers greedily eyeing UDP and IP's 16-bit length
field. 

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Mar 1993 19:07:34 GMT
From:      spenser@fudd.jsc.nasa.gov (S. Spenser Aden)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Broadcast Examples

In article <1996@alcbel.be> devdjn@space.alcbel.be writes:
>
>If you look in the Socket Based IPC section of the Network Programming Guide
>from Sun, under the heading Broadcasting and Determining Network Configuration,
>you will find an example to get you started.
>
>Good luck.
>
>P.S. The example works because I have used it.

REALLY ... hmm, I went through this about 4 weeks ago, and ended up with Sun
technical s/w support before it was resolved.  The examples, as written in the
reference you site, did *NOT* work at all.  In fact, the guy in the Solution
Center that I talked to sent me some source that did work, and it was VERY
different from what was in the docs.  When I pressed, he said "Well, there are
many inaccurate examples in the docs; that's why I keep my own personal
archive of sample code."  I was very unimpressed.

BTW, the source code in the NPG is very generic ... we found the exact same
code in the Masscomp manuals, and in another reference.  My machine is a SS2
running 4.1.2.

-Spenser
-- 
S. Spenser Aden --- Lockheed Engineering and Sciences Co. --- (713) 483-2028
NASA --- Flight Data and Evaluation Office --- Johnson Space Center, Houston
spenser@fudd.jsc.nasa.gov    (Internet) ---  Opinions herein are mine alone.
aden@vf.jsc.nasa.gov (if above bounces) ---  "Eschew obfuscation." - unknown

-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Mar 1993 20:35:47 GMT
From:      pz@modtor.uucp (Peter Ziobrzynski)
To:        comp.os.linux,comp.protocols.tcp-ip
Subject:   Re: Problem with slip (KA9Q).

The problem you have is with the DEC terminal-server and lat-telnet
gateway. The connection even if you set all the proper pass through
params on the server is not transparent. I had the same problem using UUCP. 
There was discussion of it on the Net in ultrix groups.
-- 
Peter Ziobrzynski, pz@modtor.uucp, peter@sni.ca, Toronto, Ont. Canada

-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Mar 1993 21:50:15 GMT
From:      ted@usasoc.soc.mil (Mr. Ted Nolan)
To:        comp.protocols.tcp-ip
Subject:   gated question


Hello folks,

We run gated 2.0.1.18 on our main external access machine, a Sun 4/490 running
SunOS 4.1.2

We have a direct X.25 connection to a MILNET PSN, and an ethernet connection
to our local MAN.  This gives the machine two IP addresses:

	26.27.0.80	(MILNET: Interface std0)
	137.29.95.1	(Ethernet: Interface ie0)

This machine handles and routes all our incoming internet traffic.

OK, that's the setup, now the problem:  We have a remote LAN tied into our MAN
through a SLIP connection.  The remote LAN has the IP address 192.5.132.0,
and the SLIP "network" has the number 192.26.242.0 (both are class C nets)

We want to be able to get all the way from the remote LAN to the internet
(and back), but I don't seem to be able to get the MILNET EGP servers to
recognize either the 192.5.132 net or the 192.26.242 net.  Running "traceroute"
from a number of MILNET and other internet sites shows that nobody has a
backroute to these nets.

Here's the gated configuration file I'm running.  Am I doing something wrong?

Thanks:



=======================================================================
#tracefile "gated.log" ;
#traceoptions egp config icmp update ;

interface std0 passive ;

autonomoussystem 258 ;

egp yes {
	defaultmetric 64 ;
	group maxup 2 {
		neighbor  26.2.0.65 acceptdefault ;	
		neighbor 26.3.0.246 acceptdefault ;
	} ;
} ;

rip no;
hello no;
redirect on ;

static {
	default gateway  26.19.0.16 pref 100 ;
	192.5.132.0 gateway 137.29.92.210;
	192.26.242.0 gateway 137.29.92.210;
} ;


propagate proto egp as 258 {

	proto direct {
		announce 137.29 metric 1;
	};

	proto static gateway 137.29.92.210 {
		announce 192.5.132 ;
		announce 192.26.242 ;
	};
} ;

=================================


				Thanks,

				Ted Nolan
				ted@usasoc.soc.mil

-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 1993 21:50:43 GMT
From:      banshee@cats.ucsc.edu (Wailer at the Gates of Dawn)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP vs. UDP


In <C4M54H.58t@noose.ecn.purdue.edu> schlege@lips2.ecn.purdue.edu (Kevin L Schlegelmilch) writes:
>  For a UNIX process, which protocol (TCP or UDP) can the process
>carry on sessions with the greatest number of peer processes?

UDP.  TCP is limited to the max # of sockets for your process.  UDP can have
(theoretically) an unbounded # of clients.  However the simplicity of using
TCP can outweigh UDP in many (most) cases.


-- 
The Wailer at the Gates of Dawn              | banshee@cats.UCSC.EDU       |
Just who ARE you calling a FROOFROO Head?    |                             |
DoD#0667  "Just a friend of the beast."      | banshee@ucscb.UCSC.EDU      |
2,3,5,7,13,17,19,31,61,89,107,127,521,607....| banshee@ucscb.BITNET        |

-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Mar 1993 22:30:22 GMT
From:      rich@aoa.aoa.utc.com (Rich Snow)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

> shawn@nethost1.sciatl.com (Shawn Hayes) writes:
>mike@gordian.com (Michael A. Thomas) writes:
>
>> spp@zabriskie.berkeley.edu (Steve Pope) writes:
 
>>  I wouldn't count on things staying like that. Consider the
>>not too distant day when *everything* is directly on the net,
>>managable from some super-duper SNMP client. Your printers,
>>your modems, your repeaters, your air conditioner, and your 
>>toaster ;-)
>>  254 address is going to be painfully small when every little
>>widget gets its own net address.
>
>Hopefully by that point will have a new addressing scheme in place.
>Also there would have to be some form of automatic address configuration.
>Can you imagine having to teach every person how to set up the address
>on their latest VCR/toaster/thingabob?  :>
>--

It seems as though every industry tries to reinvent the wheel when it
joins the fray. The "smart" homes which builders are coming out with
these days use different topologies than existing networks. Ostensibly
to keep the cost down, but you've got to figure somebody wants to
get their foot in the door (oops) with a proprietary technology.

As far as addressing goes, why not use arcnet. Perfect for home
use. Cheap enough for a toaster. Runs over twisted pair. Easy to
set up. Of course we could create a new class of kitchen protocols,
SNTP, SBP, NMOP, WEKP (network toaster, simple blender protocol,
network microwave oven protocol, wireless electric knife protocol...)

Heck, I'm still frustrated that audio CD players don't have an
RS-232 port so that I can catalog my disks!

-Rich
-- 
*  Rich Snow		-Adaptive-Optics-Associates,-Inc.-----------*
*  (617)864-0201	54 Cambridgepark Dr., Cambridge, MA.	    
*  rich@aoa.utc.com 	MORE IS BETTER, less_is_more.

-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 1993 01:12:43 GMT
From:      ohst@cogsci.ucsd.edu (Ronald Ohst)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.dcom.lans.ethernet,comp.dcom.lans.misc
Subject:   Netware-lite/ncsa telnet

Has anyone had any success using the Novell peer-to-peer lan, Netware-lite
with packet drivers and in conjunction with ncsa telnet?

Please send responses via email.

Thanks.
Ron
rohst@ucsd.edu

Ron Ohst				rohst@ucsd.edu,	(619) 534-2440
University of California, San Diego	Department of Cognitive Science

-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Mar 1993 01:29:53 GMT
From:      gomez@enuxha.eas.asu.edu (JL Gomez)
To:        comp.protocols.tcp-ip
Subject:   dial-up tcp-ip?

Anyone know of a manufacture who offers dial-up tcp-ip equipment?

Just want to use a PSTN line and off the shelf modems.

Plan on hooking up to a major backbone.

Will I need a CSU/DSU unit also?

Thanks!
--
gomez@enuxha.eas.asu.edu

-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Mar 1993 02:41:35 GMT
From:      dgj2y@kelvin.seas.Virginia.EDU (David Glen Jacobowitz)
To:        comp.unix.wizards,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: SLIP questions..

In article <C4nusr.Eqp@ux1.cso.uiuc.edu> simms@ux1.cso.uiuc.edu (dan simms ) writes:
>BWWL@ibm.rz.tu-clausthal.de (Wolfgang Ley) writes:
>
>> 
>>>Hello -
>>>
>>>I've been trying to set up a dial-up SLIP connection between a unix workstat
>>>and the local university.  The problem I've been experiencing is that the
>>>SLIP server dynamically assigns the clients' addresses, the gateway address,
>>>the netmask, etc. upon each connection.
>>>
>>>I need to be able to get a hold of this information and reconfigure my netwo
>>>files each time I call up.  Apparently 'BOOTP' protocol may be used to this
>>>effect - can anyone give me any information about how to go about using
>>>this protocol, or any other method to get this configuration information?
>> 
>BOOTP can't be used since it does an IP broadcast, and RARP coudn't be used
>since it uses hardware broadcast, and modems don't have hardware addresses.
>Even the RFC lists this as a shortcoming.  So ..hack away, and have fun!
>
	I don't know about you, but I use BOOTP for my dialup SLIP
links all the time. It works. The slip server makes up a SLIP address
and that is the address it continues to give to you the whole time.
BOOTP will cause the net tosend back you address. It works here at
UVa.

				dave



-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 1993 02:51:10 GMT
From:      pascoe@rocky.tntn.gtegsc.com (Dave Pascoe)
To:        comp.protocols.tcp-ip
Subject:   Problem with CSLIP-2.6

I'm having problems getting CSLIP-2.6 up and running on a
SPARCstation-2 running SunOS 4.1.1.  The SLIP driver is loaded using
modload (see recent postby brad@fcr.com to the net)).

I have tried several different SLIP clients on the PC and Macintosh
side.  I have traced the problem down to the server software but can't
figure out why it's failing.

I am logging in as a slip user whose login shell is /etc/sliplogin.
The program sliplogin runs the script slip.login which ifconfigs sl0
and sets up a route to the remote PC.

The problem is that sliplogin seems to only get to the point where it
says "starting slip login for user <username>" and then it hangs.

The CSLIP server software doesn't seem to be talking to the modem port
(/dev/ttyM0), which is a combo dial-in/dial-out port (ttyD0 for
dial-out and ttyM) for dial-in).  The modem is a Telebit Worldblazer
and the modem port runs at a constant 38400 bps with hardware
handshaking between the Unix machine and the modem.

Any ideas on why CSLIP seems to be failing to determine the correct tty?

--
Dave Pascoe
Internet: pascoe@rocky.tntn.gtegsc.com
(508) 880-2297
(617) 455-5704

-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Mar 1993 05:02:56 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP WANTED on IP-options.

Ruud Hendricksen (ruud@prl.philips.nl) wrote:
: ...
: Can anyone help me with some sample-code of how to exactly use the
: "setsockopt" call ?
: ...

Pay close attention to what gets passed by value and what gets passed
by refernece (ie what wants a pointer and what wants a value...)

Sometimes I have a hard time seeing *'s...

rick jones

-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 93 10:47:05 GMT
From:      skaamjm@ucl.ac.uk (Matthew Moore)
To:        comp.protocols.tcp-ip
Subject:   unix sort parameters for IP numbers (FAQ not found)

Apologies if this is an FAQ, but I cannot find an FAQ file...

having struggled with the Unix (AIX 3.2) sort command for half an hour,
I am unable to generate sort parameters which will sort IP numbers in
numeric order, despite using -n .
As I needed the sorted list pronto, I used other methods this time,
but would like to ask if anyone has sort parameters (or other working
method) which will produce a sorted list of IP numbers.

-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 93 11:06:18 GMT
From:      devdjn@space.alcbel.be (Dennis Newport)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Broadcast Examples

I'm not quite sure of the problems that other people seem to be having
with obtaining the broadcast address but we use the crux of what is in
NPG and it works. We

1. do the ioctl with SIOCGIFCONF to get the I/F config.

2. go through the list of ifreq structures, checking the family for AF_INET
   and doing the ioctl with SIOCGIFFLAGS

3. check the flags for IFF_BROADCAST

4. and then do the ioctl with SIOCGIFBRDADDR to get the broadcast address.

This is essentially being done in the example in the NPG.

I would be very interested to see what other solutions the Sun technical
support came up with. I wasn't aware of any other way of programmatically
getting the broadcast address other than the one I mention above.

The trouble with the solution above is that it isn't obvious and is quite
convoluted. Also, the info in the NPG is the only place that broadcasting
is described (at least in our set of Sun documentation).

---
Dennis Newport,                  email: devdjn@space.alcbel.be
Alcatel Bell Telephone,
Berkenrodelei 33,                phone: (+32) 3/829.5488
2660 Hoboken,
Belgium.


-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Mar 1993 11:52:37 GMT
From:      brian@SJF.Novell.COM (Brian Meek)
To:        comp.dcom.modems,comp.sys.novell,comp.protocols.tcp-ip
Subject:   Re: SPX/IPX and TCP/IP Modem

In article <1993Mar28.233233.14084@scammell.ecos.tne.oz.au> sss@scammell.ecos.tne.oz.au (Steve Silver) writes:
>Xref: newsun comp.dcom.modems:30493 comp.sys.novell:17519 comp.protocols.tcp-ip:16238
>Newsgroups: comp.dcom.modems,comp.sys.novell,comp.protocols.tcp-ip
>Path: newsun!ns.novell.com!alaska.et.byu.edu!news.byu.edu!hamblin.math.byu.edu!sol.ctr.columbia.edu!usc!rpi!batcomputer!munnari.oz.au!bunyip.cc.uq.oz.au!cheops!scammell!sss
>From: sss@scammell.ecos.tne.oz.au (Steve Silver)
>Subject: SPX/IPX and TCP/IP Modem
>Message-ID: <1993Mar28.233233.14084@scammell.ecos.tne.oz.au>
>Followup-To: sss@scammell.ecos.tne.oz.au
>Keywords: SPX/IPX, TCP/IP, MODEM
>Organization: Telecom Australia, Information Technology Development
>Date: Sun, 28 Mar 1993 23:32:33 GMT
>Lines: 22
>To anyone that can be of assistance.
>
>Is there a modem on the market that can support TCP/IP and SPX/IPX ?
>
>Specifically, a modem which:
>
>-    has a direct ethernet connection (AUI or coax)
>-    can support ODI or packet drivers
>-    supports SPX/IPX (Novell)
>-    supports TCP/IP
>-    speed upto or beyond 14.4KBps compressed
>-    Hayes compatiable
>
>One which I have found but does not support TCP/IP directly from the modem
>is produced by SHIVA CORPORATION in the USA.
>
>This modem supports ODI (ie lsl.com, ipxodi.com) but not TCP/IP (ie tcpip.exe).
>
>If anyone can assist please reply to Steve Silver (sss@scammell.ecos.tne.oz.au).

It's not so much the modems as what they're plugged into and what software 
is drivin' them.  The SLIP_PPP.COM ODI driver that comes with LAN WorkPlace 
for DOS v4.1 does something of the opposite...  It presently supports only 
TCPIP.EXE directly, but it can support IPXODI running over an IP Tunnel 
driver (IPTUNNEL.EXE) to a NetWare v3.11 server (using IPX over 
IPTUNNEL.LAN).

With setup, I've used several brands of high-speed modems at DTE speeds of 
up to 57,600bps.  I've just put some example configuration files on 
sjf-lwp.sjf.novell.com: ~/lwp4dos/ppp_sample/* for those who are interested. 

-- brian

-- brian


I've setup Novell's LAN WorkPlace for DOS v4.1 to use 
___________________________________________________________________________
Brian Meek                      Novell, Inc. -- Desktop Systems Group
                                Internet mail:  brian@Novell.COM

-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Mar 1993 11:54:51 GMT
From:      etxmesa@eos.ericsson.se (Michael Salmon)
To:        comp.protocols.tcp-ip
Subject:   Re: unix sort parameters for IP numbers (FAQ not found)

In article <1993Mar30.104705.29801@ucl.ac.uk>
skaamjm@ucl.ac.uk (Matthew Moore) writes:
|> Apologies if this is an FAQ, but I cannot find an FAQ file...
|> 
|> having struggled with the Unix (AIX 3.2) sort command for half an hour,
|> I am unable to generate sort parameters which will sort IP numbers in
|> numeric order, despite using -n .
|> As I needed the sorted list pronto, I used other methods this time,
|> but would like to ask if anyone has sort parameters (or other working
|> method) which will produce a sorted list of IP numbers.

If the numbers come first, as in /etc/hosts then:

 eos6c02 tmp 69 > ypcat hosts | sort -t. -n +0 -1 +1 -2 +2 -3 +3
10.11.12.12             eos9c27_2
10.11.12.14             eos8c34_2
64.0.255.254  newmach
64.0.255.255  bootunix
127.0.0.1       localhost
130.100.2.2             mailgate
130.100.2.3             erigate
130.100.10.1    eoc3 eoc_ss
130.100.10.6    eos92 torsten
130.100.10.7    eos93 lasse
130.100.10.8    eos94 snm
130.100.10.9    eos eos99 ypmaster time_master
130.100.10.11   eos90
130.100.10.12   eoamc2 amcemul2

-- 

Michael Salmon

#include	<standard.disclaimer>
#include	<witty.saying>
#include	<fancy.pseudo.graphics>

Ericsson Telecom AB
Stockholm

-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 93 12:14:11 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!

hallam@dscomsa.desy.de (Phill Hallam-Baker) writes:

>Only last month I was being flamed for saying that the major flaw of TCP/IP
>was the limited address space... 
 
>DECnet phase V anyone ?
There are several alternatives, being debated quite hotly. I'll assume
a smiley here. One *will* be adopted.

>Seriously, this problem is going to bite pretty soon, anyone who uses a
>campus switch like we do (CISCO router) ends up needing multiple class C
>addresses at the very least. If you put more than 16 or so workstations on
>the same ethernet segment they can trash it PDQ.

I hope that that doesn't imply you're using a separate class C for each
of your 16-station Ethernets. If this were done throughout, we'd run out
of numbers even more rapidly. Subnets?

To get things in perspective: the class Cs are still allocating in the
193... series. That's quite a few more to go. An important problem,
which must be (and can be) solved, but not one that's going to stop us
in the next few months.

>Thats before you start to consider toasters etc with an internet address.

There are more IP addresses available than the toaster population of the
earth :-)

Ian
-- 
Ian Phillipps, Unipalm Ltd, 216 Science Park,		Phone +44 223 420002
Milton Road, Cambridge, CB4 4WA, England.		Phax  +44 223 426868
PIPEX is a division of Unipalm Ltd. - phone 0223 424616.

-----------[000453][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Mar 1993 23:21:46 -0500
From:      "Nor Azalia Zainal" <nzainal@mango.ucs.indiana.edu>
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.unix.questions
Subject:   Questions on Unreliable Network Problems


I need to know the kinds of problems that are caused by unreliable
networks. Could anyone tell me if they know of any references on the
subject. 

	I would also appreciate it if anyone could tell me how errors
that exists on this network are handled. Is there any PD software available
that addresses and tackles errors caused by unreliable networks.

Thanks.

Azalia


-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 1993 15:06:42 GMT
From:      tonyr@hicomb.hi.com (Tony Rodriguez)
To:        comp.protocols.tcp-ip
Subject:   Offloading TCP/IP processing


Are there any successful examples of offloading some or all of the protocol
processing onto a front-end processor? I'm aware of the Interphase and Auspex
NFS accelerators which do the UDP/XDR processing for NFS requests, but am more
interested in general TCP offloading. I heard that Interlan has a board which
offloads everything below the socket layer, but don't know how it compares to a
non-offloaded system.

One obvious problem is how to connect multiple front-end processors to a
system. In order to determine which processor to send a request to, the routing
decision has to be moved up from where it is currently done in ip_output (in
BSD). What kinds of problems can this create?


-----------[000455][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 93 15:23:10 GMT
From:      smee@bristol.ac.uk (Paul Smee)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addresses!

In article <C4Hno9.Cw4@wm.estec.esa.nl> user@machine.domain writes:
>No wonder there's a shortage of addresses. You really only need a class B
>address if you have either an awful lot of hosts on a lot of local nets,
>or if you have lots of hosts on different sites.
>
>Too many class B addresses are given out when a block of class C addresses
>would do.

It's not quite that simple, owing to the haphazard way in which
addresses are assigned (i.e. in numeric order).  There is no way to
tell, by just looking at an address, where it is located
'geographically' (meaning both traditional 'geographically', and
geographically in terms of the net's topology).  Thus, the backbone
routers have got to know where every network is.

So, if you have 15 subnets, but they are all subnets of a class B
network assigned to you, the backbone boxes need only one routing entry
for you, into your class B address space -- it's then your job to route
internally between your subnets.  If, on the other hand, you had been
given 15 class C networks, which handle your needs equally well, the
backbone routers need 15 routing table entries for you -- one into each
of your class C address spaces.  Quite simply, high-speed high-volume
routers can't cope with large enough routing tables -- yet, at least.

Pending the adoption of (and changeover to) one of the 'bigger address'
proposals (which will probably be hierarchical like phone numbers, so
that the address itself implies the necessary routing info), rumor has
it that the Internet gods are going to begin assigning blocks of class
C subnets, with some geographical organization behind them.  I.e.
addresses 200.*.*.* and 201.*.*.* will be North American, 202.*.*.* and
203.*.*.* will be Europe, and so on.  (My choice of numbers may not be
exactly right, but it demonstrates the idea.)  Then the backbone
routers will only need explicit routing info for those new class Cs in
their own continent, and will know to pitch the rest across an
appropriate international link.  Pity a hierarchical arrangement wasn't
invented earlier.

-- 
Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK
 P.Smee@bristol.ac.uk - ..!uunet!uknet!bsmail!p.smee - Tel +44 272 303132

-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Mar 93 15:58:46 GMT
From:      maritza@espresso.bae.bellcore.com (Maritza Ramirez)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP WANTED on IP-options.

|> Ruud Hendricksen (ruud@prl.philips.nl) wrote:
|> : ...
|> : Can anyone help me with some sample-code of how to exactly use the
|> : "setsockopt" call ?
|> : ...
|> 

I found some examples on the client FTP source code:

				(1)
#ifdef IP_TOS
        tos = IPTOS_LOWDELAY;
        if (setsockopt(s, IPPROTO_IP, IP_TOS, (char *)&tos, sizeof(int)) < 0)
                perror("ftp: setsockopt TOS (ignored)");
#endif

                                (2)
#ifdef SO_OOBINLINE
        {
        int on = 1;

        if (setsockopt(s, SOL_SOCKET, SO_OOBINLINE, (char *)&on, sizeof(on))
                < 0 && debug) {
                        perror("ftp: setsockopt");
                }
        }
#endif /* SO_OOBINLINE */

                                (3)
#ifdef IP_TOS
        on = IPTOS_THROUGHPUT;
        if (setsockopt(data, IPPROTO_IP, IP_TOS, (char *)&on, sizeof(int)) < 0)
                perror("ftp: setsockopt TOS (ignored)");
#endif




The arguments to these calls are described on the Steven's book
(Unix Network Programming).


Question: 

	How do ip options work ? If I use x given ip option from within a 
client application, does the server application (that is going to receive
the client request) require some support of these options too ? (for example,
setting the same options as the client ?).

Maritza

-----------[000457][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Mar 1993 16:14:48 GMT
From:      hmchen@fcom.ee.ntu.edu.tw (Hung-ming Chen)
To:        comp.protocols.tcp-ip
Subject:   Re: ifconfig and UDP broadcast examples

Hi netters,

  I studied the UDP broadcast from SUN mannual. In the manual
the "rwho" program may be a good example, but it is not
completed. And I tried to find it from the ftp sites,
unfortunately, there exits no one similiar the code in the
mannual. Could someone tell me where to  find the complete
code as the SUNN manual? 

Fred Chen 3/30/93'

-----------[000458][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Mar 1993 16:31:03 GMT
From:      adykes@jpradley.jpr.com (Al Dykes)
To:        comp.protocols.tcp-ip
Subject:   Needed: name of an IP filewall product; Raptor ?


I recall seeing adds for a very secure IP firewall/gateway product
produced by a company with a name like Raptor. If this rings a bell
with anyone I'd like the name and/or phone number.  

Thanks.

Al Dykes
---------
adykes@jpr.com

-----------[000459][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 93 21:54:36
From:      drw@zermelo.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Need information on routing protocol

I once read a description of a routing protocol that extended the
currently implemented protocols in various interesting ways -- it
allowed for policy-based routing, and it handled multiply-connected
networks well.  The interesting part, though, was that when a host in
one "area" (I think) wanted to send packets to another "area", the
boundary routers would set up a route between the areas.  If some
intermediate network went down, the route would be torn down and a new
route would be set up.  So packets had to be tagged with some sort of
identification of which route they were being sent under; the packets
were sort of datagrams being sent under a bulk-rate connection between
the terminus areas.  Somebody had implemented it and it worked quite
well -- route set up took less than a second.

What I need is to know what the name of the protocol is, and somewhere
to get information about it, since I need it for some research I'm
doing.

I *thought* the protocol was OSPF, but I've read some of the OSPF
documents, and it doesn't sound right.  Does anybody know what I'm
talking about?

Please e-mail responses.

Thanks, 

Dale

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
The perfect computer has been developed.  You just feed in your problems and
they never come out again.

-----------[000460][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 1993 14:04:49 +0200
From:      szymon@galaxy.uci.agh.edu.pl (Szymon Sokol)
To:        comp.protocols.tcp-ip
Subject:   Re: Giving back an IP address !!!

Doug Hughes (doug@happy.vf.ge.com) wrote:

: Is there something weird happening on your network? We have about 25-30
                                                                 ^^^^^
: workstations on each of our two lans right now (includes Sun's mac's
: and PC's running various forms of mail, X, appletalk and NFS.)  Our 
: network utilization is typically around 2% (diskless clients with
                                       ^^
: no swap!)  There are currently two networks with a cisco between
: them and two servers (one on each network) acting as file and boot servers.
: We have peeks of utilization around 7:30 in the morning, when everybody
: logs in, and they only amount to about 7-8% of network capacity.
 
:   utilization = bits/second avg'd over five minutes divided by 10,000,000
 
: If you are trashing your network with only 16 machines, you must be
: doing some monstrous application, or there's something else wrong, like
: you're using old Ungermann Bass stuff that only provides 3Mbps bandwidth,
: or something else entirely.

Sorry, I just cannot believe. 2% of Ethernet bandwidth is 
0.02*10^7b/s = 200kb/s ~= 25kB/s, not counting protocol overhead.
Divided by the number of workstations (25) it gives us 1kB/s.
If you transfer only 1kB/s from a *diskless* (some people say 'dickless' :-) )
station, you are not really using it. Our diskless Sun SLC's with 8MB RAM each
do several times more, and they are not (well, IMO) misconfigured.
-- 
U     U  M     M  M     M  Szymon Sokol -- Network Manager
U     U  MM   MM  MM   MM  University of Mining and Metallurgy, Computer Center
U     U  M M M M  M M M M  ave. Mickiewicza 30, 30-059 Krakow, POLAND
 UUUUU   M  M  M  M  M  M  TEL. +48 12 338100 EXT. 2885    FAX +48 12 338907

-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Mar 1993 17:34:26 GMT
From:      spenser@fudd.jsc.nasa.gov (S. Spenser Aden)
To:        comp.protocols.tcp-ip
Subject:   UDP broadcasting sample code for Sun SPARC

I recently posted a message about having trouble with the source code examples
in the Sun Network Programming Guide, specifically referring to UDP
broadcasting examples.  As I've received a number of requests for this code,
I'll go ahead and post it.  This is the code that the Sun Solution Center sent
to me for evaluation.  It works on my Sun SPARCstation 2, OS 4.1.2.  Your
mileage may vary.  No guarantee of usability is implied, and don't mail me for
corrections or fixes ... I'm only sharing what I got :-).  I hope it's useful
to some people.

-Spenser

/* ====================  Initial version of a broadcast sender  ============ */
#include <rpc/rpc.h>
#include <stdio.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <net/if.h>

main(argc, argv)

int argc;
char *argv[];
{
	enum clnt_stat stat;
	int outlen, inlen, fromlen, nets;
	register int sock;
	register int i;
	struct in_addr addrs;
	struct sockaddr_in baddr, raddr; /* broadcast and response addresses */
	char outbuf[1000], inbuf[1000];

	if ((sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0)
		perror("Cannot create socket for broadcast\n");
	bzero((char *)&baddr, sizeof (baddr));
	baddr.sin_family = AF_INET;
	if(argc == 2)
		baddr.sin_port = htons(atoi(argv[1]));
	else
		baddr.sin_port = htons(1999);
	baddr.sin_addr.s_addr = htonl(INADDR_ANY);
	for (i = 0; i < 888; i++) 
	{
		outbuf[i] = 'c';
	}
	outlen = i;
	outbuf[i] = NULL;
/*	baddr.sin_addr.s_addr = htonl(0x81911100);	*/
	baddr.sin_addr.s_addr = htonl(0xc0582980);	/* 192.88.41.128 */
	if (sendto(sock, outbuf, outlen, 0,
	    (struct sockaddr *)&baddr,
	    sizeof (struct sockaddr)) != outlen) 
	{
		perror("Cannot send broadcast packet");
	}
}

/* ====================  Enhanced version of a broadcast sender  ============ */
#include <rpc/rpc.h>
#include <stdio.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <net/if.h>

static int
getbroadcastnets(addrs, sock, buf)
struct in_addr *addrs;
int sock;  /* any valid socket will do */
char *buf;  /* why allocxate more when we can use existing... */
{
	struct ifconf ifc;
	struct ifreq ifreq, *ifr;
	struct sockaddr_in *sin;
	int n, i;

	ifc.ifc_len = UDPMSGSIZE;
	ifc.ifc_buf = buf;
	if (ioctl(sock, SIOCGIFCONF, (char *)&ifc) < 0) 
	{
		perror("broadcast: ioctl (get interface configuration)");
		return (0);
	}
	ifr = ifc.ifc_req;
	for (i = 0, n = ifc.ifc_len/sizeof (struct ifreq); n > 0; n--, ifr++) 
	{
		ifreq = *ifr;
		if (ioctl(sock, SIOCGIFFLAGS, (char *)&ifreq) < 0) 
		{
			perror("broadcast: ioctl (get interface flags)");
			continue;
		}
		if ((ifreq.ifr_flags & IFF_BROADCAST) &&
		    (ifreq.ifr_flags & IFF_UP) &&
		    ifr->ifr_addr.sa_family == AF_INET) 
		{
			sin = (struct sockaddr_in *)&ifr->ifr_addr;
			if (ioctl(sock, SIOCGIFBRDADDR, (char *)&ifreq) < 0) 
			{
				addrs[i++] = inet_makeaddr(inet_netof
				    (sin->sin_addr.s_addr), INADDR_ANY);
			} 
			else 
			{
				addrs[i++] = ((struct sockaddr_in*)
				    &ifreq.ifr_addr)->sin_addr;
			}
		}
	}
 return (i);
}

main(argc, argv)

int argc;
char *argv[];
{
	enum clnt_stat stat;
	int outlen, inlen, fromlen, nets;
	register int sock;
	register int i;
	struct in_addr addrs[20];
	struct sockaddr_in baddr, raddr; /* broadcast and response addresses */
	char outbuf[1000], inbuf[1000];


	if ((sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0)
		perror("Cannot create socket for broadcast\n");
	nets = getbroadcastnets(addrs, sock, inbuf);
	bzero((char *)&baddr, sizeof (baddr));
	baddr.sin_family = AF_INET;
	if(argc == 2)
		baddr.sin_port = htons(atoi(argv[1]));
	else
		baddr.sin_port = htons(1999);
	baddr.sin_addr.S_un.S_addr = htonl(INADDR_ANY);
	for (i = 0; i < 888; i++) 
	{
		outbuf[i] = 'c';
	}
	outlen = i;
	outbuf[i] = NULL;
	for (i = 0; i < nets; i++) 
	{
		baddr.sin_addr = addrs[i];
		if (sendto(sock, outbuf, outlen, 0,
		    (struct sockaddr *)&baddr,
		    sizeof (struct sockaddr)) != outlen) 
		{
			perror("Cannot send broadcast packet");
		}
	}
}

/* ====================  Initial version of a broadcast receiver ============ */
#include <rpc/rpc.h>
#include <stdio.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <net/if.h>

main(argc, argv)
int argc;
char *argv[];
{
	int rlen, inlen;
	register int sock;
	register int i;
	struct in_addr addrs;
	struct sockaddr_in baddr; /* broadcast and response addresses */
	char inbuf[UDPMSGSIZE];

	if ((sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0)
		perror("Cannot create socket for broadcast\n");

	bzero((char *)&baddr, sizeof (baddr));
	baddr.sin_family = AF_INET;
	if(argc == 2)
		baddr.sin_port = htons(atoi(argv[1]));
	else
		baddr.sin_port = htons(1999);
	baddr.sin_addr.s_addr = htonl(INADDR_ANY);
	inlen = sizeof(baddr);

	if (bind(sock, &baddr, inlen) < 0)
		perror("bind failed\n");

	if ((rlen = recvfrom(sock, inbuf, UDPMSGSIZE, 0, &baddr, &inlen)) < 0)
		perror("Cannot receive broadcast packet");
	printf("length is %d\n", rlen);

	for (i = 0; i < rlen; i++) 
	{
		printf("%c", inbuf[i]);
	}
	printf("\n");
	exit(0);
}
-- 
S. Spenser Aden --- Lockheed Engineering and Sciences Co. --- (713) 483-2028
NASA --- Flight Data and Evaluation Office --- Johnson Space Center, Houston
spenser@fudd.jsc.nasa.gov    (Internet) ---  Opinions herein are mine alone.
aden@vf.jsc.nasa.gov (if above bounces) ---  "Eschew obfuscation." - unknown

-----------[000462][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Mar 1993 17:44:49 GMT
From:      becker@super.org (Donald J. Becker)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: need help:building a mutiplatform net

In article <1993Mar30.004703.1@vmsb.is.csupomona.edu> cvakg001@vmsb.is.csupomona.edu writes:
>Hi, I have recently transfered to CalPoly and live in the residence halls. I my
>particular hall, we have a serial link to our vax, but we are looking for more.
>
>I have recently recieved a request on be-half of housing  to assemble a 
>hall-wide network. We need to be an equal-oppertunity network provider, that is
>the net needs to be equaly freindly to macs and PCs. Additiionally the 
>equiptment investment for either platform needs to be of minimal cost. The 
>housing office has a Mac IIci that we can dedicate as a server. The hall has a 
>maximum capacity of 186 residents. We currently have a need for about 40 users,
>about 20 macs (mostly compacts but with sys7.0) and about 25 pc's. We need to 
>fullfill the current need and have the capability to expand to accouodate about
>150 users.
 ...
>I know this is asking a bunch, but as I said, this is low budget at this point,
>and I can't pay for advise. Any help, real-life stories of sucessfull 
>installations and any other relevant info would be apreciated.
>

Thin ethernet is by far the best price/performance solution for most
small networks.  However with 150 potential users you aren't talking
about a small network, and you might have problems with the physical
cable length and load.  Twisted pair and active hubs starts to make
sense when the alternative is using external transceivers ($50 ea.)
and long transceiver cables reduce the coax segement length.

Here is the write-up I send to people asking questions about Linux
networking hardware.  (And I get to put in an advert. blurb for Linux!)

 Linux is a POSIX compatible OS that runs on ISA-based (the PC-AT bus)
 machines.  It has good network performance, features NFS, X windows,
 and has all the common network utilities you expect with a *nix system

\title{Ethercard hardware tutorial}

For impatient users that just want a quick, cheap answer the summary is:
get 16 bit thinnet 8013 cards for $89.

Too brain-damaged to use: 3c501, which is surplus from many places.
	Avoid it like the plague.
8 bit ethercards: NE1000, Cabletron E10** series, WD8003, 3c503
	Slightly less expensive, but only worth the savings for light use.
16 bit ethercards: NE2000, Cabletron E20** series, WD8013, 3c503/16

NE[12]000: The now-generic name for a bare-bones design around the
	NatSemi 8390.  They use programmed I/O rather than shared
	memory, leading to easier installation but slightly lower
	performance and a few problems.  The prefix "NE" came from
	Novell Ethernet -- Novell followed the cheapest NatSemi databook
	design and sold the manufactoring rights (spun off?) Eagle, just
	to get reasonably-priced ethercards into the market.

	Some recently introduced NE2000 clones use the National
	Semiconductor "AT/LANTic" 83905 chip, which offers a shared
	memory mode similar to the 8013 and EEPROM or software
	configuration.

WD80[01]3: A shared memory design by Western Digital.  Over the years the
	design has added more registers and an EEPROM.  Clones usually
	go by the '8013' name, and usually use a non-EEPROM (jumpered)
	design.	This part of WD has been sold to SMC, so you'll usually see
	something link SMC/WD8013 or SMC Elite Plus (WD8013).

	The shared memory makes the cards 10-20% faster, especially with
	larger packets.  More importantly (to me at least) it avoids a few
	bugs in the programmed-I/O mode of the 8390, allows safe
	multi-threaded access to the packet buffer, and doesn't have
	a programmed-I/O data register that hangs your machine during
	warm-boot probes.

3c503/3c503/16: 3Com shared-memory ethercards.  They also have a
	programmed I/O mode that doesn't use the 8390 facilities (their
	engineers found too many bugs!)  It should be about the same
	speed as the same-bus-width WD80x3, but I don't have a 16 bit
	version to benchmark. 

HP-LAN ethercards: Nicely made, but hard to find.  The model numbers don't
	encode anything, so you'll have to go by the description.
	They use programmed I/O, similar to the NE*000 boards, but the
	data transfer port can be "turned off" when you aren't
	accessing it, avoiding problem with autoprobing drivers.

3c509: A new card for 3Com, which might be supported soon.  It should
	be cheap and have excellent performance. The drawbacks are that
	it _requires_ very low interrupt latency, and it isn't rated for bus
	speeds greater than 8Mhz.  The EISA version uses the same
	16 bit wide chip rather than a 32 bit interface.

I'm ofter asked "Do you know a source of inexpensive cards?"
I keep track of the current low-price vendors, just because I'm asked
this so often.  Call AT-LAN-TEC at 301-948-7070.  Ask for their
technical support person, "Vincent Bono".  As with all purchases, you
should indicate you are buying this for a Linux system.
The last I checked the price for 10 NE2000s was $670, or $69 ea.!
They also carry a clone, non-EEPROM 8013 board for $89, which is a
better choice if the very lowest price isn't essential.

I've also ordered Alta "Combo" NE2000 cards from Network Express
(aka Main Street Computers, I think) in Fl.  A bit more expensive, but
perhaps local to you.

If you are looking for prices on your own, try the back of LAN
magazine.

\section{Cables and Stuff}

If you are starting a network from scratch, it's considerably less
expensive to use thin ethernet, RG58 co-ax cable with BNC connectors,
than old-fashioned thick ethernet, RG-5 cable with N connectors, or
10baseT, twisted pair telco-style cables with RJ-45 "phone"
connectors.

Twisted pair networks require active hubs, which start around $300,
and the raw cable cost can actually be higher than thinnet.  They are
usually sold using the claim that you can use your existing telephone
wiring, but it's a rare installation where that turns out to be the
case.  The claim that you can upgrade to higher speeds is also
suspect, as most proposed schemes use higher-grade (read $$) cable and
more sophiticated termination ($$$) than you would likely install on
speculation.

Thick ethernet is mostly obsolete, and is usually used only to remain
compatible with an existing implementation.  You can connect thick
ethernet to thinnet with a passive $3 N-to-BNC connector, and that's
often the best solution to expanding a thicknet.

Thin ethernet is my "ether of choice".  The cable is inexpensive.  If
you are making your own cables solid-core RG58A is $0.09/ft. and
stranded RG58AU is $0.15/ft.  Twist-on BNC connectors are < $2 ea.,
and other misc. pieces are similarly inexpensive.  It is essential
that you properly terminate each end of the cable with 50 ohm
terminators, so budget $2 ea. for a pair.


Donald Becker				       becker@super.org
 Supercomputing Research Center
 17100 Science Drive, Bowie MD 21114		   301-805-7482


-- 
Donald Becker				       becker@super.org
Supercomputing Research Center
17100 Science Drive, Bowie MD 20715		   301-805-7482
-- 
Donald Becker				       becker@super.org
Supercomputing Research Center
17100 Science Drive, Bowie MD 20715		   301-805-7482

-----------[000463][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 93 18:33:48 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Offloading TCP/IP processing

In article <1p9nm2INNecm@news.hi.com> tonyr@hicomb.hi.com writes:
>
>Are there any successful examples of offloading some or all of the protocol
>processing onto a front-end processor? I'm aware of the Interphase and Auspex
>NFS accelerators which do the UDP/XDR processing for NFS requests, but am more
>interested in general TCP offloading. I heard that Interlan has a board which
>offloads everything below the socket layer, but don't know how it compares to a
>non-offloaded system.
>
>One obvious problem is how to connect multiple front-end processors to a
>system. In order to determine which processor to send a request to, the routing
>decision has to be moved up from where it is currently done in ip_output (in
>BSD). What kinds of problems can this create?

I've watched the FEP vs Host Resident arguments for years and thought that
I'd just state a few points.

Much of the overhead in networking is involved in moving data from the
application into the kernel and then often from the kernel into the I/O
hardware.  In a well implemented implementation, the protocol processing
overhead is usually not that large.  In moving the protocol into an FEP,
there needs to be some work managing all of the flows on TCP connections
between the application and the FEP.  Be careful that you haven't just
traded one protocol overhead for another.

Second, if your main processor is upgraded, you can get into the situation
where the FEP becomes a bottleneck and the main processor has CPU cycles
to spare while waiting on the FEP.

Third, some FEP implementations don't have access to all of the features
available in Host Resident implementations.  This is often true of access
to lower levels of protocol.  A new OS release may introduce new capabilities
to a Host Resident implementation, but an FEP implementation is usually
much more static.  Also, you may experience delays between the time an OS
release is made, and the time the FEP vendor has upgraded support for it.

Finally, if your machine needs multiple interfaces, separate FEPs each
with their own TCP/IP stack cause real topology problems for the host and
the applications on it.  The TCP/IP architecture really only expects one
TCP/IP stack between the applications at a node and that nodes's network
interfaces.  To get around this problem, you may end up with very complex
interactions between the kernel and all of the FEPs, or non-standard
application interfaces.

Art

-----------[000464][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Mar 1993 18:50:33 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Offloading TCP/IP processing

In article <1p9nm2INNecm@news.hi.com> tonyr@hicomb.hi.com writes:
>Are there any successful examples of offloading some or all of the protocol
>processing onto a front-end processor? I'm aware of the Interphase and Auspex
>NFS accelerators which do the UDP/XDR processing for NFS requests, but am more
>interested in general TCP offloading. I heard that Interlan has a board which
>offloads everything below the socket layer, but don't know how it compares to a
>non-offloaded system.

Gee, it's been a long time since this has come up.  Must be a new trend!
Anyway, current wisdom is that *generally* offloading TCP does not help.
There are a few reasons for this, but i think you'll get the idea if i
just cite the two primary ones.

First, TCP doesn't cost that much to begin with.  It is generally
believed that a carefully crafted TCP could be almost as efficient as the
corresponding protocol needed between the host and the offloaded TCP.

Second, host CPUs tend to be commodity items, while front-ends are not.
Consequently, market pressure drives host CPU power up and host prices
down much faster than they drive front-ends in those directions.
Historically, this eventually leads to the front-end being the bottle
neck in a system, ironically just the opposite of the original intent.

This isn't to say that in some cases a front-end wouldn't be a good
idea, but history shows that, at least so far, it hasn't been a winning
approach in general.
						don provan
						donp@novell.com

-----------[000465][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 1993 18:51:45 GMT
From:      bjaspan@GZA.COM (Barry Jaspan)
To:        comp.protocols.tcp-ip
Subject:   IP, UDP, and TCP implementation list?

Is there a list of (freely available) implementations of IP, UDP, and TCP, and
where they are located? I've seen a number of different implementations
mentioned here, but never all at once.  Obviously, BSD contains one.  Van
Jacobson has also written one, but I've never seen a pointer to the code
(maybe it's proprietary?).  And I'm sure there are others, with different
merits.

Thanks.

-- 
Barry Jaspan, bjaspan@gza.com
Geer Zolot Associates

-----------[000466][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Mar 1993 20:11:55 GMT
From:      assela@marcus.its.rpi.edu (A. Andre Asselin)
To:        comp.protocols.tcp-ip
Subject:   Re: Offloading TCP/IP processing

tonyr@hicomb.hi.com (Tony Rodriguez) writes:
>Are there any successful examples of offloading some or all of the protocol
>processing onto a front-end processor? I'm aware of the Interphase and Auspex

IBM's TCP/IP for MVS has an offload option.  Unfortunately, I don't know
the specifics of the implementation, but I believe that the split is at 
the sockets level (i.e. everything below sockets is on the OS/2 system).
If you have any specific questions, feel free to contact me by email...
      - Andre Asselin  (assela@rpi.edu)

-----------[000467][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 93 20:21:46 GMT
From:      grega@math.uakron.edu (Greg Akers)
To:        comp.protocols.tcp-ip
Subject:   CPI-C over rpc

Forgive me if this is a FAQ. Does anyone know of this protocol ? As I 
understand it, it is an RPC service run over TCP/IP networks. Please 
e-mail, as I am not a regular reader of this group.

Greg Akers
grega@zippysun.math.uskron.edu

-----------[000468][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Mar 1993 20:40:17 +0000
From:      tchannon@black.demon.co.uk (Tim Channon)
To:        comp.protocols.tcp-ip
Subject:   Driver for DFINET-200

I am looking for a missing driver for a circa 1988 cheapernet card DFINET-200 
and so far nothing suitable has been found. (DOS EIA 8 bit card)

Ideas anyone?

  TC. 
    E-mail: tchannon@black.demon.co.uk or tchannon@cix.compulink.co.uk
                                

-----------[000469][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Mar 1993 21:19:23 GMT
From:      madhu@cbnewsf.cb.att.com (madhu.shekhar)
To:        comp.protocols.tcp-ip
Subject:   Where are test suites for TCP/IP ?



Hi folks,

    Anyone know where I  could find  test suites for 
TCP/IP and applications like TELNET, FTP, and SNMP ? For
testing conformance with Internet recommendations ?

    Please mail your response to
          
          madhu@mt747.att.com


-----------[000470][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 1993 22:22:33 GMT
From:      wick9450@miller.cs.uwm.edu (Paul Wickman)
To:        comp.protocols.tcp-ip
Subject:   SUBNETTING A SUBNET


	I have subnetted my class B address with 255.255.240.0.  Is
it possible to further subnet one of these subnets?  For example, one of
the subnets it 139.69.48.0.  Could I further subnet just that subnet?  If
so, how would I do that?

	Any help would be greatly appreciated!!

Please send responses to pwickman@carroll1.cc.edu  


-----------[000471][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Mar 1993 22:47:55 GMT
From:      peter@rahul.net (Peter Rizk)
To:        comp.protocols.tcp-ip
Subject:   Help, with Simulation!!!!

 Hi Anybody,

Is there some one out there who can help me to get started on a Simulation
project? I neeed to know where I could find such samples of simulation
projects. I am very much interseted in Token ring and Token bus. Do you
know where I can find source code and documentation about that. Please,
let me know if you have any idea. Thanks.....

I can be reached at :       peter@rahul.net


-- 
Peter Rizk <peter@rahul.net>

-----------[000472][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31 Mar 93 00:59:12 GMT
From:      shj@ultra.com (Steve Jay {Ultra Unix SW Mgr})
To:        comp.protocols.tcp-ip
Subject:   Re: Offloading TCP/IP processing

tonyr@hicomb.hi.com (Tony Rodriguez) writes:

>Are there any successful examples of offloading some or all of the protocol
>processing onto a front-end processor?

I don't know if you'd consider us "successful", but we've been selling
such things for about 5 years.

>One obvious problem is how to connect multiple front-end processors to a
>system. In order to determine which processor to send a request to, the routing
>decision has to be moved up from where it is currently done in ip_output (in
>BSD). What kinds of problems can this create?

We bypass the the entire host protocol stack, sockets & all.  We intercept
the application's system calls & pass them to our own driver, which decides
which of the off-host adapters should handle the operation (if there's more
than one).  It ain't easy.

donp@novell.com (don provan) wrote:

> First, TCP doesn't cost that much to begin with.  It is generally
> believed that a carefully crafted TCP could be almost as efficient as the
> corresponding protocol needed between the host and the offloaded TCP.

This may be true in theory, but I don't think you'll find many (any?)
of these "carefully crafted TCP" implementations available as off-the-shelf
items yet.  I think Vernon's FDDI implementation on SGI, which follows the
"a copy not done is the fastest copy possible" philosphy, probably has
the lowest CPU utilization of any commercially availble TCP implementation.
I know it can saturate an FDDI, but I don't know what percentage of
the CPU is still left for other work.  We can pump 14 MByte/sec out of
an SGI 4d/3xx using less than 20% of a single CPU (a 33 MHz R3000, I think).
Yesterday, I was sending 23 MByte/sec from an IBM RS6000/580 using 18% of
its CPU.  This is important to some customers.

> Second, host CPUs tend to be commodity items, while front-ends are not.
> Consequently, market pressure drives host CPU power up and host prices
> down much faster than they drive front-ends in those directions.
> Historically, this eventually leads to the front-end being the bottle
> neck in a system, ironically just the opposite of the original intent.

This is probably true in the long run.  At the moment, a major exception
to this is the large mainframe.  While these are definitely a dying
technology, there are lots of them out there, and our off-host protocol
processing is a big win on those systems.  Even in the workstation market,
there are a lot of folks who'd rather crunch numbers with their CPU's
rather than compute TCP checksums.


Steve Jay
shj@ultra.com  ...ames!ultra!shj
Ultra Network Technologies / 101 Dagget Drive / San Jose, CA 95134 / USA
(408) 922-0100 x130	"Home of the 1 Gigabit/Second network"

-----------[000473][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 93 08:48:50
From:      ojr@itk.unit.no (Ornulf Rodseth)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP broadcasting sample code for Sun SPARC


The SUN manual says that broadcasts has to be enabled with the
setsockopt call before broadcasts can be sent, e.g.:

    int on = 1;

    if (setsockopt(sock, SOL_SOCKET, SO_BROADCAST, (char*)&on, sizeof(on)))
    {
        close(sock);
        return -1;
    }

I have a feeling that this isn't necessary for SUNs, but it may be for
some other type of operating system. Do anyone know?


--
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)

-----------[000474][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 93 04:09:36 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Using SLIP as Gateway

[ question about how to configure different interfaces on a Sun
  workstation to have different addresses omitted. ]

Did it occur to you to call
(a) the help desk of your Internet service provider or
(b) customer support at your workstation vendor or
(c) customer support at the 3rdparty software vendor whose
    product you are using 
before asking this in a public forum ?

Basically, each interface (in your configuration, the ethernet adapter
is one interface, the serial modem line is another) each have an IP
address. The interface is configured using the ifconfig command.
This will allow the workstation to communicate at the same time
with the ethernet and with the internet service provider.

Routing packets THROUGH the workstation from workstations on your local
network to the Internet is slightly more complicated. If your contract
with the network service provider allows you to do it, they will
probably help you set it up. From the information you gave, it sounds as
if they will allow it IF AND ONLY IF you use the addresses they issued
you for the workstations on your local net. You may have to change IP
addresses on every workstation on your net in order to use this service.

-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256

-----------[000475][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 93 04:22:44 GMT
From:      aamicone@sdcc13.ucsd.edu (Andrew Micone)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Getting DNC to work with Internet apps


I'm running SunOS 4.1.2 with a SLIP interface to  CERFNET. I've got
it configured as a cache-only name server, and mostly it seems to
work with nslookup for resolving host names. I do get an initial
error "Can't find initialize address for server : Timed out" but
for now I'm assuming that has something to do with the slip
interface. It seems to resolve host names just fine.

The problem is that none of the internet applications seems to work
right with named.If the host name is in the host table, or if you
use an IP address it works just fine, but that will not work for
mail and other services I want to use like gopher. ftp, telnet,
rlogin and such don't seem to make an attempt to resolve the name
with the nameserver. I feel like there's a configuration step that
I'm missing, but I'm not sure. Anybody got an idea what needs to be
done?

-- Andy

-----------[000476][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31 Mar 1993 06:54:08 GMT
From:      schwartz@latour.cs.colorado.edu (Michael Schwartz)
To:        comp.protocols.tcp-ip,comp.protocols.snmp
Subject:   Fremont prototype announcement

Fremont is a research prototype for discovering key network
characteristics, such as hosts, gateways, and topology.  Fremont uses an
extensible set of Explorer Modules to discover information, based on a
variety of different protocols and information sources, rather than a
single network management protocol.  This approach allows more complete
and timely information to be discovered than, for example, using only
one protocol, even one as capable as the Simple Network Management
Protocol.  The discovered information is time-stamped and recorded in a
database.  The contents of this database are cross-correlated to form
an increasingly complete network picture, to direct further discovery,
and to highlight inconsistent information.

You can try a demo of the Fremont system by telnet to
bruno.cs.colorado.edu: login as "fremont" (with no password).  If you
have a SparcStation, a better way to get a demo is to retrieve an
X-windows client we have made available, and run it on your machine.
This executable is available by anonymous FTP from ftp.cs.colorado.edu,
in pub/cs/distribs/fremont/xjsv.Z.  There is a README.DEMO file in this
same directory that describes how to run the demo.

The Fremont source code is also available by anonymous FTP, in
pub/cs/distribs/fremont/fremont.tar.Z.

If you are interested in learning more about Fremont, a paper describing
its methodology is available by anonymous FTP from ftp.cs.colorado.edu,
in pub/cs/techreports/schwartz/PostScript/Fremont.ps.Z (compressed
PostScript) or pub/cs/techreports/schwartz/ASCII/Fremont.txt.Z
(compressed ASCII).  This paper is also included in the source code
distribution.

	Sean Coleman,
	David C. M. Wood, and
	Michael Schwartz
	Dept. of Computer Science
	Univ. of Colorado - Boulder

-----------[000477][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31 Mar 1993 15:20:34 -0500
From:      "Mohd Hanafiah Abdullah" <napi@cs.indiana.edu>
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   Checksum question

Hi,

Can someone please explain to me how one does a checksum for error detection
when passing message over a network.

Thanks in advance.

Napi

-----------[000478][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31 Mar 1993 19:59:21 -0500
From:      "Mohd Hanafiah Abdullah" <napi@cs.indiana.edu>
To:        comp.protocols.tcp-ip,comp.unix.questions,cs.general
Subject:   UDP question

When using UDP how does one access the checksum field of the datagram.
Also, how does one use the checksum info in order to determine if a
transmission error has occured.

Thanks in advance, and pls respond by email.

Napi

-----------[000479][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31 Mar 1993 14:00:53 GMT
From:      stewart@oin.cis.udel.edu (John Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP broadcasting sample code for Sun SPARC

In article <OJR.93Mar31084850@mons.itk.unit.no> ojr@itk.unit.no (Ornulf Rodseth) writes:
>
>The SUN manual says that broadcasts has to be enabled with the
>setsockopt call before broadcasts can be sent, e.g.:
>
>    int on = 1;
>
>    if (setsockopt(sock, SOL_SOCKET, SO_BROADCAST, (char*)&on, sizeof(on)))
>    {
>        close(sock);
>        return -1;
>    }
>
>I have a feeling that this isn't necessary for SUNs, but it may be for
>some other type of operating system. Do anyone know?
>
>
>--
>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)

If memory serves, true BSD systems require the SO_BROADCAST to
be set, as do older (pre 4.1) SunOS systems.

Of course, memory could not be serving, though!

/jws

-----------[000480][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 93 15:18:28 GMT
From:      ade@nessie.mcc.ac.uk (Adrian Collins)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP vs. UDP

In <1pc3psINNcfr@flash.pax.tpa.com.au> hart@flash.pax.tpa.com.au (Leigh M Hart) writes:

>In this setup (and I believe with TCP generally, I might be wrong) the
>server can only communicate with one peer (client) process at a time
>(hence using fork).

Nope.  There is a function select() which handles multiplexing (or rather
sensing of which socket needs attention).

>With a server that uses UDP sockets, it too binds a port and waits for
>a packet (note, no connection as such occurs and being a broadcast 
>protocol there is no way, unless you program a protocol on top of UDP,
>to know if a packet is received, after being sent).

Generally, client/server processes which deal with lots of short requests 
(ie. less than the maximum length of a UDP datagram) with maybe one request
packet & one response packet is best written using UDP as these do not need 
the (relatively) length connection time associated with TCP. 

UDP is unreliable in that a datagram is not guaranteed to make it to it's
destination and there is no inbuilt way of knowing whether it got there or not.
However, it is very easy to build a layer of reliability over UDP by 
acknowledging received packets.

UDP is used by things like NFS where there is one request datagram and one 
response datagram per transaction.  Another example is named where transactions
include one request & one reply.  It would be a waste of time to have to set
up a connection to resolve a name.

TCP is best used when a relatively large amount of data passes or when there
is a complex dialog going on between the server and client (ie. session
based applications).  An example of this is named's xfer for transfering zone
data as this requires a lot of data to be sent.

Cheers,

 Adrian
-- 
Adrian Collins, MCC Network Unit, The University, Manchester M13 9PL, UK
    (061)-275-6009  or for those of the computer age: ade@mcc.ac.uk 

"No good opera plot can be sensible, for people do not sing when they are

-----------[000481][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31 Mar 1993 16:40:19 GMT
From:      richb@jti.com (Richard Braun)
To:        comp.protocols.tcp-ip
Subject:   Re: Of course we're running out of IP addr

hwdub@chevron.com writes:
>What the domain template actually says is (emphasis mine on the part I
>missed):
>
>   * If you are applying for a domain and a network number assignment
>   simultaneously AND A HOST ON YOUR PROPOSED NETWORK WILL BE USED
>   AS A SERVER FOR THE DOMAIN, you must wait until you receive your
>   network number assigment and have given the server(s) a netaddress
>   before sending in the domain application.  Sending in the domain
>   application without complete information in Sections 7 and 8 of
>   this template will result in the delay of the domain registration.

They still goofed, in my opinion.  It should mention in the above that
you can always alter the domain name server list later.  For example,
when jti.com joined the Internet, it did so in two stages.

  1)  Establish two name servers on the net, and MX forwarding through
      one of those sites.
  2)  A few months later, it set up a permanent leased line.

Then a week or so later, we got NIC to change the name server list.
That way we could administer our own namespace instead of pestering the
folks who were doing it before.  That's really the only issue here:
whether you want to administer your domain's namespace yourself, or
let someone else do it.  You can only do it yourself if your site is
directly connected, and even then it's not mandatory.

(By the way, there's even a hybrid solution which I established even
before NIC changed our server list.  As soon as the link went "live",
I got our existing name server sites to reconfigure themselves to point
to our primary name server as secondaries.  That's desirable even on
a permanent basis if you have a slow link and don't want to handle
incoming name-service traffic.)

-rich

-----------[000482][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 93 16:59:34 GMT
From:      velchamy@mp.cs.niu.edu (S.Velchamy)
To:        comp.protocols.tcp-ip
Subject:   Closing a TCP connection


	Is there a way to close a TCP connection without going thru the
FIN_WAIT_1, FIN_WAIT_2 states. Can I reset the port if I know that the client
on the other end is dead and he is not going to acknowledge my FIN?
	Any suggestion is really appreciated. My platform is RS6000/AIX.

Thanks.
S.Velchamy
velchamy@mp.cs.niu.edu
.

-----------[000483][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31 Mar 93 19:59:44 GMT
From:      maritza@espresso.bae.bellcore.com (Maritza Ramirez)
To:        comp.protocols.tcp-ip
Subject:   Domain Names

Upps, sorry for the previous subject

Does anyone know which is the maximum
number of characters allowed for a domain
name ? (i.e., espresso.bae.bellcore.com)

Maritza

-----------[000484][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 93 20:03:26 GMT
From:      wick9450@miller.cs.uwm.edu (Paul Wickman)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   IPX ROUTING AND IP BRIDGING


	I'm looking for a product that will route IPX/SPX and bridge TCP/IP.
I know that several (b)router hardware solutions are probably available, but
I'm wondering if there is a cheaper, software solution.  Any ideas?

	Please send all replies to pwickman@carroll1.cc.edu

Thanks

-----------[000485][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 93 23:31:11 GMT
From:      cks@hawkwind.utcs.toronto.edu (Chris Siebenmann)
To:        comp.protocols.tcp-ip
Subject:   Looking for a comprehensive list of common port numbers

 I suppose the subject says it all; we're looking for a more
comprehensive list of port numbers and what uses them than the current
Assigned Numbers RFC (1340) provides. One example of why we want it;
although the NSFNet measurements consider IRC traffic important enough
to track it specifically, port 6667 isn't named in 1340.

 Thanks in advance.

--
      "> [...] That could be best left for a Nutshell book on Sendmail.
       In England we have the Obscene Publications Act, which would
       probably prevent its import."			- Ian G Batten
cks@hawkwind.utcs.toronto.edu	           ...!{utgpu,utzoo,watmath}!utgpu!cks

END OF DOCUMENT