The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 89 00:07:50 GMT
From:      meggers@orion.oac.uci.edu (mark eggers)
To:        comp.protocols.tcp-ip
Subject:   Re: Why do TCP connections hang?

Bill,
     One thing that may be biting you is a particular bit pattern. If you 
have marginal connections to the rest of the world, or if your 
CSU/DSUs are a bit flakey, they can mangle certain bit patterns. We 
had this happen with a connection on CERFnet from here at UCI to 
SWRL (Cal State University net). PacBell and Brian Roode (another 
member of our network team) found the flakey link between Seal 
Beach and Long Beach. I think that they found it by doing extensive 
BERT (bit error rate tests) tests. 
     Since you seem to be on the track of this problem, you might try 
to artificially generate the bit pattern in a file (a quick and dirty C 
program), and then do a binary FTP to another system. If the FTP 
hangs, then you have some cause to suspect that bit pattern. You 
might want the circuit provider to then run a BERT test using the 
suspected pattern and watch for errors.
     At that point, you can then start replacing things to bring the 
error rate down.

Of course, this is just a guess (with 2 hours of sleep at that ;-) ).

Good luck - Mark Eggers, Network Communications Analyst
            University of California, Irvine

email:      meggers@uci.edu

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Fri, 01 Dec 89 11:53 PST
From:      Michael Stein                        <CSYSMAS@OAC.UCLA.EDU>
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Ye Old Discard Protocol (WKS == 9)
> We told the manufacturers that we strongly disagree with their
> practice, have suggested that they register a multicast address
> and use that, and have threatened to install filters for their
> stupid packets.

Multicast won't help on Token Ring, it maps to broadcast...

I think the ONLY solution is to not allow those packages on the
network...
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 89 05:11:53 GMT
From:      tds@cbnewsh.ATT.COM (antonio.desimone)
To:        comp.protocols.tcp-ip
Subject:   Re: Traffic Sensitive SPF Routing is NOT too hard!

From article <8911302038.AA19457@ucbvax.Berkeley.EDU>, by jzinky@BBN.COM ("John A. Zinky"):
> I would like to give my opinion on traffic sensitive routing from the
> experience of running large over-subscribed networks, such as the 1987-88
> ARPANET.

Or the phone network?  There is in fact a lot of experience in running
large networks and using traffic-sensitive routing.  When I started
this thread (I think we're on the same thread) I was really interested
in how dynamic routing algorithms in datagram networks compare to the
algorithms used in circuit-switched networks, to see if my intuition
is completely useless for datagram networks.  An apparent difference
is that routing in datagram networks can (in principle) react to
congestion on the timescales on which queues build up.

> equipment procurement (months to years). Routing is an allocation
> policy that maps traffic flows onto available resources. It works on
> the time scale of network operations (minutes to days).  Congestion
> control regulates user traffic so that resources are not
> oversubscribed. It works on the time scale of a few round trip times.

This discussion gives me a nice warm feeling since it says that routing
in datagram networks, in practice, behaves much like routing in
circuit-switched networks in the sense of mapping traffic flows, *not*
individual packets.

> "Be careful, it's a real world out there"

I love this guy!
-- 
Tony DeSimone
AT&T Bell Laboratories
Holmdel, NJ 07733
att!tds386e!tds

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 89 08:00:21 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: Ye Old Discard Protocol (WKS == 9)

Philip,
  What you're probably seeing is a very disgusting habit that seems to be
developing among purveyers of commercial network products.  They
broadcast their license numbers in an effort to prevent users from
copying their software and using multiple copies simultaneously on a
local network.  Some broadcast their licenses continuously every few
seconds in an effort to avoid people partitioning their networks,
starting up copies of the same program on isolated sections of the
network and then rejoining the network ...  I shit you not.

  This is a particularly revolting technique of copy protection since
these licenses are encapsulated in broadcast packets that interrupt every
host on the network.  Since we have a flat network of over 2000 hosts
here at LLNL, the potential disruption is dramatic for us.  We told the
manufacturers that we strongly disagree with their practice, have
suggested that they register a multicast address and use that, and have
threatened to install filters for their stupid packets.  This last is a
completely empty threat since the bridges we have (DEC LanBridge 100s)
don't support this kind of packet filtering, we don't have money to buy
new bridges, and even if we did have, the administrative effort needed to
maintain all the filters is more time than we can afford.

  I can say that if we (our network support group) learns that a product
uses this technique, we will advertise it as a prohibited product on our
network.  We just can't afford to have our network distroyed by a few
companies who prefer to invest their time in stupid copy protection
schemes rather than in improving their product and support, thereby making
it unprofitable to copy their product.  (By copying such a product you'd
still be out the documentation, support, etc.)

Casey

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Dec 89 13:53 CDT
From:      Malcom McNaylor <MALCOM%LSUVAX.SNCC.LSU.EDU@ricevm1.rice.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   MULTINET
I'm trying to find a vendor contact for MULTINET.  Address or phone number
would be helpful.  Thanks
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Dec 89 15:43 EST
From:      "John L. Jamison, VAX System Analyst" <JAMISON%campus.swarthmore.edu@CORNELLC.cit.cornell.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Looking for MacTCP example programs or working code


Anyone out there have a working program which makes use of MacTCP?  I'd
be interested in taking a look at it.

Please reply directly,

Thanks very much!

John Jamison
Swarthmore College

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Dec 89 17:37 CDT
From:      Malcom McNaylor <MALCOM%LSUVAX.SNCC.LSU.EDU@ricevm1.rice.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   MULTINET information
I need a vendor contact for MULTINET software.  Can you help me?
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 89 17:12:08 GMT
From:      wunder@HP-SES.SDE.HP.COM (Walter Underwood)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP IP vendor selection


   The Distributed Command and Control project (DC2) at
   NOSC is an attempt to bring Naval command and control
   systems into the networking arena by frontending them
   with PC-ATs.

Sounds like you are trying to put a multi-tasking application on a
single-tasking box.  Though you can write it, NONE of the support
software will have been extensively tested for multi-tasking.  Have
you thought about dumping MS-DOS and getting multitasking systems
with TCP/IP?

Some ideas:

  cheap Unix workstations (HP has one under $5000)
  Unix on PCs
  HP1000
  68000 cards with VxWorks ROM-able OS (Mizar sells these)

The VxWorks stuff looks particularly interesting.  Though I haven't
used it, I've heard some good reports.

wunder

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 89 18:53:00 GMT
From:      MALCOM@SN01.SNCC.LSU.EDU (Malcom McNaylor)
To:        comp.protocols.tcp-ip
Subject:   MULTINET

I'm trying to find a vendor contact for MULTINET.  Address or phone number
would be helpful.  Thanks

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 89 19:53:00 GMT
From:      CSYSMAS@OAC.UCLA.EDU (Michael Stein)
To:        comp.protocols.tcp-ip
Subject:   Re: Ye Old Discard Protocol (WKS == 9)

> We told the manufacturers that we strongly disagree with their
> practice, have suggested that they register a multicast address
> and use that, and have threatened to install filters for their
> stupid packets.

Multicast won't help on Token Ring, it maps to broadcast...

I think the ONLY solution is to not allow those packages on the
network...

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 89 20:43:00 GMT
From:      JAMISON@SWAT.SWARTHMORE.EDU ("John L. Jamison, VAX System Analyst")
To:        comp.protocols.tcp-ip
Subject:   Looking for MacTCP example programs or working code



Anyone out there have a working program which makes use of MacTCP?  I'd
be interested in taking a look at it.

Please reply directly,

Thanks very much!

John Jamison
Swarthmore College

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 89 21:02:12 GMT
From:      aggarwal@JVNCA.CSC.ORG (Vikas Aggarwal none)
To:        comp.protocols.tcp-ip
Subject:   tracing a route


You can get the source from teh folowingo

	rtsg.ee.lbl.gov
	uc.msc.umn.edu
	ftp.ee.lbl.gov

If you need help with the kernel modes, I could probably do so.

-vikas

=--=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-==-=-=
	JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER

INTERNET:  aggarwal@jvnca.csc.org
BITNET:    aggarwal@jvncc
UUCP:      rutgers!jvnca!aggarwal

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

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 89 21:05:32 GMT
From:      hughes@silver.bacs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip
Subject:   library

Does anyone know where source can be obtained for the library
libndbm.a (which I believe is normally located in /usr/local/lib
if at all)?  Thanks in advance for any pointers...

 //=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=\\
|| Larry J. Hughes, Senior Programmer ||  hughes@silver.bacs.indiana.edu   ||
||        Indiana University          ||                                   ||
||   University Computing Services    ||  "The person who knows everything ||
||    750 N. State Road 46 Bypass     ||     has a lot to learn."          ||
||      Bloomington, IN  47405        ||                                   ||
||         (812) 855-9255             ||  Disclaimer: See quote above.     ||
 \\=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=//

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 89 21:06:33 GMT
From:      paul@UXC.CSO.UIUC.EDU ("Paul Pomes ", I'm the NRA!)
To:        comp.protocols.tcp-ip
Subject:   FTP connections hanging

Try test files that have multiple lines of C characters (such as you would
would use for a Fortran comment block) and then multiple lines of 3
characters.  We found that when ProNet-80 modems start to go bad, these
bit patterns cause them to jump in and out of ring.

/pbp

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 89 22:12:06 GMT
From:      dieter@lynn.cs.ucla.edu (Dieter Rothmeier)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   What is INADDR_LOOPBACK for in sockets?

While reading some code, I came across the following
construct:

struct sockaddr_in sin;
....
sin.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
...


I know about INADDR_ANY, but I've never seen this one.
It's defined in <netinet/in.h>. I looked through the
documentation (this is on a Sun 3/80) quite extensively,
but couldn't find anything.

Any help would be appreciated.
Dieter

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 89 22:21:33 GMT
From:      mark@alias.UUCP (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Question about telnet RFC

I am reading over RFC854, the telnet protocol specification and have come
upon a confusing paragraph. This excerpt is from from section 3b of
GENERAL CONSIDERATIONS:

      b. If a party receives what appears to be a request to enter some
      mode it is already in, the request should not be acknowledged.
      This non-response is essential to prevent endless loops in the
      negotiation.  It is required that a response be sent to requests
      for a change of mode -- even if the mode is not changed.

The last sentence seems to contradict the remainder of the paragaph. The 1st
line says "If the requested mode is already present, do not send an
acknowledgement", but the last sentence says "an acknowledgement should be
sent EVEN if the mode is not changed".

Could someone explain this ambiguity??


------------------------------------------------------------------------------
	Mark Andrews
	Systems Programmer,
	Alias Research,
	Toronto, Canada
Phone:	(416)-362-9181
UUCP:	mark%alias@csri.utoronto.ca OR alias!mark@csri.utoronto.ca

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 89 22:25:39 GMT
From:      mcgrath@paris.Berkeley.EDU (Roland McGrath)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: What is INADDR_LOOPBACK for in sockets?

INADDR_LOOPBACK is 0x7f000001, Internet address 127.0.0.1, usually called
`localhost'.  Talking to this address gets you back to where you started from,
without going through the network hardware.
--
	Roland McGrath
	Free Software Foundation, Inc.
roland@ai.mit.edu, uunet!ai.mit.edu!roland

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 89 22:37:00 GMT
From:      MALCOM@SN01.SNCC.LSU.EDU (Malcom McNaylor)
To:        comp.protocols.tcp-ip
Subject:   MULTINET information

I need a vendor contact for MULTINET software.  Can you help me?

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 89 23:27:14 GMT
From:      zweig@brutus.cs.uiuc.edu (Johnny Zweig)
To:        comp.protocols.tcp-ip
Subject:   RFC793 pages 23 and 61

I just realized that RFC793 says to go from CLOSE-WAIT to LAST-ACK state
on page 23, and this would appear to be the Right Thing (no need to enter
CLOSING and thus TIME-WAIT since the other end's FIN is acked by this end's
FIN).  However, on page 61 it says to enter CLOSING state.

Which page is in error?

(Please no flames for having implemented my TCP directly out of RFC793 and
never looking at how UNIX does it or anything -- I've heard it before.)

-Johnny TCP

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 89 23:53:55 GMT
From:      barmar@think.com
To:        comp.protocols.tcp-ip
Subject:   Re: RFC793 pages 23 and 61

In article <1989Dec1.232714.23698@brutus.cs.uiuc.edu> zweig@cs.uiuc.edu writes:
>Which page is in error?

Page 61 is wrong.  See p.93 of RFC1122, section 4.2.2.20.(a).  If you're
implementing a TCP you should read all of section 4.2.2 of RFC1122,
"Requirements for Internet Hosts -- Communications Layers", which documents
a number of errors in RFC793.  In fact, you should read this entire
document (as well as its companion, RFC1123, which documents the
application layer and support protocols).
Barry Margolin, Thinking Machines Corp.

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

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 89 23:58:12 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: Ye Old Discard Protocol (WKS == 9)


  As an expansion and follow up of my mention of "multicast" is my last
note, I offer the following:

  I request that companies who currently use ``Broadcasted License
Numbers'' (BLN) as a product copy protection scheme, use a multicast
address instead of the broadcast address.

  The merits or demerits of doing license checking are somewhat
political.  The obnoxiousness of interrupting every other host on the
network regardless of manufacture just to check one manufacturer's
license is untenable and unjustifiable.

  I would suggest either registering a special multicast address for each
company's product or better yet, register a general ``License Multicast
Address'' (LMA) that all companies could use for such purposes.  That
would encourage all companies interested in doing BLN to do it with the
LMA.  The fact that all these companies' products would be interrupting
each other left and right can only be counted as a feature ...  Perhaps
the resulting slowness of such products would form a market force that
would select for products that concentrated their anti-copying efforts on
quality of product and service rather that algorithmic means.

  Perhaps we could even get this into the Host Requirements RFC as an
addendum ... :-)

Casey

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 89 00:48:17 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: Ye Old Discard Protocol (WKS == 9)


  This from an unnamed source since I don't know if s/he wants to be
credited/blamed:

| Why not build a "discard server" which listens for broadcast discard
| packets of that form and reflects them back at the discard port of the
| sender, thus causing a license collision, disabling the product....
| 
| Needless to say, you only want one of these on a network :-) 

  Hee hee.  I really like this idea.  I'd get in all sorts of trouble,
but it would almost be worth it ... :-)

  Obviously any such Anti-License Server would have to be programmed to
handle all the other similar schemes running around ...  (For example
SCO's XENIX TCP/IP runtime broadcasts packets to UDP port 60000 every
thirty seconds. (And yes, we've complained that 60000 isn't registered.
They should obviously use the [currently nonexistant] License Multicast
Address (LMA) to UDP port 9.))

Casey

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 89 03:48:29 GMT
From:      yhe@zippy.eecs.umich.edu (Youda He)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP IP vendor selection

In article <8912011712.AA03174@hp-ses.sde.hp.com> wunder@HP-SES.SDE.HP.COM (Walter Underwood) writes:
>
>   The Distributed Command and Control project (DC2) at
>   NOSC is an attempt to bring Naval command and control
>   systems into the networking arena by frontending them
>   with PC-ATs.
>
>Sounds like you are trying to put a multi-tasking application on a
>single-tasking box.  Though you can write it, NONE of the support
>software will have been extensively tested for multi-tasking.  Have
>you thought about dumping MS-DOS and getting multitasking systems
>with TCP/IP?
>
>Some ideas:
>
>  cheap Unix workstations (HP has one under $5000)
>  Unix on PCs
>  HP1000
>  68000 cards with VxWorks ROM-able OS (Mizar sells these)
>
>The VxWorks stuff looks particularly interesting.  Though I haven't
>used it, I've heard some good reports.
>
>wunder

Have you thought about QNX? it should run on XT, AT and 386 box, multitask,
I don't think they use TCP/IP, PC-AT  is not a single task box, MSDOS is.
We  are thinking of make control, data collection, and configuration on this
network, We haven't start it yet, but decided to go with QNX, if
some one have experience on QNx, we would link share some.


youda he








































...

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 89 07:23:00 GMT
From:      adelman@TGV.COM (Kenneth Adelman)
To:        comp.protocols.tcp-ip
Subject:   Re: MULTINET

> I'm trying to find a vendor contact for MULTINET.  Address or phone number
> would be helpful.  Thanks

    TGV, Incorporated
    15139 Old Ranch Road
    Los Gatos, CA 95030
    (408) 353-3939

    -or-

    Desiree Champagne
    SRI International
    (415) 859-6083
    <Desiree@Warbucks.AI.SRI.COM>

						    Kenneth Adelman
						    TGV, Incorporated

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 89 15:15:27 GMT
From:      housel@en.ecn.purdue.edu (Peter S. Housel)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: What is INADDR_LOOPBACK for in sockets?

In article <MCGRATH.89Dec1142539@paris.Berkeley.EDU>, mcgrath@paris (Roland McGrath) writes:
>INADDR_LOOPBACK is 0x7f000001, Internet address 127.0.0.1, usually called
>`localhost'.  Talking to this address gets you back to where you started from,
>without going through the network hardware.

	The nifty thing is that (on many systems with BSD-derived
networking) you can disable the loopback-net, through which address
127.0.0.1 is routed. Running "ifconfig lo0 down" will disable the
"loopback interface" and the machine will be unable to talk to itself.

	We once had cause to do this. Due to some kernel bug, packets
were occasionally getting stuck in loops within the loopback. The
system would get very sluggish, forwarding packets in tight little
circles.  Until the problem was fixed we just disabled the "interface"
for 30 seconds or so until the offending packet timed out.

-Peter S. Housel-	housel@ecn.purdue.edu		...!pur-ee!housel

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 89 18:10:46 GMT
From:      koreth@panarthea.ebay.sun.com (Steven Grimm)
To:        comp.protocols.tcp-ip
Subject:   Re: Question about telnet RFC

In article <662@alias.UUCP> mark@alias.UUCP (Mark Andrews) writes:
>The 1st line says "If the requested mode is already present, do not send an
>acknowledgement", but the last sentence says "an acknowledgement should be
>sent EVEN if the mode is not changed".

I take this to mean, "If you're already in the requested mode, don't send
an acknowledgement.  Otherwise, send an acknowledgement whether you change
to the requested mode or not."  Anyone know any differently?

---
"                                                  !" - Marcel Marceau
Steven Grimm		Moderator, comp.{sources,binaries}.atari.st
sgrimm@sun.com		...!sun!sgrimm

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 89 20:53:34 GMT
From:      manoj@excelan.COM (manoj @ NOVELL )
To:        comp.protocols.tcp-ip
Subject:   Re: TCP IP vendor selection

In article <1711@cod.NOSC.MIL>, neerma@cod.NOSC.MIL (Merle A. Neer) writes:

> The vendors examined during this study: Network
> Research FUSION, Exelan, CMC and FTP Software.
> 
> We have reached a point of frustration.  Our current
> strategy is to: 
1. wait for CMC to fix a bug in their > ROM for their ether card (since the rest of their stuff > looks o.k. so far, 
2. look at the public domain KA9Q > (advantage: sources), 
3. wait for FTP Software to fix > their socket library 
4. look at Woolongong (havent tried > them yet) 
5. write our own?

What were the problems with the Excelan software?

Regards!
	                                 		+---+
	manoj goel, (408) 473-8369 			| +-+-+
	Product Marketing              			+-+-+ |
        Excelan/Novell, San Jose, CA 		 	  +---+
___________________________________________________________________________
		When all else fails, read the instructions!
	                                 		+---+
	manoj goel,                                  	| +-+-+
	Product Marketing              			+-+-+ |
        Excelan/Novell, San Jose, CA 		 	  +---+
	(408) 473-8369 (voice) / 433-0775 (fax)	
___________________________________________________________________________
		When all else fails, read the instructions!

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 89 22:49:45 GMT
From:      brnstnd@stealth.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Traffic Sensitive SPF Routing is NOT too hard!

In article <6203@cbnewsh.ATT.COM> tds@cbnewsh.ATT.COM (antonio.desimone) writes:
> An apparent difference
> is that routing in datagram networks can (in principle) react to
> congestion on the timescales on which queues build up.

Since when? I don't know of any methods of controlling flapping and
instability in principle. When the Internet is highly loaded it shows
that dynamic routing fails in practice as well.

There's absolutely no reason not to use a Bayesian or maximum-entropy
calculation of the minimal-cost distribution of paths for a given
distribution of load. Maximum-entropy routing yields the efficiency of
dynamic routing without the instability of dynamic routing. If you're
paranoid, recalculate paths every week instead of every month.

---Dan

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Sun, 3 Dec 89 02:54:04 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Why do TCP connections hang?

In article <8911301020.AA14662@hayes.fai.alaska.edu> wisner@hayes.fai.alaska.edu (Bill Wisner) writes:
>The hung connections seem to be data-specific. If I try transferring the
>same file twice, both FTP connections are likely to hang at the same
>point in the file. As an exercise, I took a file and split it into several
>small chunks, then tried transferring it. The connection still hung at the
>same point in the fragmented file.

You should probably pursue this further to pin down the exact data pattern
that causes the problem.  This might yield some insight.
-- 
Mars can wait:  we've barely   |     Henry Spencer at U of Toronto Zoology
started exploring the Moon.    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 89 14:03:19 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   550 tcp-ip@nic.ddn.mil... Host unknown

This does seem a bit wierd.  I have been getting the above error message when
replying to mail items.  Using nslookup I definitely get authoritative responses
for nic.ddn.mil.

Merton

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 89 14:49:50 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Strange Behaviour

Has anyone noticed any strange behaviour when attempting to mail to nic.ddn.mil?
I am using Berkeley's latest (?) sendmail.  I first noticed the problem on
Saturday, 02 DEC 89, when I replied to a mail item received from tcp-ip.  I
got the message bounced with a host unknown error.  I attempted to resubmit
the mail item by using the following commands:

	m tcp-ip@nic.ddn.mil
	~f				Retrieve the "bounced" mail item
	~e				Edit out the old mail header
	.				Send the mail item

Received another host unknown error.

Attempted to send another message using the following commands:

	mail -v tcp-ip@nic.ddn.mil

with cc: to sms@lonex.radc.af.mil.  Message was first sent to RADC and then
to NIC.  After the connection to NIC was closed, the following was displayed
on the terminal

	>/etc/. permission denied

Any thoughts?

Merton

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 89 14:58:30 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Question about telnet RFC


	From MAILER-DAEMON Sat Dec  2 20:19:01 1989
	Received: by WLV.IMSD.CONTEL.COM (5.61/1.25)
		id AA02126; Sat, 2 Dec 89 20:18:40 -0800
	Date: Sat, 2 Dec 89 20:18:40 -0800
	From: MAILER-DAEMON (Mail Delivery Subsystem)
	Subject: Returned mail: Host unknown
	Message-Id: <8912030418.AA02126@WLV.IMSD.CONTEL.COM>
	To: mcc
	Status: RO
	
	   ----- Transcript of session follows -----
	550 tcp-ip@nic.ddn.mil... Host unknown
	
	   ----- Unsent message follows -----
	Received: by WLV.IMSD.CONTEL.COM (5.61/1.25)
		id AA02124; Sat, 2 Dec 89 20:18:40 -0800
	Date: Sat, 2 Dec 89 20:18:40 -0800
	From: mcc (Merton Campbell Crockett)
	Message-Id: <8912030418.AA02124@WLV.IMSD.CONTEL.COM>
	To: swrinde!cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!utzoo!censor!geac!alias!mark@ucsd.edu,
	        tcp-ip@nic.ddn.mil
	Subject: Re:  Question about telnet RFC
	
	Seems clear enough to me.  You receive a request to enter a state or mode from
	the remote station.  If you are currently in the requested state or mode, do
	nothing.  If you are not in the requested state or mode, you MUST send a re-
	sponse eiher to accept the new state or mode or to refuse the change.
	
	Merton
	

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 89 19:05:48 GMT
From:      anoop@WSU-ENG.ENG.WAYNE.EDU (Anoop K. Verma)
To:        comp.protocols.tcp-ip
Subject:   new subscription

Hi...
     I am working in the networking group of the Engineering Computer Center
of Wayne State University and I would like to be put on the mailing list of
the tcp-ip group for mail regarding relevant subjects.
     Please inform me as to what will I have to do for that and put me on the
mailing list.
   			ANOOP
_______________________________________________________________________________
 		anoop@wsu-eng.eng.wayne.edu
_______________________________________________________________________________

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 89 21:34:45 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re: Ye Old Discard Protocol (WKS == 9)

Some time soon we will begin charging for network traffic.  It would
seem only fair to pass the charges on to the vendors for these nefarious
packets.  And, the packets are already labeled to boot!  Let's see,
1 cent a packet times 1000 hosts that receive the junk packet. That's 10 
bucks per "protected" copy for a oneshot.  Now, let's assume that 100
persons were foolish enough to buy this protected product. That's one
thousand bucks a day.  Now finally, let's assume that these products 
ship this periodically just to make sure no one is stealing their product.
(Of course this only works on a single, link level network, IP defeats
the protection scheme.)  How about once every minute to be really safe.
That comes to hmmm let's see 60 minutes in an hour, 24 hours in a day...
Could that be One million four hundred and forty thousand dollars charged
to the vendor per day for 100 copies of their software at just one site?
Hmmm, What does that come to a year?  And how many copies of PC-NFS are
there out there?

Phil Wood,  cpw@lanl.gov

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 89 02:50:44 GMT
From:      swb@DAINICHI.TN.CORNELL.EDU (Scott Brim)
To:        comp.protocols.tcp-ip
Subject:   Re: What is INADDR_LOOPBACK for in sockets?


   >Date: 2 Dec 89 15:15:27 GMT
   >From: ea.ecn.purdue.edu!housel@ee.ecn.purdue.edu  (Peter S. Housel)
   >Subject: Re: What is INADDR_LOOPBACK for in sockets?
   >To: tcp-ip@nic.ddn.mil
   >
   >	The nifty thing is that (on many systems with BSD-derived
   >networking) you can disable the loopback-net, through which address
   >127.0.0.1 is routed. Running "ifconfig lo0 down" will disable the
   >"loopback interface" and the machine will be unable to talk to itself.

I can't resist adding that you have to be careful, though, of
situations where you lose a route to 127.0.0.1 but you have a
"default" route floating around your net.  For example, I used to see
not infrequent situations where a BSD Unix-based router would be
generating a "default" route -- say because it was EGPing with a
backbone -- and on a broken system further away from the backbone,
sendmail would try to connect to 127.0.0.1, and would end up following
the default route and accidentally connecting to the
default-generating machine (which knew where "127.0.0.1" was --
itself!), so that all mail from the broken one would appear to be from
the correct userid but the incorrect system (the default-generating
one).
							Scott

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 1989 12:54-PST
From:      Steve Deering <deering@pescadero.stanford.edu>
To:        Craig Partridge <craig@NNSC.NSF.NET>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: more on Fletcher
Craig,

I don't know how serious your proposal for a TCP Alternate Checksum
Option is, but I would hope that any real proposal would allow for:

	- a checksum longer than 16 bits (for more robust error detection)
	- a checksum at the end of the packet (for pipelined interfaces)

If it is important to maintain the current size of the TCP header, it
might be reasonable to say that checksums longer than 16 bits *have* to
go at the end of the packet.

Steve
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 89 05:30:24 GMT
From:      kaps@orange.ucsb.edu (Vikas Kapur)
To:        comp.protocols.tcp-ip
Subject:   Broadcast problems

I'm posting this for a friend who has no current net
access. Your help would be *very* much appreciated - he has had
no luck so far. Please reply to the address listed in the 
header. Like I said this is a *long* posting..source code
included...

^L

<* He has been trying to broadcast to 5 networked Sun 
workstations on a dedicated Ethernet *>

	I tried several variations to the basic approach outlined in
the Sun-3 IPC Manual. The basic problem is to get the correct
internet address corresponding to a broadcast, for which the
following call is suggested :

struct in_addr inet_makeaddr(net,bcast_lna)
int net, bcast_lna;

where net= the network number of the net on which the broadcast
				 is required, and
		bcast_lna= INADDR_ANY ( I also tried INADDR_BCAST ), specifies
				 the host_addr (last byte of the internet address).

One would thus expect, for a host with, for instance, the address :
"128.111.63.26" that the broadcast address on the same network
would be (either "128.111.63.0" - using INADDR_ANY, as suggested by the
IPC documentation from Sun, or) "128.111.63.255" using INADDR_BCAST.
It turns out that variations of this call (see inet(3) of manual pages),
give vastly differing return values, from "128.111.255.255" to
"255.255.255.255" (whih happens to be the *physical* ethernet 
broadcast address (4 bytes, all 1's).

Incidentally, there's a call for converting inet_addresses to the
form "a.b.c.d" : inet_ntoa() , which I used to look at the values
returned by the inet_makeaddr() and other call that I used
(viz., inet_addr()).

However, not one of these variations seemed to work. In fact,
the sendto() call using the address returned as above always
returned without error, but none of the processes doing a
receivefrom() on the appropriate UDP-port on any of the machines
on the network ever received the "broadcast". In the absence of
a LANalyser to monitor the packets appearing on the network, it's
difficult to say whether the broadcast didnot happen (error at the
sender), or the broadcast happened but was not received by any of
the machines (error at the receiver(s)). (P.S. - In all cases
the UDP-port of the sending machine & receiving machines were
also the same.)

A simple pair of test routines for 
the sending party & receiving parties is listed hereunder :

/*----------------------------------------------------------------*/
/* COMMON CODE */


#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#include <netdb.h>
#include <errno.h>

#define SERVENT		struct servent
#define HOSTENT		struct hostent
#define INET_ADDR	struct sockaddr_in

#define MAX_HOST_NAMELEN		128
#define MAX_TRY	30
#define MAX_MSG	100
#define SLEEP_INT	2

char MY_HOST_NAME[MAX_HOST_NAMELEN];
INET_ADDR MY_ADDR;
int MY_SOCK;

phys_init()
{
	SERVENT *srv_ent;
	HOSTENT *hst_ent;
	int on=1;

	MY_ADDR.sin_family=AF_INET;	/* my address family */
	if((srv_ent=getservbyname("TRANS_SERVER","udp"))==(SERVENT *)0)
		err_exit(-1,"Unable to find TRANS_SERVER's port number\n");
	MY_ADDR.sin_port=srv_ent->s_port;	/* get the server's port # */
	gethostname(MY_HOST_NAME,MAX_HOST_NAMELEN); /* get my host's name */
	if((hst_ent=gethostbyname(MY_HOST_NAME))==(HOSTENT *)0)
		err_exit(-2,"Can't find my host entry\n");
	bcopy(hst_ent->h_addr,&MY_ADDR.sin_addr,hst_ent->h_length);
		/* get my internet address */

	if((MY_SOCK=socket(PF_INET,SOCK_DGRAM,0))<0)
		err_exit(-3,"Can't open datagram socket\n");
	if(setsockopt(MY_SOCK,SOL_SOCKET,SO_BROADCAST,&on,sizeof(on))<0)
		err_exit(-1,"Can't set broadcast option on socket\n");
	/*	set broadcasting option on socket	*/
	if(bind(MY_SOCK,&MY_ADDR,sizeof(INET_ADDR))<0)
		err_exit(-1,"Error in binding name to socket\n");
		/* bind  my full internet address (including port number) to socket */

	return;
}


send_bcast()
{
	INET_ADDR BCAST_ADDR;
	struct in_addr bcast_addr;
	int i,size,nbytes;
	char *msg="Did you get this broadcast message\n";

	BCAST_ADDR.sin_family=AF_INET;
	BCAST_ADDR.sin_port=MY_ADDR.sin_port;
	bcast_addr=inet_makeaddr(inet_netof(MY_ADDR.sin_addr),INADDR_BROADCAST);
	printf("The broadcast address is %s",inet_ntoa(bcast_addr));
	bcopy(&bcast_addr,&BCAST_ADDR.sin_addr,sizeof(struct in_addr));
		/* form the broadcast socket address, preparatory to sending */

	size=strlen(msg);
	for(i=0;i<MAX_TRY;i++){
		if(sendto(MY_SOCK,msg,size,0,&BCAST_ADDR,sizeof(INET_ADDR))!=size)
			err_exit(-1,"Error in sending broadcast\n");
		delay();
	}
	printf("%d broadcast transmissions made\n", MAX_TRY);
	return;
}


recv_msg()
{
	char msgbuf[MAX_MSG];
	INET_ADDR src_addr;
	int size,nbytes;

	size=sizeof(INET_ADDR);
	if((nbytes=recvfrom(MY_SOCK,msgbuf,MAX_MSG,0,&src_addr,&size))<0)
		err_exit(-1,"Error in receive\n");
	printf("%d byte message received : %s\n",nbytes,msgbuf);
	return;
}


delay()
{
	sleep(SLEEP_INT);
	return;
}


err_exit(err,msg)
int err;
char *msg;
{
	perror("");
	printf("\nErr %d : %s",err,msg);
	exit(err);
}
/* end of common code */
/*---------------------------------------------------------------------*/

/*	This is the BROADCASTER's code */

#ifdef BROADCASTER

main()
{
	phys_init();
	send_bcast();
	exit(0);
}

#endif	BROADCASTER

/* end of Broadcaster's code */
/*---------------------------------------------------------------------*/

/* This is the RECEIVERS' code */


#ifdef RECEIVER

main()
{
	phys_init();
	recv_msg();
	exit(0);
}

#endif RECEIVER

/* end of receivers' code */
/*---------------------------------------------------------------------*/


You will notice that the "broadcast address" that the above inet_makeaddr
call returns is simply the machine internet address with the last two
bytes replaced by 255.255 (which is obviously wrong). I also
tried the inet_addr() call and directly passed to it "a.b.c.255",
but even that doesnot work.

Any advice or help that you can offer will be highly appreciated.

________________________________________________________________________

Vikas Kapur 

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 89 05:39:18 GMT
From:      warner@twg.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: Ye Old Discard Protocol (WKS == 9)

In article <40184@lll-winken.LLNL.GOV> casey@gauss.llnl.gov (Casey Leedom) writes:
>  Perhaps we could even get this into the Host Requirements RFC as an
>addendum ... :-)

Better yet, we should make the practice a MUST NOT in the Host
Requirements RFC.  It is totally bogus and doesn't buy the company
that is doing the copy protection anything.

Don't broadcast packets cause ARP wars anyway?  At least on networks
that have older networking software?  I'd hate to see a ARP war (aka
net meltdown) that could be traced to this practice.  Denial of
service law suits can be expensive.....

Warner Losh
warner@twg.com
These are my own opinions.
-- 
-- 
Warner Losh	warner@twg.com (formerly warner@hydrovax.nmt.edu)
Is this nightmare black, or are the windows painted?
My views and spelling are my own.  Only the letters have been changed.

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 89 14:13:07 GMT
From:      barns@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re:  RFC793 pages 23 and 61

Short answer: Page 23 is correct; page 61 is in error.  See RFC 1122,
section 4.2.2.20 (a), bottom of page 93.

General comment: (I had been thinking that "they" [or "we"] had been
a bit neglectful in not making a specific publication announcement
in the TCP-IP mailing list/newsgroup.  The relative absence of relevant
mail led me to think that maybe I was wrong.  Now I think maybe my
first impression was more correct.  So, here goes:)

The answers for this question and many others like it can be found in
the "Host Requirements RFCs".  There are three documents in this set.
RFC 1122 provides standards updates and guidance to implementors for
TCP, IP, and (to a limited extent) lower layers.  RFC 1123 provides
similar material for TCP applications (TELNET, FTP, TFTP, SMTP/RFC822,
DNS, and management/support services).  RFC 1127 provides some
background discussion on the documents, including a list of unfinished
business.  RFC 1122 and RFC 1123 are "mandatory"; RFC 1127 is just
informational and contains no specific technical direction.

Everyone who ever does anything requiring knowledge of what is
happening (or ought to be happening) inside implementations of the
"TCP/IP suite" ought to browse through these documents at least once,
and keep a copy nearby for reference.  This is especially true for
implementors, but it also holds for people who do troubleshooting,
design new software that interfaces to these protocols, or prepare
specifications for procurement.  They also have some educational merit;
I think it's probably accurate to say that most (if not all) of those
who took part in writing these documents learned some new and grotesque
tales of perverse misinterpretations of the specifications, botched
implementations, or bizarre failure modes.  If you find such things
amusing, read between the lines of these documents and your day will
be filled with hilarity.

Caveat: Yes, I was responsible for (or irresponsible for) a few words
in those RFCs.  I wasn't a chief guru, but maybe occasionally an
assistant guru, and often a conspicuous presence in the peanut gallery.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 89 16:45:22 GMT
From:      dab@OPUS.CRAY.COM (Dave Borman)
To:        comp.protocols.tcp-ip
Subject:   Re:  Question about telnet RFC

> I am reading over RFC854, the telnet protocol specification and have come
> upon a confusing paragraph. This excerpt is from from section 3b of
> GENERAL CONSIDERATIONS:
> 
>       b. If a party receives what appears to be a request to enter some
>       mode it is already in, the request should not be acknowledged.
>       This non-response is essential to prevent endless loops in the
>       negotiation.  It is required that a response be sent to requests
>       for a change of mode -- even if the mode is not changed.
> 
> The last sentence seems to contradict the remainder of the paragaph. The 1st
> line says "If the requested mode is already present, do not send an
> acknowledgement", but the last sentence says "an acknowledgement should be
> sent EVEN if the mode is not changed".
> 
> Could someone explain this ambiguity??
> 
> 	Mark Andrews

If you receive a request for a state that you are in, you don't reply.
If you receive a request for a state that you are not in, you MUST
reply, and that reply may either be to aggree or disagree with the
requested state.

	If you are WILL(DO/WONT/DONT) OPT, and you receive
	DO(WILL/DONT/WONT) OPT, you do nothing, because you
	are already in the requested state.

	If you are WONT(DONT) OPT, and you receive DO(WILL) OPT,
	you MUST respond with either WILL(DO) OPT (to acknowledge
	that you will go to the requested state) or WONT(DONT) OPT
	(to refuse to go into the requested state)

	If you are WILL(DO) OPT, and you receive DONT(WONT) OPT,
	you MUST respond with WONT(DONT) OPT, and turn off the
	option.

The unclear point about option negotiation is when one sends a
request to enable and option, and a refusal comes back (i.e., if
I send DO OPT and get back a WONT OPT).  Do I then respond with
a DONT OPT, or do I just end the negotiation there?  It can be
argued both ways.  If my state changed when I sent DO OPT, then
it seems reasonable that I should send a DONT OPT if I receive
a WONT OPT, to confirm that I have disabled the option.  But if
I don't change my state until I get the WILL OPT, then I it seems
reasonable that I do NOT send the DONT OPT, since that is what
state we are already in.

As it turns out, from the view of the protocol, when you are doing
proper option negotiation, both cases will work just fine, and
neither side of the connection should have any dependencies on
it happening one way or the other.

			-Dave Borman
			dab@cray.com

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 89 16:55:12 GMT
From:      snoopy@ixos.UUCP (Snoopy Schmitz)
To:        comp.unix.questions,comp.unix.wizards,comp.protocols.tcp-ip,comp.periphs
Subject:   WANTED: IBM SNA <-> UNIX Connection

Dear Net,

we are looking for ways to connect UNIX machines to "the IBM world".
That is something for UNIX that will plug into SNA etc. This something
should preferably be software perhaps also some hardware. 

Are there any products you can recommend ? 

I guess one idea is to use NFS and AIX, or PC-NFS on Mush-DOS but what I 
really need is link (channel) to IBMs big iron under VM etc.

Please reply by e-mail - I will gladly post a summary in this newsgroup
when I have enough and if enough people are interested.

Thanks a million,
Love,
Snoopy
-- 
uunet!unido!ixos!snoopy -or- snoopy@ixos.uucp
"Every passing hour brings the solar system 43,000 miles closer to globular
cluster M13 in Hercules - and still there are some misfits who insist that
there is no such thing as progress." - Kurt Vonnegut Jr.

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 89 17:21:53 GMT
From:      sean@dranet.dra.com
To:        comp.protocols.tcp-ip
Subject:   Re: Z39.50 (Search and Retrieval) over TCP/IP

In article <592.25694930@dranet.dra.com>, sean@dranet.dra.com writes:
> Anyone have the Z39.50 protocol running on top of TCP/IP?

I've gotten several replies to my query, and a lot of "me too's".  I'll
post a summary once I'm able to contact and verify the various places that
were reported to be working on this protocol.  I have the names of four
projects, now I'm trying to figure out how to contact them.

Also the Fall 1989 issue of EDUCOM Review has an article on the protocol.

I've replied to all the messages I received.  If you sent me something
and didn't get a reply either something munched your message, or muched
my reply (though none "bounced.")

Thanks
-- 
Sean Donelan, Data Research Associates, 1276 North Warson, St. Louis, MO 63132
Domain: sean@dranet.dra.com, Voice: (Work) +1 314-432-1100, 800-325-0888

  Affiliation given for purposes of identification, not representation

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 89 18:12:39 GMT
From:      tds@cbnewsh.ATT.COM (antonio.desimone)
To:        comp.protocols.tcp-ip
Subject:   Re: Traffic Sensitive SPF Routing is NOT too hard!

From article <4118@sbcs.sunysb.edu>, by brnstnd@stealth.acf.nyu.edu (Dan Bernstein):
> In article <6203@cbnewsh.ATT.COM> tds@cbnewsh.ATT.COM (antonio.desimone) writes:
>> An apparent difference
>> is that routing in datagram networks can (in principle) react to
>> congestion on the timescales on which queues build up.
> 
> Since when? I don't know of any methods of controlling flapping and
> instability in principle. When the Internet is highly loaded it shows
> that dynamic routing fails in practice as well.

I'm with you Dan!  You're making exactly the same point I tried to
make later in my posting (did you get there? :-).

> There's absolutely no reason not to use a Bayesian or maximum-entropy
                     ^^^^^^^^^ including being able to calculate routes
                               in a human lifetime?
> calculation of the minimal-cost distribution of paths for a given
> distribution of load. Maximum-entropy routing yields the efficiency of
> dynamic routing without the instability of dynamic routing. If you're
> paranoid, recalculate paths every week instead of every month.
> 
> ---Dan
This is a little too heavy on the jargon for me.  Are you suggesting
a single optimal route?  Or some kind of table-driven routing with
tables calculated in advance?  That's a fine idea (in principle:-) and
has been used in the phone system (*that* again) quite successfully.
It is by no means obvious or trivial to build routing tables, however!
And if "Maximum-entropy routing" means some kind of global optimization
over the space of possible tables, the method does not scale to a large
network.  If it means something more specific, maybe you could send me
(or post) a reference? 
-- 
Tony DeSimone
AT&T Bell Laboratories
Holmdel, NJ 07733
att!tds386e!tds

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 89 18:51:22 GMT
From:      paul@sdgsun.COM (Paul Emerson)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   lpd Protocol Specs

Does anyone know/have the protocol specs for the BSD lpd protocol?  I haven't
seen an RFC on this does it exist? I would like to write an lpd for use 
on a SYSV machine.  I currently have a TCP/IP based remote printing 
application but I would like to use the BSD protocol. 

And yes I konw that "/usr/ucb/rsh remotehost lpr < file" will do the trick,
that is not my interest.

Paul
---
-- 
Paul J. Emerson                           Software Design Group, Inc.  
Senior Technical Manager                  450 Lakemont Ave.
UUCP:{ucf-cs|uflorida}!sdgsun!paul        Winter Park, FL 32792
CIS: 72355,171                            (407) 657-1300

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 89 18:59:28 GMT
From:      chris@sparta.UUCP (Chris Chiotasso)
To:        comp.protocols.tcp-ip
Subject:   SNMP


I have the CMU public domain code and am porting it.  There is an
address in the documentation to direct questions to.  The address
given is:  sw01+snmp@andrew.cmu.edu.  I have tried this address in
many different forms (eg. sw01 as #1 and letter l, snmp only etc)
and have had them all returned to me.  Does anyone have the correct
address and/or an answer to the following question.

I read the code and found that the object id's are encoded with the
first 2 subids in a single subid field using (x*40)+y x=1st subid
and y=2nd subid.

I have also read the RFC's and have not found any reference to this.
Am I missing something?  Why are the first 2 ids combined?

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 89 20:54:00 GMT
From:      deering@PESCADERO.STANFORD.EDU (Steve Deering)
To:        comp.protocols.tcp-ip
Subject:   Re: more on Fletcher

Craig,

I don't know how serious your proposal for a TCP Alternate Checksum
Option is, but I would hope that any real proposal would allow for:

	- a checksum longer than 16 bits (for more robust error detection)
	- a checksum at the end of the packet (for pipelined interfaces)

If it is important to maintain the current size of the TCP header, it
might be reasonable to say that checksums longer than 16 bits *have* to
go at the end of the packet.

Steve

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 89 01:50:43 GMT
From:      schoff@PSIPOST.PSI.COM (Martin Lee Schoffstall)
To:        comp.protocols.tcp-ip
Subject:   Re:  CapNet

Woody,

For informatio on CAPNet send email to info@psipost.psi.com

Marty

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 89 04:42:54 GMT
From:      david@ms.uky.edu (David Herron -- One of the vertebrae)
To:        comp.protocols.tcp-ip,comp.sys.pyramid
Subject:   Re: Network Configuration Difficulties

In article <401@massey.ac.nz> GEustace@massey.ac.nz (Glen Eustace) writes:
>Please excuse my ignorance, but we have been unable to work out how to
>set things up. We have got D.Comer's book on networking and it didn't
>help.

That's a shame since it's such a good book.  I did find it was helpful
to be comparing between the book & source code & RFC's ... made my
comprehenshion much better ..

Anyway, here's what I've either done or understand will work.  This is
a bit difficult since you don't describe what your problem is, only what
your desired goal is.


First, you want to be running with submasks everywhere, apparently
at the 8-bit boundry (from your numbers).  An example which will set
that using BSD derived software is

	ifconfig <device> 130.123.<n>.<h> netmask 255.255.255.0 -trailers up arp
	route add net 130.123.<n> 130.123.<n>.<h> 0

Which first sets up the device and second sets up a route for that network.
(The "route add net" may be optional, I wouldn't be surprised if it were.)
It's instructional to look at "ifconfig" and "netstat -r" output to
see the different settings..


>We want to be able to run 10 SLIP lines from the Pyramid, interfaces sl0-sl9

You want to set up routes to both the 'network' and the host on the
other end of the SLIP link.  This is true for all point-point network links.
Example

	ifconfig sl0 130.123.1.1 netmask 255.255.255.0 -trailers up
	route add net 130.123.1.0 0
	route add host 130.123.1.1 0
	route add host 130.123.1.2 1

e.g. specify route to the network, then to each end of the network.

Again, the first "route add host" may be superfluous ...  The metrics
may be off ... finally, this is probably all embedded within the
system software which handles SLIP lines.  For instance, on Ultrix
most of that is embedded in /etc/sliphosts.  The explicitness of
the "route add net" command is necessary, at least some versions of
route will see the class B address "130.123.1" and assume the
poor luser is really meaning the host "130.123.0.1" ...

Hopefully the SLIP on Pyramids works better than the one in Ultrix.
In Ultrix you cannot run >1 SLIP interface, rather you can't on
either v3.0 or v3.1, haven't tried since then.  (Pardon me if I
have version numbers wrong ... I mean v3.0 and then the next pseudo-
major release, has there been one since then?)

Aside:  Think about implementing the subnet mask for your SLIP links a
little bit differently.  Instead of using netmasks at an 8-bit
boundry (which gives you a 256 host subnet of which you're only
using 2 hosts, 99% wastage there!) use a 2-bit host-part for the SLIP
networks.  This gives you "<net>.0" to refer to the net, "<net>.3"
to refer to the broadcast address on the net and "<net>.1" and
"<net>.2" to refer to each end of the net.  No wastage.


>We have two ethernet controllers but currently are only using one.

This is simply a matter of ifconfig'ing the device then route-add'ing
routes as above.

In your example picture I read it to say you wanted multiple subnets
on one physical wire.  That's a little strange and the guys over at
Rutgers say to only do that rarely, but if you must:

	ifconfig <interface> 130.123.3.1 netmask ...
	route add net 130.123.3.0 130.123.3.1 0
	route add net 130.123.4.0 130.123.3.1 1
	route add net 130.123.5.0 130.123.3.1 1

That is, for the "other" networks you pretend you're gatewaying
through yourself.


>We want to isolate each of our laboratories with a PC running PC-Route
>version 2 so that all traffic between the lab hosts and their server does
>not flood the backbone.

Good idea.  However I don't know anything about how to configure PC-Route
but it's going to be vaguely similar to the above.

An alternate, that's *far* simpler to administer, is to use a learning
bridge to isolate your networks.  The primary example of learning
bridges is DEC's LANBridge 100.  What it does is listen to the host
addresses mentioned in packets on each of its interfaces.  As it
watches packets it learns which host addresses are where and starts
being able to forward packets only when necessary.  The learning bridges
also have a spanning-tree protocol they run to map out ways through
an arbitrary net of ethernet segments connected with these things.  However,
as I understand it, there's an IEEE protocol for the spanning tree
protocol but that DEC doesn't use that protocol (because it was first
and therefore it's protocol was set in silicon?).  Possibly I'm
wrong on that last, it's something I've never bothered to track
down anyway.

Learning bridges don't provide any protocol level filtering.  Therefor
you loose whatever loose sense of security you have by being behind
a router.  You also loose some of the control you'd have behind a router.
But the things just kind of take care of themselves, y'know?



Lastly there's routing protocols to use.  Which one to use is
up to you and your local information.  All the ones which I'm
familiar with, other than the transparent arp scheme(s) described
in some RFC's in the early 900's, pass around information like

	<network> <reachability metric>

A host receiving a routing packet generally looks through its routing
table and for each network compares the metric it has with the metric
claimed by the gateway, and uses the lower of the two.

The routing protocol most used, because it's in the BSD distribution, is
RIP (Routing Information Protocol) which is embodied in /etc/routed.
It is an IGP (Interior Gateway Protocol).

routed tands to just take care of itself.  However you have to
be prepared for it to be installing all the routes your gateway
to the outside world advertises.  Here at uky.edu our machines
routinely have 500 routing table entries.  On our sequent where
each routing table entry takes up an mbuf, well, we kinda ran
out of mbufs ...

Hope this helps ...
-- 
<- David Herron; an MMDF guy                              <david@ms.uky.edu>
<- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<- 
<- New official address:  attmail!sparsdev!dsh@attunix.att.com

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 89 06:49:48 GMT
From:      smyers@ics.uci.edu (Steven A. Myers)
To:        comp.protocols.tcp-ip
Subject:   RIP documentation/implementations

I am looking for some documentation on the Routing Information
Protocol (RIP).  I have been reading the book "Internetworking with
TCP/IP" and the author suggests that the only good documentation is
the code from the program 'routed'.  Is there a public domain version
of this program available? I would also appreciate any pointers to
relevant RFC's or other publications about RIP.

Thanks for the help.

-- Steven 

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 89 09:00:43 GMT
From:      lear@genbank.BIO.NET (Eliot Lear)
To:        comp.protocols.tcp-ip, smyers@ics.uci.edu
Subject:   Re: RIP documentation/implementations

For information on RIP see RFC 1058 or the actual code.  Both the RFC
and the code are available on Internet host UUNET.UU.NET via anonymous
FTP.
-- 
Eliot Lear
[lear@net.bio.net]

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 89 10:26:57 GMT
From:      adnan@sgtech.UUCP (Adnan Yaqub)
To:        comp.protocols.tcp-ip,comp.unix.i386
Subject:   386ix's TCP (1.1.2) Doesn't Seem to Send FINs

When closing a connection which is busy sending data, Interactive's
386ix TCP (version 1.1.2) doesn't seem to send a FIN.  For example, if
I telnet into a 386ix box and start a loop echoing data and then
escape back to my telnet client and issue a disconnect, the responding
FIN from the 386ix is never sent.  I see something like this on the
network analyzer:
	386ix		telnet client		comments
	-----		-------------		--------
	data	->
		<-	ack (window = 0)	I have escaped back to client.
	data	->				This is a window probe.
		<-	ack, FIN		I disconnect.
	ack	->				My FIN is acked.
	data	->				Last gasp of data.
		<-	ack			I ack it, no more traffic.

Now, this seems to me to be a bug in the 386ix TCP/IP code.  Any
ideas?

A related topic is how should TCP recover from this situation.  The
specification says nothing about starting a timer when the FIN is
sent.  I did find this code in the Berkeley implementation:
		/*
		 * In FIN_WAIT_1 STATE in addition to the processing
		 * for the ESTABLISHED state if our FIN is now acknowledged
		 * then enter FIN_WAIT_2.
		 */
		case TCPS_FIN_WAIT_1:
			if (ourfinisacked) {
				/*
				 * If we can't receive any more
				 * data, then closing user can proceed.
				 * Starting the timer is contrary to the
				 * specification, but if we don't get a FIN
				 * we'll hang forever.
				 */
				if (so->so_state & SS_CANTRCVMORE) {
					soisdisconnected(so);
					tp->t_timer[TCPT_2MSL] = tcp_maxidle;
				}
 tp->t_state = TCPS_FIN_WAIT_2;
			}
			break;

Is this the preferred method of dealing with this problem?
--
Adnan Yaqub
Star Gate Technologies, 29300 Aurora Rd., Solon, OH, USA, +1 216 349 1860
...cwjcc!ncoast!sgtech!adnan ...uunet!abvax!sgtech!adnan

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 89 12:52:40 GMT
From:      aw0g+@ANDREW.CMU.EDU (Aaron Wohl)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP

That address is sw0l+snmp@andrew.cmu.edu

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 89 13:56:00 GMT
From:      CURT.ELLMANN@MAIL.ADMIN.WISC.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: lpd protocol

Comment: Processed by UWGATE

to: tcp-ip@nic.ddn.mil

The source for lpr and lpd is available from uunet.uu.net in
bsd-sources/src/network/lpr.tar.Z

It's a start, anyway.

By the way,  Does anyone have an lpd which runs under MS-DOS?

-curt.


                                                                               ?

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 89 14:55:11 GMT
From:      aras@dr.uucp (Arne Asplem)
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   KA9Q Makefile wanted

I have received a package with the KA9Q SLIP source code, but the
Makefile is only for the PC version. Apart from this the source code
looks complete, it includes files for both PC, SYS V and BSD etc.

> 
> #
> #	Makefile for KA9Q TCP/IP package for PC clones with Aztec C
> #		I used Aztec developer version 4.10c
>

Can anyone send a SYS V makefile with E-mail ???

And what's the lastest version of KA9Q ???

  -- Arne

/* Arne Asplem, Consultix, P.O.BOX 1367, N-1401 SKI, NORWAY
 * Phone: +47-9-876844  Fax: +47-9-876766  Pager: 096-43139
 * E-mail: aras@dr.uucp or ..!mcsun!ndosl!dr!aras
 */

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 89 15:42:23 GMT
From:      adamm@necis.UUCP (Adam Moskowitz)
To:        comp.protocols.tcp-ip,comp.unix.questions,comp.sources.wanted
Subject:   TCP/IP benchmark programs needed

I've been assigned the task of finding out just how fast the network
performance of our new boxes are and I need some software to help me do
this.

I'm looking for something that will let me blast out lots of packets of
various sizes. Being able to send packets via different protocols would
also be nice as we need to get a handle on TCP as well as UDP performance.
Something that would also let me send ill-formed packets to see that we
don't choke on such critters would also be nice. Obviously, I need source
code. Our box is a mix of System V & BSD so I'm prepared to do some
porting. I just didn't want to have to reprogram the wheel.

Does anyone out there in net.land have or know of any benchmarking programs
that will help me get these numbers? Can you send me email telling me about
them? I thought you could. :-)
--
Adam S. Moskowitz	            ...!(backbone)!{necntc,encore}!necis!adamm
                                    OR adamm@necis.nec.com

   "The second law of thermodynamics states that, left to themselves, things
   tend to go to hell in a handbasket." -- Cecil Adams (The Boston Phoenix)

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 89 18:21:15 GMT
From:      sklower@OKEEFFE.BERKELEY.EDU (Keith Sklower)
To:        comp.protocols.tcp-ip
Subject:   Re: more on Fletcher

Johnny, Steve, Craig (et al):

	This tempest in a teapot started when Johnny Zweig took a
suggestion of mine for an alternative to the checksum employed in
OSI transport and asked if it could be adapted to the TCP protocol.
(And here I'm really speaking of TCP and TP and not the lower level
headers).

	I refered to it as a ``16-bit'' version of the Fletcher
algorithm, which actually yields 32 bits of checksum, has much
better error detection properties than the standard OSI checksum,
is twice as fast to compute, etc. etc.   At no time did I EVER
suggest that it would be a good thing to replace the TCP checksum
with it!!!!!!  (I could never make it run any faster than 2.5 times
slower than the corresponding best TCP checksum).

	It does have the amusing property that you could have 16 bits
of the 32 bits generated being the standard TCP checksum (in the standard
place), and the other 16 bits could appear anywhere else in the packet.
Craig suggested that if it were a TCP option, then it could be ignored
or declined in a graceful way.

	To address Steve's concern, I'm not imaginative enough to
think of a way to place TCP options behind the data; however the
verification algorithm is one of the kind, like ethernet CRC,
where you run along and compute numbers as you receive data,
and hopefully come up with a known quantity at the end
(in this case 32 bits of zeros).  And, should Steve's reason for
wanting the checksum at the end of the packet have to do with ease
of computing changes to the checksum given small changes to the packet,
in the case of TCP, you don't alter the TCP headers or data as they
pass through gateways.

	It wouldn't be hard to come up with a minor modification to
the VMTP checksum having the same property of position independence,
which would be almost as fast to compute as the TCP checksum.
The VMTP checksum would not detect 32 bit transpositions, nor double-bit
errors (which is what may have triggered Johnny's interest).
However, people on this list have already argued quite effectively
that a stronger checksum is really not needed.

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 89 21:31:55 GMT
From:      moline@trwind.UUCP (Dan Molinelli)
To:        comp.protocols.tcp-ip
Subject:   MIB vars for HUB

does anyone have the defined MIB variables for a HUB for twisted pair/fiber
optics. we have to implement something for our SNMP network management
center.

thanks in advanced
INTERnet:	jassal@trwind.trw.com


-- 
Daniel Molinelli
TRW Information Networks Division
ARPAnet:	moline@trwind.trw.com

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 89 21:51:47 GMT
From:      karl@asylum.SF.CA.US (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP

In article <237@sparta.UUCP> chris@sparta.UUCP (Chris Chiotasso) writes:
>I read the code and found that the object id's are encoded with the
>first 2 subids in a single subid field using (x*40)+y x=1st subid
>and y=2nd subid.
>
>I have also read the RFC's and have not found any reference to this.
>Am I missing something?  Why are the first 2 ids combined?

You have stumbled onto a growing problem -- RFC's which require
knowledge which is not present in the RFC itself or another RFC.  The
answer to your question is in an OSI document, named "ISO 8825
Information Processing Systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Syntax Notation One
(ASN.1)" You need to look at section 20.

What it says is exactly what you found -- the first two object
identifier components are combined into a single subidentifier.  Why?
I don't know -- probably because they felt they could save a byte.

You'll probably find other things in SNMP that require refernce to ISO
8825 and its companion ISO 8824.  You can get copies (for $$) from a
number of sources.  I tend to use Omnicom in Vienna, Virginia.

You may also find that some SNMP implementations don't do perfect
ASN.1 encoding.  (For example, you may see COUNTERS, GAUGES [i.e.
unsigned types] being mis-encoded as negative signed integers when
high order bit is a 1.  Problems haven't occurred because most of us
tend to use machines that use 32 bit long integers and two's
complement math.)

			--karl--

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 89 22:10:09 GMT
From:      stephen@oahu.cs.ucla.edu (Steve Whitney)
To:        comp.protocols.tcp-ip
Subject:   Echoing on Telnet Protocol via Gateways

Hello to you all I/O gurus,

we'd like to submit an interesting analyse/design problem concerning echo on
Telnet protocol via gateways;

In heterogeneous environments (Un*x and non-Un*x) there are 2 places where to
perform the echo function for the Un*x EndUser:
either in the Un*x machine (via line discipline (?) or the local Telnet) or in
the Telnet agent in the gateway function.

		Questions: - Are all the Un*x machines able to locally echo
			     to the terminal (via Telnet) ?
			     
			    - Is there a risk of mixing write data (from the
			      host side) with echo of user data ?

Thanx in advance for any of your comments/suggestions.

--
Steve Whitney   "It's never _really_ the last minute"       (())_-_(())
UCLA Comp. Sci. Grad. Student                                | (* *) | 
Internet: stephen@cs.ucla.edu              UCLA Bruin-->    {  \_@_/  }
GEnie:    S.WHITNEY                                           `-----'  

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 89 23:12:42 GMT
From:      jgreely@oz.cis.ohio-state.edu (J Greely)
To:        comp.protocols.tcp-ip
Subject:   Re: Decrypting RFC 1125

In article <8911240620.AA06208@ucbvax.Berkeley.EDU> dave@CITI.UMICH.EDU
 (Dave Bachmann) writes:
>  After I had gotten this working I excitedly looked to see if it would work
>for the other Postscript RFC's.  No such luck.  EVERY AUTHOR OF A POSTSCRIPT
>RFC HAS USED A DIFFERENT PACKAGE.  In fact, the only RFC's that share a common
>format are the NTP family.  Oh well.

Ran a quick check of the four PostScript formatted RFCs I found here
(1119, 1125, 1128, and 1129), and there are two macro packages in use,
only one of which is worthwhile.  1125 uses pscat from Adobe's
TranScript package to post-process troff output into PS (thank you!).
The other (GEM-something-or-other) makes non-portable assumptions,
mangles the Adobe Document Structuring Conventions, and simply won't
print on all PS devices (guaranteed not to print on a NeXT, which is
the only system that otherwise would allow it to be viewed on-screen).
The EPS figures included look okay, but everything else is bogus.

  I would suggest that future PostScript-format RFCs be required to
conform to the published conventions, or all hell will break loose
when someone decides to use BrokenWord, whose output is printable only
on a directly-attached Apple LaserWriter (note: I'm not picking on any
particular WP package, but there are several that are almost that
bad).  Unfortunately, there's no PS validation tool, although some
ideas are floating around comp.lang.postscript.

  Call me a purist, but if I can't print it page-reversed,
double-sided, two-up, and in signature order, it ain't PostScript.
(incidentally, this is the most convenient form I've found for
carrying RFCs around; try it, you'll like it)
-=-
J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 89 01:20:52 GMT
From:      msd@trwind.UUCP ( ayuda)
To:        comp.protocols.tcp-ip
Subject:   Re: broadcast handling in presence of subnets

In article <794@excelan.COM> avnish@ka.excelan.com (Avnish Aggarwal) writes:

> If you have an IP router that is connected to subnets (which
> are all part of the same IP network), what is the router
> supposed to do with an directed IP broadcast datagram?
> (i.e. destination address is <net><-1>  where <net> is same
> as the local net)
>
> Any opinions?

You'd like to simply rebroadcast (MAC-layer) that datagram on all
connected subnets EXCEPT the one you got the original datagram from.
That won't make it if there are topological cycles though because
the same datagram will be back (and back ...) until it's time-to-
live expires.

Another way is to support RPF (reverse path forwarding).  I don't
have any references handy, but briefly this means that you translate
the source address into a route and then only rebroadcast on those
connected subnets which ARE NOT on the chosen route back to the
source.  If the virtual distributed routing database (a highly
stable beast ;>) is self-consistent, then that should not result
in a gateway/router seeing that datagram again.

I personally would think counting on the consistency of the routing
database is a risky business.  If I were implementing a router
(again), I'd only do rebroadcasting if I also implemented a cache of
source addresses and IP ID numbers which could be checked.  Since
whole-network broadcasts of that type are pretty expensive, you'd
hope that implementors would only resort to them as a last ditch
effort to find some resource which could then be directly talked
to, so the checking of such a cache should be infrequent during
times of network stability.  When it's not stable, who can blame
the router if it errs in a conservative manner by pitching abundant
broadcasts?  Also, I'd relegate the processing of such broadcasts
to a lower priority processing thread than the handling of other
traffic of the same precedence.

Happy Holidays!

++msd

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 89 01:51:39 GMT
From:      PETEHIC@UOTTAWA.BITNET (Pete Hickey)
To:        comp.protocols.tcp-ip
Subject:   Re: lpd protocol

lpd on an MS-DOS machine???  I wouldn't want to port it.  lpd forks
children to handle each request, and MS-DOS is reputed to have a
few bugs in the fork() call.... :-)

=======================================================================
Pete Hickey                     | Convention says that something funny
University of Ottawa            | goes here.  Its blank because I have
Ottawa, Ontario, CANADA         | funny to say.
(613) 564-7646                  |_____________________________________
    petehic@uotacdvm.uottawa.CA      PETEHIC@UOTTAWA.BITNET

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 89 02:42:50 GMT
From:      hahn@tolerant.UUCP (John Hahn)
To:        comp.protocols.tcp-ip
Subject:   IP <-> X25 address mapping/conversion question


I am looking for some information on the Internet Ip-addr to X25
address mapping/conversion issue. I always assumed that in order to
have TCP-IP run on top of X25 the addresses have to be mapped since
Internet and X25 address spaces were incompatible. However when I
was investigating the BSD4.3 implementation on the VAX it looks as if
there is an address conversion based on some DDN spec. 
The conversion routine goes as follows.

/*	@(#)if_ddn.c	7.1 (Berkeley) 6/5/86 */
	Copyright (c) 1985 by Advanced Computer Communications
*									*
*	NOTE: Although IF-11/X25 was designed to accept ASCII coded	*
static boolean convert_ip_addr(ip_addr, x25addr)
struct in_addr ip_addr;
u_char x25addr[];
  {
    register int temp;
    union {
	struct in_addr ip;
	struct {	 /*   (assumes Class A network number) */
	    u_char s_net;
	    u_char s_host;
	    u_char s_lh;
	    u_char s_impno;
	} imp;
    } imp_addr;

    if (imp_addr.imp.s_host < 64)	/* Physical:  0000 0 IIIHH00 [SS] */
      {					/*   s_impno -> III, s_host -> HH */
    else			/* Logical:   0000 1 RRRRR00 [SS]	*/
      {				/*   s_host * 256 + s_impno -> RRRRR	*/
Which then brings up the question if this is useable with the 
Public Data Networks (i.e. Telenet, Tymnet, Transpac ..etc)? 
Is this only for some DDN private networks and one must resort to 
mapping the address for use with the PDN's?

Thanks in advance for those who can enlighten me.

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Wed, 06 Dec 89 07:55:42 EST
From:      Brian Holmes <BHOLMES%WAYNEST1.BITNET@CORNELLC.cit.cornell.edu>
To:        TCP/IP newsgroup <TCP-IP@SRI-NIC.ARPA>
Subject:   managing addresses
I was just curious about how other sites are keeping track of
all your IP, Ethernet, Token Ring etc. addresses.  Are you
using a spreadsheet, database, flat file or simply memory?
I'm using Excel right now and I'm thinking of moving it to
Dbase or Focus.  What's everyone else doing?

                        Brian Holmes
                        UCC Operating Systems & Communications

PHONE:    (313) 577-3750  FAX=577-5626          Wayne State University
BITNET:   BHOLMES@WAYNEST1                      5925 Woodward
INTERNET: Brian_Holmes@UM.CC.UMICH.EDU          Detroit, MI 48202  U.S.A
-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 89 04:51:47 GMT
From:      brnstnd@stealth.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Traffic Sensitive SPF Routing is NOT too hard!

In article <6251@cbnewsh.ATT.COM> tds@cbnewsh.ATT.COM (antonio.desimone) writes:
> From article <4118@sbcs.sunysb.edu>, by brnstnd@stealth.acf.nyu.edu (Dan Bernstein):
> > There's absolutely no reason not to use a Bayesian or maximum-entropy
>                      ^^^^^^^^^ including being able to calculate routes
>                                in a human lifetime?

Yup.

> > calculation of the minimal-cost distribution of paths for a given
> > distribution of load. Maximum-entropy routing yields the efficiency of
> > dynamic routing without the instability of dynamic routing. If you're
> > paranoid, recalculate paths every week instead of every month.
> This is a little too heavy on the jargon for me.  Are you suggesting
> a single optimal route?  Or some kind of table-driven routing with
> tables calculated in advance?

You want as little calculation time as possible? Okay: See where the
heaviest amount of your traffic is going. Figure out two routes for it.
Figure out the delay time on each route; use maximum entropy to find the
proper distribution between routes. Remove that destination from your
calculation---and make sure to figure a higher delay on the two
calculated routes. Repeat until you've built a table covering 99% of
your destinations. All of this can be done with a minimal amount of
effort every once in a while. (None of this was my idea.)

The point is not to do a gigantic calculation of the best routes; the
point is to make routing a reasonably stable decision of ``90% of our
traffic here, 10% of our traffic there, all the time,'' rather than an
instable flip-flop between ``128.122 loves me... 128.122 loves me not...
128.122 just crashed... 128.122 loves me...'' Maximum entropy is just a
statistically sound way of keeping any desired variable---say, delay
times, where the current Internet fails so miserably---completely under
control.

---Dan

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 89 05:42:34 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re: more on Fletcher

I fail to see the reason why an alternative form of checksum is required for
the TCP frame.  As I recall the original posting, the host (in this case, an
intelligent communications processor) received the data correctly.  The error
occurred in a subsequent transmission between the "host" and external memory.

The problem is that the vendor of the intelligent communications processor
did not fully understand or is not compliant with the protocol established
by the vendor of the computer to govern DMA operations.  Or, the vendor of
the computer did not adequately define or implement the defined DMA proto-
col.

In either case, it is not TCP that is the problem.  If it is, as indicated
in an earlier message, a known problem that can occur during DMA operations,
it is the computer manufacturer's responsibility to correct the error.  If
it is a problem that only occurs with DMA operations from the intelligent
communications processor, its manufacturer is responsible for correcting
the problem.

Merton

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 89 10:05:31 GMT
From:      prc@erbe.se (Robert Claeson)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: lpd Protocol Specs

In article <387@sdgsun.COM>, paul@sdgsun.COM (Paul Emerson) writes:

> Does anyone know/have the protocol specs for the BSD lpd protocol?  I haven't
> seen an RFC on this does it exist? I would like to write an lpd for use 
> on a SYSV machine.  I currently have a TCP/IP based remote printing 
> application but I would like to use the BSD protocol. 

There was a lpr/lpd clone posted to comp.sources.unix some time ago. I
believe that it was intended for BSD systems (for what reason?). You might
want to use that and modify it to run under System V. And, when done, don't
forget to post the changes :-)

-- 
          Robert Claeson      E-mail: rclaeson@erbe.se
	  ERBE DATA AB

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Wed, 06 Dec 89 16:58:58 EST
From:      Brian Holmes <BHOLMES%WAYNEST1.BITNET@CORNELLC.cit.cornell.edu>
To:        TCP/IP newsgroup <TCP-IP@SRI-NIC.ARPA>
Subject:   Re: managing addresses
I've only received 2 replys and both have only been for
IP addresses and names, which of course is done with
the domain names file.  No responses on how people are
handleing ethernet and token ring addresses.

                        Brian Holmes
                        UCC Operating Systems & Communications

PHONE:    (313) 577-3750  FAX=577-5626          Wayne State University
BITNET:   BHOLMES@WAYNEST1                      5925 Woodward
INTERNET: Brian_Holmes@UM.CC.UMICH.EDU          Detroit, MI 48202  U.S.A
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 89 12:55:42 GMT
From:      BHOLMES@WAYNEST1.BITNET (Brian Holmes)
To:        comp.protocols.tcp-ip
Subject:   managing addresses

I was just curious about how other sites are keeping track of
all your IP, Ethernet, Token Ring etc. addresses.  Are you
using a spreadsheet, database, flat file or simply memory?
I'm using Excel right now and I'm thinking of moving it to
Dbase or Focus.  What's everyone else doing?

                        Brian Holmes
                        UCC Operating Systems & Communications

PHONE:    (313) 577-3750  FAX=577-5626          Wayne State University
BITNET:   BHOLMES@WAYNEST1                      5925 Woodward
INTERNET: Brian_Holmes@UM.CC.UMICH.EDU          Detroit, MI 48202  U.S.A

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 89 14:10:20 GMT
From:      dunigan@MSR.EPM.ORNL.GOV (Tom Dunigan 576-2522)
To:        comp.protocols.tcp-ip
Subject:   seeking software for ibm/mvs job submission from tcp/ip engines

We are seeking information on software that would permit tcp/ip
workstations to submit jobs to and retrieve output from MVS IBM systems
(that may or may not be running tcp/ip).  For example,
some client/server software that would communicate with a server
machine with a link/software to our IBM system.

I notice there is a TCP/IP "rje" protocol (77).  What service has
that port been used to provide?

thanks

tom 
  dunigan@msr.epm.ornl.gov
  

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 89 17:32:06 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   re: RIP documentation/implementations


Steven A. Myers:

See RFC 1058.

--jon.

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Dec 89 17:32:58 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Decrypting RFC 1125

In article <JGREELY.89Dec5181242@oz.cis.ohio-state.edu> J Greely <jgreely@cis.ohio-state.edu> writes:
>Ran a quick check of the four PostScript formatted RFCs I found here
>(1119, 1125, 1128, and 1129), and there are two macro packages in use,
>only one of which is worthwhile.  1125 uses pscat from Adobe's
>TranScript package to post-process troff output into PS...

Hmm.  This means, of course, that except for illustrations (haven't looked
at 1125 myself), it would be trivial to supply an ASCII-text version of
1125 -- just run through nroff instead of troff.  It would Sure Be Nice
to have a greppable version...
-- 
1233 EST, Dec 7, 1972:         |     Henry Spencer at U of Toronto Zoology
last ship sails for the Moon.  | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 89 18:09:21 GMT
From:      brnstnd@stealth.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re:  Question about telnet RFC

In article <8912041645.AA26970@opus.cray.com> dab@OPUS.CRAY.COM (Dave Borman) writes:
> The unclear point about option negotiation is when one sends a
> request to enable and option, and a refusal comes back (i.e., if
> I send DO OPT and get back a WONT OPT).

The only unclear point about option negotiation is what you do when the
user requests that an option be turned on, but then changes his mind
before you get a reply back. As I discovered several months ago, you can
handle this case in apparent conformance with RFC 854 and still allow
option negotiation loops.

The worst part is that it actually happens in practice. Tell your
implementation to show option negotiations; then connect to something
and tell your implementation to switch back and forth rapidly between
states. (For example, under BSD telnet: toggle option, mode character,
mode line, mode character ...) Stop after two or three switches, and
watch the loop.

Fortunately, Dave and the rest of the BSD telnet crew woke up when I
pointed this out; so, without giving me any credit, they've put some
loop prevention code into the 4.4 version. Hooray for academic honesty.

Back to the easy issue of DO-WONT:

> Do I then respond with
> a DONT OPT, or do I just end the negotiation there?  It can be
> argued both ways.

It can be argued both ways; but those who write books, and those who
understand why protocols fail, are in complete agreement that you end
the negotiation there. There is absolutely no reason to send an extra
negotiation.

> If my state changed when I sent DO OPT, then
> it seems reasonable that I should send a DONT OPT if I receive
> a WONT OPT, to confirm that I have disabled the option.

If your state changed when you sent DO OPT, then you are in violation
of the requirement that an option negotiation not take effect until the
appropriate point in the data stream. Dave's going to respond to this by
saying that your state can change without affecting the data stream; but
then it's not a real state change.

To put it differently, RFC 854 effectively *defines* your ``state'' as
what you're doing to the data stream, and you're not allowed to apply
OPT to the data stream unless/until the other side agrees; so you're in
violation of the RFC if your state changed when you sent DO OPT.

> But if
> I don't change my state until I get the WILL OPT, then I it seems
> reasonable that I do NOT send the DONT OPT, since that is what
> state we are already in.

This is very, very sensible.

To put it still differently: RFC 854 talks about negotiations for the
state you're already in as noncompliant negotiations, to be ignored.
If you send back a DONT after DO-WONT, you're acting the same way as any
other noncompliant implementation.

To put it still differently: RFC 854 explicitly commands, Thou shalt not
send a negotiation for the state you're already in. After DO-WONT you're
in the negative state as before, so sending a DONT is a violation.

To put it in practical terms: The more you send through the network, the
less the network will *work*.

> As it turns out, from the view of the protocol, when you are doing
> proper option negotiation, both cases will work just fine, and
> neither side of the connection should have any dependencies on
> it happening one way or the other.

Yeah, and injecting spurious packets into the Internet doesn't make your
host non-conformant, and it won't make anything fail, but it's still
stupid.

---Dan

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 89 18:51:12 GMT
From:      stine@SPARTA.COM (Robert Havens Stine)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP benchmark programs needed

Spray & ping, which are part of SunOS (& BSD?) can be used as traffic
generators.  Also, there is ttcp, available via anonymous FTP from
vgr.brl.mil, in file ftp/pub/ttcp.c, and from sgi.com, in file
sgi/src/ttcp.c.  For VMS, ttcp.c is included in the MultiNet
Programmer's Kit, a standard feature of TGV MultiNet IP software
package.

Nhfsstone is a load generation program for NFS.  It is available from
     Legato Systems, Inc.
     Nhfsstone
     260 Sheridan Avenue
     Palo Alto, California  94306

A mailing list is maintained for regular information
and bug fixes: nhfsstone@legato.com or


- Bob Stine

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 89 19:04:15 GMT
From:      zweig@brutus.cs.uiuc.edu (Johnny Zweig)
To:        comp.protocols.tcp-ip
Subject:   Re: more on Fletcher

mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes:

>I fail to see the reason why an alternative form of checksum is required for
>the TCP frame.  As I recall the original posting, the host (in this case, an
>intelligent communications processor) received the data correctly.  The error
>occurred in a subsequent transmission between the "host" and external memory.
 
>The problem is that the vendor of the intelligent communications processor
>did not fully understand or is not compliant with the protocol established
>by the vendor of the computer to govern DMA operations.  Or, the vendor of
>the computer did not adequately define or implement the defined DMA proto-
>col.

I have to disagree (note my biased opinion, given that I'm the one who 
proposed the option).  The TCP checksum is an end-to-end checksum.  Saying
"it's a hardware problem" is a cop-out (although I agree wholeheartedly
that nobody in their right mind would buy/use hardware known to suffer from
such bugs) -- my idea was simply to allow the possibility of specifying a
checksum that can detect these errors which ought not to happen.

>In either case, it is not TCP that is the problem.

But is _is_ TCP's job to detect the presence of the problem, rather than
get bitten by it.

> If it is, as indicated
>in an earlier message, a known problem that can occur during DMA operations,
>it is the computer manufacturer's responsibility to correct the error.  If
>it is a problem that only occurs with DMA operations from the intelligent
>communications processor, its manufacturer is responsible for correcting
>the problem.
 
>Merton

All I thought was "gee, why not have a standard way of doing something
that nobody ought to want to do, so that all the people who ought not to be
doing it do it in the same way?"  I am a researcher (not one of these evil
vendor type goblins that ought to solve problems rather than think them up ;-)
and I personally think playing with alternate checksums might be fun.  Further,
I am not in a position, for the most part, to say "Let's complain to Widgicorp
that the beta-test hardware they gave us is flakey and suspend research on our
latest transaction protocol for six months while they fix the problem" if I
can just say "Oh. Plug in the Fletcher-TCP module on both of the machines
in our experimental net and take a performance hit until Widgicorp gets it
fixed."

I prefer having standards that allow me to do crazy mixed-up stuff the same
way as all the other screwballs over having a non-compliant implementation
that I need to work around something.

-Johnny

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 89 21:43:23 GMT
From:      news@haddock.ima.isc.com (overhead)
To:        comp.protocols.tcp-ip
Subject:   Re: IP <-> X25 address mapping/conversion question

In article <6539@tolerant.UUCP> hahn@tolerant.UUCP (John Hahn) writes:
>
>I am looking for some information on the Internet Ip-addr to X25
>address mapping/conversion issue. I always assumed that in order to
>have TCP-IP run on top of X25 the addresses have to be mapped since
>Internet and X25 address spaces were incompatible. However when I
>was investigating the BSD4.3 implementation on the VAX it looks as if
>there is an address conversion based on some DDN spec. 
>

"Defense Data Network X.25 Host Interface Specification" Dated
December, 1983, prepared by BBN Communications Corporation.  Refer to
Section A-5 of Appendix A.

>Which then brings up the question if this is useable with the 
>Public Data Networks (i.e. Telenet, Tymnet, Transpac ..etc)? 
>Is this only for some DDN private networks and one must resort to 
>mapping the address for use with the PDN's?
>

Each Public Data Network (and DDN) assigns its own address space.
There are no address conversion algorithms that I know of except for
the DDN address space.  

I believe there was a posting a while back about about a group working
on an ARP type protocol to obtain X.25 addresses, but I may be wrong
about this.

Jim

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 89 21:58:58 GMT
From:      BHOLMES@WAYNEST1.BITNET (Brian Holmes)
To:        comp.protocols.tcp-ip
Subject:   Re: managing addresses

I've only received 2 replys and both have only been for
IP addresses and names, which of course is done with
the domain names file.  No responses on how people are
handleing ethernet and token ring addresses.

                        Brian Holmes
                        UCC Operating Systems & Communications

PHONE:    (313) 577-3750  FAX=577-5626          Wayne State University
BITNET:   BHOLMES@WAYNEST1                      5925 Woodward
INTERNET: Brian_Holmes@UM.CC.UMICH.EDU          Detroit, MI 48202  U.S.A

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 89 22:03:32 GMT
From:      ww0n+@ANDREW.CMU.EDU (Walter Lloyd Wimer III)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP


The E-mail address for comments about the CMU SNMP package is:

    Steve Waldbusser <sw0l+snmp@andrew.cmu.edu>

That userid is "s" (as in "Steve"), "w" (as in "Waldbusser"), zero, ell.
 The "+snmp" part is a hint to our mail system to direct such mail to
Steve's special SNMP mail folder.

Obviously, you needn't type Steve's whole name if you don't want to; the
part within angle brackets will suffice.


Walt Wimer
Network Development
Carnegie Mellon University

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 89 23:35:53 GMT
From:      karn@jupiter..bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: more on Fletcher

>I have to disagree (note my biased opinion, given that I'm the one who 
>proposed the option).  The TCP checksum is an end-to-end checksum.  Saying
>"it's a hardware problem" is a cop-out...

I am a big believer in the end-to-end argument. Unfortunately, even a
TCP running in the same machine as the application isn't TRULY
end-to-end.

The problem is all that software between TCP and the application. In
particular, it is common to first retrieve a file using FTP and then
have an application read it. A lot can happen between TCP and the
application in this case. Files can get corrupted or truncated by disk
I/O errors, corrupted file system structures, full disks and buggy
buffering schemes. And then there's the #1 cause of data corruption in
FTP: transferring a binary data file in the default ASCII mode! (I've
lost track of how many times I've had to help novice network users with
this one.)

In my experience these problems have accounted for far more actual cases
of corrupted data than failures of the TCP checksum. One thing I often
do on the PC to protect myself against the aforementioned hazards is to
use file compression and archiving utilities like PKARC or ZOO. Not only
do they make it easier and faster to ship a bunch of files over a slow
network, but their built-in CRCs or checksums serve as a somewhat
higher-layer check that includes FTP and the file system as well as TCP.

Phil

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Dec 89 08:08:11 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   re: fletcher

It seemed to me that the key point of Johnny's original note was that
gee, there exist these checksums with different error detection properties
that *might* be interesting for certain applications using TCP.  Could
there be a way to use a different checksum?

It seems to me that's a perfectly fair question to ask -- and the answer
appears to be yes, there's a straightforward way to negotiate a new checksum.

Whether that's a good thing or not, is entirely separate.  As some folks
have pointed out, there's always this problem with new features -- some
idiot decides the way out of a problem (e.g. broken hardware) is to use
the new feature instead of fixing the proper problem.

Craig
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 01:58:27 GMT
From:      lmg@hpindda.HP.COM (Lisa Gullicksen)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP

> from / chris@sparta.UUCP (Chris Chiotasso) / 10:59 am  Dec  4, 1989 /
>
>
>I read the code and found that the object id's are encoded with the
>first 2 subids in a single subid field using (x*40)+y x=1st subid
>and y=2nd subid.
>
>I have also read the RFC's and have not found any reference to this.
>Am I missing something?  Why are the first 2 ids combined?

The encoding of the first 2 subids in a single subid field as 
(x*40)+y  is described in ISO 8825 "Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1)" in section
20.4.  Section 20 covers "Encoding of an object identifier value."

Lisa Gullicksen
e-mail: lmg@hpindda.hp.com

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 03:06:18 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re: more on Fletcher

John:

Unless we're talking about a simple link level interface rather than an intel-
ligent communication processor, I still fail to understand how negotiating an
additional or alternative checksum is going to help.  You state:  "The TCP
checksum is an end-to-end checksum."  Unfortunately, "end" in this case would
refer to the intelligent communication processor NOT its host system.

Most of the intelligent processors that I've had the (mis)fortune to deal
with make the assumption that there will be no errors between the board and
the TCP, UDP, TELNET, and FTP peer processes in the host system.  This prob-
len is common to all intelligent processors regardless of protocol or suite
of protocols they are designed to support.

If you want to minimize the possibility of end-to-end data corruption, you
need to implement an end-to-end protocol that will physically execute in
the host processor--to a large degree replicating features in TCP/IP--or
use a simpler interface and performing the IP, TCP, etc. in the host.

Merton

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 03:42:18 GMT
From:      rossc@metro (Ross Cartlidge)
To:        comp.protocols.tcp-ip
Subject:   Re: Help: Connecting a Printer on a Terminalserver

From article <1279@dungeon.UUCP>, by hnt@Frobozz.COM (Michael Hentrich):
> How to connect from the host to the Terminalserver?

I posted something called "tcpcon" to comp.sources.unix
a few weeks ago which allows any tcp connection
to look like a real device ( it attaches a process to a pty)
It allows terminal server port to run as a printer, SLIP, getty etc

I haven't seen it appear on comp.sources.unix so I might repost
it somewhere un-moderated. Any suggestions?

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 05:19:56 GMT
From:      art@salt.acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP <-> X25 address mapping/conversion question

In article <6539@tolerant.UUCP> hahn@tolerant.UUCP (John Hahn) writes:
>
>I am looking for some information on the Internet Ip-addr to X25
>address mapping/conversion issue. I always assumed that in order to
>have TCP-IP run on top of X25 the addresses have to be mapped since
>Internet and X25 address spaces were incompatible. However when I
>was investigating the BSD4.3 implementation on the VAX it looks as if
>there is an address conversion based on some DDN spec. 
>The conversion routine goes as follows.
>
>/*	@(#)if_ddn.c	7.1 (Berkeley) 6/5/86 */
>	Copyright (c) 1985 by Advanced Computer Communications
  .
  .
  .
>Which then brings up the question if this is useable with the 
>Public Data Networks (i.e. Telenet, Tymnet, Transpac ..etc)? 
>Is this only for some DDN private networks and one must resort to 
>mapping the address for use with the PDN's?
>
>Thanks in advance for those who can enlighten me.

The IP over X.25 world can be split in two groups, nets that know about
IP addresses and those that don't.  For those nets that know about IP
and maintain a correspondence between IP and X.25 addresses (DDN,
Blacker I/Fs) the IP<->X.25 mappings are algorithmic.  For most of the
rest of the X.25 nets in the world there is no relationship between the
IP and X.25 addresses and address lookup tables are generally used.
The PDN working group of the IETF is looking into defining X.25 address
server protocols to avoid maintaining huge tables locally.

Art Berggreen
ACC

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 05:34:00 GMT
From:      wiltzius@lll-lcc.UUCP (Dave P. Wiltzius)
To:        comp.dcom.lans.hyperchannel,comp.protocols.tcp-ip
Subject:   TCP/IP performance on Cray


We are nearing completion of a port of TCP/IP to our
operating system (NLTSS) on a Cray (YMP) and I am
interested in any performance numbers on any Cray
to any other host using TCP/IP sockets, memory-memory.
Of particular interest is a configuration close to
ours where the Cray is on a HYPERchannel and
"other host" is, for Ethernet any Sun, VAX, IBM PC
or Mac via an EN641 IP router and for HYPERchannel is
an IBM 43xx (or Amdahl equivalent), a VAX (any flavor)
or another Cray (any flavor).  However, any performance
numbers will be of interest, esp. the loopback performance
that Dave Borman posted a while back.

Thanks much.  Email responses will be summarized if
requested.  Please include the configuration of the
network.

  Dave Wiltzius (wiltzius@lll-lcc.llnl.gov)
  Lawrence Livermore Nat'l Lab
  (415) 422-1551

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 06:50:08 GMT
From:      jgreely@scarecrow.cis.ohio-state.edu (J Greely)
To:        comp.protocols.tcp-ip
Subject:   Re: Decrypting RFC 1125

In article <1989Dec6.173258.1036@utzoo.uucp> henry@utzoo.uucp
 (Henry Spencer) writes:
>Hmm.  This means, of course, that except for illustrations (haven't looked
>at 1125 myself), it would be trivial to supply an ASCII-text version of
>1125 -- just run through nroff instead of troff.  It would Sure Be Nice
>to have a greppable version...

Sigh.  Correct thought, wrong RFC.  I hadn't realized until now that
we had miscopied 1124 as 1125 here.  1124 is the "troff | pscat"
output, 1125 is "TeX | dvi2ps", where dvi2ps is an old, ugly,
non-conforming dvi converter.  Take all of my negative comments about
the other PS RFCs, and apply them to 1125.  1124 is, however, fine,
although running it through nroff would still be useful for many
people.  The loss of the illustrations may hurt it (I haven't read the
text, just the PostScript; I'm not near a printer right now!), but I'd
consider the increased convenience worth it.

  Actually, the same thought applies to TeX.  Dvidoc produces
reasonably formatted ASCII text from TeX documents, and it's widely
available.
-=-
J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 08:33:11 GMT
From:      rob@PRESTO.IG.COM (Rob Liebschutz)
To:        comp.protocols.tcp-ip
Subject:   problem with bind over slip links

Ftp (and a few other programs) fail over slip links.  The error
message that you get is "bind: Can't assign requested address".
Can anyone tell me how to solve this problem?

Thanks,
Rob

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 12:52:09 GMT
From:      MAP@LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   managing addresses


   Date:         Wed, 06 Dec 89 16:58:58 EST
   From: Brian Holmes <BHOLMES%WAYNEST1.BITNET@cornellc.cit.cornell.edu>

   I've only received 2 replys and both have only been for
   IP addresses and names, which of course is done with
   the domain names file.  No responses on how people are
   handleing ethernet and token ring addresses.

Just to get this straight.  Ethernet and Token Ring addresses are
managed by: (choose one depending on your view)
	Xerox / IEEE / Manufacturer / Hardware / ARP
You don't manage them yourself, in fact you can't (*) assign them,
they are fixed.  I manage a network of around 500 hosts and don't know
or have record (+) of any of the EtherNet addresses.  I've never found
this to be much of a problem.  I have no desire to try and track this,
I'd need to be informed and spend time rechecking any time any one of
those 500 machines was serviced, and that includes every time a random
undergrad (or worse, the technically inclined administrator) turns 2
PCs off and swaps boards to see if he can figure out why his program
isn't working.

	    __
  /|  /|  /|  \		Michael A. Patton, Network Manager
 / | / | /_|__/		Laboratory for Computer Science
/  |/  |/  |atton	Massachusetts Institute of Technology

Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)

(*) Well, I'll admit there is some hardware that lets you and DEC used
to do it, but that is the exception and can cause more problems than
you could imagine if you haven't experienced it.

(+) Unless of course one of those 2 inch square yellow sticky papers
is left from configuring BootP when a gateway is first installed.  I
do occasionally have to write them down, for reasons like BootP.  But
I deal with them and promptly toss the paper.  It would be easier to
determine it from first principles than to look it up, if I ever need
it again.

BTW, We don't maintain our Name/Address mapping in the DNS file.  It's
a generated file from a nightly update run, as it says at the top
		"Editing it is futile".

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Dec 89 21:07:55 PST
From:      cire|eric <cire@cisco.com>
To:        unmvax!ariel!dd@ucbvax.Berkeley.EDU (dd)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Request for information - front-ending IBM 7171 with CISCO ASM

This sounds interesting.  What exactly is an IBM 7171 and how are you
trying to connect the cisco to it?

-c
cire|eric

"I could have done it in a much more complicated
way", said the Red Queen, immensely proud.
			-- Lewis Carrol, Alice in Wonderland
Eric B. Decker
Token Ring Development
cisco Systems - engineering
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941
-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 13:08:11 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: fletcher


It seemed to me that the key point of Johnny's original note was that
gee, there exist these checksums with different error detection properties
that *might* be interesting for certain applications using TCP.  Could
there be a way to use a different checksum?

It seems to me that's a perfectly fair question to ask -- and the answer
appears to be yes, there's a straightforward way to negotiate a new checksum.

Whether that's a good thing or not, is entirely separate.  As some folks
have pointed out, there's always this problem with new features -- some
idiot decides the way out of a problem (e.g. broken hardware) is to use
the new feature instead of fixing the proper problem.

Craig

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 14:26:26 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Decrypting RFC 1125

J,

While I don't stick up for the GEM folk, who supplied the windowing
environment for Xerox Ventura Publisher, which was used to prepare
RFC-1119/-1128/-1129, I must admit that I had to munge the PostScript
output file to make what appears as two PostScript documents as only
one by deleting the preamble to the second document. The problem arises
because some CAP packages, Ventura among them, find it easiest to produce
tables of contents as a separate document and combine them during the
printing process. Now, you could bum Xerox for such a rash assumption
or bum the Unix spoolers that don't like two documents in one envelope
or bum me for fumbling the combining process. Life goes on.

Dave

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 14:28:46 GMT
From:      mhart@dtoa1.dt.navy.mil (hart)
To:        comp.protocols.tcp-ip
Subject:   Help w/ TCP/IP

Help!!!!
	Someone asked me for info on TCP/IP software for VAX/VMS 5.  
	I know that CMU has some p.d. s/w available, which I found at 
clutx.clarkson.edu (128.153.4.3).  However, I can't figure out which 
files to get, or where there is any documentation.

	Can someone help me with this? Either alternate sources of 
code, or info on what I need to FTP??
	Also, any comments/flames on p.d. TCP/IP for VMS??

	I promised I'd get a reply back by 1500 Friday, 8 Dec, so speed 
is of the essence!!!

Thanx in advance!

Michael G. Hart
Code 1204
David Taylor Research Center
Bethesda, MD    20084-5000
ph. 202-227-1979
e-mail: mhart@dtrc.dt.navy.mil

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 15:33:39 GMT
From:      ak2@nvuxr.cc.bellcore.com (Arthur Knapp)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: IP <-> X25 address mapping/conversion question

Article <6539@tolerant.UUCP> hahn@tolerant.UUCP (John Hahn)

John,
Good question!  Address interworking is never pretty.  
I am not sure what real packet-switches and real (public and private) 
packet-switched networks are doing but there are standards which may help 
you now or in the future.

In 1984/1988 CCITT X.25 and ISO 8208-1986/1989 include a Address Extension 
Facility (AEF) parameter field.  This field allows a calling DTE to include 
additional address information. e.g., an OSI Network-layer-address or 
another subnet address.  The AEF contents field is variable length up to 
20 octets.  Both called and calling address extensions are specified.  

In RFC 1069, Callon and Braun suggest a NSAP address structure that 
includes the DoD IP address.  Gateways can then strip out the DoD IP 
address when delivering an incoming PDU.  
Gateways can add the appropriate X.25 fields for an outgoing PDU.     

You wrote
> Which then brings up the question if this is useable with the 
> Public Data Networks (i.e. Telenet, Tymnet, Transpac ..etc)? 
Does anyone know if any PSPDNs or vendors are supporting the AEF field?  
If so, do you know how many bytes the field is? 

Arthur 

Arthur Knapp          ak2@nvuxr.cc.bellcore.com
Tel: 201-758-2198           Fax: 201-530-6875
331 Newman Springs Road, Rm 1F-359
Red Bank, NJ 07701-7020  USA
Telex: 275318

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 17:48:50 GMT
From:      rdroms@NRI.RESTON.VA.US
To:        comp.protocols.tcp-ip
Subject:   Re: Decrypting RFC 1125


I've written two .sty files that might be of interest to this
discussion.  The first, rfc.sty, generates RFC-style output (title
page, headers, footers, etc.) from LaTeX.  The second, txt.sty,
generates a .dvi file that can be run through dvi2tty to produce
well-formatted (IMHO, better than stock dvi2tty or dvidoc) ASCII
output.  I generated the PostScript and ASCII versions of the Dynamic
Host Configuration Internet Draft using these .sty files.

At present, txt.sty still needs more work, primarily to track down and
eliminate all the rubber vertical glue.  Dvi2tty could also use some
work to improve spacing of characters in both dimensions.  For
example, horizontal and vertical bars (actually, rules in general) are
not handled well.

Is there general interest in these .sty files?  How many RFCs or other
documents might actually be produced in both PostScript and ASCII from
TeX?  I'd like to know if it's worth my time to put more effort into
fine-tuning these tools.

- Ralph Droms                             (On leave from Bucknell University)
  NRI                                     rdroms@nri.reston.va.us
  1895 Preston White Drive, Suite 100     (703) 620-8990
  Reston, VA 22091                        (703) 620-0913 (fax)

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 18:41:37 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   A Book Review: "The Cuckoo's Egg" by Clifford Stoll



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

A Book Review:


"The Cuckoo's Egg" by Clifford Stoll
------------------------------------

If you are interested in computer networks or espionage, this book is
for you.  The book is a very interesting, even exciting, book to read.
The book is so consistently interesting that you can open the book to
any page at random and begin reading, and before finishing the page
you will be hooked on the story.

This is the story of Cliff Stoll's fast track education as a unix
system programmer and network wizard, with the main course being
tracking down a spy!  Cliff is an astronomer, thrown into the
computer support group at Lawrence Berkeley Laboratories by a
temporary funding crunch on his astronomy project.  

As his first task, he looked into the accounting system on the unix
machines and found that two different routines disagreed by
75 cents.  While most of us would say that's close enough, Cliff
decided to dig into it.

Someone had set up a new account but had done only half the things
needed to enter it into the accounting scheme.  Looking into that
account lead to the conclusion that there was a hacker in the system!

The story tells of the schemes that Cliff used to track the spy, to
keep him interested without letting him get too much critical data, or
tipping him off to the fact he was being watched.

The tricks the spy used are described, the data he was after (anything
to do with SDI), his methods of access, of getting superuser status,
of cracking passwords.  The book names names, sites, computers,
projects, accounts, passwords cracked.

It also describes the utter frustration of dealing with our government
agencies that are supposed to care about these problems.  In contrast
to this is the incredible response of the carriers in tracing calls.

It is also a very human and personal story with clear
characterizations of the people involved.  It is deals directly with
Cliff's own life inside and outside the lab.

	The Cuckoo's Egg
	Tracking a Spy through the Maze of Computer Espionage
	Clifford Stoll
	Doubleday 1989
	ISBN: 0-385-24946-2

Review by:

	Jon Postel

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

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 19:18:33 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: more on Fletcher

In article <18511@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes:
>... after someone else first writes:
>>The TCP checksum is an end-to-end checksum.  Saying
>>"it's a hardware problem" is a cop-out...
>
>I am a big believer in the end-to-end argument.
>

Many people appear to subscribe to "the end to end argument".
I don't know if they have been convinced by persuasive argument or by
the eminence of others who have endorsed it.  The arguments I have
heard do not convince me, and I believe that in many instances data
integrity can and should be a hardware problem.

Saltzer, Reed, and Clark argued the end-to-end case in their paper
in the November '84 TOCS,  They offer a file transfer application as
their paradigm, and note five threats to the integrity of the data stored
at the receiving host:
    1) Undetected disk or disk controller error on the sending
       host while reading the original file.
    2) Software error in either host or in communications system.
    3) Undetected processor or memory hardware error in either
       end system.
    4) Communications error.
    5) Host crashes during transfer.
They then claim that a harware-implemented communications checksum only
addresses fault 4, and that
	"the careful file transfer application must still counter the
	 remaining threats; so it should still provide its own retries
	 based on an end-to-end checksum of the file."
Perhaps a careful file transfer application should, but to conclude by
extension that all applications must is unwarranted.

In counter-argument, note that the first three risks are not unique to
communications systems, and will be faced by a careful single-host
disk-to-disk file copying program.  Does this mean that every disk block
on your computer system contains a software generated checksum? 
Undoubtedly there are applications that do this, but in most cases
the prevailing industry standard of reliability, enhanced as
it might be by embedded parity/EDC/ECC hardware, is sufficient.

The particular flavour of risk 5 encountered here is unique to distributed
systems, but its detection involves handshaking and does not require
"an end-to-end checksum of the file."

A related end-to-end argument, enunciated by Cheriton in his XXX
VMTP paper, states that only the application knows how small an error
probability is tolerable, so the application must implement the checksum.
This argument is incorrect, firstly because checksumming can not establish
a maximum error probability, it can only reduce it.  An application may be
willing to tolerate a 10^-18 error rate, but it cannot determine how strong
an error detection scheme to use unless it also knows what error rate it is
starting with.  Secondly, different error detection methods have different
strengths and weaknesses, and an appropriate selection may require
knowledge of the nature of the most probable errors.

In my view, data integrity can be effectively provided by chaining
together reliable links, and if this is done properly then no end-to-end
check is necessary.  "Doing it properly" means providing a comparable 
input-to-output error rate as you get from your favourite disk
drive/controller combination, or tape/formatter combination.
That likely means some error detection (or maybe correction, for something
like a satellite channel) "on the wire", and maybe some parity or
something even fancier in the communications processor memory, and maybe
you need to ensure that the domains of protection of these things overlap
so that errors don't sneak in through the cracks.  Check out what
Ciprico/Xylogics/etc. do with the caches on their intelligent disk
controllers.  Provide the same level of service they do, it seems to
be adequate for most applications.  Who knows, you might even be able to
write applications that don't have to be told whether they are dealing with
disks or networks, becuase they same de facto reliability standard
applies to both.

When does this approach fail?  Obviously, if your packets are going
over a network you know nothing about, or have no control over, it is not
safe to make assumptions about its error properties.  In that case,
higher-level error detection does make sense, but it should be provided
as an option, or perhaps as a gateway function, and it need not be
application-to-application.  Or, if you have a particularly finicky
or critical application that may not be satisfied with the 'standard'
reliability, it may wish to enhance it and should do so whether the
data transfer involves a network, a disk, a tape, or whatever.  Moreover,
it now has a fighting chance of doing what you want because it has at least
a vague idea of the kind of underlying error rates it has to deal with.
Finally, I will concede the possibility that under the right (unusual)
conditions it may be cheaper to build hardware with no error control and
rely entirely on end-to-end error detection in software, but I surmise
that the performance penalty associated with providing error detection of
any capability in software (say, the equivalent of a 32-bit CRC) will render
this a rather unpopular option.

Comments welcome.  Thanks for your attention.


-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 19:25:44 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Xerox Etherphone experiments?

somewhen, Xerox PARC did some experiments called "Etherphone".
has anyone heard of this?  

or..  could anyone point me to a documents person/index at Xerox
where i might be able to locate information on Etherphone?

thanks...



-- 


-- Steve Elias ; eli@spdcc.com ; 6179325598 ; 5086717556 ; { *disclaimer(); }
                

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 19:47:47 GMT
From:      gamiddon@maytag.waterloo.edu (Guy Middleton)
To:        comp.protocols.tcp-ip
Subject:   ICMP dest unreachable in BSD TCP

In 4.3BSD, a TCP connection will close if one end gets an ICMP host
unreachable or net unreachable packet.  The draft Host Requirements RFC seems
to say that this is a no-no.  Does anybody have the appropriate kernel changes?

 -Guy Middleton, University of Waterloo

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 20:04:09 GMT
From:      steveg@SAIC.COM (Stephen Harold Goldstein)
To:        comp.protocols.tcp-ip
Subject:   Help w/ TCP/IP

I'm also interested in TCP/IP for VMS.  We have a MicroVAX II with a DEQNA that
we'd like to tie in with our Suns' ethernet.  Please forward info my way too.
Thanks.

Stephen Goldstein <steveg@saic.com>

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 20:38:20 GMT
From:      zweig@brutus.cs.uiuc.edu (Johnny Zweig)
To:        comp.protocols.tcp-ip
Subject:   Re: more on Fletcher


I don't know why this talk about intelligent communications processors seems
to be taken for granted -- I was thinking of using Fletcher checksumming on
Mac's with potentially flakey 3rd-party ethernet interfaces, other
workstations and minis without front-end TCP/IP processors.  I'll grant
that if a front-end can't communicate reliably with a host, that's that
and it's time to change hardware.

Let me quickly respond to several of the arguments I've seen (paraphrased):

	The current checksum is fine. Don't change it.

I am not suggesting anyone change anything, nor would I hope for such a thing.
I want to add the possibility of a few lunatic-fringe people who feel it
might be necessary/fun/worth looking at to use alternate checksum techniques.
An argument that says the current way of doing things is fine is looking
at what I suggested wrong.

	The End-To-End argument is wrong; concatenation of reliable links
	is all you need.

Fine. I assert that, on my Mac, the linke between the ethernet card's RAM and
my system RAM is unreliable, so I want to make the TCP module running on
it sufficiently robust to detect failure of that link.  I am glad you agree
(albeit implicitly) that an alternate checksum capability is necessary to
make this last (and vital) link reliable, since the end-to-end argument and
the link-by-link argument agree on what to do when what you're talking
about the last link.  (Hairsplitting: the ethernet-card -> TCP link is the
last hardware link, not the last conceptual link since the data still needs
to be copied reliably to the application.)

	Water is wet and I don't get paid to listen to malcontents who
	want to make my life more complicated.

I apologize. It's in my nature.


-Johnny

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 20:38:59 GMT
From:      johnson@ncrons.StPaul.NCR.COM (Wayne D. Johnson)
To:        comp.unix.questions,comp.unix.wizards,comp.protocols.tcp-ip,comp.periphs
Subject:   Re: WANTED: IBM SNA <-> UNIX Connection

In article <378@ixos.UUCP> snoopy@ixos.UUCP (Snoopy Schmitz) writes:
>Dear Net,
>
>we are looking for ways to connect UNIX machines to "the IBM world".
>That is something for UNIX that will plug into SNA etc. This something
>should preferably be software perhaps also some hardware. 
>
>Are there any products you can recommend ? 
>

I have used RJE on both a NCR Tower and on Suns.  Both allow the user
to transmit and submit a job on MVS.  This seems to work very well and
most of our use is in doing file transfers (submit a job that copies a
included file to disk with iebgener) and printing (use a similar job
to copy your file to the laser print sysout).  Its not very good at binary
files.  You need to use a RS232/RS448 line to do this (9600-56kbaud).

>I guess one idea is to use NFS and AIX, or PC-NFS on Mush-DOS but what I 
>really need is link (channel) to IBMs big iron under VM etc.
>

There is also rumored, a Sun product that includes a VM system in their NFS
network via TCP-IP.  Never seen it used though.

-- 
Wayne Johnson         |  Is a baby's life worth more than the right to 
NCR Comten, Inc.      |  make a choice?  Babies are people too.
Roseville MN 55113    +-----------------------------------------------------
(Voice) 612-638-7665   (E-MAIL) W.Johnson@StPaul.NCR.COM

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 21:35:04 GMT
From:      dd@ariel.unm.edu (dd)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Request for information - front-ending IBM 7171 with CISCO ASM


I am trying to front-end an IBM 7171 with a CISCO ASM.  I have
gotten it to work, but there are some performance problems.  Has
anyone out there done this thing, and could I please ask you some
questions?

Thanks in advance.

-- 
Don Doerner				dd@ariel.unm.edu
University of New Mexico CIRT
2701 Campus Blvd, NE
Albuquerque, NM, 87131			(505) 277-8036

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 89 22:01:52 GMT
From:      george@na.excelan.com (George Powers)
To:        comp.protocols.tcp-ip
Subject:   Adding RAM to a Compaq 386/16

We own many Compaq 386/16MHz systems which currently have 2 MBytes of
RAM.  Owing to the trend in PC software, we now require more like 4-6
MBbytes of RAM in each system.  Apparently the Compaq memory upgrade
card required is either unavailable or costs so much that we might as
well forget the system and buy a new one.  Is this correct?  Is there
any way to upgrade these systems cost-effectively?


--
UUCP: {ames,sun,apple,mtxinu,cae780,sco}!excelan!george  George Powers
Internet: george@excelan.com 
--

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Dec 89 09:29 EST
From:      RLR <@JHMAIL.HCF.JHU.EDU:RLR@JHUVMS.BITNET>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Traffic Sensitive SPF Routing is NOT too hard!
Whats's a reference for the maximum entropy routing algorithm? Ron Ray
-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 89 05:07:55 GMT
From:      cire@CISCO.COM (cire|eric)
To:        comp.protocols.tcp-ip
Subject:   Re: Request for information - front-ending IBM 7171 with CISCO ASM


This sounds interesting.  What exactly is an IBM 7171 and how are you
trying to connect the cisco to it?

-c
cire|eric

"I could have done it in a much more complicated
way", said the Red Queen, immensely proud.
			-- Lewis Carrol, Alice in Wonderland
Eric B. Decker
Token Ring Development
cisco Systems - engineering
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 89 07:07:18 GMT
From:      rossc@extro.ucc.su.oz.au (Ross Cartlidge)
To:        comp.protocols.tcp-ip
Subject:   SLIP/getty/printers on Terminal Servers


For all those people which replied to my posting
here is the source:-
________________________________________________________________________
Ross Rodney Cartlidge			    |   rossc@extro.ucc.su.oz.au
University Computing Service, H08	    |   Phone:     +61 2 6923497
University of Sydney, NSW 2006, Australia   |   FAX:       +61 2 6606557

------------------------------- Cut Here -------------------------------------
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create:
#	Makefile
#	README
#	nd.1
#	nd.c
#	tcpcon.1
#	tcpcon.c
#	tcpserv.1
#	tcpserv.c
# This archive created: Fri Dec  8 16:58:58 1989
export PATH; PATH=/bin:/usr/bin:$PATH
if test -f 'Makefile'
then
	echo shar: "will not over-write existing file 'Makefile'"
else
cat << \SHAR_EOF > 'Makefile'
#	Set the follwing for your site
#
#	INSTALLDIR	Place to install binaries
#	XCFLAGS		Extra libraries needed for bsd stuff
#	XLIBS		Extra libraries needed for bsd stuff
#	
#	Values for MIPS RISC/OS 3/4
INSTALLDIR=/usr/local
XCFLAGS=-I/usr/include/bsd
XLIBS=-lbsd
#
#	Values for BSD 4.3
#INSTALLDIR=/usr/local
#XCFLAGS=
#XLIBS=
#

PROGS=nd tcpserv tcpcon

all: $(PROGS)

tcpcon:	tcpcon.c
	$(CC) $(XCFLAGS) $(CFLAGS) -o $@ tcpcon.c $(LIBS) $(XLIBS)

nd:	nd.c
	$(CC) $(XCFLAGS) $(CFLAGS) -o $@ nd.c $(LIBS) $(XLIBS)

tcpserv:	tcpserv.c
	$(CC) $(XCFLAGS) $(CFLAGS) -o $@ tcpserv.c $(LIBS) $(XLIBS)

install: all
	/etc/install -o  -f $(INSTALLDIR) nd
	/etc/install -o  -f $(INSTALLDIR) tcpcon
	/etc/install -o  -f $(INSTALLDIR) tcpserv

clean:

clobber: clean
	rm -f $(PROGS)
SHAR_EOF
fi
if test -f 'README'
then
	echo shar: "will not over-write existing file 'README'"
else
cat << \SHAR_EOF > 'README'
This distribution is a set of programs to connect
an arbitrary process to a device.
It works by attaching the process to the master side
of a pty device. This makes the slave side appear to be
a connection to this process.

The process can do anything, however, most commonly
it is a process to establish a network connection
such as telnet or tcpcon , a command supplied which
connects to an arbitrary tcp address and port.

It is usually used to assign a device to a port
on a terminal server so that the port can be used
just like a real port on a machine. This enables the
port to connect a printer, run a getty, slip, uucp, ACSnet, etc.

FILES:-
Makefile
README
nd.1
nd.c
tcpcon.1
tcpcon.c
tcpserv.1
tcpserv.c

INSTALLATION:
.	Edit Makefile to reflect your machine
.	type "make install"
.	Install the manual entries.
.	Set up an "nd" device (See manual entries and also notes below)

A TEST:
Try these commands to test it
	nd -l /dev/ptypf tcpcon localhost smtp &
	cat < /dev/ttypf &
	stty -echo < /dev/ttypf # < should be > for BSD systems
	cat > /dev/ttypf
You should now be talking to the SMTP server of your machine.
try the command help<CR>
Use <CNTL>D to kill cat and then
kill the async cat.

Notes for Bridge/3COM terminal servers.

.	Enable the generic port 2000 service for your terminal
	servers.

.	Assign an IP address to the server port to which
	you wish to connect.

.	Make the port a host device.

.	Set the Physical parameters of the port  ( Use CTS/RTS flow control
	and 8bit no parity if possible)

To set up a connection to a port with address "ipaddr"
set up the following line in /etc/inittab after creating the directory
"/etc/tcpcon.d"

vn:respawn:/usr/local/nd -r -d /etc/tcpcon.d -t ptypf /usr/local/tcpcon -l /dev/ptypf ipaddr 2000

If you don't have inittab then the nd command should be in a startup rc file.

The pty's should be allocated from your last pty downward to stop nd
clashing with automatically allocated ptys.


Notes for Bridge/3COM terminal servers.

.	Create a server process for each port you wish to
	put a virtual device on, calling each process port<n>
	and assigning it to TCP port 2000+n.

.	Attach the appropriate server to the port.

.	Set the Physical parameters of the port  ( Use CTS/RTS flow control
	and 8bit no parity if possible)

.	Enable the server.

To set up device on port 6 of a cmc server with IP name cmcip, say
set up the following line in /etc/inittab after creating the directory
"/etc/tcpcon.d"

vn:respawn:/usr/local/nd -r -d /etc/tcpcon.d -t ptypf /usr/local/tcpcon -l /dev/ptypf cmcip 2006

If you don't have inittab then the nd command should be in a startup rc file.

The pty's should be allocated from your last pty downward to stop nd
clashing with automatically allocated ptys.

Caveats
	I only just added the UDP support so it might be buggy

	Some systems (RISC/OS 4.0.1 eg) don't make a read return
	on a pty when the corresponding tty is closed. This makes the
	process (eg the tcp connection) continue, when the tty is closed,
	this is annoying if you wish to cause a modem drop at the other end.
	To get round this you have to send a SIGINT to the nd process. See nd(1)
	for more details.
SHAR_EOF
fi
if test -f 'nd.1'
then
	echo shar: "will not over-write existing file 'nd.1'"
else
cat << \SHAR_EOF > 'nd.1'
.TH ND 1 "April 1989"
.SH NAME
nd \- connect a process to a pty
.SH SYNOPSIS
.B nd
[
.B \-r
]
[
.B \-l
pty
] 
[
.B \-f
failtime
] 
[
.B \-c
cleartime
] 
[
.B \-d
piddir
] 
[
.B \-t
pidtag
] 
.I command
.SH DESCRIPTION
.B Nd
runs the process specified in
.I command
with standard input, output, error
and controlling terminal assigned
to the device specified by the
.IR pty
specified in the 
.B \-l
option.
If no
.B \-l
option is supplied then
.I command
must
open the appropriate pty.
The command is passed to a forked
.I sh
as
.BI "sh \-c 'exec " "command" "'" "'"
so any legal
.I sh
syntax can appear in the
.I command
field.
.PP
Unless
.B \-r
is specified,
.B nd
dies
.I cleartime
seconds after the successful completion of
.IR command ,
allowing the other side of the connection to clear
the connection. By default
.I cleartime
is set to 2 seconds.
In the event of
.I command
exiting with a non-zero exit status
.B nd
will sleep for
.I failtime
before exiting.
If
.B \-r
is specified
.B nd
will re-exec
.I command
after waiting for
.I cleartime
or
.I failtime
as appropriate.
The
.I failtime
is to stop
.B nd
from exec-ing
the command too often.
By default
.I failtime
is set to 15 seconds,
preventing
.B nd
from respawning more than 10 times
in 2 minutes and being disabled by
.BR init (1M),
if it is being spawned from an entry in
.B inittab (4)
.PP
.BR Init (1M)
will respawn
.B nd
automatically
if a line similar to:-
.IP
.BI p1:234:respawn: " nd command"
.LP
is added to
.B /etc/inittab.
.PP
If you don't wish to run it from inittab or don't have inittab,
.B nd
should be started with the
.B \-r
option  if you wish the connection to be permanent.
.SH OPTIONS
.TP 1i
.BI \-l " pty"
Attach
.I command
to
.IR pty .
.TP 1i
.BI \-d " piddir"
Log the
.B pid
of
.I command
in
.IR piddir/tag .
Where
.I tag
is the tag specified by
.BR \-t
or if not specified
the basename of 
.I dev
or if no
.B \-l
specified then
tag defaults to
.IR pid. "<pid of command>."
Therefore if you wish to drop the connection,
then kill the process with the
.B pid
stored in this file.
.TP 1i
.BI \-t " tag"
set the name of the file which stores the
pid of command to
.IR tag .
.I failtime
seconds.
.TP 1i
.BI \-f " failtime"
set the fail sleep time to
.I failtime
seconds.
.TP 1i
.BI \-c " cleartime"
set the clear sleep time to
.I cleartime
seconds.
.SH EXAMPLES
.IP
.B
nd -r /dev/ptyqf telnet nos
.LP
will make the device
.I /dev/ttyqf
a direct connection
to the
.B telnet
session to the host
.IR nos .
The connection will be respawned
everytime the
.I telnet
dies.
.IP
.B
kill `cat /etc/tcpcon.d/ptyqf`
.LP
will drop the connection established in
the previous example.
.IP
.B
nd tcpcon \-l /dev/ptyqe terminal_server 2000
.LP
will make the device
.I /dev/ttyqe
a direct connection
to the
the
.B TCP
port
2000
on the host
.IR terminal_server .
.IP
.B
nd \-l /dev/ptyqd tcpserv 2000
.LP
will make the device
.I /dev/ttyqd
a direct connection
to any client which connects to
.B TCP
port
2000.
.SH SIGNALS
.TP 1i
SIGHUP
Sends a SIGTERM at the process group associated
with
.IR command
and restarts
.IR command .
.TP 1i
SIGTERM
Sends a SIGTERM at the process group associated
with
.I command
and exits.
.SH "SEE ALSO"
.BR tcpserv (1),
.BR tcpcon (1),
.BR telnet (1),
.BR pty (7),
.BR inittab (4).
.SH FILES
.PD 0
.TP 2i
/etc/services
List of ports and services
.TP 2i
/etc/hosts
List of hosts
.TP 2i
/etc/inittab
Script for init processes
.PD
SHAR_EOF
fi
if test -f 'nd.c'
then
	echo shar: "will not over-write existing file 'nd.c'"
else
cat << \SHAR_EOF > 'nd.c'
/*
	Written by Ross Cartlidge (rossc@extro.ucc.su.oz)
	University Computer Service
	March 1989

	tcpcon - Program to connect a tty to a tcp socket
	Developed on a MIPS M/2000 running SysVr3
	Ported to BSD/SUN-OS
*/
#include	<fcntl.h>
#include	<sys/ioctl.h>
#include	<sys/signal.h>
#include	<sys/types.h>
#include	<syslog.h>
#include	<errno.h>
#include	<stdio.h>
#include	<string.h>

#if defined(SYSTYPE_BSD43)
#define sigset signal
#define sighold(s) sigblock(sigmask(s))
#define sigrelse(s)	sigsetmask(sigsetmask(-1) & ~sigmask(s))
#endif

int		pid;
int		to;
int		term;
char		*piddir;

main(argc, argv)
int	argc;
char	*argv[];
{
	int		i;
	char		sh_c[2048];
	int		ret;
	char		*dev		= (char *)0;
	int		failtime	= 15; /* > 2m/10 for init */
	int		cleantime	= 2; /* tcp connection to cleanup*/
	int		respawn		= 0; /* respawn process*/
	char		*tag		= (char *)0;
	int		c;
	int		errflg		= 0;
	int		retval;
	void		terminate();
	void		timeout();
	extern int	errno;
	extern char	*sys_errlist[];
	extern char	*optarg;
	extern int	optind;

	openlog(argv[0], 0,  LOG_LOCAL0);
	while ((c = getopt(argc, argv, "rl:f:c:d:t:")) != -1)
		switch (c)
		{
		case 'f':
			failtime = atoi(optarg);
			break;
		case 'c':
			cleantime = atoi(optarg);
			break;
		case 'l':
			dev = optarg;
			break;
		case 'd':
			piddir = optarg;
			break;
		case 't':
			tag = optarg;
			break;
		case 'r':
			respawn++;
			break;
		case '?':
			errflg++;
		}
	if (errflg || optind >= argc)
	{
		syslog(LOG_ERR, "Usage: %s [ -d <pty> ] <command>", argv[0]);
		exit(2);
	}
	strcpy(sh_c, "exec");
	for (i = optind; i < argc; i++)
	{
		strcat(sh_c, " ");
		strcat(sh_c, argv[i]);
	}
	do
	{
		sighold(SIGTERM);
		sighold(SIGHUP);
		sigset(SIGTERM, terminate);
		sigset(SIGHUP, terminate);
		if (pid = fork())
		{
			char	pidf[64];
			FILE	*pidfs;

			if (piddir)
			{
				if (!tag)
				{
					if (dev)
					{
						if (tag = strrchr(dev , '/'))
							tag++;
						else
							tag = dev;
						sprintf(pidf, "%s/%s", piddir, tag);
					}
					else
						sprintf(pidf, "%s/pid.%d", piddir, pid);
				}
				else
					sprintf(pidf, "%s/%s", piddir, tag);
				if ((pidfs = fopen(pidf, "w")) == NULL)
					syslog(LOG_ERR, "open(%s) - %s", pidf, sys_errlist[errno]);
				else
				{
					fprintf(pidfs, "%d\n", pid);
					fclose(pidfs);
				}
			}
			if (failtime > 0)
			{
				sigset(SIGALRM, timeout);
				alarm(failtime);
			}
			else
				to = 1;
			sigrelse(SIGTERM);
			sigrelse(SIGHUP);
			while (wait(&ret) != -1 || errno == EINTR)
				;
			if ((ret & 0xff) == 0)
			{
				if ((ret >> 8 & 0xff) != 0)
				{
					unlink(pidf);
					syslog(LOG_ERR, "Failed(%d) %s", ret >> 8, sh_c);
					sighold(SIGALRM);
					while (!to)
						sigpause(SIGALRM);
					sigrelse(SIGALRM);
					retval = 1;
					continue;
				}
				else
					syslog(LOG_DEBUG, "Completed %s", sh_c);
			}
			else
				syslog(LOG_DEBUG, "Killed(%d) %s", ret, sh_c);
			unlink(pidf);
			sleep(cleantime);
			retval = 0;
			continue;
		}
#if defined(SYSTYPE_BSD43)
		ioctl(0, TIOCNOTTY, 0);
		setpgrp(0, getpid());
#endif
#if defined(SYSTYPE_SYSV)
		setpgrp();
#endif
		close(0);
		close(1);
		close(2);
		sigset(SIGTERM, SIG_DFL);
		sigset(SIGHUP, SIG_DFL);
		sigrelse(SIGTERM);
		sigrelse(SIGHUP);
		if (dev)
		{
			if (open(dev, O_RDWR) == -1)
			{
				syslog(LOG_ERR, "open(%s) - %s", dev, sys_errlist[errno]);
				exit(2);
			}
			dup(0);
			dup(0);
		}
		else
		{
			open("/dev/null", O_RDONLY);
			open("/dev/null", O_WRONLY);
			dup(1);
		}
		syslog(LOG_DEBUG, "Started %s", sh_c);
		execl("/bin/sh", "sh", "-c", sh_c, (char *)0);
		syslog(LOG_ERR, "Exec failed %s", sh_c);
	}
 while (!term);
}

void
terminate(s)
int	s;
{
	if (s == SIGTERM)
		term = 1;
	kill(-pid, SIGTERM);
}

void
timeout(s)
int	s;
{
	to = 1;
}
SHAR_EOF
fi
if test -f 'tcpcon.1'
then
	echo shar: "will not over-write existing file 'tcpcon.1'"
else
cat << \SHAR_EOF > 'tcpcon.1'
.TH TCPCON 1 "April 1989"
.SH NAME
tcpcon \- Connect to a TCP socket
.SH SYNOPSIS
.B tcpcon
[
.B \-a
] 
[
.B \-l
pty
] 
[
.B \-k
tty
] 
[
.B \-t
mintime
] 
[
.B \-r
minreads
] 
[
.B \-u
] 
.I host
.I port
.SH DESCRIPTION
.B Tcpcon
sets up a
.B TCP
connection to
.I host
on port number
.IR port ,
forwarding standard input down the connection
and writing data from the connection
to standard output.
No data is sent down the connection until
either
.I minreads
have been received
or
.I mintime
has expired.
This is because many terminal servers
accept connections to send information
such as
.B "Host Busy"
and then close the connection.
Data sent down these transient connections
would be lost.
.PP
It is is usually used with
.BR nd (1)
to attach a
.B TCP
connection to a device.
.SH OPTIONS
.TP 1i
.BI \-a
Set socket connection in
.B KEEPALIVE
mode so that the connection will die
if the other side goes down.
.TP 1i
.BI \-l " pty"
Attach the TCP connection
to
.I pty
rather than standard input and output.
Only open
.I pty
after
.I mintime
or
.I minreads
has occurred.
This will ensure that the slave will
block until a reliable
connection is created.
.TP 1i
.BI \-k " tty"
Open
.I tty
after setting up the TCP connection
so that the connection will be kept
open when other processes close the
.IR tty .
If
this option is specified
.I tty
should be the slave partner to
the device specified in the
.B -l
option.
.TP 1i
.BI \-t " mintime"
Set the minimum time 
a connection must be up before
sending characters down the connection to
.I mintime
seconds.
.TP 1i
.BI \-r " minreads"
Set the minimum number of reads received 
before
sending characters down the connection to
.I mintime
seconds.
.TP 1i
.BI \-u
connect to a UDP socket instead of a TCP socket.
.SH EXAMPLES
.IP
.B
tcpcon -l /dev/ptyqe localhost smtp
.LP
connect to the
.B smtp
server on the local machine
and attach this connection to
.IR /dev/ttyqe .
.IP
.B
kill `cat /etc/tcpcon.d/ptyqe`
.LP
will drop the connection established in
the previous example.
.SH "SEE ALSO"
.BR nd (1),
.BR setsockopt (2),
.BR tcpserv (1),
.SH FILES
.PD 0
.TP 2i
/etc/hosts
List of hosts
.TP 2i
/etc/services
List of ports and services
.PD
SHAR_EOF
fi
if test -f 'tcpcon.c'
then
	echo shar: "will not over-write existing file 'tcpcon.c'"
else
cat << \SHAR_EOF > 'tcpcon.c'
/*
	Written by Ross Cartlidge (rossc@extro.ucc.su.oz)
	University Computer Service
	March 1989

	tcpcon - Program to connect a tty to a tcp socket
	Developed on a MIPS M/2000 running SysVr3
	Ported to BSD/SUN-OS
*/
#include	<fcntl.h>
#include	<sys/ioctl.h>
#include	<sys/signal.h>
#include	<sys/types.h>
#include	<syslog.h>
#include	<errno.h>
#include	<stdio.h>
#include	<string.h>

#include <sys/time.h>
#include <sys/stat.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <setjmp.h>

#define max(a,b) 	(a<b ? b : a)
#define min(a,b) 	(a>b ? b : a)

#if defined(SYSTYPE_BSD43)
#define sigset		signal
#define sighold(s)	sigblock(sigmask(s))
#define sigrelse(s)	sigsetmask(sigsetmask(-1) & ~sigmask(s))
extern int		errno;
#endif

#if !defined(FD_SET)
#define	fd_set	int
#define	FD_SET(n,p)	(*(p) |= 1 << (n))
#define	FD_CLR(n,p)	(*(p) &= ~(1 << (n)))
#define	FD_ISSET(n,p)	(*(p) & 1 << (n))
#define	FD_ZERO(p)	(*(p) = 0)
#endif

#define	BUFSIZE	1024

struct buf
{
	char	buf[BUFSIZE];
	int	cnt;
};

jmp_buf	env;
int	keepalive	= 0;
int	pid;

main(argc, argv)
int	argc;
char	*argv[];
{
	struct hostent		*host;
	struct servent		*serv;
	struct sockaddr_in	sin;
	int			s;
	int			i;
	int			r;
	char			perror_fmt[128];
	char			usage[128];
	int			p;
	fd_set			rfds;
	fd_set			efds;
	fd_set			wfds;
	int			mintime		= 2;
	int			minreads	= 2;
	char			*dev		= (char *)0;
	char			*kdev		= (char *)0;
	int			errflg		= 0;
	void			terminate();
	int			c;
	int			status;
	struct buf		*bufs;
	int			timeout();
	int			con_type	= SOCK_STREAM;
	extern char		*optarg;
	extern int		optind;

	sprintf(perror_fmt, "PERROR_FMT=%s: %%t %%s%%m - (%%e)", argv[0]);
	sprintf
	(
		usage,
		"USAGE: %s [-a] [-t mintime ] [-r minreads] [-l pty] [-k tty] <IP Address> <TCP Port>\n", argv[0]
	);
#if defined(SYSTYPE_SYSV)
	putenv(perror_fmt);
#endif
	while ((c = getopt(argc, argv, "at:l:r:k:u")) != -1)
		switch (c)
		{
		case 'u':
			con_type =  SOCK_DGRAM;
			break;
		case 'a':
			keepalive = 1;
			break;
		case 'k':
			kdev = optarg;
			break;
		case 't':
			mintime = atoi(optarg);
			break;
		case 'r':
			minreads = atoi(optarg);
			break;
		case 'l':
			dev = optarg;
			break;
		case '?':
			errflg++;
		}
	if (errflg || optind + 1 >= argc)
	{
		fputs(usage, stderr);
		exit(2);
	}
	if ((sin.sin_addr.s_addr = inet_addr(argv[optind])) != -1)
		sin.sin_family = AF_INET;
	else
	{
		if (host = gethostbyname(argv[optind]))
		{
			sin.sin_family = host->h_addrtype;
			memcpy(&sin.sin_addr.s_addr, host->h_addr, host->h_length);
		}
		else
		{
			fprintf
			(
				stderr,
				"%s: %s: unknown host\n",
				argv[0],
				argv[optind]
			);
			exit(2);
		}
	}
	if (serv = getservbyname(argv[optind + 1], "tcp"))
		sin.sin_port = serv->s_port;
	else
		if
		(
			(
				sin.sin_port
				=
				htons
				(
					(short)strtol(argv[optind + 1],
					(char **)0, 0)
				)
			)
			<=
			0
		)
		{
			fprintf
			(
				stderr,
				"%s: %s: unknown service\n",
				argv[0],
				argv[optind + 1]
			);
			exit(2);
		}
	if ((s = connectsocket(&sin, con_type)) < 0)
		exit(1);
	if ((bufs = (struct buf *)calloc(max(minreads, 1) ,sizeof (struct buf))) < 0)
	{
		perror("calloc bufs");
		exit(1);
	}
	sigset(SIGALRM, timeout);
	sighold(SIGALRM);
	alarm(mintime);
	if (setjmp(env) == 0)
		for (i = 0; i < minreads; i++)
		{
			sigrelse(SIGALRM);
			r = read(s, bufs[i].buf, BUFSIZE);
			sighold(SIGALRM);
			if (r <= 0)
				exit(1);
			else
				bufs[i].cnt = r;
		}
	alarm(0);
	sigset(SIGALRM, SIG_IGN);
	sigrelse(SIGALRM);
	if (dev)
	{
		close(0);
		close(1);
		sighold(SIGTERM);
		if (pid = fork())
		{
			sigset(SIGTERM, terminate);
			sigrelse(SIGTERM);
			if (kdev != (char *)0 && open(kdev, O_RDWR) == -1)
				kill(pid, SIGTERM);
#if defined(SYSTYPE_BSD43)
			ioctl(0, TIOCNOTTY, 0);
			setpgrp(0, getpid());
#endif
#if defined(SYSTYPE_SYSV)
			setpgrp();
#endif
			while (wait(&status) != -1 || errno == EINTR)
				;
			if ((status & 0xff) == 0 && (status >> 8 & 0xff))
				exit(status >> 8 & 0xff);
			else
				exit(0);
		}
#if defined(SYSTYPE_BSD43)
		ioctl(0, TIOCNOTTY, 0);
		setpgrp(0, getpid());
#endif
#if defined(SYSTYPE_SYSV)
		setpgrp();
#endif
		sigrelse(SIGTERM);
		if (open(dev, O_RDWR) == -1)
		{
			perror(dev);
			exit(1);
		}
		dup(0);
	}
	for (i = 0; i < minreads && bufs[i].cnt > 0; i++)
		if (write(1, bufs[i].buf, bufs[i].cnt) != bufs[i].cnt)
			exit(0);
	for (;;)
	{
		char	*buf	= bufs[0].buf;

		FD_ZERO(&rfds);
		FD_ZERO(&efds);
		FD_SET(0, &rfds);
		FD_SET(s, &rfds);
		FD_SET(0, &efds);
		FD_SET(s, &efds);
		select(s + 1, &rfds, (fd_set *)0, &efds, (struct timeval *)0);
		if (FD_ISSET(s, &rfds) || FD_ISSET(s, &efds))
		{
			if ((r = read(s, buf, BUFSIZE)) <= 0)
			{
				perror("read");
				exit(0);
			}
			if (write(1, buf, r) != r)
			{
				perror("write");
				exit(0);
			}
		}
		if ((FD_ISSET(0, &rfds) || FD_ISSET(0, &efds)))
		{
			if ((r = read(0, buf, BUFSIZE)) <= 0)
			{
				perror("read");
				exit(0);
			}
			if (write(s, buf, r) != r)
			{
				perror("write");
				exit(0);
			}
		}
	}
}

connectsocket(sinp, t)
struct sockaddr_in	*sinp;
int			t;
{
	int	s;
	int	l;
	int	sockopt;

	if ((s = socket(AF_INET, t, 0)) <  0)
	{
		perror("socket");
		return -1;
	}
	l = sizeof *sinp;
	if (connect(s, sinp, l) < 0)
	{
		perror("connect");
		return -1;
	}
	if
	(
		t == SOCK_STREAM
		&&
		keepalive == 1
		&&
		setsockopt
		(
			s,
			SOL_SOCKET,
			SO_KEEPALIVE,
			(sockopt = 1, (char *)&sockopt),
			sizeof sockopt
		)
		<
		0
	)
	{
		perror("setsockopt");
		return -1;
	}
	return s;
}

timeout(s)
int	s;
{
	longjmp(env, 1);
}

void
terminate(s)
int	s;
{
	kill(pid, s);
}
SHAR_EOF
fi
if test -f 'tcpserv.1'
then
	echo shar: "will not over-write existing file 'tcpserv.1'"
else
cat << \SHAR_EOF > 'tcpserv.1'
.TH TCPSERV 1 "April 1989"
.SH NAME
tcpserv \- accept a TCP connection
.SH SYNOPSIS
.B tcpserv
[
.B \-u
] 
.I port
.SH DESCRIPTION
.B Tcpserv
accepts a
.B TCP
connection on
on port number
.IR port ,
forwarding standard input down the connection
and writing data from the connection
to standard output.
.PP
It is usually used with
.BR nd (1)
to attach a
.B TCP
connection to a device.
.SH OPTIONS
.BI \-u
service a UDP socket instead of a TCP socket.
.SH EXAMPLES
.IP
.B
tcpserv smtp
.LP
accepts connections to the
.B smtp
port on the local machine.
.SH "SEE ALSO"
.BR nd (1),
.BR tcpcon (1).
.SH FILES
.PD 0
.TP 2i
/etc/services
List of ports and services
.PD
.SH BUGS
SHAR_EOF
fi
if test -f 'tcpserv.c'
then
	echo shar: "will not over-write existing file 'tcpserv.c'"
else
cat << \SHAR_EOF > 'tcpserv.c'
/*
	Written by Ross Cartlidge (rossc@extro.ucc.su.oz)
	University Computer Service
	March 1989

*/
#include <sys/types.h>
#include <sys/time.h>
#include <sys/stat.h>
#include <signal.h>
#include <sys/fcntl.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <stdio.h>

#if !defined(FD_SET)
#define	fd_set	int
#define	FD_SET(n,p)	(*(p) |= 1 << (n))
#define	FD_CLR(n,p)	(*(p) &= ~(1 << (n)))
#define	FD_ISSET(n,p)	(*(p) & 1 << (n))
#define	FD_ZERO(p)	(*(p) = 0)
#endif


#define	BUFSIZE	1024
char			buf[BUFSIZE];

main(argc, argv)
int	argc;
char	*argv[];
{
	struct sockaddr_in	sin;
	struct sockaddr_in	from;
	int			fromlen;
	int			s;
	int			c;
	int			errflg		= 0;
	int			r;
	char			perror_fmt[128];
	char			usage[128];
	int			nfds;
	fd_set			rfds;
	fd_set			efds;
	int			sockopt;
	int			con_type	= SOCK_STREAM;
	extern char		*optarg;
	extern int		optind;

	sprintf(perror_fmt, "PERROR_FMT=%s: %%t %%s%%m - (%%e)", argv[0]);
	sprintf(usage, "USAGE: %s <TCP Port>\n", argv[0]);
#if defined(SYSTYPE_SYSV)
	putenv(perror_fmt);
#endif
	while ((c = getopt(argc, argv, "u")) != -1)
		switch (c)
		{
		case 'u':
			con_type =  SOCK_DGRAM;
			break;
		case '?':
			errflg++;
			break;
		}
	if (errflg || optind  >= argc)
	{
		fputs(usage, stderr);
		exit(2);
	}
	if ((s = socket(AF_INET, con_type, 0)) < 0)
	{
		perror("socket");
		exit(1);
	}
	sin.sin_family = AF_INET;
	sin.sin_addr.s_addr = INADDR_ANY;
	if ((sin.sin_port = htons((short)strtol(argv[optind], (char **)0, 0))) <= 0)
	{
		fputs(usage, stderr);
		exit(2);
	}
	if (bind(s, (struct sockaddr *)&sin, sizeof sin) < 0)
	{
		perror("bind");
		exit(1);
	}
	if (con_type == SOCK_STREAM)
	{
		listen(s, 5);
		if ((s = accept(s, (struct sockaddr *)0, (int *)0)) < 0)
		{
			perror("accept");
			exit(1);
		}
		if
		(
			setsockopt
			(
				s,
				SOL_SOCKET,
				SO_KEEPALIVE,
				(sockopt = 1, (char *)&sockopt),
				sizeof sockopt
			)
			<
			0
		)
		{
			perror("setsockopt");
			exit(1);
		}
	}
	else
	{
		fromlen = sizeof from;
		if ((r = recvfrom(s, buf, sizeof buf, 0, &from , &fromlen)) == -1)
		{
			perror("recvfom");
			exit(1);
		}
		if (connect(s, &from, sizeof from) == -1)
		{
			perror("connect");
			exit(1);
		}
		if (write(1, buf, r) != r)
		{
			perror("write");
			exit(0);
		}
	}
	for (;;)
	{
		FD_ZERO(&rfds);
		FD_ZERO(&efds);
		FD_SET(0, &rfds);
		FD_SET(s, &rfds);
		FD_SET(0, &efds);
		FD_SET(s, &efds);
		select(s + 1, &rfds, (fd_set *)0, &efds, (struct timeval *)0);
		if (FD_ISSET(0, &rfds) || FD_ISSET(0, &efds))
		{
			if ((r = read(0, buf, BUFSIZE)) <= 0)
			{
				perror("read");
				exit(0);
			}
			if (write(s, buf, r) != r)
			{
				perror("write");
				exit(0);
			}
		}
		if (FD_ISSET(s, &rfds) || FD_ISSET(s, &efds))
		{
			if ((r = read(s, buf, BUFSIZE)) <= 0)
			{
				perror("read");
				exit(0);
			}
			if (write(1, buf, r) != r)
			{
				perror("write");
				exit(0);
			}
		}
	}
}
SHAR_EOF
fi
exit 0
#	End of shell archive
-- 
________________________________________________________________________
Ross Rodney Cartlidge			    |   rossc@extro.ucc.su.oz.au
University Computing Service, H08	    |   Phone:     +61 2 6923497
University of Sydney, NSW 2006, Australia   |   FAX:       +61 2 6606557

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 89 14:29:00 GMT
From:      RLR@JHUVMS.BITNET (RLR)
To:        comp.protocols.tcp-ip
Subject:   Re: Traffic Sensitive SPF Routing is NOT too hard!

Whats's a reference for the maximum entropy routing algorithm? Ron Ray

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 89 16:21:33 GMT
From:      lixia@ARISIA.XEROX.COM (Lixia Zhang)
To:        comp.protocols.tcp-ip
Subject:   Re:  Xerox Etherphone experiments?

Yes PARC did an Etherphone project a few years ago (headed by Dan Swinehart,
swinehart.pa@xerox.com).  The Etherphones are still in use today at PARC.
There is a tech report (CSL-89-2), "Etherphone: Collected Papers 1987-1988".

Lixia

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 89 18:02:22 GMT
From:      jpeck@hpspdra.HP.COM (Joe Peck)
To:        comp.protocols.tcp-ip
Subject:   Re: managing addresses

Many of the protocol analyzers (HP4972, Network General Sniffer, Excelan,
Spider Systems, etc.) will compile a list of all ethernet source addresses 
seen and even keep track of which nodes generate the most traffic.  

The HP LanProbe keeps a database of ethernet addresses and also learns
the IP addresses of nodes.  The database can also age (remove or show as
inactive) nodes that haven't transmitted in a given time interval, e.g.
the past 10 days.  When used in conjunction with a little extra hardware,
called the Node Locator, the LanProbe can also determine a node's cable,
position.  This can be quite useful for mapping your net, figuring out 
what nodes are behind bridges/repeaters, and for finding cable fault locations 
without having to walk the cable.

I believe Hughes Lan Systems (formerly Sytek) has something similar,
although I don't know if it includes node distance information.

The LanProbe/ProbeView system and the HLS product differ from
traditional protocol analyzers in that the information is collected 
from distributed sites and then communicated over the net to a central 
information manager/database, which in turn presents the
information graphically, usually in a windowed application.

Send me mail if you'd like some LanProbe product literature.

Joe Peck
HP Design Engineer (on the LanProbe product)

Disclaimer: I currently work on the LanProbe product, and before that I
	    worked on the HP4972 Lan protocol analyzer.

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 89 20:32:01 GMT
From:      wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 ho95c.att.com!wcs)
To:        comp.unix.questions,comp.unix.wizards,comp.protocols.tcp-ip,comp.periphs
Subject:   Re: WANTED: IBM SNA <-> UNIX Connection

Every major computer vendor has an interface to Big Iron, because
you can't avoid dealing with IBM.  Minimal support is 3270 coax
support and some kind of RJE; SNA and LU6.2 are not uncommon.
If you want more interesting support, some vendors support
channel-attached connections, but you can also get tcp/ip for your
mainframe.  A lot of mail systems support interfaces from X.400 or
other UNIX mail to PROFS and DISOSS mail, and there are a number of
3270-emulation and DBMS interfaces around.
-- 
# Bill Stewart, AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 api.att.com!wcs

#		We did it for the formlessness ...

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 89 00:51:54 GMT
From:      barmar@Think.COM
To:        comp.protocols.tcp-ip
Subject:   Re: managing addresses

In article <8912071252.AA22638@gaak.LCS.MIT.EDU> MAP@LCS.MIT.EDU (Michael A. Patton) writes:
>I manage a network of around 500 hosts and don't know
>or have record (+) of any of the EtherNet addresses.

If you make use of Reverse ARP on your network, then the RARP daemon needs
a database of Ethernet addresses.  Such a database is also useful for
network debugging tools and devices.
Barry Margolin, Thinking Machines Corp.

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

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 89 01:08:43 GMT
From:      barmar@Think.COM
To:        comp.protocols.tcp-ip
Subject:   Re: more on Fletcher

In article <8912071916.AA23996@beaches.hub.toronto.edu> thomson@hub.toronto.edu (Brian Thomson) writes:
>In my view, data integrity can be effectively provided by chaining
>together reliable links
 ...
>When does this approach fail?  Obviously, if your packets are going
>over a network you know nothing about, or have no control over, it is not
>safe to make assumptions about its error properties.  In that case,
>higher-level error detection does make sense, but it should be provided
>as an option, or perhaps as a gateway function, and it need not be
>application-to-application.

This is probably true.  It does mean that the interfaces between the
transport and link layers must provide ways of querying about the error
properties of the path that datagrams will take.  This, however, implies that
the route is fixed, or at least can be determined ahead of time.  IP uses
dynamic routing at the packet level (caller-specified routes are possible,
but out of the ordinary).  A call to TCP_WRITE may result in multiple IP
datagrams, which may be fragmented into multiple link layer packets, each
of which may take a different route.

Also, there are very few links with the kind of reliability most
applications would like.  Ethernet is usually considered a reliable medium,
but when we had UDP checksums turned off on our Suns I saw lots of NFS
problems between hosts on the same Ethernet.
Barry Margolin, Thinking Machines Corp.

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

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 89 02:19:22 GMT
From:      stine@SPARTA.COM (Robert Havens Stine)
To:        comp.protocols.tcp-ip
Subject:   Loopy routes

An ftp connection between heisenberg.sparta.com &
devvax.tn.cornell.edu hung, so I ran traceroute from a nearby host
(narnia.saic.com) to see what was going on.  Answer: duelling
gateways!

traceroute output follows, from narnia.saic.com toward
devvax.tn.cornell.edu, on 8 Dec, about 20:50 EST:

 1  MCLEAN-MB.DDN.MIL (10.3.0.111)  80 ms  220 ms  120 ms
 2  MCLEAN-MB.DDN.MIL (10.3.0.111)  100 ms  120 ms  120 ms
 3  CAMBRIDGE-MB.DDN.MIL (10.3.0.5)  1060 ms  1020 ms  800 ms
 4  MCLEAN-MB.DDN.MIL (26.20.0.17)  1000 ms  660 ms  640 ms
 5  CAMBRIDGE-MB.DDN.MIL (10.3.0.5)  2120 ms  1200 ms *
 6  MCLEAN-MB.DDN.MIL (26.20.0.17)  1600 ms  1620 ms  1900 ms
 7  CAMBRIDGE-MB.DDN.MIL (10.3.0.5)  1580 ms  1620 ms  1740 ms
 8  * * *

What a ride!

In fairness, I ought to add that coherent routes were reestablished in
20-30 minutes.

Note: the McLean mailbridge entry is repeated at hops 1 & 2 because
vienna.saic.com, narnia's entry gateway, does not check the TTL field.

- Bob Stine

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 1989 10:54-EST
From:      CERF@A.ISI.EDU
To:        woody@SAIC.COM
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: CapNet
check with Marty Schoffstall: schoff@stonewall.nyser.net or
Schoff@solbourne.nyser.net.

Vint
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 1989 11:15-EST
From:      CERF@A.ISI.EDU
To:        dcrocker@DECWRL.DEC.COM
Cc:        haverty@BBN.COM, tcp-ip@NIC.DDN.MIL
Subject:   Re: TCP Fletcher Checksum Option
Dave,

times are changing. The kinds of corruption we once  fought: line noise,
are being replaced by packet loss due to congestion or slips and
peculiarities which David Tennenhouse (LCS/MIT) warns may be visited
upon us by improperly implemented or functioning ATM switches: packet
internal reordering at the cell level.

It is by no means clear that reordering at the cell level will be
detected by the ATMs or by links level algorithms sending the
packets assembled from cells to the hosts since the link level
checksums would be recomputed AFTER reassembly, most likely.

At any rate, considering the question of integrity checking
in the current and anticipated internet environment seems
timely.

Vint
-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 89 06:41:33 GMT
From:      yee@TRIDENT.ARC.NASA.GOV (Peter E. Yee)
To:        comp.protocols.tcp-ip
Subject:   The Open Book



Well, I just went out and bought Marshall T. Rose's new book, "The Open Book:
A Practical Perspective on OSI."  In a word, wow.  This is the first time I've
read a book on OSI that actually makes sense.  I've read plenty of other
explanations of OSI that look they were written by ISO committee members --
indecipherable.  "The Open Book" presents gives a clear explanation of
the OSI layers.  More importantly it's brave enough to present the issues
that went into the design (some would say misdesign) of the OSI protocols.
Rose takes an unusual approach by including soapboxes (actually delimited
with the word "soap" in a box) in his text.  In the soapbox sections you get
to read about the real reasons for some of the weird choices made in develop-
ment of the OSI protocols.

The book itself is divided into five sections, and is structured in such a
way that it could be used as the textbook in a networking course, as a
supplemental source.

The first section is called an "Introduction to OSI" and gives a brief
overview of OSI, networking in general, and some of the players involved.

The second section is titled "End-to-End Services" and addresses network
and transport services.  If you thought OSI was supposed to be interoperable
right out of the box, wait until you read this section.

"Application Services" is the name of the third section.  In this section,
Rose explains session, presentation, and application services, as well as
abstract syntax, and some of the major OSI components (Directory, MHS,
FTAM).

The fourth section is "Transition to OSI" and gives a taxonmy of approachs to
working OSI in a heavily TCP/IP world.  Rose lists several alternative
approaches and points out his preferred methods.

"The Final Soapbox" is the last section in the book, and is as its name implies
a sermon on problems and pitfalls of the standards process and its players.

What really impressed me about this book was the high-level of practical
information on OSI.  If I wanted dry reading I'd just order from ISO.
Rose has taken a (overly) complex subject and rendered it understandable.
In addition he shows how OSI and TCP/IP can be made to work together
(inevitable, I guess).  This probably irks the ISORMites, but let's face
it, after reading this book, you'll probably think twice about running
a full OSI stack.  Of course, thise may not have been his actual intention. :-)

Anyhow, for those interested in getting a copy, I've entered the following
from the copyright page:

	Rose, Marshall T.
	The Open Book: A Practical Perspective on OSI
	ISBN 0-13-643016-3
	Copyright 1990, Prentice-Hall Inc., Englewood Cliffs, New Jersey

Although the copyright date is 1990, the book has apparently been available
since October.  I wish I had known earlier so that I could have gotten my
copy earlier.

						-Peter Yee
						yee@ames.arc.nasa.gov
						ames!yee

PS I don't claim to be an expert on these things.  You got my honest report
on a book I really like.  I also don't claim to represent NASA in giving
this report.

PPS Differences of opinion gladly entertained, flames ignored.

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 89 07:07:18 GMT
From:      srg@quick.COM (Spencer Garrett)
To:        comp.protocols.tcp-ip
Subject:   Re: more on Fletcher


The problem is worse than might be imagined.  In relying on link-level
checksums not only are you vulnerable to errors occurring between
your application or its peer and their respective link-level
interfaces, but also on the same pathway *and the software* on
every gateway in between.  Given the choice between a) computing
checksums/CRC's every time and b) trying to figure out/negotiate
when to use them my inclination runs strongly toward the former.
Given how easy it is to do CRC's in software (even 32-bit ones)
I, for one, wish we could somehow convert to them instead of the
weak checksum presently in use, but failing that I sure wish
the current checksums weren't optional.  Are you listening, Sun?

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 1989 17:13-PST
From:      Steve Deering <deering@pescadero.stanford.edu>
To:        sklower%okeeffe.Berkeley.EDU@ucbvax.Berkeley.EDU (Keith Sklower)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: more on Fletcher
Keith,

My reason for wanting the checksum at the end of the packet is to allow
a high-performance (hardware-assisted) implementation to compute the
checksum on the fly as it copies a packet onto the wire, tacking it
on at the end.  This eliminates one expensive pass over the packet.  I
believe that Ultra's speedy TP-4 implementation places the checksum at
the end for the same reason.

> 	It wouldn't be hard to come up with a minor modification to
> the VMTP checksum having the same property of position independence,
> which would be almost as fast to compute as the TCP checksum.

We'd welcome any suggestions.  We did consider using 16-bit Fletcher
(i.e., two 16-bit accumulators, yielding a 32-bit result), but as you
mentioned, it would be several times slower than the TCP checksum.
The TCP checksum takes basically one instruction per 32-bit word on
common processors (using add-with-carry and loop unrolling); it's
pretty hard to beat that.  VMTP's checksum is a few percent slower
than TCP's; it's not as strong as we would like.

Steve
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 89 12:06:48 GMT
From:      aras@dr.uucp (Arne Asplem)
To:        comp.protocols.tcp-ip
Subject:   KA9Q

I've finally succeded to compile and link the ka9q SLIP package, on an
Altos 1000 Running System V Release 3.

The ka9q.tar.Z file I received had an incorrect makefile, and NO DOC !
I've made my own makefile, and ka9q seems to work properly, but since
I don't have any documentation on how to configure or even use Phil
Karn's Internet Package, I need some help !!!

I'm running KA9Q version v871225.33q - is this the latest ???

Can anyone E-mail me the doc's ???

KA9Q also complain about "./startup.net : cannot open" !
Can anyone send me a typical startup.net file for SVR3 ?

  -- Arne

/* Arne Asplem, Consultix, P.O.BOX 1367, N-1401 SKI, NORWAY
 * Phone: +47-9-876844  Fax: +47-9-876766  Pager: 096-43139
 * E-mail: aras@dr.uucp or ..!mcsun!ndosl!dr!aras
 */

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 89 15:54:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: CapNet

check with Marty Schoffstall: schoff@stonewall.nyser.net or
Schoff@solbourne.nyser.net.

Vint

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 89 16:15:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Fletcher Checksum Option

Dave,

times are changing. The kinds of corruption we once  fought: line noise,
are being replaced by packet loss due to congestion or slips and
peculiarities which David Tennenhouse (LCS/MIT) warns may be visited
upon us by improperly implemented or functioning ATM switches: packet
internal reordering at the cell level.

It is by no means clear that reordering at the cell level will be
detected by the ATMs or by links level algorithms sending the
packets assembled from cells to the hosts since the link level
checksums would be recomputed AFTER reassembly, most likely.

At any rate, considering the question of integrity checking
in the current and anticipated internet environment seems
timely.

Vint

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 89 23:13:46 GMT
From:      allen@sulaco.Sigma.COM (Allen Gwinn)
To:        comp.protocols.tcp-ip
Subject:   KA9Q TCP/IP on SCO Xenix 286

Has anybody been really successful in getting KA9Q's TCP/IP package to
work under SCO Xenix 286 as far a slip is concerned?  What is the
latest greatest and where can it be picked up (along with a good 
makefile)?

Also, does anybody know of a good off-the-shelf or public domain
implementation with such things as telnet server, ftp server (I think
I'm dreaming, but nfs server :-)

Please send me some email.  Things are too quiet around here.

-- 
Allen Gwinn  sulaco!allen      DISCLAIMER: Nobody else would WANT my opinions.
"Slow down!  You're driving too fast!  You've had 2 beers... I don't want to
 die."  - My wife

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 89 00:20:06 GMT
From:      baker@VITAM6.UUCP (Fred Baker)
To:        comp.protocols.tcp-ip
Subject:   CRCs?

CRCs may be easy to algorithmically describe in software, but to do them
rapidly enough to have time left over to do anything else (like shuttle
messages around) is, um, less than trivial.  Careful, folks

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 89 01:13:00 GMT
From:      deering@PESCADERO.STANFORD.EDU (Steve Deering)
To:        comp.protocols.tcp-ip
Subject:   Re: more on Fletcher

Keith,

My reason for wanting the checksum at the end of the packet is to allow
a high-performance (hardware-assisted) implementation to compute the
checksum on the fly as it copies a packet onto the wire, tacking it
on at the end.  This eliminates one expensive pass over the packet.  I
believe that Ultra's speedy TP-4 implementation places the checksum at
the end for the same reason.

> 	It wouldn't be hard to come up with a minor modification to
> the VMTP checksum having the same property of position independence,
> which would be almost as fast to compute as the TCP checksum.

We'd welcome any suggestions.  We did consider using 16-bit Fletcher
(i.e., two 16-bit accumulators, yielding a 32-bit result), but as you
mentioned, it would be several times slower than the TCP checksum.
The TCP checksum takes basically one instruction per 32-bit word on
common processors (using add-with-carry and loop unrolling); it's
pretty hard to beat that.  VMTP's checksum is a few percent slower
than TCP's; it's not as strong as we would like.

Steve

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 89 08:04:35 GMT
From:      srg@quick.COM (Spencer Garrett)
To:        comp.protocols.tcp-ip
Subject:   Re: CRCs?

In article <8912100021.AA23753@uunet.uu.net>, baker@VITAM6.UUCP (Fred Baker) writes:
> CRCs may be easy to algorithmically describe in software, but to do them
> rapidly enough to have time left over to do anything else (like shuttle
> messages around) is, um, less than trivial.  Careful, folks

Well, fast is a relative term, of course, but I don't think crc's are
all that slow.  Here's code to do CRC-16's very rapidly.  32-bit
polynomials take the same amount of time on 32-bit machines (but
more storage - not too much in either case, though).


/* This code generates crc16 check digits a byte at a time.
 * It assumes that the low order bits will be transmitted first,
 * and consequently the low byte should be sent first when
 * the crc computation is finished.  This is the "standard" CRC16.
 * The variable corresponding to the macro argument "crc" should
 * be an unsigned short (or longer) and should be preset to zero.
 */

#define CRC(crc, c)	 crc = (crc >> 8) ^ crctab[(crc^(c)) & 0xff]

/* generated using the CRC-16 polynomial x^16 + x^15 + x^2 + 1 */

unsigned short crctab[256] = {
	0x0000, 0xc0c1, 0xc181, 0x0140, 0xc301, 0x03c0, 0x0280, 0xc241,
	0xc601, 0x06c0, 0x0780, 0xc741, 0x0500, 0xc5c1, 0xc481, 0x0440,
	0xcc01, 0x0cc0, 0x0d80, 0xcd41, 0x0f00, 0xcfc1, 0xce81, 0x0e40,
	0x0a00, 0xcac1, 0xcb81, 0x0b40, 0xc901, 0x09c0, 0x0880, 0xc841,
	0xd801, 0x18c0, 0x1980, 0xd941, 0x1b00, 0xdbc1, 0xda81, 0x1a40,
	0x1e00, 0xdec1, 0xdf81, 0x1f40, 0xdd01, 0x1dc0, 0x1c80, 0xdc41,
	0x1400, 0xd4c1, 0xd581, 0x1540, 0xd701, 0x17c0, 0x1680, 0xd641,
	0xd201, 0x12c0, 0x1380, 0xd341, 0x1100, 0xd1c1, 0xd081, 0x1040,
	0xf001, 0x30c0, 0x3180, 0xf141, 0x3300, 0xf3c1, 0xf281, 0x3240,
	0x3600, 0xf6c1, 0xf781, 0x3740, 0xf501, 0x35c0, 0x3480, 0xf441,
	0x3c00, 0xfcc1, 0xfd81, 0x3d40, 0xff01, 0x3fc0, 0x3e80, 0xfe41,
	0xfa01, 0x3ac0, 0x3b80, 0xfb41, 0x3900, 0xf9c1, 0xf881, 0x3840,
	0x2800, 0xe8c1, 0xe981, 0x2940, 0xeb01, 0x2bc0, 0x2a80, 0xea41,
	0xee01, 0x2ec0, 0x2f80, 0xef41, 0x2d00, 0xedc1, 0xec81, 0x2c40,
	0xe401, 0x24c0, 0x2580, 0xe541, 0x2700, 0xe7c1, 0xe681, 0x2640,
	0x2200, 0xe2c1, 0xe381, 0x2340, 0xe101, 0x21c0, 0x2080, 0xe041,
	0xa001, 0x60c0, 0x6180, 0xa141, 0x6300, 0xa3c1, 0xa281, 0x6240,
	0x6600, 0xa6c1, 0xa781, 0x6740, 0xa501, 0x65c0, 0x6480, 0xa441,
	0x6c00, 0xacc1, 0xad81, 0x6d40, 0xaf01, 0x6fc0, 0x6e80, 0xae41,
	0xaa01, 0x6ac0, 0x6b80, 0xab41, 0x6900, 0xa9c1, 0xa881, 0x6840,
	0x7800, 0xb8c1, 0xb981, 0x7940, 0xbb01, 0x7bc0, 0x7a80, 0xba41,
	0xbe01, 0x7ec0, 0x7f80, 0xbf41, 0x7d00, 0xbdc1, 0xbc81, 0x7c40,
	0xb401, 0x74c0, 0x7580, 0xb541, 0x7700, 0xb7c1, 0xb681, 0x7640,
	0x7200, 0xb2c1, 0xb381, 0x7340, 0xb101, 0x71c0, 0x7080, 0xb041,
	0x5000, 0x90c1, 0x9181, 0x5140, 0x9301, 0x53c0, 0x5280, 0x9241,
	0x9601, 0x56c0, 0x5780, 0x9741, 0x5500, 0x95c1, 0x9481, 0x5440,
	0x9c01, 0x5cc0, 0x5d80, 0x9d41, 0x5f00, 0x9fc1, 0x9e81, 0x5e40,
	0x5a00, 0x9ac1, 0x9b81, 0x5b40, 0x9901, 0x59c0, 0x5880, 0x9841,
	0x8801, 0x48c0, 0x4980, 0x8941, 0x4b00, 0x8bc1, 0x8a81, 0x4a40,
	0x4e00, 0x8ec1, 0x8f81, 0x4f40, 0x8d01, 0x4dc0, 0x4c80, 0x8c41,
	0x4400, 0x84c1, 0x8581, 0x4540, 0x8701, 0x47c0, 0x4680, 0x8641,
	0x8201, 0x42c0, 0x4380, 0x8341, 0x4100, 0x81c1, 0x8081, 0x4040
};

#include <stdio.h>

main()
{
	unsigned short crc;

	int i;

	crc = 0;
	while (scanf(" %x", &i) == 1)
		CRC(crc, i);
	printf("crc 0x%02x 0x%02x\n", crc & 0xFF, crc >> 8);
}

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 89 14:18:20 GMT
From:      aras@dr.uucp (Arne Asplem)
To:        comp.protocols.tcp-ip
Subject:   Re: Point-to-Point Protocol Internet-Draft

Is "The Point-to-Point Protocol" draft available by E-mail ???

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 89 02:35:30 GMT
From:      jtk@lakesys.lakesys.com (Joe Klein)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip source


Is a public domain version of TCP/IP to be had?

What is considered the best UNIX V version?

What is the price of source?

How big is the source?

Please reply via E-Mail. 


Thank you.

-- 
--
jtk@lakesys.lakesys.COM		|	"Silence alone is great;
Joseph T. Klein	399-54-1643	|	 all else is weakness."
I'm not just a number.          |                     - Alfred DeVigny

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 89 03:42:52 GMT
From:      kanai@net2.ICS.UCI.EDU (Hiroshi Kanai)
To:        comp.protocols.tcp-ip, comp.protocols.tcp-ip@net2.ICS.UCI.EDU
Cc:        kanai@net2.ICS.UCI.EDU
Subject:   American computer network

Hi,
   Does anyone know about the network structure and protocols especially
below TCP/IP of NSFNET,BITNET,INTERNET, and CSNET and relationship amog them?
Thank you.

--Hiroshi Kanai         E-mail : kanai@ics.uci.edu

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Dec 89 13:59:39 EST
From:      Brian Holmes <BHOLMES%WAYNEST1.BITNET@CORNELLC.cit.cornell.edu>
To:        TCP/IP newsgroup <TCP-IP@SRI-NIC.ARPA>
Subject:   connecting a printer to a terminal server
I'm trying to dump TCP steams to a plotter attached to a Cisco
terminal server.  I'm getting parts of the plot files I'm dumping,
but everytime I dump it, it is a little different.  I have the
baud rate set correctly and flowcontrol software enabled on the Cisco
and the plotter.  Has anyone written any code to dump data to
devices attached to terminal servers that I could take a look at?
My data looks fine from looking at our SNIFFER.  Thanks in advance!

                        Brian Holmes
                        UCC Operating Systems & Communications

PHONE:    (313) 577-3750  FAX=577-5626          Wayne State University
BITNET:   BHOLMES@WAYNEST1                      5925 Woodward
INTERNET: Brian_Holmes@UM.CC.UMICH.EDU          Detroit, MI 48202  U.S.A
-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 89 15:04:19 GMT
From:      sjg@sun0.melb.bull.oz.AU (Simon J. Gerraty)
To:        comp.protocols.tcp-ip
Subject:   Mail eXchanger - sendmail.mx help wanted

I am currently in the process of getting a network ready to
connect to the Internet.  I have a Sun running in.named -
apparently correctly, at least nslookup seems to work fine for
all the hosts etc in my domain.

Being a binary only site, I have to rely on my manuals for
information.  Trouble is named and related issues get *very*
little coverage.

I would like to get MX records working with sendmail.mx, so that
some local non-tcp networks can receive mail.

I have followed the examples such as there are, in the book, but
cannot seem to make anything interesting happen.

Could someone please point me at a decent source of information
regarding this lot?

Any info *much* appreciated.

+-----------------------------------------------------------------------------+
Simon Gerraty	          --- ACSnet:   sjg@sun0.melb.bull.oz
Bull Information Systems  --- Internet: sjg%sun0.melb.bull.oz.au@munnari.oz.au
677 Victoria Street       --- UUCP: ...!uunet!munnari!sun0.melb.bull.oz.au!sjg
Abbotsford AUSTRALIA 3067 --- Phone: +61 3 420 0927     FAX: +61 3 420 0955

#include <disclaimer>

[ imagine something *very* witty here ]
+-----------------------------------------------------------------------------+

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 89 15:33:00 GMT
From:      tebbutt@RHINO.NCSL.NIST.GOV (John Tebbutt)
To:        comp.protocols.tcp-ip
Subject:   Re:  The Open Book

Bcc: 

That was some review - are you and Marshall related, or what ?

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 89 18:58:53 GMT
From:      goldstein@delni.enet.dec.com
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Fletcher Checksum Option

In article <[A.ISI.EDU].9-Dec-89.11:15:42.CERF>, CERF@A.ISI.EDU writes...
>Dave,
> 
>times are changing. The kinds of corruption we once  fought: line noise,
>are being replaced by packet loss due to congestion or slips and
>peculiarities which David Tennenhouse (LCS/MIT) warns may be visited
>upon us by improperly implemented or functioning ATM switches: packet
>internal reordering at the cell level.
 
>It is by no means clear that reordering at the cell level will be
>detected by the ATMs or by links level algorithms sending the
>packets assembled from cells to the hosts since the link level
>checksums would be recomputed AFTER reassembly, most likely.

Indeed, the current proposals for B-ISDN use ATM cell transfer and
state, in its service description, that it _will_ preserve order.  Now
doesn't that make you confident that the implementations will never,
ever, ever, ever mis-order a cell?  The ATM cells do not contain any
sort of sequence numbers. 

The proposed "adaptation" protocol, the bottom of Layer 2 (providing the
framing and error detection services, but not retransmission) takes
data packets and splits them into cell-sized segments.  These are 
labeled first/middle/last/only and a total length indicator is stuck on 
the tail.  If each 48-octet cell's 10-bit CRC checks, and the total
number received from first to last causes a correct length indicator
reading, then you've got a valid cell.  Note that this does detect
cell drop and spurious insertion, but not misordering.  Remember also
that they promise that the network won't misorder, so they don't 
recommend a cell sequence number...

BTW I have proposed (and gotten rebuffed by the Powers That Be at 
T1S1.5, namely the AT&T & Bellcore leadership) an end-to-end datalink
protocol that has cell sequence numbers and bulk cell ack's, loosely
based on NETBLT, with a 2^14 modulus.  You can always run it or 
something else you prefer end to end across the ATM and ignore their
recommendations for adaptation, if you're not talking to a
network-provided service (i.e., the "B-ISDN CLNS", which is an L3
datagramme service running over the adaptation layer).  My impetus,
though, is to handle cell loss without having to retransmit the whole
frame.  (Can you spell 'congestion collapse'?)  Misordering detection 
comes along with that.

>At any rate, considering the question of integrity checking
>in the current and anticipated internet environment seems
>timely.

Very true...  we now have to worry about detecting cell misordering,
etc., if we don't trust the telco networks to be perfect.
       fred

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 89 18:59:39 GMT
From:      BHOLMES@WAYNEST1.BITNET (Brian Holmes)
To:        comp.protocols.tcp-ip
Subject:   connecting a printer to a terminal server

I'm trying to dump TCP steams to a plotter attached to a Cisco
terminal server.  I'm getting parts of the plot files I'm dumping,
but everytime I dump it, it is a little different.  I have the
baud rate set correctly and flowcontrol software enabled on the Cisco
and the plotter.  Has anyone written any code to dump data to
devices attached to terminal servers that I could take a look at?
My data looks fine from looking at our SNIFFER.  Thanks in advance!

                        Brian Holmes
                        UCC Operating Systems & Communications

PHONE:    (313) 577-3750  FAX=577-5626          Wayne State University
BITNET:   BHOLMES@WAYNEST1                      5925 Woodward
INTERNET: Brian_Holmes@UM.CC.UMICH.EDU          Detroit, MI 48202  U.S.A

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 89 22:35:29 GMT
From:      pccl@cbnewsd.ATT.COM (paul.c.liu)
To:        comp.protocols.tcp-ip
Subject:   tcpdump problem on SUN3


socket(AF_NIT,SOCK_RAW,NITPROTO_RAW) call in initdevice()
of tcpdump.c returns an error stating

	nit socket: Protocol not supported.

Anyone has any clue/fix for the problem mentioned?

Thanks in advance!

paul.c.liu@ATT.COM

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 89 22:56:57 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.protocols.tcp-ip
Subject:   AT&T 7300 (3B1) broadcast address

Does anyone know how to change the broadcast address on an AT&T Unix-PC
(3B1) from x.x.0.0. to x.x.255.255.

This is old Wollengang based Win 3B software that doesn't have any
provision for the change. I was hoping someone might have worked out a
patch.
-- 
Ken Mandelberg      | km@mathcs.emory.edu          PREFERRED
Emory University    | {decvax,gatech}!emory!km     UUCP 
Dept of Math and CS | km@emory.bitnet              NON-DOMAIN BITNET  
Atlanta, GA 30322   | Phone: (404) 727-7963

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Dec 89 08:32:49 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil, ietf@isi.edu NeWS-makers@brillig.umd.edu NFS@tmc.edu apollo@umix.cc.umich.edu SUN-SPOTS@rice.edu XPERT@athena.mit.edu
Subject:   IETF Activities

Hi folks:

    This note is being sent around to let you know that the Internet
Engineering Task Force plans to start work within the next week on
developing Internet standards for network graphics and distributed file
systems.  People interested in participating in or monitoring these
activities should join the IETF mailing list (ietf-request@isi.edu).

    I should hasten to emphasize that we currently *expect* that this
process will be a matter of reviewing the various current candidate
protocols and recommending which ones are suitable for Internet-wide
use.  (Of course if none of the protocols are deemed suitable, then
development work may be required.)

Craig Partridge
IETF Area Director, Host-Based and User Services

PS: For those of you not familiar with the IETF: The IETF is charged with
near-term engineering of the Internet.  This activity includes advising
the Internet Activities Board of protocols that might be suitable for
standardization in the TCP-IP protocol suite.
-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 1989 05:26-EST
From:      CERF@A.ISI.EDU
To:        mcc@WLV.IMSD.CONTEL.COM
Cc:        sklower%okeeffe.Berkeley.EDU@UCBVAX.BERKELEY.EDU, tcp-ip@NIC.DDN.MIL
Subject:   Re: more on Fletcher
Merton

I think what is at issue is whether the TCP checksum should
be sufficiently robust to detect some of these anomalies.
In the past we opted for the simple checksum owing to a concern
for the cost of computation; if this parameter is less crucial
now, thanks to more powerful processors, one may be able to
afford the expense of better failure detection.

Vint
-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 89 02:22:16 GMT
From:      tds@cbnewsh.ATT.COM (antonio.desimone)
To:        comp.protocols.tcp-ip
Subject:   Error Control and ATM (was: TCP Fletcher Checksum Option)

From article <6796@shlump.nac.dec.com>, by goldstein@delni.enet.dec.com:
> In article <[A.ISI.EDU].9-Dec-89.11:15:42.CERF>, CERF@A.ISI.EDU writes...
>>It is by no means clear that reordering at the cell level will be
>>detected by the ATMs or by links level algorithms sending the
>>packets assembled from cells to the hosts since the link level
>>checksums would be recomputed AFTER reassembly, most likely.

I'm not sure if I understand this point.  A host worried about data
integrety would compute a packet checksum before segmentation into
cells and after reassembly into a packet.  Shouldn't the checksum
detect reordering of cells within the packet?
> 
> Indeed, the current proposals for B-ISDN use ATM cell transfer and
> state, in its service description, that it _will_ preserve order.  Now
> doesn't that make you confident that the implementations will never,
> ever, ever, ever mis-order a cell?  The ATM cells do not contain any
> sort of sequence numbers. 

It's seemed to me that people expect both too little and too much from
ATM.  Here's an example of expecting too much.  One may conceive of a
"malfunctioning" time-slot-interchange switch that reorders bytes in a
T1 frame, even though the "service description" says it won't.  Should
we put sequence numbers on individual bytes?  Similarly sequence
numbers for individual cells are overkill since the architecture of ATM
switches preserves the order of cells.

> BTW I have proposed (and gotten rebuffed by the Powers That Be at 
> T1S1.5, namely the AT&T & Bellcore leadership) an end-to-end datalink
> protocol that has cell sequence numbers and bulk cell ack's, loosely
> based on NETBLT, with a 2^14 modulus.  You can always run it or 

A modulus of 2^14 with 48-byte cells allows roughly 6 Mbits outstanding.
A cross-country circuit at 150 Mbits/second can have 9 Mbits in flight
for a 60 msec propagation delay.  Your proposal reduces throughput at
the speeds being contemplated for the next few years, to say nothing of
higher speeds in the future.  (BTW: I had nothing to do with AT&T's
positions in the standards bodies.)

> something else you prefer end to end across the ATM and ignore their
> recommendations for adaptation, if you're not talking to a
> network-provided service (i.e., the "B-ISDN CLNS", which is an L3
> datagramme service running over the adaptation layer).  My impetus,

Doesn't B-ISDN CLNS include a checksum or CRC at the frame level?

> though, is to handle cell loss without having to retransmit the whole
> frame.  (Can you spell 'congestion collapse'?)  Misordering detection 
> comes along with that.

Think for a minute about what losses will look like in a congested ATM
network.  When buffers overflow losses will occur in clusters, just
because of the long time congested queues take to recover.  Also,
errors on transmission lines typically occur in bursts: isolated random
bit errors that we all like to use for modelling are in fact a poor
representation of reality.  All this says that the loss of isolated
cells is rare, and that cell retransmission promises little gain at a
great cost in complexity.  With an understanding of loss patterns frame
retransmission seems quite reasonable.
-- 
Tony DeSimone
AT&T Bell Laboratories
Holmdel, NJ 07733
att!tds386e!tds

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 1989 08:01-EST
From:      CERF@A.ISI.EDU
To:        att!cbnewsh!tds@UCBVAX.BERKELEY.EDU
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Error Control and ATM (was: TCP Fletcher Checksum Option)
Tony,

Let's see. One might take the view that there is a
tradeoff between sequence numbering of cells and strong
checksumming to detect misordering (followed by
frame retransmission).  When cell sizes get very small
(e.g. your one byte T1 example) then sequence numbers
are silly and checksums are necessary. The current 48 byte cell
size is pretty small - perhaps small enough that sequence
numbering is too expensive. This motivates the interest in
checksumming of a stronger variety than TCP currently supports.

Vint

What I meant about link checksumming not catching the problem
is based on the idea that if cell reassembly happens in the
ATM and THEN a link level checksum is computed to "secure"
the transmission of the frame to the host, the checksum would
not detect the reassembly of misordered cells. If the checksum
is computer end to end, then it covers more of the intervening
transmission and switching plant and thus allows potential
detection of misordering (if the checksum is strong enough).

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 89 05:44:09 GMT
From:      dboyes@rice.edu (David Boyes)
To:        comp.protocols.tcp-ip
Subject:   Re: Request for information - front-ending IBM 7171 with CISCO ASM

In article <8912090646.AA16735@ucbvax.Berkeley.EDU> cire@CISCO.COM (cire|eric) writes:
>
>This sounds interesting.  What exactly is an IBM 7171 and how are you
>trying to connect the cisco to it?
>Eric B. Decker
>cisco Systems - engineering
>email:	cire@cisco.com

The 7171 is a protocol conversion box that provides IBM 3278
emulation for a large set of standard async ASCII terminals. It
grew out of a research project at Yale that eventually produced a
beastly gadget called a Series/1 that did essentially the same
job, but was much more difficult to configure and use.

The 7171 is essentially an industrial grade PC with a 370 channel
interface and up to 64 async ports (minimum 8, expandable in 8
port increments) running a embedded program that translates
keyboard input from popular ASCII terminals to the 3270-style data
streams that IBM mainframes expect. It also translates 3270 data
streams from the host into appropriate escape sequences for 
each type of supported ASCII terminal by doing lookup of
sequences stored in EEPROM. Users can add new terminal types by
running a configuration program on an ordinary IBM PC or PS/2 and
download the configuration into the controller via a serial line.

It's a very well-thought out box -- IBM did a good job with the
Yale research.

Some sites provide TCP access to their IBM boxes by attaching a
terminal server to the async ports on a 7171 and configuring the
terminal server to rotor between free ports, like this:


          |               |--------|
    net   |               |        |========
          |   |------|====|  7171  |========  large IBM iron
          |---| TS   |====|        |
          |   |------|====|        |
          |               |--------|

Users can then 'telnet' to the terminal server and be
automagically assigned a 7171 port w/o having to drag serial
cables all over the place (assuming their 'telnet' does a
reasonable terminal emulator that the 7171 can understand --
although 7171s can deal with terminals as dumb as ADM-3s, so it
doesn't have to be much). It's a pretty smooth setup, once you
get all the configuration stuff right in the terminal servers
*and* get the right cables and modem signals rigged between the
terminal server and the 7171.

My guess is that the original poster has probably set up
something very much like this and is having some problems getting
everything set up and working smoothly.


Disclaimer: I don't work for IBM. I just like the 7171 -- I've
            babysat several of them in different places, and
	    they're very well-behaved. 8-)
-- 
David Boyes      "... no love was left; All Earth was but one thought - and
dboyes@rice.edu   that was death Immediate and inglorious; and the pang of
                  of famine fed upon all entrails - men Died and their bones
                  were tombless as their flesh ..."  - Lord Byron

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 89 10:26:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: more on Fletcher

Merton

I think what is at issue is whether the TCP checksum should
be sufficiently robust to detect some of these anomalies.
In the past we opted for the simple checksum owing to a concern
for the cost of computation; if this parameter is less crucial
now, thanks to more powerful processors, one may be able to
afford the expense of better failure detection.

Vint

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 89 13:01:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Error Control and ATM (was: TCP Fletcher Checksum Option)

Tony,

Let's see. One might take the view that there is a
tradeoff between sequence numbering of cells and strong
checksumming to detect misordering (followed by
frame retransmission).  When cell sizes get very small
(e.g. your one byte T1 example) then sequence numbers
are silly and checksums are necessary. The current 48 byte cell
size is pretty small - perhaps small enough that sequence
numbering is too expensive. This motivates the interest in
checksumming of a stronger variety than TCP currently supports.

Vint

What I meant about link checksumming not catching the problem
is based on the idea that if cell reassembly happens in the
ATM and THEN a link level checksum is computed to "secure"
the transmission of the frame to the host, the checksum would
not detect the reassembly of misordered cells. If the checksum
is computer end to end, then it covers more of the intervening
transmission and switching plant and thus allows potential
detection of misordering (if the checksum is strong enough).

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 89 13:32:49 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   IETF Activities


Hi folks:

    This note is being sent around to let you know that the Internet
Engineering Task Force plans to start work within the next week on
developing Internet standards for network graphics and distributed file
systems.  People interested in participating in or monitoring these
activities should join the IETF mailing list (ietf-request@isi.edu).

    I should hasten to emphasize that we currently *expect* that this
process will be a matter of reviewing the various current candidate
protocols and recommending which ones are suitable for Internet-wide
use.  (Of course if none of the protocols are deemed suitable, then
development work may be required.)

Craig Partridge
IETF Area Director, Host-Based and User Services

PS: For those of you not familiar with the IETF: The IETF is charged with
near-term engineering of the Internet.  This activity includes advising
the Internet Activities Board of protocols that might be suitable for
standardization in the TCP-IP protocol suite.

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 89 15:02:14 GMT
From:      chabutjc@wpafb.af.mil (John Chabut)
To:        comp.protocols.tcp-ip
Subject:   Throughput from MILNET

I'm sure I'm not the first to notice that even if you
have two hosts connected to PSNs at 56 kb/s, the throughput
of an FTP is down around 4 kb/s. I realize there's overhead
associated with FTP, TCP/IP, and X.25, but how much does the
MILNET affect throughput?  Can anyone refer me to studies done
of MILNET throughput? I presume it changes due to congestion
at certain times of the day, number of active PSNs, etc.

I appreciate your interest and assistance.

--John Chabut
  SAIC
  513-429-6553
  chabutjc@asd.wpafb.af.mil   OR   jcc%dayvd%dayvb@uunet.uu.net

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 89 18:24:12 GMT
From:      kwe@BUITB.BU.EDU (Kent England)
To:        comp.protocols.tcp-ip
Subject:   Networks Considered Harmful...


	I call your attention to a Viewpoint column in the December
1989 issue of the Communications of the ACM (Vol 32, Number 12, page
1389-1390) by John McCarthy of Stanford's School of Engineering with
the provocative title of "Networks Considered Harmful For Electronic
Mail".

	This is an opinion piece which members of this list will
appreciate for presenting another viewpoint on the future of
electronic mail services.

	Kent England, Boston University

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 89 20:15:25 GMT
From:      goldstein@delni.enet.dec.com (Fred R. Goldstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Error Control and ATM (was: TCP Fletcher Checksum Option)

In article <6528@cbnewsh.ATT.COM>, tds@cbnewsh.ATT.COM (antonio.desimone) writes...
>From article <6796@shlump.nac.dec.com>, by goldstein@delni.enet.dec.com:
>> In article <[A.ISI.EDU].9-Dec-89.11:15:42.CERF>, CERF@A.ISI.EDU writes...
>>>It is by no means clear that reordering at the cell level will be
>>>detected by the ATMs or by links level algorithms sending the
>>>packets assembled from cells to the hosts since the link level
>>>checksums would be recomputed AFTER reassembly, most likely.
> 
>I'm not sure if I understand this point.  A host worried about data
>integrety would compute a packet checksum before segmentation into
>cells and after reassembly into a packet.  Shouldn't the checksum
>detect reordering of cells within the packet?

If you're referring to the use of an end-to-end checksum at Transport
or higher (i.e., a TCP checksum that could detect misordered cells),
then that would do it.  The AT&T-Bellcore AAL purports to detect
errors, but does not detect misordering.  In a pure OSI environment,
where there's no checksum above datalink, it wouldn't be caught.

>> Indeed, the current proposals for B-ISDN use ATM cell transfer and
>> state, in its service description, that it _will_ preserve order.  Now
>> doesn't that make you confident that the implementations will never,
>> ever, ever, ever mis-order a cell?  The ATM cells do not contain any
>> sort of sequence numbers. 
 
>It's seemed to me that people expect both too little and too much from
>ATM.  Here's an example of expecting too much.  One may conceive of a
>"malfunctioning" time-slot-interchange switch that reorders bytes in a
>T1 frame, even though the "service description" says it won't.  Should
>we put sequence numbers on individual bytes?  Similarly sequence
>numbers for individual cells are overkill since the architecture of ATM
>switches preserves the order of cells.

You're being silly.  We know from practice that S-TDM switches do not
reorder bytes.  And if they did, your basic CRC would detect it.  (SLIP 
users deserve what they get.)  The current TCP checksum would detect 
frogged bytes, but wouldn't detect frogged 16-bit words.  We do not know
that all manufacturers of ATM switches will build switches that are
unable to reorder cells.  There are no commercial B-ISDNs yet, so it's
purely an extrapolation that the service description will be met.  This
thread began when someone pointed out that the existing TCP checksum may
be inadequate to detect misordered cells.  You simply assert that there
won't be.  The reader is left to trust AT&T or to cover his hide. 

 >> BTW I have proposed (and gotten rebuffed by the Powers That Be at 
>> T1S1.5, namely the AT&T & Bellcore leadership) an end-to-end datalink
>> protocol that has cell sequence numbers and bulk cell ack's, loosely
>> based on NETBLT, with a 2^14 modulus.  You can always run it or 
> 
>A modulus of 2^14 with 48-byte cells allows roughly 6 Mbits outstanding.
>A cross-country circuit at 150 Mbits/second can have 9 Mbits in flight
>for a 60 msec propagation delay.  Your proposal reduces throughput at
>the speeds being contemplated for the next few years, to say nothing of
>higher speeds in the future.  (BTW: I had nothing to do with AT&T's
>positions in the standards bodies.)

A window allowing 6 Mbits outstanding is adequate for the typical
FDDI bridge application.  BLINKBLT's (my proposal's) 50-100 Mbps typical 
maximum rate seems adequate for a number of applications, and I don't
claim it's a panacaea.

>> something else you prefer end to end across the ATM and ignore their
>> recommendations for adaptation, if you're not talking to a
>> network-provided service (i.e., the "B-ISDN CLNS", which is an L3
>> datagramme service running over the adaptation layer).  My impetus,
> 
>Doesn't B-ISDN CLNS include a checksum or CRC at the frame level?

NO!  It did, before YOUR COMPANY, Tony, made a big stink and holler
about how hard it would be to compute 32-bit checksums.  They insisted
that it be taken out.  Now the only CRCs are the 10-bitters in each
cell.  Compare Draft 5 of 802.6 with the current Draft 9, since this
changed in lockstep!

If you don't think AT&T Did The Right Thing, then call Harvey Rubin
(hr@edsel) and tell him.  Or do you value your job?  Recall that AT&T
delegates at ANSI meetings are company reps, while DEC delegates are
sponsored contributors.  (I forget the exact terms.)  I'm allowed to 
speak my mind at T1S1.

Incidentally, the main impetus for the change seems to be the 
"data pipelining" service, which is there (solely, I think) to allow
Datakit VCS (tm, AT&T) cells to be stuffed into ATM cells without
waiting to fill the 48-octet ATM cells.  I'm sure the Internet
community is concerned about preserving their Datakits beyond 1999!

>> though, is to handle cell loss without having to retransmit the whole
>> frame.  (Can you spell 'congestion collapse'?)  Misordering detection 
>> comes along with that.
> 
>Think for a minute about what losses will look like in a congested ATM
>network.  When buffers overflow losses will occur in clusters, just
>because of the long time congested queues take to recover.  

Yes, that's likely.  But the bursts occur as multiple virtual channels
are "funneled" into one output queue which fills.  A moderate-speed v ch
(say, under T1 rate) will lose maybe one or two cells during the burst
event, but many v chs. will have one or two cells lost.  It all depends
upon the traffic mix, and on whether everyone's traffic is carried
as close-together cell bursts (packet trains?) or smoothed flows.  The
former cause the effect you mention; the latter reduces funneling loss.

Also,
>errors on transmission lines typically occur in bursts: isolated random
>bit errors that we all like to use for modelling are in fact a poor
>representation of reality.  All this says that the loss of isolated
>cells is rare, and that cell retransmission promises little gain at a
>great cost in complexity.  With an understanding of loss patterns frame
>retransmission seems quite reasonable.

Like I say, we don't know traffic patterns, so we can't prove loss 
patterns.  Frame retransmission makes sense in some circumstances.
Cell retransmission makes sense in some.  Since BLINKBLT uses exactly 
the same number of bits/data-cell (32) as AAL-VBR, and has relatively
similar protocol overhead, there's no higher transmission cost for it.
Just a different TE implementation.  Buffer lots of little cells (a 
round-trip's worth of bits) or buffer a smaller number of frames (a 
round-trip's worth of bits).

Either form of retransmission can be done with cell resequence
detection at some layer.  Those who choose to use the proposed BISDN
protocols may wish to develop transport or other checksums that detect
it, in case the network isn't perfect.
     fred

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 89 22:02:47 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc,rec.ham-radio.packet,comp.dcom.lans
Subject:   New release of Clarkson PC packet drivers (5.x)

Release 5.x of the Clarkson PC packet drivers is now (finally!) available.
The packet drivers hide the differences between PC Ethernet cards, and also
allow multiple (different) protocol stacks to coexist, most notably Novell
and TCP/IP.

Many bugs have been fixed.  Please upgrade, as previous versions are
known to be buggy.  Rather than include the entire read.me file here,
I'll just include the what's new section.  Following it is the howtoget.it
file.

Changes from version 4.0 to 5.0 of the drivers:

Summary: New: 3c505, ne1000, ni9210, ibmtoken.  Bugs fixed: all drivers.

Krishnan Gopalan and Gregg Stefancik wrote a packet driver for the 3c505.
Brian Fisher wrote an "Ethernet" packet driver for the IBM Token Ring Adapter.
Eric Henderson wrote a packet driver for Novell's NE1000.
Russell Nelson modified ni5210 to be a ni9210 driver.  This entailed some
	changes in 82586.asm.
Russell Nelson wrote pktmode, a utility to set the receive mode.
Russell Nelson wrote pktaddr, a utility to set the Ethernet address.
Russell Nelson wrote pktall, a utility to help debug packet reception.
Trace.com is a little bit more helpful about how to run it.
Vance Morrison added starlan support to the wd8003e driver.
Eric Henderson improved it.
Deborah Swanberg noticed that the 3c503 driver didn't timeout properly
	if there was a failure to complete a transmit.
The set_address routine in the device dependent files now
	returns the address length as it should have.
Head.asm now keeps a copy of the hardware address set by set_address.  This is
	used by f_get_address to return the current address.  The device
	dependent get_address routine always returns the PROM address.
The set_rcv_mode routine didn't work.  Not at all.
The access_type routine returns more appropriate errors.
The f_get_address routine wasn't passing the right address length to
	get_address.
Tail.asm now checks for extra parameters on the end of the line.
Dan Lanciani added changes to ni5210 version 4.2 to increase reliability.
	It works for him.  Unfortunately, I have had reports from other
	people that it breaks Novell.  So, these changes are in "if DAN"
	conditional assembly.  If your Novell connection gets dropped,
	try reassembling ni5210 after setting "DAN equ 0" in 82586.asm
Packet drivers for the NE2000 and UB NIC PC/2 are in the works, but don't
	hold your breath.
A packet driver for the Xircom pocket Ethernet adapter is undergoing testing.
Jan Engvald found and fixed a bug in the wd8003e memory presence check.




The howtoget.it file follows:



		The Clarkson packet driver collection

Availability

The Clarkson collection of packet drivers is available by FTP, by
archive-server, Fido file request, and by modem.  They come in two flavors
-- executables only (drivers.arc), and source+executables (driverss.arc).
All of the following instructions apply to both drivers.arc and
driverss.arc.

FTP:

sun.soe.clarkson.edu:/pub/ka9q/drivers.arc
grape.ecs.clarkson.edu:/e/tcpip/drivers.arc

Archive-server:

Send mail to archive-server@sun.soe.clarkson.edu and put the following
command as the body of your message:
	help

This will send you a help message.  Reading this help message will tell
you how to fetch the packet drivers.

Modem:

Call the Clarkson Heath User's Group's BBS: (315)268-6667, 8N1,
1200/2400 Baud, 24 hours.  Change to file area 24 and download drivers.arc.

Opus:

260/360 in the Nodelist.  Drivers.arc is file requestable.
-- 
--russ (nelson@clutx [.bitnet | .clarkson.edu])
Live up to the light thou hast, and more will be granted thee.
A recession now appears more than 2 years away -- John D. Mathon, 4 Oct 1989.
I think killing is value-neutral in and of itself. -- Gary Strand, 8 Nov 1989.

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 89 22:19:36 GMT
From:      jkimball@SRC.Honeywell.COM (John Kimball)
To:        comp.protocols.tcp-ip
Subject:   subnetting on non-byte boundaries


Time to call on the Wisdom of the Net . . .

We have a Class B network.  We've been following the strategy which all the
examples in the manuals depict: subnetting at the byte boundary, using the
third octet for our (internal) network ids and the fourth octet for the
host id.  

We've also been keeping our backbone as one logical network (actually three
ethernet segments joined by learning bridges).  On that backbone network,
we are approaching 250 hosts.  And we expect to need another 75 or so
additional IP addresses within a few months. Ooops.

Looks like our options are:

  Option 1:  Modify our subnetting scheme.  Use 6 bits for internal
     network id, and use 10 bits for host id.  We've kept our network
     id's in the high bits of the third octet, so the low bits are free and
     can be reassigned to the 'host part'.

     Worry 1.1:  The only examples in the manuals show subnetting on byte
       boundaries.  Will a 6/10 (vs 8/8) bit-split really work?  (Context:
       lots of Suns running 4.0.3;  VMS VAXen running CMU-TEK 6.4; some
       random Apollos and HPs that we don't care about, much.)

     Worry 1.2: Can we really expect to keep increasing the number of hosts
       on our backbone network at this rate?  When will performance
       problems set in?

  Option 2:  Play games with routing.  Put two networks on the same
       backbone, both with metric 0.

     Worry 2.1: Is this some sort of unsupported kludge -- will it work,
       for our mix of hosts?

     Worry 2.2: If we should in the future attach some gateways to that
       backbone cable, would they die of terminal confusion?

  Option 3:  Bite the bullet and buy some hardware.  Replace the learning
     bridges with true gateways, making the three segments be three networks.


Has anyone done Option 1 or Option 2?  What would you recommend?

As always, reply via mail and I'll summarize if indicated.

Thanks!
						John Kimball

Domain: jkimball@src.honeywell.com        Honeywell Systems and Research Center
        postmaster@src.honeywell.com      Computer Sciences/Software Technology
uucp: <any-smart-host>!srcsip!jkimball    3660 Technology Drive, MN65-2100
voice: 612/782-7343  fax: 612/782-7438    Minneapolis, MN  55418-1006

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 89 22:32:49 GMT
From:      koreth@panarthea.ebay.sun.com (Steven Grimm)
To:        news.admin,comp.protocols.tcp-ip
Subject:   Looking for an Internet nameserver to hold MX records

I'm looking for a nameserver on the Internet to hold MX records for a new
domain, hyperion.com.  I'd need two MX records and an SOA record.  If anyone
can help, please mail me at koreth@ebay.sun.com.  (This domain has nothing to
do with Sun and I'm not posting this on company time.)

---
"                                                  !" - Marcel Marceau
Steven Grimm		Moderator, comp.{sources,binaries}.atari.st
koreth@ebay.sun.com	...!sun!ebay!koreth

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 89 23:08:12 GMT
From:      JBOESKE@ucs.UAlberta.CA (User name Unknown)
To:        comp.protocols.tcp-ip
Subject:   MHS/SMTP Gateway

I am interested in connecting Novel/Action Technologies' MHS based mail
systems like DaVinci eMAIL, the Coordinator, etc to Internet.  Does anyone
know of gateways between MHS and SMTP?

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 89 00:59:30 GMT
From:      csu@alembic.acs.com (Dave Mack)
To:        comp.protocols.tcp-ip
Subject:   Public Domain Dialout SLIP?

I'm preparing to start hacking my version of KA9Q to support dial-out
SLIP. Before I do, is there such a critter already available? I've
heard mumbles regarding a package from BBN, but I don't have any
information.

Thanks,
Dave Mack

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Dec 89 11:11:56 -0500
From:      Debbie Deutsch <ddeutsch@BBN.COM>
To:        "Fred R. Goldstein" <shlump.nac.dec.com!delni.enet.dec.com@decuac.dec.com>
Cc:        tcp-ip@nic.ddn.mil, ddeutsch@BBN.COM
Subject:   Re: Error Control and ATM (was: TCP Fletcher Checksum Option)
We are planning to look at this problem here at BBN, as part of a
research project.  Our approach is to use checksums in a
(non-standard) adaptation layer to detect potential problems (e.g.
misordering of cells, missing cells, bit errors) and to signal any
problem to higher protocol(s), which can then decide whether
corrective action is necessary.  After all, the applications vary 
widely in their sensitivity to errors.

Of course, one of the central issues here is just what kind of errors
will be experienced, and what pattern they will follow.  Until we know
that, it will be hard to determine the best way to deal with errors.

Debbie
-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 89 03:50:59 GMT
From:      chris@CS.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   A gem from the past

The more things change, the more they stay the same....

Chris

Date: 24 Dec 1985 03:03:49 PST
Subject: Revision of OSI Carol
From: "Vinton G. Cerf / MCI ID: 105-0002" <INTERMAIL@USC-ISIF.ARPA>

Date:     Tue Dec 24, 1985  3:46 am  PDT
From:     Vinton G. Cerf / MCI ID: 105-0002
 
TO:     * Intermail / MCI ID: 107-8239
Subject:  Revision of OSI Carol
 
I added some verses:


 
                  Oh OSI, oh OSI
 
                        (to the tune of O Tannenbaum)
 
        Oh OSI, oh OSI,
        Your rules are always changing.
        Oh OSI, oh OSI,
        Your rules are always changing.
 
        Each year you bring new protocols,
        More overhead and service calls.
        Oh OSI, oh OSI
        Your rules are always changing.
 
        Oh OSI, oh OSI,
        With seven layers burdened.
        Oh OSI, oh OSI,
        With seven layers burdened.
 
        No matter where I turn to look,
        There comes another colored book!
        Oh OSI, oh OSI,
        With variation, sagging!
 
        Oh OSI, oh OSI,
        The source of my frustration!
        Oh OSI, oh OSI,
        The source of my frustration!
 
        A plebescite in 92
        Will split a layer into two;
        Oh OSI, oh OSI,
        Amoebic reproduction!
 
        Oh OSI, oh OSI,
        Eternally unfolding.
        Oh OSI, oh OSI,
        Eternally unfolding
        
        Oh, can the C C I T T
        and I S O at last agree
        On OSI, on OSI,
        The final net solution?
 
        Oh OSI, oh OSI,
        Ever in negotiation!
        Oh OSI, oh OSI,
        Ever in negotiation!
 
        Perhaps one day I'll live to see
        A multi-vendor community!
        Oh OSI, oh OSI,
        With endless promise laden.
 
        Oh OSI, oh OSI,
        Your rules are ever changing.
        Oh OSI, oh OSI,
        Your rules are ever changing.
 
- Vint Cerf
  December 1985

-------

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 89 05:02:28 GMT
From:      micky@cunixc.cc.columbia.edu (Micky Liu)
To:        comp.protocols.tcp-ip
Subject:   Re: tcpdump problem on SUN3


You didn't supply enough information...  What version of the operating
system are you running?  Sun has changed the NIT interface in a big way
from version 3.5 to 4.0.x.  I suspect that you are attempting to run
the tcpdump executable from a 3.5 system on a 4.0.x system.  If that is
the case you should try to get a new version of tcpdump from someplace.
If you are building the executable yourself, are you aware of a diff
set to enable the sources to be compiled and usable on a Sun with
SunOS4.0.x?  There are a number of anonymous ftp sites with both
the executables and the diff set, but I do not have them offhand.  If
you are really desperate I can send you the diff set only...

Good Luck!

Micky 

internet: micky@cunixc.cc.columbia.edu
  usenet: ...!rutgers!columbia!cunixc!micky
  bitnet: micky@cunixc.bitnet

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 89 16:12:14 PST (Wed)
From:      karl@asylum.sf.ca.us (Karl Auerbach)
To:        J.Crowcroft@cs.ucl.ac.uk
Cc:        yee@trident.arc.nasa.gov, iso@nic.ddn.mil, isode@nic.ddn.mil, tcp-ip@nic.ddn.mil
Subject:   The Open Book
> btw: what can you expect of a bunch of people will invent 
> (who dont have computer science degrees and all speak different 
> natural languages) but ASN.1? wait for ASN.2

ASN.1 is a growth on X.409 which came out of the work of IFIP WG 6.1
which came out of the internet community.  Please don't be so down on
ASN.1 itself -- it makes a great deal of sense when used to hold
multi-media documents and electronic mail (things which you don't have
to parse in real-time).  The dummy is the one who decided that ASN.1
is the vehicle for virtually all upper-level exchanges in OSI.

				--karl--
-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 89 12:40:53 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: The Open Book



 >"The Final Soapbox" is the last section in the book, and is as its name implies
 >a sermon on problems and pitfalls of the standards process and its players.
 
 >PPS Differences of opinion gladly entertained, flames ignored.

I agree with comments on the first sections of the book - i've just
got round to reading it and its definitely the most useful practical
book on OSI by a very long way. 

[nearest runners in my opinion are
Larmouth et al - Standards for OSI, BSP professional books, ISBN
0-632-01868-2, and Halsell, Data Comms, Computer Networks and OSI,
Addison Wesley, ISBN 0-201-18244-0, neither of which show any where
near the depth of example/experience in implementation].

The final section of the book is very US oriented (wont say biased) 
- there are a lot of European players not included;

however the principle of nitwits (= junior management) and faberge
egg-heads (= senior management) determining the course of things to
come is also well known this side of the Atlantic - i await the
distribution of ISODE along with the book, by the publishers a la
minix/xinu op sys books!!

i think its a shame that there isnt a counterpoint book on comms and
distributed systems that says "here's an open distributed system we
prepared earlier which has no design flaws and this is how we built it
in practice, and by the way its heterogeneous and free".

 jon

btw: what can you expect of a bunch of people will invent 
(who dont have computer science degrees and all speak different 
natural languages) but ASN.1? wait for ASN.2

p.s. the ultimate test of a grad student - get them to modify tcpdump
to pretty print the presentation level "of" packets traversing your
ethernet, using an ASN.1 template as the pkt parser driver - and
probably get free lunches for life telling anecdotes about debugging
it!

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Dec 89 12:40:53 +0000
From:      Jon Crowcroft <J.Crowcroft@Cs.Ucl.AC.UK>
To:        "Peter E. Yee" <yee@trident.arc.nasa.gov>
Cc:        iso@nic.ddn.mil, isode@nic.ddn.mil, tcp-ip@nic.ddn.mil
Subject:   Re: The Open Book


 >"The Final Soapbox" is the last section in the book, and is as its name implies
 >a sermon on problems and pitfalls of the standards process and its players.

 >PPS Differences of opinion gladly entertained, flames ignored.

I agree with comments on the first sections of the book - i've just
got round to reading it and its definitely the most useful practical
book on OSI by a very long way. 

[nearest runners in my opinion are
Larmouth et al - Standards for OSI, BSP professional books, ISBN
0-632-01868-2, and Halsell, Data Comms, Computer Networks and OSI,
Addison Wesley, ISBN 0-201-18244-0, neither of which show any where
near the depth of example/experience in implementation].

The final section of the book is very US oriented (wont say biased) 
- there are a lot of European players not included;

however the principle of nitwits (= junior management) and faberge
egg-heads (= senior management) determining the course of things to
come is also well known this side of the Atlantic - i await the
distribution of ISODE along with the book, by the publishers a la
minix/xinu op sys books!!

i think its a shame that there isnt a counterpoint book on comms and
distributed systems that says "here's an open distributed system we
prepared earlier which has no design flaws and this is how we built it
in practice, and by the way its heterogeneous and free".

 jon

btw: what can you expect of a bunch of people will invent 
(who dont have computer science degrees and all speak different 
natural languages) but ASN.1? wait for ASN.2

p.s. the ultimate test of a grad student - get them to modify tcpdump
to pretty print the presentation level "of" packets traversing your
ethernet, using an ASN.1 template as the pkt parser driver - and
probably get free lunches for life telling anecdotes about debugging
it!
-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 89 14:27:00 GMT
From:      HORN%HYDRA@sdi.polaroid.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Fletcher Checksum

Adding a checksum option with expanded size checksum (32, 64, ...
bit) seems to be a reasonable way to start experimenting with error
control algorithms for high speed networks.  A similar experimental
option for VMTP also seems reasonable.

As transmission speeds increase I think that we will need to look
more and more to forward error correction (FEC) techniques to
replace ARQ techniques.  With TCP, 64Kbit effective bandwidth, 250
msec end-to-end delays the ARQ impact on response time is modest and
the buffering demands are low.  At high bandwidth you have many
megabytes in flight with corresponding major buffering demands.  I
would not be surprised to see the buffers move to disk or
re-computation in some cases, with the result that a single ARQ has
a very large performance impact.

FEC techniques are improving steadily and are now in widespread use
both within modems (typically convolution codes) and in
media like CDROM (Reed Solomon codes).  For the non-error case,
there are table lookup approaches to RS (and some other) codes that
reduce the computation load to 10-20 instructions per byte for a
code that can withstand 0.001 ber.  The computation needed to repair
an error is much larger.  These approaches only minimize the cost of
generating and verifying checkwords.

One of the important aspects of using FEC is a good characterization
of the error modes of the telemetry system.  This may be the most
difficult aspect of introducing it into any large network.  You do
need to understand how errors occur, what are typical error burst
sizes, deletion and insertion modes, etc.

Examination of the system level tradeoffs would be worthwhile.  FEC
costs somewhat more CPU (rapidly getting cheaper) and uses a
controllable percentage of the bandwidth (typically a few percent)
while drastically reducing the needs for buffers at both ends.  The 
extra cost for FEC at CDROM rates (about 1Mbit/s) is a few hundred
dollars at most (retail pricing).  FEC can always retreat to ARQ for
cases beyond its ability to repair.


R Horn    horn%hydra@polaroid.com

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 89 14:36:50 GMT
From:      brian@ucsd.Edu (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Protocol Design issue

I'm currently designing yet another protocol to sit on top of a
reliable stream such as the TCP, but I'm not sure about one issue:

We have, as part of the various transactions that take place during the
lifetime of a connection, to transfer binary data.  Even with differing
machine architectures, the byte-ness of the data must be preserved
(i.e., it's still N bytes whether you store 4 or 6 per machine word).

It seems to me the best way to do this is by doing it in-band, that is,
sending a plaintext header with a byte-count, followed by that exact
number of bytes in literal mode.  This requires an accurate byte
counting at the sender and recipient, but that isn't a very difficult
thing to do, and it's not computationally expensive.

This is straightforward and relatively simple, and given the underlying
mechanism of an ordered reliable 8-bit stream, I don't see any
significant drawbacks.

All the other alternatives I've seen or dreamed up require either some
imbedded control characters with escaping, or else send the data
out-of-band (for example, FTP using a separate stream from the control
stream for file transmission).  I find both these ideas distasteful.

Are there any drawbacks to byte-counting that I've overlooked?
	- Brian

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 89 14:44:38 GMT
From:      geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
To:        comp.protocols.tcp-ip
Subject:   Re: Protocol Design issue

Why not just use XDR (RFC1014)? The sources are freely available....

Geoff Arnold, PCDS Group,     | Quote of the week: Too long to include
Sun Microsystems Inc.         | here - read "Being an American" by
Internet: geoff@East.Sun.COM  | Theodore A.Kaldis, <kaldis@topaz.rutgers.edu>
Disclaimer: Obviously....     | in talk.politics.misc. Quite amazing stuff!

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 89 15:10:57 GMT
From:      umbaugh@EVAX.ARL.UTEXAS.EDU (David Umbaugh)
To:        comp.protocols.tcp-ip
Subject:   New release of Clarkson PC packet drivers (5.x)

Russ, your message did not say how to extract the files from
dirverss.arc.
I tried ar -x driverss.arc
not the right format.
please help
Dave Umbaugh, CSE Dept, University of Texas at Arlington
<umbaugh@evax.arl.utexas.edu>

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 89 16:11:56 GMT
From:      ddeutsch@BBN.COM (Debbie Deutsch)
To:        comp.protocols.tcp-ip
Subject:   Re: Error Control and ATM (was: TCP Fletcher Checksum Option)

We are planning to look at this problem here at BBN, as part of a
research project.  Our approach is to use checksums in a
(non-standard) adaptation layer to detect potential problems (e.g.
misordering of cells, missing cells, bit errors) and to signal any
problem to higher protocol(s), which can then decide whether
corrective action is necessary.  After all, the applications vary 
widely in their sensitivity to errors.

Of course, one of the central issues here is just what kind of errors
will be experienced, and what pattern they will follow.  Until we know
that, it will be hard to determine the best way to deal with errors.

Debbie

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 89 16:25:49 GMT
From:      nelson@SUN.SOE.CLARKSON.EDU (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   New release of Clarkson PC packet drivers (5.x)


   Russ, your message did not say how to extract the files from
   dirverss.arc.

A PC file with a .arc extension is similar to a compressed tarfile, except
that it's created in one step.  Any one of the following programs will
extract the files: PKXARC, ARCE, ARC.  PKXARC.COM is on sun.soe.clarkson.edu
in the same place you found driverss.  Running it with no arguments will
give you sufficient directions to run it.
-russ

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 89 17:36:23 GMT
From:      rsalz@bbn.com (Rich Salz)
To:        comp.protocols.tcp-ip
Subject:   Re: Protocol Design issue

In <10439@ucsd.Edu> brian@ucsd.Edu (Brian Kantor) asks about shipping
binary data over a TCP stream in-band, by just using byte-counts.

I wrote an rdist-like replacement for our heterogeneous environment some
months ago, and that's exactly what I do.  A header line with a bytecount,
the bytes, and a trailer line to help catch errors.  We ship around a
couple of megabytes a week around to a variety of hosts (VMS, Ultrix,
Sun[234], ATT3b2, ATT6386, Sun3Mach, BBN Butterfly, Masscomp, Xenix) and
don't have any problems.  XDR is too big and bulky to port all over
when all you want is an opaque eight-bit binary stream.
	/r$
-- 
Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
Use a domain-based address or give alternate paths, or you may lose out.

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 89 20:17:16 GMT
From:      rnicovic@polyslo.CalPoly.EDU (Ralph Nicovich)
To:        comp.protocols.tcp-ip
Subject:   Re: subnetting on non-byte boundaries

In article <50277@srcsip.UUCP> jkimball@src.honeywell.com () writes:
>
>Time to call on the Wisdom of the Net . . .
>
>We have a Class B network.  We've been following the strategy which all the
>examples in the manuals depict: subnetting at the byte boundary, using the
>third octet for our (internal) network ids and the fourth octet for the
>host id.  
>
>We've also been keeping our backbone as one logical network (actually three
>ethernet segments joined by learning bridges).  On that backbone network,
>we are approaching 250 hosts.  And we expect to need another 75 or so
>additional IP addresses within a few months. Ooops.
>
>Looks like our options are:
>
>  Option 1:  Modify our subnetting scheme.  Use 6 bits for internal
>     network id, and use 10 bits for host id.  We've kept our network
>     id's in the high bits of the third octet, so the low bits are free and
>     can be reassigned to the 'host part'.
>
>     Worry 1.1:  The only examples in the manuals show subnetting on byte
>       boundaries.  Will a 6/10 (vs 8/8) bit-split really work?  (Context:
>       lots of Suns running 4.0.3;  VMS VAXen running CMU-TEK 6.4; some
>       random Apollos and HPs that we don't care about, much.)
>
Here we have split ours with 4/12 since we have lots of terminal servers and 
wanted 4k addresses on one network. One of these logical subnets can then
go thru a router and change the mask on the otherside to 8/8. This way
we can hace lots of small subnets and a few big ones. We have had no problem
with devices such as the SUN's where you can set the mask at the bit level.
However there are some machines (HP STARLAN on A HP-3000) for instance that
won't support this since they simply ask what class you are when you install.
In it's case you must put it on the other side of a router that sets the
mask to class C.
>     Worry 1.2: Can we really expect to keep increasing the number of hosts
>       on our backbone network at this rate?  When will performance
>       problems set in?
>
When is very dependent on what you are dooing. If you don't use routers
broadcast packets will start to be a problem. Every device must look at
every broadcast packet and every packet addressed to itself. Even though
broadcast may be 3 percent of overall trafic it may be 80 % of what any
individual device must look at. Soon devices can't keep up with trafic
retransmition occurs and trafic goes up somemore....
>  Option 2:  Play games with routing.  Put two networks on the same
>       backbone, both with metric 0.
>
>     Worry 2.1: Is this some sort of unsupported kludge -- will it work,
>       for our mix of hosts?
I have tried this and it does work, it does not solve any trafic problems
however. With some devices that don't have all the nice berkley things
like metrics you still need a router with two ethernet cards connected
to the same ethernet. Trafic now doubles for some devices since it must
send packets thru this router. It is lible to give you heart burn.
>
>     Worry 2.2: If we should in the future attach some gateways to that
>       backbone cable, would they die of terminal confusion?
>
Probably most good gateways won't die (I used a CISCO Enet-X.25 it was ok)
But trafic will become an isue.

>  Option 3:  Bite the bullet and buy some hardware.  Replace the learning
>     bridges with true gateways, making the three segments be three networks.
>
>
>Has anyone done Option 1 or Option 2?  What would you recommend?
>
 Recomendation: BITE THE BULLET.

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 89 23:02:02 GMT
From:      john@anasaz.UUCP (John Moore)
To:        comp.protocols.tcp-ip
Subject:   UDP - How unreliable?

Just a question... How reliable or unreliable is UDP. I understand that
it does not guarantee delivery or sequencing of messages. However,
I would like to know how, in practice, it can lose messages, and how
frequently it really will do this. Question applies to both Ethernet
LAN's, and such LAN's connected via Bridge over lower speed lines.

Thanks in advance.
-- 
John Moore (NJ7E)           mcdphx!anasaz!john asuvax!anasaz!john
(602) 861-7607 (day or eve) long palladium, short petroleum
7525 Clearwater Pkwy, Scottsdale, AZ 85253
The 2nd amendment is about military weapons, NOT JUST hunting weapons!

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 89 01:36:14 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Protocol Design issue

Sending a count followed by the exact number of bytes can work; indeed,
that's what Peter Honeyman and I did in uucp's 'e' protocol.  A few
caveats...  First, do everyone a favor and send the count in ASCII.
Using htonl() would work, but is only convenient if (a) the receiving
machine has ntohl(), and (b) both sides use 32-bit longs.  Me -- unless
there's a major performance issue, I'd prefer ASCII.

The other drawback is that there's no good way to abort the transfer.
I suppose you could send an 'urgent' message, but that's difficult to
handle sometimes.  We wanted to be able to abort in case the size of
the file changed between when uucico did the fstat(), and when the file
was actually read.  Might your application run into similar issues?

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 89 02:52:03 GMT
From:      louie@SAYSHELL.UMD.EDU ("Louis A. Mamakos")
To:        comp.protocols.tcp-ip
Subject:   Re: Protocol Design issue

Brian,

MDQS uses a similar mechanism to transfer files from one system to another,
and it works just fine in most cases.  The large problem that we ran into
when implementing MDQS clients and servers on large, ugly unfriendly machines
like Unisys 1100's and IBM 3080's is that there was no easy way to determine
how many bytes were to be sent without parsing the file once.  

MDQS made the assumption that all of the bytes in the file spooled would be
sent as-is over the network.  This is a broken assumption because:

	* It assumes that you can figure out exactly how long in bytes a
	file is.  Some brain damaged file systems make this difficult or
	impossible to do cheaply.

	* It assumes that the bytes are sent as-is over the network, and
	not converted to NVT ASCII, for instance.  This assumption doesn't
	hold on either the IBM or UNISYS mainframes which have, ah,
	interestingly complicated ways of storing "text" in a "file".

We've redesigned the network protocol to be able to send blocks of data,
each prefixed with a byte count.  This allows the sender to have a finite
sized buffer to accumulate the results of the host system representation
(EBCDIC on the IBM, 6 bit FIELDATA or 9 bit ASCII on the UNISYS) to NVT
ASCII translation.  It will no longer be necessary to pre-parse the entire
file just to find out how many bytes will later be shoved across the
network connection.  The additional complexity is minimal.

If you'd like to get clever, the two ends of the connection can negotiate
the largest size buffer that can be used, if required.

I believe that there is a transfer mode defined in FTP which does just
this sort of thing.  Transfer mode BLOCK, I believe.

louie

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Dec 89 10:21 MST
From:      WIMMER%telcom@rvax.ccit.arizona.edu
To:        TCP-IP@SRI-NIC.ARPA
Subject:   RE: Network Wiring Scheme

Ken,

Until the IEEE 10baseT specifications are published next year there really is 
no standard for ethernet over twisted pair.  Many vendors seem to have defined 
what they think the proposed standard will be and are at least announcing 
products to support it.  Most vendors are producing products to work on UTP
(unshielded Twisted Pair) for ethernet and even big blue has it's type 3 media
filters to allow Token Ring to work on UTP.  

Our campus has chosen to use the AT&T PDS wire plan and we are about to complete
 the rewiring of most buildings on campus to conform to PDS specs.  We install
dual RJ-45 (106bfd) jacks for voice and data use in every office.  (there are
suggestions for the quantity of these dual V/D jacks needed for every size room)
 At this point the voice jack (4 pr UTP) will be used only to connect to the new
5ESS switch (which will cutover in Feb90) and the middle 4 pins of the RJ-45 
data jack is used/reserved for the campus low speed data switch (IDX-3000's).
Our telecomm engineering group has/does authorize the use of the unused two pair
of the data jack for such things as printer sharing device connections,
 workgroup & departmental LAN's and in some cases we have used them to supply
video to an overflow room next to an instructional seminar or lecture.  We have
started to test different vendors UTP ethernet products but as yet have not 
made a decision as to which one to support.  Many of the Research Labs and 
departments have chosen to install departmental/building thick coax with AUI
bulkhead mounts off xceiver taps instead of attempting to "beta test" the as
yet unpublished 10baseT standard for UTP Ethernet.

We have tested or have currently installed on UTP the following LANs;

Arcnet UTP hubs and PC cards using LANtastic's Software
Arcnet UTP Hubs & PC cards using Novell Software
Arcnet UTP Hubs & PC cards using Arcnet Software
Cabletron UTP Ethernet concentrator & UTP transceivers
Synoptics UTP Ethernet concentrators & UTP transceivers
IBM Token Ring MAU's and IBM Token Ring PC cards using Novell software
	The MAU's between floors are connected using IBM type 1 cable
AT&T StarLAN using AT&T Hubs, PC cards, & software

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 89 04:16:14 GMT
From:      zweig@brutus.cs.uiuc.edu (Johnny Zweig)
To:        comp.protocols.tcp-ip
Subject:   Re: Error Control and ATM (was: TCP Fletcher Checksum Option)

ddeutsch@BBN.COM (Debbie Deutsch) writes:

>We are planning to look at this problem here at BBN, as part of a
>research project.
 ....
>After all, the applications vary widely in their sensitivity to errors.
>
>Of course, one of the central issues here is just what kind of errors
>will be experienced, and what pattern they will follow.  Until we know
>that, it will be hard to determine the best way to deal with errors.
>
>Debbie

Which is precisely why I advocated that there be some standard mechanism
to augment the corrective/detective features of the checksum being used on
a TCP connection when I started this Fletcher-checksum string.  We can't
look into a crystal ball and see all the things that people are ever going
to want to do.  I think it would be better for the transport protocol to
roll with the punches than to have it be inflexible, forcing users to
reinvent the wheel (say by using UDP to send adequately-checksummed packets).

-Johnny Checksum

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 89 06:03:20 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.protocols.tcp-ip
Subject:   Network Wiring Scheme

Our campus network hardware people have adopted the following
plan for wiring buildings for "networking". They wire every
office with "type 2" twisted pair cable to a phone closet.
They like the flexibility of this, since they can later decide
whether to do twisted pair ethernet, token ring, rs232, etc.
I guess this is the IBM wiring plan.

Does this seem like a reasonable approach? I thought ethernet
over twisted pair was mainly for buildings with exising cabling
in the walls. Our people are doing new wiring this way even
when they know its for ethernet.
-- 
Ken Mandelberg      | km@mathcs.emory.edu          PREFERRED
Emory University    | {decvax,gatech}!emory!km     UUCP 
Dept of Math and CS | km@emory.bitnet              NON-DOMAIN BITNET  
Atlanta, GA 30322   | Phone: (404) 727-7963

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 89 12:04:25 GMT
From:      freedman@euclid.math.temple.edu (Avi Freedman)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP - How unreliable?

In my experience with UDP staying on one side of a DEC bridge and
going between a Sun 4/280 and 5 Sun 3/60s, I lost roughly one out
of 10,000 UDP packets.  However, this is not at full Ethernet load-
I think that the load will be a _major_ factor in how many UDP packets
get lost.  Also, a slow machine (or a fast machine with a slow
ethernet card) may lose packets, and if you're going through
gateways/bridges/routers/whatever, they could hiccup or slow down
or experience high network loads and lose packets.

You get the idea.  For applications like the one I was working on
(simulating data collection of massive quantities of data points
and computing statistics about them), it was not critical if a packet
or two got lost, since the entire message was always contained in
one UDP packet.

Of course, for other applications, where order is dependant or duplication
would be unacceptable (implementing a database that sits on the
network, for example), I just use TCP.

Sorry to be so vague, but UDP packet-loss depends on many factors.  If
you'd like, I'll send you code to determine how many UDP packets are 
lost...


				Avi Freedman
				freedman@euclid.math.temple.edu

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 89 14:19:09 GMT
From:      PETEHIC@UOTTAWA.BITNET (Pete Hickey)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP - How unreliable?

How unreliable is UDP?  How fast is fast.  Unreliable does
not mean that its not good to use, it just means that you send
out a packet.  Thats all you know.  If the other machine is alive
and gets it, it got there.  If the other machine isn't running/
listening/too busy/etc. It won't get it.  The point is that
when you send it, you do not know if it has been received.

The reliability of a UDP packet is about as reliable as a single
TCP packet.  At least when its a UDP packet to a single machine.
How reliable is a UDP broadcast?????

=======================================================================
Pete Hickey                     | Convention says that something funny
University of Ottawa            | goes here.  Its blank because I have
Ottawa, Ontario, CANADA         | funny to say.
(613) 564-7646                  |_____________________________________
    petehic@uotacdvm.uottawa.CA      PETEHIC@UOTTAWA.BITNET

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 89 15:02:00 GMT
From:      amanda@mermaid.intercon.com (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: Throughput from MILNET

In article <137598.8912131631@asd.wpafb.af.mil>, chabutjc@wpafb.af.mil (John
Chabut) writes:
> I'm sure I'm not the first to notice that even if you
> have two hosts connected to PSNs at 56 kb/s, the throughput
> of an FTP is down around 4 kb/s.

Um, are you sure you're not mixing bits and bytes? 4K bytes per second
is 32K bits per second, which is not too bad across a 56K bits per
second link, especially in the presence of other traffic.

One of the reasons that NSFnet is so much faster than MILnet is that
many PSNs are linked with T1 (or faster) links rather than 56K leased
lines.

Amanda Walker
InterCon Systems Corporation
--

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 89 15:08:55 GMT
From:      amanda@mermaid.intercon.com (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP - How unreliable?

In article <1039@anasaz.UUCP>, john@anasaz.UUCP (John Moore) writes:
> [about UDP]
> I would like to know how, in practice, it can lose messages, and how
> frequently it really will do this. Question applies to both Ethernet
> LAN's, and such LAN's connected via Bridge over lower speed lines.

This depends almost entirely upon the physical configuration of the
network in question.  On a single lightly loaded Ethernet, UDP is
pretty reliable.  The more gateways you have to go through, especially
when low-speed links are involved, the higher the chances that your
datagrams will be dropped, either because of accumulated errors or
simply insufficient buffering in one of the gateways.

UDP is most useful as a cheap way to get packets around a local network
when retransmission is either unnecessary or easy to figure out how to do.
For any application that needs to work over arbitrary distances or needs
confirmation that the data actually got to the other end, TCP is probably
the way to go.

Amanda Walker
InterCon Systems Corporation
--

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 89 15:39:11 GMT
From:      pte900@csc.anu.oz
To:        comp.protocols.tcp-ip
Subject:   SMTP Mail on an IBM MVS System

How do you get SMTP mail into an IBM mainframe running MVS cheaply ?

I know about Knet, Mitek, ACC, etc. but these are all high cost systems
that require special hardware interfaces. I want something simple (not
necessarily fast) that allows TSO users to send/receive SMTP mail into/
from the Internet. The users that are interested in this already have a
bridge CS1/SNA box - would this be any use ??

Peter Elford,                           	e-mail: pte900@csc.anu.oz.au
Head, Systems Support Group 			phone: +61 62 49 3542
Computer Services Centre			fax: +61 62 47 3425
Australian National University			post: PO Box 4
Canberra, AUSTRALIA				      Canberra 2601

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 89 17:21:00 GMT
From:      WIMMER%telcom@rvax.ccit.arizona.edu
To:        comp.protocols.tcp-ip
Subject:   RE: Network Wiring Scheme


Ken,

Until the IEEE 10baseT specifications are published next year there really is 
no standard for ethernet over twisted pair.  Many vendors seem to have defined 
what they think the proposed standard will be and are at least announcing 
products to support it.  Most vendors are producing products to work on UTP
(unshielded Twisted Pair) for ethernet and even big blue has it's type 3 media
filters to allow Token Ring to work on UTP.  

Our campus has chosen to use the AT&T PDS wire plan and we are about to complete
 the rewiring of most buildings on campus to conform to PDS specs.  We install
dual RJ-45 (106bfd) jacks for voice and data use in every office.  (there are
suggestions for the quantity of these dual V/D jacks needed for every size room)
 At this point the voice jack (4 pr UTP) will be used only to connect to the new
5ESS switch (which will cutover in Feb90) and the middle 4 pins of the RJ-45 
data jack is used/reserved for the campus low speed data switch (IDX-3000's).
Our telecomm engineering group has/does authorize the use of the unused two pair
of the data jack for such things as printer sharing device connections,
 workgroup & departmental LAN's and in some cases we have used them to supply
video to an overflow room next to an instructional seminar or lecture.  We have
started to test different vendors UTP ethernet products but as yet have not 
made a decision as to which one to support.  Many of the Research Labs and 
departments have chosen to install departmental/building thick coax with AUI
bulkhead mounts off xceiver taps instead of attempting to "beta test" the as
yet unpublished 10baseT standard for UTP Ethernet.

We have tested or have currently installed on UTP the following LANs;

Arcnet UTP hubs and PC cards using LANtastic's Software
Arcnet UTP Hubs & PC cards using Novell Software
Arcnet UTP Hubs & PC cards using Arcnet Software
Cabletron UTP Ethernet concentrator & UTP transceivers
Synoptics UTP Ethernet concentrators & UTP transceivers
IBM Token Ring MAU's and IBM Token Ring PC cards using Novell software
	The MAU's between floors are connected using IBM type 1 cable
AT&T StarLAN using AT&T Hubs, PC cards, & software

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 89 17:25:43 GMT
From:      kwe@buit13.bu.edu (Kent England)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Wiring Scheme

In article <4762@emory.mathcs.emory.edu> km@mathcs.emory.edu
 (Ken Mandelberg) writes:
> I thought ethernet
>over twisted pair was mainly for buildings with exising cabling
>in the walls. Our people are doing new wiring this way even
>when they know its for ethernet.
>-- 

Many of us network managers like Ethernet over twisted pair because
the topology/architecture is much easier to manage than a bus
architecture/topology.  The technical performance on the medium is a
secondary consideration to the standardization of the medium and the
star topology.

Follow-up to comp.dcom.lans or the big-lan list at syracuse.  Lots of
discussion on these issues there.  tcp-ip doesn't care whether it's
twisted pair or baling wire.  :-)

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 89 17:29:36 GMT
From:      ntm1569@dsacg3.dsac.dla.mil (Jeff Roth)
To:        comp.protocols.tcp-ip
Subject:   Re: Throughput from MILNET


I've also been unpleasantly surprised by both throughput and
latency on the network. Our studies have shown some variation
by time of day but not as much as you might suspect; there is
greater variation depending on the route the data takes. It's
likely overloaded PSNs, in fact our worst cases are going
through one PSN to another at the same site (WPAFB).

But it does appear 56 KB buys you something; our FTP
throughput, using a 9.6 circuit, is more like 1 KB/s at best.

By the way I'd appreciate it if any readers with information on
what if any, plans exist to upgrade Milnet capacity could point
me to a source (or let me know privately by email what we can
expect).

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 89 17:52:25 GMT
From:      hwajin@wrs.com (Hwa Jin Bae)
To:        comp.protocols.tcp-ip
Subject:   Re: Protocol Design issue

The file "xdr_rec.c" in SUN RPC release has an implementation that accomplishes
this "record marking" on top of a TCP stream already.  This can be used
to preserve the application's idea of record boundaries.  No need to reinvent
the wheel.

hwajin
--
"If you live on JELLO you have to realize that you live on JELLO."

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 89 18:05:42 GMT
From:      sra@lcs.mit.edu (Rob Austein)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP - How unreliable?


   Date: 14 Dec 89 15:08:55 GMT
   From: amanda@mermaid.intercon.com (Amanda Walker)
   ...
   UDP is most useful as a cheap way to get packets around a local network
   when retransmission is either unnecessary or easy to figure out how to do.
   For any application that needs to work over arbitrary distances or needs
   confirmation that the data actually got to the other end, TCP is probably
   the way to go.

This is of course a good general rule, but there is at least one
important special case where UDP is (arguably) the right sollution for
a protocol that works over arbitrary distances: a configuration with a
huge number of clients asking short, infrequent questions of a few
global servers.  For example, the Domain Name System, where every host
on the internet needs to check with one of the half dozen root servers
once a week (assuming everybody is implementing the protocol correctly
and no machine ever needs to be rebooted or has its cache flushed...).

In this kind of configuration, the connection setup involved in using
TCP is quite expensive: the shortest likely TCP exchange would require
two packets in each direction, and the additional overhead for setting
up the TCB on the server might add significantly to the query
processing cost.

--Rob Austein

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Dec 89 16:43:54  +0100
From:      <AZ957%DK0RRZK0.BITNET@CUNYVM.CUNY.EDU>
To:        aix-l@pucc, tcp-ip@sri-nic.arpa
Cc:        iea25@leah.albany.edu, ji@close.cs.columbia.edu, monteiro@polygraf, u20139@uicvm
Subject:   AIX-PS/2 and 3COM ethernet cards
Some weeks ago I asked for the possibility of using 3COM cards for AIX,
and I got a definite *no* from a 3COM representative, whose answer I
would like to share with these mailing lists:

>>        From Eric_Siegel@DSD.3Mail.3Com.COM:
>>
>>        To my knowledge there is no driver available as yet from IBM
>>        enabling their AIX software to work with 3Com's Ethernet
>>        adapters. Many customers have expressed interest in having such
>>        a device driver and I would love to see it made available by
>>        IBM. Unlike many of its adapter competitors, 3Com does not write
>>        any of the drivers which enable its adapters to work with many
>>        of the popular thrid-party software applications. The third-
>>        party software companies themselves (IBM, DEC, SUN, Novell, etc)
>>        write, test, certify, market, and support their drivers for 3Com
>>        adapters. I would suggest sending your request to IBM to see if
>>        they will commit to developing such a driver for the 3Com
>>        EtherLink/MC. Thanks for your continued support of 3Com adapters
>>        and I'll let you know if I here anything else from IBM.
>>
>>        Eric Siegel
>>        Product Manager
>>        3Com Corporation
>>        Santa Clara, CA

So together with IBM's no, we were out and had to buy an expensive
Ungermann-Bass adapter to continue our tests.

Jochen Roderburg
Regional Computing Center
University of Cologne         Tel. :   +49-221/470-4564
Robert-Koch-Str. 10           BITNET:  A0045 @ DK0RRZK0 (CDC NOS/BE)
D-5000 Koeln 41                    or  A0045 @ DK0RRZK1 (IBM VM/CMS)
West Germany                       or  AZ957 @ DK0RRZK0 (Siemens SINIX)
-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 89 18:56:41 GMT
From:      raj@hpindwa.HP.COM (Richard Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: subnetting on non-byte boundaries

>
>     Worry 1.1:  The only examples in the manuals show subnetting on byte
>       boundaries.  Will a 6/10 (vs 8/8) bit-split really work?  (Context:
>       lots of Suns running 4.0.3;  VMS VAXen running CMU-TEK 6.4; some
>       random Apollos and HPs that we don't care about, much.)
>
>>          Here we have split ours with 4/12 since we have lots of
>>         terminal servers and wanted 4k addresses on one network.
>>         One of these logical subnets can thengo thru a router and
>>         change the mask on the otherside to 8/8. This way we can
>>         hace lots of small subnets and a few big ones. We have had
>>         no problem with devices such as the SUN's where you can set
>>         the mask at the bit level. However there are some machines
>>         (HP STARLAN on A HP-3000) for instance that won't support
>>         this since they simply ask what class you are when you
>>         install.  In it's case you must put it on the other side of
>>         a router that sets the mask to class C.

Don't care about the HP's?!!!! (Couldn't resist ;-)

Anyway, you shouldn't have to put that 3000 in the corner for much
longer, as subnets are being put into both MPE/V and MPE/XL - releases
for each should be comming 'real soon now' but i'm not supposed to
tell exactly when ;-(.  As to subnetting to byte boundaries with those
beasties, you'll be able to configure a subnetmask in a network's IP
screen using the dotted decimal notation without word/byte/nibble
restrictions.

rick jones
working to subvert 3000 networking from within ;-)

standard disclaimers and whatnot

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 89 21:02:51 GMT
From:      robert@trwind.UUCP (Robert W. Snyder)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Request for information - front-ending IBM 7171 with CISCO ASM

Robert Snyder
>
>I am trying to front-end an IBM 7171 with a CISCO ASM.  I have
>gotten it to work, but there are some performance problems.  Has
>anyone out there done this thing, and could I please ask you some
>questions?
>

I have not seen any responses on this that helped you with the 7171 problems
so I thought I would try to help by sharing the problems I recalled.

I developed a terminal server for TRW and I eventually had a field engineer
interface one to a 7171 in a milking machine fashion.  There were a few
problems I had to contend with.

	1. At the time the 7171 did not do xon/xoff flowcontrol properly
	   
	   Symptom: The network conection would appear to lock up or
	   have character loss.
	   
	   Analysis:
	   After looking at a lot of serial data analyzer output, I discovered
	   that when the terminal server flow controlled the 7171, the
	   7171 not only discontinued the transmission of normal data traffic
	   but also discontinued sending xons/xoffs, which caused it to
	   enter a "catch 22" state where both sides where flow-controlled
	   and neither could release flow-control until some action was
	   taken by the other or it would drop characters on the floor
	   because the 7171 refused to inform the terminal server that it
	   could not receive anymore characters.
	   
	   Resolution:
	   IBM fixed their code by offering an option to either allow
	   flowcontrolling of flowcontrol characters or a mode that
	   I needed to succeed that allowed flowcontrol characters to
	   be transmitted.

	2. The 7171 that I was interfacing to required that certain hardware
	   lines be asserted to transmit characters to the unit.  Once those
	   lines were asserted the 7171 began transmiting characters almost
	   instantly.

	   Symptom: The user would see a message the looked like this
	   "gin:" instead of "Login:" (I dont remember the actual message
	   but it was some sort of logon message)

	   Analysis:
	   When the hardware line were asserted the network link was not
	   quite up.  It was a couple character times off

	   Resolution:
	   I fixed my code.

	   I mention the second problem just because the 7171 was the only
	   device I ran into that exhibited this operation.

Disclaimer:  My experiences with the 7171 are specific to interfacing 
	     problems I experienced about 3 to 4 years ago.  I am not
	     an expert on the 7171, just good with terminal servers
	     and serial devices.




-- 
Robert Snyder       Disclaimer  --  nobody claims dis, but me
TRW Information Networks Division 23800 Hawthorne Blvd, Torrance CA 90505
USENET: trwind!robert
INTERNET: robert@trwind.TRW.COM                   Phone 213-373-9161

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 89 00:07:09 GMT
From:      mckenney@aai8.itstd.sri.com (Paul E. McKenney)
To:        comp.protocols.tcp-ip
Subject:   Re: Fletcher Checksum

In article <0CEC4873D71F21B02A@sdi.polaroid.com> HORN%HYDRA@sdi.polaroid.COM writes:
>[ . . . ]
>As transmission speeds increase I think that we will need to look
>more and more to forward error correction (FEC) techniques to
>replace ARQ techniques.

Nachum Shacham and I have recently written a paper on reducing the
need for ARQ through use of FEC.  The title is ``Packet Recovery
in High-Speed Networks Using Coding and Buffer Management''; drop me
a note with your USMail address if you would like a draft copy.

				Thanx, Paul

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 89 04:06:21 GMT
From:      rpw3@rigden.wpd.sgi.com (Robert P. Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: more on Fletcher

In article <89.12.09.1713.750@pescadero.stanford.edu>,
deering@PESCADERO.STANFORD.EDU (Steve Deering) writes:
+---------------
| My reason for wanting the checksum at the end of the packet is to allow
| a high-performance (hardware-assisted) implementation to compute the
| checksum on the fly as it copies a packet onto the wire, tacking it
| on at the end.  This eliminates one expensive pass over the packet.  I
| believe that Ultra's speedy TP-4 implementation places the checksum at
| the end for the same reason.
+---------------

If you have any packet buffer RAM on your controller, you probably want
to compute the checksum on transmit data as it's being copied from the
host to the controller, rather than as it's going out on the wire, just
to protect against mistakes while the data is in the controller.

Also, one of the reasons XTP has a header/trailer checksum separate from
the data checksum is so the data checksum can be done once during the copy
from the host (and at the other end when finally copying *to* the host
after reception) using some hardware assist as you suggest, while the
header/trailer checksum computation can be deferred until the packet is
actually about to go out onto the wire. This lets the headers contain
the most recent status available just as the packet was about to go out...

But the notion is similar; both checksums in XTP are in the trailer, and
can be calculated with hardware assist as part of the copy (or transmission).

-----
Rob Warnock, MS-9U/510		rpw3@wpd.sgi.com	rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 89 05:13:12 GMT
From:      rpw3@rigden.wpd.sgi.com (Robert P. Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: Fletcher Checksum

HORN%HYDRA@sdi.polaroid.COM writes:
+---------------
| FEC techniques are improving steadily and are now in widespread use
| both within modems (typically convolution codes) and in
| media like CDROM (Reed Solomon codes).  For the non-error case,
| there are table lookup approaches to RS (and some other) codes that
| reduce the computation load to 10-20 instructions per byte for a
| code that can withstand 0.001 ber.  The computation needed to repair
| an error is much larger...
+---------------

Actually, correcting can be pretty simple for certain special cases, such as
the modified (255, 252) R-S code that IBM used in the 3370(?) disk. (Sorry,
not sure about the model number; my Costello & Liu is at home.) That code
computes and transmits the residuals over the various primitive polynomials
separately, rather than with a single generator polynomial with the primitives
as factors (which is the usual case). It will correct one bad byte in 252 bytes
of data. (You can use shorter blocks, but each block needs 3 check bytes.)

In the special case of using a**(-1), a**0, and a**1 ["a" primitive in
GF(256)] as the divisors, three checksums (bytes) are generated, and if
you have 256-byte lookup tables to do your GF(256) multiplication (o.k.,
division by multiplying by the inverse), you get code like this (unoptimized!):

	for (i = 0; i <n; ++i) {
		Cm1 = recip_table_Am1[ Cm1 ^ data[i] ];
		C0 = C0 ^ data[i];	/* division by a^0 is simple XOR */
		C1 = recip_table_A1[ C1 ^ data[i] ];
	}

Then at the other end, you would compute rCm1, rC0, and rC1 (for "received
C_{-1,0,1}") similarly over the received data (*except* the trailing three
bytes, which are Cm1, C0, and C1), and XOR them respectively with Cm1, C0,
and C1 as received, then if C0 == 0 you have no error. If at most one byte
is in error, then C0 is the bits in error and C1/C0 (arithmetic done in
GF(256), by table lookup) is the byte number containing the error, and
Cm1 is used (I forgot how, probably by computing the reciprical position
number?) to detect (somewhat) against multiple errors.

Oh, you correct the error this way (simple!):

	bad_byte_num = GF_div(C1, C0);	/* GF_div is the table-lookup divide */
	data[bad_byte_num] ^= C0;

Anyway, on the transmit side you have 3 XORs and two table lookups (LOADs)
per byte, and on the receive side you have the same plus a couple of XORs
to check for errors, and a couple of table lookups and another XOR if you
need to correct.

If you also have a stronger checksum somewhere in the data (embedded CRC-32,
Fletcher, etc.), you can use that to guard against miscorrection, and drop
the Cm1 byte.  In that case the R-S code adds just two bytes to each block
of 253 bytes or less, and the CPU time is just over half of what was shown
above.  (Note that your other checksum must be *inside* the block.) After
correcting as per the R-S code (which just might correct a byte of your
other checksum), you recompute/check your other checksum on the corrected
data, and if it's o.k., you probably didn't miscorrect.

(Been thinking about using this code for SLIP over noisy lines. Now if I can
just find time to actually write/test/post the C code for the R-S routines...)

-----
Rob Warnock, MS-9U/510		rpw3@wpd.sgi.com	rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 89 07:20:31 GMT
From:      davec@CSUFRES.CSUFRESNO.EDU (David C. Choweller)
To:        comp.protocols.tcp-ip
Subject:   Trouble with PC NCSA 3c505


I am having problems using the new 3C505 driver with NCSA Telnet. I connect
to a host but after sometime the connection hangs. I do an (ALT-M) to see
the messages. Here's what I get.


Trying to open TCP connection to:<hostname>
DO Option TERMINAL TYPE (WILL)
IAC SB sent type VT102
DONT Option NAWS (WONT)
Will Option ECHO (DO)
Will Option Suppress GO AHEAD (DO)
DO Option ECHO (WILL)
WILL Option ECHO (DO)
DONT Option ECHO (WONT)

I get these same messages every time.
Can anyone, from these messages, figure out what is going wrong?


Particulars of my situation:

Machine : AST 386 DOS 3.30
ETHERNET CARD: 3C505 base addr 0x300 Int 15 DMA 5


I'm using Krishnan Gopalan and Stefancik's new 3C505 driver with the
following parameters:

3c505 0x60 15 0x300 0xd000
        /\ /\  /\     /\
        || ||    \\     \\
   packet hardware \\   base
   int    int      io   addr
   no     no       addr

I am not sure what some of these paramters refer to and use the defaults.
I know however the 3c505 in the machine uses interrupt 15, and DMA 5




If I start-up NCSA Telnet on the AST and ping it from a remote host, I
get a number of ping replies, around 15, and then it stops replying.
It seems I am communicating, but only for a short time. I would appreciate
if anyone can help me.




=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
+ D a v i d  C h o w e l l e r                                           +
+ ARPANET : davec@csufres.CSUFresno.EDU                                  +
+           davec@csuf3b.CSUFresno.EDU                                   +
+           davec@gaudi.CSUFresno.EDU                                    +
+ UUCP : davec@csuf3b.UUCP or                                            +
+        uunet!ames!lll-tis!lll-crg!csusac!csufres!davec                 +
+        ucbvax!ucdavis!csusac!csufres!davec                             +
=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 89 11:23:36 GMT
From:      santi@ixos.UUCP (Michael Santifaller)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Xerox Etherphone experiments?


	There is this book with the proceedings of a LAN conference,
	its title is "Local Area Networks" I believe, and the editor
	is Tony West from Sun, who was with IBM in Geneva, then.
	It has been published in the early '80. The book contains several
	articles about LANs, obviously, including one by Shoch (??) about
	an experiment with voice over Ethernet (3MB Ethernet at that time).
	The whole article sounded very interesting and encouraging,
	since I had never believed that Ethernet was suitable for
	voice at all. 

	Sorry, that I can't be of more help with the exact title
	and/or publisher.

	Michael

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 89 12:08:25 GMT
From:      wasc@cgch.UUCP (Armin Schweizer)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   traceroute


 I am looking for a utility which can tell me what route packets
have taken between two endpoints, showing switching to
alternate routes etc.

 Is traceroute the right thing? What exactly is traceroute doing?
Where can I get it from and how?

thank you
armin



       Armin R. Schweizer, CIBA-GEIGY AG, R1045.P.06, WRZ
                  4002 Basel / Switzerland
	          phone: -41-61-697'79'46

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 89 15:21:41 GMT
From:      dsamperi@marob.masa.com (Dominick Samperi)
To:        comp.protocols.tcp-ip
Subject:   NFS/UDP reliability

While dumping files using CPIO over NFS I've noticed that a file is dropped
now and then. What I do is cd to a directory which is an NFS mount point,
and type 'find . -print | cpio -ocvB > /dev/rmt18'. Here /dev/rmt18 is
a local tape drive, while "." is a directory on a remote machine. What
happens is that now and then CPIO issues a line of the form:
<filename> ?
This is CPIO's way of saying that it could not open the file. I've checked,
and there is nothing special about filename, i.e., the permissions are not
any different from other files that were dumped fine. In fact, if I repeat
the dump command, DIFFERENT files are not accessible! I was told by the
computer vendor that this is to be expected due to the unreliability of
UDP, and that I cannot use the tape drive to perform reliable dumps in
this way. 

An alternative procedure was suggested. It involves using dd to
dump the output of CPIO over NFS. The problem with this approach is that
it does not provide multi-volume support.

Can anyone suggest other solutions? Thanks!
-- 
Dominick Samperi -- Citicorp
dsamperi@Citicorp.COM
uunet!ccorp!dsamperi

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 89 15:37:06 GMT
From:      af%sei.ucl.ac.be@CUNYVM.CUNY.EDU ("Alain FONTAINE ", Postmaster - NAD)
To:        comp.protocols.tcp-ip
Subject:   MB, MG, MR....

Hi. May I ask if anybody is currently playing with the experimental
mailbox RR's ? Is there any software using them ? Do most implementations
of the DNServers already handle them ? Seems exactly what I need to
handle our 'logical addresses'. Thanks for any info.       /AF

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 89 16:00:56 GMT
From:      mss+@ANDREW.CMU.EDU (Mark Sherman)
To:        comp.protocols.tcp-ip
Subject:   Use of ASN.1

Fascinating. How is it that you came to the conclusions (1) ASN.1 makes
a great deal of sense when used to hold multi-media documenst and (2)
[electronic mail] doesn't need to parsed in real-time. I can name at
least one project that was canceled because the ASN.1 requirement of ODA
is such a pain. (We were certainly never thrilled by it for ODA.)
	-Mark

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 89 16:41:57 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Use of ASN.1



 >Fascinating. How is it that you came to the conclusions (1) ASN.1 makes
 >a great deal of sense when used to hold multi-media documenst and (2)
 >[electronic mail] doesn't need to parsed in real-time. I can name at
 >least one project that was canceled because the ASN.1 requirement of ODA
 >is such a pain. (We were certainly never thrilled by it for ODA.)

Mark,

1. i wouldnt claim ASN.1 ever made *much* sense

2. the PP X.400 system has channels to convert inbound ODIF into
locally real time readable formats (e.g. slate) - MTAs do not need to
parse e-mail in real time (by definition a spooled communication) .
(actually, you parse ASN.1 offline, and generate *concrete* syntax
parsers, that can easily run in real time - a recent survey we did
uncovered at least 9 such parser/generators).

however, if digital multi-medi conferencing were widely available, 
whatever presentation standard it used
would clearly take the absurd load off MTAs when used for
e-mail as well

actually, the position i take is that TCP/IP got it right for end to
end and interconnection for networks of the 70s and 80s, OSI got it right 
for 19th century application support, and no-one has it right for the next 
decade yet...
and that means 
we've only got a week to develop and field transaction protocols, decent 
XDRs, congestion proof networks, and usable applications that dont take a
minimum of a Sun 4/330 to run as fast as people (like our X.500 and
X.400 implementations)

- then we can start
making nice sounds about integrated video/voice/data in an Internet
without sounding like infernal optimists 

(hopefully some secret
consortium is about to unleash such a system for free so there's a
nice de-facto solution just like NFS and X got done, but this time
they'll repair some of the mistakes [and write it all in Algol
68:-)])

so thats my message for a happy winter solstice...

cheers

 jon

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Dec 89 16:41:57 +0000
From:      Jon Crowcroft <J.Crowcroft@Cs.Ucl.AC.UK>
To:        Mark Sherman <mss+@andrew.cmu.edu>
Cc:        yee@trident.arc.nasa.gov, isode@nic.ddn.mil, tcp-ip@nic.ddn.mil, iso@nic.ddn.mil
Subject:   Re: Use of ASN.1


 >Fascinating. How is it that you came to the conclusions (1) ASN.1 makes
 >a great deal of sense when used to hold multi-media documenst and (2)
 >[electronic mail] doesn't need to parsed in real-time. I can name at
 >least one project that was canceled because the ASN.1 requirement of ODA
 >is such a pain. (We were certainly never thrilled by it for ODA.)

Mark,

1. i wouldnt claim ASN.1 ever made *much* sense

2. the PP X.400 system has channels to convert inbound ODIF into
locally real time readable formats (e.g. slate) - MTAs do not need to
parse e-mail in real time (by definition a spooled communication) .
(actually, you parse ASN.1 offline, and generate *concrete* syntax
parsers, that can easily run in real time - a recent survey we did
uncovered at least 9 such parser/generators).

however, if digital multi-medi conferencing were widely available, 
whatever presentation standard it used
would clearly take the absurd load off MTAs when used for
e-mail as well

actually, the position i take is that TCP/IP got it right for end to
end and interconnection for networks of the 70s and 80s, OSI got it right 
for 19th century application support, and no-one has it right for the next 
decade yet...
and that means 
we've only got a week to develop and field transaction protocols, decent 
XDRs, congestion proof networks, and usable applications that dont take a
minimum of a Sun 4/330 to run as fast as people (like our X.500 and
X.400 implementations)

- then we can start
making nice sounds about integrated video/voice/data in an Internet
without sounding like infernal optimists 

(hopefully some secret
consortium is about to unleash such a system for free so there's a
nice de-facto solution just like NFS and X got done, but this time
they'll repair some of the mistakes [and write it all in Algol
68:-)])

so thats my message for a happy winter solstice...

cheers

 jon

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 89 16:43:42 GMT
From:      dtt91@wash08.uucp
To:        comp.dcom.lans,comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   nfs,pcnfs,terminal emulator

does anyone know of any terminal emulators for the pc that can ride on top
of the pcnfs tcpip stack.  we are looking for alternatives to the SUN pcnfs
VT100 implementation.

Any information pertaining to this is appreciated . Please contact 

Gary M. Patterson
TEL: 703-6853482
UUCP: uunet!wash08!wash09!dtt91

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 89 16:46:14 GMT
From:      amanda@mermaid.intercon.com (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP - How unreliable?

In article <8912141305.aa00864@mintaka.lcs.mit.edu>, sra@lcs.mit.edu (Rob
Austein) writes:
> This is of course a good general rule, but there is at least one
> important special case where UDP is (arguably) the right sollution for
> a protocol that works over arbitrary distances: [DNS]

Actually, I think of this as a case where retransmission is simple to figure
out.  For an isolated query/response (such as DNS), UDP is often quite
appropriate, for exactly the reasons Rob mentioned.

Amanda Walker
InterCon Systems Corporation
--

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 89 17:56:12 GMT
From:      jpd@pc.usl.edu (DugalJP)
To:        comp.protocols.tcp-ip
Subject:   Re: Public Domain Dialout SLIP?

In article <1989Dec13.005930.22053@alembic.acs.com> csu@alembic.acs.com (Dave Mack) writes:
>I'm preparing to start hacking my version of KA9Q to support dial-out
>SLIP.

Dave, version 890421.1 supports this, using the uucp L.sys send/expect syntax.



--
-- James Dugal,	N5KNX		Internet: jpd@usl.edu
Associate Director		Ham packet: n5knx@w5ddl
Computing Center		US Mail: PO Box 42770  Lafayette, LA  70504
University of Southwestern LA.	Tel. 318-231-6417	U.S.A.

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 89 18:06:02 GMT
From:      barrym@infmx.UUCP (Barry Mednick)
To:        comp.protocols.tcp-ip
Subject:   getting processid from netstat

Given the output from netstat -A, can I relate one of the connections
to a processid?  In particular, can I use the foreign address or the
Process Control Block address to derive the process id that is using
that connection?

Please e-mail !pyramid!infmx!barrym  or call 415 926-6674

Thanks for your help.

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 89 19:08:19 GMT
From:      zeleznik@cs.utah.edu (Mike Zeleznik)
To:        comp.protocols.tcp-ip
Subject:   Looking for ISO 7498 Part 2

Can anyone point me to an on-line copy of ISO 7498 Part 2?  This is the
security extensions for 7498.  I understand I can order it from Omnicon,
but thought maybe there was a less expensive way; I really just need to
look it over.  Thanks.

Mike

  Michael Zeleznik              Computer Science Dept.
                                University of Utah
  zeleznik@cs.utah.edu          Salt Lake City, UT  84112
                                (801) 581-5617

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 89 22:13:37 GMT
From:      greg@duke.cs.unlv.edu (Greg Wohletz)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Standard cable lengths

To quote from some cabletron documentation:

	When making up networks requiring shorter cable run, Ethernet
standard length 23.4m, 70.2m, and 117 meter cable sections should be
used.  These cable sections may be connected together to form a cable
segment by using a barrel connector.  Use of non-standard cable
lengths may result in impedance mismatches causing reflections to
occur.  These reflections may cause data errors.


My question is how critical is this?  I have some cable runs that will
probably be around 100 meters, should I be sure they are 117 meters?

    	    	    	    	    	    --Greg
    	    	    	    	    	    greg@duke.cs.unlv.edu

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 89 23:36:46 GMT
From:      bryan@iconsys.UUCP (Bryan Cardoza)
To:        comp.protocols.tcp-ip
Subject:   Request for Opinions: LAN Analyzers

Gentlefolk,

Please e-mail to me your opinions on which LAN analyzer you would
purchase (or have purchased), and why.  I am specifically interested
in working with Ethernet and being able to have the analyzer decode
TCP/IP, NFS, X and other "high-level" protocols.

We have looked at Network General's Sniffer, and I was just wondering
if any of you had any other units to suggest.

Thanks for your help.

-- 
Bryan Cardoza			uunet!iconsys!bryan
Software R&D Manager
SANYO/ICON			Phone: (801) 225-6888
Orem, Utah			FAX: (801) 226-0651

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 89 23:53:55 GMT
From:      John_Robert_Breeden@cup.portal.com
To:        comp.protocols.tcp-ip
Subject:   Re: RE: Network Wiring Scheme

>
>Ken,
>
>Until the IEEE 10baseT specifications are published next year there really is 
>no standard for ethernet over twisted pair.  Many vendors seem to have defined
 
>what they think the proposed standard will be and are at least announcing 
>products to support it.  Most vendors are producing products to work on UTP
>(unshielded Twisted Pair) for ethernet and even big blue has it's type 3 media
>filters to allow Token Ring to work on UTP.  
>
>We have
>started to test different vendors UTP ethernet products but as yet have not 
>made a decision as to which one to support.  Many of the Research Labs and 
>departments have chosen to install departmental/building thick coax with AUI
>bulkhead mounts off xceiver taps instead of attempting to "beta test" the as
>yet unpublished 10baseT standard for UTP Ethernet.
>
>We have tested or have currently installed on UTP the following LANs;
>
>Arcnet UTP hubs and PC cards using LANtastic's Software
>Arcnet UTP Hubs & PC cards using Novell Software
>Arcnet UTP Hubs & PC cards using Arcnet Software
>Cabletron UTP Ethernet concentrator & UTP transceivers
>Synoptics UTP Ethernet concentrators & UTP transceivers


WHAT IN GOD'S NAME WILL CHANGE BETWEEN THE 10BASET DRAFT AND THE FINAL
STANDARD THAT WOULD OBSOLETE THE EXISTING VENDOR'S PRODUCTS THAT CONFORM
TO THE 10BASET DRAFT TODAY??? - NOTHING!!!!!!!!!!!

None of the basic specs for 10baset in the drafts has changed (or will
change) before the standard is voted on - and the proof of that state-
ment is the ability to "plug-and-play" with the conforming vendors
who manufacture to the 10baseT draft today (AT&T, HP and UB to mention a 
few). Given that ability I'll beat the cost of hardware by having MANY 
vendors to choose from today over using those vendors that keep users locked 
into TRUE PROPRIETARY architectures (read Synoptics and Cabletron). Don't 
knock those vendors that are trying to level the playing field by activly 
supporting and MANUFACTURING to standards (or well defined draft standards) 
by buying into the hype "that the draft isn't defined well enough to build
product to" - that's hog wash!

But then if I supported ARCnet, Novell, Cabletron and Synoptics standards
would a moot point.


standard 
IBM Token Ring MAU's and IBM Token Ring PC cards using Novell software
	The MAU's between floors are connected using IBM type 1 cable
AT&T StarLAN using AT&T Hubs, PC cards, & software

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 89 06:07:47 GMT
From:      Nagle@cup.portal.com (John - Nagle)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks Considered Harmful...


      Well, in the real world, I understand that electronic mail is
on the decline, and is being replaced by fax.

					John Nagle

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 89 08:08:09 GMT
From:      dyer@spdcc.COM (Steve Dyer)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS/UDP reliability

What OS (with NFS) is running on the client machine; the machine running
"cpio"?

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edu

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 89 14:55:30 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  traceroute

Armin:

The record route option is the only way of finding out the exact path that a
packet from point A to point B.  The ICMP packet with the recorded routes may
or may not get back to you.

If you're having problems getting to point B from point A, you can use trace-
route to help identify where your problem might be occurring.  Traceroute uses
an undefined UDP port and the time to live (TTL) header option.  In its default
mode of operation, it transmits its first packet to the destination with a TTL
of one.  It will normally transmit two more packets with the same TTL after an
internal timer expires or after a time exceeded packet is received before
incrementing the TTL value.  For each TTL value it displays the responding
host name and the round trip time for each of the packets transmitted.

Traceroute continues incrementing the TTL until the default maximum of 30 is
reached or until a port unreachable response is received.  At best, you can
infer that this is the path your packets were taking to point B; however, you
may find a different path being reported should you re-initiate traceroute.

Merton

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 89 18:55:13 GMT
From:      enger@SCCGATE.SCC.COM (Robert M. Enger)
To:        comp.protocols.tcp-ip
Subject:   Re:  traceroute

Traceroute can also use source-routed packets, so that one can
attempt to examine the path that packets are taking on their way
back to you.

However, some systems don't report all the interfaces, etc.
Like the nss, that apparently only decrements ttl once, even though
it goes through lots of interfaces.  Record-route does appear to
capture most of the interface addresses.  However, record-route
is limited to 9 addresses!  A source-route, record route ping 
would be a nice thing to try.  Anyone got one?

Bob Enger
Contel Federal Systems

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 89 18:56:14 GMT
From:      barmar@Think.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Networks Considered Harmful...

In article <25086@cup.portal.com> Nagle@cup.portal.com (John - Nagle) writes:
>      Well, in the real world, I understand that electronic mail is
>on the decline, and is being replaced by fax.

That was precisely the point McCarthy was making in his article.  He said
that fax has become popular because it works with the current home
communications network (the phone system).  For email to become popular it
will have to fit in similarly, rather than requiring users to have an
account on a computer connected to an email network.
Barry Margolin, Thinking Machines Corp.

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

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 89 19:10:21 GMT
From:      roy@phri.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks Considered Harmful...

In <25086@cup.portal.com> Nagle@cup.portal.com (John Nagle) writes:
>      Well, in the real world, I understand that electronic mail is
>on the decline, and is being replaced by fax.

	A year or so ago, some people here had need to establish regular
communications with somebody at Monash University in Australia.  We proved
that email worked in both directions but then the guy at the other end
insisted we switch to fax.  Seems that he gets charged for both incomming
and outgoing email and fax was cheaper!
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,philabs,cmcl2,rutgers,hombre}!phri!roy
"My karma ran over my dogma"

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 89 04:28:12 GMT
From:      brian@ucsd.Edu (Brian Kantor)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Xerox Etherphone experiments?

Not directly relevant, but it's proven to be quite easy to wire a
telephone handset to my SparcStation and talk across the building over
the ethernet using the CODEC chip that's built in the SS1.  The delay
is a bit like a satellite link and completely controllable by adjusting
the buffering size.  It even has sidetone.

It's lots of fun to rcp into a coworker's machine and suddenly his
workstation starts saying "Toto, I've a feeling we're not in Kansas
anymore!"

Anyone attempting to do this as a serious hack must consider a squelch
algorithm so that you're not sending lots of zero-volume packets across
the Ethernet.

No doubt I'll soon get a nastygram from someone for adding to the
traffic on the internet....
	- Brian

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 89 07:20:56 GMT
From:      pvo3366@OCE.ORST.EDU (Paul O'Neill)
To:        comp.protocols.tcp-ip
Subject:   source-route, record route ping (Re:  traceroute)

>	A source-route, record route ping 
>	would be a nice thing to try.

That's what the folks who wrote ``pong'' thought.  Until they discovered
that it's a good way to remotely crash a lot of BSD 4.2-based gateways.

Not very neighborly.....

Paul O'Neill                 pvo@oce.orst.edu
Coastal Imaging Lab
OSU--Oceanography
Corvallis, OR  97331         503-737-3251

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 89 20:05:58 GMT
From:      cam@SATURN.ACC.COM (Chris Markle acc_gnsc)
To:        comp.protocols.tcp-ip
Subject:   FTP server response to perm I/O error

Folks,

How should FTP server that is receiving data (eg. STOR, STOU) close the
data connection in response to a permanent I/O error? 

Let me outline a scenario... An FTP client initiates a STOR to our server
and begins to send 100 megabytes. The data set that is the STOR target is
one measly disk track, so we have an "out of space condition". We send
the apropriate 4xx response over the control connection, but then what?

Our current scheme is issue a non-abortive close of the data connection.
The problem with this is that the remote end keeps sending the whole 100
MB which we are now just throwing away. You might say "well just issue an
abortive close (ie. TCP RST)" but that seems to cause certain clients to
close the control connection as well! (One of these clients is 4.3 BSD ftp
which we definitely need to work with).

Are clients that close the control connection when the data connection is
reset broken? How should this situation be handled between FTP servers
and clients?

Chris Markle

ACC (Advanced Computer Communications)

cam@saturn.acc.com
(301)290-8100

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 89 20:16:39 GMT
From:      enger@SCCGATE.SCC.COM (Robert M. Enger)
To:        comp.protocols.tcp-ip
Subject:   Re:  source-route, record route ping (Re:  traceroute)

Isn't it about time for 4.2 to die?  Yes, 4.2 is dumb, but even in
a court of law ignorance is no excuse (imagine how many politicians
could get off if ignorance was all it took :-)  ).

Source route traceroute is out already, better get the weak and disabled
off the street.  There must be a nice warm corner waiting for them in
a Smithsonian exhibit, perhaps right next to the Strowger switches?

Happy holidays to all,
Bob Enger

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 89 23:10:40 GMT
From:      palowoda@fiver.UUCP (Bob Palowoda)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks Considered Harmful...

From article <1989Dec16.191021.26031@phri.nyu.edu>, by roy@phri.nyu.edu (Roy Smith):
> In <25086@cup.portal.com> Nagle@cup.portal.com (John Nagle) writes:
>>      Well, in the real world, I understand that electronic mail is
>>on the decline, and is being replaced by fax.
> 
> 	A year or so ago, some people here had need to establish regular
> communications with somebody at Monash University in Australia.  We proved
> that email worked in both directions but then the guy at the other end
> insisted we switch to fax.  Seems that he gets charged for both incomming
> and outgoing email and fax was cheaper!

   I doubt this. It takes 4x times longer to transmit one page of information
on fax (asume ascii) than regular email. Also if they where being charged
for incoming calls than they where useing a service that charged them for
it. Way they didn't they just get a uucp connection and email direct? 

   Fax will still play a big part in communications.  It is very convenient
to receive fax messages via email. At least than you can have routers and/or
directory services. I see this popping up for Xenix and Unix system's already
where some software vendors have written drivers for boards like the AST 
fax boards. For a user that wishes never to store/retrieve/process such
documents than maybe a simple fax will do. For a paper office this is 
fine. In the real world computers keep track of information. Therefor
I don't see fax replaceing email. It would be difficult to repalce 
something like the whole Usenet by fax. Mergeing it would be nice.

---Bob

 


-- 
Bob Palowoda  pacbell!indetech!palowoda    *Home of Fiver BBS*  login: bbs
Home {sun|daisy}!ys2!fiver!palowoda         (415)-623-8809 1200/2400
Work {sun|pyramid|decwrl}!megatest!palowoda (415)-623-8806 2400/9600/19200 TB
Voice: (415)-623-7495                        Public access UNIX XBBS   

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 89 23:19:50 GMT
From:      pvo3366@sapphire.OCE.ORST.EDU (Paul O'Neill)
To:        comp.protocols.tcp-ip,orst.internetworking
Subject:   Re:  source-route, record route ping (Re:  traceroute)

In article <8912172016.AA01804@sccgate.scc.com> enger@SCCGATE.SCC.COM (Robert M. Enger) writes:

>Isn't it about time for 4.2 to die?

Sure. And I'm glad my systems are running the latest and the greatest.
However...

>Source route traceroute is out already, better get the weak and disabled
>off the street.

I know folks who are stuck at 4.2 (SunOS 3.5) because their vendors haven't
updated critical applications to run under SunOS 4.0 yet.  Were I to go
out and start crashing their gateways w/ pong or S-R traceroute I doubt
they or the Internet community at large would appreciate it.  

Your street analogy is quite appropriate.  Should Corvettes run Model-T's
off the road because they're weak & disabled?  Especially if there's a
passing lane?  (Regular traceroute usually tells me all I need without 
crashing them.)


Paul O'Neill                 pvo@oce.orst.edu
Coastal Imaging Lab
OSU--Oceanography
Corvallis, OR  97331         503-754-3251

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 89 00:26:33 GMT
From:      guyton%condor@RAND.ORG
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute & record-route

While traceroute is pretty good for figuring paths from A to B, it's
useless for figuring out the return paths unless you can invoke it
again from B.

Record route is almost useless because there is only room for six
addresses in the IP header.  This was ok during the days when each
"network" was the size of ARPANET or MILNET, but with a network id
(and route) for each T1 line on the current internet, the first six
addresses usually don't tell you very much.

-- Jim Guyton
   guyton@rand.org

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 89 01:01:42 GMT
From:      roy@alanine.phri.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Of interest to time freaks


	This has nothing directly to do with tcp-ip, but I know a lot of time
freaks hang out here.  If you care about keeping accurate time, in particular
the history of said endevour, you will probably want to get your hands on the
following interesting little book I found in the library today:

%T Sky with ocean joined: Proceedings of the sesquicentennial symposia of
the U.S. Naval Observatory, December 5 and 8, 1980.
%E Steven J. Dick
%E LeRoy E. Doggett
%I U.S. Naval Observatory
%C Washington, D.C.
%D 1983

	No, they don't discuss NTP, but they do talk about earlier ventures
in that direction such as Western Union clocks (discussed at length on the
telecomm digest in the past) and time balls, as well as more modern devices
such as atomic clocks.
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,philabs,cmcl2,rutgers,hombre}!phri!roy
"My karma ran over my dogma"

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Dec 89 10:25:24 CST
From:      dab@opus.cray.com (Dave Borman)
To:        samsung!munnari.oz.au!basser!metro!bunyip!brolga!ggm@think.com, tcp-ip@nic.ddn.mil
Subject:   Re:  partial transfer recovery in RFC and OSI protocols
> ftp doesn't seem to have any concept of unreliable underlying transport 
> or link. I would dearly love to see something like UK-NIFTP's partial
> file transfer recovery in ftp. (in fact, I believe most uk-niftp don't
> implement file xfer recovery and rewind the retransmission back to the front) 

> [history]   Was partial transfer recovery considered? If so, why was it 
> 	    rejected? I heard arguments against its implementation on
> 	    JANET such as "too hard" and "doesn't make sense between
> 	    divergent h/w or opsys" neither of which I think make sense,
> 	    especially given machine-independant upper-level encodings
> 	    like compressed-batch/lempel-ziv/NNTP and hop-based services
> 	    where you are placed in the role of an intermediate carrier.

>	-George
>
> Internet: G.Michaelson@cc.uq.oz.au                     Phone: +61 7 377 4079
>   Postal: George Michaelson, Prentice Computer Centre
>           Queensland University, St Lucia, QLD Australia 4067. 

The FTP protocol has always had a re-start mechanism.  Look at RFC 959,
page 26, section 3.5, and page 31 (and RFC 1123, page 36, section
4.1.3.4 for corrections to RFC 959).  The only problems with RESTART
are that 1) lots of BSD based systems don't implement it, because 2)
it only is defined for Block or Compressed modes, not for Stream
mode (and most BSD based systems only use Stream mode).  There are
implementations of FTP that do non-standard RESTART over Stream
connections. I don't know what the current status is of getting this
to be offically blessed.
			-Dave Borman, dab@cray.com
-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Dec 89 09:46:59 EST
From:      Ken Pogran <pogran@ccq.bbn.com>
To:        mcsun!unido!tub!fauern!tumuc!guug!ixos!santi@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Xerox Etherphone experiments?
A recent posting mentioned a paper presented by John Shoch in
1980 on carrying voice traffic over Ethernet.  I happen to have a
copy of the conference proceedings, so here's the complete
bibliographic reference:

     J. F. Shoch, "Carrying Voice Traffic thorugh an Ethernet
     Local Network: A General Overview," in: "Local Networks for
     Computer Communications; Proceedings of the IFIP Working
     Group 6.4 International Workshop on Local Networks," edited
     by Anthony West and Phillipe Janson; North-Holland
     Publishing Company, 1981.  ISBN: 0 444 86287 0

P.S.:  the experiments were done over the original 3 Mb/s
ETHERNET.

Ken Pogran
-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 89 05:27:58 GMT
From:      ggm@brolga.cc.uq.oz (George Michaelson)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   partial transfer recovery in RFC and OSI protocols

ftp doesn't seem to have any concept of unreliable underlying transport 
or link. I would dearly love to see something like UK-NIFTP's partial
file transfer recovery in ftp. (in fact, I believe most uk-niftp don't
implement file xfer recovery and rewind the retransmission back to the front) 

Once you start looking at that sort of functionality, you might wind up 
agreeing with the OSI reference model which (i think) puts it in session level
but given a null session layer you dont have that choice.

I guess I'd rather see suitable code in an underlying layer, so that the same
functionality was available to ALL TCP-based services, nntp-over-slow-lines
and other bulk transfer being obvious candidates. I'm not (quite) silly
enough to see everyone hacking their kernel, and nobody is offering invisble
glue between TCP and the services, so I guess its a per-service addition or
nothing.

Why bother? 

    (1)	bandwidth is scarce in several crucial places
		cross-channel links
		atlantic links
		pacific links.

    (2) Point-to-point links are NOT decreasing, SLIP to small boxes
	and dial-in IP are increasing and thus "noisy" links are
	just as common dispite backbone upgrades and other net-level
	advances.

    (3) IP based services aren't going away for years to come.

    (4) OSI services can provide this functionality and it might
	be nice to be able to bridge into Internet services and get
	the same thing. [err.. can they? I *think* they can...]

ACSnet has partial transfer recovery built into the transport(ish) level
as well as a multiplexed link level. This is *extremely* useful and far
outweighs in my opinion the other (mis?)features of this package/protocol.
With its probable demise as the "backbone" protocol across Australia I suspect
we are going to see much WORSE service until people learn how to use the IP
based services "properly", ("manual" CSMA-CD when slow IP detected a.k.a try
again at 3am) 

Question(s):

[history]   Was partial transfer recovery considered? If so, why was it 
	    rejected? I heard arguments against its implementation on
	    JANET such as "too hard" and "doesn't make sense between
	    divergent h/w or opsys" neither of which I think make sense,
	    especially given machine-independant upper-level encodings
	    like compressed-batch/lempel-ziv/NNTP and hop-based services
	    where you are placed in the role of an intermediate carrier.

[whinge]    Is it sensible/possible to extend existing product(s) to provide
	    this function? We see Telnet and other extensions, PEP is out,
	    clearly The RFCs aren't rolling over and dying yet. Too late to
	    add into ftp? can it make 4.5bsd?

[cringe]    Will people be using this feature in OSI applications? does it
	    get turned on automatically or is it missing from most existing
	    setups and thus impossible to use in MHS/FTAM over slow/noisy
	    lines?


Enquiring mind wants to know!

	-George
	

Internet: G.Michaelson@cc.uq.oz.au                     Phone: +61 7 377 4079
  Postal: George Michaelson, Prentice Computer Centre
          Queensland University, St Lucia, QLD Australia 4067. 

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Dec 89 11:02:01 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Networks considered harmful
<John Nagle>
>      Well, in the real world, I understand that electronic mail is
>on the decline, and is being replaced by fax.

<Barry Margolin>
>That was precisely the point McCarthy was making in his article.  He said
>that fax has become popular because it works with the current home
>communications network (the phone system).  For email to become popular it
>will have to fit in similarly, rather than requiring users to have an
>account on a computer connected to an email network.

<Roy Smith>
>	A year or so ago, some people here had need to establish regular
>communications with somebody at Monash University in Australia.  We proved
>that email worked in both directions but then the guy at the other end
>insisted we switch to fax.  Seems that he gets charged for both incomming
>and outgoing email and fax was cheaper!

I have seen comments like this before.  And I have attempted to answer
them before.  It is a shame to see supposed experts on communications
who are apparently as ignorent of what is really available as the general
public.  I personnaly intend to write a letter (or maybe just send a
copy of this message) to the ACM and see what kind of hornets nest it
stirs up.

The only reason that FAX is more popular than Email is "PR".  You cannot
watch TV without seeing/hearing about FAX.  It is in the programs as well
as the commercials.  You can't drive down town without hearing it on the
radio, seeing it on billboards, and seeing banners in the stores all
pushing FAX.  They sell them in the MALL and in Radio Shack.  Before
long there will be a guy on the street corner holding his coat open
and whispering "Hey Mac, you want to buy a FAX real cheap!!"

If you have any doubt of this, try a little experiment.  Ask a couple
of your neighbors if they know what FAX is and then ask if they know
what Email is.  The try it on the local kids.  My 10 year old daughter
knows what FAX is and yet claims to not know what Email is even though
she has used it herself (on my home UNIX box) and she sees me using it
every day.  It's all a matter of PR.

But the truth is, FAX offers nothing that can't be done with the PC sitting
on your desk. And the PC can even do it better.  You can send Email from
PC to PC or PC to "Real computer" or "Real computer" to PC.  The softtware
and hardware already exist.  In fact they have been around for years.
The hardware we all have and the software doesn't even cost anything!!!
You can send text, you can send pictures, you can even send color pictures.
And you can do it the same way you do with a FAX.  You can call the addressee
on the phone and send it to him directly.  As a matter of fact it has probably
reached the point where you can buy all the hardware necessary to do this for
about the same price as one of those full featured FAX machines.
Interestingly enough, the Email scenario has numerous advantages over the
FAX scenario.  I can move more data quicker.  I can manipulate the data
easier when it arrives.  And if the number is busy, I don't have to stand
around and wait.  The PC can do it for me.

So, someone please tell me "What is so great about FAX?" and why can't
those of us who use Email all the time convince the rest of the world
how much better it really is??

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 89 08:55:10 GMT
From:      freedman@euclid.math.temple.edu (Avi Freedman)
To:        comp.protocols.tcp-ip
Subject:   Packet Grabber for Suns?


	Does anyone know of code that allows a Sun 3/60 or 4/280
	running SunOS 4.X to capture all packets running by it?
	What I'd like is a source for a program like etherfind
	(presumably using NIT or some other way to get at the
	Ethernet packets in promiscuos mode) and has a hook for
	processing a packet.

	I've Read The Fine Manual on NIT(4), and if I have to, 
	I'll write such a piece of code myself, but if someone
	else has it, that would be great... :-)

	While I realize that this opens up a tremendous security
	hole, one _does_ have to have root access to use it, and
	networks _should_ be isolated by  bridges, gateways, or 
	what have you, so that LAT passwords to accounts on CIS 
	machines aren't flowing past the math network (unless 
	there is an rlogin or such from the math network).  
	Besides, if one wanted to look at all traffic seriously 
	enough, one could just bring in a portable PC with an 
	Ethernet card and run Netwatch or one of the PC programs
	that lets you see the whole packet also.

	Needless to say, any help (even if it is just pointing
	to code which uses NIT and might be helpful) would be
	appreciated.  If there is any interest in the replies
	that I get, I will post a summary.

			Thanks,
				Avi Freedman
				freedman@euclid.math.temple.edu

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Dec 89 23:27:06 -0800
From:      sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz)
To:        mentor.cc.purdue.edu!mace.cc.purdue.edu!abe@purdue.edu, tcp-ip@nic.ddn.mil
Subject:   Re: getting processid from netstat
> In article <2829@infmx.UUCP>, barrym@infmx.UUCP (Barry Mednick) writes:
> > Given the output from netstat -A, can I relate one of the connections
> > to a processid?  In particular, can I use the foreign address or the
> > Process Control Block address to derive the process id that is using
> > that connection?
> 
> % netstat -aA | grep smtp
> 80f67d0c tcp        0      0  *.smtp             *.*                LISTEN
> % ofiles -n 80f67d0c
> 
> file 8010309c of socket 80f67d8c of INPCB 80f6790c of PCB 80f67d0c	
> USER        PID  TYPE    FD  CMD           
> root        148  sock     5  sendmail      
> 
> Ofiles is available in volume 18 of comp.sources.unix, number 57.
 
	or one could simply use the "fstat" command, available with 
	4.3BSD and 2.10.1BSD.

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Dec 89 19:53:00 PST
From:      cire|eric <cire@cisco.com>
To:        bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Networks considered harmful

I think the point that McCarthy was making about FAX was not so much
that Email could do it better or whether FAX could do it better but
the ubiquitous nature of the interconnect.  With FAX all you need
to communicate with someone is get their phone number.  Almost everyone
these days (at least in our part of the world) has one of those.  The
same thing can't be said for Email addresses.

Yes Computer based telecommunications has a great deal of more utility
than FAX but I don't think that is the point.  You must first make the
connection before all that starts making a difference.

The comments about PR were quite excellent and certainly play a part.

-c
cisco engineering

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Dec 89 17:38:40 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   TCPIP & Burroughs
Does anyone know of a ETHERNET/TCPIP solution for Borroughs computers??
Pointers to commercial or non-commercial sources would be appreciated.

Thanks in advance.

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 89 14:46:59 GMT
From:      pogran@CCQ.BBN.COM (Ken Pogran)
To:        comp.protocols.tcp-ip
Subject:   Re: Xerox Etherphone experiments?

A recent posting mentioned a paper presented by John Shoch in
1980 on carrying voice traffic over Ethernet.  I happen to have a
copy of the conference proceedings, so here's the complete
bibliographic reference:

     J. F. Shoch, "Carrying Voice Traffic thorugh an Ethernet
     Local Network: A General Overview," in: "Local Networks for
     Computer Communications; Proceedings of the IFIP Working
     Group 6.4 International Workshop on Local Networks," edited
     by Anthony West and Phillipe Janson; North-Holland
     Publishing Company, 1981.  ISBN: 0 444 86287 0

P.S.:  the experiments were done over the original 3 Mb/s
ETHERNET.

Ken Pogran

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 89 15:01:12 GMT
From:      abe@mace.cc.purdue.edu (Vic Abell)
To:        comp.protocols.tcp-ip
Subject:   Re: getting processid from netstat

In article <2829@infmx.UUCP>, barrym@infmx.UUCP (Barry Mednick) writes:
> Given the output from netstat -A, can I relate one of the connections
> to a processid?  In particular, can I use the foreign address or the
> Process Control Block address to derive the process id that is using
> that connection?

% netstat -aA | grep smtp
80f67d0c tcp        0      0  *.smtp             *.*                LISTEN
% ofiles -n 80f67d0c

file 8010309c of socket 80f67d8c of INPCB 80f6790c of PCB 80f67d0c	
USER        PID  TYPE    FD  CMD           
root        148  sock     5  sendmail      

Ofiles is available in volume 18 of comp.sources.unix, number 57.

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 89 15:04:00 GMT
From:      hlison@bbn.com (Herb Lison)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Xerox Etherphone experiments?

santi@ixos.UUCP (Michael Santifaller) writes:


>	There is this book with the proceedings of a LAN conference,
>	its title is "Local Area Networks" I believe, and the editor
>	is Tony West from Sun, who was with IBM in Geneva, then.
>	It has been published in the early '80. The book contains several
>	articles about LANs, obviously, including one by Shoch (??) about
>	an experiment with voice over Ethernet (3MB Ethernet at that time).
>	The whole article sounded very interesting and encouraging,
>	since I had never believed that Ethernet was suitable for
>	voice at all. 

As part of our commercial software development, we implemented a
voice capability in our BBN/Slate software package which makes use
of a voice server in an IBM PC, accessed over the ethernet via
the Sun PC-NFS TCP/IP toolkit.

The voice server uses about 32kbs, and so far, performance does not
seem to be a problem, even on a loaded network.

Herb Lison

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 89 15:30:50 GMT
From:      jthomp@wintermute.Sun.COM (Jim Thompson)
To:        comp.protocols.tcp-ip
Subject:   Re: Protocol Design issue

In article <12485@ulysses.homer.nj.att.com> smb@ulysses.homer.nj.att.com (Steven M. Bellovin) writes:
>Sending a count followed by the exact number of bytes can work; indeed,
>that's what Peter Honeyman and I did in uucp's 'e' protocol.  A few
>caveats...  First, do everyone a favor and send the count in ASCII.
>Using htonl() would work, but is only convenient if (a) the receiving
>machine has ntohl(), and (b) both sides use 32-bit longs.  Me -- unless
>there's a major performance issue, I'd prefer ASCII.

Indeed, even 'rmt' uses the same technique.
(ascii encoding and all.)

Jim Thompson - Network Engineering - Sun Microsystems -	jthomp@central.sun.com
Member of the Fatalistic International Society for Hedonistic Youth (FISHY)
"Unemployment is the solution, not the problem."  -- B.I.R.D.

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 89 16:02:01 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

<John Nagle>
>      Well, in the real world, I understand that electronic mail is
>on the decline, and is being replaced by fax.

<Barry Margolin>
>That was precisely the point McCarthy was making in his article.  He said
>that fax has become popular because it works with the current home
>communications network (the phone system).  For email to become popular it
>will have to fit in similarly, rather than requiring users to have an
>account on a computer connected to an email network.

<Roy Smith>
>	A year or so ago, some people here had need to establish regular
>communications with somebody at Monash University in Australia.  We proved
>that email worked in both directions but then the guy at the other end
>insisted we switch to fax.  Seems that he gets charged for both incomming
>and outgoing email and fax was cheaper!

I have seen comments like this before.  And I have attempted to answer
them before.  It is a shame to see supposed experts on communications
who are apparently as ignorent of what is really available as the general
public.  I personnaly intend to write a letter (or maybe just send a
copy of this message) to the ACM and see what kind of hornets nest it
stirs up.

The only reason that FAX is more popular than Email is "PR".  You cannot
watch TV without seeing/hearing about FAX.  It is in the programs as well
as the commercials.  You can't drive down town without hearing it on the
radio, seeing it on billboards, and seeing banners in the stores all
pushing FAX.  They sell them in the MALL and in Radio Shack.  Before
long there will be a guy on the street corner holding his coat open
and whispering "Hey Mac, you want to buy a FAX real cheap!!"

If you have any doubt of this, try a little experiment.  Ask a couple
of your neighbors if they know what FAX is and then ask if they know
what Email is.  The try it on the local kids.  My 10 year old daughter
knows what FAX is and yet claims to not know what Email is even though
she has used it herself (on my home UNIX box) and she sees me using it
every day.  It's all a matter of PR.

But the truth is, FAX offers nothing that can't be done with the PC sitting
on your desk. And the PC can even do it better.  You can send Email from
PC to PC or PC to "Real computer" or "Real computer" to PC.  The softtware
and hardware already exist.  In fact they have been around for years.
The hardware we all have and the software doesn't even cost anything!!!
You can send text, you can send pictures, you can even send color pictures.
And you can do it the same way you do with a FAX.  You can call the addressee
on the phone and send it to him directly.  As a matter of fact it has probably
reached the point where you can buy all the hardware necessary to do this for
about the same price as one of those full featured FAX machines.
Interestingly enough, the Email scenario has numerous advantages over the
FAX scenario.  I can move more data quicker.  I can manipulate the data
easier when it arrives.  And if the number is busy, I don't have to stand
around and wait.  The PC can do it for me.

So, someone please tell me "What is so great about FAX?" and why can't
those of us who use Email all the time convince the rest of the world
how much better it really is??

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 89 16:02:21 GMT
From:      blais@ut-emx.UUCP (Donald Blais)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Xerox Etherphone experiments?

In article <382@ixos.UUCP> santi@ixos.UUCP (Michael Santifaller) writes:
>	There is this book with the proceedings of a LAN conference,
>	its title is "Local Area Networks" I believe, and the editor
>	is Tony West from Sun, who was with IBM in Geneva, then.
>	It has been published in the early '80. The book contains several
>	articles about LANs, obviously, including one by Shoch (??) about
>	an experiment with voice over Ethernet (3MB Ethernet at that time).

From UTCAT (UTexas online card catalog)...

Local networks for computer communications: proceedings of the IFIP
Working Group 6.4 International Workshop on Local Networks, organized
by IBM, Zurich, Switzerland, August 27-29, 1980 /edited by Anthony
West and Philippe Janson.  Amsterdam; New York: North-Holland, 1981.
-- 
Donald E. Blais           INTERNET: blais@emx.utexas.edu
Computation Center        BITNET:   BLAIS@UTAIVC
University of Texas       UUCP:     ... !cs.utexas.edu!ut-emx!blais
Austin TX 78712           PHONE:    (512) 471-3241

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 89 17:15:27 GMT
From:      roy@phri.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip,orst.internetworking
Subject:   Re:  source-route, record route ping (Re:  traceroute)

pvo3366@sapphire.OCE.ORST.EDU (Paul O'Neill) writes:
> I know folks who are stuck at 4.2 (SunOS 3.5) because their vendors haven't
> updated critical applications to run under SunOS 4.0 yet.

	Not to mention those of us stuck at SunOS-3.5 because Sun has not
yet convinced me that running 4.0 on my 3/50s is a viable option.
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,philabs,cmcl2,rutgers,hombre}!phri!roy
"My karma ran over my dogma"

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 89 18:36:56 GMT
From:      jones@larry.sal.wisc.edu (Tom Jones)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.appletalk
Subject:   simple Ethernet interface

The folks at our lab. have been users of Ethernet for
years, but now we are considering building an interface to
connect some laboratory electronics to our (DEC Ultrix)
computers using Ethernet.  The UDP protocol would probably
meet our needs.  We're no strangers to microprocessor-
based designs, but we are novices in the Ethernet area.

We would like to use a Motorola MC6809 processor because we
have the best development tools for it.  Can someone suggest
some compatible Ethernet chips to use with it?  Also, does
someone tell me what chips are used in the Kinetics Fastpath
box?
-- 
Thomas E. Jones		   | internet:	jones@sal.wisc.edu
Space Astronomy Laboratory | SPAN:	UWSAL::JONES
1150 University Avenue	   |
Madison, WI 53706	   | Ma Bell:	(608)263-4683

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 89 18:56:50 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   re: partial transfer recovery in RFC and OSI protocols

George Michaelson:

Please read the specification of FTP, RFC-959.  See section 3.5 on error
recovery and restart, and read about the REST (restart) command.

--jon.

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 89 19:42:08 GMT
From:      barns@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re:  partial transfer recovery in RFC and OSI protocols

You raise several distinct issues of which I can only respond to some.

Restart capability is defined for the FTP protocol (RFC 959) as an
optional feature and has been so since at least RFC 542, 12 August
1973, which is as far back as my collection goes.  This design works
between divergent system types.  The written specs had some unclear
areas which I hope have been fixed by text in RFC 1123, section
4.1.3.4.  Implementations are few and far between, but it was hoped
that the clarified, corrected and expanded writeup in RFC 1123 would
encourage people to take this on.  It is not very hard to do.

There is a different FTP restart scheme by Rick Adams which I have
heard will be in 4.4(?).  It is not compatible with the one defined in
the RFCs, though in principle they can coexist in a single
implementation.  It fits better with a typical UNIX I/O architecture
and thus perhaps gives better throughput and almost certainly is more
CPU-efficient on a number of real world platforms, but it does not try
to handle the more difficult cases of operation between divergent
systems.

The throughput issue regarding the two methods is architecture-dependent
and involves both software and hardware design issues.  It seems that
making the RFC version work using the normal interface routines one
finds on a UNIX box probably means either sending more packets or doing
more data copying.  In some cases it might be possible to just add
library routines to eliminate this, if the hardware has a suitable
design (i.e., scatter/gather DMA).  Also, in some systems, some of the
feared data copying may be happening already anyway.  On some machine
architectures including IBM Big Iron (but there are others too), a
relatively small amount of code together with some smart choices of
block sizes might allow you to do the RFC-style approach with
infinitesimal impact on CPU utilization or network throughput.  The
upshot of all this seems to be that neither version of Restart
maximizes interoperability, portability, and (CPU) efficiency
simultaneously.  I think OSI is trapped in the same solution space.

In either version, the Restart mechanism is basically provided for
recovery from cataclysmic disruptions (disk full, network died, host
died, impatient user blasted the client program into oblivion) and NOT
to deal with bit corruption (noisy links).  Both TCP/IP and OSI hold
that lower layers should do most of the work of protecting against the
latter problem.  I don't find this unreasonable, even on slow serial
point-to-point links.  Data link protocols should be chosen to fit the
error characteristics of the links, and TCP and TP4 can cope with some
residual glitches.  This leaves only the problem of recovery from
higher-layer aspects of service interruptions as the proper domain of
"session" recovery schemes.

Regarding the life and death of TCP/IP family protocols and their
enhancement, I agree that they aren't dead yet and can't be ignored.
However I suggest that there is only one pool of expertise available
for working on generic application domain problems in either TCP/IP or
OSI.  Seems to me that most of the experts with strong feelings are
spending most of their time in the OSI arena.  There are evidently not
enough people to go around, and those that exist evidently see OSI as a
better investment of their time right now (I presume on the theory of
broader impact).

Bill Barns

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 89 20:40:40 GMT
From:      mjb@acd4.UUCP ( Mike Bryan          )
To:        comp.unix.ultrix,comp.protocols.tcp-ip,comp.sys.dec,comp.sys.mips
Subject:   SLIP for Ultrix 3.1


I remember an earlier discussion regarding DEC's "unsupported" version
of SLIP, wherein it only supports a single line.  We're having this
problem now (Ultrix 3.1), and of course I wasn't paying close enough
attention while the discussion was going on.  Changing the config file
to increase the number of units does not seem to help; apparently DEC
has one or more modules hardcoded to allow just a single line.

We need a working SLIP soon.  If you know how to make DEC's SLIP work
with more than one line, please let me know.  If you know of any other
version of SLIP which works under Ultrix 3.1 (VAX and/or MIPS CPUs),
that would be great too.  We don't care which way we get it, we just
need it working.

Thanks in advance for any help.
-- 
Mike Bryan, Applied Computing Devices, 100 N Campus Dr, Terre Haute IN 47802
Phone: 812/232-6051  FAX: 812/231-5280  Home: 812/232-0815
UUCP: uunet!acd4!mjb  INTERNET: mjb@acd4 OR mjb%acd4@uunet.uu.net
"Agony is born of desire; that's what you get for wanting." --- Moev
-- 
Mike Bryan, Applied Computing Devices, 100 N Campus Dr, Terre Haute IN 47802
Phone: 812/232-6051  FAX: 812/231-5280  Home: 812/232-0815
UUCP: uunet!acd4!mjb  INTERNET: mjb@acd4 OR mjb%acd4@uunet.uu.net
"Agony is born of desire; that's what you get for wanting." --- Moev

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Dec 89 21:54:50 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re:  source-route, record route ping (Re:  traceroute)

In article <14450@orstcs.CS.ORST.EDU> pvo3366@sapphire.OCE.ORST.EDU (Paul O'Neill) writes:
>I know folks who are stuck at 4.2 (SunOS 3.5) because their vendors haven't
>updated critical applications to run under SunOS 4.0 yet...

Other folks are stuck at SunOS 3.5 because they view SunOS 4.0.n as a
"customer beta" release and aren't satisfied with its reliability and
performance.  We'd really like to upgrade to 4.3-compatible networking,
but having to accept the rest of SunOS 4.0 with it is too high a price.
-- 
1755 EST, Dec 14, 1972:  human |     Henry Spencer at U of Toronto Zoology
exploration of space terminates| uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Dec 89 21:59:44 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks Considered Harmful...

In article <25086@cup.portal.com> Nagle@cup.portal.com (John - Nagle) writes:
>      Well, in the real world, I understand that electronic mail is
>on the decline, and is being replaced by fax.

As the man said, "it depends on which real world we are talking about". :-)

Don't forget that one reason why fax has caught on in places where electronic
mail hasn't is its appeal to technophobic managers:  it's a way of sending
mail electronically without having to use a keyboard (after all, keyboards
are for secretaries and other underlings, not for managers).
-- 
1755 EST, Dec 14, 1972:  human |     Henry Spencer at U of Toronto Zoology
exploration of space terminates| uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 89 22:38:40 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   TCPIP & Burroughs

Does anyone know of a ETHERNET/TCPIP solution for Borroughs computers??
Pointers to commercial or non-commercial sources would be appreciated.

Thanks in advance.

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Dec 89 07:37:26 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        "\"Alain FONTAINE \", Postmaster - NAD" <af%sei.ucl.ac.be@cunyvm.cuny.edu>
Cc:        tcp-ip@nic.ddn.mil
Subject:   re: MB, MB, MR....

> Hi. May I ask if anybody is currently playing with the experimental
> mailbox RR's ? Is there any software using them ? Do most implementations
> of the DNServers already handle them ? Seems exactly what I need to
> handle our 'logical addresses'. Thanks for any info.       /AF

There may be some software that experiments with them, but their use
is not well-enough defined to put into operational use.  There are
questions, in particular, about MG expansion and making sure that mailing
lists are properly expanded without gaps and with a minimum of duplicates.

Craig
-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Dec 89 08:30:15 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Networks considered harmful
I don't think you read my whole posting.  I can send Email from PC to PC
using the exact same Phone system that FAXers use.  The software is easier
to set up than WordPerfect and the software is even FREE!!!

I still say it is all PR.
As for ease of use, even though it's already installed, our FAX takes
2 pages of instructions to send anything and it isn't in my office.
But I do have a PC and a MODEM on my desk.

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 03:53:00 GMT
From:      cire@CISCO.COM (cire|eric)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful


I think the point that McCarthy was making about FAX was not so much
that Email could do it better or whether FAX could do it better but
the ubiquitous nature of the interconnect.  With FAX all you need
to communicate with someone is get their phone number.  Almost everyone
these days (at least in our part of the world) has one of those.  The
same thing can't be said for Email addresses.

Yes Computer based telecommunications has a great deal of more utility
than FAX but I don't think that is the point.  You must first make the
connection before all that starts making a difference.

The comments about PR were quite excellent and certainly play a part.

-c
cisco engineering

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 04:19:13 GMT
From:      mrose@CHEETAH.NYSER.NET (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

> So, someone please tell me "What is so great about FAX?" and why can't
> those of us who use Email all the time convince the rest of the world
> how much better it really is??

What is great about FAX is really simple:

Reason 1:	FAX is turn-key in every aspect: any office person can
		install and use a fax machine without any serious training.

    For example, FAX addressing consists of using--get this--the telephone
    numbering system.  What an idea!  Why not use an addressing scheme that
    everyone is trained to use by their parents by age 5?

    In contrast, what does e-mail offer?  Well, it's this glop invented
    by computer people who probably never had a normal childhood!  The
    good old days of 

	user@host

    are now

	local@domain

    and if you're *real* lucky there aren't any '%' or '!'-signs involved.
    But, wait there's more, now computer people who probably never had a
    normal childbirth (or perhaps conception) are into the act and we have

	MHS-attribute-list

    and the format is in ABSTRACT SYNTAX or BINARY no less!

    Actually, the addressing thing leads us to the next reason, which, as
    Einar Stefferud points out, is the biggie.

Reason 2:	FAX uses an already existing, global infrastructure.

    The FAX infrastructure is--get this--the telephone system.  Everyone
    who needs to communicate has a connection to the telephone system.
    FAX machines hook up to this truly ubiquitous infrastructure.

    In constrast, there are gobs of networks supporting e-mail, some
    interconnected and some not.  If you live in the heart of the
    Internet, you probably thing that the Internet is ubiquitous.
    Although I have a personal 56K line going straight to my house and
    upstairs to my IP router, I must regretfully inform you that this is
    the exception and not the rule.

Summary:	FAX is a wonderful example of an 80-year old technology that
		is technically indefensible but has the world's best
		user interface: no training needed.

Having said all that, how can e-mail start competing?  Well, marketing
is a small part, but it's a second-order thing.  We need: a global,
e-mail infrastructure that is as ubiquitous as dial tone.  To do this,
we need to patch together all of the existing e-mail systems, make the
gatewaying transparent, adopt a global addressing scheme, and then start
making the technology accessible and usable by ordinary people who had
normal childhoods.

/mtr

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Dec 89 16:40:16 EST
From:      Doug Nelson <08071TCP%MSU.BITNET@CORNELLC.cit.cornell.edu>
To:        "Alain FONTAINE (Postmaster - NAD)", <af%sei.ucl.ac.be@CUNYVM.CUNY.EDU>, TCP-IP ARPA Discussions <TCP-IP@SRI-NIC.ARPA>
Subject:   Re: MB, MG, MR....
>Hi. May I ask if anybody is currently playing with the experimental
>mailbox RR's ? Is there any software using them ? Do most implementations
>of the DNServers already handle them ? Seems exactly what I need to
>handle our 'logical addresses'. Thanks for any info.       /AF

It is my understanding that MB, MG, and MR are obsolete, and that MX
was designed specifically to be a replacement and generalization of the
other three.

Doug Nelson
Michigan State University
-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 12:53:22 GMT
From:      snoopy@ixos.UUCP (Snoopy Schmitz)
To:        comp.unix.wizards,comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   SUMMARY: IBM <-> UNIX Connections (400 lines)


Dear Netters,

some time ago I sent out a query regarding the link of UNIX machines
and systems to the "IBM world" in these newsgroups - you are reading 
the promised summary.

I was actually interested in software and 
hardware to deal with the channel and not only SNA, but I did not make it
clear and hence got a whole bunch of SNA info as well. 

Thanks you all of you who replied, I hope you don't mind my thanks in list form
because I hate sending out electronic form letters. I want to add, that in
case some companies get mentioned here, this is not an endorsement either by me
or the originator of the article or the company they work for.

I got about 40 replies; some were duplicates and some people posted several
mails: these were the authors...

"Don Ingli" <guug!tumuc!unido!UMCVMB.MISSOURI.EDU!AGRISCS>
<pegasus!hansen>
<tony.austin.ibm.com!dgogates>
Bill Crandall <guug!tumuc!unido!hpda!hpinddf!bc>
Doug Nelson <guug!tumuc!unido!msu.bitnet!08071TCP>
Jeffery Bacon <guug!tumuc!unido!mtus5.bitnet!BACON>
Karl Kleinpaste <guug!tumuc!unido!cis.ohio-state.edu!karl>
Matt Burdick <guug!tumuc!unido!hpda!hpindl1!burdick>
Nick Gimbrone <guug!tumuc!unido!CORNELLA.cit.cornell.edu!NJG>
Paul Hahn <guug!tumuc!unido!sequent!paulh>
Peter H\Tkansson <guug!tumuc!unido!vd.volvo.se!peter>
Scott Schwartz <guug!tumuc!unido!shire.cs.psu.edu!schwartz>
bill gunshannon <guug!tumuc!unido!scrvmsys.bitnet!702WFG>
Kodak.COM!messingr (Rich Messinger)
eutrc4.urc.tue.nl!rcjoep (Joep Brand)
gargoyle.uchicago.edu!spanner!mje (Mark J Elkins)
hal.CSS.GOV!baugh (TetherCat 15-0)
ism.isc.com!johnan (John Antypas)
lsuc.on.ca!jim (Jim Mercer)
mips.com!bac (Bruce Clarke - Mgr. Systems Engineering)
nixhhs!andreas (Andreas Wettengel)
convex!harper (David Harper)
mdivax1!sub12c!sandberg (Mischa Sandberg)
sun!hochberg (Yigal Hochberg)
swuts!texbell!umsgmab ([5-7863] Mike Brown)
unify!grp (Greg Pasquariello)
xroads!jerry (Jerry M. Denman)
rosevax.rosemount.com!ghoul (Jon Westbrock)
uts.amdahl.com!kp (Ken Presting)
uunet.uu.net!jeffr (Jeff Radick)
uxh.cso.uiuc.edu!costigan (Steve Costigan)
xlnvax.excelan.com!manoj (manoj @ NOVELL )
larry hughes <guug!tumuc!unido!silver.ucs.indiana.edu!hughes>

I am very grateful for all your help. It is very difficult to get good info
here in W. Germany 

Here is the summary:

There seem to be many products out there...I will try to group them according
to manufacturers. Firstly the big ones and later some smaller ones. I don' t
know if I rate them correctly - I consider ones I have heard of big and the 
rest somewhat smaller...seems fair.

An apt summary is:

"Many vendors provide Unix<-->SNA interfaces of some sort.  Most are
either SNA3270 or SNA/RJE (3770) type interfaces.  But almost all allow
you some sort of access to a programmatic level so that you can write
applications that talk directly to MVS or VM over SNA.  Mips has such
a product as does Sun, HP/Apollo, DEC, etc."

Here it is company by company:

SUN
===
	"We had first purchased Sun's Channel Link board
	and software.  This provided up to 64 sessions with the connections
	defined to VTAM as 3278-2/4 terminals.  The board simulates two
	3174 controllers.  It is channel attached and in general we have 
	had no problems with it.  It is in our main Sun Server and people
	had to telnet into our Sun first before using the connection.  A
	file transfer facility was also included."

"We (Sun) have a TCP/IP solution for VM and MVS. It enables you to talk a full
TCP/IP from your IBM to any other TCP/IP machine including UNIX. We
also have an IP router witch connects Ethernet to FDDI so you can talk
from your VM to a machine that is connected directly to the FDDI. Very
soon a direct connection VM -> FDDI will be available."

     "We also run Sun's SNA product here. It consists of a card that plugs
into one of our Suns, with a direct connect that looks like a channel adapter
to the IBM. Ours has 64 HW addresses reserved for it on the IBM, configured as
3274 terminals. The Sun acts as a server, so any of our other Suns can
access the card. It advertises full SNA/3270 services; we only use the
logon and 3270 IND$FILE file transfer stuff."

IBM
===

"My first response is to ask if you have looked at IBM's TCP/IP for VM
(or MVS, if appropriate).  If not, you should; [...]"

    "IBM can run tcpip software if the box has a controller. Basically
its an industrial grade AT as the gateway. 8512 or something like that."

"You can get TCP/IP (telnet, ftp, nfs server, X) from IBM; mention the
magic number 8232.  There are also non IBM vendors (BTI, Mitek, Intel, etc.)
for VM & MVS.  The TCP/IP box is usually channel attached.  Throughput
varies..."

"There is something called an 8232 that will allow to to link a channel
and a LAN together.  I have seen it used to connect an Ethernet to a
bunch of IBM machines (sorry I am not of that world, and I do not know
what kind of machines they were).  They also sell some software that
will run TCP/IP on the VM box and thus you have the software for
that end.  It can only be connected to one LAN however, but it is
better than nothing I guess."

"... TCP code for Big Blue Iron, at least for VM/CMS (It's FAL-5798, I do
believe - we run it on our 4381). That would also allow ftp, of course.
     There's also NFS code to run under CMS, but we can't get it to work right.
If you really want that, I'd have to suggest an AIX guest."

"Why not ask your friendly IBM sales team for a copy of 5798-FAL and
an 8232 or 3174 (new box) or buy a BTI box from BTI. This software
(and one of any of a number of pieces of hardware, includeing any
of the above list) will put your VM host onto TCP/IP (we do it,
we love it). You may find it possible to then hook into the SNA net
(depending upon what exactly you need do)."

"I think that IBM has TCP/IP availble over a dial-up rs232. (SLIP).  This is
on the RT running AIX V2.2.1.  The mainframe of course would have to support
TCP/IP.

There are several other options that are availble on the RT.  There is a 
product they call EM78 which gives you LU2 display and file xfer.  There is
WHIP which gives you more capabilities.  These 2 options assume that you have
a 3x74 to connect to somewhere close.

There is also full blown SNA on the RT.  It gives you LU2, LU3, LU1 and a 
very rich LU6.2."

HARRIS
======

"If you need more features and greater performance there is a company called
Harris Data Communications in Dallas TX.  Their # is 214-386-2000.  They have
a product call the 9600 which runs SVR3.s and offers 3270 access from terminals
connected to the 9600 and to to those on a TCP/IP net.  They also have high
speed RJE for batch processing.  They 9600 also has a COAX-A option where you
can connect 3279 type terminals. 

The Harris solution is quite pricy, but they offers a complete support
and service package.

Harris also has a product called the 9700.  It basically connects a TCP/IP
network in an IBM mainfram.  It uses SDLC or for high speed can ba channel 
attached.  A nice feature of the 9700 is that with some software on the host
side, people logged into VM from the host terminals gain access to UNIX 
sessions."

AMDAHL & NIXDORF
================

"Amdahl has a version of Unix System V called UTS, which runs on 370-
architecture mainframes and supports SNA channel data links.  You could
run UTS in a VM guest machine and have the best of both worlds.  Nixdorf
and Amdahl have a joint arrangement to market and develop this software."

AT&T
====

	"If you have Sys V ATT 3.2 they have a whole suite of Sna packages
available. They are pretty new but I am using them connecting 1600 386/unix
across the country to a central host. It has been a real experience. The gang
in charge of the SNA stuff went through lots of hell both on the UNIX end
and HOST end. Give ATT a call."

"You might try talking to AT&T.  They have two products, LU6.2 for UNIX to
mainframe communications, and an SNA emulator (I can't recall the name of
the product), that will allow you a terminal session as well as a way of
grabbing incoming, and synthesizing outgoing data."

"Believe it or not, but AT&T has several products on the market for tying
IBM's to UNIX systems, running on both 386 and 3B products."

SCO
===

"The company I work for, SCO ("The Santa Cruz Operation, Inc.")
has a product for SCO XENIX and SCO UNIX System V/386 called
"uniPATH SNA-3270" that provides a 3270 terminal emulation.  Well,
actually, it emulates a 3274 terminal cluster controller hooked up
to the 37x5 by an SDLC line, plus provides emulation of the 3278
terminals as well.  It also supports file transfer using the host
program called "IND$FILE".

Note that this differs from the "tn3270" program available on BSD
any many other TCP/IP implementations in that it does not communicate
with the host program using TCP/IP, but rather with SNA/SDLC.

For more information about our product, please consult one of our
marketing types (which does not include me, I'm an engineer).
A reasonable place to start is to talk to a guy named John Harker
(uunet!sco!johnha).  Our phone # is (408)425-7222."

MITEK
=====

"Mitek Systems makes a product which will act as a gateway between Unix systems
and IBM mainframes running SNA.  On the Unix side, the connection is through
an ethernet link running TCP/IP protocols.  On the IBM side the connection is
made in one of two ways.  The local version of the product (M2000) directly
connects to the I/O channel and handles block mode (high speed) transfers.  I
don't know if they support data streaming yet on the M2000, but if not, they
are working on it.  The other version of the product (M2100) is designed for
remote attachment to the mainframe and communicates over a high speed SDLC
link; I think rates up to 56K baud are supported on this one.  Only difference
between the two units from a user's viewpoint (on the Unix box) is that the
M2100 has slower response due to the serial link to the mainframe.  The two
systems support things like file transfer, RJE, etc.  All translation from 
SNA to TCP/IP is done within the Mitek unit.  For further information contact:
                  
                           Mitek Systems Corp
                           2033 Chennault Dr.
		           Carrollton, TX 75006
                           (214) 490-4090

[...]
For what it's worth, my current company manufactures supercomputers which run
Unix and have an ethernet connection.  They picked Mitek as the vendor of choice
when they needed connectivity to the IBM world."

"Try Mitek us phone (214)490 4090 talk to david gentry.
They have a channel attached unit AND tcp/ip to VM + representative in
suisse.
We use their units on sdlc line but i assume it works ok on channels..."

SSI
===

"SSI (Software Strategies Inc.) offers packages for LU2 and LU6.2.
The LU2 is mostly for 3270 terminal emulation, but has an API
and "raw" mode, so that you can connect a transaction program to
what CICS thinks is a terminal. Sigh. The LU6.2 stuff is okay,
except that conversation start-up cost is a Unix fork-exec."

"Actually, what works for ISC is a product from System Stratigies Inc.
They make an intelligent board which does SNA, X.25 or Bysync and
runs under our 386/ix Unix V.3.2/V.4 OS.  It impliments full packet
transparancy for X.25 and application gateways for SNA as well as LU and
3270 support."

JOINER
======

"[...] But one possible solution might be JNET from Joiner
Associates.  I know it works on VMS on a VAX and lets it talk to our
4381 running VM/CMS.  It is apparently the basis for BITNET and I am
pretty sure there are UNIX systems on BITNET too.  You might try getting
in touch with them and asking more specific questions.

Joiner Associates Inc.                       Phone: (608) 238-8637
3800 Regent Street                           TELEX: 650 110-6813
PO Box 5445                                  FAX:   (608) 238-2908
Madison, Wisconsin
53705-0445 USA"

FIBRONICS
=========

	"We have recently put TCP/IP directly on our IBM system using
	hardware/software from Fibronics.  It also connects right to the 
	channel and also to the ethernet.  Software runs on the VM host and
	any ascii<->ebcdic translation is done on the VM host.  It gives us
	a wide variety of telnet connection options and supports standard
	ftp connections.  telnet and ftp are bidirectional and works here."

INTERLINK
=========

	"Another vendor I just remembered is Interlink Computer Sciences.
	They use a microVAX as the hardware platform but use the IBM code.  The
	advantage with them is that they also have DECnet capabilities with
	the same hardware at the same time."
   
RABBIT
======

"One strictly communications vendor providing SNA connectivity is Rabbit
Software.  They run on several platforms and have a pretty good reputation.
They can be contacted at 1-800-RABBITC."

MORNING STAR
============

"There is a company here in the USA (right here in my town) called
Morning Star Technologies which sells a variety of X.25, BSC, and SNA
products.  You might wish to get in touch with them.  Try directing a
query to kim@MorningStar.COM or karl@MorningStar.COM."

PUBLIC DOMAIN/BERKELEY or NET STUFF
===================================

"1) Put TCP/IP on your IBM host and use tn3270 (public domain 3270 emulator)
and NFS."

     "Well....depends on what you want. If you just want terminal service,
and you have a local TCP/IP-based net, you could use Berkeley's tn3270
code on the Unix boxes. We use it here, and it works fine."

Once again, thank you all of you for your help. I wish you all a merry
Christmas and a happy new year.

Love,
Snoopy

-- 
uunet!unido!ixos!snoopy -or- snoopy@ixos.uucp
"Every passing hour brings the solar system 43,000 miles closer to globular
cluster M13 in Hercules - and still there are some misfits who insist that
there is no such thing as progress." - Kurt Vonnegut Jr.

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 13:30:15 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

I don't think you read my whole posting.  I can send Email from PC to PC
using the exact same Phone system that FAXers use.  The software is easier
to set up than WordPerfect and the software is even FREE!!!

I still say it is all PR.
As for ease of use, even though it's already installed, our FAX takes
2 pages of instructions to send anything and it isn't in my office.
But I do have a PC and a MODEM on my desk.

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 14:12:37 GMT
From:      roy@phri.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

I wrote:
> the guy at the other end insisted we switch to fax.  Seems that he gets
> charged for both incomming and outgoing email and fax was cheaper!

702WFG@SCRVMSYS.BITNET (bill gunshannon) responded:
> It is a shame to see supposed experts on communications who are apparently
> as ignorent of what is really available as the general public.

	I'm not sure I understand.  Are you are claiming I'm one of those
"supposed experts"?  I didn't say I thought FAX was better, just that the
guy we were communicating with insisted (for good reasons or bad) that it
was the preferred way to communicate.  Since our goal was to send messages
back and forth, not to prove a point, we switched to FAX.

>So, someone please tell me "What is so great about FAX?" and why can't
>those of us who use Email all the time convince the rest of the world
>how much better it really is??

	What's so great about FAX is that it works and it's ubiquitous.
Remember the hoo-ha in Beijing a few months back?  It seemed that FAX was
the primary means of communication in and out of China.  Every fax machine
in the world can talk to every other fax machine because they all talk the
same language.  With email, you have your choice of uucp, smtp, pop[123],
csnet dialup (whatever they call it), bitnet, etc, etc, etc.  FAX works,
email sort of works, and only that if you have somebody willing to care for
it with kid gloves.

--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,philabs,cmcl2,rutgers,hombre}!phri!roy
"My karma ran over my dogma"

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 14:40:11 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

In article <8912190403.AA05387@ucbvax.Berkeley.EDU> 702WFG@SCRVMSYS.BITNET (bill gunshannon) writes:

   But the truth is, FAX offers nothing that can't be done with the PC sitting
   on your desk. ...
Agreed.

   So, someone please tell me "What is so great about FAX?" ...

If I want to send someone a FAX message, I can take it down the my local
supermarket, hand them my $3.50 and the piece of paper, and whooooosh,
a similar piece of paper pops out of my recipient's machine.

Or if I have enough FAX messages to send, I can buy my own FAX machine.
I put the piece of paper in it, dial the phone number, and press the little
green button.

*In principle*, E-mail is just as easy.  *In principle*, you can set up a
machine with a modem and just tell people to call it.

In practice, there is no standardization in E-mail packages.  You can get
one for free (Opus BBS), but it takes a good bit of tinkering to get it
working.

The way to market E-mail is to glom it onto a FAX machine.  Make a
little box that you plug in between your FAX machine and the phone
line.  Give it enough smarts so that it can distinguish between its
carrier and the FAX machines, and automatically forward the call to
the FAX machine.  Put some RAM in it so it can hold incoming messages.
Put a RS-232 (ugh) line on it so a computer can read its output.
Write some software for the PC and Mac that downloads the messages
from the little box.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
Live up to the light thou hast, and more will be granted thee.
A recession now appears more than 2 years away -- John D. Mathon, 4 Oct 1989.
I think killing is value-neutral in and of itself. -- Gary Strand, 8 Nov 1989.
Liberals run this country, by and large. -- Clayton Cramer, 20 Nov 1989.
Shut up and mind your Canadian business, you meddlesome foreigner. -- TK, 23 N.

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 15:14:29 GMT
From:      sparta@SAIC.COM (Sparta guest account)
To:        comp.protocols.tcp-ip
Subject:   Re:  sparta.com

Columbus,

The Internet has been prone to forming repeated routing loops for the
last few days.  Below is an interesting traceroute run from
narnia.saic.com (192.5.8.2) to cj3.centcom.com (131.240.95.31), at
10:00 EST on 19 Dec:

 1  MCLEAN-MB.DDN.MIL (10.3.0.111)  180 ms  120 ms  120 ms
 2  MCLEAN-MB.DDN.MIL (10.3.0.111)  180 ms  100 ms  120 ms
 3  MOFFETT-FLD-MB.DDN.MIL (26.20.0.16)  1180 ms  2220 ms  1540 ms
 4  CAMBRIDGE-MB.DDN.MIL (10.3.0.5)  1340 ms  1360 ms *
 5  MCLEAN-MB.DDN.MIL (10.3.0.111)  2400 ms  1380 ms  1820 ms
 6  * MOFFETT-FLD-MB.DDN.MIL (26.20.0.16)  2060 ms  2860 ms
 7  CAMBRIDGE-MB.DDN.MIL (10.3.0.5)  2100 ms  3360 ms  3720 ms
 8  MCLEAN-MB.DDN.MIL (10.3.0.111)  4240 ms  3520 ms *
 9  131.240.95.31 (131.240.95.31)  2160 ms !  1560 ms !  2280 ms !

There seems to be quite a bit of route thrashing; we have frequently
seen evidence that the routes are changing during a traceroute run
(witness the miraculous discovery of cfm.centcom.com, above!).

This is not an isolated occurrence.  We've been seeing quite a few
loops, especiaslly in traffic to the West coast.  I guess that
includes the West coast of South Florida :-).

- Bob

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Dec 89 23:31:36 PST
From:      cire|eric <cire@cisco.com>
To:        nvuxr.cc.bellcore.com!ak2@faline.bellcore.com (Arthur Knapp)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Networks considered harmful

It'll be especially interesting when MAN systems being discussed by
Bell Core and AT&T start coming on line.  This will effectively tie
LANs into the Central Offices.  Interesting possibilities.

-c
-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 15:44:16 GMT
From:      husain@stsusa.com
To:        comp.protocols.tcp-ip
Subject:   IP PDU header cksum algorithm question




	Does anyone have the C source code (or algorithm in ENGLISH!)
	for calculating the checksum for the IP PDU header??

	The ISO 8473 annex gives a really wierd description of the 
	cksum algorithm using MODULO 255 arithmetic. HELP! What is 
	that ?????

	Thanks in advance

	kbh
	===)------------------ 		"Dr. StrangeCode"
  	------------------(*************)--------------------------
	UUNET:			 husain@killer.stsusa.com
	Brain Loaned to:	Siemens Transmission Systems
				8620 N 22nd Ave, Phx, Az 85029
	Voice phone:		(602) 395 5222
  	------------------(*************)--------------------------

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 15:51:01 GMT
From:      perry@Morgan.COM (Perry Metzger)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

In article <8912190403.AA05387@ucbvax.Berkeley.EDU> 702WFG@SCRVMSYS.BITNET (bill gunshannon) writes:
><John Nagle>
>>      Well, in the real world, I understand that electronic mail is
>>on the decline, and is being replaced by fax.
>
><Barry Margolin>
>>That was precisely the point McCarthy was making in his article.  He said
>>that fax has become popular because it works with the current home
>>communications network (the phone system).  For email to become popular it
>>will have to fit in similarly, rather than requiring users to have an
>>account on a computer connected to an email network.
>
>I have seen comments like this before.  And I have attempted to answer
>them before.  It is a shame to see supposed experts on communications
>who are apparently as ignorent of what is really available as the general
>public.  I personnaly intend to write a letter (or maybe just send a
>copy of this message) to the ACM and see what kind of hornets nest it
>stirs up.

Right now, you can't go out to the store and buy an e-mail terminal,
but you can buy a fax machine. Sure, you can buy a PC, set it up, use
the right software, get a link to the proper service and stuff, but
that is costly and, more significantly, requires thought.

A person I know at Bellcore (Dan Nachbar) designed and built an
electronic mail "appliance" on the premise that people will use e-mail
if it is properly packaged. POMS (plain ol' mail system) has been
successfully tested with large groups of naive users (retirement home
residents in florida and Bellcore managers) and seems to have been
highly successfull. Being able to go out to the store and buy an
e-mail terminal will be what makes e-mail popular.

.pm

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 15:55:21 GMT
From:      koreth@panarthea.ebay.sun.com (Steven Grimm)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

In article <8912190403.AA05387@ucbvax.Berkeley.EDU> 702WFG@SCRVMSYS.BITNET (bill gunshannon) writes:
>So, someone please tell me "What is so great about FAX?" and why can't
>those of us who use Email all the time convince the rest of the world
>how much better it really is??

Because it's alien to most people.  A fax machine acts like a copier,
something everyone is familiar with, except the copy just happens to pop
out somewhere else.  I think it's a fairly well established fact that
people don't want to learn anything new if they can help it, and learning
to use Email as effectively as fax does take a while.  (If you don't
believe me, try mailing a binary image from a uucp node to someone on
BITNET.)

Granted, this is nothing inherently wrong with Email; one could certainly
write a nice turnkey system to do very friendly Emailing.  BUT, such a
system doesn't currently exist.  As long as the user has to worry about
what to send (or have his computer send) at a "login:" prompt, Email won't
be as popular as fax.

---
"                                                  !" - Marcel Marceau
Steven Grimm		Moderator, comp.{sources,binaries}.atari.st
koreth@ebay.sun.com	...!sun!ebay!koreth

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 16:07:31 GMT
From:      gutman@manta.NOSC.MIL (Lewis M. Gutman)
To:        comp.protocols.tcp-ip
Subject:   routing protocol paper

I would like to get a copy of Ross Callon's paper, "A Comparison of
'Link State and 'Distance Vector' Routing Algorithms."  Can anyone
direct me to an on-line copy?  Thanks in advance.

Lew Gutman
Code 854, NOSC
San Diego, CA

gutman@nosc.mil

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 16:22:40 GMT
From:      nick@toro.UUCP (Nicholas Jacobs)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

In article <8912190403.AA05387@ucbvax.Berkeley.EDU> 702WFG@SCRVMSYS.BITNET (bill gunshannon) writes:
>So, someone please tell me "What is so great about FAX?" and why can't
>those of us who use Email all the time convince the rest of the world
>how much better it really is??
>
>                                          bill gunshannon
>                                       702WFG@SCRVMSYS.BITNET

I think that we are coming back to the old bugaboo of user education.
Obviously anyone who participates in this newsgroup is many orders of
magnitude more computer literate than your average corporate user. So
unfortunately, until email is as easy to use as a telephone, many people
will not either not bother or in some cases actually go out of their way
to avoid learning all together.

I think that rather than complain about why can't Johnny Corporate learn to
use computers, why not build fax machines that know how to send faxes to
computers. That way, people who prefer to use faxes can and those of us who
know and love our email will be happy too. Also, faxes are still cheaper 
with respect to initial purchase than computers, but particularly in the case
of support, maintenance, and education. These are obviously important to
companies who must maintain a bottom-line profitabity to satisfy their
stock-holders.

Just my $0.02,

Nicholas Jacobs
+-----------------------+----------------------------+----------------------+
| UUCP: uunet!toro!nick | Internet: nick@toro.uu.net | AT&T: (212) 236-3230 |
+-----------------------+----------------------------+----------------------+
"Disclaimer? The legal fees are probably more than my annual salary..."

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 16:35:05 GMT
From:      peter%infidel@LANL.GOV
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful


Bill,

I have to disagree with your analysis of the Fax/Email issue.  It is
not an issue of "PR", it is an issue of packaging and standardization.
While I agree that everything can be done by a PC, and it can be done
better, the packaging of a FAX unit is incredible.  Scanner, modem,
software (not so soft) all wrapped up in a tidy package, driving the
cost of manufacture down, and reducing the skills needed to operate the
beast down to dialing a phone and inserting paper into a xerox
machine.  Skills most people already have.  Also keep in mind that most
people do not have a computer, but they do have a phone jack.  For the
average person or small business it is going to be cheaper (in terms of
immediate $$s and things to learn) to get a Fax unit.  

Faxes also are amazingly standardized, this will take a while to 
accomplish in the arena of Email.  The computer industry is continually
threatening to switch to X.blah-dee-blah, and you know they will not
be happy there.  It is an industry hopelessly caught up in the grass is
always greener syndrome.  People want to buy something now and use it now.
I suspect that most people do not want to keep up with the EMERGING (ahhh,
It's Alive !?!) standards.

Yours by email,

Peter Ford
Center for Nonlinear Studies
Los Alamos National Labs

P.S.  I have never sent anything by Fax.

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 16:54:44 GMT
From:      jdemarco@interlan.interlan.COM (James DeMarco)
To:        comp.protocols.tcp-ip
Subject:   FAXes vs. EMAIL

:r fax.memo

Bill Gunshannon writes:
> The only reason that FAX is more popular than Email is "PR".

I don't agree with you.  I believe that there is still a very large number
of people out in the world who are uncomfortable with computers.  FAX has
the advantage of simplicity.  For hardware, you need only a telephone line,
a FAX machine, and paper.  Setting it up is trivial (plug the FAX in an
electrical outlet and plug in a few modular phone cords).  To send a FAX, just
dial the number you want, insert your document, and va-voom -- MAGIC!  To
receive FAXes is even simpler.

Granted, there are more complicated FAX machines out there, but the simple,
CHEAP ones are going to go to technophobes.  How much would a PC setup cost?
More importantly, how simple would it be to explain how to use it JUST FOR
EMAIL?  I'm not 
talking about explaining it to someone already familiar with computers either.
I'm pretty sure I can have my nieces (both pre-teens) using a FAX confidently
within five minutes FROM SCRATCH.  I think it would take much longer to do
the same for EMAIL on a PC (and they have "played" on PCs a bit, so they aren't
totally new to computers).

> But the truth is, FAX offers nothing that can't be done with the PC sitting
> on your desk.

Currently, the PC on my desk can't talk to a FAX machine ;-).  I don't have
the appropriate hardware or software.

My PC wasn't purchased so I can send EMAIL (its use for EMAIL is mainly an
afterthought and I use our Internet connection).  I use it mainly for software
testing and development.  I suspect that most PCs were bought mainly for
non-email uses (spreadsheets, word processing, databases, etc.).  Hence, they
are not equipped with the necessary hardware for EMAIL.  FAXes, on the other
hand, really have only ONE purpose and that's why they are purchased: to
send and receive [written/printed/drawn] documents.  I don't think I can
convince say, my mother, that she should buy a PC and the appropriate HW (at
least a modem), learn how to set it up and use it, etc., just so she can send
EMAIL; she would have no other use for a PC, nor would she have the patience
or desire to use it (I know, I know, these are famous last words; but you try
convincing her a priori.).  She has NEVER used a typewriter or keyboard before
(I suspect there may be quite a number of people in that situation, by the way,
though I doubt they are on this mailing list).  She could, however, very EASILY
write (by hand) a letter and FAX it to me.  She could FAX me an article from
the local paper (which I, being 250+ miles away, don't usually get).  She could
do this without retyping everything (I think a minimal PC setup with a scanner
would cost significantly MORE than a MINIMAL FAX).

> So, someone please tell me "What is so great about FAX?" and why can't
> those of us who use Email all the time convince the rest of the world
> how much better it really is??

FAXes offer SIMPLICITY at a VERY low cost.

It is this simplicity, IMHO, that has made FAXes so popular.  Of course, the
high-end FAXes are also doing well, but I think that they are being purchased
by people already familiar with FAXes and their limitations.  There is 
[obviously] a big market for sending and receiving [short] documents over
phone lines.  If that were ALL I needed to do, I'd consider a PC overkill
and go out and buy a [cheap] FAX machine.

                                       --Jim


                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 17:03:47 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: partial transfer recovery in RFC and OSI protocols

In article <8912181942.AA10029@arcturus.mitre.org> barns@GATEWAY.MITRE.ORG writes:

   There is a different FTP restart scheme by Rick Adams which I have
   heard will be in 4.4(?).  ... it does not try to handle the more
   difficult cases of operation between divergent systems.

That is not the case.  His FTP restart scheme relies on the fact that
your file is eventually expressed as a stream of octets over the TCP
connection.  His RESTart command simply says to suppress the first N
octets.  It is brilliantly simple.

--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
Live up to the light thou hast, and more will be granted thee.
A recession now appears more than 2 years away -- John D. Mathon, 4 Oct 1989.
I think killing is value-neutral in and of itself. -- Gary Strand, 8 Nov 1989.
Liberals run this country, by and large. -- Clayton Cramer, 20 Nov 1989.
Shut up and mind your Canadian business, you meddlesome foreigner. -- TK, 23 N.

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 17:14:01 GMT
From:      brian@ucsd.Edu (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Re: Xerox Etherphone experiments?

Enough people have written to me to ask about using the SparcStation to
transmit audio that I figured I'd better stem the flow by publishing the
note here.

First of all, the wiring diagram for the SS1 audio plug is in the 4.0.3
release manual that came with the SS1.  You need an 8-pin mini-din plug
which can be kinda hard to find, but it's used by Macintoshes so check
with your local toy computer store.  Note that the chip used in the SS1
is a telephony chip (it's an AMD AM79C30, designed to be the audio
processor in an ISDN voice phone) so it hasn't got a lot of input
gain.  You'll need a high-output microphone.  I used a carbon mic with
a battery and a small transformer.  I've also run the line-level output
of my desk stereo into the SS1; again, I used a small audio transformer
to avoid ground hum and frying the codec chip.

The software I used is

	rsh hostname cat \> /dev/audio < /dev/audio

which gives about a 1-second propagation delay on our local Ethernet; I
suppose this is related to an 8k buffer in either rsh or cat (I haven't
looked).  When it's running, I'm sending a packet just about once a
second, which is so little traffic that I stopped worrying about it
there.  For duplex communication, I suppose you'd want to use something
else that uses a smaller buffer to get less delay.
	- Brian

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 17:19:59 GMT
From:      mentor.cc.purdue.edu!dls@purdue.edu  (David L Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Networks considered harmful

	Well, one point that I haven't seen here yet is that Fax can send
arbitrary information where electronic mail, in its current state, is pretty
much limited to text.
	If Joe Shmoe, corporate executive, wants to send an idea somewhere
for comment and he's got sketches and notes, should he take a couple hours
to type it in and convert the figures to pic or PostScript, or should he
Fax the original? I know what I'd do...
	Fax can do everything e-mail can do (given that all parties have
Fax machines), but e-mail can't do everything that Fax can. Of course they'll
use Fax machines! This is surprising? There's something wrong with this?
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 17:55:35 GMT
From:      karl@asylum.SF.CA.US (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Let's fix email.  Was: Re: Networks considered harmful

In article <8912190403.AA05387@ucbvax.Berkeley.EDU> 702WFG@SCRVMSYS.BITNET (bill gunshannon) writes:
><John Nagle>
>>      Well, in the real world, I understand that electronic mail is
>>on the decline, and is being replaced by fax.
>
>The only reason that FAX is more popular than Email is "PR".
 
>But the truth is, FAX offers nothing that can't be done with the PC sitting
>on your desk. And the PC can even do it better.

I don't agree with all of what you say.  Even though I have six
computers at home and many more at the office I still find Fax very,
very useful.  I still have lots of stuff on paper and I can still
mark-up a document or draw a picture better by hand.

Voice mail is also becomming very, very popular.  I have it for my car phone.

The current state of e-mail is rather primitive.  It is still stuck
using late '60s technology.  Not much to crow about.

The new e-mail standards recognize the need to bring Fax, voice, and
other media together.  That's why I am such a fan of X.400 (as an
application, not for the underlying ISO protocol stack.)  Then e-mail
would have something that could be splashed onto TV ads.

				--karl--

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 17:59:15 GMT
From:      oleary@umd5.umd.edu (dave o'leary)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

In article <6042@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>
>	Well, one point that I haven't seen here yet is that Fax can send
>arbitrary information where electronic mail, in its current state, is pretty
>much limited to text.

The problem with FAX is that it is by definition, a facsimile of a document.
I agree that the current state is not all it could be, that user interfaces
need to be improved so Joe Shmoe, corporate exec, etc. can use it as easily
as FAX.  I see in the long run (2 yrs? 5 yrs?  who knows?) the concept of
FAX will be eclipsed by what we might call electronic mail - it is really
just a matter of communication between two (or more) people.  When I send
information to you, I want you to have the information that I send in a 
manner that you can easily interpret.  Unfortunately the best we can do
today (generally available/accessible/usuable by said Joe Schmoe) is text
transfer by email (which isn't too great) or FAX, which of course also has its 
limitations. 
 
>If Joe Shmoe, corporate executive, wants to send an idea somewhere
>for comment and he's got sketches and notes, should he take a couple hours
>to type it in and convert the figures to pic or PostScript, or should he
>Fax the original? I know what I'd do...
 
>Fax can do everything e-mail can do (given that all parties have
>Fax machines), but e-mail can't do everything that Fax can. Of course they'll
>use Fax machines! This is surprising? There's something wrong with this?
>-- 
>					+-DLS  (dls@mentor.cc.purdue.edu)

It is not clear that FAX "can do everything email can do" - FAX can do some
basic things in a much more user friendly manner.  Email *can* do everything
that FAX can do (well, I can't think of anything off the top of my head,
and I may not be aware of some state of the art new development in FAX) 
but the interface to mail isn't as good.  At least, the good ones aren't
generally available, and the *standrards* (that word again) aren't together
yet either.  

Sorry about the rambling.

						dave

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 19:11:14 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

In article <NELSON.89Dec19094003@image.clarkson.edu> nelson@clutx.clarkson.edu writes:
> In practice, there is no standardization in E-mail packages.

Bingo.

Just standardise. No reason to glom an Email box onto a FAX box. Just sell
a cheap modem with (say) 64K of RAM and a serial port, and let people use
it as an Email answering machine.

I have such a beast. Its got one problem: the user interface sucks. It
sits between your existing modem and your PC and hides, which is fine,
but you can't use it while it's waiting for messages, and you can't put
messages into it (either for store-and-forward or for replies). Good idea,
poor implementation.
-- 
`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
 'U`  Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>.
"It was just dumb luck that Unix managed to break through the Stupidity Barrier
and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 19:19:25 GMT
From:      mentor.cc.purdue.edu!dls@purdue.edu  (David L Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Networks considered harmful
In article <5803@umd5.umd.edu>, oleary@umd5.umd.edu (dave o'leary) writes:
> FAX will be eclipsed by what we might call electronic mail - it is really
> just a matter of communication between two (or more) people.

	I agree. Part of that eclipse will have to be the ability to include
a copy of a physical document (bitmaps), generated graphics, sound and just
plain old arbitrary binary data in "electronic mail," which isn't at all what
we commonly call "electronic mail" today. It's the general problem of
multimedia documents in an electronic form.

> but the interface to mail isn't as good.

	The biggest problem with the interface is that it doesn't include a
Fax interface... :-) Or a sound interface.
	I mean, that's really the key difference; if I have a physical
document I want someone else to see, *I* shouldn't have to translate that
into an electronic form, even if I *can*. That's what Fax does that e-mail
does not.
	As long as there is no standard for sending sound, graphic or binary
data via long haul networks *conveniently*, there will be a need for more than
e-mail. And it should not surprise anyone that people prefer the convenience
of Fax over the current limitations of e-mail.

	And the broader question:

	Why have a separate voice network? Why have Fax-over-phone-lines?
Why NOT have a single large-scale, (very) high-bandwidth network that can handle
any kind of data you want with universal addressability?
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 19:22:05 GMT
From:      kwe@buit13.bu.edu (Kent England)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

In article <NELSON.89Dec19094003@image.clarkson.edu> 
nelson@clutx.clarkson.edu writes:
>
>The way to market E-mail is to glom it onto a FAX machine.  Make a
>little box that you plug in between your FAX machine and the phone
>line.  Give it enough smarts so that it can distinguish between its
>carrier and the FAX machines, and automatically forward the call to
>the FAX machine.  Put some RAM in it so it can hold incoming messages.
>Put a RS-232 (ugh) line on it so a computer can read its output.
>Write some software for the PC and Mac that downloads the messages
>from the little box.
>--
	This is interesting.  What *is* the right way to market
e-mail?  

	In the national research and education internet market, the
way to sell e-mail is to sell the network (NSFnet, ARPAnet, whatever).
e-mail is a "free" service that comes with the (subsidized and
exclusive) network.  The network comes first and stands in the way, if
you can't join.

	In the commercial arena, services like CompuServe set up
information servers that provide e-mail, conferences, news, etc.
e-mail is a mainframe-based service to allow subscribers to converse
with each other.  Lately, the proliferation of various commercial
information services has led to the need to interconnect the various
commercial systems together as an afterthought driven by the
subscribers' desire for ubiquitous service and not as an integral part
of the original service offering, as one might think.  The information
service comes first and stands in the way of e-mail which is an
afterthought.

	Compare this to fax.  With fax, you buy hardware from a vendor
and use an existing network for connectivity.  The fax hardware
conforms to several well-established standards (for modem signalling,
pixel placement, and page description).  You subscribe to no service
whatsoever, except the voice network service.  You don't have to
belong to an exclusive networking club like the national research and
education club and you don't have to subscribe to some information
service that provides mail forwarding and mailbox service like
CompuServe, et al, as an afterthought.  You just buy your box, plug it
in and start dialing.

	I think there would be a market niche for e-mail if someone
would offer an e-mail box like Russ Nelson describes.  Of course, you
have to have a PC to read and compose e-mail, but at least the network
and the information service providers don't get in the way.

	Kent England, Boston University

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 19:49:53 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  sparta.com

Bob,

This problem has been going on for several months, as reported some
time ago in my Internet Monthly report. At the time, it appeared the
WIDEBAND (aka FATNET) gateways appeared the most involved and even
involved traffic fluttering between ARPANET and MILNET between the
same two sites. However, things may be changing so fast that the
apparent traceroute loops aren't really that, just rickety routes
flopping all over the place. Try a record-route option, assuming
you don't have far to go.

Dave

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 19:55:04 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

In article <6042@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
> 	Fax can do everything e-mail can do (given that all parties have
> Fax machines), but e-mail can't do everything that Fax can.

Sorry, this is false. Show me how to FAX a program and I'll believe you.
And of course you can always digitize your picture and send it as an
attached file... and then the other guy can access it remotely.
-- 
`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
 'U`  Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>.
"It was just dumb luck that Unix managed to break through the Stupidity Barrier
and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 20:11:32 GMT
From:      ak2@nvuxr.cc.bellcore.com (Arthur Knapp)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

I think Vint Cerf correctly observed in one of his IEEE NETWORK columns 
that fax enjoys the advantage of using the addressing and connectivity of 
the public switched telephone network (PSTN).  Much as email does all of these neat things for me, the addressing and connectivity are not near that of the PSTN.  Thus, I still have to send hard copy to the "rest" of the world.  
And still, I like having hard copy to "review and edit" rather than the paperless VDT review.

Arthur Knapp          ak2@nvuxr.cc.bellcore.com
Tel: 201-758-2198           Fax: 201-530-6875
331 Newman Springs Road, Rm 1F-359
Red Bank, NJ 07701-7020  USA
Telex: 275318

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 20:19:12 GMT
From:      sl@van-bc.UUCP (Stuart Lynne)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

In article <NELSON.89Dec19094003@image.clarkson.edu> nelson@clutx.clarkson.edu writes:
>
>In practice, there is no standardization in E-mail packages.  You can get
>one for free (Opus BBS), but it takes a good bit of tinkering to get it
>working.
>
>The way to market E-mail is to glom it onto a FAX machine.  Make a
>little box that you plug in between your FAX machine and the phone
>line.  Give it enough smarts so that it can distinguish between its
>carrier and the FAX machines, and automatically forward the call to
>the FAX machine.  Put some RAM in it so it can hold incoming messages.
>Put a RS-232 (ugh) line on it so a computer can read its output.
>Write some software for the PC and Mac that downloads the messages
>from the little box.

Or glom the fax onto your favourite PC. 

In my opinion one of the nicer DOS based fax packages is done by Intel with
their Connection Co-Processor. It is a smart board which will send/receive
fax/files in the background. With it you can send a fax, receive a fax, send
a file to another pc with a CPP or receive a file from another pc with a
CPP.  Of course this all happens in the background, just like on a real os.

They have a little email type thing which you can enter a list of people to
send a message to. It looks up their phone numbers and sends the message
either as a fax or if that person has a pc with CPP then as an ASCII file
(it shows up at the other end as "email").


I think the advantage's of FAX are the simplicity and low cost of the
transmission. Point to point using the low cost of long distance. The data
networks "should be cheaper because packets can share a line" argument
doesn't seem to follow through when you look at the rates. And value added
email services which should be able to use bulk data transmission are also
fairly expensive. FAX is popular because it's reliable, and inexpensive.

For example in Vancouver law offices make a great deal of use of fax to send
draft documents to other law offices a couple of blocks away because it's
less expensive (essentially free) than a bicycle courier and faster. Any
email system that you want to propose for their use will have to emulate
this "feature" - essentially zero cost for operation for local use.

Last time I checked about Envoy 100 (our local Telemail clone) they charged a
fair bit for mail even if it was going to another person in the same
building :-)

Another advantage of fax is the simplicity of use. Dial the phone and the
box does the rest. This has to be carried over to the replacement email
package. You have to just give it a mail message or file to be transferred
and have it delivered without any interaction by the user (except perhaps
that he can't reset the machine for a few minutes).

-- 
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 20:29:19 GMT
From:      uucigj@swbatl.UUCP (3531)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   dial-out SLIP (KA9Q?)

I had read an older message stating that there was a release of KA9Q
available that handled dial-out.  I haven't kept up with the developments
of the KA9Q product and was wondering where I could get the binaries for an
MSDOS machine.  I would like to connect my PC at  home with my Sun at work
(at the present time transmission speed is not important), just to give me
some experience with SLIP and TCP/IP.  Any help would be appreciated.


      Gregg Jensen
   ---------------------------------------------------------------------- 
    These opinions are my own and do not necessarily reflect my companies.
      Southwestern Bell Telephone
      Send E-MAIL to the following address...
               ...!uunet!swbatl!uucigj
   ---------------------------------------------------------------------- 

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 21:40:16 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: MB, MG, MR....

>Hi. May I ask if anybody is currently playing with the experimental
>mailbox RR's ? Is there any software using them ? Do most implementations
>of the DNServers already handle them ? Seems exactly what I need to
>handle our 'logical addresses'. Thanks for any info.       /AF

It is my understanding that MB, MG, and MR are obsolete, and that MX
was designed specifically to be a replacement and generalization of the
other three.

Doug Nelson
Michigan State University

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 22:51:30 GMT
From:      merlin@smu.uucp (David Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

Of course, we could just put a FAX card into our present computers.
I have looked into this for my own purposes.  The problem is not
printing the received FAX messages, but sending them out.

When I send a FAX message, I use FINE or SUPERFINE detail settings.
This looks pretty good when it's received, even though its been
through a digitizing process at the transmitting end.  A computer-
generated FAX does not go through the digitizing stage, so it can
(in theory) look better when received.  The basic lack, though, is
in the software.

A FAX message is a basic b/w or grayscale raster image of the
input page.  It's compressed before transmission.  To send a computer
generated FAX, you must convert your document from whatever word
processor format it is already in to the raster image.  The
software to do this is just not readily available yet.  When it
becomes available, then we may get somewhere.

David Hayes	School of Engineering	Southern Methodist University
merlin@smu.edu	uunet!smu!merlin
"Here's a test to see if your job here on Earth is finished:  If you're
still here, it isn't."  -- Richard Bach, _Illusions_

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Dec 89 08:00:19 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        husain@stsusa.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   re: IP PDU header cksum algorithm question

Your note is a bit confusing because it talks about IP and then ISO 8473
and the checksums are different but, in either case, you want to read
a recent issue of Computer Communication Review.

For ISO checksums, see K. Sklower's article in the October 1989 issue.

For IP checksums, see R. Braden et. al. in the April 1989 issue.

Craig
-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 89 23:52:24 GMT
From:      sl@van-bc.UUCP (Stuart Lynne)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

In article <7367@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
}In article <6042@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
}> 	Fax can do everything e-mail can do (given that all parties have
}> Fax machines), but e-mail can't do everything that Fax can.
}
}Sorry, this is false. Show me how to FAX a program and I'll believe you.
}And of course you can always digitize your picture and send it as an
}attached file... and then the other guy can access it remotely.
}-- 
}`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
} 'U`  Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>.
}"It was just dumb luck that Unix managed to break through the Stupidity Barrier
}and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com


The EIA is sponsoring various committee's to look at extensions to the CCITT
Fax standards. Including one for File Transfer between computers equipped
with V.29 fax style modems.

Various fax board manufacturers already have proprietary protocols that
allow you to transfer files between two pc's as long as you have one of
their boards at each end.

-- 
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 00:06:34 GMT
From:      jay@silence.princeton.nj.us (Jay Plett)
To:        comp.protocols.tcp-ip
Subject:   Re: source-route, record route ping (Re:  traceroute)

In article <1989Dec18.215450.14457@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
> Other folks are stuck at SunOS 3.5 because they view SunOS 4.0.n as a
> "customer beta" release and aren't satisfied with its reliability and
> performance.  We'd really like to upgrade to 4.3-compatible networking,
> but having to accept the rest of SunOS 4.0 with it is too high a price.

Nonsense.
Harumph.

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 01:53:41 GMT
From:      raczka@gldoa.enet.dec.com (raczka@gldoa.enet.dec.com  19-Dec-1989 2050)
To:        comp.protocols.tcp-ip
Subject:   RESENDING

19 December 1989
8:50pm EST

    Good evening

        This months ConneXions lists this address as the source
        for the TCP-IP mailing list

        PLEASE add my mail address to you list....THANK YOU!!

    regards and Happy Holidays
    christopher raczka
    DIGITAL EQUIPMENT CORP

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 02:04:15 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.protocols.tcp-ip,alt.fax
Subject:   Computerfax (was: Networks considered harmful)

702WFG@SCRVMSYS.BITNET (bill gunshannon) writes:
>I don't think you read my whole posting.  I can send Email from PC to PC
>using the exact same Phone system that FAXers use.  The software is easier
>to set up than WordPerfect and the software is even FREE!!!
>
>I still say it is all PR.

	i imagine that we did read your whole posting, bill.
	the word "tirade" came to mind.  
	not that i don't tie a good rade myself, ok?

	your complaint seems to be with 'commercialization' of fax,
	rather than the technology itself.  there are problems with 
	the technology, such as the lack of a standard to specify the
	recipient of the (group 3) fax.  but commercialization is not
	necessarily a problem.  quite the opposite...

	fax is not any sort of 'threat' to email as a technology.
	instead, the combination of the two might create more useful
	technology and a stronger market for both email AND fax!



-- 


-- Steve Elias ; eli@spdcc.com ; 6179325598 ; 5086717556 ; { *disclaimer(); }
                

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 02:31:33 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: source-route, record route ping (Re:  traceroute)

| From: jay@silence.princeton.nj.us (Jay Plett)
| 
| > From: henry@utzoo.uucp (Henry Spencer)
| > 
| > Other folks are stuck at SunOS 3.5 because they view SunOS 4.0.n as a
| > "customer beta" release and aren't satisfied with its reliability and
| > performance.  We'd really like to upgrade to 4.3-compatible networking,
| > but having to accept the rest of SunOS 4.0 with it is too high a price.
| 
| Nonsense.  Harumph.

  Well.  I guess that told him.  Rarely have I witnessed such startlingly
insightful repartee.  Go get him Jay.  Don't forget to load your gun next
time.

Casey

P.S.  I, like Henry, have no intention of switching to Sun OS 4.X until
    it improves its CPU and memory usage performance considerably.

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 02:53:56 GMT
From:      emv@math.lsa.umich.edu (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

A reminder to usenet readers of comp.protocols.tcp-ip that there is an
existing newsgroup, alt.fax, which is dedicated for better or for
worse to discussions of fax technology and applications.

obl. tcp-ip-relevant comment: There's work being done at several
CICnet schools to use internet links as transport for fax messages.
The underlying tcp technology is FTP as you might expect.  A recent
announcement of fax tools was recently reposted by yrs truly to
comp.archives so if you skim through that you should be able to find
it pretty quickly.

I know there's an RFC that addresses a standard format for storing an
ascii representation of fax images written back in the olden days when
the US Post Office was going to offer the service.  

--Ed

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 04:41:00 GMT
From:      WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   Networks considered harmful


    To send a computer generated FAX, you must convert your document
    from whatever word processor format it is already in to the raster
    image.  The software to do this is just not readily available yet.

Well, most word processors are capable of producing PostScript output
files.  These files can, in turn, be sent through HiJack-PS and out a
FAX interface...

    When it becomes available, then we may get somewhere.

Where are we going?

--Frank

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 05:24:05 GMT
From:      jamesp@wacsvax.OZ (James Pinakis)
To:        comp.protocols.tcp-ip
Subject:   Building a reliable datagram protocol on top of UDP

This may have been done to death previously but I can't find out
anything about it so here goes...

I'm trying to write a protocol which delivers variable size packets
reliably (i.e. in sequence, no dups, no dropped packets) using the
Internet UDP.  I opted to use UDP since I wanted a single (server)
process to be able to accept messages from any number of sites (clients),
rather than (using the tcp-ip client/server model) a process having
to accept a connection, then fork a process to talk on that connection.
I would also prefer to only have one socket to listen on, rather than
a pile of file descriptors to select on (since the number of clients
is potentially large).

I'm currently implementing a sliding window protocol (Tanenbaum's
protocol 6, actually) but this is getting nastily complicated.
It amounts to having to maintain a set of protocol state information
for every client which establishes a "connection" to the server.
This implies a reasonably large setting up operation every time
a new client wants to start talking with the server.

Basically, I'm wondering if anyone has experience/source code which
they would like to share with me.  How efficient is this protocol
likely to be?  Would I be better off sticking with tcp-ip and
accepting a limit to the number of client processes?

Thanks in advance

james
--

Department of Computer Science,   ACSnet:   jamesp@wacsvax.oz
University of Western Australia,  ARPA:     jamesp%wacsvax.oz@uunet.uu.net
Nedlands WA 6009,                 UUCP:     ..!uunet!munnari!wacsvax!jamesp
AUSTRALIA
PHONE:  (09) 380 2305             OVERSEAS: +61 9 380 2305

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Dec 89 10:04:42 EDT
From:      Jack Haverty <haverty@BBN.COM>
To:        mrose@cheetah.nyser.net
Cc:        702WFG%scrvmsys.bitnet@BBN.COM, tcp-ip@nic.ddn.mil
Subject:   Re: Networks considered harmful
Marshall et al,

I agree wholeheartedly with your reasons:

>Reason 1:	FAX is turn-key in every aspect: any office person can
>		install and use a fax machine without any serious training.
>
>
>Reason 2:	FAX uses an already existing, global infrastructure.
>

and I'd like to add one which has been especially frustrating lately:

Reason 3: FAX is able to carry almost anything that can be put on paper
(at least in black&white)

I keep having experiences which I'm sure are pretty common among
people who use Email and Fax, for example:

I have a computer on my desk, connected to the Internet, and I know how
to use it; therefore reasons #1 and #2 are less of a problem for me
personally.  Last month I wanted to send a draft copy of a report to a
colleague on the West Coast for review and comment.  The report of
course has some graphs, diagrams, etc. in it.   She also has a computer,
and is on the Internet; in fact we both have Macintosh'es, which should
make it a piece of cake.

1/ I "BINHEXed" up my report so it could get through the mail system;
this of course is far more arcane and complex a task than you'd like to
inflict on a computer-naive user.  Then I sent that result via e-mail.
[Note: if you try this without verifying a priori that the recipient
will be able to deal with it, you run the risk of intense reactions,
invectives, speculations about your sanity and genetic background, and
the like.  It's even better than ICMP pinging to test if a remote site
is alive.  Take it from one who knows.....]

2/ My colleague reported back that the message arrived, and she
successfully decoded it from BINHEX into a file.  Unfortunately, I had
prepared it using Microsoft Word 4.0, and she was using 3.0 (at least we
were using the same brand of word processor).

3/ I went back to the word processor, and output a file in "3.0" format;
fortunately the program provides this capability.  I BINHEXed it, and
sent it off again.

4/ My colleague reported back that the message arrived, decoded
properly, and she could read it into her PC.  Unfortunately, the FONTs
that I had in my machine included some that she did not have, so that
the report was unintelligible.

5/ So much for standards...  Plan B took over.  I once again fired up
the word processor, and created a PostScript output file.  This involves
unearthing the book of folklore and finding the right magic incantation,
which involves a combination of keystrokes and timing that guarantees
that only wizards will be able to perform the rite.  Another round of
BINHEXing, and off it goes in the mail again.

6/ My colleague reported back that it all decoded, and she had
successfully sent it to the local printer.  Several pages of the
document came out, and then a page which said something about stack
overflow and offensive commands.  PostScript-related error messages seem
to me to be competitive with error reports I see from various electronic
mail systems in terms of incomprehensibility and uselessness - i.e.,
giving the recipient some hint of what to do about the problem.  Not
seeing any obvious place to sacrifice a goat, ...

7/ I took my paper copy of the report, walked down the hall to the FAX
machine, and sent it.  She had it in her hands 30 minutes later.

Assuming my experience is not a fluke, does anyone wonder why mere
mortals might use FAX instead of e-mail?   As one of the players in
e-mail in the 70s (historians see RFCs in the early 700s), it's a little
saddening to see the state of "user-friendliness" that has persisted for
the last 15 years.   For the non-technical world, E-mail provides a
capability somewhat akin to TELEX and Telegrams - the ability to send a
text-only message electronically, assisted by a wizard who will help to
figure out the proper string of magic characters needed to specify the
recipient properly.  Anything beyond that is too hard for most users,
except where specific custom software packages which go beyond the
standards have been created and are used within a community of such
users.   FAX provides a fundamentally different service.  I
wholeheartedly agree with the comment that a synergy between FAX and
E-mail has the potential for a great advance in the utility of both.

Jack


-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 06:24:44 GMT
From:      loverso@Xylogics.COM (John Robert LoVerso)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

In article <5803@umd5.umd.edu> oleary@umd5.umd.edu (dave o'leary) writes:
> In article <6042@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
> >	Well, one point that I haven't seen here yet is that Fax can send
> >arbitrary information where electronic mail, in its current state, is pretty
> >much limited to text.
> 
> The problem with FAX is that it is by definition, a facsimile of a document.

But, that's why its such a hit!

An analogy I'm reminded of is with the original Xerox copier.  It was
originally touted as a replacement for carbon paper - simply type a single
copy and duplicate it.  Sales floundered until it was retargetted to 
the duplicating of pre-existing documents; this started the copier
revolution and an industry.

I see `email' (I dislike that term) being the copier-replacing-carbon-paper;
the FAX has come along and started a revolution.  There's just no (current)
easy way to get a signed document from here to there using email, without
extra hardware (over any "standard" PC) and a better user interfaces, etc.

Personally, I find FAXing a pain and couldn't live without mail.

John

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 06:31:39 GMT
From:      sharon@asylum.SF.CA.US (Sharon Fisher)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

In article <100@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes:
>In my opinion one of the nicer DOS based fax packages is done by Intel with
>their Connection Co-Processor. It is a smart board which will send/receive
>fax/files in the background. With it you can send a fax, receive a fax, send
>a file to another pc with a CPP or receive a file from another pc with a
>CPP.  Of course this all happens in the background, just like on a real os.

The idea behind the connection coprocessor was great.  Unfortunately,
while Intel released the specs to software vendors, so you could send
messages from within software, they made it difficult for hardware
vendors to get specs.  This meant that you could only do this if both
you and the destination had Intel boards.  So it hasn't been very
successful.  Also, some people haven't been thrilled with the
technical specs of the Intel board; I'll think about it and try to
remember what they've said.

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 07:31:36 GMT
From:      cire@CISCO.COM (cire|eric)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful


It'll be especially interesting when MAN systems being discussed by
Bell Core and AT&T start coming on line.  This will effectively tie
LANs into the Central Offices.  Interesting possibilities.

-c

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Dec 89 14:58:28 EDT
From:      Jack Haverty <haverty@BBN.COM>
To:        haverty@BBN.COM
Cc:        702WFG%scrvmsys.bitnet@BBN.COM, mrose@cheetah.nyser.net, tcp-ip@nic.ddn.mil
Subject:   Re: Networks considered harmful
When I said in the message I few hours ago: "PostScript-related error
messages seem to me to be competitive with error reports I see from
various electronic mail systems in terms of incomprehensibility and
uselessness", I didn't anticipate that I'd see the following
incomprehensible reply by some mail system (at least I assume that's who
"Revised List Processor" is) attempting to establish its supremacy: 

----- received in response to my previous message to tcp-ip ----


Date:         Wed, 20 Dec 89 14:46:22 EST  
From:         Revised List Processor (1.6c)
<LISTSERV%POLYGRAF@graf.poly.edu>     
Subject:      Ack: Re: Networks considered harmful     
To:           Jack Haverty <haverty@BBN.COM>

Statistics for TCP-IP mailing (TCP-IP Redistribution List): -> Only
local users and domain-style recipients on the list.
-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 12:32:50 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.protocols.tcp-ip,alt.fax
Subject:   computerfax (was Re: Networks considered harmful)

followups to alt.fax.
by the way, does anyone else support the creation of comp.fax ?

 emv@math.lsa.umich.edu (Edward Vielmetti) writes:
	
>I know there's an RFC that addresses a standard format for storing an
>ascii representation of fax images written back in the olden days when
>the US Post Office was going to offer the service.  

	the US post office is currently offering fax service at
	some northeast post offices.  they rent space to a company	
	which put together "fax kiosks" designed for public use.

	(has anyone seen one of these beasties, yet?)

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 12:46:16 GMT
From:      mrose@CHEETAH.NYSER.NET (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Your chance to enter the brave new world of OSI...

...just in time for the holiday season!

Back in July, NYSERNet started a White Pages Pilot Project using X.500
over TCP/IP as the underlying technology.  At the three month mark last
October, we hit nearly 100K entries at approximately 30 sites, about
half of these were NYSERNet sites.  During the last three months, we
(NYSERNet and University College London) have spent a lot of effort
making the software more robust, performant, and usable, based on our
initial experiences.  Well, as we enter the next three months, I'd like
to extend an invitation to Internet sites in the US and CA to join our
pilot.  Here are the details:

1. You will need to run your own Directory Service Agent (DSA).  This should
run on just about any 4BSD-derived platform, although the recommended
platform is a Sun-3 or Sun-4.  You will need 30MB free disk for sources
and executables.  In addition, for each person you intend to have
registered, the DSA will require approximately 1K of primary memory.
(Yes, the DSA keeps entries resident in core, does its own memory management,
etc., etc., there are obscure technical reasons for this.)  I'm the
first to admit that the memory requirement is "noteworthy", but just think
of it as the price of admission.

2. The machine you run your DSA on will have to be on the Internet
(direct IP access) and your organization must reside in the United
States or Canada.  The Canadian DMD (Directory Management Domain) is
still being set-up at the University of Toronto, but should be
operational before year's end.  If there is an IP-connected site in
Mexico, contact me: I'd like to get c=MX up and running sometime.  It
would be nice to offer White Pages over dial-up or something, but no
dice.  Think of the IP-connectivity requirement as another price of admission.

3. You will need to be able to devote time to installing the software
and maintaining it.  You will also need to check on your DSA regularly
(i.e., once each morning) just to see that things are fine.  In
addition, if users at your site need help, you will be the first point
of contact.  This really isn't such a drain, considering that if you're
the PostMaster at this site, you perform the exact same functions already.

So, after comitting all this what do you get?

Well, if you want a "hype" answer:

    - you get to join a large distributed information service which is
      administered by different organizations;
    - you get to take part in the first production-quality field test of
      the OSI Directory (X.500);
    - you get to take part in the first large scale production application of
      OSI technology on top of the TCP/IP suite of protocols; and,
    - you get to add this experience to your resume, which will look
      quite good. 

But, if you want the real answer:

    You get to offer an exciting new service to your users.  White Pages
    is just one of many applications you can host on top of the OSI
    Directory.  By getting the Directory installed at your site, you are
    bootstrapping yourself to support the next generation of applications
    which need Directory Service, e.g., MHS (X.400).

Besides, it's fun to run the White Pages software to track people down,
display their photos, find out their favorite drink, etc.

For more information, use anonymous FTP to host nisc.nyser.net, and
retrieve the file

	pilot/src/pilot-ps.tar.Z

in BINARY mode.  This contains a compressed tar image of several
postscript files containing four documents: an introduction, an Admin
Guide, a User Manual, and a presentation.  Print these.  The Admin Guide
says how to get the software.

/mtr

ps: if you can't use FTP, then you don't have IP-connectivity (and can't
participate anyway).  Be kind to the WPP manager and don't send messages
asking for these documents.  Wait until the next release of the ISODE
(next month), which will contain them, and you can print them yourself.
Thanks!

/mtr

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 13:00:19 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: IP PDU header cksum algorithm question


Your note is a bit confusing because it talks about IP and then ISO 8473
and the checksums are different but, in either case, you want to read
a recent issue of Computer Communication Review.

For ISO checksums, see K. Sklower's article in the October 1989 issue.

For IP checksums, see R. Braden et. al. in the April 1989 issue.

Craig

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 14:04:42 GMT
From:      haverty@BBN.COM (Jack Haverty)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

Marshall et al,

I agree wholeheartedly with your reasons:

>Reason 1:	FAX is turn-key in every aspect: any office person can
>		install and use a fax machine without any serious training.
>
>
>Reason 2:	FAX uses an already existing, global infrastructure.
>

and I'd like to add one which has been especially frustrating lately:

Reason 3: FAX is able to carry almost anything that can be put on paper
(at least in black&white)

I keep having experiences which I'm sure are pretty common among
people who use Email and Fax, for example:

I have a computer on my desk, connected to the Internet, and I know how
to use it; therefore reasons #1 and #2 are less of a problem for me
personally.  Last month I wanted to send a draft copy of a report to a
colleague on the West Coast for review and comment.  The report of
course has some graphs, diagrams, etc. in it.   She also has a computer,
and is on the Internet; in fact we both have Macintosh'es, which should
make it a piece of cake.

1/ I "BINHEXed" up my report so it could get through the mail system;
this of course is far more arcane and complex a task than you'd like to
inflict on a computer-naive user.  Then I sent that result via e-mail.
[Note: if you try this without verifying a priori that the recipient
will be able to deal with it, you run the risk of intense reactions,
invectives, speculations about your sanity and genetic background, and
the like.  It's even better than ICMP pinging to test if a remote site
is alive.  Take it from one who knows.....]

2/ My colleague reported back that the message arrived, and she
successfully decoded it from BINHEX into a file.  Unfortunately, I had
prepared it using Microsoft Word 4.0, and she was using 3.0 (at least we
were using the same brand of word processor).

3/ I went back to the word processor, and output a file in "3.0" format;
fortunately the program provides this capability.  I BINHEXed it, and
sent it off again.

4/ My colleague reported back that the message arrived, decoded
properly, and she could read it into her PC.  Unfortunately, the FONTs
that I had in my machine included some that she did not have, so that
the report was unintelligible.

5/ So much for standards...  Plan B took over.  I once again fired up
the word processor, and created a PostScript output file.  This involves
unearthing the book of folklore and finding the right magic incantation,
which involves a combination of keystrokes and timing that guarantees
that only wizards will be able to perform the rite.  Another round of
BINHEXing, and off it goes in the mail again.

6/ My colleague reported back that it all decoded, and she had
successfully sent it to the local printer.  Several pages of the
document came out, and then a page which said something about stack
overflow and offensive commands.  PostScript-related error messages seem
to me to be competitive with error reports I see from various electronic
mail systems in terms of incomprehensibility and uselessness - i.e.,
giving the recipient some hint of what to do about the problem.  Not
seeing any obvious place to sacrifice a goat, ...

7/ I took my paper copy of the report, walked down the hall to the FAX
machine, and sent it.  She had it in her hands 30 minutes later.

Assuming my experience is not a fluke, does anyone wonder why mere
mortals might use FAX instead of e-mail?   As one of the players in
e-mail in the 70s (historians see RFCs in the early 700s), it's a little
saddening to see the state of "user-friendliness" that has persisted for
the last 15 years.   For the non-technical world, E-mail provides a
capability somewhat akin to TELEX and Telegrams - the ability to send a
text-only message electronically, assisted by a wizard who will help to
figure out the proper string of magic characters needed to specify the
recipient properly.  Anything beyond that is too hard for most users,
except where specific custom software packages which go beyond the
standards have been created and are used within a community of such
users.   FAX provides a fundamentally different service.  I
wholeheartedly agree with the comment that a synergy between FAX and
E-mail has the potential for a great advance in the utility of both.

Jack

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 14:26:16 GMT
From:      jhm+@ANDREW.CMU.EDU (Jim Morris)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

Here is an earlier reply to John's messsage -- back when it was just a
bb post on USENet's telcom.

Generally, I agree with Marshal Rose and, especially, Russ Nelson.

Bill Gunshannon: Wake up and smell the thermal paper! :-)



---------- Forwarded message begins here ----------

X-Andrew-Authenticated-As: 28;andrew.cmu.edu;Jim Morris
Received: from
Messages.7.10.N.CUILIB.3.45.SNAP.NOT.LINKED.foo.expres.cs.cmu.edu.rt.r3
          via MS.5.6.foo.expres.cs.cmu.edu.rt_r3;
          Wed, 27 Sep 89 12:20:59 -0400 (EDT)
Message-ID: <cZ8DBfy00hl=4BoPpw@andrew.cmu.edu>
Date: Wed, 27 Sep 89 12:20:59 -0400 (EDT)
From: Jim Morris <jhm+@andrew.cmu.edu>
X-Andrew-Message-Size: 4368+1
Content-Type: X-BE2; 12
If-Type-Unsupported: alter
To: telecom@eecs.nwu.edu
Subject: Re: Networks Considered Harmful - For Electronic Mail
CC: John McCarthy <JMC@sail.stanford.edu>


I think John's message was very important -- a sort of wake-up call for
the computer community.

> Excerpts from internet.telecom: 18-Aug-89 Networks Considered Harmful..
> John McCarthy@sail.stanf (9146)
 
> However, unless email is freed from dependence on the networks, I predict it 
 
> will be supplanted by telefax for most uses in spite of its many advantages 
> over telefax.
I believe email will be supplanted by FAX -- period. We will eventually
end up with a hybrid, but it will be achieved by the FAX business
assimilating all the knowledge we have about email.

> These advantages include the fact that information is 
> transmitted more cheaply as character streams than as images.
> Group IV compression brings the image vs. ASCII ratio down to about 5. 
 
> Multiple addressees are readily accommodated.
FAX store and forward services like MCI's  and AT&T' s will provide this.

>  Moreover, messages transmitted as character streams can be readily
> filed, searched, edited and used by computer programs.
OCR can work for the searching part.  99% character recognition rates
are common. There are already products available that scan, recognize,
and index documents for you. The key idea is that the image is saved
too, so there is no danger of the  1% missed characters causing problems
other than missed retrieval.

As for editing, very often one wants only to annotate another document.
This can be done on the image. If one really wants to edit a document,
OCR plus some hand massaging may suffice.

> The reason why telefax will supplant email unless email is separated 
> from special networks is that telefax works by using the existing telephone 
> network directly.
Yes!!!

> Fax has another advantage that needs to be matched and can be 
> overmatched.  Since fax transmits images, fully formatted documents can be 
> transmitted.  However, this loses the ability to edit the document. 
 This can 
> be beaten by email, provided there arises a widely used standard for 
> representing documents that preserves editability.
This is a very big proviso. There is great chaos in this area right now.
The standard proposed by CCITT, called Office Document Architecture
(ODA), is getting very little support in the US where the DoD seems to
be promoting SGML and the commercial document editor vendors are
promoting their own proprietary standards. MicroSoft's Rich Text Format 
(RTF)  seems most promising since it is used by more than one document
processor. Another hope is that a single vendor, e.g. DEC with it's
ODA-related DDIF and DECWrite (=Framemaker),  will become the market
leader and establish a de facto standard, as Lotus did for spread sheets.

A much more likely development is that PostScript becomes the exchange
standard. It is there. All document processors will produce it. It looks
a little nicer than FAX, and there is at least a fighting chance that
one can translate it back into a particular document processor's
internal format.

Another advantage of FAX you failed to emphasize is simply that it deals
with pictures effortlessly. Even if you and I have precisely the same
computing equipment and are on the ArpaNet, the fastest way for me to
get a picture to you is FAX. This is true even if the picture is hand
drawn -- drawing it on paper is faster than any drawing editor I've ever
used.


> Fortunately, there is free enterprise. Therefore, the most likely way 
> of getting direct electronic mail is for some company to offer a piece of 
> hardware as an electronic mail terminal including the facilities for
 connecting
> to the current variety of local area networks (LANs). The most likely
 way for 
> this to be accomplished is for the makers of fax machines to offer ASCII 
> service as well. 

An AppleFAX modem will already do this for Apple PICT files. I would
like to see Adobe do the same for PostScript files.

> This will obviate the growing practice of some users of fax 
> of printing out their messages in an OCR font, transmitting them by fax,
> whereupon the receiver scans them with an OCR scanner to get them back into 
> computer form.

Why should this practice be obviated? Why not work at making OCR more
effective? In a race between clever computer hackers trying to make OCR
better and institutional politicians trying to straighten out the
standards who do you think will win? Which would you rather be?




Jim.Morris@andrew.cmu.edu
412 268-2574
FAX: 412 681-2066

[An Andrew ToolKit view (a raster image) was included here, but could
not be displayed.]

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 14:56:57 GMT
From:      dricejb@drilex.UUCP (Craig Jackson drilex1)
To:        comp.protocols.tcp-ip
Subject:   Re: partial transfer recovery in RFC and OSI protocols

In article <NELSON.89Dec19120206@sun.clarkson.edu> nelson@clutx.clarkson.edu writes:
>In article <8912181942.AA10029@arcturus.mitre.org> barns@GATEWAY.MITRE.ORG writes:
>
>   There is a different FTP restart scheme by Rick Adams which I have
>   heard will be in 4.4(?).  ... it does not try to handle the more
>   difficult cases of operation between divergent systems.
>
>That is not the case.  His FTP restart scheme relies on the fact that
>your file is eventually expressed as a stream of octets over the TCP
>connection.  His RESTart command simply says to suppress the first N
>octets.  It is brilliantly simple.

I think what barns was saying is while that it may be "simple" just to read
through 100 Megabytes of a file, using a possibly CPU-intensive transformation
to turn in into a Unix-compatible file, just to transmit the last Megabyte,
it can't be considered friendly to non-Unix systems.  Especially systems
that otherwise have no problem saying "move to record 200000 of that 201000
record text file, and transmit the rest".

Just as "All the world isn't a VAX", "All the world isn't Unix".  I would
like to suggest that the world is better for that.

(Did I say enough to make inews happy?)
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 15:54:31 GMT
From:      PETEHIC@UOTTAWA.BITNET (Pete Hickey)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

How do FAX newsgroups (such as this one) work?  Do they need
a moderator? :-)
-pete

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 16:04:28 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip,comp.org.usenix
Subject:   Re: Networks considered harmful/Re: USENIX board studies UUCP

In article <8912200236.AA25652@ucbvax.Berkeley.EDU> cire@CISCO.COM (cire|eric) writes:
> Yes Computer based telecommunications has a great deal of more utility
> than FAX but I don't think that is the point.  You must first make the
> connection before all that starts making a difference.

OK. Let's do it. What should the communications look like? UUCP? Dial-up
SLIP? Or something more like FIDO? All we need to do is agree on a
standard and then we can start saying:

	mail 7134385018!peter
Or:
	mail peter@7134385018.PHONE

And folks with home PCs can do the same. Just make it simple enough that
any bozo with a copy of PCTalk can hack it up.

Chat scripts for UUCP, and baud rates, are the biggest problem.

How about this:

To start up the session, you need to send the string "email<CR>". This should
handle the login problems. You keep sending this string with a 1 second
delay until you get a protocol startup... so you'd make your email login
"email" with password (if any) "email". A PC could just start straight up
with the protocol.
-- 
`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
 'U`  Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>.
"It was just dumb luck that Unix managed to break through the Stupidity Barrier
and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 17:03:47 GMT
From:      cowan@spanky.sps.mot.com
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Which gives best data integrity:  NFS, UUCP, or FTP?


Any one got a few minutes to answer a few questions?  

For UUCP, FTP, and NFS, in what way (if any) do each of these programs
perform data integrity checks and data correction?  I'm not talking
about how a packet reaches the destination, but how, if by sheer magic
a bit in the data being transferred is munged up, it is detected and
corrected.  At what levels (in the protocol stack) is the data
integrity checking done.

What I'm really interested in is knowing is: Which one of these three
methods is most reliable (in a data integrity sense) for transferring
data, and why?   (Opinions, without sensible backing arguments, will
be directed to /dev/null.)

Any takers?


 Andy Cowan
 cowan@soleil.sps.mot.com
 (602)821-4942

 Andy Cowan
 cowan@soleil.sps.mot.com
 (602)821-4942

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 17:18:49 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: partial transfer recovery in RFC and OSI protocols


    In article <8912181942.AA10029@arcturus.mitre.org> barns@GATEWAY.MITRE.ORG writes:

	   There is a different FTP restart scheme by Rick Adams which I have
	   heard will be in 4.4(?).  ... it does not try to handle the more
	   difficult cases of operation between divergent systems.

	That is not the case.  His FTP restart scheme relies on the fact that
	your file is eventually expressed as a stream of octets over the TCP
	connection.  His RESTart command simply says to suppress the first N
	octets.  It is brilliantly simple.

Well, not exactly.  How do you compute N, or reset your file to N?  N
is a count of bytes in the transmitted data stream, which is related to
file position parameters through a transformation which could be very
complex.  On the machine with a complex file structure, the only way to
compute N in general is to play through the conversion process.

I believe Bill Barns stated it exactly right.  Rick's scheme is
brilliantly simple only for binary files between Unix systems.

Bob Braden

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 17:35:17 GMT
From:      kip%kippu@Sun.COM (David Kipping)
To:        comp.protocols.tcp-ip
Subject:   Re: Let's fix email.  Was: Re: Networks considered harmful

In article <8034@xenna.Xylogics.COM> loverso@Xylogics.COM (John Robert LoVerso) writes:
>In article <5803@umd5.umd.edu> oleary@umd5.umd.edu (dave o'leary) writes:
>> In article <6042@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>> The problem with FAX is that it is by definition, a facsimile of a document.
>
>
>I see `email' (I dislike that term) being the copier-replacing-carbon-paper;
>the FAX has come along and started a revolution.  There's just no (current)
>easy way to get a signed document from here to there using email, without
>extra hardware (over any "standard" PC) and a better user interfaces, etc.
>

One reason that FAX has been accepted so much is that the law in the states
has accepted "signed" documents which are faxed as legally binding. As a result
it has become common place to "exchange" signatures via FAX on multimillion
dollar deals.

One thing holding up email in the business community is that to my understanding,
commitments emailed are not considered binding. What is needed is to raise
the security image of email to make it binding.

I won't bring up the legal implications of sending a FAXed, signed document
over email.

disclaimers()

David Kipping 
kip@sun
(415) 336-1013

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 17:48:04 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Of interest to time freaks

Roy,

The entertainment is fun. To balance the citations from a technical standpoint,
you guys might want the following on your bookshelf: Blair, B.E. (Ed.).
TIme and Frequency Theory and Fundamentals. National Bureau of Standards
Monograph 140, U.S. Department of Commerce, 1974. While somewhat dated
in some respects, this tome may be the single most usful reference for
mathematical theory, practical generation and distribution and description
of timescales.

Dave

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 18:08:31 GMT
From:      gkrishn@beta.eng.clemson.edu (Krishnan Gopalan)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Version 1.1 of pop3client


A new release of pop3 client is available via anonymous FTP from 
eng.clemson.edu. The client now supports a mail delivery facility by talking
smtp to the pop3 server machine. Basically, you can now send mail from the
PC to the internet using the pop3 client.


Krishnan Gopalan		Engineering Computer Operations,
gkrishn@eng.clemson.edu			Clemson University.

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 18:58:28 GMT
From:      haverty@BBN.COM (Jack Haverty)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

When I said in the message I few hours ago: "PostScript-related error
messages seem to me to be competitive with error reports I see from
various electronic mail systems in terms of incomprehensibility and
uselessness", I didn't anticipate that I'd see the following
incomprehensible reply by some mail system (at least I assume that's who
"Revised List Processor" is) attempting to establish its supremacy: 

----- received in response to my previous message to tcp-ip ----


Date:         Wed, 20 Dec 89 14:46:22 EST  
From:         Revised List Processor (1.6c)
<LISTSERV%POLYGRAF@graf.poly.edu>     
Subject:      Ack: Re: Networks considered harmful     
To:           Jack Haverty <haverty@BBN.COM>

Statistics for TCP-IP mailing (TCP-IP Redistribution List): -> Only
local users and domain-style recipients on the list.

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 20:32:08 GMT
From:      hughes@silver.bacs.indiana.edu (larry hughes)
To:        comp.unix.wizards,comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   Re: SUMMARY: IBM <-> UNIX Connections (400 lines)

I might also add another interesting connection method that we're
preparing to implement at Indiana University.

We have a 3090-300S that historically has been used as an administrative
machine.  However, we're currently bringing up an online library system
and other applications that are of interest to all faculty, staff, and 
students.  The 3090 runs ACCES/MVS, and is FEP'd with an Intel 9770.

Since we anticipate connections from PC's, Mac's, terminal servers,
high end workstations, and minis, we obviously wanted to offload the 
3270 protocol conversion from the 3090.  Additionally, we found that
the ACCES/MVS software multithreads the connections more optimally when 
there are fewer sources of connections.

Our solution consists of:

  (1) 3 Sun Sparcstations which autologin each inbound telnet
      connection (on port 23) as user TN3270, and automatically
      invokes tn3270 to pass them through to the 3090.

  (2) A modified version of the Berkely bind (named) code which
      load balances most of the connections to the Sparcs based
      on number of current users and CPU load (not round-robin).
      This obviously won't work for hosts that utilize caching
      nameservers), but will work for those that don't, as well
      as for the terminal servers, PCs, and Macs.

This description is vague, but you get the idea.  It's not up yet, 
but will be soon.  We're just ironing out the last few details, 
and waiting for the next semester to start.

 //=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=\\
|| Larry J. Hughes, Senior Programmer ||  hughes@silver.bacs.indiana.edu   ||
||        Indiana University          ||                                   ||
||   University Computing Services    ||  "The person who knows everything ||
||    750 N. State Road 46 Bypass     ||     has a lot to learn."          ||
||      Bloomington, IN  47405        ||                                   ||
||         (812) 855-9255             ||  Disclaimer: See quote above.     ||
 \\=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=//

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 21:19:13 GMT
From:      meissner@osf.osf.org (Michael Meissner)
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Re: Which gives best data integrity:  NFS, UUCP, or FTP?

In article <1972@dover.sps.mot.com> cowan@spanky.sps.mot.com () writes:
|
|Any one got a few minutes to answer a few questions?  
|
|For UUCP, FTP, and NFS, in what way (if any) do each of these programs
|perform data integrity checks and data correction?  I'm not talking
|about how a packet reaches the destination, but how, if by sheer magic
|a bit in the data being transferred is munged up, it is detected and
|corrected.  At what levels (in the protocol stack) is the data
|integrity checking done.

When I was at Data General, I had some particularly bad experiences
with NFS.  Our ethernet(s) at the time had a variety of hardware
hooked up to it (Data General MV's running AOS/VS communicating with
X.25 and some TCP/IP over ethernet, MV's running DG/UX communicating
with TCP/IP, MSDOS-based PC's speaking X.25, etc.).  We added some Sun
workstations to bootstrap to the AViiON (88k based) system.  The Sun's
were running 3.5 SunOS.  We started noticing random file corruption
problems when compiling stuff on the Sun's on NFS mounted partitions
from MV's running DG/UX.

At first we thought it was some bug in our server code, but the
network people tracked it down to random packets getting a bit or two
trashed.  In order to get higher throughput, SunOS 3.5 NFS uses UDP
connections.  Unlike TCP, UPD connections can come out of order,
dupiclated, trashed, etc. and it is assumed that higher layers of
software will deal with this.  However there is an option to enable
the checksums on UDP packets, and not deliver the packets that had a
bad checksum specified.

The way we dealt with the problem was to take the NFS reference source
from Sun, recompile the one module that spit out the UDP packets to
turn on UDP checksums, ar the module into the appropriate kernel
library, and regen the systems.  Viola, it fixed our problem.

By the way, we did attempt to report the bug to Sun, and where told it
was a feature, since checksumming slows down the machine.  In
practice, we never noticed the slowdown, and we could go back to
building the software, without some object file randoming having it's
bits changed.

|What I'm really interested in is knowing is: Which one of these three
|methods is most reliable (in a data integrity sense) for transferring
|data, and why?   (Opinions, without sensible backing arguments, will
|be directed to /dev/null.)
|
|Any takers?

See above.  The normal NFS over UDP depends on your link layers of the
software not to trash the bits.  Both FTP (via the reliable TCP
streams), and UUCP (via the low level packet handler) are protected by
checksums or the like.  How well those checksums behave under stress,
(ie, whether they can fixup multiple bit errors or not) I don't know.
I have heard about random FTP corruption problems, but most of those
are either not using binary/image mode, or ftp'ing a file from a NFS
mounted disk.

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 22:08:27 GMT
From:      kasten@interlan.interlan.COM (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

> How do FAX newsgroups (such as this one) work?  Do they need
> a moderator? :-)
> -pete

Actually, they use a distributed moderator scheme. I send my news to
two friends, they each send it to two friends and so on and so on.
During the events in Tienanmen Square in Beijing during and after
the siege by the PLA the students would send a fax to a friend in a
friendly country who would then distribute it. If more reliability
is needed, you get redundant friends....

Cheers
Frank Kastenholz
Racal Interlan

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 22:42:51 GMT
From:      sl@van-bc.UUCP (Stuart Lynne)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

In article <9153@asylum.SF.CA.US> sharon@asylum.UUCP (Sharon Fisher) writes:
}In article <100@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes:
 
}The idea behind the connection coprocessor was great.  Unfortunately,
}while Intel released the specs to software vendors, so you could send
}messages from within software, they made it difficult for hardware
}vendors to get specs.  This meant that you could only do this if both
}you and the destination had Intel boards.  So it hasn't been very
}successful.  Also, some people haven't been thrilled with the
}technical specs of the Intel board; I'll think about it and try to
}remember what they've said.

Yes, the EIA committee's looking at an FTP spec are apparently not looking
at the Intel spec's.

I was just pointing to what I think is an interesting integration of the
functions at the user level. I call it push button data communications.

In other words, supply a file name and a phone number; the computer does the
rest while you get onto other things. We've had it in Unix for a while.
Except that with Unix your system administrator has to pre-configure the
network software to be able to connect properly. With the fax based systems,
you can deal with other systems, just with a phone number. No setup required
(except that you might need tell your software whether to expect a real fax
machine at the other end, or a smart pc based fax system).



-- 
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 89 23:33:29 GMT
From:      rick@uunet.UU.NET (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: partial transfer recovery in RFC and OSI protocols

> >That is not the case.  His FTP restart scheme relies on the fact that
> >your file is eventually expressed as a stream of octets over the TCP
> >connection.  His RESTart command simply says to suppress the first N
> >octets.  It is brilliantly simple.
> 
> I think what barns was saying is while that it may be "simple" just to read
> through 100 Megabytes of a file, using a possibly CPU-intensive transformation
> to turn in into a Unix-compatible file, just to transmit the last Megabyte,
> it can't be considered friendly to non-Unix systems.  Especially systems
> that otherwise have no problem saying "move to record 200000 of that 201000
> record text file, and transmit the rest".


We all agree it's a win if you can seek to an arbitrary record, right?

Now, lets take your non-vax/non-unix system.

You start to transfer a file, and the transmition fails half way
through.  Without "my" restart method, your alternative is to read the
entire file again and transmit the entire file again. With my restart
method, you still read the file again but only transmit the new part.

The cpu time to read the file is identical in eaither case. Since it
doesnt have to spend cpu time sending the first half of the file again,
it MUST use less total time. How is that not a win? On systems that
don't have to do the transformation (i.e. the overwhelming majority)
its a HUGE win. On systems that do have to do the transformation, is a
minor win. In no case is it worse that retransmitting the entire file
(which is the alternative)

Also, note that we're talking about the official "ascii" and "image"
types. There's nothing Unix specific about this. It is specific to the
stream and image types (but then the official restart method is
specific to record mode, which is the main reason it sucks).

There are two approaches. Mine is to presume that the majority of
transfers will be done in ascii or image mode and that the majority
of transfers will succeed. Therefore, you want to make the normal
case "expensive" to restart in exchange for no overhead on normal
connections.

The other "official" approach, seems to presume that block mode is
normal (I dont even know if there are ANY implementations that support
block mode) and that failures are normal. So, you clutter up the
data stream with lots of markers, etc and make it cheap to
restart. However, you make it expensive to successfully transfer a file.

I know which approach makes more sense to me...

---rick

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 00:03:07 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful


Hmm.

Can someone explain how we could have this discussion of FAX vs E-Mail via
FAX?  What is the scenario for my having recieved all the contributions to
date and sent this message to you all?

--jon.

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 01:58:04 GMT
From:      barmar@Think.COM
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Re: Which gives best data integrity:  NFS, UUCP, or FTP?

FTP and NFS do no integrity checking of their own.  FTP is intended to be
used over a reliable byte-stream, normally TCP, which does perform
integrity checks (using a checksum by default).  NFS uses RPC, which
normally runs over UDP, which has an optional checksum (it's the sender's
option -- the receiver is required to check it if it's included).

Since UUCP is normally run over phone lines, which don't have high
integrity, it does its own integrity checks.
Barry Margolin, Thinking Machines Corp.

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

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Dec 89 10:37:21 -0500
From:      tmallory@BBN.COM
To:        Marshall Rose <mrose@cheetah.nyser.net>
Cc:        tcp-ip@nic.ddn.mil, tmallory@BBN.COM
Subject:   Re: ...brave new world of OSI and email/faxmail
Marshall,

> Back in July, NYSERNet started a White Pages Pilot Project using X.500
> over TCP/IP as the underlying technology.  At the three month mark last
> October, we hit nearly 100K entries at approximately 30 sites, about

I hope to see White Pages access on my computer soon.  This may be just the
ticket to solving one of the drawback's of electronic mail, universal
addressing.  The only reason the telephone system's universal address space
works is that there are directory services.  And as many of us are being
forced to accept, those directory services are not always cheap.

> and executables.  In addition, for each person you intend to have
> registered, the DSA will require approximately 1K of primary memory.
> (Yes, the DSA keeps entries resident in core, does its own memory management,
> etc., etc., there are obscure technical reasons for this.)  I'm the

If the 1kbyte per user of ram could be moved to disk, we might be able
to afford to support enough people...

For my two cents, I'd expect fax machines to come with other interfaces soon
enough, since there are three useful pieces to the machine (fax modem,
scanner, and printer, plus the telephone line) which could be made available
to other users in an office (or home) environment.with suitable serial and/or
LAN interfaces.

Tracy
-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 02:52:29 GMT
From:      johnl@esegue.segue.boston.ma.us (John R. Levine)
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Re: Which gives best data integrity:  NFS, UUCP, or FTP?

In article <1972@dover.sps.mot.com> cowan@spanky.sps.mot.com () writes:
>For UUCP, FTP, and NFS, in what way (if any) do each of these programs
>perform data integrity checks and data correction?

Uucp passes 128 byte packets each protected by a CRC of, I believe, 8 bits.
If a packet is bad the receiver ignores it and the sender times out and
retransmits it.  The most common place I've seen uucp lose data is that older
versions didn't notice if the disk filled up.

FTP and NFS both depend on the underlying network to do the error correction.
Ethernets and dedicated lines with the usual synchronous protocols both do
CRCs and again the strategy is to ignore the bad block and wait until it's
retransmitted.  The ignoring happens at the IP level; retransmission happens
at the virtual circuit level for TCP and is up to the application for UDP.
There are optional checksums in TCP (used by ftp) and UDP (used by nfs)
headers, but they are often turned off on the assumption that link level error
correction will be adequate.

SLIP (IP over RS-232 async) does no error detection at all, so except for
the aforementioned checksums, you're naked.
-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl
"Now, we are all jelly doughnuts."

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 03:22:23 GMT
From:      bvs@NRC.COM (Bill Versteeg)
To:        comp.protocols.tcp-ip
Subject:   inter-machine socket interface



I am in the process of designing a system where an application
living in one box (without a tcp/ip stack) needs to use a tcp/ip
stack living in another box. The connection is via a serial line.
The machine running the applications can't run a full stack, it
is not a big enough box.

I have a proprietary protocol that extends a pseudo-socket interface
into a "smart-card" card environment. This protocol assumes
a shared memory architecture. ( In other words telnet, ftp, etc live
in a xenix context, while tcp/ip live in a smart card).

Is there a standard method of running a "socket" interface over 
a light weight transport layer so that it can utilize the TCP services
of a co-operating system? I don't know of any, so I am about
to embark on a project to extend our proprietary software interface
to not require a shared memory environment. If there has been any work
done in this area, I would love to hear about it.

Otherwise, I will have to do to the socket layer interface what has been
done to IP in PPP. In fact, I believe I will use what I can of PPP.

This is a rather weird request for work done in a pretty specific
area, so rather than clutter up the net, please respond to me directly.

Bill VerSteeg
Network Research Corp.
bvs@nrc.com

-- 
Bill VerSteeg
Network Research Corporation
1000 Kristian Way			
Roswell Ga. 30076					bvs@nrc.com

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 03:57:04 GMT
From:      barns@GATEWAY.MITRE.ORG (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Re: partial transfer recovery in RFC and OSI protocols

I disagree because I don't believe that the byte number in the transfer
stream is sufficient information to determine how to join the data sent
during the restarted transfer with the data sent the first time in
every imaginable case.

There would be no problem if the bytes in the transfer stream were
literally stored in the file.  This is the case in image transfers
between 8-bit-byte machines, so Rick's method should be able to be
successfully implemented for such a case on any system type.  There is
not much problem if the bytes were stored according to some
transformation of bit sequences which can be reliably inverted.  This
is pretty much true of ASCII transfers between UNIX systems and also
many others, although I'm not so sure it is strictly true if the file
being transferred contained a "naked LF" in the part that made it the
first time.  I defer to people who know the code better than I, but I
got the impression that if a client on a non-UNIX does a STOR onto a
UNIX server of a file containing a naked LF and the session dies
somewhere after the naked LF is stored but before the end of the file,
then when the client tries to restart later, it must use the SIZE
command to get the value to be put into the REST command, and the
server cannot tell the naked LF from LF's that were created out of CR
LF sequences, so it will return a size one higher than the actual byte
count received over the data connection. (?)

Besides non-invertibility problems, I suspect the existence of
situations where the state of the receiving FTP's data transformation
state machine cannot be recreated for points in mid-file in a new
session.  With image mode I think this cannot be a problem, but for
other modes it is possible that transformations such as the end-of-line
transforms used by various systems may result in the server having
state information not represented on disk.  Probably in most cases, the
state information can be synthesized at least for some points in the
file, and if so, then fudging the answer to the SIZE command (if file
was being STORed on server) or backing up the REST value based on
scanning the local file (if it was being RETRieved to client) would
enable this method to work OK, provided you can identify some such safe
point in the partial file.

A pragmatic concern for an implementor is to understand the system's
behavior when it crashes while a file is being stored.  If the byte
count can be left out of sync with the data write, a restart might give
bad results.  If the data is always made non-volatile before the byte
count is updated, this will not be a problem.  This sounds like
something the OS "ought to do right" but they sometimes don't.  (They
can also be helped to screw up by hyper-clever disk latency
optimizations or misbegotten network file systems that handle caching
in some way that might reorder these writes.)  I know of no way to
avoid all such problems, but it is probably easier to hack around known
misbehavior with the explicit restart marker method than with implicit
markers.  For example, a server might delay sending its 110 replies by
some interval and then return the byte count in the marker.  This
knowledge would then be sitting on the client end where a server crash
could not clobber it.  For a client crash while retrieving, I suppose
that the client just has to restart at some earlier point than the
filesystem claims it needs to.  This should work equally well (badly)
with either restart scheme.  For really strong assurance of integrity,
you would probably need to run checksums over the files at both ends.

I hope no one will construe this discussion as some sort of "disproof"
of Rick Adams's approach; it isn't one.  It's meant to be an
illustration that the method in the RFCs has relative advantages in
some situations, as Rick's has in many others.  Neither one seems to be
perfect or dominant in every way; either we haven't gotten smart enough
yet to do that, or the problem has no such solution.

/Bill Barns

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 04:19:24 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: partial transfer recovery in RFC and OSI protocols

In article <74106@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes:

   Also, note that we're talking about the official "ascii" and "image"
   types. There's nothing Unix specific about this. It is specific to the
   stream and image types (but then the official restart method is
   specific to record mode, which is the main reason it sucks).

As I disagreed with Barns, now I must disagree with Adams.  Yes, the official
restart method *does* require record mode.  But there is no reason why a
Unix file cannot be considered to have N records of 1024 (say) bytes plus
a trailing record of M bytes.

   The other "official" approach, seems to presume that block mode is
   normal (I dont even know if there are ANY implementations that support
   block mode) and that failures are normal. So, you clutter up the
   data stream with lots of markers, etc and make it cheap to
   restart. However, you make it expensive to successfully transfer a file.

You don't seem to recall that I implemented block mode and RESTart in
KA9Q's TCP/IP package.  I also put it into a local copy of the BSD
Tahoe FTP server.  That aside, I do agree that there is a tradeoff
between sending restart markers in block mode and sending a file in
stream mode.  If the block size is made large enough, then the
tradeoff is minimized.

Late breaking news (just got mail from Bill Barns): He points out that
explicit markers (as per the RFC) may be more reliable than implicit
markers (as per Adams) when your transfer failed.

What I did to implement RESTart was to implement block mode (as required).
Then, when a file was retrieved in block mode, I would store the markers
in a specially-named file.  So if you were fetching foo.bar, I would store
the markers in foo.$$$.  Whenever I received a marker, I would fflush()
the data file and the marker file.  In addition to keeping the markers,
I would also keep the position of the data file at the time of receipt.

Then, if the transfer succeeded, I would delete the marker file.  
If they restarted the transfer, I would check for an existing marker file,
and automagically issue a FTP RESTart with the latest marker in the file.
The wisdom of doing this automagically is not clear.  It *did*, however,
work.

   I know which approach makes more sense to me...

On one hand your technique, while sound, is interoperable only with
itself.  On the other hand, there are very few implementations of the
"interoperable" version.  If it hasn't been widely implemented, it
doesn't really matter whether the protocol is well designed or not.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
Live up to the light thou hast, and more will be granted thee.
A recession now appears more than 2 years away -- John D. Mathon, 4 Oct 1989.
I think killing is value-neutral in and of itself. -- Gary Strand, 8 Nov 1989.
Liberals run this country, by and large. -- Clayton Cramer, 20 Nov 1989.
Shut up and mind your Canadian business, you meddlesome foreigner. -- TK, 23 N.

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 04:37:58 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Anonymous FTP

If your system allows anonymous FTP, then it should map an unknown userid
into the one used for anonymous FTP.  The effect of this is that users
who cannot spell anonymoose still get logged in as anonymous.

Perhaps this idea is obvious to everyone else, and they discarded it
for one reason or another.  It wasn't obvious to me, and I thought it
was a good idea.  So I hacked it into KA9Q's NOS and it's running on
grape.ecs.clarkson.edu.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
Live up to the light thou hast, and more will be granted thee.
A recession now appears more than 2 years away -- John D. Mathon, 4 Oct 1989.
I think killing is value-neutral in and of itself. -- Gary Strand, 8 Nov 1989.
Liberals run this country, by and large. -- Clayton Cramer, 20 Nov 1989.
Shut up and mind your Canadian business, you meddlesome foreigner. -- TK, 23 N.

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 05:21:00 GMT
From:      CALIFFM@BAYLOR.BITNET (Michael Califf)
To:        comp.protocols.tcp-ip
Subject:   Re: Unauthorized access via terminal servers

Barry -

We (Baylor University) have been wrestling with this same
problem.  We are currently solving it by piping all of our
modem-to-network connections through our data PBX.  The PBX
allows us to restrict connections from dial-in modems by
enforcing a username/password/access list check on an
attached machine as part of the logon.  The network-to-
modem connections are also piped through the PBX.

We use the terminal server's security software to restrict
the IP addresses allowed to make a connection into the server
(we have to worry about people making long-distance calls
as well, to make sure auth-codes don't get "borrowed".)

Mike Califf                    (POSTMAST[ER])
Communications Software Coord  Internet: CALIFFM@BAYLOR.EDU
Baylor University C.C.I.S.     Bitnet:   CALIFFM@BAYLOR
B.U. Box 7268                  THEnet:   BAYLOR::CALIFFM
Waco, TX 76798-7268            Phone:    (817) 755-2711

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 06:13:11 GMT
From:      koreth@panarthea.ebay.sun.com (Steven Grimm)
To:        comp.protocols.tcp-ip
Subject:   Re: Building a reliable datagram protocol on top of UDP

In article <1486@wacsvax.OZ> jamesp@wacsvax.uwa.oz.OZ (James Pinakis) writes:
>Would I be better off sticking with tcp-ip and
>accepting a limit to the number of client processes?

Here's a little trick you can use to increase that limit to a fairly
outrageous value.  This does increase your server's complexity,
possibly by a great deal depending on exactly what you're doing.  (This
is BSD UNIX-oriented.)

Figure out how many open file descriptors your process can have.  The
getdtablesize() call should do it.  Serve as usual until you hit the
limit.  Then fork.  If you like, make a pipe or socket connection
between the parent and child process (this may be necessary for your
application.) Then close the listen()ing file descriptor in the parent
process; in the child, close all the connected descriptors.  The child
will now accept new connections.

If everyone disconnects from a parent process, it should die as it's no
longer needed.  If everyone disconnects from a process in the middle of
a chain, that process needs to stick around as UNIX provides no way to
stick two pipes/sockets together.

Hope that helps.  It may be more trouble than it's worth for your
application, but it's a worthwhile method for some things.

---
"                                                  !" - Marcel Marceau
Steven Grimm		Moderator, comp.{sources,binaries}.atari.st
koreth@ebay.sun.com	...!sun!ebay!koreth

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 07:01:46 GMT
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   re: Networks considered harmful

Something I like about email is that I can email a request to SRI-NIC
and find out WHOIS information and also retrieve RFC's that way. I
can't currently do this with FAX.

I agree that the general user interfaces to email need a LOT of work
to be made more usable. This is generally true about TCP/IP-based
applications, though.
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@ftp.com
		    WAKE UP AND SMELL THE BUDDHA!

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 07:02:18 GMT
From:      jtk@lakesys.lakesys.com (Joe Klein)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

In article <22979.630044353@cheetah.nyser.net> tcp-ip@nic.ddn.mil writes:
>What is great about FAX is really simple:
>
>Reason 1:	FAX is turn-key in every aspect: any office person can
>		install and use a fax machine without any serious training.
 ...
>Reason 2:	FAX uses an already existing, global infrastructure.
 ...
>Summary:	FAX is a wonderful example of an 80-year old technology that
>		is technically indefensible but has the world's best
>		user interface: no training needed.
 ...
>Having said all that, how can e-mail start competing?  Well, marketing
>is a small part, but it's a second-order thing.  We need: a global,
>e-mail infrastructure that is as ubiquitous as dial tone.  To do this,
>we need to patch together all of the existing e-mail systems, make the
>gatewaying transparent, adopt a global addressing scheme, and then start
>making the technology accessible and usable by ordinary people who had
>normal childhoods.
>
>/mtr

A freely distributed e-mail interface with a nice GUI would help. Perhaps
ELM with a PM/Motif interface. It would be nice to draft a standard for
encapsulating FAX bitmaps as well as other graphic formats. A freeware
conversion of e-mail to FAX would be nice.

Proposed e-mail fixes.

	1. FAX <=> e-mail gateways.

	2. Develop a global addressing scheme.

	3. Develop a simple user interface.

	4. Intergrate graphics, (voice?, vidio???) etc.

Can't be that hard.

-- 
 jtk@lakesys.lakesys.com               : "I'm not a nun,
 Joseph T. Klein                       :  we all know that."
 "No mom, that's UNIX not eunichs.     :                - Cher

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 07:13:00 GMT
From:      sl@van-bc.UUCP (Stuart Lynne)
To:        comp.protocols.tcp-ip,comp.org.usenix
Subject:   Re: Networks considered harmful/Re: USENIX board studies UUCP

In article <7375@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>In article <8912200236.AA25652@ucbvax.Berkeley.EDU> cire@CISCO.COM (cire|eric) writes:
>> Yes Computer based telecommunications has a great deal of more utility
>> than FAX but I don't think that is the point.  You must first make the
>> connection before all that starts making a difference.
>
>OK. Let's do it. What should the communications look like? UUCP? Dial-up
>SLIP? Or something more like FIDO? All we need to do is agree on a
>standard and then we can start saying:
>
>	mail 7134385018!peter
>Or:
>	mail peter@7134385018.PHONE
>
>And folks with home PCs can do the same. Just make it simple enough that
>any bozo with a copy of PCTalk can hack it up.
>
>Chat scripts for UUCP, and baud rates, are the biggest problem.
>
>How about this:
>
>To start up the session, you need to send the string "email<CR>". This should
>handle the login problems. You keep sending this string with a 1 second
>delay until you get a protocol startup... so you'd make your email login
>"email" with password (if any) "email". A PC could just start straight up
>with the protocol.

A couple of suggestions.

First anything you do shouldn't disenfranchise the existing successful base
that is using fax technology. Your new protocol should be able to send "email" 
to a fax machine and receive and print a fax from a fax machine. 

Let's face it at this point in time you'll be able to send email to more 
destinations by simply doing this than anything else.

Of course this implies that you'll need a V.29 modem and be able to support
the T.30 protocols. This also simplifies to a certain extent what you do when
your machine calls another or you answer the phone because the current
specifications are pretty explicit. So what you do is work within the
current standards committee's to make suggestions as to how these protocols
can be extended to support sending/receiving messages/files. 

The end result is a pretty simple to use communications medium that will
probably be quite successful because it leverages off of the current
installed base of fax machines instead of competing against it.

There are a couple of other interesting side effects. The cost of building
V.29 modems is coming down. I've seen reports of $195 9600 bps fax modems.
Definitely competitive with a 2400 Hayes compatible. A reasonable FTP using
a 9600 bps fax modem can achieve something over 700cps throughput (wall 
clock timing on a file I watched being transferred). 

The current fax specifications have given us an specific way to place calls;
synchronize with the far end; decide what type of operations will take
place; at what speed; and can be extended for a wide range of other options.

Other extensions could include higher signalling speeds, switching to a
bi-directional 1200/2400 signalling mode for interactive use, etc.

-- 
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 07:42:43 GMT
From:      LARSON@CRVAX.SRI.COM (Alan Larson)
To:        comp.protocols.tcp-ip
Subject:   Re: Anonymous FTP

--> If your system allows anonymous FTP, then it should map an unknown userid
--> into the one used for anonymous FTP.  The effect of this is that users
--> who cannot spell anonymoose still get logged in as anonymous.
--> 
--> Perhaps this idea is obvious to everyone else, and they discarded it
--> for one reason or another.  It wasn't obvious to me, and I thought it
--> was a good idea.  So I hacked it into KA9Q's NOS and it's running on
--> grape.ecs.clarkson.edu.

  This has the problem that it will map errors in logins to other
accounts to anonymous.    Why should we map 'larfson' into 'anonymous'
when I mistype my name while logging in?  I will wind up with successful
status, but will not be connected to where I thought I was.

  The curmudgeon in me suggests:  Why don't we just request that people
learn to spell, or has that gone out of favor since I went to school?

	Alan
-------

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 10:35:40 GMT
From:      reggie@dinsdale.nm.paradyne.com (George W. Leach)
To:        comp.protocols.tcp-ip,comp.org.usenix
Subject:   Re: Networks considered harmful/Re: USENIX board studies UUCP

In article <106@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes:

>A couple of suggestions.
 
>First anything you do shouldn't disenfranchise the existing successful base
>that is using fax technology. Your new protocol should be able to send "email" 
>to a fax machine and receive and print a fax from a fax machine. 

   I believe ATTMAIL provides this capability, and more.....  I have heard
that you will be able to broadcast a FAX message via a store and forward
from ATTMAIL in the future (if not now).


George W. Leach					AT&T Paradyne 
(uunet|att)!pdn!reggie				Mail stop LG-133
Phone: 1-813-530-2376				P.O. Box 2826
FAX: 1-813-530-8224				Largo, FL 34649-2826 USA

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 11:21:23 GMT
From:      micky@cunixc.cc.columbia.edu (Micky Liu)
To:        comp.protocols.tcp-ip
Subject:   My tcpdump X'mas Present

Since I seem to be receiving a lot of Dear Santa letters lately for my
diff set for tcpdump, I am making it available for anonymous ftp from
cs.columbia.edu in pub/m-liu/tcpdump3.5-4.0.diffs.  It is a small
plain text file with some important notes at the top of the file.  I
apologize to all of you who sent me mail regarding the diff set that I
did not respond to, I thought this would be an easier distribution
method for me.

Some more notes before we get inundated with more questions.  The
original sources are available from ftp.ee.lbl.gov.  As provided by
the great crew at LBL, it will run on Sun-3's running SunOS3.5.  The
diff set I created when applied to the original sources will allow it
to run on Sun-3's running SunOS4.0.x.  Now for the standard questions:

Can you mail me a diff set?

     No, I am sorry I don't have the resources (time) to do this
     anymore.  Please make alternate arrangements.

Can tcpdump run on Sun-4's?

     Not this version.  There will be a version coming out from LBL
     with my diffs merged that will support sparcs, but I do not know
     a release date.  Por favor, no se moleste.  I am sure they will
     release when they see fit...

Why is tcpdump reporting duplicate ethernet packets?

     Your kernel is broke.  There is/was a bug in the nit_if.o object
     that can be fixed by obtaining a new nit_if.o from ftp.ee.lbl.gov
     and rebuilding your kernel.  I do not know the bug number, nor do
     I know if it is corrected in 4.0.3, but you can tell if it does
     because the bug manifests itself by making all ethernet packets
     in each 'chunk' indentical.


Well that's my x'mas present to you all.  Wish you all the best this
holiday season!

Micky

internet: micky@cunixc.cc.columbia.edu
  usenet: ...!rutgers!columbia!cunixc!micky
  bitnet: micky@cunixc.bitnet

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 11:31:14 GMT
From:      a20@nikhefh.nikhef.nl (Marten Terpstra)
To:        comp.protocols.tcp-ip
Subject:   Re: Anonymous FTP

In article <NELSON.89Dec20233752@image.clarkson.edu> nelson@clutx.clarkson.edu writes:
>If your system allows anonymous FTP, then it should map an unknown userid
>into the one used for anonymous FTP.  The effect of this is that users
>who cannot spell anonymoose still get logged in as anonymous.
>

As you may know most FTP servers also accept userid ftp as the anonymous
userid. Since ftp isn't to hard to spell, this solves your problem.

__
Marten Terpstra                                  National Institute for Nuclear
Internet : terpstra@nikhef.nl 		                and High Energy Physics
Oldie-net: {....}mcsun!nikhefh!terpstra	      (NIKHEF-H), PO Box 41882, 1009 DB
Bitnet   : terpstra%nikhef.nl@hasara5.bitnet         Amsterdam, The Netherlands

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 11:40:08 GMT
From:      HANK@BARILVM.BITNET (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Looking for public domain IP router code

I remember seeing a posting here about a year ago about someone who wrote
code for an IBM PC to convert it to an IP router.  Can anyone point me in
the direction of the person who wrote the code?  Is there any other place
where one can find public domain IP router code?

As a side request, does anyone have public domain IP router code that
conforms to the OSF standard (also known as the OSPF standard by ANSI X3S3.3)
for routers?

Many thanks,
Hank

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 12:13:46 GMT
From:      D32107@FRCCSC21.BITNET ("pansiot")
To:        comp.protocols.tcp-ip
Subject:   window size for sun

Hi
   I wonder if there is a way to change the window size for TCP
   used by Sun.
More specifically, I have to send files between two machines
located on different Ethernets. These twio LAN's are connected by a slow
(9600 bps) X25 line, and GS1 gateways from Bridge .
When ftp  sends a full window (more than 20K), the gateway drops most
of the packets.
Anything I can do to lower the window users by Sun's ftp ?
Thanks in advance

Jean-Jacques Pansiot
Departement d'Informatique, Universite Louis Pasteur
Strasbourg , France
E-mail:  D32107@FRCCSC21.bitnet

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 12:54:55 GMT
From:      steve@CISE.CISE.NSF.GOV (Stephen Wolff)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

>         Why have a separate voice network? Why have Fax-over-phone-lines?
> Why NOT have a single large-scale, (very) high-bandwidth network that can
> handle any kind of data you want with universal addressability?

We're woikin' on it.

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 13:34:33 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.protocols.tcp-ip,comp.org.usenix,alt.fax
Subject:   Re: Networks considered harmful/Re: USENIX board studies UUCP

>> cire@CISCO.COM (cire|eric) writes:
>> Yes Computer based telecommunications has a great deal of more utility
>> than FAX but I don't think that is the point.  You must first make the
>> connection before all that starts making a difference.

fyi:  commercial products which support email2fax are beginning to 
appear on the market.  examples:  the Bristol Group's product for 
Sun workstations, PC Research FaxIX (with a shell script or two).

followups to alt.fax.


	
	
-- 

{ Steve Elias ; eli@spdcc.com ; 6179325598 ; 5086717556 ; }
/* C */     { *disclaimer(); } 
/* not C */ { z = disclaimer(y) : (y = lim [x-->0] ( 1/x ) ) }

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 14:35:33 GMT
From:      kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.protocols.ibm,comp.protocols.pcnet,comp.binaries.ibm.pc.d,comp.sys.ibm.pc,alt.msdos.programmer
Subject:   interrogative tcp-ip on arcnet

-- 
[Flame off, please, about the hardware choice. We _had_ to go with absolute- 
lowest-cost-per-_permissible_-suppliers.] 
-- 
We are setting up a few engineers' PClones on an ARCNET LAN, specifically 
Datapoint Corp's. DATALAN. 
-- 
The first question is, "Where can we get IP, TCP, et.al. to run over ARCNET?" 
-- 
And the second question is, "How can we use one of the boxes with a 9600 bps 
link to a UNIX/VAX with SLIP and router software to get access to the rest 
of the systems here at our center?" 
-- 
We think we would like to have a _packet_driver_ for our ARCNET cards (the 
Performance Technology card sold by Datapoint as the ARCNET RIM-1.) 
-- 
We think we could use PCIP on top of the packet driver. 
-- 
We think PCROUTE or PCBRIDGE would handle the cross-connect. 
-- 
Can we also get a _packet_driver_ SLIP? 
-- 
What about KA9Q? It seems that it might work. Maybe we could get Phil 
Karns' permission to use it. Yes, we _are_ a commercial organization, but 
our corporate management is so thoroughly brain-dead that they think 
"personal computers" (and even shared UNIX systems) are just something 
to be sold to a bunch of gullible customers, and not actual possibly useful 
tools. 
-- 
All comments and suggestions gratefully accepted! 
--------------------- 
thanx and regardz, 
Ken 

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 14:36:11 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Anonymous FTP

In article <630229363.780000.LARSON@CRVAX.SRI.COM> LARSON@CRVAX.SRI.COM (Alan Larson) writes:

   --> If your system allows anonymous FTP, then it should map an
   --> unknown userid into the one used for anonymous FTP.  The effect
   --> of this is that users who cannot spell anonymoose still get
   --> logged in as anonymous.
   --> 
   --> Perhaps this idea is obvious to everyone else, and they discarded it
   --> for one reason or another.  It wasn't obvious to me, and I thought it
   --> was a good idea.  So I hacked it into KA9Q's NOS and it's running on
   --> grape.ecs.clarkson.edu.

     This has the problem that it will map errors in logins to other
   accounts to anonymous.    Why should we map 'larfson' into 'anonymous'
   when I mistype my name while logging in?  I will wind up with successful
   status, but will not be connected to where I thought I was.
This is a reasonable objection.  I think it could be solved by requesting
the password saying something like: "Userid foobar not recognized, mapping
it to anonymous".

     The curmudgeon in me suggests:  Why don't we just request that people
   learn to spell, or has that gone out of favor since I went to school?

I implemented this because my boss told me to make anonymous ftp as
easy as possible.  He says: "I want people who know nothing about ftp
to be able to get on with no other instructions than 'ftp to
grape.ecs.clarkson.edu'".

Whatever happened to the dictum "be liberal in what you accept, conservative
in what you generate"?
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
Live up to the light thou hast, and more will be granted thee.
A recession now appears more than 2 years away -- John D. Mathon, 4 Oct 1989.
I think killing is value-neutral in and of itself. -- Gary Strand, 8 Nov 1989.
Liberals run this country, by and large. -- Clayton Cramer, 20 Nov 1989.
Shut up and mind your Canadian business, you meddlesome foreigner. -- TK, 23 N.

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 15:37:21 GMT
From:      tmallory@BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: ...brave new world of OSI and email/faxmail

Marshall,

> Back in July, NYSERNet started a White Pages Pilot Project using X.500
> over TCP/IP as the underlying technology.  At the three month mark last
> October, we hit nearly 100K entries at approximately 30 sites, about

I hope to see White Pages access on my computer soon.  This may be just the
ticket to solving one of the drawback's of electronic mail, universal
addressing.  The only reason the telephone system's universal address space
works is that there are directory services.  And as many of us are being
forced to accept, those directory services are not always cheap.

> and executables.  In addition, for each person you intend to have
> registered, the DSA will require approximately 1K of primary memory.
> (Yes, the DSA keeps entries resident in core, does its own memory management,
> etc., etc., there are obscure technical reasons for this.)  I'm the

If the 1kbyte per user of ram could be moved to disk, we might be able
to afford to support enough people...

For my two cents, I'd expect fax machines to come with other interfaces soon
enough, since there are three useful pieces to the machine (fax modem,
scanner, and printer, plus the telephone line) which could be made available
to other users in an office (or home) environment.with suitable serial and/or
LAN interfaces.

Tracy

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 15:54:50 GMT
From:      amf@bpe2.spix7.depr.bull.fr ( Anne-Marie FOUREL )
To:        comp.protocols.tcp-ip
Subject:   wanted : TLI interface with socket library


I will soon have to port applications using the TLI interface, but
our unix only has the socket interface for TCP/IP.

I'd like to know  :

1) if anybody has already met the problem and how it has been solved.

2) if anybody has written a version for TLI based on sockets.

Thanks for all hints !

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 16:37:17 GMT
From:      manoj@excelan.COM (manoj @ Prod Mktg)
To:        news.announce.newgroups,news.groups,comp.protocols.ibm,comp.protocols.nfs,comp.protocols.iso,comp.protocols.tcp-ip,comp.unix,comp.dcom.lans,comp.os.os2,comp.protocols.tcp-ip.ibmpc,comp.unix.xenix
Subject:   CALL FOR DISCUSSION ' comp.sys.netware'


			###################
                        CALL FOR DISCUSSION
			###################

		###################################
			comp.sys.netware
		###################################

Why add a new group? 

	A forum to discuss technical and non-technical issues specific to 
the Novell's Netware family of Local Area and Wide Area Networking products.  
These include Netware286, Netware386, Portable Netware, Communication products,
Database products, Excelan LAN WorkPlace family (TCP/IP) etc. etc.

	 The creation of this forum will allow the Novell Netware enthusiasts 
at USENET their own forum to discuss items of a non-technical nature 
(how to use software packages, what networking card to buy, etc) 
and items of a technical nature (what's wrong with this code?, how do I use 
this toolkit call?, etc.), thus reducing the amount of time spent sorting 
through multiple groups on protocols, lans, ibmpc, tcp-ip.

THIS IS NOT A CALL FOR VOTES; please do not send votes.  Usenet
newsgroup creation guidelines do not allow premature votes to be
counted.  A call for votes will be posted in Jan 1990, unless major issues 
remain unresolved through those dates.  Issues to be resolved are:

  o What, if any, type of group to create.  
  o What to call this group: 		   comp.sys.netware 
  o Whether the group should be moderated: NO.
  o The group's charter: 		   see above, please discuss revisions.

Followups are directed to news.groups.  Please include news.groups in
all related discussion; please minimize cross-postings to the lan, protocols,
tcp-ip, ibmpc, nfs related groups..

Netware readers interested in this discussion should follow news.groups for 
the next 2-4 weeks. 

Regards!
+-----------------------------------------------------------------------------+
|manoj goel         |Disclaimer: the ideas are mine and not my employer's..   |
|NOVELL Inc.,       |Internet:	manoj@excelan.com 		              |
|2180 Fortune Drive,|UUCP: {ames,sun,apple,amdahl,cae780}!excelan!manoj       |
|San Jose, CA 95131 |voice: 408.473.8369       fax: 408.433.0775              |
+-------------------+---------------------------------------------------------+

	                                 		+---+
	manoj goel,                                  	| +-+-+
	Product Marketing              			+-+-+ |
        Excelan/Novell, San Jose, CA 		 	  +---+
	(408) 473-8369 (voice) / 433-0775 (fax)	
___________________________________________________________________________
		When all else fails, read the instructions!

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 16:48:13 GMT
From:      simpson@SATURN.IND.TRW.COM (Scott Simpson)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

Anybody who has the X distribution can play with multimedia mail.
Try compiling the Andrew Toolkit.  It has multiple fonts, graphics and 
animation.  I don't know if it can handle bit maps.  This has one advantage
over fax: it understands the structure of the document.
-- 
Scott Simpson    TRW Information Networks Division    simpson@trwind.trw.com

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Dec 89 13:40:08 O
From:      Hank Nussbacher <HANK%BARILVM.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.ARPA
Subject:   Looking for public domain IP router code
I remember seeing a posting here about a year ago about someone who wrote
code for an IBM PC to convert it to an IP router.  Can anyone point me in
the direction of the person who wrote the code?  Is there any other place
where one can find public domain IP router code?

As a side request, does anyone have public domain IP router code that
conforms to the OSF standard (also known as the OSPF standard by ANSI X3S3.3)
for routers?

Many thanks,
Hank
-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 17:20:58 GMT
From:      sean@dranet.dra.com
To:        comp.protocols.tcp-ip
Subject:   re: Networks considered harmful

In article <8912202301.AA05357@asylum.sf.ca.us>, romkey@asylum.sf.ca.us (John Romkey) writes:
> Something I like about email is that I can email a request to SRI-NIC
> and find out WHOIS information and also retrieve RFC's that way. I
> can't currently do this with FAX.

Several companies are now selling "FAX-servers."  The most common work
by you calling a number, select the information and it is FAXed to you.
The technology is similar to the Dial-A-Tape services (Heck, even the
IRS has been using that for a couple of years).  The "inexpensive" ones
are a PC, FAX modem, and Voice/DTMF module.

Maybe SRI-NIC should start providing this service as a way for the
rest of us to get a hold of those dang Postscript RFC's :-).

-- 
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
Domain: sean@dranet.dra.com, Voice: (Work) +1 314-432-1100

  Affiliation given for purposes of identification, not representation

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 17:42:56 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip,comp.org.usenix
Subject:   Re: Networks considered harmful/Re: USENIX board studies UUCP

In article <106@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes:
> First anything you do shouldn't disenfranchise the existing successful base
> that is using fax technology. Your new protocol should be able to send
> "email" to a fax machine and receive and print a fax from a fax machine. 

I disagree. The main consideration should be to avoid disenfranchising the
people currently using existing email systems. This should be something
that someone with a PC and a $100 modem can hook into. This isn't intended
to be an enhancement to FAX, but an enhancement to email: UUCP, SMTP,
MCI-Mail, Compuserve, and so on.

> Of course this implies that you'll need a V.29 modem and be able to support
> the T.30 protocols.

Which is why it's pretty much out of the question. These are relatively
expensive modems and definitely complex protocols. This is out of reach
of the majority of people who currently use email: individual computer
hobbyists with PCs.

And the end product can be built a LOT cheaper. An IBM-PC clone with a
1200 baud internal modem is in the few hundred dollar range. And then
there are all the people with Commodore-64s. You're talking a complete
system that costs less than a FAX modem alone.
-- 
`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
 'U`  Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>.
"It was just dumb luck that Unix managed to break through the Stupidity Barrier
and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 18:16:37 GMT
From:      art@salt.acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: inter-machine socket interface

In article <444@nrcvax.NRC.COM> bvs@nrc.COM (Bill Versteeg) writes:
>
>
>I am in the process of designing a system where an application
>living in one box (without a tcp/ip stack) needs to use a tcp/ip
>stack living in another box. The connection is via a serial line.
>The machine running the applications can't run a full stack, it
>is not a big enough box.

It's big enough to run applications but not big enough to implement
TCP/IP?

>I have a proprietary protocol that extends a pseudo-socket interface
>into a "smart-card" card environment. This protocol assumes
>a shared memory architecture. ( In other words telnet, ftp, etc live
>in a xenix context, while tcp/ip live in a smart card).
>
>Is there a standard method of running a "socket" interface over 
>a light weight transport layer so that it can utilize the TCP services
>of a co-operating system? I don't know of any, so I am about
>to embark on a project to extend our proprietary software interface
>to not require a shared memory environment. If there has been any work
>done in this area, I would love to hear about it.

This enters into the realm historically know as "Host to Front End Protocols".
In my opinion (and shared by other I have talked to) that for TCP you
get into a case of diminishing returns.  Often you get into the situation
of implementing a protocol nearly as complex as the one being offloaded.
In your case, if the serial link has any loss/corruption characteristics,
your have to implement error detection and recovery.  If you need to have
multiple sessions running at the same time, you have to implement multiplexing.
If the sessions need to be dynamically established, you need to implement
connection control.  Also, don't forget about flow control and possibly
asynchronous event notification.  This all adds up to something approaching
TCP in complexity.

>Otherwise, I will have to do to the socket layer interface what has been
>done to IP in PPP. In fact, I believe I will use what I can of PPP.
>
>This is a rather weird request for work done in a pretty specific
>area, so rather than clutter up the net, please respond to me directly.

I think the issues of offloading TCP are of more general interest, so
I'm posting to the list.

>Bill VerSteeg
>Network Research Corp.
>bvs@nrc.com
>
>-- 
>Bill VerSteeg
>Network Research Corporation
>1000 Kristian Way			
>Roswell Ga. 30076					bvs@nrc.com


--
+	Art Berggreen		Advanced Computer Communications	+
|	<art@salt.acc.com>	Santa Barbara Street			|
+	(805)963-9431		Santa Barbara, CA 93101			+

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 18:18:00 GMT
From:      ljm@TWG.COM (Leo J McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   NetBIOS over TCP/IP


There appears to be a difficulty in NetBIOS over TCP/IP's handling
of simultaneous, duplicate name registration requests.  If two nodes
each ask for the same name at roughly the same time (for example if
they are both coming up from the same power failure) both nodes will
believe they own the name.

This expected behaviour results from the stipulation in section 5.1.1.1
of RFC 1002, B-NODE ADD NAME, that names are not added to the local table
until after the NAME REGISTRATION REQUESTS and NAME UPDATE REQUEST are sent
and RFC 1002 section 5.1.1.5, B-NODE INCOMING PACKET PROCESSING, which
requires that incoming NAME REGISTRATION REQUESTS be ignored until the name
is added to the local name table.  Furthermore, section 5.1.1.5 states that
incoming NAME UPDATE REQUESTS have no effect other than to update the
optional IP address cache.

This issue is further clouded by a confusion within RFCs 1001 and 1002
about the name of this final name registration packet.  Section 15.2.1
of RFC 1001, NAME REGISTRATION BY B NODES, shows a NAME OVERWRITE DEMAND
rather than a NAME UPDATE REQUEST and Section 4.2 of RFC 1002, NAME SERVICE
PACKETS, describes the existance of a NAME OVERWRITE DEMAND packet but no
NAME UPDATE REQUEST packet, however, section 5.1.1 of RFC 1002, B-NODE
ACTIVITY, the actual NetBIOS over TCP/IP B-node protocol specification,
never mentions NAME OVERWRITE DEMANDS just NAME UPDATE REQUESTS.

Note that the MAP/TOP NetBIOS over OSI specification avoids this difficulty
by defining a 'being registered state' during which the name is defended
from other name registration requests but doesn't answer to name query
requests.

If any implementors of NetBIOS over TCP/IP have dealt with this issue
I would be interested in knowing if they came to the same conclusion about
the NetBIOS specification and if they decided to implement name resolution
as per RFC or if they fixed the problem.

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 18:24:04 GMT
From:      art@salt.acc.com (Art Berggreen)
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Re: Which gives best data integrity:  NFS, UUCP, or FTP?

In article <1989Dec21.025229.2837@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes:
>There are optional checksums in TCP (used by ftp) and UDP (used by nfs)
>headers, but they are often turned off on the assumption that link level error
>correction will be adequate.

NO! Only UDP checksums are optional (a dubious option at that), TCP checksums
are ALWAYS required.

--
+	Art Berggreen		Advanced Computer Communications	+
|	<art@salt.acc.com>	Santa Barbara Street			|
+	(805)963-9431		Santa Barbara, CA 93101			+

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 18:39:44 GMT
From:      donp@na.excelan.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Anonymous FTP

>I implemented this because my boss told me to make anonymous ftp as
>easy as possible.  He says: "I want people who know nothing about ftp
>to be able to get on with no other instructions than 'ftp to
>grape.ecs.clarkson.edu'".

Actually, there's nothing in FTP that requires any login at all.  The
first FTP server i had to deal with would do an implicit "anonymous"
login when needed if no "USER" command was given.  I've never quite
figured out why the famous "anonymous" login was adopted but the much
simpler implicit login is never implemented.

>Whatever happened to the dictum "be liberal in what you accept, conservative
>in what you generate"?

This dictum applies to protocol implementations, not user interfaces.
A misbehaving peer will probably continue to misbehave indefinitely.
A mistaken user is capable of correcting her mistakes.

						don provan
						donp@excelan.com

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 18:39:48 GMT
From:      hnt@altger.uucp (Michael Hentrich)
To:        comp.protocols.tcp-ip
Subject:   BIND Named Service Problems  Need Help

Hi all out there,

We're trying to use the 'named' on SVr3.1
We do have the Lachman Implemtation of TCP/IP over Streams...

The named looks like running fine, it get's all informations
and normally works fine, BUT
sometimes without any reason it blocks, that means if
you 're tryin a netstat on another system it answers(according to the
logfile) but the program hangs...
If I send a signal to the named on the domain server it works
fine again (for a time :(((( )

Does anyone know this problem??

By the way, if I look at the 'syslog' stimes I find recvfrom (interrupted system call )

I hope, that s.o. knows the problem....
-- 
Michael Hentrich c/o Altos Computer Systems GmbH Wuermstr.55
	D-8032 Graefelfing/Munich Western Germany Voice:+49898548440 
E-Mail: hnt%altger.altos.com bang:..!uunet!mcvax!unido!altger!hnt
-------------------------------------------------------------------------------

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 18:44:19 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

Hmmm, indeed.

It must be that "FAX" is so much better than "e-mail" that they don't need
to discuss its superiority.

Actually, when it comes to Content, instead of Form (on which I think the
commercial success of FAX is largely based), there does seem to be _one_
advantage to the inherently limited, point-to-point medium: at least you have
to write things down before Faxification, and when you do a first draft you
sometimes notice that a second draft is called for.  Netmail, as I've
been saying for years and years (see RFCs with even lower numbers than
Jack Haverty's), does tend to make shooting from the metaphorical hip
rather too easy, on the other metaphorical hand.

    cheers, map
-------

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 19:03:28 GMT
From:      "Mitchell_B._Erblich.ESAE"@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   computerfax (was Re: Networks considered harmful)

Steve Elias,
the US post office is currently offering fax service at
	some northeast post offices.  they rent space to a company	
	which put together "fax kiosks" designed for public use.

	(has anyone seen one of these beasties, yet?)
YEP,
	I used one in South Florida, in Plantation near Ft. Lauderdale.

Mitch  

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 20:31:15 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: FAXes vs. EMAIL

> Granted, there are more complicated FAX machines out there, but the simple,
> CHEAP ones are going to go to technophobes.  How much would a PC setup cost?

Oh, well under $500. If we can get a reasonable standard off the ground,
probably under $100. It's much simpler technology. You could probably do it
with a Commodore-64 for that price now.

> More importantly, how simple would it be to explain how to use it JUST FOR
> EMAIL?

Again, once the software and standard is there (a SMOP):

	"Turn the machine on. After a little while it will display the
	 main screen. You can hit 'R' to read messages, 'W' to write
	 messages, and 'S' to send mail. The computer will also answer
	 the phone and accept messages in this mode.

	"If you hit R, the subject lines of waiting messages will be
	 displayed, whether they're to or from you, and for messages from
	 you whether they have been delivered yet... you can display these
	 messages, print them, or discard them.

	"If you hit W, you will be prompted for the phone number to
	 send the message to, the name of the person to receive it,
	 and a subject line (a short comment as to what the message is
	 about, such as "Christmas card".

	"If you hit S, EMAIL will attempt to send any messages waiting
	 to go out."

After the protocol is worked out (see other messages on the subject),
this should be pretty simple.
-- 
`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
 'U`  Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>.
"It was just dumb luck that Unix managed to break through the Stupidity Barrier
and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 89 21:43:41 GMT
From:      mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: Anonymous FTP

In article <909@excelan.COM> donp@na.excelan.com (don provan) writes:
>Actually, there's nothing in FTP that requires any login at all.  The
>first FTP server i had to deal with would do an implicit "anonymous"
>login when needed if no "USER" command was given.

Ah, fond memories of ITS!  Actually, that winning feature was also put
in the good version of Tenex/TOPS-20 NCP-based FTP server, but it
never made it into the TCP FTP server.

>I've never quiteb
>figured out why the famous "anonymous" login was adopted but the much
>simpler implicit login is never implemented.

I think it's history.  On Tenex (the first OS that had ANONYMOUS
login), the server did a real LOGIN system call.  To do this, there
had to be such a login directory as <ANONYMOUS>, and the FTP server
had to be able to discover <ANONYMOUS>'s password (never mind if don't
know how this was done; you probably shouldn't know!).  If these
weren't true, then no ANONYMOUS login was possible.

The Tenex (and later TOPS-20) FTP server did no file access checks; it
assumed that the operating system would do all that, based on the
access rights that the particular user had.  So, it was important to
log in *before* any files were accessed.

The objection to an automatic login as ANONYMOUS was that once you
logged in, you were stuck with that.  If you wanted superior access
rights, you had to quit your FTP connection, re-connect, and log in
all over again.  No one wanted to implement "re-login", with all the
possible security loopholes that implied, just for the convenience of
the FTP server.

When auto-login was implemented in the NCP FTP server (I forget if it
was Ken Harrenstein or I who did it), some people continued to object
on this basis, even when it was pointed out that a retrieve without a
login would just have been an error before.  I guess it was religious.

As for the Unix FTP server, I'm sure it's just a combination of
inertia and copying aspects of a design that are irrelevant on Unix.

Mark Crispin / 6158 Lariat Loop NE / Bainbridge Island, WA 98110-2098
mrc@CAC.Washington.EDU -- MRC@PANDA.PANDA.COM -- (206) 842-2385
Atheist & Proud -- R90/6 pilot -- Lum-chan ga suki ja!!!
tabesaserarenakerebanaranakattarashii...kisha no kisha ga kisha de kisha-shita
sumomo mo momo, momo mo momo, momo ni mo iroiro aru
uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iru

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 00:09:20 GMT
From:      lars@salt.acc.com (Lars J Poulsen)
To:        comp.protocols.tcp-ip
Subject:   DDN X.25 Diagnostic Codes

The DDN X.25 Host Interface Specofication stored at NIC.DDN.MIL
(NETINFO:X25.DOC) is several years old. Is there a newer version
available, and if so, where ?

A subscriber is getting a CLR 33-155 (Incompatible destination)
when connecting to a large subset of other hosts; these hosts can
generally connect to the subscriber in question without problems.

Diagnostic code 155 (9B) is undocumented in the above reference.
What does it mean, and where is it listed ?

--
/ Lars Poulsen <lars@salt.acc.com>   (800) 222-7308  or (805) 963-9431 ext 358
  ACC Customer Service              Affiliation stated for identification only
                My employer probably would not agree if he knew what I said !!

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 00:15:00 GMT
From:      brian@ucsd.Edu (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Re: Unauthorized access via terminal servers

What we did here at UCSD to solve the problem of unauthorized network access
from our dial-up Annex boxes is to hack up the nice Annex security code.

Now if you dial up one of our boxes, you can telnet (or rlogin) to
machines on a list of networks (our three class-B nets and the UC
systemwide library catalog Class-A network) without user verification,
but if you want to connect anywhere else, we'll demand of you for a userid
and a password, which are checked against a database.

Thus students, staff, and faculty have no impediments in getting to the
various machines on our network and I don't have to be responsible for
maintaining access userids and passwords for some 20,000 people!

Those few people who need off-campus access can get it by registering
with us, and when someone abuses the access, I can turn it off.  Perhaps
not the best solution, but quite workable in our view.

	Brian Kantor	UCSD Network Operations
			UCSD C-024, La Jolla, CA 92093-0124 USA
			brian@ucsd.edu ucsd!brian BRIAN@UCSD

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 00:40:06 GMT
From:      ggm@brolga.cc.uq.oz (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   Re: partial transfer recovery in RFC and OSI protocols

postel@VENERA.ISI.EDU writes:

>George Michaelson:
>Please read the specification of FTP, RFC-959.  See section 3.5 on error
>recovery and restart, and read about the REST (restart) command.

Yes, I should have RTFS, I'm sorry. I made the mistake of treating a
BSD-ism as evidence of what an RFC would contain.

I hope the various schemes for solving this problem come together into
a workable whole. To re-iterate, the ACSnet experience of having this
capability embedded in the transport layer is very positive, the costs
are sufficiently marginal to make overheads acceptable on good links,
the benefits on slow noisy ones are immense. I need hardly add that by
doing it low down the stack ALL upper layer activity can potentially
take advantage of it, whereas a feature like REST is application specific. 

Rick Adams suggestion of working on the network order octetstream seems
pretty close to what ACS is achieving, and has the benefit of being
very simple in concept. 

Thankyou to everyone who emailed me to point out the RFC was not at fault...

	-George

Internet: G.Michaelson@cc.uq.oz.au                     Phone: +61 7 377 4079
  Postal: George Michaelson, Prentice Computer Centre
          Queensland University, St Lucia, QLD Australia 4067. 

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 01:22:45 GMT
From:      pvm@VENERA.ISI.EDU (Paul Mockapetris)
To:        comp.protocols.tcp-ip
Subject:   Re: MB, MG, MR....

> >Hi. May I ask if anybody is currently playing with the experimental
> >mailbox RR's ? Is there any software using them ? Do most implementations
> >of the DNServers already handle them ? Seems exactly what I need to
> >handle our 'logical addresses'. Thanks for any info.       /AF
> 
> It is my understanding that MB, MG, and MR are obsolete, and that MX
> was designed specifically to be a replacement and generalization of the
> other three.
> 
> Doug Nelson
> Michigan State University

At the time the DNS was designed, everybody agreed that we needed to
support mail.  One faction argued for "mailbox binding" or routing
based on the whole destination (e.g. PVM@ISI.EDU) while another argued
for "agent binding", in which only the right-hand side, or ISI.EDU in
this case, is used.  The difference is whether you route mail by
individual mailbox or by oragnization/host/whatever.

The "agent binding" folks proposed a mechanism using MF and MD RRs.
This was replaced by MX.  Agent routing is the standard today.

The "mailbox binding" folks had a lot more trouble deciding what to
do, since they also felt that mailing lists, exploders, etc were on
their agenda.  Basically no agreement was possible for the same sort
of reasons as you see different mailers for UNIX.  However, I felt it
was important to at least illustrate the possibilities, so the mailbox
RRs are in the DNS spec.  I have been told by different people that
they are exactly right, completely wrong, or somewhere in between.

Every so often, I get inquiries asking whether anyone has implemented
it.  I know some places that have threatened to, and have seen several
viewgraph implementations.  I don't know if anyone has it in
production.

It seems clear to me that:

An implementation based on the current specs might be useful for some
sites.

An extended version could easily be better.

Standardizing one or getting mailbox binding elevated to an Internet
standard might be easier than getting agreement on a standard shoe
size, but need not be so.

This discussion should move to namedroppers.

paul

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Dec 89 10:01 PST
From:      Michael Stein                        <CSYSMAS@OAC.UCLA.EDU>
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Networks considered harmful
> I think Vint Cerf correctly observed in one of his IEEE NETWORK
> columns that fax enjoys the advantage of using the addressing
> and connectivity of the public switched telephone network
> (PSTN).  Much as email does all of these And still, I like
> having hard copy to "review and edit" rather than the paperl

I guess I need this explained to me :-)

Every FAX I've received has my name on it or else I wouldn't get
it...  FAX uses HUMAN readable addresses.
-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 02:51:00 GMT
From:      ljm@TWG.COM (Leo J McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   default routes in IP gateways


This note arises from a private discussion about installation of
routers.  The response seemed sufficiently useful to IP novices
to warrant distribution.

>>(paraphrased) defalt routes are bad.
 
>I am curious about your
>comment re the use of default routes. I am not a TCP guru, we are
>just getting into it here, but it seems to me that default routes
>are necessary, otherwise a router needs to know about ALL networks
>to which it can connect.

The primary problem is one of routing loops:

I set up

                      |
   A -- B -- C -- D --| great big wide world
                      |

with router B using C using D as its default gateway and you set up

					 |
                   great big wide world  |-- E -- F -- G -- H
					 |

with router G using F using E as its default gateway

If I send a packet from A to H and any of E, F, or G doesn't know that
H is behind it, the packet bounces back and forth over the Internet
until the TTL expires.

In practice this is a very easy topology to create.

  1) E and G, but not F under stand RIP. (The classic WIN/ROUTE example).

  2) 'Someone else' added G/H after you installed E and F. 

  3) 'Someone else' 'fixed' F's routing tables.


Or perhaps a simpler (common WIN/ROUTE customer) example:

  Novell -- A -- small -- B -- SLIP -- C -- small --D-- Novell
network 1      ethernet        link       ethernet     network 2

A's default is B,
B explicitly knows about A and has default of C
C explicitly knows about D and has default of B
D's default is C.

User on Novell network #1 mis-enters an internet address.
Just sit back and watch the phone bills.


Lastly, keep in mind that the errors in both of these examples are fairly
easy to spot and debug.  Much more complex and devious traps can be created
by adding additional adminstrative entities.


enjoy,
leo j mclaughlin iii
The Wollongong Group
ljm@twg.com

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 02:51:58 GMT
From:      campbell@redsox.bsw.com (Larry Campbell)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

In article <8912190403.AA05387@ucbvax.Berkeley.EDU> 702WFG@SCRVMSYS.BITNET (bill gunshannon) writes:
-But the truth is, FAX offers nothing that can't be done with the PC sitting
-on your desk. And the PC can even do it better.  You can send Email from
-PC to PC or PC to "Real computer" or "Real computer" to PC.  The softtware
-and hardware already exist.  In fact they have been around for years.
-The hardware we all have and the software doesn't even cost anything!!!

Complete hogwash.  Let me demolish this nonsense point by point:

(1) "FAX offers nothing that can't be done with the PC sitting on your desk"

Most people DON'T HAVE PCs sitting on their desk.  OK, fine, IF you have
a PC, AND a modem and telephone line, AND some software that you know how
to configure and use...  but you've now eliminated 90% of the average adult
population.

(2) "The PC can do it better"

Well, maybe.  IF the PC has a scanner, and a laser printer (gotta be able
to send hand-scribbled notes, newspaper articles with marginal commentary,
etc.), and a modem, and the right software, etc. etc.

(3) "The software doesn't even cost anything"

This is just plain stupid.  There Ain't No Such Thing As A Free Lunch.
Even if you get public domain software, SOMEONE has to configure it,
install it, fix it when it breaks, and upgrade it when external conditions
change.  None of this is free.  It costs REAL MONEY.

THERE IS ABSOLUTELY NO SUCH THING AS A FREE LUNCH!!

-You can send text, you can send pictures, you can even send color pictures.

Yeah, right.  How do I send pictures over MCI Mail?  CompuServe?  Sure,
if you, the recipient, and I, the sender, have a prior arrangement about what
picture file format to use, and are we using uuencode or atob, etc. etc.
It's stupid to expect normal (non-technoid) humans to put up with that crap.

-And you can do it the same way you do with a FAX.  You can call the addressee
-on the phone and send it to him directly.  As a matter of fact it has probably
-reached the point where you can buy all the hardware necessary to do this for
-about the same price as one of those full featured FAX machines.

Oh, come on.  Let's talk real machines, not low-ball clones, because low-ball
clones have no support;  Joe Businessman has no time to waste on tracking
down bugs in his hardware.  He just wants it to work, yesterday.  So let's
assume a 286-based machine with hard disk and some memory, maybe $2,000
for a decent one.  Scanner, $1,000.  Laser printer, $2,000.  High-speed
modem, $500.  Software, $500 (this estimate probably low).  We're up to
$7,000 now.  Last I looked, decent FAX machines sold for one TENTH this price.

-Interestingly enough, the Email scenario has numerous advantages over the
-FAX scenario.  I can move more data quicker.  I can manipulate the data
-easier when it arrives.  And if the number is busy, I don't have to stand
-around and wait.  The PC can do it for me.

Fine.  Most people don't WANT to manipulate the data.  They just want to
get a page from point A to point B.  If they get tired of busy signals,
they use a FAX service bureau.

-So, someone please tell me "What is so great about FAX?" and why can't
-those of us who use Email all the time convince the rest of the world
-how much better it really is??

Because Email sucks.  Look, I'm *in the Email business*, and I still think
it sucks.  Before we're going to get anyone other than techno-geeks to use
Email, we need (1) UNIVERSAL connectivity, and (2) REAL ease of use.  Folks,
we're still a LONG way from that goal, and FAX has beaten us to it.  The
advantages of Email (which I do recognize) just don't matter to 90% of FAX
users.
-- 
Larry Campbell                          The Boston Software Works, Inc.
campbell@redsox.bsw.com                 120 Fulton Street
wjh12!redsox!campbell                   Boston, MA 02109

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 03:15:43 GMT
From:      shj@ultra.com (Steve Jay)
To:        comp.protocols.tcp-ip
Subject:   Re^2: FAXes vs. EMAIL

peter@ficc.uu.net (Peter da Silva) writes:

>Again, once the software and standard is there (a SMOP):
 
>	"Turn the machine on. After a little while it will display the
>	 main screen. You can hit 'R' to read messages, 'W' to write
>	 messages, and 'S' to send mail. The computer will also answer
>	 the phone and accept messages in this mode.
 
>	"If you hit R, the subject lines of waiting messages will be
>	 displayed, whether they're to or from you, and for messages from
>	 you whether they have been delivered yet... you can display these
>	 messages, print them, or discard them.
 
>	"If you hit W, you will be prompted for the phone number to
>	 send the message to, the name of the person to receive it,
>	 and a subject line (a short comment as to what the message is
>	 about, such as "Christmas card".
 
>	"If you hit S, EMAIL will attempt to send any messages waiting
>	 to go out."
 
>After the protocol is worked out (see other messages on the subject),
>this should be pretty simple.

As simple as this seems, it's already beyond what a lot of civilians
(non-computer folk) are willing to accept.

FAX technology works with familiar, low tech, stuff, like pieces of
paper & writing implements of your choice.  People already know how
to create written documents, file them in some way, and locate one
via random criteria at some later date.  Using the computer & email,
you have to worry about how to edit a message going out and how to save
a message for later retrieval.  This requires a lot more than "turn it
on & type W".

As an example of what a non-technical person can easily do with FAX
messages, but might be real tough with email, is find the message
that supposedly came in within the last month or so (but really it
came in 4 months ago), and the document is remembered only as the
one that had a blue smudge in the upper left corner.

Steve Jay
Ultra Network Technologies	Domain: shj@ultra.com
101 Dagget Drive		Internet: ultra!shj@ames.arc.nasa.gov
San Jose, CA  95134		uucp:  ...ames!ultra!shj
(408) 922-0100

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 03:45:41 GMT
From:      sl@van-bc.UUCP (Stuart Lynne)
To:        comp.protocols.tcp-ip,comp.org.usenix
Subject:   Re: Networks considered harmful/Re: USENIX board studies UUCP

In article <7387@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>In article <106@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes:
>> First anything you do shouldn't disenfranchise the existing successful base
>> that is using fax technology. Your new protocol should be able to send
>> "email" to a fax machine and receive and print a fax from a fax machine. 
>
>I disagree. The main consideration should be to avoid disenfranchising the
>people currently using existing email systems. This should be something
>that someone with a PC and a $100 modem can hook into. This isn't intended
>to be an enhancement to FAX, but an enhancement to email: UUCP, SMTP,
>MCI-Mail, Compuserve, and so on.

I see, anyone with a $100 dollar modem can use any of these networks *right*
now for just the cost of the phone call. Right.

>> Of course this implies that you'll need a V.29 modem and be able to support
>> the T.30 protocols.
>
>Which is why it's pretty much out of the question. These are relatively
>expensive modems and definitely complex protocols. This is out of reach
>And the end product can be built a LOT cheaper. An IBM-PC clone with a
>1200 baud internal modem is in the few hundred dollar range. And then
>there are all the people with Commodore-64s. You're talking a complete
>system that costs less than a FAX modem alone.

I've seen add's (maybe bogus, who knows) for $195 Fax Board plus software
for an IBM PC. Well ok that's more than $100. But certainly less than your
complete pc (generic) plus 1200 bps modem. With the introduction of the
Yamaha Fax Chip I think you'll see a dramatic drop for these types of boards
over the next two years. Up until recently Rockwell had a lock on the market
and didn't have any real competition to force them to bring the prices
down.


What you seem to be proposing here is YAEFSMS (Yet Another From Scratch EMail 
Standard).

What I'm suggesting is extending an existing successful standard. Specifically
transferring RFC-822 compatible messages using the proposed Fax FTP
standard.

You want people to figure out a new set of protocols for connecting,
establishing a common protocol, using a slow signalling technology, and
start from scratch. A suggestion - might be easier to start with Fido stuff
and work sideways.

I want people to utilize an existing set of protocols for connecting and
setting up the call, a faster signalling technology, and be able to hook
into a very large and successful user base; with the addition of some simple
mail transfer protocols to be used only when there is a computer at each end
of the connection (ie no *real* fax machines). 

-- 
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 06:26:45 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.protocols.tcp-ip
Subject:   text->group 3 fax conversion software (not: harmful networks)

In article <1450@lakesys.lakesys.com> jtk@lakesys.UUCP (Joe Klein) writes:
!
!A freely distributed e-mail interface with a nice GUI would help. Perhaps

	i don't think you'll see *free* GUI's for faxmodem control
	for a while yet.  at least not until the extended Hayes AT
	command set for fax is implemented and fully standardized.

	for now, faxmodem software is tied to individual faxmodems;
	every brand has a different interface!  i don't know of a one
	which has implemented the Hayes AT-fax standard.

!ELM with a PM/Motif interface. It would be nice to draft a standard for
!encapsulating FAX bitmaps as well as other graphic formats. A freeware
!conversion of e-mail to FAX would be nice.

	it is nice!  it's included with the PBMPLUS toolkit,
	along with lots more suave X-ish filters.  

!Proposed e-mail fixes.
!
!	1. FAX <=! e-mail gateways.

	there are a few of us out there who will fax email to our local
	area codes.  there hasn't been much interest, though.  only
	4 people have asked me to fax things (Boston).

!	2. Develop a global addressing scheme.
!
!	3. Develop a simple user interface.
!
!	4. Intergrate graphics, (voice?, vidio???) etc.
!
!Can't be that hard.

	it wasn't!  unfortunately, i've got this nasty bug
	in this email2fax gateway here:  all it seems to send
	out is a fax of my cat, regardless of the input email!









-- 

{ Steve Elias ; eli@spdcc.com ; 6179325598 ; 5086717556 ; }
/* C */     { *disclaimer(); } 
/* not C */ { z = disclaimer(y) : (y = lim [x-->0] ( 1/x ) ) }

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 07:46:11 GMT
From:      Nagle@cup.portal.com (John - Nagle)
To:        comp.protocols.tcp-ip
Subject:   Re: Of interest to time freaks


     We have a leap second coming up at the end of the year, and
sites running tightly coupled clock systems may notice the transient.
Dave Mills will probably report on this at some point.

					John Nagle

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 13:06:01 GMT
From:      krupczak@secola.Columbia.NCR.COM (Bobby Krupczak)
To:        comp.protocols.tcp-ip
Subject:   Re: wanted : TLI interface with socket library

In article <232@bull.bull.fr> amf@bpe2.spix7.depr.bull.fr ( Anne-Marie FOUREL ) writes:
>
>I will soon have to port applications using the TLI interface, but
>our unix only has the socket interface for TCP/IP.
>
>I'd like to know  :
>1) if anybody has already met the problem and how it has been solved.
>2) if anybody has written a version for TLI based on sockets.

NCR Unix machines run a Sys V kernel and therefore use TLI for their
transport drivers.  The implementation of BSD sockets available for them
is simply a library that makes TLI calls.  I cant give you the source, but
it shouldnt be to hard to write this "library".

Bobby

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 13:47:32 GMT
From:      vax8530!vax5!st5@cu-arpa.cs.cornell.edu
To:        tcp-ip@nic.ddn.mil
Subject:   pd ftp server source wanted
I'm looking for public domain source code for an ftp server implementation. 
As I'm new to this list, I'd appreciate any information on general tcp-ip
anonymous servers where I can get public domain programs and code. 

Thank you. 
-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 15:44:42 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: default routes in IP gateways


	Default routes aren't bad-- it's just the way you're using them!

	The "gateway-to-the-world" (GWTTW) needs to know all of the Internet
routes, but nothing on the local side has to; they can all have a trivial
routing table of a single default route pointing to the next closer local hop
to the GWTTW along with any backside nets or the like.

	In your example:

                      |
   A -- B -- C -- D --| great big wide world
                      |

	Give A, B and C the tiny routing table (using default routes for
everything to the right) and give D a full routing table with no default
route.
	No Internet bouncing and no big routing tables. Default routes
don't harm internets; people harm internets.

	Convenient, disposable, premoistened.

-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 17:32:53 GMT
From:      kwe@buit13.bu.edu (Kent England)
To:        comp.protocols.tcp-ip
Subject:   Re: default routes in IP gateways

In article <8912211854.aa21721@Obelix.TWG.COM> 
ljm@TWG.COM (Leo J McLaughlin) writes:
>
>I set up
>                      |
>   A -- B -- C -- D --| great big wide world
>                      |
>
>with router B using C using D as its default gateway and you set up
>
>					 |
>                   great big wide world  |-- E -- F -- G -- H
>					 |
>
>with router G using F using E as its default gateway
>If I send a packet from A to H and any of E, F, or G doesn't know that
>H is behind it, the packet bounces back and forth over the Internet
>until the TTL expires.

This assumes that the managers in the GBWW are using defaults.

>  1) E and G, but not F under stand RIP. (The classic WIN/ROUTE example).
>  2) 'Someone else' added G/H after you installed E and F. 
>  3) 'Someone else' 'fixed' F's routing tables.

You describe some pretty loose usage of default and make a lot of
implicit assumptions that static routes will be used liberally.
Certainly this sort of thing can be done, but it is really not state
of the art today.  Anyone hacking static routes with liberal use of
default everywhere is going to get what's coming to him.

Suppose that all your routers A thru D are running a common interior
protocol like RIP and are not using static routes.  Suppose the same
thing for E thru H.  In this case, the routers in the stub domains
should be able to reach anyplace within their stub domain without
resort to default.  Now, suppose that all of the routers in the two
stubs (A--D and E--H) use defaults pointing into the GBWW.  Further,
suppose that the routers in the GBWW backbone do not use default
routes (nor static).  This protects the backbone from forwarding any
packets that come in from one of the stubs for a net that is
temporarily unreachable in their own domain and limits useless default
forwarding to no further than the GBWW boundary.  In this situation,
the judicious use of default in the stub routing domains seems
reasonable to me and does not lead to great inefficiency and long
lasting routing loops.

	I don't say that what you say is untrue, just that the
judicious use of default is perfectly reasonable and that static
routes combined with defaults everywhere are the cause of more routing
woe than careful use of default.


	One of the reasons I don't like default is that unreachable
net datagrams have to travel all the way to some authoritative router
that does not have a default.  These days, almost everyone continues
to use the arpanet as a global default.  I sometimes wonder how much
useless traffic washes around The Great Default Net.  In my opinion,
no backbone or regional should use any defaults, but I know that
others disagree for good reason.  If you list every network known and
default, your default woes should be minimized and new networks will
come up more quickly.

	One reason default has to be used is that the list of nets is
so large that some non-obsolete routers can't hold them all.  Our
routers can't handle more than 762 routes today, so we just got to the
point where we were losing 30-40 nets and had to drop back to using
default.  You also don't want to pass 1k net updates across 9.6 and
56k serial lines.  There are also routers where no one ever needs to
know reachability to everywhere, so why put all the routes in the
table?  Keep the table small enough so that local people can tell if
their local nets are reachable without paging thru 1k of nets.

	We set up our p4200s on one class B subnetted.  We do not use
any subnet default routes, but we point a global net default to our
GBWW router, which should not use default and will stop all
unreachables right there.  No static routes.  If I want to know about
reachability, I ask the GBWW router how to get there.  If he says he
is using default, then I know there could be trouble.

	My advice to the novice reader is not to hack static routes
and realize that carefully constructed defaults are perfectly usable.

	Kent England, Boston University

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 17:38:38 GMT
From:      bzs@world.std.com (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Networks considered harmful


As an information services provider (ahem) the first problem that
comes to mind with an e-mail box (similar to a fax box) is that once
you start commercializing like that all the non-profit nets will start
reading you the riot act.

To make this happen the first thing that would be needed would be a
clear policy regarding gatewaying mail into and thru networks like
NSFNET. Some quid pro quo that the community was comfortable with
would be a good place to start discussions. Eventually I'd assume
mutual exchange of mail would be sufficient since that services both
parties, but at first that's going to seem like too small a quid (or
is it a quo?)

The other model, where one just starts hawking such a box is an ok
idea and seems to make sense in the abstract, but I know I wouldn't be
interested and I suspect only a few fortune 500 companies would be,
ATT perhaps. The reason is that such an investment, a grassroots
attempt to build your own private e-mail-box network, would probably
take 5-10 years to be profitable. Faxes started like this but the
service was a little more tangible.

You could hook up two offices with faxes in the beginning and it was
enough to justify the boxes even if there weren't a lot of other faxes
out there to talk to, I suspect e-mail has a higher critical threshold
of utility.

More importantly, if it just hooks up two offices there are a zillion
other choices to do about the same thing as far as a (presumably
conservative and not fascinated with techno-toys) business or
administrative person is concerned. Telephones and those little pink
"while you were out" slips come to mind as do voice mail, fax, random
PC e-mail products, backdoors to research nets etc.

Just like a phone system, the real value is not being able to send a
few words from here to there, it's the security blanket of general
connectivity, knowing that the *next* person you need to speak to is
probably reachable via this medium. That's what I mean by a "critical
threshold of utility", a term I just made up. Perhaps "critical
threshold of perceived utility" would be better.

Another (almost) missing piece in the picture involves exploiting the
real advantages of e-mail over these other mediums, such as being able
to group and save/retrieve threads of conversations. For example, any
of us might be managing a dozen projects (some we might not call
projects, like office supplies, but it's still a separate thread.)

Rather than being blasted (as most of us are) with "You have 34 new
messages" every morning you need something that probably doesn't even
look like e-mail, some tagged message system which can be configured
to reflect the groups you break up your world into (sets of people,
sets of project tags, priorities, etc.)

This is the whole "groupware" thing in a nutshell. I've worked with
some executive consultant types on this kind of thing. They knew
nothing really about e-mail etc (one used MCI Mail) but they did have
some vision of what they think their customers wanted. It came down to
basically what I just described, something to structure
communications, commitments, assignments etc. Just passing more
verbiage about is actually a turn-off to a lot of people, present
company excepted.

E-mail is just a means towards that end, a utility not unlike phones,
but as has been said before (usually credited to Bill Joy), if a new
development doesn't represent an order of magnitude improvement then
it's probably not worth the effort of adapting to it.

        -Barry Shein

Software Tool & Die, Purveyors to the Trade         | bzs@world.std.com
1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzs

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 18:01:00 GMT
From:      CSYSMAS@OAC.UCLA.EDU (Michael Stein)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

> I think Vint Cerf correctly observed in one of his IEEE NETWORK
> columns that fax enjoys the advantage of using the addressing
> and connectivity of the public switched telephone network
> (PSTN).  Much as email does all of these And still, I like
> having hard copy to "review and edit" rather than the paperl

I guess I need this explained to me :-)

Every FAX I've received has my name on it or else I wouldn't get
it...  FAX uses HUMAN readable addresses.

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 18:02:07 GMT
From:      chris@SALT.ACC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   printing on the network from VMS

Merry Christmas to everyone,
				 I'm in the process of working on a distributed
print application using WIN/TCP to distribute some print capabilities out
to 3COM/Bridge terminal servers. I'm having a bit of trouble with the VMS side
of things and was hoping someone io the world has done something similar. here'sthe proposed scene:
	A user logged onto the VAX through a 3COM term server connects to the
the Wollongong TELNET server, then connecting to some application running
under VMS. There is a "network" printer on a slave port on the 3COM that is
used by the VAX. This is connected via use of TWG's 3COM print symbiont that
looks like a logical VMS printer(I guess). The problem is how can I get the
system to recognize when the Terminal user hits a "print screen" key and 
redirect the output to the network printer? I would think that some DCL could
be written to tell the terminal driver that a special key had been hit,
throw the screen buffer into a file, and then send it to the print symbiont,
but has anyone actually DONE something like this? (Re-inventing the wheel
has never been one of my goals in life (:*) ).
		I would greatly appreciate any comments/guidance that anyone
would care to share.
		THanks in advance,
   __    _____   _____     Chris VandenBerg (chris@salt.acc.com)
  //\\  / ____\ / ____\    Advanced Computer Communications
 //__\\ ||_____ ||_____    720 Santa Barbara St. 
// \___\\_____/ \_____/    Santa Barbara, CA 93101
                           (805) 963-9431

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 19:05:49 GMT
From:      barns@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re:  DDN X.25 Diagnostic Codes

I was going to go ping the appropriate DCA person but I guess he's on
Christmas vacation, so I'll give you an unofficial version.  A revision
of the DDN X.25 document is in work, and has been for a while now.
However, it isn't on the street yet.  It hit headwinds here and there
during review; long lists of comments and questions were generated and
most have been resolved, but as of the last I knew, one batch was still
in work.  (I helped create that batch - had a task to review the
draft.)  In the past, some reviewers had sufficiently adverse opinions
about the document that they thought it inadvisable to publish.  I
think that phase may be about over, although I have suggested that it
be published initially as a draft for review and comment (of course
they are hardly obliged to do what I suggest).

According to drafts I've seen, diag 155 means that you tried to open a
"Basic X.25" connection to a host whose PSN port has been configured to
accept only "Standard X.25" connections, i.e., the destination wants to
see a Standard Service facility in the call request and the source
didn't send one.  For historical reasons, a number of hosts are
configured for Basic&Standard even though they only want one of the
two, while other hosts are configured for only one or the other.  This
could explain the obscure subsetting phenomenon.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 19:06:35 GMT
From:      MAP@LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   Anonymous FTP


   Date: 21 Dec 89 21:43:41 GMT
   From: milton!blake!Tomobiki-Cho!mrc@beaver.cs.washington.edu  (Mark Crispin)

   In article <909@excelan.COM> donp@na.excelan.com (don provan) writes:
   >Actually, there's nothing in FTP that requires any login at all.  The
   >first FTP server i had to deal with would do an implicit "anonymous"
   >login when needed if no "USER" command was given.

   Ah, fond memories of ITS!  Actually, that winning feature was also put
   in the good version of Tenex/TOPS-20 NCP-based FTP server, but it
   never made it into the TCP FTP server.

This brings up one of my pet peeves about many current FTP client
implementations.  Several of the machines I FTP to do not require a
login for anonymous access, but the clients typically make me log in
anyway.  In fact, I had to specially hack one of the servers to ignore
a login request for anonymous which would otherwise be an invalid
name.  This was to fake the clients into believing the login had
succeeded so they would let me transfer files.

Please, if you are implementing an FTP client, allow for the case of
the remote machine having an open access policy, not needing any
login.  Don't restrict access by insisting on login even when it's not
needed (and may not be possible).

	    __
  /|  /|  /|  \		Michael A. Patton, Network Manager
 / | / | /_|__/		Laboratory for Computer Science
/  |/  |/  |atton	Massachusetts Institute of Technology

Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 19:12:17 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip,comp.org.usenix
Subject:   Re: Networks considered harmful/Re: USENIX board studies UUCP

In article <110@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes:
> I see, anyone with a $100 dollar modem can use any of these networks *right*
> now for just the cost of the phone call. Right.

Your sarcasm is noted.

No, of course you can't. The whole point here is to change things so you can
send mail to someone with no more than a phone number. But if this requires
new hardware anyway, it should at least be cheap hardware.

> I've seen add's (maybe bogus, who knows) for $195 Fax Board plus software
> for an IBM PC. Well ok that's more than $100. But certainly less than your
> complete pc (generic) plus 1200 bps modem.

You can buy an Atari 800 for as little as $70. Commodore-64s are similarly
priced. They're quite powerful enough to support this application. That gives
you $130 for your modem. 1200 baud modems start under $100.

There are millions of these cheap machines out there. Certainly more than
FAXes. PLUS all the IBMs and IBM clones, many of which already have modems.

> What you seem to be proposing here is YAEFSMS (Yet Another From Scratch EMail 
> Standard).

You mean YAFSEM?

No, I'm proposing a slight modification to UUCP.

When someone has a FAX machine your proposal doesn't give me any additional
capability. If they have an email machine then who cares whether it's FAX
compatible or not.

And as for the transfer speeds, my proposal has been demonstrated at up to
18,000 baud using Telebit Trailblazers. That's about twice as fast as FAX.
-- 
`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
 'U`  Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>.
"It was just dumb luck that Unix managed to break through the Stupidity Barrier
and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 19:16:38 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: Re^2: FAXes vs. EMAIL

In article <1989Dec22.031543.606@ultra.com> shj@ultra.com (Steve Jay) writes:
> As simple as this seems, it's already beyond what a lot of civilians
> (non-computer folk) are willing to accept.

Perhaps. I think you give them too little credit. Look at what they do in
France, with those abbysmal minitel terminals.

> As an example of what a non-technical person can easily do with FAX
> messages, but might be real tough with email, is find the message
> that supposedly came in within the last month or so (but really it
> came in 4 months ago), and the document is remembered only as the
> one that had a blue smudge in the upper left corner.

Whether the thing is printed on a dot matrix printer or a FAX machine
is irrelevant.
-- 
`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
 'U`  Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>.
"It was just dumb luck that Unix managed to break through the Stupidity Barrier
and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 19:21:11 GMT
From:      mak@hymir.cs.cornell.edu (Mesaac Makpangou)
To:        comp.protocols.tcp-ip
Subject:   Re: Building a reliable datagram protocol on top of UDP

In article <1486@wacsvax.OZ> jamesp@wacsvax.uwa.oz.OZ (James Pinakis) writes:

> I'm trying to write a protocol which delivers variable size packets
> reliably (i.e. in sequence, no dups, no dropped packets) using the
> Internet UDP.  I opted to use UDP since I wanted a single (server)
> process to be able to accept messages from any number of sites (clients),
> rather than (using the tcp-ip client/server model) a process having
> to accept a connection, then fork a process to talk on that connection.
> I would also prefer to only have one socket to listen on, rather than
> a pile of file descriptors to select on (since the number of clients
> is potentially large).

I implemented almost such a transport protocol at INRIA (France) for 
the SOS communication service. (SOS is an object-oriented distributed 
operating system developped at INRIA by the SOR group.)

To summarize, the SOS communication service is made of four layers:
	1) The network interface layer.
	2) The transport layer.
	3) The protocol objects layer.
	4) The application interface layer.
In the transport layer, I  implementrd
a reliable unicast and multicast datagram transport protocol.
The difference with what you want, is that this protocol doesn't enforce
the delivery in sequence of messages exchanged between protocol objects.
There are a lot of reasons of doing so. The main one is that,
not all application protocols (here encapsulated by what we call 
protocol objects) need this functionnality. So we made the
choice to provide such functionality at a higher level 
(i.e at the protocol object layer).

The protocol objects which want to enforce the sequencing
implement it by queueing messages arriving in an incorrect
order, and just waiting the arrival of the appropriate message.

> I'm currently implementing a sliding window protocol (Tanenbaum's
> protocol 6, actually) but this is getting nastily complicated.

To do this, I used some kind of sliding window too. The main point is
that I have a very large window. I managed to accept messages even
if they were not in sequence, but I ensure that every message
is delivered to its destinator(s) (i.e reliable datagram).

> It amounts to having to maintain a set of protocol state information
> for every client which establishes a "connection" to the server.
> This implies a reasonably large setting up operation every time
> a new client wants to start talking with the server.

In my implementation, I have also a set of protocol state.
I think however that its size is reasonable.
For my implementation, I assumed that the set of potential
clients and servers was known (this was realistic since this
was the set of sites runing our system).

> Basically, I'm wondering if anyone has experience/source code which
> they would like to share with me. 

I have the code, and an article and my Ph.D dissertation describing
this stuff. I will also continue to work on its improvement
sometimes by end february 1990. So I will be glad to share
my experience and my source with you.

> How efficient is this protocol likely to be? 

As far as the efficiency is concerned, the measures I did
year ago, tended to show that my protocol outperforms
tcp for messages of size range from 1024 bytes to 1500 bytes.
Below 1024 bytes, the tcp was better than my protocol.
The best explanation I have is that, UDP sends one
packet for every user message. I did not look closely to the
tcp code, but I suspect that small user messages could be sent
in a single inter-sites message.
For messages bigger than 1500 bytes, I did no measures
since my implementation assumes a maximum size of 1500
for all transport packet (the fragmentation is
implemented by the protocol object level).

> Would I be better off sticking with tcp-ip and
> accepting a limit to the number of client processes?

At the end of my implementation, I asked myself if
it was really necessary to do this, instead of using
tcp. I provide some answers in my thesis.
To summarize, I think that it is suitable for an
operating system to allow each application (or more precisely each
application protocol) to pay only for what it really needs.
I'm convince that enforcing the sequence (more generally the
delivery order: causal ordering, atomic ordering, fifo ordering, etc.),
and enforcing the fragmentation/reassemblage for examples, are not needed
by all application protocols. These functionalities should be 
better implemented by appropriate protocol objects.

So, in my case, I still believe it was necessary.
In your case however, it seems to me that your choice should be guided
by the importance of the limitation of the number of client processes
in your system.

References:
-----------

1) Protocoles de communication et Programmation par Objets: l'exemple de SOS.
	(Ph.D Thesis, Universite' Paris 6, France. February 1989.
	 Available as Rapport de Recherche INRIA.)

	This dissertation discusses extensively the structure and the
	implementation of the SOS communication service.
	Chapter 4 describes the implemtation of our reliable datagram protocol.
	Chapter 8 discusses the performance figure of this protocol and
	compares it with tcp and udp.

2) The SOS Object-Oriented Communication Service 
	(In procedings of ICCC89 Tel Aviv (Israel), October-November 89.)

I will be happy to send you a copy of both.
Also, the code is in C++, and I will check how we
can share this code once I go back at INRIA sometimes in February.

Mesaac

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 21:16:13 GMT
From:      atkins@hpindda.HP.COM (Brian Atkins)
To:        comp.protocols.tcp-ip
Subject:   FAX !vs. E-Mail

Many E-Mail providers, such as TeleMail, ATTMAIL, MCIMail, all provide
E-Mail to FAX service.  Many provide X.400 and other E-Mail interfaces
(like UUCP/UNIX/RFC.822 mail) to their own protocols, which in turn can
go out via their FAX access units.

In addition, X.400 is becoming a check-off item for many European companies,
and for many major U.S. companies as well.  With the extensions in the
1988 X.400 standards for interworking with Postal Systems, FAX, telex,
teletex, and an API standard for gateway and application interfaces to
X.400, E-Mail is finally becoming global.  

HP, DEC, Microsoft and other major companies are committed to 
X.400 as either a mail backbone, or as a gateway service to/from 
their own mail systems. (I hesitate to put IBM in this list because 
they offer it at a prohibitive price, and then only because certain 
markets demand it.  If it was up to IBM, with world would be PROFS.)

X.400 also has the capability to handle multi-media documents.  Research
in many companies is currently looking at E-Mail <=> voice mail gateways,
among other gateways.  This doesn't require any new technology or terminals.
Dial a number using your existing phone, record a message, when you're
done you have a file on your disk full of  digitized voice.  It's possible
with technology already developed and available from any voice mail vendor.

Finally, with revisions to the remote User Agent protocol (P3) and
the addition of the Message Store and it's protocol (P7), public MHS
service can be a reality.  This is different than what is currently 
provided from ATTMail, Telemail, Comp-u-serv, etc. in that it is a standard.
Software can be mass produced by many different vendors, shrink wrapped, and 
sold in shopping malls.  Then, anything with a modem and software can 
talk a form of E-Mail which 95% of the world's E-Mail users can access,
either directly or through gateways.

Once we have common X.400 MHS service (P3/P7) available, machines with
LCD displays, keyboards and a phone jack can be developed, shrink wrapped, 
and sold in malls just like FAX machines.  Unfortunately, users will
still have to come to terms with those displays and keyboards, and most
annoying of all, the addressing of E-Mail users.

But that's where X.500 comes in.  If you know enough about a person so
phone them, or address a postal letter to them, you have the actual 
E-Mail addressing information automatically retrieved by the E-Mail system.

Sound like a dream?  Today it is. In the next 2 to 3 years? Much less so!
The progression of E-Mail is coming, slowly, and in stages.  To abandon
E-Mail for FAX is ridiculous, just as abandoning FAX for E-Mail is
ridiculous (and will probably continue to be for the foreseeable future).

----------------------------------------------------------------------
Brian Atkins               atkins@hpindqa.HP.COM        (408) 447-2057
Hewlett Packard (43LS)     19420 Homestead Rd.     Cupertino, CA 95014

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 89 22:07:09 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans,rec.ham-radio.packet
Subject:   Nelson's patches to KA9Q's NOS.

Merry Christmas!  Having some idle time before the holiday vacation, I
figured I'd package up my current set of patches for Phil Karn's
TCP/IP package, NOS.  These patches are for the next-most recent
version of NOS, 890918.  If anyone adapts these for the most recent
version, I'd like a copy.  Both the patches and that version of NOS
and a version of patch for the PC are available on
sun.soe.clarkson.edu's pub/ka9q directory.  Also available from
archive-server at same host.  Filenames:

diffs.arc
src.arc
patch.arc

In short, we've got:

ARCNET.DIF     ARCnet support.
EXTERN.DIF     External access to NOS.
FCNTL.DIF      Adds fcntl()
FTPSERV.DIF    Minor fixed to the ftp server
JOIN.DIF       For people who JOIN their drives
NETRC.DIF      Adds a .netrc capability
RLOGIN.DIF     Adds a rlogin client
TAR.DIF        Adds a tarfile disk backup.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
Live up to the light thou hast, and more will be granted thee.
A recession now appears more than 2 years away -- John D. Mathon, 4 Oct 1989.
I think killing is value-neutral in and of itself. -- Gary Strand, 8 Nov 1989.
Liberals run this country, by and large. -- Clayton Cramer, 20 Nov 1989.
Shut up and mind your Canadian business, you meddlesome foreigner. -- TK, 23 N.

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 89 03:10:56 GMT
From:      sewilco@datapg.MN.ORG (Scot E Wilcoxon)
To:        comp.protocols.tcp-ip,comp.org.usenix
Subject:   Re: Networks considered harmful/Re: USENIX board studies UUCP

I thought "Networks considered harmful" suggested generalizing message
connections so any caller could deliver mail to any callee.

I think that some messages are best delivered by text, some by graphics,
and some by voice.  A "telephone" could answer with signals which tell
the calling "telephone" which types of messages can be handled, and the
local preference.  The "telephones" can be connected to voice answering
machines, e-mail computers, fax machines, handsets (for "live" voice
calls), and other devices.  Various translations (email to fax, email
to voice, etc) could be provided by "telephones" or connected devices.

Allowing uucico to be a front end for negotiating various protocols is
a step in the right direction, but before the uucico handshake there
should be another level of handshaking.  This connection-making front
end must know what type of work needs to be done and what type of
connection has been made (the latter at present by a combination of
the type of device being used and the call progress messages from
the modem, such as "CONNECT 2400" or "FAX 9600").  By knowing the
type of work, the connection-making front end can decide whether
to start uucico or translate email to fax.

The connection-making front end could also handle connection
negotiations for smart "telephones", but some negotiation protocols
should also be defined for popular technologies.  Specifically,
an asynchronous modem connection should begin with one or both
sides deciding what type of connection should be established (ie,
SL/IP, Zmodem, or uucico via a UNIX login).
-- 
Scot E. Wilcoxon  sewilco@DataPg.MN.ORG    {amdahl|hpda}!bungia!datapg!sewilco
Data Progress 	 UNIX masts & rigging  +1 612-825-2607    uunet!datapg!sewilco
	I'm just reversing entropy while waiting for the Big Crunch.

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 89 16:55:23 GMT
From:      steve@nuchat.UUCP (Steve Nuchia)
To:        comp.protocols.tcp-ip,comp.org.usenix
Subject:   Re: Networks considered harmful/Re: USENIX board studies UUCP

In article <7403@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>And as for the transfer speeds, my proposal has been demonstrated at up to
>18,000 baud using Telebit Trailblazers. That's about twice as fast as FAX.

Isn't it misleading to compare baud (actually, bit) rates for FAX and
E-mail?  One is sending an image, the other text.  FAX has a lot of
advantages, but text transfer efficiency isn't one of them.
-- 
Steve Nuchia	      South Coast Computing Services      (713) 964-2462
"If the conjecture `You would rather I had not disturbed you
 by sending you this.' is correct, you may add it to the list of
 uncomfortable truths."   - Edsgar Dijkstra

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 89 17:07:03 GMT
From:      jdarcy@pinocchio.encore.com (Jeff d'Arcy)
To:        comp.protocols.tcp-ip
Subject:   Re: partial transfer recovery in RFC and OSI protocols

braden@VENERA.ISI.EDU:
> Well, not exactly.  How do you compute N, or reset your file to N?  N
> is a count of bytes in the transmitted data stream, which is related to
> file position parameters through a transformation which could be very
> complex.  On the machine with a complex file structure, the only way to
> compute N in general is to play through the conversion process.

This kind of restart is obviously a non-trivial problem.  That being the
case, I think it makes a lot of sense to keep the protocol simple and
make the machine- or format-induced complexity invisible to the common
network software.  By making the protocol more complex you introduce
additional overhead even for simple cases or between systems that have
very simple file structures.

Jeff d'Arcy     OS/Network Software Engineer     jdarcy@encore.com
  If Encore endorsed my opinions, they couldn't afford to pay me

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 89 19:15:30 GMT
From:      bzs@world.std.com (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   computerfax (was Re: Networks considered harmful)


>	the US post office is currently offering fax service at
>	some northeast post offices.  they rent space to a company	
>	which put together "fax kiosks" designed for public use.
>
>	(has anyone seen one of these beasties, yet?)

There's one here in the Brookline Post Office. It looked expensive (I
think $15?) You can find fax-o-matics in most any motel lobby and many
copy shops, I'd be surprised if this is a big hit for the P.O.

        -Barry Shein

Software Tool & Die, Purveyors to the Trade         | bzs@world.std.com
1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzs

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 89 20:04:32 GMT
From:      sl@van-bc.UUCP (Stuart Lynne)
To:        comp.protocols.tcp-ip,comp.org.usenix
Subject:   Re: Networks considered harmful/Re: USENIX board studies UUCP

In article <17788@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes:
}In article <7403@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
}>And as for the transfer speeds, my proposal has been demonstrated at up to
}>18,000 baud using Telebit Trailblazers. That's about twice as fast as FAX.
}
}Isn't it misleading to compare baud (actually, bit) rates for FAX and
}E-mail?  One is sending an image, the other text.  FAX has a lot of
}advantages, but text transfer efficiency isn't one of them.

No it's fair. The suggestion is for extensions to the fax standards to
support FTP using V.29/V.27 compatible modems. 


-- 
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 89 22:23:05 GMT
From:      sl@van-bc.UUCP (Stuart Lynne)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

In article <8912210003.AA02652@bel.isi.edu> postel@VENERA.ISI.EDU writes:
>
>Hmm.
>
>Can someone explain how we could have this discussion of FAX vs E-Mail via
>FAX?  What is the scenario for my having recieved all the contributions to
>date and sent this message to you all?
>

Are you trying to point out that the News system (as sort of an extension of
the mail system) is doing something that would be more difficult by FAX?

I would tend to agree with you on that point. 

However to possibly clarify some of my suggestions. What I would like to see
is extensions to the FAX standards that would allow FTP between two systems
that have FAX modems. (I.e. V.29/V.27 technology, suitable for sending a fax
from your system to a Real(tm) Fax Machine. )

Once you have FTP you could see articles arriving at your machine that have
Path lines like:


	Path:  yoursite!somesite!backbone!van-bc!1-604-555-1212!slpc
	From:  stuart@1-604-555-1212

In other words the computer called slpc run's a news system. A user on that
system posted an article. It was sent via an FTP process to van-bc by
dialing up van-bc's fax line. During the call setup phase van-bc and slpc
agreed to allow slpc to transfer a file from slpc to van-bc, and have it run
as input to rnews. Specifically we have replaced uucp's uux command with
something like (assuming 555-2222 is van-bc's fax number):

	faxexecute 555-2222!rnews newsarticle

The "advantage" being that the fax subsystem doesn't require a Systems file
containing a chat script to get into the remote system. Just a phone number.
The two systems will decide what modulation schemes, baud rates, protocols,
encodings, work to do, etc; after they connect using the T.30 specifications
(extended to allow things like FTP).

You should also be able to send mail back to the orignator by sending mail
to:

	mail stuart@1-604-555-1212 mailmessage

Now if your system has aforementioned fax modem, your system just dials the
number and it and slpc decide whether or not it will allow your system to
deliver email to it (using the fax FTP protocol again).

Of course if you don't have that type of technology you can send it to a
gateway machine (for example van-bc):

	mail van-bc!1-604-555-1212!stuart mailmessage

Presumably sendmail/smail3 etc can be setup to do this for you. 

The important thing about *all* of the above is that at *no* time are we
using the fax standards in their current form. I.e. rendering the message to a
bitmap and transferring that. Just the modem technology, and the call setup
technology. 

Also note that with appropriate software a mail message like the above
*could* get delivered as a rendered bitmap if the sending machine discovered
during call setup that the destination *was* a Real(tm) Fax Machine. But
that the faxexecute request would fail (Error: fax machine can't unbatch news).

The hoped for end result is simpler point to point email using the PSTN. I
can send email to you without prior arrangement if you have either a fax
machine or a computer system equipped with fax modem (and appropriate
software). And that I think was the original idea behind the JMC article in
CACM. We must remove the requirement email has for going through special
networks or it will be supplanted by fax. 

NB I'm suggesting RFC-822 type messages for this type of use. Others might
prefer Fido type messages. Or even worse X.400. I suppose as part of the call
setup two systems can start by asking for X.400, and then falling back to
RFC-822 or Fido, and then down to a rendered bitmap.

-- 
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)

-- 
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 89 04:51:28 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: partial transfer recovery in RFC and OSI protocols

I'm keeping this issue alive because I'm still learning from it.  I hope
that others find it interesting and are also profiting from the discussion.

We are trying to decide which file transfer restarting solution is
more general: sender-controlled or receiver-controlled.
Sender-controlled restarting relies on the sender issuing restart
markers periodically, and on the receiver being able to preserve its
state at these arbitrary (to it) points.  Receiver-controlled
restarting relies on the sender being able to suppress the initial N
octets.

The restart method prescribed by the FTP RFC is sender-controlled.
The restart method implemented by Adams is receiver-controlled.  These
two methods may both be implemented at the same time provided the
markers emitted by the sender-controlled restart are distinguishable
from a string of decimal digits.

In article <8912210357.AA06303@gateway.mitre.org> barns@GATEWAY.MITRE.ORG (Bill Barns) writes:

   I disagree because I don't believe that the byte number in the transfer
   stream is sufficient information to determine how to join the data sent
   during the restarted transfer with the data sent the first time in
   every imaginable case.

It should be sufficient.  It's the receiver that chose the number.
Perhaps an example is in order?  A Unix implementation receiving an
ASCII file [1] would have two states: one for "maybe CR", and another
for "expecting LF".  A receiver-controlled restart mechanism would
only need to remember restarts when in the first state.  A sender-controlled
restart mechanism would need to remember restarts in *both* states.  It
would also need to remember which state it was in.  It would also need
the ability to enter that state upon entry to the routine.

[1] Unix uses a single character (newline) to indicate the end of a
line.  ASCII as transmitted over TCP uses two characters (CR, LF) to
indicate the end of a line.  Every occurrence of CR followed by a LF
should be changed into a newline.  The hack of ignoring CR and
translating LF into newline is not correct.

   There would be no problem if the bytes in the transfer stream were
   literally stored in the file.

Unfortunately, the rest of your discussion that followed was flawed.
You assumed that the restart parameter must be reconstructed solely
from the data file.  I don't believe this is possible for
invertibility reasons as you suggest.  Even if it were possible to do
with receiver-controlled restart, it is certainly impossible with
sender-controlled restart because you have the problem of remembering
the arbitrary (to the receiver) restart markers.

I think that you were led into the brambles because Adam's receivers
let you choose an arbitrary octet at which to restart.
Receiver-controlled restarting isn't always going to be that easy.
But it *is* going to be easier than sender-controlled restarting.

I'm ignoring the issue of block mode, which is required by
sender-controlled restart.  None of the major anonymous FTP archive
sites have implemented block mode.

And having said all that, I'll close by saying that it doesn't really
matter *which* restart method gets implemented, so long as at least
one of them *does* get implemented, preferably the same one.  Given
that receiver-controlled is simpler to implement, and a freely
copyable implementation of it for 4.3 BSD Unix already exists, I'd go
with receiver-controlled.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
Live up to the light thou hast, and more will be granted thee.
A recession now appears more than 2 years away -- John D. Mathon, 4 Oct 1989.
I think killing is value-neutral in and of itself. -- Gary Strand, 8 Nov 1989.
Liberals run this country, by and large. -- Clayton Cramer, 20 Nov 1989.
Shut up and mind your Canadian business, you meddlesome foreigner. -- TK, 23 N.

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 89 11:51:26 GMT
From:      VSBENZI@WEIZMANN.BITNET (Benzi mizrahi)
To:        comp.protocols.tcp-ip
Subject:   Ethernet Type assignment

Hello all,

 anyone knows what authority assigns Ethernet Type numbers?

 Thanx, Benzi

Computing Center,
Weizmann Institute of Science,
Rehovot,
Israel

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      Sun, 24 Dec 89 13:51:26 +0200
From:      Benzi mizrahi <VSBENZI%WEIZMANN.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@sri-nic.arpa
Subject:   Ethernet Type assignment
Hello all,

 anyone knows what authority assigns Ethernet Type numbers?

 Thanx, Benzi

Computing Center,
Weizmann Institute of Science,
Rehovot,
Israel
-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 89 20:24:51 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Of interest to time freaks

John,

Well, we are having a wonderful time on the Network Time Protocol jabber
list (ntp@trantor.umd.edu) exploring the causes, effects and defenses
of leap seconds, all fifteen of them come next year. For a mind-numbing
expose of timescales, leaps and wiggles as relevant to a computer clock
near you, see the file pub/ntp/leap.txt on louie.udel.edu. For those
clocks chiming NTP, something over 2000 so far, be advised the primary
NTP servers should leap precisely on cue; however, what your time-conversion
routines do during second 23:59:60 UT on 31 December 1989 may be anybody's
guess. The more extreme of us clockerfolk have a contest going.

Dave

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      26 Dec 89 13:42:27 GMT
From:      craig@com2serv.C2S.MN.ORG (Craig S. Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

In article <0ZXtO8S00hl=APvn1Y@andrew.cmu.edu> jhm+@ANDREW.CMU.EDU (Jim Morris) writes:
<Here is an earlier reply to John's messsage -- back when it was just a
<bb post on USENet's telcom.
<From: Jim Morris <jhm+@andrew.cmu.edu>

<> These advantages include the fact that information is 
<> transmitted more cheaply as character streams than as images.
<> Group IV compression brings the image vs. ASCII ratio down to about 5. 

Does this take into account the fact that ASCII data streams can be
easily and quickly compressed, also.

<>  Moreover, messages transmitted as character streams can be readily
<> filed, searched, edited and used by computer programs.
<OCR can work for the searching part.  99% character recognition rates
<are common. There are already products available that scan, recognize,
<and index documents for you. The key idea is that the image is saved
<too, so there is no danger of the  1% missed characters causing problems
<other than missed retrieval.

I would very much like to hear specifics of anyone getting 99%
character recognition of transmitted facsimiles on a regular basis.
What are the costs in time and money of this sort of efficiency?

<Jim.Morris@andrew.cmu.edu

/craig

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      26 Dec 89 13:55:46 GMT
From:      craig@com2serv.C2S.MN.ORG (Craig S. Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCPIP & Burroughs

In article <8912220826.AA00460@ucbvax.Berkeley.EDU> 702WFG@SCRVMSYS.BITNET (bill gunshannon) writes:
>Does anyone know of a ETHERNET/TCPIP solution for Borroughs computers??
>Pointers to commercial or non-commercial sources would be appreciated.
>                                          bill gunshannon

Try your local UNISYS branch sales office.

Or, try the folks at Intercomputer Communications Corporation (ICC).
They are located in Cincinnati, Ohio.  Their phone number is
(513)745-0500.

Hope this helps,

/craig

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      26 Dec 89 15:28:11 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful/Re: USENIX board studies UUCP

In article <24189@datapg.MN.ORG> sewilco@datapg.MN.ORG (Scot E Wilcoxon) writes:
> Allowing uucico to be a front end for negotiating various protocols is
> a step in the right direction, but before the uucico handshake there
> should be another level of handshaking.

Your solution depends on new hardware (FAX modems). The first stage needs to
be something that can be implemented now, without changing code. Allowing
anonymous UUCP with a standard account (email) and password (email) does
this. Big systems will have to set things up manually, but PeeCees can run
a slightly modified UUPC or GNUUUCP. If someone with the code and the time
did it today (alas, I have neither), we could start sending messages tomorrow.
-- 
`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
 'U`  Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>.
"It was just dumb luck that Unix managed to break through the Stupidity Barrier
and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      26 Dec 89 15:37:38 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

In article <8912230541.AA07763@ucbvax.Berkeley.EDU> haverty@BBN.COM (Jack Haverty) writes:
> Assuming my experience is not a fluke,

I think it's a fluke. Using the Mac you could have had the same problem taking
the data down the hall, or over a LAN. Why? Because the Mac has never produced
any strong file-format standards. I don't know why, what with Apple pushing
for standards everywhere else in the machine.
-- 
`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
 'U`  Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>.
"It was just dumb luck that Unix managed to break through the Stupidity Barrier
and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      26 Dec 89 15:46:16 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

In article <8912221738.AA09309@world.std.com> bzs@world.std.com (Barry Shein) writes:
> You could hook up two offices with faxes in the beginning and it was
> enough to justify the boxes even if there weren't a lot of other faxes
> out there to talk to, I suspect e-mail has a higher critical threshold
> of utility.

That's why I'm arguing for an email standard built around UUCP. It already
uses the PSTN. The only problem with UUCP is that the destination phone
number is hard coded into the system... you can't casually send a message
to 7134385018, but you can put that in your system file and send a message
to sugar.hackercorp.com. The other problem is customising the chat script.
That needs to be standardised (login email password email), and gettys that
need weird things like BREAK to lock baud rate need to be fixed. That's
largely been done.

Then you can say "now your salesemen out in the feild can call in and get
their mail at odd hours... and automatically provide a phone number they
can be reached...". Bingo... an application of immediate utility to many
middling to large businesses.
-- 
`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
 'U`  Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>.
"It was just dumb luck that Unix managed to break through the Stupidity Barrier
and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      26 Dec 89 20:38:03 GMT
From:      wiltzius@lll-lcc.UUCP (Dave P. Wiltzius)
To:        comp.protocols.tcp-ip
Subject:   Info Request, again


Does anyone know of any information regarding the implementation
of networking code (e.g. TCP/IP) in a message passing system?
I read an article about such an implementation many months ago
that extolled the virtues of such a design, but I forgot where
I read it.  I understand Mach is one such system.

Any help is greatly appreciated.
  Dave (wiltzius@lll-lcc.llnl.gov)

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      26 Dec 89 20:48:56 GMT
From:      bzs@world.std.com (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Anonymous FTP


There is a good reason to use the anonymous login name (under unix or
other OS's), it lets a sysadmin turn this on and off using familiar
tools (i.e. disable the account or don't set it up and you don't have
anonymous login.) One could invent yet another whistle (they're there
already, play with inetd.conf etc., or is that /etc/inetd.conf?) but
this is intuitively obvious and quick.

Considering the rash of holes found a while back in anonymous FTP's I
assume this was used and useful (adding/deleting a password for the
anon acct is fine on/off mechanism.) I will do this sort of thing just
because I'm rearranging files drastically or want to back-up the disk.

I have nothing against versions which loosen these conditions, but
it's not entirely vestigial and nice to use a known facility to
control something rather than inventing yet another administrative
sub-system.

Anyhow, this is all art, not science.

        -Barry Shein

Software Tool & Die, Purveyors to the Trade         | bzs@world.std.com
1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzs

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      26 Dec 89 20:58:37 GMT
From:      bzs@world.std.com (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Networks considered harmful


Re: fax newsgroups/discussions

There are "intelligencers" which you can buy and are distributed by
fax. A few times a day sheets will pop out of your fax with selected
bits of timely news and analysis. I have no idea what these cost (I
don't even remember the names of the services, but I have stood at a
fax machine reading them.)

That's a one-way medium but I don't know of any similar services on
the Internet (I guess it would be forbidden on this network since it
would be a commercial service.) Perhaps analogous services exist on
commercial e-mail nets?

Do the people in this discussion actually feel like they know *what*
goes on on the commercial e-mail nets besides simple messaging? If
someone does know perhaps you could make a quick list of activities
that might be interesting and send it to this group.

        -Barry Shein

Software Tool & Die, Purveyors to the Trade         | bzs@world.std.com
1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzs

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      26 Dec 89 23:27:26 GMT
From:      MAP@LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   Networks considered helpful


   Date: Fri, 22 Dec 89 12:38:38 EST
   From: bzs@world.std.com (Barry Shein)

   Rather than being blasted (as most of us are) with "You have 34 new
   messages" every morning [...]

You are right Barry, classification is very useful.  I do a certain
amount of classification using standard tools right now and find that
I can deal with a lot more mail that way.  I wish there were a few
more better tools, but most would require extensions to mail and
wide-spread support on originating machines.  I have thought about
implementing some of the ones that are completely recipient side.

My general technique is to group incoming mail into about 10
categories, I can read each grouping with a slightly different
mind-set.  For example, the mailbox for action requests is dealt with
first and carefully, but the mailbox for unimportant "general info
only" mail can be scanned with only the headers (in fact when I've
been away for a while, I sometimes delete indiscriminantly).  Here's a
(somewhat made up, since I've already read my mail today :-) version
of what I see on a typical morning:

There are 5 Local messages.
There are 73 Misc messages.
There are 3 Digest messages.
There is one Kermit message.
There are 15 Micro messages.
There is one MITAUG message.
There is one Amiga message.
There are Heath People Request messages.

(and yes, I'm thinking of subdividing "Misc" :-).  Just for those of
you who might be interested in following a similar option, here's what
I do.  For most systems, this either requires that you have privileges
or a sympathetic system manager.  Each mailing list I subscribe to is
delivering mail to a different address of the form MAP-<listname>-Mail
and I have the local aliases file set up to distribute these among
various mailboxes (named MAP-<mailbox>, see above).  The mail reader I
use (now GNUemacs RMAIL, previously ITS/Tops-20 Babyl) allows seperate
mail folders with different inboxes for each.  This gives me all the
flexibility needed for this approach.

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      26 Dec 89 23:31:53 GMT
From:      MAP@LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   Networks considered harmful


   Date:    Fri, 22 Dec 89 10:01 PST
   From: Michael Stein                        <CSYSMAS@oac.ucla.edu>

   Every FAX I've received has my name on it or else I wouldn't get
   it...  FAX uses HUMAN readable addresses.

But the problem is the ones I haven't received!  My FAX number is
shared by about 300 individuals.  The people who run it report several
FAXes a day without proper delivery info.  They usually hang on to it
a while if the person was expecting it and comes by they may be able
to claim it by looking at it.  People are starting to get better at
it, but the addressing is still in the "body" rather than on the
"envelope" as E-Mail does.

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 89 00:05:11 GMT
From:      jkrey@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Ethernet Type Number Assignment POC



----- Begin Included Message -----

From jkrey@venera.isi.edu Tue Dec 26 09:35:33 1989
Date: Tue, 26 Dec 89 09:34:15 PST
From: jkrey@venera.isi.edu
To: VSBENZI%WEIZMANN.BITNET@cunyvm.cuny.edu
Subject: Re:  Ethernet Type assignment
Cc: jkrey@venera.isi.edu

Benzi,

Please contact:

Xerox Corporation
Xerox Systems Institute
475 Oakmead Parkway
Sunnyvale, CA 94086
Attn: Mr. Dennis Frahmann

Phone:  (408) 737-4652


----- End Included Message -----

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 89 01:58:19 GMT
From:      jacob@gore.com (Jacob Gore)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: Networks considered harmful/Re: USENIX board studies UUCP

/ comp.protocols.tcp-ip / peter@ficc.uu.net (Peter da Silva) / Dec 26, 1989 /
> Allowing
> anonymous UUCP with a standard account (email) and password (email) does
> this.

I think we Unix system administrators have been doing this for so long,
that we forgot that it's not "UUCP" that requires a login and a password.
Just run uucico (or its equivalent) on the modem's port, instead of running
a getty->login->uucico.

> Big systems will have to set things up manually, but PeeCees can run
> a slightly modified UUPC or GNUUUCP.

Where is GNUUUCP?  I tried to find it a few months ago, but could locate no
trace of it. 

Jacob
--
Jacob Gore		Jacob@Gore.Com			boulder!gore!jacob

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 89 02:51:21 GMT
From:      sl@van-bc.UUCP (Stuart Lynne)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: Networks considered harmful/Re: USENIX board studies UUCP

In article <670004@gore.com> jacob@gore.com (Jacob Gore) writes:
>/ comp.protocols.tcp-ip / peter@ficc.uu.net (Peter da Silva) / Dec 26, 1989 /
>> Allowing
>> anonymous UUCP with a standard account (email) and password (email) does
>> this.
>
>I think we Unix system administrators have been doing this for so long,
>that we forgot that it's not "UUCP" that requires a login and a password.
>Just run uucico (or its equivalent) on the modem's port, instead of running
>a getty->login->uucico.

I doubt that uucico would work properly without having it's environment
setup by login.

Might be able to fudge it with from inittab with script.

Don't forget some systems (eg Xenix) don't easily allow anything but getty
to run on a tty port. I suppose it would be possible, but not to obvious.

-- 
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 89 03:42:32 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

In article <8912221738.AA09309@world.std.com> bzs@world.std.com (Barry Shein) writes:
> As an information services provider (ahem) the first problem that
> comes to mind with an e-mail box (similar to a fax box) is that once
> you start commercializing like that all the non-profit nets will start
> reading you the riot act.

I seriously doubt it. All an email box is is a modem++. After the way Usenet
has absorbed all the Fido crossfeeds with a minimum of indigestion, a little
more Email won't even be noticed.

Not to mention that the majority of activity would be point-to-point over
phone lines outside the internet.
-- 
`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
 'U`  Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>.
"It was just dumb luck that Unix managed to break through the Stupidity Barrier
and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 89 03:47:00 GMT
From:      ficc!peter@uunet.uu.net  (Peter da Silva)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Networks considered harmful
In article <117@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes:
> 	Path:  yoursite!somesite!backbone!van-bc!1-604-555-1212!slpc
> 	From:  stuart@1-604-555-1212

> 	faxexecute 555-2222!rnews newsarticle

> The "advantage" being that the fax subsystem doesn't require a Systems file

This "advantage" of FAX doesn't require FAX. In fact it would be MUCH easier
to just modify UUCP to support it than to invent Yet Another Point To Point
File Passing Protocol... and one that needs a new (and at this date expensive)
piece of hardware for most existing sites.
-- 
`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
 'U`  Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>.
"It was just dumb luck that Unix managed to break through the Stupidity Barrier
and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 89 08:49:25 GMT
From:      af@spix7.depr.bull.fr ( Anne-Marie FOUREL )
To:        comp.protocols.tcp-ip
Subject:   Re: wanted : TLI interface with socket library

In article <232@bull.bull.fr> amf@bpe2.spix7.depr.bull.fr ( Anne-Marie FOUREL ) I wrote:
     >I will soon have to port applications using the TLI interface, but
     >our unix only has the socket interface for TCP/IP.
     >
     >I'd like to know  :
     >1) if anybody has already met the problem and how it has been solved.
     >2) if anybody has written a version for TLI based on sockets.
     
In article <465@secola.Columbia.NCR.COM> krupczak@secola.UUCP (Bobby Krupczak) writes:
     >NCR Unix machines run a Sys V kernel and therefore use TLI for their
     >transport drivers.  The implementation of BSD sockets available for them
     >is simply a library that makes TLI calls.  I cant give you the source, but
     >it shouldnt be to hard to write this "library".

This answer makes me think that my question was not clear enough, because
what you mention is exactly the opposite of what I'm looking for, ie an
implementation of TLI interface calling BSD sockets !

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 89 15:44:59 GMT
From:      little@SAIC.COM (Mike Little)
To:        comp.protocols.tcp-ip
Subject:   ComputerFAX Kiosks

Those FAX kiosks are beginning to appear not only in US Post Offices, hotel
lobbies and airports but in such strange places as your grocery store, truck
stops and donut stores.  These systems work best for transmission usage.  To
receive FAX you must make out-of-band arrangements so that the transmitter
knows both the kiosk phone number and time to send (these public access
machines must have your charge code when reception occurs).  To my knowledge,
storage and retreival (mailbox) functions are still external.  Some of the
print shops, hotels and stationary stores getting into the act will provide
these functions and now we get closer to 'electronic' mail.  One vendor 
utilizes a PC/AT in their FAX kiosk and could, in theory, participate in 
e-mail along with FAX (they do not at this time).
	The Post Office FAX kiosk (in the northeast, at least) is a public 
facility external to the postal system just like a pay telephone.  They rent 
the space and take part of the revenue generated.
	If anyone is interested, my brother is with one (there are only
four) of these FAX kiosk companies and I will put you in touch with him for
more information.
					-Mike

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 89 16:15:06 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: Networks considered harmful/Re: USENIX board studies UUCP

[ standardising chat scripts: login email, no password, 8n1... ]

In article <670004@gore.com> jacob@gore.com (Jacob Gore) writes:
> I think we Unix system administrators have been doing this for so long,
> that we forgot that it's not "UUCP" that requires a login and a password.
> Just run uucico (or its equivalent) on the modem's port, instead of running
> a getty->login->uucico.

This is a problem for pre-SysV systems, which don't have an inittab so you
can't have uucico run from init. Also, this requires that you dedicate a
phone line to this function. I don't know about you, but I'd rather not
do that.

> [where do you get GNUUUCP]

Check your comp.sources.amiga archives.
-- 
`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
 'U`  Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>.
"It was just dumb luck that Unix managed to break through the Stupidity Barrier
and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 89 18:40:00 GMT
From:      ljm@TWG.COM (Leo J McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   Re: default routes in IP gateways


>
>	No Internet bouncing and no big routing tables. Default routes
>don't harm internets; people harm internets.
>
>					+-DLS  (dls@mentor.cc.purdue.edu)

True enough, and an appropriate phraseology.  Default routes are a
powerful and quite useful tool, but they do allow the uninformed to
shoot themselves in the foot.

enjoy,
leo j mclaughlin iii
The Wollongong Group
ljm@twg.com

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 89 20:28:19 GMT
From:      cfe+@ANDREW.CMU.EDU ("Craig F. Everhart")
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

Yes, the Messages program that you get with the Andrew contribution to
the X tape has bitmaps, too.

Give it a try.

		Craig Everhart

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 89 17:00:02 GMT
From:      cam@SATURN.ACC.COM (Chris Markle acc_gnsc)
To:        comp.protocols.tcp-ip
Subject:   What is correct FTP server response to perm I/O error?

Folks,

I asked this question once already and got a grand total of zero 
responses; being a glutton for punishment/abuse I respectfully try 
again:

How should FTP server that is receiving data (eg. STOR, STOU) respond 
after encountering a permanent I/O error. More specifically, how should
that server close the data connection in response to the permanent I/O 
error? 

Let me outline a scenario... An FTP client initiates a STOR to our server
and begins to send 100 megabytes. The data set that is the STOR target is
one measly disk track, so we have an "out of space condition". We send
the apropriate 4xx or 5xx response over the control connection, but then what?

Our current scheme is issue a non-abortive close of the data connection.
The problem with this is that the remote end keeps sending the whole 100
MB which we are now just throwing away. This can take quite a while if the
client is sending lots of data. You might say "well just issue an
abortive close (ie. TCP RST)" but that seems to cause certain clients to
close the control connection as well! (One of these clients is 4.3 BSD ftp
which we definitely need to work with).

The Host Reqs RFC provides no enlightenment about this situation.  The FTP 
RFC provides the following "guidance" (from RFC 959):

	(Page 19) - "The server MUST close the data connection 
	under the following conditions: ... 5. An irrecoverable 
	error condition occurs.", and

	(Page 45) - "Any time either the user or server see that 
	the connection is being closed by the other side, it 
	should promptly read any remaining data queued on the 
	connection and issue the close on its own side."

I would interpret this to mean that the sender of the 100MB should
"detect" our graceful close and should cease sending and issue the 
close on the sender's side. This raises the question of whether something
like BSD Unix can "detect" the close.

Are clients that close the control connection when the data connection is
reset broken? How should this situation be handled between FTP servers
and clients?

Chris Markle

ACC (Advanced Computer Communications)

cam@saturn.acc.com
(301)290-8100

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 89 17:20:55 GMT
From:      cfe+@ANDREW.CMU.EDU ("Craig F. Everhart")
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered helpful

Here at andrew.cmu.edu we invented the foo+bar@andrew.cmu.edu form of
local address, for use in addition to the usual john.doe@andrew.cmu.edu
form, to allow simple automatic sorting of incoming mail.  Mail to local
address ``foo+bar'' is stuck in the mailbox for userid foo, and the
``bar'' tag is retrievable (minimally) by looking at a ``for foo+bar''
clause in a Received: header.

An advantage to this form of local address is that recipients who wish
to use these alternate in-box forms don't have to be mail
administrators; anybody can ask that one of these annotated addresses be
added to some address list.

Like many other mail readers, we also have a whole Lisp-like language
that lets users filter and sort their incoming mail, but that's another
story.

The delivery system software that implements the foo+bar local address
form, as well as the joe.jones form, will all be in the X.V11R4 tape, in
the Andrew contribution.

		Craig

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 89 18:24:03 GMT
From:      jacob@gore.com (Jacob Gore)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: Networks considered harmful/Re: USENIX board studies UUCP

In article <670004@gore.com> jacob@gore.com (Jacob Gore) writes:
> Just run uucico (or its equivalent) on the modem's port, instead of running
> a getty->login->uucico.

/ comp.protocols.tcp-ip / peter@ficc.uu.net (Peter da Silva) / Dec 27, 1989 /
> This is a problem for pre-SysV systems, which don't have an inittab so you
> can't have uucico run from init.

You don't need init.  Let uucico run as a daemon, started from /etc/rc.
Well, you may need an equivalent of a getty unless you standardize on a
specific speed/parity/stop bits/etc. combination.

> Also, this requires that you dedicate a
> phone line to this function. I don't know about you, but I'd rather not
> do that.

I wouldn't either, but I thouht we were talking about turnkey
point-to-point email, based on your generic Piece of Crap clones.  Dialing
out of from the computer could push aside the uucico on the port.  All
you'd lose by dedicating the port to uucico is being able to handle
incoming calls that have nothing to do with email.  If it's a PC, your
average user won't be dialing into it...

And if the call is received by a 

> > [where do you get GNUUUCP]
> Check your comp.sources.amiga archives.

Thanks.

Jacob
--
Jacob Gore		Jacob@Gore.Com			boulder!gore!jacob

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 89 20:50:09 GMT
From:      dricejb@drilex.UUCP (Craig Jackson drilex1)
To:        comp.protocols.tcp-ip
Subject:   Re: partial transfer recovery in RFC and OSI protocols

Seeing the discussion of receiver-controlled vs sender-controlled restart
in the referenced article, I realized that there could be another problem
with Rick Adams' restart method (where the receiver tells the sender,
"supress the first n bytes of your transmission").

The problem would occur if the receiver was unable (or unwilling) to
store a byte-image of the transmitted file, or something transformable
back-and-forth to such and image.  If a irreversable transformation
is necessary to store the received file in the receiver's file system,
then the receiver may not be able to compute the proper byte count.

For an example, assume a receiver that implemented a record-oriented file
system, with fixed-length records.  The receiver might have to blank-pad
each record received via FTP.  (I'm ignoring the issue of long lines.)
Such a blank-padding might be innocuous to all uses on the receiver machine,
except for the retransmission.

I suppose that the way this would be dealt with is for the receiver to
store an auxiliary file, with indications of "when I began record m,
n bytes had been sent".  This file would be periodically updated (every
few hundred records) and pushed to the disk.  Some care would need to be
taken to ensure that the received file and the marker file would be
consistent after a crash.

I don't mean to say that Rick's method is not useful.  I'm just trying 
to explore the issues.
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 89 02:36:07 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: Networks considered harmful/Re: USENIX board studies UUCP

> You don't need init.  Let uucico run as a daemon, started from /etc/rc.
> Well, you may need an equivalent of a getty unless you standardize on a
> specific speed/parity/stop bits/etc. combination.

I wouldn't want to standardise on a speed. Use the fastest hardware you can
afford. And if you need getty, why not?

> I wouldn't either, but I thouht we were talking about turnkey
> point-to-point email, based on your generic Piece of Crap clones.

Yeh, but I'd like to keep it compatible with existing point-to-point UUCP.
So you can have your UNIX mini in the office accept calls from the salesemen
and feild engineers laptop email machines. So a *simple* standard chat script
would be handy.

	"" ogin--ogin--ogin email

for a PC: send "CR" until you get "login", then send "emailCR" until you get
a protocol start.
-- 
`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
 'U`  Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>.
"It was just dumb luck that Unix managed to break through the Stupidity Barrier
and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 89 10:48:22 GMT
From:      efb@suned1.Navy.MIL (Everett F. Batey II)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   3b2s and netware

Anxious to exchange notes with ANYONE who has been exposed to tcp-ip
or and netware on 3B2s.  My friends tell me it is painless and 
economical to connect some dozen or two netware equipped PCs to ATT
3B2s ( file services, remote session and so on ).  Can someone
confirm or deny this .. Never heard of a 3B2 on tcp .. nor 3B2 with 
NFS, etc. Until the gateways find us again, personal replies should
go to efb@suned1.uucp or efb@nosc.mil .. we vanished outside of the 
MILnet.  Thanks /Ev/

-- 
   efb@suned1.UUCP efbatey@suned1.nswses.Navy.MIL efb@elroy.JPL.Nasa.Gov 
           Gold Coast Sun Local User Group | Vta-SB-SLO DECUS
      Statements, Opinions ... MINE ... NOT those of my US Employer  

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 89 17:25:19 GMT
From:      emv@math.lsa.umich.edu (Edward Vielmetti)
To:        comp.unix.ultrix,comp.sys.dec,comp.protocols.tcp-ip,comp.sources.wanted
Subject:   tn3270, version for dec 3100 ?


Hi.

I'm looking for a version of tn3270 that will build cleanly 
on the DECstation 3100 under Ultrix 3.1.

I have located versions that will build under the following systems,
some small consolation -- apparently all of the ifdefs in tn3270
are #ifdef system rather than #ifdef feature, so a port is none
too fun.

ucbarpa.berkeley.edu (v4.1.1) which compiles OK on sun/vax
RT AOS 4.3 Release 2 with NFS defines on devvax.tn.cornell.edu.
HP-UX version on columbia.edu in hp/tn3270.tar.Z.
IRIS version on iris613.gsfc.nasa.gov.

Thanks for help or pointers to stuff.  A good vendor would consider
shipping this stuff as part of the release ....

--Ed

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 89 00:29:17 GMT
From:      mike@jpl-devvax.JPL.NASA.GOV (Mike Tankenson)
To:        comp.sys.proteon,comp.protocols.tcp-ip
Subject:   PRONET-80 problems with high speed UDP streams

We have been having a problem with our PRONET-80 machines here at JPL, and
were wondering if anybody else had experienced such things.  If so, we'd
like to here from you regarding hardware/software failures, software bug
fixes, workarounds, etc.

The configuration looks like so:

[popeye]
   |
 [wc]
   |
 <<ring>>
   |
 [wc]
   |
[bluto]

Both popeye and bluto are Sun 3/260s, running SunOS 4.0.1, with PRONET-80
interface boards installed + driver software.  The version of the driver
software is 1.7, and the driver header file is 1.3.  Proteon maintains that
we are running the latest version of their software.  I don't have
information on the board revisions handy, but we only received them about 4
months ago.

Both Suns also have standard Ethernet drivers, but we don't see any
problems on the Ethernet side.  Neither of these Suns exhibit any other
problems (ie. we're pretty sure it's p80 related).

The problem description:

When sending UDP streams from one Sun to the other Sun, we panic crash the
receiving Sun with a 'panic: segkmem_badop'.  This is very repeatable.  In
fact, repeat by using the 'ttcp' program from BRL, and send a high speed
UDP stream from one Sun to the other.  The first session will complete Ok.
The next time that you try to start the 'ttcp' into receive mode:

	ttcp -r -u ... &

The Sun will panic crash.

Now when a small inter-record delay is placed between UDP packets, the
problem goes away.  This only appears to happen when large streams of
back-to-back UDP packets are sent to the Sun.  TCP streams work fine.

This does *not* happen when sending data over the loopback interface --
only when one Sun is sending to the other Sun.

Any helpful ideas would be welcomed.

Subject: PRONET-80 problems with high speed UDP streams
Expires: 
References: 
Sender: 
Reply-To: mike@devvax.JPL.NASA.GOV (Mike Tankenson)
Followup-To: 
Distribution: world
Organization: Jet Propulsion Laboratory, Pasadena, CA
Keywords: 


-- 
Mike Tankenson                      Telos/Jet Propulsion Laboratory/NASA
4800 Oak Grove Drive, Pasadena, CA.  91109           Mail Stop: 301-260a
Phone: (818) 354-1439
ARPA: mike@jpl-devvax.JPL.NASA.GOV  UUCP: seismo!cit-vax!jpl-devvax!mike

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 89 00:38:21 GMT
From:      mike@jpl-devvax.JPL.NASA.GOV (Mike Tankenson)
To:        comp.protocols.tcp-ip
Subject:   PRONET-80 problems with high speed UDP streams


We have been having a problem with our PRONET-80 machines here at JPL, and
were wondering if anybody else had experienced such things.  If so, we'd
like to here from you regarding hardware/software failures, software bug
fixes, workarounds, etc.

The configuration looks like so:

[popeye]
   |
 [wc]
   |
 <<ring>>
   |
 [wc]
   |
[bluto]

Both popeye and bluto are Sun 3/260s, running SunOS 4.0.1, with PRONET-80
interface boards installed + driver software.  The version of the driver
software is 1.7, and the driver header file is 1.3.  Proteon maintains that
we are running the latest version of their software.  I don't have
information on the board revisions handy, but we only received them about 4
months ago.

Both Suns also have standard Ethernet drivers, but we don't see any
problems on the Ethernet side.  Neither of these Suns exhibit any other
problems (ie. we're pretty sure it's p80 related).

The problem description:

When sending UDP streams from one Sun to the other Sun, we panic crash the
receiving Sun with a 'panic: segkmem_badop'.  This is very repeatable.  In
fact, repeat by using the 'ttcp' program from BRL, and send a high speed
UDP stream from one Sun to the other.  The first session will complete Ok.
The next time that you try to start the 'ttcp' into receive mode:

	ttcp -r -u ... &

The Sun will panic crash.

Now when a small inter-record delay is placed between UDP packets, the
problem goes away.  This only appears to happen when large streams of
back-to-back UDP packets are sent to the Sun.  TCP streams work fine.

This does *not* happen when sending data over the loopback interface --
only when one Sun is sending to the other Sun.

Any helpful ideas would be welcomed.

-- 
Mike Tankenson                      Telos/Jet Propulsion Laboratory/NASA
4800 Oak Grove Drive, Pasadena, CA.  91109           Mail Stop: 301-260a
Phone: (818) 354-1439
ARPA: mike@jpl-devvax.JPL.NASA.GOV  UUCP: seismo!cit-vax!jpl-devvax!mike

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 89 01:24:05 GMT
From:      arm@AQUA.WHOI.EDU
To:        comp.protocols.tcp-ip
Subject:   Is SHIPNET a good idea?

I am interested in forming an NSFnet style mid-level (regional) network
connecting oceanographic research vessels.  Members would include both
U.S. and international oceanographic research organizations.

Ships connected to the network would have high speed, direct access to
NSFnet, worldwide ARPA Internet sites, and other research vessels. I am
considering the use of a modified PODA protocol over a single satellite
frequency band.  It is the use of a single satellite channel that makes
this concept affordable.  Most large research vessels currently have
INMARSAT satellite earth stations installed onboard for voice/telex/fax
communications.  The earth stations can be upgraded for data support.

I have been talking to Steve Storch at BB&N about their previous
implementations of PODA for the SATNET, MATNET, and Wide Area Network.
The technology seems to be a good fit.  It might work equally well for
remote earth science research in places such as the Arctic and
Antarctic.  I am talking to OMNET about providing user services for the
network.  There is still a lot of work to do to make sure all pieces fit.

I am looking for people who can provide information on:

1) the use of PODA or other satellite protocols designed for use with
   the TCP/IP protocol suite.  We might consider support for DECNET, OSI,
   and other protocols at a later time.

2) specific oceanographic shipboard applications which would benefit
   from the network described above.

3) articles describing how satellites have been used successfully for
   ship-to-ship or ship-to-shore data communications, paying particular
   attention to the communications protocols employed.

I would appreciate help with any of these areas.  If you do respond,
please indicate whether you wish to be included in a future "shipnet" 
mailing list.

Thanks!

Andrew Maffei / Network Manager / Woods Hole Oceanographic Institution
INTERNET: arm@aqua.whoi.edu
SPAN:     AQUA::ARM
OMNET:    A.MAFFEI/OMNET

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 89 18:12:20 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Is SHIPNET a good idea?

Andrew,

You may wish to talk with Bob Kahn of NRI, Estil Hoversten and     of Linkabit
West (now Hughes), Dick Binder of MITRE and others of us who worked the
DARPA SATNET program some years back. When I worked this             at COMSAT on SATNET
I s  whacked my head on a bunch of la  INTELSAT and COMSAT lawyers to investigate
whether CPODA would be approp      an appropriate service to bring up on MARISAT and
found their chief objection to be how to refund customers for loa st packets
(I kid you not). MATNET as you know is a spinoff technology adapted to
shipboard use, but it seems to have been mired in cryptographic ooze.
Meanwhile, rack up your shipboard TNC and have a bang with SLIP at 1200
bps over an ordinary boice ci        circuit       voice circuit an  using amateur radio       packet-radio technology.

If you can o afford the calls.

Dave

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 89 22:01:48 GMT
From:      efb@suned1.Navy.MIL (Everett F. Batey II)
To:        comp.protocols.tcp-ip
Subject:   LOST on net 192.31.106, HELP

For nearly a month we have been trying real hard to get BACK onto
the internet.  We just started a dns server  .. the nic temporarily
el;iminated our aliases.  Then returned them.  

Coincident with the last fix we got restricted to the MILnet ONLY.  The
following was the latest sent to ACTION .. They apparently cant find what
happened .. we can talk to the .MIL domain, directly, ONLY.


  From: efb@suned1.Nswses.NAVY.MIL (Everett F. Batey II)
  Date: Thu, 28 Dec 89 21:37:29 PST
  Subject: Looks like net 192.31.106 is LOST again

  We recently introduced a DNS, engsun, net_.50, we intermittently lost
  our old aliases host.NAVY.MIL on three of the critical hosts.  The NIC
  fixed that for us.  We have devolved, in the past week, since the last 
  fix to the INVISIBLE net ( Net_192.31.106 ).  The only hosts we can
  exchange packets with are on the MILnet.

  Our nslookup, in diagnostic mode, reports we are getting good id's for 
  each regular ( non-MILnet ) host we try to ping, finger or telnet / ftp
  with.  Most non-MILnet ping or finger requests, end up with 'hostname:
  unknown host'  EVEN THOUGH the dns did a successful resolution.

  WE CAN connect to and exchange packets over internet with our SECONDARY,
  nosc.mil, with the NIC and other milnet sites.  ALL routes are via

  26.17.0.46      vaxb.navy.mil nswses.arpa vaxb.nswses.navy.mil

  Frankly, I can not imagine what I might have messed up that would allow
  me to reach MILnet hosts and NO OTHERS .. UNLIKE 10 to 12 days ago when
  I could reach the entire internet; neither can I imagine an internet
  failure mode that would make this happen unless we are removed from SOME
  of the core gateways.

  vaxb packet gate is a Wollongong VMS VAX 11/780. ( POC Martin Jordaan )
  engsun dns host  is a SunOS 4.0.3 Sun 3/60. ( POC Everett F. Batey II )
  suned1 mail host is a SunOS 4.0.3 Sun 3/60. ( POC Everett F. Batey II )

  ANY HELP will be very much appreciated.  /Everett Batey dns coordinator/

  /---/ principal hosts on net 192.31.106  /---/  

  192.31.106.1	nswses-gw nswses-gw.navy.mil nswses-gw.nswses.navy.mil 
  192.31.106.2	nswses-poe nswses-poe.navy.mil nswses-poe.nswses.navy.mil 
  192.31.106.3	vaxb vaxb.navy.mil vaxb.nswses.navy.mil vb 
  26.17.0.46      vaxb.navy.mil nswses.arpa vaxb.nswses.navy.mil
  192.31.106.20	tervax tervax.navy.mil tervax.nswses.navy.mil tv 
  192.31.106.40	suned1 suned1.navy.mil suned1.nswses.navy.mil s1 
  192.31.106.50	engsun engsun.navy.mil engsun.nswses.navy.mil eng 
  192.31.106.51	suned0 suned0.navy.mil suned0.nswses.navy.mil s0 
  192.31.106.55	suned9 suned9.navy.mil suned9.nswses.navy.mil s9 

  /---/ END of principal hosts on net 192.31.106  /---/  

}-- End of excerpt from TO: action@nic.ddn.mil@nosc.mil
 
-- 
   efb@suned1.UUCP efbatey@suned1.nswses.Navy.MIL efb@elroy.JPL.Nasa.Gov 
           Gold Coast Sun Local User Group | Vta-SB-SLO DECUS
      Statements, Opinions ... MINE ... NOT those of my US Employer  

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 1989 18:36-EST
From:      CERF@A.ISI.EDU
To:        CSYSMAS@OAC.UCLA.EDU
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Networks considered harmful
Michael,

the FAX is sent from a source telephone to a destination
telephone. Both identified by telephone numbers. The
reason the fax reaches YOU is that somebody is nice enough
to read the page and give it to you -0 or maybe you
have the machine dedicated on your desk. That's fine, too.

What's important as far as ease of use goes is that the
primary thing the sender needs to know to reach you is just
a telephone numer - and there are lots of ways to find that
out (though I note that white pages is of no help here because
people haven't begun listing their faxes in the white pages).

Vint Cerf
-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 89 20:49:21 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  LOST on net 192.31.106, HELP

Please check the routing on 26.17.0.46.  I can ping it from another milnet
host but not from a host off the milnet.  Once you get 26.17.0.46 fixed,
running EGP somehow, then need to worry about nameservice for navy.mil.
Who is running the DNS for navy.mil?

Phil Wood
Los Alamos National Laboratory

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 89 21:41:24 GMT
From:      van@HELIOS.EE.LBL.GOV (Van Jacobson)
To:        comp.protocols.tcp-ip
Subject:   beta version of compressed SLIP available

A beta version of the SLIP TCP/IP header compression software
I described at IETF and Interop-89 is available for anonymous
ftp from ftp.ee.lbl.gov (128.3.254.168).  There are two files
that might be of interest:
	
  compressed.slip.rfc.ps.Z -- is a compressed PostScript file
		containing a draft of the RFC describing the
		compression algorithm design and implementation.

  cslipbeta.tar.Z -- is a compressed Unix tar file containing
		an implementation of the header compressed SLIP
		that runs on most flavors of 4BSD, Sun OS 3.x
		and (sort of) Sun OS 4.  The tarchive also contains
		a copy of the draft RFC so YOU DON'T NEED TO FTP
		THE OTHER FILE if you grab this file.

Remember that these files have to be ftp'd in binary mode and
uncompressed with zcat or compress.

This is just a beta release -- a real release (integrated with the
Point-to-Point Protocol) should be available when (if?) the RFC
is published.  In other words: you probably don't want to play
with this code (see the first two paragraphs in the README
below.)

I apologize for getting this out four months later than I said I
would but teaching took an unexpectedly large amount of time
last quarter.  Hope people find this useful.  Have a happy new year.

 - Van

--------------- This is the README from the cslipbeta tarchive:

Berkeley, CA,  Sun Dec 31 08:54:07 PST 1989

This directory contains some experimental SLIP code that does
tcp/ip header compression & TOS queuing.  This is a beta test
version for hard-core network kernel hackers.  You don't want to
play with this code unless you're (a) comfortable hacking the
kernel and (b) familiar with your system's TCP/IP implementation.

If you get the code running on some new system, find and fix a
portability problem, or find and/or fix a bug, I very much want
to hear about it.  However, it you have trouble getting the code
up and want help, re-read the previous paragraph and wait for
the official, non-beta release.

Variants of this code have been run extensively under Sun OS 3.x
on Sun-3/whatever's; on HP9000/360s & 370s (68030 machines)
running Utah's 4.3bsd, all flavors of Vaxen running 4.2bsd,
4.3bsd and 4.3tahoe; on a CCI Tahoe running 4.4bsd and on a
Xylogics Annex terminal server.  The code has been run briefly
on various Sparc architectures (Sparcstation-1, 4/110, 4/280)
under Sun OS 4.0.3.  I have tested the compression code on an
HP9000/360 under HPUX, a DEC-3100 (PMax) under Ultrix 2.x and an
SGI Personnal IRIS.  However, I don't have access to HPUX,
Ultrix or SGI kernel source so I've never run the driver in
those kernels.  I seriously doubt it would work.  People at HP,
DEC and SGI have been beta-testing the code and they may one day
release whatever magic is necessary to run SLIP with their OS.

The pieces here are:

	draft.rfc.ps	a (postscript) draft of the RFC describing the
			protocol and its implementation.  You should
			read this before diving into the code.  It's
			complete so far as I know but the RFC editor
			might change any and everything in it before
			official publication.

	INSTALLATION	some notes on installing the slip code in
			your kernel.

	slcompress.[ch]	the compression code.  This should work on
			almost any BSD system with almost any if_sl.
			It should be trivial to modify it to work
			on non-BSD (e.g., ka9q) systems.  Other than
			use of the bsd ip.h, tcp.h, etc., header files
			for packet structures, I've tried to minimize
			bsd dependencies (see the discussion in app.A
			of the RFC).

	if_sl.c		a version of /sys/net/if_sl.c (the SLIP driver)
	if_slvar.h	that works under 4.3bsd, 4.3tahoe & Sun OS3.x.
			This is essentially the SLIP driver distributed
			with 4.3bsd-tahoe plus type-of-service queuing
			(i.e., telnet & rlogin packets have their own,
			high priority queue) and calls to the compression
			routines added.  There were also a couple of
			minor bug fixes & efficiency hacks added, together
			with #ifdef's for Sun OS3 / 4.2bsd.
			If you're rolling your own if_sl, just note
			where the calls to sl_compress_init,
			sl_compress_tcp and sl_uncompress_tcp are and
			plug the equivalents into your driver.
			Note that this will *not* work under Sun OS4--
			see notes below on the sunos4/ subdirectory.

	slattach.c	a version of slattach compatible with if_sl
			(it knows how to set the flags that enable
			compression, etc.).

	slstats.c	a "netstat -I"-like program to print out various
			performance stats kept in the driver.

	tester.c	a test program for checking that the compression
			code works on your machine.  This code reads a
			packet trace then compresses & decompresses each
			packet of the trace, making sure that the final
			decompressed version exactly matches the original.
			It also prints some stats (and compressed packet
			headers) on standard out.

			Before you start kernel hacking, you should make
			sure that the compression code compiles and runs
			in your environment.  Do "make tester" (which
			should also build slcompress.c), then
			  ./tester -v telnet.trace | diff telnet.ref -
			  ./tester -v ftp.trace | diff ftp.ref -
			 If slcompress.c is working correctly, there 
			 should be no output from either diff.

	sl.h		a (dummy) include file you'll need to lint things.

	telnet.trace	(binary) packet trace inputs for "tester" from
	ftp.trace	 a telnet & ftp session, respectively.

	telnet.ref	what the "tester -v" output for telnet.trace and
	ftp.ref		 ftp.trace should look like (i.e., how they look
			 on my machines).

	timer.c		a test program, script and packet trace I've
	timer.sh	used to make timing measurements on the
	timer.trace	compression code.  I would be interested in
			the results of your running this so I can
			add more times to the RFC.
	
	sunos4/		(Minimal) support for header compression in
			the Kingston/Zachariassen "streams" SLIP driver
			for SunOS 4.x.  See the README file is this
			directory for notes.


Good luck.  Let me know about problems, suggestions, etc.

 - Van Jacobson, Lawrence Berkeley Laboratory
   van@helios.ee.lbl.gov

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 89 23:36:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Networks considered harmful

Michael,

the FAX is sent from a source telephone to a destination
telephone. Both identified by telephone numbers. The
reason the fax reaches YOU is that somebody is nice enough
to read the page and give it to you -0 or maybe you
have the machine dedicated on your desk. That's fine, too.

What's important as far as ease of use goes is that the
primary thing the sender needs to know to reach you is just
a telephone numer - and there are lots of ways to find that
out (though I note that white pages is of no help here because
people haven't begun listing their faxes in the white pages).

Vint Cerf

END OF DOCUMENT