HDTenEightyP/NetNews huggingface dataset:
From: booloo@framsparc.ocf.llnl.gov (Mark Boolootian)
Newsgroups: comp.protocols.tcp-ip
Subject: Why UDP was slower than TCP using ttcp
Date: 26 Aug 92 22:06:29 GMT
Organization: Lawrence Livermore National Laboratory

Someone asked me to summarize the answer to my question:  Why, when running
over FDDI, was UDP slower than TCP for a Cray X/MP sending to a Sun 4/680 (
using ttcp)?

I left out one piece of information which appears to be the answer:  I did
*not* fire up a receiver.  I simply sent from the Cray to another unsuspecting
machine.  After posting and getting a few responses (each of which talked
about over-running the receiver), I reran my tests with a receiver in place
and, sure enough, the data rates were as one would expect (I measured the
Cray sending around 64 mbits/second).  My guess is that sending to a machine
with no receiver was causing the receiving machine to generate ICMP
port-unreachable (or some such) error messages, and these were slowing down
the transfer.  Admittedly, this seems a little thin in terms of an
explanation (at least it does to me), but it sure sounded convincing to
those around me asking me to explain what the heck was going on...

thanks,
mb
-- 
Mark Boolootian		booloo@llnl.gov		+1 510 423 1948

"I don't know that atheists should be considered citizens, nor should they be 
considered patriots.  This is one nation under God." - George Bush 8/27/88
Newsgroups: comp.protocols.tcp-ip
From: pae@blackcat.stortek.com (Phil Earnhardt)
Subject: Re: Implementation of Distributed Database in SUN RPC
Organization: StorageTek, Louisville, CO
Date: Mon, 31 Aug 1992 18:53:38 GMT

In article <1992Aug31.010015.1275@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes:
>axk7110@usl.edu (Khanna Alok) writes:
>>I am working on implementation of a small model of distributed database.  I
>>am planning to use SUN RPC for communication between different clients and
>>servers.
>
>Unless it's just going to be a toy, good luck. There are two main problems
>with Sun RPC for doing this: a) Unless you're using a multi-threaded RPC
>server, the server will fairly quickly become the bottleneck.

Do you really mean multi-threaded here? Most UNIX platforms still lack kernel
support for multi-threading. It sounds like this is a moot issue in this
context.

Sun does supply something that looks a lot like multi-threading for its NFS
server. At initialization time, n NFS servers are forked. When idle, all of
the clients are blocked in a read() on the same UDP socket. Aesthetically,
it's ugly, but it does work. Is there some reason that Khanna couldn't use the
same trick in his code? Is this something that real users can't do without
excessive modification?

>b) Since RPC does retransmit if it doesn't get an answer "fast enough" in
>case 'a' above, you may get multiple retransmits. The server then blindly
>redoes operations, unless you wind up writing a reliable delivery system, or
>using TCP RPC or something else.

Using TCP isn't the worst thing in the world, provided you're not establishing
and tearing down connections on each transaction.

>Generally, there are enough problems with using RPC (all fixable) that for
>anything other than a toy, by the time you've fixed them all, you might as
>well have not used RPC.

Are you talking about ONC RPC, or all RPCs in general?

Netwise's RPC TOOL has certainly addressed the issue of different styles of
dispatching...there are single-threaded dispatchers, multi-processing
dispatchers (forking off a process for new requests) on systems providing
multi-processing, and multi-threaded dispatchers (spawning a new thread for
new requests) on systems providing multi-threading capabilities.

RPCs do seem to take about a 2x hit in throughput vs. hard-coding your network
application. If that's important in your application, then don't use RPCs.

>mjr.

--phil
pae@blackcat.stortek.com
Newsgroups: comp.protocols.tcp-ip
From: hoang1@litwin.com (Dave Jackson)
Subject: ioctl request SIOCGARP fail in SCO (ARP protocol)
Organization: Litwin Process Automation
Date: Fri, 28 Aug 1992 17:49:57 GMT

Hi,
I'm writing a program to read the ARP cache.
But I have the problem when using SIOCGARP in SCO/ODT ver 2.0:
  
  .
  .
  .
  int soc;
  struct arpreq ar;
  .
  .
  .
  /*
  **  Execute the IOCTL to read the ARP cache, if the host is not
  **  currently in the cache, this ioctl will fail.
  */
  if ((i = ioctl( soc, SIOCGARP, &ar )) != 0)

  It's always failed and return:
    errno == ENXIO
    ioctl: No such device or address

But if I test in DEC5000/200 Ultrix 4.2 or SUN/sparc OS 4.1.1 is ok.

Do I miss anything in SCO env.

I will post or mail my source code if you request.

Thanks in advance,

Ted Hoang
Litwin Process Automation
Email:hoang1@dynsim1.litwin.com
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Why does my slip line die overnight?
Date: 31 Aug 1992 05:27:29 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com
Keywords: slip

>In article <1992Aug30.205245.29936@psg.com> randy@psg.com (Randy Bush) writes:
>ghawkins@unix1.tcd.ie (George C. Hawkins) writes:
>> When I leave my machine overnight and come back in the morning I
>> find my slip connection has died on me.
>
>We see the same thing here in Orygun's RAINet.  We believe (urban legend)
>that the telco does an 02:00 blast to clear the lines.

This is probably the same signal that causes my phone to ding in the middle
of the night.  It's a test signal that the phone company sends out, which
some phones are more sensitive to than others.

I've been told that you can call the phone company and ask them to remove
your circuit from the list that this signal is sent to.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: lars@spectrum.CMC.COM (Lars Poulsen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Secure TCP-IP
Date: 3 Sep 92 04:12:38 GMT
Organization: CMC Network Systems (Rockwell DCD), Santa Barbara, CA, USA

In article <1992Aug28.083228.16663@hplb.hpl.hp.com>
   paola@hplb.hpl.hp.com (paola fulchignoni) writes:
>Does anyone know whether a "secure TCP" or "secure IP" exist (providing
>security
>services such as access control, source authentication, integrity, etc.)?

To secure traffic at the IP level requires a trusted physical network.
The military people have made some efforts in this direction, and some
of these efforts have been picked up by the financial community.
Esentially, you put a transmogrifier (authenticator/encryptor) between
your machine and the real network. The machines on the "red" side of the
encryptor box now form a closed network of trusted hosts, and the boxes
may optionally talk to a central control center which may potetially
open windows to talk to specific hosts attached directly to the
underlying insecure "black" network in a controlled manner. Such boxes
have been seen between a host's X.25/V.35 connector and the CSU/DSU.
They have also been spotted between the host's ethernet AUI connector
and its transceiver.  This technology is expensive. And of course you
have to trust the people who sold you the box.

The transport level could easily be modified to perform an
authentication handshake with a control center at connection startup
time, but then (of course) it would not be TCP any more. The US Air
Force has done some studies of variations of this concept. (Mostly with
parallel protocol modules sitting ARP-like between TCP and IP). I don't
think this has led to any large scale implementation.

Most people put this in the application layer. Maybe the best known
example is Kerberos. There is also work being done on a secure RPC
mechanism, and thus a secure NFS. Several workstation vendors have
formed a Trusted Systems Interoperability Group to ensure that the
multiple implementations of this spec really will be interoperable.
TSIG is loosely affiliated with IETF. HP is a major participant.
-- 
/ 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
Newsgroups: comp.protocols.tcp-ip
From: sommerfeld@apollo.hp.com (Bill Sommerfeld)
Subject: Re: TCP reliability
Date: Fri, 4 Sep 1992 19:13:01 GMT
Organization: Hewlett Packard

In article <1992Sep4.162458.1@hei.unige.ch> droux@hei.unige.ch writes:

   These two entities are communicating through AF_INET family
   sockets of SOCK_STREAM type. Our Problem is, that a receiver implemented on
   a NeXT receives much more packets than the sender implemented on 
   a Sun workstation sends (1.3 : 1).

   The data exchange is made by normal read() and write() calls followed by an 
   acknowledgement. We transmitt packets of 5000 bytes of unstructered data.
   If a sender send 300 packets (as a concrete example) the receiver receives
   over 400 packets and about 120 of them are invalid. We consider this as a
   serious problem since our system is based on realibility of TCP sockets.
   Is there a special option on sockets or another method to avoid these
   problems?

No, you have a fundamental misunderstanding about TCP.

TCP is byte oriented, not "record" or "packet" oriented.

With sockets, when you do a read() on a TCP socket, your process
either blocks until something is available, or returns immediately
having read the data immediately available (or a prefix of it, if you
passed a buffer shorter than the amount queued for read).

If you want to do record-oriented things over TCP, you have to define
your own record boundaries (e.g., with a byte count followed by the
bytes), and count carefully on the receive end.

					- Bill
From: neeraj@metrix.UUCP (Neeraj Sangal)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Monitor program for catching duplicate IP addrs?
Date: 3 Sep 92 14:37:35 GMT
Reply-To: neeraj@metrix.UUCP (Neeraj Sangal)
Organization: Metrix Network Systems Inc.

> Does anyone know of a utility program that will scan an Ethernet
> and build a table of IP # to ethernet # mappings and check for
> duplicate IP #s?  Thanks for any info,
> I was wondering if there is anything like this for Suns running SunOS 4.1.1?

You can use the NetMetrix Load Monitor to detect duplicate IP addresses.
The NetMetrix Load Monitor maintains a pretty complete mapping of MAC
and Network Addresses seen on the network and can be used to detect
duplicate addresses for most major protocols. NetMetrix runs on SunOS 4.x.x.

Neeraj Sangal
Metrix Network Systems, Inc.            1 Tara Blvd, Nashua, NH 03062
neeraj@metrix.com                       (603) 888-7000
From: ad0@cbnewsj.cb.att.com (amarjet.dhingra)
Newsgroups: comp.protocols.tcp-ip
Subject: ksh history and .nfs* files question
Keywords: ksh,nfs
Date: 1 Sep 92 21:14:47 GMT
Organization: AT&T

Please email your help directly to att!mtgzfs3!ad0

Occassionly, ksh loses history and I noticed that sometimes the commands
that I am giving are going into a file that has name like .nfs34D5 (.nfs*).
Then at some point in time this file goes away and so does part of
history and I am back to a file upto 2 days old.  I think it happens
after our weekly reboots of the server SUNs when every workstation
is rebooted automatically.  I just use the default history file name.

Any ideas for fixing this problem?

Thanks in advance.

Amarjit
Newsgroups: comp.protocols.tcp-ip
From: aep@world.std.com (Andrew E Page)
Subject: Text/Book recommendations for TCP-IP
Organization: The World Public Access UNIX, Brookline, MA
Date: Wed, 26 Aug 1992 15:10:11 GMT

    Does anyone have any recommendations for a good book on TCP-IP
protocol(s), implentations, use/abuse, etc.  I'm looking at debugging
som hardware/firmware that may not be implementing the protocol properly.  

DoD# 0581   1990 Suzuki VX800   MSF Intro Class Aug 1990

-- 
Andrew E. Page CTO(Warrior Poet)|   Decision and Effort The Archer and Arrow
DSP Ironworks                   |     The difference between what we are
Macintosh and DSP Technology    |           and what we want to be.
From: claude@trc.mew.mei.co.jp (Claude Huss)
Newsgroups: comp.protocols.tcp-ip
Subject: TCP/IP source
Date: 31 Aug 92 07:39:06 GMT
Distribution: comp
Organization: Matsushita Electric Works Ltd., Tokyo, Japan.



	Does anyone know about companies selling TCP/IP source code?

	Thank you in advance,

--
+----------------------+-----------------------------------------------------+
| Claude Huss          | Matsushita Electric Works, Ltd. Tokyo Research Labs.|
| Networking Engineer  | Mita 5-13-2, Minato-Ku, Tokyo 108, JAPAN            |
|                      | Phone: +81-3-3452-4941 Fax: +81-3-3451-0793         |
+----------------------+-----------------------------------------------------+
| Disclaimer:"Any comments for my company > /dev/null"                       |
+----------------------------------------------------------------------------+
             Gaijin Touroku Card: Don't leave home without it!
Newsgroups: comp.protocols.tcp-ip
From: weber@world.std.com (Bob Weber)
Subject: location of various address space proposals
Organization: The World Public Access UNIX, Brookline, MA
Date: Fri, 4 Sep 1992 02:57:23 GMT

is there someplace where the various proposals to the ietf
regarding solutions to the problem of exhausting the ip address
space are available via anon ftp?
thanks
Bob Weber
-- 
------------------------------------------------------------------------
Robert Weber                       Voice: 617/570-0791 
Northeast Consulting Resources     Fax:   617/523-0150 
85 Devonshire Street, 4th floor   
Xref: sparky comp.protocols.tcp-ip:4306 comp.unix.sysv386:14046
From: ejcsci@engr.uark.edu (Ed Cooley (sci386))
Newsgroups: comp.protocols.tcp-ip,comp.unix.sysv386
Subject: ISC V3.0 TCP Problems
Summary: TCP Problems using ISC V3.0
Keywords: TCP/IP, ISC, TELNET
Date: 4 Sep 92 19:24:27 GMT
Article-I.D.: engr.1992Sep4.192427.16956
Organization: University of Arkansas

We are having two problems with an installation of TCP/IP on ISC UNIX V3.0

1 - Telnet are getting a Connection closed by foreign host.  This only 
occurs on the vt (virtual terminals) or standard terminals running multiview.
It even occurs with a loop-back telnet connection.

2 - We are getting blocked at some gateway.  Here at the U of A, we have
access past our gateway to other machines on campus, but get timeouts 
when trying to ping, telnet, ftp off campus.

Any help or ideas would be greatly appreciated.

Thanks in advance,
Ed Cooley

Please respond to ejcsci@engr.uark.edu
From: ian@spider.co.uk (Ian Heavens)
Newsgroups: comp.protocols.tcp-ip
Subject: Traffic characteristics by application
Date: 23 Aug 92 21:25:07 GMT
Organization: Spider Systems Limited, Edinburgh, UK

I'm interested in anything published on traffic characteristics of
TCP and UDP based applications, including

- distribution of packet size
- lifetime of a connection
- characteristics of different types of connection
- frequency of packet generation over the lifetime of the connection.

Ideally, one could define benchmarks which measured performance of a TCP/IP
stack in a way reflecting different types of real usage.  Has anyone done this?
I believe that bulk data transfer on a single connection is the usual quoted
benchmark, using ttcp (I know there are NFS benchmarks around).  

Telnet and ftp are examples which are fairly obvious, but NFS, OLTP, etc.,
etc., would be very interesting.

In addition, is the efficiency of protocol processing best reflected by
throughput per unit of CPU usage (as reported by ttcp)?  Any other factors
that are relevant?

Thanks


ian

---
Ian Heavens				ian@spider.co.uk                 
Spider Software
Spider Park, Stanwell Street		
Edinburgh, EH6 5NG, Scotland		+44 31 555 5166 (Ext 4347)
--
Newsgroups: comp.protocols.tcp-ip
From: stevea@i88.isc.com (Steve Alexander)
Subject: Re: ioctl request SIOCGARP fail in SCO (ARP protocol)
Organization: INTERACTIVE Systems Corporation, Naperville, IL
Date: Mon, 31 Aug 1992 13:51:59 GMT

In article <1992Aug28.174957.2213@litwin.com> hoang1@litwin.com (Dave Jackson) writes:
>Hi,
>I'm writing a program to read the ARP cache.
>But I have the problem when using SIOCGARP in SCO/ODT ver 2.0:

In SCO UNIX, you cannot issue arp ioctls on a socket, due to underlying
architectural issues in the STREAMS implementation.  The way to do this
is to open the ARP driver, and issue the ioctl as part of an I_STR 
(see streamio(M)).

Here's a code fragment that might help.

#include <sys/stropts.h>
#include <sys/stream.h>
#ifndef _PATH_ARP
#define _PATH_ARP "/dev/inet/arp"
#endif

	.
	.
	.

        struct strioctl strioc;
        int s;
        int r;
	struct arpreq ar;
        if ((s = open(_PATH_ARP, O_RDWR)) < 0) {
                perror(_PATH_ARP);
                exit(1);
        }
        strioc.ic_cmd = SIOCSARP;
        strioc.ic_timout = 15;		/* seconds */
        strioc.ic_len = sizeof(ar);
        strioc.ic_dp =  (caddr_t) &ar;
        r = ioctl(s, I_STR, (caddr_t) &strioc);
	if (r < 0) {
		perror("SIOCSARP");
		exit(1);
	}
        close(s);


-- 
Steve Alexander, Software Technologies Group    | stevea@i88.isc.com
INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea
Newsgroups: comp.protocols.tcp-ip
From: eajjs@cbnewsf.cb.att.com (john.sottile)
Subject: Re: Why does my slip line die overnight?
Keywords: slip
Organization: AT&T
Date: Tue, 1 Sep 1992 17:06:24 GMT

In article <z5h1H206b9@atlantis.psu.edu> barr@pop.psu.edu (David Barr) writes:
>In article <1992Aug30.205245.29936@psg.com> randy@psg.com (Randy Bush) writes:
>>ghawkins@unix1.tcd.ie (George C. Hawkins) writes:
>>> When I leave my machine overnight and come back in the morning I
>>> find my slip connection has died on me.
>>
>>We see the same thing here in Orygun's RAINet.  We believe (urban legend)
>>that the telco does an 02:00 blast to clear the lines.
>
>Yep, i've seen similar experiences here, only here it's around 1:30.
>It won't necessarily be all the lines, but a significant portion of them.
>


Between the hours of 2am and 5am, the telecos telephone switches go into
diagnostics.  On older switch types (analog) can get noise on the
line when this happens, but it doesn't last long (the noise).

The dropped line is purely UNintentional.  The switches must go through
diags and 2am is a good time to start.  

Also, when switches are upgraded (software or hardware), the telco will
"Phase" a machine to get it to start with the new load.  98% of the time
no calls are dropped, however, if something went wrong with a load,
the machine will recover and a few calls could be dropped.  Usually,
the recovery will drop all calls, but not always.

I would suspect a PBX first (reacting to stuff on the line) before
the telco.  :-)

=============================
John Sottile                             "That Guy has to Oil his Brakes!"
AT&T Bell Labs                           #include <std/disclaimer/who-me?.h>
jjs@cblph.att.com

Let me add this:
I don't speak for AT&T and the ideas presented here are my own from my
own observations.
From: leonard@telcom.arizona.edu (Aaron Leonard)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Broadcasting and Subnets
Date: 3 Sep 92 16:07:33 GMT
Article-I.D.: arizona.1992Sep3.090735.3657
Reply-To: Leonard@Arizona.EDU
Distribution: world,local
Organization: University of Arizona Telecommunications

In article <184hnoINN7tu@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
| 
| In article <2490@cronos.metaphor.com> pstevens@Metaphor.COM (Paul Stevens) writes:
| >When I want to send a broadcast packet to all stations on a net or
| >subnet I set the IP address so that it contains the network/subnet
| >numbers but set the host portion to all 1's.  This is, of course,
| >net/subnet OR'ed with the inverse of the subnet mask.  Presumably 
| >this style of addressing even works for a net/subnet that might be
| >several hops away (i.e. the routers along the route will use the 
| >net/subnet fields of the IP address to route the packet to the proper
| >net/subnet).  My basic question concerns how to get a the correct
| >subnet mask.
| 
| There's no common method for this.  In general, hosts are only expected to
| know the subnet mask for their local networks.  Hosts are only supposed to
| use subnet masks to determine whether a destination can be reached directly
| or must go via a router.  All non-local addresses are equivalent to hosts.
| 
| Recent routing protocols transmit subnet masks along with routes, but these
| are intended only for use by routers, not individual hosts.
| 
| Sending broadcasts to remote networks is frowned upon, so there's no
| special support to make it easy.  If you want to do it, you're on your own
| for a mechanism to learn the appropriate broadcast address for that subnet.

The best and easiest approach is just to use ALL 1's (255.255.255.255) as your
broadcast address.  That way you don't have to worry about your subnet mask,
or for that matter even what your own IP address is.  Recommended by 
RFC-1122, sec. 3.3.6 (discussion section.)

This won't let you send a broadcast to a remote network, of course, but that
won't work anyway.  Use multicast for this.

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
|>   If it ain't broke, break it.
From: dsc3jfs@nmrdc1.nmrdc.nnmc.navy.mil (Jim Small)
Newsgroups: comp.protocols.tcp-ip
Subject: slip over tcp
Date: 27 Aug 92 20:21:42 GMT
Organization: Naval Medical Research & Development Command


I have a use for SLIP over TCP, instead of over a tty.  Is there any
existing code that will do this?   It will most likely be running on
an AIX system for what it's worth . . . .
-- 
I love the 3b2
The 3b2 is my friend.
Newsgroups: comp.protocols.tcp-ip
From: vances@xenitec.on.ca (Vance Shipley)
Subject: Re: Information on Standard Trunk Protocol wanted
Organization: SwitchView Inc., Waterloo, Ontario
Date: Sun, 30 Aug 1992 16:15:34 GMT

In article <BARNETT.92Aug24091154@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes:
>I am trying to get information on Unix versions of Standard Trunk
>Protocol (or System Trunk Protocol) - also known as STP. In
>particular, I am interested in free or commercial implementations of
>this protocol for UNIX systems.
>
>It is a telecom protocol over a 9.6kb link.
>
>Please repy by e-mail. Thanks.
>--
>Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett


Bruce,

Since I saw you ask this question a few weeks ago I assume you aren't
getting too many responses, so I'll toss in my two cents worth.

I have never heard of "Standard Trunk Protocol" (or "System Trunk Protocol").
Not knowing what context you ask this question in I may be off the mark here
but let me point out a couple of things I do know.

In the public switched telephone network groups of trunks connecting switching
machines have their control signals (connect, disconnect,etc.) passed over
"out of band" data links.  These data links are typically 9.6K although they
can be 56K.  The protocols used are SS7 (Signalling System Seven) and  SS6. 
SS7 is not ubiquitous yet, SS6 is the norm.  SS6 is also reffered to as CCIS
which I beleive stands for Common Channel Interoffice Signalling.  These links
connect two main machine types; STP (Signal Transfer Point) and SSP 
(Service Switching Point).  

So in reading your message I wonder if you are not looking for the SS7 (or SS6)
protocol that is commonly used by STP's.  

Incidently I have been to your facility.  I work for SwitchView.  SwitchView is
a Unix based network management system for telephone networks.  Our system is
used to monitor your Northern Telecom PBX's.

Let me know if there is any thing I can do for you.

-- 
Vance Shipley 
vances@xenitec.on.ca   vances@ltg.uucp   ..uunet.ca!xenitec!vances
Newsgroups: comp.protocols.misc