|
|
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 codeAnyone 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 hangingTry 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 issueBrian, 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 sunHi 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 harmfulYes, 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 helpfulHere 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
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |