HDTenEightyP/NetNews huggingface dataset:
From: regina@netronix.com (Regina Clarke)
Newsgroups: comp.protocols.tcp-ip
Subject: Subnet Masks
Distribution: world
Date: Fri, 06 Nov 92 19:10:36 GMT
Organization: Netronix, Inc.

Internet : regina@netronix.com
USENET   : uunet!netronix!regina
fax      : (707) 763-6291
phone    : (707) 769-3300
U.S.Mail :  Regina Clarke
            Netronix, Inc.
            1372 N. McDowell Blvd.
            Petaluma CA 94954

Would like information on subnet masks--function, any glitches from end-user p.o.v. and why fixed, contiguous addressing necessary or advisable?

Newsgroups: comp.protocols.tcp-ip
From: dotytr@nscultrix2.network.com (Ted Doty)
Subject: Re: Hippi
Followup-To: ted.doty@network.com
Summary: annonymous ftp location of HIPPI docs
Keywords: parallel performance
Organization: Network Systems Corporation
Date: Thu, 12 Nov 92 02:19:05 GMT

The current HIPPI specs are available via annonymous FTP from
network.com (I forget the directory, but it's pretty self-evident).

- Ted

--------------------------------------------------------------------------
Ted Doty, Network Systems Corporation | phone:      +1 301 596-2270
8965 Guilford Road, Suite 250         | fax:        +1 301 381-3320
Columbia, MD, 21046 USA               | voice mail: (800) 233-1485
--------------------------------------------------------------------------
These opinions are my own, not necessarially those of Network Systems.
Newsgroups: comp.protocols.tcp-ip
From: donp@novell.com (don provan)
Subject: Re: Detecting Dropped Sockets (Why is this hard on PC's?)
Organization: Novell, Inc., San Jose, California
Distribution: na
Date: Thu, 5 Nov 1992 19:35:18 GMT

In article <49191@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
>I don't disagree with your statements, however, I was curious about
>the systems you execute on.  Specifically, when a process is
>terminated, what happens to the open file descriptors?

So your claim is that if i use such an operating system, then i must
agree this behavior is correct.  Sorry.  Operating systems that aren't
brain dead (most, unfortunately, no longer in production) understand
that the file system's state shouldn't be changed unless the file
manipulation is completed, which the application typically indicates
by explicitly closing the file.  On such operating systems,
terminating a process (or crashing the machine, for that matter)
leaves the *original* file unchanged, or leaves no file at all if
there was no original file.  In almost all cases, leaving a partially
written file is absolutely the least desirable end result.  But, as
most everyone else, i'm forced to use both UNIX and DOS even though
they both have this fault.

>Aren't they typically "closed"?  Doesn't TCP typically map this into
>a "normal connection close"?

And your claim here is that since UNIX believes that it understands
how to gracefully close file descriptors, then it's OK for it to close
TCP connections gracefully as well.  Hard to argue with that if you
truely believe UNIX defines TCP/IP.  Even so, it's a shame to lose the
useful meaning of a graceful close just because one common operating
system thought it knew everything there was to know about any possible
TCP application.

>I assume that you would inject an RST in cases
>where you could prove "abnormal termination".  Can you cite an RFC
>which gives guidelines as to when TCP should inject an RST on behalf
>of the application?  I'm sure we would benefit from clean, consistent
>implementations.  

To my knowledge, no RFC deals with what TCP should do if its
application disappears.  Personally, i think that's because no one
ever conceived of the UNIX behavior as a possibility, anymore than
they thought an operating system might tend to send "Th-Th-That's all
folks!" spontaneously down the TCP pipe.

But if we take RFC-793 as gospel (and why not?), since it doesn't
mention process termination at all, my conclusion then is that the TCP
implementation should do nothing: the connection simply disappears.
No FIN, no RST, no nothing.  Then any subsequent packets from the
other end of the connection would be for a non-existent connection, so
TCP would respond with a RST.  In practice, in order to expedite the
remote node's awareness of the situation, TCP sends a RST immediately.
This isn't significantly different than doing nothing, since it's just
what would happen if an old packet arrived or something like that.

						don provan
						donp@novell.com
Newsgroups: comp.protocols.tcp-ip
From: robinson@mdivax1.uucp (Jim Robinson)
Subject: Re: Should connect() block after setting NDELAY?
Reply-To: robinson@mdd.comm.mot.com (Jim Robinson)
Organization: Motorola - Mobile Data Division; Richmond, BC
X-Newsreader: TIN [version 1.1 PL6]
Date: 10 Nov 92 22:21:53 GMT

Daniel R. Kegel (dank@blacks.jpl.nasa.gov) wrote:
>
>Hi all,
>I'm writing an application that opens sockets to many servers in parallel
>before sending out a query to each server (also in parallel).  It sets
>the sockets into nonblocking mode before the connect() as follows:
>	int flags;
>    #ifdef USE_FIONBIO
>	flags=1;
>	netioctl(qp->fds, FIONBIO, (char *)&flags);
>    #else
>	flags = fcntl(qp->fds, F_GETFL, 0);
>    #ifdef USE_O_NDELAY
>	flags |= O_NDELAY;
>    #else
>	flags |= FNDELAY;
>    #endif
>	fcntl(qp->fds, F_SETFL, &flags);
>    #endif
>The problem is, under SunOS 4.1.1, connect() then blocks until a 
>accept, reject, or defer response comes back from the server.
>This can take several seconds if the Internet is being slow.
>The local Sun guy was able to see this in the source code, but does not
>consider it a bug.  What do you all think- is it reasonable for connect()
>to block for several seconds when the socket is supposedly in nonblocking
>mode?

On a semi-related topic I can say that if, on SunOS 4.1.2, you set the
socket to nonblocking with POSIX O_NONBLOCK, a subsequent connect() will
indeed *block*; i.e., O_NONBLOCK has no effect on the connect().

-- 
Jim Robinson
robinson@mdd.comm.mot.com
{ubc-cs!van-bc,uunet}!mdivax1!robinson

Newsgroups: comp.protocols.tcp-ip
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: FAST!!! TCP-IP Machines
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 10 Nov 1992 20:28:11 GMT

In article <1992Nov10.154228.29047@panther.mot.com>, ronf@panther3.panther.mot.com (Ron Feigen) writes:
> Has anybody in netland done research on how fast different platforms process
> communication protocols?  I am currently working on an application that relies
> heavily (very heavily) on TCP-IP.  I am currently using Sun SparC II's but I 
> would really like to know if there are machines that are better suited to my
> application.
> 
> Any info would be greatly appreciated!!!!


It might help to be more specific.

All reasonable machines are now about the same speed--over a 56Kbit/sec
link.  All good machines are now about the same speed over ethernet--a little
more than 1MByte/sec.

On the other hand, Cray makes machines that do about 1Gbit/sec.
(I have a mental block about the exact numbers, which were over the
loopback interface and two flavors of HIPPI.)

In between, DEC was showing machines without labels at Interop that
were running at about 95Mbit/sec over FDDI.  (They said details about
the machines would be announced Nov. 10.  No doubt everyone has seen
the numbers in comp.arch.)  Another vendor in a nearby booth (blush)
was running somewhat faster, also over FDDI.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.protocols.tcp-ip
From: g91m1969@alpha.ru.ac.za (Thabo Mosala)
Subject: Hippi
Summary: High performance parallel interface
Keywords: parallel performance
Organization: Rhodes University, Grahamstown, South Africa
Date: Tue, 10 Nov 1992 12:25:32 GMT

I would like to get hold of the new developed standards for High Performance
Parallel Interface (Hippi) or where can I get information on the subject ?


___________________________________________________________________________

Thabo Mosala - g91m1969@alpha.ru.ac.za

The views expressed above are my own

___________________________________________________________________________
Xref: sparky comp.protocols.tcp-ip:5136 comp.protocols.ibm:804
From: mndot@msus1.msus.edu
Newsgroups: comp.protocols.tcp-ip,comp.protocols.ibm
Subject: SNA <-> IP Encapsulation
Date: 12 Nov 92 08:26:46 -0600
Organization: Minnesota State University System


I am new to this particular news feed so this may have been asked in the past.
I am not very familiar with IBM host equipment either.

I am trying to provide mainframe connectivity to a number of remote sites. 
Most of the sites have IBM 3174 (or compatible) remote controllers for SNA
communications.  This comm. takes place over multidrop 9600 bps lines.  We are
in the process of installing T1 circuits to all of those same locations.  The
T1's are primarily IP.  Does software exist for the 3174 to allow SNA
encapsulation in IP packets?  I have seen hints of this scenario on some of the
news feeds but I am not sure which ones.  Any help with this would be greatly
appreciated.

 -- Al
Xref: sparky comp.protocols.tcp-ip:5107 comp.protocols.tcp-ip.ibmpc:6187 comp.sys.novell:9242
From: ben@datacomm.ucc.okstate.edu (Ben James)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject: ODITRPKT almost working but need help!
Date: 10 Nov 92 02:23:15 GMT
Article-I.D.: unx.1992Nov10.022315.21014
Organization: Oklahoma State University, Stillwater, OK

Description of my testing methods.   

When trying to open a telnet connection with CUTCP I sent out 11 perfectly 
formed ARP packets.  With our general datacomm Sniffer I can see these packets
go out and also see responces to them.  Therefore send works for ARP.

Now I load up the Netcure software on my driver and retransmit those packets 
that were captured from before.  The ones to my mechine show up in netcapt so 
conclusion receive works for ARP.

Now I load up ibmtoken on a mechine and do a telnet session to get data loaded
into the sniffer quit and load up oditrpkt and netcapt.  Transmit data from 
sniffer back threw my driver into netcapt.  Go into netview and IP/TCP packets
look OK.  Conclusion Driver receives IP/TCP packets ok.

Summary 
ARP 	transmit and receive work
TCP/IP	only receive works

My guess is that TCP/IP traffic is getting stopped at the lsl or mlid since I 
never see a packet go out on the wire.  There have been two times when I
actually got a TCP packet out on the wire.

The only difference in the way I treat ARP and TCP/IP in my sending routine is	I change the hardware type in the ARP packet on transmit and receive and I 
reduce size to eliminate excess on incomming arp_packets.  I also round all
incomming packets up to 60.  I am doing raw receives, but I am giving a  
specific StackID on sends although I have only bound a prescan stack.
I have tried raw sends, default and prescan stacks.  I have also tried 
binding a perticular stack but I had less success there.  

Question:  Are the stack ID's the same as the ProtocolID's? 
	Is it necessary to bind a stack to send things?  
	Why would ARP work and TCP/IP not work.    
	Does anyone have any suggestions on things to try?  
	Seen something simular before?

I am also in need of Tools and ideas for debuging.  Anyone know of any shims
that I can fit into here to gain more knowledge on where the packets are getting
lost?

All speculations, ideas, and any other help greatly appreciated.

Ben James
ben@datacomm.ucc.okstate.edu
From: vlei@acp.amdahl.com (Veng Lei)
Newsgroups: comp.protocols.tcp-ip
Subject: tcp/ip network performance
Date: 11 Nov 92 19:13:16 GMT
Article-I.D.: JUTS.9a8n02mN2aP501
Reply-To: vlei@acp.amdahl.com (Veng Lei)

Could someone points to me where I can find infomation or
discussion related to IP network (for both dialup and leased
line cases) performance.

Thank you.

Veng Lei
Amdahl Corporation
Newsgroups: comp.protocols.tcp-ip
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Is telnet protocol documented?
Date: Fri, 13 Nov 1992 20:33:09 GMT
Organization: U of Toronto Zoology

In article <1391@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
>...except that when the connect() returned success and the program
>wrote something down the line, instead of a "login:" that I get when I
>type  "telnet  %s",  it  gets  utter  garbage.   The  garbage is quite
>consistent:  It consists of the 3 bytes FF FD 18...

Uh, telnet is a *protocol*; it is not an uninterpreted data path.  You're
looking at a telnet option-negotiation sequence.

>Any idea how I might get documentation of telnetd's protocol? Is there
>an RFC on it that someone can email me? ...

You get documentation on telnet the same way you get documentation on
any of the Internet protocols:  read the relevant RFCs.  For telnet, it
starts with RFC 854.  Actually, you probably want to look at the telnet
section of RFC 1123 first, as there are a whole bunch of telnet-related
RFCs and you need to know which ones matter.
-- 
MS-DOS is the OS/360 of the 1980s.      | Henry Spencer @ U of Toronto Zoology
              -Hal W. Hardenbergh (1985)|  henry@zoo.toronto.edu  utzoo!henry
Newsgroups: comp.protocols.tcp-ip
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: TCP-IP implemented in Streams ?
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 10 Nov 1992 17:37:30 GMT

In article <STEINAR.HAUG.92Nov10155519@delab.sintef.no>, Steinar.Haug@delab.sintef.no (Steinar Haug) writes:
> >    Is there anybody who knows that if the TCP/IP in Sun O.S. Release 4.1.1 
> >  is implemented in Streams mechanism ?
> 
> No, the SunOS 4.1.1 TCP/IP is basically a Berkeley (i.e. socket) based
> implementation, with streams layered on top of sockets.
> 
> Solaris 2.0 is a native streams implementation, with (as far as I know)
> sockets layered on top of streams.


I don't know about Solaris 2.0.   However, the TCP in SVR4.1 and beyond
seems to be a combination of versions of 4.3BSD around the net-1 release
that have been "stream-ized."   This observation is based on side-by-side
comparisons of the source.


Vernon Schryver,  vjs@sgi.com
From: CIR_TLW@VAX1.UTULSA.EDU (Tristia Watson)
Newsgroups: comp.protocols.tcp-ip
Subject: TCP/IP Print Drivers?
Date: 13 Nov 1992 14:40:07 -0600
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu

  
  We have an problem to which we are sure there has to be a solution...but
  have no idea what that solution might be...
  
  We have a Zenith 486, with a Cabletron Card (network connection) and we
  would like to print from Windows 3.1 to a DEC LPS400 using TCP/IP
  connections.  We would like to be able to do this without Pathworks or
  Novell or any kind of other "formal" network...besides TCP/IP.  The problem
  that we are seeing is that Windows doesn't have the necessary print
  drivers.  Are there any TCP/IP-only drivers that might help, either public
  domain or otherwise?  Any other ideas that might be useful?
  
      +---------------------------------------------------------------------+
      | Tristia Watson                              CIR_TLW@VAX1.UTULSA.EDU |
      | Client Support Coordinator                     HELP@VAX1.UTULSA.EDU |
      | Computing & Information Resources Help Desk        Phone:  631-3500 |
      +---------------------------------------------------------------------+
From: tm8t+@andrew.cmu.edu (Tod McQuillin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Transfer of 100's of MBytes files
Date: 6 Nov 92 17:39:36 GMT
Article-I.D.: andrew.8eyndsC00XQDELNoRM
Organization: Carnegie Mellon, Pittsburgh, PA

rjberke@berke.itg.ti.com (Richard Berke) writes:
> How often (1 out of 20?) do you run into aborted transfers that 
> have to be restarted from scratch?

Pretty often.  Especially with large files transferred over a SLIP
link.  I'd say 1 out of 50 times over SLIP, and 1 out of 200 on more
permanent connections.

>				      Have you been able to distinguish
> what portion of those failures are due to disk issues, circuit failures,
> or protocol implementations?

In my experience, TCP is an extremely reliable protocol.  Aborted
transfers are almost always caused by network hardware problems, or
routing difficulties.

> I am frequently asked about the reliability of using FTP to move
> files and/or sets of files that are 200-400 Mbytes, and there's interest
> in some means of recovering from a disruption in the middle of a transfer.

You can always check that the transfer was successful by taking the
checksum of the data on both ends.  The more recent implementations of
the FTP protocol I've seen all support the "reget" command (I believe
the FTP spec calls this "RETR") which allows you to resume an
interrupted transfer.  I use it all the time and have never had a
problem with it.

> I'm sensitive to disruptions, but wary of exotic schemes to recover.

I'd hardly call the reget command exotic.

> Since our world-wide links are as small as 56 Kbits/sec, transmission times
> are significant.  Good throughput for FTP (not best case) is about 5 Kbytes
> per second.  200-400 Mbytes takes 1-3 hours or more.  Detection of failed 
> transfers may be delayed, further adding to wall clock time taken to 
> accomplish the overall transfers.

You have a point there.  The reget command does not automatically work
-- you have to type it yourself.

> I've heard that protocols exist for transfers that use checkpoints and 
> can restart.  I've never heard of mainstream suppliers for them.
> Are they available?  How necessary are they, compared to FTP?

I've never had a need for something like this, but then, it sounds
like your data-moving requirements are more demanding than mine.
Newsgroups: comp.protocols.tcp-ip
From: sweeney@Ingres.COM (Tony Sweeney)
Subject: Re: TCP connect
Reply-To: sweeney@Ingres.COM (Tony Sweeney)
Organization: Ask Computer Systems Inc., Ingres Division, Alameda CA 94501
Distribution: usa
Date: 9 Nov 92 14:47:22 GMT

I wrote:
>In article <Bx66Jn.D6@ushiva.wariat.org> raw@ushiva.wariat.org (Roland Wilcher) writes:
>>
>>Some time ago there was a question about checking for a TCP connect
>>to a possibly non functioning machine without the long wait.
>>An answer was posted using connect with nonblocking mode. I don't
>>have that article now but would appreciate any pointers . Target
>>system would be Esix SVR4 using the socket libraries and TCP/IP.
>>
>>-- 
>>Lack of skill dictates economy of style.             raw@ushiva.ncoast.org
>>- Joey Ramone                                        raw@ushiva.wariat.org
>>Roland A. Wilcher                         6207 Luther Ave. Cleve Oh. 44103 
>>---------------------------------------------------------------------------
>
>
What I meant to say was - here is some code I wrote to tickle a bug
in Apollo DomainOS 10.4 tcp. Should fail at the connect() on any
working system.

--------------------------cut here--------------------------------
#include <stdio.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <fcntl.h>

main()
{
struct sockaddr_in s, peer;

int sock, namelen;

int maxfd=FD_SETSIZE;
fd_set inbits, outbits, errors;

struct timeval tims;

/* code starts here... */

FD_ZERO(&inbits);
FD_ZERO(&outbits);
FD_ZERO(&errors);

bzero((char *)&s, sizeof(s));

s.sin_family = AF_INET;
s.sin_addr.s_addr = inet_addr("127.0.0.1"); /* loopback */
s.sin_port = htons(12345);	/* any bogus value will do */

sock = socket(s.sin_family, SOCK_STREAM, 0);

if( sock < 0 )
        {
                perror( "socket" );
                exit(1);
        }

        /* set for non-blocking */

if (fcntl( sock, F_SETFL, O_NDELAY ) < 0)
	{
                perror( "fcntl" );
                exit(1);
        } ;

if (connect(sock, (struct sockaddr *)&s, sizeof(s)) < 0)
	{
	if (errno != EINPROGRESS)
		{
		perror("connect");
		exit(1);
		}
	}

tims.tv_sec=4;	/* select times out after 4 seconds */
 
if (select(maxfd, &inbits, &outbits, &errors, &tims) < 0)
                {
                perror("select");
		exit(1);
                }

namelen=sizeof(peer);

if (getpeername(sock, (struct sockaddr *)&peer, &namelen) < 0)
	{
	printf("Correct: no peer\n");
	}
else
	{
	printf("getpeername thinks it is connected to %s:%d\n",
		inet_ntoa(peer.sin_addr.s_addr), peer.sin_port);
	exit(1);
	}


exit(0);
}


Newsgroups: comp.protocols.tcp-ip
From: sgriffee@nynexst.com (Steve Griffee)
Subject: remote tcp/ip LAN access ideas
Organization: NYNEX Science & Technology, Inc.
Date: Fri, 13 Nov 92 18:31:28 GMT

thanks
Steve

The opinions above are my own and do not reflect those of my employer.
_________________________________________________________________
Steve Griffee  sgriffee@nynexst.com  NYNEX Science and Technology
Data & Information Services          500 Westchester Avenue
914-644-2531  fax: 914-644-2301      White Plains, NY 10604

This is your email.  This is your brain on email.  Any questions?
-- 
The opinions above are my own and do not reflect those of my employer.
_________________________________________________________________
Steve Griffee  sgriffee@nynexst.com  NYNEX Science and Technology
Data & Information Services          500 Westchester Avenue
Newsgroups: comp.protocols.tcp-ip
From: rjberke@berke.itg.ti.com (Richard Berke)
Subject: Transfer of 100's of MBytes files
Organization: Electronic Communications
Date: Thu, 5 Nov 1992 21:17:58 GMT

What are some customers' experiences with transfering large files
between sites using FTP?  

How often (1 out of 20?) do you run into aborted transfers that 
have to be restarted from scratch?  Have you been able to distinguish
what portion of those failures are due to disk issues, circuit failures,
or protocol implementations?

I am frequently asked about the reliability of using FTP to move
files and/or sets of files that are 200-400 Mbytes, and there's interest
in some means of recovering from a disruption in the middle of a transfer.

I'm sensitive to disruptions, but wary of exotic schemes to recover.
Since our world-wide links are as small as 56 Kbits/sec, transmission times
are significant.  Good throughput for FTP (not best case) is about 5 Kbytes
per second.  200-400 Mbytes takes 1-3 hours or more.  Detection of failed 
transfers may be delayed, further adding to wall clock time taken to 
accomplish the overall transfers.

I've heard that protocols exist for transfers that use checkpoints and 
can restart.  I've never heard of mainstream suppliers for them.
Are they available?  How necessary are they, compared to FTP?

Thanks,

Richard Berke   RBRK   Richard.Berke@lobby.ti.com  (214) 575-2828
Texas Instruments      Plano, Texas
-------------------------------------------------------------------------