The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Feb 1993 04:28:04 GMT
From:      srodawa@vela.acs.oakland.edu (Ron Srodawa)
To:        biz.sco.general,biz.sco.opendesktop,comp.protocols.tcp-ip
Subject:   Re: bootp on SCO tcp 1.2.0 (or lower)

In article <1993Jan27.141450.16326@sco.COM> larryp@sco.COM (Larry Philps) writes:
>In <1993Jan20.173734.8441@olivetti.be> jpr@olbela.olivetti.be (Morant Jean-Pierre) writes:
>
>> Hello !
>> I've read somewhere that an implementation of "bootp" for SCO is available
>> on the net. Do someone know where I can find it ?
>
>We see this question alot.  TCP/IP 1.2 _contains_ an implemenation of bootpd.
>The binary is /etc/bootpd, and there is a manpage.  Is this not what you
>want?

There are binaries for the /etc/bootpd with Carnegie-Mellon vendor code
located via anonymous ftp at unix.secs.oakland.edu:/pub/xenix.  The code
itself is compiled for Xenix 2.3.4.  I could be wrong, but I don't think the
code mentioned above for TCP/IP 1.2 has been released to Xenix.  The source
code can be quite informative as to how to accomplish BSDisms in the IOCTL
structure used by SCO TCP/IP.  BTW, larryp@sco.COM was very helpful to me
in passing along the information required.  It WASN'T in the normal
development system manuals.

-- 
| Ronald J. Srodawa               | Internet: srodawa@vela.oakland.edu      |
| School of Engineering and CS    | UUCP:     srodawa@vela.UUCP             |
| Oakland University              | Voice:    (313) 370-2247                |
| Rochester, Michigan  48309-4401 |                                         |

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Feb 1993 08:56:21 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <STEINAR.HAUG.93Jan30150411@delab.sintef.no>, 
Steinar.Haug@delab.sintef.no (Steinar Haug) writes:

> [...]
>The reason for the problem is that when sending a large message there is a
>significant (close to 1) probability that sooner or later we get an X.25
>RESET, and the email session is dropped. Of course it is retried again later,
>but some messages *never* get through. What "large" means here varies: Some
>X.25 connections will only allow about 100 kBytes or so of email through, on
>others I've been able to get up to 3 Megabytes through. Yes, this *does*
>happen on our connections with the Norwegian Telecom. Yes, we have checked
>that the RESETs come from the Norwegian Telecom X.25 switches.

Two years ago our gateway to the Internet was extremely slow and extremly
unreliable - 80-85% packet loss was typical. What did we do - did we kick
and scream: "We want OSI! We want OSI!" ?

No, we didn't. Our guys are engineers, not net priests. They made a search
to find the weak component, isolated it and replaced it - first, a software
update that improved reliability a lot, later a hardware replacement that
increased throughput a lot. That's the engineer's way to do it.

Another thing is that a system designed for handling messages of size 3Mbytes
should not be designed for a 100% reliable network. Networks just ain't
100% reliable. If you were running an OSI mail system, there would be an
OSI solution to your problems (if they were not cured by TP1, which they 
very well might be): RTSE. Note that the X.400 P1 protocol *requires* RTSE.
P3 may run without, but I would assume that on the more or less local P3
connection, the problems aren't that big. (And you may use RTSE with P3 too).

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 93 09:10:59 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer



 >>In article <1k9vpaINNrdl@cronkite.cisco.com> tli@cisco.com (Tony Li) writes:
 >>>In ten years, there is a significant possibility that TCP will be running
 >>>over CLNP.
 >I believe that Tony Li made an unintentional typo - that he meant to write
 >'TCP over CONP'. Otherwise his statement makes little sense.

TCP already can run over CLNP - it is one of the proposed 'ways
forward' for TCP/IP - CLNP is semantically a clean replacement for IP,
with 5 times the address size and strucutre permitting hieararchical
assignment, thus route aggregation etc etc - it is one of 3 or 4
good candidates, though.

similalry as X.25 can also be run over TCP (see cisco products for e.g.)

as someoen said, the only thing that doesnt work is plugging together
cons and clns - its like pipes of water being plugged into bucket
brigades - 

rant/flame on:

the problems with the OSI 7 layers is that there are no bundled
products more than a lot of other reasons 

this is good evidence as to why standards are really there - to slow
down poor unsuspecting companies while those with a good eye for the
market go and innovate....the rate of change of communications is such
that mosdt good techniology must come from innovfation - it just isnt
the same kind of 2000 year old engineering as bridge building yet...

in conmtrast, 
have you heard of someone trying to standardize all planes to run like
747s?

i hear sometimes people promote standards as increasing competition

- if thats the caser, how come the price i see on TP4/CLNP and XC.25
productsm and the cheapness of IP (and novell and appletalk) products,
eh? and quality? and conformance? etc etc...

the problemn with standards isn't that there are so many, its that the
international ones are actually conceived to do precisely the
opposite of what is claimed. its a shame so much effort is put into
them by so many reasonable technical people...

i hear people from *universities* saying its their duty to input into
standards - what a joke - they are supposed to be researching things
we dont yet understand - how could you standardise something which we 
dont know how to do?
standards are appropriate to very well established technology, and to
_services_ where safety etc is paramount?

in computing and telecoms, we should have learned to separate the 
requirements from the design enough to get contractual protection 
for procurement specifications

enuff flame...

 jon


-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 93 13:25:50 GMT
From:      izar@shuldig.cs.huji.ac.il (The Wandering Kami)
To:        comp.protocols.tcp-ip
Subject:   Looking for PC rpc based code


	Perhaps this is not the best place, but does anyone have a reference
to RPC code running from a PC ?
	Thanks in advance,

--izar
--
@----izar@cs.huji.ac.il---------------------System Group, Computer Science---@
@ "It's 5 bloody o'clock in the morning, and   | HUJI - Hebrew University    @
@  do you know where your stack pointer is ?"  | Jerusalem,Israel,Earth      @
@                                              | Scud Landing Control        @
@-----if HUJI had the same opinion as me there would be no teachers around---@

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Feb 1993 14:35:38 GMT
From:      matt@wardsgi.med.yale.edu (Matt Healy)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet VT100/VT200 for TCP/IP on MVS (IBM large Systems)

In article <1993Jan27.193648.23914@mmm.serc.3m.com>, ccg@tcdsp1.mmm.com
("Charles Ganzhorn") wrote:
> 
> Simware Inc.
> 20 Colonnade Road
> Ottawa, Ontario, Canada, K2E 7M6
> 613-727-1779
> 
> They make a package for MVS which will do the vt100 to 3270 swap.  But, for my
> two cents worth, you might want to look at getting a tn3270 emulation for the
> client end.
> 

There is a version of NCSA Telnet called tn3270, which we use
for all connections with IBM mainframe-o-sauri (mostly I use
tn3270 to use Yale's library catalog).

Matt Healy
"I pretend to be a network administrator; the lab
 net pretends to work!"

matt@wardsgi.med.yale.edu

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Feb 1993 14:44:26 GMT
From:      matt@wardsgi.med.yale.edu (Matt Healy)
To:        comp.protocols.tcp-ip
Subject:   Re: 'Magic Muffin' Information

In article <russell.14.728240698@hawk.nstn.ns.ca>, russell@hawk.nstn.ns.ca
(Paul Russell) wrote:
> 
> A friend asked me about what a 'Magic Muffin' or 'Magic Cookie' was in the 
> TCP/IP protocol.  Does anyone have any information on this?

TCP port 17 on most hosts is "get a quotation" service.  A
packet addressed to this port number will elicit a reply with
a randomly-chosen quotation; the quality of the quotation
depends on whether the sysadmin has a sense of humor.  This
is colloquially referred to as "give me a cookie" and on some
systems the command to request a quotation from host@domain
is "cookie host@domain" or something similar.

Its practical purpose is as a quick way of confirming that
a given machine can be reached over the net.

Matt Healy
"I pretend to be a network administrator; the lab
 net pretends to work!"

matt@wardsgi.med.yale.edu

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Feb 1993 15:31:36 GMT
From:      evans@tsd.arlut.utexas.edu (Eric Evans)
To:        comp.protocols.tcp-ip
Subject:   Zombie UDP ports in SCO Unix?

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

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

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

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

Does anyone have a clue about this behavior? 

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



-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Feb 1993 15:44:37 GMT
From:      Steinar.Haug@delab.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
> Another thing is that a system designed for handling messages of size 3Mbytes
> should not be designed for a 100% reliable network. Networks just ain't
> 100% reliable.

I quite agree.

> If you were running an OSI mail system, there would be an
> OSI solution to your problems (if they were not cured by TP1, which they 
> very well might be): RTSE. Note that the X.400 P1 protocol *requires* RTSE.
> P3 may run without, but I would assume that on the more or less local P3
> connection, the problems aren't that big. (And you may use RTSE with P3 too).

Actually, this *is* indeed an OSI mail system I am talking about...

Steinar Haug, system/networks administrator
SINTEF DELAB, University of Trondheim, NORWAY
Email: Steinar.Haug@delab.sintef.no, 
	sthaug@idt.unit.no, steinar@tosca.er.sintef.no

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 93 15:50:53 GMT
From:      dana@inferno.UUCP (Dana)
To:        comp.protocols.tcp-ip
Subject:   Re: If you run 2+ nets on 1 wire, please read

The Shownet at Interop runs  Novell, Appletalk, tcp/ip, OSI/GOSIP, SNA and a few others. I believe all
protocols are present at once on the FDDI backbone.  They also run Ethernet and token ring on the shownet,
but those are for the ribs only -- the backbone is strictly FDDI.  Certainly there were folks talking
tcp/ip on the same ethernet as appletalk, because there were booths with Suns in the same aisle as
the Apple booth.

-- 
Dana Hudes
dana@inferno.UUCP

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Feb 1993 17:43:07 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.protocols.tcp-ip
Subject:   Re: Connecting two 10baseT machines together.

Steve Murphy (smurph@sdf.lonestar.org) wrote:
> I remember reading on the net that one can wire
> two machines together without a "hub" by using what would be analogous 
> to a "Null Modem cable" in the RS232 world. My assumption is that one
> would "cross" the receive and transmit wire(s). Anyone know for sure?
> Please let me know.

It is possible.  I know for sure.  To build a cross-overcable from a
standard four-pair twisted-pair cable, connect the following:

Rx+ 1  -  3 Tx+          (connect pin1 of one end to pin3 of other end)
Rx- 2  -  6 Tx-          (pin2 to pin6)
Tx+ 3  -  1 Rx+          (pin3 to pin1)
Tx- 6  -  2 Rx-          (pin6 to pin2)

- Steve Kao

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Feb 1993 19:07:02 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1993Jan30.162851.13930W@lumina.edb.tih.no> ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
>The OSI philosophy is making a clear distinction between WHAT to do and
>HOW to do it. The actual *user* makes demands to the WHATs. Essentially,
>the OSI customer buys *solutions*, not mechnanisms.

Here in the US, users are considered competent enough to make informed
decisions about the technical aspects of the solution.  They are able,
willing, and expected to say things like, "Sure, your solution *looks*
like it will work, but i happen to know that by using that approach
you will limit my flexibility/reliability/usability/whatever."

Perhaps things are different in Europe, but frankly i doubt it.  I
suspect European purchasers are getting a little tired of network
service providers telling them that they shouldn't worry their pretty
little heads about how things work.

The gentleman from Norway is a good example: he's not just saying that
he has a personal dislike for non-TP4 transports so he's going to get
even by refusing to buy any.  He's telling you exactly why non-TP4
solutions are failing *in practice* for him.  He's gone beyond just
seeing that this solution didn't work and rejecting that *product*.
He has determined *why* it didn't work, so he's rejecting that *class*
of products.  You can tell him he should leave such decisions up to
the experts...but somehow i don't think he's going to listen to you.

						don provan
						donp@novell.com

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 93 19:15:37 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1993Jan30.165932.14274W@lumina.edb.tih.no> ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
>In article <1993Jan30.082516.21240@novell.com>, donp@novell.com (don provan) writes:
>>I've never even heard of X.214.  
>
>Why don't you go out and get a copy of it. It might give you a few surprises.

No, thanks.  I've got real work to do.

>Oh, well, if you have never heard of the standard documents, I suppose
>you are rather thin on the responsibilities of the Transport layer.

OK, i'll just leave all this to you OSI priests to work out.
Meanwhile, i've got some products to get out.
						don provan
						donp@novell.com

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 93 20:05:32 GMT
From:      joeg@novell.com (Joe Gervais)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1kdhsnINN88k@gap.caltech.edu> dank@cco.caltech.edu (Daniel R. Kegel) writes:
>donp@novell.com (don provan) writes:
>>Keep in mind that TCP/IP isn't under attack by Novell.  We're not
>>giving away IPX: people are *buying* it...
>
>Before I go on, let me say I appreciate anyone at Novell who is working
>on open (i.e. non-proprietary) protocols such as tcp/ip, and who is willing 
>to tell us about it on the net.  Now, onwards:
>
>Correct me if I'm wrong, but I understood that Unixware ships with
>IPX free, but TCP/IP is extra cost.  So customers of Novell's shrinkwrap
>Unix aren't buying IPX, they're getting it free, whether they want it or not.
>Sounds like Novell wants to encourage Unix users to use IPX rather than TCP/IP.
>Funny, that.
>
>I wouldn't mind getting Unix from Novell, if only it came with tcp/ip.
>Otherwise, gee, maybe I'll switch to Microsoft's NT; after all, it supports 
>the Posix API & tcp/ip for free.  Never thought I'd think of Microsoft
>as a white knight, but there you are.
>- Dan K.

If you look at the TCP/IP module from USL SVR4, you'll notice a Copyright
Lachman Notice.  The basic problem is that USL doesn't own the TCP/IP stack
in SVR4, Unisys, when it sells SVR4 with TCP/IP doesn't own the stack, and
Univel, when it ships SVR4 doesn't own the stack.  They all pay royalties to
Lachman Associates.  So since these firms pay royalties to Lachman, why 
shouldn't they pass the cost on?

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Feb 1993 21:11:25 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in SVR4

In article <1993Feb1.200532.3287@novell.com> joeg@novell.com (Joe Gervais) writes:

> If you look at the TCP/IP module from USL SVR4, you'll notice a
> Copyright Lachman Notice.  The basic problem is that USL doesn't own
> the TCP/IP stack in SVR4, Unisys, when it sells SVR4 with TCP/IP
> doesn't own the stack, and Univel, when it ships SVR4 doesn't own the
> stack.  They all pay royalties to Lachman Associates.  So since these
> firms pay royalties to Lachman, why shouldn't they pass the cost on?

This isn't a hard problem for Novell to solve, IF THEY WISH TO SOLVE
IT.  The BSD Net/2 implementation of TCP/IP is available online via
ftp from ftp.uu.net and many other places.  Most vendors of UNIX
already use the BSD sources in their kernels.  I'm frankly surprised
that SVR4 doesn't already do this.

  I rather suspect that Novell would rather us all use SPX/IPX, but I
for one won't be doing that.  I consider TCP/IP support mandatory so
the cost of (OS + TCP/IP) is what I compare when I look at various
vendors products.  

  Novell _should_ get serious and include TCP/IP with SVR4 but I
rather doubt that they will.  IF WNT or OS/2 really does include
TCP/IP with the base OS, Novell will be forced to react or they will
lost a lot of customers (e.g. me).

Ran
atkinson@itd.nrl.navy.mil


-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 1993 21:15:00 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: 'Magic Muffin' Information

In article <russell.14.728240698@hawk.nstn.ns.ca>, russell@hawk.nstn.ns.ca
(Paul Russell) wrote:
> A friend asked me about what a 'Magic Muffin' or 'Magic Cookie' was in the 
> TCP/IP protocol.  Does anyone have any information on this?

A Magic Cookie is also a generic term for a number stuck somewhere to
indicate some sort of service.  The idea is to pick a number that is
(hopefully) unlikely to occur randomly.

As an example of usage, look at the BOOTP Vendor Information field.  It
is recommended that users start the field with a four-byte number, a
"magic cookie" that is used to indicate how the rest of the field is to
be interpreted.

Similarly, but not in networking, memory allocation systems sometimes
use "magic cookies" as part of mechanisms to make sure users do not free
memory they did not allocate.

According to the Jargon File WAIS source, which explains it better than I
can:

magic cookie: [UNIX] n. 1. Something passed between routines or
   programs that enables the receiver to perform some operation; a
   capability ticket or opaque identifier.  Especially used of small
   data objects that contain data encoded in a strange or
   intrinsically machine-dependent way.  E.g., on non-UNIX OSes with a
   non-byte-stream model of files, the result of `ftell(3)' may
   be a magic cookie rather than a byte offset; it can be passed to
   `fseek(3)', but not operated on in any meaningful way.  The
   phrase `it hands you a magic cookie' means it returns a result
   whose contents are not defined but which can be passed back to the
   same or some other program later.  2. An in-band code for
   changing graphic rendition (e.g., inverse video or underlining) or
   performing other control functions.  Some older terminals would
   leave a blank on the screen corresponding to mode-change magic
   cookies; this was also called a {glitch}.  See also {cookie}.

-- 
Stephen Trier                      
Network software type              
Case Western Reserve University    
trier@ins.cwru.edu

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Feb 1993 21:45:28 GMT
From:      Mehrtens_T@msm.cdx.mot.com
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet masks within Class B Internet address

In article(Donald Amby) writes:
>    Our parent company has an official Class B(!) Internet address (139.69),
>    and my subsidiary has been assigned subnets 139.69.48 to 139.69.63.

Motorola Codex has an official class B address, and all links (local, WAN) are
given individual class C addresses. (FF.FF.FF.00  = 16 255-node subnets).  I
assign each subnetwork (WAN, LAN) a normal class C address, and all of the
machines (old and new) work well.  I see the dillema you have - I have 256
subnets, and you have only 16!  I would still assign normal class C, with 256
node subnetworks.  I would not recommend a pseudo-BC class, even though
"everything should work"!!!  8-{)

The trick in networking is to plan for the unknown leaps in future network
usage, which will require the smallest strain on the user community when one
has to change the network topology.

Break it into little bits now, and the future will be much easier to manage and
change.  I've been dorn this road before.

Tom M.
<Send for amusing, long disclaimer>


-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 93 21:47:10 GMT
From:      dank@blacks.jpl.nasa.gov (Daniel R. Kegel)
To:        comp.protocols.tcp-ip
Subject:   Novell and TCP/IP (was: Info wanted on TCP/IP vs OSI 7 layer)

joeg@novell.com (Joe Gervais) writes:

>>donp@novell.com (don provan) writes:
>>>Keep in mind that TCP/IP isn't under attack by Novell.  We're not
>>>giving away IPX: people are *buying* it...
 
>If you look at the TCP/IP module from USL SVR4, you'll notice a Copyright
>Lachman Notice.  The basic problem is that USL doesn't own the TCP/IP stack
>in SVR4, Unisys, when it sells SVR4 with TCP/IP doesn't own the stack, and
>Univel, when it ships SVR4 doesn't own the stack.  They all pay royalties to
>Lachman Associates.  So since these firms pay royalties to Lachman, why 
>shouldn't they pass the cost on?

That makes sense.  Thanks for the info, Joe.

On the other hand, why doesn't Univel charge for IPX support in Unixware?
If you're going to unbundle one protocol, why not unbundle them all?
The answer is, Univel is interested in promoting IPX, to help drive
sales of Novell Netware.  This isn't too surprising, but it would be
nice to hear Novell admit this, rather than claiming to just be selling
what people want.
- Dan K.

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Feb 1993 22:48:23 GMT
From:      dhepner@cup.hp.com (Dan Hepner)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: DCE COMPLIANT ?


From: dchen@ctp.com (Denys Chen)

>|> >My statement also implies that the software does NOT need to use DCE's RPC
>|> >as transport service.
>|>
>|> This definition would severely compromise the promise of DCE. 
 [deleted q, incorporated below]
>|>                                                               How would
>|> it be guaranteed to interoperate with other DCE applications?  
>
>It's guarranteed to interoperate with other DCE applications because it 
>_relies_ (i.e., _uses_) DCE's Name Service, Time Service, etc.

Maybe we need to revisit definitions, as it seems we're not at the
same place.  "DCE RPC" need not be purchased from OSF, but it does 
need to follow the exact same rules of what one finds in a packet 
and where one finds them.  It needs identical reliability interactions. 
Thus, if I'm writing a client and you're writing a server, if I use DCE RPC, 
I can use your server.  The fact that we found each other using DCE's 
name service is necessary but insufficient to insure interoperability.

Let's put it this way.  If I can, using my DCE RPC, send such an RPC
to your server and you can properly receive it, and if I can, using
my DCE RPC write a server and receive RPCs sent from your client, I
can interpret the arguments the same way, and the reliability guarantees 
are met, then I'll buy that as being DCE compliant.  But I'd also buy it 
as using DCE RPC.

>|>                                                               Profound
>|> in the promise of DCE is that clients and servers might be provided by
>|> different vendors.
>
>My statement does NOT limit _vendor_ of the applications. My statement 
>starts with "_any_ software ...".
>
>Maybe you can elaborate a bit more about what'd be compromised by my
>statement.

To be a bit extreme, if vendor 1 supplies a client which uses ONC RPC,
and vendor two provides a server which uses DCE RPC, they would not
interoperate. In a DCE context the supplier of the client would be 
described as the source of the problem and would be "non DCE compliant".

>Overall, to me, your posting is quite informative and articulate. 
>It really helps. Thank you.

It's an interesting question.  In this person's opinion, the real value 
of DCE is not in new technology at all, but rather in the substantial
set of standards which are implemented across the platforms of many
vendors.  This provides a large market for vendors of clients and
servers, in that if they develop their DCE applications they know
that there is a large existing base which can make use of them.  They
know that they have portability to other DCE platforms, and they
know they have interoperability with all other DCE compliant 
applications.  The end customer knows she has many choices for
all of platforms, clients, and servers.

Contrast that to the past.  We've had client-server computing for
decades, but using dozens of communication mechanisms.  We've had 
threading for decades, but using different threading paradigms and
programming interfaces.  We've had name services for at least
ten years, but never the same everywhere.  And so on.  The value
of DCE is that these things are the same everywhere.  That's why
doing even one of these things differently while doing the rest
the same is "non DCE compliant".

Dan Hepner
Not a statement of the Hewlett Packard Company

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Feb 1993 00:00:12 GMT
From:      Quentin.Smart@bbs.actrix.gen.nz
To:        comp.protocols.tcp-ip
Subject:   How to test: Packet de-fragmentation

There had been some talk a while back about testing ip fragment
re-combination.

I've written some code that I need to test.

Does sending a packet of size MTU to a host in an ICMP echo packet work?

Or would it work if I found some kind host manager who was at the end of a
fragmenting link that I could send a packet or two to port 7 (ECHO). 
(Hint any offers?)

Thanks
Quentin
smart@actrix.gen.nz

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Feb 1993 00:28:51 GMT
From:      ssa@unity.ncsu.edu (S. Alavi)
To:        misc.books.technical,alt.books.technical,bit.listserv.mailbook,comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc,misc.forsale.computer,misc.forsale.computers,misc.forsale
Subject:   "Internetworking with TCP/IP" books FOR SALE


	I have (more than 1 copy) of the following books for sale, they
	are brand new:

Internetworking with TCP/IP. Principles, Prot. and Arch. (1st ed)        $20
          D Comer [Prentice Hall]
Internetworking with TCP/IP (vol I) Princ. Prot. and Arch. (2nd ed)      $35
          D Comer [Prentice Hall]
Internetworking with TCP/IP (vol II) Design, Implem. and Internals       $35
          D Comer / D Stevens [Prentice Hall]

	add $5 for shipping and COD for 1-3 books and $1 for each additional

	======  S. Alavi    [ssa@unity.ncsu.edu]  (919)467-7909 (H)  ========
						  (919)515-8063 (W)

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 93 01:43:26 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1993Feb1.200532.3287@novell.com>, joeg@novell.com (Joe Gervais) writes:
> 
> If you look at the TCP/IP module from USL SVR4, you'll notice a Copyright
> Lachman Notice.  The basic problem is that USL doesn't own the TCP/IP stack
> in SVR4, Unisys, when it sells SVR4 with TCP/IP doesn't own the stack, and
> Univel, when it ships SVR4 doesn't own the stack.  They all pay royalties to
> Lachman Associates.  So since these firms pay royalties to Lachman, why 
> shouldn't they pass the cost on?


Both of the old STREAMS TCP/IP found in SVR3 (Lachman's and the other
one) have disappeared with SVR4.2 (or is it SVR4.1?  I forget.)  Thanks
to the merge of Sun's source, current SVR4 TCP/IP is Berkeley's, with
all that implies.

If you check the SVR4.1 (2?) source you'll notice that the code is
STREAMized 4.3BSD, apparently around 4.3BSd-tahoe with some gratiutous
changes thrown in for good (bad?) measure.  (When you run the diff's,
suppress reports caused by changes in indentation.)

The new USL TCP code tends to have rather short and obscure copyright
text, not at all similar to the old, shorter 4.2 BSD copyright legands
or the newer 4.3 legands.  I've wondered mildly why The Regents of the
Univ. of Calif. have not sued USL for failing to abide by the terms of
the BSD copyright.


Vernon Schryver,  vjs@sgi.com

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 93 02:06:35 GMT
From:      mbeyer@zamboni.NSP-SERVER1 (Mark D Beyer)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in SVR4

In article BL2@ra.nrl.navy.mil, atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:

> The BSD Net/2 implementation of TCP/IP is available online via
>ftp from ftp.uu.net and many other places. ... I'm frankly surprised
>that SVR4 doesn't already do this.

I'm not.  Net/2 doesn't just compile and run out of the box on SVR4.  You still need to 
port it.

>  I rather suspect that Novell would rather us all use SPX/IPX, ...

Nah.

$.02
--

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 1993 10:33:49 -0500
From:      marat@cis.ohio-state.edu (wisebond marat)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Appletalk on PC

I wonder if anyone on the net knows of Network packages other than Tops that will link Macs and MsDos machines using appletalk adapters on the PC's.  The best sollution would allow the use of current Network capilities of the mac and use some kind of software on the PC.

mail me responses direct at marat@cis.ohio-state.edu

or respond via news

thanks in advance.

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Tue,  2 Feb 1993 11:24:35 -0500
From:      Craig_Everhart@transarc.com
To:        comp.protocols.tcp-ip,comp.unix.programmer,comp.client-server
Subject:   Re: DCE COMPLIANT ?

Excerpts from netnews.comp.client-server: 1-Feb-93 Re: DCE COMPLIANT ?
Dan Hepner@cup.hp.com (3340)

> Let's put it this way.  If I can, using my DCE RPC, send such an RPC
> to your server and you can properly receive it, and if I can, using
> my DCE RPC write a server and receive RPCs sent from your client, I
> can interpret the arguments the same way, and the reliability guarantees 
> are met, then I'll buy that as being DCE compliant.  But I'd also buy it 
> as using DCE RPC.

I don't necessarily buy this as being ``DCE compliant''.  I buy it as
being ``DCE RPC compliant,'' though.

		Craig
		(not speaking for Transarc)

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 1993 06:57:03 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <3414@ucl-cs.uucp> J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) writes:
    
    CLNP is semantically a clean replacement for IP,
    with 5 times the address size and strucutre permitting hieararchical
    assignment, thus route aggregation etc etc - it is one of 3 or 4
    good candidates, though.

Nitpicking: While the current NSAP formats are currently 20 bytes, you do
NOT get to assign all of them.  In fact, at least with the GOSIP address
format, you get darn few bytes down to the end user.  I hope that if the
Internet DOES use TCP/CLNP (a.k.a. TUBA), we get another AFI and rethink
the address format. 

Oh, I should also point out that the NSAP is NOT fixed at 20 bytes.  One of
the nice things about CLNP is that if we get into this hole again, we just
stretch the address...
    
-- 
abyss \*-'bis\ n 
  1 : the bottomless gulf, pit, or chaos of the old cosmogonies  2 a : an 
  immeasurably deep gulf or great space  b : intellectual or spiritual 
  profundity; also : vast moral depravity 3 a Border Intermediate System

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Feb 1993 08:45:39 GMT
From:      rustomji@sol.cs.wmich.edu (Eric Rustomji)
To:        comp.protocols.tcp-ip
Subject:   Concurrent Server...

Hi there,

I am writing a client-server prorgam, wherein the
server is a master-slave configuration.
The server spawns a process for each request.

Well, here is my example:
if(FD_ISSET(clifd, &rfds))
{
   switch(fork()) {
	case 0: /* child */
	(void)close(listenfd);
	serv_client(clifd);  /* Serve child */
	exit(0);

	default: /* parent */
	(void)close(clifd);
	FD_CLR(clifd, &rfds);
	FD_CLR(clifd, &afds);
	break;
   }
}

Now the problem here is, each time the value of 'clifd' is the
same, though it points to a different entry in the socket table.

I need to know a way of storing and distinguishing these 
descriptors which are obtained, in order to use them later on.

I'd appreciate if anybody could give me a few helpful tips.
Thanks.
--
Eric

------------------------------------------------------
Eric  Rustomji         
Department of Computer Science
Western Michigan University
Office: (616) 387 - 6426      Home: (616) 387 - 5566
Email:  rustomji@cs.wmich.edu
------------------------------------------------------

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 93 10:33:00 GMT
From:      f.patzner@ldb.zer.sub.org
To:        comp.protocols.tcp-ip
Subject:   Appletalk on PC

Message-Id:   <1km48tINNca1@tomato.cis.ohio-state.edu>
Realname: wisebond marat
Organization: The Ohio State University Dept. of Computer and Info. Science
References: <C1ts1z.EoE@harpo.dev.uga.edu>
X-Gateway: ZCONNECT, RFC1036/822 UL ldb.comlink.de [UUCPfZ V4.23 U002]

I wonder if anyone on the net knows of Network packages other than Tops that will link Macs and MsDos machines using appletalk adapters on the PC's.  The best sollution would allow the use of current Network capilities of the mac and use some kind of software on the PC.

mail me responses direct at marat@cis.ohio-state.edu

or respond via news

thanks in advance.

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Tue,  2 Feb 1993 19:36:22 -0500
From:      Lyle_Seaman@transarc.com
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in SVR4

Excerpts from netnews.comp.protocols.tcp-ip: 2-Feb-93 Re: TCP/IP in SVR4
don provan@novell.com (1317)

> I suppose there are people in Novell that would rather everyone used
> IPX, but it strikes me a little odd to think there would be a
> significant number of them in Univel, a company dedicated to UNIX
> development.  Most UNIX people like TCP/IP, even within Novell.

I'll second that.  I even found non-UNIX people in Novell who didn't
much care for SPX.  Not a hard protocol to dislike, IMO.

On  The  Other  Hand, SPX (well, IPX anyway) was probably nearly the
perfect protocol for the initial purposes of NetWare.  The only thing
that it desperately needed was some plan for migration or adding new
features to the protocol once the hardware could support it.  And it's
not technically impossible to migrate away from it, even so.  NetWare
has taken a few steps in that direction.  I hope (do I?  Hmm, I'm not
sure) that Novell isn't so stuck on its own traditions that such a move
is politically impossible.

Lyle		Transarc		707 Grant Street
412 338 4474	The Gulf Tower		Pittsburgh 15219
"I don't believe it!  I believe it, though..." 	- kazar

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Feb 1993 12:31:56 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in SVR4


In article BL2@ra.nrl.navy.mil, atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:

%  The BSD Net/2 implementation of TCP/IP is available online via
% ftp from ftp.uu.net and many other places. ... I'm frankly surprised
% that SVR4 doesn't already do this.

In article <1993Feb2.020635.23369@tandem.com> mbeyer@zamboni writes:
 I'm not.  Net/2 doesn't just compile and run out of the box on SVR4.  
> You still need to port it.

  Nor did it compile out of the box for System V, Release 2.2 -- but
there are commercial vendors with SVR2 that have integrated the BSD
sources into their kernels.  It isn't some impossible task.  

Novell could include TCP/IP with all platforms -- IF THEY WANTED TO.
There is no technical barrier to this and the choice to hire Lachman
rather than do an internal port of the BSD networking code was Novell's.



-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 93 13:39:54 GMT
From:      ercm20@festival.ed.ac.uk (Sam Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) writes:
> in conmtrast, 
> have you heard of someone trying to standardize all planes to run like
> 747s?

Not exactly, but you need to be careful with your analogies.  First:
Boeing make two planes, the 757 and 767, which are about a factor of 2
apart in weight, capacity etc.  (757 is narrow bodied, 767 slightly
larger overall dimensions but widebodied).  The software controlled
flightdeck controls and flight characteristics are engineered so that
the planes fly almost identically - I don't know if they've got it so
that there's a single training for both types, but if not then it's
pretty close. 

Second: recent news articles (non-Usenet!) about successor planes to the
747 suggest that there is not enough money and engineering effort in the
whole world to make two such designs; that even if there's a market for
such a plane (800 seater size) the plane makers of the world have to
pool their resources to make it.

Note: I'm *not* *not* *not* saying that the same is the case in
networking, just that your example was not well chosen! :-)

Sam

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Tue, 02 Feb 1993 14:04:17 GMT
From:      stevea@i88.isc.com (Steve Alexander)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <vkj0vos@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <1993Feb1.200532.3287@novell.com>, joeg@novell.com (Joe Gervais) writes:
>Both of the old STREAMS TCP/IP found in SVR3 (Lachman's and the other
>one) have disappeared with SVR4.2 (or is it SVR4.1?  I forget.)  Thanks
>to the merge of Sun's source, current SVR4 TCP/IP is Berkeley's, with
>all that implies.

Sorry, that's not true.  I have several systems here running SVR4.2, and they
all still have code based on what we supplied to USL (then AT&T) back in '88 +
some upgrades from '89.

The USL SVR4.2 code is a STREAMS-based variant of BSD.

-- 
Steve Alexander, Lachman Technology, Inc. | stevea@isc.com
(708) 505-9555 x256 FAX: (708) 505-9574	  | ...!{sun,ico}!laidbak!stevea

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Tue, 02 Feb 1993 14:12:55 GMT
From:      stevea@i88.isc.com (Steve Alexander)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in SVR4

In article <C1tMt8.767@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
>  Nor did it compile out of the box for System V, Release 2.2 -- but
>there are commercial vendors with SVR2 that have integrated the BSD
>sources into their kernels.  It isn't some impossible task.  

True.  However, converting it to STREAMS is not exactly straightforward
either.  Especially when you're concerned about being binary compatible with
a previous release from USL, which Novell would be if they started from scratch.

>
>Novell could include TCP/IP with all platforms -- IF THEY WANTED TO.
>There is no technical barrier to this and the choice to hire Lachman
>rather than do an internal port of the BSD networking code was Novell's.

The SVR4 deal was completed a long time before Novell ever got into UNIX.  
They're using what they got from USL:  Our stack, SunOS 4.0 networking 
applications, and a socket library/module implementation done at Sun.

-- 
Steve Alexander, Lachman Technology, Inc. | stevea@isc.com
(708) 505-9555 x256 FAX: (708) 505-9574	  | ...!{sun,ico}!laidbak!stevea

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 93 14:20:51 GMT
From:      ishikawa@personal-media.co.jp (Chiaki Ishikawa)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.misc
Subject:   Inquiry: Free/commercial tcp/ip protocol drivers sought.


Hello.

I am looking for a free or commercial implementation of tcp/ip
protocol driver software. 

We will have our own software/hardware to prepare the basic packet
drivers. What I am looking for is the layer above it. We don't need
the user-level application such as ftp, telenet and the service
daemons such as ftpd, telnetd, etc..
(The target system is a multitasking system. It is not UNIX, nor
WIndows/NT.)

Any pointers such as

	- available free implementation and where to contact (and
	  possible ftp sites),

	- commerical implementation and where to contact,

	- FAQ or available document(s) from newsgroups and ftp sites,

	- or newsgroup(!) where I should dive in,

	- e-mail from commercial vendors

are appreciated.

[Since our Tokyo UUCP neighbor and North American UUCP neighbor (uunet)
both have disk system problems at the same time(!) and may have
problem carrying all the news posting (Murphy's Law DOES strike!), I
would appreciate if you could answer by e-mail. (Tell you the truth, I
am not sure if this will reach wide distribution. We will see.)]

If you are interested in hearing the responses I get, please let me
know. I will send you the summary of responses.

ishikawa@personal-media.co.jp

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Feb 1993 14:25:10 GMT
From:      edm@harpo.dev.uga.edu (Ed Maioriello)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   AppleTalk/MacIP across IBM 8209

Hi,

Does anyone know if either AppleTalk or IP from a Macintosh can make the
Token Ring/Ethernet jump across an IBM 8209 Lan Bridge.  I'm reasonably
sure that AppleTalk won't work, but I don't understand why.  With the
8209 running in mode 2 I would have thought that TokenTalk frames which
are SNAP frames would get converted to ethernet_snap frames.  This seems
like it should work just fine, but it doesn't seem to in real life.
I've been told that IP should work fine, but this seems like it
shouldn't work either since this means that token-ring_snap frames are
getting converted to ethernet_ii frames which I thought wasn't supposed
to happen.  (Oh yeah, our 8209s are configured to deal with Novell's IPX
as well.)

If it sounds like I'm struggling to understand what's going on here then
I've gotten my message across. :-) Any help will be greatly appreciated.

Thanks in advance.

Ed Maioriello		       		            edm @ harpo.dev.uga.edu
University Computing & Networking Services   	    edm @ aisun1.ai.uga.edu
University of Georgia  ----------------------------------------------------
Athens, Ga. 30602      | First Rule of Troubleshooting: 
(706)-542-6462         |                     If it don't work - plug it in! 


-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 93 14:44:26 GMT
From:      aris@unisup1.lasernet.co.za (Aris Stathakis)
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone know of a good LPR/LPD Server?

In <16B62716F.MACE@HDQCMS2H.UTSD.ATT.COM> MACE@HDQCMS2H.UTSD.ATT.COM writes:

>In article <1993Jan26.002814.1015@gordian.com>
>johnk@gordian.com (John Kalucki) writes:
> 
>>
>>In article <16B5BE8CE.MACE@HDQCMS2H.UTSD.ATT.COM>, MACE@HDQCMS2H.UTSD.ATT.COM writes:
>>>We have 10 LaserJet printers which we would like to connect to a LPD
>>>server, for access by our OS/2, DOS/Windows and IBM VM/CMS users.
>>>
>>>We would rather not use LPD on various machines directly connected to
>>>the printers, since we would lose access to the printer when the machine
>>>went down (was re-booted or powered off).
>>>
>>>The connections would be serial (RS-232), with one connection being
>>>parallel.
>>>
>>>We have looked at the Lantronix equipment, but that does not really
>>>offer LPD; since we have a diverse user community, we want to use the
>>>LPR and LPRMON software that is provided with the TCP/IP implementations.
>>
>>Hmm. That's funny. I have the Lantronix EPS1 here that does LPD
>>and it works fine.
>>
>>
>>                -John Kalucki
>>                johnk@gordian.com
>>
> 
>According to Lantronix, their unit really does RTEL, which can be made
>to appear to be LPD.  The problem is that you must use Lantronix supplied
>software (not standard LPR software), and that software is only supported
>for Unix.  Since we have DOS, Windows, OS/2 and VM/CMS Lantronix indicated
>that we were out of luck.  They said that they would be providing true
>LPD support in 2Q93, but still only supported for Unix (since the
>microcode upload is only supported on Unix).  Thanks for the reply, though!

Try the Chase Research IoPrint.  It's a little box with two serial and
one parallel port that acts as an LPD server.  Their number in the USA
is (615) 872 0770.  

Aris

-- 
Aris Stathakis        Tel:+27 11 887 4220 |Gimme a beer and money sandwich -  
SCO Unix Support      Fax:+27 11 887 1141 |Hold the bread. - Waldo D.R. Dobbs
Lasernet (Pty) Ltd    X25: 06550 11642692 |_________________________________
P.O. Box 78446, Sandton, 2146, R.S.A       Internet: aris@lasernet.co.za

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Feb 1993 14:58:38 GMT
From:      sbpress@libws1 (The Stony Brook Press)
To:        comp.protocols.tcp-ip,comp.unix.misc
Subject:   CSLIP for HP-UX

I'm looking for a CSLIP server program for an hp-ux system, to connect
to a macintosh running Macsllip. Is There a P.D. or shareware program
that will do this,

thanks in advance

--
signature:  		THE STONY BROOK PRESS
The State University of New York at Stony Brook Community's Feature Newspaper
Snailnet: The Stony Brook Press   |  internet: sbpress@ic.sunysb.edu  
	  S.U.N.Y. at Stony Brook |  bitnet : sbpress%ic.sunysb.edu@cunyvm
          Stony Brook N.Y. 11794  |  Voicenet : (516) 632-6451
alternate e-mail(if sbpress@ic... doesn't work): dglasner@ccmail.sunysb.edu

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Feb 1993 12:21:38 IST
From:      Yair Elharrar <X68442@BARILVM.BITNET>
To:        comp.protocols.tcp-ip
Subject:   WD8003E hardware driver for TCP/DOS

Help! I'm looking for a Western Digital 8003E card hardware driver
for use with IBM TCP/IP for DOS. Right now I'm using a packet driver
with IBM's packet driver's interface but that's just not good enough.
Any ideas?

Yair Elharrar
Bar-Ilan University

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Feb 93 16:34:30 GMT
From:      rob@leland.Stanford.EDU (Rob Tanner)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: Appletalk on PC

In article <1km48tINNca1@tomato.cis.ohio-state.edu> marat@cis.ohio-state.edu (wisebond marat) writes:
>I wonder if anyone on the net knows of Network packages other than Tops 
>that will link Macs and MsDos machines using appletalk adapters on the 
>PC's.  The best sollution would allow the use of current Network capilities 
>of the mac and use some kind of software on the PC.
>
>mail me responses direct at marat@cis.ohio-state.edu
>
>or respond via news
>
>thanks in advance.

The product you want is Farallon's PhoneNET Talk.  It will work with a
number of network cards, including PC LocalTalk for which there are
several manufacturers.

Farallon is in Emeryville, CA.  Their phone number is (415) 596-9000.


-- 
Rob Tanner                              Internet: rob@sherlock.stanford.edu
System Administrator
Stanford University, California

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 1993 16:44:33 GMT
From:      forags@smokey (Al Stangenberger)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: Appletalk on PC

In article <1993Feb2.163430.19999@leland.Stanford.EDU> rob@leland.Stanford.EDU (Rob Tanner) writes:
>Farallon is in Emeryville, CA.  Their phone number is (415) 596-9000.

The area code for Emeryville is now  510   .

-- 
Al Stangenberger                    Dept. of Forestry & Resource Mgt.
forags@violet.berkeley.edu          145 Mulford Hall - Univ. of Calif.
uucp:  ucbvax!ucbviolet!forags      Berkeley, CA  94720
BITNET: FORAGS AT UCBVIOLE          (510) 642-4424  FAX: (510) 643-5438                      

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Feb 1993 16:55:12 GMT
From:      tching@target.uucp (Tracy Ching <SysAdmin>)
To:        comp.protocols.tcp-ip
Subject:   Have you written a TCP/IP kernel sucessfully?

	I'm about to do the same.  I have Comers' series.  I'm trying to 
embed it into an AMD29200 board with ethernet chip.  Hence, ...
1) Do I -need- an OS to run the IP stuff?
2) Can you give me an idea of number of lines of code you have?
3) Any helpful hints you can give me?  (any help is greatly appreciated)

tching@target.water.ca.gov

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 93 18:22:19 GMT
From:      bob_groendyke@macgate.csuchico.edu (Bob Groendyke)
To:        comp.protocols.tcp-ip
Subject:   NCSA  &  ODI

Please forgive if this has been discussed previously, I'm new to this
group. I've recently read about Novell 4.0 supporting only ODI drivers at
the client workstation, instead of linked IPX drivers, which I'm using
for Clarkson's packet drivers. I currently run NCSA and IPX over the
Clarkson's packet drivers. So...I'm wondering if NCSA has any plans to
support ODI. Thanks,

Bob Groendyke
California State University Chico
bob_groendyke@macgate.csuchico.edu

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Feb 93 19:20:07 GMT
From:      shj@ultra.com (Steve Jay {Ultra Unix SW Mgr})
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in SVR4

stevea@i88.isc.com (Steve Alexander) writes:

>The SVR4 deal was completed a long time before Novell ever got into UNIX.  
>They're using what they got from USL:  Our stack, SunOS 4.0 networking 
>applications, and a socket library/module implementation done at Sun.

Well, the networking kernel source code AT&T sent us when we licensed
SVR4 looks a lot like BSD to me.  Side by side comparisons show that
huge parts of the SVR4 code are copied character for character from BSD.
I can believe that the interfacing to streams instead of sockets was
done by Lachman, but that's a very small percentage of the code.  It's
clear that the actual protocol handling is straight from BSD.

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"

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Feb 1993 19:37:18 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in SVR4

In article <C1sG72.BL2@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
>This isn't a hard problem for Novell to solve, IF THEY WISH TO SOLVE IT.

That's correct.  It's just a matter of time, money, and priority.
Since you have no idea what's currently going on concerning TCP/IP in
UNIXWare development, you can't really judge whether or not Novell
wishes to solve this problem, can you?  Why do you assume the worst?

>  I rather suspect that Novell would rather us all use SPX/IPX, but I
>for one won't be doing that.

I suppose there are people in Novell that would rather everyone used
IPX, but it strikes me a little odd to think there would be a
significant number of them in Univel, a company dedicated to UNIX
development.  Most UNIX people like TCP/IP, even within Novell.

>I consider TCP/IP support mandatory so the cost of (OS + TCP/IP) is
>what I compare when I look at various vendors products.

An absolutely valid and reasonable decision for you.  Other people
might have different requirements resulting in different criteria.
That's exactly what makes capitalism so great.  Since i'm not familiar
with the market, i don't know how UNIXWare's OS+TCP/IP price compares
to other venders OS+TCP/IP costs.  What was your ultimate conclusion?

						don provan
						donp@novell.com

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Tue, 02 Feb 1993 20:57:30 GMT
From:      stevea@i88.isc.com (Steve Alexander)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in SVR4

In article <1993Feb2.192007.1022@ultra.com> shj@ultra.com (Steve Jay {Ultra Unix SW Mgr}) writes:
>Well, the networking kernel source code AT&T sent us when we licensed
>SVR4 looks a lot like BSD to me.  Side by side comparisons show that
>huge parts of the SVR4 code are copied character for character from BSD.
>I can believe that the interfacing to streams instead of sockets was
>done by Lachman, but that's a very small percentage of the code.  It's
>clear that the actual protocol handling is straight from BSD.

Yes, our code is based on BSD, and we have never claimed otherwise.

-- 
Steve Alexander, Lachman Technology, Inc. | stevea@isc.com
(708) 505-9555 x256 FAX: (708) 505-9574	  | ...!{sun,ico}!laidbak!stevea

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Feb 1993 21:14:48 GMT
From:      emery@goldfinger.mitre.org (David Emery)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: DCE COMPLIANT ?

Until adopted by some formal standards-making body, DCE is nothing
more than a proprietary interface that happens to be implemented by
more than one vendor.  Let's not all jump into the "Open Software
Foundation = Open" pit.  OSF "products" are NOT a-priori "Open".

OSF has submitted MOTIF for formal standardization.  When they do the
same for DCE, and it passes the (occasional rigorous) review that
formal standards go through, then I'll consider it to be "open".  

				dave

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 93 21:57:24 GMT
From:      drich@BBN.COM (David Rich)
To:        comp.multimedia,comp.sys.sun.apps,ne.nearnet.tech,comp.protocols.tcp-ip
Subject:   Internet Desktop Video Conference Demo from BBN

A public Internet demonstration of BBN's new PictureWindow(TM) video
conferencing software is now available for Sun SPARCstation users who
are connected to the Internet.  The demonstration allows users to try
a receive-only version of the software and sample the view from our
server in Cambridge, Mass.

PictureWindow is a software package that allows workstation users to
hold video conferences over IP networks.  PictureWindow's predecessor,
DVC, was used to broadcast the July 1992 IETF conference.  The
tremendous interest in this software has prompted us to make this
demonstration available to the public.  All you need to run the
demonstration is a Sun SPARCstation such as a 1, 1+, 2, IPC, IPX or
SPARC 10.  Additional information about the demo can be found in the
README file.


Demonstration, receive-only software is available through FTP:

% ftp picwin.bbn.com
	< login "picwin">
   ftp> binary
   ftp> get PWRX_README
   ftp> get pwrx_tarfile.Z
   ftp> quit
%  

The PWRX_README file contains all the information you need to run the
demonstration.
		
For more information call 1-800-422-2359 or send electronic mail to
picwin-sales@bbn.com.

PictureWindow is a trademark of Bolt Beranek and Newman, Inc.

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Feb 1993 22:58:55 GMT
From:      A1.MCL@isumvs.iastate.edu
To:        comp.protocols.tcp-ip
Subject:   Re: AppleTalk/MacIP across IBM 8209

In article <C1ts1z.EoE@harpo.dev.uga.edu>,
edm@harpo.dev.uga.edu (Ed Maioriello) writes:
>Hi,
>
>Does anyone know if either AppleTalk or IP from a Macintosh can make the
>Token Ring/Ethernet jump across an IBM 8209 Lan Bridge.  I'm reasonably
>sure that AppleTalk won't work, but I don't understand why.  With the
>8209 running in mode 2 I would have thought that TokenTalk frames which
>are SNAP frames would get converted to ethernet_snap frames.  This seems
>like it should work just fine, but it doesn't seem to in real life.
>I've been told that IP should work fine, but this seems like it
>shouldn't work either since this means that token-ring_snap frames are
>getting converted to ethernet_ii frames which I thought wasn't supposed
>to happen.  (Oh yeah, our 8209s are configured to deal with Novell's IPX
>as well.)
>
>If it sounds like I'm struggling to understand what's going on here then
>I've gotten my message across. :-) Any help will be greatly appreciated.
>
>Thanks in advance.
>
>Ed Maioriello                                       edm @ harpo.dev.uga.edu
>University Computing & Networking Services          edm @ aisun1.ai.uga.edu
>University of Georgia  ----------------------------------------------------
>Athens, Ga. 30602      | First Rule of Troubleshooting:
>(706)-542-6462         |                     If it don't work - plug it in!
>

Here is what I have on this subject, from IBMLink,
 SLEVW1                      Item Q607079
 Item BTMBD         Document ID Q607079
 TITLE: 921203 CAN THE 8209 SUPPORT APPLETALK BETWEEN A 10BASET
               SEGMENT AND A TOKEN RING SEGMENT?

 QUESTION:
 Will the 8209 support the following configuration? One 10BaseT segment
 bridged by a single 8209 to a token ring segment. The communications
 desired is from a 10BaseT station running Attachmate software going
 through a token ring attached PC-Gateway also running Attachmate S/W
 then thru a 3174 to the host. The real issue is...will the 8209 support
 the connection between 10BaseT station and token ring gateway when the
 connection is made up of Appletalk/Ethertalk thru the 8209 to Tokentalk/
 Appletalk?
 Thank you.
 ---------- ---------- ---------- --------- ---------- ----------
 A: Unfortunately, the answer to this one is complex and does not
 leave you with a strong, comfortable feeling that it will work for
 every scenario. Please follow the logic below:
 I expect Appletalk 802.3 SNAP to work with Appletalk 802.2 LLC SNAP
 on TR across a single 8209. I say this based on previously answered
 ASKQ 8209 library items and on extended research. If at all possible,
 configure your Ethertalk for SNAP 802.3 and same for 8209 (802.3)
 and Automatic mode.

 For Ethernet V2 Appletalk frame formats, the answer is far less clear.
 Essentially, there is one opinion for working and one against working.

 On p. 2-42 of the 8209 TR/Ethernet Attach Module Guide (GA27-3891-1)
 it seems to suggest Appletalk type fields of X '7809, 80F3, 809B'
 will work across an 8209 with the IPX EC and the IPX parm enabled.
 (default is enabled) However, these are Novell/Appletalk type fields
 and may not be the same as those used for "Ethertalk." If they
 are the same, we would expect this to work per the 8209 doc,
 although it has not been tested by IBM. The only testing which was
 req'd for the IPX EC was for X '8137' and X 'E0' type/SAPs.
 That has been certified by Novell/IBM to work with the IPX EC.

 For the case of not working for Ethernet V2: Appletalk protocols
 are known to send 802.3 and V2 frames from the same WS on Ethernet.
 The 8209 was not designed for this capability, although it is a well
 known requirement for any future enhancements. There are many ASKQ
 library items which will attest to the above. Also, there are other
 vendors TCP/IP applications (don't know if your Tokentalk/Ethertalk WS's
 are using TCP/IP) which use imbedded MAC Addresses in the Info field.
 In prior Appletalk scenarios, (before the IPX EC was added to the 8209)
 this presented an 'unworkable' situation because the 8209 would only
 invert the MAC headers and not the Addresses in the INFO field.
 Since the addresses didn't match, the WS's could not talk to each
 other across TR/Ethernet single 8209 environments. Since this has
 still not been tested by IBM, I am reluctant to say definitively
 that it will work using E V2 and IPX enabled.

 NET: Try and use 802.3 for Ethertalk, this should work. If you can't,
      then I expect only the condition I have talked about to be
      workable for V2.

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


Mike Long
Iowa State University

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Feb 1993 23:51:55 GMT
From:      mike@gordian.com (Michael A. Thomas)
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone know of a good LPR/LPD Server?

In article <16B62716F.MACE@HDQCMS2H.UTSD.ATT.COM>, MACE@HDQCMS2H.UTSD.ATT.COM writes:
> According to Lantronix, their unit really does RTEL, which can be made
> to appear to be LPD.  The problem is that you must use Lantronix supplied
> software (not standard LPR software), and that software is only supported
> for Unix.  Since we have DOS, Windows, OS/2 and VM/CMS Lantronix indicated
> that we were out of luck.  They said that they would be providing true
> LPD support in 2Q93, but still only supported for Unix (since the
> microcode upload is only supported on Unix).  Thanks for the reply, though!

  The EPS-1 which John mentioned is shipping with real LPD support
(using rfc 1179 and source as a guide...) as of right now. The LPD 
support scheduled for Q293 is for the rest of the server line. This
should work just fine from any of your host systems as there is no 
host software required (unlike RTEL as you mention).
  I'm not certain what you mean by only supporting Unix though. The
microcode upload (server software download?) is necessary only on
non-flash rom based units. The EPS-1 is a flash based unit, and the
other servers are flash optional. In any case, the Lantronix boxes
will boot from TFTP, MOP (DEC/VMS), and Netware -- not just Unix.
-- 

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

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Feb 1993 00:29:10 GMT
From:      wow001@acad.drake.edu
To:        comp.protocols.tcp-ip
Subject:   Porting on 9600 baud? Anyone?

Is there any way to connect a macintosh computer to a VAX using TCP/IP(or
anything else) over a 9600 baud digital line so that the mac can have an IP#
and be ported to?  The Macintosh is useing appletalk right now but has Ethernet
capability.  Running an ethernet cable to the VAX requires more resources than
available.  I seldom read this group so please email me(post though others may
have the same question)


Thanks in advance
Wade Webster


-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 93 01:35:49 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: NCSA  &  ODI

In article <1kme4rINNi37@charnel.ecst.csuchico.edu> bob_groendyke@macgate.csuchico.edu (Bob Groendyke) writes:
>Please forgive if this has been discussed previously, I'm new to this
>group. I've recently read about Novell 4.0 supporting only ODI drivers at
>the client workstation, instead of linked IPX drivers, which I'm using
>for Clarkson's packet drivers. I currently run NCSA and IPX over the
>Clarkson's packet drivers. So...I'm wondering if NCSA has any plans to
>support ODI. Thanks,

I can't answer your question about NCSA, but i can allay your concerns
somewhat: NetWare v4.0 will support any client that sends it properly
formatted NetWare packets.  The format of these packets doesn't change
from release to release, so any existing client software will continue
to work NetWare v4.0 with no decrease in functionality.

I think what you've heard is that NetWare v4.0 will only include ODI
client software, it won't include the old non-ODI software.  (Well,
i've heard this on the streets, but actually, i am not in a position
to confirm that this is really true, since this type of decision is
made elsewhere and i haven't seen the official announcement.)  It is
true that some new features of NetWare v4.0 won't be available using
the older non-ODI software, but i don't know which.  So you might be
better off with an ODI based NCSA, but you won't be dead in the water
without it.
						don provan
						donp@novell.com

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 93 01:52:50 GMT
From:      banshee@cats.ucsc.edu (Wailer at the Gates of Dawn)
To:        comp.protocols.tcp-ip
Subject:   REQUEST: Apple talk <=> tcp


	could someone mail me pointers for connecting a mac se to a tcp
network?  the mac would have to talk tcp to a mix of pc and unix hosts.

-- 
The Wailer at the Gates of Dawn              | banshee@cats.UCSC.EDU       |
Just who ARE you calling a FROOFROO Head?    |                             |
DoD#0667  "Just a friend of the beast."      | banshee@ucscb.UCSC.EDU      |
2,3,5,7,13,17,19,31,61,89,107,127,521,607....| banshee@ucscb.BITNET        |

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Feb 1993 02:34:11 GMT
From:      s29@osiris.cso.uiuc.edu (R Mills)
To:        comp.protocols.tcp-ip
Subject:   Macintosh and TCP/IP

Hello all.....

I am not much of a mac guru and know little about apple talk so here it
goes:

I am setting up a tcp/ip network that will be mostly twisted pair ethernet
all into a star hub.

On this network you will find Sun workstations, 3b2 Unix boxes, 386 unix/dos
boxes, xterminals and 2 hp laserjet 3SIs w/ jetdirect ethernet cards.

I have 2 quadra 700 macs with:

Lazerwriter II
Agfa Procolor Premier Slide Maker
Epson ES-300C color scanner
Tektronics Phaser III

These devices are rs232 or appletalk.

The users of these macs like to mount each other's hard drives across
appletalk so that each other can use both hard drives and devices.  When
they do this, it slows both quads to a crawl.

Here is what I want to do and need suggestions on:

I want to tcp/ip the macs together (10mb) ethernet and then setup the
tektronics Phaser III and all of the other devices so that my main tcp/ip
network can use these devices.

Questions:
1. will there be too much load on the main star hub if I just place each
device on the star hub?
2. will it be to my benefit to have the macs serv all of the devices on
rs-232 or appletalk and then tcp/ip the macs into the hub?
3. should I put both macs into the hub or daisy chain the 2 macs together
and then terminate that chain into the hub?

How would you network the macs/devices into the tcp/ip network.  Keep in
mind that traffic accross my hub should be light....

Thanx for any help you can provide out there!!!!

Please send your responces to:

Don Ingli
don@scsmo1.attmail.com


-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 1993 12:36:40 -0500
From:      hubley-robert@cs.yale.edu (Robert Hubley)
To:        comp.protocols.tcp-ip
Subject:   Ethernet Connectivity Question


	I dont know if this is the right group to ask but here it goes anyway.
I want to set up a 10BaseT extension to my current network.  The configuration
I am proposing is the following (see below).  Does anyone know of any reason
why this would not work or does anyone know of a better solution involving
10BaseT connectivity to the remort workstations?

I would appreciate any input.

Thanks
-Rob
                     


                       +-------+
                       | M P T |>--- Network Port ..unused (local-loopback)
    +--------+         | u o r |
    | Server |   AUI   | l r a |
    |        |>-------<| t t n |>--- Port two (Workstation)  
    +--------+     Port| i   c |>--- Port three (Workstation) 
                    One|     e |>--- Port four (Workstation)
                       |     i |>--- Port five (Workstation)
                       |     v |>--- Port six (Workstation)
                       |     e |>--- Port seven (Workstation)
                       |     r |>----+ Port eight
                       +-------+     |
                                     |
                                     |
                    AUI              |
            +------------------------+
            |
            |
            |                 The equipment above I already have
  ********* | ********************************************************
            |                 The equipment below I want to purchase
            |
            |
            |    +-------+
            |    | M P R |
            +---<| u o e |>~~~ 10BaseT (RJ45 No Connection) 
                 | l r p |>~~~ 10BaseT  "
                 | t t e |>~~~ 10BaseT  "
                 | i   a |>~~~ 10BaseT  "
                 |     t |>~~~ 10BaseT  "
                 |     e |>~~~ 10BaseT  "
                 |     r |>~~~ 10BaseT  "
                 |       |>~~~ 10BaseT ~~~~~~~~~~+
                 |       |                       ~
                 +-------+                       ~
                                                 ~
                                                 ~
            +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
            ~
            ~
            ~                       +-------+
            ~                       | M P T |> Network..unused (local-loopback)
            ~   +---------+         | u o r |
            ~   | 10BaseT |   AUI   | l r a |>--- Port two (Workstation)
            +~~~| TRNCVR  |>-------<| t t n |>--- Port three (Workstation) 
                +---------+     Port| i   c |>--- Port four (Workstation)
                                 One|     e |>--- Port five (Workstation)
                                    |     i |>--- Port six (Worktation)
                                    |     v |>--- Port seven (Workstation)
                                    |     e |>--- Port eight (Workstation)
                                    |     r |
                                    +-------+    
-- 
Robert M. Hubley                                                 (203) 432-6428 
Systems Programmer                                  
Yale University Computer Science Dept.                hubley-robert@cs.yale.edu 

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 93 07:13:42 GMT
From:      mark@mcs.spb.su (Mark Orlov)
To:        comp.protocols.tcp-ip
Subject:   SLIP and ICL DRS 6000



        I want to have dial-up SLIP on ICL DRS 3000
        and DRS 6000.

        Does anybody  have it?
        If not what can you advise?  May be, to port free SLIP
        realisations which can be got from anonymous FTP servers?
        But which one?



        Thanks and best Regards,

                        Mark.

======================================================================
   Mark Orlov,                      |  Internet --> mark@mcs.spb.su
   Head of UNIX systems department, |     Voice --> +7 (812) 5683952
   Marine Computer Systems (ICL)    |
   St. Petersburg,  Russia.         |

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 93 10:22:29 GMT
From:      bourkej@ul.ie
To:        comp.protocols.tcp-ip
Subject:   Can TCP/IP have backup routes

Howdy,

I need to have a bunch of sun workstations on an ethernet witha router and
a backup router.  If one router goes pop, the other router will have to 
act as the net's router.

I know TCP?IP routes are on a connection basis, but is there any other way ?



john


-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 93 11:50:42 GMT
From:      eb@felix.Sublink.Org (Enrico Badella)
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   HELP! Using NFS to create a distributed shared memory.

I'm working on a project where I have no authority to change the
architecture 8-( and I'm wondering if the chosen distributed IPC
method is reasonable or not.

This is the problem:
there are several clients that do data acquisition and want to export
their data to a server (probably X11 based) on a remote machine. The
solution that someone chose is to have all the clients write their 
data in a common file at different positions (to avoid locking the file)
and the server reads this file via NFS. More or less like this:

    +--------+
    |client 1|\
    +--------+ \ +--------+
    +--------+  \|        | 		 +-------+
    |client 2|---|        |   		 |  X11  |
    +--------+   |  FILE  | <----NFS---->| front |
        .        |	  |   		 |  end  |
        .       /|	  |		 +-------+
    +--------+ / +--------+
    |client k|/
    +--------+

It has never been tried out. I was asked my opinion and told the guy
in charge of the project that I wouldn't have used NFS but a real 
client/server approach using RPC or, depending on the complexity of 
the info pass around, TCP/UDP/IP. This solution, especially RPC, was
rejected as too difficult to implement ;-).

I have a strange feeling that this solution won't work as expected
but cannot focalize the possible problems; or is my 'programmer's ego'
rejecting it because so simple and possibly elegant.

Thanks.

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

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 93 12:34:12 GMT
From:      ercm20@festival.ed.ac.uk (Sam Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

donp@novell.com (don provan) writes:
> The gentleman from Norway is a good example: he's not just saying that
> he has a personal dislike for non-TP4 transports so he's going to get
> even by refusing to buy any.  He's telling you exactly why non-TP4
> solutions are failing *in practice* for him.  He's gone beyond just
> seeing that this solution didn't work and rejecting that *product*.
> He has determined *why* it didn't work, so he's rejecting that *class*
> of products.  You can tell him he should leave such decisions up to
> the experts...but somehow i don't think he's going to listen to you.

Actually that's not how I read his posts.  To me it sounded like he was
saying 'the Norwegian PTT's implementation X.25 won't work for sending
3MB mail files around and therefore X.25 is no good for anything.'  This
is clearly an over-generalisation.  If he can't get a better X.25
service from his PTT or another provider then obviously he needs to use
something else, but that's a commercial and pragmatic decision not a
reason for condemning X.25 on principle.

In the UK Academic Community we have a very reliable, high speed (2Mbps)
private X.25 network.  It runs the UK's own Coloured Book protocols and
there's a (now rather shaky) committment to run OSI CONS over it in
future.  In the last couple of years we have been runnig IP over it for
pragmatic reasons - it gives us the applications and connectivity that
people expect.  For the same reasons the successor network, SuperJANET,
will carry native IP (on SMDS and what are effectively leased 34Mbps
lines initially, ATM eventually).  It will probably be a multiprotocol
network, but exactly how we carry X.25/CONS, CLNP and other protocols is
still being studied. 


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

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 93 13:42:57 GMT
From:      hgoldhoorn@mswe.dnet.ms.philips.nl
To:        comp.protocols.tcp-ip
Subject:   Re: Help with ka9q

In article <amehta-210193223907@commons4-44-kstar-node.net.yale.edu>, amehta@minerva.cis.yale.edu (Anand R. Mehta) writes:
> Hello all.
> 
> I am currently trying to set up a PPP link between a NeXT and a PC, which
> is on the campus ethernet.  I have the NeXT PPP implimentation working, but
> cannot get the PC up.  I believe that the packet driver is installed
> correctly (NCSA telnet will use it), and that the problem is one of
> configuring the PC routing tables, etc.  I have not even tried ka9q with
> PPP, as I cannot get it to work over ether.
> 
> Could someone who has configured ka9q to work (even without ppp) please
> email me a copy of their *.net file so that I can have a look at what is
> going on? 

try this for net.bat:
cls
depca.com 0x60 0x5 0x300 0xd000
920411lt
termin 0x60





> Also, any tips on where to find more documentation would be
> greatly appreciated.
> 
> What I would like to have eventually is this:
> 
> ============PC============ether
>              |
>              |
>              ppp
>              |
>             NeXT
> 
> with ka9q routing packets between the NeXT and the rest of the world.
> 
> Any help that you can give me would be greatly appreciated.
> 
> -Anand 
> Academic Computing Services
> Yale University
> (203) 436-1437

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 93 13:47:55 GMT
From:      hgoldhoorn@mswe.dnet.ms.philips.nl
To:        comp.protocols.tcp-ip
Subject:   Re: Help with ka9q

In article <amehta-210193223907@commons4-44-kstar-node.net.yale.edu>, amehta@minerva.cis.yale.edu (Anand R. Mehta) writes:
> Hello all.
> 
> I am currently trying to set up a PPP link between a NeXT and a PC, which
> is on the campus ethernet.  I have the NeXT PPP implimentation working, but
> cannot get the PC up.  I believe that the packet driver is installed
> correctly (NCSA telnet will use it), and that the problem is one of
> configuring the PC routing tables, etc.  I have not even tried ka9q with
> PPP, as I cannot get it to work over ether.
> 
> Could someone who has configured ka9q to work (even without ppp) please
> email me a copy of their *.net file so that I can have a look at what is
> going on?  Also, any tips on where to find more documentation would be
> greatly appreciated.
> 
> What I would like to have eventually is this:
> 
> ============PC============ether
>              |
>              |
>              ppp
>              |
>             NeXT
> 
> with ka9q routing packets between the NeXT and the rest of the world.
> 
> Any help that you can give me would be greatly appreciated.
> 

try this for autoexec.net   (made for net from pe1chl)
it works on the local decnet here  ( trial only)
setenv CALLSIGN ${CALLSIGN-MSHD1}
buffers 32 2 64
attach packet 0x60 lan 3000 472 mshd1
source \net\config.net
hostname $CALLSIGN.ampr.org
ip address $CALLSIGN
source \net\routes.net
del -f ${NETMAILQ}*.lck
ax25 port 1 conn $CALLSIGN
ax25 port 6 conn $CALLSIGN-1
start discard
start echo
start finger
start ftp
start rcmd 333 "hier de password zin voor de rcmd server invullen"
start smtp
start telnet
ax25 start bridge
ax25 start mbox ${NETFINGER}name.txt
ax25 start mheard
ax25 start netdigi
ax25 start tnc "> MSHD1, chat mode"
`
Harry



> -Anand 
> Academic Computing Services
> Yale University
> (203) 436-1437

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 93 14:52:41 GMT
From:      smb@research.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in SVR4

In article <1993Feb2.192007.1022@ultra.com>, shj@ultra.com (Steve Jay {Ultra Unix SW Mgr}) writes:
> stevea@i88.isc.com (Steve Alexander) writes:
> Well, the networking kernel source code AT&T sent us when we licensed
> SVR4 looks a lot like BSD to me.  Side by side comparisons show that
> huge parts of the SVR4 code are copied character for character from BSD.
> I can believe that the interfacing to streams instead of sockets was
> done by Lachman, but that's a very small percentage of the code.  It's
> clear that the actual protocol handling is straight from BSD.

Yes.  So what?

There was a lot of changed code in at least three places -- at the
user-TCP interface, the TCP-IP interface, and the IP-driver interface.
This was done to support streams -- a decision that was, to my way of
thinking, unquestionably correct.  For better or for worse, support
of streams implied support of TLI and DLPI -- and that decision is,
perhaps, much more questionable, but was dictated by decisions made
long ago.  And that, in turn, demanded development of a high-quality
socket compatibility package.

I think you'd be surprised at how long some of that took, and how thorny
some of the interface questions were.  For example, how should TCP cache
a route, or IP inform TCP when the cached route seems dead, given that the
only communication between the two modules is supposed to be via message-
passing, and *not* pointers to shared tables?  Sure, invent a message --
but you want it to be the right message.

You're absolutely right that lots of vendors can, and have, ported a
BSD-derived TCP/IP to their SysV kernels.  Need I remind you that some of
those ports don't work well?

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Feb 1993 15:17:07 GMT
From:      pirey@nswc.navy.mil (Phil Irey 703.663.1582)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: sources for xtp (eXpress Transport


I know of three companies which have software implementations of XTP

1) Mentat - contact Bruce Carneal at (805) 987-3950
2) Network Express - contact Alf Weaver at (804) 979-7529
3) XTP Systems - contact Larry Green at (804) 965-0825

By the way, the most recent version of XTP is 3.6.

phil irey (pirey@relay.nswc.navy.mil)

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 93 18:01:37 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1kl5vvINN9mh@cronkite.cisco.com>, tli@cisco.com (Tony Li) writes:
> In article <3414@ucl-cs.uucp> J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) writes:
>     
>     CLNP is semantically a clean replacement for IP,
>     with 5 times the address size and strucutre permitting hieararchical
>     assignment, thus route aggregation etc etc - it is one of 3 or 4
>     good candidates, though.
> 
> Nitpicking: While the current NSAP formats are currently 20 bytes, you do
> NOT get to assign all of them.  In fact, at least with the GOSIP address
> format, you get darn few bytes down to the end user.  I hope that if the
> Internet DOES use TCP/CLNP (a.k.a. TUBA), we get another AFI and rethink
> the address format. 
> 
> Oh, I should also point out that the NSAP is NOT fixed at 20 bytes.  One of
> the nice things about CLNP is that if we get into this hole again, we just
> stretch the address...

While a new AFI might not be a bad idea, I think you are a bit negative on the
space available under US GOSIP. Current IP addresses are 4 octets with half the
address space given to just 126 (127?) nets and another 25% to just 32K nets.
While this lucky group has plenty of space, most remaining address space allows
only 254 nodes per net. My building has more than 254 nodes!

Under GOSIP the MINIMUM address space available to EVERY network is 8 octets
allowing trillions of nodes per net and the total number of nets available is
similarly large. The individual nets can decide for themselves just how to
allocate this space (subnet). We use 2 octets for subnet giving us 64K subnets
of about 280 trillion addresses. I think that should be adequate. (6 octets for
"local" address" makes it possible to use the 802 MAC address there.)

While the GOSIP namespace uses a lot of bits for bookkeeping, they were not
selected trivially and make setting up routing much more straight forward. They
allow easy delegation of addressing authority at several levels and have some
reserved space in case something was missed.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov		(510) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Feb 1993 19:07:05 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in SVR4

In article <kfPlC670BwxIQ1u48y@transarc.com> Lyle_Seaman@transarc.com writes:
>On  The  Other  Hand, SPX (well, IPX anyway) was probably nearly the
>perfect protocol for the initial purposes of NetWare.

On the one hand, i think you might be giving Novell a little too much
credit.  On the other hand, TCP/IP *still* doesn't have the addressing
flexibility or the dynamic service location abilities that IPX has.

>I hope (do I?  Hmm, I'm not sure) that Novell isn't so stuck on its
>own traditions that such a move is politically impossible.

Me, too.  In fact, you might say i've bet my career on it.

						don provan
						donp@novell.com

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Feb 1993 19:23:40 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <31211@castle.ed.ac.uk> ercm20@festival.ed.ac.uk (Sam Wilson) writes:
>Actually that's not how I read his posts.  To me it sounded like he was
>saying 'the Norwegian PTT's implementation X.25 won't work for sending
>3MB mail files around and therefore X.25 is no good for anything.'  This
>is clearly an over-generalisation.

I read it as "My X.25 is unreliable.  Therefore i don't think it's a
good idea to buy a product that assumes all X.25s are reliable, since
that assumption is demonstrably false."  I personally agree with this
position technically, particularly since you don't always control all
networks your packets have to traverse to get where they're going.  On
the other hand, i agree that this one technical point is not necessarily
the deciding factor for the market, but remember that the original point
was merely that it was a valid point of view for a user, as opposed to a
developer, to take.  OSI products can react to it however they see fit.

>In the last couple of years we have been runnig IP over it for
>pragmatic reasons - it gives us the applications and connectivity that
>people expect.

Then there's that....
						don provan
						donp@novell.com

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 93 20:43:12 GMT
From:      mike@gordian.com (Michael A. Thomas)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in SVR4

In article <kfPlC670BwxIQ1u48y@transarc.com>, Lyle_Seaman@transarc.com writes:
> On  The  Other  Hand, SPX (well, IPX anyway) was probably nearly the
> perfect protocol for the initial purposes of NetWare.  The only thing
> that it desperately needed was some plan for migration or adding new
> features to the protocol once the hardware could support it.  And it's
> not technically impossible to migrate away from it, even so.  NetWare
> has taken a few steps in that direction.  I hope (do I?  Hmm, I'm not
> sure) that Novell isn't so stuck on its own traditions that such a move
> is politically impossible.

  From what I've seen, SPX is normally irrelevent to what most people
consider "Netware". The NCP stuff is all based right on top of IPX
(the network layer) and could trivially be implemented as either
a seperate protocol layer (like TCP, UDP, ICMP) or even by just
riding it on top of UDP like NFS does. 
  This would certainly help the routing brain damage that Netware
(IPX/RIP) suffers from.
-- 

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

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 93 20:48:51 GMT
From:      dharber@dcs.simpact.com
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in SVR4

In article <C1sG72.BL2@ra.nrl.navy.mil>, atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
> In article <1993Feb1.200532.3287@novell.com> joeg@novell.com (Joe Gervais) writes:
> 
>> If you look at the TCP/IP module from USL SVR4, you'll notice a
>> Copyright Lachman Notice.  The basic problem is that USL doesn't own
>> the TCP/IP stack in SVR4, Unisys, when it sells SVR4 with TCP/IP
>> doesn't own the stack, and Univel, when it ships SVR4 doesn't own the
>> stack.  They all pay royalties to Lachman Associates.  So since these
>> firms pay royalties to Lachman, why shouldn't they pass the cost on?
> 
> This isn't a hard problem for Novell to solve, IF THEY WISH TO SOLVE
> IT.  The BSD Net/2 implementation of TCP/IP is available online via
> ftp from ftp.uu.net and many other places.  Most vendors of UNIX
> already use the BSD sources in their kernels.  I'm frankly surprised
> that SVR4 doesn't already do this.
> 

My guess is that the Lachman code is STREAMS based. I'm going to follow
up on your reference to the BSD Net/2 code but I believe that it is not
a STREAMS based implementation.

Does anyone know about a STREAMS based public domain TCP/IP stack?

I am also looking for any public domain STREAMS emulation software that
is appropriate for porting to an embedded environment. Does such a thing
exist?

I am also looking for any design info -- pseudo code, notes, whatever --
that provide information on implementing a STREAMS environment.

Does AT&T/USL/Novell/whoever's in charge publish any of their SYS V
streams code for the kernel support modules?

I have the standard AT&T STREAMS guide and the SUN 'Writing Device Drivers
STREAMS Programming' manual. I am looking for stuff that would speed up
the development of a STREAMS environment for real time systems.

Thanks

Dave Harber

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Feb 1993 21:11:40 GMT
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: NCSA  &  ODI

In article <1kme4rINNi37@charnel.ecst.csuchico.edu>,
 bob_groendyke@macgate.csuchico.edu (Bob Groendyke) wrote:
>I'm wondering if NCSA has any plans to support ODI.

You can make NCSA Telnet work with ODI by using the ODIPKT shim,
which is available in the directory hsdndev.harvard.edu:pub/odipkt/ .

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

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Feb 1993 21:44:36 GMT
From:      ertl@nova.tat.physik.uni-tuebingen.de (Thomas Ertl)
To:        comp.protocols.tcp-ip
Subject:   DNS and 6 Bit subnet mask ?

Our class B network is using a 6 bit subnet mask. Now we like to
establish DNS name service. It seems that I can set up a name server
for the reverse ip-address to hostname resolution only for four
adjacent subnets since I do not know of a way to tell the name server
which subnet mask to use. 
Did I get this right? Is there a workaround / patch?

Thomas Ertl  ertl@tat.physik.uni-tuebingen.de


-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 93 22:11:37 GMT
From:      sen@signet.com (Siddhartha Sen)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <1993Jan28.201534.16358@novell.com> donp@novell.com (don provan) writes:
>
>I'm not sure where you're looking, but from what i can see, in ten
>years we won't even remember OSI.  With all the excitement about the
>growing OSI market, everyone seems to overlook the fact that the
>
	AS for I can see, I do not know what protocol stack we will use ten years from
now BUT it will call itself OSI !!! :-) :-)

>TCP/IP market is growing an order of magnitude faster.  IP doesn't
>have to "take over", since it's the installed based in virtually every
>market that isn't dominated by proprietary networking.  From
>everything i've heard, the only people still interested in OSI are the
>ones that have to deal with painful, government induced network
>monopolies such as the European phone companies.  (I've lost count of
>the number of times i've heard about people that wanted OSI only to
>connect geographically separated *TCP/IP* LANs.)

	Sorry, I must also add ISO/CCITT has excellentlly "standardized" all phy layer
standards. At the real hardware level it is actually OSI (execpt possibly ethernet
- but then TCP/IP is known to be closely linked with ethernet) and acc to u long-haul
nets work out to be OSI. So what you have :- user->TCP->IP->OSI(Phy)->IP(gateway)->OSI
(long-haul)->IP(gateway)->OSI(phy)->IP->TCP->user

	You like it !!!!
>

	- Siddhartha 
-- 
___________________________________________________Siddhartha__Sen______
e-mail: sen@signet.com | FAX: 617-942-082 | SIGMA network systems Inc,
voice : 617-942-0200x136 <--off->| 25 Walkers Brook Dr, READING MA 01867 
voice : 617-942-2193  <-- res --> 5 Lakeview Av, #4, READING MA 01867 

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Feb 1993 23:09:36 GMT
From:      richb@jti.com (Richard Braun)
To:        comp.dcom.lans.misc,comp.sys.ibm.pc.hardware,comp.protocols.tcp-ip
Subject:   Going live on Internet, need some advice

We're about to tie our company into Internet and I'm trying to assess the
current options for making a low-cost physical connection.  We don't have
the budget for a router at the moment, and I need to figure out how to get
the most out of the 56K DDS-2 line we're about to have.

At the other end of the connection is a Cisco router and a t-router from
that vendor.  At this end, we have a few Unix boxes (running on
lowly 386s), a Xyplex server, a Novell server, and a bunch of PCs and Macs.

Would it be simplest to put a CSU/DSU onto one of the 386 boxes and run
routing on that system?  If so, what sort of options do I have in the way
of sync boards and SysVr4 device drivers?  (Would I have to fall back to
async?)

Barring that, another approach is to run the CSU/DSU at 38.4K into the
Xyplex unit.  Is that a reasonable option, if I make sure the CSU/DSU can
function at that speed on its async port?

I've also heard of a special data-compressing WAN bridge from Gandalf which
costs about 3x as much as CSU/DSU units; it requires an Ethernet AUI
connection on each end.  Are there similar options from other vendors
which might get down into the CSU/DSU price range?

Finally, it occurs to me that Novell 3.11 has IP routing built in, and I'm
wondering if it's functional enough to connect right into a CSU/DSU and
run SLIP in an environment like this.

Any hints on this would be much appreciated (even from vendors hawking
their wares).  I'm much too ignorant on this topic, so if you can point me
to some good reading on it that'd be most helpful.

Thanks!
-rich

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Feb 1993 23:19:30 GMT
From:      rustomji@sol.cs.wmich.edu (Eric Rustomji)
To:        comp.protocols.tcp-ip
Subject:   remote startup...

Hi there,

I was wondering if anybody could give me a few tips here.

I need to run a client program, thru a host program, which
connects to a server sitting on one of the workstations.

Following is my code:
execl("/usr/ucb/rsh", "/usr/ucb/rsh", rhost, progname,
cs_server, (char *)0 );

where: rhost -- remote hostname
progname - name of client program
cs_server - name of server (needed as an arg for client)

I guess, it attempts to run the client program, but the rsh
part of it grabs the tty, till the client program exits.

What I need to do:
* Find a way of running a program in the background on a remote 
machine.
* Maybe use rsh thru exec() or the system() call.

I would appreciate if you could give me a few hints etc.
Thanks a bunch!
--
Eric


-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 93 01:07:20 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

In article <31211@castle.ed.ac.uk> ercm20@festival.ed.ac.uk (Sam Wilson) writes:

>In the UK Academic Community we have a very reliable, high speed (2Mbps)
>private X.25 network.  

  Nothing personal, but 2 Mbps ain't "high speed".  My Ethernet is 5
Mbps for real throughput, FDDI is right near 100 Mbps of throughput,
the US IP backbone is at 45 Mbps, and experimental ATM networks are
155 Mbps.  2 Mbps is middlin speed these days.

>  In the last couple of years we have been runnig IP over it for
>pragmatic reasons - it gives us the applications and connectivity that
>people expect.  For the same reasons the successor network, SuperJANET,
>will carry native IP (on SMDS and what are effectively leased 34Mbps
>lines initially, ATM eventually).

  I happen to think the whole world is going multiprotocol.  IPv4 has
a larger installed base and a faster growth rate than ISO, yet for
political reasons ISO isn't going away, and a lot of sites have to
deal with sundry proprietary protocols whether they like it or not
(e.g. SNA, SPX/IPX).

Ran
atkinson@itd.nrl.navy.mil

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Feb 1993 01:11:05 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: DCE COMPLIANT ?

In article <C1w70C.LA@cup.hp.com> dhepner@cup.hp.com (Dan Hepner) writes:
>
>From: emery@goldfinger.mitre.org (David Emery)
>
>>Until adopted by some formal standards-making body, DCE is nothing
>>more than a proprietary interface that happens to be implemented by
>>more than one vendor.  Let's not all jump into the "Open Software
>>Foundation = Open" pit.  OSF "products" are NOT a-priori "Open".
 
>OSF has submitted DCE to X/Open for standardization.  It has not
>as yet been accepted, but it is a hot work item.

Dan,

  READ the posting before you followup.  X/Open is NOT "a formal
standards-making body".  Those are outfits like IEEE, ANSI, and ISO.

  Claims that OSF is anything other than propreitary technology being
pushed by the big 3 members of OSF (HP, IBM, and DEC) are false and
possibly fraudulent.  

  None of this has to do with TCP/IP so followups are redirected.



-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 93 03:14:17 GMT
From:      rypma@waterloo.hp.com (Ted Rypma)
To:        comp.protocols.tcp-ip,comp.unix.misc
Subject:   Re: CSLIP for HP-UX

The Stony Brook Press (sbpress@libws1) wrote:
: I'm looking for a CSLIP server program for an hp-ux system, to connect
: to a macintosh running Macsllip. Is There a P.D. or shareware program
: that will do this,                          ^^^^^^^^^^^^^^^^^

I have never seen or heard of one anywhere.

Ted Rypma
HP Panacom Division
Waterloo, Ontario

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Thu,  4 Feb 1993 12:29:41 -0500
From:      Lyle_Seaman@transarc.com
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in SVR4

Excerpts from netnews.comp.protocols.tcp-ip: 3-Feb-93 Re: TCP/IP in SVR4
don provan@novell.com (643)

> In article <kfPlC670BwxIQ1u48y@transarc.com> Lyle_Seaman@transarc.com writes:
> >On  The  Other  Hand, SPX (well, IPX anyway) was probably nearly the
> >perfect protocol for the initial purposes of NetWare.
 
> On the one hand, i think you might be giving Novell a little too much
> credit.  

What was good about IPX and the NCPs at the time that Drew and crew
started trying to make a distributed filesystem for peecees:
1.  small
2.  fast
3.  reused XNS code, so they didn't have to do it all from scratch (this
is conjecture -- I *hope* they reused the code and didn't reimplement
it!  I gather that most of it has been reimplemented since.)

They were trying to solve a very small problem, and (IMO) did it
reasonably well.  It was a good solution from a business perspective,
though not worth much from an academic perspective.

What's bad about IPX and the NCPs:
1.  they don't scale
2.  they require a rather low delay underlying network for decent
performance (I think we agree that high bandwidth and low delay are
often at odds).
3.  security?  (not an IPX issue, maybe an NCP issue)

These are shortcomings from a *business* perspective as well as from an
academic perspective.  These weren't really issues for the
narrowly-targeted initial problem.

> On the other hand, TCP/IP *still* doesn't have the addressing
> flexibility or the dynamic service location abilities that IPX has.

Perhaps you'd care to elaborate on these features?  I was not aware that
these capabilities were part of the protocol:  rather, I thought they
were glued on the side.   For instance, NetWare servers send out a "HERE
I AM" broadcast periodically, and a NetWare client, when first booted,
will send out a whole bunch of "WHERE IS A SERVER???" broadcasts.   I'm
not sure that it's really part of IPX.

Lyle.

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Thu,  4 Feb 1993 12:40:24 -0500
From:      Lyle_Seaman@transarc.com
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in SVR4

Excerpts from netnews.comp.protocols.tcp-ip: 3-Feb-93 Re: TCP/IP in SVR4
Michael A. Thomas@gordia (1245)


>   From what I've seen, SPX is normally irrelevent to what most people
> consider "Netware". 

I agree completely.  That's probably why it has been neglected so by
Novell. (It is, or was, used by some of the administrative tools). 
Sometimes people have tried to use it to implement services, but the
performance of SPX (because it is so, shall we say, simple) has been
sorely trying.

> The NCP stuff is all based right on top of IPX
> (the network layer) and could trivially be implemented as either
> a seperate protocol layer (like TCP, UDP, ICMP) or even by just
> riding it on top of UDP like NFS does. 
>   This would certainly help the routing brain damage that Netware
> (IPX/RIP) suffers from.

This is what I was hinting at about migration to a more robust protocol.
 The point about routing is a good one, I'd forgotten that.

Lyle.

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Feb 1993 05:13:21 GMT
From:      seetog@cheops.qld.tne.oz.au (Paul O'Keeffe)
To:        comp.protocols.tcp-ip
Subject:   Bugs in tn3270?

We have been using the Berkeley tn3270 on a Pyramid to connect
to an IBM mainframe.  Up till now it has been performing very
respectably.

We have found a couple of problems with tn3270 while using one
particular mainframe application.  We know it is not the
application's problem, since it works when we go via a different
3270 emulation.

The first problem is that it doesn't always erase all the
characters from the previous screen.  The redraw key doesn't
help, so tn3270 must think those characters belong to the new
screen.  It seems that its emulation is not quite there.

The second problem is that it doesn't automatically tab to the
next field after filling up a one character field.

If anyone has any ideas, fixes or similar experiences, I would
be very grateful to hear from them.

Thanks,

Paul O'Keeffe (seetog@cheops.qld.tne.oz.au)
Network Products Information Technology Operations.
Telecom Australia.

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 1993 07:28:06 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Can TCP/IP have backup routes

In article <20496.2b6f9ce5@ul.ie> bourkej@ul.ie writes:
    
    I need to have a bunch of sun workstations on an ethernet witha router and
    a backup router.  If one router goes pop, the other router will have to 
    act as the net's router.
    
No problem.  Pick your solution:

- Use RIP.  Configure RIP on the routers.  Run routed on the Suns.  The
Suns will use the router that's up.

- Use IRDP (Router discovery protocol).  Client software is available on
ftp.cisco.com.  cisco support is in our 9.1 release.

- Use GDP.  This is just a slightly different protocol from IRDP, but is
cisco specific.

Tony

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

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 1993 07:38:58 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.dcom.lans.misc,comp.sys.ibm.pc.hardware,comp.protocols.tcp-ip
Subject:   Re: Going live on Internet, need some advice

In article <C1wB01.5MM@jti.com> richb@jti.com (Richard Braun) writes:

    At the other end of the connection is a Cisco router and a t-router from
    that vendor.  At this end, we have a few Unix boxes (running on
    lowly 386s), a Xyplex server, a Novell server, and a bunch of PCs and Macs.
    
    Would it be simplest to put a CSU/DSU onto one of the 386 boxes and run
    routing on that system?  If so, what sort of options do I have in the way
    of sync boards and SysVr4 device drivers?  (Would I have to fall back to
    async?)
    
Rich,

You don't mention which models are at the far end, but I'm guessing that it
will have only a sync interface on it.  You would need to talk PPP to the
cisco, so you would need that software on your side.

    I've also heard of a special data-compressing WAN bridge from Gandalf which
    costs about 3x as much as CSU/DSU units; it requires an Ethernet AUI
    connection on each end.  Are there similar options from other vendors
    which might get down into the CSU/DSU price range?
    
Our low end routers are down in that price range.  You might check with
your salesman.  We recently reduced prices on the IGS when the 3000 was
announced.

Tony

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

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 93 09:04:59 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer



 >people expect.  For the same reasons the successor network, SuperJANET,
 >will carry native IP (on SMDS and what are effectively leased 34Mbps
 >lines initially, ATM eventually).  It will probably be a multiprotocol
 >network, but exactly how we carry X.25/CONS, CLNP and other protocols is
 >still being studied. 
 
 Sam, 

there's several good reasons x.25 will fade away...

1. errors are low enough in the net to obviate the need for 'reliable
link' 
2. what failures happen are in switching/routing, so end to end
recovery is needed
3. transmission capacity has outdistanced cpu speed so you canna
support too much state inside the switch gear...i.e. per packet is a
no-no

the sooner cons goes away and we go clnp or ipv7 (mebbe same thing)
and any connection-ishness comes from VCI/VPI stuff _below_ link
layer, the better...its the only way the truly global multiservice
internet will work...

 jon

where are we in the IPv7 design space? without much space left to design
it

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Feb 1993 09:53:17 GMT
From:      b130729@hp9000.csc.cuhk.hk (Lam Siu-chung)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Where can I find the Packet drivers for 3c509

Does anyone know where can I find the packet drivers for 3c509

Please return your reply to sclam@cuhk.hk    or
			    chung@rs6000.csc.cuhk.hk

Thanks


Lam siu-chung


-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Feb 1993 11:07:05 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: DCE COMPLIANT ?

In article <C1w70C.LA@cup.hp.com>, dhepner@cup.hp.com (Dan Hepner) writes:

>From: emery@goldfinger.mitre.org (David Emery)
>
>>Until adopted by some formal standards-making body, DCE is nothing
>>more than a proprietary interface that happens to be implemented by
>>more than one vendor.  Let's not all jump into the "Open Software
>>Foundation = Open" pit.  OSF "products" are NOT a-priori "Open".
>>
>>OSF has submitted MOTIF for formal standardization.  When they do the
>>same for DCE, and it passes the (occasional rigorous) review that
>>formal standards go through, then I'll consider it to be "open".  
>
>OSF has submitted DCE to X/Open for standardization.  It has not
>as yet been accepted, but it is a hot work item.

Is "Open" the new term for what used to be called "Standard"?

In the good old days, at least in the OSI-oriented part of the world
(and after all it was OSI that made "Open" a household word in the
datacomm community), an open system was, informally speaking, a
system with an interface to the rest of the world defined solely
by the bit streams coming out of it or being accepted by it. An
open system should not depend on how or by whom the incoming bit
stream is generated, as long as it conforms to standards. And it 
may generate its outgoing bitstream by any means it pleases, as
long as this bitstream conforms to standards.

IS DCE defined that way? I have tried to get some information out
of the DCE environment, but that channel certainly isn't very open...
Sure I've got about a dozen of "white papers" which are essentially
marketing brochures in a technical style - but for "hard" info,
"white paper" is a very descriptive term. 

This marketing info certainly makes it look as if DCE most 
definitely cares about how the bitstream is generated - one of the
main purposes of DCE seems to be to form a *standard programming
environment* for distributed computing (DCE!). The standard 
communication interface looks to me more like a consequence, rather
than a primary goal. So, openness in the classical sense the
way I interpret it, it is not. - Unless they extract the protocol
part of DCE and define the semantics by the protocol alone, 
rather than by the way the protocol is generated.

Could anyone with more info on DCE comment upon this?


-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 93 14:52:22 GMT
From:      thurlow@convex.com (Robert Thurlow)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: DCE COMPLIANT ?

In <1993Feb4.110712.21405W@lumina.edb.tih.no> ketil@edb.tih.no (Ketil Albertsen,TIH) writes:

>This marketing info certainly makes it look as if DCE most 
>definitely cares about how the bitstream is generated - one of the
>main purposes of DCE seems to be to form a *standard programming
>environment* for distributed computing (DCE!). The standard 
>communication interface looks to me more like a consequence, rather
>than a primary goal. So, openness in the classical sense the
>way I interpret it, it is not. - Unless they extract the protocol
>part of DCE and define the semantics by the protocol alone, 
>rather than by the way the protocol is generated.
 
>Could anyone with more info on DCE comment upon this?

OSF is working on a set of documents which will specify both the
APIs used to access DCE services and the over-the-wire protocols.
These documents are known as the AES (Application Environment
Specifications).  As it does so, it will also create a set of
test suites to ensure compliance with the AES.  The Validation
Test Suites (VTS) should be an excellent way to ensure that a
given implementation really does behave in the expected way.
The approach should provide a means to ward off interoperability
problems before implementations are widely installed, which I
think was a significant problem for the OSI protocols.

You're right in saying that the bits-on-the-wire was not the
first thing designed and specified; the APIs were probably there
first.  Without a stable API, though, I think raw protocols are
much less useful.  I think X.400 struggled for some time before
an API was standardized, and that X.500 sufferd less from that
because the API showed up earlier in the life cycle.

Rob T
--
Rob Thurlow, thurlow@convex.com
"Shouldn't I have this, shouldn't I have this, shouldn't I have all of this,
 and, passionate kisses, passionate kisses, passionate kisses, from you?"
- "Passionate Kisses" Lucinda Williams

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 93 16:53:56 GMT
From:      dsc9hmr@bumed10.med.navy.mil (H. Mike Rice)
To:        comp.protocols.tcp-ip
Subject:   CMU's BOOTP on 3B2/SVR3/WIN3B ??


I have just ftp'd CMU's BOOTP and am trying to get a working SVR3 
version on a 3B2.  The code must work on both WIN/3B and CMC's MNP.
I have been able to track down the equiv header files for all but
syslog.h .  The bootpd.c file is riddled with calls to syslog, even
if I remove the -DSYSLOG from the Makefile.  

If anyone has ported this puppy to SVR? and still has their notes 
around, I really would appreciate the help.  If not, I'm going to 
develop a homegrown syslog ....  However, time is critical !!

Thanks in advance !!

-- rice
--
|                    H. Mike Rice    |    elf_______________________
| |  dsc9hmr@bumed10.med.navy.mil    |         Empowerment through
|_|_____    rice@access.digex.com    |             Education !
  |_______                           |______________________________

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Feb 1993 16:58:13 GMT
From:      gibian@talent.ljo.dec.com (Marc S. Gibian)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: DCE COMPLIANT ?


>> In article <thurlow.728837542@convex.convex.com>, thurlow@convex.com
>>(Robert Thurlow) writes:
>> 
>> You're right in saying that the bits-on-the-wire was not the
>> first thing designed and specified; the APIs were probably there
>> first.  Without a stable API, though, I think raw protocols are
>> much less useful.  I think X.400 struggled for some time before
>> an API was standardized, and that X.500 sufferd less from that
>> because the API showed up earlier in the life cycle.

All of the OSI standards had the characteristic of specifying protocol and
not APIs.  This made their acceptance, product implementation, and use far
more difficult than it probably should have been.  I had not known of any
effort to include API specifications in any of the OSI standards.  On the
other hand, a number of organizations (formal and other) have worked to
try to fill this gap through producing their own API standards for various
OSI standards.

Have the OSI standards themselves actually started to address the API issues?
--
Marc S. Gibian			email: gibian@talent.ljo.dec.com
Principal Software Engineer	phone: (508) 486-6598
Digital Equipment Corporation	fax:   (508) 486-6648  or (508) 486-6100

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Feb 1993 17:42:53 GMT
From:      thurlow@convex.com (Robert Thurlow)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: DCE COMPLIANT ?

In <1993Feb4.165813.8872@engage.pko.dec.com> gibian@talent.ljo.dec.com (Marc S. Gibian) writes:

>Have the OSI standards themselves actually started to address the API issues?

No, I don't believe they have awakened to this need yet.

Rob T
--
Rob Thurlow, thurlow@convex.com
"Shouldn't I have this, shouldn't I have this, shouldn't I have all of this,
 and, passionate kisses, passionate kisses, passionate kisses, from you?"
- "Passionate Kisses" Lucinda Williams

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 1993 17:51:59 GMT
From:      ted@larson.corp.hp.com (Ted Larson)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: DCE COMPLIANT ?















-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 93 17:55:44 GMT
From:      peirce@outpost.SF-Bay.org (Michael Peirce)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: Appletalk on PC


In article <1km48tINNca1@tomato.cis.ohio-state.edu> (comp.protocols.appletalk,comp.protocols.tcp-ip), marat@cis.ohio-state.edu (wisebond marat) writes:
> I wonder if anyone on the net knows of Network packages other
> than Tops that will link Macs and MsDos machines using
> appletalk adapters on the PC's.  The best sollution would allow
> the use of current Network capilities of the mac and use some
> kind of software on the PC.

You might want to check out the new offering from Coactive Computing.
They recently announced a cool box called the Connector.  It plugs
into a PC's parallel port and lets the PC participate in a localTalk
based AppleTalk network.  It's bundled with some software that provides
filesharing (AppleShare compatable) and print sharing capabilities.

From what I've seen, they've done a very nice job.  You get the Connector
and the AppleTalk software for $149 SRP.

Coactrive Computing Corp.
1301 Shoreway Road, Suite 221
Belmont CA 94002
(415) 802-1080

--  Michael Peirce      --   peirce@outpost.SF-Bay.org
--  Peirce Software     --   Suite 301, 719 Hibiscus Place
--                      --   San Jose, California USA 95117
--  Makers of:          --   voice: (408) 244-6554 fax: (408) 244-6882
--             Smoothie --   AppleLink: peirce & America Online: AFC Peirce

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Feb 1993 20:15:03 GMT
From:      davew@dslsn1.lampf.lanl.gov (David Whitehouse)
To:        comp.protocols.tcp-ip
Subject:   mbufs not freed

Hello,

I have an data acquisition application running on a silicon graphics 4D/480
which results in a steady increase in the number of mbuffs in use until all
of the network memory is used and then connectivity is lost.  If I log onto
the console and kill the process the network returns to normal. 

The system configuration is as follows:

6 (eventually 14) Motorola MVME 167 monoboards running the VxWorks realtime
operating system send buffers of data to the SGI using Synchronous RPC over UDP.
The Monoboards are attached to 2 separate ethernet segments. All data is sent
to one socket on the SGI. The SGI has 3 ethernet (IP) interfaces, 2 connected 
to the monoboards and one to the rest of the world. The SGI must give the 
monoboards permission to send data, this keeps the UDP buffer from being filled.

The number of mbufs in use grows steadily even if the data rate is adjusted to
be very low.

This application works properly when run on DECstations or when run on
a single processor SGI with only a single IP connections.

Any suggestions would be appreciated.

David Whitehouse

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Feb 1993 21:58:53 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in SVR4

In article <1993Feb3.204312.10233@gordian.com> mike@gordian.com (Michael A. Thomas) writes:
>  From what I've seen, SPX is normally irrelevent to what most people
>consider "Netware".

This is correct.  SPX relates to NetWare in about the same way TCP
relates to NFS (if you'll allow me to ignore the NFS over TCP stuff).

>The NCP stuff is all based right on top of IPX
>(the network layer) and could trivially be implemented as either
>a seperate protocol layer (like TCP, UDP, ICMP) or even by just
>riding it on top of UDP like NFS does. 

Don't i wish.  No, i'm afraid the thing that makes NetWare NetWare is the
Service Advertising Protocol, or SAP.  This is essentially an internet
wide broadcast of *currently* available services.  There's no
straightforward way to map this onto TCP/IP.  DNS is too static, and the
the service location protocols don't include the internet wide
distribution of service information.  Implementing SAP itself on IP might
work, but it would require help from all the IP routers in the net....

Other than that, NCP on UDP is easy.  In fact, RFC1234 describes a way
to run IPX on UDP.  When you think about it, that's not significantly
different technically speaking than running NCP directly on UDP.  The
packet format is only the simplest part of the problem.

						don provan
						donp@novell.com

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 93 22:10:31 GMT
From:      guy@Auspex.COM (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

>The USL SVR4.2 code is a STREAMS-based variant of BSD.

But does it "have rather short and obscure copyright text, not at all
similar to the old, shorter 4.2 BSD copyright legands or the newer 4.3
legands"?  If so, then Somebody should put the BSD copyright notices
back in....

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Feb 1993 22:39:19 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in SVR4

In article <IfQJ_530BwxI01u=sa@transarc.com> Lyle_Seaman@transarc.com writes:
>> On the other hand, TCP/IP *still* doesn't have the addressing
>> flexibility or the dynamic service location abilities that IPX has.
>
>Perhaps you'd care to elaborate on these features?  I was not aware that
>these capabilities were part of the protocol:  rather, I thought they
>were glued on the side.

Address flexibility is built in: 32 bit network numbers, an
inexhaustable supply, and 48 bit node numbers to allow the hardware
address to be used as the node number.  The latter avoids both the
need for an ARP type function and also allows for automatic node
address configuration based on hardware address.

Dynamic service location is SAP.  I was speaking a little loosely when
attributing SAP specifically to IPX, but it is such an integral part
of IPX internets that it has to be supported by all IPX routers.  At
any rate, there's still nothing like it in the TCP/IP suite (although
that's mainly because, as you mentioned, it doesn't scale very well).

						don provan
						donp@novell.com

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Feb 1993 00:12:28 GMT
From:      davew@dslsn1.lampf.lanl.gov (David Whitehouse)
To:        comp.protocols.tcp-ip
Subject:   Re: mbufs not freed

The problem I posted earlier was due to an rpc call being made 
repeatedly with a timeout of zero and no return value. It is now
fixed.

David Whitehouse

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Feb 1993 01:02:24 GMT
From:      dchen@ctp.com (Denys Chen)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: DCE COMPLIANT ?

The subject seems to have gone broader than I expected. It seems to have 
turned into "What is the definition for STANDARD". 

Remember in my original posting, I was asking for some *high level* articulation
on what is "DCE Compliant". I know OSF has (will have) a validation suite. But 
we all know that not eveyone of us has "things" to be submitted to osf for that 
validation. From another more pratical point of view, you want to tell your 
client more than just "the software we're building or are going to use is 
DCE Compliant because it has been validated by osf" (not to say the validation 
suite/process is not available yet). 

Dan Hepner has articultated on that. I'd like to see more on that.

***********   Denys Chen      dchen@ctp.com    1-617-374-8271   ***********
NOTHING IN THIS ARTICLE REPRESENTS VIEWPOINT, OPINION, OR WHATSOEVER OF THE
ORGANIZATION FROM WHICH THIS ARTICLE IS POSTED.



-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Feb 1993 01:03:44 GMT
From:      b130729@hp9000.csc.cuhk.hk (Lam Siu-chung)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Packet driver for Racal InterLan NIC N6610 ?

Where can I find the packet driver for the Racal InterLan network
interface card N6610 ?

Please return your reply to   sclam@cuhk.hk   or
			      chung@rs6000.csc.cuhk.hk


Thanks

Lam Siu-chung


-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 93 01:05:13 GMT
From:      echan@skynet.intel.com (Eldon Chan ~ )
To:        comp.protocols.tcp-ip
Subject:   tcp/ip package on PC


Does anyone have a list of tcp/ip package for PCs ? Has anyone or magazine
done any evaluation/comparision between these packages.

I'll do a summary if I got enough responses.

Thanks

---
Eldon Chan                   
Intel Corporation
Design Technology 
Networking group
echan@scdt.intel.com              

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Feb 1993 09:29:49 GMT
From:      prabowo@research.ptt.nl
To:        comp.protocols.tcp-ip
Subject:   help ? info's hardly needed

Dear all tcp-ip users,

Would someone pleasse help me, by telling where are
the ftp address which i can get any informations
about TCP, UDP, ICMP, IP-RIP, OSPF, IGRP, IP and
SNAP ?.

If it is possible i prefer to receive any replay at
my email address (prabowo@research.ptt.nl).

Thank you all in advance,
Bowo

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Feb 1993 09:36:15 GMT
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Connectivity Question

In article <1kovr8INNjej@BIGBIRD.CF.CS.YALE.EDU>, hubley-robert@cs.yale.edu
 (Robert Hubley) wrote:
>The configuration
>I am proposing is the following (see below).  Does anyone know of any reason
>why this would not work or does anyone know of a better solution involving
>10BaseT connectivity to the remort workstations?

There is at least one problem with the diagram.  The external 10Base-T
transceiver at the bottom cannot connect directly to Port 1 of its
multi-port transceiver because they are both DCE's (provider of
connectivity).

You could however connect this 10Base-T trnasceiver to the "network"
port of the bottom multi-port transceiver.

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

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 93 11:51:00 GMT
From:      john.will@satalink.com (John Will)
To:        comp.protocols.tcp-ip
Subject:   Re: Moving from coax to 1

GJ>No, most certainly not. 10baseT is point-to-point. Which means that you
GJ>have to have a separate connection between the HUB and every apparatus
GJ>in your office. In my case, this would mean that I'd fill more than one
GJ>hub, just for my own equipment!

Yes, but that's it's HUGE advantage!  When you have a cable problem, you
know right where to look!  Find bad connections on a large coax network
can be loads of fun.
---
 . KingQWK 1.05 # 97 . Talk is cheap, because supply exceeds demand!
             

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 93 11:51:00 GMT
From:      john.will@satalink.com (John Will)
To:        comp.protocols.tcp-ip
Subject:   MS-DOS TCP/IP API

I'm about to embark on a project that requires me to connect a number of
IBM-PC boxes to a Sun workstation using TCP/IP and socket connections.
What I'm trying to find is some software for DOS that supports the TCP/IP
protocol and provides an API to minimize the work of creating the network
link.  Any information about such products would be appreciated.

Internet: john.will@satalink.com
---
 . KingQWK 1.05 # 97 . Save the Whales.  Collect the entire set!
                                                    

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 93 11:52:22 GMT
From:      morten@dxcern.cern.ch (Morten Nielsen)
To:        comp.protocols.tcp-ip
Subject:   The listen() call


Hi,

I have a problem using a call to listen. The function should setup the number of connections that may be queued. I want the queue to have the length 0 which I do with the call :

listen (sockfd, 0);

but the server still queues incomming calls, the second incomming call gets connected and the third hangs until some timeout. I was looking for an error message for both the second and the third call.

Where am I wrong ?

Regards,

Morten Nielsen
morten@sunlib.cern.ch

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Feb 1993 12:53:42 GMT
From:      i4cc@aud1.aud.auc.dk (Claus H. Christensen)
To:        comp.protocols.tcp-ip
Subject:   What is a BOOTP server


I am a beginner to TCP/IP network, so if you can help me whith BOOTP, 
please mail to me soon.



-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Feb 1993 13:30:54 GMT
From:      anton@analsyn.gts.org (Anton J Aylward)
To:        comp.protocols.tcp-ip
Subject:   Re: Moving from coax to 10BaseT

In the article (<1993Jan31.230935.25138@unipalm.co.uk>) Ian Phillipps (ian@unipalm.co.uk) posted to comp.protocols.tcp-ip:
: cliffb@cjbsys.bdb.com (cliff bedore) writes:
 
: >In article <19971@mindlink.bc.ca> Frank@mindlink.bc.ca (Frank I. Reiter) writes:
: >>2) What options are available for small (less than a dozen nodes) networks
: >>currently running coax and wanting to move to 10BaseT?  For example, I
: >>understand that 10BaseT topology has all nodes wired to hubs - are there hubs
: >>available which are cost effective for small networks?
 
: >For 1,2,3 or so systems, coax may be just fine but beyond that, you get into
: >the complexities of having to run basically 2 cables to each PC.
 
: Everyone here seems to think that thinnet is the kludgy daisy-chained
: thing you find in development labs.  We have thinnet wired sub-floor
: with neat make-before-break connecters with a twin length of coax out to
: a BNC plug. We just moved almost *everyone* round here, and only had one
: problem, that of one segment that ended up with too many drops on it.
: Fixed with a run of coax from the repeater.

Right! thin-net is most definitely NOT a KLUDGE!
Tenbase-T is a kludge by comparison.  Its there to take advantage of
existing twisked pair (aka phone line) installed in the building which
runs to the wiring closet.   Put your hub in the closet.  Make you newt
a star-wired daisy-chain!

Seriously, thin-net is easy and reliable and very flexible.
The only advantage - other than already installed wiring - of -T over
-10 that really matters is that you can disconnect a single drop from
the hub in a way that makes fault isolation easier.

But then if you had a good design and good tools....

--
Anton J Aylward
	"The body politic is swerving from left to right and right to
	 left looking for quick fixes for systemic problems."
	   - Paul Palango, Journalist, ex The Globe and Mail

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 1993 13:51:43 GMT
From:      Charles Menser <charles@peachnet.edu>
To:        comp.protocols.tcp-ip
Subject:   Is there a DNS TXT record?

Does DNS support a text (TXT) record? How about Sun's
implementation?

I am trying to configure a Telebit Netblazer with many users,
and Telebit is telling me to use a TXT record for passwd file
lookups.

I saw no mention of it in RFC 1034.

Thanks,
Charles
-----
charles@peachnet.edu

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Fri, 05 Feb 1993 14:11:35 GMT
From:      mau@kreutler.de (Hans Mau)
To:        comp.protocols.tcp-ip,de.comp.os.unix
Subject:   Motorola TCP/IP and LANTRONIX Terminalserver

Dear colleagues,
we are experiencing problems transferring data between a PTY(master side)
and a Terminal-Server port via TCP/IP. A cutout of the program being used is
attached below.
The process hangs on writing to the server-port when large amounts
of data are output (rewriting a terminal screen connected to the port) and
small amounts are input (cursor key pushed on the connected terminal).
   What is wrong? (Server-, Unix-host, our software?)
   Somebody have experiences with this kind of problem?
   How can we debug this?
Thanks in advance for any info; please answer by mail, as I only
have write access to this newsgroup.
Hans Mau   mau@kreutler.de

Unix:
   Motorola SYSTEM V/88
   bos R32V3.1 FH32.31 RM04
   nse R32V3.1 NT32.31 RM01
   NSE problem patch tape #2 installed
Terminalserver:
   LANTRONIX ETS-8
   Server Version V2.2/12(920721)
   Flash Rom Version 2.0 (June 1, 1992)
Program Cut-out:
  int server_fd,master_fd;
  fd_set rfd;

  server_fd = socket(AF_INET, SOCK_STREAM, TCP)) < OK)
  setsockopt( server_fd, SOL_SOCKET, SO_LINGER, &ling, sizeof(struct linger))
  setsockopt( server_fd, SOL_SOCKET, SO_KEEPALIVE, &a, sizeof(a))
  connect( server_fd, &srv, sizeof( srv)))

  master_fd = open( master, O_RDWR|O_EXCL) ;
 
  FD_ZERO ( &rfd );
  while (1)
  {
        ...
	FD_SET( server_fd, &rfd );
	FD_SET( master_fd, &rfd );
	nfound = select ( 8, &rfd, NULL, NULL, (struct timeval *)0 );
	if ( FD_ISSET ( master_fd, &rfd ) )
	{       ich = master_fd ;       anderer = server_fd ; }
	else if ( FD_ISSET ( server_fd, &rfd ) )
	{       ich = server_fd ;       anderer = master_fd ; }
	FD_CLR ( ich, &rfd ) ;

	anz = read ( ich , puffer, BUFFSIZE );
	fnr = write ( anderer , bp, anz );
   }

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Feb 1993 15:40:41 GMT
From:      bradley@mdd.comm.mot.com (Michael Bradley)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp/ip package on PC

In article <C1yB0p.Btx@inews.Intel.COM> echan@skynet.intel.com (Eldon Chan ~ ) writes:
>
>Does anyone have a list of tcp/ip package for PCs ? Has anyone or magazine
>done any evaluation/comparision between these packages.
>
>I'll do a summary if I got enough responses.
>
>Thanks
>
>---

October 1992 issue of Network Computing
 "We Review Seven TCP/IP Products for
  DOS and MAC"

  Michael Bradley


-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 93 16:32:05 GMT
From:      dricejb@drilex.dri.mgh.com (Craig Jackson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in SVR4

In article <IfQJ_530BwxI01u=sa@transarc.com> Lyle_Seaman@transarc.com writes:
>Excerpts from netnews.comp.protocols.tcp-ip: 3-Feb-93 Re: TCP/IP in SVR4
>don provan@novell.com (643)
>
>> On the other hand, TCP/IP *still* doesn't have the addressing
>> flexibility or the dynamic service location abilities that IPX has.
>
>Perhaps you'd care to elaborate on these features?  I was not aware that
>these capabilities were part of the protocol:  rather, I thought they
>were glued on the side.   For instance, NetWare servers send out a "HERE
>I AM" broadcast periodically, and a NetWare client, when first booted,
>will send out a whole bunch of "WHERE IS A SERVER???" broadcasts.   I'm
>not sure that it's really part of IPX.

1. Novell's addressing is superior for its application because you don't
have to assign an address to each node.  The node address comes from the
hardware address on the network, which in the case of the two major networking
systems (Ethernet and Token-ring) is unique anyway.  The network address
needs only to be configured into servers.

Note that most of the other successful PC networking systems have this quality.
LAN Manager is sort of an exception, because you have to give each station
a NetBIOS name, I think.

2. Novell's Service Advertising Protocol system is not part of the basic IPX
protocol in the purist sense.  However, it is part of IPX in the fact that
all IPX routers must also provide SAP services.  (Or at least act like they
do.)

Note that while SAP doesn't scale well, it's at least there.  The TCP/IP
world doesn't have one single method for service discovery.  (DNS does part
of the job, but then there are the service discovery portions of things
like DCE.)
-- 
Craig Jackson -- cjackson@mgh.com (Straight Internet)
dricejb@drilex.dri.mgh.com (uucp-forwarded)
{bbn,alliant,redsox}!drilex!{dricej,dricejb}

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Fri, 05 Feb 1993 16:35:09 GMT
From:      jpm@Logix.DE (Jan-Piet Mens)
To:        comp.protocols.tcp-ip,comp.unix.sysv386,biz.sco.general,comp.unix.pc-clone.32bit
Subject:   TCP/IP slowing down on SCO

Hello Netlanders!

I have terrible trouble with a large file server running SCO Unix 3.2.4
and SCO TCP 1.1.3f w/ NFS 1.1.1d.

Telnet, and rlogin work fine, both tested from several clients running
DOS or Unix (incl. other Unices), and seem to perform rather nicely.

NFS, ftp, rcp, etc., all work fine when reading/getting data/files
*from* the server (server->client). But, whenever data is transferred
towards the server (client->server) throughput is between zilch and
approx 10-12KB/second (measured w/ FTP).

I have R all TFM, and don't know where to continue :-(  Our ethernet
adapters are WD8013 Elite Plus (on all sides), we have thin cabling,
and what else do you want to know ? ;-)

I have included streams statistics and `netstat' output as well as a
list of my config variables, below. We have 32MB memory on an i486,
two SCSI disks on AH1542B, and a dumb Hostess adapter w/ 8 serial ports.

Could someone give me a clue on what to look at next ?
Thank you for your help.
	-JP

/etc/conf/cf.d/config.h (munged to save space)
  KDBSYMSIZE          300000	NBUF                     0
  MAXBUF                 600	NCALL                   30
  NINODE                 400	NS5INODE               300
  NFILE                  400	NMOUNT                  12
  CTBUFSIZE              128	NPROC                  150
  NREGION                400	NCLIST                 120
  MAXUP                   30	NOFILES                 60
  NHBUF                  256	NHINODE                128
  NPBUF                   20	DMAABLEBUF              16
  NAUTOUP                 10	NGROUPS                  8
  BDFLUSHR                30	MAXPMEM                  0
  SHLBMAX                  8	FLCKREC                100
  PUTBUFSZ              2000	MAXSLICE               100
  ULIMIT             2097152	SPTMAP                  50
  PIOMAP                  50	PIOMAXSZ                64
  DO387CR3                 0	NODE            "logixwi"
  CMASK                    0	NSHINTR                  8
  NUMXT                    3	NUMSXT                   6
  NCPYRIGHT               10	NKDVTTY                  8
  PRFMAX                3072	MAX_CFGSIZE           1024
  VGA_PLASMA               0	NAHACCB                 36
  SDSKOUT                  4	VHNDFRAC                16
  AGEINTERVAL             31	GPGSLO                  25
  GPGSHI                  40	GPGSMSK               1056
  MAXSC                    1	MAXFC                    1
  MAXUMEM               4096	MINARMEM                25
  MINASMEM                25	MINHIDUSTK               4
  MINUSTKGAP               2	NQUEUE                 450
  NSTREAM                200	NSTRPUSH                 9
  NSTREVENT              256	MAXSEPGCNT               1
  NMUXLINK                87	STRMSGSZ              4096
  STRCTLSZ              1024	NBLK4096                 8
  NBLK2048                32	NBLK1024                32
  NBLK512                 64	NBLK256                256
  NBLK128                256	NBLK64                 256
  NBLK16                 128	NBLK4                  256
  STRLOFRAC               80	STRMEDFRAC              90
  NLOG                     3	NUMSP                   64
  NUMTIM                  32	NUMTRW                  32
  MSGMAP                 100	MSGMAX                2048
  MSGMNB                4096	MSGMNI                  50
  MSGSSZ                   8	MSGTQL                  40
  MSGSEG                1024	SEMMAP                  10
  SEMMNI                  10	SEMMNS                  60
  SEMMNU                  30	SEMMSL                  25
  SEMOPM                  10	SEMUME                  10
  SEMVMX               32767	SEMAEM               16384
  SHMMAX              524288	SHMMIN                   1
  SHMMNI                 100	SHMSEG                   6
  SHMALL                 512	NRCVD                  150
  NSNDD                  100	NSRMOUNT                10
  NADVERTISE              25	MAXGDP                  24
  MINSERVE                 3	MAXSERVE                 6
  NRDUSER                250	RFHEAP                3072
  NLOCAL                   0	NREMOTE                  0
  RCACHETIME              10	RFS_VHIGH                1
  RFS_VLOW                 1	S52KNBUF               100
  S52KNHBUF               32	NMPBUF                   0
  NMPHEADBUF             100	BFREEMIN                 0
  PLOWBUFS                30	NCOPYBUF               100
  S5CACHEENTS            256	S5HASHQS                61
  S5OFBIAS                 8	DSTFLAG                  1
  TBLNK                    0	NSCRN                    0
  NEMAP                   10	TIMEZONE               480
  XSEMMAX                 60	XSDSEGS                 25
  XSDSLOTS                 3	SCRNMEM                  0
  KBTYPE                   0	NDISK                    4
  EVQUEUES                40	EVDEVS                  48
  EVDEVSPERQ               3	NSPTTYS                 48
  DMAEXCL                  0	ETRUNC                   1
  SECLUID                  1	SECSTOPIO                1
  SECCLEARID               1	NAIOPROC                 5
  NAIOREQ                120	NAIOBUF                120
  NAIOHBUF                25	NAIOREQPP              120
  NAIOLOCKTBL             10	EXTRA_NDEV              10
  EXTRA_NEVENT             0	EXTRA_NFILSYS            0
  MAX_BDEV               100	MAX_CDEV               100
  MAXACPUS                 9	NTTYP                   30
  NNFSRNODE              150	SCSI_NAHA                1
  SCSI_NSTP                1	SCSI_NSDSK               2

# crash
dumpfile = /dev/mem, namelist = /unix, outfile = stdout
> strstat
ITEM                  CONFIG   ALLOC    FREE         TOTAL     MAX    FAIL
streams                  200       66     134           373      71       0
queues                   450      284     166           756     304       0
message blocks          1610      195    1415        538051     525       0
data block totals       1288      195    1093        455832     382     262
data block size    4     256        1     255          3858     107       0
data block size   16     128        2     126          2520     102     262
data block size   64     256       63     193        366703     103       0
data block size  128     256       98     158         18884     140       0
data block size  256     256       23     233         21961      32       0
data block size  512      64        8      56         23809      16       0
data block size 1024      32        0      32            71       8       0
data block size 2048      32        0      32         17895      16       0
data block size 4096       8        0       8           131       3       0

Count of scheduled queues:   0

# netstat -i
Name  Mtu   Network      Address            Ipkts Ierrs    Opkts Oerrs  Coll
wdn0  1500  192.109.38   logixwi            49090     0    48286     0     0
lo0   2048  loopback     localhost           4696     0     4696     0     0

# netstat -s
ip:
	53985 total packets received
	0 bad header checksums
	0 with size smaller than minimum
	0 with data size < data length
	0 with header length < data size
	0 with data length < header length
	92 fragments received
	0 fragments dropped (dup or out of space)
	23 fragments dropped after timeout
	0 packets forwarded
	0 packets not forwardable
	0 redirects sent
tcp:
	26886 packets sent
		15874 data packets (1548459 bytes)
		289 data packets (171894 bytes) retransmitted
		10509 ack-only packets (9927 delayed)
		0 URG only packets
		0 window probe packets
		69 window update packets
		145 control packets
	27753 packets received
		15787 acks (for 1615014 bytes)
		147 duplicate acks
		0 acks for unsent data
		12009 packets (453692 bytes) received in-sequence
		64 completely duplicate packets (9966 bytes)
		0 packets with some dup. data (0 bytes duped)
		392 out-of-order packets (339762 bytes)
		0 packets (0 bytes) of data after window
		0 window probes
		7 window update packets
		1 packet received after close
		0 discarded for bad checksums
		0 discarded for bad header offset fields
		0 discarded because packet too short
	51 connection requests
	45 connection accepts
	95 connections established (including accepts)
	177 connections closed (including 1 drop)
	1 embryonic connection dropped
	15588 segments updated rtt (of 15837 attempts)
	246 retransmit timeouts
		0 connections dropped by rexmit timeout
	0 persist timeouts
	1 keepalive timeout
		1 keepalive probe sent
		0 connections dropped by keepalive
	8 connections lingered
		0 linger timers expired
		8 linger timers cancelled
		0 linger timers aborted by signal
udp:
	0 incomplete headers
	0 bad data length fields
	0 bad checksums
-- 
    __  _____   __  __ 
   |  ||  _  \ |  \/  |    Logix GmbH                           +49-611-309797
 __|  ||  ___/ |      |    Moritzstrasse 50                       jpm@Logix.DE 
|_____||__|    |__||__|    D-6200 Wiesbaden  ...!uunet!mcsun!unido!logixwi!jpm

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Feb 1993 16:49:51 GMT
From:      hjb@netcom.com (H. J. Bae)
To:        comp.protocols.tcp-ip
Subject:   Re: mbufs not freed

In article <1993Feb4.201503.17725@newshost.lanl.gov> David Whitehouse writes:

>6 (eventually 14) Motorola MVME 167 monoboards running the VxWorks realtime
>operating system send buffers of data to the SGI using Synchronous RPC over UDP.
>The Monoboards are attached to 2 separate ethernet segments. All data is sent
>to one socket on the SGI. The SGI has 3 ethernet (IP) interfaces, 2 connected 
>to the monoboards and one to the rest of the world. The SGI must give the 
>monoboards permission to send data, this keeps the UDP buffer from being filled.
>The number of mbufs in use grows steadily even if the data rate is adjusted to
>be very low.

i'm not sure what 'SGI must give the monoboards permission to send data'
actually means. some kind of app level protocol being used here?
in any case, VxWorks uses the same BSD derived code as SGI for sockets,
UDP, IP, etc. when the app writes data to a socket and the socket buffer
runs out on the write side, the app task is going to pend (on a socket
buffer semaphore) until more space becomes available (after the network
code sends the data queued up in the socket queue). this socket buffer
is by default set to 2K (as in the original 4.3 BSD tahoe code). the
receive side for UDP socket is by default set to 4K + sizeof(sockaddr_in).
UDP sockets should not be using more data than that on VxWorks. you can 
monitor this by using inetstatShow call from the VxWorks shell on your 
target, which prints out UNIX 'netstat -a' style output. it could be
that your applications are not reading incoming data properly? not sure...
more details please.

the only other thing that i can think of is that MVME167 probably uses the 
LANCE driver, which has been optimized to loan out receive buffers from 
the LANCE receive ring to the protocol code. each time a buffer is filled
in by the chip and sent up to the protocol stack as mbufs, a new mbuf needs
to be allocated to replace the empty slot in the receive ring. the loaned
out mbuf will eventually be freed by the protocol layer when the user 
consumes the received data (by reading it). there might be a bug there.
(although i doubt it. i tested this stuff pretty thoroughly when i did
all that.) when you do something like mbufShow call or print out contents
of mbstat, do you see cluster mbufs being used up?  or are they small mbufs?
probably the clusters... lemme know

love
hwajin
--
Hwa-Jin Bae
Peaceful Star Project
2899 Ford St., Oakland CA 94601	
hjb@netcom.com  (510) 536-7607

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 93 17:35:20 GMT
From:      west@mgmt3.ncsl.nist.gov (Jim West)
To:        comp.protocols.tcp-ip
Subject:   Re: CLNP (Was: Info wanted on TCP/IP vs OSI 7 layer)

In article <1993Jan29.182344.3743W@lumina.edb.tih.no> ketil@edb.tih.no writes:
>In article <8370@dove.nist.gov>, west@mgmt3.ncsl.nist.gov (Jim West) writes:
>
>>What ever happened to IS 8473 -- The Connection-Less Network Protocol (CLNP)?
>>Saying that ISO Network layer is Connection Oriented is incorrect or at
>>least incomplete. 
>
>Let's distinguish between CLNP and CLNS. You can easily build a CO service
>on top on a CL protocol - see eg. a TCP-based socket service, based on the 
>IP protocol.

Fine.  Let me add some definitions also:
	CLNP  -- The Connectionless Network Protocol (defined in IS 8473)
	IP    -- The Internet Protocol (defined in RFC 791)

>Now that we are at IP: Read the introduction to the IP RFC, and see what was

Be careful.  I did read it and it show me you next statement is uninformed

>the originally intended application area for IP: As an *interNET* protocol.
>(The use of IP as an *interHOST* protocol is a comparatively new idea.)

Comparatively new?  How long does something have to be done until it is
no longer _new_.  TCP has been using IP as its network layer as long
as I can remember (I know that NCP was used before IP, but that was
before I entered collage -- oh dear I'm showing my age ;-).

Let me quote RFC791 (INTERNET PROTOCOL)

Section 1.1 : Motivation
   "The internet protocol provides for transmitting blocks of
    data called datagrams from sources to destinations, where
    sources and destinations are hosts identified by fixed
    length addresses"

I think that makes it pretty clear that the intent of IP is to move
packets between hosts (End Systems in OSI terminology).
(That's 1)

I was replying to your comment that OSI is connection oriented.  I
reviewed my original copy of IS 7498 (dated 1984) and you get the
idea the OSI only considered connection oriented networking service.
(But ISO did produce an addendum to 7498 on connectionless services)
But ISO has developed at set of standards that are connectionless
in nature:

   IS 8473  The connectionless network protocol (CLNP)
            (_The_ CNLP, not a clnp.  You seem to confuse the two)

   IS 8602  The connectionless transport protocol (CLTP)

ISO certainly expected 8473 to be used because they also issued:

   IS 8073 Addendum 2 :  Connection Oriented Transport Protocol
                         Class 4 operation over connectionless
                         network service.

The OSI reference model and the protocols coming out of ISO 
didn't agree with each other.  I have a copy of N5092 titled
"Working Draft of Revised ISO 7498-1".  (dated June 1990) Guess what! 
Instead of ignoring the issue of connectionless service, ISO seems to
be changing the refence model.  In addition to the stuff on
a connection oriented transport service, they have

   "section 7.4.4.1 'Transport Connectionless Function'
        (ADI) The Transport Layer provides the following
        functions to support connectionless-mode
        transmission ..."
        <There is a description of the functionality>

(Now it gets worse for those who despise CLNP)

In section 7.5 Network layer:

   "section 7.5.2 Purpose
      (ADI) The Network Layer provides the functional and
      procedural means for connectionless-mode or
      connection- mode transmission among transport-entities
      and, therefore, provides to the transport-entities
      independence of routing and relaying considerations
      associated with connectionless- mode or connection-mode
      transmission"

(Note that 'connectionless-mode' always comes before
 'connection-mode'.  I think ISO is realizing which is
 more important an the network layer :-).

(I believe that ISO has now adopted this document, although
I don't have the most recent copy)

Now don't you think you should get your head out of the sand and
recognize that ISO allows a network layer that provides a
connectionless service, and this service is provided for
by CNLP (_the_ CLNP).

>Although the wording is new, the technical contents is similar in 8473 and
>its associated standards: A multi-hop net connection that spans several nets 
>may use "local" protocols in their respective nets, while the net-to-net
>protocol may be eg. 8473. 
 
>The OSI stack of standard documents is taller than most of us know... MUCH
>more that 7 layers... There is also an "Internal organization of the Network
>layer", IS 8648, describing an architecture for relaying between nets.

I know.  I've read that document.  If ISO had done their job right the
first time and allowed only one type of network service (CO or CL)
8648 would never have had to be written.  Basically, 

>That
>is, NE-to-NE-to-NE-to... where the NEs may be in different nets. But interacting
>at a Net service interface with a TE only at the endpoints.
>
>> The ISO Standards specify a Connectionless service
>>and a Connection Oriented service.  Sure, they don't interoperate, but what
>>does ISO care about interoperability? :-).
>
>You can never hope to get interoperability between a TE using CLNS and another
>TE using CONS, no more than a series of postcards can be received on a phone
>as a stream of spoken sentences, or a telephone conversation as postcards.

Sure you can.  Why don't you check out report# 841 from Norsk Regnesntral
(dated Nov. 1990) (It references a paper I wrote).  Solutions are not
pretty because you have to have some type of relaying functionality at
the Transport layer (which violate the OSI reference model).  If all
transport entities use TP4, then it becomes a little easier.
Also look at ISO TR 10172  (TR = Technical Report)
(That's 2)

>If a NE by using a CLNP is capable of providing a CONS, smile and be happy! 

Why not just use TP4/CLNP and smile and be happy? ;-).
You get the same reliable transport service as TP2/X.25, but
internetworking is a lot easier (you just don't expect a lot
from the network layer).

Jim West

-- 
----------------------------------------------------------------------
In this message I speak only for myself, not necessarily for my employer.
National Institute of Standards and Technology
west@mgmt3.ncsl.nist.gov

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Feb 1993 18:09:49 GMT
From:      cricket@winnie.corp.hp.com (Cricket Liu)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there a DNS TXT record?

In article <1ktrdfINNci7@NS1.PeachNet.EDU>, Charles Menser <charles@peachnet.edu> writes:
|> Does DNS support a text (TXT) record? How about Sun's
|> implementation?

DNS does support TXT records, but early BIND implementations, including
Sun's, don't.  You need the 4.8.3 BIND to do TXT records.  I believe
Solaris 2.X has a 4.8.3-based version of BIND.  So does HP-UX 8.0 and
later.

-- 
cricket

cricket@hp.com / Hewlett-Packard Corporate Network Services / Palo Alto, CA

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Feb 1993 18:14:36 GMT
From:      levinson@halcyon.com (Don Levinson)
To:        comp.protocols.tcp-ip
Subject:   where do I find RARP server software for BSD?

The subject says it all, I want to run a RARP server on my BSD machine but
I need the sources, so where do I find them? I am also looking for BOOTP
server sources.
thank you
-- 
-------------------------------------------------------------------------------
 Don Levinson	  levinson@halcyon.com	| 	Fatigue Technology Inc.
 "Stupid answers for stupid questions"	| 	100 Andover Park West
    ph:206-246-2010 fax:206-244-9886	| 	Seattle, WA 98188

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 1993 20:22:20 GMT
From:      bbehlen@soda.berkeley.edu (Brian Behlendorf (Vitamin B))
To:        comp.sys.sun.misc,comp.protocols.tcp-ip
Subject:   Help!  How do I get rid of these?

	I was running a program on medisg.stanford.edu under SunOS
Release 4.1.1.  It basically was a program which allowed people to
log into a port # and interact with the program (and with each other).
However, when someone logged in from a particular site, the program
froze (but it didn't dump core).  I killed the process, and after
a few minutes tried to re-establish it back onto port 7283 but got a 

bind: port already in use.

I did a netstat | grep 7283 and got:

tcp        0     26  medisg.Stanford..7283  dbootp_exec_25.n.7152  CLOSING

This has remained there since; I tried using close() like the program
does to close the socket but it didn't shut it down.  So I re-established
it on port 7282 and tried it again.  The next day, the very same thing 
happened:

>netstat | grep 7282
tcp        0     69  medisg.Stanford..7282  dbootp_exec_25.n.3295  CLOSING

So now there's TWO of these things here, which are preventing me from
establishing them on either port 7282 or 7283.  The sysadmin is out of
town for a couple weeks;  I was hoping there was something I could do 
to remove those links; it would make sense that I should be able to, since
my program ran setuid to me anyways. 

If you know of any tool I can use to kill those off, let me know.  I
_think_ I know what machine those links are coming from, and I've mailed
root there, to see if they can kill it off from that end...

	Brian

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Feb 1993 22:07:48 GMT
From:      bxv2873@ritvax.isc.rit.edu
To:        comp.protocols.tcp-ip
Subject:   Internet Destop Video Conference Demo From BBN

This is regarding the FTP address you listed to get more info on the destop
conference info.  I try login to get the info but I'm not able to login. 
Access is denied.  I'm interested in obtaining more info on the subject.
Please post me more infor.  Thanks
					Thie 
					(R.I.T - Rochester NY)

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Feb 1993 22:21:08 GMT
From:      bxv2873@ritvax.isc.rit.edu
To:        comp.protocols.tcp-ip
Subject:   Internet Destop Video Conf.

I have question regarding the FTP address you gave up to get more info on
desktop video conference.  I try login several time but not having any 
success.  Access is denied.  I like to get more info on this subject.  I 
sound interesting.  Please supply me with more info.  Thanks,

					Thie
					(R.I.T.  Rochester)

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6 Feb 1993 00:27:22 GMT
From:      mundt@casbah.acns.nwu.edu (John Mundt)
To:        comp.protocls.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   .EDU domain denied to K12 school

I represent a K-8 school in Glenview, IL.  Recently, I applied for
a domain in the .EDU for a consortia of schools in the northern
portion of a collar county of Chicago.  The requested domain name
was to be NCOOK.EDU.  Instead, that request was shunted over to
the geographical domain structure and I was assigned NCOOK.K12.IL.US.

I do not wish to be in the .US domain, prefering the affiliation
by activity.  I was caught off-guard by this, and appealed.  That
appeal was denied, without my having spoken to any of the principals
who made that decision.

My reason for posting this is to gather information and opinion of
those of you one the net.  

   a)  Can an application to a domain be summarily denied?  I thought
       a domain name was to be given to any valid applicant, and I 
       believe that our school district is a valid applicant.

   b)  Who, by name, is actually responsible for assigning or 
       rejecting a name.  My only contact has been to Jon Postel
       who is apparently head of the .US domain and is instrumental
       in arguing for geographical domain naming (RFC1386)

    c)  What is the opinion of those who are in education and already
        have domain assignments in either .EDU or .US?  I will list
        below the reasons I wish my teachers to be assigned to .EDU

    d)  What is the history and future of domain names by affiliation
        and/or by geography.  While I've heard rumblings over the 
        past couple of years, I didn't follow this or other related
        newsgroups, so I need pointers to RFC's relating to the
        topic.

Thanks for your interest and responses.  I shall summarize them as
I receive them.  Below are my reasons for wanting the .EDU name
assignment.

John P. Mundt
Head, Administrative Computing
Glenview School District 34
1401 Greenwood Road
Glenview, IL 60025
(708) 998-5007

mundt@casbah.acns.nwu.edu
mundt@admctr.chi.il.us

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

I wish to introduce my teachers to the Internet in as easy and least
threatening manner as possible.  They are by and large a group without
experience in large computer networks, and except for recent hires,
without any experience with e-mail or the Internet.  Yet with the
NREN bill and other initiatives, they will be participants in the
near future.

E-mail addresses should be simple, mneumonic, and easily promulgated 
to others at conferences, meetings, through list-serves, etc.  The
longer the address, the more it will become an obstacle to the ex-
change of ideas and information.

Placing people in geographical domains forces two more levels of
abstraction onto the name structure.  THis makes things harder to 
remember, harder to type, and more prone to error. One is either

   user@local_domain.edu

or

    user@local_domain.k12.<state>.us

The RFC1386 proposal is to create a name based on thhe school name,
the district, the town, k12, the state, and .US for something like
this for one of my junior high teachers:

   user@springman-jr.district34.glenview.k12.il.us

While I surely could set up an aliasing structure, there would
be many small schools lacking the expertise to do so, forcing
people to use addresses such as the above.  Not good for sharing
names at a state teacher's convention. 

As teachers read about domain naming, they read that in the US,
naming is by affiliation.  They would logically feel that their 
proper affiliation is education.  If they have come from the university
community, they are accustomed to it.  Geographical naming forces
a new paradigm on them.  Not good either.

Finally, geographical naming following the conventions set forth
in the RFC do not allow for regional groupings.  Most of Illinois
school districts do not follow strict township boundaries, so 
our district encompasses parts of Golf and Northfield as well as
Glenview.  The high school district encompasses many towns.  We
function mostly as a group of associated districts so our request of
NCOOK.EDU was meant to swallow  about 10 districts who share common
goals, problems, student demographics, etc.  
-- 
---------------------------------
John Mundt                    mundt@casbah.acns.nwu.edu
Glenview School District 34   mundt@chinet.chi.il.us
(And coming real soon now...  mundt@ncook.k12.il.us)

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 93 01:31:42 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.org.usenix,comp.protocols.tcp-ip,comp.unix.ultrix,comp.dcom.lans.fddi
Subject:   TCP/IP Throughput Enhancement Software and Paper Available


	This note is to announce availability of some TCP/IP
throughput enhancement software and a paper about that software.  A
paper by myself and Joseph Pasquale appeared at the Winter '93 Usenix
on some network throughput enhancement work.  The paper promised that
the performance enhancements described would be made available.  This
is that promised release.  The meat of the work was a two enhancements
to the checksum algorithms used by TCP/IP: a new checksum elimination
algorithm and an optimization of the MIPS processor checksum routine.
The paper also contains measurements and analysis for processing
UDP/IP packets sent over FDDI.  Both the paper and checksum
enhancement software are available for anonymous FTP from ucsd.edu in
the pub/csl/fastnet directory.  The software is for a DECstation
Ultrix 4.2a kernel, but should be portable to some degree (the RISC
checksum to any MIPS-based machine, the checksum elimination algorithm
to any Berkeley Unix based network subsystem).
	The software includes a performance enhancement not described in the
paper.  The MTU reported by the FDDI driver to higher network layers has been
reduced from the real FDDI MTU of 4352 bytes to 4096.  This change is made
because of an effect seen in the measurements.  The paper includes some
graphs on total CPU time necessary to process (send and receive) packets of
various lengths.  Those graphs show upward spikes in packet sizes between 1
and 1024 bytes, and between 4097 and 5120 bytes.  That is because many small
mbufs are allocated to hold data in those ranges as opposed to one or two
large mbufs, and there is a per-mbuf computation time penalty .  Reducing the
FDDI driver's if_mtu to 4096 avoids those spikes, raising performance.
	The patches in this distribution significantly improve throughput.
They raise TCP throughput on an old DECstation 5000/200 from 2.1
megabytes/sec (MB/s) to 3.2 MB/s.  UDP throughput rises from 2.4 MB/s
to 4.6 MB/s.
	As a warning, the checksum elimination algorithm is experimental.  I
am currently taking empirical data to try and back up the reasoning behind
the algorithm, but it will be a few months before the results are in.
Certainly the algorithm does not have IETF approval of any kind.  The
RISC checksum optimization, on the other hand, is entirely within IETF rules
and has been tested for several workstation-years.
	If you do anything with the software, or have comments on the
checksum elimination algorithm, I would be interested in hearing about it
(our addresses may be found at the bottom).
	UCSD Computer System Lab research into high performance
networking is continuing.  This distribution will be updated in the
future as more enhancements are developed (or the inevitable bugs are
found).

There are several files in the distribution:

README - this note
DOC - documentation
BUFFERS - optimal I/O buffer size considerations
usenixw93.ps - the Usenix paper
csum_patches - patches to Ultrix 4.2a source code implementing the
		improvements. 
locore_patch - patch to Ultrix 4.2a MIPS /sys/machine/mips/locore.o
		(in BINARY distribution!) implementing RISC checksum.
BINARY.4_2a - directory of object files implementing both improvements.
BINARY.4_2a/tcp_usrreq.o
BINARY.4_2a/tcp_output.o
BINARY.4_2a/tcp_input.o
BINARY.4_2a/udp_usrreq.o
BINARY.4_2a/udp_usrreq.o

How to Install This Software:

From BINARY distribution:

	Copy in the object files in BINARY except locore.o into
/sys/MIPS/BINARY, being sure to first move old versions aside.  Now,
since locore.o is typically recompiled whenever you reconfigure your
kernel (even from binary distribution!), you have to patch your locore.s
using the patch in locore_patch. 
	The next step is to reconfigure your kernel.  Use the same kernel
configuration file (in /sys/conf/mips) as you already use EXCEPT you
need to specify which checksum improvement algorithm, if any, you wish
to use.  This is done by adding an option to the kernel configuration file:

options		SEQUOIA_FASTNET      # faster networking

Then follow normal procedures for building a kernel.
	Note: the object files are compiled in such a way that all the
improvements, even the experimental checksum elimination algorithm, are
enabled.  It is, however, possible to set things up so that you only use the
RISC checksum (more than halving the benefit of this package).  Since the
RISC checksum is completely contained in locore.s, and no other enhancements
are in there, one could only install that patch and avoid installing any of
the object files.

	Oh, yeah: what happens if you aren't running Ultrix 4.2a?  Good
question.  This stuff will PROBABLY work with other Ultrix releases
since the TCP/IP code doesn't seem to change much from release to
release, but then again it might not work.  I would be interested in
hearing if you try it out and it doesn't work - maybe some arrangements 
can be made.

From source distribution:

	Make the patches to your source code, using the csum_patches file.
If you aren't using Ultrix 4.2a source code, you may want to put in the
patches by hand.  Then build your kernel normally.

	Next step is to reconfigure your kernel.  Use the same kernel
configuration file (in /sys/conf/mips) as you already use EXCEPT you
need to specify which checksum improvement algorithm, if any, you wish
to use.  You do this by adding an option to your kernel.  There are
four options (if you specify none, you get a "normal" kernel): 

options		SEQUIOA_FASTNET      # all nifty new algorithms in one option
options		SEQUIOA_FASTSUM      # just RISC checksum
options		SEQUIOA_NOSUM        # just checksum elimination
options		SEQUOIA_NOSMALLBUFS  # just if_mtu reduction to 4k

(the SEQUOIA_ prefix is to ensure that names of kernel enhancements from the
Sequioa 2000 project don't run afoul of other options invented
elsewhere).  You can mix and match those options, but SEQUOIA_FASTNET
will save you time.


Usenix Paper:

Here are the title and abstract of the Usenix paper:


		    Measurement, Analysis, and Improvement of 
		    UDP/IP Throughput for the DECstation 5000

Abstract

Networking software is a growing bottleneck in modern workstations, particularly for
high throughput applications such as networked digital video. We measure various
components of the UDP/IP protocol stack in a DECstation 5000/200 running Ultrix 4.2a,
and quantify the way in which checksumming and copying dominate the processing time
for high throughput applications.  This paper describes network software measurements
and substantial performance improvements which derive from a faster checksum
implementation.


Addresses:

	Jonathan Kay			Professor Joseph Pasquale
	jkay@ucsd.edu			pasquale@ucsd.edu

	Department of Computer Science and Engineering
	University of California, San Diego
	La Jolla, CA 92093-0114

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6 Feb 1993 01:49:03 GMT
From:      dfish@dante.nmsu.edu (FISH)
To:        comp.protocols.tcp-ip
Subject:   emulation


     We are using NCSA Telnet in order to connect our IBM PC's to a
network. We would like to expand the capabilities that we have without
the expense.  Specifically we would like to be able to emulate one of
these graphics
screens.  I know that there are commercial products, however none that
I have seen are:
1) reasonably priced
2) compatible with NCSA.

     I talked with our computer center and several people suggested
putting a request in the news groups. Please if you have information
on products that will allow us to emulate one of the below listed
terminals using a network card send the information to me at
dfish@nmsu.edu.  Thank you.

terminal_types:
 VT640          (1)
 VT241  ------- (2)
 CIT467         (3)
 TK4010 ------- (4)
 TK4107         (5)
 PT100G ------- (6)
 SEIKO          (7)
 VS11   ------- (8)
 GENERIC        (9)
 CVAXSTATION - (10)
 MVAXSTATION   (11)
 DECWINDOWS -- (12)

Thank you again. 
Dan Fish


-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6 Feb 1993 04:15:52 GMT
From:      matt@wardsgi.med.yale.edu (Matt Healy)
To:        comp.protocols.tcp-ip
Subject:   Re: If you run 2+ nets on 1 wire, please read

In article <1kjgstINNqfi@inferno>, dana@inferno.UUCP (Dana) wrote:
> 
> The Shownet at Interop runs  Novell, Appletalk,
 tcp/ip, OSI/GOSIP, SNA and a few others. I believe all
> protocols are present at once on the FDDI backbone.
 They also run Ethernet and token ring on the shownet,
> but those are for the ribs only -- the backbone is 
 strictly FDDI.  Certainly there were folks talking
> tcp/ip on the same ethernet as appletalk, because 
 there were booths with Suns in the same aisle as
> the Apple booth.
> 

[PLEASE KEEP YOUR LINES UNDER 80 CHARACTERS!]

To clarify a bit:

AppleTalk and TCP/IP are protocols; Ethernet and
FDDI are hardware media over which these and
other protocols can run.  On the Macintosh I
am now using, two different drivers are active:
MacTCP to support TCP/IP connections, and
EtherTalk to support AppleTalk connections.

Right now I am using both services: AppleTalk
to mount our AppleShare file server and TCP/IP
to use NewsWatcher and Telnet.  At this moment
I am logged in via Telnet to a Unix system
from which I send email, and logged in via NNTP
to the campus Usenet news server.  All this is
done without problems from one Ethernet connection.

On the same wire my packet analyzer also finds
packets for DECnet and Novell IPX, which this
computer just ignores.  There is no problem
with various protocols sharing a wire so long
as total traffic is not excessive.

Matt Healy
"I pretend to be a network administrator;
 the lab net pretends to work"

matt@wardsgi.med.yale.edu

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6 Feb 1993 05:21:13 GMT
From:      guay@fraser.sfu.ca (Tim Guay)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Where can I find the Packet drivers for 3c509

In article <1993Feb4.095317.10736@hp9000.csc.cuhk.hk> b130729@hp9000.csc.cuhk.hk (Lam Siu-chung) writes:
>Does anyone know where can I find the packet drivers for 3c509
>
>Please return your reply to sclam@cuhk.hk    or
>			    chung@rs6000.csc.cuhk.hk

I'd like to know to, so can someone post this to the net...Please.



-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6 Feb 1993 06:37:28 GMT
From:      sbardhan@uncc.edu (Soumendu Bardhan)
To:        comp.protocols.tcp-ip
Subject:   Thesis Topic

Dear Sirs,
          I want to learn about TCP/IP and more about UNIX , client-server paradigm. 
If someone please suggests me some  topic  that could be taken up as
a thesis , I will be very grateful.

I would appreciate if you could comment on these topics too :
Writing --Remote Login, --ftp
Thanks
--Soumendu





-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6 Feb 1993 11:23:52 GMT
From:      doswangx@nuscc.nus.sg (Wang Xi (Ms))
To:        comp.protocols.tcp-ip
Subject:   Bootp of PCTCP for DOS

[ Article crossposted from comp.dcom.lans ]
[ Author was Wang Xi (Ms) ]
[ Posted on Sat, 6 Feb 1993 11:16:02 GMT ]


Hi, everybody

When I am trying to make use of BOOTP of PCTCP, I found that bootp is able
to get ip address from bootp server successfully within the same subnet.
But I can not make it work if there is router in between bootp client and
bootp server. Any body have ideas to make bootp works even there are routers
in between bootp clients and bootp servers ?

Thank you in advance!

Esther.X.Wang


Internet: doswangx@nuscc.nus.sg


-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 1993 15:25:50 GMT
From:      HSTAMS@cipvax.biolan.Uni-Koeln.DE (Henning Stams)
To:        comp.protocols.tcp-ip
Subject:   Re: What is a BOOTP server

>
>I am a beginner to TCP/IP network, so if you can help me whith BOOTP, 
>please mail to me soon.
>
A bootp server satisfies bootp-requests of clients.
The clinet sends its ethernet-address and gets back stuff like the following:
* IP-Address of that client
* Gateway address for the client
* Netmask
* Address of Domain Name Server
* Address of Time Server

An "cheap" alternative for bootp is rarp (reverse address resolution 
protocol), where the client only receives its IP-Address by sending its 
ethernet-address.

Hope that helps.

Henning (hstams@biolan.uni-koeln.de)

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 1993 15:28:10 GMT
From:      HSTAMS@cipvax.biolan.Uni-Koeln.DE (Henning Stams)
To:        comp.protocols.tcp-ip
Subject:   Re: What is a BOOTP server

In article <HSTAMS.4.0@cipvax.biolan.Uni-Koeln.DE> HSTAMS@cipvax.biolan.Uni-Koeln.DE (Henning Stams) writes:
>From: HSTAMS@cipvax.biolan.Uni-Koeln.DE (Henning Stams)
>Subject: Re: What is a BOOTP server
>Date: 6 Feb 1993 15:25:50 GMT
>>
>>I am a beginner to TCP/IP network, so if you can help me whith BOOTP, 
>>please mail to me soon.
>>
>A bootp server satisfies bootp-requests of clients.
>The clinet sends its ethernet-address and gets back stuff like the following:
>* IP-Address of that client
>* Gateway address for the client
>* Netmask
>* Address of Domain Name Server
>* Address of Time Server
>
>An "cheap" alternative for bootp is rarp (reverse address resolution 
>protocol), where the client only receives its IP-Address by sending its 
>ethernet-address.
>
>Hope that helps.
>
>Henning (hstams@biolan.uni-koeln.de)
I forgot to say that a bootup-file may also be transmitted upon a bootp-
request.

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 1993 20:46:42 GMT
From:      roy@mchip00.med.nyu.edu (Roy Smith)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: DCE COMPLIANT ? (somewhat long)

mjr@tis.com (Marcus J Ranum) writes:
> I used to work for a large vendor and often had cause to sit and think "is
> this stuff we are calling 'open' and 'standard' REALLY helping solve the
> customer's problems, or is it REALLY just another way of selling software
> that will lock them into our platform?"

	You mean like Open/VMS?  When I first heard that, I didn't know
whether to laugh or cry.  The day that I can ftp a freeware VMS clone that I
can run on a collection of random 386 hardware, I'll believe VMS and Open
belong in the same paragraph, let alone in the same product name.

	Don't get me wrong, not being "Open" does not by itself condem a
product.  The Macintosh hardware and system software is about as far as you
can get from being Open in the sense of "freely copyable" (and with the
recent changes in system software upgrade policies getting even further),
yet I'm a Macintosh fanatic.  The difference is that the Mac is such a far
superior environment (at least for some tasks and people) that it's worth
putting up with the non-open-ness.
-- 
Roy Smith <roy@nyu.edu>
Hippocrates Project, Department of Microbiology, Coles 202
NYU School of Medicine, 550 First Avenue, New York, NY 10016
"This never happened to Bart Simpson."

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Sun,  7 Feb 1993 13:01:16 -0500
From:      Lyle_Seaman@transarc.com
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in SVR4

Excerpts from netnews.comp.protocols.tcp-ip: 7-Feb-93 Re: TCP/IP in SVR4
Perry Hutchison@marie.uu (669)

> In <51792@drilex.dri.mgh.com> dricejb@drilex.dri.mgh.com (Craig Jackson)
> writes:
 
> + 1. Novell's addressing is superior for its application because you don't
> + have to assign an address to each node.  The node address comes from the
> + hardware address on the network, which in the case of the two major
> + networking systems (Ethernet and Token-ring) is unique anyway ...

This is also true of XNS (Xerox Network Services), I believe.

IPX/SPX  is a very stripped-down XNS.  FWIW, Banyan's VINES "Network
Operating System" protocols are much closer (identical?) to Grey Book
XNS.


Lyle		Transarc		707 Grant Street
412 338 4474	The Gulf Tower		Pittsburgh 15219

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Sun,  7 Feb 1993 13:04:56 -0500
From:      Lyle_Seaman@transarc.com
To:        comp.protocols.tcp-ip
Subject:   Re: If you run 2+ nets on 1 wire, please read

Excerpts from netnews.comp.protocols.tcp-ip: 6-Feb-93 Re: If you run 2+
nets on 1.. Matt Healy@wardsgi.med.y (1517)

> There is no problem
> with various protocols sharing a wire so long
> as total traffic is not excessive.

This is not neccessarily true.  The protocols must have at least a
*basic* compatibility, at the (so-named) Data Link layer -- the first
layer of protocol based on the physical medium.

Most of the common protocols in use are compatible to that level,
however, a few of them are not.

Lyle		Transarc		707 Grant Street
412 338 4474	The Gulf Tower		Pittsburgh 15219

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 93 08:55:43 GMT
From:      perryh@marie.uucp (Perry Hutchison)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in SVR4

In <51792@drilex.dri.mgh.com> dricejb@drilex.dri.mgh.com (Craig Jackson) writes:

+ 1. Novell's addressing is superior for its application because you don't
+ have to assign an address to each node.  The node address comes from the
+ hardware address on the network, which in the case of the two major
+ networking systems (Ethernet and Token-ring) is unique anyway ...

This is also true of XNS (Xerox Network Services), I believe.

---
perryh%marie@pdxgate.cs.pdx.edu  ("should" work)
marie!perryh@pdxgate.cs.pdx.edu  (if above bounces)
Guest account -- not affiliated with St. Mary's Academy.
If you post a reply to this, please mail also as the feed here is lossy.

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 93 10:14:30 GMT
From:      Lyle_Seaman@transarc.com
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in SVR4

Excerpts from netnews.comp.protocols.tcp-ip: 7-Feb-93 Re: TCP/IP in SVR4
Perry Hutchison@marie.uu (669)

> In <51792@drilex.dri.mgh.com> dricejb@drilex.dri.mgh.com (Craig Jackson)
> writes:
 
> + 1. Novell's addressing is superior for its application because you don't
> + have to assign an address to each node.  The node address comes from the
> + hardware address on the network, which in the case of the two major
> + networking systems (Ethernet and Token-ring) is unique anyway ...
 
>This is also true of XNS (Xerox Network Services), I believe.

IPX/SPX  is a very stripped-down XNS.  FWIW, Banyan's VINES "Network
Operating System" protocols are much closer (identical?) to Grey Book
XNS.

Lyle		Transarc		707 Grant Street
412 338 4474	The Gulf Tower		Pittsburgh 15219

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 93 19:20:04 GMT
From:      sobi0268@mary.cs.fredonia.edu (Kevin V. Sobilo)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP in Ada???

I asked a question a week or so ago about if there was a package that
would allow TCP/IP programming in Ada. I got a response of a PD
package that will allow me to do so... However it requires me
to have a Alsys Compiler to use it... Does anyone know where I
can get an Alsys Compiler.. Ive never heard of it... I use the
NYU ada-ed....

Also are there any COMMERCIAL packages that would allow the same...
This is reaseatch for a class Im taking so any info you can give
me is appreciated.

Thanx for all responses in advance...



				Kevin V. Sobilo
			sobi0268@mary.cs.fredonia.edu

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 1993 10:09 MST
From:      einhorn_d@apsicc.aps.edu (E. Drew Einhorn)
To:        comp.protocols.tcp-ip
Subject:   How to unbind from an internet address/port?

I am a first time socket user.  How do I clear a binding.
Tried having my server close the fd for the bound socket it was
listening to and that does not appear to work.  Tis possible a
bug in my code is preventing the close from being executed but
I don't think so.  Is there something else I should be doing?

Assuming I figure out the correct technique for unbinding when the
server shuts down.  

Is there a utility
that can release a binding after a buggy server has crashed and
burned without cleaning up after itself.  If all else fails I can
reboot the system, but I am hoping for something less drastic.

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Feb 1993 06:57:46 GMT
From:      tanner@csunix (root@insight)
To:        comp.protocols.tcp-ip
Subject:   Network Programming?

Is this the correct newsgroup to post network programming questions?

I have tried the *.programmer groups, but they are to general. If this
is not the correct group, can you please direct me to a group more
suited to what I am looking for. Thanks.



-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Feb 1993 07:43:52 GMT
From:      ccewch@nuscc.nus.sg (Wong Chee Heng)
To:        comp.protocols.tcp-ip
Subject:   Ethernet ARP vs Token Ring ARP???


I know that when running TCP/IP on the Ethernet, the 48-bit Ethenet address 
mapping between and the 32-bit IP address is using a protocol called ARP
and it is specified in RFC826. But what about Token Ring? Is the same 
protocol used without modification? OR is there a RFC for it? I could not
find such RFC in the index.

Can someone pls enlightnen me. Thank you.


--
Wong Chee Heng
Systems Programmer
ccewch@nuscc.nus.sg.

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 93 08:00:15 GMT
From:      johng@informix.com (John Galloway)
To:        comp.protocols.tcp-ip
Subject:   broadcasting and Subnetting, And multiple Nets on one ether?

Two questions:
1) If using subnet addressing to divide a single net IP addr into multiple
    physical nets, what happens with broadcasting?  Are broadcast
    packets restricted to their source subnet  or do they propogate?

1a) If using IGCMP I assume this isn't an issues since there is an
    explicit list of multicast members, true?  and is IGCMP widely
    implemented?

2) Is there any functional reason that multiple Net IP addres can not
    exist on the same physical net? Its not as efficeint as if datagrams
    can be restriced to only those hosts that are really on the target net,
    but does it work? (the case I was thinking of was if you are (stuck
    with) using bridges to connect multiple physical nets, that for
    administrative purposes want to have their own Net addrs, then the
    common ethernet that they are all bridged too, has this setup).

ok I lied, 3 questions!  thanks.
	-jrg
internet    jrg@galloway.sj.ca.us  John R. Galloway, Jr  795 Beaver Creek Way
internet    johng@informix.com     CEO...receptionist    San Jose, CA   95133
applelink   D3413                  Galloway Research     (408) 259-2490
-- 
internet    jrg@galloway.sj.ca.us  John R. Galloway, Jr  795 Beaver Creek Way
internet    johng@informix.com     CEO...receptionist    San Jose, CA   95133
applelink   D3413                  Galloway Research     (408) 259-2490

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 93 12:32:06 GMT
From:      ercm20@festival.ed.ac.uk (Sam Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: Info wanted on TCP/IP vs OSI 7 layer

atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
> In article <31211@castle.ed.ac.uk> ercm20@festival.ed.ac.uk (Sam Wilson) writes:
> 
> >In the UK Academic Community we have a very reliable, high speed (2Mbps)
> >private X.25 network.  
> 
>   Nothing personal, but 2 Mbps ain't "high speed".  My Ethernet is 5
> Mbps for real throughput, FDDI is right near 100 Mbps of throughput,
> the US IP backbone is at 45 Mbps, and experimental ATM networks are
> 155 Mbps.  2 Mbps is middlin speed these days.

Oh, certainly.  It *was* high speed when it was put in (considering the
US backbone was then at 1.5Mbps, which shows how we are in a sense still
at the mercy of the standards-making bodies - we used to have 2Mbps
compared to your 1.5Mbps and now we're planning 34Mbps as against your
45Mbps, sigh) but I agree that it has been well overtaken now.  That
said, there certainly used to be a significant fraction of the
networking world who thought that it was technically impossible to run
X.25 at over 64Kbps and I just like to dispel this particular myth
whenever I get the chance! :-)  Trivia, I know.  

As Jon Crowcroft recently pointed out, X.25 is unlikely to be able to
compete at the higher speeds because of the large demands it makes on
switches compared to connectionless and fast packet/cell switching. 

>   I happen to think the whole world is going multiprotocol.  IPv4 has
> a larger installed base and a faster growth rate than ISO, yet for
> political reasons ISO isn't going away, and a lot of sites have to
> deal with sundry proprietary protocols whether they like it or not
> (e.g. SNA, SPX/IPX).

Certainly.  Unfortunately some of the protocol suites (AppleTalk and
Novell spring to mind) aren't particularly well designed for global
scale nets, which rather leaves us with the IP and the different
varieties of OSI as the likely market leaders for off-site connectivity. 


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

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 93 12:58:56 GMT
From:      yvan@estwm0.wm.estec.esa.nl
To:        comp.protocols.tcp-ip
Subject:   FTP anonymous server code for VMS


Hi

could someone tell me where I could find the source code for an FTP anonymous
 server running under VMS 5.**.
Thank you for your help

Ivan

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 93 13:01:00 GMT
From:      viau@wm.estec.esa.nl (Pierre "play-soccer-not-football" Viau)
To:        comp.protocols.tcp-ip
Subject:   REQUEST: anonymous FTP server code for VMS


Can somebody tell where I can find the source of an FTP anonymous server for VMS ?

Thanks in advance

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 93 13:43:20 GMT
From:      tony@scotty.dccs.upenn.edu (Anthony Olejnik)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Assignment of IP address across multiple subnets (bootp?)


I have some portable machines which have a need to be moved quite
frequently among our campus subnets.  Normally, the machines are
stationary and are assigned static IP address.

Q: Is there a way to dynamically assign IP address to thes machines
   *ACROSS* subnets boundaries?

I know I can use BOOTP to assign IP addresses from within a subnet.
However, it is my understanding that I can`t use BOOTP across subnets.

What I`d really like to do is set up a *SINGLE* BOOTP-like server on
a given subnet.  Then, depending on which subnet the machine is
requesting from, the BOOTP-like server will assign the appropriate
IP address for that subnet.  My though is that there will be multiple
IP address (a unique one for each subnet) reserved for *each* of the
dynamic machines.

My fall back solution would be to maintain a BOOTP server on each
and every subnet (which I personally don`t want to do).

Any help would be greatly appreciated.
Thanks in advance.

--tony


-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Feb 93 15:48:11 GMT
From:      braun@dri.com (Kral)
To:        comp.protocols.tcp-ip
Subject:   Re: Moving from coax to 10BaseT

In article <19971@mindlink.bc.ca> Frank@mindlink.bc.ca (Frank I. Reiter) writes:
>In a recent column in OST James Gaskin suggests that system administrators
>should be converting ethernets from coax to 10BaseT and *not* investing
>anything more in coax.  I put two questions to the readers of this group:
>
>1) Do you concur with Mr. Gaskin that coax is dead or dying?
>
>2) What options are available for small (less than a dozen nodes) networks
>currently running coax and wanting to move to 10BaseT?  For example, I
>understand that 10BaseT topology has all nodes wired to hubs - are there hubs
>available which are cost effective for small networks?
>
>I look forward to your replies...

The previous poster makes a good point: it really depends on the
number of nodes you are going to install.  It also depends on the
permanence of the nodes.

If, for example, you are building a small lab, particularly one that 
will not last long (at least, in its present physical configuration),
you probably want to go with thinnet, just because of the cost.

However, if you are putting in a large installation in a relatively
permanent configuration (eg: an office environment), you are much
better off going with 10baseT for the following reasons:

1)	Trouble shooting is much easier.

2)	If a physical problem occurs on a station, it is less likely
	to take down the whole segment.  Furthermore, if you invest in
	an intelligent hub with management capabilities, the bad port
	can be quickly isolated either automatically or manually.

3)	Cabling can be more easily strung and well concealed (which is
	both an esthetic consideration and also improves reliability
	as cables are less likely to be stepped on, stretched, bent,
	etc.

4)	If you string level 5 cabling (expensive, but possibly worth
	it) you will be set for many years, as you will be able to run
	CDDI, ATM, 100baseT, or whatever the next version of common
	network protocols are: whatever it is, you can bet there will
	be a twisted pair version of it, and for speeds over 10Mbits,
	you will be better off with level 5.

Finally, if the budget permits, it is best to run 2-4 twisted pair
cables to each station.  This costs a lot more up front, but saves a
lot of money over the long term as you now have spare ports for
replacing bad cables, adding addition connections (without buying a
repeater for each station), and providing access to more than one
network for each station.

-- 
kral   408/645-2031                                                braun@dri.com
Network Scapegoat in Training                                      Novell/DSG
That's the whole problem with science.  You've got a bunch of empiricists 
trying to describe things of unimaginable wonder." - Calvin

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Feb 1993 17:07:14 GMT
From:      jrmassi@col400.att.com (Joseph R. Massi)
To:        comp.protocols.tcp-ip
Subject:   File Transfer Utilities

We are looking for a tcp or udp based file transfer utility which will
do all or some of the following:
	
	transfer files on a scheduled basis (e.g. at night)
	provide for restarts if file transfer is interrupted
	provides log statistics and audit information
	provides some level of access control.

Any ideas or pointers would be appreciated.

Mark Kusiak
(301) 369-4813
kusiak@col400.att.com
--
joe.
/* I'm not speaking for AT&T, and AT&T isn't speaking for me */
Joe Massi 			j_r_massi@att.com or att!col400!jrmassi
AT&T Bell Laboratories		(301) 369-7780
Columbia, MD			packet radio: kb2jg@w3iwi.md.usa.noam


-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 93 17:55:26 GMT
From:      SUSANMC@nervm.nerdc.ufl.edu (Susan McIntosh)
To:        comp.protocols.tcp-ip
Subject:   Sources for network training

Forgive me if there's a better place to post a question of this sort...
 
I and several co-workers are looking for good sources for network
training, topics such as OSI layers, bridges, routers, network monitoring
and optimization, etc.  We are aware of several vendor classes that may
be good, but wondered if anyone had any experience with third-party training.
We'd appreciate any info :-)
 
please email ...
 
susan mcintosh                                Northeast Regional Data Center
susanmc@nervm.nerdc.ufl.edu                   University of Florida

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Feb 1993 19:07:00 GMT
From:      erick@demorgan.uwaterloo.ca (Erick Engelke)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: DCE COMPLIANT ? (somewhat long)

 mjr@tis.com (Marcus J Ranum) writes:
>ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
>
>>In the good old days, at least in the OSI-oriented part of the world
>>(and after all it was OSI that made "Open" a household word in the
>>datacomm community), an open system was...
>
>	This is a mighty narrow definition of an "open system" and I
>think a lot of folks would disagree with it. The openness of a system
>does not stem solely from having a well defined interface. In my opinion
>the interface must not only be well-defined, it must be available for
>use without licnse fee.
>
>	TCP/IP+telnet, etc. is a good example of an open software suite.
>	DCE is not.

Open Systems
by Erick Engelke

I had some time.
I had two klunky machines.
I found some FTP sites.
I downloaded RFCs.

In just a few months
thousands were using my code,
now two years later,
its millions untold.

IP was simple,
not like a legal text,
so it's the open system
that I like best.

The internet community propagates itself by ease of becoming
involved.  The cost and hassle of obtaining many other so-called
open standards may not lead to their demise, but it does prevent
them from overtaking the truly open standards IMHO.

Erick

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

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 93 19:34:06 GMT
From:      d1h1883@sc.tamu.edu (Dave Hess)
To:        comp.protocols.tcp-ip
Subject:   Re: Assignment of IP address across multiple subnets (bootp?)

In article <108544@netnews.upenn.edu> tony@scotty.dccs.upenn.edu (Anthony Olejnik) writes:
[...]
> What I`d really like to do is set up a *SINGLE* BOOTP-like server on
> a given subnet.  Then, depending on which subnet the machine is
> requesting from, the BOOTP-like server will assign the appropriate
> IP address for that subnet.  My though is that there will be multiple
> IP address (a unique one for each subnet) reserved for *each* of the
> dynamic machines.
[...]

I am in the same kind of dilemma but I don't think the above solution is
possible. First you would have to have vendors start supporting an IP address
of a BOOTP server that the box should contact. Right now they just use
broadcast which won't get off of a subnet in most cases.

The second problem is that once the single bootp server decides to reply,
how does it deliver the response? The router for the box's subnet does not
have an ARP entry for the box yet and the box won't respond to a ARP request
since it doesn't know it's IP address yet.

RFC 951 goes into these issues in some decent depth. There is only one
solution that I know of. You have to use special features in gateways (e.g.
"ip helper" addresses on a Cisco) to establish connectivity. The problem
is when you end up with a box behind a gateway that does not support this.

Dave

--
David K. Hess
Graduate Assistant                     David-Hess@tamu.edu
Supercomputer Center                  Texas A&M University

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Feb 1993 20:43:06 GMT
From:      willemk@nijmeg.ingr.com (willem kutschruiter)
To:        comp.protocols.tcp-ip
Subject:   ICMP redirect.

I have a router with two ip networks configured on one physical
ethernet port.

The node and router use a class B address with a subnet mask off
255.255.255.0

Now, when node a ping to node b, the packets are send to the
router and from that same in coming port they go out again as
well.
This results in undesirable network load as each packet will be
twice on the physical trunk.

Using a diffrent subnetmask is not an option for us.

I would think that the router should send out an ICMP redirect
mesage to the sending node to inform that the destination is on
the same physical trunk and to update it's routing table.

I'am refering to rfc792 page 12.

Question is, Are mine assumptions correct?.


-- 
Willem Kutschruiter.      Sr Technician network systems.

Intergraph Nijmegen,  The Netherlands
Phone +31 (80) 525709  ext 709   Mailpath : willemk@nijmeg.ingr.COM

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Feb 93 21:33:17 GMT
From:      pgreen@zia.aoc.nrao.edu (Philip Green)
To:        comp.protocols.tcp-ip
Subject:   Help with FTP LIST & NLST

Recently I have decided to modify the ftp program to log
anonymous connections to other sites. Since we have no 
source I found a version on uu.net or sunsite that I then
modified. The problem now is ls no longer works as the
orignal version of FTP did. The sun version(original) produces
ls output much the same as ls unix-command on a local file system.
The new version of ftp produces a long listing. I have
read RFC959 and it says that NLST & LIST are the commands
that are used. NLST provides a directory list and LIST
appears to provide whatever the daemon creator wished.

How should I handle ls in my program should I map it
to LIST and give the user whatever returns or should
I attempt to do what Sun did and provide something
similar to the ls unix-command? Any suggestions hints
examples etc.. are much appreciated.


Phil Green
NRAO
-- 
Phil Green                           	pgreen@aoc.nrao.edu
NRAO					505.835.7294

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Feb 1993 21:49:00 GMT
From:      mshah@next3.corp.mot.com
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Hesiod Class and Problems with Zone X'fer

Hi !!

I have never used class HS for my DNS. But there's a nameserver on DEC  
running DNS from which we are planning to get a zone x'fer (i.e act as  
their secondary) which uses it. 

For test purposes I tried to do a zone x'fer from that DEC nameserver.  
Eventhough my nameserver succeeded in getting a zone it would not resolve  
that domain for me. So I looked at the zone and found that a few NS  
records were preceeded by a number instead of "IN" (or "HS") for that  
record class.
For e.g. 
nameserver 3600    4       NS      xyz.sudomain.mot.com.

I was told that those records were defined as class HS (Hesiod) at the  
site that I got a zone x'fer from. The problem is my SUN will not  
understand this record (the above example) and since it considers this as  
a database error it will not resolve that domain. Also, if this NS records  
are modified to look as 

nameserver 3600    IN       NS      xyz.sudomain.mot.com.

our nameserver running on  a SUN (OS 4.1.2) will start resolving that  
domain. So can you please tell me why SUN translates an "HS" class record  
when it gets a zone x'fer in an erroneous way or if something else may be  
wrong. Also any info. on class HS will be helpful.

THANKS IN ADVANCE !!!!

--Manish
  mshah@mot.com


-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Feb 1993 22:55:38 GMT
From:      fgreco@cfdev1026.shearson.com (Frank Greco)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: DCE COMPLIANT ? (somewhat long)

In article <1l0s2hINNd5i@sol.tis.com> mjr@tis.com (Marcus J Ranum) writes:
>
>ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
>
>>In the good old days, at least in the OSI-oriented part of the world
>>(and after all it was OSI that made "Open" a household word in the
>>datacomm community), an open system was, informally speaking, a
>>system with an interface to the rest of the world defined solely
>>by the bit streams coming out of it or being accepted by it.
>
>	This is a mighty narrow definition of an "open system" and I
>think a lot of folks would disagree with it. The openness of a system
>does not stem solely from having a well defined interface. In my opinion
>the interface must not only be well-defined, it must be available for
>use without licnse fee.

	Why?  Recall that an interface is an on-paper specification.
	It should be free.  An implementation of that specification
	*could* be commercial and cost money (ie, "proprietary").  An
	implementation could also be free, but the point is that it
	could be either.  e.g., NFS is a public spec, but most
	implementations are not free.

	Frank G.
--
+-On Assignment at: Lehman Brothers-+-Office: Mercury Technologies, Inc.-+
| World Financial Center, 11th Floor| 53 Wall Street - Fifth Floor       |
| New York City, NY 10285 Desk: 1515| New York City, NY 10005            |
| email: fgreco@shearson.com        | email: fgreco@mercury.com          |

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 93 23:18:50 GMT
From:      maf@tabatha.MAE.CWRU.Edu (Mark Fullmer)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP redirect.

In article <1993Feb8.204306.1524@nijmeg.ingr.com>, willemk@nijmeg.ingr.com (willem kutschruiter) writes:
|> I have a router with two ip networks configured on one physical
|> ethernet port.
|> 
|> The node and router use a class B address with a subnet mask off
|> 255.255.255.0
|> 
|> Now, when node a ping to node b, the packets are send to the
|> router and from that same in coming port they go out again as
|> well.
 ...
|> I would think that the router should send out an ICMP redirect
|> mesage to the sending node to inform that the destination is on
|> the same physical trunk and to update it's routing table.

You would need some kind of ARP redirect for this to work, which
doesn't exist.

Depending on what kind of router you are using, it may support
proxy arp for any nets not on your physical router port.  Although
you would need to change the subnet mask for all hosts on that router
port to get rid of the 2x traffic, your whole network wouldn't need
to change.

If you're doing RIP and using Unix, routed could be modified to 
learn about the 'other' subnet(s) on the ethernet.

--
mark
maf+@osu.edu

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 1993 23:51:47 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP redirect.

In article <1993Feb8.204306.1524@nijmeg.ingr.com> willemk@nijmeg.ingr.com (willem kutschruiter) writes:

    [configuration with multiple network numbers on the same cable]

    I would think that the router should send out an ICMP redirect
    mesage to the sending node to inform that the destination is on
    the same physical trunk and to update it's routing table.
    
Sorry, but the router cannot assume that the node has a route to the other
destination.  Nor is there any mechanism through with the router can tell
the host about such a route.

As a result of these and other problems, a router can only issue a redirect
if a source and the next hop are on the same subnet.

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

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Feb 1993 03:17:05 GMT
From:      marbm-b@ascii.co.jp (Marcos Bachir Mubaied)
To:        comp.protocols.tcp-ip
Subject:   IP address problem

	I would like to know the number of the RFC
	which deals on the insufficiency IP address problem, namely
	about the available IP addresses will not be
	enough after some years(?).
	If be possible I would appreciate to receive the response
	by mail also because often I have problems  accessing   news.
	Thanks in advance.

-- 
	A S C I I  Corporation - JAPAN     Network Systems Development
	marbm-b@ascii.co.jp      
	M a r c o s    B a c h i r    M u b a i e d

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 93 06:51:25 GMT
From:      catone@dmark.wharton.upenn.edu (Tony Catone)
To:        comp.protocols.tcp-ip
Subject:   Re: Assignment of IP address across multiple subnets (bootp?)

In article <108544@netnews.upenn.edu> tony@scotty.dccs.upenn.edu (Anthony Olejnik) writes:

   I have some portable machines which have a need to be moved quite
   frequently among our campus subnets.  Normally, the machines are
   stationary and are assigned static IP address.

   Q: Is there a way to dynamically assign IP address to thes machines
      *ACROSS* subnets boundaries?

   I know I can use BOOTP to assign IP addresses from within a subnet.
   However, it is my understanding that I can`t use BOOTP across subnets.

BOOTP should work fine across subnets if your routers support BOOTP
forwarding per RFC-951.  At least that was the concensus the last time
this question went around the horn a few months ago.  Anyone working
on a FAQ yet?  Anyone want to?


- Tony
  catone@dmark.wharton.upenn.edu


-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 1993 10:41:19 GMT
From:      HSTAMS@cipvax.biolan.Uni-Koeln.DE (Henning Stams)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Assignment of IP address across multiple subnets (bootp?)

In article <108544@netnews.upenn.edu> tony@scotty.dccs.upenn.edu (Anthony Olejnik) writes:

>Q: Is there a way to dynamically assign IP address to thes machines
>   *ACROSS* subnets boundaries?
It should be possible. As far as I know, only the Ethernet-Broadcast
has to reach the BOOTP server in the other subnet. With BOOTP, you can
assign a unique NETMASK, BROADCAST and GATEWAY for each group of clients,
and of course you can assign a unique IP-Address to every client.

The "grouping" of clients within one subnet is usually done via a sample
entry for each subnet, which will be addressed on the line of the client
in that subnet via "tc=subnet1.sample" in the BOOTP-Config file of the
BOOTP-Server.

I never used it, but I'm quite sure it should work, because all the sample
BOOTP config files I've seen carried out for different subnets.

Hope that helps, Henning (hstams@biolan.Uni-Koeln.DE)

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Feb 1993 13:16:14 GMT
From:      jos@bull.nl (Jos Vos)
To:        comp.protocols.tcp-ip
Subject:   Routing between 2 class C networks on 1 Ethernet

Maybe this is a FAQ, maybe it is an unsolvable problem...

Is it possible to establish routing between 2 class C networks
on 1 Ethernet without having routers (or hosts acting as such
by having 2 physical Ethernet-interfaces)?

Please MAIL responses to me.
Thanks.

-- 
--    Jos Vos <jos@bull.nl>   (UUCP: ...!{uunet,mcsun,sun4nl}!nlbull!jos)
--    Bull Nederland NV, Product Support Unix, Amsterdam, The Netherlands

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Feb 1993 13:20:57 GMT
From:      peterl@progress.COM (Peter Lauterbach)
To:        comp.protocols.tcp-ip
Subject:   How to start tuning a TCP/IP WAN ?


Greetings,

	I have a user who has two systems wired together over a 9600 baud
X25 line. They are both 486 33Mhz machines running Unix 5 Release 4.0
of the Unisys variety.

	They are having incredibly bad performance. ie. ftp of about 
 800 bytes /sec.  Is this "normal" ?

	I've just started network tuning of Ethernet based stuff, but
this serial line network just has me stumped. Where should I start ?
ie. Pointers to references would be nice ? Can you tune these puppies,
just like a 10MB lan ?

	Sorry for the newbie questions, but I'm out of answers. Thx.

					Regards,
					Peter

 PS. I have most of the Nutshell books, if it's in there,pls let me know.

--
Peter Lauterbach			Progress Software Corporation
Peter.Lauterbach@progress.com		14 Oak Park, Bedford, MA 01730 USA

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Feb 93 13:56:27 GMT
From:      dcrocker@leland.Stanford.EDU (Dave Crocker)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: DCE COMPLIANT ? (somewhat long)

This thread has wandered into the realm of defining "open", a topic dear
to my heart, so I thought I would offer the view I wrote in my chapter
on the IETF standards process in the Internet Systems Handbook:

    Open Publication
    Open Ownership
    Open Development

Open Publication appears to be what the conversation, here, mostly
references.  Note, however, that vendors with proprietary specs -- i.e.,
specifications for which they control all changes -- often publish them,
to encourage third-party implementations.  NFS, DecNet, and PostScript are
examples.  While open publication is useful, the technology is still
controlled by one company.  In my own view, multi-vendor consortia are
only slightly better.  They have the benefit of no single company
retaining ownership, but the detriment, usually, of very limited
membership and perspective.  This detriment might include nefarious
goals, but more typically is unfortunate simply the pursuing technical
solutions that might not represent the most workable or acceptable
vehicle for the "community".

Open Ownership is best represented by the ISO and CCITT OSI activities.
No single organization or country owns the technology or change control
to it.  On the other hand, there is an explicit -- or implicit --
barrier to participation.  E.g., ISO permits one member per country,
though it permits many "advisor-level" participants.  (Members vote,
participants don't.)  More importantly, participation means incurring 
the cost of travel to many fine places, all of them far away.  This 
cuts down the base of participation enormously.

Open Development means that literally anyone may participate easily.
The closest approximation to this is the Internet standards process
(the IETF) since development is done by open-membership working groups
which do a great deal of the work via Internet email.  You must incur
whatever it costs you to access Internet mail, but there is no 
incremental cost for working group participation.  The IETF meets 3
times a year, and it sure helps to incur the expense of going to those
meetings, but that isn't required.  In my own view, this broad base
of participation has a huge effect on what is produced.  First, 
constraints and preferences of virtually the entire technical operational,
and consumer(well, end-user) world become crystal clear, even if the
solution doesn't.  Second, whatever is adopted has a very, very large
base of market acceptance by the time it hits the streets, since a
very, very large base of the market helped create it.

Dave

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Feb 1993 14:54:30 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   API standards (was: DCE COMPLIANT ?)

In article <thurlow.728847773@convex.convex.com>, thurlow@convex.com (Robert 
Thurlow) writes:

>>Have the OSI standards themselves actually started to address the API issues?
>
>No, I don't believe they have awakened to this need yet.

"awakened to this need" ... that is not the same as "considered to be
outside the scope of", is it?

Generally speaking, OSI standards define a lot of things as "outside the
scope of the standard", usually phrased something like [The definition
of APIs] "is a local matter".

Almost all CCITT OSI standards open with a chapter 0, containing roughly
the same introductory phrase: 

"The aim [of OSI] is to agree with a minimum of technical agreement 
outside of the interconnection standards themselves, the interconnection 
of information processing systems:
 - from different manufacturers
 - under different managements
 - of different levels of complexity
 - of different ages. "

(This one is from X.500 (88), but it looks the same other places as well).

Both CCITT and ISO recognize the value of local standards, but do not consider
it their responsibility. Well, for ISO that applies only within OSI - there
are several standards applicable to local interfaces. Actually, even CCITT
do define standard APIs in selected areas, such as for the CHILL language
interface to data storage.

After seeing the XAPIA X.400 spec, I am sure happy that neither CCITT nor
ISO will force that down my throat. I've got much better solutions myself
- much simpler to comprehend, better suited to my storage facilities, and
much more efficient (because the parameter formats suit my tools better).

Also, we would definitely need *several* API standards. With a single one,
we would not have the event driven communication directly mapped onto the 
event driven environment of eg. X.11 and MS-Windows, because it wouldn't
fit the "Fortran programmers" (by that I mean the programming model of
Fortran, not the language itself - plain c under plain unix is the same!).
We would end up with a synchronous/timeout-based interface between an event
system and another event system. That could hardly be described as elegant!

So I *will* do it my way, because none of the proposals I have seen honor
my programming model. Please correct me if I am wrong - and point me to
the documents defining an event driven interface.

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 93 15:16:41 GMT
From:      sym@ecmwf.co.uk (Stuart Mitchell)
To:        comp.protocols.tcp-ip
Subject:   Problems with routed on an AIX 3.2 workstation

I don't know if this is a FAQ or not, but we've been having problems with a routed on
an AIX workstation apparently advertising itself as a gateway into subnets that it 
shouldn't (both subnets within our network and also some networks completely outside
our network). To get round it we put the routed into passive mode and set up some
static routes elsewhere on the net.

Anybody else heard of anything like this ? Or am I on my own with this one ?

stuart
(sym@ecmwf.co.uk)

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Feb 1993 16:47:36 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.org.usenix,comp.protocols.tcp-ip,comp.unix.ultrix,comp.dcom.lans.fddi
Subject:   Re: TCP/IP Throughput Enhancement Software and Paper Available

In article <44590@sdcc12.ucsd.edu> jkay@cs.ucsd.edu (Jon Kay) writes:
}       This note is to announce availability of some TCP/IP
}throughput enhancement software and a paper about that software.  A
}paper by myself and Joseph Pasquale appeared at the Winter '93 Usenix
}on some network throughput enhancement work.
      ...
}usenixw93.ps - the Usenix paper

There is an error in this paper.  On page 8:

Several times the sequence:

        addu     v0,v1
        addu     v1,t5,0xffff                 # or t6
        addu     v0,v1

appears.  The middle "addu" should be "and".

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Senior Systems Geek
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Feb 1993 19:00:58 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.protocols.tcp-ip
Subject:   Re: Moving from coax to 10BaseT

Doug Siebert (dsiebert@icaen.uiowa.edu) wrote:
> 1.  When 10BaseT is set up, is it easy to do multiple connections from one
> port on a 10BaseT hub, perhaps using a 10BaseT->thinnet repeater?  (I assume
> such a thing is available and isn't too expensive?)  Otherwise all our thinnet
> transceivers are useless, right?  (And we'd have to get more or larger hubs)

I only know about HP hubs.  Our 10bT hubs all have a BNC connector.
This connector can be used to attach to the ThinNet segment.  In fact,
we recommend connecting our hubs together with ThinCoax when multiple
hubs are needed.
 
> 2.  Is it simple to link multiple 10BaseT hubs together, and is it relatively
> cheap?

With HP hubs, you can connect them together either by ThinCoax to their
BNC connectors, or by a cross-over twisted-pair cable to any of their
10bT ports.  For all HP hubs except our 8-port hub, you can also attach
a transceiver the the hub's AUI port (the 8-port hub has no AUI port).
We recommend using fiber-optic transceivers to connect hubs over long
distances (up to 1km) or in different buildings.

ThinCoax segments with T-connectors and terminators are not very
expensive.  Cross-over twisted-pair is even less expensive.
Transceivers and special cables (including ThickCoax) can run into
money.
 
> 4.  Are the advantages of getting an intelligent hub that speaks SNMP worth
> the additional cost?  Or is a cheaper "dumb" hub good enough for most uses?
> What are the issues involved in making this decision?

For most uses, a "dumb" hub is sufficient.  You need an intelligent hub
if your network is large or complex or has problems.  Intelligent HP
hubs can tell you which port is having problems either from the console
port (the 8-port hub has no console port; all others do) or from a MIB
browser running SNMP over either IP or IPX.  HP's OpenView Hub Manager
or Interconnect Manager knows about HP hubs.  When the hub has a
problem, the Hub or IC Mgr causes the hub to change color, the color the
hub changes to depends upon the problem.  HP's OV Mgrs can do the same
with some non-HP hubs too.

- Steve Kao

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Feb 1993 19:24:07 GMT
From:      dhepner@cup.hp.com (Dan Hepner)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: DCE COMPLIANT ? (somewhat long)


From: dcrocker@leland.Stanford.EDU (Dave Crocker)


>    Open Publication
>    Open Ownership
>    Open Development
>
>Open Publication appears to be what the conversation, here, mostly
>references.

  [but publication is insufficient] 

>In my own view, multi-vendor consortia are
>only slightly better. 

No doubt some consortia are better than others. There are surely
many I wouldn't care to defend.  However, if a consortium
is 
 -open to membership by all interested organizations
 -actually represents a substantial majority of all interested
  organizations
 -owns its specifications
 -controls development of its specifications

then your criteria seem to have been met.  X/Open qualifies on
all counts.

However, no standards organization, which explicitly includes
the formal standards bodies, operates in isolation.  If other forces
in the world are ignored, the standards produced will exist in
isolation, without implementation, as ISO has found on more than
one occasion.  So "ownership" and "development" of a successful
open standard often have to take into account actual forces in the 
world.  These forces include:

- existing implementations  (adapt and adopt an existing standard)
- ongoing development  (standardize things being worked on)
- other relevant standards (compatibility is highly desired)

>They have the benefit of no single company
>retaining ownership, but the detriment, usually, of very limited
>membership and perspective.  This detriment might include nefarious
>goals, but more typically is unfortunate simply the pursuing technical
>solutions that might not represent the most workable or acceptable
>vehicle for the "community".

Would you really claim that formal standards bodies are superior
in avoiding this last problem?

Dan Hepner

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Feb 1993 19:50:14 GMT
From:      Steinar.Haug@delab.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: How to start tuning a TCP/IP WAN ?

peterl@progress.COM (Peter Lauterbach) writes:
> 	I have a user who has two systems wired together over a 9600 baud
> X25 line. They are both 486 33Mhz machines running Unix 5 Release 4.0
> of the Unisys variety.
> 
> 	They are having incredibly bad performance. ie. ftp of about 
>  800 bytes /sec.  Is this "normal" ?

800 bytes/sec = 6400 bits/sec. For a 9600 baud line, with X25, IP, TCP and
FTP overhead, that's actually fairly decent. Certainly not "incredibly bad".

Steinar Haug, system/networks administrator
SINTEF DELAB, University of Trondheim, NORWAY
Email: Steinar.Haug@delab.sintef.no, 
	sthaug@idt.unit.no, steinar@tosca.er.sintef.no

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Feb 93 21:07:35 GMT
From:      dcrocker@leland.Stanford.EDU (Dave Crocker)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: DCE COMPLIANT ? (somewhat long)

In article <C274K7.G3v@cup.hp.com> dhepner@cup.hp.com (Dan Hepner) writes:
>
>   However, if a consortium
>is 
> -open to membership by all interested organizations
> -actually represents a substantial majority of all interested
>  organizations
>
>then your criteria seem to have been met.  X/Open qualifies on
>all counts.

There is a myth about open criteria for membership, as followed
by most (all?) consortia.  It ignores the filter of money.  It
costs (usually) serious money to join and it costs even more serious
money to attend the meetings, where the bulk of the work is done.  
Better still, many consortia charge real money for copies of their
specs.  While people have different thresholds of pain, the lesson
from no-incremental-charge to participate or to obtain copies of
specs that we see in the Internet is that (along with a measurable
amount of noisy input) we get participants with special knowledge,
clever ideas, extra time, etc., for special topics, with great
regularity.  

>  If other forces
>in the world are ignored, the standards produced will exist in
>isolation, without implementation, as ISO has found on more than

Exactly.  The challenge is to build enough feedback and assistance into
the development process so as to minimize the error.  It is worth 
keeping in mind that the OSI participants generally have been
intelligent, committed, right-thinking folks.  (I don't like much of
what they've produced, but that wasn't because they weren't trying.)
In fact, they believed they were solving "general" problems for
the "long term."  It's tough to criticize such intent.  Rather, I
find it remarkable that the approach apparently didn't/doesn't
work.  The Internet process, on the other hand, tends to much more
restrictive in its goals, yet its products seem to be not only
immediately usable but also to last rather a long time.

I believe that the amount of broad-based participation and feedback
that is built-in during the development process -- along with the
ability to let small groups of similar-minded folks drive the core
of that process -- is responsible for the utility of the output.

>   So "ownership" and "development" of a successful
>open standard often have to take into account actual forces in the 
>world.  These forces include:
>
>- existing implementations  (adapt and adopt an existing standard)
>- ongoing development  (standardize things being worked on)
>- other relevant standards (compatibility is highly desired)

They should, yes.  But they often don't.  The challenge is to make
a development process which tends to FORCE people into considering the
factors that you list.

>>    This detriment might include nefarious
>>goals, but more typically is unfortunate simply the pursuing technical
>>solutions that might not represent the most workable or acceptable
>>vehicle for the "community".
>
>Would you really claim that formal standards bodies are superior
>in avoiding this last problem?
>
Sigh.  Not eliminated completely, but Internet standards which make it
through the process tend to have an extremely broad base of support,
both from developers/vendors and from customers/users.  (As the IETF
grows, there is quite a challenge to maintain this truth assertion.)

D/

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Feb 1993 22:16:54 GMT
From:      rich@grebyn.com (Richard Lawrence)
To:        comp.protocols.tcp-ip
Subject:   Re: Assignment of IP address across multiple subnets (bootp?)

In article <108544@netnews.upenn.edu> tony@scotty.dccs.upenn.edu (Anthony Olejnik) writes:
>
>I have some portable machines which have a need to be moved quite
>frequently among our campus subnets.  Normally, the machines are
>stationary and are assigned static IP address.
>
>Q: Is there a way to dynamically assign IP address to thes machines
>   *ACROSS* subnets boundaries?
>
>I know I can use BOOTP to assign IP addresses from within a subnet.
>However, it is my understanding that I can`t use BOOTP across subnets.

BOOTP can function between different subnets. It requires a router in
the center that understands the process, and assists in transforming the
MAC address if applicable. This is called "bootp helper" mode and exists
on several modern routers (Cisco I know for sure, Wellfleet I'm pretty
certain, 3com I don't know yea or nay).

Keep in mind though, that if you choose to do this by bootp and then
move a machine around, it will still require editing the bootptab file
on the bootp server for new IP addresses. You can't have multiple
entries, in other words - one MAC, one IP address.



-- 
Rich Lawrence DoD#9630 rich@grebyn.com '92Seca II "Yuri" CI$:71101,2272
  I do not speak for my employer (or even half the time myself...)
   217 years ago my government gave me certain inalienable rights.
     Since then, they've been trying to correct their mistake.

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Feb 1993 22:27:58 GMT
From:      rustomji@sol.cs.wmich.edu (Eric Rustomji)
To:        comp.protocols.tcp-ip
Subject:   HELP WITH FD PASSING !!

Hi there,

How do you pass a socket fd to another program via a connected
socket ?

An example depicting it will be great.

Please reply ASAP!

Thanks.
--
Eric
------------------------------------------------------
Eric  Rustomji         
Dept. of Comp. Sc.
Western Michigan University
Office: (616) 387 - 5645      Home: (616) 387 - 5566
Email:  rustomji@cs.wmich.edu
------------------------------------------------------

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 93 23:14:19 GMT
From:      sklower@diva.Berkeley.EDU (Keith Sklower)
To:        comp.protocols.tcp-ip
Subject:   Re: How to start tuning a TCP/IP WAN ?

In article <1993Feb9.132057.24099@progress.com> peterl@progress.COM (Peter Lauterbach) writes:
}	I have a user who has two systems wired together over a 9600 baud
}X25 line. They are having incredibly bad performance. ie. ftp of about 
}800 bytes /sec.  Is this "normal" ?

800 bytes x 8 bits/byte is 6400baud, about 2/3 the available bandwith.
I wouldn't call that ``incredibly bad''; but it might be tuned up some.

You didn't say who the X.25 provider was, and what mtu and window(s)
they support.  It could be a simple matter of requesting additional
window space for X.25 connections.  The default on 9.6 accunet service
is 2 packets of 128 bytes, and the most they'll give you is 3.


-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      09 Feb 93 23:45:51 GMT
From:      jallard@microsoft.com (James 'J' Allard)
To:        comp.protocols.tcp-ip
Subject:   Re: Assignment of IP address across multiple subnets (bootp?)

In article <108544@netnews.upenn.edu> tony@scotty.dccs.upenn.edu (Anthony Olejnik) writes:
>
>Q: Is there a way to dynamically assign IP address to thes machines
>   *ACROSS* subnets boundaries?

If you're interested in dynamic IP address assignment, you're probably
interested in DHCP (dynamic host configuration protocol). This protocol
is under development in the IETF and addresses both managability, and 
the dynamics of internetworks.

>I know I can use BOOTP to assign IP addresses from within a subnet.
>However, it is my understanding that I can`t use BOOTP across subnets.

Not quite true. If your router/gateway software supports BOOTP forwarding
(this involves more than a simple filter, the packet needs to be altered
to reflect the originating subnet), then you should be in business. Check
with the vendor of your gateway(s), they may already support it.

-- 
_______________________________________________________________
J. Allard                                 jallard@microsoft.com
Program Manager of TCP/IP Technologies    work: (206)882-8080
Microsoft Corporation                     home: (206)860-8862

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 93 00:40:45 GMT
From:      John@Johns.FrontierTech.COM (John F. Moehrke)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP redirect.

>
>I have a router with two ip networks configured on one physical
>ethernet port.
>
>The node and router use a class B address with a subnet mask off
>255.255.255.0
>
>Now, when node a ping to node b, the packets are send to the
>router and from that same in coming port they go out again as
>well.
>This results in undesirable network load as each packet will be
>twice on the physical trunk.
>
>Using a diffrent subnetmask is not an option for us.
>
>I would think that the router should send out an ICMP redirect
>mesage to the sending node to inform that the destination is on
>the same physical trunk and to update it's routing table.
>
>I'am refering to rfc792 page 12.
>
>Question is, Are mine assumptions correct?.

The fatal flaw is that an ICMP redirect can not be sent out in response
to an ICMP message. Since ping uses ICMP echo type messages the
router can not tell you to redirect using ICMP.

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Feb 1993 02:11:49 GMT
From:      thurlow@convex.com (Robert Thurlow)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: API standards (was: DCE COMPLIANT ?)

In <1993Feb9.145436.27979W@lumina.edb.tih.no> ketil@edb.tih.no (Ketil Albertsen,TIH) writes:

>In article <thurlow.728847773@convex.convex.com>, thurlow@convex.com (Robert 
>Thurlow) writes:
 
>>>Have the OSI standards themselves actually started to address the API issues?
>>
>>No, I don't believe they have awakened to this need yet.
 
>"awakened to this need" ... that is not the same as "considered to be
>outside the scope of", is it?

I don't think they need to work the API into their standards, but I
think they need to facilitate the writing of one-or-more APIs to go
with the protocol.  If it doesn't exist, it hurts the acceptance of
the protocol greatly.  So far, I don't tend to see that being done
on a regular basis.  X.500 was a best-case, where the API only lagged
the standard by a small number of years.

>After seeing the XAPIA X.400 spec, I am sure happy that neither CCITT nor
>ISO will force that down my throat. I've got much better solutions myself
>- much simpler to comprehend, better suited to my storage facilities, and
>much more efficient (because the parameter formats suit my tools better).

You're free to write your own API, or for that matter use your own
protocol within your mail system, but as a customer, I would find
value in having interfaces I needed to deal with be standard, and
I've been involved in situations where the source code interface
was almost as important as the over-the-wire protocol.  I find no
advantage in forcing the world to invent an API per implementation.
I admit that the X.400 API isn't one I yearn for, but in the end,
I'd rather encourage standard APIs and try to get better quality.

>Also, we would definitely need *several* API standards. With a single one,
>we would not have the event driven communication directly mapped onto the 
>event driven environment of eg. X.11 and MS-Windows, because it wouldn't
>fit the "Fortran programmers" (by that I mean the programming model of
>Fortran, not the language itself - plain c under plain unix is the same!).
>We would end up with a synchronous/timeout-based interface between an event
>system and another event system. That could hardly be described as elegant!

At first glance, I tend to think each top-level operation (e.g. an MHS)
has a "natural" programmatic style, and that an alternate API style
fits less well and gets in the way.  But I won't hold too strong to
this, as I suspect that if I thought about it, I'd see a need for
multiple APIs to span all of the situations we have out there.

Rob T
--
Rob Thurlow, thurlow@convex.com
"Shouldn't I have this, shouldn't I have this, shouldn't I have all of this,
 and, passionate kisses, passionate kisses, passionate kisses, from you?"
- "Passionate Kisses" Lucinda Williams

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Feb 1993 04:42:22 GMT
From:      matcsp@nuscc.nus.sg (Shih-Ping Chan)
To:        comp.protocols.tcp-ip
Subject:   KA9Q with LPD: FTP site needed

Can someone please e-mail me with the address of an FTP site
with the version of KA9Q that includes LPD?

Thanks alot - (actually any DOS LPD implementation will do)



-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Feb 1993 06:02:30 GMT
From:      johnson@tigger.jvnc.net (Steven L. Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re: Assignment of IP address across multiple subnets (bootp?)

rich@grebyn.com (Richard Lawrence) writes:

>Keep in mind though, that if you choose to do this by bootp and then
>move a machine around, it will still require editing the bootptab file
>on the bootp server for new IP addresses. You can't have multiple
>entries, in other words - one MAC, one IP address.

Just thinking out loud of what it would take to make this work
so that systems could be moved transparently.  If the router
filled in the gateway field of bootp request with the ip address
of the interface on which the request was received the bootp
server would have sufficient information to choose the 'correct'
address from multiple alternatives (or pool of alternatives for
dynamic ip address assignment).  It's my understanding that RFC951
does not dictate this behavior for the router, instead allowing
the router to file in the gateway address field (giaddr) with
the ip address of the router or any address that would allow
the response to be routed to the correct network/subnet.  Thus
the behavior descibed above is conformant with RFC951 but not
required by it, IMO.  One would need something more than a
simple vanilla bootp server to make use of this information.

I don't know what current routers actually use for the giaddr
or whether this would actually work.  Comments?

-Steve

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Feb 1993 10:15:50 GMT
From:      jos@bull.nl (Jos Vos)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing between 2 class C networks on 1 Ethernet

jos@bull.nl (Jos Vos) writes:

>Maybe this is a FAQ, maybe it is an unsolvable problem...
 
>Is it possible to establish routing between 2 class C networks
>on 1 Ethernet without having routers (or hosts acting as such
>by having 2 physical Ethernet-interfaces)?

I've found the solution. In fact, I already tried part of the solution
before posting the question, but I'd forgotten to establish a route
command on the other host, so my first impression was that it didn't work.

For people interested in the answer:

Add a route command in the TCP/IP startup stuff of each host:

	route add othernet myhost 0

Here othernet is the network-address of the network you're not on
yourself and myhost is the host-address of yourself.

-- 
--    Jos Vos <jos@bull.nl>   (UUCP: ...!{uunet,mcsun,sun4nl}!nlbull!jos)
--    Bull Netherlands, Prosessional Services, Amsterdam, The Netherlands

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Feb 1993 10:20:16 GMT
From:      als@kowari.cpsg.com.au (Anthony Shipman)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   SUNRPC UDP caching and idempotency

In the UDP side of SUNRPC there is a cache for holding recent replies.
If the client retransmits a request then it is answered out of the cache 
rather than have the server be called twice for the same request.

This feature defaults to off and to enable it you call svc_enablecache().
Strangely there is no mention of it in the standard documentation.
In ONC the same situation exists.  There is a svc_dg_enablecache() but it
is not documented.

Is this feature supposed to be for general use?  Has anyone ever used it?



--
Anthony Shipman                 "You've got to be taught before it's too late,
CP Software Export Pty Ltd,      Before you are six or seven or eight,
19 Cato St., East Hawthorn,      To hate all the people your relatives hate,
Melbourne, Australia, 3121       You've got to be carefully taught."  R&H

E-mail: als@cpsg.com.au

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Feb 1993 11:21:03 GMT
From:      tkolasny@scholia.wbme.jhu.edu (Anthony Kolasny)
To:        comp.protocols.tcp-ip
Subject:   SLIP using BOOTP to resolve IP address


I have been successful using NCSA Telnet,  NUPop 1.03,  and other applications
through SLIP with the IP specified. When I use BOOTP to get the lines IP 
address, I get a time out error.   I tested BOOTP with a PC on the LAN and am 
able to connect to other machines on the LAN getting the IP from BOOTP but 
the gateway and nameserver are not recognized. I'm guessing that my entries 
in /etc/bootptab  is not configured correctly. 
 
What am I doing wrong?  Is this suppose to work? The modem is connected to 
the ttya port of a sun4.  I'm using cslip2.6. 
 
The /etc/slip.hosts entry looks like this:
 
Sslip   `hostname`      slip1.wbme.jhu.edu      0xffffff00  auto-comp proxy-arp
 
And, the /etc/bootptab entry on BOOTP server looks like this:
 
global.wbme:\
        :sm=255.255.255.0:bf=null:ds=128.220.2.7:
 
subnet88.wbme:\
        :tc=global.wbme:gw=128.220.88.20:

slip1.wbme.jhu.edu:tc=subnet88.wbme:ht=ethernet:ha=0800200771b2:ip=128.220.88.29:

where ha=0800200771b2 is the SLIP's host hardware address.

Your assistance is greatly appreciated.

Thanks,
Anthony Kolasny <tkolasny@scholia.wbme.jhu.edu>


-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Feb 1993 11:41:53 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: API standards

  Folks should be aware that the IEEE POSIX P1003.12 working group has
work underway to standardise the use of both 4.4 BSD sockets and the
X/Open Transport Interface (XTI) { which is a derivative of the System
V Transport Layer Interface (TLI)} interfaces.  The work is intended
to support use of both ISO OSI and Internet protocol suites and so is
often called the "Protocol-Independent Interface" work.

  Unlike some POSIX work that is objectionable, this work is very
focused on standardising the existing practice.  Folks with both
sockets and XTI/TLI expertise and implementation experience are
working on the draft being put together.  I think it might go to
ballot with IEEE late in 1993.  I fully expect that it will be
universally implemented once it becomes the standard (partly because
it represents standardisation of existing practice so vendors will
only need tweaks to bring their existing implementations in line with
the standard).

  Other work in the IEEE is attempting to standardise programming
interfaces for use over a FULL ISO OSI stack and for X.400.  I think
the X.400 interfaces (IEEE P1224 working group ?) are in balloting,
but I'm not sure.

  Followups have been redirected to comp.std.unix which is where
discussion of POSIX related standards belongs.

Ran
atkinson@itd.nrl.navy.mil

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 1993 12:47:46 GMT
From:      rank@winf.uni-passau.de (Christian Rank)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   References about Computer Networks

I am looking for references on books and papers about
  1. Reliability and Optimization of Computer Networks
  2. Increasing the Reliability of Computer Networks

If anybody has references about this topics: I would be happy if you would
e-mail me the references. (I'll post a summary if there is interest.)

Thanks in advance.


-- 
Christian Rank
Lehrstuhl fuer Wirtschaftsinformatik * Universitaet Passau *
Innstr. 29 * D-8390 Passau

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 93 16:02:14 GMT
From:      partho@cs.umd.edu (partho pratim mishra)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   TCP-IP implementations for IBM PS-2

I would like to know if there any TCP-IP implementations on
IBM PS/2 OS/2 platforms and if so from which vendors. 
I am not a regular reader of this
newsgroup (although I will monitor it for the next few days)
so I would appreciate it if you could send me a
copy of your response by e-mail also.

Thanks



-- 
                               |  Systems Design and Analysis Group
      Partho Pratim Mishra     |  Department of Computer Science    
         partho@cs.umd.edu     |  University of Maryland         
                               |  College Park, MD 20742      

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Feb 1993 16:31:12 GMT
From:      rpn4313@ucs.usl.edu (Narayanan Raja P)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for high speed networking

I am looking for an article/paper which deals with modifications
on TCP/IP to make it condusive to HIGH SPEED networking.

Now, I distinctly remember reading one such article sometime ago but
failed to keep track of the reference.

Could somebody assist me !

Thanks a lot. Please mail your replies to  rpn4313@ucs.usl.edu


Raja Narayanan
Grad Student


-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 93 17:55:12 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: How to start tuning a TCP/IP WAN ?

In article <1993Feb9.132057.24099@progress.com> peterl@progress.COM (Peter Lauterbach) writes:
>
>Greetings,
>
>	I have a user who has two systems wired together over a 9600 baud
>X25 line. They are both 486 33Mhz machines running Unix 5 Release 4.0
>of the Unisys variety.
>
>	They are having incredibly bad performance. ie. ftp of about 
> 800 bytes /sec.  Is this "normal" ?

I'd say that this is not unusual.

>	I've just started network tuning of Ethernet based stuff, but
>this serial line network just has me stumped. Where should I start ?
>ie. Pointers to references would be nice ? Can you tune these puppies,
>just like a 10MB lan ?

You need to know things like:

	What X.25 packet size is being used?
	What X.25 packet window is being used?
	How many X.25 hops are involved?
	Is packet level acknowledgement local, or end-to-end?
	If it's local, is it coupled to end-to-end flow control?
	What size TCP segments are being handed to X.25?
	What is the TCP window size?
	Can the host open multiple SVCs in parallel?
	Can you adjust any of the above?

With a typical FTP over TCP/IP over X.25, about the best you could expect is
about 90% of link speed (1-2% bit stuffing, 8-9% protocol overhead).  This
is about 1080 B/s of FTP data on a 9600 link.
>
>	Sorry for the newbie questions, but I'm out of answers. Thx.
>
>					Regards,
>					Peter

Art

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Feb 1993 19:55:15 GMT
From:      willemk@nijmeg.ingr.com (willem kutschruiter)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP redirect.

tli@cisco.com (Tony Li) writes:

>In article <1993Feb8.204306.1524@nijmeg.ingr.com> willemk@nijmeg.ingr.com (willem kutschruiter) writes:
 
>    [configuration with multiple network numbers on the same cable]
 
>    I would think that the router should send out an ICMP redirect
>    mesage to the sending node to inform that the destination is on
>    the same physical trunk and to update it's routing table.
>    
>Sorry, but the router cannot assume that the node has a route to the other
>destination.  Nor is there any mechanism through with the router can tell
>the host about such a route.

I'am using RIP, so the route to the other destination is there.

>As a result of these and other problems, a router can only issue a redirect
>if a source and the next hop are on the same subnet.

Which is in our case but these happend to be the same
router/port.

What you are saying is that if I would use two routers, it
should work, but if these ehternet ports happend to be in the
same box, it does not. ???


-- 
Willem Kutschruiter.      Sr Technician network systems.

Intergraph Nijmegen,  The Netherlands
Phone +31 (80) 525709  ext 709   Mailpath : willemk@nijmeg.ingr.COM

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Feb 1993 21:06:48 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for high speed networking

In article <1993Feb10.163112.24107@usl.edu> rpn4313@ucs.usl.edu (Narayanan Raja P) writes:
>I am looking for an article/paper which deals with modifications
>on TCP/IP to make it condusive to HIGH SPEED networking.

  Van Jacobson & Dave Borman wrote an RFC on TCP extensions related to
high speed networks.  There are several implementations of that high
speed Van J TCP and it works well.  Tom Skibo, formely of somewhere
else and currently of SGI, wrote a freely distributable implementation
of that kind of TCP.  I forget where the Skibo source code is kept for
anonymous ftp though, so don't bother asking me...



-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Feb 93 21:57:09 GMT
From:      drubin@poly.edu (David Rubin)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Cabletron EMME Flash Download


Has anyone successfully used "bootp" to download a new software image into the Cabletron EMME card (for the MMAC-series HUB)?

I am in the process of trying to set up bootp to do this, but I'd like to hear from anyone who has already done it, to avoid any unnecessary mistakes and network down time.

Any information would be appreciated ... please respond via E-mail.

--
Dave Rubin
Polytechnic University, New York
drubin@poly.edu


-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Feb 93 08:30:51 MST
From:      wmah@ersys.edmonton.ab.ca (Wayne Mah)
To:        comp.protocols.tcp-ip
Subject:   Yellow pages and subnet mask of 255.255.255.128

Forgive me if this is a FAQ.  In addition I don't have
ftp access to the relevant RFCs.

Is there any RFC or restriction in using subnet mask
255.255.255.128 and using Yellow Pages?

Thanks in advance.

--
Wayne Mah              wmah@ersys.edmonton.ab.ca 

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 1993 04:57:51 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP redirect.

(willem kutschruiter) writes:
    tli@cisco.com (Tony Li) writes:
    
    >Sorry, but the router cannot assume that the node has a route to the other
    >destination.  Nor is there any mechanism through with the router can tell
    >the host about such a route.
    
    I'am using RIP, so the route to the other destination is there.
    
That route points to the router.  What you need is for it to point to the
interface on the host itself.

    >As a result of these and other problems, a router can only issue a redirect
    >if a source and the next hop are on the same subnet.
    
    Which is in our case but these happend to be the same
    router/port.
    
If this is indeed your case, then the router can issue the redirect.

    What you are saying is that if I would use two routers, it
    should work, but if these ehternet ports happend to be in the
    same box, it does not. ???
    
No, not at all.  I'm saying that the above statement is exactly correct.
The source and the next hop (from the router) must be on the same IP
subnet.  I'm not sure what the alternate situation you're describing is.

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

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 93 13:45:55 -0500
From:      harvey@indyvax.iupui.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Bootp of PCTCP for DOS

In article <1705@tuura.UUCP>, jel@tuura.UUCP (Jerry Lahti) writes:
> doswangx@nuscc.nus.sg (Wang Xi (Ms)) writes:
>
>>bootp server. Any body have ideas to make bootp works even there are routers
>>in between bootp clients and bootp servers ?
>
> You can ask your network managers to set up the routers to
> effectively bridge BOOTP traffic, if the router software allows
> this. They might not like the idea very much.

No, not if I could figure out any other way to do it.  On Ciscos AGS+s
(the only one I know about since it's all we have here at IUPUI) you can
configure your routers to flood IP broadcasts throughout an Internetwork
"in a controlled fashion" that uses a spanning-tree database (iff you are
already doing bridging).  At least the manual says you can.  I don't think
I'd want to do it this way to make just to make BOOTP work unless I had
no other choice, which brings us to...

> Alternatively, you can set up bootp relay agents on each
> separate subnetwork.  However, I do not know if there is
> any easily available software or 'black box' solutions for this.

This is available on Ciscos.  You can configure a IP "helper address" in
the router to forward UDP broadcasts for specific sets of ports.  I think
I'd prefer to do it this way if possible in preference to flooding.
The term "flooding" reminds me too much of storms... :-)

> The third solution is to specify the address of the BOOTP server
> when you run the BOOTP client.  However, this requires that
> your PC knows its IP address, subnet mask and a router to use,
> which presumably is exactly the information you would like to
> retrieve using BOOTP.

This (PC must know it's own IP address) is incorrect, at least according
to the "chicken-egg issues" section in the BOOTP RFC (951).  However, I will
be finding out for myself soon because we are going to be needing to use
BOOTP here for a project in the works...
--
James Harvey    IUPUI OIT Technical Support -- VMS/Unix/Networks
harvey@iupui.edu  uucp:iugate!harvey  bitnet:harvey@indyvax

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Feb 93 06:11:00 GMT
From:      ciumicro@rta.oz.au
To:        comp.protocols.tcp-ip
Subject:   Running TCP/IP and SPX/IPX over ethernet on the IBM-PC

We are seeking information on software which might fulfil our needs. We require
PC-based software which will allow us to run TCP/IP and SPX/IPX concurrently
over ethernet.

Our current environment is as follows:

* Geographically diverse user sites, with ethernet networks in each site and
  leased lines between sites
* Multiple communications links between the larger sites for backup and
  bandwidth purposes
* Various Unix hosts and Novell NetWare file servers
* Variety of PCs, some running Windows 3.x
* Excelan 205T ethernet cards and Excelan LAN Workplace For DOS 3.5 software
* Novell (aka EagleTech) NE2000 ethernet cards and Novell LAN Workplace For DOS
  4.x software

The Excelan 205T/LWP 3.5 combination works well, but the LWP 3.5 software will
only work with the Excelan card, and is no longer available. In a pure DOS
environment we experience no problems, but running Windows with the TCP/IP and
SPX/IPX protocol stacks loaded is a bit unstable.

The Novell NE2000/LWP 4.x combination causes us problems, which is why we are
looking for alternatives. It appears that the TCP/IP implementation in LWP 4.x
does not buffer out-of-sequence TCP/IP packets, but rather discards them,
meaning that they have to be resent by the host. In our environment, where we
have multiple communications links between the larger sites, out-of-sequence
packets are common, and the non-buffering of out-of-sequence packets increases
our TCP/IP traffic over the WAN links by an estimated 70%.

The discarding of out-of-sequence packets by LWP 4.x causes packet timeouts and
resulting packet retransmissions, and thus a very noticeable "jerkiness" of the
display - it might take a couple of seconds and 3 or 4 "bursts" to receive and
display a screenful of data, which is unacceptable. Under the same conditions
the LWP 3.5 software will display the same screenful of data quickly and
smoothly.

We are looking to find a software solution which will allow us to continue with
our current Excelan 205T and Novell NE2000 ethernet cards, as well as use
ethernet cards from other suppliers. To obtain this flexibility presumably
means using software which supports ODI or NDIS.

Comments are welcome...

Cheerio, Michael

ciumicro@xwdev.pandc.rta.oz.au

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 93 08:38:33 GMT
From:      anderl@kommu.UUCP (Horst Anderl)
To:        comp.protocols.tcp-ip
Subject:   Source for TokenBus driver?

I am looking for example/generic sources for a token bus driver.

It should run on AT&T Unix and it should meet the DLP (Data Link
Provider) Interface.

Every little bit of source would be of interest.

Thanks a lot in advance,
--
NAME   Horst Anderl
EMAIL  anderl@kommu.erls01.siemens.de  ...!unido!kommu!anderl
SNAIL  Siemens AG, ANL A432/WF, Postfach 4848, Nuernberg, Germany
PHONE  +49-911-895-3998, +49-911-895-4127, +49-9133-5356
FAX    +49-911-895-2213

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 93 09:27:02 GMT
From:      jel@tuura.UUCP (Jerry Lahti)
To:        comp.protocols.tcp-ip
Subject:   Re: Bootp of PCTCP for DOS

doswangx@nuscc.nus.sg (Wang Xi (Ms)) writes:

>bootp server. Any body have ideas to make bootp works even there are routers
>in between bootp clients and bootp servers ?

You can ask your network managers to set up the routers to 
effectively bridge BOOTP traffic, if the router software allows 
this. They might not like the idea very much.

Alternatively, you can set up bootp relay agents on each
separate subnetwork.  However, I do not know if there is
any easily available software or 'black box' solutions for this.

The third solution is to specify the address of the BOOTP server
when you run the BOOTP client.  However, this requires that
your PC knows its IP address, subnet mask and a router to use,
which presumably is exactly the information you would like to
retrieve using BOOTP.

/Jerry Lahti

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 1993 20:23:19 +1030
From:      hart@flash.pax.tpa.com.au (Leigh M Hart)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp/ip package on PC

echan@skynet.intel.com (Eldon Chan ~ ) writes:


>Does anyone have a list of tcp/ip package for PCs ? Has anyone or magazine
>done any evaluation/comparision between these packages.
 
>I'll do a summary if I got enough responses.

I assisted a friend in a project that required the analysis of serveral
PC tcp/ip packages.  Mainly programming libraries.

KA9Q is a NOS, based on the ham radio packet network, PC/TCP,
and a few others, the one we decided was the best for the project
was WATTCP - waterloo TCP.  quite a nice library overall, writen for
use with TurboC.  

It has a nice set of docs - and very easy to use.

Leigh

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

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Feb 1993 15:33:58 GMT
From:      donp@niaid.nih.gov (Don Preuss)
To:        comp.protocols.tcp-ip
Subject:   Re: Assignment of IP address across multiple subnets (bootp?)

tony@scotty.dccs.upenn.edu (Anthony Olejnik) writes:


>I have some portable machines which have a need to be moved quite
>frequently among our campus subnets.  Normally, the machines are
>stationary and are assigned static IP address.
 
>Q: Is there a way to dynamically assign IP address to thes machines
>   *ACROSS* subnets boundaries?
 
>I know I can use BOOTP to assign IP addresses from within a subnet.
>However, it is my understanding that I can`t use BOOTP across subnets.

One option is to use a dynamic bootp server. We use this set up here, on 
6 networks. (and more every week). We have a bootp server on the network that
supports a pool of dynamic addresses. When a computer requests an IP 
address (and it is not assigned a static bootp address) it is allocated one
from the pool. We can thus move computers from net to net without worrying about
configuration. In addition, when new computers are received, there is virtually
no set up on them. 

The only cost is that you need to run this server on each network.
There is no need then for bootp helper addresses, since all bootp traffic is local.

We are running 600 machines this way, and have really had no problems.

donp


>--tony


-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 93 16:40:23 GMT
From:      laum@db.toronto.edu (Marc Lau)
To:        comp.protocols.tcp-ip
Subject:   A meta faq

Dear all,

I gather this must be a frequently asked question itself ...

Is there an FAQ list for this group and if there is, is it archived somewhere?

Many thanks.

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Feb 1993 16:51:26 GMT
From:      pete@mips.fidata.fi (Petri Helenius)
To:        comp.protocols.tcp-ip
Subject:   Authd for SVR3.2


Does there exist authd/identd that'll work on SVR3.2? Specially SunSoft
Unix?

I've tried to port both but there are some "missing links" between 
some kernel structures I've been unable to resolve.

Pete
--
--
 Petri Helenius, Fimeko-Data Oy 
 Phone +358-0-458 2421, Telefax +358-0-458 2425
 Internet pete@fidata.fi, Snail: Hollantilaisentie 36, 00330 HKI, FINLAND
 X.400    /C=fi/ADMD=fumail/PRMD=inet/O=fidata/S=Helenius/G=Petri/
 Looking for Unix(r) FAX-system ?   Mail queries to fdfax@fidata.fi

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Feb 1993 17:00:00 +0000
From:      leo@elmail.co.uk ("E.J.Leoni-Smith")
To:        comp.protocols.tcp-ip
Subject:   Re: File Transfer Utilities


>We are looking for a tcp or udp based file transfer utility which will
>do all or some of the following:
        
        transfer files on a scheduled basis (e.g. at night)
        provide for restarts if file transfer is interrupted
        provides log statistics and audit information
        provides some level of access control.

>Any ideas or pointers would be appreciated.

I have just the thing for you.
It was invented over 20 years ago I believe by a company called AT&T - I think 
you may know of them :-)

Its called UUCP. It does exactly what you want. 
And it doesn't even need a TCP/IP connection - although it sure can run over 
one.

>Mark Kusiak
>(301) 369-4813
>kusiak@col400.att.com

Moral: before you start gazing in girly magazines
       looking to meet the girl of your dreams
       She's tried and she's tested and you met her before
       Its a damn sight cheaper with the girl next door.

>/* I'm not speaking for AT&T, and AT&T isn't speaking for me */

Surprisingly enough, neither am I

>Joe Massi                       j_r_massi@att.com or att!col400!jrmassi
>AT&T Bell Laboratories          (301) 369-7780
>Columbia, MD                    packet radio: kb2jg@w3iwi.md.usa.noam

Leo Smith
ElectricMail ltd
Cambridge, UK
Leo@elmail.co.uk




-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 93 17:47:48 GMT
From:      skibo@florida.wpd.sgi.com (Thomas Skibo)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for high speed networking

In article <C293zD.3r4@ra.nrl.navy.mil>, atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
|> In article <1993Feb10.163112.24107@usl.edu> rpn4313@ucs.usl.edu (Narayanan Raja P) writes:
|> >I am looking for an article/paper which deals with modifications
|> >on TCP/IP to make it condusive to HIGH SPEED networking.
|> 
|>   Van Jacobson & Dave Borman wrote an RFC on TCP extensions related to
|> high speed networks.  There are several implementations of that high
|> speed Van J TCP and it works well.  Tom Skibo, formely of somewhere
|> else and currently of SGI, wrote a freely distributable implementation
|> of that kind of TCP.  I forget where the Skibo source code is kept for
|> anonymous ftp though, so don't bother asking me...

It's a patch to the BSD 4.3 Net-2 release.  It's available via anonymous
ftp from uxc.cso.uiuc.edu:/pub/tcplw.shar.Z.

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

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Feb 1993 19:48:04 GMT
From:      jiang@csbser.csb.yale.edu (Jianxin Jiang)
To:        comp.protocols.tcp-ip
Subject:   NIS questions

This is a re-post. The first one went on the net without a subject line.
Sorry...

							Jiang

-------------------------------------------------------------------------
Hello,

    I have a couple of questions about NIS:

    1) How do ypbind and ypserv daemons work? Does ypbind bind to a server by 
       sending out broadcast packets to the network? In so, then how does ypserv 
       respond? (my guess is not with broadcast)  

    2) How do netmask and broadcast address affect client binding and server
       response?

    The questions arose from my attempt to understand why the ypbind daemon 
on an NIS client failed to bind to a server in the same subnet (created by
extending a class B network number through the third octet of the IP address). 
In my case, the network interfaces (one on each machine) on the three machines 
running NIS are configured as follows:

     
	Machine		IP Address	Netmask		Broadcast

	Master		135.140.17.10	255.255.255.0	135.140.255.255
	Slave		135.140.17.20	255.255.0.0	135.140.255.255
	Client		135.140.17.25	255.255.255.0	135.140.17.255

Obviously, the netmask and the broadcast address of the slave were not
correct, nor was the broacast address of the master. After re-configuring
the interfaces with the correct netmask (255.255.255.0) and broadcast 
address (135.140.17.255), everything started to work properly.

You see, I got NIS working, but I don't quite understand why it is working
and why it didn't. Your explanations would be greatly appreciated. Thanks!

							Jiang

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Feb 1993 20:48:56 GMT
From:      ptrubey@netcom.com (Phil Trubey)
To:        comp.protocols.tcp-ip
Subject:   Single port terminal server?

I am doing some preliminary design work for a process control/manufacturing
automation type of environment.  My situation is that I have a number
of devices that communicate with the outside world using good old
serial ports.  The controller computers are all LAN attached and can
speak TCP/IP.  To enable these controller computers to control the
serial devices, I could install a single LAN attached terminal server 
and hang all the serial devices off of it.  The problem with this
architecture is that I've introduced a single point of failure (the
terminal server).  Ideally, I would like each of these serial devices
to be attached directly to the LAN itself.  As easy way to
retrofit these serial devices in this way would be to hook them up
to a (hopefully) inexpensive single port terminal server that would
speak serial asynch on one end and telnet/tcp/ip on the other.

Anyone know if there are manufacturers that make something like this?
The closest thing that I've found so far is a 4 port terminal server
by Lantronix for $995.

Any observations or comments on this architecture would be welcome.

Thanks,
-- 

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

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Feb 1993 20:55:13 GMT
From:      ramon@helix.nih.gov (Ramon J. Hontanon)
To:        comp.protocols.tcp-ip
Subject:   DECnet and IP at same time????


A naive question:

I have a Macintosh connected to an ethernet network used for both IP
and DECnet traffic. Right now only a DECnet client runs on the Mac
(MacTerminal/Pathworks). Here is the question:

- Can I just bring up my FTP client (e.g. Fetch) and transfer files or 
  do I have to reboot everytime I want to use IP vs. DECnet services?

Thanks in advance

Ramon@helix.nih.gov
--
 ----------------------------------------------------------------------
| Ramon J. Hontanon,  KE8SF   | Flow Cytometry Computer Support        |  
| E-mail: ramon@helix.nih.gov | CBER FDA National Institutes of Health |
| Voice: (301) 496 0718       | 8800 Rockville Pk. Bethesda, MD 20892  |

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Feb 1993 22:07:12 GMT
From:      brooks@lambda.msfc.nasa.gov (jody brooks)
To:        comp.protocols.tcp-ip
Subject:   Extending SNMP AGents ???

We are using DECmcc to manage SNMP in a multi-vendor environment.
On our SPARCstation 2's we have installed Sun's SNMP daemon, snmpd
(the one included with SunNet Manager - as I mentioned, though, we
are not using SunNet Manager as our Network Manager.).

Now we need to extend the SNMP Agent to include a private MIB we have
created.  The concept of extending agents is mentioned often in many
vendors literature, but the how's are not given much verbage (at least
not that I've seen).

?: Does anyone know if the SNMP daemon we have is extendible (extensible)
    and how?
?: Any actual implementations out there I can peruse? 

I know the SMUX Protocol (RFC 1227) is supposed to be a standard for
extending agents, but what agents implement this protocol (on any
platform)?  The SNMP agent in ISODE 7.0 does, but from the best I can
tell, that particular implementation doesn't allow set operations.
Does anyone know about this?  

?: Does the ISODE 7.0 agent allow (implement) set-requests for the main
    SNMP agent (MIB-II) and/or for the SMUX peer (private MIB's)?

The best I can tell from the literature is "no" to both.

?: Does it allow traps for either? both? neither?

We've heard that Hewlett-Packard has an extensible agent that will run
on HP's and Sun's, and DEC has the Polycenter agent that will run on
VMS and ULTRIX that's supposed to be extensible.

?: Any information on these extensible agents?
 ?: Do they work with any (most any) management station?
 ?: Any info on the costs (w/ Gov't discounts)?


TIA
Jody Brooks


-- 
----------------------------------------------------------------------------
| Jody Brooks            brooks@lambda.msfc.nasa.gov       (205)461-4598   |
| New Technology, Inc.   Marshall Space Flight Center     Huntsville, AL   |
----------------------------------------------------------------------------

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Feb 1993 23:06:42 GMT
From:      bjean@eis.calstate.edu (Ben Jean)
To:        comp.protocols.tcp-ip
Subject:   Sockets programming?

Hi netters,
I'm new to networking programming. I never wrote a protocol
and don't even know how it's like :(
Can anyone tell me where I can get socket based c/s applications
source codes so I can hack on them. I need to know how c & servers
innteracts.
Any hints will greatly appreciated :)
Bye,
bj

-- 

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Feb 1993 02:19:45 GMT
From:      ehrlich@daneel.cs.psu.edu (Dan Ehrlich)
To:        comp.protocols.tcp-ip,comp.sys.dec,comp.unix.ultrix
Subject:   Using a TeleBit T3000 for a SLIP Connection on ULTRIX/RISC

We are trying to set up a T3000 modem to connect to a DECstation
5000/33 for a SLIP connection.  The documentation that comes with the
SLIP provided by DEC is spartan, but it is also noted that it is
unsupported.  Can anyone suggest how to configure the T3000?  We have
tried a few combinations but nothing seems to work very well.  By the
way, does anyone know if there is a way to get the serial port on a
DECstation to use hardware (RTS/CTS) flow control?

Thanks in advance for any information you may be able to share.

-- 
Dan Ehrlich - Sr. Systems Programmer - Penn State Computer Science
"Universities should be safe havens where ruthless examination of
 realities will not be distorted by the aim to please or inhibited
 by the risk of displeasure." - Kingman Brewster

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Feb 1993 03:13:23 GMT
From:      rich@grebyn.com (Richard Lawrence)
To:        comp.protocols.tcp-ip
Subject:   Re: Assignment of IP address across multiple subnets (bootp?)

johnson@tigger.jvnc.net (Steven L. Johnson) writes:

>rich@grebyn.com (Richard Lawrence) writes:
 
>>Keep in mind though, that if you choose to do this by bootp and then
>>move a machine around, it will still require editing the bootptab file
>>on the bootp server for new IP addresses. You can't have multiple
>>entries, in other words - one MAC, one IP address.
 
>Just thinking out loud of what it would take to make this work
>so that systems could be moved transparently.  If the router
>filled in the gateway field of bootp request with the ip address
>of the interface on which the request was received the bootp
>server would have sufficient information to choose the 'correct'
>address from multiple alternatives (or pool of alternatives for
>dynamic ip address assignment).  It's my understanding that RFC951
>does not dictate this behavior for the router, instead allowing
>the router to file in the gateway address field (giaddr) with
>the ip address of the router or any address that would allow
>the response to be routed to the correct network/subnet.  Thus
>the behavior descibed above is conformant with RFC951 but not
>required by it, IMO.  One would need something more than a
>simple vanilla bootp server to make use of this information.

I could see where you could determine the network address that the
machine had been moved to, but how are you going to guess at a host
address? Any testing method you could use would be prone to error due to
machines that were turned off at the time of the test.....

neat idea, though.
-- 
Rich Lawrence DoD#9630 rich@grebyn.com '92Seca II "Yuri" CI$:71101,2272
       Disclaimer: I speak for myself only, and no corporation.
   217 years ago my government gave me certain inalienable rights.
     Since then, they've been trying to correct their mistake.

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Feb 1993 09:31:06 GMT
From:      evansmp@uhura.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: DECnet and IP at same time????

Ramon J. Hontanon (ramon@helix.nih.gov) wrote:
: 
: A naive question:
: 
: I have a Macintosh connected to an ethernet network used for both IP
: and DECnet traffic. Right now only a DECnet client runs on the Mac
: (MacTerminal/Pathworks). Here is the question:
: 
: - Can I just bring up my FTP client (e.g. Fetch) and transfer files or 
:   do I have to reboot everytime I want to use IP vs. DECnet services?

I don't see any reason why not so far a the network protocols are concened.
(A vax can do this quite happerly)

The only problems would be in the specific implimentaions of the software
you are trying to run.
e.g. do they try and configure the card differently?
do the two packages assume that they should have exclusive access to the
network and just dump any packets they don't know about?

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

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 93 09:55:23 GMT
From:      ishikawa@personal-media.co.jp (Chiaki Ishikawa)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.misc
Subject:   Re: Inquiry Free/commercial tcp/ip protocol drivers sought.


Hello.  I asked the net about 10 days ago (Feb. 2, 1993) about
free/commercial TCP/IP software packages. I have received some
answers.  We are yet to analyze some of the packages mentioned in the
answers.  This is still an *INTERIM* report. We have begun to got in
contact with some sources now.

Following is the original post.  I am reposting since due to my
oversight, the feed to our gateway machine was incomplete during the
last 10 days :-( Although I do know that the post made it to Europe
and USA, I would like to gather more information if possible from the
help of the net.

    I am looking for a free or commercial implementation of tcp/ip
    protocol driver software. 

    We will have our own software/hardware to prepare the basic packet
    drivers. What I am looking for is the layer above it. We don't need
    the user-level application such as ftp, telenet and the service
    daemons such as ftpd, telnetd, etc..
    (The target system is a multitasking system. It is not UNIX, nor
    WIndows/NT.)

    Any pointers such as

	    - available free implementation and where to contact (and
	      possible ftp sites),

	    - commerical implementation and where to contact,

	    - FAQ or available document(s) from newsgroups and ftp sites,

	    - or newsgroup(!) where I should dive in,

	    - e-mail from commercial vendors

    are appreciated.

    [Since our Tokyo UUCP neighbor and North American UUCP neighbor (uunet)
    both have disk system problems at the same time(!) and may have
    problem carrying all the news posting (Murphy's Law DOES strike!), I
    would appreciate if you could answer by e-mail. (Tell you the truth, I
    am not sure if this will reach wide distribution. We will see.)]

    If you are interested in hearing the responses I get, please let me
    know. I will send you the summary of responses.

    ishikawa@personal-media.co.jp

    ADDITIONAL QUESTIONs: on Feb. 5th.

    Since our aim is to port the software to an embedded realtime operating system,
    we would like to know if the porting to a such system is easy. For example, we can't allow the program to do a simple busy wait in such a system. 
    Of course, if we can substitute such usage with a 
    better synchronization routines in a clean manner, it is OK.

    Also, if there are any special assumption about the network driver
    interface (between OS and network driver), we would like to know.  For
    example, is there any special requirement for the memory management
    for the network data buffers.



Please send e-mail to me if you know a package that you feel should be
put into the target list for our investigation.  We intend to at least
try to hear more about details of commercial packages from the
commercial source and/or check the suitability of software packages
for our particulr purposes.  Again, information from commercial
vendors are welcome. In the meantime, this information may be of
helpful to readers.

	Acknowledgement to

	Russell Nelson" <pmcgw!uunet!crynwr.com!nelson>
	Ian Heavens <pmcgw!uunet!spider.co.uk!ian>
	Phil Karn <pmcgw!uunet!unix.ka9q.ampr.org!karn>
	Stephane Bortzmeyer <pmcgw!uunet!cnam.cnam.fr!bortz>
	David Bridgham!uunet!EPILOGUE.COM!dab
	uunet!netcom.com!dmayer (David J. Mayer)
	uunet!romeo.wtk.suresnes.marben.fr!mchauvin (Marc CHAUVIN)
	uunet!spider.math.ilstu.edu!behr (Eric Behr)
	uunet!wco.ftp.com!graeme (Graeme Vanderstoel)

Please let me know if your name is omitted from the above list. I have
received many mails and if your names slips by during my mail shuffle,
I apologize. Again I have not put much product information in this
interim report. I will follow this up with a more detailed list.

Here is the list. Only names and known contacts are listed.  The 'C' in
first column means that I have at least heard, or exchanged a short
e-mail messages with the source mentioned.

Free/commericial:

C  :KA9Q by Phil Karn, 				    Source at: ucsd.edu
    karn@unix.ka9q.ampr.org
    *SORRY* we are yet to analyze the source code.

?  :PCIP originally by people at MIT. Probably Obsolete.
    (See below FTP Software for the commerical version of PCIP.

?  :NCSA (like NCSA TELNET).	   Said to be poorly documented,etc.
    *UNKNOWN* : I don't know the source yet. However, I have seen it
                running on Macintosh before.

?  : MacTCP.  See writeup comp.sys.mac.comm FAQ (anonymous ftp from
	rascal.ics.utexas.edu, file communications.FAQ in the directory
	mac/faq) and my notes on MacTCP (spider.math.ilstu.edu in
	/pub/mac/mac-tcp.txt or sumex.stanford.edu in
	/info-mac/report/mac-tcp-info.txt).
	(above info from Eric
	Behr, Illinois State University, Math Department, behr@math.ilstu.edu,
	
	*SORRY*, I have not yet read the FAQ yet :-( I have only 24
                 hours a day.

   :Xinu implementatoin by R. Stevens and D. Comer in the book
    "Internetworking with TCP/IP vol II". Prentice hall.
	suggested by 
  Stephane Bortzmeyer,     Conservatoire National des Arts et Metiers	
 bortzmeyer@cnam.cnam.fr   Laboratoire d'Informatique

	*SORRY*, I have only looked at (not read) the book yet.

   :BSD NET2.  Obvious source. Legal cloud caused by AT&T/USL suit
               surrounding it.

	*SORRY*, we may not want to see it because of the legal	problem.

Commercial Product:

?  : Lloyd Associates.  Commercial version of KA9Q. 
     *YET TO BE HEARD*

c  :OSI technology of France.  Commercial.
    Marc Chauvin, E-Mail: mchauvin@wtk.suresnes.marben.fr

C  :Spider Systems Limited, Edinburgh, UK    Streams-based TCP/IP stack, etc. 
	Ian Heavens,		ian@spider.co.uk                 

C  :Crynwr Software. 			Packet drivers.
	Crynwr Software, info@crynwr.com

C  :Epilogu Technology Corp.		Attache [TCP/IP, etc.]
    	info@epilogue.com 

C   :FTP Software,	commerical version of PCIP.
     	info@ftp.com

   :Interactive Systems Corp. 	Streamware TCP
	(from an old news clipping, 1992, May.30). 
                     		
   :Network Research		Fusion Developer's Program
	(from old news clip. 1991 Sept).

[end of list]

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Feb 1993 15:06:40 GMT
From:      stevevr@ecs.comm.mot.com (Steve Vranyes)
To:        comp.protocols.tcp-ip
Subject:   Multicasting

I am looking to use multicasting in an application that I am building.
The problem I ran into is that I want to multicast to processes and not just
to a box.  I would like to have multiple clients on the same computer be 
able to receive the same packet from the server without putting in a
multiplexing agent on each box.  Does anyone have any advice for how this can
be handeled in an effecient manner?

Thanks in advance
Steve Vranyes
stevevr@ecs.comm.mot.com
Motorola Inc.

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 93 15:36:13 GMT
From:      bvs@nrc.com (Bill Versteeg)
To:        comp.protocols.tcp-ip
Subject:   Re: LPR and Fortran flow control RFC 1179

kenh@leps5.phys.psu.edu (Ken Hornstein) writes:

>In article <1993Jan26.072251.8942@spectrum.CMC.COM> lars@spectrum.CMC.COM (Lars Poulsen) writes:
>>In article <1993Jan22.170024.2775@vax1.mankato.msus.edu>
>>   robin@vax1.mankato.msus.edu writes:
>>>For output we get a complete printout on the host... but the fortran flow
>>>control is NOT interpreted and the "1" "0" "+".. etc. are printed.
>>
>>The file is printed as transmitted. How would the print server host know
>>that this file came from FORTRAN ?
 
>Isn't there a code you can send using the lpr protocol that tells the
>print server host that the client is using FORTRAN carriage controls?
>I thought there was, but it's been a while ....
 
>--Ken


Yes, in the header of the lpr message, there is a mechanism for saying
Fortran carriage controls. However, when sending to a device
that does not interpret control files (like a print server with no 
disk), this does not get processed.
If the control file would get sent first, the resource-poor server could
process the header correctly. Unfortunately, the lpr clients in use
typically send the data then the control file. If you can't spool the 
data to disk, then examine the header befor printing the data, you run into
problems like this...

Bill VerSteeg
-- 
Bill VerSteeg
VerSteeg CodeWorks
bvs@nrc.com

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 1993 22:33:56 +1030
From:      hart@flash.pax.tpa.com.au (Leigh M Hart)
To:        comp.protocols.tcp-ip
Subject:   Re: File Transfer Utilities

jrmassi@col400.att.com (Joseph R. Massi) writes:

>We are looking for a tcp or udp based file transfer utility which will
>do all or some of the following:
>	
>	transfer files on a scheduled basis (e.g. at night)
>	provide for restarts if file transfer is interrupted
>	provides log statistics and audit information
>	provides some level of access control.
 
>Any ideas or pointers would be appreciated.

I've written a udp file transfer server/client - the server can handle
multiple sessions, restarts aren't a problem to code, it logs some
stuff :) and security is a matter of adding another char * to the 
header struct :)

scheduling would be a matter of checking the time/date against a
schedule file and acting on it appropriately.  The way it's written
the server can't initiate a session itself, but I'd guess you'd be 
running a server on each recipiant machine anyway ;)  so it could
spawn a task to send it through the client.

Mail me if you're interested in what I've got or more.

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

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 93 18:03:58 GMT
From:      schmidt@net1.ics.uci.edu (Douglas C. Schmidt)
To:        comp.unix.internals,comp.protocols.tcp-ip
Subject:   Empirical comparison between SVR4 streams and BSD sockets

In article <1993Feb12.105745.13814@spider.co.uk> ian@spider.co.uk (Ian Heavens) writes:
++ In article <QINYI.93Feb9105158@r6j.uk.ac.man.cs> qinyi@uk.ac.man.cs (Yi Qin (BCW PhD)) writes:
++ >Has anybody out there done any performance comparison between the streams
++ >and the sockets? Any comments on their implementations are also welcome.
++ >The comparison should be based on the identical, or at least comparable
++ >platforms.

Here's one data point that I gathered recently when testing our new
Solaris 2.1 configuration on sparcstation 2's using the standard ttcp
benchmarking utility.  I believe the Solaris 2.1 socket interface is
actually implemented as a set of library routines that run over top of
STREAMS.  Likewise, the Sun OS 4.1.2 socket interface runs over top of
the modified BSD network architecture.  Therefore, this should provide
a fairly reasonable platform to perform the tests.

I compiled ttcp on both platforms using cc -O.  The ttcp.c file
required a small amount of modification to run on Solaris.  I've
included the updated file below.

To get a rough idea of the "out-of-the-box" performance I simply
started the "receiver" side of ttcp using the "-r -s -f m" options on
a sparc2 running Solaris 2.1. and a sparc2 running SunOS 4.1.2.  I
then ran tests using the default "-r -s" sender options on two
different machines, each on the same Ethernet subnet.  The results
below are representative of the timings I obtained by running multiple
executions of the test:

----------------------------------------
% solaris.ttcp -r -s -f m
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
ttcp-r: socket
ttcp-r: accept from 128.195.4.82
ttcp-r: 16777216 bytes in 16.00 real seconds = 8.00 Mbit/sec +++
ttcp-r: 2976 I/O calls, msec/call = 5.51, calls/sec = 186.00
ttcp-r: 0.8user 5.5sys 0:16real 39%

% sunos.ttcp -r -s -f m
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
ttcp-r: socket
ttcp-r: accept from 128.200.38.14
ttcp-r: 16777216 bytes in 21.00 real seconds = 6.10 Mbit/sec +++
ttcp-r: 11494 I/O calls, msec/call = 1.87, calls/sec = 547.33
ttcp-r: 0.2user 4.6sys 0:21real 23%
----------------------------------------

The results are interesting since the Solaris/STREAMS version
significantly outperforms the SunOS/BSD version.  A bit of
experimentation using truss and trace indicated one plausible
explanation.  It appears that the STREAMS implementation typically
received incoming buffers in 8192 byte chunks, whereas the BSD
implementation was restricted to 4096 byte chunks (i.e., their default
TCP window/buffer size in the receiver).  Note also that the number of
I/O calls is *much* greater for the Sun OS version!

By expanding the -b (system buffer size) and -l (application buffer
size) options to around 32k I was eventually able to get both versions
to operate at around 8.53 Mbit/sec on average (out of a theoretical
maximum of 10 Mbit/sec on Ethernet, which is pretty good I believe).

My conclusion from this experiment are that the overhead from using
the STREAMS subsystem does not appear to be significant compared with
the original BSD network architecture.  In fact, by default the
STREAMS-based version is actually significantly faster, probably due
to using larger buffering/window sizes in the implementation.

I'd be interested to know whether anyone else has found the same
behavior and/or whether my conclusions are justified!

	Thanks,

		Doug

----------------------------------------
/*
 *      T T C P . C
 *
 * Test TCP connection.  Makes a connection on port 5001
 * and transfers fabricated buffers or data copied from stdin.
 *
 * Usable on 4.2, 4.3, and 4.1a systems by defining one of
 * BSD42 BSD43 (BSD41a)
 * Machines using System V with BSD sockets should define SYSV.
 *
 * Modified for operation under 4.2BSD, 18 Dec 84
 *      T.C. Slattery, USNA
 * Minor improvements, Mike Muuss and Terry Slattery, 16-Oct-85.
 * Modified in 1989 at Silicon Graphics, Inc.
 *      catch SIGPIPE to be able to print stats when receiver has died
 *      for tcp, don't look for sentinel during reads to allow small transfers
 *      increased default buffer size to 8K, nbuf to 2K to transfer 16MB
 *      moved default port to 5001, beyond IPPORT_USERRESERVED
 *      make sinkmode default because it is more popular,
 *              -s now means don't sink/source
 *      count number of read/write system calls to see effects of
 *              blocking from full socket buffers
 *      for tcp, -D option turns off buffered writes (sets TCP_NODELAY sockopt)
 *      buffer alignment options, -A and -O
 *      print stats in a format that's a bit easier to use with grep & awk
 *      for SYSV, mimic BSD routines to use most of the existing timing code
 * Modified by Steve Miller of the University of Maryland, College Park
 *      -b sets the socket buffer size (SO_SNDBUF/SO_RCVBUF)
 * Modified Sept. 1989 at Silicon Graphics, Inc.
 *      restored -s sense at request of tcs@brl
 * Modified Oct. 1991 at Silicon Graphics, Inc.
 *      use getopt(3) for option processing, add -f and -T options.
 *      SGI IRIX 3.3 and 4.0 releases don't need #define SYSV.
 * Modified for operation under Solaris 2.1, 10 Feb 1993
 *      Douglas C. Schmidt (schmidt@ics.uci.edu)
 *
 * Distribution Status -
 *      Public Domain.  Distribution Unlimited.
 */
#ifndef lint
static char RCSid[] = "ttcp.c $Revision: 1.9 $";
#endif

/* #define BSD43 */
/* #define BSD42 */
/* #define BSD41a */
#define SYSV /* required on SGI IRIX releases before 3.3 */

#include <stdio.h>
#include <signal.h>
#include <ctype.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <sys/time.h>           /* struct timeval */

#if defined(SYSV)
#include <sys/times.h>
#include <sys/param.h>
struct rusage
{
  struct timeval ru_utime, ru_stime;
};

#define RUSAGE_SELF 0
#else
#include <sys/resource.h>
#define memcpy(A,B,C) bcopy ((A),(B),(C))
#define memset(A,B,C) bzero((A),(C))
#endif

struct sockaddr_in sinme;
struct sockaddr_in sinhim;
struct sockaddr_in frominet;

int domain, fromlen;
int fd;                         /* fd of network socket */

int buflen = 8 * 1024;          /* length of buffer */
char *buf;                      /* ptr to dynamic buffer */
int nbuf = 2 * 1024;            /* number of buffers to send in sinkmode */

int bufoffset = 0;              /* align buffer to this */
int bufalign = 16 * 1024;       /* modulo this */

int udp = 0;                    /* 0 = tcp, !0 = udp */
int options = 0;                /* socket options */
int one = 1;                    /* for 4.3 BSD style setsockopt() */
short port = 5001;              /* TCP port number */
char *host;                     /* ptr to name of host */
int trans;                      /* 0=receive, !0=transmit mode */
int sinkmode = 0;               /* 0=normal I/O, !0=sink/source mode */
int verbose = 0;                /* 0=print basic info, 1=print cpu rate, proc
                                 * resource usage. */
int nodelay = 0;                /* set TCP_NODELAY socket option */
int b_flag = 0;                 /* use mread() */
int sockbufsize = 0;            /* socket buffer size to use */
char fmt = 'K';                 /* output format: k = kilobits, K = kilobytes,
                                 *  m = megabits, M = megabytes,
                                 *  g = gigabits, G = gigabytes */
int touchdata = 0;              /* access data after reading */

struct hostent *addr;
extern int errno;
extern int optind;
extern char *optarg;

char Usage[] = "\
Usage: ttcp -t [-options] host [ < in ]\n\
       ttcp -r [-options > out]\n\
Common options:\n\
        -l ##   length of bufs read from or written to network (default 8192)\n\
        -u      use UDP instead of TCP\n\
        -p ##   port number to send to or listen at (default 5001)\n\
        -s      -t: source a pattern to network\n\
                -r: sink (discard) all data from network\n\
        -A      align the start of buffers to this modulus (default 16384)\n\
        -O      start buffers at this offset from the modulus (default 0)\n\
        -v      verbose: print more statistics\n\
        -d      set SO_DEBUG socket option\n\
        -b ##   set socket buffer size (if supported)\n\
        -f X    format for rate: k,K = kilo{bit,byte}; m,M = mega; g,G = giga\n\
Options specific to -t:\n\
        -n##    number of source bufs written to network (default 2048)\n\
        -D      don't buffer TCP writes (sets TCP_NODELAY socket option)\n\
Options specific to -r:\n\
        -B      for -s, only output full blocks as specified by -l (for TAR)\n\
        -T      \"touch\": access each byte as it's read\n\
";

char stats[128];
unsigned long nbytes;           /* bytes on net */
unsigned long numCalls;         /* # of I/O system calls */
double cput, realt;             /* user, real time (seconds) */

void err ();
void mes ();
int pattern ();
void prep_timer ();
double read_timer ();
int Nread ();
int Nwrite ();
void delay ();
int mread ();
char *outfmt ();

void
sigpipe ()
{
}

main (argc, argv)
     int argc;
     char **argv;
{
  unsigned long addr_tmp;
  int c;

  if (argc < 2)
    goto usage;

  while ((c = getopt (argc, argv, "drstuvBDTb:f:l:n:p:A:O:")) != -1)
    {
      switch (c)
        {

        case 'B':
          b_flag = 1;
          break;
        case 't':
          trans = 1;
          break;
        case 'r':
          trans = 0;
          break;
        case 'd':
          options |= SO_DEBUG;
          break;
        case 'D':
#ifdef TCP_NODELAY
          nodelay = 1;
#else
          fprintf (stderr,
                   "ttcp: -D option ignored: TCP_NODELAY socket option not supported\n");
#endif
          break;
        case 'n':
          nbuf = atoi (optarg);
          break;
        case 'l':
          buflen = atoi (optarg);
          break;
        case 's':
          sinkmode = !sinkmode;
          break;
        case 'p':
          port = atoi (optarg);
          break;
        case 'u':
          udp = 1;
          break;
        case 'v':
          verbose = 1;
          break;
        case 'A':
          bufalign = atoi (optarg);
          break;
        case 'O':
          bufoffset = atoi (optarg);
          break;
        case 'b':
#if defined(SO_SNDBUF) || defined(SO_RCVBUF)
          sockbufsize = atoi (optarg);
#else
          fprintf (stderr,
                   "ttcp: -b option ignored: SO_SNDBUF/SO_RCVBUF socket options not supported\n");
#endif
          break;
        case 'f':
          fmt = *optarg;
          break;
        case 'T':
          touchdata = 1;
          break;

        default:
          goto usage;
        }
    }
  if (trans)
    {
      /* xmitr */
      if (optind == argc)
        goto usage;
      memset ((char *) &sinhim, 0, sizeof (sinhim));
      host = argv[optind];
      if (atoi (host) > 0)
        {
          /* Numeric */
          sinhim.sin_family = AF_INET;
#if defined(cray)
          addr_tmp = inet_addr (host);
          sinhim.sin_addr = addr_tmp;
#else
          sinhim.sin_addr.s_addr = inet_addr (host);
#endif
        }
      else
        {
          if ((addr = gethostbyname (host)) == NULL)
            err ("bad hostname");
          sinhim.sin_family = addr->h_addrtype;
          memcpy ((char *) &addr_tmp, addr->h_addr, addr->h_length);
#if defined(cray)
          sinhim.sin_addr = addr_tmp;
#else
	  sinhim.sin_addr.s_addr = addr_tmp;
#endif /* cray */
        }

      sinhim.sin_port = htons (port);
      sinme.sin_port = 0;       /* free choice */
    }
  else
    {
      /* rcvr */
      sinme.sin_family = AF_INET;
      sinme.sin_port = htons (port);
      sinme.sin_addr.s_addr = INADDR_ANY;
    }

  if (udp && buflen < 5)
    {
      buflen = 5;               /* send more than the sentinel size */
    }

  if ((buf = (char *) malloc (buflen + bufalign)) == (char *) NULL)
    err ("malloc");
  if (bufalign != 0)
    buf += (bufalign - ((int) buf % bufalign) + bufoffset) % bufalign;

  if (trans)
    {
      fprintf (stdout,
               "ttcp-t: buflen=%d, nbuf=%d, align=%d/%d, port=%d",
               buflen, nbuf, bufalign, bufoffset, port);
      if (sockbufsize)
        fprintf (stdout, ", sockbufsize=%d", sockbufsize);
      fprintf (stdout, "  %s  -> %s\n", udp ? "udp" : "tcp", host);
    }
  else
    {
      fprintf (stdout,
               "ttcp-r: buflen=%d, nbuf=%d, align=%d/%d, port=%d",
               buflen, nbuf, bufalign, bufoffset, port);
      if (sockbufsize)
        fprintf (stdout, ", sockbufsize=%d", sockbufsize);
      fprintf (stdout, "  %s\n", udp ? "udp" : "tcp");
    }

  if ((fd = socket (PF_INET, udp ? SOCK_DGRAM : SOCK_STREAM, 0)) < 0)
    err ("socket");
  mes ("socket");

  if (!trans)
    if (bind (fd, (struct sockaddr *) &sinme, sizeof (sinme)) < 0)
      err ("bind");

#if defined(SO_SNDBUF) || defined(SO_RCVBUF)
  if (sockbufsize)
    {
      if (trans)
        {
          if (setsockopt (fd, SOL_SOCKET, SO_SNDBUF, (char *) &sockbufsize,
                          sizeof sockbufsize) < 0)
            err ("setsockopt: sndbuf");
          mes ("sndbuf");
        }
      else
        {
          if (setsockopt (fd, SOL_SOCKET, SO_RCVBUF, (char *) &sockbufsize,
                          sizeof sockbufsize) < 0)
            err ("setsockopt: rcvbuf");
          mes ("rcvbuf");
        }
    }
#endif

  if (!udp)
    {
      signal (SIGPIPE, sigpipe);
      if (trans)
        {
          /* We are the client if transmitting */
          if (options)
            {
#if defined(BSD42)
              if (setsockopt (fd, SOL_SOCKET, options, 0, 0) < 0)
#else /* BSD43 */
              if (setsockopt (fd, SOL_SOCKET, options, (char *) &one, sizeof (one)) < 0)
#endif
                err ("setsockopt");
            }
#ifdef TCP_NODELAY
          if (nodelay)
            {
              struct protoent *p;
              p = getprotobyname ("tcp");
              if (p && setsockopt (fd, p->p_proto, TCP_NODELAY,
                                   (char *) &one, sizeof (one)) < 0)
                err ("setsockopt: nodelay");
              mes ("nodelay");
            }
#endif
          if (connect (fd, (struct sockaddr *) &sinhim, sizeof (sinhim)) < 0)
            err ("connect");
          mes ("connect");
        }
      else
        {
          /* otherwise, we are the server and
           * should listen for the connections
           */
          listen (fd, 1);       /* allow a queue of 0 */
          if (options)
            {
#if defined(BSD42)
              if (setsockopt (fd, SOL_SOCKET, options, 0, 0) < 0)
#else /* BSD43 */
              if (setsockopt (fd, SOL_SOCKET, options, (char *) &one, sizeof (one)) < 0)
#endif
                err ("setsockopt");
            }
          fromlen = sizeof (frominet);
          domain = AF_INET;
          if ((fd = accept (fd, (struct sockaddr *) &frominet, &fromlen)) < 0)
            err ("accept");
          {
            struct sockaddr_in peer;
            int peerlen = sizeof (peer);
            if (getpeername (fd, (struct sockaddr *) &peer, &peerlen) < 0)
              {
                err ("getpeername");
              }
            fprintf (stderr, "ttcp-r: accept from %s\n",
                     inet_ntoa (peer.sin_addr));
          }
        }
    }
  prep_timer ();
  errno = 0;
  if (sinkmode)
    {
      register int cnt;
      if (trans)
        {
          pattern (buf, buflen);
          if (udp)
            (void) Nwrite (fd, buf, 4); /* rcvr start */
          while (nbuf-- && Nwrite (fd, buf, buflen) == buflen)
            nbytes += buflen;
          if (udp)
            (void) Nwrite (fd, buf, 4); /* rcvr end */
        }
      else
        {
          if (udp)
            {
              while ((cnt = Nread (fd, buf, buflen)) > 0)
                {
                  static int going = 0;
                  if (cnt <= 4)
                    {
                      if (going)
                        break;  /* "EOF" */
                      going = 1;
                      prep_timer ();
                    }
                  else
                    {
                      nbytes += cnt;
                    }
                }
            }
          else
            {
              while ((cnt = Nread (fd, buf, buflen)) > 0)
                {
                  nbytes += cnt;
                }
            }
        }
    }
  else
    {
      register int cnt;
      if (trans)
        {
          while ((cnt = read (0, buf, buflen)) > 0 &&
                 Nwrite (fd, buf, cnt) == cnt)
            nbytes += cnt;
        }
      else
        {
          while ((cnt = Nread (fd, buf, buflen)) > 0 &&
                 write (1, buf, cnt) == cnt)
            nbytes += cnt;
        }
    }
  if (errno)
    err ("IO");
  (void) read_timer (stats, sizeof (stats));
  if (udp && trans)
    {
      (void) Nwrite (fd, buf, 4);       /* rcvr end */
      (void) Nwrite (fd, buf, 4);       /* rcvr end */
      (void) Nwrite (fd, buf, 4);       /* rcvr end */
      (void) Nwrite (fd, buf, 4);       /* rcvr end */
    }
  if (cput <= 0.0)
    cput = 0.001;
  if (realt <= 0.0)
    realt = 0.001;
  fprintf (stdout,
           "ttcp%s: %ld bytes in %.2f real seconds = %s/sec +++\n",
           trans ? "-t" : "-r",
           nbytes, realt, outfmt (((double) nbytes) / realt));
  if (verbose)
    {
      fprintf (stdout,
               "ttcp%s: %ld bytes in %.2f CPU seconds = %s/cpu sec\n",
               trans ? "-t" : "-r",
               nbytes, cput, outfmt (((double) nbytes) / cput));
    }
  fprintf (stdout,
           "ttcp%s: %d I/O calls, msec/call = %.2f, calls/sec = %.2f\n",
           trans ? "-t" : "-r",
           numCalls,
           1024.0 * realt / ((double) numCalls),
           ((double) numCalls) / realt);
  fprintf (stdout, "ttcp%s: %s\n", trans ? "-t" : "-r", stats);
  if (verbose)
    {
      fprintf (stdout,
               "ttcp%s: buffer address %#x\n",
               trans ? "-t" : "-r",
               buf);
    }
  exit (0);

usage:
  fprintf (stderr, Usage);
  exit (1);
}

void
err (s)
     char *s;
{
  fprintf (stderr, "ttcp%s: ", trans ? "-t" : "-r");
  perror (s);
  fprintf (stderr, "errno=%d\n", errno);
  exit (1);
}

void
mes (s)
     char *s;
{
  fprintf (stderr, "ttcp%s: %s\n", trans ? "-t" : "-r", s);
}

pattern (cp, cnt)
     register char *cp;
     register int cnt;
{
  register char c;
  c = 0;
  while (cnt-- > 0)
    {
      while (!isprint ((c & 0x7F)))
        c++;
      *cp++ = (c++ & 0x7F);
    }
}

char *
outfmt (b)
     double b;
{
  static char obuf[50];
  switch (fmt)
    {
    case 'G':
      sprintf (obuf, "%.2f GB", b / 1024.0 / 1024.0 / 1024.0);
      break;
    default:
    case 'K':
      sprintf (obuf, "%.2f KB", b / 1024.0);
      break;
    case 'M':
      sprintf (obuf, "%.2f MB", b / 1024.0 / 1024.0);
      break;
    case 'g':
      sprintf (obuf, "%.2f Gbit", b * 8.0 / 1024.0 / 1024.0 / 1024.0);
      break;
    case 'k':
      sprintf (obuf, "%.2f Kbit", b * 8.0 / 1024.0);
      break;
    case 'm':
      sprintf (obuf, "%.2f Mbit", b * 8.0 / 1024.0 / 1024.0);
      break;
    }
 return obuf;
}

static struct timeval time0;    /* Time at which timing started */
static struct rusage ru0;       /* Resource utilization at the start */

static void prusage ();
static void tvadd ();
static void tvsub ();
static void psecs ();

#if defined(SYSV)
/*ARGSUSED*/
static
getrusage (ignored, ru)
     int ignored;
     register struct rusage *ru;
{
  struct tms buf;

  times (&buf);

  /* Assumption: HZ <= 2147 (LONG_MAX/1000000) */
  ru->ru_stime.tv_sec = buf.tms_stime / HZ;
  ru->ru_stime.tv_usec = ((buf.tms_stime % HZ) * 1000000) / HZ;
  ru->ru_utime.tv_sec = buf.tms_utime / HZ;
  ru->ru_utime.tv_usec = ((buf.tms_utime % HZ) * 1000000) / HZ;
}

/*ARGSUSED*/
static
gettimeofday (tp, zp)
     struct timeval *tp;
     struct timezone *zp;
{
  tp->tv_sec = time (0);
  tp->tv_usec = 0;
}

#endif /* SYSV */

/*
 *                      P R E P _ T I M E R
 */
void
prep_timer ()
{
  gettimeofday (&time0, (struct timezone *) 0);
  getrusage (RUSAGE_SELF, &ru0);
}

/*
 *                      R E A D _ T I M E R
 *
 */
double
read_timer (str, len)
     char *str;
{
  struct timeval timedol;
  struct rusage ru1;
  struct timeval td;
  struct timeval tend, tstart;
  char line[132];

  getrusage (RUSAGE_SELF, &ru1);
  gettimeofday (&timedol, (struct timezone *) 0);
  prusage (&ru0, &ru1, &timedol, &time0, line);
  (void) strncpy (str, line, len);

  /* Get real time */
  tvsub (&td, &timedol, &time0);
  realt = td.tv_sec + ((double) td.tv_usec) / 1000000;

  /* Get CPU time (user+sys) */
  tvadd (&tend, &ru1.ru_utime, &ru1.ru_stime);
  tvadd (&tstart, &ru0.ru_utime, &ru0.ru_stime);
  tvsub (&td, &tend, &tstart);
  cput = td.tv_sec + ((double) td.tv_usec) / 1000000;
  if (cput < 0.00001)
    cput = 0.00001;
  return (cput);
}

static void
prusage (r0, r1, e, b, outp)
     register struct rusage *r0, *r1;
     struct timeval *e, *b;
     char *outp;
{
  struct timeval tdiff;
  register time_t t;
  register char *cp;
  register int i;
  int ms;

  t = (r1->ru_utime.tv_sec - r0->ru_utime.tv_sec) * 100 +
    (r1->ru_utime.tv_usec - r0->ru_utime.tv_usec) / 10000 +
    (r1->ru_stime.tv_sec - r0->ru_stime.tv_sec) * 100 +
    (r1->ru_stime.tv_usec - r0->ru_stime.tv_usec) / 10000;
  ms = (e->tv_sec - b->tv_sec) * 100 + (e->tv_usec - b->tv_usec) / 10000;

#define END(x)  {while(*x) x++;}
#if defined(SYSV)
  cp = "%Uuser %Ssys %Ereal %P";
#else
#if defined(sgi)                /* IRIX 3.3 will show 0 for %M,%F,%R,%C */
  cp = "%Uuser %Ssys %Ereal %P %Mmaxrss %F+%Rpf %Ccsw";
#else
  cp = "%Uuser %Ssys %Ereal %P %Xi+%Dd %Mmaxrss %F+%Rpf %Ccsw";
#endif
#endif
  for (; *cp; cp++)
    {
      if (*cp != '%')
        *outp++ = *cp;
      else if (cp[1])
        switch (*++cp)
          {

          case 'U':
            tvsub (&tdiff, &r1->ru_utime, &r0->ru_utime);
            sprintf (outp, "%d.%01d", tdiff.tv_sec, tdiff.tv_usec / 100000);
            END (outp);
            break;

          case 'S':
            tvsub (&tdiff, &r1->ru_stime, &r0->ru_stime);
            sprintf (outp, "%d.%01d", tdiff.tv_sec, tdiff.tv_usec / 100000);
            END (outp);
            break;

          case 'E':
            psecs (ms / 100, outp);
            END (outp);
            break;

          case 'P':
            sprintf (outp, "%d%%", (int) (t * 100 / ((ms ? ms : 1))));
            END (outp);
            break;

#if !defined(SYSV)
          case 'W':
            i = r1->ru_nswap - r0->ru_nswap;
            sprintf (outp, "%d", i);
            END (outp);
            break;

          case 'X':
            sprintf (outp, "%d", t == 0 ? 0 : (r1->ru_ixrss - r0->ru_ixrss) / t);
            END (outp);
            break;

          case 'D':
            sprintf (outp, "%d", t == 0 ? 0 :
                     (r1->ru_idrss + r1->ru_isrss - (r0->ru_idrss + r0->ru_isrss)) / t);
            END (outp);
            break;

          case 'K':
            sprintf (outp, "%d", t == 0 ? 0 :
                     ((r1->ru_ixrss + r1->ru_isrss + r1->ru_idrss) -
                      (r0->ru_ixrss + r0->ru_idrss + r0->ru_isrss)) / t);
            END (outp);
            break;

          case 'M':
            sprintf (outp, "%d", r1->ru_maxrss / 2);
            END (outp);
            break;

          case 'F':
            sprintf (outp, "%d", r1->ru_majflt - r0->ru_majflt);
            END (outp);
            break;

          case 'R':
            sprintf (outp, "%d", r1->ru_minflt - r0->ru_minflt);
            END (outp);
            break;

          case 'I':
            sprintf (outp, "%d", r1->ru_inblock - r0->ru_inblock);
            END (outp);
            break;

          case 'O':
            sprintf (outp, "%d", r1->ru_oublock - r0->ru_oublock);
            END (outp);
            break;
          case 'C':
            sprintf (outp, "%d+%d", r1->ru_nvcsw - r0->ru_nvcsw,
                     r1->ru_nivcsw - r0->ru_nivcsw);
            END (outp);
            break;
#endif /* !SYSV */
          }
    }
 *outp = '\0';
}

static void
tvadd (tsum, t0, t1)
     struct timeval *tsum, *t0, *t1;
{

  tsum->tv_sec = t0->tv_sec + t1->tv_sec;
  tsum->tv_usec = t0->tv_usec + t1->tv_usec;
  if (tsum->tv_usec > 1000000)
    tsum->tv_sec++, tsum->tv_usec -= 1000000;
}

static void
tvsub (tdiff, t1, t0)
     struct timeval *tdiff, *t1, *t0;
{

  tdiff->tv_sec = t1->tv_sec - t0->tv_sec;
  tdiff->tv_usec = t1->tv_usec - t0->tv_usec;
  if (tdiff->tv_usec < 0)
    tdiff->tv_sec--, tdiff->tv_usec += 1000000;
}

static void
psecs (l, cp)
     long l;
     register char *cp;
{
  register int i;

  i = l / 3600;
  if (i)
    {
      sprintf (cp, "%d:", i);
      END (cp);
      i = l % 3600;
      sprintf (cp, "%d%d", (i / 60) / 10, (i / 60) % 10);
      END (cp);
    }
  else
    {
      i = l;
      sprintf (cp, "%d", i / 60);
      END (cp);
    }
  i %= 60;
  *cp++ = ':';
  sprintf (cp, "%d%d", i / 10, i % 10);
}

/*
 *                      N R E A D
 */
Nread (fd, buf, count)
     int fd;
     void *buf;
     int count;
{
  struct sockaddr_in from;
  int len = sizeof (from);
  register int cnt;
  if (udp)
    {
      cnt = recvfrom (fd, buf, count, 0, (struct sockaddr *) &from, &len);
      numCalls++;
    }
  else
    {
      if (b_flag)
        cnt = mread (fd, buf, count);   /* fill buf */
      else
        {
          cnt = read (fd, buf, count);
          numCalls++;
        }
      if (touchdata && cnt > 0)
        {
          register int c = cnt, sum;
          register char *b = buf;
          while (c--)
            sum += *b++;
        }
    }
 return (cnt);
}

/*
 *                      N W R I T E
 */
Nwrite (fd, buf, count)
     int fd;
     void *buf;
     int count;
{
  register int cnt;
  if (udp)
    {
    again:
      cnt = sendto (fd, buf, count, 0, (struct sockaddr *) &sinhim, sizeof (sinhim));
      numCalls++;
      if (cnt < 0 && errno == ENOBUFS)
        {
          delay (18000);
          errno = 0;
          goto again;
        }
    }
  else
    {
      cnt = write (fd, buf, count);
      numCalls++;
    }
 return (cnt);
}

void
delay (us)
{
  struct timeval tv;

  tv.tv_sec = 0;
  tv.tv_usec = us;
  (void) select (1, (fd_set *) 0, (fd_set *) 0, (fd_set *) 0, &tv);
}

/*
 *                      M R E A D
 *
 * This function performs the function of a read(II) but will
 * call read(II) multiple times in order to get the requested
 * number of characters.  This can be necessary because
 * network connections don't deliver data with the same
 * grouping as it is written with.  Written by Robert S. Miles, BRL.
 */
int
mread (fd, bufp, n)
     int fd;
     register char *bufp;
     unsigned n;
{
  register unsigned count = 0;
  register int nread;

  do
    {
      nread = read (fd, bufp, n - count);
      numCalls++;
      if (nread < 0)
        {
          perror ("ttcp_mread");
          return (-1);
        }
      if (nread == 0)
        return ((int) count);
      count += (unsigned) nread;
      bufp += nread;
  } while (count < n);

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

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Feb 93 19:08:05 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Subnet usage

Is it legal to have a class B subnet which is either all 1's or 0's?
We have a class B network assigned our company.  Lets say it is 130.99.0.0 .
We use RIP and a subnet mask of 255.255.255.0.  Can we assign the subnets
130.99.0 and 130.99.255?
 
Will packets with these addresses be construed to be broadcasts for all of
130.99?  For instance, a node on the 130.99.255 network may need to broadcast
with all 1's which results in an IP destination of 130.99.255.255.  Should
the router forward the packet to all the 130.99 subnets?  Is the same true
for network 130.99.0?
 
How would OSPF handle these networks?
 
On the surface, it seems that both network addresses are OK.  The routers
will determine with the help of the subnet mask that the "network" number
is 130.99.0 or 130.99.255.  Neither of these numbers are all 1's or 0's
which makes the network number valid and not a broadcast.
 
Which RFC explains this?  Is there more descriptive information in other
resources?
I am open to suggestions and hopefully answers.
 
Thank you in advance,
 
Ted Hacker,
3M Company.


-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 93 19:27:19 GMT
From:      dsc9hmr@bumed10.med.navy.mil (H. Mike Rice)
To:        comp.protocols.tcp-ip
Subject:   Re: How to start tuning a TCP/IP WAN ?

The best you can expect right now with 9600 baud with no network 
overhead would be 1200 bytes.  Actually, your point-to-point is
not all that bad considering X.25 and IP.  You said 'wired together'
is that via leased line or via a short haul ??  

You will get better response by replacing the short haul.  

Just a thought ....   :-)

-- rice
--
|                    H. Mike Rice    |    elf_______________________
| |  dsc9hmr@bumed10.med.navy.mil    |         Empowerment through
|_|_____    rice@access.digex.com    |             Education !
  |_______                           |______________________________

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Feb 1993 20:52:11 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet usage

Charles Ganzhorn (ccg@tcdsp1.mmm.com) wrote:
> Is it legal to have a class B subnet which is either all 1's or 0's?
> We have a class B network assigned our company.  Lets say it is 130.99.0.0 .
> We use RIP and a subnet mask of 255.255.255.0.  Can we assign the subnets
> 130.99.0 and 130.99.255?

This is illegal.  Both the "0" and "255" are illegal octets in a subnet
address.  Note that an octet having a one-bit subnet mask is also
illegal, and any subnet address for that octet will be either all ones
or all zeros, both of which are illegal.

- Steve Kao

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Feb 1993 21:01:33 GMT
From:      fmcgnnss@unix2.tcd.ie (Fergal Niall McGuinness)
To:        comp.protocols.tcp-ip
Subject:   Information on Multicasting



Can anybody point me to any public domain software or papers on the subject
of multicasting? I would appreciate any help.

Fergal

 
--
	Fergal McGuinness                             fmcgnnss@unix2.tcd.ie
	Dept. Of Microelectronic Engineering
	Trinity College Dublin
	Ireland.  

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 1993 21:43:11 GMT
From:      scoggin@delmarva.com (John K Scoggin Jr)
To:        comp.protocols.tcp-ip
Subject:   Re: Information on Multicasting

In article 729550893@unix2.tcd.ie, fmcgnnss@unix2.tcd.ie (Fergal Niall McGuinness) writes:
> 
> 
> Can anybody point me to any public domain software or papers on the subject
> of multicasting? I would appreciate any help.
> 
> Fergal
> 
>  
> --
> 	Fergal McGuinness                             fmcgnnss@unix2.tcd.ie
> 	Dept. Of Microelectronic Engineering
> 	Trinity College Dublin
> 	Ireland.  

Steve Deering did an interesting doctoral dissertation entitled "Multicast
Routing in a Datagram Internetwork".  It is available in PostScript form
from:

	System:		gregorio.stanford.edu
	Directory:	vmtp-ip
	Filenames:	sdthesis.part1.ps.Z, sdthesis.part2.ps.Z,
			sdthesis.part3.ps.Z

There is some code there as well.  

	- John

---
+---------------------------------------------------------------------+    
|  John K. Scoggin, Jr.			Email: scoggin@delmarva.com   |
|  Supervisor, Network Operations       Phone: (302) 451-5200         |
|  Delmarva Power & Light Company       Fax:   (302) 451-5321         |
|  500 N. Wakefield Drive               NOC:   (800) 388-7076         |
|  Newark, DE 19714-6066		                              |
|  The opinions expressed are not those of Delmarva Power, simply the |
|  product of an over-active imagination...                           |
+---------------------------------------------------------------------+


-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Feb 1993 21:59:46 GMT
From:      edm@harpo.dev.uga.edu (Ed Maioriello)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   MacTCP and TokenTalk -> 8209 -> Ethernet

Hi,

We'll here is another 8209 and Macintosh related question.  I'm trying
to get some Macs running the MacTCP version of NCSA Telnet on a 4Mbs
Token Ring (Apple NuBus 4/16 TR cards) to talk with IP hosts on an
Ethernet across an 8209 Lan Bridge.  The macs are varieties of the Mac
II family (all 030's) OS's 6.07-7.01, MacTCP v.1.1.1.

Thanks to responses to my previous postings I understand why AARP
doesn't function across 1 8209, but I'm wondering if there is some
reason why IP ARP doesn't function.  Is it that Telnet doesn't know what
to do with token ring, or is it that MacTCP is creating the packets in
such a way that the 8209 can't find the addresses in the data, or
something else.

When I try to connect using a IP name the connection will time out
trying to get to the Name Server which is on the ethernet.  Using an IP
number it times out trying to open the connection.  I believe in both
cases it is failing in the ARP process (or maybe sooner - while talking
to the TR card though no errors show up when loading Telnet).

Thanks in advance for any suggestions.  Please let me know if I need to
supply more details.

Ed Maioriello		       		            edm @ harpo.dev.uga.edu
University Computing & Networking Services   	    edm @ aisun1.ai.uga.edu
University of Georgia  ----------------------------------------------------
Athens, Ga. 30602      | First Rule of Troubleshooting: 
(706)-542-6462         |                     If it don't work - plug it in! 




-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Feb 93 22:22:57 GMT
From:      skibo@florida.wpd.sgi.com (Thomas Skibo)
To:        comp.unix.internals,comp.protocols.tcp-ip
Subject:   Re: Empirical comparison between SVR4 streams and BSD sockets

In article <2B7BE68E.28910@ics.uci.edu>, schmidt@net1.ics.uci.edu (Douglas C. Schmidt) writes:
|> Here's one data point that I gathered recently when testing our new
|> Solaris 2.1 configuration on sparcstation 2's using the standard ttcp
|> benchmarking utility.  I believe the Solaris 2.1 socket interface is
|> actually implemented as a set of library routines that run over top of
|> STREAMS.  Likewise, the Sun OS 4.1.2 socket interface runs over top of
|> the modified BSD network architecture.  Therefore, this should provide
|> a fairly reasonable platform to perform the tests.
|> 
|> I compiled ttcp on both platforms using cc -O.  The ttcp.c file
|> required a small amount of modification to run on Solaris.  I've
|> included the updated file below.
|> 
|> To get a rough idea of the "out-of-the-box" performance I simply
|> started the "receiver" side of ttcp using the "-r -s -f m" options on
|> a sparc2 running Solaris 2.1. and a sparc2 running SunOS 4.1.2.  I
|> then ran tests using the default "-r -s" sender options on two
|> different machines, each on the same Ethernet subnet.  The results
|> below are representative of the timings I obtained by running multiple
|> executions of the test:
|> 
|> ----------------------------------------
|> % solaris.ttcp -r -s -f m
|> ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
|> ttcp-r: socket
|> ttcp-r: accept from 128.195.4.82
|> ttcp-r: 16777216 bytes in 16.00 real seconds = 8.00 Mbit/sec +++
|> ttcp-r: 2976 I/O calls, msec/call = 5.51, calls/sec = 186.00
|> ttcp-r: 0.8user 5.5sys 0:16real 39%
|> 
|> % sunos.ttcp -r -s -f m
|> ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
|> ttcp-r: socket
|> ttcp-r: accept from 128.200.38.14
|> ttcp-r: 16777216 bytes in 21.00 real seconds = 6.10 Mbit/sec +++
|> ttcp-r: 11494 I/O calls, msec/call = 1.87, calls/sec = 547.33
|> ttcp-r: 0.2user 4.6sys 0:21real 23%
|> ----------------------------------------
|> 
|> The results are interesting since the Solaris/STREAMS version
|> significantly outperforms the SunOS/BSD version.  A bit of
|> experimentation using truss and trace indicated one plausible
|> explanation.  It appears that the STREAMS implementation typically
|> received incoming buffers in 8192 byte chunks, whereas the BSD
|> implementation was restricted to 4096 byte chunks (i.e., their default
|> TCP window/buffer size in the receiver).  Note also that the number of
|> I/O calls is *much* greater for the Sun OS version!
|> 
|> By expanding the -b (system buffer size) and -l (application buffer
|> size) options to around 32k I was eventually able to get both versions
|> to operate at around 8.53 Mbit/sec on average (out of a theoretical
|> maximum of 10 Mbit/sec on Ethernet, which is pretty good I believe).
|> 
|> My conclusion from this experiment are that the overhead from using
|> the STREAMS subsystem does not appear to be significant compared with
|> the original BSD network architecture.  In fact, by default the
|> STREAMS-based version is actually significantly faster, probably due
|> to using larger buffering/window sizes in the implementation.
|> 
|> I'd be interested to know whether anyone else has found the same
|> behavior and/or whether my conclusions are justified!

okay.

I kind of wish you would have posted the ttcp output for the tests where
you achieved full Ethernet bandwidth.  I'd like to see the percent CPU.
This would tell us which implementation worked harder to provide full
Ethernet bandwidth.
   
If you take the percent CPU in the first results above and divide by the
data rate achieved, you get 4.9% CPU / Mbit/s  for STREAMS and
3.8% CPU / Mbit/s for sockets.  I'm inclined to argue that the
socket implementation is slightly more efficient, even with
all the extra system calls (looks like the sockets were returning 1460
bytes/call [ethernet packet size] vs. 5637 [?!] bytes/call for the STREAMS).

I'd really like to see these comparisons on FDDI or HIPPI!


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

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Feb 1993 09:23:29 GMT
From:      queloz@bernina.ethz.ch (Ronald Queloz)
To:        comp.protocols.tcp-ip
Subject:   XTI for HP-UX HP Series 9000/700

Hi Netlanders,

does anybody know if there is an implementation of XTI, on top of TCP/IP,
for HP-UX on HP Series 9000/700?

Thanks in advance for any information.


Ron.

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Feb 1993 13:48:01 GMT
From:      edwards@world.std.com (Jonathan Edwards)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: DCE COMPLIANT ? (somewhat long)

In article <1993Feb9.135627.8390@leland.Stanford.EDU> dcrocker@leland.Stanford.EDU (Dave Crocker) writes:
>This thread has wandered into the realm of defining "open", a topic dear
>to my heart, so I thought I would offer the view I wrote in my chapter
>on the IETF standards process in the Internet Systems Handbook:
>
>    Open Publication
>    Open Ownership
>    Open Development
>

In my experience, "open" = "sells like PC's".
Thats the way I see most people using the word.



-- 
Jonathan Edwards				edwards@intranet.com
IntraNet, Inc					617-527-7020

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 93 18:45:39 GMT
From:      guy@Auspex.COM (Guy Harris)
To:        comp.unix.internals,comp.protocols.tcp-ip
Subject:   Re: Empirical comparison between SVR4 streams and BSD sockets

>I believe the Solaris 2.1 socket interface is
>actually implemented as a set of library routines that run over top of
>STREAMS.

It's a set of library routines, plus a "sockmod" STREAMS module, that
run on top of STREAMS-and-TPI-based transport providers.  See
"Implementing Berkeley Sockets in System V Release 4", in the Winter
1990 USENIX proceedings.

>The results are interesting since the Solaris/STREAMS version
>significantly outperforms the SunOS/BSD version.

Note that, from what people at Sun have told me, the SunOS 5.x Internet
protocol implementation is not derived from the BSD Internet protocol
implementation; that may account for some of the performance differences
seen.

>% solaris.ttcp -r -s -f m

	...

>ttcp-r: 16777216 bytes in 16.00 real seconds = 8.00 Mbit/sec +++
>ttcp-r: 2976 I/O calls, msec/call = 5.51, calls/sec = 186.00
>ttcp-r: 0.8user 5.5sys 0:16real 39%
>
>% sunos.ttcp -r -s -f m

	...

>ttcp-r: 16777216 bytes in 21.00 real seconds = 6.10 Mbit/sec +++
>ttcp-r: 11494 I/O calls, msec/call = 1.87, calls/sec = 547.33
>ttcp-r: 0.2user 4.6sys 0:21real 23%

It might be interesting to run profiled (and statically linked, so that
library routine time - which should include time in system calls - can
be included in the profile) versions of "ttcp" in both cases, to see
where the extra CPU time is being spent in the SunOS 5.x version. 

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Saturday, 13 Feb 1993 23:52:13 EST
From:      <SURU@TWNMOE10.BITNET>
To:        comp.protocols.tcp-ip
Subject:   current work on IP address space

Dear Netter,

    Can anyone describe current work of IETF on expanding IP address
space or point me to other reference? Thanks. Please reply me
privately.

--Liu Zi-Di


-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Feb 1993 02:40:14 GMT
From:      rypma@waterloo.hp.com (Ted Rypma)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP using BOOTP to resolve IP address

Anthony Kolasny (tkolasny@scholia.wbme.jhu.edu) wrote:

: I have been successful using NCSA Telnet,  NUPop 1.03,  and other applications
: through SLIP with the IP specified. When I use BOOTP to get the lines IP 
: address, I get a time out error.
:
: [stuff deleted]
:
: where ha=0800200771b2 is the SLIP's host hardware address.

The function [actually, one of many] of bootp in this case is to map a link
level address (LLA) to an IP address. The fatal flaw in your attempt is
that a SLIP interface _has_no_LLA_ and cannot therefore send one.!

Bootpd wants to map incoming LLA's to a table entry with other parameters
and the incoming bootp client request from the SLIP connected machine has
no LLA - game over.

I don't know of any, but perhaps there are specially modified versions of
bootpd out there that will broadcast a reply to the interface that sent the
request using some other lookup value?

The best solution to this problem (negotiating parameters) that I know
of is PPP :-)

Ted Rypma
HP Panacom Division
Waterloo, Ontario

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 93 04:52:44 GMT
From:      redi@dynamics.bu.edu (Jason Redi)
To:        comp.protocols.tcp-ip
Subject:   Dialin SLIP through annex

Hi!
	I was wondering if anyone has had any experiences with establishing
a SLIP connection through an annex modem pool.  When I telnet to our
machine from the annex, I execute slattach /dev/ttyp0 (AIX OS).  The machine
then says that it was successful opening the slip line and punts me back to
the annex.
	I don't know how to get the AIX machine and annex to keep 
communicating, even after my slattach command takes the  device from telnet.
	Any ideas?

		Thanks,
			J

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Feb 1993 05:33:34 GMT
From:      johnson@tigger.jvnc.net (Steven L. Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re: Assignment of IP address across multiple subnets (bootp?)

rich@grebyn.com (Richard Lawrence) writes:

>johnson@tigger.jvnc.net (Steven L. Johnson) writes:

[my suggestion for using the giaddr field in the bootp request
 packet to assist in determining a/the valid host address and/or
 config, deleted]

>I could see where you could determine the network address that the
>machine had been moved to, but how are you going to guess at a host
>address? Any testing method you could use would be prone to error due to
>machines that were turned off at the time of the test.....

The incoming bootp request still has the hardware (ethernet) address
of the requesting machine.  The network address could be used to
disambiguate between multiple possible entries for that machine in
a bootp table by matching the network address of the gateway machine
against the ip address in the table.  This would require an entry in
the table for every machine for every subnet that it could appear on.

I suspect your comment above is with respect to dynamic ip address
assignment.  Dynamic address assignment from a pool of addresses
is a separate issue from initially determining which pool of addresses
are valid for the particular subnet from which the original bootp
request was sent.  There are systems that do dynamic assignment, but
the ones that I've heard of require a separate bootp server on each
subnet.  With respect to the specific issue you raise, a pool of
addresses are reserved for the dynamic allocation procedure.  If
a machine that was using a dynamic address was turned off, it will obtain
a new address when it is turned back on.  I'll leave it to those
who actually have run these type of systems to comment further
on address reuse algorithms that attempt to minimize similar problems.

The method I suggested before may be able to consolidate these
multiple bootp dynamic servers into one single centralized bootp
server.  Perhaps this has already been done.  There may be more
specific information in the drafts from the dynamic host configuration
working group (dhc) or from someone on that working group.

-Steve
 Disclaimer: I may have no idea what I'm talking about.

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Feb 1993 11:38:28 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.unix.internals,comp.protocols.tcp-ip
Subject:   Re: Empirical comparison between SVR4 streams and BSD sockets

skibo@florida.wpd.sgi.com (Thomas Skibo) writes:

>I kind of wish you would have posted the ttcp output for the tests where
>you achieved full Ethernet bandwidth.  I'd like to see the percent CPU.
>This would tell us which implementation worked harder to provide full
>Ethernet bandwidth.
>   
>If you take the percent CPU in the first results above and divide by the
>data rate achieved, you get 4.9% CPU / Mbit/s  for STREAMS and
>3.8% CPU / Mbit/s for sockets.  I'm inclined to argue that the
>socket implementation is slightly more efficient, even with
>all the extra system calls (looks like the sockets were returning 1460
>bytes/call [ethernet packet size] vs. 5637 [?!] bytes/call for the STREAMS).

If the ttcp used is the derived from the ttcp sources floating around
it will use sockets on top of streams rather than just streams.
If you want to test sockets vs STREAMS you'd have to write a ttcp
that uses STREAMS and nothing else.

Casper

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 1993 19:25:14 +1030
From:      hart@flash.pax.tpa.com.au (Leigh M Hart)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Using slipper.exe between two PC's - what's not right?

I'm trying to find out if slipper.exe is what I want to use to connect
via slip to my host.  I threw two PC's together with a nul modem cable
and ran the slipper packet driver on both machines.  I tried to establish
some sort of communication between the two pc's but to no avail.

As far as I can tell the tcp/ip package I'm using isn't talking
to the packet driver for some reason.. slipper uses vector $60 btw

any ideas would be appreciated :)

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

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Feb 1993 13:46:23 GMT
From:      dan@dribble.c-mols.siu.edu (Dan Ellison)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: MacTCP and TokenTalk -> 8209 -> Ethernet

In <C2Cvrn.MB7@harpo.dev.uga.edu> edm@harpo.dev.uga.edu (Ed Maioriello) writes:

>Hi,
 
>We'll here is another 8209 and Macintosh related question.  I'm trying
>to get some Macs running the MacTCP version of NCSA Telnet on a 4Mbs
>Token Ring (Apple NuBus 4/16 TR cards) to talk with IP hosts on an
>Ethernet across an 8209 Lan Bridge.  The macs are varieties of the Mac
>II family (all 030's) OS's 6.07-7.01, MacTCP v.1.1.1.
 
>Thanks to responses to my previous postings I understand why AARP
>doesn't function across 1 8209, but I'm wondering if there is some
>reason why IP ARP doesn't function.  Is it that Telnet doesn't know what
>to do with token ring, or is it that MacTCP is creating the packets in
>such a way that the 8209 can't find the addresses in the data, or
>something else.
 
>When I try to connect using a IP name the connection will time out
>trying to get to the Name Server which is on the ethernet.  Using an IP
>number it times out trying to open the connection.  I believe in both
>cases it is failing in the ARP process (or maybe sooner - while talking
>to the TR card though no errors show up when loading Telnet).
 
>Thanks in advance for any suggestions.  Please let me know if I need to
>supply more details.

I have been successful in getting Mac's and PC's to run accross an 8209
bridge.  The machines in my case were on the ethernet side and the TR
was connecting the building backbone.  One thing that was necessary was to
insure the these machine were running 802.3 protocol (802.2 in your case.)
The bridge will not properly format a TokenTalk packet for bridging.

The ARP problem is another thing all together.  It was quite frustrating
to try to set up an 8209 on a subnet that has another router on it.  The
ARPs never get responded to as the bridge sees only what is directly
connected to it.  One possibility might be to place static ARP entries
into the 8209.  I'd try turning off the TokenTalk first though and see if 
this doesn't do it for you.  Good luck.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Dan Ellison, Network Spec 	  -    	Computing Affairs, SIU-C 	| 
| Southern Illinois University 	  - 	Carbondale, IL 62901            |   
| FAX:      (618) 453-3459        -   	PHONE:    (618) 453-6149 	|     

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Feb 1993 17:02:17 GMT
From:      senturia@bio4.csuohio.edu (J B Senturia)
To:        comp.protocols.tcp-ip
Subject:   Arcnet <--> Ethernet


We have acquired a Tandy 6000 with an arcnet interface.  Is there
a way to communicate with our "ethernet" TCP/IP system.  the 
computer runs the Xenix flavor of Unix, while all of our other computers
on the same subnet use Unix System V release 3.? and WIN/TCP/IP.  these
computers all connect to a Thick coax network, with connection to the
campus backbone via fiber -- local cannections to the Thick coax are
via utp, thin coax as well as direct AUI connections to the Thick
coax.  Any ideas would be appreciated,

Thanks,
--
Jerome B. Senturia  | Internet: senturia@bio4.csuohio.edu
Dept. of Biology    | uucp:{uunet}!cwjcc!ncoast!csubio!senturia
Cleveland St. Univ. | Voice: (216)687-2411   Fax: (216)687-5443
Cleveland, OH 44115 | "I didn't do it and I won't do it again."

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Feb 1993 20:18:20 GMT
From:      peram@eceyv.ncsu.edu (Peram Marimuthu)
To:        comp.protocols.tcp-ip
Subject:   Problems with LAN

For one of my projects, I need to know the various problems 
associated with LANs or WANs. For example, I know that in 
my network two machines had the same IP address and because
of that one machine could not establish a telnet session.
Did you experience any such problems? Please let me know.
I will summarize if there is sufficient interest.

peram

peram@eceyv.ncsu.edu



-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Feb 1993 21:13:13 GMT
From:      ckd@eff.org (Christopher Davis)
To:        comp.protocols.tcp-ip
Subject:   Re: Moving from coax to 10BaseT

K> == Kral  <braun@dri.com>

 K> Finally, if the budget permits, it is best to run 2-4 twisted pair
 K> cables to each station.  This costs a lot more up front [...]

It doesn't cost twice as much to run twice as many pairs to each office.
Wire is cheap, labor after the fact is not.  We recently moved into new
space and as part of that ran 8 pairs from the phone closet to every
workstation (2 pairs for phones, 2 pairs for 10T, and 4 pairs for future or
other use).
--
* Christopher Davis * <ckd@eff.org> * <ckd@kei.com> * [CKD1] * MIME * RIPEM *
226 Transfer complete. 17512509 bytes received in 5.2e+02 seconds (33 Kbytes/s)

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Feb 93 21:45:02 GMT
From:      darron@comtech.ct.oz.au
To:        comp.protocols.tcp-ip
Subject:   Request for Information


I am preparing a presentation to a technical forum on TCP/IP. 
Currently I have no printed reference matter to provide to the delegates
and I would appreciate any comprehensive papers that any one has
that I can distribute to the delegates.

This is a non profit forum for technical information.

Thanks in advance

Darron Lonstein
Comtech Technical Services Director


-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Feb 1993 09:12:14 GMT
From:      sxn9307@ucs.usl.edu (Nadimpalli Sanjay)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   internet header info


Could someone throw light on this:

In the Internet Header, a byte is used for TYPE OF SERVICE.  
I wanted to know what kind of information is being (or has been)
stored in that byte?

Thanks in advance

Sanjay

e-mail:  sanjay@ucs.usl.edu

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Feb 1993 09:38:26 GMT
From:      loneshay@csie.nctu.edu.tw (Lone Shay)
To:        comp.protocols.tcp-ip
Subject:   RAW SOCKET call


Hi all:
I need to know how to use a RAW socket to send data.
I have the super user privilege. But the data I sent
are reported : message too long...
Anyway, I cannot transmit any data out.
I use sendto to transmit. Is there anything special
for a Raw Socket ?

Help. Help. My advisor is pushing me so hard....

Lone Shay
Email: loneshay@csie.nctu.edu.tw

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Feb 1993 15:35:48 GMT
From:      matheys@online.cern.ch (Jean-Pol Matheys)
To:        comp.protocols.tcp-ip
Subject:   When Should SIGPIPE Be Generated ?


Dear Net,

I have a client talking to a server over a TCP/IP socket using simple write()
calls.  If the server crashes (presumably not closing the socket),  the first
write() call thereafter is still successful, and I do not get SIGPIPE until a
second write() call is made to write on that socket. Is this the expected and
usual behavior ?  I somehow expected a SIGPIPE some time after the very first
write() (e.g. a few seconds thereafter), but it doesn't come.  With KEEPALIVE
on, the same happens.  I cannot say SIGPIPE never comes, but I waited for six
minutes and it didn't come ...

Do I miss something ?

In case it matters,  my client is on an Ultrix 4.2A machine and the server is
on an OS-9 2.4 system.

--
Jean-Pol Matheys

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


-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Feb 1993 18:09:44 GMT
From:      fox@wubios.wustl.edu (Dave Fox)
To:        comp.protocols.tcp-ip
Subject:   IPX to TCP/IP migration



I am posting this for a friend that wants information on any net 
traffic or information on IPX to TCP/IP migration.  He is looking
especially for any experience in comparing library calls.


PS.  Does anyone know of a newsfeed in the CEDAR RAPIDS, IA area.


Please e-mail me any info.  .  

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Feb 1993 18:34:30 GMT
From:      ychen4@eos.ncsu.edu (YINGYING  CHEN)
To:        comp.protocols.tcp-ip
Subject:   ask for a ftp site containing OSPF routing protocol


Keywords: Open Shortest Path First (OSPF) routing protocol

     Please help me.
     Does anybody know a FTP archive cite that has the RFC for Open Shortest
Path First (OSPF) routing protocol?
     I got to know the OSPF routing protocol as soon as possible.
     Please send the FTP address to my E-mail address.
     My address is : ychen4@eos.ncsu.edu
     Thanks a lot.
                                --Yingying

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 93 18:46:44 GMT
From:      spoelhof@kodak.com (Gordon Spoelhof)
To:        comp.sys.m68k,comp.protocols.tcp-ip
Subject:   Slow network transmit speed on pNA+ (?)

I am experiencing slow TCP/IP transmit rates using Integrated System's pNA+ 
product on the Motorola 167 board.  Although I did not expect parity between 
transmit (330KB/sec) and receive rates (830KB/sec), the difference is too 
large to ignore.  I am using a Sun IPX as the network partner.  All transfers 
are large (2MB) and are measured memory-to-memory.  Window sizes on each host 
are set to 32KB.

I have allocated a fairly generous share of memory to both ethernet driver 
(244KB packet storage) and TCP/IP buffer space (800KB MBUF and 1K buffers 
pools).

LAN analyzer seems to indicate few if any dropped packets (from Motorola 167) 
but large ACK turnaround time (30 millisecond) from the Sun.

Has anyone else noticed behavior similar to this?

Any pointers helpful!

Please respond to spoelhof@kodak.com

Thank - you


Gordon Spoelhof
Eastman Kodak Company / Health Sciences Division
Mailcode 2/8/C 39105 
100 Carlson Road / Rochester, NY 14653-9105
Email: spoelhof@kodak.com
Phone: 716-253-9735 / FAX: 716-253-7966

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Feb 1993 18:52:46 GMT
From:      ychen4@eos.ncsu.edu (YINGYING  CHEN)
To:        comp.protocols.tcp-ip
Subject:   Asking for an FTP site having the OSPF routing protocol



    Please help me!!!
    Does anybody can send me the address of an FTP archive cite that has the 
RFC for Open Shortest Path First (OSPF) routing protocol?
    I got to know the OSPF routing protocol as soon as possible.
    I really appriciate your help.
    Here is my address: ychen4@eos.ncsu.edu

                           --Yingying

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Feb 1993 19:00:38 GMT
From:      smoore@unity.ncsu.edu (Sam Moore)
To:        comp.protocols.misc,comp.protocols.ibm,comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Request information about manufacturing protocols


Where can I get on-line information about manufacturing protocols?
What protocols are being used? I have seen references to MAP and TOP.
Are the being used? Is there anything in the public domain that runs
under Unix?

I am looking at a project where I will be interfacing a Unix
workstation with some manufactuing equipment. I will be getting the
information from the interfaced workstation to other workstations
using a homebrew TCP application level protocool. If there is a
standard messaging protocol and/or a data definition that exists, then
I will use it.

Thanks,

Sam

-- 
............................................................................
...Sam Moore...............................Computer Operations..............
...Mail:  Sam_Moore@ncsu.edu...............College of Textiles..............
...Phone: +1 (919) 515-6594................North Carolina State University..

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 1993 21:55:17 GMT
From:      rfrink@meaddata.com (Rick Frink)
To:        comp.protocols.tcp-ip
Subject:   TTCP Usage

   Does anybody have a lead on a manual page or usage guidelines
 for the ttcp utility ?  Thanks.

-- 
Rick Frink                                              (513) 865-1645
Mead Data Central                             Telecomm/Campus Networks
P.O. Box 933                                       rfrink@meaddata.com
Dayton, Ohio  45401                          ...!uunet!meaddata!rfrink

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 93 00:18:03 GMT
From:      ken@sugra.uucp (Kenneth Ng)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: DCE COMPLIANT ? (somewhat long)

In article <C2E3o3.99A@world.std.com: edwards@world.std.com (Jonathan Edwards) writes:
:In article <1993Feb9.135627.8390@leland.Stanford.EDU> dcrocker@leland.Stanford.EDU (Dave Crocker) writes:
:>This thread has wandered into the realm of defining "open", a topic dear
:>to my heart, so I thought I would offer the view I wrote in my chapter
:>on the IETF standards process in the Internet Systems Handbook:
:>    Open Publication
:>    Open Ownership
:>    Open Development
:In my experience, "open" = "sells like PC's".
:Thats the way I see most people using the word.

The way I have seen it, "open" refers to "my" equipment, "propierity" and
"closed" refer to my competition.  Just like "natural" refers to my stuff,
and "artifical" refers to my competition in the food arena.

-- 
Kenneth Ng
Please reply to ken@eies2.njit.edu for now.
"All this might be an elaborate simulation running in a little device sitting
on someone's table" -- J.L. Picard: ST:TNG

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Feb 1993 03:10:25 GMT
From:      loneshay@csie.nctu.edu.tw (Lone Shay)
To:        comp.protocols.tcp-ip
Subject:   Raw Socket Usage

Hello World:
I am trying to access network in a lower layer in order to test
the raw throughput of FDDI. My test bed consists of 2 Sun SPARC
II, linked with both Ethernet and FDDI.

The problem is:
I use raw socket call to bypass TCP layer, but I cannot receive
any thing on the network. Is there anybody familiar with
raw socket call could give me some information about how to use
a raw socket to transmit and receive ?

Any tiny experience will be appreciated. Thanks a lot.

Lone Shay
Internet: loneshay@csie.nctu.edu.tw 


-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Feb 1993 04:40:53 GMT
From:      ssc4334@ucs.usl.edu (Chintalapati Shyam S)
To:        comp.protocols.tcp-ip
Subject:   A question about handling of Gateway crashes !!

hi, 

	Once a default gateway is down, the host times out the connection and assumes
that the default gateway is down.  If there is more than one default gateway
host starts sending further datagrams to the alternative default gateway. Now,
suppose that this gateway determines that the crashed gateway is a better route.
It sends an ICMP redirect message to the host telling it to use the crashed 
gateway.  Then, this results in the host again trying to transmit to the crashed
gateway and timing out. If it has an entry saying this gateway has currently
crashed, it can ignore the redirect message, but still the alternative default
gateway keeps sending "redirects" to the host. In practice, how this problem is solved?

	I am sorry if this is an FAQ or if this is not a proper place to ask
this question.

	Thanks in advance,
------
shyam

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Feb 93 11:12:55 CST
From:      C581176@mizzou1.missouri.edu (Pankaj Gulati)
To:        comp.protocols.tcp-ip
Subject:   RFC on ICMP

Hi Netter,
I need the RFC for ICMP. Pls. tell me where to get it from.
Thanks,
Pankaj.
c581176@mizzou1.missouri.edu
gulati@cyclone.cs.missouri.edu

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Feb 1993 05:24:04 GMT
From:      bzs@world.std.com (Barry Shein)
To:        alt.books.technical,rec.arts.books,wstd.general,comp.protocols.tcp-ip,biz.books.technical,misc.books.technical
Subject:   OBS: Chapter 3 of The Internet Companion Available for Anon FTP



				   
			     Tracy LaQuey
				   
			    Editorial Inc.
				   
			 Software Tool & Die
				   
				 and
				   
		      The Online BookStore (OBS)
				   
		       Are Pleased To Announce
				   
			Another Installment Of
				   

			The Internet Companion


The Online BookStore (OBS) continues with their first simultaneous
electronic and print publication of a major new book: The Internet
Companion: A Beginner's Guide to Global Networking by Tracy LaQuey
with Jeanne C. Ryer (Addison-Wesley, $10.95).

Online copies of Vice-President-elect Al Gore's Foreword and the first
three chapters of this best-selling book are available via anonymous
FTP from:

			    world.std.com

in the directory:

		     /OBS/The.Internet.Companion/

Further chapters will be released in the future. See the README and
COPYRIGHT files in that directory for more details. Direct comments
and questions about the book to:

		   internet-companion@world.std.com

This pioneering effort is a step in bringing together the on-line
electronic and print media, enabling authors to explore new avenues of
publishing their works. Comments, inquiries, etc. welcome: Send to
obs@world.std.com.

-- 
        -Barry Shein

Software Tool & Die    | bzs@world.std.com          | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Feb 1993 06:17:38 GMT
From:      ae2@cunixa.cc.columbia.edu (Amiran Eliashvili)
To:        comp.protocols.tcp-ip
Subject:   overriding the queuelen in listen(2)


Hi all:

I was wondering if there is a way to increase the maximum length of
the queue of pending connections when using listen(socket, queuelen).
Currently, the man pages states that queue could not be more than five
requests. Has anyone hacked this or can guess how to go about
modifying or enhancing this ? ANy comments will be much appreciated.
Thanks.

Please reply to : ae2@cunixa.cc.columbia.edu
thanks
/amiran

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Feb 1993 08:41:23 GMT
From:      alan@csie.nctu.edu.tw (Lone Shay)
To:        comp.protocols.tcp-ip
Subject:   Raw Socket Usage

Hello World:

I'd like to access network in a lower layer. So I use raw socket to bypass
TCP layer. I have super user privilege. My test bed consists of 2 Sun SPARC
2 workstations connected with both Ethernet and FDDI.

My problem is:

I cannot receive any messages I sent out. Is there any subtle technique when 
using Raw Socket to transmit and receive ?

Any information is appreciated. 
Thanks a lot.

Lone Shay
Email: loneshay@csie.nctu.edu.tw


-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1993 09:44:05 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: A question about handling of Gateway crashes !!

In article <1993Feb16.044053.17614@usl.edu> ssc4334@ucs.usl.edu (Chintalapati Shyam S) writes:
>	Once a default gateway is down, the host times out the connection and assumes
>that the default gateway is down.  If there is more than one default gateway
>host starts sending further datagrams to the alternative default gateway. Now,
>suppose that this gateway determines that the crashed gateway is a better route.
>It sends an ICMP redirect message to the host telling it to use the crashed 
>gateway.  Then, this results in the host again trying to transmit to the crashed
>gateway and timing out. If it has an entry saying this gateway has currently
>crashed, it can ignore the redirect message, but still the alternative default
>gateway keeps sending "redirects" to the host. In practice, how this problem is solved?

Routers are supposed to use a gateway-to-gateway protocol (GGP) to keep
track of each other, so that they don't send redirects to dead gateways.
There will, of course, be a period of time before the alternative gateway
realizes that the primary gateway is down, so this will happen for a while.
But eventually the alternative gateway should stop sending the erroneous
redirects.

Good GGP's are designed so that they discover gateway failures and compute
new routes connections time out, and well-behaved transport and application
protocols should be tolerant of temporary network failures during these
changeover periods.  This is why the TCP specs say that its default timeout
should be large (hours, not seconds).  Unfortunately, this conflicts with
applications that want to know "immediately" when the host at the other end
of a connection crashes (at the application and transport layers it's often
difficult to distinguish network/gateway failures from host failures --
they all look like timeouts).

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 93 11:09:39 GMT
From:      Sam.Wilson@ed.ac.uk
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: Hesiod Class and Problems with Zone X'fer

mshah@next3.corp.mot.com writes:
> ... So can you please tell me why SUN translates an "HS" class record  
> when it gets a zone x'fer in an erroneous way or if something else may be  
> wrong. Also any info. on class HS will be helpful.

This is a known problem with the way BIND (Sun's named is actually BIND)
handles non-IN class information - it leaks and gets it all mixed up
with the IN class RRs.  You need a modified copy of bind.  I know of at
least two versions that fix this, one is George Ross's
(gdmr@dcs.ed.ac.uk) 4.8.3+ with the HSprimary and HSsecondary
extensions, and at least one other person has done similar extensions. 
These particular fixes are not, I believe, in Paul Vixie's 4.9, but
might well be in 4.9.x. 

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

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 93 12:39:57 GMT
From:      ian@ukpoit.co.uk (Ian Spare)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet usage

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

Although I agree with you I'd like to point out that people do indeed use 
0 as an address part, to my dismay someone here set up a LAN as
147.77.0.h where h is host part. They report no problems with this network 
which consists of one HP-9000 and 30 or so PC's. I'm keen to look at the LAN 
with an analyser but they get all defensive when this is mentioned !!




-- 
Ian Spare , iT , Barker Lane , CHESTERFIELD , DERBYS , S40 1DY , GREAT BRITAIN
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      iT - The Information Technology Business Of The Post Office
~~~~~~~~~~~~~~~~~~~~~~~  In Tune With Technology ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Feb 1993 13:10:43 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: overriding the queuelen in listen(2)

>I was wondering if there is a way to increase the maximum length of
>the queue of pending connections when using listen(socket, queuelen).
>Currently, the man pages states that queue could not be more than five

Sure, there are two ways to do it.  (1) Change the constant SOMAXCONN in
the header sys/socket.h and recompile your kernel :-)  (2) If your system
is BSD-derived, use a debugger and find the instructions corresponding to

	if (backlog < 0)
                backlog = 0;
        so->so_qlimit = min(backlog, SOMAXCONN);
        splx(s);
        return (0);

at the end of the function solisten(), and patch the instructions accordingly.

Other than that, it's not reconfigurable (in the systems I've seen at least).

	Rich Stevens  (rstevens@noao.edu)

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Feb 1993 17:06:10 GMT
From:      j_pan@ranger.enet.dec.com (Joanna Pan)
To:        comp.protocols.tcp-ip
Subject:   Re: Raw Socket Usage


In article <C2Iu5D.Erw@csie.nctu.edu.tw>, loneshay@csie.nctu.edu.tw (Lone Shay) writes...
>Hello World:
>I am trying to access network in a lower layer in order to test
>the raw throughput of FDDI. My test bed consists of 2 Sun SPARC
>II, linked with both Ethernet and FDDI.
> 
>The problem is:
>I use raw socket call to bypass TCP layer, but I cannot receive
>any thing on the network. Is there anybody familiar with
>raw socket call could give me some information about how to use
>a raw socket to transmit and receive ?
> 
>Any tiny experience will be appreciated. Thanks a lot.
> 
>Lone Shay
>Internet: loneshay@csie.nctu.edu.tw 
> 

Use sendto() and recvfrom() socket calls send/receive on raw socket.

_______________________________________________________________________________
!	Joanna Pan							      !
! 	Personal Computer Systems Group					      !
!	Digital Equipment Corporation					      !
!	Littleton, Massachusetts					      !
-------------------------------------------------------------------------------

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 93 17:23:18 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet usage

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

Note that the use of all 0's and all 1's for the subnet part has been made
illegal mostly by decree rather than technical requirements.  Disallowing
these values for both the host part and the subnet part avoids a lot of
ambiguity in both the code and in address adminsistration.  But there are
implementations out there that will accept and even work properly, under the
right circumstances, if these rules are broken (definitely not recommended
though).

A good reference is RFC-1122, section 3.2.1.3 Addressing:.

Art

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 93 17:40:05 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.dcom.lans,comp.dcom.lans.ethernet,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.sys.novell,comp.dcom.lans.novell,bit.listserv.novell
Subject:   3c509 packet driver release 10.1

The 3c509 packet driver has been officially released at version 10.1.
All the beta test copies have been 10.0, so if you have one, please
upgrade to 10.1.  The driver is in 3c509a.zip and is (will be) on all
your favorite FTP/UUCP/BBS sites:

Please report problems.  I cannot guarantee that I will work on your
problem if you are not a Crynwr customer.  I CAN guarantee that I
will not work on it if you don't report it to me.  Written reports
are preferred to phone calls.

-- HOWTOGET.IT

		The Crynwr packet driver collection

Availability

The Crynwr packet driver collection is available by mail, by FTP, by
email, by UUCP and by modem.  The drivers are distributed in three files:
drivers.zip, which contains executables and documentation,
drivers1.zip, which contains the first half of the .ASM files, and
drivers2.zip, which contains the second half of the .ASM files.

Mail:

Columbia University distributes packet drivers by mail.  The formats
are 9-track 1600 bpi tapes in ANSI, tar, or OS SL format, or PC
diskettes (360K 5.25" and 720K 3.5").  The exact terms and conditions
have yet to be worked out, please call (212) 854-3703 for ordering
information, or write to:

  Kermit Distribution, Dept PD
  Columbia University Center for Computing Activities
  612 West 115th Street
  New York, NY  10025

or send e-mail to kermit@watsun.cc.columbia.edu (Internet) or
KERMIT@CUVMA (BITNET/EARN).


FTP/email:

The packet driver collection has its own directory devoted to it on
simtel20.army.mil, pd1:<msdos.pktdrvr>.  The drivers are there, along
with many free programs that use the packet drivers.

SIMTEL20 files are also available by anonymous ftp from mirror sites
OAK.Oakland.Edu (141.210.10.117), wuarchive.wustl.edu (128.252.135.4),
ftp.uu.net (137.39.1.9), nic.funet.fi (128.214.6.100), src.doc.ic.ac.uk
(146.169.3.7), nic.switch.ch (130.59.1.40), archie.au (139.130.4.6),
nctuccca.edu.tw (140.111.3.21), by e-mail through the BITNET/EARN file
servers.

Modem:

If you cannot access them via FTP or e-mail, most SIMTEL20 MSDOS
files, including the PC-Blue collection, are also available for
downloading from Detroit Download Central (313) 885-3956.  DDC
has multiple lines which support 300/1200/2400/9600/14400 bps
(103/212/V22bis/HST/V32bis/V42bis/MNP).  This is a subscription system
with an average hourly cost of 17 cents.  It is also accessable on
Telenet via PC Pursuit and on Tymnet via StarLink outdial.  New files
uploaded to SIMTEL20 are usually available on DDC within 24 hours.

CD-ROM:

Public, private or corporate institutions and libraries interested in
the SIMTEL20 MS-DOS collection in CD-ROM format bundled with library
card-catalog type access and duplication software can contact Coyote
Data, Ltd. by mail at 1142 N. Main, Rochester, MI 48307 or by FAX at
(313) 651-4071.  Others who do not need the access and duplication
software should send e-mail to: rab@cdrom.com (Robert Bruce), telephone
(800) 786-9907 or (510) 947-5996, or FAX (510) 947-1644 for details on
his CD-ROM offer.


UUCP:

The packet driver files are available from UUNET's 1-900-GOT-SRCS, in
uunet!~/systems/msdos/simtel20/pktdrvr.  Contact UUNET for more details:

UUNET Technologies, Inc.
3110 Fairview Park Drive, Suite 570
Falls Church, VA 22042
+1 703 204 8000 (voice)
+1 703 204 8001 (fax)
info@uunet.uu.net

-- end of HOWTOGET.IT

-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Feb 1993 18:34:36 GMT
From:      stewart@oin.cis.udel.edu (John Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC on ICMP

In article <16B779DB7.C581176@mizzou1.missouri.edu> C581176@mizzou1.missouri.edu (Pankaj Gulati) writes:
>Hi Netter,
>I need the RFC for ICMP. Pls. tell me where to get it from.
>Thanks,
>Pankaj.
>c581176@mizzou1.missouri.edu
>gulati@cyclone.cs.missouri.edu

FTP to ftp.nisc.sri.com and get rfc/rfc792.txt.

/jws

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Feb 1993 19:32:31 GMT
From:      estrella@cass.ma02.bull.com (Gustavo Estrella)
To:        comp.protocols.tcp-ip
Subject:   Re: Programming TCP-IP in Windows 3.1 !!!!!

I am interested in writing some programs that use TCP/IP connection from
within windows 3.1.  I have picked up a copy of the WINWATCP library
but have not had a chance to test it yet.

Is any one out there experienced with this library?  Are there copy of the 
actual LIB files floating around ?(Rather than the just the source.).

Any information will be appreciated.  Thanks.

---------------------------------------------------------------------------
Gus Estrella           - Groupe Bull Information System
---------------------------------------------------------------------------

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Feb 1993 19:39:11 GMT
From:      mitton@dave.lkg.dec.com (Dave Mitton)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: MacTCP and TokenTalk -> 8209 -> Ethernet


In article <dan.729697583@dribble>, dan@dribble.c-mols.siu.edu (Dan Ellison) writes:
Newsgroups: comp.protocols.appletalk,comp.protocols.tcp-ip
From: dan@dribble.c-mols.siu.edu (Dan Ellison)
Subject: Re: MacTCP and TokenTalk -> 8209 -> Ethernet
Date: Sun, 14 Feb 1993 13:46:23 GMT

>I have been successful in getting Mac's and PC's to run accross an 8209
>bridge.  The machines in my case were on the ethernet side and the TR
>was connecting the building backbone.  One thing that was necessary was to
>insure the these machine were running 802.3 protocol (802.2 in your case.)
>The bridge will not properly format a TokenTalk packet for bridging.
>
>The ARP problem is another thing all together.  It was quite frustrating
>to try to set up an 8209 on a subnet that has another router on it.  The
>ARPs never get responded to as the bridge sees only what is directly
>connected to it.  One possibility might be to place static ARP entries
>into the 8209.  I'd try turning off the TokenTalk first though and see if 
>this doesn't do it for you.  Good luck.
>--
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>| Dan Ellison, Network Spec 	  -    	Computing Affairs, SIU-C 	| 
>| Southern Illinois University 	  - 	Carbondale, IL 62901            |   
>| FAX:      (618) 453-3459        -   	PHONE:    (618) 453-6149 	|     

	
Dan, I would like to know what you got to work, how, and what the limitations
are.  (by email if you wish)

	One thing to look out for, is that the EtherTalk and TokenTalk
algorithms for hashing a Zone ID into a multicast address are totally
different.   So ZIP multicast packets will NOT be heard on the other side of
the 8209.  Because it's listening for something else.

	I don't know enough about AppleTalk or ZIP to understand the
consequences of this.

	Dave.
	Digital Equipment Corp.
	Token Ring Program.


-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Feb 1993 20:54:48 GMT
From:      schneck@Physik.TU-Muenchen.DE (Bernhard Schneck)
To:        comp.protocols.tcp-ip
Subject:   SLIP and route problems

Hi,

I'm having some problems with SLIP on a Sparc (SunOS 4.1.1, cslip-2.6)


I have a Class-B net (say 111.111) with 8-bit subnet mask (255.255.255.0)
The modem-host (SunOS4.1.1, cslip-2.6) lives on subnet 222 and has the 
ip host address 123 on the ethernet interface.

I want to set up a slip connection to remote host, give that one another
address (124) from the 111.111.222 subnet, and let the slip server proxy-arp
for the remote box.

	ifconfig sl0 111.111.222.123 111.111.222.124 netmask 255.255.255.254
	arp -s 111.111.222.124 <123's ether addr> pub

After a few minutes (about 3, is this the routed hold time?) all routes are
flushed from the routing tables of the slip server host.  I think the 
netmask setting on the sl interface somehow messes up the ethernet interface
netmask, but who knows??  Should I leave out the netmask?

anybody knows what happens?  and how I can fix it?

\Bernhard.
--
Bernhard Schneck              | Email: Bernhard.Schneck@Physik.TU-Muenchen.DE
GeNUA Gesellschaft fuer Netz- | TU Muenchen Physik |
und UNIX-Administration mbH   | 8046 Garching      |        Auslaender bleiben,
8000 Muenchen 83, Germany     | Germany            |          Nazis vertreiben!

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Feb 1993 21:34:28 GMT
From:      edm@harpo.dev.uga.edu (Ed Maioriello)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   MacTCP/TokenTalk -> 8209 -> Ethernet Summary

Hi,

Many thanks to all who responded to my query about making MacTCP
applications work on a Mac on a Token Ring connected to the Internet via
an 8209.  In this case the 8209 does just what it should what was
lacking was the "MacTCP Token-Ring Extension" (not to be confused with
the "TokenTalk Extension").  This is available via anonymous ftp on
ftp.apple.com in the dts/mac/netcomm directory.  Documentation is
included and installation is easy.  

Licensed users of MacTCP are allowed to use this extension.  There are
Appletalk, MacTCP and MacOS version restrictions on the use of this
extension.

Thanks again for all the help, especially from Ross Bogue and Eric Behr
at ilstu.

Ed Maioriello		       		            edm @ harpo.dev.uga.edu
University Computing & Networking Services   	    edm @ aisun1.ai.uga.edu
University of Georgia  ----------------------------------------------------
Athens, Ga. 30602      | First Rule of Troubleshooting: 
(706)-542-6462         |                     If it don't work - plug it in! 



-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Feb 1993 21:52:38 GMT
From:      IWaters@cmutual.com.au (Ian Waters)
To:        comp.protocols.tcp-ip
Subject:   Re: Bootp of PCTCP for DOS

In article <1705@tuura.UUCP>, jel@tuura.UUCP (Jerry Lahti) says:
>
>doswangx@nuscc.nus.sg (Wang Xi (Ms)) writes:
>
>>bootp server. Any body have ideas to make bootp works even there are routers
>>in between bootp clients and bootp servers ?
>
>You can ask your network managers to set up the routers to 
>effectively bridge BOOTP traffic, if the router software allows 
>this. They might not like the idea very much.
>
>Alternatively, you can set up bootp relay agents on each
>separate subnetwork.  However, I do not know if there is
>any easily available software or 'black box' solutions for this.
>
>The third solution is to specify the address of the BOOTP server
>when you run the BOOTP client.  However, this requires that
>your PC knows its IP address, subnet mask and a router to use,
>which presumably is exactly the information you would like to
>retrieve using BOOTP.
>
>/Jerry Lahti
Hiya Jerry,
	Here at CM, we currently run 3 subnets of the one bootp Server, we
have achieved this is the following configuration.

			Subnet 129
	--------------------------------------------------------------------------
			      |
		------------------------------------------
		|		         |
		|        HP ER Router	         |
		|		         |
		------------------------------------------
			     |
	----------------------------------------------------------------------------
		|	Subnet 128	|
		|			|
	           ----------		---------------------------------
	          |	      |		|		|
	          |	      |	 	|  HP ER ROUTER	|
	           -----------		|		|
	        Bootp Host		---------------------------------
					|
					|
			-------------------------------------------------------------
					Subnet 1

I have enabled PROXY Bootp Requests to be forwarded via the 2 HP routers
into our 128 Subnet, the routers have a configurable option to support this type
of proxy bootp relay. We found that this works very well, we have devices on the 
129 subnet and 1 subnet bootp to the local routers, the routers then proxy the 
request to the Bootp server, who inturn replies to the Router. Once having 
recieved the reply, the router then forwards the bootp reply to the requesting
device.

The only problems we have found with this so far, have all be put down to Router
OS software revision bugs, which have soon been fixed. Luckly we are running
the PCTCP suite of software on most of our PC's (we have 200 licences) and on
the rest we are running wollongong software. We just found that you need to
add the wollongong entries into the bootptab with an extra entry compared to the
PCTCP devices. (:vm=rfc1048).

Hope this helped... and Hopefully I didnt rattle on for to long..

Regards
		Ian.W

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 1993 22:24:34 GMT
From:      stlouis@unixg.ubc.ca (Phill St. Louis)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   LAT PC networking muddle

This is my first post to this newsgroup.  I am a "newbie" in this 
subject area. 
 
We want to be sure that what we are thinking of doing is feasible.
 
We have an ethernet network, with Suns, Macintoshes, PCNFS DOS machines and
we are located at St. Paul's hospital.  This ethernet is independent of the
St. Paul's ethernet, but we want to connect to the hospital ethernet for
Pharmacy and Lab data.  The two networks have totally different IP numbers.
 
Our plan is to put a second ethernet card in a Sparcstation 10 Model 30
to get our connection to the hospital ethernet.  My concern is wheither
we will be able to access the Lab info located on a VAX from a PC (using
PATHWORKS) if the PC is located on our ethernet.  Are we better off
connecting this PC directly to the hospital network?  Or will we have no
problem connecting via the Sparcstation 10.  The PC with PATHWORKS needs to
use LAT to access the data on the VAX.  We do not use LAT on our TCP/IP
network.  If we put the PC on our ethernet, will we need to add LAT service
to the Sun?
 
Is there any information that I have left out?  Am I posting to the correct
newsgroup. 
 
Thank you
 
Phill St-Louis
Health Care & Epidemiology
U.B.C.


-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Feb 1993 01:56:36 GMT
From:      alech@hpindda.cup.hp.com (Alec Henderson)
To:        comp.protocols.tcp-ip
Subject:   Re: XTI for HP-UX HP Series 9000/700

queloz@bernina.ethz.ch (Ronald Queloz) asks:

>does anybody know if there is an implementation of XTI, on top of TCP/IP,
>for HP-UX on HP Series 9000/700?

An XTI/TLI interface for TCP/IP is NOT available on HP-UX (up to and
including release 9.xx).  We are looking at providing either XTI or
TLI on a future release.  I am interested in any input on why you
would like to use XTI/TLI (rather than BSD sockets) and whether you
have an preference between XTI and TLI.

Regards,
Alec Henderson

Telephone: 408-447-3965         	Hewlett-Packard
FAX:       408-447-3660			Information Networks Division
E-mail:    alech@cup.hp.com	       	19420 Homestead Road MS 43L9
HPDesk:    Alec Henderson/HP6600/1B	Cupertino, CA  95014  (USA)


-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Feb 1993 02:13:54 GMT
From:      russell@ccu1.aukuni.ac.nz (Russell Fulton)
To:        comp.protocols.tcp-ip
Subject:   Wanted- software to ftp new files.

We want some to set up some mirror archives and I am looking for
software to do this. What we want is a piece of software that will
retrieve all files from a directory tree that are newer than some
particular time. 

I want to do it this way because we will only mirror a subset of the
files because of diskspace constraints. i.e. software that works by
comparing the local and remote directories won't work for us.

I would prefer something that works with an existing ftp client like the
perl package rftp. (rftp allows you to read and write whole directory
trees by ftp)

If I can't find anything that will work of the shelf then I will
probably modify rftp.

Thank, Russell.


-- 
Russell Fulton, Computer Center, University of Auckland, New Zealand.
<rj_fulton@auckland.ac.nz>

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 1993 06:53:42 GMT
From:      emv@msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Programming TCP-IP in Windows 3.1 !!!!!

Gustavo Estrella (estrella@cass.ma02.bull.com) wrote:
: I am interested in writing some programs that use TCP/IP connection from
: within windows 3.1.  I have picked up a copy of the WINWATCP library
: but have not had a chance to test it yet.

The short answer for TCP/IP and windows 3.1 is "winsock".
FTP to sunsite.unc.edu and you should be able to find the
spec and some sample programs, plus a list of vendors.

--Ed


-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 93 14:20:22 GMT
From:      sna@prophet.pharm.pitt.edu (Stewart Abramson)
To:        comp.protocols.tcp-ip
Subject:   Need Help with FTP server on MS-DOS

Hi there:

We use NCSA/Telnet on our Macintosh's to set them up as FTP file servers. 
We have it set up so that a remote Mac running the Mac program Fetch can
FTP whole directories from the Mac FTP server that is running NCSA/Telnet. 
(It is also possible to FTP transfer whole directories from a Sun UNIX
computer to a Mac using Fetch.)

We would like to do the same thing with our IBM-PC running MS-DOS.  We have
installed NCSA/Telnet on our IBM-PC, and we can FTP files from the PC to a
Mac using the program Fetch on the Mac.  The problem is that Fetch cannot
even "see" any of the directories on the PC, let alone FTP a complete
directory and its contents.

What is wrong with NCSA/Telnet on our IBM?  Why can we not identify the
directories, and if we solve that problem will it be possible to FTP whole
directories from the IBM to a Mac as we can do from Mac to Mac.

Any help will be appreciated.  Please respond to me at
sna@prophet.pharm.pitt.edu because I do not read this newsgroup very often.

Stewart N. Abramson
Assistant Professor
Department of Pharmacology
University of Pittsburgh

sna@prophet.pharm.pitt.edu

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 1993 14:25:59 GMT
From:      DIEPERINK@SCSMTA.SWITCH.CH (DIEPERINK)
To:        comp.protocols.tcp-ip,comp.unix.aix
Subject:   SLIP and RS/6000

Hi Netters !

I'm looking for SLIP on a RS/6000. Where can I find it ?
Is there some shareware or public domain stuff ?

Thanks for your help.
-- Alwin Dieperink
dieperink@clients.switch.ch

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Feb 1993 16:07:59 GMT
From:      dprabhak@gmuvax2.gmu.edu (Diwakar)
To:        comp.protocols.tcp-ip
Subject:   SLIP: PC-NFS to SCO UNIX

Hi,

Does anybody out there has had any experience in establishing
a SLIP connection between an IBM compatible running
PC-NFS v3.0.1 and SCO UNIX ? 

The following is a brief description of the problem I am facing:

PC-Side:
--------

PC-NFS has been installed and I run connect to establish a session
with the Unix Box. The connection is established successfully and I get
back to the C:\ prompt. However, I cannot run basic commands like
ping "server name", a telnet to the server, or mounting a remote drive
on the server.

Unix-Side:
----------

1. Added a chain using netconfig to install slip. The chain is
   configured as sco_tcp -> sl0.

2. I run slattach with the following syntax in /etc/sunslip:

	/etc/sunslip /dev/tty2G x97.0.0.6 x97.10.1.24 2400&
	echo SUNSLIP
	echo Attaching user 97.10.1.24 to network via central 97.0.0.6

	where 97.0.0.6 is the IP address of the server and 97.10.1.24
	is the address of the PC. The modem operates at 2400 baud.

	The "x" in front of the IP address is to prevent the machine from
	swallowing the first character of the IP address. I am not sure
	why this happens.

	In addition, I added the following commands without which
	connect would not work.

	echo SUNSLIP
	echo Attaching user 97.10.1.24 to network via central 97.0.0.6

	NOTE: central is the server with 97.0.0.6 as its IP address.

	The permissions on /etc/sunslip is 4777.

I would appreciate any help with this problem.
Thanks, 

Diwakar
dprabhak@gmuvax2.gmu.edu



-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 93 16:37:51 GMT
From:      john@bugs.wrq.com
To:        comp.protocols.tcp-ip
Subject:   TCP/IP on Alpha available yet?

Hi

I'm wondering if anyone out there has any information about tcp/ip on the 
new DEC Alpha machine.  Are there any which have been ported yet?

thanks,

John Addie
Walker, Richer, and Quinn Inc.

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Feb 1993 16:54:55 GMT
From:      Doug_Smith@Novell.COM (J. Douglas Smith)
To:        comp.protocols.tcp-ip,comp.os.os2.networking
Subject:   SLIP Server for OS/2 2.0

Does anyone know of a SLIP server for OS/2 2.0?  I'm using IBM's TCP/IP  
package.

Doug Smith
UNIX Desktop Group
Novell
jdsmith@novell.com

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Feb 1993 17:18:12 GMT
From:      adelman@tgv.com (Kenneth Adelman)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on Alpha available yet?

In article <1993Feb17.083751.1@bugs.wrq.com>, john@bugs.wrq.com writes...
>Hi
>
>I'm wondering if anyone out there has any information about tcp/ip on the
>new DEC Alpha machine.  Are there any which have been ported yet?

    Yes, a few. MultiNet V3.2 (which we just finished shipping to
all customers) fully supports the Alpha systems. I believe that
a few other VMS TCP/IP vendors have announced support, but I don't
know which ones have already shipped.

							    Ken

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 1993 17:21:26 GMT
From:      dennisf@freeman.Eng.Sun.COM (Dennis Freeman)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI/XTI implementation for HP-UX wanted

>From queloz@bernina.ethz.ch (Ronald Queloz)
>Subject: TLI/XTI implementation for HP-UX wanted
>Date: Tue, 16 Feb 1993 12:21:01 GMT
>
>Does anybody outthere know about a TLI or XTI implementation for HP-UX
>running over BSD sockets (TCP/IP based) or something like that?
>Is there anywhere C source to implement this?


Well, SunSoft has supplied HP with ONC Source Code 4.2, which includes XTI/Socket 
conversion libraries.  I don't know if HP plans to do anything with the code.

We wrote the XTI layer so that non-SVR4 ONC licensees could support the TI-RPC libraries
on their sockets-based operating systems.  (SVR4 licensees have TI-RPC on TLI).

ONC 4.2 source code is available from SunSoft, you can contact me for details.
It is BSD-based, quite portable.

---
Dennis Freeman
SunSoft Technology Licensing Manager	
SunSoft (a Sun Microsystems Business)
2550 Garcia Ave., MTV08-111
Mountain View, CA 94043
United States of America
Voice (415) 336-0955; Fax (415) 336-5620
Email: dennis.freeman@Eng.Sun.Com



-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Feb 1993 18:00:45 GMT
From:      ronf@panther3.panther.mot.com (Ron Feigen)
To:        comp.protocols.tcp-ip
Subject:   Re: determining port number

Have you ever had one of those days when you you can't remember how to do 
something that you have done/know in the past?  I hate it when that happens!!!!

If I bind a socket with a port # of 0.  How do I figure out what # the O/S
assigned??????

Thanks in advance!!!

Ron



-- 

>
Ron Feigen
ronf@panther.mot.com

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Feb 1993 18:48:51 GMT
From:      thomas@lkg.dec.com (Matt Thomas)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on Alpha available yet?


In article <1993Feb17.083751.1@bugs.wrq.com>, john@bugs.wrq.com writes:
|>I'm wondering if anyone out there has any information about tcp/ip on the 
|>new DEC Alpha machine.  Are there any which have been ported yet?

And (of course) DEC OSF/1 comes with TCP/IP.
--
Matt Thomas                            Internet:   thomas@lkg.dec.com
U*X Networking                         UUCP:       ...!decwrl!thomas
Digital Equipment Corporation          Disclaimer: This message reflects my own
Littleton, MA                                      warped views, etc.

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 93 19:14:46 GMT
From:      matthews@oberon.umd.edu (Mike Matthews)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over ATM?

Are there any articles out there about running TCP/IP over ATM?  Or any
studies, research datum, anything?  If so, *please* divulge said information
to me via Email and I'd be eternally grateful.

Well, maybe not *eternally* but at least for a while. :-)

Thanks.
------
Mike Matthews, matthews@oberon.umd.edu (NeXTmail accepted)
------
It is much easier to suggest solutions when you know nothing about the
problem.


-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Feb 1993 19:34:01 GMT
From:      ronf@panther3.panther.mot.com (Ron Feigen)
To:        comp.protocols.tcp-ip
Subject:   Oops... never mind! Re: determining port number

In article <1993Feb17.180045.19838@panther.mot.com> ronf@panther3.panther.mot.com (Ron Feigen) writes:
>Have you ever had one of those days when you you can't remember how to do 
>something that you have done/know in the past?  I hate it when that happens!!!!
>
>If I bind a socket with a port # of 0.  How do I figure out what # the O/S
>assigned??????
>
>Thanks in advance!!!
>
>Ron


Oops, it came to me, yeeesh..... I hate it when this happens.  FYI use
getsockname().  Oh well......



-- 

>
Ron Feigen
ronf@panther.mot.com

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Feb 1993 19:51:59 GMT
From:      dennis@nebulus.ampr.ab.ca (Dennis Breckenridge VE6TCP)
To:        comp.protocols.tcp-ip
Subject:   Looking for a good PC TCP Suite

Hi netlanders:
 I am looking for recomendations on various IBM/PC TCP/IP suites. I 
understand there are several packages. I have tried an old version
of Beam and Whiteside and found it to be quite good. Is there any
other vendors that you have tried? 

Some of the services I would be interested in are: email,slip,ftp,telnet
talk, and finger. Are there other DOS services available? 

What kind of problems do you have with both installation and functionality?

Thanks for any help. 

-- 
-------------------------------------------------------------------------------
Dennis Breckenridge VE6TCP        I prefer group activity because, even if it's 
dennis@nebulus.ampr.ab.ca         foolish, at least I'm not the only fool.
-------------------------------------------------------------------------------

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 1993 22:19:49 GMT
From:      scoggin@delmarva.com (John K Scoggin Jr)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on Alpha available yet?

You mean someone actually developed an OS WITHOUT TCP/IP support?  Must be
an ex-DEC employee :-)  What idiots.

	- John
---
+---------------------------------------------------------------------+    
|  John K. Scoggin, Jr.			Email: scoggin@delmarva.com   |
|  Supervisor, Network Operations       Phone: (302) 451-5200         |
|  Delmarva Power & Light Company       Fax:   (302) 451-5321         |
|  500 N. Wakefield Drive               NOC:   (800) 388-7076         |
|  Newark, DE 19714-6066		                              |
|  The opinions expressed are not those of Delmarva Power, simply the |
|  product of an over-active imagination...                           |
+---------------------------------------------------------------------+


-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Feb 1993 00:23:11 GMT
From:      hyung@twg.com (Henry Yung (The Last In Line))
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on Alpha available yet?


In article <1993Feb17.083751.1@bugs.wrq.com>, john@bugs.wrq.com writes:
|>Hi
|>
|>I'm wondering if anyone out there has any information about tcp/ip on the 
|>new DEC Alpha machine.  Are there any which have been ported yet?
|>
|>thanks,
|>
|>John Addie
|>Walker, Richer, and Quinn Inc.
|>

The answer depends on which operating system you are talking about.
If you are talking about OpenVMS, then there two are companies who ported
TCP/IP to Alpha AXP OpenVMS:  Wollongong and TGV.  Wollongong first
demonstrated TCP/IP and NFS on Alpha OpenVMS last May at DECUS in
Atlanta.  If you are talking about OSF/1, then TCP/IP is already
part of the operating system.  If you are talking about Windows NT,
I believe it is also part of the operating system.

Hank

------------------------------------------------------------------------ 
  __  __/  |      /    _____/  Henry Yung	Email: hyung@twg.com
     /     |     /    /        VMS Software Engineering
    /        /  /    / -- /    The Wollongong Group, Inc.
  _/       _/ _/   ______/     Voice: (415)962-7100 FAX: (415)969-5547


-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Feb 1993 00:33:31 GMT
From:      bradley@mdd.comm.mot.com (Michael Bradley)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: internet header info

In article <1993Feb15.091214.14742@usl.edu> sxn9307@ucs.usl.edu (Nadimpalli Sanjay) writes:
>
>Could someone throw light on this:
>
>In the Internet Header, a byte is used for TYPE OF SERVICE.  
>I wanted to know what kind of information is being (or has been)
>stored in that byte?
>
>Thanks in advance
>
>Sanjay
>
>e-mail:  sanjay@ucs.usl.edu

RFC 1349 - "Type of Service in the Internet Suite"
 Michael Bradley



-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Feb 1993 00:47:50 GMT
From:      880506s@dragon.acadiau.ca (James R. Skinner)
To:        comp.protocols.tcp-ip,comp.os.os2.networking
Subject:   Re: SLIP Server for OS/2 2.0

Doug_Smith@Novell.COM (J. Douglas Smith) writes:

>Does anyone know of a SLIP server for OS/2 2.0?  I'm using IBM's TCP/IP  
>package.

Start SLIP with the paramaters -ra

-- 

-----------------------------------+--------------------------------------------
        James Robie Skinner        |     Jodrey School of Computer Science        James.Skinner@dragon.acadiau.ca  |  Acadia University, Wolfville, NS, Canada
-----------------------------------+--------------------------------------------

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 93 16:43:13
From:      vixie@pa.dec.com (Paul A Vixie)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: Hesiod Class and Problems with Zone X'fer

> This is a known problem with the way BIND (Sun's named is actually BIND)
> handles non-IN class information - it leaks and gets it all mixed up with
> the IN class RRs.  You need a modified copy of bind.  I know of at least
> two versions that fix this, one is George Ross's (gdmr@dcs.ed.ac.uk) 4.8.3+
> with the HSprimary and HSsecondary extensions, and at least one other
> person has done similar extensions.  These particular fixes are not, I
> believe, in Paul Vixie's 4.9, but might well be in 4.9.x.

There will be limited support in 4.9's named-xfer for Hesiod.  I will be
very interested in contributions to make it more robust.

--
Paul Vixie, DEC Network Systems Lab	
Palo Alto, California, USA         	"Don't be a rebel, or a conformist;
<vixie@pa.dec.com> decwrl!vixie		they're the same thing, anyway.  Find
<paul@vix.com>     vixie!paul		your own path, and stay on it."  -me

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Feb 93 12:19:48 GMT
From:      pauck@wmdhh.wmd.de (Marco Pauck/1000000;WMD GmbH)
To:        comp.protocols.tcp-ip,comp.unix.aix
Subject:   Re: SLIP and RS/6000

DIEPERINK@SCSMTA.SWITCH.CH (DIEPERINK) writes:

>Hi Netters !
 
>I'm looking for SLIP on a RS/6000. Where can I find it ?
>Is there some shareware or public domain stuff ?

It's included in AIX. Ask InfoHider!

	Marco
-- 
Marco Pauck - WMD GmbH Hamburg, Germany
e-mail: pauck@wmdhh.wmd.de, phone: +49-40-58958-120, fax: +49-40-58958-199
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
-- 
Marco Pauck - WMD GmbH Hamburg, Germany
e-mail: pauck@wmdhh.wmd.de, phone: +49-40-58958-120, fax: +49-40-58958-199
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Feb 1993 14:04:41 GMT
From:      koelman@cuby.stc.nl (Ton Koelman)
To:        comp.protocols.tcp-ip
Subject:   Net redirect in ICMP, why is it obsolete?



--
Ton Koelman   e-mail: koelman@stc.nato.int (NeXT Mail Welcome!)
SHAPE Technical Centre, P.O. Box 174, 2501 CD  The Hague
The Netherlands  (voice: 31-70-3142429, fax: 31-70-3142111)

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Feb 1993 15:04:53 GMT
From:      martin@melpar (Kevin Martin)
To:        comp.protocols.tcp-ip
Subject:   Cabletron Ethernet Hubs


Is anyone using Cabletron Ethernet hubs with EMME management
boards?  I would like to hear from any other users to discuss
their experiences and/or problems.  Anyone using HP OpenView
and Ctron hubs are especially asked to respond.

Please mail responses directly, and thanks in advance.

------------------------------------------------------------------
Kevin Martin
martin@melpar.esys.com
E-Systems, Melpar Division - Network Administration
Falls Church, VA    (703) 560-5000 x3210/x4543

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Feb 1993 17:45:42 GMT
From:      mahmood@lambda.msfc.nasa.gov (Rafique Mahmood)
To:        comp.protocols.tcp-ip
Subject:   NEED UDP MULTICAST TO WORK ON FDDI for SGI machine.

We have 2 SGI machines one is 4/120 and the other os Indigo. I installed FDDI on it.
I know SGI OS supports multicast on ethernet. One of the machine I used before to run
UDP multicast software. but I do not know did it need any special setup for that. If it is
then it was done before I came on board (almost 3 mo.).

I am trying to send multicast packets from indigo to 4/120 or vice versa. machine 4/120
seems sending packets (no error) but receiver keeps waiting, never receives a packets.
I am using multicast address 225.5.5.10. my IP address for those machines are 222.0.0.3
and 222.0.0.4. We are using these address locally. I can send the packet using a fixed
destination address (like 222.0.0.4), but when I send to multicast address 225.5.5.10 receiver
does not receive anything.

Q: IS multicast is not supported on FDDI?

Anything I am doing wronh?

Please email me the response. Thanks.

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




*** I am installing FDDI/DX on Sun 4/260. Does anyone know will it support multicast?
we are running 4.1.1 OS on sun.


-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 1993 17:52:00 GMT
From:      cn356@cleveland.Freenet.Edu (Michael A. Giroux)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP applications in Ada


Does any one know of any good references discussing development of
a TCP application in Ada?  Any ftpable source?  Thanks.

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Feb 1993 18:28:38 GMT
From:      mark@st.unocal.com (Mark E. Towfiq)
To:        comp.protocols.tcp-ip
Subject:   OSPF Routing Protocol, SunOS


Does anyone know of an implementation of the OSPF routing protocol for
SunOS??

-- 
Mark E. Towfiq                           Unocal Corporate Information Services
Phone: (714)693-6740                     5460 E. La Palma Ave.
Internet: mark@st.unocal.COM             Anaheim Hills, Ca 92807

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Feb 1993 19:56:16 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: NEED UDP MULTICAST TO WORK ON FDDI for SGI machine.

In article <1993Feb18.174542.3788@lambda.msfc.nasa.gov>, mahmood@lambda.msfc.nasa.gov (Rafique Mahmood) writes:
> We have 2 SGI machines one is 4/120 and the other os Indigo. I installed FDDI on it.
> I know SGI OS supports multicast on ethernet. One of the machine I used before to run
> UDP multicast software. but I do not know did it need any special setup for that. If it is
> then it was done before I came on board (almost 3 mo.).
> 
> I am trying to send multicast packets from indigo to 4/120 or vice versa. machine 4/120
> seems sending packets (no error) but receiver keeps waiting, never receives a packets.
> I am using multicast address 225.5.5.10. my IP address for those machines are 222.0.0.3
> and 222.0.0.4. We are using these address locally. I can send the packet using a fixed
> destination address (like 222.0.0.4), but when I send to multicast address 225.5.5.10 receiver
> does not receive anything.
> 
> Q: IS multicast is not supported on FDDI?
> 
> Anything I am doing wronh?
> 
> Please email me the response. Thanks.
> 
> Rafique,
> email: mahmood@lambda.msfc.nasa.gov
> 
> 
> *** I am installing FDDI/DX on Sun 4/260. Does anyone know will it support multicast?
> we are running 4.1.1 OS on sun.


If multicast did not work on SGI boxes over FDDI, then dogfight would
not work.  That would be considered a serious problem in some circles.


Vernon Schryver,  vjs@sgi.com

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Feb 1993 21:08:28 GMT
From:      sen@signet.com (Siddhartha Sen)
To:        comp.protocols.tcp-ip
Subject:   HELP :- Setting IP packet routing options


TO,

	DEAR FRIENDS OUT THERE IN NETLAND,


	I have two questions both related, with the second being an 
	extension of the first.

    (i)

	How does one send off a ping packet "so as to take a specific
	route". I know that I can put that in the "options field" but how
	do I access those fields. I want either (i) any command that
	would make me do that _or_ (ii) a system call syntax to set
	options field _or_ (iii) (preferably) both.


    (ii) 

	I want to "tune" the IP so that every time send a packet for a
	perticular host ip address (or a network ip addr) it takes a given 
	route. 
	
    N.B>

	(i) In giving the "specific route", I would prefer giving some
	    key gateways and not all hop stops. (In other words loose
	    source routing)

	(ii) The idea for this exercize is simple. I know that one path
	     is at times "shaky" and thanks to the routing tables along the
	     way I cannot ping along the "other path".  I want to basically
	     "jump" the routing table for one machine and push the packet
	     down the other line. I really don't know if this can be
	     done in the first place !!!!

	(iii) PLATFORM: SUNsparc2 running 4.1.3

	In case you have some clarification or some positive guidelines
	please _also_ email as I'll receive them very fast. (our "newsfeed"
	only runs during the night)


Thanks to all,


					- Siddhartha



-- 
_______Siddhartha__Sen________sen@signet.com____________617_942_0200x136_____
#include <stddisc.h>  /* All above stuff is my own opinion and etc etc etc */
----"Unborn to-morrow , dead yesterday, why fret about them if today be sweet"
------------------------------------------------------Rubayyat-i-Omar-Khayyam

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Feb 1993 21:39:04 GMT
From:      leisner@wrc.xerox.com (Marty Leisner 71348 )
To:        comp.protocols.tcp-ip
Subject:   BSD sockets versus TLI calls

Can someone point me at a good example of BSD sockets versus TLI calls?

Also, is BSD sockets posix compliant?  What is the POSIX mechanism for networking/IPC?

--
marty
leisner@eso.mc.xerox.com leisner.henr801c@xerox.com 
Member of the League for Programming Freedom
"I just know I'm a better manager when I have Joe DiMaggio in center field" -- Casey Stengel

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Feb 1993 21:51:49 GMT
From:      kornya@newton.cs.jhu.edu (Elizabeth Kornya)
To:        comp.protocols.tcp-ip
Subject:   Question: slow FTP under SCO


I am attempting to FTP files across Internet and are having speed
problems on puts.  The problems are intermitent, with transfer rates
ranging from .25 to 6 kb/sec.  There seems to be an excess number 
of retries when the receiving side attempts to send a response to
the initial packet.  A packet capture reveals a window size of 
16384 on the receiving node and 4096 on our side.  We suspect that 
our window size is the problem, but are open to any suggestions
anyone might have.

At the moment we need to know:

How do you change the TCP window size under SCO Unix 3.2.0?

--Liz Kornya

--------------------------------------------------------------------------
"When in danger or in doubt, run in circles, scream and shout."

kornya@server.cs.jhu.edu


-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Feb 1993 21:56:33 GMT
From:      kornya@newton.cs.jhu.edu (Elizabeth Kornya)
To:        comp.protocols.tcp-ip
Subject:   Re: Question: slow FTP under SCO


Oops!  Forgot to mention:  Please _e-mail_ responses to:
kornya@server.cs.jhu.edu

Thanks a lot,
--Liz Kornya

--------------------------------------------------------------------------
"When in danger or in doubt, run in circles, scream and shout."

kornya@server.cs.jhu.edu


-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 93 00:53:37 GMT
From:      alagu@gallant.apple.com (Alagu Periyannan)
To:        comp.protocols.tcp-ip
Subject:   lpr/lpq source


Hi!

Does anybody know whether the source to BSD Unix lpr, lpq and lpd
are available public domain ?? And if so where ?

Is there a FAQ on TCP/IP for Unix systems?


-- 
---------------------------------------------------------------
Alagu Periyannan

alagu@apple.com

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 1993 00:55:11 GMT
From:      corrigan@weber.ucsd.edu (Michael J. Corrigan)
To:        comp.sys.hp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   CLOSING network connections from pcs.

Our HP-UX system ( 9000/827 HP-UX 8.02 ) has A LOT of connections in 
the CLOSING state ( appended is the current 447 connections in this state).

It seems that all the connections are from PCs running for the most
part NCSA telnet. The connections are both to telnet and to ftp.
From the fact that the Send-Q is nonempty in most of the cases, I'd
guess that HP is unable to deliver (receive acknowledgment of previous ?)
stuff to the PC and is waiting forever to send something,
but my understanding of the tcp protocols involved is minimal.
Also I get reports that the connection seems hung to the user and 
they probably reboot the PC or elsewhise exit telnet ( which is definitely
a protocol violation  ? )
While a bad network could probably cause all sorts of pathology, I am
wondering whether it isn't something systematically wrong about something
within the tcp for the HP or the PC, or their interoperation. I am also
struck by the fact that it is exclusively PCs in the list, no Unix systems
and also that ftp to and from the HP to many different Unix systems
never shows any performance problems and rarely hangs no matter how far
away and no matter how slow the link.

If anyone has ever seen this sort of thing before, I'd appreciate
hearing about it.

Thanks

Michael J. Corrigan
University of California, San Diego

Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address          Foreign Address        (state)

`netstat -a| grep CLOSING`

tcp        0     87  weber.telnet           131.247.90.14.11073    CLOSING
tcp        0     14  weber.telnet           dlowell.2498           CLOSING
tcp        0    246  weber.telnet           131.247.90.14.11774    CLOSING
tcp        0      4  weber.telnet           dbailey.3036           CLOSING
tcp        0      5  weber.telnet           lib5.6658              CLOSING
tcp        0      7  weber.telnet           sociology74.7613       CLOSING
tcp        0      4  weber.telnet           usb19.10716            CLOSING
tcp        0      3  weber.telnet           atucker.11693          CLOSING
tcp        0      5  weber.telnet           yclewll.15443          CLOSING
tcp        0    157  weber.ftp-data         saa194.56113           CLOSING
tcp        0    142  weber.ftp-data         saa194.50392           CLOSING
tcp        0      7  weber.telnet           sociology73.7557       CLOSING
tcp        0      7  weber.telnet           sociology70.3443       CLOSING
tcp        0      7  weber.telnet           sociology76.2139       CLOSING
tcp        0    346  weber.ftp-data         sociology70.42563      CLOSING
tcp        0    217  weber.ftp-data         saa194.54588           CLOSING
tcp        0      3  weber.telnet           saa194.16197           CLOSING
tcp        0    317  weber.ftp-data         sociology70.40231      CLOSING
tcp        0      4  weber.telnet           hss08.7717             CLOSING
tcp        0      7  weber.telnet           sociology81.3613       CLOSING
tcp        0     13  weber.telnet           sschulze.2729          CLOSING
tcp        0      4  weber.telnet           hss08.12127            CLOSING
tcp        0      7  weber.telnet           sociology71.2058       CLOSING
tcp        0      3  weber.telnet           hss08.11074            CLOSING
tcp        0     30  weber.telnet           mremilla.2893          CLOSING
tcp        0     15  weber.telnet           mcunning.14870         CLOSING
tcp        0      5  weber.telnet           hss09.8047             CLOSING
tcp        0      6  weber.telnet           hss08.7130             CLOSING
tcp        0      9  weber.telnet           mcunning.11490         CLOSING
tcp        0     53  weber.telnet           131.247.90.14.7749     CLOSING
tcp        0      7  weber.telnet           sociology71.15341      CLOSING
tcp        0      7  weber.telnet           sociology71.14617      CLOSING
tcp        0      9  weber.telnet           hss07.15477            CLOSING
tcp        0    264  weber.ftp-data         saa194.50655           CLOSING
tcp        0      4  weber.telnet           hss07.10617            CLOSING
tcp        0      3  weber.telnet           gborjas.3855           CLOSING
tcp        0     16  weber.telnet           hss07.14563            CLOSING
tcp        0    317  weber.ftp-data         sociology70.53028      CLOSING
tcp        0     67  weber.telnet           ljpro-cancer195.15709  CLOSING
tcp        0    153  weber.ftp-data         saa194.46480           CLOSING
tcp        0     13  weber.ftp              saa194.14458           CLOSING
tcp        0      4  weber.telnet           saa194.2813            CLOSING
tcp        0     37  weber.telnet           hss07.7279             CLOSING
tcp        0      7  weber.telnet           sociology71.7688       CLOSING
tcp        0    105  weber.telnet           131.247.90.14.15798    CLOSING
tcp        0     13  weber.ftp              saa194.3527            CLOSING
tcp        0      3  weber.telnet           saa194.14600           CLOSING
tcp        0      5  weber.telnet           hss08.6594             CLOSING
tcp        0      4  weber.telnet           hss14.15297            CLOSING
tcp        0      5  weber.telnet           hss11.14511            CLOSING
tcp        0    126  weber.telnet           hss07.6531             CLOSING
tcp        0      7  weber.telnet           sociology73.10987      CLOSING
tcp        0      7  weber.telnet           mcunning.12077         CLOSING
tcp        0     18  weber.telnet           hss08.7770             CLOSING
tcp        0     14  weber.telnet           dlowell.3584           CLOSING
tcp        0      4  weber.telnet           saa194.6609            CLOSING
tcp        0    951  weber.telnet           131.247.90.14.16186    CLOSING
tcp        0      7  weber.telnet           ydacayan.15069         CLOSING
tcp        0      3  weber.telnet           shyllebe.15077         CLOSING
tcp        0      5  weber.telnet           apereira.11038         CLOSING
tcp        0      4  weber.telnet           jconlisk.7966          CLOSING
tcp        0     50  weber.telnet           131.247.90.14.14866    CLOSING
tcp        0    147  weber.telnet           lraut.3101             CLOSING
tcp        0      4  weber.telnet           hss08.2668             CLOSING
tcp        0     36  weber.telnet           hss14.10513            CLOSING
tcp        0     13  weber.telnet           sociology70.15239      CLOSING
tcp        0      4  weber.telnet           hss08.14685            CLOSING
tcp        0    101  weber.telnet           131.247.90.14.2915     CLOSING
tcp        0      3  weber.telnet           hss08.12244            CLOSING
tcp        0      3  weber.telnet           shyllebe.16036         CLOSING
tcp        0      3  weber.telnet           sociology74.15646      CLOSING
tcp        0      6  weber.telnet           hss11.11964            CLOSING
tcp        0      7  weber.telnet           hss08.2841             CLOSING
tcp        0      4  weber.telnet           yclewll.6477           CLOSING
tcp        0      7  weber.telnet           sociology71.11281      CLOSING
tcp        0    199  weber.telnet           cul91-39.2526          CLOSING
tcp        0      3  weber.telnet           hss07.11629            CLOSING
tcp        0      7  weber.telnet           sociology72.3871       CLOSING
tcp        0      5  weber.telnet           sociology70.2547       CLOSING
tcp        0      9  weber.telnet           hss13.4041             CLOSING
tcp        0      3  weber.telnet           hss09.6285             CLOSING
tcp        0      7  weber.telnet           twade.7820             CLOSING
tcp        0      5  weber.telnet           sociology74.6847       CLOSING
tcp        0      3  weber.telnet           hss11.6901             CLOSING
tcp        0      5  weber.telnet           hss09.8148             CLOSING
tcp        0      4  weber.telnet           hss11.14454            CLOSING
tcp        0      3  weber.telnet           yclewll.3580           CLOSING
tcp        0      7  weber.telnet           sociology76.3336       CLOSING
tcp        0      4  weber.telnet           hss08.11784            CLOSING
tcp        0     19  weber.telnet           dlowell.10695          CLOSING
tcp        0     14  weber.telnet           mobrian.3904           CLOSING
tcp        0      4  weber.telnet           hss14.7291             CLOSING
tcp        0      7  weber.telnet           hss14.16259            CLOSING
tcp        0     60  weber.telnet           jrauch.16163           CLOSING
tcp        0     22  weber.telnet           dlowell.14370          CLOSING
tcp        0      4  weber.telnet           hss11.14837            CLOSING
tcp        0      9  weber.telnet           hss06.6321             CLOSING
tcp        0      9  weber.telnet           mcunning.14683         CLOSING
tcp        0      5  weber.telnet           hss04.3172             CLOSING
tcp        0      5  weber.telnet           yclewll.6728           CLOSING
tcp        0      3  weber.telnet           yclewll.15846          CLOSING
tcp        0      3  weber.telnet           hss06.15315            CLOSING
tcp        0      7  weber.telnet           sociology71.11735      CLOSING
tcp        0      8  weber.telnet           saa194.3573            CLOSING
tcp        0      9  weber.telnet           mcunning.7963          CLOSING
tcp        0      7  weber.telnet           hss08.2845             CLOSING
tcp        0      6  weber.telnet           hss08.14981            CLOSING
tcp        0      5  weber.telnet           hss11.10445            CLOSING
tcp        0      5  weber.telnet           hss09.7804             CLOSING
tcp        0     17  weber.telnet           hss08.7609             CLOSING
tcp        0      7  weber.telnet           hss03.15205            CLOSING
tcp        0      7  weber.telnet           sociology71.10398      CLOSING
tcp        0      9  weber.telnet           vramey.6184            CLOSING
tcp        0     63  weber.telnet           rramanat.6425          CLOSING
tcp        0    171  weber.telnet           131.247.89.252.7224    CLOSING
tcp        0      3  weber.telnet           hss09.7455             CLOSING
tcp        0      8  weber.telnet           hss09.15571            CLOSING
tcp        0      4  weber.telnet           sociology79.14777      CLOSING
tcp        0      7  weber.telnet           shyllebe.10657         CLOSING
tcp        0      8  weber.telnet           hss02.7905             CLOSING
tcp        0      3  weber.telnet           yclewll.7091           CLOSING
tcp        0      4  weber.telnet           cchatfie.10767         CLOSING
tcp        0      7  weber.telnet           hss02.14795            CLOSING
tcp        0      9  weber.telnet           shyllebe.15324         CLOSING
tcp        0      8  weber.telnet           hss08.7273             CLOSING
tcp        0     13  weber.telnet           hss09.10877            CLOSING
tcp        0     12  weber.telnet           plindsay.10487         CLOSING
tcp        0      7  weber.telnet           hss08.15692            CLOSING
tcp        0      6  weber.telnet           hss11.11469            CLOSING
tcp        0      9  weber.telnet           hss11.7556             CLOSING
tcp        0      6  weber.telnet           hss06.7434             CLOSING
tcp        0      3  weber.telnet           hss09.4036             CLOSING
tcp        0      3  weber.telnet           jducey.7117            CLOSING
tcp        0      5  weber.telnet           atucker.2738           CLOSING
tcp        0      4  weber.telnet           hss07.15668            CLOSING
tcp        0      3  weber.telnet           yclewll.7851           CLOSING
tcp        0      4  weber.telnet           cul91-47.8071          CLOSING
tcp        0      5  weber.telnet           apereira.14606         CLOSING
tcp        0     99  weber.telnet           131.247.89.252.15248   CLOSING
tcp        0      3  weber.telnet           hss10.11152            CLOSING
tcp        0      4  weber.telnet           hss07.2319             CLOSING
tcp        0     42  weber.telnet           hss09.2201             CLOSING
tcp        0     84  weber.telnet           hss07.11708            CLOSING
tcp        0      3  weber.telnet           hss10.7538             CLOSING
tcp        0      4  weber.telnet           yclewll.6531           CLOSING
tcp        0      5  weber.telnet           hss11.11078            CLOSING
tcp        0      9  weber.telnet           twade.15975            CLOSING
tcp        0     20  weber.telnet           dlowell.7338           CLOSING
tcp        0      7  weber.telnet           hss10.7526             CLOSING
tcp        0      4  weber.telnet           hss09.15762            CLOSING
tcp        0     18  weber.telnet           dlowell.11383          CLOSING
tcp        0      6  weber.telnet           hss11.15762            CLOSING
tcp        0      8  weber.telnet           hss11.11103            CLOSING
tcp        0     21  weber.telnet           jrauch.7574            CLOSING
tcp        0      5  weber.telnet           cul91-47.2677          CLOSING
tcp        0     18  weber.telnet           dlowell.10704          CLOSING
tcp        0      4  weber.telnet           hss07.6559             CLOSING
tcp        0     14  weber.telnet           hss09.6762             CLOSING
tcp        0      3  weber.telnet           hss12.15122            CLOSING
tcp        0     14  weber.telnet           hss10.15763            CLOSING
tcp        0      4  weber.telnet           hss09.11124            CLOSING
tcp        0      4  weber.telnet           hss10.3414             CLOSING
tcp        0      7  weber.telnet           hss09.3260             CLOSING
tcp        0      7  weber.telnet           hss13.3280             CLOSING
tcp        0     16  weber.telnet           hss12.2842             CLOSING
tcp        0      4  weber.telnet           atucker.6582           CLOSING
tcp        0      4  weber.telnet           hss03.2156             CLOSING
tcp        0     19  weber.telnet           dlowell.10529          CLOSING
tcp        0      3  weber.telnet           hss09.15577            CLOSING
tcp        0      7  weber.telnet           hss06.10542            CLOSING
tcp        0      3  weber.telnet           hss13.14504            CLOSING
tcp        0     14  weber.telnet           mstinchc.15881         CLOSING
tcp        0      5  weber.telnet           jducey.2617            CLOSING
tcp        0      3  weber.telnet           hss11.6542             CLOSING
tcp        0      7  weber.telnet           hss13.2976             CLOSING
tcp        0     14  weber.telnet           hss04.10486            CLOSING
tcp        0     23  weber.telnet           hss10.7728             CLOSING
tcp        0      4  weber.telnet           hss09.2501             CLOSING
tcp        0      3  weber.telnet           hss01.15403            CLOSING
tcp        0      3  weber.telnet           hss06.3470             CLOSING
tcp        0      7  weber.telnet           hss06.16061            CLOSING
tcp        0      3  weber.telnet           hss14.10659            CLOSING
tcp        0     34  weber.telnet           mstinchc.11997         CLOSING
tcp        0     18  weber.telnet           hss13.15337            CLOSING
tcp        0      3  weber.telnet           hss08.15514            CLOSING
tcp        0      5  weber.telnet           hss10.16300            CLOSING
tcp        0      9  weber.telnet           hss08.7078             CLOSING
tcp        0     22  weber.telnet           dlowell.8170           CLOSING
tcp        0      3  weber.telnet           atucker.2622           CLOSING
tcp        0      6  weber.telnet           hss11.4090             CLOSING
tcp        0      5  weber.telnet           hss13.10877            CLOSING
tcp        0      4  weber.telnet           hss13.6372             CLOSING
tcp        0      5  weber.telnet           hss01.10662            CLOSING
tcp        0      3  weber.telnet           hss01.2561             CLOSING
tcp        0      7  weber.telnet           hss14.11499            CLOSING
tcp        0     46  weber.telnet           sociology73.16149      CLOSING
tcp        0     82  weber.telnet           dlowell.14414          CLOSING
tcp        0     58  weber.telnet           mremilla.14353         CLOSING
tcp        0      9  weber.telnet           sociology73.7624       CLOSING
tcp        0     63  weber.telnet           131.247.89.252.10901   CLOSING
tcp        0    175  weber.telnet           cul91-32.3254          CLOSING
tcp        0      3  weber.telnet           hss08.6397             CLOSING
tcp        0     16  weber.telnet           hss09.6153             CLOSING
tcp        0      7  weber.telnet           hss07.15229            CLOSING
tcp        0      4  weber.telnet           atucker.11425          CLOSING
tcp        0      3  weber.telnet           yclewll.16197          CLOSING
tcp        0      9  weber.telnet           sociology69.6630       CLOSING
tcp        0      3  weber.telnet           jrowe.15278            CLOSING
tcp        0      9  weber.telnet           sschulze.16263         CLOSING
tcp        0    724  weber.telnet           131.247.89.252.2717    CLOSING
tcp        0    199  weber.ftp-data         153.9.11.19.42293      CLOSING
tcp        0    167  weber.telnet           cul91-32.16076         CLOSING
tcp        0      6  weber.telnet           hss11.14514            CLOSING
tcp        0      5  weber.telnet           sociology69.7141       CLOSING
tcp        0     13  weber.telnet           mcunning.15544         CLOSING
tcp        0      7  weber.telnet           ydacayan.11767         CLOSING
tcp        0      4  weber.telnet           sociology79.6353       CLOSING
tcp        0      3  weber.telnet           hss11.6680             CLOSING
tcp        0     10  weber.telnet           saa194.6186            CLOSING
tcp        0      6  weber.telnet           hss09.15094            CLOSING
tcp        0     92  weber.ftp-data         saa194.44783           CLOSING
tcp        0      3  weber.telnet           hss13.14575            CLOSING
tcp        0     13  weber.telnet           mcunning.10953         CLOSING
tcp        0      3  weber.telnet           cul91-47.3151          CLOSING
tcp        0      6  weber.telnet           hss13.7371             CLOSING
tcp        0      6  weber.telnet           hss08.8061             CLOSING
tcp        0      4  weber.telnet           hss08.14577            CLOSING
tcp        0     16  weber.telnet           hss13.10317            CLOSING
tcp        0      7  weber.telnet           sociology71.7869       CLOSING
tcp        0     20  weber.telnet           dlowell.7323           CLOSING
tcp        0     15  weber.telnet           hss10.7997             CLOSING
tcp        0      3  weber.telnet           hss09.11395            CLOSING
tcp        0      3  weber.telnet           hss08.14826            CLOSING
tcp        0      3  weber.telnet           saa194.11531           CLOSING
tcp        0      3  weber.telnet           hss07.8031             CLOSING
tcp        0      5  weber.telnet           hss10.7444             CLOSING
tcp        0      7  weber.telnet           hss01.14971            CLOSING
tcp        0     64  weber.telnet           131.247.89.252.7617    CLOSING
tcp        0      9  weber.telnet           sociology72.6689       CLOSING
tcp        0     30  weber.telnet           jrauch.6378            CLOSING
tcp        0      5  weber.telnet           hss06.11547            CLOSING
tcp        0     14  weber.telnet           ydacayan.7350          CLOSING
tcp        0      4  weber.telnet           hss12.16268            CLOSING
tcp        0     46  weber.telnet           sociology73.10921      CLOSING
tcp        0      4  weber.telnet           hss07.10991            CLOSING
tcp        0     27  weber.telnet           hss11.15876            CLOSING
tcp        0      9  weber.telnet           sociology69.10863      CLOSING
tcp        0      5  weber.telnet           hss04.7376             CLOSING
tcp        0      6  weber.telnet           hss11.11318            CLOSING
tcp        0    175  weber.telnet           cul91-32.6943          CLOSING
tcp        0      8  weber.telnet           dbailey.3339           CLOSING
tcp        0      7  weber.telnet           sociology71.6925       CLOSING
tcp        0      3  weber.telnet           hss03.11457            CLOSING
tcp        0      7  weber.telnet           sociology69.3128       CLOSING
tcp        0      9  weber.telnet           plindsay.11132         CLOSING
tcp        0      6  weber.telnet           hss07.7398             CLOSING
tcp        0      7  weber.telnet           sociology72.15110      CLOSING
tcp        0      3  weber.telnet           sociology71.14637      CLOSING
tcp        0      9  weber.telnet           hss04.10731            CLOSING
tcp        0     10  weber.telnet           131.247.89.252.14978   CLOSING
tcp        0     14  weber.telnet           yclewll.10343          CLOSING
tcp        0     14  weber.telnet           sociology72.7780       CLOSING
tcp        0      7  weber.telnet           mcunning.2510          CLOSING
tcp        0      3  weber.telnet           hss07.3006             CLOSING
tcp        0      3  weber.telnet           lraut.6439             CLOSING
tcp        0      9  weber.telnet           sociology71.10429      CLOSING
tcp        0     18  weber.telnet           hss09.14513            CLOSING
tcp        0      3  weber.telnet           hss07.3413             CLOSING
tcp        0      9  weber.telnet           sociology71.3373       CLOSING
tcp        0      4  weber.telnet           hss07.14515            CLOSING
tcp        0      4  weber.telnet           hss12.10245            CLOSING
tcp        0     35  weber.telnet           hss09.11436            CLOSING
tcp        0     16  weber.telnet           hss08.15746            CLOSING
tcp        0      6  weber.telnet           hss04.3997             CLOSING
tcp        0      6  weber.telnet           hss12.6909             CLOSING
tcp        0     16  weber.telnet           hss07.3663             CLOSING
                                                                     CLOSING
tcp        0      7  weber.telnet           hss10.15249            CLOSING
tcp        0    194  weber.telnet           hss13.15313            CLOSING
tcp        0    101  weber.telnet           hss13.11822            CLOSING
tcp        0      6  weber.telnet           cul91-7.7714           CLOSING
tcp        0     21  weber.telnet           hss10.11783            CLOSING
tcp        0      3  weber.telnet           hss10.6623             CLOSING
tcp        0      5  weber.telnet           yclewll.10479          CLOSING
tcp        0     15  weber.telnet           sociology71.7968       CLOSING
tcp        0     13  weber.telnet           sociology69.2682       CLOSING
tcp        0      8  weber.telnet           sociology73.6547       CLOSING
tcp        0      3  weber.telnet           hss13.15042            CLOSING
tcp        0      4  weber.telnet           shyllebe.2731          CLOSING
tcp        0      5  weber.telnet           gborjas.3401           CLOSING
tcp        0     35  weber.telnet           hss07.12009            CLOSING
tcp        0      4  weber.telnet           lib63.7048             CLOSING
tcp        0     33  weber.telnet           econlab2.10440         CLOSING
tcp        0     12  weber.telnet           cchatfie.3950          CLOSING
tcp        0      4  weber.telnet           hss07.10668            CLOSING
tcp        0      6  weber.telnet           hss10.2077             CLOSING
tcp        0      9  weber.telnet           ydacayan.15747         CLOSING
tcp        0     18  weber.telnet           jbetts.7119            CLOSING
tcp        0     59  weber.telnet           twade.10699            CLOSING
tcp        0      7  weber.telnet           sociology73.6999       CLOSING
tcp        0     13  weber.telnet           mcunning.10274         CLOSING
tcp        0      3  weber.telnet           shyllebe.15370         CLOSING
                                                                     CLOSING
tcp        0      7  weber.telnet           twade.7727             CLOSING
tcp        0      7  weber.telnet           mcunning.6614          CLOSING
tcp        0    175  weber.telnet           cul91-32.10432         CLOSING
tcp        0      7  weber.telnet           hss12.14758            CLOSING
tcp        0      6  weber.telnet           hss05.10358            CLOSING
tcp        0      5  weber.telnet           hss10.16108            CLOSING
tcp        0      3  weber.telnet           dbailey.3349           CLOSING
tcp        0      4  weber.telnet           econlab2.8125          CLOSING
tcp        0      4  weber.telnet           hss07.7624             CLOSING
tcp        0      7  weber.telnet           hss08.2697             CLOSING
tcp        0     85  weber.telnet           131.104.144.99.12115   CLOSING
tcp        0     22  weber.telnet           hss09.11648            CLOSING
tcp        0     30  weber.telnet           mremilla.10303         CLOSING
tcp        0      7  weber.telnet           mcunning.14436         CLOSING
tcp        0      7  weber.telnet           sociology72.15990      CLOSING
                                                                     CLOSING
tcp        0      4  weber.telnet           hss07.7302             CLOSING
tcp        0    216  weber.telnet           131.104.200.210.15336  CLOSING
tcp        0    607  weber.4126             cul91-47.ftp-data      CLOSING
tcp        0      4  weber.telnet           hss06.12248            CLOSING
tcp        0      3  weber.telnet           rramanat.6397          CLOSING
tcp        0      5  weber.telnet           hss06.16094            CLOSING
tcp        0      4  weber.telnet           hss05.14630            CLOSING
tcp        0     15  weber.telnet           mcunning.11665         CLOSING
tcp        0     18  weber.telnet           dlowell.14630          CLOSING
tcp        0      7  weber.telnet           hss13.7611             CLOSING
tcp        0    229  weber.telnet           gkaminsk.11746         CLOSING
tcp        0     20  weber.telnet           dlowell.15465          CLOSING
tcp        0      3  weber.telnet           hss12.14929            CLOSING
tcp        0      9  weber.telnet           jhamilton.2103         CLOSING
tcp        0      3  weber.telnet           hss09.2450             CLOSING
tcp        0      4  weber.telnet           cul91-47.16220         CLOSING
tcp        0    231  weber.telnet           hss09.12071            CLOSING
tcp        0      3  weber.telnet           yclewll.3795           CLOSING
                                                                     CLOSING
tcp        0     21  weber.telnet           dlowell.11789          CLOSING
tcp        0     14  weber.telnet           mremilla.15505         CLOSING
tcp        0      5  weber.telnet           gborjas.16204          CLOSING
tcp        0     44  weber.telnet           sociology71.3001       CLOSING
tcp        0      7  weber.telnet           sociology71.15991      CLOSING
tcp        0      3  weber.telnet           hss04.2435             CLOSING
tcp        0      4  weber.telnet           hss03.15177            CLOSING
tcp        0      4  weber.telnet           shyllebe.14444         CLOSING
tcp        0      3  weber.telnet           hss09.10558            CLOSING
tcp        0    410  weber.telnet           linch.cis.usf.edu.2404 CLOSING
tcp        0    167  weber.telnet           131.104.200.66.10815   CLOSING
tcp        0      3  weber.telnet           shyllebe.14744         CLOSING
tcp        0     51  weber.telnet           cul91-47.16067         CLOSING
tcp        0      9  weber.telnet           mcunning.3793          CLOSING
tcp        0      9  weber.telnet           ydacayan.3395          CLOSING
tcp        0    283  weber.telnet           econlab2.11798         CLOSING
tcp        0     39  weber.telnet           econlab2.6264          CLOSING
tcp        0      3  weber.telnet           yclewll.2899           CLOSING
tcp        0      4  weber.telnet           hss01.16241            CLOSING
tcp        0      4  weber.telnet           hss07.16150            CLOSING
tcp        0     15  weber.telnet           hss04.2877             CLOSING
tcp        0      3  weber.telnet           jducey.3540            CLOSING
tcp        0      6  weber.telnet           hss09.3525             CLOSING
tcp        0      6  weber.telnet           dsmallwo.14675         CLOSING
tcp        0      6  weber.telnet           dsmallwo.6997          CLOSING
tcp        0     15  weber.telnet           mcunning.3815          CLOSING
tcp        0     13  weber.ftp              sociology69.3483       CLOSING
tcp        0    165  weber.ftp-data         sociology69.51993      CLOSING
tcp        0    165  weber.ftp-data         sociology69.51639      CLOSING
tcp        0      4  weber.telnet           hss10.14420            CLOSING
tcp        0     27  weber.telnet           hss09.2171             CLOSING
tcp        0      3  weber.telnet           yclewll.2478           CLOSING
tcp        0      4  weber.telnet           hss10.12249            CLOSING
tcp        0    175  weber.telnet           cul91-32.15065         CLOSING
tcp        0    175  weber.telnet           cul91-32.11176         CLOSING
tcp        0    598  weber.telnet           hss07.15257            CLOSING
tcp        0      9  weber.telnet           lraut.10427            CLOSING
tcp        0      3  weber.telnet           jrowe.7142             CLOSING
tcp        0    142  weber.telnet           cul91-32.3092          CLOSING
tcp        0    771  weber.2997             rramanat.ftp-data      CLOSING
tcp        0      8  weber.telnet           hss05.15880            CLOSING
tcp        0      9  weber.telnet           ydacayan.12067         CLOSING
tcp        0     20  weber.telnet           dlowell.15649          CLOSING
tcp        0      6  weber.telnet           dbailey.7911           CLOSING
tcp        0    103  weber.telnet           hss04.16315            CLOSING
tcp        0    199  weber.telnet           cul91-32.3789          CLOSING
tcp        0    175  weber.telnet           cul91-32.10418         CLOSING
tcp        0      3  weber.telnet           econlab2.10807         CLOSING
                                                                     CLOSING
tcp        0      7  weber.telnet           hss08.12225            CLOSING
tcp        0     13  weber.telnet           ydacayan.6848          CLOSING
tcp        0      4  weber.telnet           gborjas.15591          CLOSING
tcp        0      7  weber.telnet           cgranger.3848          CLOSING
tcp        0    138  weber.telnet           mobrian.7060           CLOSING
tcp        0     44  weber.telnet           sociology73.3922       CLOSING
tcp        0      3  weber.telnet           sociology81.11434      CLOSING
tcp        0     15  weber.telnet           sociology81.10757      CLOSING
tcp        0      4  weber.telnet           hss12.10957            CLOSING
tcp        0      4  weber.telnet           jducey.6217            CLOSING
tcp        0     80  weber.telnet           dbailey.3582           CLOSING
tcp        0     23  weber.telnet           jhamilton.2340         CLOSING
tcp        0     15  weber.telnet           ryamasak.14633         CLOSING
tcp        0      3  weber.telnet           ybalesko.10532         CLOSING
tcp        0      7  weber.telnet           dlowell.4034           CLOSING
tcp        0     37  weber.telnet           mobrian.14965          CLOSING
tcp        0     81  weber.telnet           mobrian.3930           CLOSING
tcp        0      5  weber.telnet           hss08.7350             CLOSING
tcp        0     46  weber.telnet           sociology72.11262      CLOSING
tcp        0     35  weber.telnet           mremilla.2314          CLOSING
tcp        0      9  weber.telnet           mcunning.6582          CLOSING
tcp        0     15  weber.telnet           ydacayan.6585          CLOSING
tcp        0     90  weber.telnet           mobrian.15245          CLOSING
tcp        0     32  weber.telnet           hss09.11499            CLOSING
tcp        0     13  weber.telnet           hss08.15209            CLOSING
tcp        0     88  weber.telnet           hss08.3740             CLOSING
tcp        0      8  weber.telnet           hss10.2817             CLOSING
tcp        0     43  weber.telnet           mobrian.10442          CLOSING
tcp        0     40  weber.telnet           mobrian.14407          CLOSING
tcp        0      4  weber.telnet           hss07.7768             CLOSING
tcp        0    175  weber.telnet           cul91-32.15872         CLOSING
tcp        0      7  weber.telnet           econlab2.4056          CLOSING
tcp        0     13  weber.telnet           ryamasak.16363         CLOSING
tcp        0     13  weber.telnet           mcunning.10435         CLOSING
tcp        0      9  weber.telnet           hss07.2588             CLOSING
tcp        0      7  weber.telnet           mremilla.14978         CLOSING
tcp        0    296  weber.telnet           hss04.15841            CLOSING
tcp        0     14  weber.telnet           mcunning.14858         CLOSING
tcp        0      7  weber.telnet           mcunning.11730         CLOSING
tcp        0      9  weber.telnet           ryamasak.15031         CLOSING
tcp        0      7  weber.telnet           jconlisk.7920          CLOSING
tcp        0      5  weber.telnet           cchatfie.7109          CLOSING
tcp        0    104  weber.telnet           hss04.14371            CLOSING
tcp        0    251  weber.telnet           cul91-32.7326          CLOSING
tcp        0      3  weber.telnet           yclewll.7487           CLOSING
tcp        0      7  weber.telnet           hss04.12137            CLOSING
tcp        0      9  weber.telnet           mcunning.11282         CLOSING
tcp        0      3  weber.telnet           hss12.15894            CLOSING
tcp        0     13  weber.telnet           mcunning.3956          CLOSING
tcp        0     73  weber.telnet           shyllebe.10688         CLOSING
tcp        0     15  weber.telnet           hss08.14843            CLOSING
tcp        0      7  weber.telnet           sociology74.7517       CLOSING
tcp        0     72  weber.ftp-data         saa194.51733           CLOSING
tcp        0    141  weber.telnet           hss08.2523             CLOSING
tcp        0     46  weber.telnet           jrauch.3332            CLOSING
tcp        0      7  weber.telnet           hss10.15660            CLOSING
tcp        0      3  weber.telnet           jducey.15902           CLOSING
tcp        0      6  weber.telnet           hss09.10917            CLOSING
tcp        0      3  weber.telnet           hss05.12183            CLOSING
tcp        0      7  weber.telnet           hss12.12178            CLOSING

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Feb 1993 05:35:28 GMT
From:      elelko@nuscc.nus.sg (Kwok-Onn Looi)
To:        comp.protocols.tcp-ip
Subject:   Help on PCTCP LPD



Has anuyone got their PCTCP LPD server running ? I would like to know
how the configuration for the printers look like. Does it use the same
format as in Unix's <printcap> file ? Just managed to get the LPD to
recognize the <hosts> file.


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

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

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


-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 1993 05:52:07 GMT
From:      nilayp@violet.berkeley.edu (Nilay Patel;FH 1C39E;36540;6430162;RC38)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: Appletalk on PC

In article <1993Feb2.163430.19999@leland.Stanford.EDU> rob@leland.Stanford.EDU (Rob Tanner) writes:
>
>The product you want is Farallon's PhoneNET Talk.  It will work with a
>number of network cards, including PC LocalTalk for which there are
>several manufacturers.
>
>Farallon is in Emeryville, CA.  Their phone number is (415) 596-9000.
>
Actually, Farallon has just moved to Alameda, CA. Their new phone number
is (510) 814-5000 (I think.) If this is not their number, just call
the 510 information and ask for them in Alameda...

The 510 information line is (510) 555-1212

-- Nilay Patel
nilayp@violet.berkeley.edu


-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Feb 1993 06:45:18 GMT
From:      tsukako@sdl.hitachi.co.jp (Masato Tsukakoshi)
To:        comp.protocols.tcp-ip
Subject:   Re: OSPF Routing Protocol, SunOS

In article <1993Feb18.182838.20432@unocal.com> mark@st.unocal.com writes:
>
>Does anyone know of an implementation of the OSPF routing protocol for
>SunOS??
>

Cornell University's GateD (Gateway Daemon) supports multiple routing protocol
like RIP-I/II, OSPF-2, BGP-2/3, EGP and Hello.  The newest version is Relese3.0
Alpha 4.  It is still ALPHA, but works fine on my SPARC (SunOS 4.1.2).

Anonymous FTP is avilable at gated.cornell.edu.  The newest GateD is 
/pub/gated/gated-R3_0Alpha_4.tar.Z.

---
  Masato Tsukakoshi

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Feb 1993 12:36:59 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: BSD sockets versus TLI calls

In article <1993Feb18.213904.9234@spectrum.xerox.com> leisner@eso.mc.xerox.com writes:
>Also, is BSD sockets posix compliant?  
>What is the POSIX mechanism for networking/IPC?

POSIX, in a now rare moment of sanity, decided to standardise BOTH
sockets and XTI/TLI interfaces.  The spec is not quite stable just
now, but rumour is that it will go to ballot by the end of 1993...



-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Feb 1993 14:12:51 GMT
From:      evansmp@uhura.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Net redirect in ICMP, why is it obsolete?

Ton Koelman (koelman@cuby.stc.nl) wrote:

Net redirection is obsolete because it dosn't send the netmask as
well.
Which is really needed with subneted and supernetted nets.

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

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 93 14:45:31 GMT
From:      gdha@se.alcbel.be (Gratien D'haese)
To:        comp.protocols.tcp-ip,comp.protocols.misc,comp.os.vms,vmsnet.networks.tcp-ip.misc
Subject:   VMS and PCNFS problems

>From mcla@bits.alcbel.be  Fri Feb 19 15:44

	Hi netters,

	We are trying to export an VMS file system in order to mount it
	from a SUN workstation and a (DOS)PC using FTP's PC/TCP software
	version 2.1.
	The tests succeed when trying a mount from an Ultrix machine but not
	from the SUN or the PC. The error message from the SUN mount is

	mount: btzv01:/mcladisk/mcla server not responding: RPC: Authentication
	error; why = Invalid client credential
	mount: giving up on:
   	/home5/u/isdn/mcla/vmsmount

	The error from the PC is :

	Authentication server did not respond. NFS filesystem not mounted.

	Has anybody of you similar experiences and what is the remedy?

	Thanks in advance for all who will respond.

	(The sun requires a PCNFS daemon. People at Dec pretend that 
	this isn't necessary for VMS. Is this so?)
		
Could you please reply via mail to mcla@bits.alcbel.be
Thanks.
--
  _______ 		Gratien D'haese    Switching Systems Division  se121
  \     /Alcatel			  F. Wellesplein 1, B-2018 Antwerpen
   \   /  Bell		e-mail: gdha@se.alcbel.be    Phone: (32) 3 240 94 51
    \/ Telephone		gdha@alcbel.be 	     Fax:   (32) 3 240 99 50

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Feb 93 15:16:19 GMT
From:      tomevans@ralvmm.vnet.ibm.com (tomevans@ralvmm.vnet.ibm.com)
To:        comp.protocols.tcp-ip
Subject:   Re: BSD sockets versus TLI calls

In article <C2p4Do.KA1@ra.nrl.navy.mil>, atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
|> In article <1993Feb18.213904.9234@spectrum.xerox.com> leisner@eso.mc.xerox.com writes:
|> >Also, is BSD sockets posix compliant?  
|> >What is the POSIX mechanism for networking/IPC?
|> 
|> POSIX, in a now rare moment of sanity, decided to standardise BOTH
|> sockets and XTI/TLI interfaces.  The spec is not quite stable just
|> now, but rumour is that it will go to ballot by the end of 1993...
|> 
|> 
Does anyone know of any applications written to the TLI/XTI interfaces,
public domain or otherwise? 
-- 
Tom Evans  TCP/IP Development
TOMEVANS@RALVMM.VNET.IBM.COM; (919) 254-4097

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Feb 1993 17:30:42 GMT
From:      lcypher@zero.cypher.com (Louis Cypher)
To:        comp.protocols.tcp-ip
Subject:   UUCP over TCP


I am just wondering about something. I recently started receiving my
news feeds over a SLIP link, and the transfer rates have dropped from
1600-1700 cps down to a blazing 160-170 cps. Does UUCP automatically
do this so that the SLIP line is not bogged down with the transfers?
Or is something wrong?



-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 93 18:51:33 GMT
From:      hudson@hal.com (Don Hudson)
To:        comp.protocols.tcp-ip,comp.os.os2.networking
Subject:   Re: SLIP Server for OS/2 2.0

(James R. Skinner) writes:
|> Doug_Smith@Novell.COM (J. Douglas Smith) writes:
|> 
|> >Does anyone know of a SLIP server for OS/2 2.0?  I'm using IBM's TCP/IP  
|> >package.
|> 
|> Start SLIP with the paramaters -ra
|> 
|> -- 

or get David Bolen's SLIP package from ans.net if you need a more capable
SLIP.  It supports startup scripts in REXX, so you can do things like
configure the modem to wait for the call, then do stuff like prompt for 
a login id and password, then send something like "Packet mode enabled" 
to the caller. (which is what I have to do to get SLIP going to my site).

--

Don Hudson

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 93 20:51:59 GMT
From:      gerwitz@sulu.kodak.com (Paul F Gerwitz)
To:        comp.lang.postscript,comp.protocols.tcp-ip
Subject:   Re: HP JetDirect for Unix

In article <C2MoF9.2Bu@well.sf.ca.us>, shiva@well.sf.ca.us (Kenneth Porter) writes:
|> I just got a Hewlett Packard Laserjet 4M (8ppm, PostScript, 6mb,
|> serial/parallel/Appletalk) and am considering getting the Unix
|> Ethernet interface.  Has anyone any experience with this critter?
|> It's advertised as being supported on Suns and HPUX, but my Sun is a
|> 386i so I expect that it's too old to be officially supported (it
|> runs SunOS 4.0.2).
|> 

I have been using Jet-Direct for connections both to a LaserJet-II and a
PaintJet-300XL.  The scripts and other things that HP provides have been
more than adequate for my needs.  In browsing over the filesets, It looks
like they even give you enough to 'roll-your-own' if need be.
-- 
 +----------------------------------------------------------------------------+
 | Paul F Gerwitz  WA2WPI  | SMTP: gerwitz@kodak.com                          |
 | Eastman Kodak Co        | UUCP: ..uunet!atexnet!kodak!eastman!gerwitz      |
 +----------------------------------------------------------------------------+

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Feb 1993 23:36:04 GMT
From:      bryan@uhura1.uucp (A. Bryan Curnutt)
To:        comp.lang.postscript,comp.protocols.tcp-ip
Subject:   Re: HP JetDirect for Unix

In article <C2MoF9.2Bu@well.sf.ca.us> shiva@well.sf.ca.us (Kenneth Porter) writes:
>I just got a Hewlett Packard Laserjet 4M (8ppm, PostScript, 6mb,
>serial/parallel/Appletalk) and am considering getting the Unix
>Ethernet interface.  Has anyone any experience with this critter?

I installed a JetDirect card in our LJ4 a couple of weeks ago.
I haven't messed around with it much yet, but can answer some of
your questions.

Source code is included with the SunOS software package.  Included in
this (commercially available for a sum of money) source code is the
following helpful statement:

 * (c) Copyright 1992 Hewlett-Packard Company.  All Rights Reserved.
 *
 * This source is for demonstration purposes only.
 *
 * Since this source has not been debugged for all situations, it will not be
 * supported by Hewlett-Packard in any manner.

The setup involves using a Sun machine as the spooler, and running the
software on the spool machine as a filter.  The filter appears to just
open a socket to communicate with the JetDirect card, and write any
data received by the lpr FIFO to that socket.  At first glance, I don't
see any protocols used other than just writing to the socket (except for
the printer initialization...).

The simplest setup involves creating separate print queues for the
PostScript and non-PostScript (text, HP-PCL, HP-GL) jobs.

So far, in the minimal amount of time I've spent on it, I haven't been
able to get any of the other filters (primarily lprps) working with the
JetDirect card.  On our serially-connected PostScript printer, we're
using dvitps piped to lprps as the DVI filter, but lprps uses some
ioctl() calls that are specific to serial ports, and don't work on the
network connection.

The software we have installed specifies SunOS 4.1.1, and the binaries
are for SPARC machines.  A competent HP vendor or sales rep would be
able to tell you whether it actually requires 4.1.1, or can be used
under 4.0.3.
-- 
Bryan Curnutt                                  Stoner Associates, Inc.
bryan%uhura1@uunet.uu.net       (713)626-9568 voice  (713)622-7832 fax

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 1993 23:50:06 GMT
From:      geoff@poori.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
To:        comp.protocols.tcp-ip
Subject:   Re: BSD sockets versus TLI calls

In article 9yn@ra.nrl.navy.mil, atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
##In article <1993Feb19.151619.23510@watson.ibm.com> tomevans@ralvmm.vnet.ibm.com (tomevans@ralvmm.vnet.ibm.com) writes:
##>Does anyone know of any applications written to the TLI/XTI interfaces,
##>public domain or otherwise? 
##
##There are a large number of TLI/XTI-based networking applications.
##

... and there are even more apps that run over XTI/TLI without
realizing it. Transport Independent RPC apps running on SVR4 UNIX, or
on DOS/Windows (built with our toolkit). Also apps written to sockets
running over an emulation library mapping sockets onto XTI/TLI (usually
with a bit of help from a streams module or something similar).

---
Geoff Arnold, PC-NFS architect, Sun Select. (geoff.arnold@East.Sun.COM)
--------------------------------------------------+-------------------
"What if they made the whole thing up?            | "The Great Lie" by
 Four guys, two thousand years ago, over wine..." |    The Tear Garden


-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Sat, 20 Feb 1993 14:04:15 GMT
From:      dedgar@mta.ca
To:        comp.protocols.tcp-ip
Subject:   ICMP NetUnreachable and TCP behaviour?

Hello

What should TCP do when it gets a ICMP network unreachable message in a
connection that is in the ESTABLISHED state. By this I mean the connection
has been working then a network unreachable message is received. 

Are spurious Network Unreachable messages very common? Kinda hate to 
shut down a TCB every time one of these arrives - but then it is not
right to keep transmitting if the net really has gone down.

What are your thoughts on this. What do other implementations do?

Thanks
							Dale Edgar
							Cybernetic Control Inc.
							DEDGAR@MTA.CA

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 1993 16:23:42 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: BSD sockets versus TLI calls

In article <1993Feb18.213904.9234@spectrum.xerox.com> leisner@eso.mc.xerox.com writes:
>Can someone point me at a good example of BSD sockets versus TLI calls?

"Unix Network Programming" by Stevens describes the differences and has
many examples.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 1993 16:27:41 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: how do you find port number of remote process

In article <C2poK4.Gz1@news.Hawaii.Edu> vasan@uhics.ics.Hawaii.Edu (T. R. Srinivasan) writes:
>	I am running a server process in one machine and a
>client in another machine. When I do bind in server process,
>I don't specify the port number (letting the machine assign 
>an unused one). But when I do connect in client, I need to
>specify the port number assigned to the server process.
>Is there a way to find the server process's port number
>from client program. 

Unless you're using a facility like the portmapper, a server needs to have
a fixed port number so that clients can find it.

If you're using the portmapper, the server can find out the port number
that was assigned by using getsockname() and then register the port with
the portmapper.  This simply replaces the well-known port number with a
well-known program number.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 1993 16:32:30 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP NetUnreachable and TCP behaviour?

In article <1993Feb20.140415.5371@jupiter.sun.csd.unb.ca> dedgar@mta.ca writes:
>What should TCP do when it gets a ICMP network unreachable message in a
>connection that is in the ESTABLISHED state. By this I mean the connection
>has been working then a network unreachable message is received. 

It should keep on trying until it times out.

>Are spurious Network Unreachable messages very common? Kinda hate to 
>shut down a TCB every time one of these arrives - but then it is not
>right to keep transmitting if the net really has gone down.

Network unreachables frequently occur when a router has gone down and the
routing protocols haven't stabilized on an alternate router.  With some
protocols this instability can last several minutes.

>What are your thoughts on this. What do other implementations do?

I think most BSD versions (perhaps everything before Net/2 or 4.4) close
the connection, and this is generally considered a bug.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 93 04:15:56 GMT
From:      6500msd@ucsbuxa.ucsb.edu (Michael D'Errico)
To:        comp.protocols.tcp-ip
Subject:   anyone using UDP?


Has anyone here used UDP instead of TCP to do their communication?
Sure TCP is great since it does a lot of work for you, but it also
requires a lot of network overhead that is often unnecessary.  I
was wondering how much extra work would be required to do the hand-
shaking manually (retransmission requests, packet ordering, etc.)
Some factors I'm interested in are relative design time, code size,
and traffic reduction for the two protocols.


Thanks,

Michael D'Errico
6500msd@ucsbuxa.ucsb.edu

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 93 11:24:40 GMT
From:      jshaw@actrix.gen.nz (Jim Shaw)
To:        comp.protocols.tcp-ip
Subject:   Help with routing problem

I am looking after a network that has 7 lans ( HP Unix +PC's on all except one
site that has several Suns and a mainframe) all of which are hooked up
with HP(Wellfleet routers) into a redundant network. 
ie there are at least 2 PTP lines into each router, as well as the LAN port. 

It looks like this:

where each site includes a LAN not detailed below.
All links are 48K bps.

-------------					-----------
|	    |					|	  |
| Site 1    |-----------------------------------| Site 2  |
|	    |					|	  |
------------					-----------
      |						     |
      |						     |
      |						     |
-------------		   -----------		-----------
|	    |	  	   |	      |		|	  |
| Site 3    |--------------| Site 4   |---------| Site 5  |
|	    |	  	   |	      |		|	  |
-------------		   -----------		-----------
      |						     |
      |						     |
      |						     |
-------------					-----------
|	    |					|	  |
| Site 6    |-----------------------------------| Site 7  |
|	    |					|	  |
------------					-----------


Site 4 is the key site to maintain connectivity to.

The routers are configured to use RIP only to communicate routes. 

The problem is that when a link goes down, user sessions ( tcp based) are lost
before the routers sort out a new route. Typically this takes 2-4 minutes.
Uses get a message of the form "Network unreachable" or sometimes a read error.

How can I speed this up. Will OSPF or EGP between the routers help at all?

Ideally I would like a new route established within 10-20 seconds.( or less)

Can anyone out there shed any light. 

Thanks, Jim

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 1993 19:21:18 +1030
From:      hart@flash.pax.tpa.com.au (Leigh M Hart)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Any ideas?

I've been trying to use both slipper and slip8250 to connect two spare
PC's I've got lying around.  I want them to be peer <-> peer, ie not
dependant on each other for anything in particular.

eg: I want to be able to write tcp-ip server/client programs and test
them on these machines.  For some reason I can't get slipper or 
slip8250 to act properly.  The null modem cable I'm using is fine,
has all the handshaking lines in the right place etc.  


Anyone done this before?  sucessfully?  It's giving me the screaming
$%(*!

:)

Thanks all.

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

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21 Feb 1993 17:05:54 GMT
From:      ole@Csli.Stanford.EDU (Ole Jacobsen)
To:        comp.protocols.tcp-ip
Subject:   Call for articles: ConneXions

Call for Articles

ConneXions--The Interoperability Report is a monthly technical
journal which covers all aspects for computer networking and
distributed computing. ConneXions seeks articles ranging from
technology tutorials and user case studies, to letters, opinions
and book reviews. For author guidelines, send a message to
ole@interop.com. Authors receive a complimentary lifetime sub-
scription.

Ole J Jacobsen, Editor & Publisher ConneXions--The Interoperability Report
Interop Company, 480 San Antonio Road, Suite 100, Mountain View, CA 94040,
Phone: (415) 962-2515  FAX: (415) 949-1779  Email: ole@csli.stanford.edu



-- 
*** PLEASE: Do not include my message in your reply. If you must include it,
please do so AFTER your reply rather than before it. Thank you very much.***

Ole J Jacobsen, Editor & Publisher ConneXions--The Interoperability Report

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 1993 20:38:08 GMT
From:      mjr@tis.com (Marcus J Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: anyone using UDP?

6500msd@ucsbuxa.ucsb.edu (Michael D'Errico) writes:
>
>Has anyone here used UDP instead of TCP to do their communication?
>Sure TCP is great since it does a lot of work for you, but it also
>requires a lot of network overhead that is often unnecessary.

	Have you actually profiled your application and determined
that the massive overhead of TCP is a performance bottleneck for you?
         ^  ;)

	I've used UDP, but only when I'm writing an application that
doesn't care if the data I'm sending gets there, or has simple, stupid,
idempotent operations. If you actually need reliable sequenced delivery,
you'll wind up wasting a huge amount of time re-implementing something
in your code that's probably slower than TCP anyhow, in addition to
being more complex and a waste of time. You actual mileage may vary,
of course.

mjr.

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 93 21:18:55 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: anyone using UDP?

In article <7737@ucsbcsl.ucsb.edu>
   6500msd@ucsbuxa.ucsb.edu (Michael D'Errico) writes:
>Has anyone here used UDP instead of TCP to do their communication?
>Sure TCP is great since it does a lot of work for you, but it also
>requires a lot of network overhead that is often unnecessary.  I
>was wondering how much extra work would be required to do the hand-
>shaking manually (retransmission requests, packet ordering, etc.)
>Some factors I'm interested in are relative design time, code size,
>and traffic reduction for the two protocols.

Believe it or not, if you need reliable delivery of sequenced data, TCP
(pr TP4) is about as efficient as you get. If you can dispense with either
the sequence or the reliability, you can get smaller, but generally, it's
not worth the trouble.

Some IMPLEMENTATIONS of TCP are less than optimal, of course. If you are
limited by a bad TCP implementation, you might want to consider getting
a better implementation, or writing a new and better TCP implementation,
rather than re-inventing the functions of TCP from scratch.

Van Jacobson found that processing a normal, in-sequence TCP packet
takes something like 37 instructions on a SPARC processor. Looking at
the protocol code, you realize that the full module is much larger than
that. All of the additional code deals with opening and closing
connections, recovering from errors etc; all of which you would have to
re-invent.

The major limitation of TCP is that it is designed for one-to-one
communication; reliable, sequenced delivery of one-to-many multicasts
(such as video or audio) requires a different protocol, which is where
most of the R & D work is going these days.
-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 93 21:24:54 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Help with routing problem

In article <1993Feb21.112440.16972@actrix.gen.nz>
   jshaw@actrix.gen.nz (Jim Shaw) writes:
>The routers are configured to use RIP only to communicate routes. 

What else would they be doing with RIP ?

>The problem is that when a link goes down, user sessions ( tcp based) are lost
>before the routers sort out a new route. Typically this takes 2-4 minutes.

Yes, it is typical for RIP (or any other distance vector protocol) to take
about that long to settle after a link state change.

>How can I speed this up. Will OSPF or EGP between the routers help at all?
>Ideally I would like a new route established within 10-20 seconds.( or less)

OSPF and IS-IS were designed to do make routes settle faster. 20-30
seconds are common for OSPF.

EGP is not meant to be used inside a routing domain, and it's being
phased out, anyway, in favor of BGP-4.
-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 1993 10:28:41 -0500
From:      kenh@leps5.phys.psu.edu (Ken Hornstein)
To:        comp.protocols.tcp-ip
Subject:   Re: ka9q for unix?

In article <1993Feb22.142842.17017@kub.nl> JBOSTERS@KUBVX1.KUB.NL (Jeroen Bosters) writes:
>
>Hi Netters,
>
>first I apoligise if this is not the right group to ask, but anyway. 
>Does anyone here know where I can find ka9q for unix, preferably in a 
>version the runs on a sun or an apollo machine.

Why on earth would you need it?  Unix has everything built-in that ka9q
does!

--Ken

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 93 12:22:48 PST
From:      dtomas@futon.SFSU.EDU ()
To:        comp.protocols.tcp-ip
Subject:   tcp/ip <-> X.25


	A friend of mine can send me mail via X.25 . I am on Internet(tcp/ip).
I have questions:

1) Do I need an account on a machine that provides x.25 so that I can 
   receive e-mail from a X.25 source? 
2) Are there any public Internet <-> X.25 gateways that I can access?

Is there anything else I should know? 

	All information, advice is gladly accepted.

	Thanks
	Danny Tomasevich
	dtomas@futon.sfsu.edu
 

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Feb 1993 10:37:23 GMT
From:      evansmp@uhura.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP NetUnreachable and TCP behaviour?

Barry Margolin (barmar@think.com) wrote:
: In article <1993Feb20.140415.5371@jupiter.sun.csd.unb.ca> dedgar@mta.ca writes:
: >What should TCP do when it gets a ICMP network unreachable message in a
: >connection that is in the ESTABLISHED state. By this I mean the connection
: >has been working then a network unreachable message is received. 
: 
: It should keep on trying until it times out.

Optionally passing this to the process as a SOFT error is also a possibility.

There is also the question of what the timeout should be.
: 
: >Are spurious Network Unreachable messages very common? Kinda hate to 
: >shut down a TCB every time one of these arrives - but then it is not
: >right to keep transmitting if the net really has gone down.
: 
: Network unreachables frequently occur when a router has gone down and the
: routing protocols haven't stabilized on an alternate router.  With some
: protocols this instability can last several minutes.

This is to be expected since the routing protocol data goes through
the same routes as the transmitted data.

You may have a domino effect where other routers are (temporally) overloaded.

: 
: >What are your thoughts on this. What do other implementations do?
: 
: I think most BSD versions (perhaps everything before Net/2 or 4.4) close
: the connection, and this is generally considered a bug.

It is also open to exploitation by people sending out ICMP packets.

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

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 1993 19:17:28 -0500
From:      tener@cs.widener.edu (Stuart Tener)
To:        comp.protocols.tcp-ip
Subject:   Re: ka9q for unix?

In article <1marf9$e2e@leps5.phys.psu.edu> kenh@leps5.phys.psu.edu (Ken Hornstein) writes:
>In article <1993Feb22.142842.17017@kub.nl> JBOSTERS@KUBVX1.KUB.NL (Jeroen Bosters) writes:
>>
>>Hi Netters,
>>
>>first I apoligise if this is not the right group to ask, but anyway. 
>>Does anyone here know where I can find ka9q for unix, preferably in a 
>>version the runs on a sun or an apollo machine.
>
>Why on earth would you need it?  Unix has everything built-in that ka9q
>does!
>
>--Ken

Ken:

	This is redicoulous! (<-sp?) I am not into amateur tcp/ip on
	packet, but I am into normal packet. And I am quite sure that if
	you plug a tnc into a serial port on a sun, and have the
	complete SunOS operating system installed, that there will be
	more software necessary than that which is provided by Sun.

	I think you are quite wrong in your quick, and somewhat
	obnoxious answer. The guy is obviously trying to get tcp/ip
	running under unix, and you are steering him in a redicoulous
	direction.

	I personally do not know the answer to this question, but would
	love to see what it takes to get tcp/ip running on a Sun or
	Apollo with packet radio.

	thank you,

	stuart b. tener, n3gwg
	tener@cs.widener.edu
	(215)-338-6005

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Feb 1993 11:41:40 GMT
From:      db3l@ans.net (David Bolen)
To:        comp.protocols.tcp-ip,comp.os.os2.networking
Subject:   Re: SLIP Server for OS/2 2.0

In article <1900@cogsci.ucsd.EDU> lopes@cogsci.ucsd.EDU (alann lopes) writes:

>In article <1m3a7lINNiv8@hal.com> hudson@hal.com (Don Hudson) writes:
>-
>-or get David Bolen's SLIP package from ans.net if you need a more capable
>-SLIP.  (...)
>
>Does this SLIP package allow multiple instances to work at the same time
>and be configured to any com port?  Has anyone ever used with a Digiboard?

It can be configured for any com port, but in its current incarnation
cannot have multiple instances running.  Actually, the goal is not to
require that - it has been designed to support several interfaces
itself, although that aspect isn't completely finished.  I plan to let
it handle as many interfaces as the TCP/IP kernel can (which is a
maximum of 10 as of the UB2252 CSD or later), without having to run
separate copies of the program.  The driver automatically creates the
necessary threads to dedicate to each interface.

As for the Digiboard, I don't know anyone offhand that is using such a
system (although I no longer know everyone who is using the driver),
but as long as the Digiboard drivers let the ports look like standard
OS/2 COM ports, there shouldn't be a problem.  The SLIP driver uses
standard OS/2 I/O functions (DosOpen/DosRead/DosWrite) and the defined
Async IOCtl (DosDevIOCtl) calls to manage interface ports.

-- David
--
/-----------------------------------------------------------------------\
 \              David Bolen             \  Internet: db3l@ans.net      /
  |   Advanced Network & Services, Inc.   \   Phone: (914) 789-5327   |
 / 100 Clearbrook Road, Elmsford, NY 10523  \   Fax: (914) 789-5310    \
\-----------------------------------------------------------------------/

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 93 11:52:00 GMT
From:      steve@terminus.ericsson.se (Steve Reynolds)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   WAN encapsulations?


There have been one or two questions on the net  recently about how to carry protocols such as X.25 OVER an IP network (rather than the 877 style IP over X.25). I'm sorry if this subject has been already fully discussed, but I missed any replies.

How can WAN products (X.25, SNA etc) take advantage of the routing capabilities of a router backbone? 

It seems on first discussion that there are three possible ways to carry a protocol such as X.25 across a router backbone.

1) Use Frame Relay. This has configurational problems for a large backbone and loses all of the routing gained from IP - is this true?

2) Use a proprietary WAN-TCP/IP-WAN gateway. I believe certain manufacturers offer this, but what is the reliability and performance of such as scheme and how many protocols are offered?

3) Try to incorporate a general encapsulation along the lines of  rfc 1241 into the WAN unit. Does this work for WAN protocols or is it a Datagram only encapsulation?


I'm sorry if this is one of those questions which is too big to answer, but if anyone can help with a little here or there then I will summarise.


Thanks in advance


steve



---

---------------------------------------------------
| Steve Reynolds                                  |
| Ericsson-CAMTEC                                 |
| Leicester                                       |
| UK                                              |
| TEL:    +44 533 537534                          |
| EMAIL:  steve@terminus.ericsson.se              |
---------------------------------------------------


-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 1993 21:57:21 -0500
From:      kenh@leps5.phys.psu.edu (Ken Hornstein)
To:        comp.protocols.tcp-ip
Subject:   Re: ka9q for unix?

In article <1mbqeoINNl4l@lucy.cs.widener.edu> tener@cs.widener.edu (Stuart Tener) writes:
>	I think you are quite wrong in your quick, and somewhat
>	obnoxious answer. The guy is obviously trying to get tcp/ip
>	running under unix, and you are steering him in a redicoulous
>	direction.

Uh-huh.  Let's see .... What does KA9Q have?

	Multitasking kernel		Comes with Unix.
	TCP/IP				Comes with Unix (on apollo and suns)
	Serial line drivers		Available for free

Note that I'm not trashing KA9Q at all ... I use it, and I love it.  But
Unix comes with everything you need, except packet radio drivers.  And porting
KA9Q to Unix would be kinda pointless, IMHO.  And I didn't think my original
reply was that obnoxious at all.  Obnoxious would have been something like:

"You stupid shithead, get a clue.  If you had any brains for all, you'd know
that Unix comes with everything you need!"

Which I didn't say, nor I meant.

--Ken

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Feb 1993 13:47:41 GMT
From:      stein@itek.norut.no (Stein Olav Toennessen)
To:        comp.protocols.tcp-ip
Subject:   How does packet switched network respond to continuous media?


We are doing research on how to transmit continuous media over packet switched 
networks. We are specially interested in results from measurements in real 
IP-networks. Has someone measured:

- How high the packet-/bit error rate is?
- How big the delay and the variance in the delay is? 
- Is it really a problem that packets arrives out of sequence?
- How much buffer space, due to synchronisation, must the receiver have in 
  different cases?

We would be grateful to get copy/reprints/hints on where to find research 
results covering this area for comparison with our own results.
__________________________________________________________________________
Stein Olav Toennessen 		Phone: +47 83 80150, Fax: +478382420
NORUT IT AS 
NORUT-Gruppen AS
N-9005 Tromsoe, Norway		E-mail: stein-olav.tonnessen@itek.norut.no
--------------------------------------------------------------------------

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Feb 1993 13:51:53 GMT
From:      aj@sage.cc.purdue.edu (John Dormer)
To:        comp.protocols.tcp-ip
Subject:   Re: anyone using UDP?

  You realize that if you get into trying to do the ordering guarantees that
TCP does, you will be reinventing the wheel. If you only want the lower parts
of TCP, like ports and other features it has in common with UDP, then use
UDP. 

  You may acheive some reduction in bandwidth by building your own protocol to
run on top of UDP, but not likely. I know I don't have enough experience yet
to design a protocol which would surpass TCP doing TCP's job.  You will also
spend lots of time debugging your protocol which you could have otherwise
spent on the applications. 8| This is where you  must make your decision.

:	John Dormer
:	Purdue Daemons
:	jad@expert.cc.purdue.edu
 

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Feb 93 14:28:42 GMT
From:      JBOSTERS@KUBVX1.KUB.NL (Jeroen Bosters)
To:        comp.protocols.tcp-ip
Subject:   ka9q for unix?


Hi Netters,

first I apoligise if this is not the right group to ask, but anyway. 
Does anyone here know where I can find ka9q for unix, preferably in a 
version the runs on a sun or an apollo machine.

thanx in advance

Jeroen



*******************************************************************************
* Jeroen Bosters            * Student of Information Management & Technology  *
* Schoolstraat 363          * at Tilburg University, the Netherlands          *
* 5038 RL  Tilburg          ***************************************************
* The Netherland            *   " The prince of darkness is a gentleman ...   *
* JBOSTERS@KUB.NL           *        ... Modo he's called and Mahu   "        *
* jbosters@nyx.cs.du.edu    *                   Shakespeare,  King Lear       *
*******************************************************************************

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Feb 1993 15:28:47 GMT
From:      erick@demorgan.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: anyone using UDP?

 6500msd@ucsbuxa.ucsb.edu (Michael D'Errico) writes:
>
>Has anyone here used UDP instead of TCP to do their communication?
>Sure TCP is great since it does a lot of work for you, but it also
>requires a lot of network overhead that is often unnecessary.  

It sounds like you don't mind TCP's constraints (one-to-one, etc.)

TCP has a lot of thought in it, but that doesn't mean it's bulky.
On a decent implementation it blows away most 'lite' protocols
on LANs and even moreso on WANs.

Inventing your own protocol assumes you will have more experience
and resouces than the Internet over the last many years.  The
Inet crowd is not static, if there were a significantly better
protocol than TCP, we would be running it over IP today.  

The other thing TCP gives you is scalability and interoperability.
These may be the last things on your mind today, but you will
eventually kick yourself when you realize that you need these
things and you have to rethink or port your proprietary protocol.

In summary, TCP is both the volkswagon and the porshe.  It can
be tuned to be more conserative or more speed hungry, but most
people don't even need to do such tuning.

Erick

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

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Feb 1993 15:29:05 GMT
From:      etxmesa@eos.ericsson.se (Michael Salmon)
To:        comp.protocols.tcp-ip
Subject:   Re: anyone using UDP?

In article <C2uruH.2ts@mentor.cc.purdue.edu>
aj@sage.cc.purdue.edu (John Dormer) writes:
|>   You realize that if you get into trying to do the ordering guarantees that
|> TCP does, you will be reinventing the wheel. If you only want the lower parts
|> of TCP, like ports and other features it has in common with UDP, then use
|> UDP. 
|> 
|>   You may acheive some reduction in bandwidth by building your own protocol to
|> run on top of UDP, but not likely. I know I don't have enough experience yet
|> to design a protocol which would surpass TCP doing TCP's job.  You will also
|> spend lots of time debugging your protocol which you could have otherwise
|> spent on the applications. 8| This is where you  must make your decision.

I have seen several articles along this theme and I wondered if this
wisdom applied to remote procedure calls? Especially between physically
close computers and with short messages.

-- 

Michael Salmon

#include	<standard.disclaimer>
#include	<witty.saying>
#include	<fancy.pseudo.graphics>

Ericsson Telecom AB
Stockholm

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 93 16:53:49 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: WAN encapsulations?

In article <1257@quirm.terminus.ericsson.se> steve@terminus.ericsson.se writes:
>
>There have been one or two questions on the net  recently about how to carry protocols such as X.25 OVER an IP network (rather than the 877 style IP over X.25). I'm sorry if this subject has been already fully discussed, but I missed any replies.
>
>How can WAN products (X.25, SNA etc) take advantage of the routing capabilities of a router backbone? 
>
>It seems on first discussion that there are three possible ways to carry a protocol such as X.25 across a router backbone.
>
>1) Use Frame Relay. This has configurational problems for a large backbone and loses all of the routing gained from IP - is this true?

X.25 packet level requires reliable delivery from each link level hop.  Without
this, a dropped or misordered packet will cause a VC Reset and probable loss of
even more packets.  FR only provide "best effort" datagram service.

>2) Use a proprietary WAN-TCP/IP-WAN gateway. I believe certain manufacturers offer this, but what is the reliability and performance of such as scheme and how many protocols are offered?

Most proprietary schemes tunnel the X.25 data packets using a reliable transport
protocol (typically TCP).  This is probably as good a technical solution as one
is going to find.

>3) Try to incorporate a general encapsulation along the lines of  rfc 1241 into the WAN unit. Does this work for WAN protocols or is it a Datagram only encapsulation?

People in the IETF on occasion have discussed defining a standard for tunneling
X.25 using TCP/IP.  These attempts have never proceded to an actual document as
far as I can remember.

>
>I'm sorry if this is one of those questions which is too big to answer, but if anyone can help with a little here or there then I will summarise.
>
>
>Thanks in advance
>
>
>steve

Art

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 93 19:58:36 GMT
From:      880506s@dragon.acadiau.ca (James R. Skinner)
To:        comp.protocols.tcp-ip,comp.os.os2.networking
Subject:   Re: SLIP Server for OS/2 2.0

db3l@ans.net (David Bolen) writes:

>It can be configured for any com port, but in its current incarnation
>cannot have multiple instances running.  Actually, the goal is not to
>require that - it has been designed to support several interfaces
>itself, although that aspect isn't completely finished.  

Wow this would be really nice.  Hope you get some spare time soon 8-)

-- 

-----------------------------------+--------------------------------------------
        James Robie Skinner        |     Jodrey School of Computer Science        James.Skinner@dragon.acadiau.ca  |  Acadia University, Wolfville, NS, Canada
-----------------------------------+--------------------------------------------

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1993 09:23:56 -0800
From:      brian@network.ucsd.edu (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Re: ka9q for unix?


The latest version of the KA9Q NOS package is always available from host
UCSD.EDU via anonymous FTP.  Look in the /hamradio/packet/tcpip/ka9q
directory.  There are other variants, accessories, and associated files
in the surrounding directories.


There is no mail server available for non-FTP people.  Sorry.
	- Brian

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 93 20:28:02 GMT
From:      cmo@pogo.wv.tek.com (Christine Olsen)
To:        comp.protocols.tcp-ip
Subject:   XNS spec


Does anyone know where I can find an XNS specification?

Please reply via email: cmo@pogo.wv.tek.com

Thanks for any help!

Christine

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 93 21:06:06 GMT
From:      tm8t+@andrew.cmu.edu (Tod McQuillin)
To:        comp.protocols.tcp-ip
Subject:   X.25 and Unix

I have a good idea of the theory involved as far as packet switching
and network communication protocols go.  What I'm lacking is practical
knowledge, in terms of dollars and cents and nuts and bolts.

What kind of hardware and software does it take to get a Unix machine
running TCP/IP connected to an X.25 network like Sprintnet?  How much
does it cost?

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 93 21:45:48 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   ICMP NetUnreachable and TCP behaviour?

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

   In article <1993Feb20.140415.5371@jupiter.sun.csd.unb.ca> dedgar@mta.ca writes:   >What should TCP do when it gets a ICMP network unreachable message in a
   >connection that is in the ESTABLISHED state. By this I mean the connection
   >has been working then a network unreachable message is received. 

   It should keep on trying until it times out.

Sorry, Barry, I've been Karnized.  You're wrong.  You should dedicate
a limited amount of resources to your TCP/IP services.  If you go
over that limit, then you time out the connection with the highest
retransmit period (or perhaps refuse the new connection if the
"failed" connection has not been failing for very long).

For non-interactive connections, e.g. SMTP, timing out does not make
sense.  Far better to keep trying as long as you have the memory
resources.

If something is taking a very long time, the user should be alerted
and given a chance to cancel.  But the operating system should not be
making that decision based on a fixed period of time.

-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Feb 1993 23:07:39 GMT
From:      evans@tsd.arlut.utexas.edu (Eric Evans)
To:        comp.protocols.tcp-ip
Subject:   Zombie UDP ports?

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

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

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

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

Does anyone have a clue about this behavior?  It seems I remember seeing 
something like this on Usenet before.

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



-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 93 23:13:04 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: anyone using UDP?

In article <1993Feb22.190228.24321@mdd.comm.mot.com>, bradley@mdd.comm.mot.com (Michael Bradley) writes:
> ...
>  One may have little choice depending on requirements. We are working
> in an environment where bandwidth is low and expensive (wireless).
> TCP header overhead (assuming you cant use header compression) and
> connection setup and tear down are an expense one may or may not be
> able to deal with. Not everybody has the luxury of megabit - 
> essentially for free bandwidth.
>  
>   Michael Bradley


1. There is not a lot of fat in the 20 byte TCP header.
    Any link so slow that it has serious problems with the 20 byte TCP
    header is going to have essentially just as serious problems with
    the 8 byte UDP header.

2. If you cannot use header compression, than you are not likely to
    be able to roll your own protocol.  Obviously, TCP/IP+header
    compression would be considered a "new" protocol.

    There are many ways to compress the 40 byte TCP/IP headers.
    16 bits is quite enough for those 40 bytes if you use an 8-bit link
    layer checksum and give up the end-to-end TCP data checksum.

3. Connection set up and tear down can be expensive, as can the 
    expense of maintaining thousands of semi-active or inactive
    connections.  That is why UDP is still the better choice for
    NFS and many RPC applications.  NFS over TCP is right if you don't
    mind some more per-client state on the server and if your network
    is subject to problems not found on correctly functioning LAN's.


Vernon Schryver,  vjs@sgi.com

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 93 23:40:36 GMT
From:      rodo@.auspex.com (Rod Livingood)
To:        comp.protocols.tcp-ip
Subject:   Request: ip verification testsuite

Is there an IP verifiation program similar to the connectathon
available either publically or for purchase?  Also, has anyone
seen more information regarding CTP?

-- 
Rod Livingood


-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Feb 1993 23:42:33 GMT
From:      landman@hal.physics.wayne.edu (Joe Landman)
To:        comp.protocols.tcp-ip,comp.os.os2.networking
Subject:   Re: SLIP Server for OS/2 2.0

Well, I have Dave Bolens package, and it works nicely, but the site I am dialing
into is dropping slip in favor of PPP.  Is there a PPP driver in the works
for 1.2.1 ?  Is it not to painful to hack out using someone-elses
PPP driver?  Any help would be appreciated.

Joe Landman
landman@hal.physics.wayne.edu

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Feb 1993 00:12:06 GMT
From:      will@physuna.phs.uc.edu (David Will)
To:        biz.sco.general,comp.sys.sun.admin,alt.sys.sun,comp.protocols.nfs,comp.protocols.tcpip,comp.unix.aix,comp.unix.admin
Subject:   on and rlogin security on the internet

 I'm interested in the security issues regarding rlogin and the nfs on command
when a network is added to the internet.  

Specifically it appears that if a machine on the internet has the same hostname 
and one ip number pair that is the same as a trusted machine's on a 
local network and a user with the same uid then that user can gain 
access to that machine running the  rexd via the on command.  Is this accurate? 

It seems that one could just create a machine give it two ip addresses (looks
like a gateway), one ip for the network it really is connected to and one that
matches the target machine. Then with the same hostname and an appropriate uid
thats all there is to it.  Similarly rlogin presents the same hole if host.equiv
is used within the local network.

Is there anyway of protecting against this hole other than hiding your 
hostname ,ip and uid's?  Any way to prevent rpc packets from being routed
to the internet?  Is there anyway of qualifying packets?  

I would like to hear about solutions that don't involve secure nfs or 
other security systems unless this is the only way to secure the system. 
Some of the systems I'm concerned about don't currently support secure NFS.
Is there some difficulty presented to the potential hacker that 
I'm overlooking?  I've notice that few systems run the
rexd for on but many if not most support rlogin and hosts.equiv.  Is there 
some reason that rlogin is considered more secure than on?

Please write to me at will@physunc.phy.uc.edu as my news connection is currently
unreliable.

Thanks
David Will


-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 93 06:38:57 CST
From:      tannenba@cae.wisc.edu (Todd Tannenbaum)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.unix.admin
Subject:   Netserve-92 from Traakan

Anyone out in newsland use Netserver-92 from Traakan Software??
This is a package that turns your pc into an nfs/lpd/modem server.

I am looking for comments/experiences from people using this
software.  I'd be very grateful if you could email your thoughts and
experiences (good & bad) with the product to me at tannenba@engr.wisc.edu.

Thanks!

-- 
Todd Tannenbaum, Network Manager   | e-mail: tannenba@engr.wisc.edu
Computer Aided Engineering Center  | Voice Ph: (608) 262-3118
University of Wisconsin-Madison    | Fax Ph: (608) 262-6707

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Feb 93 01:14:15 GMT
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: ka9q for unix?

In article <1mbqeoINNl4l@lucy.cs.widener.edu> tener@cs.widener.edu (Stuart Tener) writes:
>In article <1marf9$e2e@leps5.phys.psu.edu> kenh@leps5.phys.psu.edu (Ken Hornstein) writes:
>>In article <1993Feb22.142842.17017@kub.nl> JBOSTERS@KUBVX1.KUB.NL (Jeroen Bosters) writes:
>>>first I apoligise if this is not the right group to ask, but anyway. 
>>>Does anyone here know where I can find ka9q for unix, preferably in a 
>>>version the runs on a sun or an apollo machine.
>>
>>Why on earth would you need it?  Unix has everything built-in that ka9q
>>does!
 
>	I think you are quite wrong in your quick, and somewhat
>	obnoxious answer. The guy is obviously trying to get tcp/ip
>	running under unix, and you are steering him in a redicoulous
>	direction.

No, Ken is pretty much right.  Your statement "trying to get tcp/ip
running under unix" is the crux.  Most every version of UNIX ships
with TCP/IP!

>	I personally do not know the answer to this question, but would
>	love to see what it takes to get tcp/ip running on a Sun or
>	Apollo with packet radio.

All it takes is a packet radio driver.  ka9q was written for packet
radio, but with any clarkson (crynwr) driver, will work with anything
from Ethernet to Token Ring.  (For PC's, that is).  Thus, the answer
is NOT to have ka9q for UNIX (which is re-porting the wheel), but
having a packet radio driver.

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

--Dave
-- 
System Administrator, Population Research Institute    barr@pop.psu.edu
What does it profit a man if he gains the whole world, but still runs DOS?

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1993 01:35:19 GMT
From:      Andrew Nielsen <anielsen@uniwa.uwa.edu.au>
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: MacTCP and TokenTalk -> 8209 -> Ethernet

In article <veizades-140293213234@kip-55.apple.com> John Veizades,
veizades@apple.com writes:
>An IBM 8209 bridge sends packets to the ethernet is one of two forms.  If
>it sees an 802.3 packet from the ethernet host all packets are sent to
 that
>host as 802.3 packets, if iit sees an ethernet v2 packet all packets are
>sent in ethernet v2 format.  A macintosh sends 802.3 packets for
 AppleTalk
>and ethernet v2 packets for TCP/IP and this is where the problem with the
>8209 bridge begins.  MacTCP 1.1.1 will understand both types of packets
 and
>will solve the 8209 problems for TCP/IP but if the bridge first sees an
>ethernet v2 packet first AppleTalk won't work over this connection.  IBM
>may have a fix for this and you should check with them.

From memory, there was a really good article about this scenario by Garry
Hornbuckle, in a recent issue of "Connections".

_________________________________________________________________________
Andrew D. Nielsen                    Internet : anielsen@uniwa.uwa.edu.au
Computer Support Officer             AppleLink: AUST0190
Winthrop Technology                  
The University of Western Australia                    Tel: +61-9-3801757
NEDLANDS WA 6009   AUSTRALIA                           FAX: +61-9-3821688

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1993 02:14:45 GMT
From:      mjr@tis.com (Marcus J Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: ka9q for unix?

tener@cs.widener.edu (Stuart Tener) writes:
	This is redicoulous! (<-sp?) I am not into amateur tcp/ip on
>	packet, but I am into normal packet. And I am quite sure that if
>	you plug a tnc into a serial port on a sun, and have the
>	complete SunOS operating system installed, that there will be
>	more software necessary than that which is provided by Sun.

	You'd need a driver for the TNC interface to handle sending
and receiving packets on it. The IP stack on a UNIX machine generally
handles doing all the magic stuff and then (much like ka9q) queues a
packet on an interface for transmission. To add a driver for a tnc,
I guess you'd be well off starting by looking at some of the ethernet
drivers or the SLIP driver. I don't know of any existing tnc drivers,
but then I'm no ham.

mjr.

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1993 03:06:41 GMT
From:      rfrink@meaddata.com (Rick Frink)
To:        comp.protocols.tcp-ip
Subject:   ttcp info

  Does anybody know where I can get some info on ttcp, like a MAN
 page ?


-- 
Rick Frink                                              (513) 865-1645
Mead Data Central                             Telecomm/Campus Networks
P.O. Box 933                                       rfrink@meaddata.com
Dayton, Ohio  45401                          ...!uunet!meaddata!rfrink

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Feb 1993 13:47:36 -0500
From:      amanda@intercon.com (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: anyone using UDP?

bradley@mdd.comm.mot.com (Michael Bradley) writes:
>  One may have little choice depending on requirements. We are working 
> in an environment where bandwidth is low and expensive (wireless). TCP 
> header overhead (assuming you cant use header compression) and 
> connection setup and tear down are an expense one may or may not be 
> able to deal with. Not everybody has the luxury of megabit - 
> essentially for free bandwidth. 

If you are working over wireless, though, the last thing you probably want to 
use is UDP.  Rather, you should design a special-purpose protocol that makes 
best use of the medium.  For example, in our recent demos of wireless email 
at MacWorld Expo and Mobile '93, we don't even try to run SMTP over the air--
a full duplex protocol would be prohibitively expensive.  Instead, we use an 
application-level protocol optimzed for the characteristics of the carrier 
(RAM Mobile Data, in this case), essentially half duplex with acks, to send 
messages to a gateway which then forwards them on via SMTP (and handles 
incoming ones the same way).

On the other hand, with the advent of digital cellular and other real-time 
packet and circuit switched wireless data services, we probably *will* end up 
running TCP over the air.  It's just not practical at the moment given the 
current state of the marketplace (unless of course you're running a point-to-
point link with Cylink gear or something similar).

I'm sure that you folks (and other wireless service providers) will come up 
with ways to deliver more bandwidth at lower costs as time goes on... ;).


Amanda Walker
InterCon Systems Corporation



-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1993 10:30:43 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP NetUnreachable and TCP behaviour?

In article <730267630snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
>Sorry, Barry, I've been Karnized.  You're wrong.  You should dedicate
>a limited amount of resources to your TCP/IP services.  If you go
>over that limit, then you time out the connection with the highest
>retransmit period (or perhaps refuse the new connection if the
>"failed" connection has not been failing for very long).

I nice ideal, but I think it's unrealistic in most OSes.  It's easy to do
this if the resource that's exhausted is the TCB table.  But there are too
many other kinds of resources that may be related to a TCP connection, and
having the code that handles resource exhaustion for each of them call into
TCP is unlikely.  For instance, I would be very impressed to see an OS
whose handler for a full process table goes looking for hung TCP
connections to kill.

>For non-interactive connections, e.g. SMTP, timing out does not make
>sense.  Far better to keep trying as long as you have the memory
>resources.

Most mailers will return a message as undeliverable if it can't be sent for
a few days.  If nothing else, the TCP timeout should be set to the time
remaining before the message should be returned.  Otherwise, if the
receiving system dies in the middle of a delivery, that pending delivery
will never time out.

Also, since most mailers (except, perhaps, synchronous mailers on personal
computers) have their own high-level retry facility, it may be better to
allow the TCP level to time out sooner.  Suppose a machine dies and its
name is reassigned to a machine with a different address.  Deliveries in
progress should time out, and when the mailer retries them it should do the
name-to-address lookup again.

>If something is taking a very long time, the user should be alerted
>and given a chance to cancel.  But the operating system should not be
>making that decision based on a fixed period of time.

And what if the user is at the other end of the comatose connection?  For
instance, how does a TELNET server alert the user?
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Feb 93 11:19:16 GMT
From:      saetenar@geos01.sinet.slb.com (Arne Saeten)
To:        comp.protocols.tcp-ip
Subject:   High-speed TP

Keywords: 



Hello!


I am going to build up a FDDI network with max. 80 nodes. 77 of them are going
to send to three masters which receive data from the "slave" nodes. So I 
have 77 nodes that send data, and 3 that receive this data. I know exactly
what kind of data that are sent, and I know exactly when the data are sent.
I do not need routing!

What kind of reliable end-to-end protocol should I use ?????

I need really high data-rate, say > 1 Mbps from each of the 77 send-nodes, 
which means each of the receive-nodes must be able to handle ~26 Mbps.
The application is very specific, so I am wondering if I can use TCP/IP.
(It would be easiest)



Hope for suggestions/comments !!


saetenar@oslo.sgp.slb.com

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 93 18:03:05 CST
From:      lkim@swri.edu (Louis Kim)
To:        rec.arts.books,comp.protocols.tcp-ip,biz.books.technical,misc.books.technical
Subject:   Re: OBS: Chapter 3 of The Internet Companion Availabl

In article <BZS.93Feb16002404@world.std.com> bzs@world.std.com (Barry Shein) writes:
>Subject: OBS: Chapter 3 of The Internet Companion Availabl
>From: bzs@world.std.com (Barry Shein)
>Date: Tue, 16 Feb 1993 05:24:04 GMT
>
>
>				   
>			     Tracy LaQuey
>				   
>			    Editorial Inc.
>				   
>			 Software Tool & Die
>				   
>				 and
>				   
>		      The Online BookStore (OBS)
>				   
>		       Are Pleased To Announce
>				   
>			Another Installment Of
>				   
>
>			The Internet Companion
>
>
>The Online BookStore (OBS) continues with their first simultaneous
>electronic and print publication of a major new book: The Internet
>Companion: A Beginner's Guide to Global Networking by Tracy LaQuey
>with Jeanne C. Ryer (Addison-Wesley, $10.95).
>
>Online copies of Vice-President-elect Al Gore's Foreword and the first
>three chapters of this best-selling book are available via anonymous
>FTP from:
>
>			    world.std.com
>
>in the directory:
>
>		     /OBS/The.Internet.Companion/
>
>Further chapters will be released in the future. See the README and
>COPYRIGHT files in that directory for more details. Direct comments
>and questions about the book to:
>
>		   internet-companion@world.std.com
>
>This pioneering effort is a step in bringing together the on-line
>electronic and print media, enabling authors to explore new avenues of
>publishing their works. Comments, inquiries, etc. welcome: Send to
>obs@world.std.com.
>
>-- 
>        -Barry Shein
>
>Software Tool & Die    | bzs@world.std.com          | uunet!world!bzs
>Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
 -
| Louis J. Kim                      ---  _ O                PH:512-522-5556 |
| Southwest Research Institute    ---  ,/  |\/'            FAX:512-522-3042 |
| Post Office Drawer 28510      ----      |__                 lkim@swri.edu |
| San Antonio, TX 78228-0510   ----    __/   \    76450.2231@compuserve.com |

                                                                             

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Feb 93 12:45:40 GMT
From:      phanacek@nyx.cs.du.edu (Petr Hanacek)
To:        comp.protocols.tcp-ip
Subject:   PC/TCP API description ?

Is there any PC/TCP programming API description?

   Thanks.

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 93 15:17:24 GMT
From:      erick@demorgan.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: anyone using UDP?


 bradley@mdd.comm.mot.com (Michael Bradley) writes:
> (John Dormer) writes:
>>  You realize that if you get into trying to do the ordering guarantees that
>>TCP does, you will be reinventing the wheel. If you only want the lower parts
>>of TCP, like ports and other features it has in common with UDP, then use
>>UDP. 
>>
>>  You may acheive some reduction in bandwidth by building your own protocol to
>>run on top of UDP, but not likely. I know I don't have enough experience yet
>>to design a protocol which would surpass TCP doing TCP's job.  You will also
>>spend lots of time debugging your protocol which you could have otherwise
>>spent on the applications. 8| This is where you  must make your decision.
>>
>
> One may have little choice depending on requirements. We are working
>in an environment where bandwidth is low and expensive (wireless).
>TCP header overhead (assuming you cant use header compression) and
>connection setup and tear down are an expense one may or may not be
>able to deal with. Not everybody has the luxury of megabit - 
>essentially for free bandwidth.
> 

But that makes the case for TCP even stronger.  You start with a 
working TCP, tune it for the speed characteristics and $ cost per
packet and that's it.  The beauty of TCP is that you do it once 
and so many applications inherit your work.  Push people
onto UDP and you start seeing constant re-invention.  Look at NFS
tuneups, TFTP tuneups, etc.

In packet radio and cellular situations it is reasonable to do
proxy TCP whereby you connect up to a well connected host and
do TCP through it, but I would particularly recommend a tuned
TCP for the low bandwidth part.

                 tuned TCP	             normal TCP
     handheld -  -  -  -  - - PROXY HOST ________________________ INTERNET


After all, some of TCPs refinements came from radio, eg. KA9Q's 
idea of discarding unappropriate round-trip-times.

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

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 93 15:55:42 GMT
From:      drp@dpfe.UUCP (drp)
To:        ncr.communications,ncr.dcom.tcp-ip,att.dcom.tcp-ip,comp.protocols.tcp-ip
Subject:   Repost of rwhod error

CSD at EMD has tcp/ip running with 4 towers & one directly connected to
WIN. We communicate fine with everyone. The problem is we receive the 
following in /usr/etc/syslog on all 4 TOWERS:

rwhod Level: 6, Pid: xxx, malformed host name from nnnnnnnn (host name)

I have checked all route & name tables on the systems & find nothing wrong.
What have I over looked or suggestions to check or does rwhod have a bug?

Thanks
-------- 1 reply stated below  ------
We too have seen this message but can not figure out where it comes from.
I actually have a (very low priority) bug report assigned to me to figure out 
where/why this is coming from.

Thanks in advance,
Scott
-------- 2nd reply stated below  -------
Received 1 reply that host name was possibly invalid - this is not the case.
All of the host names are correct. The nnnnnnnnn is for one TOWER which has
a valid host name. The nnnnnnnnn address varies depending on which TOWER was
brought up first. Normally 1951935ab is first, but 1951935ac has been the
one reported to be incorrect when it was the first TOWER brought up on the
network.
Scott - perhaps you can pass this information along with your very low priority
bug report. 

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Feb 1993 16:30:19 GMT
From:      bradley@mdd.comm.mot.com (Michael Bradley)
To:        comp.protocols.tcp-ip
Subject:   Re: ka9q for unix?

In article <1mbqeoINNl4l@lucy.cs.widener.edu> tener@cs.widener.edu (Stuart Tener) writes:
>In article <1marf9$e2e@leps5.phys.psu.edu> kenh@leps5.phys.psu.edu (Ken Hornstein) writes:
>>In article <1993Feb22.142842.17017@kub.nl> JBOSTERS@KUBVX1.KUB.NL (Jeroen Bosters) writes:
>>>
>>>Hi Netters,
>>>
>>>first I apoligise if this is not the right group to ask, but anyway. 
>>>Does anyone here know where I can find ka9q for unix, preferably in a 
>>>version the runs on a sun or an apollo machine.
>>
>>Why on earth would you need it?  Unix has everything built-in that ka9q
>>does!
>>
>>--Ken
>
>Ken:
>
>	This is redicoulous! (<-sp?) I am not into amateur tcp/ip on
>	packet, but I am into normal packet. And I am quite sure that if
>	you plug a tnc into a serial port on a sun, and have the
>	complete SunOS operating system installed, that there will be
>	more software necessary than that which is provided by Sun.
>
>	I think you are quite wrong in your quick, and somewhat
>	obnoxious answer. The guy is obviously trying to get tcp/ip
>	running under unix, and you are steering him in a redicoulous
>	direction.
>
>	I personally do not know the answer to this question, but would
>	love to see what it takes to get tcp/ip running on a Sun or
>	Apollo with packet radio.
>
>	thank you,
>
>	stuart b. tener, n3gwg
>	tener@cs.widener.edu
>	(215)-338-6005

The following may be out of date but its worth a try. I saved this
from one of the cellurar lists:

||KA9Q is available from SIMTEL (wmsr-simtel20.army.mil) in the
||directory PD1:<MSDOS.KA9Q-TCPIP> 
||
||This is mirrored on various archive sites for anonymous ftp
||src.doc.ic.ac.uk:/computing/systems/ibmpc/wmsr-simtel20.army.mil/ka9q-tcpip
||wuarchive.wustl.edu:/mirrors/msdos/ka9q-tcpip
||
||If you don't have Internet access you can use the 'trickle'
||mail-server.  Send a mail message to trickle@awiwuw11.bitnet with the
||command 'help' in the body of the message.
||
||

 It could be that the the requester actually wants to hack the code.
While the Berkeley source is also available, the ka9q is (IMHO) a
little more streamlined (although having less features).

 Michael Bradley


-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Feb 1993 16:32:47 GMT
From:      erick@demorgan.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP NetUnreachable and TCP behaviour?

 nelson@crynwr.com (Russell Nelson) writes:
> barmar@think.com writes:
>   someone wrote:
>   >What should TCP do when it gets a ICMP network unreachable message in a
>   >connection that is in the ESTABLISHED state. By this I mean the connection
>   >has been working then a network unreachable message is received. 
>
>   It should keep on trying until it times out.
>
>Sorry, Barry, I've been Karnized.  You're wrong.  You should dedicate
>a limited amount of resources to your TCP/IP services.  If you go
>over that limit, then you time out the connection with the highest
>retransmit period (or perhaps refuse the new connection if the
>"failed" connection has not been failing for very long).
>
>For non-interactive connections, e.g. SMTP, timing out does not make
>sense.  Far better to keep trying as long as you have the memory
>resources.

Before making the blanket statement, you may want to think about how
there can be other resources tied to a connection, such as file
resouces, locks, physical devices, etc.

Suppose you have a FTP daemon with a half downloaded file and a 
dead connection which would have timed out under other circumstances.
It may become necessary to kill the FTPD just to unlock the file.  And
that implies a privileged user on many systems as well as some
form of human intervention.  And if the system doesn't kill connections
and processes, other seemingly unrelated problems occur.

In my humble experience, the bulk of transfers are not performed
at a user level.  Instead they are mail, news, file backup and
and remote file updates (eg. mirrored FTP sites) and consitute
massive amounts of data.  Some should be persistant while others
make sense to fail in a timeout.

>If something is taking a very long time, the user should be alerted
>and given a chance to cancel.  But the operating system should not be
>making that decision based on a fixed period of time.

I agree, what is missing from XTI and BSD but quite needed is
a warning level rather than an errorlevel.  My suggestion is
adding something like ECOMATOSE to the list of errno and treating
it like an error in calls to read/write/etc, but not failing 
subsequent i/o.  That leaves it up to the application to
treat as an error, or to ignore it, or to ask the user for 
an action.

Erick

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

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Feb 1993 01:17:17 -0500
From:      Tod McQuillin <tm8t+@andrew.cmu.edu>
To:        comp.protocols.tcp-ip
Subject:   firewalls and host unreachable

Since I have to diagnose a lot of network problems in my job, I've
gotten into the habit of investigating every "Host unreachable" error
I encounter just out of habit.

But it drives me crazy when traceroute says the host is reachable just
fine, thank you, even when TCP connections fail.  I wish there was
an error message like "Access to TCP port 21 denied through gateway
sub39gate.borland.com", instead of the incredibly vague errors I have
to endure now.

I expect this isn't feasable with IP the way it stands, but I'd
certainly like the see this added to whatever great protocol inherits
the internet from IP.

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Feb 1993 17:00:42 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: anyone using UDP?

In article <1993Feb22.190228.24321@mdd.comm.mot.com> bradley@mdd.comm.mot.com (Michael Bradley) writes:
   We are working in an environment where bandwidth is low and
   expensive (wireless).

So are we (dialup), though the crunch isn't quite so bad.

   TCP header overhead (assuming you cant use header compression) and
   connection setup and tear down are an expense one may or may not be
   able to deal with.

If your TCP doesn't have header compression, then you should implement
it.  It's really not that tough (there's sample code in the RFC!), and
it gains you so much, particularly in a low-bandwidth environment like
wireless or dialup.

Session setup and teardown expense is a different problem, but at
least you're only hit once per session.  If you leave your sessions
open for extended periods of time, the setup/teardown won't hurt much,
though you'll have to carry around a chunk of state for each
connection.  And if you want to avoid the one-time SYN/FIN expense,
then you'll be stuck with non-header-compressible UDP through the life
of the interaction.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221           +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Feb 1993 17:23:18 GMT
From:      dij@afp.com (Didier Jouan)
To:        comp.protocols.tcp-ip
Subject:   Problems to determine network interfaces

Hi,

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

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

Here it is :

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

iSocket = socket( AF_INET, SOCK_DGRAM, NULL );

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

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

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

Any suggestions will be appreciated.

Thanks in advance!

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

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1993 18:43:15 GMT
From:      randerso@oac.hsc.uth.tmc.edu (Robert Anderson)
To:        comp.protocols.tcp-ip
Subject:   Using TCP/IP printer node as a BSD printer

I have several laser printers running off of DOS-based print servers through FTPSOFT 2.05's lpd program.  This allows me to print to these nodes from any other DOS-based machine running the corresponding lpr.exe.

Does anyone know how I can print to these nodes within a Unix command shell's
lpr?  I am running SunOS 4.1.1 on a SPARC2.

Please email to randerso@acad1.sahs.uth.tmc.edu.   THANK YOU.


-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Feb 1993 19:34:05 GMT
From:      rmorley@mis.mi04.zds.com (Ron Morley)
To:        comp.protocols.tcp-ip
Subject:   IP address locator

Does anyone know of a tool that will allow me to find out what IP addresses
exist on our network?  I am responsible for IP address administration, but 
the information that my predecessors have left me is very fragmented and 
almost unusable.  Also, I know that some of our users have "black" IP    
addresses that they have assigned themselves.  I would like to be able to
find them so that I can give them legitimate addresses.  I have tried
running a set of scripts on our HP 9000/837 that pings progressive IP
addresses and writes out the addresses that it finds.  However, it seems
to put an unacceptable load on our network when I run it.  Any ideas would
be very welcome.

Thanks in advance,

Ron Morley

Zenith Data Systems
Hilltop Rd.
St. Joseph, MI.

disclaimer: any opinions are my own...no one else wants them

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Feb 1993 19:38:30 GMT
From:      cam@mbunix.mitre.org (McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   Implementations of ST-II Protocol (rfc1190)

I'm interested in finding what implementations exist of the Experimental
Internet Streams Protocol, Version 2, as described in RFC 1190.

Please respond with a follow-up posting or e-mail - I'll compile replies
if there is interest.

Colleen McLaughlin
C2 Communications
The MITRE Corporation


-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1993 19:47:58 GMT
From:      scoggin@delmarva.com (John K Scoggin Jr)
To:        comp.protocols.tcp-ip
Subject:   BOOTP with PC/TCP V2.11

We are investigating the use of BOOTP to configure a fairly large number
of PCs running PC/TCP.  Does anyone on the net have any recommendations or
"gotchas" concerning this approach?

Thanks.

	- John
---
+---------------------------------------------------------------------+    
|  John K. Scoggin, Jr.			Email: scoggin@delmarva.com   |
|  Supervisor, Network Operations       Phone: (302) 451-5200         |
|  Delmarva Power & Light Company       Fax:   (302) 451-5321         |
|  500 N. Wakefield Drive               NOC:   (800) 388-7076         |
|  Newark, DE 19714-6066		                              |
|  The opinions expressed are not those of Delmarva Power, simply the |
|  product of an over-active imagination...                           |
+---------------------------------------------------------------------+


-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Feb 1993 21:24:38 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.protocols.tcp-ip
Subject:   Re: Using TCP/IP printer node as a BSD printer

Robert Anderson (randerso@oac.hsc.uth.tmc.edu) wrote:
> I have several laser printers running off of DOS-based print servers through
> FTPSOFT 2.05's lpd program.  This allows me to print to these nodes from any
> other DOS-based machine running the corresponding lpr.exe.
> 
> Does anyone know how I can print to these nodes within a Unix command shell's
> lpr?  I am running SunOS 4.1.1 on a SPARC2.
> 
> Please email to randerso@acad1.sahs.uth.tmc.edu.   THANK YOU.

You do not say which laser printers you are using.  If they are HP
LaserJet printers, you can purchase a card that will allow the printer
to work on a unix network.  For XIO machines (variants of LJ II & LJ III
except for the IIISi), you can get the C2071S card for 10baseT (Twisted-
Pair) networks.  For XIO machines on a 10base2 (ThinLan), you can get
the C2071T card.  For MIO machines (LJ IIISi and all variants of LJ 4),
you can get the J2340A card.  All three cards cost $895.

In addition to the card, you'll need to get a tape containing the host
software.  For SunOS 4.1.1, you'll want option AAV with one of the
cards.  You only need to buy the tape once, no matter how many cards you
buy.  The tape costs $100.

You may want to subscribe to the comp.periphs.printers newsgroup, where
different tcp/ip laser printers are discussed.

- Steve Kao

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 93 22:01:00 GMT
From:      dotytr@nscultrix2.network.com (Ted Doty)
To:        comp.protocols.tcp-ip
Subject:   Re: High-speed TP

In article <1993Feb23.111916.3486@slcs.slb.com> saetenar@geos01.sinet.slb.com (Arne Saeten) writes:
>
>What kind of reliable end-to-end protocol should I use ?????
>
>I need really high data-rate, say > 1 Mbps from each of the 77 send-nodes, 
>which means each of the receive-nodes must be able to handle ~26 Mbps.
>The application is very specific, so I am wondering if I can use TCP/IP.
>(It would be easiest)
>
We routinely achieve 60+ Mbps transfers Cray-Cray over FDDI.  I expect
that even lesser hosts will perform adequately.

- Ted

P.S. We just finished benchmarking TCP (socket-socket) transfers over
HIPPI, and we saw 650+ Mbps for single streams.  TCP is plenty fast.

--------------------------------------------------------------------------
Ted Doty, Network Systems Corporation | phone:      +1 301 596-2270
8965 Guilford Road, Suite 250         | fax:        +1 301 381-3320
Columbia, MD, 21046 USA               | voice mail: (800) 233-1485
--------------------------------------------------------------------------
These opinions are my own, not necessarially those of Network Systems.

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Feb 1993 23:20:10 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP NetUnreachable and TCP behaviour?

In article <C2wtyn.DIn@watserv1.uwaterloo.ca> erick@demorgan.uwaterloo.ca (Erick Engelke) writes:
>Before making the blanket statement, you may want to think about how
>there can be other resources tied to a connection, such as file
>resouces, locks, physical devices, etc.
>
>Suppose you have a FTP daemon with a half downloaded file and a 
>dead connection which would have timed out under other circumstances.
>It may become necessary to kill the FTPD just to unlock the file.  And
>that implies a privileged user on many systems as well as some
>form of human intervention.  And if the system doesn't kill connections
>and processes, other seemingly unrelated problems occur.

Let me turn this argument around and use it against you: suppose that
connection *isn't* dead (keep-alives are flying, both windows are wide
open, both transmission queues are completely empty), but the FTP
client application isn't providing any data for transmission.  Isn't
that open file still a problem?  Aren't those resources still as
precious?  After a while don't you still want to give up and stop
wasting resources on that FTP client?  TCP's not going to be able to
help you with that case, so why are you so worried about it handling
the special case where the TCP connection is dead?

Only the application understands what kind of resources it's using,
how precious those resources are, and how important the task it's
trying to accomplish is.  The application should take all factors into
account, and set up its own application layer timeout.  TCP knows none
of this and doesn't care about it, either.  Overloading one of the TCP
timers to play the role of an application timeout is a suboptimal solution.

						don provan
						donp@novell.com

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Feb 1993 00:39:35 GMT
From:      hallam@zeus02.desy.de (Phill Hallam-Baker)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on Alpha available yet?

In article <1ludm5INN7gd@blackhole.delmarva.com>, scoggin@delmarva.com (John K
Scoggin Jr) writes:

|>You mean someone actually developed an OS WITHOUT TCP/IP support?  Must be
|>an ex-DEC employee :-)  What idiots.

Some of us can remember when TCP/IP was on the restricted export list.

What I think is ludicrous is that the DEC support for DECnet and TCP/IP is
completely different. There is no good reason why I shouln't be able to do 

copy vxdesy.desy.de::[hallam]*.* *

over TCP/IP? FTP is a completely derranged abortion of an interface. Why is it
that the average vendor gets away with something that bad?


Multinet on the Alpha is avaliable and it looks pretty OK. The DEC UCX product
is about to go into external field test. The Multinet product so far has been
better, whether DEC will screw them later when they change their driver software
is another question.


-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Feb 1993 00:54:43 GMT
From:      jwilliam@Endor.sim.es.com (Jerry Williams x2562)
To:        comp.protocols.tcp-ip
Subject:   ARP - Hardware addresses

I have a couple of books Unix network programming by W.Richard Stevens,
Internetworking with TCP/IP by Douglas Comer, and TCP/IP Network Administation
by Craig Hunt.  What I would like to do is create a list of node names, IP
addresses and Hardware addresses of all the systems on the subnet.  The problem
is that some of the systems are PC's and they don't respond to ping, but I
do end up with there hardware address in my ARP table.  So even though ping
times out I do get the address.  I would like to be able to write a C program
to do this more efficiently, but I need some help and all the books just skip
over it or hint at it.  I have a Sun SPARC 2 running 4.1.2.  What I would like
is a piece of code or a Title of a book that goes into detail about how to
do it.  I know I could do a ping host 1;arp host but I don't really want it
to be pinged or to be in the arp table on the machine.  Also I would like to
know more about the arp table.  How do the systems in the list get there,
like I know ping will put them there.  But there are some systems in the list
that I can see no good reason for them to be in the list.  And then some
systems come and go.  So I guess that there is some value that is set that
tells the system how long to keep them in the table.  How big can the table
get ?  Thanks for any help!

	Jerry





-- 

Jerry Williams @ Evans & Sutherland  560 Arapeen Drive, SLC, Utah 84108
jwilliam@endor.sim.es.com     or   jwilliam%endor@sim.es.com
..sim.es.com!endor!jwilliam  or   {decwrl, utah-cs}!esunix!jwilliam

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Feb 1993 03:08:14 GMT
From:      matt@wardsgi.med.yale.edu (Matt Healy)
To:        comp.protocols.tcp-ip
Subject:   Re: TTCP Usage

In article <1lp3g5INN102@meaddata.meaddata.com>, rfrink@meaddata.com (Rick
Frink) wrote:
> 
>    Does anybody have a lead on a manual page or usage guidelines
>  for the ttcp utility ?  Thanks.
> 
> -- 
> Rick Frink                                              (513) 865-1645
> Mead Data Central                             Telecomm/Campus Networks
> P.O. Box 933                                       rfrink@meaddata.com
> Dayton, Ohio  45401                          ...!uunet!meaddata!rfrink

I've emailed the man page from my system to this guy; anyone
else who needs it please email _him_ with your request...

Matt Healy
"I pretend to be a network administrator;
 the lab net pretends to work"

matt@wardsgi.med.yale.edu

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 93 05:35:39 GMT
From:      amolitor@nmsu.edu (Andrew Molitor)
To:        comp.protocols.tcp-ip
Subject:   Re: ka9q for unix?

In article <1mc3qh$jo2@leps5.phys.psu.edu> kenh@leps5.phys.psu.edu (Ken Hornstein) writes:
>Uh-huh.  Let's see .... What does KA9Q have?
>
>	Multitasking kernel		Comes with Unix.
>	TCP/IP				Comes with Unix (on apollo and suns)
>	Serial line drivers		Available for free
>
>Note that I'm not trashing KA9Q at all ... I use it, and I love it.  But
>Unix comes with everything you need, except packet radio drivers.  And porting
>KA9Q to Unix would be kinda pointless, IMHO.  And I didn't think my original
>reply was that obnoxious at all.  

	Well. ka9q *has* been ported to Unix. Yeah, it was a hack,
but there are benefits - if your Unix box is already on the Internet,
you may NOT want it dual-homed to that and the amateur net, and
it gets to be a little tricky to set up your routes, I think.

	Porting ka9q gives you your packet network setup (BBS, and all
that) cleably separated from the rest of your network.

	I'd poke around the FTP archive on ucsd.edu, down in the
hamradio tree. I think a Unix port of some sort exists, there.

	Andrew

>--Ken

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Feb 1993 06:54:14 GMT
From:      sbardhan@uncc.edu (Soumendu Bardhan)
To:        comp.protocols.tcp-ip
Subject:   How to test TCP --HELP!!

Hi netters,
           I'm new to Networks and trying to write
the TCP protocol. I can't figure out how to 
*test* the software at the end.
Can I dump the packet to the IP layer?
Is there any test-bed ?
Can I use sockets and simulate the 
packet-loss,retransmission-timeout etc.

Please give your suggestions.IT WILL
BE VERY HELPFUL TO ME.
THANKS
-SOUMENDU


-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 1993 08:18:33 GMT
From:      dulimart@cps.msu.edu (Hansye S. Dulimarta)
To:        comp.os.386bsd.questions,comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   PC <-> Sparc


Greetings,
  I'd like to have a TCP/IP connection between a PC and a Sparc via a serial
line. Recently, I've been reading about PPP/SLIP and come to a conclusion
that with PPP/SLIP, the connection has to be dialed up.

Is it correct? Or, can I use PPP/SLIP via a null modem cable?

Thanks for your information,
Hans.
-- 
|_|_|_|_|  _|_|_ |_|_|_|_| Hans Dulimarta [dulimart@cps.msu.edu]
|_|_|_|  _|_| |_|_ |_|_|_| Pattern Recognition & Image Processing Laboratory
|_|_|  _|_|_ X _|_|_ |_|_| Department of Computer Science
|_|   |_|_|_|_|_|_|_|  |_| Michigan State University

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Feb 1993 10:19:49 GMT
From:      jp@tygra.Michigan.COM (John Palmer)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: Nslookup problems on AIX 3.x

In article <1993Feb23.184824.22839@schbbs.mot.com> mshah@next3.corp.mot.com writes:
"Hi ! I compiled nslookup successfully on AIX 3.x and started named. But  
"IBM's named requires for us to have the /etc/resolv.conf file empty if we  
"are running DNS. Still I put in my nameserver records in because nslookup  
"looks at /etc/resolv.conf for nameservers and when I run nslookup this is  
"what I get:
"
"$ nslookup
"*** Can't find server name for address 196.66.66.66: Timed out
                                            ^^^^^^^^
"*** Can't find server name for address 196.66.66.67: Timed out
                                            ^^^^^^
"*** Default servers are not available
"

NSLOOKUP will not recognize an address with this many 66's in it as its a
Christian program and its the beginning of lent. If you attempt to run it
too many times, the program will summon a priest to exorcise the 66's from
your system. 
 
Solution: change your addresses to 196.77.77.* and sacrifice a couple of
chickens on your operators console. (Last suggestion from Jon Brewster).

(Sorry folx, I just couldn't resist this one).
-- 
"Come on Jiro, its    | E-MAIL: jp@michigan.com  CAT-TALK IS BACK as a FREE
 time for your        | SYSTEM!! 313-882-2209 300-14400 V.32/V.32BIS/TurboPEP
  medication"         | Anon-UUCP: System: tygra, Login: nuucp, no pw
  -- Dr. Xanthian     | Get file "/cat/pub/filelist" for a list of files.

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 93 11:02:49 GMT
From:      S.M.Clark@lut.ac.uk (Sean Clark)
To:        comp.protocols.tcp-ip
Subject:   SLIP over PAD connection?

Calling all SLIP experts,

I manage two SPARCstations located at different UK universities. Currently
the only way to make a network connection between them is via a PAD. Would
it be possible to run SLIP over such a PAD connection so that I can use FTP
to exchange files between the two machines? I have installed installed SLIP
on both SPARCs.

I'm wondering if rather than specifying the serial port (/dev/ttya) when I
use the "sliplogin" command with a modem could I could "call" the remote
machine via the PAD and then specify the terminal (e.g. /dev/ttyp0)
instead. Is this a dopey idea? Has anyone done anything similar?

Thanks,

Sean Clark,
Loughborough Univiersity, UK

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 93 11:23:42 GMT
From:      scott@ais.com
To:        comp.protocols.tcp-ip
Subject:   Multiple Socket Connections? HELP!

Could someone point me in the direction of a better method to do this:

I am writing a daemon (with BSD sockets) that accepts multiple
connections and manages requests from the connections while at
the same time accepting new connections.

My current method is to initially do an accept().  Once I have
the first connection I set both the socket and the connection
socket to NON-BLOCKING.  This allows me to do an accept() and
if no one is trying to connect then accept() returns with 
EWOULDBLOCK.  Then I do a select() on the connections and if
I have any requests I manage them at this time.  Then I repeat
from the 2nd accept().

The problem is, I really don't believe that this is the best way
to do it and the user and system times for the daemon process
grows unbounded.

Thanks in advance.

--Scott Gregory
scott@ais.com

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 93 14:26:25 GMT
From:      markl@spuddy.uucp (Mark Liversedge)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over ATM?

In article <18531@umd5.umd.edu> matthews@oberon.umd.edu (Mike Matthews) writes:
>Are there any articles out there about running TCP/IP over ATM?  Or any
>studies, research datum, anything?  If so, *please* divulge said information
>to me via Email and I'd be eternally grateful.
>
>Well, maybe not *eternally* but at least for a while. :-)
>
>Thanks.
>------
>Mike Matthews, matthews@oberon.umd.edu (NeXTmail accepted)
>------
>It is much easier to suggest solutions when you know nothing about the
>problem.

Can you CC: it to me too!!! (markl@spuddy)
-- 
 * Meeeow ! Call Spuddy on (0203) 638780/638693 for FREE mail & Usenet access *

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Feb 1993 14:38:00 +0000
From:      leo@elmail.co.uk ("E.J.Leoni-Smith")
To:        comp.protocols.tcp-ip
Subject:   Re: anyone using UDP?


mjr@tis.com (Marcus J Ranum) writes..

>
>6500msd@ucsbuxa.ucsb.edu (Michael D'Errico) writes:
>>
>>Has anyone here used UDP instead of TCP to do their communication?
>>Sure TCP is great since it does a lot of work for you, but it also
>>requires a lot of network overhead that is often unnecessary.
>
>        Have you actually profiled your application and determined
>that the massive overhead of TCP is a performance bottleneck for you?
>         ^  ;)
>
>        I've used UDP, but only when I'm writing an application that
>doesn't care if the data I'm sending gets there, or has simple, stupid,
>idempotent operations. If you actually need reliable sequenced delivery,
>you'll wind up wasting a huge amount of time re-implementing something
>in your code that's probably slower than TCP anyhow, in addition to
>being more complex and a waste of time. You actual mileage may vary,
>of course.
>
>mjr.
>
>
I have to disagree: UDP is also an ideal method of delivering 
asynchronous messages to multiple clients. Like several
hundred of them. Especially when you realise that each 
client requires a socket and a couple of 
processes on your 'server'. I have seen UDP used 
very succesfully to broadcast financial information 
around a lan. Each machine that had to recieve it kept 
a tally of message numbers: If one message went 'missing' a 
request for retransmit was sent to the server. Clients 
that already had the message ignored the retransmit.

This elegant solution at a stroke removed the need for 
some 2-3000 processes running on the (fairly small) server.

TCP is a reliable _stream_ connection, UDP can be easily made to 
provide a (reliable enough) _broadcast_ 'connection'.

After all - look at NFS: it has good and bad results from being run 
over UDP



-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 93 15:12:17 GMT
From:      sp_ppm@nodomain (Paul Moore)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin,comp.unix.solaris
Subject:   How to associate multiple IP addresses with the same Sun workstation

Hello,

We have an application which involves interconnecting two Sun workstations via serial
lines. Since the data bandwidth between the two Suns exceeds that of a single
interconnecting line, the two workstations are interconnected by two serial lines
in parallel, with the routing being done by means of Cisco routers. The configuration is shown below:

         +---------+                                               +---------+
         |         |     +--------+    Line 1       +--------+     |         |
         |  Sun    |     | Cisco  |-----------------| Cisco  |     |  Sun    |
         |         |-----| router |-----------------| router |-----|         |
         | source  |     +--------+    Line 2       +--------+     |  destn  |
         |         |                                               |         |
         +---------+                                               +---------+

The problem is that the Cisco router determines which line to use from the IP address.
This means that all the data addressed to the destination Sun is always being routed
to the destination Sun on the one line. Is there any way to be able to communicate
between the two Suns using different destination IP address, so that the traffic is
split between the two lines. 

Thank you in advance,

Paul.

---
Paul Moore,                      email: sp_ppm@space.alcbel.be
ALcatel Bell Telephone,
Berkenrodelei 33,                phone: (+32) 3/829.5024
2660 Hoboken,
Belgium.

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Feb 1993 15:17:32 GMT
From:      bjork@telebit.com (Steven Bjork)
To:        comp.protocols.tcp-ip
Subject:   Network mapping with traffic density


The railroads have a neat way of showing traffic density
on a schematic of their lines. Between major junctions,
show traffic density by a wide line for a heavily used
path, and a narrower line for a lesser used path.

It's really easy to pick out the traffic flow on the
Burlington Northern's Powder River Basin coal lines
when you look at a map produced like this.

I wonder what the NSFnet/CIX folks maps would look like
if they had a similar version.

Hm, could you *see* that mud running on a cray wrt traffic :)?

../Steven

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Feb 1993 16:50:34 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Network mapping with traffic density

In article <C2yL59.GEF@telebit.com>, bjork@telebit.com (Steven Bjork) writes:
> 
> The railroads have a neat way of showing traffic density
> on a schematic of their lines. Between major junctions,
> show traffic density by a wide line for a heavily used
> path, and a narrower line for a lesser used path.
> 
> It's really easy to pick out the traffic flow on the
> Burlington Northern's Powder River Basin coal lines
> when you look at a map produced like this.
> 
> I wonder what the NSFnet/CIX folks maps would look like
> if they had a similar version.
> 
> Hm, could you *see* that mud running on a cray wrt traffic :)?
> 
> ../Steven


For a few years, Silicon Graphics has been showing and selling
such a product, but using colors to indicate loads (either packets
or bytes).  I think there are now others doing similar things.


Vernon Schryver,  vjs@sgi.com

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Feb 1993 16:51:21 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.os.386bsd.questions,comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: PC <-> Sparc

In article <1mfb0p$fgc@msuinfo.cl.msu.edu> dulimart@cps.msu.edu (Hansye S. Dulimarta) writes:
   can I use PPP/SLIP via a null modem cable?

Sure, we do it all the time.  What's not working?
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221           +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Feb 1993 17:02:41 GMT
From:      tda10@cus.cam.ac.uk (Tim)
To:        biz.sco.general,comp.sys.sun.admin,alt.sys.sun,comp.protocols.nfs,comp.protocols.tcpip,comp.unix.aix,comp.unix.admin
Subject:   Re: on and rlogin security on the internet

In article <C2vKK7.8Mu@babbage.ece.uc.edu>, will@physuna.phs.uc.edu (David Will) writes:
|>  I'm interested in the security issues regarding rlogin and the nfs on command
|> when a network is added to the internet.  
|> 
|> Specifically it appears that if a machine on the internet has the same hostname 
|> and one ip number pair that is the same as a trusted machine's on a 
|> local network and a user with the same uid then that user can gain 
|> access to that machine running the  rexd via the on command.  Is this accurate? 

Of you are referring to the SunOS `on' command then it uses the rexd daemon. 
This is, by default, not turned on in recent versions of SunOS at least.  There
are comments in /etc/inet.conf about this.

`rsh' is the more secure alternative, whose corresponding daemon is turned on by
default.

Tim.

---
University of Cambridge Computing Service - Unix-Support
Internet: tda10@ucs.cam.ac.uk  - what more do you need?
Tim Auckland
Not to be taken seriously...

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Feb 1993 17:40:01 GMT
From:      erick@demorgan.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP NetUnreachable and TCP behaviour?

my knowledgable friend donp@novell.com (don provan) writes:
> erick@demorgan.uwaterloo.ca (Erick Engelke) writes:
>>Before making the blanket statement, you may want to think about how
>>there can be other resources tied to a connection, such as file
>>resouces, locks, physical devices, etc.
>>
>>Suppose you have a FTP daemon with a half downloaded file and a 
>>dead connection which would have timed out under other circumstances.
>>It may become necessary to kill the FTPD just to unlock the file.  And
>>that implies a privileged user on many systems as well as some
>>form of human intervention.  And if the system doesn't kill connections
>>and processes, other seemingly unrelated problems occur.
>
>Let me turn this argument around and use it against you: suppose that
>connection *isn't* dead (keep-alives are flying, both windows are wide
>open, both transmission queues are completely empty), but the FTP
>client application isn't providing any data for transmission.  Isn't
>that open file still a problem?  Aren't those resources still as
>precious?  After a while don't you still want to give up and stop
>wasting resources on that FTP client?  TCP's not going to be able to
>help you with that case, so why are you so worried about it handling
>the special case where the TCP connection is dead?

The TCP connection being dead is a special case to you, but to people
on packet radio, cellular phones, or up in the boonies as I often
am, broken connections are a fact of daily life.  

I'm not certain why you asked about FTP, most FTP servers follow
this strategy already by closing the control channel after a 
perscribed period of inactivity!  Under FTP the major file 
resources are used by the data channel which is only open
during data transfers, so it is entirely reasonable to set
a perscribed data rate of, say, at least one byte of data
every ten minutes. 

This strategy leaves the FTP server resiliant enough for
low bandwidth real-time data as well as regular FTP over 
lossy lines, saturated lines/gateways, etc.

Maybe I'm missing your point.

>Only the application understands what kind of resources it's using,
>how precious those resources are, and how important the task it's
>trying to accomplish is.  The application should take all factors into
>account, and set up its own application layer timeout.  TCP knows none
>of this and doesn't care about it, either.  Overloading one of the TCP
>timers to play the role of an application timeout is a suboptimal solution.

Exactly, that's why I suggested the extension errno=ECOMATOSE when
reads/writes timeout but the connection is otherwise untouched and
fully survivable.

Any application which is interested in surviving will just retry
the operation, others can treat it as a failure and close up the
session.  I merely suggest it as a way of allowing applications to
choose how resiliant they wish to be without breaking the BSD/XTI 
model too severely.

That's what I'm doing here for SMTP and have added an application
multiplier index based on how treasured a connection is.  After the 
first COMATOSE notice, the mail system will usually drop a connection.  
But if there has been a significant amount of data sent over that 
connection and so it is more desireable to not repeat the process, 
it will wait for a few COMATOSE notices. 

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

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Feb 1993 18:10:52 GMT
From:      geurin@texasex.nosc.mil
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   PD Sniffer?


Hi,

Does anyone know of a PD/SW PC or Unix based Network Sniffer?

Any leads appreciated,
Chance Geurin
geurin@nosc.mil

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Feb 1993 20:55:40 GMT
From:      andy@vistachrome.com (Andrew Finkenstadt)
To:        comp.protocols.tcp-ip
Subject:   Is a double-response to a PING okay?


Is this a problem with a double-response to a PING request?
-Andy

PING qms3200laser.vistachrome.com: 56 data bytes
64 bytes from 157.131.3.2: icmp_seq=0. time=29. ms        <--
64 bytes from 157.131.3.2: icmp_seq=0. time=29. ms        <--
64 bytes from 157.131.3.2: icmp_seq=1. time=69. ms
64 bytes from 157.131.3.2: icmp_seq=2. time=89. ms
64 bytes from 157.131.3.2: icmp_seq=3. time=39. ms
64 bytes from 157.131.3.2: icmp_seq=4. time=119. ms
64 bytes from 157.131.3.2: icmp_seq=5. time=29. ms
64 bytes from 157.131.3.2: icmp_seq=6. time=19. ms
64 bytes from 157.131.3.2: icmp_seq=7. time=19. ms
64 bytes from 157.131.3.2: icmp_seq=8. time=19. ms
64 bytes from 157.131.3.2: icmp_seq=9. time=19. ms
64 bytes from 157.131.3.2: icmp_seq=10. time=29. ms
64 bytes from 157.131.3.2: icmp_seq=11. time=19. ms
64 bytes from 157.131.3.2: icmp_seq=12. time=19. ms
64 bytes from 157.131.3.2: icmp_seq=13. time=19. ms
64 bytes from 157.131.3.2: icmp_seq=13. time=19. ms
64 bytes from 157.131.3.2: icmp_seq=14. time=19. ms
64 bytes from 157.131.3.2: icmp_seq=15. time=19. ms
64 bytes from 157.131.3.2: icmp_seq=16. time=19. ms
64 bytes from 157.131.3.2: icmp_seq=17. time=19. ms
64 bytes from 157.131.3.2: icmp_seq=18. time=19. ms
64 bytes from 157.131.3.2: icmp_seq=19. time=29. ms
64 bytes from 157.131.3.2: icmp_seq=20. time=19. ms        <--
64 bytes from 157.131.3.2: icmp_seq=20. time=19. ms        <--
64 bytes from 157.131.3.2: icmp_seq=21. time=19. ms
64 bytes from 157.131.3.2: icmp_seq=22. time=19. ms
64 bytes from 157.131.3.2: icmp_seq=23. time=19. ms
64 bytes from 157.131.3.2: icmp_seq=24. time=19. ms        <--
64 bytes from 157.131.3.2: icmp_seq=24. time=19. ms        <--
64 bytes from 157.131.3.2: icmp_seq=25. time=19. ms
64 bytes from 157.131.3.2: icmp_seq=26. time=19. ms

-- 
Andrew Finkenstadt, Vista-Chrome, Inc., Homes & Land Publishing Corporation
GEnie Unix RoundTable Manager, andy@vistachrome.com, andy@genie.geis.com.
"[The author] neither accidentally nor intentionally omits or includes 
anything that could support a preconceived thesis." - C&EN 21-DEC-92 p.72

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Feb 1993 22:03:42 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP NetUnreachable and TCP behaviour?

In article <C2yrqq.HrB@watserv1.uwaterloo.ca> erick@demorgan.uwaterloo.ca (Erick Engelke) writes:
>The TCP connection being dead is a special case to you, but to people
>on packet radio, cellular phones, or up in the boonies as I often
>am, broken connections are a fact of daily life.  

Even though it may account for 95% or even 99.99% of the cases you
have, it's still a special case.  The general case is "nothing's
happening", which covers not only the special case of conditions being
too bad to maintain the TCP connection, but also the special case of
the remote application dropping into a coma while its TCP continues
functioning normally, and the special case of the *local* TCP
malfunctioning such that it doesn't notify the application that the
connection has failed (including, now that i think of it, the TCP
implementations that are being discussed here that don't detect loss
of connectivity to begin with), and probably several other special
cases that would never occured to me until i saw them happen.

(Oddly enough, i would have thought the topologies you cite as examples
are exactly the ones that would be hurt by premature connection
termination.  Those all sound like situations where the user would
really want the application to keep trying to continue a connection even
in the face of protocol layer errors that would probably mean certain
death for a TCP connection in a more run-of-the-mill environment.  As
far as i understand, a disruption of service in those environments would
often be only temporary, so aborting the connection altogether just
because TCP's been retransmitting without success for ten minutes or
because a network or host has been unreachable for ten minutes would
seem to be exactly the wrong behavior.  Hmmm...  Maybe i've lost track
of what we're discussing.)

>I'm not certain why you asked about FTP, most FTP servers follow
>this strategy already by closing the control channel after a 
>perscribed period of inactivity!

The article i was responding to used the example of an FTP daemon that
would use up resources (a file locked for writing was the specific
example) indefinitely if the connection failed silently.  The fact
that most FTP servers have inactivity timeouts actually illustrates
that his example has a simple, effective solution that isn't based on
the behavior of the TCP implementation.  (I'm not sure, however, if
such inactivity timers typically timeout a connection with an active
transfer going, which is the case we're discussing.)

In fact, it's just such inactivity timers i was thinking of as
examples of how an application can handle the general case without any
changes to the I/O system or the TCP implementation to help it handle
the special case.  There's no reason every other application can't
have similar timers.

>Exactly, that's why I suggested the extension errno=ECOMATOSE when
>reads/writes timeout but the connection is otherwise untouched and
>fully survivable.

That's fine, as long as you appreciate that this is a characteristic
of the local I/O implementation, not of the TCP protocol stack
implementation.  Personally, since there's a straightforward way to
solve this problem already which doesn't impact the standard TCP APIs,
i'd say the general approach would be the way to go.

>That's what I'm doing here for SMTP and have added an application
>multiplier index based on how treasured a connection is.  After the 
>first COMATOSE notice, the mail system will usually drop a connection.  
>But if there has been a significant amount of data sent over that 
>connection and so it is more desireable to not repeat the process, 
>it will wait for a few COMATOSE notices. 

Sounds great to me.  Perhaps if you explain why you feel the I/O system
has to participate in identifying the comatose I/O stream, then i'll
understand where we differ.  Since the application has at least as much
information about what comatose really means for this particular
application, i don't see why the I/O system needs to be involved at all.
In your particular case, for example, your SMTP implementation doesn't
agree with the I/O system's definition of comatose, so it makes up its
own by ignoring some of the comatose indications it receives.  Wouldn't
it be easier for your SMTP to just define comatose for itself and not
try to coordinate with a definition made up by the I/O system?

In summary, i think that there's a lot of TCP information, such as
timeouts and unreachable notifications, that seem so close to what the
application wants that there's been a long history of trying to use
that information to support application timeouts.  I believe this
information really isn't suitable for the needs of an application, and
i suggest you'll be better off if you ignore them and use specific
timing mechanisms, such as a timeout on a poll procedure perhaps, to
accomplish your true goals.
						don provan
						donp@novell.com

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Feb 1993 22:42:02 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.protocols.tcp-ip
Subject:   Re: anyone using UDP?

Back to the original question,

Michael D'Errico (6500msd@ucsbuxa.ucsb.edu) wrote:
> Has anyone here used UDP instead of TCP to do their communication?

SNMP usually runs on top of UDP.  If you have a network management
package that accesses a device's MIB variables, the odds are the SNMP
packets are inside UDP packets.

- Steve Kao

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1993 09:13:51 -0600
From:      bryan@wupost.wustl.edu (bryan o'connor)
To:        comp.archives.admin,comp.protocols.tcp-ip
Subject:   wuarchive ftpd -- call for beta-testers


CALL FOR BETA-TESTERS FOR WUARCHIVE FTP SERVER
----------------------------------------------

In anticipation of the next release of the enhanced ftp server developed
at Washington University, we are issuing this call for beta-testers.

As a beta-tester, you would be expected to compile, run, and test the
server and then report bugs/comments.

Because I don't have access to numerous machines, some fiddling (due to
operating system idiosyncrasies) may be required to get the code to 
compile.  In that case, a revised Makefile as well as diffs to code would
need to be sent to me in order to support your machine architecture.

The goal of this beta-test is to squash bugs, increase the portability of
the code, and receive comments about the additional functionality.

The final release version of the server will hopefully incorporate 
new features generated by the response of the beta-testers.

If interested in participating as a beta-tester, please fill out the 
following form and send it to bryan@fegmania.wustl.edu.

===============================================================================
WUARCHIVE beta test application

1. Information about you

   Name :
   Email:

2. Information about the machine that will run the server

   Machine name     :
   Machine type     :
   Operating System :
   Running Kerberos?:

   Are you currently running an older version of the wuarchive ftp server:

   If so, what features of the older version do you use/like the most?

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

-- 
Bryan D. O'Connor                          Internet: bryan@wugate.wustl.edu
Software Engineer, wuarchive development    UUCP: ...!uunet!wuarchive!bryan
Office of the Network Coordinator                BITNET: bryan@wunet.bitnet
Washington University in Saint Louis                 Phone: +1 314 935 7048

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1993 01:17:54 GMT
From:      rfrink@meaddata.com (Rick Frink)
To:        comp.protocols.tcp-ip
Subject:   Re: ttcp info

In article <1mc4c1INN9cb@meaddata.meaddata.com>, rfrink@meaddata.com (Rick Frink) writes:
|>   Does anybody know where I can get some info on ttcp, like a MAN
|>  page ?
|> 

  Would the kind person from SGI please resend the MAN page.  Thanks again.


|> 
|> -- 
|> Rick Frink                                              (513) 865-1645
|> Mead Data Central                             Telecomm/Campus Networks
|> P.O. Box 933                                       rfrink@meaddata.com
|> Dayton, Ohio  45401                          ...!uunet!meaddata!rfrink
 
-- 
Rick Frink                                              (513) 865-1645
Mead Data Central                             Telecomm/Campus Networks
P.O. Box 933                                       rfrink@meaddata.com
Dayton, Ohio  45401                          ...!uunet!meaddata!rfrink

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Feb 93 02:51:13 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   IP address locator

In article <1993Feb23.193405.12528@mis.mi04.zds.com> rmorley@mis.mi04.zds.com writes:

   Does anyone know of a tool that will allow me to find out what IP addresses
   exist on our network?

Jan Engvald's pdclkset.  It listens to ARP broadcasts and makes a
record of them in a file.  You have to run it for a few days to catch
everybody, but it should do the trick.  You need to have a Crynwr
packet driver, so fetch that first, then look in SOFTWARE.DOC for a
pointer to it.  The NE2000 driver runs over the adapter in a Z-Station...


-- HOWTOGET.IT

		The Crynwr packet driver collection

Availability

The Crynwr packet driver collection is available by mail, by FTP, by
email, by UUCP and by modem.  The drivers are distributed in three files:
drivers.zip, which contains executables and documentation,
drivers1.zip, which contains the first half of the .ASM files, and
drivers2.zip, which contains the second half of the .ASM files.

Mail:

Columbia University distributes packet drivers on PC diskette by
postal mail.  5.25-inch 360K and 3.5" 720K diskettes are available;
please specify size.  Two diskette sets are available, and two prices
are quoted for each; the first price is for the USA, Canada, and
Mexico; the second price is for shipment to all other countries.  All
prices are in US dollars.  Prepayment by check, MasterCard, or Visa
is accepted.  If your check is not drawn on a US bank, please add $35
check-cashing fee.

  1. Binaries and documentation:        $35  /  $40
  2. Source code:                       $60  /  $68

To order by credit card, please specify MasterCard or Visa, your card
number and expiration date, and sign and date your order.  For further
information, call +1 212 854-3703, or write to:

  Kermit Distribution, Dept PD
  Columbia University Academic Information Systems
  612 West 115th Street
  New York, NY  10025

or send e-mail to kermit@columbia.edu (Internet) or KERMIT@CUVMA
(BITNET/CREN/EARN).

FTP/email:

The packet driver collection has its own directory devoted to it on
simtel20.army.mil, pd1:<msdos.pktdrvr>.  The drivers are there, along
with many free programs that use the packet drivers.

SIMTEL20 files are also available by anonymous ftp from mirror sites
OAK.Oakland.Edu (141.210.10.117), wuarchive.wustl.edu (128.252.135.4),
ftp.uu.net (137.39.1.9), nic.funet.fi (128.214.6.100), src.doc.ic.ac.uk
(146.169.3.7), nic.switch.ch (130.59.1.40), archie.au (139.130.4.6),
nctuccca.edu.tw (140.111.3.21), by e-mail through the BITNET/EARN file
servers.

Modem:

If you cannot access them via FTP or e-mail, most SIMTEL20 MSDOS
files, including the PC-Blue collection, are also available for
downloading from Detroit Download Central (313) 885-3956.  DDC
has multiple lines which support 300/1200/2400/9600/14400 bps
(103/212/V22bis/HST/V32bis/V42bis/MNP).  This is a subscription system
with an average hourly cost of 17 cents.  It is also accessable on
Telenet via PC Pursuit and on Tymnet via StarLink outdial.  New files
uploaded to SIMTEL20 are usually available on DDC within 24 hours.

CD-ROM:

Public, private or corporate institutions and libraries interested in
the SIMTEL20 MS-DOS collection in CD-ROM format bundled with library
card-catalog type access and duplication software can contact Coyote
Data, Ltd. by mail at 1142 N. Main, Rochester, MI 48307 or by FAX at
(313) 651-4071.  Others who do not need the access and duplication
software should send e-mail to: rab@cdrom.com (Robert Bruce), telephone
(800) 786-9907 or (510) 947-5996, or FAX (510) 947-1644 for details on
his CD-ROM offer.


UUCP:

The packet driver files are available from UUNET's 1-900-GOT-SRCS, in
uunet!~/systems/msdos/simtel20/pktdrvr.  Contact UUNET for more details:

UUNET Technologies, Inc.
3110 Fairview Park Drive, Suite 570
Falls Church, VA 22042
+1 703 204 8000 (voice)
+1 703 204 8001 (fax)
info@uunet.uu.net

UK UUCP:

Steve Kennedy's BBS is on +44 71 483 2454 (Telebit T2500 PEP/V32 ...)
                                                2455 (USR HST/DS+)

Files will be in /pub
there will be an anonymous uucp (nuucp) account.

System name is "marvin"

-- end of HOWTOGET.IT

-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Feb 1993 03:18:03 GMT
From:      dgalekov@encore.com (Dale Galekovic)
To:        comp.protocols.tcp-ip
Subject:   Network Analyzer Software question  ......

I  would  like  to  know if anyone out there in netland knows where I might
find (publicly or commercially) Network Diagnostic Software that  will  run
on  a  PC  running  unix and preferably X11 based.  I know this Software is
packaged to run on DOS but haven't seen any packages for Unix  based  PC's.
Any help or leads would be appreciated.


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

Dale Galekovic (dgalekovic@encore.com)
Mailstop 406
System Integration
Encore Computer Corp.
Ft. Lauderdale, FL  33313-4499

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


-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 93 05:35:40 GMT
From:      catone@dmark.wharton.upenn.edu (Tony Catone)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP using BOOTP to resolve IP address

In article <C2F3F3.9tC@waterloo.hp.com> rypma@waterloo.hp.com (Ted Rypma) writes:


   Bootpd wants to map incoming LLA's to a table entry with other parameters
   and the incoming bootp client request from the SLIP connected machine has
   no LLA - game over.

   I don't know of any, but perhaps there are specially modified versions of
   bootpd out there that will broadcast a reply to the interface that sent the
   request using some other lookup value?

There was mention some little while back that CISCO terminal servers
respond to bootp requests over dialin SLIP lines.  We have Xylogics
terminal servers, so I never got to try it.


- Tony
  catone@dmark.wharton.upenn.edu



-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Feb 1993 07:59:43 GMT
From:      hoens@gmd.de (Guenter Hoens)
To:        comp.protocols.tcp-ip
Subject:   Re: Is a double-response to a PING okay?

In <C2z0ss.GsJ@vistachrome.com> andy@vistachrome.com (Andrew Finkenstadt) writes:


>Is this a problem with a double-response to a PING request?
>-Andy
 
>PING qms3200laser.vistachrome.com: 56 data bytes
>64 bytes from 157.131.3.2: icmp_seq=0. time=29. ms        <--
>64 bytes from 157.131.3.2: icmp_seq=0. time=29. ms        <--
>64 bytes from 157.131.3.2: icmp_seq=1. time=69. ms
>64 bytes from 157.131.3.2: icmp_seq=2. time=89. ms

you should find out, whether both answers come from the same hardware-
address (only for sure, i think it does, because the ping goes to a special
address).
perhaps you can find out (by watching the frames on the cable), whether
there are REALLY two different frames on the cable, and if so, whether
both of them are error-free.
i think, there should be only one answer. if there are more, there should
be a reason for it.
further questions:
- does it only happen under heavy load?
- does it only happen between these two machines?

good luck

--
-----------------------------------------------------------------
* Guenter Hoens, GMD - I8, 
* German National Research Center for Computer Science
* hoens@gmd.de    (02241) 14-2408

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Feb 1993 14:07:11
From:      fks@vaxeline.ftp.com  (Frances K. Selkirk)
To:        comp.protocols.tcp-ip
Subject:   Re: Using TCP/IP printer node as a BSD printer

In article <8790@lib.tmc.edu> randerso@oac.hsc.uth.tmc.edu (Robert Anderson) writes:

> I have several laser printers running off of DOS-based print servers through
> FTPSOFT 2.05's lpd program.  This allows me to print to these nodes from any
> other DOS-based machine running the corresponding lpr.exe.
> 
> Does anyone know how I can print to these nodes within a Unix command shell's
> lpr?  I am running SunOS 4.1.1 on a SPARC2.

In your /etc/printcap file, set up a printer name to associate with a
networked PC/LPD printer. In the printcap entry specify:
	
	:rm=host:\

where "host" is a fully qualified hostname. You will also need to specify
other standard printcap information, such as the spool directory (sd).

When this is ready, the command line:
 
	lpr -P printername filename 

will send your file to the remote LPD.

For more information, do "man lpr" and "man printcap" from the Sun-OS 
command line.


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


-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Feb 1993 09:14:21 GMT
From:      evansmp@uhura.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Is a double-response to a PING okay?

Andrew Finkenstadt (andy@vistachrome.com) wrote:
: 
: Is this a problem with a double-response to a PING request?
: -Andy
: 
: PING qms3200laser.vistachrome.com: 56 data bytes
: 64 bytes from 157.131.3.2: icmp_seq=0. time=29. ms        <--
: 64 bytes from 157.131.3.2: icmp_seq=0. time=29. ms        <--

Possibly the routing was being changed as the packet was sent.

It is POSSIBLE to get multiple packets generated on an ip WAN.
You should also allow for this happening when using UDP.
(TCP will take care of it)

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

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Feb 1993 10:56:33 GMT
From:      shiao@ans.net (Dennis Shiao)
To:        comp.protocols.tcp-ip
Subject:   Re: Network mapping with traffic density


In article <C2yL59.GEF@telebit.com> bjork@telebit.com (Steven Bjork) writes:

>The railroads have a neat way of showing traffic density
>on a schematic of their lines. Between major junctions,
>show traffic density by a wide line for a heavily used
>path, and a narrower line for a lesser used path.
>
>It's really easy to pick out the traffic flow on the
>Burlington Northern's Powder River Basin coal lines
>when you look at a map produced like this.
>
>I wonder what the NSFnet/CIX folks maps would look like
>if they had a similar version.

Advanced Network & Services (ANS) uses a network management tool called
XGMON, developed at IBM T.J. Watson Research Center, that does just this.
At the last 2 Interop's, we've displayed a "Live Map" of the T3 ANSnet
backbone, which displays both operational status and link thicknesses in
real time. We'll be showing the map again at the Washington D.C. Interop.

-Dennis.
--
Advanced Network & Services, Inc.    E-Mail: shiao@ans.net
100 Clearbrook Road                  Office: (914) 789-5340
Elmsford, NY 10523		     Fax:    (914) 789-5310

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1993 22:47:21 -0500
From:      themos@umbc.edu (Mr. Themos Pentakalos)
To:        comp.protocols.tcp-ip
Subject:   INTELLIS IDNET PRINT SERVERS

Hello.

Has anyone implemented successfully the compact print servers
from Intellis called IDNET? Also XCD makes the same exact boxes
and calls them X-CONNECT. They are print servers which allow laser
printers to go on the ethernet. They speak LAT and TCP/IP as well.

I ask this because we just ordered some last week but just yesterday
we heard that they have major problems with overheating. Is this
true? Can someone confirm?

Thank you in advance and please respond to:   themos@umbc5.umbc.edu

Themos

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Feb 1993 14:27:36 GMT
From:      rwa@aurora.cc.umr.edu (Richard W. Altheide)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP using BOOTP to resolve IP address

Tony Catone (catone@dmark.wharton.upenn.edu) wrote:
: In article <C2F3F3.9tC@waterloo.hp.com> rypma@waterloo.hp.com (Ted Rypma) writes:


:    I don't know of any, but perhaps there are specially modified versions of
:    bootpd out there that will broadcast a reply to the interface that sent the
:    request using some other lookup value?

I'm not aware of any such beast.  Perhaps someone else can help here.

: There was mention some little while back that CISCO terminal servers
: respond to bootp requests over dialin SLIP lines.  We have Xylogics
: terminal servers, so I never got to try it.

Cisco Systems indeed implements async bootp in their terminal servers.  I
don't remember the software level where this was introduced, but, it is
in the 9.1 software for the ASM-CS and CS-500 servers.  It allows response
to most of the bootp parameters needed to keep a station happy.  We use
the servers using PCs with CUTCP and Gopher; Macintoshes using MacTCP and
MacSLIP.  It works like a champ for SLIP dialup with no user configuration
needed.  The end user software, of course, must support Bootp.

Richard W. Altheide, Sr. Systems Programmer
UMR Computing Services                           Internet:  rwa@umr.edu
114 Mathematics/Computer Science Building        Telephone: 1.314.341.4841
Rolla, MO   65401-0249                           Fax:       1.314.341.4216

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 93 16:10:39 GMT
From:      tom@tredysvr.Tredydev.Unisys.COM (Tom Albrecht)
To:        comp.unix.sysv386,comp.protocols.tcp-ip,comp.unix.i386,comp.unix.questions,comp.unix.wizards
Subject:   alarm() and connect() question


I writing an application that uses sockets in SVR4.  I would like to
timeout a connect() request after some period of time using the alarm()
function.

[code fragment begin]

	(void) signal(SIGALRM, timedout);
	(void) alarm(10);

	if (connect(sd, (struct sockaddr *)&me, sizeof(me)) != 0){
		perror("connect");
		return 0;
	}

	(void) alarm(0);

[code fragment end]

It seems that once into the connect() function, the alarm signal is ignored.
The system just times out the connect and returns ETIMEDOUT.

The default value for timeout is 177 seconds.  There doesn't seem to be any
way to adjust this on a per socket basis, hence the need to try something
else.

Is there some other way to do this?

-- 
Tom Albrecht

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 93 17:26:56 GMT
From:      sonicsys@netcom.com (Sudhakar Ravi)
To:        comp.protocols.tcp-ip
Subject:   bootp sources

I got the sources for bootp from CMU, and ran into a problem with the way
the bootreply handles filenames.  We have a ROM that lets a Macintosh
boot disklessly from a UNIX machine, and the CMU version of bootp doesn't 
seem to return a diskfile name in the bootreply.  This is ok if 
you're using the bootp server to just get an IP address, but it doesn't
work if you're also trying to get the filename to boot from.  
Has anyone encountered this problem before?  And if so, is there a fix for
this?

Sudhakar Ravi
sonicsys@netcom.com
(408)736-1900 x107
-- 
Sonic Systems
sonicsys@netcom.com
(408)736-1900

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Feb 1993 17:29:14 GMT
From:      titzer@grizzly.uoregon.edu (David A. Titzer)
To:        comp.protocols.tcp-ip
Subject:   Re: IP address locator

-In article <1993Feb23.193405.12528@mis.mi04.zds.com>, rmorley@mis.mi04.zds.com (Ron Morley) writes:
|> Does anyone know of a tool that will allow me to find out what IP addresses
|> exist on our network?  I am responsible for IP address administration, but 
|> the information that my predecessors have left me is very fragmented and 
|> almost unusable.  Also, I know that some of our users have "black" IP    
|> addresses that they have assigned themselves.  I would like to be able to
|> find them so that I can give them legitimate addresses.  I have tried
|> running a set of scripts on our HP 9000/837 that pings progressive IP
|> addresses and writes out the addresses that it finds.  However, it seems
|> to put an unacceptable load on our network when I run it.  Any ideas would
|> be very welcome.
|> 
|> Thanks in advance,
|> 
|> Ron Morley
|> 
|> Zenith Data Systems
|> Hilltop Rd.
|> St. Joseph, MI.
|> 
|> disclaimer: any opinions are my own...no one else wants them


Try using the "arp" utility, with "-a" argument. Should return
names if known, "?" if not, the IP address, and the ethernet address.
The ethernet address, with a range assigned to manufacturers, will
even give you a clue to what type of machine you have discovered.
For example, a Sun workstation should give you 8:0:20:x:x:x. This 
will help when cleaning up your domain.

Good luck!

Dave
===============================================================================

David A. Titzer
Senior Systems Analyst
Kestrel Associates, Inc.		Naval Research Laboratory
2800 Shirlington Rd. Ste. 901		4555 Overlook Ave., S.W.
Arlington, VA 22206			Washington, DC 20375-5320
(703)379-2261 - Voice			(202)767-3903 - Voice
(703)379-2264 - FAX			(202)404-7402 - FAX

E-Mail: titzer@net.nrl.navy.mil					

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Feb 1993 19:01:53 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.lang.postscript,comp.protocols.tcp-ip
Subject:   Re: HP JetDirect for Unix

Jeff Hakner (hak@alf.cooper.edu) wrote:
> Yeah, wouldn't it be nice if HP did something standard, like LPD or
> TELNET??  What's so great about their canned software, anyway?

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

- Steve Kao

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Feb 1993 19:05:29 GMT
From:      a722756@roper.mc.ti.com (W. Donald Rolph)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP with PC/TCP V2.11


INclude me also - we are considering the same thing.
-- 

Regards.
 
Don Rolph  a722756@pan.mc.ti.com WD3 MS10-13 (508)-699-1263

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Feb 1993 20:21:58 GMT
From:      rwa@aurora.cc.umr.edu (Richard W. Altheide)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP with PC/TCP V2.11

John K Scoggin Jr (scoggin@delmarva.com) wrote:
: We are investigating the use of BOOTP to configure a fairly large number
: of PCs running PC/TCP.  Does anyone on the net have any recommendations or
: "gotchas" concerning this approach?
 
: Thanks.

We are not using PC/TCP, but, we do have an installation of 960 IBM PCs and
Macintoshes that are all configured with BootP.  The only "gotcha" that I
am aware of is if the stations are between routers, you will need to have a
BootP server on each segment or a router that can forward the BootP UDP
broadcasts.  It is also helpful to have a couple of machines providing the
BootP service in case one is down.  We just copy the BootP config file using
FTP automated with a .netrc to the server locations.  You do have to be
prepared to make changes to the config file if you have to change an
ethernet card in a machine, but, this is just a matter of training a few people
to make changes.

I am using the CMU bootpd obtained from lancaster.andrew.cmu.edu.  The file
is /pub/bootp.2.2alpha.tar.Z.  I have this running on Sun/3, Sun/4, and 
HP/UX 8.0.  I haven't tried any other platforms.

We have a common version of CUTCP and of Mac/TCP that are used on all the
machines.  Configuration is from a central point and a few scripts can
insure that you don't have duplication of addresses.

--
Richard W. Altheide, Sr. Systems Programmer
UMR Computing Services                           Internet:  rwa@umr.edu
114 Mathematics/Computer Science Building        Telephone: 1.314.341.4841
Rolla, MO   65401-0249                           Fax:       1.314.341.4216

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Feb 1993 20:45:46 GMT
From:      peter@ferranti.com (peter da silva)
To:        comp.protocols.tcp-ip,comp.sys.ibm.pc.hardware,comp.os.386bsd.misc
Subject:   Gateway 8-bit ethernet cards

I just bought a couple of ethernet cards from a bankruptcy sale. They're
marked:

	Gateway Communications
	G/ETHERNET

	3 sets of jumpers and a switch bank

on the front, and

	QEC-4V0.94V0
	9106
	G-ETHER 8220031-REV.02

on the back.

Anyone have any idea what I can do with these? If the answer is "landfill"
I won't be too upset, but I'd really like to get my two PCs talking.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 1993 00:18:52 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: How to associate multiple IP addresses with the same Sun workstation

In article <1973@alcbel.be> sp_ppm@space.alcbel.be writes:
    
    We have an application which involves interconnecting two Sun
    workstations via serial lines. Since the data bandwidth between the two
    Suns exceeds that of a single interconnecting line, the two
    workstations are interconnected by two serial lines in parallel, with
    the routing being done by means of Cisco routers. 
    
    The problem is that the Cisco router determines which line to use from
    the IP address.  This means that all the data addressed to the
    destination Sun is always being routed to the destination Sun on the
    one line. Is there any way to be able to communicate between the two
    Suns using different destination IP address, so that the traffic is
    split between the two lines.
    
Disable the ip route cache on both serial lines.

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

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 1993 02:16:40 GMT
From:      erick@demorgan.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP NetUnreachable and TCP behaviour?

 donp@novell.com (don provan) writes:
>
>As far as i understand, a disruption of service in those environments would
>often be only temporary, so aborting the connection altogether just
>because TCP's been retransmitting without success for ten minutes or
>because a network or host has been unreachable for ten minutes would
>seem to be exactly the wrong behavior.  

On packet radio, Karn's optimistic approach would appear to
make sense on a personal machine with only bandwidth concerns
and no cost-per-packet.

Cellular radio, however, will often be charged on a per packet
basis renderring the forever approach to be terribly expensive
as long as keep-alives are used by either side.

Think about people with dial-up IP services.  Sustaining a useless
idle connection costs them an hourly rate if the other side uses
keepalives, or if it keeps trying to ACK some data and keeps seeing
TTL expired or unreachable messages.

>if you explain why you feel the I/O system
>has to participate in identifying the comatose I/O stream, then i'll
>understand where we differ.  Since the application has at least as much
>information about what comatose really means for this particular 
>application.

I know these don't seem like the general cases, but by placing the
control in the TCP and not the application, you make applications
portable to all these environments and many more.  And none of
these situations are terribly uncommon, but the approach I am
suggesting helps them and more.

Let me diverge for a moment.  I've got projects working in
Antartica, the Yukon, black boxes along railway lines, satellite
controls, dialup sites across a country with phone bills 10 times
what you pay, cellular radio and of course common desktops on well 
connected lans.  So of course my perspective is warped by the incredible
diversity of these situations.  But handling them all with one
code set and zero changes to the application layer is a worthwhile
and attainable goal.

While TCP offers inherent scalability, the benefits of the system
can be greatly enhanced if we allow the TCP to participate in
the management of connections based on knowledge of their costs
and well selected constants after investigating connectivity patterns.

Imagine having a file which lists defaults including on and offsite
retransmit defaults, on/offsite SYN timeouts, etc.
Add to that a second file which lists well known ports and a few 
operating characteristics including TTL, timeouts (if any) and 
overrides on the above file.  Making these values SNMP queryable
will one day help with management and comparing two systems.

Why should we lower our TCPs to react differently to different
connections?  There are several good reasons which come to mind
immediately, I hope they are as obvious to others as to me.
	- different expectations - X vs. FTP, remote MAN vs. SMTP
	- the same issues as source routing for traffic 
	- the addition of TCP level security parameters
	- the same issues as prioritized routing


>In fact, it's just such inactivity timers i was thinking of as
>examples of how an application can handle the general case without any
>changes to the I/O system or the TCP implementation to help it handle
>the special case.  There's no reason every other application can't
>have similar timers.

IMHO the problem with application based timers is that you start 
telling the application to understand networks.  Look where that
got X!  By embedding the timers into the O/S, you can tune all 
applications at once and more predictably.  And you also gain
a common location for all parameters.  And not everyone has source,
for DOS, Macs and increasingly for Unix, you get binaries and have
to live with the authors' design choices.

Also, as developers we both know people use our applications in
ways we never expected.  I would ask the Gopher client to suggest 
to the user that it give up after about 30 seconds on an unsuccessful
local site connection, and perhaps after about 2 minutes on 
remote sites.  One of our local colleges may decide to...
(went out and drank a few beers)... do something really
different which requires very different parameters that don't
seem terribly obvious right now.


Erick
-- 
----------------------------------------------------------------------------
Erick Engelke		  Networking is the concept of having data, finding it
erick@sunee.uwaterloo.ca  somewhere else and thinking that it's a good thing.
  			  A distributed environment just means you are less 

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 1993 02:37:32 GMT
From:      dhesi@cirrus.com (Rahul Dhesi)
To:        comp.protocols.tcp-ip
Subject:   I/O timeouts (was Re: ICMP NetUnreachable and TCP behaviour?)

In <C2yrqq.HrB@watserv1.uwaterloo.ca> erick@demorgan.uwaterloo.ca
(Erick Engelke) writes:

>Exactly, that's why I suggested the extension errno=ECOMATOSE when
>reads/writes timeout but the connection is otherwise untouched and
>fully survivable.

Isn't this just a sneaky way of saying ETIMEOUT, the hypothetical error
that a system call would return if BSD allowed you to specify a
timeout parameter?  In your case you are presumably hard-coding the
timeout value.

     ioctl(fd, SET_READ_TIMEOUT, 175);	/* 175 second read timeout */
     count = read(fd, buf, count);
     if (count == -1 && errno == ETIMEOUT) {
	... handle timeout on read;  could try again or abort ...
     } ...

The above can, of course, be achieved with the select() system call
or with alarm().

The advantage of having a timeout built into the read() system call,
for example, would be that naive applications could be easily modified
to handle timeouts gracefully without much recoding.  But I would call
the error value ETIMEOUT, not ECOMATOSE, because only the application
can decide after how much time a connection should be classified as
comatose.
-- 
Rahul Dhesi <dhesi@cirrus.com>
also: dhesi@rahul.net

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1993 09:20:28 +1100
From:      markd@werple.apana.org.au (Mark Delany)
To:        comp.protocols.tcp-ip
Subject:   Re: anyone using UDP?

6500msd@ucsbuxa.ucsb.edu (Michael D'Errico) writes:

>Has anyone here used UDP instead of TCP to do their communication?
>Sure TCP is great since it does a lot of work for you, but it also
>requires a lot of network overhead that is often unnecessary.  

I have chosen to use UDP instead of TCP for two reasons only:

1)	I wanted to broadcast to save bandwidth - typically a message
	was going to some 20-50 systems on the local net, thus in a
	good environment it reduced the transmited bytes on the net by
	20-50 times.  Note that the number of packets is not reduced
	by anything like that order as all recipients have to still
	send ack packets, so the number of packets is still ~ half
	that of a non-broadcast (TCP) implementation.

2)	One of the platforms I worked on had severe restrictions on
	the number of sockets you could have open at any one time.
	Since UDP requires only one socket regardless of the number of
	recipients, it saved my day.

The downside, as many have pointed out is that UDP is unreliable, thus
I had to layer my own protocol on top of UDP to make it reliable. This
meant more code and more debugging, and I'm certain that my dinky
protocol was no match for the TCP implementations.

In summary, (and from what others are saying about efficiency) you
should choose TCP vs UDP largely on your application requirements, not
performance issues.

--
Mark Delany                                          markd@werple.apana.org.au

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 93 04:21:54 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   PD Sniffer?

In article <1993Feb24.181052.13531@nosc.mil> geurin@texasex.nosc.mil writes:

   Does anyone know of a PD/SW PC or Unix based Network Sniffer?

There's the venerable Netwatch from PCIP, ported to run over packet
drivers.  It's on netlab1.usu.edu, in pub/pcip.

-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 93 04:33:10 GMT
From:      ggw@wolves.Durham.NC.US (Gregory G. Woodbury)
To:        comp.protocols.tcp-ip
Subject:   Re: ka9q for unix?

DB>barr@pop.psu.edu (David Barr) writes:
ST>>tener@cs.widener.edu (Stuart Tener) writes:
KH>>>kenh@leps5.phys.psu.edu (Ken Hornstein) writes:
JB>>>>JBOSTERS@KUBVX1.KUB.NL (Jeroen Bosters) writes:

JB>first I apoligise if this is not the right group to ask, but anyway. 
JB>Does anyone here know where I can find ka9q for unix, preferably in a 
JB>version the runs on a sun or an apollo machine.

KH>Why on earth would you need it?  Unix has everything built-in that ka9q
KH>does!

ST>	I think you are quite wrong in your quick, and somewhat
ST>	obnoxious answer. The guy is obviously trying to get tcp/ip
ST>	running under unix, and you are steering him in a redicoulous
ST>	direction.

DB>No, Ken is pretty much right.  Your statement "trying to get tcp/ip
DB>running under unix" is the crux.  Most every version of UNIX ships
DB>with TCP/IP!

Ken and David are missing a huge point.  Sure, Unix tends to come with
TCP/IP implementations *available* for the machine, but in many cases
they are an extra cost option or are incomplete.  (Most Unixen TCP/IPs
do NOT have a SLIP or PPP module in their toolkit, you have to add it
yourself.  And it may require a Kernal recompile, which may not be
possible, etc....)

TCP/IP may be available, that doesn't mean that it is automatically
included in the package.  Now, Sun's practically always include some
form of networking, but a person buying a Sun for personal use at home
might not want to spend the extra hundreds of dollars for a package that
they aren't likely to use (and I don't think that slattach is supplied
by Sun either.)

I am pretty sure that Appollo had TCP/IP as an rather pricey extra cost
item in their systems when I last looked at them.

Don't slam someone for asking a question that does have a valid reason
behind it.  Also remember that having a domain name doesn't imply IP
connectivity!
-- 
Gregory G. Woodbury @ The Wolves Den UNIX, Durham NC  <Standard disclaimers>
UUCP: ...dukcds!wolves!ggw   ...duke!wolves!ggw           [use the maps!]
Domain: ggw@wolves.Durham.NC.US  ggw%wolves@duke.cs.duke.edu
[This site is *not* affiliated with Duke University.  (Idiots!) ]

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 1993 05:37:07 GMT
From:      daylan@baker.ds.boeing.com (Daylan B Darby)
To:        comp.protocols.tcp-ip
Subject:   Ethernet address hash function

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

daylan@baker.ds.boeing.com


-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 1993 05:54:07 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: IP address locator

titzer@grizzly.uoregon.edu (David A. Titzer) writes:
}-rmorley@mis.mi04.zds.com (Ron Morley) writes:
}|> Does anyone know of a tool that will allow me to find out what IP addresses
}|> exist on our network?
 
}Try using the "arp" utility, with "-a" argument. Should return
}names if known, "?" if not, the IP address, and the ethernet address.

A useful way to `prime the pump' for arp is like this:

      ping -v b.b.0.0

It seems that many hosts will respond to a ping request with a "host" part
of all zeros (note that this, as with a pervious suggestion of a package
which listened to arps, doesn't work very well through routers).  There is
also a package called "fping" which can be useful (check "archie" for it).

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 1993 07:50:53 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: IP address locator

In article <1993Feb23.193405.12528@mis.mi04.zds.com> rmorley@mis.mi04.zds.com writes:
    
    Does anyone know of a tool that will allow me to find out what IP addresses
    exist on our network?
    
usc.edu:pub/etherfind.tar.Z is a hacked version that reports only unknown
addresses.

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

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 1993 10:15:43 GMT
From:      evansmp@uhura.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: firewalls and host unreachable

Tod McQuillin (tm8t+@andrew.cmu.edu) wrote:
: Since I have to diagnose a lot of network problems in my job, I've
: gotten into the habit of investigating every "Host unreachable" error
: I encounter just out of habit.
: 
: But it drives me crazy when traceroute says the host is reachable just
: fine, thank you, even when TCP connections fail.  I wish there was
: an error message like "Access to TCP port 21 denied through gateway
: sub39gate.borland.com", instead of the incredibly vague errors I have
: to endure now.

Well the gateway  could send a PORT unreachable message.

Or it maybe that your application is not decoding the destination
ICMP.
: 
: I expect this isn't feasable with IP the way it stands, but I'd
: certainly like the see this added to whatever great protocol inherits
: the internet from IP.

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

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 1993 12:38:02 GMT
From:      rich@tsmnet3.melpar.esys.com (Richard Martin)
To:        comp.protocols.tcp-ip
Subject:   Re: IP address locator


In article <C30Lwr.Fu6@ra.nrl.navy.mil>, titzer@grizzly.uoregon.edu (David A. Titzer) writes:
|> -In article <1993Feb23.193405.12528@mis.mi04.zds.com>, rmorley@mis.mi04.zds.com (Ron Morley) writes:
|> |> Does anyone know of a tool that will allow me to find out what IP addresses
|> |> exist on our network?  I am responsible for IP address administration, but 
|> |> the information that my predecessors have left me is very fragmented and 
|> |> almost unusable.  Also, I know that some of our users have "black" IP    
|> |> addresses that they have assigned themselves.  I would like to be able to
|> |> find them so that I can give them legitimate addresses.  I have tried
|> |> running a set of scripts on our HP 9000/837 that pings progressive IP
|> |> addresses and writes out the addresses that it finds.  However, it seems
|> |> to put an unacceptable load on our network when I run it.  Any ideas would
|> |> be very welcome.
|> |> 
|> |> Thanks in advance,
|> |> 
|> |> Ron Morley
|> |> 
|> |> Zenith Data Systems
|> |> Hilltop Rd.
|> |> St. Joseph, MI.
|> |> 
|> |> disclaimer: any opinions are my own...no one else wants them
|> 
|> 
|> Try using the "arp" utility, with "-a" argument. Should return
|> names if known, "?" if not, the IP address, and the ethernet address.
|> The ethernet address, with a range assigned to manufacturers, will
|> even give you a clue to what type of machine you have discovered.
|> For example, a Sun workstation should give you 8:0:20:x:x:x. This 
|> will help when cleaning up your domain.
|> 
|> Good luck!
|> 
|> Dave
|> ===============================================================================
|> 
|> David A. Titzer
|> Senior Systems Analyst
|> Kestrel Associates, Inc.		Naval Research Laboratory
|> 2800 Shirlington Rd. Ste. 901		4555 Overlook Ave., S.W.
|> Arlington, VA 22206			Washington, DC 20375-5320
|> (703)379-2261 - Voice			(202)767-3903 - Voice
|> (703)379-2264 - FAX			(202)404-7402 - FAX
|> 
|> E-Mail: titzer@net.nrl.navy.mil					

"arp" will only return IP and ethernet address of machines that have "talked"
to your machine, it will not show the IP and ethernet addresses off all machines
on the network.  arp tables usually decay so even if you have talked to every
machine at one point, your current arp table may not contain information
about every node on the network.

If you have a Sun, get tcpdump (I'm not sure where it's at now, but find an 
archie server and it'l tell you).  It is a collection of network analysis
tools that can look at each packet on the network.  It might be able to 
watch all packets and pull out the IP addresses from the packet.

Hope this helps!!

Rich
-- 
################################### <--> ######################################
Richard Martin
E-Systems, Melpar Division - Network Engineering
Internet: rmartin@melpar.esys.com                       UUCP: uunet!melpar!rich

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 1993 17:41:19
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: anyone using UDP?

In article <1993Feb22.152905.10643@ericsson.se> etxmesa@eos.ericsson.se (Michael Salmon) writes:

    In article <C2uruH.2ts@mentor.cc.purdue.edu>
    aj@sage.cc.purdue.edu (John Dormer) writes:
    |> ...You may acheive some reduction in bandwidth by building your own
    |> protocol to run on top of UDP, but not likely....
    
    I have seen several articles along this theme and I wondered if this
    wisdom applied to remote procedure calls? Especially between physically
    close computers and with short messages.

If you can be *absolutely* sure that your application will only be
used on small, reliable LANs, then you might well be able to build
something adequate but lightweight using UDP.  However, if you aren't
in perfect control of the environment, someone, somewhere will overload
the cable, or put a marginally faulty interface on it, or expect the
application to work across an overloaded IP router, or *something*.
Then you will be cursed roundly.

Most network managers have some experience with trying to make things
designed to work on small, reliable LANs work on big, bad catenets.
This is an important cause of chronic bad tempers in the profession.

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


-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 1993 17:41:57
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: anyone using UDP?

In article <1993Feb22.190228.24321@mdd.comm.mot.com> bradley@mdd.comm.mot.com (Michael Bradley) writes:

     One may have little choice depending on requirements. We are working
    in an environment where bandwidth is low and expensive (wireless).
    TCP header overhead (assuming you cant use header compression) and
    connection setup and tear down are an expense one may or may not be
    able to deal with. Not everybody has the luxury of megabit - 
    essentially for free bandwidth.
     
And meanwhile FDDI-based speed freaks are voicing hopes that the
end-to-end checksum can be avoided in *their* use of TCP.

The lesson here is that you may have to sacrifice one or all of
interoperability, hardware-independence or robustness in order to
squeeze the last little bit out of a specific environment.  Fifteen
years ago, the tradeoff generally favored doing your own custom OS,
or protocol, or database, or whatever.  Things change, and I wouldn't
bet a substantial sum on a narrowly-focussed effort these days.

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


-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 1993 17:42:26
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: PC/TCP API description ?

In article <1993Feb23.124540.1583@mnemosyne.cs.du.edu> phanacek@nyx.cs.du.edu (Petr Hanacek) writes:

    Is there any PC/TCP programming API description?

There is a partial description in Ralf Brown's "Interrupt List", which
I believe is available from various anonymous FTP servers.  However,
if you seriously want to implement something, you can either buy our
Developer's Kit (manuals, libraries, example source code, support,
part PC-502), or you can just buy the manual alone (part PC-704).

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


-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 1993 17:51:57
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: I/O timeouts (was Re: ICMP NetUnreachable and TCP behaviour?)

In article <C32CC7.Lov@watserv1.uwaterloo.ca> erick@demorgan.uwaterloo.ca (Erick Engelke) writes:

    ....  My idea with ECOMATOSE was a warning level where the OS has not
    taken any fatal action.

There is a close parallel between this and the PC-IP "timeout upcall"
function - it got called when the TCP had done some number of retransmits,
and it was up to the application to decide what to do, if anything.

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


-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 1993 13:14:03 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: firewalls and host unreachable

In article <wfWl=hy00WB8F1ZkBw@andrew.cmu.edu> Tod McQuillin <tm8t+@andrew.cmu.edu> writes:

>But it drives me crazy when traceroute says the host is reachable just
>fine, thank you, even when TCP connections fail.  I wish there was
>an error message like "Access to TCP port 21 denied through gateway
>sub39gate.borland.com", instead of the incredibly vague errors I have
>to endure now.

  Single-level firewalls should use the "communication with end host
administratively prohibited" indicator.

  MLS systems should not use that because it is an overt (no "c" :-)
violation of MAC.  MLS systems should simply ignore all out of range
incoming packets.

Ran
atkinson@itd.nrl.navy.mil

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 1993 15:26:16 GMT
From:      j.williams@aston.ac.uk (John Williams)
To:        comp.protocols.tcp-ip
Subject:   Automatic running of processes in TCP/IP

I would like to set up a system which allows users to call a TCP port and then
automatically run a process, like the way X.25 subaddresses are used.
Is there a way or a piece of software that can do this?
Thanks
John Williams
Aston University
+44 21 359 3611 X 5142

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 1993 15:57:42 GMT
From:      erick@demorgan.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: I/O timeouts (was Re: ICMP NetUnreachable and TCP behaviour?)

 dhesi@cirrus.com (Rahul Dhesi) writes:
> erick@demorgan.uwaterloo.ca
>
>>Exactly, that's why I suggested the extension errno=ECOMATOSE when
>>reads/writes timeout but the connection is otherwise untouched and
>>fully survivable.
>
>Isn't this just a sneaky way of saying ETIMEOUT, the hypothetical error
>that a system call would return if BSD allowed you to specify a
>timeout parameter?  In your case you are presumably hard-coding the
>timeout value.
>
>     ioctl(fd, SET_READ_TIMEOUT, 175);	/* 175 second read timeout */
>     count = read(fd, buf, count);
>     if (count == -1 && errno == ETIMEOUT) {
>	... handle timeout on read;  could try again or abort ...
>     } ...
>
>The above can, of course, be achieved with the select() system call
>or with alarm().
>
>The advantage of having a timeout built into the read() system call,
>for example, would be that naive applications could be easily modified
>to handle timeouts gracefully without much recoding.  

I don't like the constant use of exceptions and alarms which
is prevalent in common unix code.  BSD TALK, for example, shows
how convoluted the whole process can be when you start looking
into alarms.

>But I would call
>the error value ETIMEOUT, not ECOMATOSE, because only the application
>can decide after how much time a connection should be classified as
>comatose.

As my later post suggests (before I had to log off quickly because
the machine was enterring a destructive countdown) location and usage
specific parameters would best be handled in a centralized file,
and with the option of different parameters happening for on/off-site
situations.  As the Internet grows to fill more roles, the need for
such customization in our OS's becomes very important.

But anyways, I always viewed ETIMEOUT as a fatal error on a
file, such as with the connect() call, where the OS make a
decision and the application has to live with it.  My idea 
with ECOMATOSE was a warning level where the OS has not taken
any fatal action.

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

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 1993 17:44:10 GMT
From:      sen@signet.com (Siddhartha Sen)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP NetUnreachable and TCP behaviour?

Dear Friends,

	In all the discussion on TCP's behavior on net unreachable messages,
I find nobody asked the natural question that should TCP care about ICMP  
in the first place ?

	TCP is a "layer" above IP and its interaction with IP should
be via the well known procedure calls. Now for TCP to disconnect,
the IP layer must pass an error saying "host unreachable". I do
not know that is the case or not (if what I say is what that
happens please tell me accordingly and not _flame_ me).

	If that not be the case then TCP has no business to "sneak"
into ICMP stuff and "be informed". 

	If that be the case, (IP reports to TCP that net is
unreachable ) this report can take place only when "sending" (I suppose)
because otherwise (receive) how the IP layer would know that 
the line is dead (IP is connectionless ). So, in this case TCP
should do similarly what id does when an error comes from IP.

	Am I missing something ? 

Regards,


Siddhartha

-- 
_______Siddhartha__Sen________sen@signet.com____________617_942_0200x136_____
#include <stddisc.h>  /* All above stuff is my own opinion and etc etc etc */
----"Unborn to-morrow , dead yesterday, why fret about them if today be sweet"
------------------------------------------------------Rubayyat-i-Omar-Khayyam

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 93 18:54:31 GMT
From:      chuckb@babbage.csus.edu (Chuck Bland)
To:        comp.protocols.tcp-ip
Subject:   TCP, retry timer, RF extension


I have been pondering extending existing TCP/IP networks thru RF
to remote PCs. The first thought is use The Karn Code. I also
need to mention that this would be in a commercial sense, not
done for Ham radio.

I have thought of a potential problem and I like some comments from
folks who are already in control of networks and/or hosts (non-Karn
hosts).

The problem is with the TCP retry timer. Is it not true that EXISTING
nets and hosts have much shorter retry timers, since connectivity is
so much better, bits rates are higher, etc ? Presuming that is so,
one host could practically jam an RF channel with retries, since the
RF unit didn't (and couldn't) respond fast enough to suite it. I have
seen something close to this by using NCSA FTP, targeting an RF host
(Karn), getting to the RF network from my PC via ethernet thru another
Karn host as a gateway. In other words...

NCSA PING ---ethernet--- Karn RF Gateway---RF link--- Karn Remote Host

NCSA FTP FLOODED the rf channel with connect requests.

I don't know of anything that would keep this same type of thing from happening
on an existing network.

What are typical retry timer values ? Are they configurable ? What would be
the effect on the existing net to lengthen them to accomadate the RF channel ?
Does it take a recompile to accomplish any of this ? What other alternatives
are there, presuming you DON'T want to hack TCP ?

Hopefully I've been clear enough on this. Looking forward to the replies.

Chuck Bland
chuckb@babbage.ecs.csus.edu
--
My sig file

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 1993 21:34:10 GMT
From:      JBaird@rm42.ucc.uconn.edu (James Baird)
To:        comp.protocols.tcp-ip
Subject:   Multiple Subnets on one Token-Ring?


Here's a poser for all you IP gurus:

On our campus, we have a token-ring backbone connecting by source routing 
bridges to local (building) token rings.  We also have ethernet 
segments, interconnected with routers to make separate IP subnets (the 
ethernets are separate - i.e., they don't use the token ring backbone).  
Thus, on our TCP/IP network, the ENTIRE campus token ring is one TCP/IP 
subnet (128 hosts with our subnetting scheme).

The problem is, token ring people are starting to want access to TCP/IP 
(not that I blame them...).  We need to separate the token ring into 
separate subnets, fast, and  was wondering if there was a way to do it 
without replacing all our cheap bridges with expensive routers.

After paging through my handy-dandy copy of _Internetworking with TCP/IP_, 
particularly the chapters on ARP and IP, I'm trying to find a reason why I 
couldn't just throw two (or more...) router interfaces on the token ring, 
set up as different subnets, and set up my hosts accordingly.  It seems to 
me, based on what I read, that the hosts and router on, say, subnet 23 would 
only see broadcasts from subnet 23, and ignore any other IP traffic on 
the ring.  

Does anybody have any good reasons why this is a really stupid idea, or am 
I beginning to know TCP/IP from a hole in the wall?  (fat chance)

We thank you again for your support, 
Jim Baird
UCONN Computer Center 

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 93 23:04:04 GMT
From:      merce@iguana.uucp (Jim Mercer)
To:        comp.protocols.tcp-ip
Subject:   Re: ka9q for unix? (with answer and flame)

In article <1mc3qh$jo2@leps5.phys.psu.edu> kenh@leps5.phys.psu.edu (Ken Hornstein) writes:
>>	I think you are quite wrong in your quick, and somewhat
>>	obnoxious answer. The guy is obviously trying to get tcp/ip
>>	running under unix, and you are steering him in a redicoulous
>>	direction.
>
>Uh-huh.  Let's see .... What does KA9Q have?
>
>	Multitasking kernel		Comes with Unix.
>	TCP/IP				Comes with Unix (on apollo and suns)
>	Serial line drivers		Available for free
>
>Note that I'm not trashing KA9Q at all ... I use it, and I love it.  But
>Unix comes with everything you need, except packet radio drivers.  And porting
>KA9Q to Unix would be kinda pointless, IMHO.  And I didn't think my original
>reply was that obnoxious at all.  Obnoxious would have been something like:
>
>"You stupid shithead, get a clue.  If you had any brains for all, you'd know
>that Unix comes with everything you need!"

You stupid shithead, get a clue.

not all unix's have TCP/IP, and even some of those don't have serial drivers
for free or any amount of money.

my 3b1 does not come with TCP/IP, but i can use ka9q to do slip with it.

my 3b2 has TCP (an add-on), but there are no slip drivers for it. period.

before trying to make a definitive answer to a question, make sure you know
what you are talking about.

"what do you want diesel for? all cars use gasoline."

BTW: ka9q for unix can be had from ucsd.edu:/pub/packet-radio/ka9q/sysv
(or something along those lines.)

-- 
[ Jim Mercer   Reptilian Research  merce@iguana.reptiles.org  +1 416 506-0654 ]
[                true(1)    Now, /bin/true always returns zero.               ]
[                           -- from Ultrix Release Notes 4.3                  ]

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Feb 1993 23:04:27 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: TCP, retry timer, RF extension

> The problem is with the TCP retry timer. Is it not true that EXISTING
> nets and hosts have much shorter retry timers, since connectivity is
> so much better, bits rates are higher, etc ?

No this is not correct. Most existing hosts use adaptive retry timers
(in particular, Jacobson's algorithm combined with Karn's algorithm --
see RFC 1122 for details on what is expected and pointers to papers).
Both algorithms were heavily tested over paths where one or more links
were substantially slower than the others and showed good performance.
Radio links were included in these tests.

> NCSA PING ---ethernet--- Karn RF Gateway---RF link--- Karn Remote Host
>  
> NCSA FTP FLOODED the rf channel with connect requests.

This is not a proper test.  PING uses a connection-less protocol and simply
sends packets, often as fast as it can.  It doesn't have an retry timers.
Try doing an FTP across the wire -- you'll see an initial load of packets
as the round-trip time estimator adapts, then all should be fine.

> What are typical retry timer values ? Are they configurable ? What would be
> the effect on the existing net to lengthen them to accomadate the RF channel ?
> Does it take a recompile to accomplish any of this ? What other alternatives
> are there, presuming you DON'T want to hack TCP ?

As I've noted above, standard TCP *adapts* to long delays.  There should be
no need to hack TCP.

Craig Partridge
craig@bbn.com

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 93 05:20:15 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: anyone using UDP?

In article <930226174157@cream.ftp.com>, jbvb@vax.ftp.com (James B. VanBokkelen) writes:
>      
> And meanwhile FDDI-based speed freaks are voicing hopes that the
> end-to-end checksum can be avoided in *their* use of TCP.

Not all of us.

Some of us are completely saturating the ring with a single TCP virtual
circuit, pushing the token latency as high as you might wish, with
valid and checked checksums, with what are advertised as "low cost"
UNIX boxes.  (well, not quite as "low cost" as a generic 386SX PC, but
less than a "mid-priced" car.)

Recall that at Interop92 there were two different vendors showing
machines doing >= 95Mbit/sec.

The TCP checksum is too easy to do in hardware to worry about bending
the RFC.


Vernon Schryver,  vjs@sgi.com

-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Feb 1993 06:03:56 GMT
From:      uad1200@dircon.co.uk (Ian Wade)
To:        comp.protocols.tcp-ip
Subject:   *****  KA9Q NOS:  NOSview now on ucsd.edu   *****

===========================
KA9Q: NOSview RELEASE [304]
===========================
by Ian Wade, G3NRW


NOSview [304] is now available via FTP on

        * * * * * * * * * * * * * * * * * * * * * * * * *
        *   ucsd.edu:  /hamradio/packet/tcpip/nosview   *
        * * * * * * * * * * * * * * * * * * * * * * * * *

Download the file:
                     * * * * * * * * * *
                     *                 *
                     *   nosvw304.zip  *
                     *                 *
                     * * * * * * * * * *


NOSview, first introduced in September 1991, is an on-line
documentation and runtime package for the KA9Q Network
Operating System (NOS).  It contains:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

***  probably the only complete reference work anywhere
     that describes all of the commands to be found in the
     major NOS releases.

***  a TSR file viewer that lets you read the NOSview
     documentation on-line, without breaking out of NOS.

***  NOSgas: the "NOS Get-Away Special"  --  a complete set
     of working NOS runtime software, based on the PA0GRI
     2.0m release.

***  a complete set of templates for the NOS control files.

***  full details on how to get the book "NOSintro", which
     describes in detail how TCP/IP works and how to use
     KA9Q NOS.  Ideal for beginners to TCP/IP (and more
     advanced users will find many gems of helpful
     information there as well).

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


NOSview [304] contains many new documentation files, and
the template NOS control files match the listings in the
book "NOSintro".

Extras include ....

    UUENCODE/UUDECODE file conversion utilities
    AX.25 Baycom Packet Driver
    KISS protocol documentation
    HOSTS <> DOMAIN conversion programs
    PCElm and ELM Mailers
    The Clockwork VIEW TSR file viewer

As NOSVW304.ZIP is quite large (around 700 KB), you may
prefer instead to get your copy by mailing a DOS-formatted
diskette (any size EXCEPT 360 KB) and return mailer to:

     Ian Wade, G3NRW
     7 Daubeney Close
     Harlington
     DUNSTABLE
     Bedfordshire
     LU5 6NF
     United Kingdom

Please enclose return postage as follows:

     United Kingdom:               UK postage stamps
     Rest of Europe:               3 IRCs
     The Americas, Africa:         7 IRCs
     Rest of the World:            9 IRCs

(Any unused IRCs will of course be returned).

There is no charge for NOSview, so please do NOT enclose
any form of payment.


73 de Ian Wade, G3NRW

February 1993

P.S.  If you would like full details of the book
      "NOSintro", please email me direct:

        ianwade @ dircon.co.uk

--
* * * * * * * * * * * * * * * * *|* * * * * * * * * * * * * * * * * * * *
*  Ian Wade                      | Email:   ianwade @ dircon.co.uk.     *
*  Dowermain Ltd                 |          g3nrw @ dircon.co.uk.       *
*  7 Daubeney Close, Harlington, | AX.25:   G3NRW @ GB7KHW.#21.GBR.EU   *
*  DUNSTABLE, Beds  LU5 6NF, UK  | AMPRnet: g3nrw.ampr.org 44.131.5.147 *
* * * * * * * * * * * * * * * * *|* * * * * * * * * * * * * * * * * * * *

-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 1993 06:18:49 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple Subnets on one Token-Ring?

In article <JBaird.18.730762450@rm42.ucc.uconn.edu>
JBaird@rm42.ucc.uconn.edu (James Baird) writes: 
    
    The problem is, token ring people are starting to want access to TCP/IP 
    (not that I blame them...).  We need to separate the token ring into 
    separate subnets, fast, and  was wondering if there was a way to do it 
    without replacing all our cheap bridges with expensive routers.
    
    After paging through my handy-dandy copy of _Internetworking with
    TCP/IP_, particularly the chapters on ARP and IP, I'm trying to find a
    reason why I couldn't just throw two (or more...) router interfaces on
    the token ring, set up as different subnets, and set up my hosts
    accordingly.  It seems to me, based on what I read, that the hosts and
    router on, say, subnet 23 would only see broadcasts from subnet 23, and
    ignore any other IP traffic on the ring.
    
You should be able to do this with a single interface off of your router.

Tony

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

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 93 16:02:44 GMT
From:      bask@ra.cs.umb.edu (Brian Pedranti)
To:        comp.protocols.tcp-ip,comp.os.os2.networking
Subject:   PC/NFS Was: SLIP Server for OS/2 2.0

>>Does anyone know of a SLIP server for OS/2 2.0?  I'm using IBM's TCP/IP  
>>package.
>
	Use David Bolen's SLIP package. e-mail at db31@and.net

On a related note. Has anyone actually mounted an OS/2 NFS drive on a
PC/TCP workstation? PC/TCP comes with that pcnfs.c thing, has anybody
compiled it for OS/2?

What else is available for NFS clients and print-redirectors for DOS?

Brian

-- 
----------------------------------------------------------------------
Brian Pedranti                       | "Now I can't see the stars 
bask@cs.umb.edu | bask@ra.cs.umb.edu |  Know we have gone too far"
University of Mass. at Boston        |  - Overkill; Horrorscope 

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Feb 1993 16:02:52 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP, retry timer, RF extension

> chuckb@babbage.csus.edu (Chuck Bland) writes:
>
>I have been pondering extending existing TCP/IP networks thru RF
>to remote PCs. The first thought is use The Karn Code. I also
>need to mention that this would be in a commercial sense, not
>done for Ham radio.
>
>The problem is with the TCP retry timer. Is it not true that EXISTING
>nets and hosts have much shorter retry timers, since connectivity is
>so much better, bits rates are higher, etc ? 

A modern TCP has a few default constants, but it adapts to the data
rates of the connection and all intermediate lines.  So before resending
data, the TCP uses statistics to say it is unlikely that the previous
packet worked.  To do this, it keeps constant track of a few run-time
statistics.

Suppose the average time it takes for a packet to receive the remote
machine and return (the round trip time or RTT) is 1.6 s.  And suppose
the standard deviation is 0.6 s.  After 1.6 + 0.6 s or 2.2 s of no ACK, 
there is about an 82% probability the packet was lost, after 2.8 s there
is about a 98% probability the packet was lost. 

What I failed to mention was that the usual average calculation is
useless here (imagine if someone else joined your bandwidth so you
suddenly have to share it) so your TCP will use a time-weighted average, 
and most TCPs compute standard error rather than standard deviation, and 
many systems delay ACKs depending on data rates on the connection, etc.

Also, you were probably seeing extra packets related to what we
normally call "the slow start" algorithm which will significantly
improve performance over long path connections - though not necessarily
over radio depending on the congestion control.

So my answer has been algorithms for this and that control the
packet sending rates.  It is the selective use of algorithms or
constants in them that will ultimately give you the performance
you need.  But I would hazzard to say that it takes some proficient
knowledge of these algorithms to make them tuned in your favour.

Erick

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

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Feb 1993 16:10:38 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: PC/TCP API description ?

> jbvb@ftp.com writes:
>> phanacek@nyx.cs.du.edu (Petr Hanacek) writes:
>
>    Is there any PC/TCP programming API description?
>
>There is a partial description in Ralf Brown's "Interrupt List", which
>I believe is available from various anonymous FTP servers.  However,
>if you seriously want to implement something, you can either buy our
>Developer's Kit (manuals, libraries, example source code, support,
>part PC-502), or you can just buy the manual alone (part PC-704).

I'd like to add to James' response:

The manual alone is only suitable for writing things that talk at
a very PC/TCP-centric layer.  I'm not complaining, I wish more companies
gave that level of detail.

But most people are starting with code from another system or are
interested in someday porting to other PC or Unix systems.

If so, pick up the complete developer's kit.  You get BSD compatible
libraries, as well as a C interface to the low level stuff.  Think
about that, programming in C allows most of us to avoid stuffing
registers and calling interrupts directly - the complete toolkit
also removes that level of complexity and simplies use of the low
and high level interfaces.

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

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Feb 93 16:41:43 GMT
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: ka9q for unix? (with answer and flame)

In article <1993Feb26.230404.11676@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes:
>You stupid shithead, get a clue.
>
>not all unix's have TCP/IP, and even some of those don't have serial drivers
>for free or any amount of money.

No shit.  This has already been stated.

>my 3b1 does not come with TCP/IP, but i can use ka9q to do slip with it.
>
>my 3b2 has TCP (an add-on), but there are no slip drivers for it. period.
>
>before trying to make a definitive answer to a question, make sure you know
>what you are talking about.

Before you spout off like this, make sure to read the original post.
The original poster wanted ka9q for Suns an Apollos, both of which have
TCP/IP.  We're not talking about 3b1's and 3b2's.  ka9q is redundant.
(although a packet radio driver, of course, is not, but that's an
entirely different matter)

--Dave
-- 
System Administrator, Population Research Institute    barr@pop.psu.edu
What does it profit a man if he gains the whole world, but still runs DOS?

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Feb 1993 18:09:30 GMT
From:      dcarr@gandalf.ca (Dave Carr)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP, retry timer, RF extension

In <C3478s.2sD@watserv1.uwaterloo.ca> erick@sunee.uwaterloo.ca (Erick Engelke) writes:

>> chuckb@babbage.csus.edu (Chuck Bland) writes:
>>
>>I have been pondering extending existing TCP/IP networks thru RF
>>to remote PCs. The first thought is use The Karn Code. I also
>>need to mention that this would be in a commercial sense, not
>>done for Ham radio.
>>
>>The problem is with the TCP retry timer. Is it not true that EXISTING
>>nets and hosts have much shorter retry timers, since connectivity is
>>so much better, bits rates are higher, etc ? 
 
>A modern TCP has a few default constants, but it adapts to the data
>rates of the connection and all intermediate lines.  So before resending
>data, the TCP uses statistics to say it is unlikely that the previous
>packet worked.  To do this, it keeps constant track of a few run-time
>statistics.

Yes.  But PC/TCP has the above mentioned problem.  I ran into it testing
wide-area bridges over 64K pipes.  PC/TCP would not adjust it's timers,
or at least not make them long enough. 
-- 
Dave Carr               | dcarr@gandalf.ca       | It's what you learn, 
Principal Designer      | TEL (613) 723-6500     | after you know it all,
Gandalf Data Limited    | FAX (613) 226-1717     | that counts. 

-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Feb 1993 00:04:00 +0000
From:      rmt@cix.compulink.co.uk (Richard Thomas)
To:        comp.protocols.tcp-ip
Subject:   No subject

Subject : PPP Protocol Testing

I'd be interested in suggestions from the net :

In April I'll be doing some interoperability testing to see how
different router vendors' PPP implementations get on together.

Specifically, we plan to build a test network around Ethernets
and some E1 simulators which uses PPP to link hosts which
exchange a variety of protocols. So far, that list is
something like IP, IPX, Appletalk, DECNet and Transparent
Bridging. If I can think of a good source of OSI packets
(DEC V ?) that will be in there too.

Getting hosts together to source that variety of
traffic will be a challenge but so far response from router
vendors has been good : we've 'yes's from Wellfleet, Proteon,
ACC, Xyplex, Eicon, and Retix, with possibles from 3Com and
now, who was it ? Ah yes, Cisco.

I'd be very interested in your suggestions or experiences
in what you've seen to be problems with PPP - any weak areas
you think especially worth testing, or pairs of vendors with
known problems. Basic compatibility, performance and option
support are not hard to test - but what would you look for ?

'Data Communications' are interested in carrying the result
so you'll see some feedback from this eventually.

Mail me with any comments, and if there's a good set I will
summarise here.

Richard Thomas

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Feb 1993 00:24:49 GMT
From:      brunner@practic.com (Thomas Eric Brunner)
To:        comp.protocols.tcp-ip
Subject:   Re: IP address locator


One such tool was written by a former co-worker of mine at SRI, as one part
of a "find the damn ip-forwarders" problem large bridged networks had then
with default host vendor configurations. Look for ETHERHOSTPROBE in the NOC
Tools catalog nearest you.

.SH SYNOPSIS
.B "etherhostprobe begin-addr end-addr"
.SH DESCRIPTION
Probes each Internet address in the range starting with ``begin-addr'' and
ending with ``end-addr'' (both ``begin-addr' and ``end-addr'' can be either
hostnames or dotted-decimal Internet addresses) by forcing an ARP
packet to be sent to each Internet address in the range specified.
Up to 5 ARPs per hosts will be send at 0.25 second intervals.
This program uses the operating system's ARP tables, and thus may degrade
performance somewhat while running.

Written by Paul McKinney, putatively at my request.

The output is then fed to "ipforwarding", which figures out if the arp'er
at w.x.y.z forwards, which was then usually the case.

-- 
#include <std/disclaimer.h>		We learn through trail and eror.
Eric Brunner Tule Network Services
at sign: brunner@practic.practic.com, bang address: uunet!practic!brunner
trying to understand multiprocessing is like having bees live inside your head.

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Feb 1993 03:38:34 GMT
From:      jsl@world.std.com (Jonathan S Levinson)
To:        comp.protocols.tcp-ip
Subject:   Saving connections

We are building a database server for TCP/IP.  The clients will be UNIX
workstations.  The servers will be IBM mainframes running the database.
The login protocol to the mainframe database involves first establihing a
connection using BSD socket call connect, and then exchanging login
information. Does it make sense to save connections?  In otherwords, have
daemons running that preserve a pool of connections (and their associated
sockets). Logging off would not destroy the connection.  Future logins
could use the connection.  For example, we would search through the
connection list, for a host TCP/IP address and server port that matched
the desired one. We would have a daemon connection manager.  The goal
would be to avoid the overhead of reestablishing a connection.  Is this
overhead high? Does it cost a lot to establish a connection?  The idea of
saving connections comes from the SNA and APPC world where SNA session
establishment is costly and so conversations utilize sessions in an
already existent session pool. 

   

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Feb 1993 04:30:35 GMT
From:      peter@ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip,comp.periphs
Subject:   Terminal Servers

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

-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 1993 15:23:22 -0600
From:      karl@ddsw1.MCS.COM (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   FTP client (new; easier to use) available?

A couple of months ago someone posted a pointer to a freely available,
easier-to-use FTP client package which was on the net somewhere. 

Does anyone have a pointer to that I can have?  I would love to get ahold of
this; I have some users who would like a better user interface than the
standard FTP fare.

Thanks in advance.

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Data Line: [+1 312 248-0900]	LIVE Internet in Chicago; an MCSNET first!

-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Feb 1993 13:33:43 GMT
From:      dedgar@mta.ca
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP NetUnreachable and TCP behaviour?

In article <C32H9n.Got@signet.com>, sen@signet.com (Siddhartha Sen) writes:

>	In all the discussion on TCP's behavior on net unreachable messages,
>I find nobody asked the natural question that should TCP care about ICMP  
>in the first place ?
>
>	TCP is a "layer" above IP and its interaction with IP should
>be via the well known procedure calls. Now for TCP to disconnect,
>the IP layer must pass an error saying "host unreachable". I do
>not know that is the case or not (if what I say is what that
>happens please tell me accordingly and not _flame_ me).

RFC 1122 (Host Requirements - Communications Layers) specifically
states in section 3.2.2.1 (page 40) that ICMP destination unreachable messages
MUST be passed to the transport layer and TCP (page 103) MUST act on
them. 

>
>	If that not be the case then TCP has no business to "sneak"
>into ICMP stuff and "be informed". 
>

In fact the notion of strict protocol layering in the TCP/IP suite
is frequently violated. For example: an IP pseudo header is required
to construct TCP and UDP segments, IP options must be passable
all the way down to ip from the application layer & etc. There
are lots of other examples. There are lots of differing opinions about
this non strict layering and whether it is a strength or a weakness.
This issue is frequently discussed during those depressingly regular
TCP/IP vs OSI slugfests one sees on this group. I do hope this doesn't
start another one ;-)

With TCP/UDP/IP the rfc's are the rules, and like it or don't, ya gotta
play by em.

						Dale Edgar
						Cybernetic Control Inc.
						DEDGAR@MTA.CA  

-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Feb 1993 14:26:05 GMT
From:      peter@ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip,comp.periphs
Subject:   Re: Terminal Servers

UU.PSI.COM's mail routing is all messed up (it directs all mail to a bogus
system 'xtabfail'), so please send any responses to 'peter@taronga.com'.

Grumble.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Feb 1993 14:59:50 GMT
From:      rypma@waterloo.hp.com (Ted Rypma)
To:        comp.protocols.tcp-ip
Subject:   Re: bootp sources

Sudhakar Ravi (sonicsys@netcom.com) wrote:
: I got the sources for bootp from CMU, and ran into a problem with the way
: the bootreply handles filenames.  We have a ROM that lets a Macintosh
: boot disklessly from a UNIX machine, and the CMU version of bootp doesn't 
: seem to return a diskfile name in the bootreply.  This is ok if 
: you're using the bootp server to just get an IP address, but it doesn't
: work if you're also trying to get the filename to boot from.  
: Has anyone encountered this problem before?  And if so, is there a fix for
: this?

CMU bootp has a nasty habit of wanting to know that tftp can access the
file before it'll put the name in the response. If for any reason it
decides your desired file isn't avalaible, it won't bother putting the
boot file name in the response. This can especially be a problem for those
hosts that support nfs as a file access method for downloading (as opposed
to the obvious earlier predilection at CMU for tftp).

The latest CMU bootpd does have a workaround/modification for this; the
'sa= ' (Server Address) flag tells bootpd that the file is on some other
machine, so it will always provide the name, even if it believes it isn't
on the bootp server host.

Ted Rypma
HP Panacom Division
Waterloo, Ontario

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Feb 1993 16:04:34 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP NetUnreachable and TCP behaviour?

In article <1993Feb28.133343.13206@jupiter.sun.csd.unb.ca> dedgar@mta.ca writes:

>In fact the notion of strict protocol layering in the TCP/IP suite
>is frequently violated. 

  This is also widely true of OSI protocol implementations in the
network layer and transport layer.  In both OSI and TCP/IP, there is
normally stricter implementation of layering above the transport layer
and below the network layer than between the two.  The OSI documents
like to pretend that they are strictly separated, but this is often
not true of OSI implementations.

> There are lots of differing opinions about this non strict layering
> and whether it is a strength or a weakness.  

  Given that most OSI implementations don't strictly layer, the phrase
"this non-strict layering" must be referring to the implementation
guidance in the Host Requirements RFCs.  However, the OSI specs
religiously avoid implementation guidance -- which is one reason that
NIST sponsors regular meetings of the OSI Implementor's Workshop (so
that interested parties can agree on the details of implementations).

Ran
atkinson@itd.nrl.navy.mil


-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Feb 1993 21:36:56 GMT
From:      k2@bl.physik.tu-muenchen.de (Klaus Steinberger)
To:        comp.protocols.tcp-ip
Subject:   Re: bootp sources

rypma@waterloo.hp.com (Ted Rypma) writes:

>: boot disklessly from a UNIX machine, and the CMU version of bootp doesn't 
>: seem to return a diskfile name in the bootreply.  This is ok if 
 
>boot file name in the response. This can especially be a problem for those
>hosts that support nfs as a file access method for downloading (as opposed
>to the obvious earlier predilection at CMU for tftp).
You run into the same problem, if your tftp is chroot'ed to some other
directory than the root. I've modified bootpd to chroot to, but it would
work to if you precede it with a chroot command.

Sincerely,
Klaus
--
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende
FAX:   (+49 89)3209 4280        D-8046 Garching, Germany
Internet: Klaus.Steinberger@Physik.Uni-Muenchen.DE

END OF DOCUMENT