# The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1991)
DOCUMENT: TCP-IP Distribution List for September 1991 (403 messages, 242504 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1991/09.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 Sep 91 03:51:57 GMT
From:      wilbur!wndrsvr!andyb@ism.isc.com (Andy Brager)
To:        comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   PPP for ISC Unix V.3.2.2.1


Greetings netters.

Does PPP exist for ISC Unix V.3.2.2.1  ?
Does anyone know where I could get a copy?

Thanks!!

Andy
--
If I bounce, please send a copy of the *whole* message including
the headers, to andyb@stb.info.com.  Thank you.


-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 91 19:46:53 GMT
From:      urlichs@smurf.sub.org (Matthias Urlichs)
To:        comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

In comp.protocols.tcp-ip, article <2424@crackers.clearpoint.com>,
martillo@crackers.clearpoint.com (Martillo) writes:
< and should a developer implement this interface for his
< bridge, router or end host, that network device will be able to
< communicate with the Little Dipper/Auriga products over point-to-point
< serial links as well as any other device which implements this
< specification.  Comments on this draft are welcome.
<
One question: I couldn't find anything in these proposals that isn't covered
by RFCs 1171 and 1220..?

Sure, PPP is a tad more work to implement (especially link setup), but we're
talking WANs here and I suggest that the features (identification, link
quality monitoring, et al) are worth the investment.

Substituting sync for async lines in RFC1171 is left as an exercise for the

--
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/


-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 91 19:50:29 GMT
From:      pcg@aber.ac.uk (Piercarlo Antonio Grandi)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

scogen@xenitec.on.ca (scogen@xenitec.on.ca) writes:

> We are trying to configure an SCO Unix system running some type of
> IP, (maybe TCP, maybe UPD) to operate at maximum throughput. Our goal
> is to get up to _6_ Megabits/Sec.

Well, nearly any modern Ethernet card will deliver 6 Megabits per second.
After all it's only around 600KB/s. SCO's TCP protocol stack will most
probably not be able to keep up with the card though.

> We realize that we need EISA bus machines with 32-bit Ethernet cards to do
> this.

Why ever? The 16 bit ISA bus runs at 8Mhz and transfers 16 bit across.
Taking account of all hw protocol overheads it can sustain between 5-6 MB per
second. Here you are proposing to load it with just 600KB/s, which is one
tenth of its top capacity. Think of this: my VGA card will, during continuous
graphics operation, sustain 2MB/s over the ISA bus, and my SCSI controller
will get 1.4MB/s sustained from a SCSI disk.

32 bit EISA Ethernet cards are an expensive joke, as is any "turbo" interface
between a 40MB/s 32 bit bus (EISA) and a 0.8MB/s 1 bit one (Ethernet).

Same goes for EISA SCSI disk controllers (the most expensive SCSI disks
top out at 4MB/s, and most cannot do more more than 1.5MB/s off the
platter). In practice EISA is only needed for very high speed graphics
(good luck with that) and for disk arrays, or, theoretically, for very
high bandwidth tapes.

The real benefits of EISA, for most people, are not in bandwidth, but
in configurability and interrupt sharing and multiple mastering, where
the ISA bus is badly misdesigned.

> Another important detail is that each computer will be talking over a
> Cisco router with one ethernet card per computer.

Note that you need an Ethernet card per computer anyhow :-).

Probably what you mean is that you will have a separate Ethernet cable per
computer. This of course means that each machine would have its own 0.8MB/s
Ethernet dedicated to itself. The problem is that I doubt very much that
this would buy you anything at all, as I would expect the CISCO router not
to be able to sustain more than 0.8MB/s aggregate anyhow, as routers are
normally not designed to sustain the maximum combined bandwidth of all the
Ethernets they link. Does anybody know for sure what is the maximum thruput
of a CISCO router?

I expect that in practice having a star configuration with a router in the
middle and an Ethernet to each machine will probably buy you nothing at all,
except having a single active failure point.

> This way we completely eliminate packet collisions.

This is probably completely unnecessary. Collisions are very rarely a
problem, the Ethernet will in practice share out its capacity between
machines in only slightly less than linear fashion, if packet sizes are not
too small.

If you really want for some funny reason a star configuration, with an
active hub, and no collisions and guaranteed point-to-point capacity,
consider seriously getting a Token Ring.  At least Token Ring active hubs
are designed for this task, and not as routers, and tend to be fairly fail
safe too.

> They also told us about their ES3210 card, which they claim can
> operate at _13_ Megabits/Sec. I thought that the cable can't operate
> faster than 10 Megabits/Sec. Am I missing something?

Well, they are telling you nice numbers out of thin air.

> How do I get real numbers that will tell me what to expect in the field?

Toss a coin... :-)

> I don't know how obvious my lack of network expertise is,

Very obvious. :-). But at least you know. Some other poster who also replied
to your article is not in a much better position than yourself, but does not
know. :-)

> but if you see any questions that I'm not asking, I need to know that
> also. I'm sure I'm not asking everything I need to know.

Well, now that I have answered your questions, let's tell you something more
useful.

First of all, the good news: as I have said almost any modern Ethernet card
will deliver substantially all of the Ethernet bandwidth, and this bandwidth
is at worst one fifth of the ISA bus bandwidth, so you don't need any EISA
machine.  Collisions will be in practice not a problem. You probably don't
need a CISCO router at all, you can put all the machines on the same
Ethernet, if you don't need 6Mb/s sustained bandwidth between each machine,
but only aggregate.

The bad news are that the TCP/UDP/IP sw on the host, and in particular
SCO's, will have such huge overheads and misdesigns that in practice you
will not be able to use more than a fraction of the nominal speed of the
hardware. Somebody (Van Jacobson and others) have spent some serious effort
in tuning up certain implementations of TCP/UDP/IP and can boast of being
able of getting TCP/UDP/IP end-to-end connections that exploit 90-95% of the
hardware capacity, but figures like 30-50% are far more common. I don't
remember exactly, but I seem to remember that you'd be lucky to get more than
300-400KB/s end-to-end on a TCP/UDP/IP connection from SCO's Internet
protocol stack.

Finally, what you should tell us is what is your problem, e.g. how many
machines you have got to link, how far apart they are, what is the average
packet length, and what is the maximum packet rate that you expect from each
machine, and other characteristics. Once you have told this to us, we can
tell you whether Ethernet makes any sense at all. Possible alternatives are
running TCP/UDP/IP over SCSI or over several point-to-point links, e.g.
synch, or RS-422, for example.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk


-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 91 20:00:28 GMT
From:      pcg@aber.ac.uk (Piercarlo Antonio Grandi)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

bill@connection.prospect.com (Bill Poitras) writes:

> In article <1991Aug29.041708.29784@unislc.uucp> martin@unislc.UUCP (Martin Cryer,D1Z01,5754) writes:
> >I think you are asking too much of a timesharing O/S even with an EISA
> >PC to get sustained 6Mbytes/s. If you only want it for bursts, you
> >may have better luck.
>
> Are you kidding?  I have seen 100Mbytes/s when ftping a file to a PS/2
> running AIX with a ESDI controller and 16 bit ethernet controller.  I can
> consitently get 20Mbytes/s.  Hell, I can get 11Mbytes/s sometimes to a PC
> running DOS.  This is a ISA machine with a 16bit RLL controller.  I don't

Alleluiah! Alleluiah! He got a dispensation from Shannon himself! He can
shove thru an 800KB/s Ethernet and a 1MB/s ESDI device ten, twenty, one
hundred times their maximum rated capacity! He is one of the Anointed! The
last time we saw anything similar it involved bread and fish!

Amazing facts: the maximum bandwidth of the MCA bus when running at full
tilt in 32 bit mode is under 40MB/s; to have 100MB/s of transfer rate
*to memory* would require dozens of megabytes of requires hundreds of MB
of 4-way interleaved 20-30ns RAM; to be able to consistently get 20MB/s
on a TCP/IP link would require, assuming an overhead of 4 instructions
per byte passed thru (wildly optimistic, just consider checksumming), a
80Mhz CPU.

:-) :-) :-) :-) :-) :-) :-) :-)
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk


-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 91 20:17:17 GMT
From:      martillo@crackers.clearpoint.com (Martillo)
To:        comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

In article <BOB.91Aug31121320@remora.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:
> In article <2424@crackers.clearpoint.com> martillo@crackers.clearpoint.com (Martillo) writes:
>    ... [S]hould a developer implement this interface ... that network
>    device will be able to communicate with the Little Dipper/Auriga
>    products ...

> Would I still be able to communicate with members of the Little
> Dipper/Auriga product line if I don't manage to SLITHER, but instead
> only implement something like SLIP or PPP?

> Which is to say, will Clearpoint's boxes talk to the rest of the
> world?

We may not have the same view of network system architecture.
Clearpoint makes high-performance WAN/Ether bridging products (routing
will soon be available).  In the normal course of events bridges (unlike
routers) do not really talk to end hosts.  Bridges are so to speak out
of band and talk to other bridges.  Logically, all the bridges (assumed
to be running STP) and ethersegments can be replaced by a single ether
cable and no network host would notice.

To summarize: bridges are communications subnet devices and not network
hosts.  Historically, communications subnet devices have not had network
addresses and have not been reachable from network hosts.  Recently it
has become more common to implement network host functionality in
communications subnet devices, and in fact some protocols have been
developed which make the implementation of such network host
functionality useful in certain situations.  For this reason, the Little
Dipper/Auriga products support SNMP, server telnet and client telnet.

But in general, especially in more common networking environments where
TCP/IP is not used, communications subnet devices only communicate with
other communications subnet devices (except perhaps at boot time), i.e.
bridges generally talk to other bridges while forwarding or filtering
all network host traffic without actually operating on the data within
the packets which compose the traffic.  The Little Dipper/Auriga
products do communicate with all other bridges which implement 802.1d
STP.

The Little Dipper/Auriga has the capability to do SLIP and PPP.  Remote
transparent bridging using PPP (as well as remote transparent bridging
using Frame Relay and X.25) will appear shortly.  I read RFC1055 and it
looks like SLIP is targeted for slow asynchronous character-oriented
serial links.  This is not really a high-performance medium and the
protocol does not lend itself to transparent bridging and without
customer demand you would have to make an awfully persuasive case to
encourage us to provide it.

In most networking environments which I have analyzed the largest part
of the traffic is local with infrequent resort to the use of wide-area
links (of course there are some notable exceptions like airline
reservation systems and there are special features in the Little
Dipper/Auriga to handle such systems).  In the usual environments it
makes sense to add 1 to several (currently the LD supports a maximum of
3) WAN interfaces to the bridge to provide all the hosts within the
bridged environments or to a router with a WAN interface.  Providing
wide-area connectivity in this manner is cheaper than giving many
individual hosts their own wide area links especially when they would
probably use these interfaces much less than they would use their LAN
interfaces.

Reasonable possible architectures to provide WAN connectivity are:

1) Ethernet - Bridge InterWorking Unit (BIWU) - WAN Link - BIWU - Ethernet

2) Ethernet - Bridge InterWorking Unit (BIWU) - WAN Link - Router - Ethernet

3) Ethernet - Hybrid Bridge/Router (HBR) - Wan Link Network - HBR - Ethernet

4) Ethernet - Router - WAN Link - Router - Ethernet

5) Ethernet - Half-Router - WAN Link - Half-Router - Ethernet

In IP terms, architecture:

(1) corresponds to 1 IP network
and can employ the transparent bridging version of PPP or
SLITHERNET.

(2) corresponds to 2 IP networks
and can employ the transparent bridging version of PPP or
SLITHERNET.

(3) corresponds to 3 IP networks
and can employ only SLITHERNET.

(4) corresponds to 3 IP networks
and can employ the transparent bridging version of PPP, SLITHERNET
or PPP for IP.

(5) corresponds to 2 IP networks
and can employ the transparent bridging version of PPP, SLITHERNET
or PPP for IP.

Once we concentrate on high-performance networking on moderate to
high-speed synchronous serial links, only SLITHERNET is completely
flexible.  But I will gladly sell you the means to implement
architecture (5) because I can then lock you into my proprietary
implementation of half-routers.

(4) is an inefficient use of IP networks, and is an architecture which
should be discouraged.  But we will support you, if you truly want to
do it.

(3) is in most cases the most reasonable architecture when a mesh of
serial links interconnects connect several major bridged LAN sites and
only SLITHERNET supports this.  Unless a bridging device supports
SLITHERNET, there is no growth path to this architecture, and a customer
who choses bridges and routers which don't support SLITHERNET will
probably in the end have to duplicate his investment.

Now in all cases it is possible a customer truly wants to replace the
right hand half of the network with a single IP host.  If the Little
Dipper/Auriga bridging device is run in bridging mode, the single IP
host will either use PPP in transparent bridging mode or SLITHERNET.  If
the Little Dipper/Auriga bridging device is run in routing mode, the
single IP host will either use PPP for IP or SLITHERNET.  I will make
available a SLITHERNET implementation for the IBM PC in the next couple
of weeks for those people who truly wish to do this.

I should note that PPP is basically misdesigned because the latest crop
of Ethernet chips tend to support HDLC modes while the latest crop of
Serial HDLC chips tend to support Ethernet modes.  As a consequence if
SLITHERNET is used for wide area networking while ethernet is used for
local area networking, respinning ethernet software for wan uses and
respinning ethernet interfaces for wan interfaces is relatively
straightforward as well as vice versa.  PPP makes such respinning much
harder and more costly.  Basically, a customer who demands PPP is
demanding that his hardware and software cost more.  In a period of
economic retrenchment, demanding SLITHERNET makes a lot more sense
especially when SLITHERNET is a flexible architecture which provides
growth paths.

In short, there are no plans to provide SLIP because it is inappropriate
for the class of devices typified by the Little Dipper/Auriga products.
PPP for transparent bridging will be available shortly.  PPP for IP will
only become available with routing (available shortly) unless customers
start clamoring for the ability to communicate over a wide area link
solely with the network host functionality built into the bridge.

Joachim Carlo Santos Martillo Ajami

--
the author and in no way do they reflect the official opinion or policy
of Clearpoint Research Corporation.


-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 91 21:12:37 GMT
From:      karl@MorningStar.Com (Karl Fox)
To:        comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

Joachim Carlo Santos Martillo Ajami writes:

Reasonable possible architectures are:

1) Ethernet - Bridge InterWorking Unit (BIWU) - WAN Link - BIWU - Ethernet
2) Ethernet - Bridge InterWorking Unit (BIWU) - WAN Link - Router - Ethernet
3) Ethernet - Hybrid Bridge/Router (HBR) - Wan Link Network - HBR - Ethernet
4) Ethernet - Router - WAN Link - Router - Ethernet
5) Ethernet - Half-Router - WAN Link - Half-Router - Ethernet

In IP terms, architecture:

(1) corresponds to 1 IP network and can employ the transparent
bridging version of PPP or SLITHERNET.
(2) corresponds to 2 IP networks and can employ the transparent
bridging version of PPP or SLITHERNET.
(3) corresponds to 3 IP networks and can employ only SLITHERNET.
(4) corresponds to 3 IP networks and can employ the transparent
bridging version of PPP, SLITHERNET or PPP for IP.
(5) corresponds to 2 IP networks and can employ the transparent
bridging version of PPP, SLITHERNET or PPP for IP.

You should really have said "Reasonable possible *bridging* architectures",
because I suspect that the most common way of interconnecting TCP/IP
networks looks like your number (4) but where the routers have their
interfaces configured with the BSD IFF_POINTOPOINT semantics, associating
their interface with the primary (Ethernet) address of the machine at the
other end of the WAN link and providing a host route to it.  This doesn't
work with X.25, which usually requires a subnet (unless you are running it
over a point-to-point connection), but it's exactly what is intended to be
used with PPP.  It corresponds to only two IP networks; the point-to-point
link doesn't use up a subaddress.  This is what we recommend to our PPP
customers, and I believe is also what Sun recommends to their Internetwork
Router customers.

Best of all, the two ends of the circuit don't have to come from the same
vendor.  There are dozens of products you can buy *today* that work this
way.  It would certainly rub *me* the wrong way if I were Wellfleet or 3COM
and PSI or Alternet told me I had to buy a cisco router if I wanted a
connection.  It also means that PSI or Alternet can pick a router vendor
and stick with it, since their connections run a non-proprietary protocol.

I believe Bob was referring to something like this.  Coming from the TCP/IP
point of view (and not being constrained by protocol architectures that
don't scale past a LAN), he didn't see the value in bridging over routing.
Of course, if you *do* use TCP/IP, there isn't any (at least until the
Internet gets more than 20 hops wide).

If I've missed something important here, flame away, as I'm somewhat of a
novice at this stuff and probably deserve it.


-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 91 21:51:24 GMT
From:      jik@athena.mit.edu (Jonathan I. Kamens)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: how to keep /etc/hosts up to date

Why don't you just update the software on the machines that are running the
BSD networking software so that they're doing bind name resolution instead?

There's no good reason for any machines to still be using hosts files instead
of bind, at least not for machines that are running BSD networking software.
If your vendor distributes software that does networking without bind support,
then complain to your vendor.  And if you compiled the software yourself, then
get the bind distribution and recompile so that bind is used.

--
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710


-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 91 23:35:57 GMT
From:      dave@pmafire.inel.gov (Dave Remien)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

In article <1991Sep1.195029.16374@aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>scogen@xenitec.on.ca (scogen@xenitec.on.ca) writes:
>> Another important detail is that each computer will be talking over a
>> Cisco router with one ethernet card per computer.
>
>Note that you need an Ethernet card per computer anyhow :-).
>
>Probably what you mean is that you will have a separate Ethernet cable per
>computer. This of course means that each machine would have its own 0.8MB/s
>Ethernet dedicated to itself. The problem is that I doubt very much that
>this would buy you anything at all, as I would expect the CISCO router not
>to be able to sustain more than 0.8MB/s aggregate anyhow, as routers are
>normally not designed to sustain the maximum combined bandwidth of all the
>Ethernets they link. Does anybody know for sure what is the maximum thruput
>of a CISCO router?

Ours forwards at about 15000 packets per second, and routes at about

Lessee ---- 15000 * 1500 = 22.5MBytes/sec, a tad faster than Ethernet
will go.  Even routing implies (assuming max size legitimate packets)
3MBytes/sec.  I suspect that the quoted Cisco rates are for minimum (50
byte) or fairly small packets, netting somewhere in the neighborhood of
100KBytes/sec.

[ Stuff bites dust ]

>
>The bad news are that the TCP/UDP/IP sw on the host, and in particular
>SCO's, will have such huge overheads and misdesigns that in practice you
>will not be able to use more than a fraction of the nominal speed of the
>hardware. Somebody (Van Jacobson and others) have spent some serious effort
>in tuning up certain implementations of TCP/UDP/IP and can boast of being
>able of getting TCP/UDP/IP end-to-end connections that exploit 90-95% of the
>hardware capacity, but figures like 30-50% are far more common. I don't
>remember exactly, but I seem to remember that you'd be lucky to get more than
>300-400KB/s end-to-end on a TCP/UDP/IP connection from SCO's Internet
>protocol stack.

Our SCO box, with WD8003e, 33MHz 80386 and caching ESDI controller
simply is incapable of EVER exceeding 100KB/sec over the network, even
using a simple send the same packet over and over again through a UDP
connection. Average rcp/ftp stuff is about 70KB/sec.

My Dell V.4 box, admittedly running on a '486-25 with SCSI and WD8013,
averages 285KB/sec talking to our HP9000/720, sending 20MB at a whack.

>Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
>Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
>Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk

Dave
--
Dave Remien +*+*+*+*+*+*+*+*+*+*+*+*+*+*+ WINCO Computer Engineering Group
dave@pmafire.inel.gov or rzd@inel.gov      "Dave Barry for President"


-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 91 03:47:25 GMT
From:      MITRE-TAEGU@TAEGU-EMH1.ARMY.MIL
To:        comp.protocols.tcp-ip
Subject:   Routing using RIP

RE:  RIP routing algorithm - "routed" implementation

The RIP algorithm is based on selecting the route with the least number of
hops.  However, how does it select between routes with an equal number of hops?

Suppose a system that looks something like the following:

______________
|  Distant   |
|  Network   |
--------------
/         \
/             \       <----Diverse comms paths
/               \
________         ________
|  A   |         |  B   |        <---Local gateways
--------         --------
||               ||
================================     <----Local ethernet
||       ||      ||        ||
C        D  ..............  Z     <---Local workstations

The local workstations (C..Z) would all have paths to the distant network
through both A and B.  Both would have equal hop counts.  How then do they
select the gateway to use?

A non-scientific observation of our path use would seem to indicate that one
route is preferred over the other in routing packets.  Is it possible that this
selection is based on the order of their appearance in the /etc/hosts file?
(Note that our system does not use NIS, for reasons that are beyond the scope
of this discussion.)

We would appreciate any insight into the routing under these conditions.  Also,
is there any reason to believe that "gated" may handle this situation better
than "routed" does?

Thanks for any information.

Dan Jones
mitre-taegu

P.S.:    The local gateways are currently Sun 3/160s running SunOS 3.5. with
the SunLink version 5.0 internet routing package.   (This will
eventually be upgraded to SunOS 4.1.1 and the version 6.x of the
internet routing package.)  The local workstations can be either Sun
3/160s or Sun 386is running SunOS 4.0.2.

P.P.S:   Are there alternative routing algorithms available that would use
another metric, such as delay time, instead of hop count?


-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 91 09:52:09 GMT
From:      jacob@chaos.cs.brandeis.edu (Jacob Baltuch)
Subject:   info on getting onto internet requested

I'm trying to get the company I work for onto the Internet.

I'd need info on:

1. administrativia (where to apply... procedure...)
essentially a pointer

2. approximate cost of hardware (also: is it up to me and a willing
gateway to use SLIP...)

thanks for any info. please email: jacob@chaos.cs.brandeis.edu/
baltuch@binah.cc.brandeis.edu


-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 91 10:24:21 GMT
From:      gsb1@forth.stirling.ac.uk (Mr Gordon S Byron)
To:        comp.protocols.tcp-ip
Subject:   double msgs

I get two coipies of every msg on this list. As well as the "straight"
msg, i also get a copy which has Sender:
tcp-ip-request@uk.ac.nsfnet-relay as well. Can the moderators fix this
or could the problem be at my end?
_______________________________________________________________________________
Snailmail: Gordon Byron, Arts Computing Advisor,Pathfoot Building,
University of Stirling,FK9 4LA  Stirling, Scotland, UK.
Voice:  0786  67266  Fax: +78651335
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 91 10:52:38 GMT
From:      werner@inesc.pt (Werner Vogels)
To:        comp.os.mach,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   problems using MACH-NFS


We installed MACH 2.6(Mt Xinu) on a few i386 boxes (compaq, intel) and
experience on all these machines the same problem with using NFS. When
we mount a disk from one of our sparcstations, everything runs fine until
a nfs.read request is done. The i386 asks for 8192 bytes and the ss respondes
imeditaly with sending these 8k (fragmented at IP level). We can see data
traveling the network but the i386 will not kick the packet up to user
level. Not having the kernel code or objects we can not do any further
debugging. Does any body has any clues?

--
Werner Vogels

INESC - Distributed Systems and Industrial Automation Group
Tel: +351 1 3155150 ext 280, Fax: +351 1 525843
e-mail: werner@inesc.pt / C=pt;A= ;P=inesc;s=werner


-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 91 12:39:28 GMT
From:      larry@nstar.rn.com (Larry Snyder)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

dave@pmafire.inel.gov (Dave Remien) writes:

>Our SCO box, with WD8003e, 33MHz 80386 and caching ESDI controller
>simply is incapable of EVER exceeding 100KB/sec over the network, even
>using a simple send the same packet over and over again through a UDP
>connection. Average rcp/ftp stuff is about 70KB/sec.

>My Dell V.4 box, admittedly running on a '486-25 with SCSI and WD8013,
>averages 285KB/sec talking to our HP9000/720, sending 20MB at a whack.

why do you suppose the SCO box is so slow while the Dell Box screams
(is the 8013 vs the 8003 the issue - or surely not because of the 486
vs the 386)

--
Larry Snyder, NSTAR Public Access Unix 219-289-0287
{larry@news.rn.com, ..!uunet!news.rn.com!larry}


-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 91 13:32:01 GMT
From:      PIRARD@VM1.ULG.AC.BE (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   hostname & domainname

In a Unix system (IBM aix), I am not sure what to specify for hostname
and domainname an I've found no documentation clear about that.
My first guess would have been:
hostname="machine1"  domainname="department.university.be"
Then I read that, for mail, the hostname may be stripped of its labels.
Could it be:
hostname="machine1.department"  domainname="university.be"
Finally, everything also seems ok (almost) if:
hostname="machine1.department.university.be"  domainname=""
What is the definition of and relation between hostname and domainname?
I guess that mail as distributed should work if mail-address=host-name
without any related modification to sendmail.cf, but aix appends my
Given the various mail configuration errors I saw, it's unclear to many.

Please cc: me in an answer. Despite on Internet, I get this group
8 days after you send your mail.

Andr'e PIRARD         SEGI, Univ. de Liege        139.165 IP coordinator
B26 - Sart Tilman     B-4000 Liege 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU


-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 91 13:51:20 GMT
From:      cpcahil@virtech.uucp (Conor P. Cahill)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

pcg@aber.ac.uk (Piercarlo Antonio Grandi) writes:

>    Same goes for EISA SCSI disk controllers (the most expensive SCSI disks
>    top out at 4MB/s, and most cannot do more more than 1.5MB/s off the
>    platter). In practice EISA is only needed for very high speed graphics
>    (good luck with that) and for disk arrays, or, theoretically, for very
>    high bandwidth tapes.

Throughput is not the only evaluation factor for a disk controller.  Another
factor, which is where a good EISA controller will shine, is the amount of
time the bus is tied up transferring that 4MB/s.  You yourself said that
the theoretical max for the ISA bus was between 5 and 6 MB/s.  4MB/s is
appox 80% of the theoretical max.  With a good EISA controller that same
4MB/s can take up only 12% of the theoretical max, thereby freeing the
bus up for other operations.

>    The real benefits of EISA, for most people, are not in bandwidth, but
>    in configurability and interrupt sharing and multiple mastering, where
>    the ISA bus is badly misdesigned.

I want the EISA for the bandwidth.  I like the fact that a controller can
get me my data blocks that much faster while taking up less of the system
bus.

>First of all, the good news: as I have said almost any modern Ethernet card
>will deliver substantially all of the Ethernet bandwidth, and this bandwidth
>is at worst one fifth of the ISA bus bandwidth, so you don't need any EISA

Giving up 20% of the bus bandwidth just to handle ethernet i/o sounds like
a good reason to go with EISA.   20% is alot of the system.

--
I guess these are the views of VTI - since it is my consulting company.

Conor P. Cahill              (703)430-9247              uunet!virtech!cpcahil
Virtual Technologies, Inc.  46030 Manekin Plaza            Sterling, VA 22170


-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 91 15:23:44 GMT
From:      pcg@aber.ac.uk (Piercarlo Antonio Grandi)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

dave@pmafire.inel.gov (Dave Remien) writes:

> In article <1991Sep1.195029.16374@aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
> >Probably what you mean is that you will have a separate Ethernet cable per
> >computer. This of course means that each machine would have its own 0.8MB/s
> >Ethernet dedicated to itself. The problem is that I doubt very much that
> >this would buy you anything at all, as I would expect the CISCO router not
> >to be able to sustain more than 0.8MB/s aggregate anyhow, as routers are
> >normally not designed to sustain the maximum combined bandwidth of all the
> >Ethernets they link. Does anybody know for sure what is the maximum thruput
> >of a CISCO router?

> Ours forwards at about 15000 packets per second, and routes at about
> 2000 packet/sec. The newer ones are supposed to about double that.

Amazing facts #2! Shannon is in a jolly good mood if he gives so many
dispensations these days:

> Lessee ---- 15000 * 1500 = 22.5MBytes/sec, a tad faster than Ethernet
> will go.

25 times the bandwidth of a single Ethernet. Impressive! CISCO must be very
generous to give customers so much extra capacity, as their routers rarely
connect more than 2-3 Ethernet segments, and they overdesign their products
to handle ten times the maximum load on their average configuration.

> Even routing implies (assuming max size legitimate packets) 3MBytes/sec.

Here I detect the possibly improbable assumption that it can forward or
route maximal size packets at the maximum rate, which seems incredibly
optimistic, because 22MB/s aggregate bandwidth is a really stunning figure,
being able to forward packets between 25 Ethernets at full tilt.

If it really can route 22MB/s then whatever processor card is inside a CISCO
router must have a bus that is at least four times as fast as an ISA bus,
nearly as fast as an EISA bus, and it must have a diabolically fast memory
subsystem.

22MB/s cannot be achieved by most :-) 386 memory subsystems for pure string
copies.  Try copying a 1KB string from one buffer to another for a few
thousand times and then calculate the memory bandwidth.

Just to give people an idea of the numbers involved, here is a transcript of
a quick test done on the local DECsystem 5830, which has got a screamingly
fast (20-25MIPS) 25Mhz R3000 CPU:

Script started on Mon Sep  2 16:04:31 1991
$cat copy.c #define N (1024/sizeof (int)) int from[N],to[N]; main() { register long k = 64*1024; while (k--) bcopy(from,to,sizeof to); }$ cc -o ./copy -O copy.c
$time ./copy 8.3 real 7.0 user 0.1 sys I read 7 seconds for copying 64MB, or almost 10MB/s. This is reading and writing, with no processing. Maybe this 25Mhz R3000 CPU can beat a CISCO router bandwidth only if one does simply reads from its own cache, so let's have a look at just reading:$ cat read.c
#define N (1024/sizeof (int))

int frame[N];

main()
{
register int	i;
register volatile	v;
register long	k = 64*1024;

while (k--)
for (i = 0; i < N; i++)
v = frame[i];

return v;
}

$cc -o ./read -O read.c$ time ./read
4.8 real         4.1 user         0.0 sys
$^] script done on Mon Sep 2 16:05:55 1991 That's a tad over 4 seconds for 64MB, or 16MB/s. I'd be truly amazed if the CISCO router could handle 22.5MB aggregate bandwidth, even if just for forwarding, unless it has inside a processor memory combination substantially faster than a 5830, or it has a wormhole chip. Somehow I think both hypothesises are somewhat improbable. > I suspect that the quoted Cisco rates are for minimum (50 > byte) or fairly small packets, netting somewhere in the neighborhood of > 100KBytes/sec. I suspect that too, so that at 15k packets/s we'd get about 0.8MB/s for forwarding. Looks more like it. CISCO may not have gotten a Shannon dispensation after all. The original poster should tell us, as I said, what kind of packet size and frequency distribution he expects and so on. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk  -----------[000016][next][prev][last][first]---------------------------------------------------- Date: 2 Sep 91 17:13:15 GMT From: mike@tredysvr.Tredydev.Unisys.COM (Mike Marciniszyn) To: comp.unix.sysv386,comp.protocols.tcp-ip Subject: Lachman TCP/IP T_CONN_RES Bug?  THE PROBLEM: We've seen crash dumps from systems in which TCP listening circuits no longer seem to correctly connect. After some investigation, I've determined that the inp_tstate has been incorrectly set to BADSTATE, after which the listening circuit/socket no longer can connect properly. The connection actually takes place underneath the API but because of the BADSTATE, the T_CONN_IND is never forwarded up from the tcp driver to the API. THE CULPRIT: The only place that I can find for this to occur is in the handling of the T_CONN_RES primitive in tcp_state.c. The code correctly checks to see if accepting the T_CONN_RES would cause the transport to enter a BADSTATE. However, when that is the case inp_tstate is unconditionally updated as follows: inp->inp_tstate = NEXTSTATE(TE_ERROR_ACK, inp->inp_tstate); The normal state for a listening endpoint is TS_IDLE and in fact, a T_CONN_RES handled in that state would cause the inp_tstate to get assigned BADSTATE. I believe this sequence of events can occur if a connection is aborted in the TCP streams driver after several T_CONN_IND's have been forwarded to the API layer but before the API layer has generated the T_CONN_RES for all of them. In that case, the count of cloned pcb/tcb's linked to the listening pcb would be less than the number of T_CONN_IND's forwared to the API. The T_CONN_RES for the aborted connection could encounter a TS_IDLE endpoint and cause the above problem. THE SOLUTION (?): Only do the above assignment when it would not result in setting inp_tstate or better yet JUST NOT DO THE ASSIGNMENT AT ALL. I can't think of any rationale for the ERROR_ACK due to an out of state primitive changing the state of a transport endpoint! (In fact, the T_CONN_RES primitive is the only one with such an assignment!) OTHER SIDE ISSUES (uncovered as a result of the investigation): Aborted connections do not generate T_DISCON_IND's with the sequence number that matches the T_CONN_IND sequence number. They just silent discard the pcb/tcb. Such an indication would allow the API to discard T_CONN_IND's when a T_DISCON_IND with a matching sequence number exists. The sequence number in the T_CONN_IND is actually a pointer to the tcb structure. It is possible that a connection could be aborted and its space re-assigned to the SAME listening endpoint resulting in multiple T_CONN_IND's with the same sequence number! The code really should use a cycling sequnce number. A queue reference in the T_CONN_RES could result in kernel panics when the kernel uses it as a queue pointer to test for queue validity! A better way of testing queue reference validity would be to thread the list of TCP pcb's and seeing if a tcb with the queue exists on the list! 1). Has anyone seen the above problem? 2). Does anyone have any comments on the solution? 3). Does anyone know why the state change to BADSTATE exists? Mike Marciniszyn Maintenance Subsystem Development Unisys Tredyffrin DOMAIN: mike@tredysvr.tredydev.unisys.com UUCP: tredysvr!mike  -----------[000017][next][prev][last][first]---------------------------------------------------- Date: 2 Sep 91 21:06:00 GMT From: art@opal.acc.com (Art Berggreen) To: comp.protocols.tcp-ip Subject: Re: Routing using RIP  In article <9108271304.aa07864@36sig.taegu-emh1.army.mil> MITRE-TAEGU@TAEGU-EMH1.ARMY.MIL writes: >RE: RIP routing algorithm - "routed" implementation > >The RIP algorithm is based on selecting the route with the least number of >hops. However, how does it select between routes with an equal number of hops? This points out one of the weaknesses of RIP's course metrics. In most of the implementations I've seen, it is somewhat random. From the basic algorithm of only accepting new routes which have a SMALLER metric than one already in the routing table, I'd guess that most implementations would take the first seen equal cost route. If the router supports multi- path forwarding, then multiple equal cost routes can be kept and used for forwarding. Art  -----------[000018][next][prev][last][first]---------------------------------------------------- Date: 2 Sep 91 22:04:25 GMT From: thurlow@convex.com (Robert Thurlow) To: comp.os.mach,comp.protocols.tcp-ip,comp.protocols.nfs Subject: Re: problems using MACH-NFS  In <1991Sep2.105238.15359@inesc.pt> werner@inesc.pt (Werner Vogels) writes: >We installed MACH 2.6(Mt Xinu) on a few i386 boxes (compaq, intel) and >experience on all these machines the same problem with using NFS. When >we mount a disk from one of our sparcstations, everything runs fine until >a nfs.read request is done. The i386 asks for 8192 bytes and the ss respondes >imeditaly with sending these 8k (fragmented at IP level). We can see data >traveling the network but the i386 will not kick the packet up to user >level. Not having the kernel code or objects we can not do any further >debugging. Does any body has any clues? Sounds like the Ethernet card and/or the Ethernet driver in the i386 machines is choking on the sudden influx of data from the network. This is common if you have a fair-to-poor Ethernet card, and about the only thing to be done is to cut back on the "rsize" parameter in the mount request to a more conservative value, like 2048 or 1024 bytes. You might have some kind of statistic to verify this; if Mach has 'netstat', 'netstat -i' should show you input errors if it's a driver problem. I expect it won't show up there, and that it's the card. Rob T -- Rob Thurlow, thurlow@convex.com An employee and not a spokesman for Convex Computer Corp., Dallas, TX  -----------[000019][next][prev][last][first]---------------------------------------------------- Date: 3 Sep 91 04:56:41 GMT From: torek@elf.ee.lbl.gov (Chris Torek) To: list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards Subject: Re: Need help selecting Ethernet cards for very high throughput rates.  In article <1991Sep1.195029.16374@aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes: >... The 16 bit ISA bus runs at 8Mhz and transfers 16 bit across. Taking >account of all hw protocol overheads it can sustain between 5-6 MB per >second. (I know nothing of the ISA bus and little of PC architecture in general, and will just take the above for granted.) Given this bus speed, you can get 1.25 MB/s out of your Ethernet, although you may have to be careful: if you use the bus twice for each 16-bit word sent---and it is easy to do this in some architectures---you will take 2.5 MB/s out of your 5 or 6. This leaves the other half of the bus bandwidth for whatever else goes on. (If you touch it more than twice you will get into trouble---anything like that implies that there are other devices doing the same.) Ideally, you will touch it only once. >32 bit EISA Ethernet cards are an expensive joke, as is any "turbo" interface >between a 40MB/s 32 bit bus (EISA) and a 0.8MB/s 1 bit one (Ethernet). Actually, Ethernet is 1.25 MB/s (10 over 8 = 1.25, not 0.8). -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov  -----------[000020][next][prev][last][first]---------------------------------------------------- Date: 3 Sep 91 08:18:21 GMT From: dr754312%cs.nthu.edu.tw@CUNYVM.CUNY.EDU (Ching-ho Huang) To: comp.protocols.tcp-ip Subject: Re: Finger server as a requirement for all Internet hosts  You may change the access right of the FINGER file.  -----------[000021][next][prev][last][first]---------------------------------------------------- Date: 3 Sep 91 14:10:19 GMT From: sfancher@spdcc.COM (Steven Fancher) To: comp.protocols.tcp-ip,comp.unix.aix Subject: AIX 3.1 ARP Question  A question about AIX 3.1 ARP implementation: According to RFC826 a node should update its ARP cache if it sees a request or a reply who's IP address matches an entry in its cache. i.e. A, B, and C are nodes on a network. A and B have ARP cache entrys for C. C's hardware address changes. A broadcasts a request for C's new hardware address and C sends a reply. A updates his cache. B also gets both the broadcast request and the reply. B should update its cache entry for both A and C (B saw the request containing A's hardware address and the reply containing C's hardware address). On our network, tests show that A and C do everything right, but B's cache does not get updated. I have looked at the ARP code and it seems that it should work. Does AIX 3.1 IP code implement RFC 826 completely. Should this be working for us or did they punt on this part of the protocol? Does anyone know the answer to this? I would greatly appreciate any replies. Please mail any info to 'sfancher@clam.com'. I will post a summary if there is interest. Thanks, Steven Fancher | CLaM Associates | 25 First Street | Cambridge, MA +1 617 621 2542| sfancher@clam.com | No Disclaimer Applies  -----------[000022][next][prev][last][first]---------------------------------------------------- Date: 3 Sep 91 15:39:23 GMT From: bill@bilver.uucp (Bill Vermillion) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards Subject: Re: Need help selecting Ethernet cards for very high throughput rates.  In article <1991Sep1.200028.16596@aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes: > Amazing facts: the maximum bandwidth of the MCA bus when running at full > tilt in 32 bit mode is under 40MB/s; to have 100MB/s of transfer rate > *to memory* would require dozens of megabytes of requires hundreds of MB > of 4-way interleaved 20-30ns RAM; to be able to consistently get 20MB/s > on a TCP/IP link would require, assuming an overhead of 4 instructions > per byte passed thru (wildly optimistic, just consider checksumming), a > 80Mhz CPU. That contradicts what I have read about the MCA bus. The 40MB/s is for streaming data mode (burst mode is at 20MB/s). However the MCA bus support data-multiplexing, that uses the address lines as data to give a 64 bit wide transfer. It's not limited to using just the data lines. My information is from a book called "The Micro Channel Architecture Handbook" written by Chet Heath (one of the MCA designers, so there is a vested interest there). This books shows that when multiplexing using the streaming data mode the transfer rate is 80MB/sec. (NCR is claiming that speed on their new MCA bus-based multi-processor '486 boxes). One paragraph (paraphrased to conserve space) notes that the bus cycle time is 100ns in these specifications, but the bus specs would allow a 50ns cycle time. At that time the throughput could approach 160MB/sec. There is nothing to note that this has been done, though they did note that the "model 70 E80 systems implement at 62.5 ns cycle". -- Bill Vermillion - UUCP: ...!tarpit!bilver!bill : bill@bilver.UUCP  -----------[000023][next][prev][last][first]---------------------------------------------------- Date: 3 Sep 91 16:34:30 GMT From: se@IKP.Uni-Koeln.DE (Stefan Esser) To: list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards Subject: Re: Need help selecting Ethernet cards for very high throughput rates.  FTPing large files between institutes (each of them connected to the universities backbone net through a IGS) I get up to 1MB/s depending on the sending and receiving machines. While the receive buffers of 386s and Sun SLCs are easily overrun when receiving more than a few packets, resulting in transfer speeds of 10KB/s to 200KB/s, modern workstations (eg. DEC 5000/200, Sparc 2) are well capable of sending and receiving Megabytes at 1MB/s. My measurements were done between Suns and DECs local and over two IGS routers. The test file was about 4MB long. It was 'preloaded' into the buffer cache and then sent into '/dev/null'. Speeds between machines on the same cable or connected through 2 CISCOs always came out at about 1MB/s without much difference. Seems, the CISCO boxes are *really* fast. A way to 'benchmark' the TCP overhead is to ftp a long file from the buffer cache into '/dev/null' through the 'local loopback' (127.0.0.1). Then the local system has to send and receive the data at the same time, doubling the overhead. Values seen on fast 386s are in the range of 200KB/s, while the Sun2 or DEC 5000/200 go well beyond 1MB/s. You probably can't get more than *twice* the performance measured this way with any network controller on your system. Stefan -- Stefan Esser, Institute of Nuclear Physics, University of Cologne, Germany se@IKP.Uni-Koeln.DE [134.95.192.50]  -----------[000024][next][prev][last][first]---------------------------------------------------- Date: 3 Sep 91 16:44:42 GMT From: ejackson%sedofis%sed@CUNYVM.CUNY.EDU To: comp.protocols.tcp-ip Subject: NONE  SEND INFO.  -----------[000025][next][prev][last][first]---------------------------------------------------- Date: 3 Sep 91 17:13:10 GMT From: rbrickey@BBN.COM (Ron Brickey) To: comp.protocols.tcp-ip Subject: Unsubscribe  Please unsubscribe me. --- ron  -----------[000026][next][prev][last][first]---------------------------------------------------- Date: 3 Sep 91 17:25:24 GMT From: barnett@grymoire.crd.ge.com (Bruce Barnett) To: comp.protocols.tcp-ip Subject: high-level network analysis tools needed  I have a need for a high-level network (TCP) analyzer. That is, I want to measure transactions instead of packets. A transaction might be several packets which establish the connection, transfer the data, and acknowledgement of the data. The goal is to characterize an existing network, and gain a better understanding of the dynamics of a network. If I can purchase a product that does this, fine. If not, I may have to build such a tool. I have two questions: Does anyone know of any commercial product that has this ability? If not, do you think such a monitor can be implemented in software on a fast Unix box (perhaps using nnstat as a starting point)? Please reply by E-Mail. -- Bruce G. Barnett barnett@crdgw1.ge.com uunet!crdgw1!barnett  -----------[000027][next][prev][last][first]---------------------------------------------------- Date: 3 Sep 91 19:35:26 GMT From: dcarr@hobbit.gandalf.ca (Dave Carr) To: comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)  In <2431@crackers.clearpoint.com> martillo@crackers.clearpoint.com (Martillo) writes: >I should note that PPP is basically misdesigned because the latest crop >of Ethernet chips tend to support HDLC modes while the latest crop of >Serial HDLC chips tend to support Ethernet modes. As a consequence if >SLITHERNET is used for wide area networking while ethernet is used for >local area networking, respinning ethernet software for wan uses and >respinning ethernet interfaces for wan interfaces is relatively >straightforward as well as vice versa. Yes, and anyone who has an WAN driver for an 82596, I would like to hear from (and so would Intel I imagine). Given the errata, I doubt it would SLITHER ! And also I will quote a Zilog engineer "You're not going to use the USC in Ethernet mode ? (long pause) Are you?"... Given the FIFO bugs, (albeit corrected with the latest step of the week), I would stick to HDLC on the USC, and Ethernet on the 82596. -- Dave Carr | dcarr@donut.gandalf.ca | If you don't know where Gandalf Data Limited | TEL (613) 723-6500 | you are going, you will Nepean, Ontario, Canada | FAX (613) 226-1717 | never get there.  -----------[000028][next][prev][last][first]---------------------------------------------------- Date: 3 Sep 91 20:49:37 GMT From: jonson@NISC.SRI.COM (1Lt Matthew W. Jonson) To: comp.protocols.tcp-ip Subject: Re: TCP-IP@NIC.DDN.MIL vs USENET's "comp.protocols.tcp-ip"  <Lars Poulsen writes> > Subject: TCP-IP@NIC.DDN.MIL vs USENET's "comp.protocols.tcp-ip" > > I originally submitted the message just before this one to > TCP-IP@NIC.DDN.MIL, and it has not been returned as undeliverable, but > after 24 hours, it has not shown up on comp.protocols.tcp-ip yet. The new host of the mailing list is NISC.SRI.COM. I haven't noticed any real improvement, I routinely have expected my contributions to the list to take a day to show up on it. > It appears that the mailing list has become separated from the newsgroup, > perhaps intentionally. If so, when did that happen ? > > Or is NIC in bad shape ? yes :-) /matt -- Lt Matthew W Jonson jonson@server.af.mil snail-mail: Network Systems Engineer 205-279-4075 SSC/SSMT USAF DDN Program Office AV: 596-4075 Gunter AFB, AL 36114  -----------[000029][next][prev][last][first]---------------------------------------------------- Date: 4 Sep 91 01:10:14 GMT From: nwnetman@U.WASHINGTON.EDU (Jonathan Kochmer) To: comp.protocols.tcp-ip Subject: Q: Master List of TELNET / FTP programs?  Has anyone compiled a list of *all* TELNET/FTP programs for *all* operating systems? In the best of all possible worlds, I would like a list including the following information: - name of the package; - operating system under which it runs; - in the case of freeware / shareware, definitive FTP source(s), directory, and filename, or user group(s) from which it can be obtained; - in the case of commercial packages, company's name, postal and e-mail address, and package's cost; - nature of user interface (e.g., completely command driven, partially or completely menu driven, etc.); - quality of online and written documentation; - if there are multiple packages available for a given OS, qualitiative comparisons on ease of use and installation. If such a list does not yet exist, it would probably be "A Good Thing" to create and distribute, especially as more sites with minimal technical support and a wide diversity of OS's start hooking up to the Internet (e.g., k-12 schools, sites in Eastern European and less-industrialized nations, etc.). If, within a week, it appears that there is no such list, I will post a second request for information in which I will list all the packages of which I am aware, and will solicit information for other packages not listed, with an eye towards creating such a document. Many thanks in advance! Jonathan Kochmer University Computing Services University of Washington nwnetman@milton.u.washington.edu  -----------[000030][next][prev][last][first]---------------------------------------------------- Date: 4 Sep 91 03:15:08 GMT From: ed@weir.pa.dec.com (Ed Gould) To: comp.os.mach,comp.protocols.tcp-ip,comp.protocols.nfs Subject: Re: problems using MACH-NFS  > We installed MACH 2.6(Mt Xinu) on a few i386 boxes (compaq, intel) and > experience on all these machines the same problem with using NFS. When > we mount a disk from one of our sparcstations, everything runs fine until > a nfs.read request is done. The i386 asks for 8192 bytes and the ss respondes > imeditaly with sending these 8k (fragmented at IP level). We can see data > traveling the network but the i386 will not kick the packet up to user > level. Not having the kernel code or objects we can not do any further > debugging. Does any body has any clues? This sounds like you're using an Ethernet interface in the 386 box that can't receive enough back-to-back packets without dropping at least one to reassemble the 8KB datagram. Some interfaces - notably the older 3Com (3c501) - don't have enough buffering to receive more than two consecutive packets. 8KB datagrams typically get split into seven packets for transmission. The solution to this problem is to specify smaller read and write sizes (read sizes for remote filesystems, write sizes for exported filesystems) in fstab (or on the mount command line). Try adding rsize=2048,wsize=2048 to the options field of the appropriate fstab entries. (I believe that only rsize needs to be specified on the 386 end; wsize should be set on any machines that mount filesystems *from* the machine with an inadequate Ethernet card.) --- Ed Gould Digital Equipment Corporation ed@pa.dec.com Network Systems Laboratory +1 415 688 1309 505 Hamilton Ave, Palo Alto, CA 94301 "I'll fight them as a woman, not a lady. I'll fight them as an engineer."  -----------[000031][next][prev][last][first]---------------------------------------------------- Date: 4 Sep 91 04:26:25 GMT From: marc@dumbcat.sf.ca.us (Marco S Hyman) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.sysv386,comp.unix.wizards Subject: Ethernet packets/second (was Re: Need help selecting ...)  In article <1991Sep2.152344.14037@aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes: > dave@pmafire.inel.gov (Dave Remien) writes: > > > In article <1991Sep1.195029.16374@aber.ac.uk> > > pcg@aber.ac.uk (Piercarlo Grandi) writes: > > >Probably what you mean is that you will have a separate Ethernet cable > > >per computer. This of course means that each machine would have its own > > >0.8MB/s Ethernet dedicated to itself. The problem is that I doubt very > > >much that this would buy you anything at all, as I would expect the > > >CISCO router not to be able to sustain more than 0.8MB/s aggregate > > >anyhow, as routers are normally not designed to sustain the maximum > > >combined bandwidth of all the Ethernets they link. Does anybody know for > > >sure what is the maximum thruput of a CISCO router? > > Ours forwards at about 15000 packets per second, and routes at about > > 2000 packet/sec. The newer ones are supposed to about double that. > > Amazing facts #2! Shannon is in a jolly good mood if he gives so many > dispensations these days: > > > Lessee ---- 15000 * 1500 = 22.5MBytes/sec, a tad faster than Ethernet > > will go. > Stop right there! 15000 packets/second is (approx) the Ethernet maximum. For those who want the math: Minimum frame length = 64 bits of preamble 64 bits 6 octet destination address 48 bits 6 octet source address 48 bits 2 octet type 16 bits 46 octet data 368 bits 4 octet FCS 32 bits ----------------- 576 bits The time to transmit this frame at 10 Mbit/s is 57.6 usec. Add to that the minimal interframe spacing of 9.6 usec and you can spit a frame out every 67.2 usec or 14880 (almost 14881) frames per second -- assuming one station is doing all the transmitting. cisco playes the specsmanship game of being able to handle this theoretical maximum. They are not the only ones who try to play this game. (Note that when playing this game the payload maximum is 14880 pps * 46 bytes/p = 684480 bytes/second. That's a lot of work for a bit more that 1/2 Mbyte/s.) Using the maximum ethernet frame length the numbers look like 1220.8 usec per frame. When adding the 9.6 usec interframe spacing requirement the maximum frames/second (large frames) is 812 frames/second. The payload in this case increases to 1.218 Mbytes/s. Typical networking -- the best throughput occurs when the processor is doing the least amount of work :-) // marc -- marc@dumbcat.sf.ca.us -- pacbell!dumbcat!marc  -----------[000032][next][prev][last][first]---------------------------------------------------- Date: 4 Sep 91 04:44:03 GMT From: megauthi@watcgl.waterloo.edu (Marc E. Gauthier) To: comp.protocols.nfs,comp.protocols.tcp-ip Subject: Need documentation or references for AFS and RFS  Is there any available documentation on the AFS (Andrew File System) and RFS (??? Remote File System) remote file system protocols? Any pointers, either online or paper documentation, would be appreciated. I would like to add these references to my masters essay. In particular, I'd like to know if it would be possible to get a complete specification that would allow one to implement these protocols in a new (non-Unix) environment. Also, if there are any other remote file system protocols that look like contenders for a standard, I'd like to know about them. I'm particularly interested in protocols that work over the Internet. (Of course, I know about NFS, FTP, TFTP; and a simple grep' through the RFC index didn't bring up anything about AFS or RFS) Any info is most welcomed. -Marc -- Marc E. Gauthier megauthier@watcgl.waterloo.edu University of Waterloo 129.97.140.64 885-1211 x3469 or x4548  -----------[000033][next][prev][last][first]---------------------------------------------------- Date: 4 Sep 91 14:27:19 GMT From: jim@lsuc.on.ca (Jim Mercer) To: news.groups,bit.listserv.biglan,comp.dcom.lans,comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,rec.radio.amateur.packet Subject: CFD: comp.protocols.tcp-ip.ka9q  [ Follow-ups directed to news.groups and comp.protocols.misc (for those not willing to wade through news.groups) ] This is an official Request For Discussion for the creation of the new newsgroup "comp.protocols.tcp-ip.ka9q" Proposed Charter: Comp.protocols.tcp-ip.ka9q would be for discussion of the configuration, modification, extention and administration of the KA9Q NOS IP routing software. This group is intended to cover both the "old NET" version and the newer "NOS" version, as well as the various platforms it has been ported to. While there are existing groups which cover various elements of the KA9Q package, it is the intention of this group, to gather together the vast net-wide knowledge base into one area. Currently discussions about ka9q are carried out in rec.radio.amateur.packet, comp.protocols.tcp-ip[.ibmpc], comp.protocols.ppp as well as several mailing lists. I would hope that this concentration of readers would aid in adding some structure and coordination to the development of the package, as there are currently many flavours of the system derived from varying previous versions. Why "comp.protocols.tcp-ip.ka9q"? ka9q's strength (IMHO) is its IP routing capabilities and secondly, its built in TCP server support (SMTP, POP, finger, etc). These strengths are applicable to many tcp-ip environments. While the software's roots are based in amateur packet radio, its use is spreading rapidly into the IP routing/briding/serving arena. rumor has it that this software is the base of the Telebit Netblazer's OS. ka9q supports the following protocols: SLIP PPP SMTP POP bootp RIP ARP FTP telnet ICMP plus others Discussion will end at 11:59 P.M. on 27 September 1991. i will running the vote unless anyone has any objections. -- [ Jim Mercer jim@lsuc.On.Ca || ...!uunet!attcan!lsuc!jim +1 416 947-5258 ] [ Educational Systems Manager - Law Society of Upper Canada, Toronto, CANADA ] [ Standards are great. They give non-conformists something to not conform to. ] [ The opinions expressed here may or may not be those of my employer ]  -----------[000034][next][prev][last][first]---------------------------------------------------- Date: 4 Sep 91 16:01:36 GMT From: mjhammel@Kepler.dell.com (Michael J. Hammel) To: comp.protocols.tcp-ip Subject: gethostbyaddr() in ISC TCP/IP 1.1.2  The TCP/IP Guide fro ISC has a man page for this call that lists its syntax as: struct hostent *gethostbyaddr(addr, len, type) char *addr int len, type If you use gethostbyname() it returns the same hostent structure. This structure has two fields in it that I thought related to what gethostbyaddr() is asking for: h_addrtype and h_length. Are the "len" and "type" parameters required in gethostbyaddr() the same as h_lenght and h_addrtype in the hostent structure? IE, for IP internet addresses should length be 4 and type be AF_INET? I'm pretty sure of the latter, but when I use either 4 or the length of the *addr in the length parameter I still don't get a valid reply from the nameserver. Michael J. Hammel | mjhammel@{Kepler|socrates|feynman}.dell.com Dell Computer Corp. | {73377.3467|76424.3024}@compuserve.com #include <disclaim/std> | zzham@ttuvm1.bitnet "Jesus Saves! But Gretzky gets the rebound! He shoots! HE SCORES!"  -----------[000035][next][prev][last][first]---------------------------------------------------- Date: 4 Sep 91 17:18:40 GMT From: brian@telebit.com (Brian Lloyd) To: comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)  martillo@crackers.clearpoint.com (Martillo) writes: > SLITHERNET: A Proposal > for Using Moderate-To-High-Speed > Synchronous Serial Connections as a > LAN-like Networking Medium Ah yes, Yet Another Serial Protocol (YASP). Pretty soon its going to be like IBM in the 60's and early 70's when they had about 100 different variations of bisync, all mutually incompatible. -- Brian Lloyd, WB6RQN Telebit Corporation The views expressed Network Systems Architect 1315 Chesapeake Terrace herein are my own and brian@telebit.com Sunnyvale, CA 94089-1100 are not necessarily voice (408) 745-3103 FAX (408) 734-3333 my employer's.  -----------[000036][next][prev][last][first]---------------------------------------------------- Date: 4 Sep 91 17:38:20 GMT From: sean@fiamass.ie (Sean Mc Grath) To: comp.protocols.tcp-ip Subject: unsubscribe  Please unsubscribe sean@fiamass.ie  -----------[000037][next][prev][last][first]---------------------------------------------------- Date: 4 Sep 91 18:21:49 GMT From: garath@ais.org (Belgarath) To: comp.protocols.tcp-ip Subject: Re: gethostbyaddr() in ISC TCP/IP 1.1.2  mjhammel@Kepler.dell.com (Michael J. Hammel) writes: >and h_addrtype in the hostent structure? IE, for IP internet addresses >should length be 4 and type be AF_INET? I'm pretty sure of the latter, >but when I use either 4 or the length of the *addr in the length >parameter I still don't get a valid reply from the nameserver. char *query_ip_number(socket) int socket; { struct sockaddr_in PeerInfo; int len = sizeof PeerInfo; if(getpeername(socket, (struct sockaddr *)&PeerInfo, &len) == -1) stop("getpeername()"); return inet_ntoa(PeerInfo.sin_addr); } char *query_ip_name(socket) int socket; { long test = inet_addr(query_ip_number(socket)); struct hostent *HostInfo = gethostbyaddr(&test, 4, AF_INET); return HostInfo->h_name; }  -----------[000038][next][prev][last][first]---------------------------------------------------- Date: 4 Sep 91 18:22:22 GMT From: nwnetman@U.WASHINGTON.EDU (Jonathan Kochmer) To: comp.protocols.tcp-ip Subject: RE: Q: Master List of All TELNET/FTP Packages?  In an eralier posting, I asked: >> Has anyone compiled a list of *all* TELNET/FTP programs for *all* >> operating systems? Billy Barron replied: > Yes, see NETINFO:VENDORS-GUIDE.DOC on NIC.DDN.MIL via anonymous FTP. It's quite an impressive document; some 150 pages long, and chock full of exactly the kind of information I was looking for. Jonathan Kochmer University Computing Services University of Washington Seattle, WA  -----------[000039][next][prev][last][first]---------------------------------------------------- Date: 4 Sep 91 18:27:04 GMT From: garath@ais.org (Belgarath) To: comp.protocols.tcp-ip Subject: Problems with multiple connections  I have a structure defined to hold the people who connect with the following format: struct caller_info { int socket; /* Will hold the socket id */ char *nick; /* Will hold the nickname of the person */ char *host; /* Will hold the string name of the host */ char *ip; /* Will hold the numeric id of the host */ } User[MAX_USERS]; As it currently stands, I can only accept one connection at a time. If one is sitting at a read() call, the other one stops right after the connected message until the first connection closes, then the second moves on. That is problem number 1. I want multiple people obviously. My next problem is reading info. I don't know what to put for the length it should read. If I put 10 for instance, and they only put 4 characters, then it'll screw up for the next time they put something as it'll still have the other 6. Is that why you use the loop thing that was in the nroff you sent me? If they only type 4 chars though, then hit return, where will those next 6 bytes come from? I think I need to use select() calls or an fcntl() with FIONREAD or something, but am unsure of how to use it. After that's fixed, I need to be able to tell *when* someone just typed something so that I can send it to the other people. Right now I basically have: while(1) { char buff[10]; NewFD = accept(); write() some stuff. read(NewFD, &buff, sizeof(buff)); write() another. close(NewFD); } Any help would be greatly appreciated.  -----------[000040][next][prev][last][first]---------------------------------------------------- Date: 4 Sep 91 19:38:35 GMT From: katz@celtics.ma30.bull.com (katz) To: comp.protocols.tcp-ip Subject: ORACLE SQL*NET tcp port numbers.  I would like to have some information about the underlying communications of two ORACLE packages communicating with the SQL*NET protocol over tcp/ip. 1). Is the communication interface of ORACLE use sockets ? 2). How is established the tcp port number between the two packages? Thank you for a quick reply. -- == Eddie Katz BULL HN Information Systems == == (508) 294 2586 (FAX 294 2583) 300, Concord Rd == == MS - MA30 836A Billerica, MA 01821 == == Edouard.Katz@mips2.ma30.bull.com ==  -----------[000041][next][prev][last][first]---------------------------------------------------- Date: 4 Sep 91 19:42:58 GMT From: ddrg@hobbit.gandalf.ca (Duncan Glendinning) To: comp.protocols.tcp-ip Subject: Re: Decnet IV Implementation  In <9108271757.AA13434@achilles.coral.com> ken@achilles.coral.com (Ken Benstead) writes: >Hello World, > > I known this is probably not the "right place" to ask this question >but I'm not sure where "right place" would be, so here goes anyway. Does >anyone know of a Decnet IV router implementation suitable for porting >(ie includes source code)? A public domain implementation would be >nice but any information (including commercial packages) would be much >appreciated. Please E-Mail reponses directly to me. >Thanks in anticipation, >Ken Benstead >kbenstead@coral.com I'd also appreciate hearing about public domain implementations of Decnet Phase IV. -- Duncan Glendinning CAnet: ddrg@mentor.gandalf.ca, ddrg@gandalf.ca Gandalf Data Ltd. Voice: (613) 723-6500 Nepean, Ontario Fax: (613) 226-1717 Canada K2E 7M4  -----------[000042][next][prev][last][first]---------------------------------------------------- Date: 5 Sep 91 03:31:22 GMT From: ce1zzes@prism.gatech.EDU (Eric Sheppard) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: IRC client for MSDOS?  I found one, but it used a local dialup to reach an irc server. Does a package exist that uses, say, packet drivers? Looking for a decent irc client. Eric -- Eric Sheppard Georgia Tech | "Of course the US Constitution isn't Atlanta, GA | perfect; but it's a lot better than what ARPA: ce1zzes@prism.gatech.edu | we have now." -Unknown uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!ce1zzes  -----------[000043][next][prev][last][first]---------------------------------------------------- Date: 5 Sep 91 12:57:10 GMT From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) To: comp.protocols.tcp-ip Subject: truly silly route, UC london to UC dublin  given the distance from london to dublin, and the fact that there is 2 Mbps IP to belfast, this is a truly silly route: traceroute to 137.43.1.4 (137.43.1.4), 30 hops max, 40 byte packets 1 cisco (128.16.6.150) 0 ms 10 ms 10 ms 2 gateway (128.16.3.3) 20 ms 30 ms 30 ms 3 192.80.7.1 (192.80.7.1) 30 ms 30 ms 30 ms 4 192.80.6.2 (192.80.6.2) 200 ms 210 ms 220 ms 5 nss.sura.net (192.80.214.254) 200 ms 230 ms 200 ms 6 College_Park.MD.NSS.NSF.NET (129.140.9.77) 220 ms 320 ms 210 ms 7 Ithaca.NY.NSS.NSF.NET (129.140.74.9) 280 ms 290 ms 250 ms 8 Ithaca.NY.NSS.NSF.NET (129.140.10.79) 270 ms 340 ms 280 ms 9 Ithaca.NY.NSS.NSF.NET (129.140.10.130) 460 ms 370 ms 530 ms 10 gate-cern.easi.net (192.70.246.2) 660 ms 690 ms 1120 ms 11 ext-gw-01-e.cern.ch (192.65.185.129) 340 ms 360 ms 12 ibr-router.surfnet.nl (192.87.4.9) 520 ms 560 ms 440 ms 13 hef-router.nikhef.nl (192.87.4.21) 400 ms 380 ms 460 ms 14 192.16.192.233 (192.16.192.233) 750 ms 750 ms 980 ms 15 * * * i mean really, are we trying to cover as many continents as poss...ayvbe we should route it via kaist & CSIRO for good measure:-) j.  -----------[000044][next][prev][last][first]---------------------------------------------------- Date: 5 Sep 91 14:16:55 GMT From: jessea@homecare.COM (Jesse W. Asher) To: comp.unix.admin,comp.protocols.tcp-ip Subject: Changing passwd on remote system.  I've got a problem with networking that someone may be interested in. I've got a sun server and server 386 systems running unix (System V R4). Unfortunately, AT+T didn't include the passwd functionality in NIS in SVR4 so I'm having to come up with a different way of managing passwords. I'd like everyone to be able to log into any computer on the network with the same loginid and same password. So, what I'd like to do is write a little program that will allow the user to go through the network and change their passwd that is located on the server. Then the server will propagate the passwd file via NIS. Does anyone have ideas on how I can do this? I'd really like to avoid writing a passwd program and would just like to call passwd on the remote system. But there are authentication problems and I would prefer that users didn't log onto the server at all. Any ideas on how to best tackle this problem?  -----------[000045][next][prev][last][first]---------------------------------------------------- Date: 5 Sep 91 14:55:33 GMT From: jim@lsuc.on.ca (Jim Mercer) To: news.announce.newgroups,news.groups,comp.protocols.misc,comp.protocols.tcp-ip Subject: RFD: comp.protocols.tcp-ip.ka9q  This is an official Request For Discussion for the creation of the new newsgroup "comp.protocols.tcp-ip.ka9q" Proposed Charter: Comp.protocols.tcp-ip.ka9q would be for discussion of the configuration, modification, extention and administration of the KA9Q NOS IP routing software. This group is intended to cover both the "old NET" version and the newer "NOS" version, as well as the various platforms it has been ported to. While there are existing groups which cover various elements of the KA9Q package, it is the intention of this group, to gather together the vast net-wide knowledge base into one area. Currently discussions about ka9q are carried out in rec.radio.amateur.packet, comp.protocols.tcp-ip[.ibmpc], comp.protocols.ppp as well as several mailing lists. I would hope that this concentration of readers would aid in adding some structure and coordination to the development of the package, as there are currently many flavours of the system derived from varying previous versions. Why "comp.protocols.tcp-ip.ka9q"? ka9q's strength (IMHO) is its IP routing capabilities and secondly, its built in TCP server support (SMTP, POP, finger, etc). These strengths are applicable to many tcp-ip environments. While the software's roots are based in amateur packet radio, its use is spreading rapidly into the IP routing/briding/serving arena. rumor has it that this software is the base of the Telebit Netblazer's OS. ka9q supports the following protocols: SLIP PPP SMTP POP bootp RIP ARP FTP telnet ICMP plus others Discussion will end at 11:59 P.M. on 27 September 1991. i will running the vote unless anyone has any objections. -- [ Jim Mercer jim@lsuc.On.Ca || ...!uunet!attcan!lsuc!jim +1 416 947-5258 ] [ Educational Systems Manager - Law Society of Upper Canada, Toronto, CANADA ] [ Standards are great. They give non-conformists something to not conform to. ] [ The opinions expressed here may or may not be those of my employer ]  -----------[000046][next][prev][last][first]---------------------------------------------------- Date: 5 Sep 91 16:54:59 GMT From: libes@cme.nist.gov (Don Libes) To: comp.unix.admin,comp.protocols.tcp-ip Subject: Re: Changing passwd on remote system.  In article <1991Sep5.141655.15426@homecare.COM> jessea@homecare.COM () writes: >network with the same loginid and same password. So, what I'd like to >do is write a little program that will allow the user to go through the >network and change their passwd that is located on the server. Then the >server will propagate the passwd file via NIS. Does anyone have ideas >on how I can do this? I'd really like to avoid writing a passwd program >and would just like to call passwd on the remote system. But there are >authentication problems and I would prefer that users didn't log onto >the server at all. Any ideas on how to best tackle this problem? There is an expect script that will do this that comes with the expect distribution. It's designed for a single user who wants to keep multiple accounts in sync, where some computers have separate NIS, or don't even use NIS. Your case would just be a very simple use of it. Your users can call it directly as: passmass server where 'server' is the name of your server. They will then be prompted for the old and new passwords. Or you can bury that in a script (called 'yppassword', for example). Or edit passmass so that it has a default server, and then change it's name to yppassword. Don  -----------[000047][next][prev][last][first]---------------------------------------------------- Date: 5 Sep 91 17:09:14 GMT From: TANNERC@CU18.CRL.AECL.CA To: comp.protocols.tcp-ip Subject: udp on Internet Connection  Hi All We are just about to get our connection to the Internet. We are planning to install a router of our own (CISCO) which we will use to keep unwanted traffic from our own network (and vica versa). I am wondering what functions we will loose (or what problems we will cause ourselves) if we prevent any UDP traffic between our local network and the Internet. Thanks in advance for your advice. Chris -- Chris Tanner Tannerc@CU18.CRL.AECL.CA AECL Research Chalk River Ont. Canada K0J 1J0  -----------[000048][next][prev][last][first]---------------------------------------------------- Date: 5 Sep 91 18:07:58 GMT From: MRC@Panda.COM (Mark Crispin) To: comp.protocols.tcp-ip Subject: Nippon Telephone & Telegraph change of address  Maximum distribution requested. I have been asked to get the word out on this to any/all e-mail correspondents with personnel at Nippon Telephone and Telegraph in Japan. --- Begin forwarded message -- NTT is now providing domain name service directly to the full Internet and is retiring the CSnet connection. Please send your messages to NTT users using the syntax user@ntt-20.ntt.jp and not to user%ntt-20.ntt.jp@relay.cs.net Any messages addressed to addresses of the form user%host.ntt.jp@relay.cs.net will be rejected after 9/15. Please check any mailing lists under your control and correct as necessary. If you have any questions on this, please contact: nic@nttta.ntt.jp  -----------[000049][next][prev][last][first]---------------------------------------------------- Date: 5 Sep 91 18:08:30 GMT From: sma@rocksanne.wrc.xerox.com (Susie Armstrong) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window  Fred Bohle mentions that the TCP on Xerox boxes will not send a FIN into a zero window. If the Xerox boxes you refer to are the 8000 or 6085 series of machines, then the TCP implementation was written by me, and perhaps I can explain the rationale behind not sending a FIN into a zero window. FINs, like SYNs, are client control information, and must be sent reliably; that is, they consume sequence numbers. As such, even though they occupy no "physical space" in the segment data space, I subjected them to the same rules as "physical data". If a window is closed, I concluded that the remote end really meant it - it wants no more client data, including FINs. Of course, per protocol, I will send URGs and RSTs into a closed window. Note that though I will not send a FIN into a closed window, I will process a FIN that I receive into my closed window (my window reflects buffering for "physical data", and FINs don't consume buffers, so processing that FIN is easy to do). This reflects my belief in that old transport implementation rule "be conservative about what you send, be liberal about what you accept". Having different windowing rules for FINs than for other client data (i.e. SYNs and physical data) seems conceptually wrong. However, I do agree that the specification is not explicit on this point, and sending the FIN into a closed window (and having it accepted) does not harm the integrity of the data or of the closing handshake. This implementation was done pre-host-requirements-rfc - perhaps that document has some more clues on the commonly accepted treatment of FINs in general, if not on this case specifically. Cheers, Susie Armstrong Xerox Webster Research Center armstrong.wbst128@xerox.com  -----------[000050][next][prev][last][first]---------------------------------------------------- Date: 5 Sep 91 22:47:31 GMT From: martin@unislc.uucp (Martin Cryer) To: list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards Subject: Re: Need help selecting Ethernet cards for very high throughput rates.  In article <1991Sep1.195029.16374@aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes: >scogen@xenitec.on.ca (scogen@xenitec.on.ca) writes: > >> We are trying to configure an SCO Unix system running some type of >> IP, (maybe TCP, maybe UPD) to operate at maximum throughput. Our goal >> is to get up to _6_ Megabits/Sec. > >Well, nearly any modern Ethernet card will deliver 6 Megabits per second. >After all it's only around 600KB/s. SCO's TCP protocol stack will most >probably not be able to keep up with the card though. > >> We realize that we need EISA bus machines with 32-bit Ethernet cards to do >> this. > >Why ever? The 16 bit ISA bus runs at 8Mhz and transfers 16 bit across. Some run at 10 as will some controllers, you may be able to match a pair that give that xtra bit.... >Taking account of all hw protocol overheads it can sustain between 5-6 MB per >second. Here you are proposing to load it with just 600KB/s, which is one >tenth of its top capacity. Think of this: my VGA card will, during continuous >graphics operation, sustain 2MB/s over the ISA bus, and my SCSI controller >will get 1.4MB/s sustained from a SCSI disk. > But while you are using the bus... EISA offers 32bit DMA so you can DMA into user space directly, whatever its address. EISA Bus Master DMA also holds the bus for a shorter time (upto 33MHz) and being Bus Master reduces the cpu involvement... (I know PCAT Bus Master boards exist, but they are finicky on memory timings). >32 bit EISA Ethernet cards are an expensive joke, as is any "turbo" interface >between a 40MB/s 32 bit bus (EISA) and a 0.8MB/s 1 bit one (Ethernet). Cuts response time to the controller requests though and gives better burst speed to the controller. Expense is probably releated to current sales volumes. Advent of Intel BMIC usage will bring costs down... > > Same goes for EISA SCSI disk controllers (the most expensive SCSI disks > top out at 4MB/s, and most cannot do more more than 1.5MB/s off the > platter). In practice EISA is only needed for very high speed graphics > (good luck with that) and for disk arrays, or, theoretically, for very > high bandwidth tapes. Mmm, well with the new Seagate 1.25GB disks that spin at 5400+ rpm, ~3.0MBytes/s is possible, and with more than one device 5.0 MBytes/s is not impossible. Even if the sustained xfer rate is not this, it allows quicker reponse to simultaneous 2 device requests and reduces bus contention. This all adds upto better system throughput. Also, modern drives have caches which allow better than 1.5MByte/s xfers for < cache size xfers. > > The real benefits of EISA, for most people, are not in bandwidth, but > in configurability and interrupt sharing and multiple mastering, where > the ISA bus is badly misdesigned. This is indeed true, but for power users everything helps. EISA also means up to 16 slots on some boards... EISA Bus also allows more upmarket systems to be designed which still allow those systems to use standard ISA boards for less performance critical uses - providing a more expanded product offering. EISA gives actual bus timings as a standard, as opposed to "if-it-works- with-an-IBM-PCAT-then-it-must-be-ok" standards. > >> Another important detail is that each computer will be talking over a >> Cisco router with one ethernet card per computer. > >Note that you need an Ethernet card per computer anyhow :-). > >Probably what you mean is that you will have a separate Ethernet cable per >computer. This of course means that each machine would have its own 0.8MB/s >Ethernet dedicated to itself. The problem is that I doubt very much that >this would buy you anything at all, as I would expect the CISCO router not >to be able to sustain more than 0.8MB/s aggregate anyhow, as routers are >normally not designed to sustain the maximum combined bandwidth of all the >Ethernets they link. Does anybody know for sure what is the maximum thruput >of a CISCO router? > >I expect that in practice having a star configuration with a router in the >middle and an Ethernet to each machine will probably buy you nothing at all, >except having a single active failure point. > >> This way we completely eliminate packet collisions. > >This is probably completely unnecessary. Collisions are very rarely a >problem, the Ethernet will in practice share out its capacity between >machines in only slightly less than linear fashion, if packet sizes are not >too small. > >If you really want for some funny reason a star configuration, with an >active hub, and no collisions and guaranteed point-to-point capacity, >consider seriously getting a Token Ring. At least Token Ring active hubs >are designed for this task, and not as routers, and tend to be fairly fail >safe too. > >> They also told us about their ES3210 card, which they claim can >> operate at _13_ Megabits/Sec. I thought that the cable can't operate >> faster than 10 Megabits/Sec. Am I missing something? > >Well, they are telling you nice numbers out of thin air. > >> How do I get real numbers that will tell me what to expect in the field? > >Toss a coin... :-) > >> I don't know how obvious my lack of network expertise is, > >Very obvious. :-). But at least you know. Some other poster who also replied >to your article is not in a much better position than yourself, but does not >know. :-) > >> but if you see any questions that I'm not asking, I need to know that >> also. I'm sure I'm not asking everything I need to know. > >Well, now that I have answered your questions, let's tell you something more >useful. > >First of all, the good news: as I have said almost any modern Ethernet card >will deliver substantially all of the Ethernet bandwidth, and this bandwidth >is at worst one fifth of the ISA bus bandwidth, so you don't need any EISA >machine. Collisions will be in practice not a problem. You probably don't Collisions may be a problem. You have to get the DATA from somewhere and put it somewhere too, unless all data is RAM to RAM only. The longer you have the Bus the less time there is for disk i/o and handling other ISA xfers you need. EISA will help reduce this risk. An Ethernet card that handles the kind of bandwidth you want is probably dumb in the sense that no protocol handling at link or IP layers and above is handled out on the board, but in the kernel drivers. You are correct below that the protocol stacks will probably get you... EISA will give you 32bit DMA address space, so your drivers can (if nicely written), give you DMA from user space to controller (or controller to user space) without copying, whatever your memory size. This is especially important for high volume disk i/o on SVR4 where the buffer cache is through the normal VM page fault / free page pool mechanism and can therefore come potentially from any real memory address (and not just below 16MB where the SVR4 buffer cache is likely to be). >need a CISCO router at all, you can put all the machines on the same >Ethernet, if you don't need 6Mb/s sustained bandwidth between each machine, >but only aggregate. > >The bad news are that the TCP/UDP/IP sw on the host, and in particular >SCO's, will have such huge overheads and misdesigns that in practice you >will not be able to use more than a fraction of the nominal speed of the >hardware. Somebody (Van Jacobson and others) have spent some serious effort >in tuning up certain implementations of TCP/UDP/IP and can boast of being >able of getting TCP/UDP/IP end-to-end connections that exploit 90-95% of the >hardware capacity, but figures like 30-50% are far more common. I don't >remember exactly, but I seem to remember that you'd be lucky to get more than >300-400KB/s end-to-end on a TCP/UDP/IP connection from SCO's Internet >protocol stack. And even slower for file system to net to file system xfers. Ftp in BINARY/IMAGE mode for big files probably will even give only 100kbytes/s of so on a 386/486 type of PC running a fairly standard Un*x and TCP/IP stack. Tftp won't give much better either. > > >Finally, what you should tell us is what is your problem, e.g. how many >machines you have got to link, how far apart they are, what is the average >packet length, and what is the maximum packet rate that you expect from each >machine, and other characteristics. Once you have told this to us, we can >tell you whether Ethernet makes any sense at all. Possible alternatives are >running TCP/UDP/IP over SCSI or over several point-to-point links, e.g. >synch, or RS-422, for example. If you are going to do SCSI, ie using host controllers both as target and initiator, the reliability will be higher than Ethernet and a simpler protocol layering than TCP/IP may be in order for efficiency. (ALso bigger block sizes could be used than normal datagrams). >-- >Piercarlo Grandi | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk >Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg >Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk Martin Cryer Unisys Europe Africa Unix SVR4 Development Unisys Salt Lake City All opinions are my own and not those of my employer.  -----------[000051][next][prev][last][first]---------------------------------------------------- Date: 6 Sep 91 01:28:05 GMT From: erik@srava.sra.co.jp (Erik M. van der Poel) To: comp.protocols.tcp-ip Subject: Re: EBCDIC ASCII and *much* more  Andr'e PIRARD writes: > So, because we restrict ourselves to single-octet codes for now What do you suggest for the Japanese, Chinese, Korean, and Taiwanese users? - -- EvdP  -----------[000052][next][prev][last][first]---------------------------------------------------- Date: 6 Sep 91 02:02:21 GMT From: martillo@cpoint.clearpoint.com (Joachim Carlo Santos Martillo) To: comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)  In article <KARL.91Sep1171232@remora.MorningStar.Com> Karl Fox <karl@MorningStar.Com> writes: >Joachim Carlo Santos Martillo Ajami writes: > Reasonable possible architectures are: > 1) Ethernet - Bridge InterWorking Unit (BIWU) - WAN Link - BIWU - Ethernet > 2) Ethernet - Bridge InterWorking Unit (BIWU) - WAN Link - Router - Ethernet > 3) Ethernet - Hybrid Bridge/Router (HBR) - Wan Link Network - HBR - Ethernet > 4) Ethernet - Router - WAN Link - Router - Ethernet > 5) Ethernet - Half-Router - WAN Link - Half-Router - Ethernet > In IP terms, architecture: > (1) corresponds to 1 IP network and can employ the transparent > bridging version of PPP or SLITHERNET. > (2) corresponds to 2 IP networks and can employ the transparent > bridging version of PPP or SLITHERNET. > (3) corresponds to 3 IP networks and can employ only SLITHERNET. > (4) corresponds to 3 IP networks and can employ the transparent > bridging version of PPP, SLITHERNET or PPP for IP. > (5) corresponds to 2 IP networks and can employ the transparent > bridging version of PPP, SLITHERNET or PPP for IP. >You should really have said "Reasonable possible *bridging* architectures", except that bridges were not used in all the architectures which I described. >because I suspect that the most common way of interconnecting TCP/IP >networks looks like your number (4) but where the routers have their >interfaces configured with the BSD IFF_POINTOPOINT semantics, associating >their interface with the primary (Ethernet) address of the machine at the >other end of the WAN link and providing a host route to it. This method sounds more like the half-router method (5). > This doesn't >work with X.25, which usually requires a subnet (unless you are running it >over a point-to-point connection), but it's exactly what is intended to be >used with PPP. It corresponds to only two IP networks; the point-to-point >link doesn't use up a subaddress. Avoiding the waste of subnets is good, but this method of interconnect appears rather inflexible. Non-IP traffic does not have an obvious way to get across the link. And the point-to-point link probably cannot easily be replaced by a mesh of point-to-point links as might be desirable to provide a high degree of availability, alternate routing and fault tolerance. Since this method is a half-router formalism, I have to wonder how synchronized the software must be on both end hosts. If one machine can support the latest and greatest routing software, does the semantics of BSD IFF_POINTTOPOINT prevent the best use from being made of this new software. > This is what we recommend to our PPP >customers, and I believe is also what Sun recommends to their Internetwork >Router customers. The Suns use an 8530 type device on their serial interface, which requires fairly expensive interrupt service routines. A lot of serial traffic could easily make necessary an upgrade to a more powerful router. I can see where recommending this solution might desirable from Sun's standpoint. >Best of all, the two ends of the circuit don't have to come from the same >vendor. Of course, for this reason I am making the slithernet specification available. Now personally I would rather that customers had to buy all their equipment from us, but I also know customers are not stupid and don't like to play this sort of game. As a consequence, I am explicitly telling our competitors as well as makers of non-competing networking products how to communicate with our devices over a serial link. I have confidence that even if we aid our competitors, Clearpoint will still be able to provide the biggest bang for the buck, and as a consequence, customers will choose Clearpoint products over those of our competitors. > There are dozens of products you can buy *today* that work this >way. To me dozens, hardly seems like a resounding vote of confidence. > It would certainly rub *me* the wrong way if I were Wellfleet or 3COM >and PSI or Alternet told me I had to buy a cisco router if I wanted a >connection. Actually, NEARnet makes us buy cisco router for our internet connection. > It also means that PSI or Alternet can pick a router vendor >and stick with it, since their connections run a non-proprietary protocol. I would actually prefer that the interconnect connection be made with remote transparent bridges because it is cheaper and NEARnet currently limits our access to our router. The situation would be analogous in New England Telephone limited our access to our PBX. The router like the PBX should be under our control, and a remote transparent bridge could function analogously to the CSU/DSU between our PBX and the central office. >I believe Bob was referring to something like this. Coming from the TCP/IP >point of view (and not being constrained by protocol architectures that >don't scale past a LAN), he didn't see the value in bridging over routing. 1) You have to turn on UDP checksumming if you connect two ethernets by a bridge rather than a router. 2) Bridges are a fairly efficient way to reduce contention on a LAN. Suppose you have eight hosts on a LAN. There is a fairly high probability of collision. But take each of these hosts and connect them to a Little Dipper ether port. Now at any instant 4 separate pairs of hosts can communicate with each other without colliding. Of course, you could do this with a router, but there are not too many eight interface routers on the market, and such a box would probably not do the routing at wire speed. The Little Dipper does do wire speed bridging (and will do wire speed routing shortly) at a very low cost. In general, putting a bridge in front of a boot server or an NFS server might be a good idea to increase performance, reliability and availability while reducing contention while putting a router in front of such a device is probably not a good idea because of extra overhead and most advice which I have read recommends against so doing. >Of course, if you *do* use TCP/IP, there isn't any (at least until the >Internet gets more than 20 hops wide). I think we may be at different incarnations on the wheel of reincarnation of computer and communications hardware. A few years ago, a lot of companies did intelligent ethernet controllers and put TCP/IP on the controller. This did not work so well because the cards cost too much for cheap low power machines and became a bottle neck on the expensive powerful machines. So in many respects, dumb network interfaces with the implementation of communications protocols within the end host was a good idea. Once the communications protocols are implemented in end hosts, the older OSI/PTT (actually DARPA NCP) model of networking in which end hosts take little part in the routing of packets but rather are served by intelligent packet switches becomes pointless. But now the Little Dipper/Auriga product line provide a better solution than involving end hosts intimately in the routing of packets and better performance can be achieved by reincarnating the older model in new more powerful garb. In fact, since the Auriga and Karina devices actually plug into endhosts, it may still appear as if the newer DARPA TCP/IP model is being followed. >If I've missed something important here, flame away, as I'm somewhat of a >novice at this stuff and probably deserve it. I see no obvious reason for flames at this point in the discussion. Joachim Carlo Santos Martillo Ajami  -----------[000053][next][prev][last][first]---------------------------------------------------- Date: 6 Sep 91 02:16:34 GMT From: pte900@jatz.aarnet.edu.au (Peter Elford) To: comp.protocols.tcp-ip,comp.protocols.ibm,comp.unix.aix Subject: tn3270 on SNA emulators  The tn3270 protocol allows a 3270 datastream to be carried over a telnet session to support full-screen block-mode access to IBM and compatible mainframe systems. To make use of it, you need a tn3270 client (I know of versions of UNIX, DOS, Macs, and VMS at least) and a tn3270 server which runs on the IBM mainframe system itself, ie. +--------+ +--------+ | PC/Mac | | IBM | | | | | | tn3270 | | tn3270 | | client | | server | +--------+ +--------+ | | --+----- tn3270 protocol ---+---- As an alternative to using tn3270, many vendors (most?) support the connection of their systems to IBM systems via SNA (or BSC) links. The system in question then emulates an IBM 3274 terminal cluster controller and users can gain access to the IBM mainframe itself by telnetting to the "SNA-gateway" system and then running some program that does the 327x terminal emulation, ie. +--------+ +------------------+ +--------+ | PC/Mac | | Gateway | | IBM | | | | | | | | telnet | | telnet < 327x | | | | client | | server > emulator| | | +--------+ +--------+---------+ +--------+ | | | | --+--- telnet protocol -----+- +--- SNA/BSC -----+ The problem with this second solution is that you end up with character by character echo between the telnet client and the gateway. This, for users users used to block mode terminals with instanteous, consistent response for local editting of the screen, can be something of a culture shock, ie. they complain. Why don't vendors offer SNA gateways that support tn3270 servers ?, ie. +--------+ +------------------+ +--------+ | PC/Mac | | Gateway | | IBM | | | | | | | | tn3270 | | tn3270 | 327x | | | | client | | server | emulator| | | +--------+ +--------+---------+ +--------+ | | | | --+--- tn3270 protocol -----+- +--- SNA/BSC -----+ This would provide much better, more IBM-like access to the mainframe system, and would avoid the cost and overheads of installing a LAN interface and IP software on the IBM mainframe (which is not cheap :-). It may be that somone out there has already done this using the runtime libraries that are freqently provided with the SNA emulation packages; if so I'd really like to hear from you (particularly if it is on the Sun or IBM RS/6000 platforms), Peter Elford, e-mail: P.Elford@aarnet.edu.au Network Co-ordinator, phone: +61 6 249 3542 Australian Academic Research Network, fax: +61 6 247 3425 c/o, Computer Services Centre, pager: +61 6 245 3035 Australian National University post: PO Box 4 Canberra, AUSTRALIA Canberra 2601  -----------[000054][next][prev][last][first]---------------------------------------------------- Date: 6 Sep 91 02:19:24 GMT From: martin@unislc.uucp (Martin Cryer) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards Subject: Re: Need help selecting Ethernet cards for very high throughput rates.  >bill@connection.prospect.com (Bill Poitras) writes: > >> Are you kidding? I have seen 100Mbytes/s when ftping a file to a PS/2 >> running AIX with a ESDI controller and 16 bit ethernet controller. I can >> consitently get 20Mbytes/s. Hell, I can get 11Mbytes/s sometimes to a PC >> running DOS. This is a ISA machine with a 16bit RLL controller. I don't >> see your problem. > Where do you buy one of these high throughput PS/2s, I want one NOW! As for the EXTENDED ESDI and the HyperEthernet... This is even worse than an IBM salesman in a bar at closing time.... Or is this a case of "my-PC-is-bigger-then-your-PC", naa - naa - nana - naa! Martin Cryer Unisys Europe Africa Unix SVR4 Development Unisys Salt Lake City All opinions are my own and not those of my employer.  -----------[000055][next][prev][last][first]---------------------------------------------------- Date: 6 Sep 91 04:24:31 GMT From: martin@unislc.uucp (Martin Cryer) To: list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards Subject: Re: Need help selecting Ethernet cards for very high throughput rates.  TYPO CORRECTION TIME.... In article <1991Sep5.224731.1555@unislc.uucp> martin@unislc.UUCP (Martin Cryer,D1Z01,5754) writes: >In article <1991Sep1.195029.16374@aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes: >>scogen@xenitec.on.ca (scogen@xenitec.on.ca) writes: >> >>> We are trying to configure an SCO Unix system running some type of >>> IP, (maybe TCP, maybe UPD) to operate at maximum throughput. Our goal >>> is to get up to _6_ Megabits/Sec. sorry I read this as megabyte / s originally! ^^^^ I blame my bad eyesight and this darned X windows font! >> >>Well, nearly any modern Ethernet card will deliver 6 Megabits per second. >>After all it's only around 600KB/s. SCO's TCP protocol stack will most >>probably not be able to keep up with the card though. >> >EISA will give you 32bit DMA address space, so your drivers can (if >nicely written), give you DMA from user space to controller (or controller >to user space) without copying, whatever your memory size. This is >especially important for high volume disk i/o on SVR4 where the >buffer cache is through the normal VM page fault / free page pool >mechanism and can therefore come potentially from any real memory >address (and not just below 16MB where the SVR4 buffer cache is likely to be). Sorry this should say SVR3 here ^^^^ Martin Cryer Unisys Europe Africa Unix SVR4 Development Unisys Salt Lake City All opinions are my own and not those of my employer.  -----------[000056][next][prev][last][first]---------------------------------------------------- Date: 6 Sep 91 06:12:16 GMT From: pnr@ngs.fi (Pekka Nikander) To: comp.protocols.tcp-ip,comp.protocols.ibm,comp.unix.aix Subject: Re: tn3270 on SNA emulators  In article <1991Sep6.021634.20465@newshost.anu.edu.au> pte900@jatz.aarnet.edu.au (Peter Elford) writes: > Why don't vendors offer SNA gateways that support tn3270 servers ?, ie. > > +--------+ +------------------+ +--------+ > | PC/Mac | | Gateway | | IBM | > | | | | | | > | tn3270 | | tn3270 | 327x | | | > | client | | server | emulator| | | > +--------+ +--------+---------+ +--------+ > | | | | > --+--- tn3270 protocol -----+- +--- SNA/BSC -----+ The Mitec OpenConnect provides the functionality you want to. Their solution is a "black box" that acts as the gateway, Contact Mitek 2033 Chennault Drive Carrollton, TX 75006 (214) 490 4090 (214) 490-5052 FAX Furthermore, I have written such a program on the top of Sun Sunlink SNA. It should not be too hard to provide support for BSC as well, but I don't have access to BSC lines. The program is still under testing, and I don't know weather it eventually will be freely distributable, supported commercial product, or both. However, if anybody is interested, please contact me. Pekka Nikander Internet: pnr@ngs.fi -or- Nixu Oy Inc, independent consultation company Pekka.Nikander@ngs.fi -- Pekka Nikander  -----------[000057][next][prev][last][first]---------------------------------------------------- Date: 6 Sep 91 06:13:56 GMT From: rpw3@rigden.wpd.sgi.com (Rob Warnock) To: comp.protocols.tcp-ip Subject: Re: AIX 3.1 ARP Question  In article <9189@spdcc.SPDCC.COM> sfancher@spdcc.COM (Steven Fancher) writes: +--------------- | According to RFC826 a node should update its ARP cache if it sees a | request or a reply who's IP address matches an entry in its cache. | i.e. A, B, and C are nodes on a network. A and B have ARP cache entrys | for C. C's hardware address changes. A broadcasts a request for C's | new hardware address and C sends a reply. A updates his cache. | B also gets both the broadcast request and the reply. B should update | its cache entry for both A and C (B saw the request containing A's | hardware address and the reply containing C's hardware address). +--------------- B does *not* (and should not) see the reply from C! From RFC 826, page 5 (or so, they're not numbered), "Packet Reception", near the end of the algorithm: Send the packet to the (new) target hardware address on the same hardware on which the request was received. The "(new) target hardware address" is in this case C's unicast address, *not* the MAC-layer broadcast address. -Rob ----- Rob Warnock, MS-1L/515 rpw3@sgi.com Silicon Graphics, Inc. (415)335-1673 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311  -----------[000058][next][prev][last][first]---------------------------------------------------- Date: 6 Sep 91 10:02:24 GMT From: graeme@ccu1.aukuni.ac.nz ( Graeme Moffat) To: comp.protocols.tcp-ip Subject: Re: routing problem from hell  Since no-one has followed up on this, I will offer my opinions - if I'm wrong, please flame - I'll learn from it *B^) I'm still feeling my way with this stuff. mcneill@eplrx7.uucp (Keith McNeill) writes: >The site on which I work has a large bridged ethernet with many hosts on it. >A class B address has been assigned to the site (call it XXX.YYY.0.0). The >network owners have assigned each building a subnet number. Hosts that sit >on the large bridged ethernet do no use subnetting (i.e. subnet mask >255.255.0.0). >My network is a separate ethernet. My network was assigned subnet 252 within >the XXX.YYY.0.0 network. All hosts on my ethernet, including both interfaces >on the router, use a subnet mask of 255.255.255.0. My router is a Sun >Workstation running proxy arp. Proxy arp is used to enable communication >between the subnetted (my network) and non-subnetted (everybody else) >portion of the XXX.YYY.0.0 network. I have seen this subnetted & non-subnetted hosts situation referred to as having a highway with cars driving on the left & trucks on the right! Do I have these definitions right? - Routing: Having two (or more) interfaces in different nets, and passing packets between those nets - Proxy arp: One (or more) interfaces in the *same* net, responding to recognised host addresses and forwarding packets on their behalf From the netstat table below, it seems to me that your host is routing, not proxy arping. I'm not too familiar with proxy arp, but don't you just have a table of host addresses on the 252 side that the 78 interface will respond for? I can anticipate that you will say you're not running routing code, ie routed or gated, but I have seen Sun clones running SunOS which function as routers by default, despite RFC1122 saying that this should not happen. >On my router I have added a default route pointing to the 78 subnet interface. >netstat -r on my router: >Routing tables >Destination Gateway Flags Refcnt Use Interface >127.0.0.1 127.0.0.1 UH 3 19989 lo0 >default XXX.YYY.78.1 U 5 2295226 ie3 >XXX.YYY.252.0 XXX.YYY.252.10 U 78 1681671 ie0 >XXX.YYY.78.0 XXX.YYY.78.1 U 0 4851 ie3 This is correct for a subnetted router. It would be better to have a proper router (eg cisco) as the default host if you have multiple logical subnets on the same physical cable. >The root of the problem is that my router sits on subnet 78 and the router >to the AAA.BBB.CCC.0 network sits on subnet 10. When I try to add a route >sun-router>> route add net AAA.BBB.CCC.0 XXX.YYY.10.1 1 add net >AAA.BBB.CCC.0: gateway XXX.YYY.10.1: Network is unreachable This is correct. XXX.YYY.10 is not in your subnet. >Non subnetted machines sitting on the bridged ethernet have no problem >communicating with the AAA.BBB.CCC.0 network. It is, after all, a *different* network, and XXX.YYY.10.1 is a true router. >This leads to 2 questions: >1) Is my router (i.e. the Sun IP code) acting correctly. Yes >2) One way to solve this would be to change the subnet mask on the 78 > side of my router to 255.255.0.0. Can the Sun IP code deal with a > machine with 2 different subnet masks for the same class B network. If it can, it's broken! If the 78 side is now net XXX.YYY.0.0, then XXX.YYY.252.0 is a host address in the same network, not a net address. As I've said, I don't believe you are proxy arping. Changing *both* your masks, and using proxy arp, will, I think, work. -- Graeme Moffat g.moffat@aukuni.ac.nz \ Time wastes us all, Computer Aided Design Centre, Fax: +64-9-366-0702 / our bodies & our wits School of Engineering, Ph: +64-9-737-999 x8384 / But we waste time, University of Auckland, Private Bag, Auckland, NZ \ so time & we are quits  -----------[000059][next][prev][last][first]---------------------------------------------------- Date: 6 Sep 91 12:33:25 GMT From: josevela@mtecv2.mty.itesm.mx (Jose Angel Vela Avila) To: comp.unix.admin,comp.protocols.tcp-ip Subject: Re: Changing passwd on remote system.  Well you could do 2 things : a) Get a copy of npasswd (emx.utexas.edu) it is a great password checking package and also suppoerts Yellow Pages (NIS) b) Do a rsh (remote shell) to the Server machine, and change the local password in the server. That easy !! _____________________________________________________________________________ Jose Angel Vela Avila. Instituto Tecnologico y de Estudios Superiores de Monterrey I.T.E.S.M Mexico. ___ _ ___ _ __ ( > ' ) / // / ) josevela@mtecv2.mty.itesm.mx __/________ _ ( / _ // __. /--/ josevela@tecmtyvm.mty.itesm.mx / / (_) \_)__</_ \/ </_</_(_/|_ / ( o josevela@tecmtyvm.BITNET <_/  -----------[000060][next][prev][last][first]---------------------------------------------------- Date: 6 Sep 91 14:08:45 GMT From: jessea@homecare.COM (Jesse W. Asher) To: comp.protocols.tcp-ip,comp.unix.admin Subject: Backups using rsh.  I'd like to do backups over our network using rsh, but I'm wondering if the data will be transferred reliably. Does rsh use tcp or udp and should I be using it for backups? -- Jesse W. Asher NIC Handle: JA268 Phone: (901)386-5061 Health Sphere of America Inc. 5125 Elmore Rd., Suite 1, Memphis, TN 38134 Internet: jessea@homecare.COM UUCP: ...!banana!homecare!jessea  -----------[000061][next][prev][last][first]---------------------------------------------------- Date: 6 Sep 91 16:31:49 GMT From: gwilliam@SH.CS.NET (George Williams) To: comp.protocols.tcp-ip Subject: Re: Any results from Gbits testbeds ?  Date: 28 Aug 91 13:52:56 GMT From: Marten Terpstra <mcsun!hp4nl!nikhefh!a20@uunet.uu.net> Subject: Any results from Gbits testbeds ? Hi all, Couls anyone tell me if there are any (preliminary) test results or other conclusions available somewhere on the NSF net sponsored Gigabit testbeds ? And now that I'm more or less on the subject, can anyone suggest some readi ng material on ATM and other of these goodies that are to come ? Thanks, -Marten The August 26 Issue of NW did a feature article ( page 44 ) on the 5 ( Auroura, Blanca, Casa, Nectar, Vistanet ) NREN prototype testbeds. As the article points out there are varying degrees of new switching and transmission technologies involved with each deployment; ATM, Sonnet, SMDS, etc. I found it to be a good overview for non-participants ( with an interest ), such as myself. Recommend ( but who am I ) reading. [ Standard disclaimer applies. My views only ] George Williams  -----------[000062][next][prev][last][first]---------------------------------------------------- Date: 6 Sep 91 16:56:45 GMT From: cgonzale@mtecv2.mty.itesm.mx To: comp.protocols.tcp-ip Subject: Western Digital's cards  Does anybody know the difference between Western Digital's Ethercard Elite 16 Combo and WD8013EW cards ? We need an Ethernet card with 10BaseT & BNC media support in the same board but we are not shure about the correct model that we have to order. Thanks, Cesar  -----------[000063][next][prev][last][first]---------------------------------------------------- Date: 6 Sep 91 17:00:24 GMT From: kent@tfd.COM (Kent Hauser) To: alt.sys.sun,comp.protocols.tcp-ip Subject: need help usings streams modules with sockets  I'm using SunOS 4.1.1 and I need line-at-a-time reading on a tcp stream. I also need to spin in a select loop so I can do non-blocking i/o on multiple desriptors. A perfect solution would be to push a "ldterm" streams module on the socket descriptor & use cannonical processing. Unfortunately, the ioctl returns "not supported on a socket". My question is (before I write a custom streams filter to do this & other filtering) does this mean that *no* streams modules are supported on sockets, or just that ldterm doesn't work on sockets. Also, if someone has a simple sample streams module with all of the OS hooks in it, i'd appreciate it. Thanks. kent -- Kent Hauser UUCP: {uunet,sundc,uupsi}!tfd!kent Twenty-First Designs INET: kent@tfd.com (202) 408-0841  -----------[000064][next][prev][last][first]---------------------------------------------------- Date: 6 Sep 91 17:51:22 GMT From: kasten@EUROPA.CLEARPOINT.COM (Frank Kastenholz) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window  From RFC792: 2.10. Robustness Principle TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.  -----------[000065][next][prev][last][first]---------------------------------------------------- Date: 6 Sep 91 18:42:53 GMT From: bumed@nmrdc1.nmrdc.nnmc.navy.mil (BUMED GUEST ACCT) To: comp.os.vms,comp.protocols.ibm,comp.protocols.tcp-ip Subject: POP daemon on an Amdahl  We are currently trying to use POPmail. We have successfully ported a version to run off FTP's TCP layer and now either have to transfer a couple hundred vms accounts to 3b2s (gag!) or need to find a POP daemon to run on a vm system. Does anyone know where I can find such a daemon? Sorry for the wide distribution, but I need a quick response......  -----------[000066][next][prev][last][first]---------------------------------------------------- Date: 6 Sep 91 18:49:32 GMT From: bumed@nmrdc1.nmrdc.nnmc.navy.mil (BUMED GUEST ACCT) To: comp.os.vms,comp.protocols.ibm,comp.protocols.tcp-ip Subject: Re: POP daemon on an Amdahl  We are currently trying to use POPmail. We have successfully ported a version to run off FTP's TCP layer and now either have to transfer a couple hundred vms accounts to 3b2s (gag!) or need to find a POP daemon to run on a vm system. Does anyone know where I can find such a daemon? Sorry for the wide distribution, but I need a quick response...... sorry for posting twice but the news server forgot to add my account name Please reply to nmctr6@bumed10.bumed.nnmc.navy.mil  -----------[000067][next][prev][last][first]---------------------------------------------------- Date: 6 Sep 91 20:37:19 GMT From: fab@MD.INTERLINK.COM (Fred Bohle) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window  Frank writes: >From: kasten@europa.clearpoint.com (Frank Kastenholz) >Message-Id: <9109061751.AA20593@europa.clearpoint.com> >To: fab@md.interlink.com, mentor.cc.purdue.edu!dls@purdue.edu, tcp-ip@nic.ddn.mil >Subject: Re: TCP FIN and window >>From RFC792: >2.10. Robustness Principle > TCP implementations will follow a general principle of robustness: be > conservative in what you do, be liberal in what you accept from > others. So what is your conclusion from this statement. I want to be liberal and accept the FIN, in fact I already do that. What is not determined is does the statement about being conservative mean the other end should NOT send the FIN? I argued against this in previous messages. Let's hear your opinion, Frank. Let's hear everyone's opinions. Fred ------------------------------------------------------------------------ Fred Bohle EMAIL: fab@leo.md.interlink.com Interlink Computer Sciences AT&T : 301-317-6600 9145 Guilford Road, Suite 175 Columbia, MD 21046 ------------------------------------------------------------------------  -----------[000068][next][prev][last][first]---------------------------------------------------- Date: 6 Sep 91 21:56:00 GMT From: dls@MENTOR.CC.PURDUE.EDU To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window  I don't think sending the FIN violates being conservative, because any conforming implementation knows how to strip off and discard data beyond its window. As I have argued, sending it, at least when you're sending other data, is absolutely free. My$0.02:

"Be liberal in what you receive and conservative in what you
send" practically qualifies as a political sound bite. All the substance is
subject to interpretation. Everyone will agree it's a good idea to do that,
which is undoubtedly why it is quoted so often, but it doesn't mean any
agreement at all on the issue.
Anyone for being tough on crime, too?!? :-)

+-DLS


-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 91 03:18:19 GMT
From:      yeh@NETIX.COM (Shannon Yeh)
To:        comp.protocols.tcp-ip
Subject:   Re: How to connect to the Internet?


Marc,

I wish my easy_to_use 3-R system can be of help for you to gain your internet
access.  It is:

Rope  (a lease line from your telephone company)
Router (an IP router, or a gateway if your local net is big enough)
Registered net membership (registering your name resolver)

As of the details of those hardware connections, I seldom use the Installation
Guide, because we can figure them out by their physical sizes, for example, we
never try to put a 9-pin conector to a 25-pin slot.

On the costs issue, As far as I am aware of, the telephone companies charge
usually a nearest backbone outlet from your office.  The membership fee
has two categories: direct member of some regional network, or an
associate member of some members of those regional networks.  You should
be able to get a quote from your local service providers.  You may try
to contact your local universities first.

shannon
-------


-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 91 16:33:50 GMT
From:      selene@osystem.pdx.com
To:        comp.protocols.tcp-ip
Subject:   (none)

delete tcp-ip jander@osystem.pdx.com

Please turn OFF the mailinglist!   It gets routed through a no-no spot.

--Jon

__________________________________/----\______________________________________
| selene@osystem.pdx.com (Jonathan Anderson)   Voice: +1 503 682 3731        |
| Jonathan Anderson @ 1:105/291.2.fidonet.org                                |
| "On the bleeding edge of technology!"                                      |
\----------------------------------=||=--------------------------------------/


-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 91 10:43:46 GMT
From:      ykluger@fibronics.UUCP (Yoav Kluger)
To:        comp.protocols.tcp-ip
Subject:   SLIP Sources

Hi,

Does anyone know of publicly available sources for SLIP ?

-- Yoav Kluger
Fibronics Ltd.
MTM Industrial Park
Haifa 31905, Israel

Email: imp!uunet!fibronics!ykluger
Voice: Int'l.972.4.313313 x669
Fax:	  Int'l.972.4.516266


-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 91 18:43:49 GMT
From:      scoggin@delmarva.delmarva.COM (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   (none)

Subject: Re: Changing from ASYNC to TCP/IP while still keeping security?
To: tcp-ip@nic.ddn.mil
Date: Sun, 8 Sep 91 14:43:49 EDT
Sender: <tcp-ip-relay@nisc.sri.com>
From: John Scoggin <scoggin@delmarva.delmarva.com>
In-Reply-To: <6118@inews.intel.com>; from "John Reece" at Aug 29, 91 10:04 pm
X-Mailer: ELM [version 2.3 PL11]

>
> In article <1991Aug29.191937.10748@milton.u.washington.edu>, erikm@hardy.u.washington.edu (Erik Madsen) writes:
>
> |> What I want to do is propose to the MIS people that we can still keep
> |> the same security we have now (or maybe do smarter security) and get
> |> faster connections between
> |> our corporate net (our desktop computers) to our internet server (and
> |> still convincing them that if we do that, we are not opening our corporate
|> net to the outside internet world.

You might check with the folks at Advanced Networks & Systems - Linda Boykin
(boykin@nic.ans.net) might be a good start.  ANS has a Secure Internet
Gateway product for your type of situation.

----------------------------------------------------------------------
John K. Scoggin, Jr.
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		        (800) 388-7076
500 N. Wakefield Drive			Fax:    (302) 451-5321
Newark, DE  19714-6066	                Email:  scoggin@delmarva.com
----------------------------------------------------------------------


-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 91 19:10:08 GMT
From:      chrisv@CMC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   FDDI throughput

Good morning,
I was hoping that someone out there might have some good information regarding
Network SYstems FDDI router throughput and Network Peripherals VME adapter
FDDI throughput? It's so tough to find out how fast things really run once
you get them installed into your environment, and I was hoping that someone
had done some testing to obtain rough estimates.
Please respond directly and I'll summarize to the net if appropriate.
Thank you,
Chris VandenBerg
CMC -  A Rockwell Intl Co.   125 Cremona Dr.   Goleta, CA. 93117
Internet - chrisv@cmc.com          ma-bell - 805-562-3127


-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 91 19:23:36 GMT
From:      karl@ddsw1.MCS.COM (Karl Denninger)
To:        comp.mail.misc,comp.protocols.tcp-ip
Subject:   Top-level domains; anyone have a list?

Does anyone have a list of valid top-level domains?  I have found myself in
need of one for mailer configuration here (it's a strange beast, yes).  We
need to forward all mail for domain addresses to one site, and route UUCP
mail separately.  However, I want to pre-select knowing that the top level
domain (ie: ".us") is valid first.

Any help appreciated!

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Data Line: [+1 312 248-0900] Anon. arch. (nuucp) 00:00-06:00 C[SD]T


-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 91 20:36:03 GMT
From:      bill@connection (Bill Poitras)
To:        comp.protocols.tcp-ip
Subject:   This is a test of mailing to an NNTP server

This message is to test using mail to post to the Usenet news.  I chose
this newsgroup because it had a dash in its name and is a group which I
read often.  All flames to /dev/null.  Thank you.

+-----------------+---------------------------+-----------------------------+
| Bill Poitras    | Polygen Corporation       | {princeton bu}!polygen!bill |
|     (bill)      | Waltham, MA USA           | - This space for rent -     |
|                 | FAX (617)890-8694         | bill@polygen.com            |
+-----------------+---------------------------+-----------------------------+


-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 91 23:54:28 GMT
From:      ykluger@fibronics.UUCP (Yoav Kluger)
To:        comp.protocols.tcp-ip
Subject:   Limited Broadcast Problem on Unix?

Hi,

I am trying to implement BootP. I have a server running on a UNIX
machine (SUN SparcStation) bound to the BootP server port, and a
client (on a custom box) which comes up and sends an initial BootP
request.  Since the client does not know even its IP address, it uses
the "This Host" address (all 0's) as the source address, and the
surprisingly and in a most disappointing fashion, the server does not
get the request datagram - it is stopped somewhere, either in IP or
UDP or the socket (my guess is in the latter). Attemtps to send the
very same datagram from the very same client to the very same server
using either the specific address of the host hosting the server or
ultimate success.

Could anybody help me with this? Is it possible that SUN's unix does
not support limited broadcast? Or do I have to activate some hidden
socket option?

Thanks in advance for any tips

-- Yoav Kluger
Fibronics Ltd.
MTM Industrial Park
Haifa 31905, Israel

Email: imp!uunet!fibronics!ykluger
Voice: Int'l.972.4.313313 x669
Fax:	  Int'l.972.4.516266


-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 01:38:58 GMT
From:      emv@msen.com (Ed Vielmetti)
Subject:   Re: knowbots: searches on inet sections

In article <36002@hydra.gatech.EDU> ccoprmm@prism.gatech.EDU (Michael Mealling) writes:

Has anyone been doing anything with a species of program called a "knowbot"?
Essentially they scout the net (news, archives, mail lists, etc) for articles
that would be of interest to the user. If you've read David Brin's _Earth_,
they are referred to as "ferrets". (I kind of like the name "meme-hound").

There's a pile of discussion going on all over in assorted places
about these things, here's some pointers to where the traffic is and
who's talking.  This is by its very nature a sketchy report, since
the whole premise of this is that there are people of every field and
persuasion looking for tools and techniques to look for interesting
articles, and so you'd bound to find traffic and experts just about
anywhere.

"Knowbot" is trademarked, not a generic term, take care how you use
it.  There's a service which calls itself the "Knowbot Information
use by telnet to sol.bucknell.edu, port 185; it's a system that looks
found at
nri.reston.va.us:/rdroms/*
including the text of an internet draft on the subject.  (I'll have to
check if and when this was published as an RFC.)

KIS is reviewed in the June 1991 issue of _Boardwatch_ Magazine.
There's a short account by Vincent Mazzarella of a presentation by Mr
David Ely of CNRI (the Corporation for National Research Initiatives)
to the ACR Workshop on Computer Networks in Radiology Research in
bionet.general (March 1991) where he refers to systems like "Grateful
Med" as a Knowbot:

One can build a KNOWBOT locally and then send this to a larger
machine, have the program run on that larger machine, returning
processed data to the local system.  GRATEFUL MED is a good
example of this concept in which a search routine is built at the
local PC and is then sent to a large database for a search.

The first thing I turned to to start to prepare this was WAIS, the
Wide Area Information Service. A search for "knowbot" in the
"matrix_news" database on quake.think.com yielded a good article that
references a meeting of the Coalition for Networked Information (CNI)
working group on "Developing a Framework for Network Directories and
Related Services", held June 3-4 at Stanford.  This meeting brought
together some of the interested parties; you can find an account of it
via anonymous in the file
quake.think.com:/pub/mids/matrix_news/cni.3
or by using the WAIS source in
quake.think.com:/pub/mids/matrix_news.src
Rather than quote bits of the article it would be most useful to fetch
the whole thing and read it.  WAIS itself falls into this category
generally, since there's a division of labor between the search
engines running on remote machines like Connection Machine
supercomputers, and the local display and user interface systems
running in point-and-click (Mac) or part of your editor (GNU Emacs)
environments.

comp.archives is an example of a real-life system which uses some of
these tools.  A set of programs systematically filters through days
worth of usenet news postings looking for key words and phrases that
refer to materials available for anonymous FTP from remote systems.  A
human editor pares these hits down somewhat to wipe out some noise and
scheme to date has employed a single moderator at a time in this role,
it's lacking but for volunteers to have multiple people each tracking
a more specialized subset of the net and sharing their sense for
important new additions to archives with others.  (Further discussion
to comp.archives.admin.)  I don't know that the scanning code has yet

For the limited problem space of "ftp'able files" the searching
necessary is really quite minimal; for searches on fuzzier topics
you'd probably want to go with a system that had a priori full text
indexing of probably relevant groups combined with regular scanning of
usenet news + mailing lists for key words and phrases which would have
a lower hit rate but might lead you farther afield.  One interesting
project that also focuses on searching through usenet is the
"Pasadena" system; there will be a presentation on it by Mitch Wyle at
SIGIR in Chicago in October.

The "archie" service (see quiche.cs.mcgill.ca:/archie/doc/) is also
worth noting, both in the context of providing before-the-fact
searching for FTP retrieval and also as a general tool for locating
things around the net in a knowbot-style fashion.

There's a great deal to be gained if what you're dealing with can be
treated not just as great amorphous gobs of information; the more that
you can deduce explicit or implicit structure in the information the
more focused and precise your searches can be.  As an extreme example
the work of Malone at MIT ("Information Lens") to provide users with
tools to create structured e-mail messages and then also tools to
filter through their mail based on the added structred information
have proven to be very powerful.  Unfortunately, netnews tends to be
anything but a nice small homogenous cooperating community, so those
tools would have less success when unleashed on the daily torrent of
netnews.

One reaction to this flood of news is to try to locate sources which
have an ear open to the wide world of what's out there and which can
condense and edit it down to a reasonable stream of especially
interesting materials.  Sometimes you'll find volunteers up to the
task, and you'll often see people forwarding off particularly
interesting mailing list or newsgroup materials to their friends who
don't have the time or energy (or tools) to plow through netnews.

Paper- (or email-) based electronic information sources have started
to pop up; no doubt more are coming.  For $xx-$xxx/year (the price of
a good magazine, let's say, but less than an academic journal
subscription) you get the services of an editorial staff, some on-line
materials.  I doubt that anyone gets rich from producing one of them
any time soon, but a well-edited and properly produced periodical
should be able to support itself from readers of the net.

--
Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
MSEN, Inc. 628 Brooks Ann Arbor MI 48103 +1 313 741 1120
for information on MSEN products and services contact info@msen.com

Notes.

There was a review of comp.archives in an earlier issue of Boardwatch.

The masthead says that Boardwatch comes out 12 times a year.
It gives these electronic mail addresses:

Internet:	jack.rickard@csn.org
GEnie:		JACK.RICKARD
CompuServe:	71177,2310
Fidonet:	104/555
MCI Mail:	418-7112

WAIS can be had from quake.think.com:/pub/wais/.  A (beta test) ascii

The "Matrix News" materials are on quake.think.com:/pub/mids/matrix_news/
A subscription form is in the file "0subscribe".
Matrix News
Matrix Information & Directory Services
701 Brazos, Suite 500
Austin, TX 78701-3243
U.S.A.
Thanks to John Quarterman for this excellent periodical.

bionet.general quotations were found in the WAIS server "biosci"
running at genbank.bio.net.

I don't have a good citation for Information Lens.

comp.archives has not been written up extensively in any periodical
(and that's probably my fault).


-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 06:53:37 GMT
From:      skl@cs.sfu.ca (Samuel Lam)
Subject:   Re: Backups using rsh.

In article <1991Sep6.140845.25125@homecare.COM>, jessea@homecare.COM () wrote:
>I'd like to do backups over our network using rsh, but I'm wondering if
>the data will be transferred reliably.  Does rsh use tcp or udp and
>should I be using it for backups?

rsh(1) uses TCP, so it's as reliable as TCP is (whatever that
means these days :-)).

...Sam
--
<skl@cs.sfu.ca>


-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 06:58:26 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window


...the probe time should be the same as the retransmission time, with
exponential backoff, and not 2 minutes (!). Berkeley uses a minimum of
5 seconds (as much as a 1000 times too large on an Ethernet), which makes
for pretty poor performance if you do drop a probe.

I'm sorry, but this is pretty much all wrong.

1) In a modern TCP, the receiver window will never be o unless the destination
device is slower than the network link (eg terminal servers).

2) The sender's view of the window can of course be 0 (causing it it go into
probe mode) whenever the receiver's window is smaller than the effective
delay*bandwidth product of the network (more common).

3) In case two, the receiver will be sending one ACK for each two packets or
so, each opening the window appropriately.  In order for there to be a
significant performance hit, youhave to drop ALL of those ACKs, AND the
first probe or so.  This is notvery likely.

4) Probes are a failsafe technique for recovering from am ACK that would
open the window being lost.  Lost packets are rare.

5) In case one, the correct interval for probing the window should be
based on the time you expect the remote host to dispose of it's data.
This isn't based on the network characteristics at all, so basing the
initial probe interval on the calculated RTT is completely bogus.
(If you can use the calculated RTT and slow-start/etc to measure the
effective network bandwidth, you ought to be able to get a good idea
of the effective end-device bandwidth by doing similar calculations
on the window updates (slightly more difficult because the window
updates aren't nicely sequenced for you)).
(No one does this, and it isn't important.  As long as you exponentially
back off your probes, you hit a non-obnoxious interval relatively soon
anyway.  And the probes are hardly ever useful anyway.)
(oh, while rfc793 implies that maybe the data shouldn't be acked until
it is actually disposed of by the 'end-device', I don't think that
there are many TCPs thatactually operate this way.  I hope not, since
it seems much more useful to use the RTT values to characterize the
nework, rather than the application).

6) Given all of the above, I think the 5 second minimum of the berkeley
code is quite appropriate.  I can also claim actual data in that area.
I recently "fixed" cisco's terminal server TCP code to do better
zero-window probing (in particular, to avoid affecting the RTT numbers
while probing).  Part of this included changing the debugging support
to differentiate between probes and other retransmissions.  It is quite
clear that doing the first probe after the calculated RTTO results in
way to many probes being sent.

Bill Westfield
cisco Systems.
-------


-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 07:04:52 GMT
From:      mni@CRAYAMID.CRAY.COM (Michael Nittmann)
To:        comp.protocols.tcp-ip
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

in fact that fusion in a jar were two researchers and they stirred up
massive confusion in the media some time ago. maybe this is a second try ..


-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 13:35:29 GMT
From:      dmbarton@ralvmm.vnet.ibm.com ("Daniel M. Barton")
To:        comp.protocols.tcp-ip
Subject:   Re:   a minconfigured host

> Suppose that an IP host is miconfigured with a forwarding capability,
> i.e. the host would try to forward a packet received which was not
> destined to this host, would it decrease the TTL of the packet?

If a host that is not a router is forwarding packets, then it is
broken, but you already know that.  The misconfigured host would be
considered a router, and should obey all the rules of a router,
including decreasing the TTL of a packet.  If it is not decreasing the
TTL, then it is broken.

Daniel

=====-=====-=====-=====-=====-=====-=====-=====-=====-=====-=====-=====-=====

Daniel M. Barton                 Internet:  dmbarton@ralvmm.vnet.ibm.com
TCP/IP Development                          dmbarton%ralvmm@vnet.ibm.com
IBM Research Triangle Park, NC  USA


-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 13:50:55 GMT
From:      Y.Murayama@CS.UCL.AC.UK (Yuko Murayama, +44-71-387-7050 ext.3721)
To:        comp.protocols.tcp-ip
Subject:   Re: a minconfigured host


>If a host that is not a router is forwarding packets, then it is
>broken, but you already know that.  The misconfigured host would be
>considered a router, and should obey all the rules of a router,
>including decreasing the TTL of a packet.  If it is not decreasing the
>TTL, then it is broken.

I understand that the misconfigured (i.e. ip.forwarding) host *should*
decrease the TTL.  But my question is if it is quite so in the current
popular implementation, such as the IP on a UNIX system.

Yuko


-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 13:56:47 GMT
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window

Johnny writes:

>From: micro-heart-of-gold.mit.edu!wupost!m.cs.uiuc.edu!zweig@bloom-beacon.mit.edu  (Johnny Zweig)
>Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
>Subject: Re: TCP FIN and window
>Message-Id: <1991Aug28.215504.7608@m.cs.uiuc.edu>
>References: <1991Aug19.220019.4082@novell.com>, <1991Aug27.205232.7303@ultra.com>, <1991Aug27.192634.16859@jarvis.csri.toronto.edu>
>To: tcp-ip@nic.ddn.mil

>How about advertizing a one-octet window?  There's no law that says that you
>have to actually _accept_ data -- so advertize a teensy window...

>-Johnny Singleton

The problem with this approach is when there really is data and the window
really should be closed.  If you advertize one byte, the other end will send
it.  Now what?  If you advertize zero bytes, you have not changed the problem.
If you do not ack the byte you got, the other end will retransmit, eventually
breaking the connection.  If you advertize one byte again, what will you do
with the byte you just got, and what will you do with the next one you get,
etc., etc., eventually you have too much data.  This negates flow control.
It just changes a full-bandwidth flow into a slow leak (1 byte per round trip).

Again, I say just allow the FIN to flow into a zero window.

Fred


-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 18:33:32 GMT
From:      pcg@aber.ac.uk (Piercarlo Grandi)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

On 3 Sep 91 04:56:41 GMT, torek@elf.ee.lbl.gov (Chris Torek) said:

pcg> 32 bit EISA Ethernet cards are an expensive joke, as is any "turbo"
pcg> interface between a 40MB/s 32 bit bus (EISA) and a 0.8MB/s 1 bit
pcg> one (Ethernet).

torek> Actually, Ethernet is 1.25 MB/s (10 over 8 = 1.25, not 0.8).

That's impossible to achieve, it ignores inband formatting information
(headers, CRC, pauses between packets) and other practical constraints.

The theoretical maximum is a bit less than 1MB/s, and even that cannot
in practice be achieved because the Ethernet is a simplex channel, and
most protocols require ACKs every now and then, and thus in practice you
cannot just pump data continuously from source to target with maximal
size packets.

The very best Ethernet sw can drive it at 0.8MB/s, sustained, with
occasional bursts at 0.9MB/s.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk


-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 18:52:29 GMT
From:      pcg@aber.ac.uk (Piercarlo Grandi)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

On 2 Sep 91 13:51:20 GMT, cpcahil@virtech.uucp (Conor P. Cahill) said:

cpcahil> pcg@aber.ac.uk (Piercarlo Antonio Grandi) writes:

pcg> Same goes for EISA SCSI disk controllers (the most expensive SCSI
pcg> disks top out at 4MB/s, and most cannot do more more than 1.5MB/s
pcg> off the platter). In practice EISA is only needed for very high
pcg> speed graphics (good luck with that) and for disk arrays, or,
pcg> theoretically, for very high bandwidth tapes.

cpcahil> Throughput is not the only evaluation factor for a disk
cpcahil> controller.  Another factor, which is where a good EISA
cpcahil> controller will shine, is the amount of time the bus is tied up
cpcahil> transferring that 4MB/s.

Latency then perhaps matters. But in practice not a lot...

cpcahil> You yourself said that the theoretical max for the ISA bus was
cpcahil> between 5 and 6 MB/s.  4MB/s is appox 80% of the theoretical
cpcahil> max.

Of course, but this is nearly irrelevant. Almost nobody keeps their SCSI
bus running at its top rated bandwidth continuously (not even Adaptec,
which stay off the bus for some programmable fraction of the time).

In particular disk access tends, in normal operation, to be bursty (the
effect of caching and paging, and then of intervening seeks).

Also, most disks currently available don't do much more than 1.3MB
sustained, so having two such disks gives you, if both are active
together, an instantaneous bandwidth of 2.6MB/s, but on average they
will not be both active together, and theat will not in acase last long.

In practice 5-6MB/s is many times than the *average* bandwidth
required, and it is twice the highest instantaneous load you can expect
to see in a small to medium general purpose timesharing system.

cpcahil> With a good EISA controller that same 4MB/s can take up only
cpcahil> 12% of the theoretical max, thereby freeing the bus up for
cpcahil> other operations.

The problem is that, except for very large systems running very large
loads, or particular cases, there are no other operations.

All CPU memory access, the real pig, is via a private bus, and only
tapes, disks, communications and framebuffers use the ISA bus, and their
combined *average* utilization is nowhere its saturation point, and
their *peak* is also accomodated more or less easily.

pcg> First of all, the good news: as I have said almost any modern
pcg> Ethernet card will deliver substantially all of the Ethernet
pcg> bandwidth, and this bandwidth is at worst one fifth of the ISA bus
pcg> bandwidth, so you don't need any EISA

cpcahil> Giving up 20% of the bus bandwidth just to handle ethernet i/o
cpcahil> sounds like a good reason to go with EISA.  20% is alot of the
cpcahil> system.

Yes, but you are not transferring 1MB/s constantly thru your Ethernet
adapter, I hope. And if you are, then most people have pretty low

Quite surprisingly :-) the highest bandwidth user is likely to be the
frame buffer: SVGA cards, which are pretty slow as frame buffers go, can
require 2MB/s, and, if you are doing image processing, sustainedly. But
a 2MB/s video card will almost surely need a 2MB/s disk/tape subsystem,
and this is not the sort of application that I would do with ISA, I
would definitely do it with EISA. I would also use EISA for largish
(more than (perhaps half) a dozen users) timesharing.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk


-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 18:56:24 GMT
From:      voliva@hpcc01.corp.hp.com (Val Oliva)
To:        comp.protocols.tcp-ip
Subject:   Re: a minconfigured host


---------
/ hpcc01:comp.protocols.tcp-ip / Y.Murayama@CS.UCL.AC.UK (Yuko Murayama, +44-71-387-7050 ext.3721) /  6:07 am  Aug 29, 1991 /

Suppose that an IP host is miconfigured with a forwarding capability,
i.e. the host would try to forward a packet received which was not destined
to this host,  would it decrease the TTL of the packet?

Yuko Murayama
Dept of Computer Science
University College London
----------

Assuming that this host is configured as an IP router, then it
should decrement the TTL of the packet.

NOTE : Hosts with 'Embedded Gateway Code' and are configured as
IP router must follow RFC 1009 (Requirements for Ineternet
Gateways).

Regards,

Val Oliva


-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 19:06:32 GMT
From:      08071TCP@MSU.EDU (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: how to keep /etc/hosts up to date

>We've got a few systems running BSD networking without support for
>BIND in the network library routines.  Their /etc/hosts, /etc/networks,
>/etc/gateways, etc., files are out of date, and I'm looking for
>ideas on updating them.
>
>There are three sources of information that I'd like to include in
>the updated files.  First, I need our own departmental information.
>Since we maintain the local BIND server ourselves, it is easy to
>derive the appropriate information from the BIND database source
>files by writing a translator.  No problem there.
>
>Second, I need University-wide information.  I'd like to get this
>data by querying BIND itself, but I don't know how to get started.
>This part of /etc/hosts has been maintained by hand in the past.
>Is there a better (i.e., automated, BIND-based) approach?

I do this with a little input file to nslookup, plus a two-bit awk
script to reformat the results.  This works fine if you know all the
domains from which you want data; if there are many subdomains that
are delegated to other servers, you would need to add some logic to
spot them and do a recursive set of nslookup/awk calls.

If you're interested in these files, let me know.

>Third, I need well-known Internet sites and networks.  I can get
>the DoD Internet Host Table from the NIC (using gettable), and this
>may be enough.

That's exactly what I do.  It's generally enough, although I have a
little filler file in which I can stuff miscellaneous entries that are
not determined by one of the three sections you listed.

Someday, I'll be out of the business of maintaining a huge hosts file.....

Doug Nelson
Network Manager
Michigan State University


-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 19:48:10 GMT
From:      johnscj@NSCO.NETWORK.COM (Curt Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re:  CISCO phone number?

Cisco number is 415-326-1941  FAX number is 415-326-1989


-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 20:09:50 GMT
From:      exudnw@exu.ericsson.se (Dave Williams)
To:        comp.protocols.nfs,comp.protocols.tcp
Subject:   NFS bibliography?

Is there any interest in publishing an NFS bibliography similar to the one
frequently published in comp.windows.x?  If so, (or even not) please send
me the title(s) of your favorite NFS reference and I'll post a summary.
If there exists an NFS bibliography, then post it or send me a copy.

Thanks

--
= exudnw@exu.ericsson.se                                  (214)907-7928 =
= David Williams                                                        =
= Ericsson Network Systems                                              =
= Richardson, TX 75081                        These opinions are my own.=


-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 20:19:18 GMT
To:        comp.protocols.tcp-ip
Subject:   Support of Multiple Logical Subnetwork by Routers

> C.H. Cheng, The Chinese Univ. of Hong Kong writes:
>Is anyone out there using 3Com Brouter (BR/2000)? I think we have the latest
>version (V3.0.2.3).  Unfortunately, although the manual mentions that it
>supports Multiple Logical Network (Subnetwork?!) for IP, we are not able to
>implement subnet routing through a single port when we set up two addresses
>(with different subnet no. of course) to this port.  It seems that the
>secondary address is of no use with this brouter.

3Com Corp.


-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 20:42:38 GMT
From:      APRIL@NIC.DDN.MIL (April Marine)
To:        comp.protocols.tcp-ip
Subject:   Transition of NIC services

FYI--for widest distribution.

This transition of NIC services also applies to the assignment of
IP network addresses, top-level domains, and second-level domains
under COM, EDU, MIL, NET, ORG, and GOV.

**********************************************************************
DDN MGT Bulletin 84              DCA DDN Defense Communications System
(NIC@NIC.DDN.MIL)  (800) 235-3155

DEFENSE  DATA  NETWORK

MANAGEMENT  BULLETIN

The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network
Information Center under DCA contract as a means of communicating
official policy, procedures and other information of concern to
management personnel at DDN facilities.  Back issues may be read
through the TACNEWS server ("@n" command at the TAC) or may be
obtained by FTP (or Kermit) from the NIC.DDN.MIL host [192.67.67.20]
for bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the
bulletin number).
**********************************************************************

TRANSITION OF NIC SERVICES

The transition of the Network Information Center from SRI
International in Menlo Park, CA, to Government Systems Inc. in
Chantilly, VA, is officially scheduled for 1 October 1991.  This
includes the transition of services currently offered to DDN and
Internet users by SRI, such as network/user registration, on-line
information services, and Help Desk operations.  SRI will continue to
provide all NIC services, to include responding to all user calls and
requests, until 30 September 1991.

DISA and GSI will make every effort to ensure a smooth and timely
transition of NIC services from SRI.  Network users should be
minimally impacted.  With a few minor exceptions, all on-line services
currently offered by SRI will appear the same to the user when a
connection is established to the new (GSI) NIC host.  These exceptions
are due to the change from the TOPS20 operating system to the SunOS
operating system.  The new NIC host is a Sun 470 SPARCserver running
SunOS 4.1.  All users on the DDN and the Internet should carefully
note the following changes:

U.S. Postal Address:      Government Systems, Inc.
Attn: Network Information Center
Suite 200
Chantilly, VA  22021

Help Desk Telephone Numbers:

1-800-365-3642 (1-800-365-DNIC)
1-703-802-4535

Help Desk Hours of Operation:

7:00 am to 7:00 pm Eastern Standard Time

Fax Number:               1-703-802-8376

Root Domain Server:       192.112.36.4 (NS.NIC.DDN.MIL)

During the period of 26 to 30 September 1991 the ID (WHOIS) database
will not be changed.  All registration actions for this five day
period will be suspended.  This action is necessary in order to
transfer the master database to GSI.  Starting 26 September 1991, all
U.S. mail and fax requests should be addressed to the GSI address and
fax number shown above.  All electronic mail requests should continue
to be directed to the "HOSTMASTER" and "REGISTRAR" mailboxes at
NIC.DDN.MIL.  As appropriate, SRI will redirect electronic mail to
GSI.  On 1 October 1991 all registration activities will resume to
include the normal generation of DDN TAC access cards.
Currently-valid TAC access cards will remain valid until the normal
expiration date.

IMPORTANT!  Hosts not using the domain naming system should edit their
host tables prior to 1 October 1991 to reflect the change in GSI's
domain name DIIS.DDN.MIL (192.112.36.5) to NIC.DDN.MIL and delete the
current NIC.DDN.MIL (192.67.67.20) from their tables.  The GSI IP
address, 192.112.36.5, will not change and may be used in lieu of the
domain name.  GSI will re-generate all informational and network
tables (i.e., host tables) no later than 8 October 1991.  All tables
will be available using the same access method currently used to

We hope that the transition and its accompanying changes will not
greatly inconvenience network users, and we thank you in advance for
your patience and understanding.  For general questions regarding the
transition, users may call the new NIC Help Desk after September 1,
1991 at 1-800-365-3642.  Questions regarding NIC operations policy
should be referred to Mr. Wil Pitre of DISA/DODS at (703) 692-2771
(DSN) 222-2771.  Questions regarding NIC contractual matters should be
referred to Mr. Tyrone Smallwood of DISA/DISCA.
-------


-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 22:05:13 GMT
From:      flamer@endeavor.intel.com (Jim Trethewey)
To:        comp.protocols.tcp-ip
Subject:   Trouble w/ Clarkson SLIP packet driver + PC/TCP

Is anyone else using the PC/TCP generic SLIP kernel with the
Clarkson SLIP8250 packet driver with success?  I am not.

What I have:
PC/TCP (PC-210) Version 2.05 from FTP Software, Inc.,
The Clarkson packet driver SLIP8250.COM (included on Unsupported Disk A:),
HCL (Hummingbird Communications Ltd.) eXceed/W (X server for MS-Win3.0),
Microsoft Windows 3.00,
MS-DOS 3.3,
and a 386 pc.

My ultimate goal is to run the PC as an X terminal over SLIP to the UNIX
client, and so far it works up to a point (the point at which the PC locks
up).
I am trying to SLIP on COM2: (IRQ3, IO_base 0x2f8, 9600 baud, 8-1-NONE) to
a UNIX PC (Intel 386 UNIX V.3.2 R2.2 + Lachman TCP/IP + X11R3).
On the PC, I do:

slip8250 -w 0x60 -h 6 3 0x2f8 9600
slpdrv -t 32 -p 16

It works as long as I don't stress it.  Under stress (ftp a >=30K file), it
hangs.  Reducing the baud rate makes no difference (other than it's slower).
Increasing the PC's buffers, e.g., with:

slip8250 -w 0x60 -h 6 3 0x2f8 9600 20480 20480

only makes it take longer to hang.
I do have h/w (RTS/CTS) flow control on both ends.  The Clarkson SLIP8250.ASM
code that was provided appears only to WATCH CTS, I guess so it won't overdrive
the other guy (UNIX), but it never seems to drop RTS if its own buffers get
too full, so UNIX never throttles itself.

Is there a newer version of the Clarkson driver that implements RTS/CTS flow
control BOTH directions?  Or is there something else magical I was supposed
to do?

When the lock-up occurs, I get a message (from MS-Windows, I assume) like:

I/O card parity interrupt at 24E3:04DC.
Type (S)hut off NMI, (R)eboot, other keys to continue

I can also get it to fail in "plain" DOS doing an FTP, without MS-Windows
or the X server in the picture.

Anyone with experience to share?  I'd be most grateful.

--Jim Trethewey, $WORK = flamer@mithril.intel.com,$HOME = flamer@alfirin
5200 NE Elam Young Parkway HF3-73, Hillsboro OR 97124-6497 (503)696-5444


-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 22:19:47 GMT
From:      woodcock@mentor.cc.purdue.edu (Bruce Sterling Woodcock)
Subject:   Re: Backups using rsh.

In article <1991Sep9.065337.6596@cs.sfu.ca> skl@cs.sfu.ca (Samuel Lam) writes:
>rsh(1) uses TCP, so it's as reliable as TCP is (whatever that
>means these days :-)).

It means it's more reliable than NFS, and an order of magnitude faster, at
least.  :)

Why don't all distributed filesystems simply use TCP/IP for data communication?

Bruce

--
------------------------ woodcock@mentor.cc.purdue.edu ------------------------
Yes.  We fuck.  Often, and with great enjoyment of the act.  We aren't married,
we use birth control, we use interesting little toys on occasion.  We moan like
beasts in heat.  Life is *great*.  -- Bryant, ref. to Erin, on alt.brother-jed.


-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 22:51:56 GMT
From:      art@opal.acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Ethernet Throughput

>That's impossible to achieve, it ignores inband formatting information
>(headers, CRC, pauses between packets) and other practical constraints.
>
>The theoretical maximum is a bit less than 1MB/s, and even that cannot
>in practice be achieved because the Ethernet is a simplex channel, and
>most protocols require ACKs every now and then, and thus in practice you
>cannot just pump data continuously from source to target with maximal
>size packets.
>
>The very best Ethernet sw can drive it at 0.8MB/s, sustained, with
>occasional bursts at 0.9MB/s.
>--
>Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
>Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
>Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
>

The overhead of Ethernet is effectively 38 bytes (8 bytes preamble, 14
bytes MAC header, 4 bytes FCS and 12 bytes interpacket time).

Then absolute theoretical maximum throughput follows.

For minimum sized packets (46 bytes of information) this gives:

5.476Mb/s or 0.685 MB/s

for maximum sized packets (1500 bytes):

9.752Mb/s or 1.219MB/s

Allowing 40 bytes for TCP/IP overhead for maximum sized gives:

9.492Mb/s or 1.186MB/s

Art


-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 23:00:24 GMT
From:      bmiller@CABELL.VCU.EDU (Bryan E. Miller)
To:        comp.protocols.tcp-ip
Subject:   (none)

Fellow netters:

I am writing asking for any information/opinions on TFTP....
I've heard lots of rumors and stories about the possible security
risks to be considered before enabling this option.  I'd like to
hear any good/bad stories, as well as any implementation concerns
that anyone has...

Bryan Miller
Network Manager
Virginia Commonwealth University
bmiller@cabell.vcu.edu


-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 01:44:43 GMT
From:      warb@faatcrl (Dan Warburton)
To:        comp.protocols.tcp-ip
Subject:   Re: Support of Multiple Logical Subnetwork by Routers

A563700@CUCSC.BITNET ("C.H. Cheng, The Chinese Univ. of Hong Kong") writes:

>Hi all,

>  Is there anyone running Multiple Logical (Sub)network successfully with
>other brand of bridging router?

>C.H. Cheng
>Computer Services Center
>The Chinese Univ of Hong Kong

We are using cisco AGS router with 6 ethernets and Multiple Logical Subnets
We have partitioned our Class C address with a four bit subnet. We avoid
subnet 0 and subnet F, Giving 14 subnets with 14 hosts (we aviod host 0 and hostF) . We assign multiple subnets to the same ethernet address when the number of
hosts exceeds fourteen or for logical (to us) reasons. Works Well. As does the
router.

--
+  Dan Warburton   Nas Simulation Support Facility (NSSF)
+                  Federal Aviation Administration Technical Center
+                  Atlantic City International Airport, NJ 08405    //
+  609-484-4480    Mail Stop: ACN-313        Aikido        Amiga  \X/ Sun
+  warb@faatcrl.uucp  ...rutgers!faatcrl!warb   -- An Open Systems Group --


-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 02:02:38 GMT
From:      lindner@cs.umn.edu (Paul Lindner)
To:        comp.unix.misc,comp.protocols.tcp-ip
Subject:   Internet Gopher v0.2 Curses Client and Server is available


The Internet Gopher
A Distributed Information Service

Unix-Server, Curses-Client Release 0.2, 9 Sep. 1991

University of Minnesota
Computer and Information Services

The Internet Gopher is a distributed docuemnt delivery service.   It
allows a neophyte user to access various types of data residing on
multiple hosts in a seamless fashion.  This is accomplished by
presenting the user a hierarchical arrangement of documents and by
using a client-server communications model.  The Internet Gopher
Curses Client allows a user on a terminal to access the vast array of
information available on various gopher servers.  The Internet Gopher
Server accepts simple queries, and responds by sending the client a
document.

Also included in the release are experimental clients and servers for
real-time radio, utilities for using gopher in shell scripts (written
in perl), and some sound utilities for NeXT machines.

Other Internet Gopher Software available includes:

Macintosh Gopher client written in HyperCard.
Macintosh Gopher Server software.
PC Gopher Client with a Borland Turbo Vision Interface.
Full Text Indexing servers for NeXT machines.
NeXT Gopher client (provided by Max Tardiveau of the University of St.
Thomas.)

All of this software is available for anonymous ftp to
boombox.micro.umn.edu (128.101.95.95) in the /pub/gopher directory.

The Internet Gopher Development Team can be reached via e-mail as
gopher@boombox.micro.umn.edu.  If you prefer paper we can be reached
at:

Internet Gopher Team
132 Shepherd Labs
100 Union Street SE
Minneapolis, MN 55455
--
| Paul Lindner | lindner@boombox.micro.umn.edu   |"You have to spit
|              | Computer & Information Services | to see the shine..."
|             	| University of Minnesota         | -- Babes in Toyland
///// / / /    /////// / / / /  /  /  /   /      //// / / / /  /  /  /   /


-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 04:49:44 GMT
From:      wcs@cbnewsh.cb.att.com (Bill Stewart 908-949-0705 erebus.att.com!wcs)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

In article <PCG.91Sep9183332@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
] The theoretical maximum is a bit less than 1MB/s, and even that cannot
] in practice be achieved because the Ethernet is a simplex channel, and
] most protocols require ACKs every now and then, and thus in practice you
Actually, if you're Van Jacobson, and have really high-tech equipment
(a pair of Sun 3/60s!) it's possible to achieve 8 Mbits/sec for
large-block file transfers by careful tuning.  The 3/60 had AMD LANCE
Ethernet chips - the 3/280 used Intel chips, and he could only get

My first reaction to the request, however, was "Wow!  What is this
guy trying to accomplish?  Are PCs and Ethernets the right approach?
If he's got money to burn, why isn't he using FDDI?  Is this broadcast
data, or really point-to-point, or does he have one blazing-fast data
source that he's trying to store?  Is this data being stored to disk,
or just displayed on screens?  If it's being stored, how much is there?
Maybe you want one big machine with 100 MB RAM to store it and shove

Especially if the real application is broadcast, there's been a lot
of work on broadcast protocols.  Alternatively, as some people have
suggested, there are other networks such as SCSI that are cheap,
fast, and efficient.  How many machines are you trying to connect?

(NASA has some large data-shuffler that's basically a big multi-ported
memory box with a bunch of DMA connections to a bunch of buffers,
which they've used for some high-speed data applications;
I don't remember any details, since it's been about 3 years since I
read about the beast, but it was very hard to emulate with
non-custom approaches.)

Oh - cisco routers DO have a lot of bandwidth, at least in the large models -
I think it's the AGS-PLUS (we paint a Death Star on the front and
sell it as the AT&T StarWAN 450).  The C-Bus backplane has a 533
Mbits/sec bandwidth, and the high-speed multiport Ethernet cards can
do essentially full bandwidth for (all? 4-6?) each port.
Most routers have traditionally been limited by their
packet-processing rate, but the newer products from cisco, Proteon,
and a few other people have fast enough processors to get beyond that.
The 450's packet-processing rate was something around 50-60kpps for
short packets, and being increased as they tuned the software,
but for this job you'd presumably use large packets so the problem
is bus bandwidth and memory buffers anyway - should be ok.

Good luck!
--
Pray for peace;      Bill
# Bill Stewart 908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M-312 Holmdel NJ
# "After all, the 'good of society' is based upon the 'rights of the individual.'
# Not the other way around, IMHO." -- Chris Preston


-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 06:30:49 GMT
From:      torek@elf.ee.lbl.gov (Chris Torek)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

>torek> Actually, Ethernet is 1.25 MB/s (10 over 8 = 1.25, not 0.8).

In article <PCG.91Sep9183332@aberdb.aber.ac.uk> pcg@aber.ac.uk
(Piercarlo Grandi) writes:
>That's impossible to achieve, it ignores inband formatting information
>(headers, CRC, pauses between packets) and other practical constraints.

This is true...

>The theoretical maximum is a bit less than 1MB/s, and even that cannot
>in practice be achieved because the Ethernet is a simplex channel ...

but this is not, quite.  (See below.)

>The very best Ethernet sw can drive it at 0.8MB/s, sustained, with
>occasional bursts at 0.9MB/s.

I beg to differ.  Here is a rerun of old tcp-ip mail.  I have quoted it
in its entirety because Van tends to get quoted out of context.  If you
reproduce this, you must either include the whole thing or get permission

To: tcp-ip@nic.ddn.mil
Subject: saturating an ethernet from 1000 miles away
Date: Wed, 05 Jun 91 07:47:44 PDT
From: Van Jacobson <van@ee.lbl.gov>

A minor milestone in high-speed, long-haul networking happened
at the recent Educom National Net '91 conference in Washington,
DC:  TCP transfers from a Cray YMP at Pittsburgh Supercomputer
Center to a Sun Sparcstation-2 on the show floor ran at a
sustained rate of 10Mb/s (by sustained' I mean sustained over
hundreds of megabytes of data transferred -- In one of the first
tests, we shipped 256MB from the PSC to DC in 3.9 minutes).  The
rough topology was:

FDDI            T3 backbone        Ethernet
100Mb/s            45Mb/s            10Mb/s
PSC YMP -------> PSC ENSS --....--> DC ENSS ---------> SS-2

The limiting bandwidth was the show ethernet & we ran at that
bandwidth.  If we could have gotten in & out of the ENSS at >=
45Mb/s, we would have run at the 45Mb/s NSFNet backbone
bandwidth.  (Dave Borman's Cray TCP has been measured at over
300Mb/s.  My TCP on the SS-2 runs 48Mb/s through the loopback
interface (i.e., copying all the data twice, doing both sides of
the protocol & context switching on every packet) and should
easily sink or source >100Mb/s as soon as Sun comes up with a
decent high-speed network interface.)

The real milestone is that two completely independent
implementations of the RFC1072/RFC1185 "fat pipe" extensions,
one by Dave Borman of Cray Research for Unicos on the YMP & one
by me for an experimental TCP/IP running on the SS-2,
interoperated with no problems.  [This gave me no small measure
of joy:  Sun demonstrated their normal inability to supply system
source to academic sites & I didn't get a copy of 4.1.1 (the
only version of Sun OS that would run on a SS-2) until Friday of
the week before the show.  I spent a very long weekend
throwing out Sun's network & IPC code & replacing it with my
experimental 4.4BSD stuff and got a working kernel 45 minutes
before the movers came to crate up our lone Sparcstation-2 &
ship it from California to DC.  So the very first chance to
test my RFC1072 implementation against Dave Borman's was when we
got the machine uncrated & connected the SS-2 to the show net in
DC.  I was all resigned to another 36 hours of sleepless
debugging when, to my utter astonishment, the Cray &
Sparcstation flawlessly negotiated a 512KB window & timestamps,
then happily started exchanging data at a very high rate.
(Several other groups were busy setting up their demos.  I
started up my usual throughput test programs on the Cray & Sun
then looked down at the recv' indicator light on the Cabletron
transceiver & noticed it was on solid -- I stared at it for at
least 30 seconds & it didn't even blink.  Right after that I
heard one of the Cornell people say What happened to the
network?  Our connection seems to have stopped.'' and I did my
best to look innocent while the test finished.)]

The big disappointment was that I was worried about what would
happen when the TCP congestion avoidance / recovery algorithms
started interacting with half a megabyte of stored energy
(in-transit data) in the pipe.  So I'd spend a bunch of time
tuning the Fast Retransmit and Fast Recovery algorithms & had a
bunch of instrumentation set up to watch how they'd perform.
But the damn T3 NSFNet refused to drop packets -- we shipped
slightly more than 30GB (roughly 22 million data packets) during
the three days of the show & the kernel network stats said that
6 were dropped.  Naturally, I wasn't watching for any of
these 6 & a 0.00003% loss rate wasn't enough test any of the
spiffy new algorithms.  Oh well, maybe next time I'll bring my
wire cutters and chop halfway through the cable to make things a
bit more interesting.

[The one interesting piece of behavior had to do with the
ethernet controller on the Sun:  The LANCE is a half-duplex
device so if it's receiving back-to-back ethernet packets it will
never attempt to transmit, even if it has data available to
send.  TCP will attempt to ack every other packet but, since new
data packets were arriving back-to-back from the ENSS, the ack
packets just got queued in the LANCE on the SS-2.  Since the
acks can't get out, eventually (after half a megabyte is sent)
the window on the Cray should close, it should stop sending
packets & the SS-2 should get to dump 180 back-to-back ack
packets, re-opening the window & restarting the data flow.  This
would have resulted in essentially the stop-and-wait performance
of a BLAST protocol but, fortunately, there seems to be a 128KB
buffer somewhere in the T3 NSFNet so after 90 data packets there
was a 30us pause, allowing the SS-2 LANCE to grab the ethernet,
dump 45 back-to-back acks, then start collecting the next 90
data packets.  So the window on the Cray never shut & the pipe
stayed full -- due to essentially an engineering mistake in the
network (a transcontinental T3 run at T3 needs at least half a
meg of buffer everywhere a queue can form).  This, incidentally,
is one reason why we used a half megabyte window instead of the
80KB window required to fill a 36ms RTT into 10Mb bandwidth-delay
product.]

Anyway, I'm writing this mostly to document that it happened &
to thank all the people at LBL, PSC, Merit, Cray & Sun that made
it happen.  I'm particularly grateful to Dave Borman for some
great Cray TCP software and to Geoff Baehr at Sun for battling
with the lawyers and getting us the system pieces we needed
(it's nice to know that at least part of Sun still ranks
engineering over bean counting).  And I am eternally grateful to
Wendy Huntoon of PSC & Elise Gerich of Merit who put in long,
long hours to get the new and almost untested PSC & NSF T3
connections up & running, then kept everything running smoothly
and essentially trouble free for the entire show.

- Van Jacobson
--
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov


-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 07:38:58 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

In <17380@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes:

>>torek> Actually, Ethernet is 1.25 MB/s (10 over 8 = 1.25, not 0.8).

>In article <PCG.91Sep9183332@aberdb.aber.ac.uk> pcg@aber.ac.uk
>(Piercarlo Grandi) writes:
>>That's impossible to achieve, it ignores inband formatting information
>>(headers, CRC, pauses between packets) and other practical constraints.

Just following up Chris' reposting of Van's note.  If Van's note fails
to convince, one should read the paper by Boggs, Mogul and Kent in the
Proceedings of SIGCOMM '88.  They walk through the various models of
Ethernet and show that simplifying assumptions in some models cause
the models to understate the maximum bandwidth.  Also, they did some
real tests of bandwidth with various configurations of senders and
receivers that show the throughput rates.  My recollection is that
they showed a maximum practical rate (after headers et. al.) of a little
over 1 MByte/s.

Craig Partridge

PS: Yes, Boggs is Dave Boggs, of Metcalfe and Boggs, the Ethernet designers.


-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 09:08:27 GMT
From:      tjc@ecs.soton.ac.uk (Tim Chown)
To:        comp.protocols.tcp-ip
Subject:   Re: Western Digital's cards

In <4089@mtecv2.mty.itesm.mx> cgonzale@mtecv2.mty.itesm.mx writes:

>Does anybody know the difference between Western Digital's Ethercard Elite 16 Combo and WD8013EW cards ?

>We need an Ethernet card with 10BaseT & BNC media support in the same board but we are not shure about the correct model that we have to order.

Are they not one and the same thing?   The Combo cards we ordered all
had WD8013EW on a sticker on the back.  We're very happy with their
performance and compatibility with the free NCSA software.

Tim
--


-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 11:04:57 GMT
From:      and@kaija.spb.su (Victor A. Andreenko)
To:        comp.protocols.tcp-ip
Subject:   Locus TCP/IP for DOS and NE1000

Hi netters,

We have  Locus TCP-IP package for DOS, V1.0. Unfortunately
driver for Ethernet card Novell NE1000 is absent in
this distribution.  All drivers in this package have
named _*.drv_ and they are installed from _config.sys_
at boot time.

We have some questions:
1) what type of driver used by this package ?
Is some description of LOCUS TCP/IP drivers type ?
2) Can we use PDS, NDIS or other drivers NE1000 by
some other ways ?
3) May we get LOCUS driver for NE1000 from anywhere ?

Any information appreciable.

-----------------------------------------------------------------------------
Victor A. Andreenko    e-mail internet: and@kaija.spb.su
Leningrad(St. Petersburg)        phone: office: +7 (812) 2941103,2983700
USSR                              home: +7 (812) 2954347


-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 14:04:53 GMT
From:      martillo@cpoint.clearpoint.com (Joachim Carlo Santos Martillo)
To:        comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

In article <14455@cpoint.clearpoint.com> martillo@cpoint.clearpoint.com (Joachim Carlo Santos Martillo) writes:

>1) You have to turn on UDP checksumming if you connect two ethernets
>by a bridge rather than a router.

This should say:

You don't have to turn on UDP checksumming if you connect two ethernets
by a bridge rather than a router.

Joachim Carlo Santos Martillo Ajami


-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 14:33:01 GMT
From:      gordon@FTP.COM (Gordon Lee)
To:        comp.protocols.tcp-ip
Subject:   SLIP and PPP compared

> From: ...!visual!ssanbeg@ucbvax.Berkeley.EDU  (Scott Sanbeg)
>
> Basically, I don't know if PPP is more efficient than SLIP,

Here's something I have been wanting to post for a while and finally
found an excuse.  This really is a FAQ waiting to happen.

Efficient in which respect ?  effective throughput ? administration ?

In terms of data throughput, efficiency of a serial link is determined
more by the underlying hardware than the framing protocol.  A pair
of 9600 baud modems can only pass so many bytes.  Framing protocol
overhead is a fairly minor factor (IMO).  SLIP has a (defacto) MTU
of 1006 and two bytes of framing per frame.  Async PPP has a (defacto) MTU
of 1500 with 5-8 bytes of framing per frame.  Depending on how it
is configured on site, PPP's special character escaping scheme may

If you discount the byte stuffing, the two protocols are not far apart
in terms of maximal effective throughput (MTU size packets).  PPP will
deliver *marginally* less throughput due to its slightly higher number
of framing bytes (any extra byte stuffing a particular link is configured
to perform will reduce PPP's effective throughput further).

As packet size decreases, effective throughput would tilt in favor of SLIP
because the framing bytes become a larger proportion of the overall frame
size.  For highly interactive traffic (telnet) where packets are no larger
than say, 64 bytes, this becomes more pronounced, but even then, a best
case configuration put a PPP frame at only 3 bytes larger than an equivalent
SLIP frame.  (best case means: PPP header compression options on, Async Ctrl
Char Map is all zeroes).

Why PPP ?  more features:
- Two of the framing bytes present in PPP but absent in SLIP are a type
field used to demultiplex different network layer protocols.  This
is a key feature for routers because SLIP links only pass IP
traffic, no IPX, no DECNet, no ISO, etc.
- Two other bytes are a frame check sequence which allows the frame
integrity to be checked at the data link layer.
- PPP can be configured to escape certain ctrl characters (0x00-0x1f)
which your data comm hardware may be sensitive to.
- PPP provides an authentication capability (currently unencrypted,
but encryption is being worked on in IETF).
- PPP's IP configuration allows for IP addresses to be negotiated
automatically.

Judge for yourself whether these features are necessary and worth
is highly dependent on the context.  Your mileage will vary.

There are many other considerations:
- There are more SLIP implementations in the field (plus more mature)
- The performance differences described are fairly thin (IMO)
- Not all PPP implementations offer all of the features I describe above
- Not all PPP implementations are async, many are sync (faster because
invariably much of the framing is processed by hardware)

my $0.02 (don't spend it all in one place), - GL }} Gordon Lee FTP Software Inc }} voice: (617) 246-0900 26 Princess St }} fax: (617) 245-7943 Wakefield, MA 01880  -----------[000105][next][prev][last][first]---------------------------------------------------- Date: 10 Sep 91 14:52:48 GMT From: utterbac@husc9.harvard.edu (Margot Utterback) To: comp.protocols.tcp-ip Subject: Need the LPD protocol  Murphy strikes again! Just because the last time someone posted the location of a document describing the lpd protocol I decided not to get it, now I desperately need it. Such is life! (heavy sigh) Anyway, can some kind soul point me to such a document? Thanks very much in advance. Please e-mail because I need it ASAP. utterbac@husc.harvard.edu  -----------[000106][next][prev][last][first]---------------------------------------------------- Date: 10 Sep 91 15:49:12 GMT From: bg18215@hawaii.sbi.com (Beth Gilbrech) To: comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: TCP/IP Accounting Software  Am interested in any tcp/ip accounting utilities that might be available: commercial, public domain or otherwise. We need to keep track of #/packets sent to particular ip addresses and other obscure details over here. Any and all info would be appreciated. -- Beth Gilbrech net: bg18215@hawaii.sbi.com Salomon Technology Services phone: 1-201/896-7340 Systems Engineering - Network Software fax: 1-201/460-0674 **An employee and not a spokesperson for Salomon Brothers, Inc.**  -----------[000107][next][prev][last][first]---------------------------------------------------- Date: 10 Sep 91 17:48:58 GMT From: aninda@bach.ecse.rpi.edu (Aninda Dasgupta) To: comp.protocols.tcp-ip Subject: Re: TCP/IP on OS/2  IBM has an excellent TCP/IP offering, including source code and many example programs. There are a number of other vendors offering this package .  -----------[000108][next][prev][last][first]---------------------------------------------------- Date: 10 Sep 91 17:59:11 GMT From: raj@hpindwa.cup.hp.com (Rick Jones) To: comp.protocols.tcp-ip Subject: Re: Need help selecting Ethernet cards for very high throughput rates.  I just love a good opening... ;-) torek> Actually, Ethernet is 1.25 MB/s (10 over 8 = 1.25, not 0.8). Piercarlo>That's impossible to achieve, it ignores inband formatting Piercarlo>... Piercarlo>practical constraints. Piercarlo>... Piercarlo>The theoretical maximum is a bit less than 1MB/s, and even Piercarlo>... Piercarlo>packets. Well, I decided to do some back-o-lope calculations a little while back, and came-up with something on the order of 1128-1130 KB/s for TCP over Ethernet. This was based on min gaps and pre-ambles and such. BTW, that is user-level thruput... Piercarlo>The very best Ethernet sw can drive it at 0.8MB/s, sustained, with Piercarlo>occasional bursts at 0.9MB/s. Well, then folks like HP and Sun (I have to be egalitarian ;-) must have the very very best Ethernet sw ;-) as I have seen HP 700's do 1100KB/s sustained and SS2's do 1063KB/s sustained. And that's released product... rick jones ___ _ ___ |__) /_\ | Richard Anders Jones | HP-UX Networking Performance | \_/ \_/ Hewlett-Packard Co. | "It's so fast, that _______" ;-) ------------------------------------------------------------------------ Being an employee of a Standards Company, all Standard Disclaimers Apply  -----------[000109][next][prev][last][first]---------------------------------------------------- Date: 10 Sep 91 18:13:39 GMT From: jal@acc.flint.umich.edu (John Lauro) To: list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards Subject: Re: Need help selecting Ethernet cards for very high throughput rates.  In article <PCG.91Sep9185229@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes: >cpcahil> Throughput is not the only evaluation factor for a disk >cpcahil> controller. Another factor, which is where a good EISA >cpcahil> controller will shine, is the amount of time the bus is tied up >cpcahil> transferring that 4MB/s. > >Latency then perhaps matters. But in practice not a lot... > >cpcahil> You yourself said that the theoretical max for the ISA bus was >cpcahil> between 5 and 6 MB/s. 4MB/s is appox 80% of the theoretical >cpcahil> max. > >Of course, but this is nearly irrelevant. Almost nobody keeps their SCSI >bus running at its top rated bandwidth continuously (not even Adaptec, >which stay off the bus for some programmable fraction of the time). > >In particular disk access tends, in normal operation, to be bursty (the >effect of caching and paging, and then of intervening seeks). > That's because the CPU is too busy waiting for the controllers (disk and ethernet) to accept the data so it can work on getting something else ready to send. Even if no single piece is any faster, it frees the processor that much quicker. Granted, under dos you will not notice any significat difference. A Novell 386 server, or Unix, etc... will take advantage of it. I don't think anyone listed all the specs for Cisco routers. Here are some more for the AGS+. They demonstrated protype software in October 1990 that could forward more than 74,000 pps total in multiple streams. The reason for these speeds, is it's possible to put over 24 ethernet ports on these boxes, or FDDI. There is a 16 MIPS Bit Slice processor per interface card, the main CPU is a 30 Mhz 60020, and the C-BUS controller also has a 16 MIPS processor. Back to the original topic... If a dedicated 10Mbs per computer is wanted, he would save much money with high speed bridges. There are some that can take upto 7 ports and handle full ethernet speed on all ports. By using multiple bridges you could have any number of available ports. These devices cost considerably less than an equally equiped router. Routers are best to keep the broadcasts down, but if you have only a small number of machines per segment, than that isn't needed. Also if he was considering anything less than an AGS+ (even an AGS) then it would probabbly be better not to use any router at all if the number of machines is sufficiently small. (Was the number ever stated?)  -----------[000110][next][prev][last][first]---------------------------------------------------- Date: 10 Sep 91 19:12:46 GMT From: deb.kocsis@UM.CC.UMICH.EDU To: comp.protocols.tcp-ip Subject: Merit/NSFNET Seminar Announcement  Dear Moderator: Please forward this seminar announcement to the mailing list you moderate if appropriate and of interest to your readers. If you no longer moderate this list, please reply with the new moderator if you have contact information for that person. Thank you. Merit/NSFNET Information Services ------------------------------------------------------------ Please pass on the announcement below to interested parties where appropriate. Hard-copy brochures are available for your colleagues not-yet attached by sending us their postal address or calling 1-800-66-MERIT or (313) 936-3000. Thank you. ----------------------------------------------------------- The Merit Networking Seminars: Making Your NSFNET Connection Count ------------------------------------------------------------ Merit/NSFNET Information Services is committed to providing current information on national networking to all users of the NSFNET and the Internet. Toward this end we will sponsor a one-and- a-half day seminar in College Park, Maryland on November 11-12, hosted by SURANet. "Making Your NSFNET Connection Count" will be an informative seminar focusing on Internet tools, resources, and applications. Campus computing leaders, information systems and networking administrators, educational liaisons, librarians, and educators who want to learn more about national networking are encouraged to attend. Day 1, Real People Doing Real Things With Networking, will feature a number of presentations concerning network applications in education from the elementary grades through the college level. The Day 1 activities will begin with a keynote address by Stephen Wolff, Director of the Division of Networking, Communications, and Research Infrastructure of the National Science Foundation. Day 2, Network Tools and Futures, will provide attendees with information on the tools and resources available on the Internet. Day 2 will also include information on directory services for people and applications on the Internet, as well as parallel sessions for special interests in internetworking, gigabit technology, and K-12 networking. The seminar will conclude with a presentation on the National Research and Education Network (NREN) and its pending legislation by Mike Nelson, Professional Staff Member, United States Senate Committee on Commerce, Science, and Transportation. The seminar will be held at the University College of the University of Maryland. Microcomputers connected through SURAnet to NSFNET and the Internet will be available on-site so that attendees may access network resources discussed in the presentations. The registration fee is$295 until November 1. Registrations received
after that date should include $345. This fee includes the seminar, receptions on Sunday and Monday evenings, lunch on Monday and Tuesday, the demonstration room, and all seminar materials. For further information and a complete agenda send an electronic message to seminar@merit.edu or telephone 1-800-66-MERIT, or (313) 936-3000.  -----------[000111][next][prev][last][first]---------------------------------------------------- Date: 10 Sep 91 20:12:00 GMT From: JOHNGALT@CCIT.ARIZONA.EDU (John Galt) To: comp.protocols.tcp-ip Subject: Need help choosing PCROUTE/KA9Q/SLIP/PPP/V.32bis/V.42bis...  Hello, I am trying to connect two physically separate ethernet segments together. One segment is located in a project office which is located about eight miles as the phone flies from the district office which has the other segment. Originally, before I started work in this office, a bridge and DSU/CSU combination was purchased. We recently received the equipment, two NAT bridges and two Astrocom DSU/CSU combinations. I called our local phone company, US West, and requested that the line be put in. WELL, they told me that the price had gone up on July 15. Originally, the line was to cost ~$740.00 to install and then $180.00 per month (this is for a 56K line). As of the price increase, however, the installation cost is$1000.00 and the
monthly charge is $720.00!!!!!!! Flame on. This is a 400% increase! I thought deregulation was supposed to stop this kind of thing! I may have to blame it on our local "Arizona Corporation Commission" which seems to be a rubber stamp regulatory organization. Flame off. We can't afford the monthly charge on this line, so I decided to connect us in a different way. KUDOS: The people at NAT were very helpful. They gave us a couple alternative ideas and, when that didn't work for us, they allowed us to return the bridges. If I ever get a chance to do business with NAT again, I will gladly give them first shot at anything. If you ever need ethernet bridges or monitoring tools, look into them. I dealt with Jim Huang at (800) 543-8887. On the other hand, I am still waiting for a call back from Astrocomm, and I have left messages... Back to the problem: After reading as much material as I can get my hands on, I think the best solution for us is to use a PPP or SLIP line with V.32bis and V.42bis modems. I want to connect one of these modems to each ethernet segment, either directly on the back of one of our UNIX boxes (we have Data General AViiON 300's), or to a dedicated PC running PCRoute or KA9Q. To tell the truth, I don't care for the DG's, so I would rather stick with the PC's. Any opinions on this idea? Now the questions: Has anyone used either PCRoute or KA9Q for this purpose? I think PCRoute only supports SLIP, where KA9Q supports PPP. Theoretically this would be an advantage, but is there a practical difference? I only need to talk TCP/IP, so I won't need the multiple protocol capabilities of PPP. If there is no real advantage to PPP over SLIP, then should I stick with PCRoute? What about hardware? That is, what ethernet board should I use? PCRoute only seems to support certain boards. What about the speed of a packet driver interface? I have read that it is much slower than direct access. Is this going to be a practical limitation? Should I stick with an 8088 or get a 80286 based computer? If I was routing two ethernet segments directly, it would seem to be an advantage to get the 286. Since I will be connecting to a serial line, do I need the extra power of the 286? And what type serial port board should I use? I want to be able to use the port at 38.4 or 57.6K. The documentation recommends a board with the 16550 chip. Is this something that just plugs into the 8250 slot? What about something like the Digiboard intelligent port boards? Anybody have experience with the V.32bis/V.42bis modems? The Digicomm seems pretty good, and is cheaper than either the CODEX or AT&T. The Hayes doesn't even seem to meet the V.32 spec (the specs say "ping-pong to simulate V.32"). What about other V.32bis modems? Thanks very much in advance for any information you can send to me. Please reply directly to me and I will summarize if there is interest. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % "Dr. John Galt" Internet : johngalt@ccit.arizona.edu % % U.S. Geological Survey BITNET : johngalt@arizrvax % % P.O. Box 3328 Voice : (602) 623-5444 % % Tucson, AZ 85722 % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%  -----------[000112][next][prev][last][first]---------------------------------------------------- Date: 10 Sep 91 21:25:33 GMT From: lstowell@pyrnova.pyramid.com (Lon Stowell) To: comp.protocols.ppp,comp.protocols.tcp-ip Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)  In article <1991Sep4.171840.29088@telebit.com> brian@telebit.com (Brian Lloyd) writes: > >Ah yes, Yet Another Serial Protocol (YASP). Pretty soon its going to >be like IBM in the 60's and early 70's when they had about 100 >different variations of bisync, all mutually incompatible. > Think of it as job security Brian. And remember what happened to IBM when their "future site" model resulted in SNA with 7 incompatible LU types....all they did was move the incompatibility above the link layer...  -----------[000113][next][prev][last][first]---------------------------------------------------- Date: 10 Sep 91 23:01:35 GMT From: coolidge@speaker.wpd.sgi.com (Don Coolidge) To: comp.protocols.tcp-ip Subject: Re: Ethernet Throughput  In article <1991Sep9.225156.22053@salt.acc.com>, art@opal.acc.com (Art Berggreen) writes: |> >That's impossible to achieve, it ignores inband formatting information |> >(headers, CRC, pauses between packets) and other practical constraints. |> > |> >The theoretical maximum is a bit less than 1MB/s, and even that cannot |> >in practice be achieved because the Ethernet is a simplex channel, and |> >most protocols require ACKs every now and then, and thus in practice you |> >cannot just pump data continuously from source to target with maximal |> >size packets. |> > |> >The very best Ethernet sw can drive it at 0.8MB/s, sustained, with |> >occasional bursts at 0.9MB/s. Ummm...I've been measuring the TCP throughput of several of our (SGI) Ethernet interfaces lately, and all of them come in higher than that. Using ttcp -s, I get from 0.905MB/s (VME expander interface) to 1.079 MB/s . Perhaps you'd consider reviewing your figures? :^) |> The overhead of Ethernet is effectively 38 bytes (8 bytes preamble, 14 |> bytes MAC header, 4 bytes FCS and 12 bytes interpacket time). |> |> Then absolute theoretical maximum throughput follows. |> |> For minimum sized packets (46 bytes of information) this gives: |> |> 5.476Mb/s or 0.685 MB/s |> |> for maximum sized packets (1500 bytes): |> |> 9.752Mb/s or 1.219MB/s |> |> Allowing 40 bytes for TCP/IP overhead for maximum sized gives: |> |> 9.492Mb/s or 1.186MB/s That's a good UDP number. TCP/IP overhead is actually a bit higher - you have to account for ACKs. That would be 3*(38+40) per 3000 bytes (two MTU packets, one ACK), or 0.86505*10Mb/s theoretical TCP throughput. That's 1.081 MB/s. I'd say that at 1.079, SGI is doing pretty well... - Don Coolidge coolidge@sgi.com  -----------[000114][next][prev][last][first]---------------------------------------------------- Date: 11 Sep 91 03:51:18 GMT From: marc@dumbcat.sf.ca.us (Marco S Hyman) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.sysv386,comp.unix.wizards Subject: Re: Need help selecting Ethernet cards for very high throughput rates.  In article <PCG.91Sep9183332@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes: > torek> Actually, Ethernet is 1.25 MB/s (10 over 8 = 1.25, not 0.8). > > That's impossible to achieve, it ignores inband formatting information > (headers, CRC, pauses between packets) and other practical constraints. > > The theoretical maximum is a bit less than 1MB/s, ... You weren't listing earlier. The theoretical maximum is 1.218 Mbytes/sec of payload (user data) using maximum frame sizes and minimum delays. See article <1175@dumbcat.sf.ca.us> if you need to see how the bits up. (This rate is provided at only 812 packets/second. That's plenty of time to handle headers, CRCs, etc. > and even that cannot > in practice be achieved because the Ethernet is a simplex channel, and > most protocols require ACKs every now and then, and thus in practice you > cannot just pump data continuously from source to target with maximal > size packets. True, but we're playing the specsmanship game here, aren't we? // marc -- marc@dumbcat.sf.ca.us -- pacbell!dumbcat!marc  -----------[000115][next][prev][last][first]---------------------------------------------------- Date: 11 Sep 91 13:05:58 GMT From: et@ajk.tele.fi (Eero Torri) To: alt.security,sci.crypt,comp.protocols.tcp-ip Subject: "Open Systems Security" document available  This is a forwarded message from Arto Karila: -------------------------------------------------------------------------- In June I posted a note about my study "Open Systems Security - an Architectural Framework" which I made available through the Internet on our host "ajk.tele.fi". The paper deals with security architectures for open systems and is applicable to both OSI and DoD Internet. The paper aroused lots of interest. Unfortunately the quality of service provided by our host was rather bad last summer because we were changing machines. Also, many people complained that they had difficulties printing the document which was in post script format. A slightly updated version of the document is now available in (hopefully) more standard post script format which should print on printers other than the Apple LaserWriter too. Our host is now running a lot better and the paper is also available on one of best managed ftp servers "nic.funet.fi". I hope this has solved most of the problems. So, the paper is now available with anonymous FTP at two locations: host: ajk.tele.fi, file: PublicDocuments/OpenSystemsSecurity.tar.Z host: nic.funet.fi, file: pub/doc/security/karila/OpenSystemsSecurity.ps.Z The format is compressed post script, page size A4, length over 100 pages. -- Arto Karila + INTERNET: atk@ajk.tele.fi Telecom Finland + TEL : +358 0 704 2000 Business Systems R&D + FAX : +358 0 704 2712 P.O. Box 140 00511 HELSINKI -------------------------------------------------------------------------- -- Eero Torri + INTERNET: et@ajk.tele.fi TELE/Palvelukehitys + TELEBOX : spp482 Elim{enkatu 8 + TEL : +358 0 704 2973 00511 HELSINKI + FAX : +358 0 704 2712  -----------[000116][next][prev][last][first]---------------------------------------------------- Date: 11 Sep 91 16:21:16 GMT From: booloo@lll-crg.llnl.gov (Mark Boolootian) To: comp.protocols.tcp-ip,comp.unix.wizards,comp.arch Subject: Speed of memory and fast networks (was: Need help selecting Enet cards)  In article <1991Sep2.152344.14037@aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes: > >Just to give people an idea of the numbers involved, here is a transcript of >a quick test done on the local DECsystem 5830, which has got a screamingly >fast (20-25MIPS) 25Mhz R3000 CPU: > > Script started on Mon Sep 2 16:04:31 1991 [ code deleted ] >$ time ./copy
>	    8.3 real         7.0 user         0.1 sys
>
>I read 7 seconds for copying 64MB, or almost 10MB/s. This is reading and
>writing, with no processing. Maybe this 25Mhz R3000 CPU can beat a CISCO
>router bandwidth only if one does simply reads from its own cache, so let's
>have a look at just reading:
>
[ code deleted ]
>    $time ./read > 4.8 real 4.1 user 0.0 sys > >That's a tad over 4 seconds for 64MB, or 16MB/s. > There is currently some work going on here attempting to design a gigabit switch based on the (developing) FiberChannel standard. One of my colleagues is involved in this work and we have been having discussions regarding who can make use of gigabit data rates. The argument put forth by my colleague is that memory speed on most computers is so slow that, when using a protocol like TCP which typically (most common implementations) touches memory at least three times (DMA into memory and copy from kernel to user space - I didn't count the checksum), high data rates to the application just aren't possible. For example, we measured the memory speed of a Vax 6310 at around 8 MBytes/sec. If memory is touched three times for a TCP connection, that means a maximum possible data rate of less than 3 MBytes/sec. So even if we have a HiPPI connection on this machine, we aren't going to do any better than 3 MB/sec. Mr. Grandi has measured memory speed of the Vax 5830 at 16 MB/sec. And that means a maximum achievable TCP rate of less than 6 MB/sec. That isn't fast enough to justify hanging a 5830 on a gigabit network. And that's a long way from saturating an FDDI ring. It seems that supercomputers (e.g. Cray Y/MP) use very fast memory and can achieve very high throughput rates. Are these the only machines that can take (direct) advantage of gigabit/FDDI data rates? Using a gigabit net for a backbone is one aspect but being able to deliver a gigabit rate to an application seems a pipe dream for most of the current (less than super) computer architectures. I don't claim to be an expert (ex - one who has been; spurt - a small drip :-) when it comes to architecture and I don't know what all is out there, but my impression is that memory speeds need to come way up in order to make use (at the application level) of fast networks. Additionally, a protocol such as TCP needs to be better "integrated" within a given architecture. For example, reducing the number of copies by eliminating the kernel/user space copy, and performing the checksum in parallel with a copy rather than requiring a memory access just to calculate the checksum are sorely needed. I guess what I'd like to know and hear comments on is whether there are any architectures out there (other than Cray/Fujitsu/NEC) that can actually take advantage of high-speed networks (FDDI and up)? Thanks in advance, mb --- Mark Boolootian booloo@lll-crg.llnl.gov +1 415-423-1948  -----------[000117][next][prev][last][first]---------------------------------------------------- Date: 11 Sep 91 17:10:02 GMT From: pansiot@ISIS.U-STRASBG.FR (Jean-Jacques Pansiot Departement d'Informatique Universite Louis Pasteur Strasbourg FRANCE) To: comp.protocols.tcp-ip Subject: SLIP (or PPP) over switched network  I would like to establish dynamically a link between two IP network using a public switched network (ISDN or Phone). A call should be made when there is a packet to forward, and also the circuit should be released after some idle time (for obvious financial reasons). Is it possible to do this with curent implementations of SLIP or PPP? I know that there are similar products for IP over X25. I would prefer free software... Thanks for any help jean-jacques pansiot Universite Louis Pasteur Strasbourg, France pansiot@isis.u-strasbg.fr  -----------[000118][next][prev][last][first]---------------------------------------------------- Date: 11 Sep 91 19:29:00 GMT From: rml0@harvey.gte.com (Robert Long) To: bit.listserv.ibm-nets,comp.protocols.tcp-ip,comp.sys.hp,comp.protocols.ibm,comp.dcom.lans Subject: Searching for interconnect between 3270 terminals and UNIX host  I am in search of a hardware or software solution to the following problem... I have an HP 9000 platform with HP-UX hosting a character based (VT100) application. This platform has Async, Ethernet and X.25 connections which accomodate incoming terminal sessions via Dial-in, Telnet-TCP/IP and X.3/X.25. My Platform +-------+ +--------+ ~~~~~~~ +-----+ *--* | HP |-------| X.25 | { X.25 } +--|Modem|-----/\ | 9000 |---+ | Switch |-----{ PSDN } | +-----+ +-------+ | +--------+ {~~~~~~~~} +--+-----------+ | +-|TerminalServer| | | +--------------+ | | |------+------------Ethernet-----------+-------------------| This satsifies the needs of all of my prospective users except for one. This user is sitting in front of a real 3270 terminal, attached to a 3274, attached to a 3745, attached to a 3090 IBM host. My external Customer/User +------+ +------+ +------+ +------+ | 3270 |------| 3274 |-------| 3745 |-------| 3090 | | Term | | Clus | | FEP | | Host | +------+ +------+ +------+ +------+ I want to give access to the VT100-based application running on the HP9000 from the 3270 bound user. I want to avoid asking them to install an application on their 3090. Therefore I am focusing on the downstream pieces (i.e. FEP and Cluster Controller). I am aware of options for 3274-like controllers from AT&T/Memorex that connect to an Ethernet and provide VT100 emulation over Telnet to TCP/IP hosts, but this can't be considered because their current controllers don't support the option and they won't trade them out. I could consider DEC's DECserver 510 or 550, but these come out LAT instead of Telnet - and then I would need a router or such to get the traffic back to my HP9000. I have 3090 hosts and an SNA network of my own and would consider making additions to it to accomplish these connections. I want to avoid requiring my external user to run their 3090's MIPs to accomplish this (like running STX under MVS - going out to NPSI in the 3745). But, I would consider running these on my own machines to accomodate them. Well, any insights - hints - or products? I will definitely post any solutions offered! My Thanks, Bob Long GTE Telephone Operations P.O. Box 290152 IM Technology Mail Code S5-A Temple Terrace, FL 33687 --------------------------------------------------- 813/979-3219 -Voice FAX- 813/979-3259 R.LONG/GTE -SprintMail Internet- rml0@gte.com --------------------------------------------------- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Bob Long rml0@gte.com GTE Telephone Operations Tampa, FLorida  -----------[000119][next][prev][last][first]---------------------------------------------------- Date: 11 Sep 91 20:22:49 GMT From: brian@telebit.com (Brian Lloyd) To: comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)  I have been reading this thread (and others elsewhere regarding "SLITHERNET") with some interest. What I have yet to understand is how SLITHERNET is better than PPP (especially since there are so many PPP implementations now and I have never seen a SLITHERNET implementation). As for regionals forcing people to buy a particular vendor's router to connect to the regional network; that is falling by the wayside. There are many people who are buying Telebit NetBlazers and running dedicated sync PPP links to Alternet's cisco routers (that is how we talk to Alternet here). Also most of the other IP router vendors are offering PPP so they can interoperate on point-to-point links too. The requirement for PPP is becoming part of the router requirements doc as well. Why muddy the water with another nonstandard? -- Brian Lloyd, WB6RQN Telebit Corporation The views expressed Network Systems Architect 1315 Chesapeake Terrace herein are my own and brian@telebit.com Sunnyvale, CA 94089-1100 are not necessarily voice (408) 745-3103 FAX (408) 734-3333 my employer's.  -----------[000120][next][prev][last][first]---------------------------------------------------- Date: 11 Sep 91 22:59:39 GMT From: martillo@jjmhome.UUCP (Joachim Martillo) To: comp.protocols.ppp,comp.protocols.tcp-ip Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)  In article <169385@pyramid.pyramid.com>, lstowell@pyrnova.pyramid.com (Lon Stowell) writes: > In article <1991Sep4.171840.29088@telebit.com> brian@telebit.com (Brian Lloyd) writes: > >Ah yes, Yet Another Serial Protocol (YASP). Pretty soon its going to > >be like IBM in the 60's and early 70's when they had about 100 > >different variations of bisync, all mutually incompatible. > Think of it as job security Brian. And remember what > happened to IBM when their "future site" model resulted in > SNA with 7 incompatible LU types....all they did was move the > incompatibility above the link layer... Of course, a better way to view the issue is to note that the promulgation of PPP is based on a fundamentally silly idea that a single protocol can solve all problems for all times on very diverse media over a very wide range of speeds. Further, even if we accept this ridiculous premise, PPP is fundamentatlly misdesigned with all sorts of goop built into the protocol which simply doesn't belong there, ridiculous FSA's and one of the most moronic methods of tunneling which I have ever perused. Somehow promulgating attrocities like PPP looks more motivated by a hidden agenda to guarantee job security than suggesting a reasonable alternative. Joachim Carlo Santos Martillo Ajami  -----------[000121][next][prev][last][first]---------------------------------------------------- Date: 11 Sep 91 23:16:50 GMT From: skl@cs.sfu.ca (Samuel Lam) To: comp.protocols.tcp-ip Subject: Re: Need the LPD protocol  In article <1991Sep10.105250.3239@husc3.harvard.edu>, utterbac@husc9.harvard.edu (Margot Utterback) wrote: >... the last time someone posted the location of a document describing >the lpd protocol I decided not to get it, now I desperately need it. It's RFC 1179, and is available at all the usual RFC outlets.. 1179 McLaughlin, L. Line printer daemon protocol. 1990 August; 14 p. (Format: TXT=24324 bytes) ...Sam -- <skl@cs.sfu.ca>  -----------[000122][next][prev][last][first]---------------------------------------------------- Date: 11 Sep 91 23:28:09 GMT From: dank@blacks.jpl.nasa.gov (Dan Kegel) To: alt.security,sci.crypt,comp.protocols.tcp-ip Subject: Re: "Open Systems Security" document available  Arto Karila (atk@ajk.tele.fi) writes: >In June I posted a note about my study "Open Systems Security - >an Architectural Framework" which I made available through the Internet >on our host "ajk.tele.fi". The paper deals with security architectures >for open systems and is applicable to both OSI and DoD Internet. > >The paper aroused lots of interest. Unfortunately the quality of service >provided by our host was rather bad last summer because we were changing >machines. Also, many people complained that they had difficulties printing >the document which was in post script format. > >A slightly updated version of the document is now available in (hopefully) >more standard post script format which should print on printers other than >the Apple LaserWriter too. Our host is now running a lot better and the >paper is also available on one of best managed ftp servers "nic.funet.fi". >I hope this has solved most of the problems. > >So, the paper is now available with anonymous FTP at two locations: >... >The format is compressed post script, page size A4, length over 100 pages. It is available in the USA; anon FTP to blacks.jpl.nasa.gov, dir pub/karila, file OpenSystemsSecurity.ps.Z (The link between Finland and the USA was in fact quite slow, 920 bytes/sec.) - Dan Kegel (dank@blacks.jpl.nasa.gov)  -----------[000123][next][prev][last][first]---------------------------------------------------- Date: 12 Sep 91 03:39:38 GMT From: paulb@mlacus.oz.au (Paul Bandler) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,acus.general,comp.protocols.ibm Subject: TELNET & 3270 (tnv3270?) - Request For Information  I need some information about 3270 terminal emulation over a TCP/IP network, including product availability. I've seen discussion on these groups about products which do 3270 emulation over TCP/IP networks, however I'm unclear exactly how they work. I assume that they somehow map a 3270 data stream over a Telnet data stream? That being the case, if I have a PC with such a Telnet/3270 product, what requirement, if any, does this place on the 3270 host to have a peer entity? Does, say IBM, supply a 3270/Telnet server which receives this data stream and directs it into the normal 3270 data path? If so, where does this server run, in the host or in a Front End Processor? Can anyone offer comment on the performance of such a terminal network? Is it a feasible solution for a large terminal network? How does is compare say with say a solution which uses a communications server to convert into a real 3270/ bisynch stream before reaching the host? Thanks in advance for any information. Please reply by email rather than posting as postings take a long time to trickle down this way. Regards, Paul Bandler ACUS - Australian Centre for Unisys Software  -----------[000124][next][prev][last][first]---------------------------------------------------- Date: 12 Sep 91 05:24:05 GMT From: shaw@pegasus.com (Sandy Shaw) To: comp.unix.misc,comp.protocols.tcp-ip Subject: ftp text conversion  I recently wrecked some non-text files by ftp'ing from a system where the fact that I had forgot to use the binary command caused some type of text conversion to take place. Unfortunately, the original files are no longer available. The conversion performed did not affect the length of the files. Does anyone out there know what type of conversion has been done and if it is reversible? Help! shaw@pegasus.com  -----------[000125][next][prev][last][first]---------------------------------------------------- Date: 12 Sep 91 05:44:52 GMT From: rpw3@rigden.wpd.sgi.com (Rob Warnock) To: list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards Subject: Re: Need help selecting Ethernet cards for very high throughput rates.  In article <PCG.91Sep9183332@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes: +--------------- | On 3 Sep 91 04:56:41 GMT, torek@elf.ee.lbl.gov (Chris Torek) said: | torek> Actually, Ethernet is 1.25 MB/s (10 over 8 = 1.25, not 0.8). | | That's impossible to achieve, it ignores inband formatting information | (headers, CRC, pauses between packets) and other practical constraints. +--------------- True, but you can get a lot closer than you seem to think. See below... +--------------- | The theoretical maximum is a bit less than 1MB/s, and even that cannot | in practice be achieved because the Ethernet is a simplex channel, and | most protocols require ACKs every now and then, and thus in practice you | cannot just pump data continuously from source to target with maximal | size packets. +--------------- The data rate within a packet is 1.25 MB/s. I fear you are overstating the amount of overhead. +--------------- | The very best Ethernet sw can drive it at 0.8MB/s, sustained, with | occasional bursts at 0.9MB/s. +--------------- Hah! Our slowest systems (SGI Irix 4D/25's) can *sustain* over 0.95 MB/s of *user* data bytes from one Unix process to another via standard TCP/IP, and faster systems (e.g., a pair of 4D/340's) can *sustain* 1.075 MB/s. I know, because I measured it again just a moment ago, to be sure. The systems involved were normal equipment, the same as customers would get, *not* in single-user mode, *were* running the X server, *were* running the usual assortment of daemon processes [routed, mrouted, timed, inetd, &c.], but had no heavy users except my "ttcp" job. [Oh, yes, and they were running the just-released Irix version 4.0 software.] I am told by our TCP developers that using the optional "IO3" I/O board (I only had "IO2"s on my 340's), running "single-user" with no graphics or daemons running, and with an idle net (there were 20+ other stations on my local net doing routed and timed, &c.), they have sustained 1.100 MB/s. O.k., so I only got 1.075 MB/s; it was under non-ideal conditions... ;-} Let's look at what you should be able to sustain theoretically, given fast enough hardware and software. Most Berkeley-based TCPs will transmit one ACK per two data packets, with default window settings. The 64-bit Ethernet preamble is 8 bytes, and the 9.6us inter-packet gap is equivalent to 96/8 = 12 bytes. So: pre dst src type IP/TCP data CRC IPG Data: 8 + 6 + 6 + 2 + 20+20 + 1460 + 4 + 12 = 1518 + 20 = 1538 Data: 8 + 6 + 6 + 2 + 20+20 + 1460 + 4 + 12 = 1518 + 20 = 1538 Ack: 8 + 6 + 6 + 2 + 20+20 + 0+(20)+4 + 12 = 64 + 20 = 84 ==== ==== 2920 3160 There are 2920 user data bytes (not including the "pad" to bring the ACK up to the minimum Ethernet packet size) moved per 3160 byte-times on the wire, which is (2920/3160)*1.25 = 1.155 MB/s of *user* data, process-to-process. If you open your TCP window size all the way to 64 KB, you'd need one ACK per 44 packets, but to keep things moving smoothly you'd need two ACKs per window, or one ACK per 22 data packets = 1460/(1538 + (84/22)) = 1.18 MB/s. Now *that's* the maximum sustainable! -Rob ----- Rob Warnock, MS-1L/515 rpw3@sgi.com Silicon Graphics, Inc. (415)335-1673 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311  -----------[000126][next][prev][last][first]---------------------------------------------------- Date: 12 Sep 91 05:46:12 GMT From: wbe@bbn.com (Winston Edmond) To: alt.security,sci.crypt,comp.protocols.tcp-ip Subject: Re: "Open Systems Security" document available  Even after playing with the PostScript directly to try to get things to work, I'm still unable to get this paper to print properly. I had at least some success with the 'tar' file version from ajk.tele.fi, but I had no success at all getting the version from blacks.jpl.nasa.gov (which matched the version from nic.funet.fi) to print. I've sent details to Arto. -WBE  -----------[000127][next][prev][last][first]---------------------------------------------------- Date: 12 Sep 91 06:12:30 GMT From: rpw3@rigden.wpd.sgi.com (Rob Warnock) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.sysv386,comp.unix.wizards Subject: Re: Need help selecting Ethernet cards for very high throughput rates.  1.094 MB/s In <17380@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) says: +--------------- | Actually, Ethernet is 1.25 MB/s (10 over 8 = 1.25, not 0.8). | | (Piercarlo Grandi) writes: | >The very best Ethernet sw can drive it at 0.8MB/s, sustained, with | >occasional bursts at 0.9MB/s. | | I beg to differ. Here is a rerun of old tcp-ip mail. I have quoted it | in its entirety because Van tends to get quoted out of context... +--------------- If you look carefully at Van's fine article quoted by Chris, you will see that the size/time he reports for a large file transfer equates to 1.094 MB/s. Gee, awfully close to the 1.1 MB/s I claimed for SGI boxes. Multiple people getting the same result with various hardwares. Must be real. ;-} -Rob p.s. This fall's Interop is going to be fun. Who's got the best "ttcp" number over FDDI, I wonder...? ----- Rob Warnock, MS-1L/515 rpw3@sgi.com Silicon Graphics, Inc. (415)335-1673 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311  -----------[000128][next][prev][last][first]---------------------------------------------------- Date: 12 Sep 91 07:45:59 GMT From: craig@sics.se (Craig Partridge) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.sysv386,comp.unix.wizards Subject: Fastest FDDI at Interop?  In <lbiue4o@sgi.sgi.com> rpw3@rigden.wpd.sgi.com (Rob Warnock) writes: >p.s. This fall's Interop is going to be fun. Who's got the best "ttcp" >number over FDDI, I wonder...? My bet is that the winner won't be the folks with the fastest software but the folks with the fastest FDDI interface -- most of the folks who have FDDI boards in the works or in production only seem to get about 40 to 50 Mbits/second out of the board. As a back of the envelope calculation, I took Clark et. al.'s performance paper from IEEE Communications Magazine in 1989 and figured that a conservative estimate is that a packet costs about 1,000 instructions + the number of instructions to do the checksum. So figure you can do the TCP checksum in a one instruction per 2 bytes (also conservative) and use 8Kbyte FDDI maximum packet sizes and you get a bit over 5,000 instructions per packet for processing. Take a machine of between 10 and 20 MIPS and your software ought to crack 100Mbit/sec. (Note this calculation isn't perfect -- there's some operating system overhead like timers and schedulers that can eat into the amount of cycles available for protocols). Craig PS: You can do similar calculations and figure TP4/CLNP ought to be doing around 50Mbits or so, even though its checksum is somewhat more intensive than TCP's to compute. So while at Interop, you can also reasonably ask the OSI software houses to show how fast *their* stuff runs over FDDI.  -----------[000129][next][prev][last][first]---------------------------------------------------- Date: 12 Sep 91 09:44:04 GMT From: glaser@custine.crin.fr (Norbert Glaser) To: comp.protocols.tcp-ip Subject: Server sources  Hi, I'm looking for public available tcp-ip server sources for unix V. Thank's ! Norbert ------------------------------------------------------------------------------- CCCC RRR I N N Campus Scientifique Norbert Glaser, Office 705 C R R I NN N B.P. 239 Tel.: (+33) 83.91.20.00 C RRR I N N N F-54506 Vandoeuvre-Cedex Ext. 26.67 CCCC R R I N NN France FAX : (+33) 83.41.30.79 ------------------------------------------------------------------------------- > "Toutes les grandes personnes ont d'abord e'te' des enfants. < > Mais peu d'entre elles s'en souviennent." (Saint-Exupe'ry) < -------------------------------------------------------------------------------  -----------[000130][next][prev][last][first]---------------------------------------------------- Date: 12 Sep 91 12:24:06 GMT From: AKayser@dnpap.et.tudelft.nl (Alfred Kayser) To: comp.protocols.tcp-ip Subject: Re: Speed of memory and fast networks (was: Need help selecting Enet cards)  booloo@lll-crg.llnl.gov (Mark Boolootian) writes: >There is currently some work going on here attempting to design a gigabit >switch based on the (developing) FiberChannel standard. One of my colleagues >is involved in this work and we have been having discussions regarding who >can make use of gigabit data rates. The argument put forth by my colleague >is that memory speed on most computers is so slow that, when using a protocol >like TCP which typically (most common implementations) touches memory at least >three times (DMA into memory and copy from kernel to user space - I didn't count >the checksum), high data rates to the application just aren't possible. I disagree. Read on. >For example, we measured the memory speed of a Vax 6310 at around 8 MBytes/sec. >If memory is touched three times for a TCP connection, that means a maximum >possible data rate of less than 3 MBytes/sec. So even if we have a HiPPI >connection on this machine, we aren't going to do any better than 3 MB/sec. I disagree about some points. I've measured memory speed (buswidth) of certain machines and found numbers such as 20 MB/sec for suns and about 35 MB/sec for IBM RS6000 (520 one of the slowests). So this will deliver about 11-12 MBytes/sec transfer rate! >Mr. Grandi has measured memory speed of the Vax 5830 at 16 MB/sec. And that >means a maximum achievable TCP rate of less than 6 MB/sec. That isn't fast >enough to justify hanging a 5830 on a gigabit network. And that's a long way >from saturating an FDDI ring. Put 10 IBM RS6000's on a HiPPI ring and it is full with data. Other measurements have shown that 10 suns can fill FDDI with a transferrate of 6MBytes/sec each. Totalling 60Mbytes/sec!! >It seems that supercomputers (e.g. Cray Y/MP) use very fast memory and can >achieve very high throughput rates. Are these the only machines that can take >(direct) advantage of gigabit/FDDI data rates? Using a gigabit net for a >backbone is one aspect but being able to deliver a gigabit rate to an >application seems a pipe dream for most of the current (less than super) >computer architectures. I don't claim to be an expert (ex - one who has been; >spurt - a small drip :-) when it comes to architecture and I don't know what >all is out there, but my impression is that memory speeds need to come way up >in order to make use (at the application level) of fast networks. Indeed why do we have a pipe across networks for application to application connection which is many times faster than memory and the machine itself? answer: because networks are shared amongst users, machines, applications, you named it. >Additionally, a protocol such as TCP needs to be better "integrated" within >a given architecture. For example, reducing the number of copies by eliminating >the kernel/user space copy, and performing the checksum in parallel with a >copy rather than requiring a memory access just to calculate the checksum are >sorely needed. These tricks are being done. But measurements have shown that TCP isn't that much trouble. >I guess what I'd like to know and hear comments on is whether there are any >architectures out there (other than Cray/Fujitsu/NEC) that can actually take >advantage of high-speed networks (FDDI and up)? It is usefull for situations where a small number of hosts can fill the network easily. Take some RS6000's and use them as image viewing stations, connect them to a distributed image data base and see how ethernet is completely stuffed. (Ethernet just to connect two stations is fast enough for the images.) Conclusion, keep up the good works of designing, implementing, testing, measuring and standardizing of very fast networks. Especially for non-backbone situations. >Thanks in advance, >mb >--- >Mark Boolootian booloo@lll-crg.llnl.gov +1 415-423-1948 -- -- Ir. Alfred Kayser. PACS, OS/2, TCP/IP. --- Email: AKayser@et.tudelft.nl -- -- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 -- -- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --  -----------[000131][next][prev][last][first]---------------------------------------------------- Date: 12 Sep 91 13:40:12 GMT From: jra@lawday.DaytonOH.NCR.COM (John R. Ackermann) To: comp.protocols.tcp-ip Subject: configuring ftp site  I'm trying to set up a minor ftp site and don't know what the standard directory structure is that most anonymous users would expect. Also, our implementation of ftp doesn't (at least not yet) support a user name of "anonymous". What alternative names are common for anonymous ftp? Thanks. -- John R. Ackermann, Jr. Law Department, NCR Corporation, Dayton, Ohio (513) 445-2966 John.Ackermann@daytonoh.ncr.com Packet Radio: ag9v@n8acv tcp/ip: ag9v@ag9v.ampr [44.70.12.34]  -----------[000132][next][prev][last][first]---------------------------------------------------- Date: 12 Sep 91 13:48:49 GMT From: fingerhu@ircam.fr (Michel Fingerhut) To: comp.protocols.tcp-ip,eunet.misc Subject: The shortest way from Paris to the UK is...  traceroute to sun2.nsfnet-relay.ac.uk (128.86.8.45), 30 hops max, 40 byte packets 1 ircam-gw (129.102.0.1) 10 ms 10 ms 0 ms 2 fnet-gw.inria.fr (192.44.64.26) 4290 ms 3910 ms 1130 ms 3 sophia-gw.inria.fr (192.93.1.1) 590 ms 680 ms 1240 ms 4 icm-sophia.atlantic.fr (192.33.170.10) 1710 ms 1190 ms 1730 ms 5 148.52.2.1 (148.52.2.1) 2820 ms 340 ms * 6 NSS.TN.CORNELL.EDU (192.35.82.100) 4790 ms 1120 ms 590 ms 7 Ithaca.NY.NSS.NSF.NET (129.140.10.13) 700 ms 800 ms 830 ms 8 Ann_Arbor.MI.NSS.NSF.NET (129.140.81.10) 660 ms 1390 ms 2220 ms 9 Ann_Arbor.MI.NSS.NSF.NET (129.140.17.13) 2740 ms Ann_Arbor.MI.NSS.NSF.NET (129.140.17.77) 1840 ms Ann_Arbor.MI.NSS.NSF.NET (129.140.17.13) 2340 ms 10 Salt_Lake_City.UT.NSS.NSF.NET (129.140.79.17) 2770 ms 3940 ms 4450 ms 11 * Salt_Lake_City.UT.NSS.NSF.NET (129.140.15.12) 4810 ms 700 ms 12 Palo_Alto.CA.NSS.NSF.NET (129.140.77.15) 690 ms 1760 ms 2220 ms 13 Palo_Alto.CA.NSS.NSF.NET (129.140.13.16) 2730 ms Palo_Alto.CA.NSS.NSF.NET (129.140.13.80) 3400 ms Palo_Alto.CA.NSS.NSF.NET (129.140.13.16) 3930 ms 14 Palo_Alto.CA.NSS.NSF.NET (129.140.13.130) 2790 ms 1210 ms 710 ms 15 AMES.TWB.NET (192.52.195.28) 540 ms 580 ms 2470 ms 16 * * * 17 * 192.80.6.1 (192.80.6.1) 3000 ms 2040 ms 18 cisco.ulcc.ac.uk (128.86.1.2) 2750 ms 3470 ms 3930 ms 19 * *  -----------[000133][next][prev][last][first]---------------------------------------------------- Date: 12 Sep 91 17:16:51 GMT From: jeffs@novell.com (Jeff Seideman) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: poll on Pop usage  I am trying to find out if POP servers really are installed on networks. I would appreciate if you would take the time and email your answers to the following questions: Does your network mail host include a POP server? Was it pur- chased with the host, or obtained separately? If obtained separately, was it public domain or a purchased pro- duct? In either case, how can I obtain it? If so, does it use the POP-2 or POP-3 protocol? If POP-3, how does it deviate from the POP-3 standard? ie. Does its command list differ from the following: * USER name: login return: +OK, -ERR * PASS pwd: password return: +OK, -ERR * STAT: summary return: +OK #msgs #bytes * LIST [#]: summary return: +OK (summary), -ERR * RETR #: read msg return: +OK (msg), -ERR * DELE #: delete msg return: +OK, -ERR * NOOP: handshake return: +OK * LAST: hightes access return: +OK # * RSET: undo marks return: +OK * TOP # #: retrieve msg lines return: +OK (msg), -ERR * RPOP name: remote login return: +OK, -ERR * QUIT: end session return: +OK If POP-2, how does it deviate from the POP-2 standard? ie. Does its command list differ from the following: * HELO name password: login return: +OK, -ERR * FOLD folder: specify folder/mailbox return: #msgs, -ERR * READ [#]: begin reading msg return: =size * RETR: retrieve msg return: msg * ACKS: ack & save return: =size next * ACKD: ack & delete return: =size next * NACK: not received return: =size * QUIT: end session return: +OK thanks: +-----------------------------------------------------------------------+ | Jeff Seideman: jeffs@novell.com | +-----------------------------------------------------------------------+  -----------[000134][next][prev][last][first]---------------------------------------------------- Date: 12 Sep 91 17:19:07 GMT From: jeffs@novell.com (Jeff Seideman) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: poll on BSD Unix mailers  I am trying to find out if there is any kind of standard Unix mailer that is being used, or at least if there is one whose use is widespread enough to approach being a standard. I would appreciate if you would take the time and email your answers to the following questions: Do your Unix hosts use the BSD mailer, or any other command line mailer? If so, does its command list include the following: * d [message list]: delete msgs * m [user list]: mail to list * n: read next message * q: end session * s: [message list] file: append messages to file * u: [message list]: undelete messages * w: [message list] file: same as s, w/o the "from" line * x: quit and forget marks * z [-]: read next [previous] page of headers thanks: +-----------------------------------------------------------------------+ | Jeff Seideman: jeffs@novell.com | +-----------------------------------------------------------------------+  -----------[000135][next][prev][last][first]---------------------------------------------------- Date: 12 Sep 91 17:36:35 GMT From: brian@telebit.com (Brian Lloyd) To: comp.protocols.ppp,comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)  martillo@jjmhome.UUCP (Joachim Martillo) writes: >Of course, a better way to view the issue is to note that >the promulgation of PPP is based on a fundamentally silly idea that a single >protocol can solve all problems for all times on very diverse media over >a very wide range of speeds. Further, even if we accept this ridiculous >premise, PPP is fundamentatlly misdesigned with all sorts of goop built >into the protocol which simply doesn't belong there, ridiculous FSA's and >one of the most moronic methods of tunneling which I have ever perused. >Somehow promulgating attrocities like PPP looks more motivated by a hidden >agenda to guarantee job security than suggesting a reasonable alternative. >Joachim Carlo Santos Martillo Ajami You are right, PPP is a bit more complex than it needs to be (FSM, etc.). On the other hand, it works and works very well for most point-to-point circuits over which people transmit the datagrams of unreliable networks. There are methods for transferring IP, Appletalk, CLNP, IPX, and DECnet. It supports communications between MAC layer bridges. It has the support of many people, users and vendors alike. There exist many interoperable implementations. It is going to be a router requirement. You are swimming against the tide. Hey, c'mon now. There are things that I would like to see done differently in various protocols in the Internet Protocol Suite. That doesn't mean that I reject and spurn IP just because I think that I can do it better. Perhaps PPP would have been more to your liking had you participated in the design, specification, and implementation process. I guarantee you that everyone who has done an implementation has generated input that has helped extend PPP and make it more useful. One last point: I have used PPP on everything from a 1200 bps async dial-up link to a dedicated T1 link and it works very well in all the cases that I have encountered (real-world that is with real modems, DSU/CSUs, and telco-supplied links). The proof of the pudding is in the tasting, don't you think? -- Brian Lloyd, WB6RQN Telebit Corporation The views expressed Network Systems Architect 1315 Chesapeake Terrace herein are my own and brian@telebit.com Sunnyvale, CA 94089-1100 are not necessarily voice (408) 745-3103 FAX (408) 734-3333 my employer's.  -----------[000136][next][prev][last][first]---------------------------------------------------- Date: 12 Sep 91 17:45:51 GMT From: sandee@Think.COM (Daan Sandee) To: comp.unix.misc,comp.protocols.tcp-ip Subject: Re: ftp text conversion  In article <1991Sep12.052405.27189@pegasus.com>, shaw@pegasus.com (Sandy Shaw) writes: |> I recently wrecked some non-text files by ftp'ing from a system where |> the fact that I had forgot to use the binary command caused some type of |> text conversion to take place. Unfortunately, the original files are no |> longer available. The conversion performed did not affect the length of the |> files. Does anyone out there know what type of conversion has been done |> and if it is reversible? Help! |> |> shaw@pegasus.com Anything might have happened, depending on what system you were ftp'ing from, and which system you are ftp'ing to, neither of which you name. Without that information, nobody can help you. One tip : ftp the files back to the same system. Okay, so you don't have write privileges there. So ftp the files back to *another* similar system. Daan Sandee sandee@think.com Thinking Machines Corporation Cambridge, Mass 02142  -----------[000137][next][prev][last][first]---------------------------------------------------- Date: 12 Sep 91 18:43:04 GMT From: 6500elli@ucsbuxa.ucsb.edu (James A Elespuru) To: comp.protocols.tcp-ip Subject: Which protocol is used with rp?  The subject says it. Which protocol is used for data transmitions with a remote printer (ie FTP? telnet? UDP?). Thanks Don. C.Itoh Technology, Irvine,CA.  -----------[000138][next][prev][last][first]---------------------------------------------------- Date: 12 Sep 91 18:43:49 GMT From: dadams@awawa.Ebay.Sun.COM (Don Adams Secure Products Syst Eng Sun Federal) To: alt.security,sci.crypt,comp.protocols.tcp-ip Subject: Re: "Open Systems Security" document available  I had similar luck with the same version. Don Adams  -----------[000139][next][prev][last][first]---------------------------------------------------- Date: 12 Sep 91 18:51:47 GMT From: barmar@think.com (Barry Margolin) To: comp.unix.misc,comp.protocols.tcp-ip Subject: Re: ftp text conversion  In article <1991Sep12.052405.27189@pegasus.com> shaw@pegasus.com (Sandy Shaw) writes: >I recently wrecked some non-text files by ftp'ing from a system where >the fact that I had forgot to use the binary command caused some type of >text conversion to take place. Unfortunately, the original files are no >longer available. The conversion performed did not affect the length of the >files. Does anyone out there know what type of conversion has been done >and if it is reversible? Help! The conversions depend on the OSes running on the two systems. The general idea is that the sending system converts the text into a standard format, and the receiving system converts from that into its own format. The most common conversions have to do with newlines. The standard format uses CR followed LF as the newline indication, and CR followed by NUL in place of a bare CR (so that a CR followed by LF in the original file can be distinguished). If the sending system uses LF as its newline indication, it will insert a CR before every LF in the file when transmitting it, and add a NUL after any CR in the file. If the receiving system uses CR as its newline indication, it will replace every CR/LF pair with CR; what it should do with CR/NUL is unclear. Sometimes the conversions are reversible, other times they aren't. For instance, in the above example, if the receiving system translates CR/NUL to LF, the conversion is invertible -- replace all CRs with LF and vice versa. But if CR/NUL is translated to anything else, then this character becomes ambiguous in the resulting file; you can't tell whether it was originally a CR or that character. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar  -----------[000140][next][prev][last][first]---------------------------------------------------- Date: 12 Sep 91 19:39:42 GMT From: mikes@cascade.ens.tek.com (Mike Skrydlak) To: comp.protocols.ppp,comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)  In article <10930@jjmhome.UUCP> martillo@jjmhome.UUCP (Joachim Martillo) writes: >Of course, a better way to view the issue is to note that >the promulgation of PPP is based on a fundamentally silly idea that a single >protocol can solve all problems for all times on very diverse media over >a very wide range of speeds. Further, even if we accept this ridiculous >premise, PPP is fundamentatlly misdesigned with all sorts of goop built >into the protocol which simply doesn't belong there, ridiculous FSA's and >one of the most moronic methods of tunneling which I have ever perused. > >Somehow promulgating attrocities like PPP looks more motivated by a hidden >agenda to guarantee job security than suggesting a reasonable alternative. > >Joachim Carlo Santos Martillo Ajami I, as a customer, want to have routers/whatevers from different vendors be able to talk to each other & route/whatever various protocol-type packets. To achieve this 'multiple vendor choice' scenario, I want a 'standard' protocol to do this, and perform 'adequately'. It doesn't have to be perfect. Few things are, especially when designed by committee. I believe many other customers feel this way. If PPP does this, most customers will forgive it's flaws. And I believe they will view most criticisms at this point as 'Too little, too late'. That's life.  -----------[000141][next][prev][last][first]---------------------------------------------------- Date: 12 Sep 91 20:14:18 GMT From: plcochet@nysnet.nys.GOV (Peter L. Cochetti) To: comp.protocols.tcp-ip Subject: SLIP DRIVER for ATT 3B2/Wollongong TCP/IP  Is there a SLIP drive which will work on an ATT 3B2-1000/80 using the Win/3b tcpip? No one at either ATT or Wollongong seems to know! I guess the answer is no....does anyone else have it?  -----------[000142][next][prev][last][first]---------------------------------------------------- Date: 13 Sep 91 02:28:35 GMT From: jkp@cs.HUT.FI (Jyrki Kuoppala) To: alt.security,sci.crypt,comp.protocols.tcp-ip Subject: Re: "Open Systems Security" document available  In article <WBE.91Sep11224612@crystal.bbn.com>, wbe@bbn (Winston Edmond) writes: > Even after playing with the PostScript directly to try to get things to >work, I'm still unable to get this paper to print properly. I had at least >some success with the 'tar' file version from ajk.tele.fi, but I had no >success at all getting the version from blacks.jpl.nasa.gov (which matched >the version from nic.funet.fi) to print. I've sent details to Arto. The version on funic was dated Aug 27; that's probably the original unfixed version (the tar on ajk.tele.fi was dated 29 Aug). After Arto's second announcement, I had troubles connecting to ajk.tele.fi from nic.funet.fi (and still do, looks like an over-paranoid router somewhere) so I wasn't able to update the document on nic.funet.fi. When I tried from a .hut machine just now, it worked, so now the documents is pub/doc/security/karila/OpenSystemsSecurity.tar.Z at host nic.funet.fi. I haven't printed the document but the stuff in the tar.Z distribution seems to work with Ghostscript 2.2, so I suppose it's correct. The file OpenSystemsSecurity.ps doesn't work at all with Ghostscript 2.2. The old (non-working) version of the document is in pub/doc/security/karila/old. //Jyrki  -----------[000143][next][prev][last][first]---------------------------------------------------- Date: 13 Sep 91 04:57:17 GMT From: graeme@ccu1.aukuni.ac.nz ( Graeme Moffat) To: comp.protocols.tcp-ip Subject: Forwarding of broadcast packets  I have been using Netwatch to observe ethernet packets to learn what exactly is happening. I have observed the following behaviour which seems rather unsociable to me, and would appreciate comments from others. We have a class B network with 8 bits of subnet, multiple logical subnets on the one backbone. The vast majority of hosts think they are on a non-subnetted net, 3 unix hosts with another interface connected to a physical subnet & two cisco routers know better. Also some AEG's route to localtalk Macs & 2 PC's route to Banyan Vines networks. The backbone is wholly bridged. What concerns me is this: whenever a host broadcasts at the ethernet level, (RIP update, rwho, packets to a particular IP address where host only knows a default net to send to...),(but *not* ARP), four other hosts repeat that packet, sending it to a destination of '00ffbad1dead', and also sending an ICMP redirect to the original source. Two hosts are non-gateway RS6000's, one is a gatewaying Sun clone running 4.1.1, the other is one of the Banyan PC's. What is common to these? In the case of the RS6000's, I know how to stop this - there are network options of 'ipsendredirects' & 'ipforwarding' which are *on by default*, which is totally contrary to RFC1122, and there's no way a nongateway host should *ever* send a redirect! But what about the others? As well, my gatewayed RS6000 responds to some packets by sending ICMP unreachables (not just one, but between 3 & 8 at a time!!) back to the source. I'm not certain, but I think it's reacting to the IP address of x.y.255.255 which the other (dumb, nonsubnetted) hosts use. (And all the rebroadcasts mentioned above compound the fault! But anyway, even though my host *is* subnetted, it should recognise that as an 'all subnets broadcast', shouldn't it? I would appreciate comments before I report this to IBM. Also, how can I accurately match a machine's response to the packet that caused it, using only Netwatch & perhaps PCAnalyse? Am I asking too much? Thanks in advance for any advice -- Graeme Moffat g.moffat@aukuni.ac.nz \ Time wastes us all, Computer Aided Design Centre, Fax: +64-9-366-0702 / our bodies & our wits School of Engineering, Ph: +64-9-737-999 x8384 / But we waste time, University of Auckland, Private Bag, Auckland, NZ \ so time & we are quits  -----------[000144][next][prev][last][first]---------------------------------------------------- Date: 13 Sep 91 05:50:59 GMT From: Andy.Linton@comp.vuw.ac.nz (Andy Linton) To: comp.protocols.tcp-ip,eunet.misc Subject: Re: The shortest way from Paris to the UK is...  In article <1991Sep12.134849.1337@ircam.fr>, fingerhu@ircam.fr (Michel Fingerhut) writes: |> traceroute to sun2.nsfnet-relay.ac.uk (128.86.8.45), 30 hops max, 40 |> byte packets |> 1 ircam-gw (129.102.0.1) 10 ms 10 ms 0 ms |> 2 fnet-gw.inria.fr (192.44.64.26) 4290 ms 3910 ms 1130 ms |> 3 sophia-gw.inria.fr (192.93.1.1) 590 ms 680 ms 1240 ms |> 4 icm-sophia.atlantic.fr (192.33.170.10) 1710 ms 1190 ms 1730 |> ms |> 5 148.52.2.1 (148.52.2.1) 2820 ms 340 ms * |> 6 NSS.TN.CORNELL.EDU (192.35.82.100) 4790 ms 1120 ms 590 ms |> 7 Ithaca.NY.NSS.NSF.NET (129.140.10.13) 700 ms 800 ms 830 ms |> 8 Ann_Arbor.MI.NSS.NSF.NET (129.140.81.10) 660 ms 1390 ms 2220 |> ms |> 9 Ann_Arbor.MI.NSS.NSF.NET (129.140.17.13) 2740 ms |> Ann_Arbor.MI.NSS.NSF.NET (129.140.17.77) 1840 ms |> Ann_Arbor.MI.NSS.NSF.NET (129.140.17.13) 2340 ms |> 10 Salt_Lake_City.UT.NSS.NSF.NET (129.140.79.17) 2770 ms 3940 ms |> 4450 ms |> 11 * Salt_Lake_City.UT.NSS.NSF.NET (129.140.15.12) 4810 ms 700 ms |> 12 Palo_Alto.CA.NSS.NSF.NET (129.140.77.15) 690 ms 1760 ms 2220 |> ms |> 13 Palo_Alto.CA.NSS.NSF.NET (129.140.13.16) 2730 ms |> Palo_Alto.CA.NSS.NSF.NET (129.140.13.80) 3400 ms |> Palo_Alto.CA.NSS.NSF.NET (129.140.13.16) 3930 ms |> 14 Palo_Alto.CA.NSS.NSF.NET (129.140.13.130) 2790 ms 1210 ms 710 |> ms |> 15 AMES.TWB.NET (192.52.195.28) 540 ms 580 ms 2470 ms |> 16 * * * |> 17 * 192.80.6.1 (192.80.6.1) 3000 ms 2040 ms |> 18 cisco.ulcc.ac.uk (128.86.1.2) 2750 ms 3470 ms 3930 ms |> 19 * * Compare this with our path! traceroute to sun2.nsfnet-relay.ac.uk (128.86.8.45), 30 hops max, 38 byte packets 1 ngauranga (130.195.6.1) 6 ms 5 ms 2 csc.net.vuw.ac.nz (130.195.1.1) 12 ms 7 ms 3 gw-vuw.waikato.kawaihiko.net.nz (140.200.216.1) 58 ms 35 ms 4 feba-aotearoa.waikato.paccom.net.nz (130.217.64.1) 63 ms 85 ms 5 arc2.nsn.nasa.gov (132.160.254.1) 736 ms 694 ms 6 ARC1.NSN.NASA.GOV (192.52.195.2) 699 ms 700 ms 7 GSFC1.NSN.NASA.GOV (128.161.2.3) 779 ms 780 ms 8 ULCC.NSN.NASA.GOV (128.161.65.59) 869 ms 871 ms 9 cisco.ulcc.ac.uk (128.86.1.2) 905 ms (ttl=239!) 893 ms (ttl=239!) 10 * *  -----------[000145][next][prev][last][first]---------------------------------------------------- Date: 13 Sep 91 11:40:43 GMT From: scoggin@delmarva.delmarva.COM (John Scoggin) To: comp.protocols.tcp-ip Subject: (none)  Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I) To: samsung!crackers!martillo@zaphod.mps.ohio-state.edu (Martillo) Date: Fri, 13 Sep 91 7:40:42 EDT Sender: <tcp-ip-relay@nisc.sri.com> From: John Scoggin <scoggin@delmarva.delmarva.com> Cc: tcp-ip@nic.ddn.mil Reply-To: scoggin@delmarva.com In-Reply-To: <2424@crackers.clearpoint.com>; from "Martillo" at Aug 31, 91 2:31 am X-Mailer: ELM [version 2.3 PL11] > > The following memorandum is a first draft of one of a pair of potential > RFCs which specify a methodology for using wide-area serial synchronous > DCE/DTE-type point-to-point links as a computer networking medium. The > Clearpoint Little Dipper/Auriga product line offer as one of several > configurable options a wide-area interface which implements this > specification, and should a developer implement this interface for his > bridge, router or end host, that network device will be able to > communicate with the Little Dipper/Auriga products over point-to-point If this is a "potential RFC", why isn't it being handled as an Internet Draft? Also, maybe you should change the name (to be consistent with the networking community's love of acronyms) to YAPPP - Yet Another Point-to- Point Protocol. Seriously, if PPP is deficient, shouldn't we create a Working Group to revisit point-to-point protocols in general? I don't really think the RFC process was created for the purpose of "legitimizing" proprietary protocols. A lot of companies are starting to point to RFC xyz and saying that their product meets an RFC; nevermind that the IETF lists the protocol and that RFC as Experimental or Not Recommended... ---------------------------------------------------------------------- John K. Scoggin, Jr. Supervisor, Network Operations Phone: (302) 451-5200 Delmarva Power & Light Company (800) 388-7076 500 N. Wakefield Drive Fax: (302) 451-5321 Newark, DE 19714-6066 Email: scoggin@delmarva.com ----------------------------------------------------------------------  -----------[000146][next][prev][last][first]---------------------------------------------------- Date: 13 Sep 91 11:54:51 GMT From: srwmcln@windy.dsir.govt.nz To: comp.protocols.tcp-ip Subject: Wanted:PD IBM PC Telnet/Ethernet terminal server s/w.  I have a friend who is interested in PD software to turn a IBM PC into a Telnet/Ethernet terminal server for (say) 20 terminals. Whats out there?.  -----------[000147][next][prev][last][first]---------------------------------------------------- Date: 13 Sep 91 15:11:16 GMT From: bill@banana.fedex.com (bill daniels) To: comp.protocols.tcp-ip Subject: Cabletron Prod. Support Stinks  Does anyone else have comments about Cabletron's product support. We have had incredibly bad luck with returns for repair (the need for repair is another story!). On two occasions, units have been returned for repair with proper RMA/RA numbers and on two occasions the receiving department claims that they have never received the devices. (ATTENTION: Upcoming Plug For My Own Company!) Thank goodness that Federal Express has deliver records with someone's name on it. However, even after this, the support people will not call back. We call and leave messages and it is like the message goes the way of the RMA numbers - into a black hole. Is this uniquely our problem or have others experienced this sort of behavior from their product support? We bought Cabletron products based upon their reputation (which due to failures in the H/W we have yet to experience just how good their products are!). I have egg on my face because of my recommendations that we try their stuff. This is absolutely the only TCP/IP - ethernet equipment that we have used that didn't just go plug and play. The first problem encountered was with the NB25E bridge. Right out of the box, it generated massive collisions and gunk on the net. We finally were able to make the MAGIC cable needed to connect the console port of the bridge to a terminal (why are VTx00 and ADDS the only ones supported?) and set up the characteristics that we wanted to play with. When I say MAGIC cable, I mean MAGIC cable; No "standard" RS-232 sort of config will work. It has to have some semi-bizarre combo of H/W signaling. Even after this the bridge still generated massive (*&^ on the net. OK, infant mortality, get an RMA and back to the factory it goes. After being lost and not worked on for a week or two, it is finally returned and "fixed". Something was indeed broken in the unit. Now it comes back and our MAGIC console cable won't work. Back to the factory where "Mr. Fixit" tells us that our cable is built wrong. We need to have a couple of pins moved around into positions that don't match anything in print or match anything ever built by anyone around here where there are decades of experience making serial devices talk. "OK, send it back to us please with the cable corrected." Guess what? Still no talkie on the console. With no console, the bridge configuration cannot be set up. We can't ping the bridge or talk SNMP to it. It leaves us totally blind which is not acceptable in our environment. In the meantime, port 7 on the MT-800 (a DELNI clone) has given up the ghost. Get the RMA. Send it to Cabletron. Receiving claims they have never seen it. Deja vu all over again? They will not return our calls. This is the most frustrating experience that we have ever gone through with a H/W vendor. We aren't even being kissed on the cheek and told everything will be o.k. while we wait much longer than necessary. Are we just being picked on? bill daniels -- these ravings are in no way sanctioned by federal express corp bill daniels | voice: (901)797-6328 federal express corp | fax: (901)797-6388 box 727-2891, memphis, tn 38194 | email: bill@banana.fedex.com  -----------[000148][next][prev][last][first]---------------------------------------------------- Date: 13 Sep 91 17:26:11 GMT From: wlb@memstvx1.memst.edu To: comp.protocols.tcp-ip Subject: Proxy ARP software needed for SUN  Hello, I need some help either locating or modifying software for Proxy ARP. We have a class B network, 141.225.0.0, for our campus. We are connected to SURAnet via a Proteon router. We have assigned subnet numbers for different building/departments but have not enabled subnetting campuswide. Our Engineering department has now acquired second ethernet cards for 2 of their SUNs and wants to subnet. I need to find software (Proxy ARP) to allow the SUN to answer ARP requests for the workstations on the subnet that the non-subnetted hosts do not know about. I perfer to find something at no cost, but would be willing to purchase a commercial package if nothing free is available. I can FTP to sites on the Internet, so that would be the best source if the software is out there. Thanks in advance, Bill Brown Systems Programmer/Postmaster/Network flunky Memphis State University wlb@memstvx1.memst.edu wlb@memstvx1.bitnet  -----------[000149][next][prev][last][first]---------------------------------------------------- Date: 13 Sep 91 17:53:03 GMT From: Sam.Wilson@ed.ac.uk To: comp.protocols.tcp-ip,eunet.misc Subject: Re: The shortest way from Paris to the UK is...  Well, we can't help it if France's routing is messed up! :-) [ from cancer.ucs.ed.ac.uk - 129.215.200.7 ] cancer: 54) traceroute 129.102.0.1 traceroute to 129.102.0.1 (129.102.0.1), 30 hops max, 40 byte packets 1 129.215.200.253 (129.215.200.253) 4 ms 4 ms 3 ms 2 gw.ulcc.ja.net (146.97.112.4) 125 ms 107 ms 97 ms 3 cisco.ulcc.ac.uk (128.86.1.2) 102 ms 108 ms 122 ms 4 hef-router.nikhef.nl (192.16.192.176) 691 ms 789 ms 2494 ms 5 Amsterdam.Nl.EU.net (192.87.4.20) 713 ms 773 ms 1044 ms 6 134.222.2.2 (134.222.2.2) 796 ms 502 ms 504 ms 7 fnet-gw.inria.fr (192.93.1.108) 582 ms 401 ms 763 ms 8 * * * : : : 30 * * *  -----------[000150][next][prev][last][first]---------------------------------------------------- Date: 13 Sep 91 20:28:04 GMT From: steve+@andrew.cmu.edu (Stephen Webster) To: comp.protocols.tcp-ip Subject: tn6530 anybody?  Hey all, have you heard of (or do you have) a Telnet that emulates one of those old Tandem 6530 terminals? Doesn't matter what it runs on, I'll buy the box; just got to have it. Please burble by email. I can't be trusted to read any newsgroup regularly. thanks, -steve webster  -----------[000151][next][prev][last][first]---------------------------------------------------- Date: 13 Sep 91 20:46:02 GMT From: solomon@becks.comm.mot.com (James Solomon) To: comp.protocols.tcp-ip Subject: What are the sources of UDP packet errors?  Greetings: Take the hypothetical situation of three hosts connected via Ethernet. No bridges, routers, gateways ... no nothin', except these three hosts: A, B, and C. Let's say A sends B a UDP packet. Now, if we assume that the Ethernet tranceivers and the IP code in all hosts are working properly, can we *ever* get an error at the UDP layer (that is, an error detected solely by the UDP checksum)? If the answer to this is, *yes*, please enumerate the reasons why such an error could occur. [I'm after reasons that help shed some light on the process of computer communications, not things like the UDP code is hosed'' ;-)] What if we release the restrictions above, namely, place these hosts on separate networks, connected via routers (whose Ethernet drivers are also functioning properly). Are the sources of error now simply those inherent in connection-less network layer service, i.e., lossed packets, duplicated packets, etc? Any insight into this matter is greatly appreciated. Thanks, -- Jim Solomon (solomon@becks.comm.mot.com)  -----------[000152][next][prev][last][first]---------------------------------------------------- Date: 13 Sep 91 21:08:53 GMT From: petri@digiw.fi (Petri Alhola) To: comp.protocols.tcp-ip Subject: Public TCP/IP networks info Wanted  We are here in Finland building with our local unix users group (fuug) public accessible TCP/IP based network based in dial up lines. It used async modem lines eith 9600..19200 with SLIP and 64K ISDN lines with ppp. I am personaly involved to project by developping the software used in 64K bit links. I like to get more information about similar projects in other countiries where is build this kind of publisly accessible internet like networks that are not limited only to large companies and univerities. As i know there is alternet in usa that is one similar. The information that i like to get is, how they are organized, what is policy to joining them, what it costs, how they are implemented, how they uses dialup and fixged lines. I am also intrested to get pointers where i can ftp more information. Petri Alhola petri@digiw.fi  -----------[000153][next][prev][last][first]---------------------------------------------------- Date: 13 Sep 91 21:24:39 GMT From: richb@kronos.com (Rich Braun) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Router security features  At a user group meeting yesterday, the topic of discussion was network security and "firewall" routers. We had an engineer from a local TCP/IP vendor come in and discuss the details of their router software with us. In order to encourage more commercial enterprises (like my company) to connect with Internet, network security issues have to be addressed in a more cost-effective and less labor-intensive way than in the past. At this meeting, a couple of people wanted to be able to tie into the network using an inexpensive piece of DOS-based router software which had some fairly simple security features in place. The engineer for this vendor claimed that "no" router has these features as of this date. Routers currently operate strictly at Level 3 (IP, beneath TCP). IP datagram headers do not contain the information necessary to screen network traffic for security purposes, unless all you want to do is allow and disallow traffic between particular IP addresses (a fairly useless idea). Current Internet thinking is that network security should be host-based rather than network-based. A number of companies therefore put one host on Internet and run a local network on the other side of this "firewall". Employees must either walk over to that host system or remote login to it in order to access Internet. I really don't like that approach. But in order to provide host-based security features in a modern environment of distributed workstations, one per desktop (especially given the freely-available TCP/IP software one can use under DOS), the security administrator has to worry about a far greater number of hosts than in the past. When I worked for DEC/Marlboro ten years ago, there was exactly one computer on ARPAnet. Today, given the same number of employees and similar (but new) equipment, there would be perhaps 500 desktop systems which could run TCP/IP and theoretically be connected to Internet. Is it possible to implement a port-number-based TCP/IP security filter within a router? (This could be configured to only allow certain types of connects to go through, etc.) If it's possible, can it be done without unduly slowing performance down or adding cost? Is it reasonable to expect router vendors to provide this, in the absence of an RFC standard to do it? Is there an RFC working committee already addressing this issue (generally, network-based rather than host-based security)? If this can't be done in a router, I would assert that any other approach would add latency to packet-forwarding time, because the router (or equivalent functionality in a Unix-based host) is usually a given when connecting to Internet, and a separate box would add a second hop to network connections. By the way, I'm talking about low-cost software-based routers in the$1,000-5,000 range, not whiz-bang models beyond the price-range of small
companies.

-rich


-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 91 22:21:47 GMT
From:      dank@blacks.jpl.nasa.gov (Dan Kegel)
To:        alt.security,sci.crypt,comp.protocols.tcp-ip
Subject:   Re: [alt.security] Re: "Open Systems Security" document available

I wrote:
>Arto Karila (atk@ajk.tele.fi) writes:
>>In June I posted a note about my study "Open Systems Security -
>>an Architectural Framework" which I made available through the Internet
>>on our host "ajk.tele.fi". The paper deals with security architectures
>>for open systems and is applicable to both OSI and DoD Internet.
>It is available in the USA;
>anon FTP to blacks.jpl.nasa.gov, dir pub/karila, file OpenSystemsSecurity.ps.Z
>(The link between Finland and the USA was in fact quite slow, 920 bytes/sec.)
>- Dan Kegel (dank@blacks.jpl.nasa.gov)

properly, so I have downloaded the files from ajk.tele.fi.  Get them with
anon FTP to blacks.jpl.nasa.gov, dir pub/karila, file OpenSystemsSecurity.tar.Z
and/or OpenSystemsSecurity.txt.Z.
- Dan K.

-r--r--r--  1 dank       246271 Sep 11 16:32 OpenSystemsSecurity.ps.Z
-r--r--r--  1 dank       346316 Sep 13 15:16 OpenSystemsSecurity.tar.Z
-r--r--r--  1 dank       115683 Sep 13 15:17 OpenSystemsSecurity.txt.Z
-r--r--r--  1 dank         3432 Sep 13 15:21 README


-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 91 05:28:34 GMT
From:      ron@npd.Novell.COM (Ron Holt)
To:        comp.protocols.tcp-ip
Subject:   Re: What are the sources of UDP packet errors?

In article <1991Sep13.204602.18573@ecs.comm.mot.com> solomon@becks.comm.mot.com (James Solomon) writes:

>Now, if we assume that the Ethernet tranceivers and the IP code in all hosts
>are working properly, can we *ever* get an error at the UDP layer (that is, an
>error detected solely by the UDP checksum)?  If the answer to this is, *yes*,
>please enumerate the reasons why such an error could occur. [I'm after reasons
>that help shed some light on the process of computer communications, not things
>like the UDP code is hosed'' ;-)]

The UDP checksum is there to detect errors not detected elsewhere such
as at the Ethernet data link level.  If you make the hypothetical
assumption that there will never be any failures anywhere in your
hardware or software, I would say no, you could never get a UDP
checksum error.  But if you assume only the Ethernet tranceivers and
the IP code in your hosts can be trusted, there still are other
areas that could fail and generate UDP checksum errors.  Examples:
intermittent software bugs in the Ethernet driver, flakey memory in
occasionally corrupt packet buffers, etc.

>What if we release the restrictions above, namely, place these hosts on
>separate networks, connected via routers (whose Ethernet drivers are also
>functioning properly).  Are the sources of error now simply those inherent in
>connection-less network layer service, i.e., lossed packets, duplicated
>packets, etc?

All of the problems I mention above can occur (and have occurred at
times) in routers that would simply result in corrupted packets being
delivered to users if there were no checksum.  Your questions are
touching upon the subject of the importance of an end-to-end checksum.
Basically, you have to decide if you want to pay a small (if implemented
properly) performance hit in computing the UDP checksum for the benefit
of detecting otherwise undetected bad packets.  Alternatively, you can
assume your hardware and software are generally reliable and disable UDP
checksums.  You get what you pay for.
--
Ron Holt   ron_holt@npd.novell.com   +1 801-568-8674


-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 91 17:41:53 GMT
From:      lhl@CS.WISC.EDU (L.H. Landweber)
To:        comp.protocols.tcp-ip
Subject:   (none)

CALL FOR PARTICIPATION

INET'92
International Networking Conference
Internet Society
Kobe Japan - June 15-18, 1992

The first international conference organized by the
Internet Society (just being formed) focusing on
worldwide issues of research and academic networking -
INET '92 - will be held on June 15-18, 1992 in Kobe,
Japan. The goal of this conference is to bring together
individuals from university, industry and government who
are involved with planning, developing, implementing, managing
and funding national, regional and international research

The conference agenda will include plans and status
reports on research and academic networks throughout the
world. In addition, possible topics for conference
sessions include but are not limited to the following:

Technology and Services
-- Progress toward international open network protocols
-- Interoperability among existing national and international networks
-- Collaboration technologies
-- Security, management and authentication in managing networks
-- Technologies of the '90s
-- Mail and directory services
-- Very high speed networks
-- Data storage: terabytes and beyond
-- Networks and network services of the 21st century

Applications
-- Network support of international scientific collaboration
-- Supercomputing
-- High energy physics
-- Workstation teleconferencing
-- Computer supported collaborated works
-- Education
-- Libraries

Regional Issues
-- Asia-Pacific Rim		-- Latin America
-- Eastern Europe		-- North America
-- Europe			-- Africa
-- Special Issues for the Third World

Policy Issues
-- Globalization of services
-- Commercialization/privatization
-- Appropriate use
-- Security
-- Privacy
-- Telecommunications policy

Information for Paper Submission
For Technology & Services and Applications sessions,
please submit 6 copies (in English) of double-space
typed manuscript (maximum of 20 pages) with an abstract
to

Prof. Haruhisa Ishida
Computer Centre, University of Tokyo
Bunkyo-ku, Tokyo
Japan 113
(Phone) +81-3-3818-0287
(FAX) +81-3-3814-7279

You may also submit a PostScript version of your paper
by e-mail to ishida@u-tokyo.ac.jp.

Tutorials
In addition to papers, proposals for one day tutorials
are solicited in any of the conference area.  Such
proposals should be submitted to the program chair or
Deborah Estrin (estrin@usc.com) by January 6, 1992.

Important dates
-- January  6, 1992		Manuscript due and proposal due for a tutorial
-- March 1, 1992		Notification of acceptance to authors
-- April 15, 1992		Camera-ready papers due

Workshop for Developing Countries

A one day workshop for representatives of developing and
third world  countries, "How to Plan for and Implement
Research and Academic Networks", will be held in
conjunction with INET'92.

Conference Committee
-- General Conference Chair		Hideo Aiso, Japan
-- Regional Conference co-chairs
North America:			Richard Mandelbaum, USA
Europe: 			Frode Greisen, Denmark
Asia-Pacific Rim: 		Jun Murai, Japan
Developing Countries:	 	Stefano Trumpy, Italy

Program Committee
-- Program Chair			Haruhisa Ishida, Japan
-- Program Regional co-chairs
-- North America: 		John Demco, Canada
-- Europe:			Dennis Jennings, Ireland
-- Asia-Pacific Rim:		Hide Tokuda, Japan/USA
-- Developing Countries:	Enzo Puliatti, UNDP/Italy

-- Chair					David Farber, USA

Tutorial Committee
-- Chair					Deborah Estrin, USA

Internet Society Liaison			Larry Landweber, USA

General Inquiries
To be added to the conference mailing list, send
mail, fax or E-mail to one of these addresses.

Japan & Pacific Rim:
WIDE project,
INET '92 secretariat 	Phone: +81 466 48 9433
5322 Endo, Fujisawa		FAX:   +81 354 90 7002

North America:
EDUCOM,
INET '92 secretariate	Phone: +1 202 872 4200
1112 16th Street, NW	FAX:   +1 202 872 4318
Washington DC 20036, USA	EMail: inet92@educom.edu

Europe:
UNI-C,
INET '92 secretariate	Phone: +45 45 93 83 55
DTH, bygning 305		FAX:   +45 45 93 02 20
DK-2800 Lyngby, Denmark	EMail: inet92@vm.uni-c.dk

Internet Society
in cooperation with
ACM SIGCOMM
IPSJ(Information Processing Society of Japan)
CREN, EDUCOM, FARNet, IAB and NetNorth in North America
JAIN, JCRN, TISN, and WIDE in Japan
EARN, EUUG (EUnet), NORDUNET and RARE in Europe

Digital Equipment Corporation
IBM
Novell


-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 91 20:47:32 GMT
From:      dave@fps.com (Dave Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: What are the sources of UDP packet errors?

In article <1991Sep13.204602.18573@ecs.comm.mot.com> solomon@becks.comm.mot.com (James Solomon) writes:
>
>Greetings:
>
>Take the hypothetical situation of three hosts connected via Ethernet.
>No bridges, routers, gateways ... no nothin', except these three hosts:
>A, B, and C.  Let's say A sends B a UDP packet.
>
>Now, if we assume that the Ethernet tranceivers and the IP code in all hosts
>are working properly, can we *ever* get an error at the UDP layer (that is, an
>error detected solely by the UDP checksum)?  If the answer to this is, *yes*,
>please enumerate the reasons why such an error could occur.  [I'm after reasons
>that help shed some light on the process of computer communications, not things
>like the UDP code is hosed'' ;-)]

Yes.  The interface between the transceiver and the host could be faulty.
Most machines will have parity checking on memory buses so this isn't
too much of a problem.  However if you have several layers of hardware which
discard and then regenerate the parity you can have a problem.  The UDP
checksum doesn't catch all errors, but it is an additional backup.

If you say that UDP checksumming is useless unless you have a problem you're
quite right.  However you need the checksum to tell you you have a problem.

>What if we release the restrictions above, namely, place these hosts on
>separate networks, connected via routers (whose Ethernet drivers are also
>functioning properly).  Are the sources of error now simply those inherent in
>connection-less network layer service, i.e., lossed packets, duplicated
>packets, etc?

Now is when you really need UDP checksumming.  Each of these devices
will discard and regenerate the Ethernet CRC's.  If any errors are
inserted into the data inside the routers this will go unnoticed.  The
probability of this is low, but non-zero.  If you're running your
NFS across a SLIP link you're dead meat as there is no checksumming
performed at the link-level there.  Of course, very few people run
SLIP much faster than 19200 so you usually don't want to run NFS across
it, but other UDP based protocols can have problems.

Basically, a restriction like "the Ethernet drivers are functioning properly
so why should I need UDP checksums" is bogus.  You can never assume that
a portion of you system is functioning.  That's the whole point behind
checksums.  You can say "I believe the probability of this event is very low
so I choose not to have end-to-end checksums of the data."

BTW, lost packets, duplicated packets, etc. should not cause corrupted
UDP data so checksumming doesn't help there, unless of course, your IP
re-assembly code is broken.
--
David L. Smith
FPS Computing, San Diego        ucsd!celit!dave or dave@fps.com
"It was time to stop playing games.  It was time to put on funny hats and
eat ice cream.  Froggie played his oboe" - Richard Scarry


-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 91 19:42:51 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Router security features

In article <1991Sep13.212439.10000@kronos.com>, richb@kronos.com (Rich Braun) writes:
>                                   ...           The engineer for this
> vendor claimed that "no" router has these features as of this date.
> ..

Talk to other vendors.

I know of at least one important computer vendor (not my employer) whose
connection to the Internet appears to involve just such filters.  I suspect
it involves some vendor's dedicated routers.

There are also such facilities for workstations acting as routers,
including my employer's.

Vernon Schryver,   vjs@sgi.com


-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 91 20:31:44 GMT
From:      skl@cs.sfu.ca (Samuel Lam)
To:        alt.sys.sun,comp.protocols.tcp-ip
Subject:   NIT-based traceroute

Could someone please tell me where the NIT-based version of
traceroute is archived.

...Sam
--
<skl@cs.sfu.ca>


-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 91 20:39:49 GMT
From:      kph@cisco.com (Kevin Paul Herbert)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Router security features

cisco routers support access lists using TCP port numbers and IP addresses. You can
send mail to customer-service@cisco.com to find out more.

Our low-end router costs just a little bit more than the price range you quoted.

Kevin


-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 91 21:34:46 GMT
To:        comp.protocols.tcp-ip
Subject:   non-ip info request

Yes, I know this is comp.protocols.tcp-ip but, who knows... someone
might have the info handy.

for the in-progress round of router (& bridge tests) I'd like to
verify what I'm doing with 2 protocols: DECnet & OSI

can anyone send me an anotated packet dump of a OSI and a DECnet
packet? Some sort of protocol that would 1/ route & 2/ be a good one
to test performance with. (I'm using Echo Request packets for IP-UDP,
AppleTalk etc)  But if there is not a dump of an OSI & DECnet ping
(actually I don't know that there is such a thing as a DECnet ping),
then anything would do.

What I need most is the anotation, i.e. what bits do what
something like

offset	data
00 	AA 00 04 00 02 04        # dest MAC address of router
06 	AA 00 04 00 01 04        # source hardware address
12 	08                       # type high byte
13 	00                       # type low byte
#
14 	45                       # IP version - 4,
# byte units) - 5
15 	00                       # service field
16 	00 2E                    # total length
18 	00 00                    # ID
20 	40 00                    # flags (3 bits)-4 (do not
# fragment),
# fragment offset-0
22 	0A                       # TTL
23 	11                       # protocol - 17 (UDP)
24 	C4 8D                    # header checksum
10 	00 4 26                  # source IP address
10 	00 4 30                  # destination IP address

can anyone help (soon! :-( )

thanks

Scott

sob@harvard.edu


-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 02:53:34 GMT
From:      zweig@cs.uiuc.edu (Johnny Zweig)
To:        comp.protocols.tcp-ip
Subject:   SND.WL1/SND.WL2 confusion

I am tracking down a bug in my implementation of TCP, which I wrote with RFC
793 open on my lap.  There is some garbled nonsense (at least it looks like
nonsense to me; I don't know if I'm being stupid or Postel was smoking
something on page 72) about only updating the send window when SND.WL1 !=
SEG.SEQ or SND.WL2 != SEG.ACK which is designed to keep you from updating your
send window on the basis of out of date (retransmitted) ACKs.

Problem:  when a receive window opens up, if no data have been sent, my TCP
module will see totally identical ACK segments, except that the later ones
have bigger windows.  The bug is that an application sending 1K chunks hangs
when the remote TCP's receive window gets below 1K and my send window doesn't
get updated by the later ACKs with those succulent 4096 octet windows because
of my (mis)implementation of the (mis)statements on page 72 of RFC 793.

So could someone please explain/give a pointer to an explanation of the Right
Thing (tm) to do with updating the TCP send window?  It seems like the
gratuitously smaller window (i.e. two identical ACKs, the latter of which has
a smaller window) without preventing me from (correctly) using a gratuitously
bigger window size.  I understand the need to not decrease the send window
when you see a retransmission (I think; it's getting late, and I'm tired) but
I think my reading of RFC 793 p.72 is the Wrong Thing.

-Johnny Window


-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 07:53:04 GMT
From:      AKayser@dnpap.et.tudelft.nl (Alfred Kayser)
To:        comp.protocols.tcp-ip,eunet.misc
Subject:   Re: The shortest way from Paris to the UK is...

Sam.Wilson@ed.ac.uk writes:

>Well, we can't help it if France's routing is messed up! :-)

>[ from cancer.ucs.ed.ac.uk - 129.215.200.7 ]
>cancer: 54) traceroute 129.102.0.1
>traceroute to 129.102.0.1 (129.102.0.1), 30 hops max, 40 byte packets
> 1  129.215.200.253 (129.215.200.253)  4 ms  4 ms  3 ms
> 2  gw.ulcc.ja.net (146.97.112.4)  125 ms  107 ms  97 ms
> 3  cisco.ulcc.ac.uk (128.86.1.2)  102 ms  108 ms  122 ms
> 4  hef-router.nikhef.nl (192.16.192.176)  691 ms  789 ms  2494 ms
> 5  Amsterdam.Nl.EU.net (192.87.4.20)  713 ms  773 ms  1044 ms
> 6  134.222.2.2 (134.222.2.2)  796 ms  502 ms  504 ms
> 7  fnet-gw.inria.fr (192.93.1.108)  582 ms  401 ms  763 ms
> 8  * * *
>     :
>     :
>     :
>30  * * *
It seems that from holland we get the shortest connection (in hops).
Even from cancer.ucs.ed.ac.uk it is longer.
From dutepp0.et.tudelft.nl:
traceroute to sun2.nsfnet-relay.ac.uk (128.86.8.45), 30 hops max, 40 byte packets
1  dutrci1.tudelft.nl (130.161.180.25)  20 ms  8 ms  5 ms
2  snet-router.surfnet.nl (192.87.8.17)  11 ms  8 ms  8 ms
3  hef-router.nikhef.nl (192.16.183.80)  9 ms  9 ms  10 ms
4  cisco.ulcc.ac.uk (192.16.192.185)  103 ms  87 ms  85 ms
5  * *

Also note very fast responce times.
--
-- Ir. Alfred Kayser. PACS, OS/2, TCP/IP. --- Email: AKayser@et.tudelft.nl --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --


-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 11:46:12 GMT
From:      tb@Materna.DE (Torsten Beyer)
To:        comp.protocols.tcp-ip
Subject:   RPC on SYSVR4

Hi everybody,

We have some RPC application that we have ported to SYSVR4 recently. Looking
at what rpcgen emits this looks pretty different from what I have seen under
BSD-ish UNIXes (like SunOS). It seems like the RPC library runs directly on
top of TLI. I wonder wether the source for such a library is publicly
available (like the socket-based RPC libraries). Any hints ?

cheers
-Torsten
--
Torsten Beyer                      	mail	     : tb@Materna.DE
Dr. Materna GmbH		   	vox humana   : +49 231 5599 225
Vosskuhle 37, D-4600 Dortmund	   	fax machina  : +49 231 5599 100
UNIX is a registered trademark of AT&T. AT&T is a modem test command


-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 11:54:46 GMT
From:      tom@ksr.com
To:        comp.protocols.tcp-ip
Subject:   (none)


Please remove me from this list.

Thank you.

|| * * * * * =========       Tom Varga
||  * * * *  =========       Kendall Square Research
|| * * * * * =========       617-895-9415
|| ===================       tom@ksr.com
|| ===================       uunet!ksr!tom
|| ===================       N2UA @ KA1PEP
||


-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 11:55:09 GMT
From:      scoggin@delmarva.delmarva.COM (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   (none)

Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)
To: dcarr@hobbit.gandalf.ca (Dave Carr)
Date: Mon, 16 Sep 91 7:55:09 EDT
Sender: <tcp-ip-relay@nisc.sri.com>
From: John Scoggin <scoggin@delmarva.delmarva.com>
Cc: tcp-ip@nic.ddn.mil
In-Reply-To: <1991Sep3.193526.21423@hobbit.gandalf.ca>; from "Dave Carr" at Sep 3, 91 7:35 pm
X-Mailer: ELM [version 2.3 PL11]

>
> In <2431@crackers.clearpoint.com> martillo@crackers.clearpoint.com (Martillo) writes:
>
> >I should note that PPP is basically misdesigned because the latest crop
> >of Ethernet chips tend to support HDLC modes while the latest crop of
> >Serial HDLC chips tend to support Ethernet modes.  As a consequence if
> >SLITHERNET is used for wide area networking while ethernet is used for
> >local area networking, respinning ethernet software for wan uses and
> >respinning ethernet interfaces for wan interfaces is relatively
> >straightforward as well as vice versa.
>
> Yes, and anyone who has an WAN driver for an 82596, I would like to hear from
> (and so would Intel I imagine).  Given the errata, I doubt it would SLITHER !
>
> And also I will quote a Zilog engineer "You're not going to use the USC in Ethernet
> mode ?  (long pause)  Are you?"...  Given the FIFO bugs, (albeit corrected with the
> latest step of the week), I would stick to HDLC on the USC, and Ethernet on the
> 82596.
> --
> Dave Carr               | dcarr@donut.gandalf.ca | If you don't know where
> Gandalf Data Limited    | TEL (613) 723-6500     | you are going, you will
> Nepean, Ontario, Canada | FAX (613) 226-1717     | never get there.
>
[Begin Soapbox]

I agree with Mr. Carr.

It is interesting to note the reactions of people to this new proposal for
a serial protocol.  I think the folks at Clearpoint might want to reconsider
the resources being spend on a product such as this, as opposed to developing
a PPP-based product line, if this reaction is representative of the market.

The comment regarding the overhead of using the async adapters on a work-
station at high-speed is probably justified.  There is at least one vendor
issue.  IMHO, this is a decent approach since it will interoperate with any
other PPP-based product at the other end.  And after all, isn't interoperabilitywhat we are all about?

[End of Soapbox]

----------------------------------------------------------------------
John K. Scoggin, Jr.
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		        (800) 388-7076
500 N. Wakefield Drive			Fax:    (302) 451-5321
Newark, DE  19714-6066	                Email:  scoggin@delmarva.com
----------------------------------------------------------------------


-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 12:11:09 GMT
From:      martinea@HAWK.NSTN.NS.CA (Michael P. Martineau)
To:        comp.protocols.tcp-ip
Subject:   Re: ka9q bootp and POP (was: Re: KA9Q or PcRoute)


while i have some ka9q enthusiasts attention, has anyone got the ka9q POP
server to work with POPmail (PC version)?

From what I remember from looking at this issue several months ago, some
POP servers return comments as part of their response fields.  If I remember
correctly, POPmail does not like these comments (it expects numerics in
the return field and gets confused when it see additional text).  The
POP server can be hacked to remove the comments.

*************************************************************************
* Michael P. Martineau			martinea@hawk.nstn.ns.ca	*
* General Manager			Phone: 468-NSTN			*
* NSTN Inc.				FAXL   468-3679			*
*************************************************************************


-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 12:22:18 GMT
From:      ANGLEY@raleng.mtc.com (Kevin Angley)
To:        comp.protocols.tcp-ip
Subject:   Unsubscribe

Please remove me from the tcp-ip mailing list.

If this is not the appropriate means of getting off the list, a private message
with the correct procedure to angley@raleng.mtc.com would be appreciated.


-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 12:58:17 GMT
From:      marikar@digrev.UUCP (Mo)
To:        comp.protocols.tcp-ip
Subject:   Unsubscribe

Please take me off the mailing list.
Mo Marikar.
Digital Review.


-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 13:24:14 GMT
From:      matthew@ooc.uva.nl (Matthew Lewis)
To:        comp.protocols.tcp-ip
Subject:   Wanted: rarpd with dynamic allocation of IP addresses

Hello!  As the subject says... We have a class-c net and are moving over to
NFS for our PC's.  Since all of the PC's are never used at once, we would
love to be able to allocate a pool of IP addresses to use for them via
rarp.  Has anyone done this yet?  Is there a compelling reason NOT to?

Thanks,

Matthew Lewis
University of Amsterdam

P.S.  If you reply by mail, I'll summarize
--
Matthew Lewis, University of Amsterdam		Grote Bickersstraat 72
+31-20-52 51 220				1013 KS  Amsterdam
Internet: matthew@ooc.uva.nl			The Netherlands


-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 13:57:45 GMT
From:      scoggin@delmarva.delmarva.COM (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   (none)

Subject: Re: Q: Master List of TELNET / FTP programs?
To: nwnetman@u.washington.edu (Jonathan Kochmer)
Date: Mon, 16 Sep 91 9:57:44 EDT
Sender: <tcp-ip-relay@nisc.sri.com>
From: John Scoggin <scoggin@delmarva.delmarva.com>
Cc: tcp-ip@nic.ddn.mil
In-Reply-To: <9109040110.AA24341@milton.u.washington.edu>; from "Jonathan Kochmer" at Sep 4, 91 1:10 am
X-Mailer: ELM [version 2.3 PL11]

>
>
> Has anyone compiled a list of *all* TELNET/FTP programs for *all*
> operating systems?  In the best of all possible worlds, I would like
> a list including the following information:
>
> Jonathan Kochmer
> University Computing Services
> University of Washington
>
> nwnetman@milton.u.washington.edu

There is a TCP/IP Vendor's Guide, which is kept REASONABLY up-to-date.  It
is available via anonymous FTP from nic.ddn.mil as NETINFO:VENDORS-GUIDE.DOC
.211 - they also have it available in paper form for a small fee.
----------------------------------------------------------------------
John K. Scoggin, Jr.
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		        (800) 388-7076
500 N. Wakefield Drive			Fax:    (302) 451-5321
Newark, DE  19714-6066	                Email:  scoggin@delmarva.com
----------------------------------------------------------------------


-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 14:33:10 GMT
From:      ralfi@pemcom.pem-stuttgart.de (Ralf U. Holighaus)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   lpr command for SCO wanted

Hi, netlanders,

I think I once read that someone has ported the lpr command (the lpd
client) to the SCO base? I have a customer who wants to use the Novell
NFS server lpd functionality from his SCO UNIX systems...

Thanks a lot in advance. I'm sorry that I didn't get the source from
the net when it appeared at the first time.

Regards
Ralf.
--
| Ralf U. Holighaus          |                                     PEM GmbH |
| Technical Support Manager  |          Vaihinger Strasse 49, PO-Box 810165 |
|                            |                 W-7000 Stuttgart 80, Germany |
| holighaus@pem-stuttgart.de |    VOICE: x49-711-713045 FAX: x49-711-713047 |


-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 14:58:59 GMT
From:      subra@thor.cc.nd.edu (Kumaraswamy Subramanian)
To:        comp.protocols.tcp-ip
Subject:   Info. wanted on POP2 server implementation

Hello,
I am trying to implement a POP2 server and I have a question on the POP2
protocol. I am following the RFC 918 and the RFC says that whenever a POP2
client requests for the message using "RETR" command the server should send
multiline response(each line terminated with CRLF pair) and should change its
state to wait for an ACKS/ACKD/NACK from the client. The problem I am facing
is when I tested the server with a POP2 client the client hangs up at the
"RETR" state and my logfile for the POP2 server says the message has been
transferred to the client and also has changed its state to receive one of the
acknowledgement(ACKS/ACKD/NACK). The client is not able to recognize the end
of message from the server. It just keeps on waiting thinking that the more
message is yet to come from server.
Is there any way to tell the client the "End of Message" like the POP3 server
which terminates the message with ".CRLF"? or am I missing something here?
(currently I haven't implemented timeouts for client wait time )

-------------------------------------------------------------------------------
email: subra@thor.cc.nd.edu

Kumaraswamy Subramanian
Network Analyst,
Univ. of Notre Dame
Notre Dame IN


-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 14:59:46 GMT
From:      rich@progress.COM (Rich Lenihan)
Subject:   standard services?

I have a question about the contents of the /etc/services file.  We have
a very heterogenous UNIX tcp/ip-based network.  We'd like to be able
to assign local services in the /etc/services file without fear of stomping
on some vendor's implementation of their networking product.

Is there a range of port numbers that are considered to be user-defined?  I
assume that numbers in the lower range would be reserved, but I've come across
numbers in the 6000 range as well.  Also, is there any place (like the NIC)
where these numbers are registered?

Thanks (and apologies if this is a FAQ-type question)

Rich

------------------------------------------------------------------------------
Rich Lenihan                 UUCP: mit-eddie!progress!rich
Progress Software Corp.      Internet: rich@progress.com
5 Oak Park                   >-   Insert funny stuff here  -<
Bedford, MA  01730           >-Draw amusing symbols, logo's-<
USA                          >-     or characters here     -<


-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 16:05:31 GMT
From:      hjones@csi.compuserve.com (Benny Jones)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for TOPS-10?

I'm trying to find a TOPS-10 implementation of TCP/IP.  Can anyone
help me?  Thanks much.

Benny Jones
CompuServe	70003,1153
Internet	hjones@magnus.acs.ohio-state.edu
--
Benny Jones
CompuServe 		70003,1153
Internet		hjones@magnus.acs.ohio-state.edu


-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 16:14:43 GMT
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Router security features

3Com's NETBuilder bridge/router software (ver 3.0 and greater) includes IP
to info@3com.com or call 1-800-NET-3Com (408-764-5000 outside the USA)


-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 16:23:22 GMT
From:      mmm@well.UUCP (Michael Hidalgo)
To:        comp.protocols.tcp-ip
Subject:   Unsubscribe


Please remove me from the mailing list.
Michael Hidalgo


-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 19:25:53 GMT
From:      osmana@well.sf.ca.us (Osman Arslaner)
To:        comp.protocols.tcp-ip
Subject:   SQL Server and TCP/IP


We would like to run our SQL Server (from Microsoft) over TCP/IP
protocols. We have installed TCP/IP from FTP Software on our OS/2
Server and tried to interface to the SQL Server program through
NetBios. We were not able to make it work.

We are told that SQL Server is using Named Pipes and will not interface
to NetBios, but we can interface it directly to TCP/IP using a file
called "sockets.dll".

Has anybody installed SQL Server over TCP/IP yet ? Also where can we get
a copy of this file "sockets.dll" ?

Any help will be appreciated.
Thanks.

Osman Arslaner.
Montreal, QUEBEC.


-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 20:01:24 GMT
From:      warb@faatcrl (Dan Warburton)
To:        comp.protocols.tcp-ip
Subject:   Help with SOW for Internet wanted


I need to write a Statement of Work suitable for use in Government
(FAA) procurement for a 56kbs connection to the Internet. If you have
specifications of this type connection please forward them to me at:

warb@faatcrl.uucp

As you can see we are a UUCP site trying to upgrade to direct connection.
Some Questions I have:

1. How can I charactize the Internet? List the major regional networks I
want to be able to exchange packets with? Indicate which machines I want
to be able to ping?

2. How can I keep from getting a dial up connection? Specify some type of
minimum latency time for connection.

3. What type of Engineering Support Services are available? I am thinking of help with
routing, E-mail, netnews and bridging with-in our networks is what I am thinking.

--
+  Dan Warburton   Nas Simulation Support Facility (NSSF)
+                  Federal Aviation Administration Technical Center
+                  Atlantic City International Airport, NJ 08405    //
+  609-484-4480    Mail Stop: ACN-313        Aikido        Amiga  \X/ Sun
+  warb@faatcrl.uucp  ...rutgers!faatcrl!warb   -- An Open Systems Group --


-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 23:27:13 GMT
From:      cs@Eng.Sun.COM (Carl Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC on SYSVR4


> We have some RPC application that we have ported to SYSVR4 recently. Looking
> at what rpcgen emits this looks pretty different from what I have seen under
> BSD-ish UNIXes (like SunOS). It seems like the RPC library runs directly on
> top of TLI. I wonder wether the source for such a library is publicly
> available (like the socket-based RPC libraries). Any hints ?

We don't make an SVr4 version available (likely we will when Sun ships
an SVr4 system), but the one that we do make available as TIRPCSRC is very,
very close to what we actually use (basically, things have been added to the
SVr4 version in order to get it to run on SunOS 4.1, and that version is made
available as TIRPCSRC).  Appended is the blurb on where to get it.

Carl

Sun's freely licensed implementation of Transport Independent RPC
(TIRPC), is now available as source code via anonymous ftp from
uunet.uu.net in the directory "networking" as the file named
tirpcsrc.tar.Z.  This is a compressed tar file.  This implementation of
TIRPC is compatible with SunOS 4.1 *only*, and requires root
priviledges for installation.

TIRPC is the version of Sun RPC that is part of System V Release 4 (SVR4).
See the "README" file in the distribution, as well as the files in
the doc and man directories, for further information.

To use anonymous FTP, use the ftp program to connect to uunet.uu.net.
When prompted for a user name, enter "anonymous".  When prompted for
change directories (cd) to the "networking" directory, where you will find
tirpcsrc.tar.Z.


-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 23:46:09 GMT
From:      peterr@syacus.acus.oz.au (Peter Russell)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,acus.general,comp.protocols.ibm
Subject:   Re: TELNET & 3270 (tnv3270?) - Request For Information


I think you use the telnet/3270 type thing in a PC when you have a 3274
type controller that has the ethernet support installed.  I think 3274's
of the right model and upgrade will do all of straight coax, token ring or
ethernet.

Peterr


-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 00:35:41 GMT
From:      pmanglik@tanj.intel.com (Pankaj Manglik)
To:        comp.protocols.tcp-ip
Subject:   unsubscribe


Please take me off the maiiling list.

Pankaj


-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 06:35:20 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   cisco router performance (was selecting a fast ethernet card).

A rather curious set of circumstances has caused a message requesting info
on high performance ethernet controllers of PCs to lead to some speculation
on how a cisco might operate,a ndhow fast it really is.  I thought I should
step in with real (inside) data in that area.  So....

Piercarlo Grandi says:

dave@pmafire.inel.gov (Dave Remien) writes: [I think]

> Ours forwards at about 15000 packets per second, and routes at about
> 2000 packet/sec. The newer ones are supposed to about double that.

First comment:  The cisco forwards (used to) 15k routed IP packets per second
under some set of moderately ideal conditions ("fast switching" within the
same interface complex.)  15K is an old number - the ideal case is several
times that now.  The "2000 packets/sec" number is for pessimal cases (eg
output interface is less intelligent").  What the number actually means is
that the cisco can make 15k routing decisions in a second, and that the
best case end-of-input packet to start of output packet time is 66.7 uS.

> Lessee ---- 15000 * 1500 = 22.5MBytes/sec, a tad faster than Ethernet
> will go.

25 times the bandwidth of a single Ethernet. Impressive! CISCO must be
very generous to give customers so much extra capacity, as their
routers rarely connect more than 2-3 Ethernet segments, and they
overdesign their products to handle ten times the maximum load on
their average configuration.

We're not so generous - we charge a lot of money.  And I suspect that
the "average" cisco router is larger that 2-3 ethernets (maximum
capacity is something like 28 ethernets.  Many protocols are sensitive
to delay, so shipping a packet out as quickly as possible is a good idea.
Finally, ciscos support interfaces like FDDI and T3 that go much faster
than ethernet, and the architecture has to support those too.

> Even routing implies (assuming max size legitimate packets) 3MBytes/sec.

Here I detect the possibly improbable assumption that it can forward
or route maximal size packets at the maximum rate, which seems
incredibly optimistic, because 22MB/s aggregate bandwidth is a really
stunning figure, being able to forward packets between 25 Ethernets at
full tilt.

If it really can route 22MB/s then whatever processor card is inside a
CISCO router must have a bus that is at least four times as fast as an
ISA bus, nearly as fast as an EISA bus, and it must have a
diabolically fast memory subsystem.

22MB/s cannot be achieved by most :-) 386 memory subsystems for pure
string copies.  Try copying a 1KB string from one buffer to another
for a few thousand times and then calculate the memory bandwidth.
:
: code to time bcopy deleted
:

I'd be truly amazed if the CISCO router could handle 22.5MB aggregate
bandwidth, even if just for forwarding, unless it has inside a processor
memory combination substantially faster than a 5830, or it has a
wormhole chip. Somehow I think both hypothesises are somewhat improbable.

Well, no wormhole chip.  But under optimal conditions, the aggregate
throughput of a cisco is much faster than 22.5MB.  The memory system consists
of a bunch of very fast static RAM shared between the interfaces of each
interface complex.  The "processor" consists of one or more custom micro
coded bit-slice processors and a 30Mhz 68020 which may or may not be involved.
The packets are not copied at all, which helps a lot - a packet comes in,
we check it, route it, and get it sent out some other interface.  This takes
about 67 uS (to get 15kpps).

> I suspect that the quoted Cisco rates are for minimum (50
> byte) or fairly small packets, netting somewhere in the neighborhood of
> 100KBytes/sec.

I suspect that too, so that at 15k packets/s we'd get about 0.8MB/s for
forwarding. Looks more like it. CISCO may not have gotten a Shannon
dispensation after all.

Nope.  Since the data isn't copied, the forwarding rate is independent
of the packet size.  Obviously, we can't ship out packets faster than
they can be sent on the destination interface.  But other packets might
have to go to other interfaces.  Now, I've mentioned "interface complex"
a couple of times.  In somewhat older ciscos, an interface complex is
one to four network interfaces on a single card.  Copying data to a
different card is (of course) somewhat slower.  In current ciscos, the
interface complex is one two four boards (each with up to six interfaces)
on the 'cBus', a 533 Mbit/s bus, which expands the scope of high speed.

---------------------

Sender: <tcp-ip-relay@nisc.sri.com>
From: aria!dumbcat!marc@uunet.uu.net  (Marco S Hyman)

Stop right there!  15000 packets/second is (approx) the Ethernet
maximum.  For those who want the math:

Minimum frame length = 64 bits of preamble		64 bits
6 octet destination address	48 bits
6 octet source address		48 bits
2 octet type			16 bits
46 octet data		       368 bits
4 octet FCS			32 bits
-----------------
576 bits

The time to transmit this frame at 10 Mbit/s is 57.6 usec.  Add to that
the minimal interframe spacing of 9.6 usec and you can spit a frame out
every 67.2 usec or 14880 (almost 14881) frames per second -- assuming
one station is doing all the transmitting.

Exactly correct.  The theorectical max doesn't change with multiple stations,
but you are more likely to have collisions which will interfere somewhat.
Still, studies (Boggs @ DEC) have shown that even with 20 stations trying
to transmit simultaneously, the usable badnwidth ofan ethernet is still
close to 10 Mbit/s.

cisco playes the specsmanship game of being able to handle this
theoretical maximum.  They are not the only ones who try to play this
game.  (Note that when playing this game the payload maximum is 14880
pps * 46 bytes/p = 684480 bytes/second.  That's a lot of work for a bit
more that 1/2 Mbyte/s.)

It's a game if you have a two port ethernet only box.  As described above, the
actual numbers get more interesting when you have more or faster interfaces.

Using the maximum ethernet frame length the numbers look like 1220.8
usec per frame.  When adding the 9.6 usec interframe spacing requirement
the maximum frames/second (large frames) is 812 frames/second.  The
payload in this case increases to 1.218 Mbytes/s.  Typical networking --
the best throughput occurs when the processor is doing the least amount
of work :-)

This can't be argued with either.  If you're trying to get the maximum
performance out of your tcp, and it isn't sending full sized network
datagrams, that is certainly the first thing to fix.

To get back to the original question, on high throughput for PC Unix:
Van Jacobson has done a convincing proof that TCP can go over 6Mbit/sec.
(He tuned the TCP on a SUN 3/60, and got repeatable TCP data transfer
rates consistantly close to 9Mbit/sec.  A sun 3/60 is not a blazingly fast
machine, though it does have a shared memory ethernet controller.)
There were some interesting results:

1) checksumming does NOT matter.  The limiting factor is usually the
memory cycle time of the processor memory.  Given a modern CPU
with some form of instruction cache, the checksum can be folded
into a data copy at zero cost.

2) The ethernet controller CHIP DOES matter.  Going this fast means
that the wire will be full of data almost all of the time, and
collisions WILL occur between the systems sending data and the
ACKs the receiver has to send back.  If the chip cannot reset
its packet pointers and whatnot quickly in the event of a collision,
it won't go as fast (This was the suspected reason that Intel's
82586 ethernet controller had a lower peak performance than the
AMD Lance chip used in the 3/60).

3) The hardware matters.  The 68k in the 3/60 was idle about 30% of
the time in 3/60.  Why wasn't it less idle and going faster?
Well, because the Lance couldn't make use of the full bandwidth
of the memory - It takes an eternity (600 nS) to do a single
16 bit memory transfer, and during that time, the 68k couldn't
access the memory either, so it sat idle.  This goes to show that
a bus is only as fast at the device driving it.  So EISA bus has
a bandwitdh of XXX Mbyte/sec - can your I/O device, DMA controller,
or CPU actually deliver or eat data that fast?

Can a PC do 6Mbit/sec?  I doubt it.  Pre-Jacobson TCPs tend to go about
1Mbit/sec, and I don't think that anyone has made significant efforts to
incorporate the new theory into PC implementation.

Bill Westfield
cisco Systems.
-------


-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 07:30:50 GMT
From:      bersee@nikhef.nl (Josefien Bersee)
To:        comp.protocols.tcp-ip
Subject:   announcement 3rd JENC


ANNOUNCEMENT AND CALL FOR PAPERS
--------------------------------

3rd Joint European Networking Conference

****************************************
Building Research Networking for Europe
****************************************

Innsbruck, Austria, May 12-15, 1992

Organized by RARE (Reseaux Associes pour la Recherche Europeenne)
in cooperation with:

o ACM SIGCOMM     o ACOnet        o EARN
o EurOpen         o Internet Society

GOALS

This conference aims at informing the participants about the state of
the art in networking and about building new and better network
services. It will provide a forum for the presentation and discussion
of technical and strategic topics related to the provision of
networking services for research and higher education, as well as
corresponding research and development activities. As a result parti-
cipants will get understanding of the issues in European Networking.

The conference addresses technical, managerial and end-user support
staff from local, national and international service providers as well
as application developers, policy makers and representatives of
funding bodies, advanced user groups and standards organizations.

Much emphasis will be placed on cooperation between networking
services. The conference will continue and enhance the discussion
between members of different networking communities, building on the
positive experiences of the earlier Killarney and Blois Conferences.
This conference is THE forum on networking in Europe and presents a
unique opportunity to meet key people active in networking today.

CONFERENCE VENUE

The city of Innsbruck is situated in the middle of Tirol, one of the
most famous holiday areas in Austria.  Innsbruck offers history and
traditions as well as an up-to-date infrastructure.  The conference
will take place in the Innsbruck Convention Centre - Kongresshaus
Innsbruck - a spacious centre of high international standard.

FIRST INVITATION AND PRELIMINARY PROGRAMME

A first invitation and preliminary programme, including information on
the RARE Secretariat if you want to make sure you receive the
invitation.

CALL FOR PAPERS

As for the past Joint Networking Conferences, the programme will
include a combination of solicited and submitted papers.
Presentations taking 20, 30 or 45 minutes are invited.  One-page
summaries of proposed papers should arrive at the programme chair not
later than November 17, mentioning the topic against which the author
would like his paper assessed and the expected length of the
conference presentation.  It is again intended to publish proceedings
of the conference in "Computer Networks and ISDN Systems".  Full
papers must be provided by the start of the conference at the latest.

Topics for submitted papers should be related to the major headings
of the general outline of the conference given below:

1 Users, User Support & Group Communications

User Support
User View of European Networked Resources - User Requirement
Impact of Networking
Teleconferencing
Videoconferencing

2 Infrastructure: Coordination & Management

Multiprotocol Backbone Infrastructure
Network Management
Operational & Interworking
Quality of Service - Concepts, Performance, Measurement
Security Implementation and Operation
Services Management
Gateways

3 Coordination of Applications & Services/Projects

Access Control and Authentication
Directory Services
Distributed Computing
Distributed Services Management
Documentation Format, eg. ODA
File Servers
Information Services (Library etc.)
Message Handling Systems (MHS)
High Performance Computing
Visualisation

4 Technology

New Technology (ATM, Frame Relay)
Products
Security Techniques

5 Policy, Funding & Futures

Economic Impact of Networking
Electronic Publishing & Intellectual Property Rights
International Export - Legal Restrictions
Is there life after COSINE?
Security Policy

6 International Success Stories - Advanced Uses/Users

Collaborative Research
Distance Learning

7 Status reports of national initiatives and European projects

COSINE
Country Reports
RARE Working Groups
Standards
EARN / EurOpen / RIPE

CALL FOR POSTERS AND DEMONSTRATIONS

As in previous years, a poster wall will be available for the display
of posters.  Participants are invited to submit a poster presentation
of the project they work on or a topic of common interest to the
conference participants. The programme committee will select the two
best posters during the conference for inclusion in the conference
proceedings.

During the conference there will be the opportunity for participants
to present their project or activities in the form of a demonstration,
either as part of their presentation or separately.  Requests for
demonstrations should be made through the RARE Secretariat, specifying
technical requirements.  X.25 and IP connectivity will be provided.

FURTHER INFORMATION

For further information contact :

RARE Secretariat                        Programme chair :
P.O. Box 41882                          Christian Michau
NL-1009 DB AMSTERDAM

tel +31 20 592 5078                     tel +33 1 44274260
fax +31 20 592 5043                     fax +33 1 44274261
email raresec@nikhef.nl                 email michau@frors12.bitnet
O=nikhef; S=raresec

Progamme committee :
Christian Michau, Vint Cerf, Howard Davies, Marieke Dekker, Jill
Foster, Frode Greisen, Krzysztof Heller, Dennis Jennings, Barry
Leiner, Manfred Paul, Paul-Andre Pays, Paul Van Binst


-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 14:50:51 GMT
From:      plcochet@nysnet.nys.GOV (Peter L. Cochetti)
To:        comp.protocols.tcp-ip
Subject:   Wollongong/ATT 3B2 TCP/IP SLIP Packet Driver


I am trying to connect my ATT 3B2-1000 to internet using SLIP, but the ATT/
Wollongong tcp-ip doesn't have the driver. Does anyone know where I can get it?


-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 14:52:41 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: SND.WL1/SND.WL2 confusion

In article <1991Sep16.025334.1409@m.cs.uiuc.edu> zweig@cs.uiuc.edu writes:
>I am tracking down a bug in my implementation of TCP, which I wrote with RFC
>793 open on my lap.  There is some garbled nonsense (at least it looks like
>nonsense to me; I don't know if I'm being stupid or Postel was smoking
>something on page 72) about only updating the send window when SND.WL1 !=
>SEG.SEQ or SND.WL2 != SEG.ACK which is designed to keep you from updating your
>send window on the basis of out of date (retransmitted) ACKs.

That isn't what it says, it says (SND.WL1 < SEG.SEQ  .OR.
(SND.WL1 = SEG.SEQ .AND. SND.WL2 =< SEG.ACK)), which is not what you say
above.  In particular,  SND.WL1 = SND.SEQ .AND. SND.WL2 = SEG.ACK
is permitted.  Assuming that you actually implemented the test
the RFC describes, and just muffed it when describing it in your posting,
this should not be causing your difficulties.

On the other hand, just before the WL1/WL2 stuff on page 72 is the text:

If SND.UNA < SEG.ACK =< SND.NXT, the send window should be
updated.

This is a typo that was corrected in RFC1122, page 94, where it
says:
...	the window should be updated if: SND.UNA =< SEG.ACK =< SND.NXT

If you implemented this test according to the original text, it will
cause the problem you describe.  1122 corrects a number of typos in
the original documents; you should have a copy of it open on your
desk beside the copy of 793 that you're working from!
--
Brian Thomson,	    CSRI Univ. of Toronto
utcsri!uthub!thomson, thomson@hub.toronto.edu


-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 15:54:52 GMT
From:      ort@frenulum.eng.ufl.edu (Randy Thomas)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.unix.xenix.misc,comp.unix.xenix.sco
Subject:   HLS 6130 Support under SCO UNIX

I am trying to find out how easily I can use a Hughes LAN Systems 6130
broadband NIC under SCO's UNIX.  Neither HLS nor SCO have been very helpful
and documentation.  HLS told me that the 6130 card was supported under
XENIX ONLY!  However, SCO claims no support for the card under XENIX nor
UNIX.  Am I missing the boat here.  Is it possible that SCO's support for
another card might work for the HLS 6130.  Any help would be greatly
appreciated.

Thank you,

--
Randy Thomas
ort@wasp.eng.ufl.edu
Computer & Information Engineering Sciences
University of Florida


-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 16:07:17 GMT
From:      black@beno.CSS.GOV (Mike Black)
To:        comp.protocols.tcp-ip
Subject:   Why can't my clients talk to another subnet?

I have read as much material as is on the net and have succeeded
(somewhat) in implementing subnetting on our buildings Sun workstations.
Here's an example of our setup:

22.19.4.1 (255.255.255.0) --------  22.19.6.1 (255.255.255.0)
|                                   |
Host1                               Host2
|
192.9.201.1 (255.255.255.0)
|
192.9.201.2 Client1
192.9.201.3 Client2

The Clients here cannot ping,ftp, or telnet to Host2.  Host2 also
cannot ping,ftp, or telnet to the clients.  Note that a route has
On Host1: route add net 22.19.6.0 Host1 0
On Host2: route add net 22.19.4.0 Host2 0

The two hosts can talk to each other fine, but not the clients.  Can
someone enlighten me?
Thanx...Mike...

--
-------------------------------------------------------------------------------
: usenet: black@beno.CSS.GOV   :  land line: 407-494-5853  : I want a computer:
: real home: Melbourne, FL     :  home line: 407-242-8619  : that does it all!:
-------------------------------------------------------------------------------


-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 19:26:23 GMT
From:      edhall@rand.org (Ed Hall)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

In article <10930@jjmhome.UUCP> martillo@jjmhome.UUCP (Joachim Martillo) writes:
>Of course, a better way to view the issue is to note that
>the promulgation of PPP is based on a fundamentally silly idea that a single
>protocol can solve all problems for all times on very diverse media over
>a very wide range of speeds.

Of course, the exact same charge has been leveled at TCP/IP itself.  I
regard both charges as having the same merit....

-Ed Hall
edhall@rand.org


-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 21:29:40 GMT
From:      martillo@AZEA.CLEARPOINT.COM (Joachim Carlo Santos Martillo)
To:        comp.protocols.tcp-ip
Subject:   SLITHERNET versus PPP discussion

I received a recommendation that this discussion be moved from usenet
to the mailing lists.  Articles are separated by ='s.  Newly added

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

Sender: <tcp-ip-relay@nisc.sri.com>
From: brian@telebit.com (Brian Lloyd)
Newsgroups: comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)
Message-ID: <1991Sep11.202249.24555@telebit.com>
Date: 11 Sep 91 20:22:49 GMT

"SLITHERNET") with some interest.  What I have yet to understand is
how SLITHERNET is better than PPP (especially since there are so many
PPP implementations now and I have never seen a SLITHERNET
implementation).

*I showed SLITHERNET in Washington in January.  SLITHERNET may not be
*the best way to handle serial links, but PPP is truly backwards.  And
*you are right, if you only compare a single point to point link there
*is no real difference.  But suppose 10 sites are to be interconnected
*probably a better idea than interconnecting Suns or other routers even
*if serial point-to-point semantics are used between routers.  If the
*number of sites to be connected by wide-area links grows, a complex mesh
*of interconnected packet switches (a communications subnet) might be
*required.  In such a case another level of addressing is required
*because it is undesireable to route packets through the communications
*subnet on the basis of IP address.  Now you can get the necessary
*second level of addressing by using the PPP bridging encapsulation.
*Of course, since bridging PPP includes the whole MAC packet which
*include a type or LSAP/DSAP pair, there is no reason to use
*network level PPP at all. Unfortunately the bridging PPP
*specification is totally brain-dead in that there is a
*variable number of bytes in front of the MAC addresses.  Because of
*this goop, implementing PPP in a WAN-LAN remote transparent bridge
*is quite painful.

*The question remains how to route packets within
*the communications subnet.  SLITHERNET allows the direct application
*of 802.1d MAC bridging. Again the bridging PPP specification can be
*used but the specification has added yet another level of brain-death
*by not including the MAC addresses with the 802.1d BPDUs.

*In fact, STP may not be the best way to route packets in a wide-area
*communications subnet, but with the extra level of addressing, another
*logical MAC address could be used in the implementation of another
*routing scheme which could be retrofitted later.

As for regionals forcing people to buy a particular vendor's router to
connect to the regional network; that is falling by the wayside.
There are many people who are buying Telebit NetBlazers and running
dedicated sync PPP links to Alternet's cisco routers (that is how we
talk to Alternet here).  Also most of the other IP router vendors are
offering PPP so they can interoperate on point-to-point links too.
The requirement for PPP is becoming part of the router requirements
doc as well.  Why muddy the water with another nonstandard?

*The mere definition of a protocol in an RFC hardly means that it
*is either useful, reasonable or much of a standard.  Who
*uses RDP for anything?

*PPP evinces no evidence of the application of any modern ideas of
*protocol design and in fact violates most principles of good protocol
*design.  PPP is misdesigned for any sort of sophisticated use of a mesh
*of wide-area links.  PPP contains ridiculous cruft in the terms of
*silly FSA's.  PPP is misdesigned relative to trends in capabilities
*provided by the latest crop of LAN or DTE/DCE serial interface chips.
*This silly piece of garbage should be given a swift burial.

--
Brian Lloyd, WB6RQN         Telebit Corporation        The views expressed
Network Systems Architect   1315 Chesapeake Terrace    herein are my own and
brian@telebit.com           Sunnyvale, CA 94089-1100   are not necessarily
voice (408) 745-3103        FAX (408) 734-3333         my employer's.

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

Sender: <tcp-ip-relay@nisc.sri.com>
From: brian@telebit.com (Brian Lloyd)
Newsgroups: comp.protocols.ppp,comp.protocols.tcp-ip,comp.dcom.lans
Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)
Message-ID: <1991Sep12.173635.5447@telebit.com>
Date: 12 Sep 91 17:36:35 GMT

martillo@jjmhome.UUCP (Joachim Martillo) writes:

>Of course, a better way to view the issue is to note that
>the promulgation of PPP is based on a fundamentally silly idea that a single
>protocol can solve all problems for all times on very diverse media over
>a very wide range of speeds.  Further, even if we accept this ridiculous
>premise, PPP is fundamentatlly misdesigned with all sorts of goop built
>into the protocol which simply doesn't belong there, ridiculous FSA's and
>one of the most moronic methods of tunneling which I have ever perused.

>Somehow promulgating attrocities like PPP looks more motivated by a hidden
>agenda to guarantee job security than suggesting a reasonable alternative.

>Joachim Carlo Santos Martillo Ajami

You are right, PPP is a bit more complex than it needs to be (FSM,
etc.).  On the other hand, it works and works very well for most
point-to-point circuits over which people transmit the datagrams of
unreliable networks.  There are methods for transferring IP,
Appletalk, CLNP, IPX, and DECnet.  It supports communications between
MAC layer bridges.  It has the support of many people, users and
vendors alike.  There exist many interoperable implementations.  It is
going to be a router requirement.  You are swimming against the tide.

Hey, c'mon now.  There are things that I would like to see done
differently in various protocols in the Internet Protocol Suite.  That
doesn't mean that I reject and spurn IP just because I think that I
can do it better.  Perhaps PPP would have been more to your liking had
you participated in the design, specification, and implementation
process.  I guarantee you that everyone who has done an implementation
has generated input that has helped extend PPP and make it more
useful.

One last point: I have used PPP on everything from a 1200 bps async
dial-up link to a dedicated T1 link and it works very well in all the
cases that I have encountered (real-world that is with real modems,
DSU/CSUs, and telco-supplied links).  The proof of the pudding is in
the tasting, don't you think?

*I would have to do some analysis of link utilization and cpu
*overhead.  The Sun uses an 8530 which has lots of associated
*overhead.  The trend in ethernet chip design seems to be to give
*them an HDLC mode.  Thus to a Sun a WAN card and an ethernet card
*which represents much less cpu overhead than an 8530
*could look identical.  And to the hardware designer converting an
*ethercard to a WAN card might be minor quickly made changes.
*There are lots of economies which could be obtained and which
*might be passed on to the customer if SLITHERNET is used.
*PPP, being totally brain-dead, of course makes such economies
*impossible.

--
Brian Lloyd, WB6RQN         Telebit Corporation        The views expressed
Network Systems Architect   1315 Chesapeake Terrace    herein are my own and
brian@telebit.com           Sunnyvale, CA 94089-1100   are not necessarily
voice (408) 745-3103        FAX (408) 734-3333         my employer's.

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

Path: cpoint!crackers!jjmhome!martillo
Sender: <tcp-ip-relay@nisc.sri.com>
From: martillo@jjmhome.UUCP (Joachim Martillo)
Newsgroups: comp.protocols.ppp,comp.protocols.tcp-ip
Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)
Message-ID: <10930@jjmhome.UUCP>
Date: 11 Sep 91 22:59:39 GMT
References: <169385@pyramid.pyramid.com>

In article <169385@pyramid.pyramid.com>, lstowell@pyrnova.pyramid.com (Lon Stowell) writes:
> In article <1991Sep4.171840.29088@telebit.com> brian@telebit.com (Brian Lloyd) writes:

> >Ah yes, Yet Another Serial Protocol (YASP).  Pretty soon its going to
> >be like IBM in the 60's and early 70's when they had about 100
> >different variations of bisync, all mutually incompatible.

>    Think of it as job security Brian.  And remember what
>    happened to IBM when their "future site" model resulted in
>    SNA with 7 incompatible LU types....all they did was move the
>    incompatibility above the link layer...

Of course, a better way to view the issue is to note that the
promulgation of PPP is based on a fundamentally silly idea that a
single protocol can solve all problems for all times on very diverse
media over a very wide range of speeds.  Further, even if we accept
this ridiculous premise, PPP is fundamentatlly misdesigned with all
sorts of goop built into the protocol which simply doesn't belong
there, ridiculous FSA's and one of the most moronic methods of
tunneling which I have ever perused.

Somehow promulgating attrocities like PPP looks more motivated by a
hidden agenda to guarantee job security than suggesting a reasonable
alternative.

Joachim Carlo Santos Martillo Ajami

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

Sender: <tcp-ip-relay@nisc.sri.com>
From: martillo@cpoint.clearpoint.com (Joachim Carlo Santos Martillo)
Newsgroups: comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)
Message-ID: <14496@cpoint.clearpoint.com>
Date: 10 Sep 91 14:04:53 GMT
References: <2429@crackers.clearpoint.com> <KARL.91Sep1171232@remora.MorningStar.Com> <14455@cpoint.clearpoint.com>
Organization: Clearpoint Research Corp., Hopkinton MA

In article <14455@cpoint.clearpoint.com> martillo@cpoint.clearpoint.com (Joachim Carlo Santos Martillo) writes:

>1) You have to turn on UDP checksumming if you connect two ethernets
>by a bridge rather than a router.

This should say:

You don't have to turn on UDP checksumming if you connect two ethernets
by a bridge rather than a router.

Joachim Carlo Santos Martillo Ajami

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

Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)
To: samsung!crackers!martillo@zaphod.mps.ohio-state.edu (Martillo)
Date: Fri, 13 Sep 91 7:40:42 EDT
Sender: <tcp-ip-relay@nisc.sri.com>
From: John Scoggin <scoggin@delmarva.delmarva.com>
Cc: tcp-ip@nic.ddn.mil
In-Reply-To: <2424@crackers.clearpoint.com>; from "Martillo" at Aug 31, 91 2:31 am

> The following memorandum is a first draft of one of a pair of potential
> RFCs which specify a methodology for using wide-area serial synchronous
> DCE/DTE-type point-to-point links as a computer networking medium.  The
> Clearpoint Little Dipper/Auriga product line offer as one of several
> configurable options a wide-area interface which implements this
> specification, and should a developer implement this interface for his
> bridge, router or end host, that network device will be able to
> communicate with the Little Dipper/Auriga products over point-to-point

If this is a "potential RFC", why isn't it being handled as an Internet
Draft?

*Because I wanted to get some input from the internet community.

Also, maybe you should change the name (to be consistent with the
networking community's love of acronyms) to YAPPP - Yet Another Point-to-
Point Protocol.

*Because I don't like acronyms.

Seriously, if PPP is deficient, shouldn't we create a Working Group to
revisit point-to-point protocols in general?

*Because that seems like a great way to get nothing done or produce
*an attrocity like PPP.  I doubt ethernet or IP for that matter
*would have be produced or would have been so useful and easy to
*apply if they had been designed by committee.

I don't really think the
RFC process was created for the purpose of "legitimizing" proprietary
protocols.

*This question is orthogonal to the issue.  I proposed SLITHERNET because
*PPP is deficient in major ways.  Most of my company's business is not
*among the internet community.  And I could make a good argument
*that perhaps the ability to provide an almost shrink-wrap packet
*data network is a competitive advantage for our products, but we
*decided to be good network citizens.

A lot of companies are starting to point to RFC xyz and saying
that their product meets an RFC; nevermind that the IETF lists the protocol
and that RFC as Experimental or Not Recommended...

*Sounds like the description which should be applied to PPP.

----------------------------------------------------------------------
John K. Scoggin, Jr.
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		        (800) 388-7076
500 N. Wakefield Drive			Fax:    (302) 451-5321
Newark, DE  19714-6066	                Email:  scoggin@delmarva.com
----------------------------------------------------------------------

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

Newsgroups: comp.protocols.ppp,comp.protocols.tcp-ip,comp.dcom.lans
Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)
Message-Id: <16876@zephyr.ens.tek.com>
Date: 12 Sep 91 19:39:42 GMT
References: <169385@pyramid.pyramid.com> <10930@jjmhome.UUCP>
Followup-To: comp.protocols.ppp
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 25
Status: RO

In article <10930@jjmhome.UUCP> martillo@jjmhome.UUCP (Joachim Martillo) writes:

>Of course, a better way to view the issue is to note that
>the promulgation of PPP is based on a fundamentally silly idea that a single
>protocol can solve all problems for all times on very diverse media over
>a very wide range of speeds.  Further, even if we accept this ridiculous
>premise, PPP is fundamentatlly misdesigned with all sorts of goop built
>into the protocol which simply doesn't belong there, ridiculous FSA's and
>one of the most moronic methods of tunneling which I have ever perused.

>Somehow promulgating attrocities like PPP looks more motivated by a hidden
>agenda to guarantee job security than suggesting a reasonable alternative.
>
>Joachim Carlo Santos Martillo Ajami

I, as a customer, want to have routers/whatevers from different
vendors be able to talk to each other & route/whatever various
protocol-type packets.  To achieve this 'multiple vendor choice'
scenario, I want a 'standard' protocol to do this, and perform
'adequately'. It doesn't have to be perfect.  Few things are,
especially when designed by committee. I believe many other customers
feel this way.

*Unfortunately, PPP is very brain-dead and hinders any sort of
*sophisticated wide-area networking techniques.  Now maybe Tecktronix
*will never do any sort of sophisticated wide-area networking, but
*I would not count on such a possibility.

If PPP does this, most customers will forgive it's flaws.
And I believe they will view most criticisms at this point as

'Too little, too late'.  That's life.

*If you like PPP, go ahead and stick to it.  We do support it
*even though it hinders sophisticated wide-area networking and
*is basically a low-performance protocol.  You will pay for it later.

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

Sender: <tcp-ip-relay@nisc.sri.com>
From: Joachim Carlo Santos Martillo <martillo@azea.clearpoint.com>
Message-Id: <9109092005.AA03696@azea.clearpoint.com>
Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking
To: Art Berggreen <iplpdn-request@nri.reston.va.us>
Date: Mon, 9 Sep 91 16:05:55 EDT
Cc: iplpdn@nri.reston.va.us
In-Reply-To: <9109031614.AA29828@opal.acc.com>; from "Art Berggreen" at Sep 3, 91 9:14 am
X-Mailer: ELM [version 2.2 PL14]
Status: RO

>  Just a quick question about the Serial Line Ethernet proposals.

>  What mechanisms are being pursued to guarantee WAN like loss rates?
^^^
I assume you mean LAN.

The Little Dipper/Auriga products keep track of error rates in terms
of proportion of bad packets detected over unit intervals and can put
an interface in the disconnected state if the error rate becomes too
large.  These products also detect anomalous line conditions and will
turn the interface off entirely in some cases.

The Little Dipper/Aurigas can run a short packet protocol where the
hdlc drivers at both ends of the interface communicate with each
other, set parameter and do tests and develop some statistices.

This short packet protocol is logically out-of-band, and should it be
standardized for interoperability.  But it should probably be put into
a separate specification since this short packet protocol really
Slithernet and Slide.

There is an even more important reason to keep this sort of link
statistics and testing protocol separate from the main transport
protocol.  While the actual transport specification is unlikely to
change from one serial point-to-point medium to the next, the method
of determining link reliability is likely to change from one type of
serial point-to-point medium to next or may even change with time on a
specific serial point-to-point medium as equipment changes or
improves.

In the past, some of T1 ESF hype suggested that reliability
information might be available on a separate 16 kbps management
channel.  If such information were available on a separate channel,
there would be little reason to require testing and diagnostics to be
built right into the specification of Slithernet or Slide, and in fact
there would be no need for an "out of band" short packet reliability
protocol.  By leaving this protocol to be defined later, I am
purposefully making clear that this protocol should be optional and
may in fact in some cases be irrelevant.

The incorporation of link diagnostics and statistics into PPP is an
implies an assumption that the designer at the instant of design knew
what is appropriate for all serial point-to-point technologies for all
time and therefore the designer believed it was reasonable for him to
simultaneously solve the transport, diagnostics, statistics and
reliability problem in a big mish-mash rather than reasonably
partitioning the problem.

A reasonable way to handle link diagnostics and testing with
Slithernet would be to allocate a logical mac address for this purpose
and have a diagnostic and test application listening at this address
or connecting to its peer at the other end of the point-to-point link.
Such an application could perform a full suite of tests to obtain much
more useful information than the short packet protocol could provide
or the built-in PPP functionality could provide.  Of course, since PPP
does not have a reasonable addressing mechanism, PPP could not host
such applications.

Even such diagnostic and testing peers might not be sufficient to
choose an appropriate communications path.  Slithernet provides an
architecture for a communication subnet consisting of a mesh of serial
point-to-point links connected by mac bridges (PSNs).  In travelling
from source host to destination host, a packet might transverse
several links and bridges.  Even though the link from the source host
to the first mac bridge might have a sufficiently good error rate (and
maybe all the links in the path as well), the cumulative error over
all links in the path might not be acceptable.

For situations like this, mechanisms like higher level management
protocols might be helpful in determing the best paths, but as of now
providing good transport with reasonable reliability is still an area
of on-going research and development.  Because these are still areas
of on-going research and development, the field of computer networking
is reasonably interesting.  But because a lot of research and
development is still required, the built-in features of a protocol
like PPP for link diagnostics and statistics only provide the warm and
fuzzies for the customer and a sinecure for an engineer, but on the
whole, the approach to protocol design used in PPP is fairly miserable
and the diagnostic and statistics features of the protocol have the
perfect analogy in the snake oil which one might have purchased from a
patent medicine salesman at the turn of the century.

>  1) Don't bother, and live with serial channel error rates.
>  2) Run an error rate monitoring protocol and stop using bad links.
>  3) Run a full error detecting/correcting protocol like LAPB.
>  4) Something else.

>  Art

Joachim Carlo Santos Martillo Ajami

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

Sender: <tcp-ip-relay@nisc.sri.com>
From: martillo (Joachim Carlo Santos Martillo)
Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)
Date: Mon, 9 Sep 91 13:52:54 EDT
Cc: martillo (Joachim Carlo Santos Martillo)

> > point-to-point links to provide a communications subnet for a
> > subnetwork to which many hosts can be attached.  To these hosts
> > slithernet looks like an ethernet, and therefore all the standard
> > software can be run in the standard configuration.

> But using something like a Telebit Trailblazer you get the same
> advantage.  I'm still at a loss for where Slithernet gives the
> user capability he doesn't already have with PPP and a router.

A trail-blazer, a link running PPP and a router gives you simply a
point to point link.  Slithernet allows you to take a set of
serial-point-point links, a set of bridges (to act as PSNs) and build
yourself a shrink-wrap communications subnet for a wide area network.
This communications subnet can provide high availability and fault
tolerance and alternate routing in a way which is transparent to the
devices which are connected.

Now in a sense IP routers are second order PSNs in that they route
between networks which might correspond to wide area communications
subnets, but designing a wide-area network which has more than a
trivial number of point-to-point links is sort of a cludge and rather
costly.  Also, there are a lot better things for which SUN cpu cycles
might be used than for taking lots of character interrupts and
building data packets from the received characters.

The slithernet wide-area network can transport anything which can be
put in an ethernet packet and can support broadcast functionality like
ARP.  Rather than treating the serial interface as some special
non-broadcast medium as must be done with PPP, the slithernet
interface appears to IP more or less as a standard ethernet interface
albeit a slow one (but not much different than some of the versions of
cheapernet which AT&T has marketed in the past).

> > Many ethernet chips have an hdlc mode which expects etherformat
> > packet.  Slithernet takes advantage of this technology.  And in fact
> > for many hardware companies (like Clearpoint) respinning and ether
> > card as a WAN card would be trivial except that the newer
> > sophisticated ether chips are incompatible with PPP.  Actually, the
> > newer serial chips are gaining ethernet modes which cannot be
> > efficiently used with PPP.

> What are the implications of this for the user?  Are you saying that
> this eliminates the need for a full-blown router and that something
> that is more bridge-like could take its place?

Just as you can use bridges or routers with ethernet depending on your
needs, you can use bridges or routers with slithernet.

But if the serial chip has an interface to the host processor which
looks like the interface to a common ethernet chip, or if in fact
common ethernet chips can be programmed to do hdlc bit stuffing,
software development is a lot cheaper if the changing one or two lines
of the initialization code of the ethernet driver is sufficient to
turn the ethernet driver into a serial hdlc driver.  If software
development become cheaper, eventually the lower costs might be passed
along to the customer especially because the bridge/router market is
rather competitive.  Unfortunately, because PPP packets do not look
like slithernet packets, PPP prevents such software development
savings and in fact if PPP is the serial communications standard
rather than replacing a couple of line interface chips on an ethernet
board to respin it as a wide-area point-to-point board in a couple of
weeks, the board might have to be completely redesigned over a period
of several months.  The redesign represents major added costs.  Such
costs are passed onto the customer.

Joachim Carlo Santos Martillo Ajami

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

Sender: <tcp-ip-relay@nisc.sri.com>
From: martillo (Joachim Carlo Santos Martillo)
Message-Id: <9108302112.AA06328@azea.clearpoint.com>

> > You comment that slide can do everything PPP can do.
> > Aside from the obvious fact that it can carry protocols as an
> > extension of ethernet, how does SLIDE cope the the parameter
> > negotiation problem.  That is, depending on performance
> > situations, one (who believes in PPP) wants to negotiate various
> > forms of compression and authentication, etc.  It looks like SLIDE
> > simply says "that function should not be done at this layer".  Is

> I actually believe this.  After all the bundespost is working on a
> switched or permanent point-to-point ether service and nobody seems to
> worry about the question.  But because of the ethernet min packet
> size, you can use all packets shorter than 62 bytes as out of band
> signals to do all the parameter negotiation one wants.  To tell the
> truth I have forgetten the details of PPP parameter negotiation, but
> you might be able to use the PPP procedures.

This position that parameter negotiation should be somehow out of band
and only ancillary to the protocol is not merely aesthetic.  Suppose a
circuit switched public telephone network is providing transport and a
means of parameter negotiation on the signaling channel.  It might be
preferable to use this mechanism rather than the PPP parameter
negotiation even though PPP might mandate in-band procedure especially
because concerns about parameter negotiations are much larger in
demand circuit switched environments than in leased or nailed-down
line environments.

> After agreeing on basic parameters, you could use an ethernet logical
> address to communicate with an authentication server.  I believe the
> IEEE 802.10 committee is busily working on this.

> In any case authentication should be part of a separate specification.
> The argument that one has to use PPP because it provides
> authentication is rather bogus.  I suppose nobody should have used
> TCP/IP, rlogin, telnet or NFS until kerberos was worked out.

If anything the problem of authentication is even more orthogonal to
the question of transport.  Also authentication is an area of ongoing
development.  What is needed can change with circumstances and what is
available can change with time.  Transport and authentication should
be implemented as completely separate but communicating modules which
can be mixed and matched.  There is no obvious reason to include the
authentication procedure as part of the transport specification, and I
would argue that doing so might indicate a less than optimal
partitioning of the various problems associated with computer
networking.

Of course host requirements might specify a set of transport
procedures and a set of authentication procedures.

> Joachim Carlo Santos Martillo Ajami

Joachim Carlo Santos Martillo Ajami

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

Sender: <tcp-ip-relay@nisc.sri.com>
From: martillo (Joachim Carlo Santos Martillo)
Message-Id: <9108301225.AA05846@azea.clearpoint.com>
Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

> Briefly, can you explain why
> what you are proposing is different or better than PPP?

PPP is simply an encapsulation for the transmission of packets along a
point-to-point serial DCE/DTE link.  In some sense PPP can handle the
trivial or degenerate case of the problem which Slithernet addresses.

Slithernet provides an architecture for interconnecting such
point-to-point links to provide a communications subnet for a
subnetwork to which many hosts can be attached.  To these hosts
slithernet looks like an ethernet, and therefore all the standard
software can be run in the standard configuration.

Many ethernet chips have an hdlc mode which expects etherformat
packet.  Slithernet takes advantage of this technology.  And in fact
for many hardware companies (like Clearpoint) respinning and ether
card as a WAN card would be trivial except that the newer
sophisticated ether chips are incompatible with PPP.  Actually, the
newer serial chips are gaining ethernet modes which cannot be
efficiently used with PPP.

In general PPP is a backwards-directed concept.

Joachim Carlo Santos Martillo Ajami

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

Sender: <tcp-ip-relay@nisc.sri.com>
From: Joachim Carlo Santos Martillo <martillo@azea.clearpoint.com>
Subject: Re:  Using Wide-Area Point-to-Point Links for Computer Networking (I)
Date: Fri, 30 Aug 91 4:33:54 EDT

> Did you know that SLIDE was used in the way you describe by the Bridge
> Communications IB/3 in 1986?  It runs DC to 10 MBPS, you believe the
> data sheet.

So what? A SLIDE encapsulation is rather obvious.  They were probably
not the first either.

> Great, if you are doing Ethernet (not 802.5 or mixed media) remote
> bridging over a point to point line.  No so hot if you're routing - the
> header on the line just became a minimum of 14 octets, maybe as much as
> 20.  Frame Relay? SMDS?

20 bytes! Quel horreur!  I don't understand the point.  Routers
between token ring and Ethernet have been built and work fine.  There
should be no reason routing between token ring and slithernet won't
work as well except for the larger rate differential.

> The 82586, by the way, doesn't generate or not generate FCS on a frame
> by frame basis.  That is a feature of the 82596.

I have never programmed an 82586, but when Intel was trying to sell me
on this chip, the technical rep claimed that if CRC needed to be
generated on a per packet basis, the procedure was to chain a
configure command which turned on CRC generation before the transmit
command and then chain a configure command which turned off CRC
generation after the transmit command.

> You should talk to 3COM.  They've got a lot of experience with SlitherNET.
> And they don't use it anymore.

I have built a SLITHERNET.  It works fine and has run for a year.  And
I have beat on it with all sorts of protocols including NFS.

Joachim Carlo Santos Martillo Ajami


-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 22:08:00 GMT
To:        comp.protocols.tcp-ip
Subject:   BSD tcp source code?

Can anybody tell me where BSD tcp, tftp, and telnet source code
can be found?

Thanks,

Tal Elyashiv
R&D Dept.
Delta Controls Inc.
(604) 590-8184


-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 23:41:30 GMT
To:        comp.protocols.tcp-ip
Subject:   looking for a thesis topic

Dear Friends,

I am a student at Arizona State University doing my Masters in Computer

Science. I am presently looking for a good topic for my thesis and hence

have been referring to various journals but have not come up with a good

topic. I intend to work in the area of TCP/IP. If any of you have a good

topic in mind or have any suggestions to make, please let me know.

I look forward to hearing from you.

Sincerely yours,

Aniruddha Gokhale

or        : asasg@asuvm.inre.asu.edu


-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 23:48:48 GMT
From:      scd@math.ufl.edu (Steve C Donahue)
To:        comp.protocols.tcp-ip
Subject:   Dialup IP


I have the CREN/CSNET release of Dialup IP (version 2.0).  The docs for
this claim that the code has been installed on Sun OS 3.5.  We are running
Sun 4.1.1 rev A.  I am having a problem with the installation and I think
(actually, I am sure) that it has to do with the difference in OS
revisions.  In the installation docs, they say to modify the file
/sys/sys/tty_conf.c.  I assume that this was a pre-4.1.1 file because it
does not exist now.

I would really like to use this version of SLIP because it negotiates phone
connections on demand.  If there is another package that does this, I would
gladly take it.  However, I have not been able to dig one up.  Any help
would be appreciated.

--
----------------------------------------------------------------
It is a miracle that curiosity survives formal education.
-- Albert Einstein

Steve Donahue                 Internet: scd@cis.ufl.edu
CIS Engineering               NeXTmail: uflorida!thecube!steve
University of Florida


-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 00:20:01 GMT
To:        comp.protocols.tcp-ip
Subject:   API for FTP?

Is there an application program interface to FTP, with examples (software)
of how to use it?  Ideally, this would be a set of C routines that we
could FTP.

We're writing some software that will use FTP, and we're looking for the
interface and examples of how to use it.  Thank you.

Charley Pow


-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 01:02:57 GMT
From:      hayes@ultra.com (John Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: Why can't my clients talk to another subnet?

In <49983@seismo.CSS.GOV> black@beno.CSS.GOV (Mike Black) writes:

>I have read as much material as is on the net and have succeeded
>(somewhat) in implementing subnetting on our buildings Sun workstations.
>Here's an example of our setup:

>22.19.4.1 (255.255.255.0) --------  22.19.6.1 (255.255.255.0)
>  |                                   |
Host1                               Host2
>  |
192.9.201.1 (255.255.255.0)
>  |
>192.9.201.2 Client1
>192.9.201.3 Client2

>The Clients here cannot ping,ftp, or telnet to Host2.  Host2 also
>cannot ping,ftp, or telnet to the clients.  Note that a route has
>On Host1: route add net 22.19.6.0 Host1 0
>On Host2: route add net 22.19.4.0 Host2 0

>The two hosts can talk to each other fine, but not the clients.  Can
>someone enlighten me?

From your network number of 22 it would seem that you have one portion of
your network configured as a subnetted class A net, while a separate section
of the net (192.9.201) is a subnetted class C net.  You are trying to use
both sections with the same netmasks.

For the sake of this discussion I am going to assume that host 1 and
host 2 are running routed, and that the clients are not.  The following
answers may change slightly if this is not the case.  For clarity, I will
refer to the 22 net as NET1 and the 192.9.201 net as NET2.

The netmasks that should be used in the ifconfig for the interfaces in NET1
should be something on the order of 255.255.0.0.  I specify interfaces rather
than machine, because Host1 has 2 interfaces, one for each net.

The netmasks for those interfaces on NET2 should be something like
255.255.255.0.

The 'Host' machines should have no need for any route add's, as they are
running routed, and each of the client machines should have a route as
such: route add net 22.19.0.0 Host1 1

John.

--
John Wm. Hayes 						hayes@ultra.com
UltraNetwork Technologies				(408)922-0100 x202


-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 01:28:56 GMT
From:      dalton@pine.circa.ufl.edu (DALTON)
To:        comp.protocols.tcp-ip
Subject:   Reply on CMUIP Mail on a Vax

We are having trouble getting the CMU-IP e-mail to work on our Vax.
We are able to get IP mail to e.g. Dalton@Robot.nuceng.ufl.edu. just fine
is on the Robot machine or on the DecNet cluster.  Can anyone help on this.

We are able to rount mail through another mathine using the command:

mail  anyfile.txt  ""Other_vax::Wins%""<user@machine.dept.site.network>"""

But we would like to be just use the Reply option within Vax Mail.  I can
use to Reply on the Other_vax that is running the Wollongong WINS software,
but not on Robot, using CMU-IP.

Any help will be appreciated.

Ron Dalton, Prof. Nuc. Eng. Sci., U. of FL, Gainesville.
Dalton@Robot.NucEng.UFL.edu.


-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 06:51:13 GMT
From:      martillo@AZEA.CLEARPOINT.COM (Joachim Carlo Santos Martillo)
To:        comp.protocols.tcp-ip
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I) (fwd)

This further discussion of the merits of PPP may be of interest.

Sender: <tcp-ip-relay@nisc.sri.com>
From: martillo@crackers.clearpoint.com (Martillo)
Newsgroups: comp.protocols.ppp,comp.protocols.tcp-ip,comp.dcom.lans
Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)
Date: 18 Sep 91 12:27:54 GMT
References: <169385@pyramid.pyramid.com> <10930@jjmhome.UUCP> <1991Sep17.192623.5717@rand.org>
Organization: Clearpoint Research Inc, Hopkinton, MA

In article <1991Sep17.192623.5717@rand.org> edhall@rand.org (Ed Hall) writes:
>In article <10930@jjmhome.UUCP> martillo@jjmhome.UUCP (Joachim Martillo) writes:
>>Of course, a better way to view the issue is to note that
>>the promulgation of PPP is based on a fundamentally silly idea that a single
>>protocol can solve all problems for all times on very diverse media over
>>a very wide range of speeds.

>Of course, the exact same charge has been leveled at TCP/IP itself.  I
>regard both charges as having the same merit....

>		-Ed Hall
>		edhall@rand.org

Just go ahead and compare apples and oranges.  It shows good analytical
skills.  I probably should have said "a single link level protocol" but
I assumed most people would understand.  The logic of PPP is rather more
like claiming that 802.5 algorithms can be used on all ring media even
though there are ring media which don't use tokens.

TCP does one job well.  It provides sequenced reliable transport on
top of a virtualized network layer.  PPP by way of contrast tries
to do all sorts of random crap.  The TCP designers understood how to
do good protocol design.  The PPP designers did not understand.

Joachim Carlo Santos Martillo Ajami

--
the author and in no way do they reflect the official opinion or policy
of Clearpoint Research Corporation.


-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 11:51:12 GMT
From:      se@IKP.Uni-Koeln.DE (Stefan Esser)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

In article <PCG.91Sep9183332@aberdb.aber.ac.uk> you write:
|>That's impossible to achieve, it ignores inband formatting information
|>(headers, CRC, pauses between packets) and other practical constraints.

|> The very best Ethernet sw can drive it at 0.8MB/s, sustained, with
|> occasional bursts at 0.9MB/s.

What makes you that sure ?
Would you believe someone who, has seen more than 900KB/s, sustained ?

May be that you can't *imagine* TCP transfers faster than 800KB/s.
But there are people who *know* that it is possible, because they've done it.

If you have INTERNET access to this site, I invite you to test the ethernet
performance of our DEC 5000/200 and Sparc 2 systems.
Then you'll also know that it is possible ...

Stefan
--
Stefan Esser,  Institute of Nuclear Physics,  University of Cologne,  Germany
se@IKP.Uni-Koeln.DE                                           [134.95.192.50]


-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 12:27:54 GMT
From:      martillo@crackers.clearpoint.com (Martillo)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

In article <1991Sep17.192623.5717@rand.org> edhall@rand.org (Ed Hall) writes:
>In article <10930@jjmhome.UUCP> martillo@jjmhome.UUCP (Joachim Martillo) writes:
>>Of course, a better way to view the issue is to note that
>>the promulgation of PPP is based on a fundamentally silly idea that a single
>>protocol can solve all problems for all times on very diverse media over
>>a very wide range of speeds.

>Of course, the exact same charge has been leveled at TCP/IP itself.  I
>regard both charges as having the same merit....

>		-Ed Hall
>		edhall@rand.org

Just go ahead and compare apples and oranges.  It shows good analytical
skills.  I probably should have said "a single link level protocol" but
I assumed most people would understand.  The logic of PPP is rather more
like claiming that 802.5 algorithms can be used on all ring media even
though there are ring media which don't use tokens.

TCP does one job well.  It provides sequenced reliable transport on
top of a virtualized network layer.  PPP by way of contrast tries
to do all sorts of random crap.  The TCP designers understood how to
do good protocol design.  The PPP designers did not understand.

Joachim Carlo Santos Martillo Ajami

--
the author and in no way do they reflect the official opinion or policy
of Clearpoint Research Corporation.


-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 12:35:48 GMT
From:      bmiller@CABELL.VCU.EDU (Bryan E. Miller)
To:        comp.protocols.tcp-ip
Subject:   Sendmail


Any sendmail guru's out there???

I have a question concerning "Apparently-to".  When exactly should you
see this line in a mail header, as opposed to the normal "To:"???

Thanks,

Bryan Miller
bmiller@cabell.vcu.edu


-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 13:59:42 GMT
From:      chi@SPARTA.COM (Chi Chu)
To:        comp.protocols.tcp-ip
Subject:   let me out!

Please unsubscribe chi@sparta.com.  I can't take it anymore!


-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 14:58:55 GMT
From:      albright@LAGER.CISCO.COM (Bob Albrightson)
To:        comp.protocols.tcp-ip
Subject:   Re: udp on Internet Connection

> Hi All
>
> We are just about to get our connection to the Internet. We are planning
> to install a router of our own (CISCO) which we will use to keep
> unwanted traffic from our own network (and vica versa). I am wondering
> what functions we will loose (or what problems we will cause ourselves)
> if we prevent any UDP traffic between our local network and the
> Internet.

You will loose domain name service.  Some routing protocols use UDP.  Just to
name a few.  Don't filter all UDP.

-bob


-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 15:45:56 GMT
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP FIN and window

>Date: 5 Sep 91 18:08:30 GMT
>From: rochester!rocksanne!sma@cu-arpa.cs.cornell.edu  (Susie Armstrong)
>Organization: WRC, XEROX
>Subject: Re:  TCP FIN and window
>Message-Id: <897@rocksanne.WRC.XEROX.COM>
>To: tcp-ip@nic.ddn.mil
>Status: R

>Fred Bohle mentions that the TCP on Xerox boxes will not send
>a FIN into a zero window. ...

>Note that though I will not send a FIN into a closed window,
>I will process a FIN that I receive into my closed window (my
>window reflects buffering for "physical data", and FINs don't
>consume buffers, so processing that FIN is easy to do).  This
>reflects my belief in that old transport implementation rule
>you accept".

Exactly.  This is why I think a clarification is in order here.
Following this rule leads us into this problem.  I believe that
you SHOULD send the FIN into a zero window, and you believe that
you should NOT.

I wrote several points trying to justify my position, and would
like others to comment on them.  Briefly they are:

1. FIN, like SYN is a session control function, and as such
deserves special treatment.

2. FIN takes sequence space but not data space, so buffering
considerations do not apply.

3. This strategy of sending FIN into a zero window is practiced
by a great number of implementations, so interoperability is
NOT impaired by following it.  On the contrary, interoperability
IS impaired by NOT following it.

4. If it makes you feel better about it, consider sending FIN in this
situation to be more like a zero window probe.  You MUST support
zero window probes, and FIN is one byte beyond the current sequence
number in the situation which gave rise to the problem is the first
place.

(The original problem was trying to close the FTP data connection.
The data port had a zero window in the reverse direction.  Xerox
would not send the FIN into this zero window.)

>However, I do agree that the specification is not
>explicit on this point, and sending the FIN into a closed
>window (and having it accepted) does not harm the integrity
>of the data or of the closing handshake.

>This implementation was done pre-host-requirements-rfc -
>perhaps that document has some more clues on the commonly
>accepted treatment of FINs in general, if not on this case
>specifically.

No such luck.  My scan of host-req. did not show up anything useful on
this issue.

>Cheers,
>    Susie Armstrong
>    Xerox Webster Research Center
>    armstrong.wbst128@xerox.com

Glad to meet you Susie.  Let's pursue this further, offline if you wish.

Others, please respond with opinions and suggestions for how to proceed
(RFC perhaps?)
Fred
------------------------------------------------------------------------
Interlink Computer Sciences	AT&T : 301-317-6600
Columbia, MD 21046
------------------------------------------------------------------------


-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 16:03:25 GMT
To:        comp.protocols.tcp-ip
Subject:   Re:  tn3270 on SNA emulators


Date: 6 Sep 91 02:16:34 GMT
Sender: <tcp-ip-relay@NISC.SRI.COM>
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!manuel!jatz.aarnet.edu.au!pte900@ucbvax.Berkeley.EDU  (Peter Elford)
Organization: AARNet
Subject: tn3270 on SNA emulators
Message-Id: <1991Sep6.021634.20465@newshost.anu.edu.au>
To: tcp-ip@nic.ddn.mil

Why don't vendors offer SNA gateways that support tn3270 servers ?, ie.

+--------+               +------------------+        +--------+
| PC/Mac |               |     Gateway      |        | IBM    |
|        |               |                  |        |        |
| tn3270 |               | tn3270 |   327x  |        |        |
| client |               | server | emulator|        |        |
+--------+               +--------+---------+        +--------+
|                         |        |                 |
--+--- tn3270 protocol -----+-       +--- SNA/BSC -----+

system, and would avoid the cost and overheads of installing a LAN
interface and IP software on the IBM mainframe (which is not cheap :-).

Then you lose the ability to use other functions to/from the IBM mainframe!
You cannot FTP to/from the IBM mainframe, you cannot Telnet FROM the IBM,
you cannot MAIL to/from the IBM,  you cannot use an API to write TCP appl.
code, you cannot use NFS there, ...

It is not cheap, but it is not all that expensive either.

------------------------------------------------------------------------
Interlink Computer Sciences	AT&T : 301-317-6600
Columbia, MD 21046
------------------------------------------------------------------------


-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 16:05:05 GMT
From:      hendrick@ctron.com (Jim Hendrick)
To:        comp.protocols.tcp-ip
Subject:   Looking for an old Posting by Jacobson

I am looking for postings regarding performance of TCP/IP, specifically the

interim notes on BSD Network Speedup posting by Jacobson posted here in
comp.protocols.tcp-ip July 1988

and the

Cong. Avoid. and Control "Comp. COmm. Review" vol 18 no 4 pp 314-329
procc ACM SIGCOMM Aug 1988

and supposedly posted here in this newsgroupp Nov. 1988.

Any info would be appreciated Thanks.

--
###############################################################################
### My opinions, etc are exclusively the property of nobody in particular.  ###
### "If you think this is a mess, you should see what its like in here..."  ###
### tapping his forehead. . .                                               ###
###############################################################################


-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 18:49:42 GMT
From:      tom@ksr.com
To:        comp.protocols.tcp-ip
Subject:   Please remove me from this list.


Please remove me from this list.

|| * * * * * =========       Tom Varga
||  * * * *  =========       Kendall Square Research
|| * * * * * =========       617-895-9415
|| ===================       tom@ksr.com
|| ===================       uunet!ksr!tom
|| ===================       N2UA @ KA1PEP
||


-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 19:50:18 GMT
From:      TGAMS@CUNYVM.BITNET (Tom Abernathy)
To:        comp.protocols.tcp-ip
Subject:   SLIP for IBM-PC, SUN3, SUN386i, VAX/VMS

I am looking for information / sources for Serial Line IP implementations
for IBM Personal Computers (running DOS), SUN3 and/or SUN386i, and
VAX running VMS and WIN/TCP.
If there are public domain versions of this where are they.
Thank you.

Tom Abernathy
Mount Sinai School of Medicine
tom@msrcvax
or
tgams@cunyvm.cuny.edu


-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 20:52:54 GMT
From:      allebrandi@inland.com (Tom Allebrandi)
To:        comp.protocols.tcp-ip
Subject:   "Reverse Subnetting"

I have a question about subnetting and netmasks. None of the documents
I have read, including the RFC (whose number I forget), deal with what
we are trying to do.

The NIC has assigned our company 32 Class C network numbers. The
numbers were carefully chosen so that

1) The "C" byte for the first one is a multiple of 32;
2) The "C" byte for the rest of the numbers follow in sequence.

Specifically, we have 192.111.128 through 192.111.159.

What we would like to do is this: Pretend to be a Class B subnetwork by
using a netmask of 255.255.224.0 The way that I understand subnets is
that you do the following:

3) If the answers are the same, the two hosts are on the same
local network.

For example:

A) 192.111.128.1 AND 255.255.224.0 = 192.111.128.0
B) 192.111.132.1 AND 255.255.224.0 = 192.111.128.0
C) 192.111.167.1 AND 255.255.224.0 = 192.111.160.0

Hosts A and B would be treated as being on the same local network; C
would not be on the same local network.

I've tried this idea on a number of different TCP/IP implementations.
My results are:

1) CMU/TEK TCP/IP on VAX/VMS - Works

2) Multinet TCP/IP on VAX/VMS - I have been told that this works

3) DEC Ultrix-32 (version 4.1) - Will not let you set the netmask for a
Class C network number to anything but 255.255.255.0

4) Sun O/S (version 4.something) - You can set the netmask but once you
do the local host can no longer communicate with the network.

5) Silicon Graphics Unix (version unknown) - Same as for Sun O/S.

For those that don't work, should it? Am I possibly just doing
something wrong? On the Ultrix machine, for example, I use

to start TCP/IP. I use a similar command on the Sun and Silicon Graphics.

Please respond by Email, I'll summarize if necessary.

Thanks!

--- Tom Allebrandi		Inland Steel Research Labs
Allebrandi@Inland.Com	East Chicago, IN


-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 21:30:01 GMT
From:      jon@mxmsd.UUCP (Jon Fields)
To:        comp.dcom.modems,comp.protocols.tcp-ip
Subject:   Dialup IP and Telebit NetBlazer

Hello,

We require some low volume, low cost, TCP/IP connections to  remote
hosts for purposes of ftp, telnet, and running X clients.  The XRemote
product from NCD satisfies the last requirement, but not the first
two.  SLIP will satisfy the first two, but I have heard that it
performs very poorly for the last.

I have heard about the Telebit NetBlazer, and have sent away for
info on it.  I would greatly appreciate comments from people who have
similar requirements to ours, and how they have been satisfied.  Also,
with great interest.  And finally, if you know of other dialup IP

E-mail is fine; I will post a summary if there is enough interest.

Thanks!!

Jon Fields
--
UUCP: ...uunet!mxmsd!jon         Jon Fields
Voice: (513)-825-3931 x-314       Measurex--Management Systems Division
Fax: (513)-825-5393             1280 Kemper Meadow Drive
Cincinnati, Ohio 45240


-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 21:41:16 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Wireless network connections?

LAN communications.  The article is slanted toward the company which is
contemplating building a complete LAN based on radio transceivers.

In my case, I'm wondering if a single point-to-point radio connection
might be more cost-effective than infra-red for a 100-meter haul across
a roadway and parking lot.  At last check, a pair of IR transceivers
for Ethernet cost on the order of US$12,000. This article mentions the existence of radio transceivers costing as little as$2,800 a pair.

Ideally, the cost of this could be brought down to a level comparable
with or below that of a 56K leased line plus modems, and deliver better
performance (perhaps even 10M, which IR can deliver).

The vendors mentioned in the article are Motorola, NCR, and
Telesystems.  The NCR product plugs into an AT bus, which could theore-
tically be configured as a low-cost TCP/IP router if outfitted with an
Ethernet LAN card and appropriate software.

Has anyone set something up like this?  In our case, this would be a
temporary solution, as our company is contemplating a move and even if
it doesn't move there will eventually (12-24 months) be fiber optic
conduit available at our doorstep.

I don't have purchasing authority on this, but I'd love to be able to
go to management and say, "We can join Internet for under $10,000 and thereby save$30,000 a year".  At this point, direct Internet access is
a pipe dream, given presently-high startup and monthly access costs.

-rich


-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 21:51:45 GMT
From:      bcanning@REED.EDU
To:        comp.protocols.tcp-ip
Subject:   unsubscirbe bcanning@reed.edu



-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 22:33:56 GMT
From:      pnm@SATURN.ACC.COM (Patrick N. Medved)
To:        comp.protocols.tcp-ip
Subject:   SCO Drivers


I am working on porting a driver from a Sun Machine
to a SCO Unix machine.  I need the driver to interface
to IP.  I called SCO and they said their documentation
doesn't go into that.  Possibly if I got involved with
their developer relations, then they could get me
some information on how to do it, or maybe some sample
drivers.

It seems to me I have seen some messages on this list
about drivers for SCO.  I would appreciate some
information on how to connect a driver on SCO to IP.

Specifically, could someone point me to some SCO IP drivers that are
available via FTP and any documentation for doing this.

Thanks, Pat

pnm@saturn.acc.com


-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 91 10:11:32 GMT
From:      graeme@ccu1.aukuni.ac.nz ( Graeme Moffat)
To:        comp.protocols.tcp-ip
Subject:   Re: Why can't my clients talk to another subnet?

hayes@ultra.com (John Hayes) writes:

>In <49983@seismo.CSS.GOV> black@beno.CSS.GOV (Mike Black) writes:

>>I have read as much material as is on the net and have succeeded
>>(somewhat) in implementing subnetting on our buildings Sun workstations.
>>Here's an example of our setup:

>>22.19.4.1 (255.255.255.0) --------  22.19.6.1 (255.255.255.0)
>>  |                                   |
Host1                               Host2
>>  |
192.9.201.1 (255.255.255.0)
>>  |
>>192.9.201.2 Client1
>>192.9.201.3 Client2

>>The Clients here cannot ping,ftp, or telnet to Host2.  Host2 also
>>cannot ping,ftp, or telnet to the clients.  Note that a route has
>>On Host1: route add net 22.19.6.0 Host1 0
>>On Host2: route add net 22.19.4.0 Host2 0

>>The two hosts can talk to each other fine, but not the clients.  Can
>>someone enlighten me?

Clients:  'route add default Host1 1'
(assuming that 192.9.201 is the only net here, and Host1 can forward ie is
running routed or gated) will give the clients access to 22.19.x or whatever
Host1 knows about. But remember that IP is two way, and Host2 still does not
know how to send (back) to the clients.

>From your network number of 22 it would seem that you have one portion of
>your network configured as a subnetted class A net, while a separate section
>of the net (192.9.201) is a subnetted class C net.  You are trying to use
>both sections with the same netmasks.

The class C net is not subnetted!  That is the normal mask. It doesn't
matter that the two nets have the same mask.

>For the sake of this discussion I am going to assume that host 1 and
>host 2 are running routed, and that the clients are not.  The following

Neither host2 nor the clients *need* run routed, but host1 does

>The netmasks that should be used in the ifconfig for the interfaces in NET1
>should be something on the order of 255.255.0.0.  I specify interfaces rather

This makes things much easier, because now both hosts are in the same subnet.
Either running routed/gated on Host2, or 'route add net 192.9.201 Host1 1'
will do. I would favour the dynamic (routed) approach.
But what if they *want* 24 bits of subnet?  Then they would like to have
'route add net 192.9.201 Host1 1' but Host2 can't do that because it's not
in the same (logical) net as Host1, even though they're on the same cable.
Now, they need a host which can have multiple interfaces on the same
physical cable, and can 'pass' packets from one subnet to the other (in
reality, forward them out on the same cable).  Routers (can you say $$) do this using logical addresses for one physical interface. The hosts would then have a judicious mixture of static routes (one, in this case) and a default. For host2: 'route add net 22.19.4 Host2 0' & 'route add default 22.19.6.254 1' where the router has 22.19.x.254 as its secondary addresses on every subnet. (I guess that could be 22.x.y.254, but I assume there's more to this network that's not been presented, why else have a class C net at all?, there seems plenty of spare class A) The static routes are not strictly necessary but improve efficiency since packets sent to the default will be doubled on the network. >The netmasks for those interfaces on NET2 should be something like >255.255.255.0. I assumed that they were already >The 'Host' machines should have no need for any route add's, as they are >running routed, and each of the client machines should have a route as >such: route add net 22.19.0.0 Host1 1 Or the more general default one -- Graeme Moffat g.moffat@aukuni.ac.nz \ Time wastes us all, Computer Aided Design Centre, Fax: +64-9-366-0702 / our bodies & our wits School of Engineering, Ph: +64-9-737-999 x8384 / But we waste time, University of Auckland, Private Bag, Auckland, NZ \ so time & we are quits  -----------[000214][next][prev][last][first]---------------------------------------------------- Date: 19 Sep 91 12:30:31 GMT From: kasten@EUROPA.CLEARPOINT.COM (Frank Kastenholz) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window  > From tcp-ip-relay@nisc.sri.com Thu Sep 19 03:30:44 1991 > Sender: <tcp-ip-relay@nisc.sri.com> > From: fab@md.interlink.com (Fred Bohle) > To: fab@md.interlink.com, kasten@europa.clearpoint.com, > mentor.cc.purdue.edu!dls@purdue.edu, tcp-ip@nic.ddn.mil > Subject: Re: TCP FIN and window > > Frank writes: > > >From: kasten@europa.clearpoint.com (Frank Kastenholz) > >Message-Id: <9109061751.AA20593@europa.clearpoint.com> > >To: fab@md.interlink.com, mentor.cc.purdue.edu!dls@purdue.edu, tcp-ip@nic.ddn.mil > >Subject: Re: TCP FIN and window > >>From RFC792: > >2.10. Robustness Principle > > TCP implementations will follow a general principle of robustness: be > > conservative in what you do, be liberal in what you accept from > > others. > > So what is your conclusion from this statement. I want to be liberal > and accept the FIN, in fact I already do that. What is not determined > is does the statement about being conservative mean the other end should > NOT send the FIN? I argued against this in previous messages. > > Let's hear your opinion, Frank. when there is a particular form of behavior which is of dubious "legality" per the spec, then do not do it. if you can make sense out of a packet when you receive it and you can correctly process it, then you should. if you are advertising a window of size n and a packet comes in that is bigger than size n, if you can process it (have the buffers/computrons/whatevers) then you should do so. you should not gratuitously drop the packet.  -----------[000215][next][prev][last][first]---------------------------------------------------- Date: 19 Sep 91 14:21:30 GMT From: PIRARD@VM1.ULG.AC.BE (Andr'e PIRARD) To: comp.protocols.tcp-ip Subject: Re: EBCDIC ASCII and *much* more  u t!wnoc-tyo-news!sranha!sranhd!srava!erik@ucbvax.Berkeley.EDU> On 6 Sep 91 01:28:05 GMT you said: >Andr'e PIRARD writes: >> So, because we restrict ourselves to single-octet codes for now > >What do you suggest for the Japanese, Chinese, Korean, and Taiwanese >users? A decent solution of the war between ISO and Unicode. So they can start using computers. I know what's waiting. But most of all a single code. I know that redundant character codes mean big troubles. So, no rush towards immediate solutions for profit. But I don't think America will abandon ASCII right away. There is still some CP/M around! The same holds for 8-bit codes. Andr'e.  -----------[000216][next][prev][last][first]---------------------------------------------------- Date: 19 Sep 91 15:36:34 GMT From: pnm@SATURN.ACC.COM (Patrick N. Medved) To: comp.protocols.tcp-ip Subject: SCO DRIVERS  I am working on porting a driver from a Sun Machine to SCO UNIX. I need the driver to interface to IP. I called SCO and they said their documentation doesn't go into that. If I was to become involved with developer relations, I could get info on interfacing a driver to IP. I think the interface is called the LI interface. I thought I had seen some drivers mentioned in this group that were written for SCO Unix as available via FTP. I would appreciate any information on how to get any drivers or documentation via FTP if possible. Thanks, Pat pnm@saturn.acc.com  -----------[000217][next][prev][last][first]---------------------------------------------------- Date: 19 Sep 91 15:42:14 GMT From: rogers@ux1.cso.uiuc.edu (Bill Rogers) To: comp.protocols.tcp-ip Subject: I need a PD bootp server for DOS?  Is there a pd dos implemetation of bootp server to assisn IP address? We are using a mix of NCSA, Clarkson, and Ka9q and would like to dynamically assign ip's. Thanks, Bill -- .............................................................................. Bill Rogers . Internet - rogers@ux1.cso.uiuc.edu Asst. Director for Academic Computing . Bitnet - ROGERS@UIUCVMD Sangamon State University . Voice - 217-786-6549  -----------[000218][next][prev][last][first]---------------------------------------------------- Date: 19 Sep 91 16:46:01 GMT From: donp@novell.com (don provan) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window  In article <9109062037.AA18038@leo.md.interlink.com> fab@MD.INTERLINK.COM (Fred Bohle) writes: >So what is your conclusion from this statement. I want to be liberal >and accept the FIN, in fact I already do that. What is not determined >is does the statement about being conservative mean the other end should >NOT send the FIN? I argued against this in previous messages. Sending the FIN is fine. It's just another probe into a zero window. The fact that you probe as soon as the FIN is available is just an implementation detail. What isn't conservative is announcing a zero window yet expecting the remote node to send the FIN to you briskly. don provan donp@novell.com  -----------[000219][next][prev][last][first]---------------------------------------------------- Date: 19 Sep 91 18:31:53 GMT From: phil@brahms.amd.com (Phil Ngai) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window  dls@MENTOR.CC.PURDUE.EDU writes: > Anyone for being tough on crime, too?!? :-) Let's end government waste, fraud and abuse. Also, let's be tougher about collecting on student loans. -- This posting is purely a personal opinion.  -----------[000220][next][prev][last][first]---------------------------------------------------- Date: 19 Sep 91 18:38:25 GMT From: 08071TCP@MSU.EDU (Doug Nelson) To: comp.protocols.tcp-ip Subject: Re: routing problem from hell  Well, I'll take a stab at it, too. >>The root of the problem is that my router sits on subnet 78 and the router >>to the AAA.BBB.CCC.0 network sits on subnet 10. When I try to add a route >>sun-router>> route add net AAA.BBB.CCC.0 XXX.YYY.10.1 1 add net >>AAA.BBB.CCC.0: gateway XXX.YYY.10.1: Network is unreachable > >This is correct. XXX.YYY.10 is not in your subnet. What you really need to do is designate a single subnet on the bridged Ethernet in which all the routers live. Or, if your default router handles multiple subnets (e.g. cisco), you can define a secondary address on it that is in your subnet (78 in your case). >>This leads to 2 questions: ... >>2) One way to solve this would be to change the subnet mask on the 78 >> side of my router to 255.255.0.0. Can the Sun IP code deal with a >> machine with 2 different subnet masks for the same class B network. > >If it can, it's broken! If the 78 side is now net XXX.YYY.0.0, then >XXX.YYY.252.0 is a host address in the same network, not a net address. I wouldn't go so far as to call it broken. It is generally the case that you have to use the same subnet mask on each side, but it doesn't have to be, if the router will accept subnet masks per route, and sort the routes properly (smaller subnets to the top). The Sun IP code doesn't do this. Doug Nelson Michigan State University ! graeme@ucbvax.Berkeley.EDU>  -----------[000221][next][prev][last][first]---------------------------------------------------- Date: 19 Sep 91 18:51:13 GMT From: 08071TCP@MSU.EDU (Doug Nelson) To: comp.protocols.tcp-ip Subject: Duplicate/old mailings  Is NISC.SRI.COM having trouble getting mail out to the TCPIP list? I am receiving frequent multiple copies of letters, and letters that are up to two weeks old. I don't have any reason to suspect that it's a problem with the SMTP on my end; is it that I'm just too far down (up) the list, and it can't tell exactly where it left off when it encounters a non-responding address? Doug Nelson Michigan State University  -----------[000222][next][prev][last][first]---------------------------------------------------- Date: 19 Sep 91 19:26:13 GMT From: oleg@watson.ibm.com (Oleg Vishnepolsky) To: comp.protocols.tcp-ip Subject: Re: API for FTP?  In <17879@leadsv.UUCP> netnews@leadsv.UUCP (Leads Network News) writes: > Is there an application program interface to FTP, with examples (software) > of how to use it? Ideally, this would be a set of C routines that we > could FTP. > > We're writing some software that will use FTP, and we're looking for the > interface and examples of how to use it. Thank you. > > Charley Pow IBM OS/2 and DOS TCP/IP products come with client FTP API. They do come with examples of how to use it. Other vendors may have it as well but I personally am not aware of any. Oleg Vishnepolsky  -----------[000223][next][prev][last][first]---------------------------------------------------- Date: 19 Sep 91 20:37:44 GMT From: robert@nysnet.nys.GOV (Robert J. Vitello) To: comp.protocols.tcp-ip,comp.sys.att Subject: SLIP driver for AT&T 3B2  We are operating a 3B2/1000 using AT&T's remarketing of Wollongong's TCP/IP. While Wollangong supports the SLIP driver, AT&T even denies that there is such a thing. And because of the relationship between Wollongong and AT&T, it appears that we can't get the SLIP driver from the original supplier either. Has anyone a way around this? Are there any alternative sources?  -----------[000224][next][prev][last][first]---------------------------------------------------- Date: 19 Sep 91 21:04:53 GMT From: aej@manyjars.WPI.EDU (Allan E Johannesen) To: comp.protocols.tcp-ip Subject: Protocol Test Suite  Is something similar to the "DCA Upper Level Protocol Test System Software" filed away in some FTP archive? I have seen an old reference to a 1600 BPI tape of binaries which would run on ULTRIX 1.1 available from NTIS, but was hoping a more contemporary software source was available somewhere on the Internet. This package tested interoperability of TCP, IP, SMTP, FTP and TELNET.  -----------[000225][next][prev][last][first]---------------------------------------------------- Date: 19 Sep 91 23:27:04 GMT From: donp@novell.com (don provan) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window  In article <9109062156.AA16523@mentor.cc.purdue.edu> dls@MENTOR.CC.PURDUE.EDU writes: > "Be liberal in what you receive and conservative in what you >send" practically qualifies as a political sound bite. All the substance is >subject to interpretation. Everyone will agree it's a good idea to do that, >which is undoubtedly why it is quoted so often, but it doesn't mean any >agreement at all on the issue. On the contrary, i dare say this rule has been applied zillions of times with utter certainty to make implementation decisions and settle arguments. If you consider it a vacuous motherhood, perhaps you do not understand it very well. Its application is, perhaps, blurred in this particular case because the suggested handling of FIN is "only a little liberal", being only slightly at odds with the specs. In addition, this behavior is a reasonable candidate for canonization in future specs. (The presence of this behavior in the specs would, of course, instantly make it conservative.) Finally, notice that this FIN handling only causes problems in rare cases. This is a classic proof of The Rule: sending something too liberal is only a problem when communicating with a second implementation that's too conservative about what it receives. The beauty of applying The Rule to a real world problem is that it often shows that *both* implementations are at fault. :-) don provan donp@novell.com  -----------[000226][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 01:15:40 GMT From: robert@swanee.ee.uwa.oz.au (Roberto Togneri) To: comp.protocols.tcp-ip Subject: Increasing transfer size of SOSS - Can it be done ?  Hi, We have successfully been using SOSS to access our MOD drive from DOS. However write access is exceedingly slow. Due in part to the MOD itself but I also believe in part to the 1024 packet limit that SOSS imposes. NFS uses 8192 bytes per packet (or burst?). Is there a way of recompiling SOSS with a bigger packet size? Or is the problem deeper than that? I have the sources to pcip, pcipdrv and soss. Any help appreciated. -- Dr. Roberto Togneri Phone: +61-9-380-2535 Digital Signal Processing Research Group Dept. of Electrical & Electronic Engineering The University of Western Australia Fax: +61-9-380-1065 NEDLANDS WA 6009 Australia Email: robert@swanee.ee.uwa.oz.au  -----------[000227][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 01:43:56 GMT From: dinesha@bass.bu.edu (Dinesh V.) To: comp.protocols.iso,comp.protocols.tcp-ip Subject: Looking for Network Management Standards  Hi, I am looking for the ISO/IEC Network Management Standards Documents. Our Library here doesn't have them and though I tried some other local facilities, I couldn't lay my hands on them. I was wondering if there were some anonymous ftp sites where I could get them from or whether they are available in the electronic format. If not, is there some organisation I could write to and obtain them? Could you mail your responses to dinesha@bu-pub.bu.edu? Thanks, Dinesh. PS: I am particularly interested in the Configuration Management Standard.  -----------[000228][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 05:58:00 GMT From: ACM_CSA@SWTEXAS.BITNET (ACM_CSA@SWTEXAS.BITNET) To: comp.protocols.tcp-ip Subject: HP Apollo Ethernet Revisited  Ok guys... sorry that I have so negligent in replying, but there has been this little catch called school that I must attend to. I have compiled as many facts about our system that I could find. It seems that our Apollos use a token ring network to communicate between each other, and the ethernet card is only attached to machine //plum. It also seems that our school administrators have delayed (again humph!) the installation of TCP/IP (and thus an Internet connection) on our VAXen. That changes our outlook on life so that we will just be connecting the Apollos to a TI UNIX machine, and to a Novell PC network. There has been a small breakthrough of sorts since my last message. There is a command in one of the books that shows how to activate the ethernet card for an operation of some type. Using a varation of the command, we got the card online just for sending and not for receiving. We are still clueless as to how to make the thing work properly. If there are any further inquires as to the specific setup of a machine, we can deal with it through e-mail. Thank you. Brian Collins Chairman of USERDIR for ACM/CSA Bitnet: ACM_CSA@SWTEXAS THEnet: SWT::ACM_CSA Internet: ACM_CSA%SWTEXAS.BITNET@RICEVM1.RICE.EDU -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ------- ------- ------- --> | 1 | ---------> | 2 | ---------> | 3 | ---------- | ------- ------- ------- | | | 9Tr | | | ------- | | | | ------- ------- | | --- | 5 | <--------- | 4 | <--------- | | ------- ------- | | | | | | ------- ------- | --> | 6 | ---------> | 7 | --- | ------- ------- | | | | | | ------- ------- | ---------------------- | 9 | <--------- | 8 | <-- ------- ------- Num //Node ID Other --------------------------------------------------------------------------- 1 //Banyan - F066 DN3000, Diskless (//Plum), 4M RAM 2 //Fig - F6B3 DN3000, Diskless (//Plum), 4M RAM 3 //Redwood - FE3A DSP90, Diskless (//Plum), 3M RAM, 9 Track Tape Drive 4 //Banana - 12C99 DN4000, 140M HD, 4M RAM, SIO, 5.25" Floppy, Color 5 //Palm - 10450 DN4000, 320M HD, 12M RAM, 8mm Tape 6 //Peach - FEC3 DN3000, 320M HD, 4M RAM, 8mm Tape 7 //Plum - 104AA DN3000, 320M HD, 4M RAM, SIO, 5.25" Floppy, 802.3 Ethernet Card 8 //Pear - E925 DN3000, Diskless (//Plum), 4M RAM 9 //Mulberry - 10033 DN3000, Diskless (//Plum), 4M RAM  -----------[000229][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 06:36:00 GMT From: v130jarn@ubvmsb.cc.buffalo.edu (THE SHOTGUNNER) To: comp.protocols.tcp-ip Subject: FTP sites in the US  I was wondering where a person could get FTP numbers for Pennsylvania or the surrounding area? Does it matter what type of connection one is on, say VAX cluster or UNIX? I'd appreciate a list, but don't know where to get it. Much appreciated.... Alex (V130JARN@ubvmsb.cc.buffalo.edu)  -----------[000230][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 08:53:38 GMT From: wetzels@amc.uva.nl To: comp.protocols.tcp-ip Subject: subscribe  please subscribe wetzels@amc.uva.nl  -----------[000231][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 09:02:16 GMT From: tom@wcc.oz.au (Tom Evans) To: comp.protocols.tcp-ip Subject: Re: Forwarding of broadcast packets  In article <1991Sep13.045717.13473@ccu1.aukuni.ac.nz>, graeme@ccu1.aukuni.ac.nz ( Graeme Moffat) writes: > I have been using Netwatch to observe ethernet packets to learn what exactly > is happening. > (RIP update, rwho, packets to a particular IP address where host only knows > a default net to send to...),(but *not* ARP), four other hosts repeat that > packet, sending it to a destination of '00ffbad1dead', and also sending an > ICMP redirect to the original source. That ethernet address is "Off, Bad One Dead". This is an "ARP-Storm-killer-address", given in response to an ARP request for what is understood to be a broadcast IP address. It serves to stop the confused host from continuously asking for an address that it should never get an ARP resolution for. I have forwarded more complete details to Graeme. ======================== Tom Evans tom@wcc.oz.au Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179 Victoria, Australia 61-3-764-1100 FAX ...764-1179 A.C.N. 004 818 455 wcc@cup.portal.com, AppleLink: "WEBSTER.USA" 2109 O'Toole Avenue, Suite J SAN JOSE CA 95131 - 1303 CALIFORNIA 1-408-954-8054 FAX 1-408-954-1832  -----------[000232][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 09:41:05 GMT From: koelman@issun3.stc.nl (Ton Koelman) To: comp.protocols.tcp-ip Subject: IP reassembly in Comer Volume II  Hello, I just went through the section on reassembly (7.4) in Comer's Internetworking with TCP/IP Volume II (love it...) and noticed that there is no mentioning whatsoever of the arrival of duplicates and fragments of duplicates. Has anyone checked the code to see what happens when this occurs? I wonder whether it was a deliberate decision not to mention duplicates... I would ask the authors directly if I had their e-mail addresses, I missed them in the book... Ton Koelman koelman@issun3.stc.nl  -----------[000233][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 11:47:05 GMT From: backman@FTP.COM (Larry Backman) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window  >> 1) In a modern TCP, the receiver window will never be o unless the destination >> device is slower than the network link (eg terminal servers). Or the host above the device is tied up doing something else. We have this nice Mach machine which doesn't believe in the ENOSPACE error code; instead it prints the message "file system full, pausing" on the console. Guess what happens to any receive windows of active TCP connections in this instance! I'll refrain from the myriad cases a PCTCP window can go to 0.. >> 5) In case one, the correct interval for probing the window should be >> based on the time you expect the remote host to dispose of it's data. >> This isn't based on the network characteristics at all, so basing the >> initial probe interval on the calculated RTT is completely bogus. Which in the case I mentioned above is non-deterministic. >> (No one does this, and it isn't important. As long as you exponentially >> back off your probes, you hit a non-obnoxious interval relatively soon >> anyway. And the probes are hardly ever useful anyway.) But in my extreme situation above (which happened to me not so long ago) my active mail connection would back off to our maximum backoff 1,2,4...32,etc. and timeout before I had a chance to clean up the filesystem, thus freeing space so the Mach system could drain the TCP window allowing me to continue. Of course the problem was exaggerated by the fact that I was coming in over a 2400 baud line... Larry Backman backman@ftp.com  -----------[000234][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 14:37:33 GMT From: sgaras@brnwil.uucp (Sam Garas) To: comp.protocols.tcp-ip Subject: Using LAN manager 1.1 tcp-ip with FTP PC/TCP  I am trying to use HP's LAN manager 1.1 tcp protocol in conjuction with FTP's PC/TCP. I run into a conflict because of the two TCP protocols loaded at the same time. I can not run both of them at the same time. I was wondering if anyone has any suggestions on how to run PC/TCP and LAN manager 1.1 at the same time without running into any conflicts. Can this be done? Thanks ******************************************************************************** ###### ## # # Sam Garas R&D Software Specialist # # # # # # # Brown & Williamson Tobacco Corporation # # ## # # # 1600 West Hill St. ###### ### # # # Louisville, KY 40210 # # # # # # # # (502) 568-7903 # # # # # # # sgaras@brnwil.uucp ###### ### # ## ## coplex.com!brnwil!sgaras *******************************************************************************  -----------[000235][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 15:48:21 GMT From: fjr@sgfb.ssd.ray.com (Fred J. Roeber) To: comp.protocols.tcp-ip Subject: LANCE chip bug  I am not sure this is the correct news group but figured I would give it a try. We are using certain hardware cards for our ethernet network. These cards use the AMD LANCE chips for packet generation. What we are finding is that periodically the LANCE seems to hang and stops sending and receiving packets. In some cases, a software chip reset clears things up but in others only a HW reset will fix things. I have heard from others of rumors of similar problems. Indeed, I have noticed in the SGI ethernet driver that they have support for software access to the chip reset line and take a lot of care to work around "LANCE problems". What I am wondering is whether there is some known LANCE bug that causes these problems. I find it hard to believe that this would be the case since typical workstations don't seem to hang for this reason and I can't imagine that all the vendors drivers have the special error recovery stuff that SGI put in. Does anybody have any pointers on this subject. If people send to me I'll post a summary. Thanks in advance. Fred ______________________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr | |______________________________________________________________|  -----------[000236][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 15:50:16 GMT From: lyman@anduril.network.com (John R. Lyman) To: comp.protocols.tcp-ip Subject: Re: TCP FIN and window  It seems that the important thing to ask is how many times and how often will this out-of-window FIN be retransmitted. We certainly don't want to waste bandwidth retransmitting out-of-window data. IMHO it is better if no data is sent (including the FIN) into a closed window. Rather the probe mechanism should be used to prompt the receiver to open the window. As for processing an out of window FIN, its probably not worth the trouble unless all of the preceeding data has already been accepted. In which case an execption to the spec can be made for robustness. John Lyman  -----------[000237][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 16:06:58 GMT From: lr@cs.brown.edu (Luigi Rizzo) To: comp.protocols.tcp-ip Subject: Where can I find CSLIP code ?  The title says almost all... I'm working on some code that transfers IP packets on a (slow) serial line and would like to compress them before transmission. I think I some parts of CSLIP should work, does anyone know where can I find it ? Thanks Luigi ================================================================== Luigi Rizzo Brown University & Univ. di Pisa e-mail: lr@cs.brown.edu, luigi@iet.unipi.it ==================================================================  -----------[000238][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 16:47:38 GMT From: fc297303@seas.gwu.edu (jogle) To: comp.protocols.tcp-ip Subject: looking for references about the Internet  Hello... Can anyone point me to any references on the Internet, it's history, it's current configuration, etc? Is a map of the net available via ftp anywhere? Any help would be greatly appreciated. Please E-mail Thanks in advance,  -----------[000239][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 17:09:49 GMT From: jbvb@FTP.COM (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: high-level network analysis tools needed  That is, I want to measure transactions instead of packets. A transaction might be several packets which establish the connection, transfer the data, and acknowledgement of the data. Our LANWatch product comes with a program called TANA, which separates out all the TCP connections it can find in a dump file, and tells you the initial state, final state, number of packets, etc. We also provide source code, so you can modify it (using MSC 5.1 under DOS). James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901  -----------[000240][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 17:09:50 GMT From: jbvb@FTP.COM (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: Backups using rsh.  Why don't all distributed filesystems simply use TCP/IP for data communication? With any luck, we and Interstream (at least) will be demonstrating NFS over TCP at Interop. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901  -----------[000241][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 17:12:26 GMT From: anthony@IRENE.JPL.NASA.GOV (Anthony Martin) To: comp.protocols.tcp-ip Subject: TCP/IP for Vax VMS  To Whom It May Concern, I am looking for a TCP/IP product which will run on a MocroVaxII. Due to old historical software, we are unable to upgrade to current version of VMS and are at 4.6. DEC can't support us and we are looking for some TCP/IP software elsewhere. We have heard rumors that Carnegie-Mellon University has TCP/IP shareware which may work but have had no success in getting a point of contact. Any help or suggestions would be greatly appreciated. Anthony Martin (818)354-1580 anthony@irene.jpl.nasa.gov  -----------[000242][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 17:40:57 GMT From: brian@telebit.com (Brian Lloyd) To: comp.dcom.modems,comp.protocols.tcp-ip Subject: Re: Dialup IP and Telebit NetBlazer  FYI there is a mailing list, netblazer-users@telebit.com, where users of the NetBlazer discuss implementation and usage of the NetBlazer. Telebit and/or other users answer questions. Send mail to netblazer-users-request@telebit.com to subscribe. -- Brian Lloyd, WB6RQN Lloyd and Associates Network Architect 3420 Sudbury Road brian@telebit.com Cameron Park, CA 95682 voice (916) 676-1147  -----------[000243][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 18:44:00 GMT From: v130jarn@ubvmsb.cc.buffalo.edu (THE SHOTGUNNER) To: comp.protocols.tcp-ip Subject: tcp locations  Sorry to bug you all, but how do I get a comprehensive list of FTP sites?????  -----------[000244][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 19:19:23 GMT From: ragarwal@acsu.buffalo.edu (Rajesh S. Agarwalla) To: comp.protocols.nfs,comp.protocols.tcp Subject: Need information of documentation to NFS  Hi, I need to understand NFS to the very finest level of detail. Could anyone please give me information on good papers, books or any other material to understand NFS? If possible, please reply by email and I can then post a summary of all the responses I receive. Thank you very much. Rajesh -- Rajesh S. Agarwalla | (O): (716) 636-3772 Department of Computer Science | (R): (716) 833-8009 State University of New York at Buffalo | Buffalo, NY 14260 | Email: ragarwal@cs.buffalo.edu  -----------[000245][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 20:56:55 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: a minconfigured host  In article <9109091352.AA03752@NISC.SRI.COM> Y.Murayama@CS.UCL.AC.UK (Yuko Murayama, +44-71-387-7050 ext.3721) writes: > >If a host that is not a router is forwarding packets, then it is > >broken, but you already know that. The misconfigured host would be > >considered a router, and should obey all the rules of a router, > >including decreasing the TTL of a packet. If it is not decreasing the > >TTL, then it is broken. > >I understand that the misconfigured (i.e. ip.forwarding) host *should* >decrease the TTL. But my question is if it is quite so in the current >popular implementation, such as the IP on a UNIX system. The definition of a router is "a host that forwards packets between subnets", so your original question was poorly worded, since there's no such thing "a host that is not a router that is forwarding packets." But to answer your revised question, most IP implementations that include forwarding capability decrement the TTL when they do so. Presumably the intent of including the capability is to allow the host to be a router. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar  -----------[000246][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 23:17:31 GMT From: fitz@wang.com (Tom Fitzgerald) To: comp.protocols.tcp-ip Subject: Re: "Reverse Subnetting"  allebrandi@inland.com (Tom Allebrandi) writes: > The NIC has assigned our company 32 Class C network numbers. The > numbers were carefully chosen so that > What we would like to do is this: Pretend to be a Class B subnetwork by > using a netmask of 255.255.224.0 We tried this experiment here also, using a single Sun and a number of SCO UNIX machines (SysV). It also failed - the machines refused to accept a netmask with fewer bits than 255.255.255.0. Reading through the source for different TCP/IP packages, I decided it was doomed to failure - there is too much code that assumes that a different network can't possibly be part of the same subnet. Are there changes to the TCP/IP conventions in the works to make this possible? It'd certainly cut down on the demand for class B addresses. --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz  -----------[000247][next][prev][last][first]---------------------------------------------------- Date: 20 Sep 91 23:49:54 GMT From: BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) To: comp.protocols.tcp-ip Subject: Re: SLIP and PPP compared  > Basically, I don't know if PPP is more efficient than SLIP, Efficient in which respect ? effective throughput ? administration ? One thing left out in this discussion is that many users assume that PPP comes with "tcp header compression", and slip doesn't. In reality, a random slip implementation and a random PPP implementation are about equally likely to have header compression. BillW -------  -----------[000248][next][prev][last][first]---------------------------------------------------- Date: 21 Sep 91 05:12:40 GMT From: romkey@ASYLUM.SF.CA.US (John Romkey) To: comp.protocols.tcp-ip Subject: Using Wide-Area Point-to-Point Links for Computer Networking (I)  Date: 10 Sep 91 14:04:53 GMT Sender: <tcp-ip-relay@nisc.sri.com> From: decwrl!ucbvax.Berkeley.EDU!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!transfer!lectroid!jjmhome!crackers!cpoint!martillo (Joachim Carlo Santos Martillo) Organization: Clearpoint Research Corp., Hopkinton MA References: <2429@crackers.clearpoint.com>, <KARL.91Sep1171232@remora.MorningStar.Com>, <14455@cpoint.clearpoint.com> In article <14455@cpoint.clearpoint.com> martillo@cpoint.clearpoint.com (Joachim Carlo Santos Martillo) writes: >1) You have to turn on UDP checksumming if you connect two ethernets >by a bridge rather than a router. This should say: You don't have to turn on UDP checksumming if you connect two ethernets by a bridge rather than a router. Joachim Carlo Santos Martillo Ajami UDP provides an End-To-End checksum; you should *always* use it, especially when you cross physical network boundaries via computational devices. The UDP checksum will protect against corruption in places that the bridge or routing device may not. A packet in a bridge may be corrupted as it is transferred from ethernet chip to memory, or during other bus transfers, or by software failure after the ethernet CRC has been verified. Because the UDP checksum is end-to-end it can guard against such problems. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us voice: 617 942-0915  -----------[000249][next][prev][last][first]---------------------------------------------------- Date: 21 Sep 91 07:42:33 GMT From: jamin@caldera.usc.edu (Sugih Jamin) To: news.groups,comp.protocols.tcp-ip Subject: comp.protocols.research?  Hello, Is there a comp.protocols.research that is akin to comp.os.research but concerns itself with (inter)networking research? -- sugih Use e-mail, save a tree.  -----------[000250][next][prev][last][first]---------------------------------------------------- Date: 21 Sep 91 13:00:23 GMT From: tom@rs1.tcs.tulane.edu (Tom Gerace) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: IBM AADU and Clarkson packet drivers  We have an ethernet network of pc's, using a PS/2 running AIX as a file server. The workstations use file and print services by running IBM's AIX Access for DOS Users product (AADU). We also have the requirement to run TN3270 with Clarkson packet drivers concurrently. The problem that we've run up against is that the AADU package uses drivers of its own (PCINIT and NTY), and the Clarkson packet drivers cause conflicts. I know that a Novell solution was created with the -n switch in the Clarkson packet drivers, allowing both the Novell drivers and the Clarkson drivers to be in memory at once. Has anyone out there done the same thing with AADU and tn3270 that we are doing here? Can the two drivers use the one ethernet board concurrently? Thanks in advance for the help. Tom Gerace tom@rs1.tcs.tulane.edu Manager, Consultants Bureau (504) 865-5631 Tulane Computing Services Tulane University New Orleans, LA 70118 USA  -----------[000251][next][prev][last][first]---------------------------------------------------- Date: 21 Sep 91 13:03:21 GMT From: and@kaija.spb.su (Victor A. Andreenko) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: LOCUS PC/TCP for DOS and NE1000  Hi, We have Locus TCP-IP package for DOS, V1.0. Unfortunately driver for Ethernet card Novell NE1000 is absent in this distribution. All drivers in this package have named _*.drv_ and they are installed from _config.sys_ at boot time. We have some questions: 1) what type of driver used by this package ? Is some description of LOCUS TCP/IP drivers type ? 2) Can we use PDS, NDIS or other drivers NE1000 by some other ways ? 3) May we get LOCUS driver for NE1000 from anywhere ? Any information appreciable. Please send answers not only via USENET, but direct e-mail too. ----------------------------------------------------------------------------- Victor A. Andreenko e-mail internet: and@kaija.spb.su Independent affiliate "KAIJA" phone: office: +7 (812) 2941103 St. Petersburg (Leningrad) +7 (812) 2983700 Chernyshevskogo sq. 9, home: +7 (812) 2954347 SU-196128 , USSR  -----------[000252][next][prev][last][first]---------------------------------------------------- Date: 21 Sep 91 16:18:47 GMT From: romkey@ASYLUM.SF.CA.US (John Romkey) To: comp.protocols.tcp-ip Subject: Using Wide-Area Point-to-Point Links for Computer Networking (I)  Date: 12 Sep 91 19:39:42 GMT Sender: <tcp-ip-relay@nisc.sri.com> From: decwrl!uunet.uu.net!zephyr.ens.tek.com!cascade.ens.tek.com!mikes (Mike Skrydlak) If PPP does this, most customers will forgive it's flaws. And I believe they will view most criticisms at this point as 'Too little, too late'. That's life. Further: most customers care about functionality more than technical elegance. The Internet and TCP/IP community have changed over the years, and it's important to understand this. They are no longer just the hard code cadre of network hackers that got the whole thing going. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us voice: 617 942-0915  -----------[000253][next][prev][last][first]---------------------------------------------------- Date: 21 Sep 91 16:41:37 GMT From: rusek@pilot.njin.net (Robert John Rusek) To: comp.protocols.tcp-ip Subject: Novell 386 3.11 to Internet / Telnet / FTP  I have a Netware 3.11 server which I wish to connect to the internet. I require my workstations to be able to TELNET, FTP, and Mail to the internet. Does anyone know of a way to accomplish this. Thanks  -----------[000254][next][prev][last][first]---------------------------------------------------- Date: 21 Sep 91 17:18:44 GMT From: mjhammel@Kepler.dell.com (Michael J. Hammel) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Cc: mjhammel@kepler.dell.com, and@kaija.spb.su Subject: Re: LOCUS PC/TCP for DOS and NE1000  In article <9109211303.AA25796@kaija.spb.su>, and@kaija.spb.su (Victor A. Andreenko) writes: > Hi, > > We have Locus TCP-IP package for DOS, V1.0. Unfortunately > driver for Ethernet card Novell NE1000 is absent in > this distribution. All drivers in this package have > named _*.drv_ and they are installed from _config.sys_ > at boot time. > > We have some questions: > 1) what type of driver used by this package ? > Is some description of LOCUS TCP/IP drivers type ? > 2) Can we use PDS, NDIS or other drivers NE1000 by > some other ways ? > 3) May we get LOCUS driver for NE1000 from anywhere ? > > Any information appreciable. > > Please send answers not only via USENET, but direct e-mail too. I don't think the version 1.0 package contains a driver for that card. I have the version 2.0 package and it only supports the following cards: 3Com 3C503 3Com 3C501 3Com 3C523 MICOM NI5251 Western Digital WD8003 I know the version 2.0 and earlier packages do not support the NDIS or PDS specs. You might contact the following addresses to see if they can let you know if a driver for that card exists: support@locus.com uunet!locus.com!support Gee, I didn't know we could send mail to the USSR. I guess "Distribution: world" really means exactly that now. :-) Michael J. Hammel | mjhammel@{Kepler|socrates|feynman}.dell.com Dell Computer Corp. | {73377.3467|76424.3024}@compuserve.com #include <disclaim/std> | zzham@ttuvm1.bitnet ===Silly Saying Under Construction===  -----------[000255][next][prev][last][first]---------------------------------------------------- Date: 21 Sep 91 23:45:27 GMT From: martillo@crackers.clearpoint.com (Martillo) To: comp.protocols.tcp-ip Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)  In article <=lfcl#h@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >Granted that PPP has some protocol overhead which some people may regard as >random crap. The same may still be said about TCP/IP (have you ever read >RFC 1144?). >But the point is that lots of the stuff PPP does is actually necessary in a >heterogenous environment with possibly unreliable lower-level links. This statement is true only in the sense that some sorts of links require extra management, but it does not mean that such management is reasonably defined into the link level transport protocol. >To do reliable link setup and teardown, you need something like a state >machine, and if you don't want to impose unnecessary restrictions on what >equipment people are going to connect to your link and how they can configure >it, you better have option negotiation. The option negotiation should be part of a separate protocol. >Surprise: PPP's state machine is sufficiently general that its code >can be shared between protocols. The option negotiation may not be perfect, >but it works. But it is an example of PPP's misdesign that this stuff is even included in the main transport protocol. The option negotiation may actually be reasonable as long as it is properly treated as a separate protocol whose use depends on whether it is applicable. Option negotiation and authentication in some networks can reasonably take place out of band. >Plus, I still haven't found if you can do anything with Slithernet that >would be impossible, or even prohibitively more difficult, with PPP. 1) There is good evidence to believe that PPP is going to be incompatible with the latest generation of serial chips which support ether modes and with the latest generation of ether chips which support serial modes. 2) Only the bridging version of PPP contains sufficient information that sophisticated mesh topologies of serial links can be supported. Such mesh topologies are often desirable when seeking high reliability and availability in a network. 3) Unfortunately, the bridging version of PPP contains variable length goop in front of the MAC packet. Many microprocessors, like the AM29k or IBM ROMP (used in the RT/PC) have no real capabilities for dealing with multiple allignments of data. The Intel 80x86 microprocessors can handle multiple allignments of data, but will produce much lower performance when doing so. 4) PPP is rather inflexible in the following case: Serial P-to-P Router A ------------------ Router B describes the initial set up But it becomes desirable to replace one router with the following set up Serial P-to-P Ethernetwork Router A ------------------ Bridge --------------- Router B1 | | Ether | | Ethernetwork Router B2----------| |------------------Router B3 With PPP, it is necessary to reconfigure router A to generate PPP bridging packets or in fact get new software or a new router if router A does not happen to support PPP bridging formats. If SLITHERNET were used, no changes to router A would be necessary. >Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Joachim Carlo Santos Martillo Ajami  -----------[000256][next][prev][last][first]---------------------------------------------------- Date: 22 Sep 91 00:00:01 GMT From: pmanglik@tanj.intel.com (Pankaj Manglik) To: comp.protocols.tcp-ip Subject: unsubscribe  Please remove me from this list. Thanks. Pankaj  -----------[000257][next][prev][last][first]---------------------------------------------------- Date: 22 Sep 91 00:45:17 GMT From: geoff@FERNWOOD.MPK.CA.US (the terminal of Geoff Goodfellow) To: comp.protocols.tcp-ip Subject: Internet Commercialization BOF scheduled for INTEROP.  Thursday 9:15-11:15PM (Oct 10) (See INTEROP Program for location) Internet Commercialization Geoff Goodfellow President Anterior Technology/RadioMail In the last year increasing attention has been given to the commercial IP services market. The purpose of this BOF is examine the emerging market of "commercial" IP services. Representatives from the various commercial IP service providers will be present to answer your questions and to help clear the air in this emerging area.  -----------[000258][next][prev][last][first]---------------------------------------------------- Date: 22 Sep 91 01:12:58 GMT From: sfrazier@mcinix.vlink.COM (Steven E. Frazier) To: comp.protocols.tcp-ip Subject: SLIP 9.6 Sync vs Async  Is it possible to run SLIP on Sync modems? I have a chance to buy a couple of 9.6 Sync modems. I would like to run SLIP between two boxes and I was wondering if I could use the Sync modems or not, if so, how would I handle the connection from the Sync modem to the Async com port? Thanks in advance. Please email me your answers. Steve  -----------[000259][next][prev][last][first]---------------------------------------------------- Date: 22 Sep 91 08:21:09 GMT From: anthony@cco.caltech.edu (Lawrence Anthony) To: comp.protocols.tcp-ip Subject: Where to obtain CMU tcpip suite?  could someone please let me know where to obtain the CMU tcpip package? we are running a version of CMU tcpip that dates from 1988 on our vaxstations. if a more recent version exists, i would like to update our machines accordingly. please reply via e-mail unless you think this topic is of general interest. thanks in advance. lawrence anthony lza@ulysses.caltech.edu  -----------[000260][next][prev][last][first]---------------------------------------------------- Date: 22 Sep 91 12:46:00 GMT From: jbvb@FTP.COM (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)  You don't have to turn on UDP checksumming if you connect two ethernets by a bridge rather than a router. Our Tech Support people have seen many cases of corrupted files due to not using UDP checksums, even between hosts on the local Ethernet. Packets can get damaged on the I/O bus, or by defective Ethernet cards (or in the bridge, if it re-calculates the CRC), not just on the cable itself. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901  -----------[000261][next][prev][last][first]---------------------------------------------------- Date: 22 Sep 91 17:45:10 GMT From: backman@FTP.COM (Larry Backman) To: comp.protocols.tcp-ip Subject: Re: SQL Server and TCP/IP  >> >> We would like to run our SQL Server (from Microsoft) over TCP/IP >> protocols. We have installed TCP/IP from FTP Software on our OS/2 >> Server and tried to interface to the SQL Server program through >> NetBios. We were not able to make it work. >> Exactly what problems did you have? Did you contact us? >> We are told that SQL Server is using Named Pipes and will not interface >> to NetBios, but we can interface it directly to TCP/IP using a file >> called "sockets.dll". >> SQL server runs on top of Named Pipes which runs on top of Netbios which runs on top of TCP. Sockets.DLL is the API from an application to FTP Software's TCP protocol stack in OS/2. To confuse things even more; SQL Server uses Name Pipes but also uses 2 or 3 LANMAN API calls to enumerate & find things. Novell provided a Named Pipes's & Netbios DLL so SQL server would run over the Netware OS/2 Requestor. It did, but as I recall it was inadaquate due to inability to do resource location without the aforementioned LanMan API's. This could have been corrected by NOvell since I last looked (6/90). >> Has anybody installed SQL Server over TCP/IP yet ? Also where can we get >> a copy of this file "sockets.dll" ? >> Socket.dll is part of our standard PCTCP for OS/2 distribution. If I had to guess you are running over our 1.0 product which is almost a year out of rev. Here's what I suggest you do; * contact support@ftp.com (1-617-246-0920) with your problems * upgrade to our latest rev (PCTCP for OS/2 1.1PL1) * Get SQL Server running on either Lanman or Netware 1st. * Drop PCTCP for OS/2 into the equation While we have never tested SQL Server over TCP: we have extensively tested LANMAN over our Netbios. In theory (ha, ha, ha) since SQL server is a Lanman application, it should work. Larry Backman backman@ftp.com  -----------[000262][next][prev][last][first]---------------------------------------------------- Date: 22 Sep 91 20:40:11 GMT From: gmc@PREMISES1.QUOTRON.COM (Greg Christy) To: comp.protocols.tcp-ip Subject: NIT-based traceroute  Version 2.0 of traceroute can be found on ftp.ee.lbl.gov as tcpdump-2.0.tar.Z. Be sure to get and apply the patch found in tcpdump-2.0.patch-1 as well. Greg  -----------[000263][next][prev][last][first]---------------------------------------------------- Date: 22 Sep 91 21:32:37 GMT From: dab@BERSERKLY.CRAY.COM (David Borman) To: comp.protocols.tcp-ip Subject: Re: Speed of memory and fast networks (was: Need help selecting Enet cards)  > >Mr. Grandi has measured memory speed of the Vax 5830 at 16 MB/sec. And that > >means a maximum achievable TCP rate of less than 6 MB/sec. That isn't fast > >enough to justify hanging a 5830 on a gigabit network. And that's a long way > >from saturating an FDDI ring. > Put 10 IBM RS6000's on a HiPPI ring and it is full with data. > Other measurements have shown that 10 suns can fill FDDI with a transferrate > of 6MBytes/sec each. Totalling 60Mbytes/sec!! HiPPI is not a ring technology. HiPPI networks are made with crossbar switches. You set up and tear down individual connections through the switch. Seperate connections do not interfere with each other. (e.g., if you have a connection between machines A and B, and another connection between machines C and D, each connection can pump data through at the full 800 mbits/sec if it is able to...) So, a HiPPI network is not used as a backbone in the same sense that FDDI is used as a backbone... -David Borman, dab@cray.com  -----------[000264][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 01:01:30 GMT From: explorer@iastate.edu (Michael L Graff) To: comp.protocols.tcp-ip Subject: KA9Q PPP problems  I'm trying to connect with the campus network using a communications line which will eat ^s and ^q. I'd like to use KA9Q's PPP, but I'm having problems. Rather than run ~1.5 miles every five minutes or so, I thought I'd try it on two directly connected machines first, then modify the config files later to protect the special characters and write the dialer scripts. However, I've only established ONE connection in this manner. I mean, come on, direct connection? Must be in the config files... If anyone has gotten this type of thing to work, PLEASE mail me the config files used on both ends of the connection and dial scripts if handy. Thanks in advance, --Michael --  -----------[000265][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 02:46:49 GMT From: sandeep@schutz.ee.uts.EDU.AU (Sandeep Chandra) To: comp.protocols.tcp-ip Subject: Add to Mailing List  Hi, Will appreciate greatly if my name could be added to the mailing- list. My email address is : sandeep@ee.uts.edu.au Ta, Sandeep Chandra, Multimedia Group, Uni of Tech, Sydney, AUS +61 2 330 2353  -----------[000266][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 04:05:17 GMT From: erik@eab.retix.com (Erik Forsberg) To: comp.protocols.tcp-ip Subject: Re: cisco router performance (was selecting a fast ethernet card).  In article <12718250271.13.BILLW@mathom.cisco.com> BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes: > >To get back to the original question, on high throughput for PC Unix: >Van Jacobson has done a convincing proof that TCP can go over 6Mbit/sec. >(He tuned the TCP on a SUN 3/60, and got repeatable TCP data transfer >rates consistantly close to 9Mbit/sec. A sun 3/60 is not a blazingly fast >machine, though it does have a shared memory ethernet controller.) >There were some interesting results: > > 1) checksumming does NOT matter. The limiting factor is usually the > memory cycle time of the processor memory. Given a modern CPU > with some form of instruction cache, the checksum can be folded > into a data copy at zero cost. > > 2) The ethernet controller CHIP DOES matter. Going this fast means > that the wire will be full of data almost all of the time, and > collisions WILL occur between the systems sending data and the > ACKs the receiver has to send back. If the chip cannot reset > its packet pointers and whatnot quickly in the event of a collision, > it won't go as fast (This was the suspected reason that Intel's > 82586 ethernet controller had a lower peak performance than the > AMD Lance chip used in the 3/60). > > 3) The hardware matters. The 68k in the 3/60 was idle about 30% of > the time in 3/60. Why wasn't it less idle and going faster? > Well, because the Lance couldn't make use of the full bandwidth > of the memory - It takes an eternity (600 nS) to do a single > 16 bit memory transfer, and during that time, the 68k couldn't > access the memory either, so it sat idle. This goes to show that > a bus is only as fast at the device driving it. So EISA bus has > a bandwitdh of XXX Mbyte/sec - can your I/O device, DMA controller, > or CPU actually deliver or eat data that fast? > >Can a PC do 6Mbit/sec? I doubt it. Pre-Jacobson TCPs tend to go about >1Mbit/sec, and I don't think that anyone has made significant efforts to >incorporate the new theory into PC implementation. > Question was, can a PC do 6 Mbit/sec ? A 25 Mhz 386 AT class machine should be able to. A 25 Mhz Microchannel (PS2 model 80) using same software could easily do 9 Mbit/sec. What was the software ? It was an OSI protocol stack running OSI NETBIOS (old TOP NETBIOS) over class 4 transport, over CLNS over LLC on Ethernet (using Western Digital 16 bit cards and their NDIS drivers). A similar TCP/IP implementation should be able to go marginally faster due to less complex software required. But hardware performance is far more important. So I think we can expect to see those numbers in the future.  -----------[000267][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 09:44:41 GMT From: tb@Materna.DE (Torsten Beyer) To: comp.protocols.tcp-ip Subject: SO_KEEPALIVE  Hi Everybody, Just a short question: When switching on SO_KEEPALIVE on a tcp socket, how often does that connection get tested for beeing established ? cheers -Torsten -- Torsten Beyer mail : tb@Materna.DE Dr. Materna GmbH vox humana : +49 231 5599 225 Vosskuhle 37, D-4600 Dortmund fax machina : +49 231 5599 100 UNIX is a registered trademark of AT&T. AT&T is a modem test command  -----------[000268][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 11:58:19 GMT From: tom@ksr.com To: comp.protocols.tcp-ip Subject: (none)  Please, can someone help me get off this d*mn list!!!! || * * * * * ========= Tom Varga || * * * * ========= Kendall Square Research || * * * * * ========= 617-895-9415 || =================== tom@ksr.com || =================== uunet!ksr!tom || =================== N2UA @ KA1PEP ||  -----------[000269][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 13:10:30 GMT From: jbvb@FTP.COM (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)  The requirement for PPP is becoming part of the router requirements doc as well. Why muddy the water with another nonstandard? Clearpoint wants SLIDE et al. Because PPP doesn't do what bridges need; they want MAC addresses and 802.1 spanning tree connectivity. I don't know if their hope that hosts will implement it will ever come true, but the prospect of multi-vendor interoperability among half-bridges sounds like a good idea to me. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901  -----------[000270][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 13:54:00 GMT From: asnjiw01@ASNCEN.ASN.NET ("Janice Wolf") To: comp.protocols.tcp-ip Subject: Unsubscribe  Please remove me from the tcp-ip mailing list. If this is not the appropriate means of getting off the list, please send instructions to me at asnjiw01@asncen.asn.net. Thank you.  -----------[000271][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 14:01:20 GMT From: ginny@AIX.NIH.GOV (Ginny Vinton/1000000) To: comp.protocols.tcp-ip Subject: unsubscribe  Please unsubscribe ginny@aix.nih.gov  -----------[000272][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 14:18:41 GMT From: evan@IS.RICE.EDU (Evan R. Wetstone) To: comp.protocols.tcp-ip Subject: Re: udp on Internet Connection  > > > Hi All > > > > We are just about to get our connection to the Internet. We are planning > > to install a router of our own (CISCO) which we will use to keep > > unwanted traffic from our own network (and vica versa). I am wondering > > what functions we will loose (or what problems we will cause ourselves) > > if we prevent any UDP traffic between our local network and the > > Internet. > > You will loose domain name service. Some routing protocols use UDP. Just to > name a few. Don't filter all UDP. Yes, *PLEASE* do not filter all UDP. You can cause serious problems for your regional network if you do. We had a site that decided to filter out all incoming DNS requests from the outside. Unfortunately, there were (and possibly still are) a lot of semi brain-damaged implementations of name resolvers out there. Sun's implementation of DNS in NIS (nee YP) under 4.0 was one of them. It could handle a hard error (i.e. Non-existent domain), but it couldn't handle a soft error (i.e. no response at all). Like the Eveready rabbit, they keep going and going, trying to contact the nameservers as fast as they can. As time goes on, more and more hosts need to get information about that domain. More and more traffic flows across the T1. The routers start to bog down. Eventually, one of the links fails. The routes to that site start to flap. More sites try to contact the nameservers. The network begins to melt. It's not a pretty picture. Moral: If you shut off all UDP service into your net, your regional may shut your connection down to save the rest of the network.... -- Evan Wetstone Sesquinet Network Support  -----------[000273][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 14:19:04 GMT From: rwskubow@GRAND.WATERLOO.EDU (Rog Skubowius) To: comp.protocols.tcp-ip Subject: (none)  Please unsubscribe rwskubow@grand.{uwaterloo.ca, waterloo.edu} from this mailing list.  -----------[000274][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 14:42:19 GMT From: mark@telesys.ncsc.navy.mil (Williams) To: comp.protocols.tcp-ip Subject: Re: configuring ftp site  John Ackerman writes... > I'm trying to set up a minor ftp site and don't know what the standard > directory structure is that most anonymous users would expect. > > Also, our implementation of ftp doesn't (at least not yet) support a > user name of "anonymous". What alternative names are common for > anonymous ftp? > > Thanks. John, this is just an amateur's opinion, but if your TCP/IP documentation doesn't tell you how to set up an FTP server and the package doesn't support "normal" anonymous ftp, I think you should look at another TCP/IP. Setting up an FTP server is kind of risky and although my vendor's package (Sun) suggests not enabling anonymous ftp, it supports it by establishing the kind of restricted access space that people usually want to provide. An uncontrolled anonymous ftp capability allows people to read and write nearly any file on your system; this is surely not your objective. If you had a package that was supported the anonymous FTP server, it should tell you how to set it up. I really recommend going that direction. Anybody else got any comments? Mark L. Williams Head, Telecommunications Branch Code 7630 Naval Coastal Systems Center Panama City, FL 32407-5000 (904)235-5153 (mark@telesys.ncsc.navy.mil)  -----------[000275][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 14:43:30 GMT From: jra@lawday.DaytonOH.NCR.COM (John R. Ackermann) To: comp.protocols.tcp-ip Subject: POP2 - POP3 interoperability?  Will the Berkely POP3 server (as modified for SysV and WIN-TCP) work with POP2 pc clients? In particular, with the ka9q NOS pop client? -- John R. Ackermann, Jr. Law Department, NCR Corporation, Dayton, Ohio (513) 445-2966 John.Ackermann@daytonoh.ncr.com Packet Radio: ag9v@n8acv tcp/ip: ag9v@ag9v.ampr [44.70.12.34]  -----------[000276][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 15:05:12 GMT From: jbvb@FTP.COM (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: API for FTP?  Is there an application program interface to FTP... You don't say what operating system you're using. We developed such an API for DOS, and later ported it to OS/2. IBM implies they will offer something similar in their next release of their OS/2 product in November. I don't know of any others. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901  -----------[000277][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 15:05:13 GMT From: jbvb@ftp.com (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: TELNET & 3270 (tnv3270?) - Request For Information  I assume that they somehow map a 3270 data stream over a Telnet data stream? Yes. The data is in EBCDIC, with 3270 buffer orders, and the IAC EOR sequence is used to delimit blocks. Does, say IBM, supply a 3270/Telnet server which receives this data stream and directs it into the normal 3270 data path? All the mainframe TCP/IP packages include TN3270 clients and servers. Where the code winds up depends on the package. OpenConnect Systems (formerly Mitek) also has a gateway box that takes TCP/IP on one side and maps it to SNA on the other. The big advantage of TN3270 is that it is block mode; the alternative approach of converting the 3270 DS into VT100 escape sequences is compute-intensive whereever the conversion takes place (sometimes in the mainframe, otherwise in an outboard box), and creates much more traffic on the net as it simulates block-mode to a remote client. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901  -----------[000278][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 15:05:14 GMT From: jbvb@ftp.com (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: Trouble w/ Clarkson SLIP packet driver + PC/TCP  Unless you have a 16550 serial controller chip on your 386, Windows will make your PC drop far too many characters for decent SLIP performance. I don't think flow control will help. We've had good luck with current versions of the Clarkson SLIP8250 driver, which contains 16550 support in addition to the basic 8250. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901  -----------[000279][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 16:15:00 GMT From: OLSON@MV2.NSWC.NAVY.MIL To: comp.protocols.tcp-ip Subject: Unscribe  Please remove me from the tcp-ip mailing list.  -----------[000280][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 16:17:39 GMT From: gallager@bbn.com (Douglas Gallager) To: comp.protocols.tcp-ip Subject: Re: cisco router performance (was selecting a fast ethernet card).  Marco Hyman writes: Stop right there! 15000 packets/second is (approx) the Ethernet maximum. For those who want the math: Minimum frame length = 64 bits of preamble 64 bits 6 octet destination address 48 bits 6 octet source address 48 bits 2 octet type 16 bits 46 octet data 368 bits 4 octet FCS 32 bits ----------------- 576 bits The time to transmit this frame at 10 Mbit/s is 57.6 usec. Add to that the minimal interframe spacing of 9.6 usec and you can spit a frame out every 67.2 usec or 14880 (almost 14881) frames per second -- assuming one station is doing all the transmitting. Bill Westfield writes in response: > Exactly correct. The theorectical max doesn't change with multiple stations, > but you are more likely to have collisions which will interfere somewhat. > Still, studies (Boggs @ DEC) have shown that even with 20 stations trying > to transmit simultaneously, the usable badnwidth ofan ethernet is still > close to 10 Mbit/s. Certainly throughput changes when you change from 1 workstation to 2 or more workstations; with one you can't have any collisions, but with 2 or more you can. And as you say, the theoretical max doesn't change much as the number of workstations changes. But the maximum possible throughput you get from an ethernet (CSMA/CD) depends on a lot of things, including the propagation time between any two stations divided by the time it takes for a packet to be transmitted. (Since there are actually N*(N-1)/2 different distances between N workstations, this is actually a little bit more complicated than this, but you get the picture.) In other words, if all the workstations are connected by a very short cable, and they are sending each other maximum size packets, the throughput will be much higher than if they are connected by a very long cable, and they send each other minimum size packets. I also think you use the word "simultaneously" a little loosely. If all workstations are literally transmitting "simultaneously", then the throughput will 0. You mean that all are transmitting at random times, such that their aggregate rate is something less than 10Mbits/second. Doug Gallager  -----------[000281][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 16:20:36 GMT From: willis@cs.tamu.edu (Willis Marti) To: comp.protocols.tcp-ip Subject: Re: Router security features  kronos!richb (Rich Braun) wrote: Is it possible to implement a port-number-based TCP/IP security filter within a router? (This could be configured to only allow certain types of connects to go through, etc. Both cisco & 3COM provide such a capability. {We have cisco's, the campus likes IB-2000s}. I can't comment on the performance, but the functionality is there to do a great deal of filtering. It is *not* a total solution, but can contribute greatly to your 'firewall'. Cheers, ------------------------------------------------------------------------------- Willis F. Marti Internet: willis@cs.tamu.edu Director, Computer Services Group, Dept of Computer Science, Texas A&M Univ. ---Not an official document of Texas A&M---  -----------[000282][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 16:54:25 GMT From: hsw@COLUMBIA.SPARTA.COM (Howard Weiss) To: comp.protocols.tcp-ip Subject: Re: [alt.security] Re: "Open Systems Security" document available  I pulled over the tar file and sucessfully printed each of the document sections on a postscript printer (NEC 960) with no trouble. It looks like the A4 formatting causes you to lose the line numbers which were probably in a page header that did not get printed on 8.5x11 paper. Otherwise, the pages look fine. Howard Weiss SPARTA, Inc. 9861 Broken Land Parkway, suite 355 Columbia, MD 21046 phone: (301) 381-9400 x201 email: hsw@columbia.sparta.com  -----------[000283][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 17:38:27 GMT From: billh@hpcndpc.CND.HP.COM (Bill Hayes) To: comp.protocols.tcp-ip Subject: Re: Using LAN manager 1.1 tcp-ip with FTP PC/TCP  >I am trying to use HP's LAN manager 1.1 tcp protocol in conjuction >with FTP's PC/TCP. I run into a conflict because of the two TCP >protocols loaded at the same time. I can not run both of them at the >same time. I was wondering if anyone has any suggestions on how to >run PC/TCP and LAN manager 1.1 at the same time without running into any >conflicts. Can this be done? > >Thanks The two simple alternatives to solve this problem are: (1) Run LAN Manager over the RFC NETBIOS module provided by FTP, Inc and don't use HP TCP/IP. (2) Look at services that you need from PC/TCP and see if HP has a way to provide this capability with HP's LAN Manager client. Bill Hayes HP  -----------[000284][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 17:56:02 GMT From: shiao@ans.net (Dennis Shiao) To: comp.protocols.tcp-ip Subject: Introductory Material on FTP  I am looking for some pointers to introductory material on FTP (besides the man pages on a given system). The material should be geared towards relatively new users on the internet, who are not quite as aware of the many services available. Thus, the material would cover the basic commands of ftp, how to connect to a host, using anonymous ftp, etc. I tried looking for archives of this newsgroup in the following places, cs.dal.ca: /pub/comp.archives/comp.protocols.tcp-ip srawgw.sra.co.jp: /.a/sranha/arch/arch/comp.archives/.. ..auto/comp.protocols.tcp-ip src.doc.ic.ac.uk: /Usenet/comp.archives/auto/comp.protocols.tcp-ip but could not find anything subtantial. This leads to my second question: Is there an archive for this group ? And if so, where is it ? I tried looking for a FAQ as well, and turned up empty. Thanks in advance. Reply via e-mail is preferred. -Dennis. -- Advanced Network & Services, Inc. E-Mail: shiao@nis.ans.net 100 Clearbrook Road (914) 789-5340 Elmsford, NY 10523  -----------[000285][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 18:10:49 GMT From: richb@kronos.com (Rich Braun) To: comp.protocols.tcp-ip Subject: Re: cisco router performance (was selecting a fast ethernet card).  Just caught the tail end of this thread, from someone at Cisco. I'd say the Cisco router is by far and away the most popular (the only?) TCP/IP router product available, given the response to my query for info on low-cost routers. Well over half of my responses suggested the Cisco router, despite my request for bottom-line cost under US5,000. This latest thread, though, points out something that I've always felt about Cisco: they're a Rolls-Royce type of company, and I want a Volks- wagen. My desire is to go to management and say "I can get real-time, secure access to Internet for little money", not "I can route 22 megabytes of data per second on our corporate backbone". Is my impression inaccurate? Does this Acura Legend company also market a Honda Civic? -rich  -----------[000286][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 18:20:24 GMT From: alanlb@thorcs.vt.edu (Alan L. Batongbacal) To: comp.protocols.tcp-ip Subject: Can a node pick up stuff not its own?  I am involved in building a system that (hopefully) will listen in on arbitrary transmissions on an Ethernet. For the sake of simplicity, say that the machines on the network are all Unix machines running TCP/IP. Is there a way for a particular machine to listen in on transmissions meant for its brethren? -alan l. batongbacal -alanlb@vtopus.cs.vt.edu  -----------[000287][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 18:56:25 GMT From: marleyd@sumax.seattleu.edu (David Marley) To: comp.protocols.tcp-ip Subject: unsubscribe  Please remove me from this lisst  -----------[000288][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 19:02:53 GMT From: richb@kronos.com (Rich Braun) To: comp.protocols.tcp-ip Subject: Re: Increasing transfer size of SOSS - Can it be done ?  robert@swanee.ee.uwa.oz.au (Roberto Togneri) writes: > We have successfully been using SOSS to access our MOD drive from DOS. >However write access is exceedingly slow. Due in part to the MOD itself >but I also believe in part to the 1024 packet limit that SOSS imposes. NFS >uses 8192 bytes per packet (or burst?). Is there a way of recompiling SOSS >with a bigger packet size? Or is the problem deeper than that? If someone has a new publicly-available RPC library which can handle multi-packet requests and which compiles under DOS, I'd be happy to integrate it with SOSS. Single-packet RPC is a limitation of the existing one (it's pretty _old_). -rich  -----------[000289][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 19:56:29 GMT From: murky@hssi.dnet.hac.com (Gary A. Murakami) To: comp.protocols.tcp-ip,comp.sys.hp Subject: Looking for Stanford ethernet filter for HP  Need source for the Stanford Ethernet Filter. If it exists, I would like versions compatible with HP-UX but will settle for any version right now. I would like to find anonymous ftp site(s). Thanks. Gary A. Murakami murky@hssi.dnet.hac.com Hughes Training Inc. West Covina, CA "In life the only constant is change."  -----------[000290][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 20:03:23 GMT From: BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) To: comp.protocols.tcp-ip Subject: Re: Wanted:PD IBM PC Telnet/Ethernet terminal server s/w.  I have a friend who is interested in PD software to turn a IBM PC into a Telnet/Ethernet terminal server for (say) 20 terminals. Whats out there?. Do you have the hardware needed to connect 20 terminals to a PC? My guess is that in order to do that, you step well outside of the "mass produced" PC peripherals, lose the cost advantages of the PC platform, and would be just as well off buying a commercial terminal server from one of the many vendors that provide them. That said, you would probably want to start with the PD version of NCSA telnet for the IBMPC... BillW -------  -----------[000291][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 21:00:17 GMT From: debbie@pooh.sdd.trw.com (Debbie Salierno) To: comp.protocols.tcp-ip Subject: Help wanted on IP Datagram Reassembly  To whomever can help, I've been hunting around for an algorithm to handle IP datagram reassembly. Since I'm new to the TCP/IP world, I'm not sure how to handle the reassembly. I have been reading the Comer text books on how to handle fragmentation and they have been helpful but I need the source code or psuedo code so I can implement it on my machine. I have RFC 815 on "IP Datagram Reassembly Algorithm" but there is no pseudo code or enought detail for me to implement it with some confidence that it will work. What I'm looking for is a detailed algorithm for reassembly or the source code itself. If anyone can help, I would really appreciate a response. Thanks  -----------[000292][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 21:03:20 GMT From: jhc@iris.uucp (James H. Coombs) To: comp.protocols.tcp-ip Subject: Re: SO_KEEPALIVE  In article <tb.685619081@elwood> tb@Materna.DE (Torsten Beyer) writes: >Just a short question: When switching on SO_KEEPALIVE on a tcp socket, how >often does that connection get tested for beeing established ? The timing is implementation dependent. I had to patch the kernel in Apple's A/UX 1.1.1 to get the timings that I had when I started using keepalives with 1.1. I STRONGLY recommend that you implement your own connection testing. I have done so since, and the implementation is trivial. FYI. The original timings were something like 1 test a minute, with a timeout after 10 minutes of no response. I don't remember exactly what A/UX 1.1.1 gave me, but it was something like 2 days. --Jim  -----------[000293][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 21:20:22 GMT From: yeh@NETIX.COM (Shannon Yeh) To: comp.protocols.tcp-ip Subject: (none)  since the majority net users do not have control over the mailing lists-- to those who like to unsubscribe, the only thing I can do is to say "bye-bye"; to those who like to subscribe, the only thing I can do is to say "welcome". So, it is not absolutely important to copy the subscription/unsubscription requests to everyone. shannon ------- ------- Forwarded Message Return-Path: owner-ietf-smtp@dimacs.rutgers.edu Return-Path: <owner-ietf-smtp@dimacs.rutgers.edu> Received: from dimacs.rutgers.edu by netix.com (4.1/LLNL-1.18) id AA03207; Fri, 6 Sep 91 16:18:06 PDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11326; Fri, 6 Sep 91 18:49:40 EDT Received: from NETIX.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11314; Fri, 6 Sep 91 18:49:30 EDT Received: from localhost.netix.com by netix.com (4.1/LLNL-1.18) id AA03102; Fri, 6 Sep 91 15:47:56 PDT Message-Id: <9109062247.AA03102@netix.com> To: ietf-smtp@dimacs.rutgers.edu, ietf-tcp@nisc.sri.com In-Reply-To: Your message of "Fri, 06 Sep 91 17:13:31 EDT." <9109062113.AA05742@batman.sbi.com> Date: Fri, 06 Sep 91 15:47:50 PDT Sender: <tcp-ip-relay@nisc.sri.com> From: Shannon Yeh <yeh@netix.com> > Please unsuscribe me from the SMTP list group. If people like to subscribe or unsubscribe to/from a mailing list, I guess they could always tell mailing_list_name-request@domainname; if this doesn't work, I would recommend them to send a msg to the postmaster of the distribution host. Just a piece of suggestion. shannon ------- ------- End of Forwarded Message  -----------[000294][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 21:47:47 GMT From: debbie@pooh.sdd.trw.com (Debbie Salierno) To: comp.protocols.tcp-ip Subject: Need Help on IP header  To whomever can help, I've been trying to fiqure out whether IBM's AIX implementation of IP is wrong or me not understanding how it should work. Hopefully someone can enlighten me. The scenario is as follows: I'm sending a 2k buffer from one host to multiple host hooked up to an NSC intelligent bridge router. The router has a copy_to function which allows copies of the datagram to be made and sent out to certain hosts. Since I sent a 2k buffer, I assumed that IBM's implementation of IP would fragment the buffer so it would fit on a network frame. Since I'm sending thru ethernet the MTU is 1.5k therefore AIX would have to break up the buffer before sending it out to the destination host (correct I hope). Once the NSC router receives this datagram it envelopes it with a copy_to header and an IP header so it can be routed to the hosts which need this datagram. Since the router is routing thru ethernet, it doesn't need to break the datagram down any further. The application receiving this datagram receives the copy_to header, original IP header and the data in its buffer. The IP header above the copy_to header has been strip off by the IP protocol. Since the original IP header was modified due to the copy_to, IP won't handle the reassembly. My problem is with the data in the IP header possibly being incorrect. I received two datagrams with the following headers: datagram 1. 45 00 05 dc 3d 40 20 00 1c 11 00 00 64 9c 08 05 64 9d 08 04 04 0b 04 c4 07 d8 84 91 < data > datagram 2. 45 00 02 24 3d 40 00 b9 1c 11 00 00 64 9c 08 05 64 9d 08 04 < data > datagram 1. has a header length of HLEN=5 but it has 2 words worth of options should it be HLEN=7 and not HLEN=5? And if the header length should be 7 words is IBM implemenation of IP incorrect? According to what I have read, Header length has to be a minimum of 5 but can be larger depending on the option fields used. Is this correct? If the header length is correct, how can one tell where the data should start? datagram 2. has the correct header length of 5 and the data follows after the fifth word of header. If someone can help explain this problem, I greatly appreciate the help. Thanks  -----------[000295][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 21:51:07 GMT From: BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) To: comp.protocols.tcp-ip Subject: Re: Speed of memory and fast networks (was: Need help selecting Enet cards)  The argument put forth by my colleague is that memory speed on most computers is so slow that, when using a protocol like TCP which typically (most common implementations) touches memory at least three times (DMA into memory and copy from kernel to user space - I didn't count the checksum), high data rates to the application just aren't possible. This assumes that the DMA into memory and the kernel to user copy take their bytes from the same chunk of memory bandwidth. One would hope that any architecture designed for high I/O bandwidth would be able to do a lot of I/O into memory without having any effect on the processor's access to memory. For example, we measured the memory speed of a Vax 6310 at around 8 MBytes/sec. If memory is touched three times for a TCP connection, that means a maximum possible data rate of less than 3 MBytes/sec. So even if we have a HiPPI connection on this machine, we aren't going to do any better than 3 MB/sec. The number is suspicious (it works out to 1 (32 bit) memory transfer every 500 nS. While this might be typical for transfering data over a bus (an old bus, anyway), but sounds way wrong for "integrated" memory. Maybe the bcopy that you are using needs improving... I would also claim that if the bandwidth one gets from their network is the same as the bandwidth that one gets from their memory, then this IS a "high data rate to the application"). One might as well claim that gigabit networks are useless because they are faster than any existing disk drives, so what would be the point during FTPs. In fact, I'd go so far as to say that the entire point of very high speed networking is to remove the distintion between remote and local data. That isn't fast enough to justify hanging a 5830 on a gigabit network. Supporting a single 1G data stream is only one excuse for having a 1G network. Also inherent in such a network is the concept of multiplexing multiple streams. And there will always be computers too slow to take advantage of the full bandwidth of the network (or generic I/O devic they are connected to. That doesn't make that computer useless, nor does it mean that it should not be connected. I doubt whether anyone expected single hosts to use the full bandwidth of an ethernet during that development effort, and there are certainly hardware controllers that still do not permit this. So what? A good design for a network permits hosts to access them to the limit of their own abilities, perhaps based on other design criteria (There have certainly been more ethernet interfaces sold that will never do anywhere close to 10 Mbit/sec. At <300 each, this is not a problem...) BillW -------  -----------[000296][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 22:18:21 GMT From: lms@SSDS.SSDS.COM (L. Michael Sabo) To: comp.protocols.tcp-ip Subject: Re: Cabletron Support  Not to get a long chain going regarding whose customer support is good and whose is not - but I feel I must respond to the posting regarding Cabletron. We have had *excellent* support from Cabletron over the years. Their technical support has been both prompt and accurate. Also they listened to our needs for network management, for example, and we saw our requirements fulfilled in their SPECTRUM product. That's my two cents. P.S. BIG-LAN is a more appropriate forum for LAN "talk" and customer support issues are better left between customers and vendors. L. Michael Sabo SSDS, Inc  -----------[000297][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 91 23:27:09 GMT From: paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO) To: comp.protocols.tcp-ip Subject: Re: Sendmail  bmiller@CABELL.VCU.EDU (Bryan E. Miller) writes: >I have a question concerning "Apparently-to". When exactly should you >see this line in a mail header, as opposed to the normal "To:"??? If the message header block is missing the To: line, sendmail will add the Apparently-to: header. /pbp -- Paul Pomes, Computing Services Office | Good gun control is a two-handed University of Illinois - Urbana | grip, trigger control, and sight Email to Paul-Pomes@uiuc.edu | management.  -----------[000298][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 00:16:32 GMT From: jude@discovery.nas.nasa.gov (Jude A. George) To: comp.protocols.tcp-ip,comp.protocols.iso Subject: table of Internet site locations?  Is there available a table of Internet networks and their respective locations (latitude & longitude, or city name, or zip code, or whatever)? I know that such location information is available for UUCP sites, since each UUCP site must have a phone number. For wide area networks, (e.g. 35.0.0.0), a location for each router would be needed. This information will be used by a network management system we are developing in-house. Jude George Computer Sciences Corporation NASA Ames Research Center  -----------[000299][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 00:38:31 GMT From: pwb@newt.phys.unsw.oz.au (Paul W. Brooks) To: comp.protocols.tcp-ip Subject: Re: Duplicate/old mailings  In article <9109191855.AA02165@NISC.SRI.COM>, 08071TCP@MSU.EDU (Doug Nelson) writes: > Is NISC.SRI.COM having trouble getting mail out to the TCPIP list? I am > receiving frequent multiple copies of letters, and letters that are up > to two weeks old. > I seem to be getting lots of duplicate messages, in many newsgroups, not just comp.protocols.tcp-ip, and through Internet News, not the mailing lists. I thought maybe our newsreaders were broken after a recent OS upgrade! - anybody know where they are coming from? Paul Brooks |Internet: pwb@newt.phys.unsw.edu.au Uni. of N.S.W. |If you have trouble sleeping, try lying on the end of Kensington NSW 2033| your bed. With a little luck you'll drop off. AUSTRALIA | - Mark Twain.  -----------[000300][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 01:21:25 GMT From: jra@lawday.DaytonOH.NCR.COM (John R. Ackermann) To: comp.protocols.tcp-ip Subject: POP2 Server for SVR3/WIN-TCP needed  Well, I've found out that POP3 <isn't> a superset of POP2, and the nice POP3 server I just got running isn't going to do me any good. Can someone point me to a POP2 server that'll work on SVR3 with WIN-TCP, or can reasonably be made to do so... Thanks, John -- John R. Ackermann, Jr. Law Department, NCR Corporation, Dayton, Ohio (513) 445-2966 John.Ackermann@daytonoh.ncr.com Packet Radio: ag9v@n8acv tcp/ip: ag9v@ag9v.ampr [44.70.12.34]  -----------[000301][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 01:24:35 GMT From: Christopher-Vance@adfa.oz.au (Christopher JS Vance) To: comp.protocols.tcp-ip Subject: Re: routing problem from hell  | >>The root of the problem is that my router sits on subnet 78 and the router | >>to the AAA.BBB.CCC.0 network sits on subnet 10. When I try to add a route | >>sun-router>> route add net AAA.BBB.CCC.0 XXX.YYY.10.1 1 add net | >>AAA.BBB.CCC.0: gateway XXX.YYY.10.1: Network is unreachable | > | >This is correct. XXX.YYY.10 is not in your subnet. I don't seem to have the original article, to follow it up directly, so I'm trusting somebody else's quote. But I think we have a solution to a related problem: What we have is a campus-wide class B network with a number of bridges to make things look unified without subnets. But we also have a couple of real class C size subnets. outside world -- router ------------\ D.E.1.16 | | |--------- apollo ---- ring D.E.51.0 | D.E.1.12 D.E.51.3 | | | |---------- sun ---- ethernet D.E.31.0 | D.E.30.20 D.E.31.1 | | other hosts ------------/ D.E.F.G (F != 31, F != 51) Most hosts on campus are totally unaware of the use of subnets. All hosts on the two subnets use a network mask of 255.255.255.0 on both sides of their gateways. All hosts use static routing, mostly: localhost localhost D.E my ethernet address default D.E.1.16 The non-gateway hosts on the two subnets use localhost localhost D.E.F my external address default my D.E.F gateway The point now, is that the two gateways are different, the apollo uses: localhost localhost D.E.51 D.E.51.3 ring D.E.1 D.E.1.12 backbone ethernet default D.E.1.16 which works, because the campus router is on the same [sub]net as the ethernet interface of the host. The other sun gateway must use localhost localhost D.E.31 D.E.31.1 ether subnet D.E.30 D.E.30.20 backbone ethernet default D.E.30.21 But there is no host D.E.30.21. This works because we have a friendly host export an ARP entry for this IP address which has the ethernet address for the router D.E.1.16. Perhaps we could tell the router to recognise this as an alternative IP address for itself on the save interface as D.E.1.16, but I don't drive that machine, so I can't tell you. Why this kludge? There are multiple hosts on D.E.30.* which all think the campus has no subnets. Why is the other network different? They have no hosts except those on their subnet. The other part of the solution is a proxy ARP server which ensures that requests from non-subnetted hosts for ethernet addresses of hosts on D.E.31 and D.E.51 get given the ethernet addresses of their respective gateways instead. -- Christopher  -----------[000302][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 03:23:41 GMT From: mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) To: comp.protocols.tcp-ip Subject: Re: POP2 - POP3 interoperability?  In article <1991Sep23.144330.25972@lawday.DaytonOH.NCR.COM> jra@lawday.DaytonOH.NCR.COM (John R. Ackermann) writes: >Will the Berkely POP3 server (as modified for SysV and WIN-TCP) work >with POP2 pc clients? In particular, with the ka9q NOS pop client? POP2 and POP3 are quite different protocols. In particular, POP3 is *not* an extended version of POP2. The IMAP2 distribution (FTPHOST.CAC.WASHINGTON.EDU, imap/imap.tar.Z or imap/new-imap.tar.Z for the latest) includes both a POP2 and a POP3 server. The code is for BSD, but it shouldn't be too hard to port to SysV as long as you have inetd. -+-+- | -++- --|-- /__ Mark ("Gaijin") Crispin "Gaijin! Gaijin!" +-|-|-+ -+-++++ +-|-+ / / R90/6 pilot; DoD #0105 "Chigau. Omae ha gaijin." +-+-+-+ |\|||| |===| / / Atheist & Proud "Iie, boku ha nihonjin." --|-- /| |/\| -+===+- /\ (206) 842-2385/543-5762 "Souka. Yappari gaijin!" /|\ | |__| / \ / \ FAX: (206) 543-3909 Hee, dakedo UNIX nanka wo tsukatte, umaku ikanakute mo shiranai yo.  -----------[000303][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 05:16:00 GMT From: romkey@ASYLUM.SF.CA.US (John Romkey) To: comp.protocols.tcp-ip Subject: re: API for FTP?  There exists no general API for the FTP protocol. While I was at FTP Software, I created one for an FTP library that's a part of PC/TCP. It's documented in their Dev Kit, for which I believe you can even buy the documentation separately (but which is not available online). Of course, the only FTP implementation I know of that conforms to it is the one in the devkit, as well, so that's probably not very helpful to you. You can probably figure out ways to drive most UNIX and some DOS FTP's from scripts, if you need to, or (under UNIX) fork an FTP client and set up pipes for its stdin and stdout and read and write commands and responses to it. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us voice: 617 942-0915  -----------[000304][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 09:25:19 GMT From: martillo@AZEA.CLEARPOINT.COM (Joachim Carlo Santos Martillo) To: comp.protocols.tcp-ip Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)  > From: martillo@azea.clearpoint.com (Joachim Carlo Santos Martillo) > Date: Sun, 22 Sep 91 11:26:07 EDT > X-Mailer: ELM [version 2.2 PL14] > > 4) PPP is rather inflexible in the following case: > > Serial P-to-P > > Router A ------------------ Router B describes the initial set up > > But it becomes desirable to replace one router with the following > > set up > > Serial P-to-P Ethernetwork > > Router A ------------------ Bridge --------------- Router B1 > > | | > > Ether | | Ethernetwork > > Router B2----------| |------------------Router B3 > > With PPP, it is necessary to reconfigure router A to generate > > PPP bridging packets or in fact get new software or a new router > > if router A does not happen to support PPP bridging formats. > > If SLITHERNET were used, no changes to router A would be necessary. > > >Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ > > Joachim Carlo Santos Martillo Ajami > > You seem bent on sticking bridges in the middle of things. Sobeit. > > That is not how I build networks but I tend to have a rather narrow > > view of things :-). > Often there is no choice, our building is wired for for TWIP and > thin-wire ethernet with cables beginning in the telecommunications > closet and terminating in offices. This arrangement is quite common > in large corporate networks. > How does this preclude the use of routers? Because cabling and the wiring closet might be the responsibility of Telecommunications, and they might not want Engineering or R&D equipment in areas which they control. And their position is not unreasonable. Suppose MIS does not run IP based software. Therefore, their offices must be connected by bridges or repeaters in the wiring closet. If Engineering and R&D offices are connected by IP routers, when offices are changed, there is a rewiring nightmare. But suppose everyone used IP based software. Suppose Engineering and R&D had about 120 machines on three subnetworks with about 40 machines on a given subnetwork which corresponded to a single thinwire coax cable. Now rather than being connected to a single coax cable, each of these machine is connected to a wire which terminates in the wiring closet. Now I suppose, you could use several IP routers to route among 40 networks, but having a single machine per network is fairly silly (and low performance given that IP is actually designed to be efficient when a relatively large number of machines are connected to a relatively smaller number of machines). You could use a several multiport repeater to connect 40 ethernets, but there is no real growth possibilities here because repeaters quickly increase the effective length of an ethernet to the maximum. You could even use a combination of multiport repeaters and IP routers, But that would mean subdividing our subnetworks into smaller subnetworks and they might work well right now. Also the larger the number of subnetworks the more work routers have to do, and performance will go down. There really is a use for bridges in such environments as described which are quite common in large corporate networks. And anyway this claim "I don't build networks with bridges" is simply prejudice. IP routers do one thing very well. They route between IP subnetworks very well. They do not route frames very well within an IP subnetwork (and in fact can't). Now the issue of routing within an IP subnetwork is not important with LANs because LANs have very simple broadcast communications subnets and use packet filtering at the individual hosts which receive all packets. However, such communications subnets are inherently low performance because communication between one pair of hosts preclude communications between any other pair of hosts (not precisely true on some ring networks where communication between just a subset of the ring hosts would be precluded). Such communications subnets are also security nightmares because all hosts hear all packets. High performance and secure communications subnets use meshes of packet switches. It happens that we call these packet switches MAC bridges when the interconnection technology is ethernet but the terminology does not change the function which is being performed. > Muliport Bridges are used as hups to create single logical ethernets > from multiple separate physical ethernets. This set up is > topologically convenient, and eases management and increases > availability (if someone kicks or unterminates his connection, only > his segment becomes unusable). > A router will do the same thing. No this is incorrect, an IP router is very good at routing traffic among IP subnetworks. A properly designed PSN (Packet Switch Node) (aka MAC bridge) can give high performance frame routing between end hosts with added security as a bonus. > Repeaters could have been used but our traffic load is simply too high > for repeaters to be a reasonable way of achieving connectivity. > Routers are not really a reasonable solution unless each office > ethernet is to be a separate subnetwork. > I agree but you can still use a router. Only for a few special case architectures. > Joachim Carlo Santos Martillo Ajami Joachim Carlo Santos Martillo Ajami  -----------[000305][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 09:46:57 GMT From: jcross@ec.uwa.oz.au (Jennifer Cross - pgmr) To: comp.protocols.tcp-ip Subject: Re: Speed of memory and fast networks (was: Need help selecting Enet cards)  booloo@lll-crg.llnl.gov (Mark Boolootian) writes: >I guess what I'd like to know and hear comments on is whether there are any >architectures out there (other than Cray/Fujitsu/NEC) that can actually take >advantage of high-speed networks (FDDI and up)? >Mark Boolootian booloo@lll-crg.llnl.gov +1 415-423-1948 Just a thought... Many of the specialised (read non unix) systems out-there use more direct memory systems. For a (possibly trivial) example the Amiga OS uses systems messaging by passing pointers to memory (inherently dangerous I admit, but Very fast). The current (latest) Amigas are running a 68040 with 0-16Mb Static ram and 8-64Mb dram (direct to processor - not on an external bus). The memory speeds on these systems are very impressive - not that you could _effectivly_ use this type of bandwidth out to a "normal" amiga i/o device but ideal for memory mapped (anywhere in any process's address space) i/o. when required, the OS simply passes pointers to memory structures between processes (no copying - ever). On the amiga this only work because their is NO address space protection. I think protected memory which allows this type of multiple allowed readers/writers are being implimented for the new(er) distributed data boxes - where all storage appears as memory (100% virtual). I own an Amiga for fun, use SUN, SGI, PC, MAC for work. -- ___ ( > /) (voice) +61 9 362 6680 __/_/> ____ ____ o // _ __ (home) cjcross@DIALix.oz.au / / (__/ / <_/ / <_<_//__</_/ (_ @ Beautiful Perth, Western Australia <_/ /> (work) jcross@ecel.uwa.oz.au </ (voice) +61 9 380 3879  -----------[000306][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 09:47:55 GMT From: gsb1@forth.stirling.ac.uk (Mr Gordon S Byron) To: comp.protocols.tcp-ip Subject: Duplicate/old mailings  Hi Doug. I haven't removed the direct address to you so you should get this addressed to yourself and again as a member of the list. I assume you will therefore recieve 3 mailings of this. I'm getting duplicate mailings. Somebody emailed yesterday saying the same thing was happening to them. One of the dupolicate examples always has Sender:tcp-ip-request@uk.ac.nsfnet-relay...I suspect the problem may be there. The first of the two mailings always had, as one would expect, Sender: tcp-ip-relay@com.sri.nisc. I mentioned this via email to somebody(sorry, forgot name) concerned with administering the list. I believe it may take some days to rectify. _______________________________________________________________________________ Snailmail: Gordon Byron, Arts Computing Advisor,Pathfoot Building, University of Stirling,FK9 4LA Stirling, Scotland, UK. Voice: 0786 67266 Fax: +78651335 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  -----------[000307][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 11:27:56 GMT From: koelman@issun3.stc.nl (Ton Koelman) To: comp.protocols.tcp-ip Subject: Re: Help wanted on IP Datagram Reassembly  In <28DE55E1.1457@deneva.sdd.trw.com> debbie@pooh.sdd.trw.com (Debbie Salierno) writes: > I've been hunting around for an algorithm to handle IP datagram >reassembly. Since I'm new to the TCP/IP world, I'm not sure how to >handle the reassembly. I have been reading the Comer text books on how >to handle fragmentation and they have been helpful but I need the source >code or psuedo code so I can implement it on my machine. > I have RFC 815 on "IP Datagram Reassembly Algorithm" but there is no >pseudo code or enought detail for me to implement it with some confidence >that it will work. What I'm looking for is a detailed algorithm for >reassembly or the source code itself. If anyone can help, I would really >appreciate a response. Comer Volume 2 contains enough detail, I would think. Phil Karn's ka9q also has the reassembly code. You can also look at the BSD code (on uunet.uu.net) Ton K. koelman@stc.nl  -----------[000308][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 12:34:07 GMT From: marikar@digrev.UUCP (Mo) To: comp.protocols.tcp-ip Subject: Unsubscribe  Please take me off them mailing list. Mo Marikar Digital Review  -----------[000309][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 13:02:23 GMT From: bersee@nikhef.nl (Josefien Bersee) To: comp.protocols.tcp-ip Subject: rectification dates 3rd JENC  ************* RECTIFICATION ************* We regret that a mistake has crept into the announcement of the "Third RARE Joint European Networking Conference" Please note that it will be held from Monday 11 - Thursday 14 May 1992 in Innsbruck, Austria (instead of 12-15). Please accept our apologies for any inconvenience this may have caused. Josefien Bersee RARE Secretariat  -----------[000310][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 15:13:53 GMT From: dxe@cassidy (Dan Ellsweig - Network planning) To: comp.protocols.tcp-ip Subject: MVS-TCP/IP  Greetings fellow netters..... We here at Salomon Brothers have begun to investigate the offerings by IBM which place IBM at the fringe of the distributed processing environment as we know it. Specifically, the offering which opens the entire IBM product line by allowing TCP/IP interconnect. I am wondering if there are network users out there who may have specific experience ( good and bad ) in using the IBM TCP/IP products - MVS-TCP/IP in particular. We are interested in using the FTP, NFS, SNMP, Mail and MVS socket libraries. All input is welcome!!!!!! In addition, any information regarding future products such as the CICS-TCP/IP interface or information on IMS access via TCP/IP would be welcome. Thanks -- ***************************************************************************** Dan Ellsweig ** Salomon Technology Services ** dxe@cassidy.sbi.com ** Route 3 East Rutherford, N.J. ** *****************************************************************************  -----------[000311][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 15:46:56 GMT From: rpcfod@nimbus@UUNET.UU.NET (Robert Patt-Corner) To: comp.protocols.tcp-ip Subject: SLIP Addressing Issues  I'd like to check an assumption out ... We're trying to set up SLIP access to a mostly ethernet network. I'm under the impression that IP addresses belong to interfaces, not to hosts. Thus to set up the addresses we'd use, for instance our class B address for the ether: 138,219.x.x And perhaps a class C for the SLIP. To do the routing we'd need to find an IP implementation that permits assigning (on a single host) an address from the ether netrange to the ethernet card and from the SLIP range to the async port. Is this correct? If so, then does this rule out (for the router) packages like KA9Q and its derivatives, which firmly believe in one host, one address? Anybody do it with WIN/TCP for VMS?  -----------[000312][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 16:12:20 GMT From: thomson@hub.toronto.edu (Brian Thomson) To: comp.protocols.tcp-ip Subject: Re: Need Help on IP header  In article <28DE6104.15DD@deneva.sdd.trw.com> debbie@pooh.sdd.trw.com (Debbie Salierno) writes: > > I've been trying to fiqure out whether IBM's AIX implementation of IP >is wrong or me not understanding how it should work. Hopefully someone can >enlighten me. > > The scenario is as follows: > >I'm sending a 2k buffer from one host to multiple host hooked up to an NSC >intelligent bridge router. The router has a copy_to function which allows >copies of the datagram to be made and sent out to certain hosts. Since I >sent a 2k buffer, I assumed that IBM's implementation of IP would fragment >the buffer so it would fit on a network frame. Since I'm sending thru >ethernet the MTU is 1.5k therefore AIX would have to break up the buffer >before sending it out to the destination host (correct I hope). Once the >NSC router receives this datagram it envelopes it with a copy_to header >and an IP header so it can be routed to the hosts which need this datagram. >Since the router is routing thru ethernet, it doesn't need to break the >datagram down any further. Actually, it might have to since it may be adding extra headers to an already maximally-sized Ethernet packet. However, this second-level fragmenting should be invisible to you, because it will be occuring in the router-to-destination datagram, not in the envelopped datagram. >The application receiving this datagram receives >the copy_to header, original IP header and the data in its buffer. The >IP header above the copy_to header has been strip off by the IP protocol. >Since the original IP header was modified due to the copy_to, IP won't handle >the reassembly. My problem is with the data in the IP header possibly being >incorrect. I received two datagrams with the following headers: > >datagram 1. 45 00 05 dc 3d 40 20 00 1c 11 00 00 64 9c 08 05 64 9d 08 04 > 04 0b 04 c4 07 d8 84 91 < data > > >datagram 2. 45 00 02 24 3d 40 00 b9 1c 11 00 00 64 9c 08 05 64 9d 08 04 > < data > > >datagram 1. has a header length of HLEN=5 but it has 2 words worth of options > should it be HLEN=7 and not HLEN=5? And if the header length > should be 7 words is IBM implemenation of IP incorrect? According > to what I have read, Header length has to be a minimum of 5 but > can be larger depending on the option fields used. Is this > correct? If the header length is correct, how can one tell where > the data should start? > >datagram 2. has the correct header length of 5 and the data follows after > the fifth word of header. > I don't understand why you believe those 8 octets are options. They don't look like any kind of IP options I am familiar with. On top of this, the IP offset and length numbers make sense only if they are data rather than options. Eg., fragment 1: offset 0 more fragments length 5DC = 1500 decimal fragment 2: offset B9 = 185 chunks length 224 = 548 decimal Now if frag 1 really has a 5 word header, its data length is 1480 octets. Meanwhile, frag 2's offset is 185 * 8 = 1480 octets. It adds up. There is something funny about the total data length, though, if you really are sending 2K = 2048 octets of data in the datagram, because the way it looks now total data length is 1500-20 + 548-20 = 2008. It would be useful to know which 40 are missing. If something is being trashed here, it isn't clear whether it is AIX or the router that is at fault. The router does seem to be zeroing the IP checksum (which is not good!) of the copied fragments, so it might be messing around with other things too. You should try to eliminate one possible source of errors, by checking what the fragments look like before the router munges them. A lan analyser is the best tool for this. -- Brian Thomson, CSRI Univ. of Toronto utcsri!uthub!thomson, thomson@hub.toronto.edu  -----------[000313][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 17:02:45 GMT From: lms@SSDS.COM (Michael Sabo, Denver) To: comp.protocols.tcp-ip Subject: Cabletron Customer Support  > Does anyone else have comments about Cabletron's product support. Not to start a long chain regarding whose customer support is good and whose isn't - yet I feel I must respond regarding customer support I have received from Cabletron over the years. Simply put I have received superior service. Their responses to my questions have been immediate and accurate. Cabletron has been one of the few companies who listened to our needs and incorporated these into subsequent product offerings. This was especially true during the development of their network management platform SPECTRUM. L. Michael Sabo SSDS, Inc. P.S. Perhaps the BIG-LAN news group would have been a more appropriate forum regarding LAN questions.  -----------[000314][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 17:53:26 GMT From: fxs@stowe.UUCP (Fran Sullivan) To: comp.protocols.tcp-ip Subject: Please change distribution.  Could you change my distribution address from fmrco!fxs@uunet.uu.net to fmrco!stowe!tcpip@uunet.uu.net I would like to distribute this to a larger following within my company. Thanks, |\/\/\/| * Fran Sullivan | | * fmrco!fxs@uunet.uu.net | | * Sun Tech Support | (o) (o) * Fidelity Information Systems C _) ...Hey Dude! * Boston, MA 02109 | __| * ( 617 ) 570-2762 | / / \ / ---- \  -----------[000315][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 18:10:48 GMT From: markb@giga.slc.unisys.com (Mark Baranowski) To: comp.protocols.tcp-ip Subject: Is MX-ing the domain-name legal?  Hello; Suppose I have a domain named: sub.domain.edu And suppose I have the following hosts inside of this domain: host1.sub.domain.edu host2.sub.domain.edu host3.sub.domain.edu Is it legal to have an MX record so that mail can be sent to the domain name rather than to a specific host? For example: sub.domain.edu. IN MX 20 host2.sub.domain.edu. The intent here would be for host2 to act as the domain's mailhost and for the from-line on outgoing mail to read "user@sub.domain.edu" so that the outside world would not be aware of hosts 1, 2, or 3. The reason for my question is that I have been told that the above configuration violates the RFC for DNS. Yet I have seen many domains on the Internet configured in a similar manner! Thanks. -- markb@slc.unisys.com, markb@signus.elen.utah.edu, ...!giga!markb "WERE THERE ALIENS ON THE MOON WHEN THE ASTRONAUTS LANDED?" -- National Enquirer headline  -----------[000316][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 19:39:11 GMT From: krishna@cs.albany.edu (Krishnakumar K.) To: comp.protocols.tcp-ip Subject: Distributed file systems and TCP  In article <9109201709.AA24932@ftp.com> jbvb@ftp.com writes: > > Why don't all distributed filesystems simply use TCP/IP for data > communication? > Overhead!! It is quite clear that distributed file systems can live very well without TCP. In most cases (if not all) the reply to the file system call acts as the acknowledgement also and this renders the specific ack to the call as required by TCP unnecessary. In most distributed file systems completion of the call is the responsibility of the client and so the client can always make an extra call in case of a lost reply. Things being so, I feel that distributed systems are well off without TCP and the extra traffic. >With any luck, we and Interstream (at least) will be demonstrating NFS over >TCP at Interop. > Isn't NFS good enough with just UDP? Krishnakumar K. dept. of CS SUNY Albany email: krishna@cs.albany.edu  -----------[000317][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 20:17:24 GMT From: jca@crash.cts.com (John C. Archambeau) To: comp.protocols.tcp-ip,comp.unix.sysv386,comp.ibm.pc.hardware Subject: 3-Com boards  I have access to a pair of 3-Com boards that I plan on using. Problem is that I have no documentation on the boards for jumper setting the port address and memory address of the board. Nor do I have a disk with MS-DOS drivers. The boards are either 3C501's, 3C502's or 3C503's. The boards are identical, but one has a boot prom that says on it, "3C502 EtherStart V. 1.1." I plan on using one board in a Compaq 286 with an Intel Inboard/AT and one (for now) in a 386SX/20 (Orchid Motherboard). Both systems will be running ISC 2.0.2. The Unix may be upgrade to ESIX R4 later down the line. I would appreciate any information one may have on configuring the jumpers for the boards. Later down the line, one of the 3-Com boards will be replaced with a WD8003E or WD8013E and the 3-Com board will be put into an XT clone running PC/IP or Karn's KA9Q. Also, any documented problems with using these boards and how to get around them would be most appreciated. Thanks, JCA -- /* ** ARPA : crash!jca@nosc.mil ** INTERNET: jca@crash.cts.com ** UUCP : {nosc ucsd hplabs!hp-sdd}!crash!jca */  -----------[000318][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 20:36:23 GMT From: yongwang@eng.auburn.edu (Yong Wang) To: comp.protocols.tcp-ip Subject: unsubscribe  Please unsubscribe me from the list. ---yongwang@eng.auburn.edu  -----------[000319][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 21:15:06 GMT From: goldstein@delni.enet.dec.com (Fred R. Goldstein) To: comp.protocols.tcp-ip Subject: Re: Need help choosing PCROUTE/KA9Q/SLIP/PPP/V.32bis/V.42bis...  In article <F8758C8B3AC0E582@Arizona.edu>, JOHNGALT@CCIT.ARIZONA.EDU (John Galt) writes... >... I called our local phone >company, US West, and requested that the line be put in. WELL, they told >me that the price had gone up on July 15. Originally, the line was to cost >~740.00 to install and then 180.00 per month (this is for a 56K line). As >of the price increase, however, the installation cost is 1000.00 and the >monthly charge is 720.00!!!!!!! > >Flame on. >This is a 400% increase! I thought deregulation was supposed to stop this >kind of thing! I may have to blame it on our local "Arizona Corporation >Commission" which seems to be a rubber stamp regulatory organization. >Flame off. Just as a hunch, did you order "DDS 56K" service? In many cases, the telephone companies are "transitioning" the old DDS services. These were hubbed, so every circuit went through some central test board, at great cost, in order to guarantee low BER. You need that as much as your bicycle needs armor plate! Nowadays you should NEVER order DDS; instead, order "dirty digital" or "DDS2" or "Accunet Spectrum" (AT&T's name) or some other service. In general these ONLY come in 56/64 kbps speeds (typically 64 kbps with restrictions that make them effectively 56k after the DSU). But they're also usually cheap, about the same as a voice grade line or little more. The phone company is getting people to move to the new service by raising the price of DDS (hubbed) to the sky. That's the usual way. BTW, PPP buys you one thing SLIP can't: A checksum! The TCP checksum is a bad joke; PPP has a true CRC. If you don't like undetected errors, don't use SLIP. Anywhere on your network. Period. --- Fred R. Goldstein Digital Equipment Corp., Littleton MA goldstein@delni.enet.dec.com voice: +1 508 952 3274 Do you think anyone else on the planet would share my opinions, let alone a multi-billion dollar corporation?  -----------[000320][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 21:30:31 GMT From: REDREC@UNAMVM1.BITNET (Cristina Casimiro) To: comp.protocols.tcp-ip Subject: Re: TCP/IP on OS/2  Hi : Do you if UNISYS offers the same package (TCP/IP,etc) Cristina Casimiro Universidad Nacional Autonoma de Mexico  -----------[000321][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 91 23:27:53 GMT From: gaddam@remus.rutgers.edu (Surekha Reddy Gaddam) To: comp.protocols.tcp-ip Subject: Interested in TLI interface VS Berkely Sockets  Can some one post the trade-offs between the TLI interface and the Berkely sockets. Thanks, Surekha Reddy  -----------[000322][next][prev][last][first]---------------------------------------------------- Date: 25 Sep 91 00:45:57 GMT From: karl@ddsw1.MCS.COM (Karl Denninger) To: comp.protocols.tcp-ip Subject: Re: cisco router performance (was selecting a fast ethernet card).  In article <1991Sep23.181049.17056@kronos.com> richb@kronos.com (Rich Braun) writes: >router, despite my request for bottom-line cost under US5,000. > >This latest thread, though, points out something that I've always felt >about Cisco: they're a Rolls-Royce type of company, and I want a Volks- >wagen. My desire is to go to management and say "I can get real-time, >secure access to Internet for little money", not "I can route 22 megabytes >of data per second on our corporate backbone". Try Telebit for the NetBlazer. If you need a couple of ethernets, and no more than one 56K leased line link (synchronous) then the Netblazer is much less expensive and quite capable. It's a Volkswagon, and priced like it. Seems to work like it too (nice and reliable). -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Data Line: [+1 312 248-0900] Anon. arch. (nuucp) 00:00-06:00 C[SD]T Request file: /u/public/sources/DIRECTORY/README for instructions  -----------[000323][next][prev][last][first]---------------------------------------------------- Date: 25 Sep 91 01:26:55 GMT From: glenn@score.aic.co.jp (Glenn Mansfield) To: comp.protocols.tcp-ip Subject: Queries on CMOT  We are currently investigating the CMOT management protocol suite. We intend doing some experimentation on this subject. In this context: are there any CMOT implementations available as pds or otherwise. are there any other sites carrying out similar experiments? is there a working group / news group where discussions on this subject is being carried out. Please reply to me by mail. I will summarise the replies in this newsgroup. thanks glenn glenn@aic.co.jp  -----------[000324][next][prev][last][first]---------------------------------------------------- Date: 25 Sep 91 07:09:39 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Speed of memory and fast networks (was: Need help selecting Enet cards)  In article <1991Sep24.094657.1202@uniwa.uwa.oz.au>, jcross@ec.uwa.oz.au (Jennifer Cross - pgmr) writes: > ... > Many of the specialised (read non unix) systems out-there use more direct > memory systems. ... > I own an Amiga for fun, use SUN, SGI, PC, MAC for work. ^^^ SGI IRIS's have done something similar for network output for years, and that with IRIX 4.0, do something similar on input when convenient. It is convenient surprisingly and significantly often with TCP/IP/FDDI and with certain "C compiler and linker technology". Vernon Schryver, vjs@sgi.com  -----------[000325][next][prev][last][first]---------------------------------------------------- Date: 25 Sep 91 09:47:25 GMT From: johnm@vaxc.cc.monash.edu.au To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: IBM AADU and Clarkson packet drivers  In article <9236@cs.tulane.edu>, tom@rs1.tcs.tulane.edu (Tom Gerace) writes: > ... > I know that a Novell solution was created with the -n switch > in the Clarkson packet drivers, allowing both the Novell drivers > and the Clarkson drivers to be in memory at once. By default, a Packet Driver supports multiple applications that want to use different protocols simultaneously; without having them fight for control of the I/O board. The -n option was created to change to format of packets of one of these protocols. From INSTALL.DOC: The -n option is used to convert IPX packets between the Ethernet II type 8137 encapsulation used by BYU's PDSHELL IPX interface code and the 802.3-style encapsulation normally used on Ethernet by Netware servers, shells and boot PROMs. ... > Has anyone out there done the same thing with AADU and tn3270 > that we are doing here? Can the two drivers use the one > ethernet board concurrently? What you require is a AADU driver (or AADU kernel) that makes calls to a Packet Driver, and then AADU and tn3270 will both be able to communicate concurrently. John -- John Mann, Leader - Networking Section Internet: johnm@vaxc.cc.monash.edu.au Computer Centre, Monash University Phone: +61 3 565 4774 Clayton, Victoria 3168, Australia Fax: +61 3 565 4746  -----------[000326][next][prev][last][first]---------------------------------------------------- Date: 25 Sep 91 12:54:39 GMT From: garyo@apricot.co.uk (Gary Osborne) To: comp.protocols.tcp-ip Subject: Re: Using LAN manager 1.1 tcp-ip with FTP PC/TCP  sgaras@brnwil.uucp (Sam Garas) writes: >I am trying to use HP's LAN manager 1.1 tcp protocol in conjuction >with FTP's PC/TCP. I run into a conflict because of the two TCP >protocols loaded at the same time. I can not run both of them at the >same time. I was wondering if anyone has any suggestions on how to >run PC/TCP and LAN manager 1.1 at the same time without running into any >conflicts. Can this be done? Why not junk the HP stack, run the FTP stack with FTP's Netbios, and their DISPKT (Packet Driver -> NDIS converter) software. From what you say this should work. FTP's Netbios is very compliant and the DISPKT driver is now old and safe software. Cheers. ============================================================================== Gary Osborne garyo@apricot.co.uk Apricot Computers Limited Birmingham, UK ==============================================================================  -----------[000327][next][prev][last][first]---------------------------------------------------- Date: 25 Sep 91 13:41:32 GMT From: pv0618@hertz.njit.edu (Paranjothi Varadarajan) To: comp.protocols.tcp-ip Subject: Question on tn3270  Hi ! I am using tn3270 software ( I have the source code) to log into an MVSR machine. I would like to build something which lets the end user (using my application) to directly go to the login prompt (ie pass the domain stage). The User Interface currently runs tn3270 domain_name and the user sees the following in an xterm " SNS/TCP Version 1.0.0 Server Telnet (domain_name) Wed, 25 Sep 91 9:35:07 EDT Enter "NEWS" for current news. Enter Command Or 'HELP': " The user then enters a (probably) system name, to which the system responds by giving a logon promt. I would like to remove this need of having the user to enter the system name at the domain prompt every time and take him directly to the logon prompt eg I would like to be able to run tn3270 domain_name sys_name. I have been looking into the tn3270 code . Does any body out there any ideas of how can I do this. I certainly do not want to write another program to run on top of tn3270 which probably opens up pipes and reads and writes thru the pipe to communicate the system name. Is it possible to use a socket for this ? Please respond by posting in the news group in addition to sending the mail , since I may loose the account I am using currently. Really appreciate any clues... thanks !  -----------[000328][next][prev][last][first]---------------------------------------------------- Date: 25 Sep 91 13:54:00 GMT From: Alessandro.Forin@SPICE.CS.CMU.EDU To: comp.protocols.tcp-ip Subject: Re: LANCE chip bug  The first thing you should fix is your mail setup :-)) sandro- ----------------------------------------------------------------------------- Date: Wed, 25 Sep 91 09:28:54 -0400 Sender: <tcp-ip-relay@nisc.sri.com> From: "Mail Delivery Subsystem" <postmaster@ray.com> Subject: Returned mail: Unable to deliver mail Precedence: junk To: Alessandro.Forin@SPICE.CS.CMU.EDU ----- Transcript of session follows ----- 554 fjr... Cannot open /ub1/fjr/.forward: Permission denied setgroups: Not owner ----- Unsent message follows ----- Received: from uunet.UU.NET by rayssd.ssd.ray.com (5.65/8.26) with UUCP ; Wed, 25 Sep 91 09:28:55 -0400 Received: from SPICE.CS.CMU.EDU by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA16944; Wed, 25 Sep 91 08:54:46 -0400 Date: Wed, 25 Sep 1991 08:48-EDT Sender: <tcp-ip-relay@nisc.sri.com> From: Alessandro.Forin@SPICE.CS.CMU.EDU To: "Fred J. Roeber" <rayssd!fjr@uunet.uu.net> Subject: Re: LANCE chip bug Message-Id: <685802936/af@SPICE.CS.CMU.EDU> In-Reply-To: "Fred J. Roeber"'s mail message of 20 Sep 91 15:48:21 GMT The Lance is a chip and all chips have bugs :-) The ones I found are documented in a driver, which is free just like all other Mach 3.0 code. Let me know if you want to look at it. sandro-  -----------[000329][next][prev][last][first]---------------------------------------------------- Date: 25 Sep 91 13:59:04 GMT From: jjohnson@HNS.COM (Jayne Johnson) To: comp.protocols.tcp-ip Subject: Connection failure detection with Berkeley sockets  I have a BSD4.3 Tahoe release of the TCP/IP suite of protocols and have noticed strange behaviour from the socket api. Given the following scenario: 1. card A creates a non-blocking socket for listening 2. card B creates a non-blocking socket and initiates a connection request to card A. 3. card A receives a connection indication from the select() from card B 4. card A accepts the connection request from card B. 5. card B receives a connection confirmation from the select() from card A. 6. card A and card B exchange messsages 7. an operator resets card A ( on purpose , to simulate card failures ) 8. card B gets an indication from the select() My question is as follows , how can an application determine when a connection has been broken ? Should select() get an indication? Should I set a socket option (like out-of-band data ? ). Should I read the socket control block structure state field? Is there a message passed between the TCP and socket api which can be forwarded up to the application interface when connections are closing? I need to find out when a connection has failed as soon as possible since my system has redundant cards ( which already have connections established ) and I can easily switch over to the redundant card when a connection indication is received. I prefer to treat the socket api like a black box and not read the socket control block structure. I have been reading the RFCs , Steven's book on UNIX network programming, Lefler's book on BSD , Comer's book on TCP/IP and there doesn't seem to have any literature on this subject. I also have instituted a failure management scheme which uses 'ping' and periodic echo messages to determine who is alive and well in the network. However the failure management system is much slower than connection indications. Any thoughts? Any literature? Thanks in advance for your help and insight. Jayne F. Johnson Hughes Network Systems 11717 Exploration Lane Germantown, Md 20874 email : jjohnson@hns.com phone : 301/428-2714  -----------[000330][next][prev][last][first]---------------------------------------------------- Date: 25 Sep 91 14:09:35 GMT From: thomson@hub.toronto.edu (Brian Thomson) To: comp.protocols.tcp-ip Subject: Re: Is MX-ing the domain-name legal?  In article <1081@giga.slc.unisys.com> markb@giga.slc.unisys.com (Mark Baranowski) writes: >Is it legal to have an MX record so that mail can be sent to the >domain name rather than to a specific host? For example: > > sub.domain.edu. IN MX 20 host2.sub.domain.edu. > ... > >The reason for my question is that I have been told that the above >configuration violates the RFC for DNS. Not likely. Check out the example zone on page 16 of rfc1033. Note the MX record for domain SRI.COM directed at host KL.SRI.COM. -- Brian Thomson, CSRI Univ. of Toronto utcsri!uthub!thomson, thomson@hub.toronto.edu  -----------[000331][next][prev][last][first]---------------------------------------------------- Date: 25 Sep 91 16:22:13 GMT From: richb@kronos.com (Rich Braun) To: comp.protocols.tcp-ip Subject: All these "unsubscribe" requests  If someone is retransmitting this newsgroup via an e-mail list and retransmitting responses via reply e-mail, PLEASE DISABLE THE REPLY POSTINGS. At least until you provide a better method for people to get themselves off the e-mail list. Thank you. -rich  -----------[000332][next][prev][last][first]---------------------------------------------------- Date: 25 Sep 91 16:49:29 GMT From: mark@TELESYS.NCSC.NAVY.MIL (Williams) To: comp.protocols.tcp-ip Subject: Re: FTP sites in the US  Alex writes: > I was wondering where a person could get FTP numbers for Pennsylvania or > the surrounding area? Does it matter what type of connection one is on, > say VAX cluster or UNIX? I'd appreciate a list, but don't know where to get > it. and, paraphrased, what are available ftp sites. FTP is available in almost all tcp-ip implementations. I assume that you really want to know what sites have ftp servers running that support anonymous logins. If that's what you're looking for, the archie system at McGill University is one source. You can get information on using archie by telnetting to quiche.cs.mcgill.ca and logging in as archie. In addition, you can get a list of probable ftp servers by doing an anonymous ftp to quiche.cs.mcgill.ca, cd archie/listings, and capturing the info you get from an ls there. If you do an ls -l, you can see when the information on the listed host was last captured and how much space it takes to hold a compressed version of the ftp-able file list. I'm not sure why you're interested in just the Pennsylvania area... as the domains indicate, anonymous ftp is supported on machines all over the world. Mark L. Williams Head, Telecommunications Branch Code 7630 Naval Coastal Systems Center Panama City, FL 32407-5000 (904)235-5153 (mark@telesys.ncsc.navy.mil)  -----------[000333][next][prev][last][first]---------------------------------------------------- Date: 25 Sep 91 18:14:29 GMT From: saba@tellab1.TELLABS.COM (Bruce Sabalaskey) To: comp.protocols.tcp-ip Subject: Unsubscribe  Please unsubscribe me from this list.  -----------[000334][next][prev][last][first]---------------------------------------------------- Date: 25 Sep 91 18:30:26 GMT From: slf@well.sf.ca.us (Sharon Lynne Fisher) To: comp.protocols.snmp,comp.protocols.tcp-ip Subject: Looking for SNMP users  I'm doing a story for Communications Week, and I'm looking for users who have switched from some other network management method, or no network management method, to some Unix-based management method, such as Accumaster or SNMP. If you'd be willing to be interviewed for this story, please reply here, send me email at slf@well.sf.ca.us, or call me at (415) 864-5987. Thanks!  -----------[000335][next][prev][last][first]---------------------------------------------------- Date: 25 Sep 91 19:15:08 GMT From: shj@ultra.com (Steve Jay) To: comp.protocols.tcp-ip Subject: zero windows & probes (was - Re: TCP FIN and window)  In <12716157325.11.BILLW@mathom.cisco.com> BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes: >1) In a modern TCP, the receiver window will never be o unless the destination > device is slower than the network link (eg terminal servers). Destination devices slower than networks are quite common. I just tried an experiment on a Sun 4/370 with fddi & a SCSI disk. I sent 800 KB from a faster machine to the 4/370, which was writing the data to its SCSI disk. A 0 window occurred 4 times during the transfer. Please don't consider a 0 window an "unusual" event, or one that only happens with very slow devices. > 4) Probes are a failsafe technique for recovering from am ACK that would > open the window being lost. Lost packets are rare. Maybe not that uncommon in wide-area networks. I think starting with a fairly fast "zero-window" probe is a good idea. Perhaps RFC 1122's suggestion of 1 RTT is a bit quick, but the 5 seconds in Berkeley is definitely too long. 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"  -----------[000336][next][prev][last][first]---------------------------------------------------- Date: 25 Sep 91 20:45:26 GMT From: kxb@math.ksu.edu (Karl R. Buck) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs,comp.sys.ibm.pc.misc Subject: Using "mount" and SOSS  How can I allow a certain user (or failing that anyone from a certain client) to be able to mount a file system on SOSS? The documentation states that the export.us file is similar to exports(5), but there seem to bee some major differences in SunOS export format. At any rate I am trying to mount using mount(1) on a Sun client (using setuid root and executing as another user) but SOSS keeps complaining about "invalid client credentials". I am able to mount file systems just fine using "net use" with Sun's PC-NFS. Any ideas? Thanks. -- Karl Buck email: kxb@hilbert.math.ksu.edu Department of Mathematics Phone: 913.532.6750 Kansas State University Manhattan, KS 66506  -----------[000337][next][prev][last][first]---------------------------------------------------- Date: 25 Sep 91 22:37:37 GMT From: NIC@NIC.DDN.MIL (DDN Reference) To: comp.protocols.tcp-ip Subject: DDN NIC changes!  This message is a notification of DDN NIC services transitioning from SRI to a new contractor, GSI, and other related changes that will be occurring. These changes should occur between 27-Sep-91 and 1-Oct-91. HOST NIC.DDN.MIL Address will change from 192.67.67.20 to 192.112.36.5 MAILING LISTS TCP-IP, NAMEDROPPERS, and ISODE will move from NISC.SRI.COM back to NIC.DDN.MIL. PRIMARY ROOT SERVER NS.NIC.DDN.MIL Address will change from 192.67.67.53 to 192.112.36.4 ROOT SERVER A.ISI.EDU A root server will no longer run on this host. ROOT SERVER KAVA.NISC.SRI.COM A new root server will be run at SRI at address 192.33.33.24, to take the place of A.ISI.EDU. New ROOT.CACHE file that can be used with NAMED: ---------- ; ; @(#)root.cache 1.1 (Berkeley) 86/01/21 ; ; Initial cache data for root domain servers. ; . 999999 IN NS NS.NIC.DDN.MIL. 999999 IN NS KAVA.NISC.SRI.COM. 999999 IN NS AOS.BRL.MIL. 999999 IN NS C.NYSER.NET. 999999 IN NS TERP.UMD.EDU. 999999 IN NS NS.NASA.GOV. 999999 IN NS NIC.NORDU.NET. ; ; Prep the cache (hotwire the addresses). Order does not matter ; NS.NIC.DDN.MIL. 999999 IN A 192.112.36.4 KAVA.NISC.SRI.COM. 999999 IN A 192.33.33.24 AOS.BRL.MIL. 999999 IN A 192.5.25.82 C.NYSER.NET. 999999 IN A 192.33.4.12 TERP.UMD.EDU. 999999 IN A 128.8.10.90 NS.NASA.GOV. 999999 IN A 128.102.16.10 NS.NASA.GOV. 999999 IN A 192.52.195.10 NIC.NORDU.NET. 999999 IN A 192.36.148.17 -------  -----------[000338][next][prev][last][first]---------------------------------------------------- Date: 26 Sep 91 00:25:32 GMT From: Liquid.Len@SOL.USC.EDU To: comp.protocols.tcp-ip Subject: [PMDF Mail Server <Postmaster@gamera.usc.edu>: Undeliverable mail]  Please deal with this problem/mail loop. It's been a week and we're getting millions of these. We don't have a user YONTA at node Gamera.bitnet or Gamera.usc.edu, and if whoever it is is sending thinking he exists, please remove him, from your list. Thanks in advance. USC --------------- Return-Path: <postmaster@gamera.usc.edu> Received: from gamera.usc.edu by sol.usc.edu (4.1/SMI-3.0DEV3) id AA13290; Wed, 25 Sep 91 16:35:33 PDT Date: Wed, 25 Sep 91 16:32 PDT Sender: <tcp-ip-relay@nisc.sri.com> From: PMDF Mail Server <Postmaster@gamera.usc.edu> Subject: Undeliverable mail To: tcp-ip-relay%NISC.SRI.COM@usc.edu Message-Id: <0D220746293FE07A2C@gamera.usc.edu> X-Envelope-To: asbed@SOL.USC.EDU The message could not be delivered to: Addressee: YONTA Reason: %MAIL-E-NOSUCHUSR, no such user YONTA at node GAMERA ---------------------------------------- Received: from JNET-DAEMON by gamera.usc.edu; Wed, 25 Sep 91 16:32 PDT Received: From SNYBUFVA(MAILER) by GAMERA with Jnet id 7683 for YONTA@SC; Wed, 25 Sep 1991 16:32 PST Received: from JNET-DAEMON by SNYBUFVA with PMDF#10360; Wed, 25 Sep 1991 19:35 EST Received: From CUNYVMV2(MAILER) by SNYBUFVA with Jnet id 8321 for YONTA%SC@SNYBUFVA; Wed, 25 Sep 1991 19:35 EDT Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.08) with BSMTP id 8710; Wed, 25 Sep 91 19:31:44 EDT Received: from NISC.SRI.COM by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with TCP; Tue, 24 Sep 91 23:05:49 EDT Received: by NISC.SRI.COM (5.65/SRI-NISC1.2) id AA13064; Fri, 20 Sep 91 14:34:56 -0700 Received: from NIC.DDN.MIL by NISC.SRI.COM (5.65/SRI-NISC1.2) id AA13060; Fri, 20 Sep 91 14:34:53 -0700 Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 19 Sep 91 09:23:02 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05372; Thu, 19 Sep 91 09:19:49 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 91 15:42:14 GMT Sender: <tcp-ip-relay@nisc.sri.com> From: agate!spool.mu.edu!samsung!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!rogers%ucbvax.Berkeley.EDU@usc.edu Subject: I need a PD bootp server for DOS? To: tcp-ip%nic.ddn.MIL@usc.edu Message-id: <1991Sep19.154214.23302@ux1.cso.uiuc.edu> Organization: University of Illinois at Urbana X-Envelope-to: YONTA Is there a pd dos implemetation of bootp server to assisn IP address? We are using a mix of NCSA, Clarkson, and Ka9q and would like to dynamically assign ip's. Thanks, Bill -- .............................................................................. Bill Rogers . Internet - rogers@ux1.cso.uiuc.edu Asst. Director for Academic Computing . Bitnet - ROGERS@UIUCVMD Sangamon State University . Voice - 217-786-6549  -----------[000339][next][prev][last][first]---------------------------------------------------- Date: 26 Sep 91 00:50:31 GMT From: bill@banana.fedex.com (bill daniels) To: comp.protocols.tcp-ip Subject: HELP - netstat, connect(ions)  We have a program that serves another set of programs. It accepts connections from the clients on a one-connection-per-message basis. The client then closes the connection at which time the server (I hope) closes his socket. netstat(1) continues to show many sockets to the server, even after the client has gone away. The states show as LAST_ACK and TIME_WAIT and such as that. My question revolves around the number of sockets still showing under netstat(1). Is there a maximum number of these sockets in the TIME_WAIT, etc, state that can exist before the server will stop accepting new connections? If there are clients attempting to connect in a fairly rapid basis, will the clients eventually have to block waiting around on an available socket? This seems to be happening with the clients. I believe that they are sitting around waiting on a connection which blocks the client for a number of seconds (< 10 secs). The configuration is a DECsystem 5500, Ultrix 4.2. The server socket id is 2003, if that matters. -- these ravings are in no way sanctioned by federal express corp bill daniels | voice: (901)797-6328 federal express corp | fax: (901)797-6388 box 727-2891, memphis, tn 38194 | email: bill@banana.fedex.com  -----------[000340][next][prev][last][first]---------------------------------------------------- Date: 26 Sep 91 02:06:06 GMT From: wong_a@summer.chem.su.oz.au To: comp.protocols.tcp-ip Subject: Sendmail.cf!  I'm setting up sendmail and since we don't have a particularly exotic setup, I just used the default sendmail.cf suppiled by Apollo. I've looked at the .cf file and all the "rules" look O.K. But here's the transcript from a 'sendmail -bm -v wong_a@summer.chem.su.oz.au' session, wong_a@summer.chem... Connecting to summer.chem.tcp... 220 SUMMER.CHEM.SU.OZ.AU TGV/MultiNet SMTP service ready. >>> HELO lester.ARPA 250 SUMMER.CHEM.SU.OZ.AU ; Hello lester.ARPA, pleased to meet you. >>> MAIL From:<root@lester.ARPA> 250 OK >>> RCPT To:<wong_a@lester.ARPA> 250 <wong_a@lester.ARPA>... ok - delivered as <wong_a@lester.ARPA> >>> DATA 354 Start mail input; end with <CRLF>.<CRLF> >>> . 250 OK ; Job SMTP-NETMAIL (queue SMTP_SUMMER, entry 155) started on SMTP_SUMMER >>> QUIT 221 SUMMER.CHEM.SU.OZ.AU TGV/MultiNet SMTP service complete. wong_a@summer.chem... Sent Why is the 'RCPT To:' field set to '<wong_a@lester.ARPA>' rather than '<wong_a@summer.chem.su.oz.au> ?? How did sendmail modify the address I gave it, summer.chem.su.oz.au -> lester.ARPA What rule am I supposed to modify? Thanks Adrian. ----------------------------------------------------------------------------- Adrian Wong, Dept.of Theoretical Chemistry wong_a@summer.chem.su.oz.au University of Sydney NSW 2006 Australia 061-2-692 4137 -----------------------------------------------------------------------------  -----------[000341][next][prev][last][first]---------------------------------------------------- Date: 26 Sep 91 02:37:17 GMT From: lars@spectrum.cmc.com (Lars Poulsen) To: alt.security,sci.crypt,comp.protocols.tcp-ip Subject: Re: "Open Systems Security" documnet available  Arto Karila (atk@ajk.tele.fi) posted a pointer to a document about security in Open Systems; Dan Kegel subsequently made it available on a file server at JPL. I retrieved it, and it was a disaster ... The document apparently has been posted earlier, and users had grief with printing it, because it required (but did not include) the Apple LaserPrep file. This version was supposed to alleviate that problem. (1) I retrieved the file and queued it for printing on my Imagen printer. I received 300 pages of PostScript Source, beginning with the Apple LaserPrep file. The only reason I'm still alive, is because nobody knows I was the one who submitted the job .... Problem no 1: The concatenated file does not begin with the magic cookie that tells the print spooler that this job is PostScript and doesn't need to be run through the text-to-PostScript converter before printing. That cookie is "%!" in the first two bytes. Problem no 2: The VI editor won't read the file because there are lines somewhere in the file longer than 256 ?? 512 ??? bytes. Solution: Use the ADB debugger to zap the second byte from a "%" to a "!" sign. (2) I printed the file again. No output. Just a cover page that said "Input file 768364 bytes: 0 pages printed". Problem no 3: Those long lines turn out to be the famous patented Apple bit-smoothing code for the laserwriter. About 12000 hex digits in a looooooooooong hex string; wrapped in code that essentially says "If the product name is not "LaserWriter", skip to end of file". That's just dandy, if the file is LaserPrep; not so great, if the file is the concatenated LaserPrep plus Arto's book. Solution: Use ADB debugger to locate the offending section and insert a "0A" (new line) character into the hex string every 128 bytes or so; then use VI to delete the whole binary program and wrapper. About 3 hours. (3) I printed the file again. The cover page is great. The next two pages are printed upside-down-reversed; i.e. to read them I have to hold the paper against the light and read THROUGH the paper. The next 80 pages look OK. Appendices again are mirror-reversed. The bibliography is not reversed, but is truncated about a half to a whole inch, so every line is missing a word or so. Problem no 4: The file is really a concatenation of 5 output files from a wordprocessor. Not sure which one. Each file starts out by invoking a "psu" (page setup) macro, and ends with a "Trailer". The psu macro contains some code that essentially says "fiddle with something called /invertflag is this is not a LaserWriter and the PostScript interpreter's revision number is less than 47.0". Well, our Imagen printer runs a PostScript CLONE called UltraScript revision 2.0. Solution: Try to delete the /invertflag portion of the /psu macro. (4) Print again: No output. Job failed with an error message: [ Error: typecheck; OffendingCommand: get ] Obviously, I deleted something wrong. Well, I'm out of time and patience. I really would have liked to read this paper, but I don't have time to reverse-engineer it from the broken postscript file. Will somebody wake me up when it's fixed ? -- / Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM  -----------[000342][next][prev][last][first]---------------------------------------------------- Date: 26 Sep 91 02:40:36 GMT From: jprice@intel7.intel.com (Great GooglyMoogly!) To: comp.protocols.tcp-ip Subject: (none)  Please remove me from your distribution list, please. Thanx in advance. o-------------------------------------------------------------o : John Price, FB7-53, Intel, Rio Rancho, New Mexico 87124 : : eMail: JPrice@Intel7.Intel.Com : : standard disclaimer applies : o-------------------------------------------------------------o "...it'll cure your asthma, too." - Grand Wazoo  -----------[000343][next][prev][last][first]---------------------------------------------------- Date: 26 Sep 91 12:41:43 GMT From: emv@msen.com (Edward Vielmetti) To: news.announce.newgroups,news.groups,comp.protocols.tcp-ip,ba.internet,dnet.inet Subject: RFD: comp.internet.{policy,routing,research}  I'd like to open the floor for discussion a new "comp.internet" set of newsgroups, including some suggestions charters for a few of them, and ideas for others. It's a curious artifact of how Usenet and the Internet have developed that there isn't a single mainstream usenet group with the name "internet" in it. Several regional news hierarchies have created such groups (ba.internet, dnet.inet) and they carry reasonable traffic. But there's nothing in the mainstream netnews to discuss how the internet works, who is involved in running it, what it costs, what it should be doing. Those discussions happen in one of several dozen mailing lists. Here's a few suggested newsgroups (with charters handy) to take up the slack. comp.internet.policy Rules, regulations, and policy decisions regarding internetworking. Appropriate use guidelines, commercial use restrictions, export regulations as they apply to internets. What the rules are, who makes them, what it costs to make your own rules. comp.internet.routing Routing protocols on the Internet -- RIP, EGP, BGP, OSPF, IS-IS, RSPF. Sensible routing architectures for regional, campus, and world networks. Policy-based routing. Traceroute. Observations of what does and doesn't work on the internet today. Traceroute contests (worked all states; worked all continents; maximum hop count :-) comp.internet.research (moderated) Also suggested as "comp.protocols.research". Matters of internetworking interest relevant to future networks and which expand the knowlege and state of the art. Moderated (need to find a moderator for this one). Target audience doesn't read a lot of netnews, but does care about the Internet, and doesn't have time to read tcp-ip. Several other groups could potentially fall under the general "comp.internet" rubric; certainly any of the IETF mailing lists might have a parallel public newsgroup with a name somewhere near these (or in comp.protocols or in comp.dcom). Quite possibly there's room for a comp.internet.com-priv gateway to the existing "commercialization and privatization of the internet" mailing list (com-priv-request@uu.psi.com). These groups which I have describe are new lists, not gateways of older mailing lists; they supplement the existing discussions, and don't replace them. The net has grown substantially since TCP-IP@NIC.DDN.MIL first was gatewayed into comp.protocols.tcp-ip. Internetworking is a booming industry, and it has generated a number of high-traffic mailing lists. The proposed groups have already seen substantial discussion on the net; the names are reasonable (though I'm up for suggestions); and I think they'd be a good addition. -- Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com MSEN, Inc. 628 Brooks Ann Arbor MI 48103 +1 313 741 1120 for information on MSEN products and services contact info@msen.com "Technically trained people are not troglodytes" -- Mitch Kapor, RFC 1259  -----------[000344][next][prev][last][first]---------------------------------------------------- Date: 26 Sep 91 15:19:56 GMT From: tom@ksr.com To: comp.protocols.tcp-ip Subject: Please remove me from this list.  I tried sending to the list manager and I've tried sending to the list itself but it seems like I just can't get off this list. Somebody, please help me get off, otherwise I'll just continue annoying everybody with these silly messages. Thanks, tom@ksr.com  -----------[000345][next][prev][last][first]---------------------------------------------------- Date: 26 Sep 91 15:36:45 GMT From: jkp@cs.HUT.FI (Jyrki Kuoppala) To: alt.security,sci.crypt,comp.protocols.tcp-ip Subject: Re: "Open Systems Security" documnet available  In article <1991Sep26.023717.15435@spectrum.CMC.COM>, lars@spectrum (Lars Poulsen) writes: >Arto Karila (atk@ajk.tele.fi) posted a pointer to a document about >security in Open Systems; Dan Kegel subsequently made it available >on a file server at JPL. I retrieved it, and it was a disaster ... Try with nic.funet.fi pub/doc/security/karila/OpenSystemsSecurity.tar.Z which has the files separately. I haven't printed all of the files, but they do have the magic cookie and do seem to work with Ghostscript - there seems to mantras something like 'Copyright Lawsuits Inc, all rights reversed' in the documents and also some eexec hex gibberish, but Ghostscript doesn't seem bothered by those, and neither did a HP laserjet something with which I tested Abstract.ps. //Jyrki  -----------[000346][next][prev][last][first]---------------------------------------------------- Date: 26 Sep 91 15:50:11 GMT From: yongwang@eng.auburn.edu (Yong Wang) To: comp.protocols.tcp-ip Subject: unsubscribe  Please remove me from this list. Thanks. yongwang@eng.auburn.edu  -----------[000347][next][prev][last][first]---------------------------------------------------- Date: 26 Sep 91 18:12:05 GMT From: brian@telebit.com (Brian Lloyd) To: comp.protocols.tcp-ip Subject: Re: SLIP and PPP compared  The difference in efficiency between SLIP and PPP when transporting IP datagrams is minimal. Many PPP implementations include VJ header compression while few SLIP implementations support VJ header compression (I am not aware of any commercial SLIP offering that has VJ header compression). There is another issue here: PPP will support other protocol stacks and SLIP will not. If you are considering the possibility of running more than one protocol stack over your link you will want to consider PPP. Also having the ability to negotiate anuthentication and IP addresses is a win. -- Brian Lloyd, WB6RQN Lloyd and Associates Network Architect 3420 Sudbury Road brian@ray.lloyd.com Cameron Park, CA 95682 voice (916) 676-1147  -----------[000348][next][prev][last][first]---------------------------------------------------- Date: 26 Sep 91 22:15:16 GMT From: Ewan.Tempero@comp.vuw.ac.nz (Ewan Tempero) To: alt.security,sci.crypt,comp.protocols.tcp-ip Subject: Re: "Open Systems Security" documnet available  Here is what I did. First the disclaimers 1. I know nothing about postscript except that it's some kind of stack-based language for printing things 2. This has worked for me "twice". "twice" is in quotes because the first time I did this was a long time ago and I only vaguely remember the details but the second time I did it (a couple of minutes ago) it took about 5 minutes to figure out how to print the first 3 pages (4 minutes were taken up in finding where I put the damn file and then uncompressing it) 3. I make no claims that this will work for anyone else on any other system with any other printer (not "any other _brand_ of printer", any other printer than the physical one I used, which was the department Apple Laserwriter II) So, I tried to print the document as received and got some error (I forget what it was). So I looked at the postscript to see what I could see. Knowing nothing about postscript I couldn't see much. I then created another postscript file that I knew would print (using dvips this time, I forget what I used last time) and looked at it again to see what I could see as being different. My "weirdness detection heuristic" identified the line: %%IncludeProcSet: "(AppleDict md)" 68 0 as being weird so I deleted it and tried printing the file again. It worked. <shrug> good luck --ewan -- e-mail: ewan@comp.vuw.ac.nz Post: Department of Computer Science Phone: +64 4 715 328 x8069 Victoria University of Wellington Fax: +64 4 715 375 P.O. Box 600, Wellington, New Zealand Conjecture: 1+1=1 (plus a small constant)  -----------[000349][next][prev][last][first]---------------------------------------------------- Date: 26 Sep 91 23:25:52 GMT From: jeff@markets.UUCP (Jeff Crilly N6ZFX) To: comp.protocols.tcp-ip Subject: delete jeff@markets.com  delete jeff@markets.com unsubscribe jeff@markets.amix.com - I tried various ways to get off the list. Maybe this will do it.  -----------[000350][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 00:45:47 GMT From: dee@nimbus.worldbank.org (W. McDonald Buck) To: comp.os.vms,comp.protocols.nfs,comp.protocols.tcp-ip Subject: Re: Is TCP/IP and NFS viable in corporate network.  I didn't see the original post, nor many of the responses to this thread, but the question is very important to me as some of us are tasked to create a corporate network. We want to do just this (TCP/IP, NFS, etc). I need some info on who has done this on a large scale, and what success they have had. I am particularly interested in sites where users predominantly use PCs. We have thousands of PCs and eight hundred MACs. Maybe 2500 pcs are on token rings, and some run Banyan vines. Maybe 500 run Pathworks over ethernet. Most pcs are isolated, and just connect to terminal servers, or have token ring cards for SNA access to a 3090. We propose to try to build a campus wide TCP/IP net, and offer services to all. Thanks for any input.  -----------[000351][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 04:05:15 GMT From: jgd@convex.csd.uwm.edu (John G Dobnick) To: alt.security,sci.crypt,comp.protocols.tcp-ip Subject: Re: "Open Systems Security" documnet available  From article <1991Sep26.023717.15435@spectrum.CMC.COM>, by lars@spectrum.cmc.com (Lars Poulsen): > Arto Karila (atk@ajk.tele.fi) posted a pointer to a document about > security in Open Systems; Dan Kegel subsequently made it available > on a file server at JPL. I retrieved it, and it was a disaster ... I, too, had difficulties with this. What I wound up doing was (using the JPL files as a base): Acquired the tar file with the individual sections. Ignored the mass "all-in-one" file. Printed the individual sections, individually. It seems that the combined file has this Apple header cruft in it that triggers our PostScript printer's "this is text" filter (the file lacks the "%!" magic-cookie.) Our (non-Apple) printer also seemed to choke on the Apple-specific data. The individual sections each start with "%!" magic-bits; the document prints without incident, although some assembly is required. :-) -- John G Dobnick Computing Services Division @ University of Wisconsin - Milwaukee INTERNET: jgd@uwm.edu ATTnet: (414) 229-5727 UUCP: uunet!uwm!jgd "Knowing how things work is the basis for appreciation, and is thus a source of civilized delight." -- William Safire  -----------[000352][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 04:06:00 GMT From: CURT.ELLMANN@MAIL.ADMIN.WISC.EDU To: comp.protocols.tcp-ip Subject: unsubscribe  to: tcp-ip@nic.ddn.mil please remove me from the tcp-ip list thanks curt.ellmann@mail.admin.wisc.edu  -----------[000353][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 07:09:25 GMT From: marc@dumbcat.sf.ca.us (Marco S Hyman) To: comp.protocols.tcp-ip Subject: Re: Interested in TLI interface VS Berkely Sockets  In article <Sep.24.19.27.53.1991.1179@remus.rutgers.edu> gaddam@remus.rutgers.edu (Surekha Reddy Gaddam) writes: > > Can some one post the trade-offs between the TLI interface and > the Berkely sockets. Just a few... In BSD UNIX Sockets are kernel based. In System V TLI is an interface library implemented upon a STREAMS based network. The same TLI interface can be used with any STREAMS based network implementation. Address sizes might be a concern with sockets. (What do you do if the network address requires more bytes than will fit into a struct sockaddr?) TLI buffer management is more complex, even with the t_alloc call. It's all too easy (IMHO) to have a memory leak using TLI. A TLI server has to do more work that a socket server to accept a connection. Using sockets an accept call returns a new socket -- TLI has to create the new endpoint before calling accept. You can not read and write to a TLI endpoint unless the network stream has been modified (by popping and pushing the appropriate module). t_snd and t_rcv would have to be used. // marc -- marc@dumbcat.sf.ca.us -- pacbell!dumbcat!marc  -----------[000354][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 10:41:07 GMT From: daveg@prowler.clearpoint.com (Dave Goldblatt) To: comp.dcom.lans,comp.dcom.modems,comp.lang.c,comp.os.vms,comp.protocols.tcp-ip,comp.sys.dec,comp.unix.wizards,comp.sys.cdc,comp.sys.prime,comp.sys.ibm.pc.hardware Subject: Help Requested in Defeating Ring Buffer Software Patent  [ I apologize for the wide distribution (especially if you've seen it before), but as this could conceivably affect a wide number of people, I figure it's worth it. Flames to email, please. ] I am looking for information which could be used to invalidate a patent which covers one of the most basic techniques in software: the ring buffer. Specifically, the patent is on the idea of using two circular buffers in commonly addressable memory to queue pointers to messages (also in shared memory) between two processors. One buffer contains messages going in one direction, and the other buffer contains messages going in the other. The allegedly inventive feature is having one of the processors tell the other processor the size of the ring buffers. I'm looking for code or references to this technique written before October 5, 1981. An example of dual processor communication would be ideal, however, inter-process communication via this method could also prove useful. I know of at least one network adapter which violates this patent, and also of an Ethernet controller which does as well, but neither are before the required date. I've also heard that the CDC 6x00 line used this method -- details would be appreciated. Any information will be GREATLY appreciated! For better results, email will be appreciated even more so. Thanks! -dg- -- "We go out in the world and take our | Dave Goldblatt [daveg@clearpoint.com] chances / Fate is just the weight of | Subsystems Software Engineering circumstances / That's the way that | Clearpoint Research Corporation lady luck dances / Roll the bones.." - Rush  -----------[000355][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 12:18:29 GMT From: graeme@ccu1.aukuni.ac.nz ( Graeme Moffat) To: comp.protocols.tcp-ip Subject: Re: routing problem from hell  Christopher-Vance@adfa.oz.au (Christopher JS Vance) writes: > Detailed description of network deleted >But there is no host D.E.30.21. This works because we have a friendly >host export an ARP entry for this IP address which has the ethernet >address for the router D.E.1.16. Perhaps we could tell the router to >recognise this as an alternative IP address for itself on the save >interface as D.E.1.16, but I don't drive that machine, so I can't tell >you. Ask the people who do! Sounds like your campus network administration is as bad as ours. They should have this set up, and assist you to configure correctly. >Why this kludge? There are multiple hosts on D.E.30.* which all think >the campus has no subnets. Why is the other network different? They >have no hosts except those on their subnet. But wouldn't it be better to do it properly? If part of your net is subnetted, than *all* of it should be. And how do the hosts D.E.30.* talk to the subnetted ones? >The other part of the solution is a proxy ARP server which ensures >that requests from non-subnetted hosts for ethernet addresses of hosts >on D.E.31 and D.E.51 get given the ethernet addresses of their >respective gateways instead. Ah. Thinking about it, I suppose this actually reduces network packets, since a properly subnetted host would have to send packets for all different subnets to the router for forwarding back on the same cable, while here the hosts believe that they're all on the same physical interface and hence only one packet appears. Who keeps the proxy ARP tables uptodate when hosts are changed? What if there were many more subnets all over the place? -- Graeme Moffat g.moffat@aukuni.ac.nz \ Time wastes us all, Computer Aided Design Centre, Fax: +64-9-366-0702 / our bodies & our wits School of Engineering, Ph: +64-9-737-999 x8384 / But we waste time, University of Auckland, Private Bag, Auckland, NZ \ so time & we are quits  -----------[000356][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 13:45:12 GMT From: mike@sojurn.uucp (Mike Sangrey) To: alt.security,sci.crypt,comp.protocols.tcp-ip Subject: Re: "Open Systems Security" documnet available  In article <1991Sep26.023717.15435@spectrum.CMC.COM> lars@spectrum.cmc.com (Lars Poulsen) writes: >Well, I'm out of time and patience. I really would have liked to read >this paper, but I don't have time to reverse-engineer it from the >broken postscript file. Will somebody wake me up when it's fixed ? > >-- >/ Lars Poulsen, SMTS Software Engineer > CMC Rockwell lars@CMC.COM Me too, Me too, .... If this has already been fixed, I would really like to know where to get a copy. I'm mainly uucp, but with some work I can ftp it. Thanks !! -- | UUCP-stuff: rutgers!devon!sojurn!mike | "It muddles me rather" | | Slow-stuff: 2129 Old Phila. Pike | Winnie the Pooh | | Lancaster, Pa. 17602 | with apologies to | | Fast-stuff: (717) 396-9897 | A. A. Milne |  -----------[000357][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 13:58:38 GMT From: kasten@EUROPA.CLEARPOINT.COM (Frank Kastenholz) To: comp.protocols.tcp-ip Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)  James, Brian, et, al, Clearpoint is not "pushing" SLIDE "over" PPP. For various historical reasons, SLIDE development preceeded PPP development. PPP is being developed right now and we hope to have it released by the end of the year. We ARE committed to A) developing standards based bridges and routers and B) publishing any proprietary protocols that we develop so as to continue the thought, development, and evolution of networking. As a corporate philosophy, we believe very strongly in contributing to the area from which we have gained so much and SLITHER/SLIDE is one such contribution. PPP provides the same capabilities that SLIDE does. It also provides more capabilities than SLIDE does. It is also a standard -- SLIDE is not. It is also more costly to implement than SLIDE is -- it has a finite state machine, link control protocols, several supporting protocols and services and so on. There are techno-religous arguments as to whether PPP is a "good" protocol or not. Reasonable people may and do hold differing opinions on the subject, and they do. Those arguments are best carried out on the mailing lists and in the market place. If, at some point, SLIDE "wins" (whatever that means) then perhaps it too could become a standard protocol. Cheers Frank Kastenholz Clearpoint Research Corp. > From tcp-ip-relay@nisc.sri.com Fri Sep 27 02:13:23 1991 > To: brian@telebit.com (Brian Lloyd) > Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I) > Sender: <tcp-ip-relay@nisc.sri.com> > From: jbvb@ftp.com (James B. Van Bokkelen) > Reply-To: jbvb@ftp.com > Cc: tcp-ip@nic.ddn.mil > Repository: babyoil.ftp.com > Originating-Client: plug.ftp.com > > The requirement for PPP is becoming part of the router requirements > doc as well. Why muddy the water with another nonstandard? > > Clearpoint wants SLIDE et al. Because PPP doesn't do what bridges need; > they want MAC addresses and 802.1 spanning tree connectivity. I don't > know if their hope that hosts will implement it will ever come true, but > the prospect of multi-vendor interoperability among half-bridges sounds > like a good idea to me. > > James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 > FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 > > > slipslide  -----------[000358][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 14:20:34 GMT From: mark@TELESYS.NCSC.NAVY.MIL (Williams) To: comp.protocols.tcp-ip Subject: UNSUBSCRIBING  Well, since there have been a bunch of "let me off the list" requests on the air lately, let me remind people that, in general, you should direct your unsubscribe requests to [interest-group]-request@[host]. If that's not working for tcp-ip, there's a problem that probably requires contacting a live person by telephone or specific email address. To recheck before posting, I picked up the latest interest-group info from NIC. Here's the entire tcp-ip entry, in case anyone's forgotten what the purpose of this group actually is... TCP-IP@NIC.DDN.MIL The NIC has taken over the responsibility for the periodic update of the TCP-IP implementations (the latest update can be obtained via FTP by ANONYMOUS login from SRI-NIC file NETINFO:VENDORS-GUIDE.DOC). We are particularly interested in the addition and expansion of TCP services. In addition to this function, it is hoped that this distribution list can aid in the following areas: To act as an on-line exchange among TCP developers and maintainers. To announce new and expanded services in a timely manner. Archives are kept on SRI-NIC in files: TS:<TCP-IP>TCP-IP.* where the "*" is a wild-card character. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to TCP-IP-REQUEST@NIC.DDN.MIL. Please do \not/ send such requests to TCP-IP@NIC.DDN.MIL, as this address is self forwarding to the entire list membership. Coordinator: Vivian Neou <Vivian@NIC.DDN.MIL> (415) 859-4781 I hope this eliminates the confusion... Mark L. Williams Head, Telecommunications Branch Code 7630 Naval Coastal Systems Center Panama City, FL 32407-5000 (904)235-5153 (mark@telesys.ncsc.navy.mil)  -----------[000359][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 14:38:03 GMT From: dave@mmagnet2.mmc.com (David A. Rageth) To: comp.protocols.tcp-ip Subject: BIND and MX records  I have a generic question about the use of MX records in the domain name server. Currently, to insure the delivery of mail we have the following MX definitions for hosts: hosta IN MX 10 hosta IN MX 20 servera IN MX 50 serverb hostb IN MX 10 hostb IN MX 20 servera IN MX 50 serverb Instead of repeating the same set for each host, is it possible to do the following: * IN MX 20 servera IN MX 50 serverb hosta IN MX 10 hosta hostb IN MX 10 hostb x++++++++++++++++++++++++++++++++++++++++x x David Rageth x x Internet : dave@mmc.com x x voice : (303)977-4584 x x fax : (303) 877-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  -----------[000360][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 15:10:36 GMT From: poorman@convex.com (Peter W. Poorman) To: comp.protocols.tcp-ip Subject: Correct response to FTP "NLST"?  Hi folks; I've just run across an interesting issue in the implementation of the FTP protocol. RFC 959 says that the correct response to a "NLST" (Name LiST) command is "... a stream of names of files and no other information." Many servers (for example, SunOS) return a list that INCLUDES the names of sub-directories, while other servers do not. This difference makes life difficult for programs that attempt to make sense out of the this information. (Exactly what this command is intended for, according to the RFC.) Does anyone out there have any information that would clarify the "correct" behavior in this case? Thanks! --Pete Poorman poorman@convex.com  -----------[000361][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 15:41:55 GMT From: wayne@ultra.com (Wayne Hathaway) To: comp.protocols.tcp-ip Subject: Re: Speed of memory and fast networks (was: Need help selecting Enet cards)  David Borman says: >> HiPPI is not a ring technology. HiPPI networks are made with >> crossbar switches. You set up and tear down individual >> connections through the switch. Seperate connections do not >> interfere with each other. (e.g., if you have a connection >> between machines A and B, and another connection between machines >> C and D, each connection can pump data through at the full 800 >> mbits/sec if it is able to...) So, a HiPPI network is not used as >> a backbone in the same sense that FDDI is used as a backbone... He is of course correct that HIPPI is not a ring technology. It is in fact a *channel* technology, quite similar to the earlier Cray High Speed External (HSX) channel. He is also correct that *one* way of building "HIPPI networks" is with crossbar switches. This is reminiscent of the old days of interconnecting IBM mainframes with channel-to-channel adapters. This is by no means the *only* way of networking with HIPPI, however. It is equally possible to use the HIPPI as a traditional channel, connecting to a "control unit" (network adapter) that provides access to a traditional network, with traditional networking facilities like a wide variety of host connections, routers, network hierarchies ("backbones"), and so forth. The trick, of course, is to find a network fast enough to make a HIPPI connection worthwhile; clearly Ethernet and FDDI to *not* fit the bill. Wayne Hathaway domain: wayne@Ultra.COM Ultra Network Technologies uucp: ...!ames!ultra!wayne 101 Daggett Drive phone: 408-922-0100 x132 San Jose, CA 95134 direct: Hey, you!  -----------[000362][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 15:59:49 GMT From: dank@blacks.jpl.nasa.gov (Dan Kegel) To: alt.security,sci.crypt,comp.protocols.tcp-ip Subject: Re: "Open Systems Security" documnet available  jgd@convex.csd.uwm.edu (John G Dobnick) writes: >From article <...>, by lars@spectrum.cmc.com (Lars Poulsen): >> Arto Karila (atk@ajk.tele.fi) posted a pointer to a document about >> security in Open Systems; Dan Kegel subsequently made it available >> on a file server at JPL. I retrieved it, and it was a disaster ... >I, too, had difficulties with this. What I wound up doing was >(using the JPL files as a base): > Acquired the tar file with the individual sections. > Ignored the mass "all-in-one" file. > Printed the individual sections, individually. >It seems that the combined file has this Apple header cruft in it >that triggers our PostScript printer's "this is text" filter (the >file lacks the "%!" magic-cookie.) Our (non-Apple) printer also >seemed to choke on the Apple-specific data. >The individual sections each start with "%!" magic-bits; the document >prints without incident, although some assembly is required. :-) Ok, I am deleting the all-in-one file from blacks.jpl.nasa.gov. The tar file is still available as blacks.jpl.nasa.gov:pub/security/karila/OpenSystemsSecurity.tar.Z - Dan Kegel  -----------[000363][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 16:02:23 GMT From: schmidt@orion.oac.uci.edu (Douglas C. Schmidt) To: comp.protocols.tcp-ip Subject: Re: Interested in TLI interface VS Berkely Sockets  ++ In article <Sep.24.19.27.53.1991.1179@remus.rutgers.edu> gaddam@remus.rutgers.edu (Surekha Reddy Gaddam) writes: ++ > ++ > Can some one post the trade-offs between the TLI interface and ++ > the Berkely sockets. If you have a chance, check out chapters 6 and 7 from W. Richard Stevens excellent book on UNIX Network Programming. It covers both BSD sockets and TLI there. Doug p.s. another trade-off between the two is that in certain Sun OS releases the TLI/Streams support appears to be broken, e.g., you can't perform an orderly release! I understand this is fixed in later versions.  -----------[000364][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 16:06:59 GMT From: prakash@beast.sme.siemens.com (Veera Prakash) To: comp.protocols.tcp-ip Subject: Unsubscribe me please!!!  Please, Please remove me from the mailing list. I have sent several messages to tcp-ip-request@nic.ddn.mil and tcp-ip-request@nisc.sri.com. But, nobody has cared so far. Thanks very much, Veera Prakash <prakash@sme.siemens.com>  -----------[000365][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 16:11:48 GMT From: elogan@hp835.mitek.com (Ernie Logan) To: comp.protocols.tcp-ip Subject: Re: Correct response to FTP "NLST"?  In article <poorman.685984236@convex.convex.com> poorman@convex.com (Peter W. Poorman) writes: >Hi folks; > >I've just run across an interesting issue in the implementation of the >FTP protocol. > >RFC 959 says that the correct response to a "NLST" (Name LiST) command >is "... a stream of names of files and no other information." Many >servers (for example, SunOS) return a list that INCLUDES the names of >sub-directories, while other servers do not. > >This difference makes life difficult for programs that attempt to make >sense out of the this information. (Exactly what this command is intended >for, according to the RFC.) > >Does anyone out there have any information that would clarify the "correct" >behavior in this case? > >Thanks! > >--Pete Poorman > poorman@convex.com RFC 1123 (Host Requirements RFC) says: (I quote from "4.1.2.7 LIST and NLST Commands: RFC-959 Section 4.1.3") "The data returned by an NLST command MUST contain only a simple list of legal pathnames, such that the server can use them directly as the arguments of subsequent data transfer commands for the individual files." RFC 1123 expands on most application related RFC's, amd is the latest information for FTP. This means to me that the SunOS you refer to is NOT RFC compliant if it does what you say it does. --- Ernie Logan AS/400 TCP/IP Development elogan@oc.com OpenConnect Systems 2033 Chennault Drive Carrollton, Texas USA 75006 Phone: (214) 490-4090 *-------------------------------* * "My opinions are mine alone. * * No one else would want them." * *-------------------------------*  -----------[000366][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 16:21:25 GMT From: dzoey@terminus.umd.edu (Joe Herman) To: comp.protocols.tcp-ip Subject: Re: Correct response to FTP "NLST"?  poorman@convex.com (Peter W. Poorman) writes: >RFC 959 says that the correct response to a "NLST" (Name LiST) command >is "... a stream of names of files and no other information." Many >servers (for example, SunOS) return a list that INCLUDES the names of >sub-directories, while other servers do not. >Does anyone out there have any information that would clarify the "correct" >behavior in this case? From the Host Requirements RFC (RFC 1123) Section 4.1.2.7 "The data returned by and NLST command MUST contain only a simple list of legal pathnames, such that the server can use them directly as the arguments of subsequent data transfer command for the individual files." I interpret this to mean that you should only return file names and not sub directories in response to an NLST command. Joe Herman U. of Maryland DOSIP project. dzoey@terminus.umd.edu -- "Everything is wonderful until you know something about it."  -----------[000367][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 16:44:54 GMT From: pmanglik@tanj.intel.com (Pankaj Manglik) To: comp.protocols.tcp-ip Subject: Please unsubscribe NOW  tom@ksr.com writes: > > Please, can someone help me get off this d*mn list!!!! > Tom Varga Tom, Looks like 'you can check out anytime you want, but you can never leave'. I have been trying unsuccessfully to get off the list for the last 3 weeks. Pankaj  -----------[000368][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 16:44:56 GMT From: dsoulele@uccs.jpl.nasa.gov (Dean Souleles) To: comp.protocols.tcp-ip Subject: SLIP and/or PPP for Ultrix 4.1  I'm interested in establishing a an internet connection between a machine in Europe and a machine in the U.S. For various reasons I need to use a serial connection. I am thinking of using SLIP and/or PPP to run a TCP/IP connection with high-speed data compressing modems. inter-continental US to Europe. I plan to have some X windows clients running on the remote machine with the X server running locally. A couple of questions: 1. Is SLIP the appropriate protocol to use for this? Is there another way to do this? 2. Are SLIP and PPP independent of each other? (I.E. Do I need both of them?) 3. What is the current version of SLIP and PPP? 4. It there an Ultrix 4.x port of SLIP and PPP available via ftp (and where)? Thanks much. -- Dean Souleles dsoulele@uccs.jpl.nasa.gov dsoulele@dsfvax.jpl.nasa.gov Jet Propulsion Laboratory  -----------[000369][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 17:07:32 GMT From: donp@novell.com (don provan) To: comp.protocols.tcp-ip Subject: Re: Correct response to FTP "NLST"?  In article <poorman.685984236@convex.convex.com> poorman@convex.com (Peter W. Poorman) writes: >RFC 959 says that the correct response to a "NLST" (Name LiST) command >is "... a stream of names of files and no other information." Many >servers (for example, SunOS) return a list that INCLUDES the names of >sub-directories, while other servers do not. From RFC1123, "Requirements for Internet Hosts -- Application and Support", page 31: The data returned by an NLST command MUST contain only a simple list of legal pathnames, such that the server can use them directly as the arguments of subsequent data transfer commands for the individual files. You are confusing the OS concept of "filename" with the FTP concept of "name". This quote seems to try to clear up such confusion by refering to "pathnames", which, to me at least, clearly indicates that the directory information should, in fact, be included. The distinction between "filename" and "directory" is entirely OS specific. From an external host, the OS's filename cannot be distinguished from the OS's directory information. This leads me to think that the FTP "name" of the file should be a unique name that isn't dependent on the current context of the FTP session. Consequently, it would include the directory information. Since the 4.2BSD FTP server reacted in exactly the way you prefer, there are many implementations which are at odds with this practice. >This difference makes life difficult for programs that attempt to make >sense out of the this information. Actually, back when i was doing FTP client hacking (a *long* time ago, mind you), i found just the opposite to be the case. The problem is that as long as the user provides the NLST argument, she can use her OS specific knowledge to aim the NLST at a particular directory without the client program's knowledge. Now when the NLST response comes back, the client program doesn't have a clue how to combine what the user asked for with what came back from the server to identify a particular file. If NLST returns a pathname for the file that is unique across the entire file system, the client program can operate on each file without having to understand the user's original directory request. The Host Requirements passage i quoted above seems to be aimed at solving this problem by requiring that the returned string can be used "directly" as an argument to a file operation. In my experience, only UNIX specific FTP clients can do anything with the filename-only NLST response. (And many UNIX specific FTP client implementators seem to have difficulty understanding what makes their client UNIX specific....) don provan donp@novell.com  -----------[000370][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 17:51:04 GMT From: brian@RAY.LLOYD.COM (Brian Lloyd) To: comp.protocols.tcp-ip Subject: Using Wide-Area Point-to-Point Links for Computer Networking (I)  Truce. Sr. Martillo and I have let the PPP and SLIDE discussion slither off into personal mail. I appologize profusely for cluttering up the tcp-ip mailing list. It came from responding to mail and not paying attention to who all the recipients were. Mea culpa. Brian Lloyd, WB6RQN Lloyd and Associates Network Architect and all-around nice guy 3420 Sudbury Road brian@ray.lloyd.com Cameron Park, CA 95682 voice (916) 676-1147  -----------[000371][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 18:34:46 GMT From: craig@sics.se (Craig Partridge) To: comp.protocols.tcp-ip Subject: Re: Is MX-ing the domain-name legal?  In <1081@giga.slc.unisys.com> markb@giga.slc.unisys.com (Mark Baranowski) writes: >Is it legal to have an MX record so that mail can be sent to the >domain name rather than to a specific host? For example: > sub.domain.edu. IN MX 20 host2.sub.domain.edu. >The intent here would be for host2 to act as the domain's mailhost >and for the from-line on outgoing mail to read "user@sub.domain.edu" >so that the outside world would not be aware of hosts 1, 2, or 3. This is perfectly legal -- your informant is mis-informed. I think RFC 974 even has an example like this. Craig Partridge  -----------[000372][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 91 19:17:00 GMT From: NEWKIRK@hsdwl.utc.com To: comp.protocols.tcp-ip Subject: How to convert to legitimate network address  First, some "claimers": (1) this is the right list, (2) I do read it, and (3) I'm not the only one interested. Well, it's finally happened. We now have a bone fide class B network number and are now facing the task of converting a bogus, class A, wholly bridged network into something legitimate. Problem is, where to grab a hold? The existing network has about 500 hosts and workstations of various varieties, e.g. Sun's, HP's, Dec's (VMS & Ultrix), PC's, Mac's, etc. We also use IBM's tcp/ip code on VM and MVS, UCX on a VAX 9xxx, and so on. Our network covers about a dozen buildings, mostly "local", but some 30 miles or so away. Novell is also sprouting and there's LAT to contend with. Our current thoughts are to use a simple 255.255.255.0 subnet mask and perhaps start with Domain Name services. But that's about where the ideas stop and speculation begins. A wholesale replacement of bridges with routers isn't reasonable ($$), and a "midnight address-changing
party" is sadistic.  In a nutshell, the overall need is for an orderly
transisition from the old to the new.

So, where should we start?  Suggestions, thoughts, rules-of-thumb,
war stories, references to published documentation (RFC's?), and so on,
replies would make a useful addition to the FAQ list.

Bill Newkirk

PS: If you just can't resist, go ahead and say, "I told you so."  :-)


-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 20:54:17 GMT
From:      hobbit@FTP.COM (*Hobbit*)
To:        comp.protocols.tcp-ip
Subject:   gethostby* routines

Is it really the case that most gethostbyaddr() implementations return only
the canonical name in the hostent [hostinfo? whatever] struct, without filling
in the aliases as well?  This is sort of biting us on the suns on which we
dinked the libraries to use the domain resolver instead of the YP kludge --
now we're having to do things like put the FQDN in the exports file because
when "mountd" does its inverse lookup, all it gets back is the cname and no
aliases [I checked this with a small example program].  If gethostent()
winds up using the host table, all the aliases seem to get filled in, but not if
we're strictly using the resolver.

We further noticed that one can "work around" this by taking the one name you
get back, and doing a forward gethostbyname() on *that*.  You then get
back all the aliases.  Sure, we can mung all our various Sun libraries to
do this and hope all the executables call this same library, but it doesn't
help us for all cases and I was wondering if there was a better way to make

_H*


-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 21:11:45 GMT
From:      megauthi@watcgl.waterloo.edu (Marc E. Gauthier)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Summary of replies -- AFS, RFS & other remote file systems

Here is a summary of the replies I have gotten concerning my inquiry
would do a summary, but it has been suggested, and the material seems
of general interest.  I have edited down most replies, for brevity.

------------------  AFS  ------------------

I got very good references on AFS (mostly from Transarc, who are
maintaining/improving/commercializing it).
Perhaps the most interesting was a reference on where to get documentation
for AFS ... in AFS files!  (i.e., you'd need to be running AFS to get
them -- not useful if you're looking for docs on how to _implement_ AFS :-)
But they are available via anonymous FTP also, as described below.

> From Brian.Pawlowski@Eng.Sun.COM Wed Sep  4 03:58:28 1991
> From: Brian.Pawlowski@Eng.Sun.COM (Brian Pawlowski)
> Subject: AFS Specs
>
> I have attached two notes on AFS docs (where to get them) to get
> you started.
[I included part of the first -MEG]
>
> After reading the docs (which describe AFS 3! not AFS 4 (aka OSF DCE DFS))
> I'd be intrerested in hearing if you think it is feasible to implement
> these protocols from scratch.
>
> Keep in mind that many feel that AFS 4 (which is the most likely
> pretender, er I mean contender, to the throne currently occupied
> by NFS:-) is by some measure two to four times more complex
> than AFS 3.

> Here goes, first mail from Ed_Zayas@transarc.com.
>
> [Access is through AFS]
>
> The set of AFS-3 programmer's specification documents have now been
> released, and are publicly available in the GCO cell.  For those who
> forgot, you may access the .dvi and PostScript files for these papers in
> the following directories:
>
>       /afs/grand.central.org/darpa/doc/afs/specs/progint/
>               archov - Architectural Overview
>               bsrv - BOS Server
>               fscm - File Server/Cache Manager
>               psrv - Protection Server
>               rx - Rx, LWP
>               vvl - Volume/Volume Location Server

> From erz+@transarc.com Wed Sep  4 11:19:53 1991
> From: Ed._Zayas@transarc.com
> Subject: Re: AFS 3 documentation?
>
> Marc...
>
> Yes, you're right, AFS is not free (cheap, but not free).  Anyway, we
> did indeed think ahead to the fact that people not running AFS might
> like to look at these documents.  We've set up an anonymous FTP service
> here, and the specs are available in this fashion.
>
> The host you want to FTP from is grand.central.org (IP address
> 192.54.226.100, just in case name mapping is a problem for you).  You'll
> find yourself sitting in the equivalent of the /afs/grand.central.org
> AFS directory.  The AFS-3 programmer specs are, as you might imagine,
> visible in the following directory:
>
> 	darpa/doc/afs/specs/progint
>
>
> Please make sure to forward any comments, suggestions, etc. to me having
> to do with the AFS prog spec suite.  Also, please tell your friends who
> don't normally read this bboard that they are there for the sharing.
>
> As far as the AFS-4 stuff, I don't believe the specs are publicly
> releasible yet.  However, there was a paper presented at the Summer 1990
> Usenix that might interest you.  It is entitled DEcorum File System
> Architectural Overview'', and gives a flavor of what's going on in
> AFS-4''.  If you don't already have it or can't easily get a hold of
> it, I'm moving the on-line version of it to GCO.  You'll be able to find
> it, again via anonymous FTP, in the following directory [...]:
>
> 	darpa/doc/afs/dce/usenix90

> From erz+@transarc.com Tue Sep 10 10:20:55 1991
>[...]
> You can use the following reference for the Usenix DFS paper:
>
> 	Michael L. Kazar, Bruce W. Leverett, et. al.,
> 	Decorum File System Architectural Overview'',
> 	USENIX Conference Proceedings,
> 	Anaheim, TX, Summer 1990

[ The USENIX paper is also available in PostScript.  I've put the paper,
as well as the .dvi version of AFS specs, available via anonymous FTP
from our site is often quite slow. -MEG ]

> Elaine Wolfe
> Marketing Services
> Transarc Corporation
> The Gulf Tower, 707 Grant St.
> Pittsburgh, PA 15219
> (412) 338-4448
> elaine@transarc.com

[ I thought I might as well include this, for people actually interested
in getting AFS.  -MEG ]

------------------  RFS  ------------------

> From doug@access.digex.com Thu Sep  5 06:28:13 1991
> From: "Douglas E. Humphrey" <doug@access.digex.com>
>
> [...] I know that RFS is an AT&Tism,
> found in System V UNIX, so AT&T via some channel would be the
> place for that.
> [...]

------------------  Misc  ------------------

> From watstar@sail.uwaterloo.ca Wed Sep  4 17:15:53 1991
> From: WATSTAR at UW <watstar@sail>
>
>[...]
> There are two more:
>    UNIX's remote tape protocol (RMT?) which is a very limited random access
>    system.  Only one file at a time, but its random access makes it more
>    useful than ftp at times.
>
>    Andy Taunenbaum & Co. at the Free (Vrie) University in Holland have designed
>    the bullet server which runs on their amoeba protocols.  Typical network
>    disk throughputs of about 600Kbytes/s was their claim about two years ago.
>    That is roughly four times typical NFS, eh?
>    The amoeba system is very popular in Europe.
>
> Erick

> From forsyth@minster.york.ac.uk Thu Sep  5 06:39:18 1991
> Subject: file system protocols
>
> the 10th edition's file system protocol is described in volume 2
> of the UNIX Programmer's Manual (10th Edition),
> which has been published as a book by Saunders College Publishing.
> it is interesting because it is relatively straightforward.
> it is worth looking up the articles by L Marshall about the
> Newcastle Connection.
> a decent one should take less than 1000 lines of C at each end!
> the Newcastle Connection takes more because it does more
> (it distributes all unix system calls, not just file system operations).
> NFS takes more because .... [your entry here, 30 words or less].

> From droms@sol.bucknell.edu Mon Sep  9 09:36:10 1991
> From: droms@sol.bucknell.edu (Ralph E. Droms)
>
>    Is there any available documentation on the AFS (Andrew File System)
>    and RFS (??? Remote File System) remote file system protocols?
>
> I know of a couple - the attached list is extracted from an NFS
> bibliography I've compiled as part of a two-day NFS tutorial.  (Sorry
> for the LaTeX format.)  BTW, RFS == "Remote File Sharing".
>
> - Ralph Droms                 Computer Science Department
>   droms@bucknell.edu          323 Dana Engineering
>                               Bucknell University
>   (717) 524-1145              Lewisburg, PA 17837
>
> -----
> \section{AFS (Vice--Virtue)}
>
> \begin{itemize}
>
> \item Morris, J. H., M. Satyanarayanan, M. H. Conner, J. H. Howard, D.
> S. H. Rosenthal and F. D. Smith, Andrew: a distributed personal
> computing environment, {\em Comm. of the ACM 29} 3, (March 1986), 184--201.
>
> Describes the Andrew computing environment, including the VICE--VIRTUE
> file system, the Andrew window system and Andrew support for
> distributed applications.
>
> \item Satyanarayanan, M., J. H. Howard, D. A. Nichols, R. N.
> Sidebotham, A. Z. Spector, M. J. West, The ITC distributed file
> system: prinicples and design, {\em Proc. of the 10th ACM Symp. on Op.
> Sys. Prin.} (Dec. 1--4 1982), 35--30.
>
> Details the architecture and implementation of the VICE--VIRTUE file
> system.
>
> \item Howard, J. H., M. Kazar, S. G. Menees, D. A. Nichols, M.
> Satyanarayanan, R. N. Sidebotham, M. J. West, Scale and performance in
> a distributed file system, {\em ACM Trans. on Comp. Sys.  6} 1 (Feb.
> 1988), 51--81.
>
> Compares the performance of VICE--VIRTUE and NFS.
>
> \item Satyanarayanan, M., Integrating security in a large distributed
> system, {\em ACM Trans. on Comp. Sys. 7} 3 (August 1989), 247--280.
>
> Describes the integration of identification, verification and
> encryption in the VICE--VIRTUE file system.
>
> \end{itemize}
>
> \section{RFS}
>
> \begin{itemize}
>
> \item Rifkin, A. P., M. P. Forbes, R. L. Hamilton, M. Sabrio, S. Shah
> and K. Yueh, RFS architectural overview, {\em Proc. of the Summer 1986
> USENIX Conf.}, 248--259.
>
> Describes AT\&T's RFS, with details of the implementation and the
> mechanisms with which RFS preserves \unix\ semantics.
>
> \item Bach, M. J., M. W. Luppi, A. S. Melamed and K. Yueh, A
> remote--file cache for RFS, {\em Proc. of the Summer 1987 USENIX
> Conf.}, 273--279.
>
> Illustrates the use of caching to improve the performance of RFS.
>
> \item Harris, D., Remote File System, in {\em \unix\ Networking}, S. G.
> Kochan and P. H. Wood, eds., Hayden Books, Indianapolis, IN, 1989,
> 203--236.
>
> An overview of RFS.
>
> \end{itemize}

[ A much more complete and readable version of this bibliography has been
made available by its author via anonymous FTP from nri.reston.va.us
in rdroms/{nfs-biblio.txt , nfs-biblio.PS} (latter file is in PostScript
format).  It covers many areas of distributed file systems, and includes
comments on the references too.  -MEG ]

> From gdmr@dcs.edinburgh.ac.uk Fri Sep  6 04:45:38 1991
>
> FTAM?  (The ISODE version, for example.)

[ The following was useful when looking for references in USENIX
proceedings (just grep through the bibliography file)...  -MEG ]

> From andrea@usenix.org Fri Sep  6 16:51:48 1991
> From: andrea@usenix.org (Andrea Galleni)
> Subject: Re:  Online Usenix proceedings?
>
>                 USENIX Online Library/Index
> What Is It:
>      The USENIX online index is an electronically  available
>      related groups.  The index is kept as  a  simple  ASCII
>      file,  in  refer/bib format, sorted by author, and con-
>      tains information  about  papers  published  in  USENIX
>      conference and workshop proceedings, newsletters, jour-
>      nal, and the like.
>
> How to Get the Index [200k long!]:
>
>              echo send bibliography | mail uunet!library
>
>      Or, via anonymous ftp to uunet.uu.net:
>
>              ftp> get library/bibliography

-Marc
--
Marc E. Gauthier   megauthier@watcgl.waterloo.edu
Computer Graphics Lab, University of Waterloo  [129.97.140.64]  +1 519 888 4548


-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 21:49:29 GMT
From:      schmidt@net4.ics.uci.edu (Douglas C. Schmidt)
To:        comp.protocols.tcp-ip
Subject:   obtaining the maximum UDP packet size


Hi,

I'm curious to know if there is any portable way to determine
the largest packet size devliverable via UDP (other than just
experimenting until it fails ;-)).  I notice that in rfc 1122, in
section 4.1.4 it says:

----------------------------------------
4.1.4  UDP/APPLICATION LAYER INTERFACE

The application interface to UDP MUST provide the full services of the
IP/transport interface described in Section 3.4 of this document.
Thus, an application using UDP needs the functions of the
calls described in Section 3.4.  For example, GET_MAXSIZES() can be
used to learn the effective maximum UDP maximum datagram size for a
particular {interface,remote host,TOS} triplet.
----------------------------------------

It doesn't seem that any of the socket options available via
getsockopt return this informtion.  Can someone tell me how to obtain
this info?  For example, it appears that Sun OS 4.x has a limit of
around 8k bytes, but that number doesn't seem to appear in any header
files.

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."         | (714) 856-4101
-- In loving memory of Terry Williams (1971-1991)|


-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 22:12:45 GMT
From:      olinger@halley.est.3m.com (Randy M. Olinger)
To:        comp.protocols.tcp-ip
Subject:   DecNet Version of RCPGEN

Is there an easy to port client-server programs built using RPCGEN
to a VAX that has TCP/IP??  I have a simple pserver rogram that accesses a
database on unix and returns the result to a client program.  I would
like to have the client running on several hardware platforms, and so
far all the UNIX platforms have been no problem (HP, Sun, Ultrix).  I
do not want to make the VAX's in our department (or company)
outcasts...

I also don't want to go and learn all the low-level pipe type stuff,
but may have to.

Any help would be appreciated

--
Randy M Olinger


-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 23:07:10 GMT
From:      schoff@uu.psi.com (Martin Schoffstall)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Wireless network connections?

There are a few purveyors of WideArea Wireless networking also, which
are appropriate to the laptop mobile environment; however, the bandwidth
is less than 56kbps and user software is nearly non-existant, this is

Marty


-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 91 13:17:37 GMT
From:      bin@primate.wisc.edu (Brain in Neutral)
To:        comp.protocols.tcp-ip
Subject:   Re: Is MX-ing the domain-name legal?

From article <1991Sep27.183446.27144@sics.se>, by craig@sics.se (Craig Partridge):
In <1081@giga.slc.unisys.com> markb@giga.slc.unisys.com (Mark Baranowski) writes:
>Is it legal to have an MX record so that mail can be sent to the
>domain name rather than to a specific host?  For example:

>    sub.domain.edu.     IN      MX     20   host2.sub.domain.edu.

I hope so, because that's what I do here.  The intent is to allow our
a logical entity which remains stable over time, rather than email addresses
containing the names of particular machines (short term entities which
change over time).

When the machine to which the domain is mx-ed is retired, you just change
the mx record in your dns info.

(Of course, it might require a bit of messing around to make sure that
mail gets routed to the correct machines for particular users...)

--
Paul DuBois
dubois@primate.wisc.edu


-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 91 13:51:59 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Interested in TLI interface VS Berkely Sockets

The big difference (IMHO) is that 95% of the applications today are
written to the socket interface, and 5% use TLI.  I keep looking for
people using TLI outside of AT&T and there don't seem to be many.
Sun/AT&T helped solidify this with their abysmal implementation of
TLI in SunOS 4.1 (and their statement that all new applications
were supposed to written to TLI).  Berkeley also helped solidify
this with their implementation of the OSI protocols in 4.3BSD Reno
with few changes required to the socket interface.  (As I recall,
circa 1986 AT&T's reason for developing TLI was that sockets
wouldn't be usable with OSI.)

Regardless, it appears both will be around as the POSIX 1003.12
working group is recommending both as part of their DNI.

As a matter of interest, is anyone aware of any Unix or non-Unix
systems other than System V derivatives and SunOS that provide TLI?

Rich Stevens  (rstevens@noao.edu)


-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 91 22:27:55 GMT
From:      revco@REVCO.MED.YALE.EDU (Jim Revkin)
To:        comp.protocols.tcp-ip
Subject:   unsubscribe

please unsubscribe me from the tcp-ip mailing list.
i never realized how much correspondence would be involved.

thanks,

jim revkin aka

revco@revco.med.yale.edu


-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 91 22:38:34 GMT
From:      mshiels@TMSoftware.ca (Michael A. Shiels)
To:        comp.protocols.tcp-ip
Subject:   socket interface to X.25 or NetBIOS?

Are there any unix machines out there which implement a socket interface
to X.25 and/or NetBIOS.  With the advent of LAN Manager and better access
to the lower layers of Ethernet it seems possible for Unix manufacturers
to implement NetBIOS protocols for unix.  Just thought I'd check what's
--
---

Michael A. Shiels                           | mshiels@masnet.uucp
MaS Network Software and Consulting         | mshiels@tmsoftware.ca


-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 91 07:00:55 GMT
From:      jt@mentat.com (Jerry Toporek)
To:        comp.protocols.tcp-ip
Subject:   Re: Interested in TLI interface VS Berkely Sockets

In article <1991Sep28.135159.720@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:
>
>As a matter of interest, is anyone aware of any Unix or non-Unix
>systems other than System V derivatives and SunOS that provide TLI?
>

Yes.  OSF/1 and Netware 386 include TLI libraries based on the Mentat version.

Digital supplies an XTI (over sockets) library with Ultrix. (XTI is a superset
of TLI defined by X/Open.)

OSF/1 also includes an XTI Streams interface to sockets-based protocols (known
as XTISO).

There are several others that may not be publicly announced yet that will be
available real soon now.

--
Jerry Toporek ========================   ''  ===============================
jt@mentat.com                          < @ @ >      Mentat Inc.
uunet!mentat.com!jt                     ( > )       1145 Gayley Ave, Suite 315
(213)208-2650 Ext-24                     \~/        Los Angeles, CA 90024


-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 91 15:15:59 GMT
From:      geoff@vindaloo.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
To:        comp.protocols.tcp-ip
Subject:   Re: Interested in TLI interface VS Berkely Sockets

Quoth rstevens@noao.edu (W. Richard Stevens) (in <1991Sep28.135159.720@noao.edu>):
#As a matter of interest, is anyone aware of any Unix or non-Unix
#systems other than System V derivatives and SunOS that provide TLI?

The PC-NFS Programmer's Toolkit 2.0 (which is shipping but has not
yet been formally announced - >sigh<) includes XTI (X/Open cleaned
up version of TLI) and sockets for DOS.

Geoff

--Geoff Arnold, PC-NFS architect(geoff@East.Sun.COM or geoff.arnold@Sun.COM)--
------------------------------------------------------------------------------
--       Sun Technology Enterprises : PC Networking group                   --
--                (a Sun Microsystems Inc. company)                         --


-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 91 17:48:36 GMT
From:      howard@thumper.bellcore.com (Howard Bussey)
To:        comp.dcom.lans,comp.dcom.modems,comp.lang.c,comp.os.vms,comp.protocols.tcp-ip,comp.sys.dec,comp.unix.wizards,comp.sys.cdc,comp.sys.prime,comp.sys.ibm.pc.hardware
Subject:   Re: Help Requested in Defeating Ring Buffer Software Patent

The SCOPE (and later KRONOS and NOS) operating systems on the CDC 6000
and 7000 series used a circular buffer for I/O.  The control structure
was like:

struct CBUFFER {
int *first, *in, *out, *limit;
};

first and limit pointed to the first, and 1 past the last "words" in the
buffer (so the size of the buffer is (limit - first)).

in and out pointed to the next available word for writing and reading,
respectively.

in==out implied the buffer was empty. in+1 == out (in the equivalence
class implied by CBUFFER) meant the buffer was full.

The constraints were first <= {in|out} < limit.

This was used to allow a program to read or write data (even
continuously!).  Most of the operating system ran in peripheral
processors (PPs).  When an I/O operation was started, with the CIO
(Combined I/O) service, a PP was allocated to the request.  It would
poll (yes, poll!) the CBUFFER structure.  When (in != out), the PP would
transfer data.  So the CBUFFERs were used for inter-processor
communication.  Actually, the PPs were only 1 processor, which
time-multiplexed itself each microsecond among 10 or 20 different
contexts, resulting in what looked like 10 or 20 individual PPs (each
with 1 microsecond instruction cycle times).

The SCOPE/KRONOS/NOS operating system may have allowed several
simultaneous and independent transfers.  I do know that tape-tape copies
could keep the tapes spinning continuously.

[N.B. IMHO, the 6600 was the first RISC machine! please, discussion
directly to me]

--------------------------------------------------------------
Howard Bussey <howard@thumper.bellcore.com>
Bellcore Room 2P-288/445 South Street/Morristown NJ 07962-1910
voice: +201 829 44 79; fax: +201 829 58 88


-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 91 19:05:11 GMT
From:      wilker@gauss.math.purdue.edu (Clarence Wilkerson)
To:        comp.dcom.lans,comp.dcom.modems,comp.lang.c,comp.os.vms,comp.protocols.tcp-ip,comp.sys.dec,comp.unix.wizards,comp.sys.cdc,comp.sys.prime,comp.sys.ibm.pc.hardware
Subject:   Re: Help Requested in Defeating Ring Buffer Software Patent


Most interrupt drive io systems for Z80 's in the late 70's used ring bufferes of some kind. I'm
pretty sure the console io on the Heath-Zenith H89 used this, and the Mostek io modules did
also.
Clarence Wilkerson


-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 91 19:51:03 GMT
From:      sandee@Think.COM (Daan Sandee)
To:        comp.dcom.lans,comp.dcom.modems,comp.lang.c,comp.os.vms,comp.protocols.tcp-ip,comp.sys.dec,comp.unix.wizards,comp.sys.cdc,comp.sys.prime,comp.sys.ibm.pc.hardware
Subject:   Re: Help Requested in Defeating Ring Buffer Software Patent

This in response to Dave Goldblatt's request on the history of circular buffers,
and as comment on Howard Bussey's response.
Note I have set the followup to comp.sys.cdc, so we old CDC hands can go and
wallow in nostalgia without annoying the rest of the universe further.
There's still stuff that I don't know either that Dave would want to know,
i.e. the real first date, so this is a hint to Dave to keep reading this
newsgroup, as more details may turn up. -- Daan.

In article <882@salt.bellcore.com>, howard@thumper.bellcore.com (Howard Bussey) writes:
|> The SCOPE (and later KRONOS and NOS) operating systems on the CDC 6000
|> and 7000 series used a circular buffer for I/O.  The control structure
|> was like:
|>
|> struct CBUFFER {
|>  int *first, *in, *out, *limit;
|> };
[ excellent description deleted ]

|>  ..............  Actually, the PPs were only 1 processor, which
|> time-multiplexed itself each microsecond among 10 or 20 different
|> contexts, resulting in what looked like 10 or 20 individual PPs (each
|> with 1 microsecond instruction cycle times).

(not quite relevant, and not quite correct either. With 20 PPs, there were
*two* PP chassis each acting as 10 logical PPs in a slot-and-barrel
arrangement. Only the 6000 series ; don't know about 7000 series ; Cyber 70's
were the same but optionally had 7 PPs per chassis ; Cyber 170s from Model D
onwards had real hardware individual PPs).

|> The SCOPE/KRONOS/NOS operating system ....
Well, there's SCOPE, later known as NOS/BE ; and KRONOS, later known as
NOS. That's two operating systems.
The fact that both Scope and Kronos had circular buffers means that the
feature must be *very* old. After 1970, they weren't talking to each other.
In fact, lots of the Scope and Kronos development consisted of the two sides
(re)inventing the same wheels, though in a different order.

|>   ..... may have allowed several
|> simultaneous and independent transfers.  I do know that tape-tape copies
|> could keep the tapes spinning continuously.

At least in SCOPE, the CPU-resident program could set up TWO of these structs
(called File Environment Tables, or FETs), one for reading, one for writing,
using the same buffer, then fire up one PP for reading and one for writing.
The read PP would move the IN pointer, and the write PP would move the OUT
pointer, and the CPU program could sit back and watch. This mechanism was known
as pointer chasing. In this manner a tape-to-tape copy would proceed at full
tape speed. If there was a hitch (say, error recovery on read) the write PP
would find the buffer empty and give up. The CPU program would regain control,
wait for data to be available, and fire up the write PP again.

|> --------------------------------------------------------------
|> Howard Bussey <howard@thumper.bellcore.com>

Dave's original request was for any code before Oct 81. Well, I can find code
which I *think* I wrote around 1976. But the basic principle was in CDC
operating systems *at least* in the very early 1970's. Before my time, anyway.
I first heard of this method in late 1973. (I wonder, do I still have the
SCOPE 3.4 Handbook, dated 1972 or 1973, which describes this?)
Is Greg Mansfield out there ? or Dave Cahlander ? Or Seymour Cray, for that
matter : I don't think he invented it, but I'm sure he knows who did.

Daan Sandee                                           sandee@think.com
Thinking Machines Corporation
Cambridge, Mass 02142


-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 00:25:08 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: zero windows & probes (was - Re: TCP FIN and window)


>1) In a modern TCP, the receiver window will never be o unless the
>   destination device is slower than the network link.

Destination devices slower than networks are quite common.  I just
tried an experiment on a Sun 4/370 with fddi & a SCSI disk.  I sent
800 KB from a faster machine to the 4/370, which was writing the data to
its SCSI disk.  A 0 window occurred 4 times during the transfer.

Please don't consider a 0 window an "unusual" event, or one that only
happens with very slow devices.

I'm not (I work on terminal servers all the time, and network interfaces are
certainly getting to the point that they can be faster than disks.)  In a
sense, this is EXACTLY the point I'm trying to make.  Doing 0 window probes
based on network RTTs does not really make any sense at all.  What you
really need to know is how long before the window SHOULD open again (which
is dependent on the IO device), and NOT on how long it should take to get
a repsonse back (which is only dependent on the network (in theory, anyway.))

> 4) Probes are a failsafe technique for recovering from am ACK that would
>    open the window being lost.  Lost packets are rare.

Maybe not that uncommon in wide-area networks.  I think starting with
a fairly fast "zero-window" probe is a good idea.  Perhaps RFC 1122's
suggestion of 1 RTT is a bit quick, but the 5 seconds in Berkeley is
definitely too long.

Even in WANs, dropped packets are relatively rare.  5 seconds is probaly
too long (there are applications that would take 5 seconds to get rid of
a (1500 byte) packet, but they are pretty rare, and even a small system
can probably put up with a probe more often than every 5 seconds).  Before
it gets changed, I'd like to see statistics on how often that time has to
go off to illicit a window update that was lost...

BillW
-------


-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 02:04:39 GMT
From:      rvp@surf.sics.bu.oz.au (Rey V. Paulo)
To:        comp.protocols.tcp-ip
Subject:   Re: cisco router performance (was selecting a fast ethernet card).

We are installing a new MAC running A/UX.  It is connected to one subnet
in our class B network.  After the installation, it appears that the new
host doesn't understand subnetworking.  For instance, I can run telnet,ping,
etc. to any other host in the same subnet but all hosts outside the subnet
are unreachable.  Has anyone encountered similar problems?  I would
appreciate any help or suggestion.

Many thanks.
--
Rey V. Paulo                  | Internet:  rvp@surf.sics.bu.oz.au
Bond University               | I am not bound to please thee with my answer.
AUSTRALIA                     |         -Shylock, in "The Merchant of Venice"
------------------------------+----------------------------------------------


-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 04:56:22 GMT
From:      skl@cs.sfu.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: socket interface to X.25 or NetBIOS?

In article <mf-13g5xj@tmsoft>, mshiels@TMSoftware.ca (Michael A. Shiels) wrote:
>Are there any unix machines out there which implement a socket interface
>to X.25 and/or NetBIOS.

The UBC X.25 support for BSD/SunOS had a socket interface, and
since the 4.4 BSD X.25 support is based on that, it should have
it as well.

...Sam
--
<skl@cs.sfu.ca>


-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 10:38:41 GMT
From:      AKayser@dnpap.et.tudelft.nl (Alfred Kayser)
To:        comp.protocols.tcp-ip
Subject:   Re: Speed of memory and fast networks (was: Need help selecting Enet cards)

BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes:
>    The argument put forth by my colleague is that memory speed on
>    most computers is so slow that, when using a protocol like TCP
>    which typically (most common implementations) touches memory at
>    least three times (DMA into memory and copy from kernel to user
>    space - I didn't count the checksum), high data rates to the
>    application just aren't possible.

>This assumes that the DMA into memory and the kernel to user copy
>take their bytes from the same chunk of memory bandwidth.  One would
>hope that any architecture designed for high I/O bandwidth would be
>able to do a lot of I/O into memory without having any effect on the

>    For example, we measured the memory speed of a Vax 6310 at
>    around 8 MBytes/sec.  If memory is touched three times for a
>    TCP connection, that means a maximum possible data rate of less
>    than 3 MBytes/sec.  So even if we have a HiPPI connection on
>    this machine, we aren't going to do any better than 3 MB/sec.

>The number is suspicious (it works out to 1 (32 bit) memory transfer
>every 500 nS.  While this might be typical for transfering data over a
>bus (an old bus, anyway), but sounds way wrong for "integrated" memory.
>Maybe the bcopy that you are using needs improving...

It sure looks like it. Look at this sheet posted at comp.benchmarks:
}Newsgroups: comp.benchmarks,comp.arch
}Subject: Attainable memory bandwidth
}Message-ID: <MCCALPIN.91Sep27212326@pereland.cms.udel.edu>
}Date: 28 Sep 91 01:23:26 GMT
}Sender: usenet@ee.udel.edu
}Organization: College of Marine Studies, U. Del.
}
}==========================================================
}Memory Transfer Rates in MB/s for Standard Fortran Kernels
}==========================================================
}John D. McCalpin			September 24, 1991
}mccalpin@perelandra.cms.udel.edu	DELOCN::MCCALPIN
}
}The following table presents the results of a simple test of the
}memory bandwidth of a computer running some simple vector kernels
}coded in Fortran.  In each case, only the memory transfer rate in
}Millions of Bytes per second (MB/s) is shown.
}
}Machine		Copy	Scale	Sum	SAXPY
}------------------------------------------------------
}IBM RS/6000-950	190.5	163.3	184.6	187.5
}IBM RS/6000-530	145.5    88.9   109.1   120.0
}IBM RS/6000-320	 58.2	 55.7	 60.0	 60.0
}SGI 4D/240		 35.6	 22.1	 34.9	 25.6
}DEC 5000		 25.9	 25.6	 23.1	 21.8
}Sun 4/490		 25.0	 16.7	 24.0	 19.4
}Sun SS1+		 28.6	 12.3	 25.5	 13.3
}SGI 4D/25		 23.7	 11.6	 17.8	 13.7
}Sun SS1		 24.6	  9.3	 24.0	  9.6
}------------------------------------------------------
}
}The test shows how well the memory system can move large (uncacheable)
}contiguous arrays around and how much the work of FP operations can be
}overlapped with the waits on cache misses.  The results on the latter
}range from superb (IBM 320) to awful (Sun SS1).
}
}Fortran code ommitted.
}--
}John D. McCalpin			mccalpin@perelandra.cms.udel.edu
}Assistant Professor			mccalpin@brahms.udel.edu
}College of Marine Studies, U. Del.	DELOCN::MCCALPIN (SPAN)

This shows that advanced machines can easily produce a data stream
of 50Mbytes/sec or more. The other reason for research on high speed
networks is that there is also research on high speed memory.

>I would also claim that if the bandwidth one gets from their network is
>the same as the bandwidth that one gets from their memory, then this IS
>a "high data rate to the application").  One might as well claim that
>gigabit networks are useless because they are faster than any existing
>disk drives, so what would be the point during FTPs.

>In fact, I'd go so far as to say that the entire point of very high speed
>networking is to remove the distintion between remote and local data.
This is exactly the ultimate goal. (IMHO)
--
-- Ir. Alfred Kayser. PACS, OS/2, TCP/IP. --- Email: AKayser@et.tudelft.nl --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --


-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 14:53:58 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

Having looked over the slide and slither "rfcs", and the
assoicated mail, I have cleverly decided to stay out of the
philosophical discussion. However, there are a few mis-statements
of "facts" that I feel compelled to respond to....

Firstly, the idea of using (essentially) the ethernet encapsulation on
serial line is tempting.  No need to write a new RFC for each new protocol,
potentially better error checking, shared device driver code.  So you
waste a few header bytes - it's a high speed line, it doesn't matter much.
Ethernet has been areound for a while now, and everyone is familiar with it.

1) There is good evidence to believe that PPP is going to be
incompatible with the latest generation of serial chips which support
ether modes and with the latest generation of ether chips which
support serial modes.

...if the serial chip has an interface to the host processor which
looks like the interface to a common ethernet chip, or if in fact
common ethernet chips can be programmed to do hdlc bit stuffing,
software development is a lot cheaper if the changing one or two lines
of the initialization code of the ethernet driver is sufficient to
turn the ethernet driver into a serial hdlc driver.

A) The fact that some ether/serial chips are capable of supporting both
formats does not make PPP "incompatible" with these chips.
B) Defining "standards" based on available chips is backwards, sort of.
C) I count only 1 (one) more chip familly supporting both (The Zilog).
The last generation of Intel chips (in fact, the 82586 was the first
second generation ethernet chip available) also supported many modes.
The AMD ILLAC does NOT support serial modes according to the latest
documentation I've seen.
D) The interface device driver is such a small portion of the software
that makes up a modern multi-protocol multi-media bridge/router that
the cost savings of having a "single driver" are pretty small.
E) Those savings are offset by the overhead and difficulty of providing
unnecessary protocols for the serial line (eg ARP).
F) And it still doesn't help all those interfaces that are neither
HDLC nor EtherNet (TR, FDDI, T3, ULtraNet, ISDN, ATM, etc...)
G) No matter how hard one tries to pretend otherwise, a serial PtoP
link is NOT an ethernet.  Trying to treat it like one is probably
not a very good idea.

2) Only the bridging version of PPP contains sufficient information
that sophisticated mesh topologies of serial links can be supported.
Such mesh topologies are often desirable when seeking high reliability
and availability in a network.

I'm sure the router vendors who have been offering boxes that support
"sophisticated mesh topologies" for the last 5 years will be surprised
to hear this.  Or did you mean "only the bridging version of PPP contains
sufficient information to to bridging"?

3) Unfortunately, the bridging version of PPP contains variable length
goop in front of the MAC packet.  Many microprocessors, like the AM29k
or IBM ROMP (used in the RT/PC) have no real capabilities for dealing
with multiple allignments of data.  The Intel 80x86 microprocessors
can handle multiple allignments of data, but will produce much lower
performance when doing so.

I re-read the RFC, because I didn't believe that Fred Baker (with the IETF
looking over his shoulder) would do anything this stupid, and I was right.
It looks to me like for an equivilent configuration, the PPP bridging spec
"factors" out to a fixed packet format:

A) There is an optional "LAN ID" word.  I'd assume that this is either
there on essentially all packets, or never, in a particular network.
In any case, it's 32 bits long, so it doesn't affect alignment.
B) If you are bridging either 802.4 or 802.5, you can get packets with
another 16 bits of "stuff" in them.  I don't think that you can both
types of packets on the same link (otherwise SRT or 8209 style symantics
would come into play, converting the packets to one form or ther other).
Even if you could, I don't see how this would affect overall speed.  Since
you have to do table lookups of both source and destination "ethernet"
addresses, one of them is never aligned on 32 bit boundries...

4) PPP is too complex in other ways (primarilly the link control protocol)

This is probably true, although it is not too difficult to implement the
"minimal subset" of PPP.  All during the period that PPP was being defined
(two years!), there were occasional talks amoung router vendors about
bypassing "all that async-oriented" stuff and coming out with a de-facto
industry standard based on someone's (anyone's!) existing sync spec.  But
we didn't...  You can always get stuck like the rest of us - run PPP when
you need to talk to another vendor, and your own protocol when that won't
work for some reason.

BillW
-------


-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 15:16:52 GMT
From:      I.Wakeman@cs.ucl.ac.uk
To:        comp.protocols.tcp-ip
Subject:   Re: Distributed file systems and TCP

O
Krishnakumar K. writes in response to the question without attribution:
>>
>>    Why don't all distributed filesystems simply use TCP/IP for data
>>    communication?
>>
>
>It is quite clear that distributed file systems can live very well
>without TCP. In most cases (if not all) the reply to the file system
>call acts as the acknowledgement also and this renders the specific ack
>to the call as required by TCP unnecessary. In most distributed file
>systems completion of the call is the responsibility of the client and
>so the client can always make an extra call in case of a lost reply.
>Things being so, I feel that distributed systems are well off without TCP
>and the extra traffic.

I  agree with you (up to a point) when you're running a filesystem over an
archetypal, high speed, low error rate, local area network; but if
you're running a file system distributed over a wide area network, all
the assumptions about the operating environment change, and a whole new
set of network algorithms have to be used, especially to look after
congestion problems. Whilst it is possible to build the mechanisms to
cope with WANs into your transaction mechanism over UDP, you only end up
reproducing the functionality of a reliable transport protocol such as
TCP. So, since if you're putting a file system over a high latency
network one ought to be doing some form of file caching (a reason for
ditching NFS and moving to something more sensible like AFS), which
requires bulk transport anyway, go for a reliable tranport protocol in
the first place - its a win in the long run.

>
>>With any luck, we and Interstream (at least) will be demonstrating NFS over
>>TCP at Interop.
>>
>Isn't NFS good enough with just UDP?

Over a congested WAN - No.
>
>Krishnakumar K.
>dept. of CS
>SUNY Albany
>
>email: krishna@cs.albany.edu
>

ian

Ian Wakeman                                       +44 71 387 7050 ext 3706
Internet: I.Wakeman@cs.ucl.ac.uk    UUCP: ...!{uunet,ukc}!ucl-cs!I.Wakeman
Computer Science, University College London, Gower Street, LONDON WC1E 6BT


-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 15:45:14 GMT
From:      tar@math.ksu.edu (Tim Ramsey)
To:        alt.sys.sun,comp.protocols.tcp-ip
Subject:   whois and SunOS 4.1.1

hilbert% uname -a
SunOS hilbert 4.1.1 3 sun4

hilbert% whois \!tar13

When we understand knowledge-based systems, it will be as before --
except our fingertips will have been singed.
-- Epigrams in Programming, ACM SIGPLAN Sept. 1982
----------------------------------------------------------------------
Hi!  You have attempted to contact a whois server at SRI-NIC.ARPA.
vendor is really out of it.  Please complain to them.
To contact the current DDN NIC WHOIS server, it will be
necessary to either:

a) Use a command-line option to tell your WHOIS client
to connect to a different host (NIC.DDN.MIL),

b) Or, recompile WHOIS with the CORRECT name for the DDN NIC,
NIC.DDN.MIL, in place of the ancient SRI-NIC.ARPA.

contractor, GSI, at 1-800-365-3642.  Thank You.
--------------------------------------------------------[caw 91/09/24]

I guess it's official.  Sun is really out of it.  :-)

(time to recompile whois)

--
Department of Mathematics, Kansas State University, Manhattan KS  66506-2602


-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 15:54:32 GMT
From:      solomon@becks.comm.mot.com (James Solomon)
To:        comp.protocols.tcp-ip
Subject:   PD Implementation of TCP/IP


Greetings:

Does anyone know of any source code for TCP/IP available via anonymous FTP?  I
am aware of the BSD4.3 code on uunet.uu.net but I'm looking for something that
has more comments (yes, I ask the world ;-) and is not meant to be part of
the kernel.  Please send Email and I'll summarize if there is significant
interest.

Gracias,
--
Jim Solomon (solomon@becks.comm.mot.com)


-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 16:12:06 GMT
To:        comp.protocols.tcp-ip
Subject:   Re: MVS-TCP/IP


>From: sbi!pivot-sts!cassidy!dxe@uunet.uu.net  (Dan Ellsweig - Network planning)
>Subject: MVS-TCP/IP
>Message-Id: <540@pivot-sts.sbi.com>
>To: tcp-ip@nic.ddn.mil
>Status: R

>Greetings fellow netters.....

>We here at Salomon Brothers have begun to investigate the offerings
>by IBM which place IBM at the fringe of the distributed processing
>environment as we know it. Specifically, the offering which opens
>the entire IBM product line by allowing TCP/IP interconnect.
>
>I am wondering if there are network users out there who may have
>specific experience ( good and bad ) in using the IBM TCP/IP
>products - MVS-TCP/IP in particular.
>
>We are interested in using the FTP, NFS, SNMP, Mail and MVS socket
>libraries. All input is welcome!!!!!!
>
>In addition, any information regarding future products such as
>the CICS-TCP/IP interface or information on IMS access via TCP/IP
>would be welcome.

Interlink Computer Sciences markets SNS/TCPaccess for MVS.  It
contains FTP, SMTP, Sockets, etc.  SNS/NFS is also available
for NFS support.

------------------------------------------------------------------------
Interlink Computer Sciences	AT&T : 301-317-6600
Columbia, MD 21046
------------------------------------------------------------------------


-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 19:05:15 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs,comp.sys.ibm.pc.misc
Subject:   Re: Using "mount" and SOSS

kxb@math.ksu.edu (Karl R. Buck) writes:
>How can I allow a certain user (or failing that anyone from a certain client)
>to be able to mount a file system on SOSS?

If you're running a name server (named) somewhere on your LAN, you can
specify a list of up to 50 client names separated by spaces after the
names of filesystems.  Make sure NETDEV is configured with the IP
address of at least one name server.

SOSS doesn't directly support this for sites which don't run a name
server.  It relies on PC/IP, which might support some form of host
file but I'm not sure what it would be.  So: run a name server if you
want to use this.  Always a good idea in any event; I hate updating
hostname files.

I didn't know the NFS protocol allows for specifying a list of allowed or
disallowed user-names for mount requests.  Does it?

-rich


-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 20:01:28 GMT
From:      richb@kronos.com (Rich Braun)
Subject:   Sanity check on network configuration

I'd like to bounce this idea I have off the net.community before I go in
and recommend something that I'll wind up having to undo later.  We're about
to renumber our internal TCP/IP LAN so it'll conform to the "real"
Internet if and when it gets connected.

First, a simplified diagram of our in-house net:

+----+-----+-----+------+-----+   ---X~~~~~~(The Great Beyond)
A    B     C     D      E     F
|    |           |      |
+G   +H          +I     +J
+K               +L     +M
+N

Boxes A through F are on the backbone.  C and F only have one Ethernet
interface; A, B, D, and E each have two Ethernet interfaces and run IP
routing.  This second interface is hooked up to a subnet (mostly of
DOS PC's running CUTCP).  Eventually box X (a router of some sort)
will connect the backbone with the Internet At Large.

Right now, every system in the whole LAN is set up with a 24-bit subnet
mask (24 bits of address, 8 bits of host number).  Because I can guarantee
that each subnet won't ever have more than 62 nodes, I'm thinking of
switching to a 26-bit subnet mask (6 bits for the host number) for the
subnets while keeping a 24-bit (Class C) subnet mask for the backbone.

Is this the most sensible way of setting things up, so as to avoid
having to go out and get another Class C network number every time we
add a router to the network?  (We'd have plenty of expansion space if
we could put 4 routers into each Class C network.)  Am I right to assume
that I need to have a unique "network number" for each router interface
card?

My thinking on this is a wee bit foggy and there's no one else here to ask.

-rich


-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 20:08:24 GMT
From:      gooey@helix.nih.gov (Sean Graham)
To:        comp.protocols.tcp-ip
Subject:   WD8013EP Packet Driver Question...


I was wondering if someone can tell me if the current packet
driver "WD8003E.COM   6535  03-28-91" supports the WD8013EP
card.  It's the Ethercard PLUS Elite16.  If not, could someone
point me in the direction of a driver that would support it?

Email if you can.

Sean

--
|| Sean N. Graham                 NIH               DoD# 601  AMA# 601894  ||
|| '91 GSX600FM | '85 RX-7    Bethesda, Md          gooey@helix.nih.gov    ||
|| "This is a test of the Emergency Broadcasting System.  This is just a   ||
|| test.  In the event of a real emergency you would most likely be dead." ||


-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 21:01:14 GMT
From:      phil@brahms.amd.com (Phil Ngai)
To:        comp.protocols.tcp-ip
Subject:   all these unsubscribe requests

Looks like they're all coming via UCBVAX. Anyone
wanna beat on their postmaster?

--
This posting is purely a personal opinion.


-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 21:02:49 GMT
From:      shj@ultra.com (Steve Jay)
To:        comp.dcom.lans,comp.dcom.modems,comp.lang.c,comp.os.vms,comp.protocols.tcp-ip,comp.sys.dec,comp.unix.wizards,comp.sys.cdc,comp.sys.prime,comp.sys.ibm.pc.hardware
Subject:   Re: Help Requested in Defeating Ring Buffer Software Patent

In <1991Sep29.195103.18362@Think.COM> sandee@Think.COM (Daan Sandee) writes:

>Dave's original request was for any code before Oct 81. Well, I can find code
>which I *think* I wrote around 1976. But the basic principle was in CDC
>operating systems *at least* in the very early 1970's. Before my time, anyway.
>I first heard of this method in late 1973. (I wonder, do I still have the
>SCOPE 3.4 Handbook, dated 1972 or 1973, which describes this?)
>Is Greg Mansfield out there ? or Dave Cahlander ? Or Seymour Cray, for that
>matter : I don't think he invented it, but I'm sure he knows who did.

The "Circular I/O" technique being discussed here was in the original COS
(Chippewa Operating System) for the 6600 in 1964.   It is described in
the COS Reference Manual.  If someone's life depends on it, I know where
I can get a copy of that manual.

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"


-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 22:08:48 GMT
From:      hwajin@omni.com (Hwa-Jin Bae)
To:        comp.protocols.tcp-ip
Subject:   Re: obtaining the maximum UDP packet size

In article <28E3A769.20571@ics.uci.edu> schmidt@ics.uci.edu (Douglas C. Schmidt) writes:
>	It doesn't seem that any of the socket options available via
>getsockopt return this informtion.  Can someone tell me how to obtain
>this info?  For example, it appears that Sun OS 4.x has a limit of
>around 8k bytes, but that number doesn't seem to appear in any header
>files.

SunOS uses default udp_sendsize of 9K which is used to allocate socket
level buffers for each socket opened by users.  BTW, 9K for sending
side -- for NFS traffic (8K + some extra stuff).  Applications are
restricted by this "send" size because UDP is datagram service.  If you
want to send larger packets you'll need to use setsockopt SO_SNDBUF.
To get the currently available maximum UDP packet size you can use in

*hwajin


-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 22:46:24 GMT
From:      jonson@SERVER.AF.MIL (1Lt Matthew W. Jonson)
To:        comp.protocols.tcp-ip
Subject:   Re: Why can't my clients talk to another subnet?

<Mike Black writes>
> Subject: Why can't my clients talk to another subnet?
> Message-Id: <49983@seismo.CSS.GOV>
>
> I have read as much material as is on the net and have succeeded
> (somewhat) in implementing subnetting on our buildings Sun workstations.
> Here's an example of our setup:
>
> 22.19.4.1 (255.255.255.0) --------  22.19.6.1 (255.255.255.0)
>   |                                   |
Host1                               Host2
>   |
192.9.201.1 (255.255.255.0)
>   |
> 192.9.201.2 Client1
> 192.9.201.3 Client2
>
> The Clients here cannot ping,ftp, or telnet to Host2.  Host2 also
> cannot ping,ftp, or telnet to the clients.  Note that a route has
> On Host1: route add net 22.19.6.0 Host1 0
> On Host2: route add net 22.19.4.0 Host2 0
>
If the clients have a
statement they will try to send all their non-local packets to host1 for
forwarding.  You could also run your net 22 as a Class B sized net and then
you wouldn't need the two route commands you mentioned above (use a netmask
of 255.255.0.0).

One other thing worth pointing out is that net 22 is in actuality owned by
Defense Information Systems Agency and is used on what is known as DSNET1 which
is our lowest (classification level) classified network.  Although net 22 may
never be connected to the Internet, it is allocated.  If you have any plans to
connect this network you are working on to the Internet, you need to make sure
you have requested and received valid unused net numbers from the NIC...

/matt
--

Lt Matthew W Jonson       jonson@server.af.mil  snail-mail:
Network Systems Engineer     205-279-4075       SSC/SSMT
USAF DDN Program Office      AV: 596-4075       Gunter AFB, AL  36114

Any opinions expressed herein are my own and NOT the property of the USAF.



END OF DOCUMENT