----MESSAGE-BEGIN---- <1990090107493200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 4 Sep 90 20:01:54 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17444; Tue, 4 Sep 90 19:48:49 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Sep 90 07:49:32 GMT From: mips!zaphod.mps.ohio-state.edu!usc!orion.oac.uci.edu!mothra.nts.uci.edu!meggers@apple.com (Mark Eggers) Subject: proxy arp Message-Id: <26DF680C.6030@orion.oac.uci.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Is there anywhere I can get proxy arp that will run on a Sun 4 ?? thanks - /mde/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090108283500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 4 Sep 90 19:49:06 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16470; Tue, 4 Sep 90 19:37:59 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Sep 90 08:28:35 GMT From: olivea!tymix!cirrusl!sungraph!dhesi@apple.com (Rahul Dhesi) Subject: Re: sockets vs. streams Message-Id: <2350@cirrusl.UUCP> References: <6964@milton.u.washington.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In <6964@milton.u.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: >If "network I/O looks like local device I/O" under Unix then when the >h*ll do I have to worry about all the socket or streams crap? I think the confusion in this discussion is between reading and writing on the one hand and opening the connection on the other hand. Once a virtual circuit has been set up, the socket mechanism becomes transparent to the extent networking will allow. Setting up the virtual circuit does require more steps than opening a device or file. I find this fairly understandable, because the BSD socket interface gives you LOTS of options, and it was designed to be independent of the underlying transport mechanism. >If I want to connect to port 0.143 on host 128.95.112.69, why can't I >do something like > open ("/tcp/128.95.112.69-0.143",O_RDWR|O_CREAT,0);... Like somebody said, it would be nice if there was a library routine that would make this easy. I suppose the open() system call could also do this, but then there might be too much functionality in a single system call, because it would have to understand all possible protocols and possibly accept additional parameters for the different types of sockets and connections that are possible. Quick! Get a copy of Stevens's book on UNIX network programming. The socket mystery will be gone for ever. -- Rahul Dhesi UUCP: oliveb!cirrusl!dhesi ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090112355900> Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sat, 1 Sep 90 18:28:44 PDT Received: by uunet.uu.net (5.61/1.14) with UUCP id AA23090; Sat, 1 Sep 90 19:18:46 -0400 Received: by world.std.com (5.61++/Spike-2.0) id AA08202; Sat, 1 Sep 90 19:15:59 -0400 Date: Sat, 1 Sep 90 19:15:59 -0400 From: bzs@world.std.com (Barry Shein) Message-Id: <9009012315.AA08202@world.std.com> To: tcp-ip@nic.ddn.mil In-Reply-To: (David L Stevens's message of 31 Aug 90 21:31:44 GMT <13526@mentor.cc.purdue.edu> Subject: sockets vs. streams Why does everyone assume this topic is so heated? I think the discussion is long overdue and we'd all benefit from getting it out in the open (or is that in in the open()?). I'm mixed on this issue. TOPS-20 had a file-system-like interface (was that BBN's TCP?) and, to be frank, I found it quite clumsy (tho interesting.) The string one passed to the open call started to look more and more like a long string of IBM/JCL and less and less like a file name as various options were added. In MRC's example, the fact that the connection was active or passive was passed via the flags field (O_CREAT in the example.) That removes a lot of the utility; I can't specify it on a command line easily, passing what I want transparently thru a utility that otherwise doesn't really know it's doing network I/O. That should be a major goal if we are going to bother at all. But that leads to things like: "/dev/tcp/active/192.74.137.5/143/debug=true/...." or something like that. I guess one could say "so what, at least you can do it!" (and, in fact, I don't have a good response to that!) As to David Stevens questions about file system semantics, what does "cd /dev/anydev" mean now? Nothing, you get back "Not a directory". In this mythical TCP you might get back something (e.g. some form of NFS done this way), or not. I don't see that as a serious problem. Again, with "ls /tcp" it could be treated like a device, in general nothing happens (you get back info about just "/tcp".) One could imagine more being done, but that's an acceptable start. Seek, urgent data etc, none of that stuff works on every device. I see you're focusing on the filesystem aspect. It's not that TCP *is* a filesystem, it's that you can address it with the naming conventions of the filesystem. I suppose a counter-argument is why then can't I: open("/dev/tty06/9600/cbreak/noecho/xtabs/even/nonl",...) I dunno, why not? I'm also not convinced that anything that's happened thus far is mutually exclusive to a filesystem-like interface. Perhaps it would be too bad to have two similar interfaces, but that's the worst that could happen. In fact, it could be implemented right now. Just write a library with some of the necessary syscalls written at user-level to recognize names like this (or if they look like regular files then pass them on to the kernel) and see how it works. This is kids' stuff, if anyone wants to know how or doubts it can be done send me mail. You don't have to touch the kernel to do this (at least not to do a proto.) On systems with shared libraries it could even be made to work with existing binaries (tho that can get "exciting", but no big deal if you have an extra disk to boot off of for experimenting.) I think there was a project out of Purdue several years ago which did just this (I forget the name.) I remember playing with some software from there which did something like this, all user level. Or maybe I was writing it...hmmm. My experienced guess is that as one puts it all together all sorts of problems will arise and it'll tend to get kludgier and kludgier as more crap is added to that string to make it work. Maybe I'm wrong, but an experiment is easy enough. I can't see why someone who was terribly interested wouldn't just demo a prototype and write a paper for all of us to read (perhaps first verifying that it hasn't been done a half-dozen times before, possibly reporting where the disappointments existed.) -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090116444400> Received: from mcsun.EU.net by NIC.DDN.MIL with TCP; Sun, 2 Sep 90 08:22:02 PDT Received: by mcsun.EU.net via EUnet; Sun, 2 Sep 90 17:21:54 +0200 (MET) Received: from castle.ed.ac.uk by kestrel.Ukc.AC.UK via Janet (UKC CAMEL FTP) id aa01356; 2 Sep 90 16:16 BST Received: from spider.co.uk by castle.ed.ac.uk id aa09745; 2 Sep 90 16:16 WET DST Received: by widow.spider.co.uk; Sat, 1 Sep 90 16:44:50 +0100 From: Nick Felisiak Message-Id: <8116.9009011544@redrump.spider.co.uk> Received: by redrump.spider.co.uk; Sat, 1 Sep 90 16:44:46 +0100 To: tcp-ip@nic.ddn.mil Date: Sat, 1 Sep 90 16:44:44 WET DST Subject: Re: Are sockets the wave of the future X-Mailer: Elm [version 1.5b] In article <2117@rossignol.Princeton.EDU> Tom Reingold writes: > At my job, we are about to write some applications for running over > TCP/IP on Unix hosts. We would like to think ahead with portability in > mind. One day, our code may run on a non-unix host. And if we write > it in sockets, we may run against a version that is built upon and > supports only STREAMS. Or will we? > 1. What implementations are built on STREAMS? There are three that I know of, and probably several that I don't. I'm not trying to be exahustive below! 1. Lachman/Interactive - this originated from Convergent Technology, and is widely used on 386 machines. 2. Wollongong - used by AT&T. 3. Spider - used by Prime, Olivetti (In the UK), etc. > 2. Are they new or old? Spider's was done specifically for streams - i.e the kernel code is not based on BSD! > 3. Are all TCP/IP suites done with sockets nowadays? I think all the UNIX products offer both sockets and TLI. > 4. Is there a reason to consider implementing our code in STREAMS? If it's application level code, this is largely irrelevant. > 5. Currently, our hosts run System V release 3.[23] and have both > libraries. Which is "the way" to go? I discuss my biases below. In article <1990Aug24.220021.10122@murdoch.acc.Virginia.EDU>, Ran Atkinson continues: > The network interfaces specified by the System V Interface Definition > and by the X/Open consortium are based on the STREAMS with TLI (Transport > Level Interface) that were originally developed at AT&T. (What follows may be considered controversial!) TLI is firstly very ISO-oriented, and secondly half a specification. This causes the TCP interface user a number of problems. The ISO-orientation means that certain things which TCP wants to do are just impossible. There is no equvalent to the 'getpeername()' call, for instance. Inetd style servers cannot, therefore, discover where they are being called from (if they care) using TLI as defined. The 'half-a-specification' aspect refers to the lack of a 'standard' for address formats, name services, etc. In the TCP world, I think everyone has gone for the Berkley 'sockaddr' structure as the address structure used in t_bind, etc. Lucky there was a standard already there! I've seen one implementation (can't remember who's) which took a host name and port number as ASCII strings - which is probably more in the spirit of TLI. I never found out if they had put the whole of the resolver library into the kernel, or what they did about specifying the remote address on a connect indication. I have a long list of shortcomings of TLI - mail me if you're interested! > Since the System V socket-library is built on top of STREAMS/TLI, > an application written to use sockets will probably be slower on > a System V system that the same application written using STREAMS/TLI > natively. In general I think that the STREAMS/TLI approach is better > because details of the transport protocol used are appropriately hidden > unlike BSD sockets. Not true. TLI does not provide a super-set of the Socket interface, and so building a compatible socket interface on top of TLI is not possible. We (Spider) have a 'socket library' which uses ioctl calls (in the main) to our TCP driver, which also understands the TLI messages (TPI at that level). I really don't see how details of the transport protocol are hidden by TLI. You still need to code up name to address translation (almost certainly using 'gethostbyname' type calls), and probably implement the TLI counterpart to 'setsocketoptions' differently for each vendor's TCP/TLI that you try to work with, since there is no standard specified for such things as keep-alive, no-delay, IP options, etc. The socket model, on the other hand, provides a de-facto standard for all these things. > Certainly a lot of good software is out there using sockets and I don't > think that the socket library will disappear anytime soon, but for new > software I really think that STREAMS/TLI are a better approach -- > especially if developing for a System V platform. There have already been a few changes to TLI since it first appeared, and I expect there will be more. The socket interface, on the other hand, is pretty stable. I've ported code from BSD systems to Sys-V using our socket interface without any problems in the networking area. It's worth considering that most of our ISO product customers require a socket interface along side TLI as well! The presence of ISO in BSD4.4 will go a long way to establish the 'standard' for this interface. Usual disclaoimers apply. Nick Felisiak nick@spider.co.uk Spider Systems Ltd +44 31 554 9424 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090123441300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 4 Sep 90 21:34:57 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25485; Tue, 4 Sep 90 21:18:10 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Sep 90 23:44:13 GMT From: shelby!msi-s0.msi.umn.edu!cs.umn.edu!uc!shamash!vtcqa@decwrl.dec.com (Jeff Comstock) Organization: Control Data Corporation, Arden Hills, MN Subject: Re: KA9Q by Bdale Garbee Message-Id: <25346@shamash.cdc.com> References: <9008280020.AA17723@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9008280020.AA17723@ucbvax.Berkeley.EDU> CLEBER%SBU.UFRGS.ANRS.BR@UICVM.UIC.EDU writes: > > Could anyone tell me if KA9Q Internet Software Package source >code is available. If yes, what's the places that i can get it >by FTP. > Thanks in advance, > Cleber Weishheimer. Although Bdale Garbee is a contributor to the KA9Q package, KA9Q is actually Dr. Phil Karn. Bdale is N3EUA. Anyway, the latest bits from Phil (KA9Q) are on thumper.bellcore.com in the directory pub/ka9q/nos . You will also find a reference manual there. Thumper is the machine that Phil puts his latest source and exe files. In case you don't know what N3EUA and KA9Q mean, they are amateur radio callsigns. The primary purpose of the KA9Q package is to allow radio amateurs to network computers via packet radio. Jeff Comstock - NR0D ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090203003300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 4 Sep 90 16:52:22 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04937; Tue, 4 Sep 90 14:49:44 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Sep 90 03:00:33 GMT From: world!bzs@bloom-beacon.mit.edu (Barry Shein) Organization: The World Subject: Re: Muhammad Jefferson Gets Honky Hate Mail Message-Id: References: <1990Aug30.200853.24851@salt.acc.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Let's help Mr. Macri exercise his freedom of speech and widen the distribution of his gems. >Xref: world soc.singles:21005 alt.sex:15390 >Path: world!bloom-beacon!snorkelwacker!apple!salt.acc.com!claude >From: claude@salt.acc.com (Claude Macri) >Newsgroups: soc.singles,alt.sex >Subject: Re: Muhammad Jefferson Gets Honky Hate Mail >Message-ID: <1990Sep1.012542.25352@salt.acc.com> >Date: 1 Sep 90 01:25:42 GMT >References: <1990Aug30.200853.24851@salt.acc.com> >Reply-To: claude@salt.acc.com (Muhammad Jefferson) >Distribution: na >Organization: Advanced Computer Communications, Santa Barbara, California >Lines: 50 > > >Yo, I just got some more racist trash, this time from >some phoney liberal white dude from that uptown candy-assed >rich school that caters to a bunch of temporary liberals -- >Stanford University. (After they get their white asses out of >school and have to lounge around for an easy living at daddy's >doorstep, they stop votin for racial progress, and start votin against >social programs that favor the oppressed minorities.) > >Here's what the dude in his holy white robe had to say: > >>Please stop. You're just a minor irritant, but the kind of >>garbage you trade in is fucking up years of progress. > >Hey man, yous a real pain in my ass, too, and what kind of progress >are you talking about, man? Affirmative Action?? That shit >just goes to middle class light-skinned Toms. Those brothers >are muthas. Those are the cats who get the affirmative >action that the ladies hand out, too. Meanwhile the brothers >who are true and black only get crime, clap, and crack. > >>If you're >>black, then you must be a plant for the klan, trying to brew a >>conflict out of nothing. > >Really, my pigment is closer to mahogany than black, but >I just say I'm black because that color is so popular with the >artsy white ladies. > >>If you're not black, I don't even know what >>to say. Read some African-american history. > >Sheeit. Read some history by a bunch of wealthy white dudes? >The dudes who make history don't write it, and the dudes who >write it don't make it, they fake it. >Hey man, none of my friends have enough money to sit around >typin on a computer for a livin. We too busy >survivin in the neighborhoods you liberals drive through with >the windows rolled up on your way to your suit and tie lounge- >chair jobs. > >Next thing you liberals will want is Affirmative Action programs >in basketball. Pretty soon the Lakers will be forced to >have some incompeten white dudes again, and even Japanese dudes >-- maybe even some ladies. > >Hmmmmm? Come to think of it, maybe this >Affirmative Action shit aint so bad after all. > >Muhammad Jefferson -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090203385800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 4 Sep 90 21:39:56 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26029; Tue, 4 Sep 90 21:23:18 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Sep 90 03:38:58 GMT From: unisoft!hoptoad!pacbell!pacbell.com!mips!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucbvax.Berkeley.EDU (Edward Vielmetti) Organization: University of Michigan Math Dept., Ann Arbor MI. Subject: Re: Long lines... Message-Id: References: <9008311254.AA03868@mcsun.EU.net>, <9008311421.AA08486@mcsun.EU.net> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9008311421.AA08486@mcsun.EU.net> Piet.Beertema@MCSUN.EU.NET writes: Right, that's what I expected: it's just a technical problem (a gateway not announcing a route). In other words: there was no need to send this problem to an extremely wide-reaching mailing list. Contacting the managers of the first gateway (@inria) could have solved the problem... Anyway, we'll go after it and inform the people involved. Well, maybe yes, maybe no. I think that discussions of this sort are extremely interesting, and it is useful to draw the attention of the international community to such events. This is the first I had heard of such behavior europe->usa->europe; previously someone saw a usa->europe->usa hop. There is an IETF working group (the Topology Engineering Working Group) which has in the past looked into these things; intercontinental networks are more and more interesting all the time. I'm waiting for the first report of usa->europe->japan->australia, myself. --Ed Edward Vielmetti, U of Michigan math dept ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009050500.AA29272@ucbvax.Berkeley.EDU] <1990090208595500> From: HANK@BARILVM.BITNET (Hank Nussbacher) Newsgroups: comp.protocols.tcp-ip Subject: Multi-protocol router scorecard Message-ID: <9009050500.AA29272@ucbvax.Berkeley.EDU> Date: 2 Sep 90 08:59:55 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 436 Posted: Sun Sep 2 09:59:55 1990 CAVEATS ------- The following scorecard tries to compare various multi-protocol routers. The current scorecard mainly contains information for cisco and Wellfleet but any other vendor is welcome to send me a complete set of manuals for their equipment so that I can analyze and update the scorecard. The fact of the matter is that certain features and "gotchas" only appear when testing the actual equipment. I hope that the user population of multi-protocol routers will assist me in making this scorecard as comprehensive as possible so that people who follow do not have to go through what I have gone through. It was difficult to decide whether to include future release notes in this scorecard. I trust the user population in the Internet to take each promise for a "future feature" with a grain of salt and to keep watch on the vendors that indeed they follow through with their promises. All too often vendors state certain features will be available in a certain release and sometimes their deadlines slip. It is advised that people should not base their decisions on the future release notes. [That was a long caveat]. If you have comments, suggestions, additions, or subtractions or corrections, please send them to: HANK@VM.TAU.AC.IL or HANK@TAUNIVM.BITNET (but not to both!) The scorecard will be updated on a monthly basis. If you read this report and are not connected to the Internet, you can send your comments to: Hank Nussbacher Computer Center Tel Aviv University Ramat Aviv Israel This report may be freely reproduced, as long as it is not altered in any sort of way. [The above employer has nothing to do with this scorecard so if something bothers you about it, I take full responsibility.] END OF CAVEATS -------------------------------------------------------------------- Distribution: cisco@spot.colorado.edu wellfleet@nstn.ns.ca tcpip@nic.ddn.mil ripe@mcsun.eu.net p4200@devvax.tn.cornell.edu Usenet: comp.dcom.lans -------------------------------------------------------------------- Comparison of Multiprotocol Routers Henry Nussbacher August 1990 Version 1.5 +--------------+--------------+---------------+ Multiprotocol | cisco AGS+ | Wellfleet LN | Proteon p4200 | Router | Rel. 8.1(14) | Rel. 5.35 | | +--------------+--------------+---------------+ 1. General | | | | - # of slots | 9 | 4 | | - Processor | 68020 | 68020 | | - Memory | 4Mbyte | 4Mbyte | | - Updates via | ROM, TFTP | diskette,TFTP| | - Speed of bus | 530Mb/sec (a)| 320Mb/sec | | - Boot from | | | | - ROM | Yes | No | | - Net-boot | | | | - IP | Yes | No | | - Decnet (MOP) | No | No | | - Diskette | No | Yes | | - Another router | Yes | No | | - Volatile changes | Yes (b) | No | | - CPU statistics | Yes (c) | No | | - Memory stats | Yes | No | | - Ease of install | Very easy | menu driven | | - Documentation | Difficult | Skimpy | | - Autorestart (d) | Yes | Yes | | - Restart for | | | | config changes | No | Yes | | - Watchdog timer | Yes | | Yes | - Reboot time (e) | 29 sec (f) | 120-600 sec | | - Power-up time (g)| 29 sec | 120-600 sec | | Notes: a. Speed of old AGS bus is 160Mb. b. Volatile changes represents the ability of the router to accept a configuration change that is dynamic that only affects the current running system and once the system is rebooted, the change disappears. c. CPU statistics refers to the ability of the router to provide a monitoring facility to see what the CPU is doing and how often it is doing it. d. Autorestart in the event of a power failure. e. Reboot time refers to the amount of elapsed time needed to perform a logical restart (reboot) from the fastest available media. f. cisco timings are for older AGS system. g. Power-up time refers to the amount of elapsed time needed from the time of a power failure and recovery until the router is up and operational. 2. Interfaces (a) | | | | - Ethernet | | | | (802.3 10Base5) | 24x10Mb | 8x10Mb | | - Thin Ethernet (b)| | | | (802.3 10Base2) | No | 8x10Mb | | - 4Mb Token Ring | 4x4Mb | 4x4Mb | | - 16Mb Token Ring | Rel 9.0 | Rel 5.40 (c) | | - RS232 | 24x64kb | 16x64kb | | - RS449 | 12x64kb | 16x64kb | | - V.35 | 12x64kb | 16x64kb | | - T1 | 12x1.544Mb | 8x1.544Mb | | - CEPT DS1 (2Mb) | 12x2Mb | 8x2Mb | | - FDDI | 2x100Mb | Rel 5.5 (d) | | - DAS (Dual) (e)| Yes | Yes | | - SAS (Single) | Yes | No | | - X.25 | | | | - Max # of VCs | Unlimited (f)| 254 | | - Card types (g) | 4E, 1E2S, | 2E, 1E1S, | | per slot | 2E2S, 4S, | 1E2S, 2E2S, | | | | 1TR2S, 4S | | | | 1TR | | Notes: a. Each interface subsection represents the maximum number of LANs or WANS that can be configured for that particular subsection. It is possible to "mix and match" various subsections by reducing the upper limit. b. Thin Ethernet refers to a standard BNC connector available directly on the router. c. 4x16Mb. d. 1x100Mb. e. Dual is also known as Type A and Single is also known as Type B. f. Depends on memory limitations. g. Card types: E: Ethernet, S: Serial/Synchronous line TR: Token-Ring 3. Interface part II | | | | - Frame Relay (a) | Rel 8.2 | | | - Ethernet | | | | encapsulation | | | | - Standard v2.0 | Yes | | | - IEEE 802.3 | Yes | | | - SNAP 802.2 | | | | (RFC1042) | Yes | Yes | | - Serial | | | | encapsulation | | | | - HDLC | Yes | | | - LAPB | Yes | | | - PPP (RFC1134) | Yes | | | - DDCMP | No | No | | - X.25 | Yes | | | - SVC | Yes | Yes | | - PVC | Yes | Yes | | - Encryption (b) | Pulse-time | | | - Filtering by | | | | source/dest | Yes | Yes | | Notes: a. CCITT standards Q.931 (Frame Relay) and I.122 (Lap-D) b. Encryption refers to the ability of the router to compensate for encrypting devices on various interfaces or circuits. 4. IP | | | | - Subnetting | | | | (RFC950) | Yes | Yes | | - ARP (RFC826) | Yes | Yes | | - RARP (RFC903) | Yes | No | | - BOOTP (RFC951) | Yes | No | | - proxy ARP | | | | (RFC1027) | Yes | Yes | | - ICMP | Yes | Yes | | - Name-server | Yes | No | | - Accounting | Yes | No | | - MTU | Yes | No | | - Security - IPSO | Yes | No | | - Static routing | Yes | Yes | | - Source routing | Yes | No | | - Filters | | | | - source/dest | Yes | Yes | | - TCP | Yes | | | - UDP | Yes | | | - ICMP | Yes | | | - by protocol (b)| Yes (a) | Yes | | - Routing protocols| | | | - RIP (RFC1058) | Yes | Yes | | - EGP (RFC904) | Yes | Yes | | - BGP (RFC1105) | Yes | No | | - Proprietary | IGRP | eRIP | | - Filtering | Yes | No | | - Default routes | Yes | Yes | | - OSPF | Rel 9.0 | Rel 5.6 | Yes | Notes: a. Can be done but is difficult and requires advanced knowledge of the specific protocols. b. Filtering by protocol can also be viewed as filtering by port number. 5. DECNET | | | | - Phase IV Router | Yes | Yes | | - Area Router | Yes | No | | - Phase IV+ (a) | Rel 8.2 | No | | - Phase IV-V | | | | Transitional gty | Rel 8.2 | | | - Phase V | Yes (b) | No | | - Address xlation | | | | gateway (c) | Yes | No | | - NCP | | | | - area-max-cost | Yes | Yes | | - area-max-hops | Yes | Yes | | - max-address | Yes | Yes | | - max-area | Yes | Yes | | - max-cost | Yes | Yes | | - max-hops | Yes | Yes | | - max-visits | Yes | Yes | | - router-priority| Yes | Yes | | - hello-timer | Yes | Yes | | - routing-timer | Yes | Yes | | - Filtering | | | | - source/dest | Yes | No | | - by protocol | No | No | | - by object | No | No | | - routing | Yes (d) | No | | - MOP | Bridged | Bridged | | - Static routing | No | No | | - Max routing table| 1023 | 1023 | | - Max # of broad. | | | | router adjencency| 32 | | | Notes: a. Phase IV+ refers to path-split capability. This means "normal" and not "interim". Normal allows out-of-sequence packets to arrive. Interim does not allow out-of-sequence packets to arrive. b. cisco claims that it's ISO CLNS support is compatible with Decnet Phase V. c. Address Translation Gateway is the ability to connect two separate Decnet networks with overlapping addresses. d. It is not possible to filter out of area addresses. It is only possible to filter an entire area or addresses within one's area. 6. Bridging | | | | - Local bridging | Yes | Yes | | - LAVC (a) | Yes | Yes | | - Remote bridging | Yes (b) | Yes | | - Transparent | | | | - Learning | Yes | Yes | | - Spanning tree | | | | (IEEE 802.1) | Yes | Yes | | - Priority (c) | Rel 8.2 | No | | - Filtering | | | | - Multicast | Yes | Yes | | - Protocol | Yes | Yes | | - Source/dest | Yes | Yes (g) | | - Masking (d) | No | No | | - Load sharing | Yes (e) | Yes | | - Token Ring | | | | - Source route | Yes | | | - Multi-ring (f) | Yes | | | Notes a. LAVC refers to the ability to act as a local bridge between two Vax clusters using the DEC LAVC protocol. b. cisco does not support bridging over X.25 or LAPB. c. Priority refers to the ability to assign a priority to a specific protocol so that that protocol is sent faster than any other protocol over a specific circuit/interface. d. Masking refers to the ability to specify some pattern string to be matched within the packet, so that the user can specify almost any filter. e. cisco load sharing (balancing) is on a per-node basis and not on a per packet basis. That means that over 2 parallel serial lines the cisco will automatically allocate 50% of the learned Ethernet addresses to one line and the other 50% to the other line. f. Multi-ring refers to bridging between multiple Token Ring networks (all hosts must understand RIF). g. Wellfleet can only filter on destination address and not on source address. 7. Other protocols | | | | (ability to route) | | | | - XNS | Yes (a) | Yes | | - UB derivitive | Yes | | | - Appletalk | | | | - Phase 1 | Yes | Yes | | - Phase 2 | Rel 8.2 | Rel 5.40 | | - Tokentalk | Rel 8.2 | Yes | | - Ethertalk | Yes | Yes | | - Localtalk | No | | | - RTMP | Yes | Rel 5.40 | | - AARP | Yes | Rel 5.40 | | - NBP | Yes | Rel 5.40 | | - EP | Yes | Rel 5.40 | | - ATP | Yes | | | - ZIP | Yes | Rel 5.40 | | - DDP | Yes | Yes | | - ISO | | | | - ISO 8473 CLNP | Yes | No | | - ISO 9542 ES-IS | Yes | No | | - Apollo Domain | Yes | No | | - Novell IPX | Yes (a) | Yes | | - X.25 | Yes | Yes | | - bridging | Rel 9.0 | Yes | | - routing | Yes | Yes | | - switching | Yes | Yes ??? | | - Security | Yes (b) | | | Notes: a. With cisco equipment, if there are both Ethernet and Token Ring interfaces, then DECnet cannot be run simultaneously with either Novell IPX or XNS. This restriction will be removed in Release 8.2. b. cisco provides filtering/permitting/denying certain packets only for IPX, XNS and Appletalk in the section listed above. 8. Management | | | | - Central managed | Yes | Yes | | - SNMP | | | | - Platform | Sun 3, Sparc | Sun 3 | | - DEC EMA (a) | No | Yes (a) | | - External | | | | software (b) | No (c) | No | | - X netmap | Yes | Yes | | - Telnet to | | | | device (d) | Yes | No | | - X interactive | Yes | | | performance | | Yes | | - History stats | Yes | No | | - Report writer | Yes (c) | No | | - Alerts (e) | No | No | | - User defined | | | | extensions (m) | Yes | No | | - Usage stats | Yes | Yes (f) | | - Direct MIB access| No | Yes | | - PING | Yes | Yes (g) | | - Telnet | Yes (h) | Yes (i) | | - MOP Remote Cons. | Rel. 8.2 | Bridged | | - NICE (j) | No | No | | - Decnet connect | No | No | | - Passwords (k) | Yes | Yes | | - Netview support | | | | - Disable lines | | | | dynamically | Yes (l) | Yes | | Notes: a. DEC EMA refers to the product's intent to support the DEC Enterprise Management Architecture in the future. No release version has been mentioned yet for this feature. b. External software refers to the need to have some external software package available in order to run SNMP monitoring. c. cisco requires the Sybase database system in order to run their NMS software. This package is bundled with their NMS. d. Ability to click on an icon on the X-11 network map and open a telnet connection to the device in question. e. Alerts refers to the ability to define a preset limit for a specific MIB variable at which point the SNMP monitoring software will present a window on top of the network map informing the network operator of the problem. f. Wellfleet interactive usage statistics are only for (ISO model) level 2. Upper level statistics (such as RIP, UDP, TCP, Decnet HELLO, ARP) are not available. g. Wellfleet PING command stops after first failure and waits for user response. This makes it very hard to check the total percentage of line failures over a short period of time. h. cisco is limited to 5 incoming Telnet sessions but has no limitation on outgoing Telnet sessions. i. Wellfleet Telnet is limited to one incoming and one outgoing session. j. NICE refers to the ability of the router to accept "SET EXECUTOR" as well as initiate a "SET EXECUTOR" to a remote host. k. Passwords refers to the ability to limit certain configuration and customization options only to those users who supply a password. l. cisco command is not an EXEC command but actually requires a configuration change to disable a line. m. The ability for the NMS software to add other vendor MIBs to their database, in order to manage these particular hardware units. 9. Debugging & | | | | Monitoring | | | | - Data-Link Layer | Yes | Yes | | - LAN | Yes | Yes | | - Link | Yes | Yes | | - Decnet | Yes | Yes | | - Tcp/Ip | Yes | Yes | | - Event log | Yes | Yes | | - Environmentals | Yes | No | | Notes: a. Environmentals refers to the monitoring of variables such as fan, power supply, memory, temperature, etc. 10. Performance (a) | | | | - Router forward | 2917 (b) | 3757 (c) | 902 | - Router filter (d)| 2279 (b) | 3757 | 902 | - Bridge forward | | | | - Bridge filter | | | | - LAT compression | Yes | No | | Notes: a. Performance based on 256 byte packets, between separate interface cards, with no packet loss. Numbers listed are in packets per second. Numbers based on Bradner report, Harvard University, Sept 1989. A revised benchmark is expected sometime in Sept 1990. b. cisco performance numbers based on AGS and CSC2 hardware. c. Wellfleet numbers may be higher but equipment was not able to generate packets faster than the LN. d. Filter is based on 10 packet filters enabled. 11. Survivability | | | | - alternate power | | | | supply | No | Yes (d) | | - standby line (a)| No | No | | - fault tolerant(b)| No | No | | - field tolerant(c)| No | No | | - broadcast storms | Yes | No | | Notes: a. Standby line refers to the ability to define a line that is to be a hot standby, in the event that the primary line goes down. The software switches all traffic automatically to the backup line. b. Fault tolerant refers to having redundent systems that are normally in standby mode, and that are only called into active mode in the event that the primary system fails. Various systems are the power supply, the fan, the bus, the controller cards, etc. c. Field tolerant refers to the ability to withstand harsh elements and conditions out in the "field." d. Alternate power supply only available in large Concentrator model. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090211011800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 4 Sep 90 23:35:13 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07047; Tue, 4 Sep 90 23:24:48 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Sep 90 11:01:18 GMT From: sdd.hp.com!samsung!munnari.oz.au!metro!pta!yarra!chris@ucsd.edu (Chris Jankowski) Organization: Pyramid Technology Corp PL, Melb., Australia Subject: "The Open Book" by Rose - your opinions sought Message-Id: <65137@yarra.oz.au> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil From RFC1175: Rose, Marshall T., The Open Book: A Practical Perspective on OSI, 651 pgs., Prentice Hall, Englewood Cliffs, NJ, 1989. This is a comprehensive book about Open Systems Interconnection (OSI). In particular, this book focuses on the pragmatic aspects of OSI: what OSI is, how OSI is implemented, and how OSI is integrated with existing networks. In order to provide this pragmatic look at OSI the book makes consistent comparisons and analogies of the OSI pieces with the TCP/IP suite of networking protocols. What do you think about the book? Is it worth buying? What I am after is a book which would be an equivalent of the Comer's book on Internet but obout OSI. How would you compare it with the Comer's book on Internet? Is it similar in style, depth, objective and clarity? I'll summarise if enough responses received. Thank you. -m------- Chris Jankowski - Senior Systems Engineer chris@yarra.oz{.au} ---mmm----- Pyramid Technology Corporation Pty. Ltd. fax +61 3 820 0536 -----mmmmm--- 11th Floor, 14 Queens Road tel. +61 3 820 0711 -------mmmmmmm- Melbourne, Victoria, 3004 AUSTRALIA (03) 820 0711 micron n. - a unit of length of one milionth of a meter, worth $2,000,000,000 since the fault in the Hubble space telescope mirror has been identified. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090211490000> Received: from SPICE.CS.CMU.EDU by NIC.DDN.MIL with TCP; Sun, 2 Sep 90 19:02:38 PDT Date: Sun, 2 Sep 1990 15:49-EDT From: Alessandro.Forin@SPICE.CS.CMU.EDU To: tcp-ip@nic.ddn.mil Subject: Re: OS network interfaces (was: sockets vs. streams) Message-Id: <652304954/af@SPICE.CS.CMU.EDU> In-Reply-To: Barry Shein's mail message of Sat, 1 Sep 90 19:15:59 -0400 The multiserver Mach 3.0 [and other systems such as Plan9, for instance] place indeed much more semantics in filesystem names. For networking, we have a Network Protocol Server (NP) that contains the protocol code and talks to the ether device (or whatever) at the packet level. It's NP's business what names mean. It's independent of the OS environment (streams, sockets whatever) what is the interface that NP exports to other servers and to the U*x emulation library. [Right now it's just the socket BSD interface, cuz we did it 2 years ago quickly just to see if the thing was plausible] What I am interested in for the second round implementation is what would be the most flexible interface for NP. The goal is to come up with something that can satisfy the needs of multiple OS environments [BSD, sysV, VMS, you name it]. What I have in mind right now is to just be concrete and go with something along the lines of BSD's protocol layer (underneath sockets). This assumes that streams can be made to work on top of it [which is, I gather, exactly what most SysV TCP implementations are]. We (CMU) are not interested in streams or sysV directly, but a number of other people certainly will. Comments and suggestions are therefore extremely welcome. As for extra functionality.. you certainly get to "see" what's going on under /net [default mount point for NP]. If I go by protocols, there are subdirs like /net/ip (maybe /net/arp) /net/iso /net/ns , and then /net/ip/tcp /net/ip/udp /net/ip/imp and so on. What's under each protocol is fuzzy, right now, but it will let you see all established connections. As for 'manipulating' things there.. Keith Sklower and others have already pointed out that 'creat' might be messy, but opening an existing file, reading and writing to it (permissions aside) is doable, just like named pipes. [In other words, new names are only created by NP as part of the connection setup] I would pose that /net// loses because a given host can only be reached via some other qualifier besides its 'name': both ether address(es!) and IP numbers are ok, for instance, if you use the right mean. Then again one could overload symlinks to get a different view into the name space. In our system each and every system or user server can export a name space: I can think of the existing named and inetd as simple and useful cases of U*x network servers that can be extended this way. And BTW, all the various databases that go with a server can be administrated in a simpler way by collecting all permanent and temporary information within the server's subtree. Sooo, you have a chance to voice for a bigger-and-better network system .... shoot! sandro- Historical note: We already have a remote filesystem (RFS, it was born long before ma Bell's one) that works along these lines: /../somehost/usr/ is the /usr directory in host's namespace. This is where our own ideas originated. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009050515.AA00758@ucbvax.Berkeley.EDU] <1990090213325200> From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) Newsgroups: comp.protocols.tcp-ip Subject: Re: sockets vs. streams Message-ID: <9009050515.AA00758@ucbvax.Berkeley.EDU> Date: 2 Sep 90 13:32:52 GMT References: <9009012315.AA08202@world.std.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 28 Posted: Sun Sep 2 14:32:52 1990 this reminds me of a great idea from newcastle: RESCUE (REduced System Call Unix E by gum, i canna recall what the E was for), an anlaogy with RISC hardware. i think they got down to about 4 system calls, you lose all the process ones from the extreme 8th edition idea of /proc, so processes are created, run and debug with open/read/write and destroyed with close remote execution is simple -you use newcastle conenction, and open /machinename/proc of course addresses just arent used - just like you dont use inodes instead of filenames...so all this overloading of things in the name is unnecassary. all info is in the first component of the path - i.e. proc is local processes machinename/proc is remote processes (open /mil.ddn-nic/proc/telnetd, is a telnet connection to the nic) and so forth and the talk facility is just a curses version of write to /machine/dev/tty?. multicast getsa a bit tricky, i guess you do open("/mil.*", ...) to give the 3 minute warning:-) of course, some good things can be taken too far, cant they? jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090214295500> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Sun, 2 Sep 90 04:08:06 PDT Received: from BARILVM.BIU.AC.IL by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 3441; Sun, 02 Sep 90 07:06:45 EDT Received: from BARILVM (HANK) by BARILVM.BIU.AC.IL (Mailer R2.03B) with BSMTP id 8753; Sun, 02 Sep 90 11:03:26 O Date: Sun, 02 Sep 90 10:59:55 O From: Hank Nussbacher Subject: Multi-protocol router scorecard To: cisco@spot.colorado.edu, wellfleet@nstn.ns.ca, tcp-ip@nic.ddn.mil, ripe@mcsun.EU.NET, p4200@devvax.tn.cornell.edu CAVEATS ------- The following scorecard tries to compare various multi-protocol routers. The current scorecard mainly contains information for cisco and Wellfleet but any other vendor is welcome to send me a complete set of manuals for their equipment so that I can analyze and update the scorecard. The fact of the matter is that certain features and "gotchas" only appear when testing the actual equipment. I hope that the user population of multi-protocol routers will assist me in making this scorecard as comprehensive as possible so that people who follow do not have to go through what I have gone through. It was difficult to decide whether to include future release notes in this scorecard. I trust the user population in the Internet to take each promise for a "future feature" with a grain of salt and to keep watch on the vendors that indeed they follow through with their promises. All too often vendors state certain features will be available in a certain release and sometimes their deadlines slip. It is advised that people should not base their decisions on the future release notes. [That was a long caveat]. If you have comments, suggestions, additions, or subtractions or corrections, please send them to: HANK@VM.TAU.AC.IL or HANK@TAUNIVM.BITNET (but not to both!) The scorecard will be updated on a monthly basis. If you read this report and are not connected to the Internet, you can send your comments to: Hank Nussbacher Computer Center Tel Aviv University Ramat Aviv Israel This report may be freely reproduced, as long as it is not altered in any sort of way. [The above employer has nothing to do with this scorecard so if something bothers you about it, I take full responsibility.] END OF CAVEATS -------------------------------------------------------------------- Distribution: cisco@spot.colorado.edu wellfleet@nstn.ns.ca tcpip@nic.ddn.mil ripe@mcsun.eu.net p4200@devvax.tn.cornell.edu Usenet: comp.dcom.lans -------------------------------------------------------------------- Comparison of Multiprotocol Routers Henry Nussbacher August 1990 Version 1.5 +--------------+--------------+---------------+ Multiprotocol | cisco AGS+ | Wellfleet LN | Proteon p4200 | Router | Rel. 8.1(14) | Rel. 5.35 | | +--------------+--------------+---------------+ 1. General | | | | - # of slots | 9 | 4 | | - Processor | 68020 | 68020 | | - Memory | 4Mbyte | 4Mbyte | | - Updates via | ROM, TFTP | diskette,TFTP| | - Speed of bus | 530Mb/sec (a)| 320Mb/sec | | - Boot from | | | | - ROM | Yes | No | | - Net-boot | | | | - IP | Yes | No | | - Decnet (MOP) | No | No | | - Diskette | No | Yes | | - Another router | Yes | No | | - Volatile changes | Yes (b) | No | | - CPU statistics | Yes (c) | No | | - Memory stats | Yes | No | | - Ease of install | Very easy | menu driven | | - Documentation | Difficult | Skimpy | | - Autorestart (d) | Yes | Yes | | - Restart for | | | | config changes | No | Yes | | - Watchdog timer | Yes | | Yes | - Reboot time (e) | 29 sec (f) | 120-600 sec | | - Power-up time (g)| 29 sec | 120-600 sec | | Notes: a. Speed of old AGS bus is 160Mb. b. Volatile changes represents the ability of the router to accept a configuration change that is dynamic that only affects the current running system and once the system is rebooted, the change disappears. c. CPU statistics refers to the ability of the router to provide a monitoring facility to see what the CPU is doing and how often it is doing it. d. Autorestart in the event of a power failure. e. Reboot time refers to the amount of elapsed time needed to perform a logical restart (reboot) from the fastest available media. f. cisco timings are for older AGS system. g. Power-up time refers to the amount of elapsed time needed from the time of a power failure and recovery until the router is up and operational. 2. Interfaces (a) | | | | - Ethernet | | | | (802.3 10Base5) | 24x10Mb | 8x10Mb | | - Thin Ethernet (b)| | | | (802.3 10Base2) | No | 8x10Mb | | - 4Mb Token Ring | 4x4Mb | 4x4Mb | | - 16Mb Token Ring | Rel 9.0 | Rel 5.40 (c) | | - RS232 | 24x64kb | 16x64kb | | - RS449 | 12x64kb | 16x64kb | | - V.35 | 12x64kb | 16x64kb | | - T1 | 12x1.544Mb | 8x1.544Mb | | - CEPT DS1 (2Mb) | 12x2Mb | 8x2Mb | | - FDDI | 2x100Mb | Rel 5.5 (d) | | - DAS (Dual) (e)| Yes | Yes | | - SAS (Single) | Yes | No | | - X.25 | | | | - Max # of VCs | Unlimited (f)| 254 | | - Card types (g) | 4E, 1E2S, | 2E, 1E1S, | | per slot | 2E2S, 4S, | 1E2S, 2E2S, | | | | 1TR2S, 4S | | | | 1TR | | Notes: a. Each interface subsection represents the maximum number of LANs or WANS that can be configured for that particular subsection. It is possible to "mix and match" various subsections by reducing the upper limit. b. Thin Ethernet refers to a standard BNC connector available directly on the router. c. 4x16Mb. d. 1x100Mb. e. Dual is also known as Type A and Single is also known as Type B. f. Depends on memory limitations. g. Card types: E: Ethernet, S: Serial/Synchronous line TR: Token-Ring 3. Interface part II | | | | - Frame Relay (a) | Rel 8.2 | | | - Ethernet | | | | encapsulation | | | | - Standard v2.0 | Yes | | | - IEEE 802.3 | Yes | | | - SNAP 802.2 | | | | (RFC1042) | Yes | Yes | | - Serial | | | | encapsulation | | | | - HDLC | Yes | | | - LAPB | Yes | | | - PPP (RFC1134) | Yes | | | - DDCMP | No | No | | - X.25 | Yes | | | - SVC | Yes | Yes | | - PVC | Yes | Yes | | - Encryption (b) | Pulse-time | | | - Filtering by | | | | source/dest | Yes | Yes | | Notes: a. CCITT standards Q.931 (Frame Relay) and I.122 (Lap-D) b. Encryption refers to the ability of the router to compensate for encrypting devices on various interfaces or circuits. 4. IP | | | | - Subnetting | | | | (RFC950) | Yes | Yes | | - ARP (RFC826) | Yes | Yes | | - RARP (RFC903) | Yes | No | | - BOOTP (RFC951) | Yes | No | | - proxy ARP | | | | (RFC1027) | Yes | Yes | | - ICMP | Yes | Yes | | - Name-server | Yes | No | | - Accounting | Yes | No | | - MTU | Yes | No | | - Security - IPSO | Yes | No | | - Static routing | Yes | Yes | | - Source routing | Yes | No | | - Filters | | | | - source/dest | Yes | Yes | | - TCP | Yes | | | - UDP | Yes | | | - ICMP | Yes | | | - by protocol (b)| Yes (a) | Yes | | - Routing protocols| | | | - RIP (RFC1058) | Yes | Yes | | - EGP (RFC904) | Yes | Yes | | - BGP (RFC1105) | Yes | No | | - Proprietary | IGRP | eRIP | | - Filtering | Yes | No | | - Default routes | Yes | Yes | | - OSPF | Rel 9.0 | Rel 5.6 | Yes | Notes: a. Can be done but is difficult and requires advanced knowledge of the specific protocols. b. Filtering by protocol can also be viewed as filtering by port number. 5. DECNET | | | | - Phase IV Router | Yes | Yes | | - Area Router | Yes | No | | - Phase IV+ (a) | Rel 8.2 | No | | - Phase IV-V | | | | Transitional gty | Rel 8.2 | | | - Phase V | Yes (b) | No | | - Address xlation | | | | gateway (c) | Yes | No | | - NCP | | | | - area-max-cost | Yes | Yes | | - area-max-hops | Yes | Yes | | - max-address | Yes | Yes | | - max-area | Yes | Yes | | - max-cost | Yes | Yes | | - max-hops | Yes | Yes | | - max-visits | Yes | Yes | | - router-priority| Yes | Yes | | - hello-timer | Yes | Yes | | - routing-timer | Yes | Yes | | - Filtering | | | | - source/dest | Yes | No | | - by protocol | No | No | | - by object | No | No | | - routing | Yes (d) | No | | - MOP | Bridged | Bridged | | - Static routing | No | No | | - Max routing table| 1023 | 1023 | | - Max # of broad. | | | | router adjencency| 32 | | | Notes: a. Phase IV+ refers to path-split capability. This means "normal" and not "interim". Normal allows out-of-sequence packets to arrive. Interim does not allow out-of-sequence packets to arrive. b. cisco claims that it's ISO CLNS support is compatible with Decnet Phase V. c. Address Translation Gateway is the ability to connect two separate Decnet networks with overlapping addresses. d. It is not possible to filter out of area addresses. It is only possible to filter an entire area or addresses within one's area. 6. Bridging | | | | - Local bridging | Yes | Yes | | - LAVC (a) | Yes | Yes | | - Remote bridging | Yes (b) | Yes | | - Transparent | | | | - Learning | Yes | Yes | | - Spanning tree | | | | (IEEE 802.1) | Yes | Yes | | - Priority (c) | Rel 8.2 | No | | - Filtering | | | | - Multicast | Yes | Yes | | - Protocol | Yes | Yes | | - Source/dest | Yes | Yes (g) | | - Masking (d) | No | No | | - Load sharing | Yes (e) | Yes | | - Token Ring | | | | - Source route | Yes | | | - Multi-ring (f) | Yes | | | Notes a. LAVC refers to the ability to act as a local bridge between two Vax clusters using the DEC LAVC protocol. b. cisco does not support bridging over X.25 or LAPB. c. Priority refers to the ability to assign a priority to a specific protocol so that that protocol is sent faster than any other protocol over a specific circuit/interface. d. Masking refers to the ability to specify some pattern string to be matched within the packet, so that the user can specify almost any filter. e. cisco load sharing (balancing) is on a per-node basis and not on a per packet basis. That means that over 2 parallel serial lines the cisco will automatically allocate 50% of the learned Ethernet addresses to one line and the other 50% to the other line. f. Multi-ring refers to bridging between multiple Token Ring networks (all hosts must understand RIF). g. Wellfleet can only filter on destination address and not on source address. 7. Other protocols | | | | (ability to route) | | | | - XNS | Yes (a) | Yes | | - UB derivitive | Yes | | | - Appletalk | | | | - Phase 1 | Yes | Yes | | - Phase 2 | Rel 8.2 | Rel 5.40 | | - Tokentalk | Rel 8.2 | Yes | | - Ethertalk | Yes | Yes | | - Localtalk | No | | | - RTMP | Yes | Rel 5.40 | | - AARP | Yes | Rel 5.40 | | - NBP | Yes | Rel 5.40 | | - EP | Yes | Rel 5.40 | | - ATP | Yes | | | - ZIP | Yes | Rel 5.40 | | - DDP | Yes | Yes | | - ISO | | | | - ISO 8473 CLNP | Yes | No | | - ISO 9542 ES-IS | Yes | No | | - Apollo Domain | Yes | No | | - Novell IPX | Yes (a) | Yes | | - X.25 | Yes | Yes | | - bridging | Rel 9.0 | Yes | | - routing | Yes | Yes | | - switching | Yes | Yes ??? | | - Security | Yes (b) | | | Notes: a. With cisco equipment, if there are both Ethernet and Token Ring interfaces, then DECnet cannot be run simultaneously with either Novell IPX or XNS. This restriction will be removed in Release 8.2. b. cisco provides filtering/permitting/denying certain packets only for IPX, XNS and Appletalk in the section listed above. 8. Management | | | | - Central managed | Yes | Yes | | - SNMP | | | | - Platform | Sun 3, Sparc | Sun 3 | | - DEC EMA (a) | No | Yes (a) | | - External | | | | software (b) | No (c) | No | | - X netmap | Yes | Yes | | - Telnet to | | | | device (d) | Yes | No | | - X interactive | Yes | | | performance | | Yes | | - History stats | Yes | No | | - Report writer | Yes (c) | No | | - Alerts (e) | No | No | | - User defined | | | | extensions (m) | Yes | No | | - Usage stats | Yes | Yes (f) | | - Direct MIB access| No | Yes | | - PING | Yes | Yes (g) | | - Telnet | Yes (h) | Yes (i) | | - MOP Remote Cons. | Rel. 8.2 | Bridged | | - NICE (j) | No | No | | - Decnet connect | No | No | | - Passwords (k) | Yes | Yes | | - Netview support | | | | - Disable lines | | | | dynamically | Yes (l) | Yes | | Notes: a. DEC EMA refers to the product's intent to support the DEC Enterprise Management Architecture in the future. No release version has been mentioned yet for this feature. b. External software refers to the need to have some external software package available in order to run SNMP monitoring. c. cisco requires the Sybase database system in order to run their NMS software. This package is bundled with their NMS. d. Ability to click on an icon on the X-11 network map and open a telnet connection to the device in question. e. Alerts refers to the ability to define a preset limit for a specific MIB variable at which point the SNMP monitoring software will present a window on top of the network map informing the network operator of the problem. f. Wellfleet interactive usage statistics are only for (ISO model) level 2. Upper level statistics (such as RIP, UDP, TCP, Decnet HELLO, ARP) are not available. g. Wellfleet PING command stops after first failure and waits for user response. This makes it very hard to check the total percentage of line failures over a short period of time. h. cisco is limited to 5 incoming Telnet sessions but has no limitation on outgoing Telnet sessions. i. Wellfleet Telnet is limited to one incoming and one outgoing session. j. NICE refers to the ability of the router to accept "SET EXECUTOR" as well as initiate a "SET EXECUTOR" to a remote host. k. Passwords refers to the ability to limit certain configuration and customization options only to those users who supply a password. l. cisco command is not an EXEC command but actually requires a configuration change to disable a line. m. The ability for the NMS software to add other vendor MIBs to their database, in order to manage these particular hardware units. 9. Debugging & | | | | Monitoring | | | | - Data-Link Layer | Yes | Yes | | - LAN | Yes | Yes | | - Link | Yes | Yes | | - Decnet | Yes | Yes | | - Tcp/Ip | Yes | Yes | | - Event log | Yes | Yes | | - Environmentals | Yes | No | | Notes: a. Environmentals refers to the monitoring of variables such as fan, power supply, memory, temperature, etc. 10. Performance (a) | | | | - Router forward | 2917 (b) | 3757 (c) | 902 | - Router filter (d)| 2279 (b) | 3757 | 902 | - Bridge forward | | | | - Bridge filter | | | | - LAT compression | Yes | No | | Notes: a. Performance based on 256 byte packets, between separate interface cards, with no packet loss. Numbers listed are in packets per second. Numbers based on Bradner report, Harvard University, Sept 1989. A revised benchmark is expected sometime in Sept 1990. b. cisco performance numbers based on AGS and CSC2 hardware. c. Wellfleet numbers may be higher but equipment was not able to generate packets faster than the LN. d. Filter is based on 10 packet filters enabled. 11. Survivability | | | | - alternate power | | | | supply | No | Yes (d) | | - standby line (a)| No | No | | - fault tolerant(b)| No | No | | - field tolerant(c)| No | No | | - broadcast storms | Yes | No | | Notes: a. Standby line refers to the ability to define a line that is to be a hot standby, in the event that the primary line goes down. The software switches all traffic automatically to the backup line. b. Fault tolerant refers to having redundent systems that are normally in standby mode, and that are only called into active mode in the event that the primary system fails. Various systems are the power supply, the fan, the bus, the controller cards, etc. c. Field tolerant refers to the ability to withstand harsh elements and conditions out in the "field." d. Alternate power supply only available in large Concentrator model. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090215071800> Received: from ico.isc.com by NIC.DDN.MIL with TCP; Sun, 2 Sep 90 20:08:06 PDT Received: from violet.ico.isc.com by ico.isc.com (5.61/1.35) id AA00862; Sun, 2 Sep 90 21:07:21 -0600 Date: Sun, 2 Sep 90 21:07:18 MDT Message-Id: <9009030307.AA02947@violet.ICO.ISC.COM> To: J.Crowcroft@cs.ucl.ac.uk Cc: tcp-ip@nic.ddn.mil From: "Doug McCallum" Subject: Re(2): TLI, NLI, DLI - Request for information In reply to your message of Fri, 31 Aug 90 09:34:13 +0100 ------- > do any of TLI, NLI or DLI contain something with more functionality > than sockets - like a standard management interface, or a standard > packet filter or traceer interface - and i dont mean ioctl and nit > like vaguaries TLI has been discussed to death. It is similar to sockets and has adherents and detractors like sockets do. 4.4BSD sockets pretty much fix the deficiencies that TLI tried to address. NLI and DLI don't exist with those names. There is NPI and DLPI. They are interfaces between STREAMS modules and don't really have any relationship to sockets or anything like that. They could have programming interfaces defined for them but there currently aren't any. Of course, since they are just STREAMS messages, a user level program can access the interfaces. To summarize what NPI (Network Provider Interface) and DLPI (Data Link Provider Interface) are: NPI: Provides a common set of primitives that are based on the OSI service primitives for network services. The intent is to have a common set of primitives to allow a transport provider to be able to communicate with a network service provider. While not really necessary, it does provide a way to cleanly separate the network provider from the other parts of the stack and to allow multiple providers. One possibility is to have CONS and CLNS network providers for OSI under a single stack. In reality, it is just a nice way to do something similar to RAW sockets but then be able to link the network STREAM under a provider module and construct a new stack without having to modify any part of the network provider driver. NPI provides for connection primitives as well as connectionless. DLPI: This is the STREAMS interface to data link device drivers. While similar to NIT and other mechanisms for gaining access to the device driver level, it really is just the mechanism for a network service provider to communicate with the device driver. A STREAM can be opened and bound to some service access point (Ethertype, 802.2 LSAP, whatever) and then be linked under a network provider module. It is possible to use it a user level to implement things like RARP or other application that uses the data link level directly. The V.4 DLPI also includes primitives for connection oriented protocols such as 802.2 Class 2 Type 2 LLC. > if not, i suggest its just more noiseware to make unix less useful, > designed by manufacturers running scared from real open systems and > shareware... TLI may have been that. It does seem to smack of NIH. NPI and DLPI developed to meet a different need - that of getting vendors to write drivers that would work with other vendors protocol stacks. Since STREAMS isn't a protocol or driver implementation itself and is only the framework to develop protocols and drivers, there needed to be a consistant interface between the various types of modules. NPI and DLPI are intended to do that. The BSD way doesn't fit the STREAMS model very well. Besides, DLPI at least, is far more flexible. The drivers don't have to be modified to allow a third party vendor's protocol stack take advantage of them. Doug McCallum Interactive Systems Corp. dougm@ico.isc.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090216125200> Received: from bells.cs.ucl.ac.uk by NIC.DDN.MIL with TCP; Sun, 2 Sep 90 06:36:17 PDT Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id ; Sun, 2 Sep 1990 14:32:53 +0100 To: Barry Shein cc: tcp-ip@nic.ddn.mil Subject: Re: sockets vs. streams In-reply-to: Your message of Sat, 01 Sep 90 19:15:59 -0400. <9009012315.AA08202@world.std.com> Date: Sun, 02 Sep 90 14:32:52 +0100 From: Jon Crowcroft this reminds me of a great idea from newcastle: RESCUE (REduced System Call Unix E by gum, i canna recall what the E was for), an anlaogy with RISC hardware. i think they got down to about 4 system calls, you lose all the process ones from the extreme 8th edition idea of /proc, so processes are created, run and debug with open/read/write and destroyed with close remote execution is simple -you use newcastle conenction, and open /machinename/proc of course addresses just arent used - just like you dont use inodes instead of filenames...so all this overloading of things in the name is unnecassary. all info is in the first component of the path - i.e. proc is local processes machinename/proc is remote processes (open /mil.ddn-nic/proc/telnetd, is a telnet connection to the nic) and so forth and the talk facility is just a curses version of write to /machine/dev/tty?. multicast getsa a bit tricky, i guess you do open("/mil.*", ...) to give the 3 minute warning:-) of course, some good things can be taken too far, cant they? jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090217592700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 4 Sep 90 23:23:43 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06079; Tue, 4 Sep 90 23:14:17 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Sep 90 17:59:27 GMT From: snorkelwacker!usc!samsung!munnari.oz.au!cs.mu.OZ.AU!kre@bloom-beacon.mit.edu (Robert Elz) Subject: Re: sockets vs. streams Message-Id: <5329@munnari.oz.au> References: <6964@milton.u.washington.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <6964@milton.u.washington.edu>, mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: > > If "network I/O looks like local device I/O" under Unix then when the > h*ll do I have to worry about all the socket or streams crap? There was a time when building network names into the filesystem was seen as a sensible thing to do - nice and regular, existing programs would be able to use them, ... Unfortunately, while its a nice idea, it really won't work in general, and if it doesn't work in general, its not worth the effort. First, its perfectly reasonable for an application to check whether a file exists before attempting to open it, that way more meaningful error messages can be given - this is kind of hard to do with a network connection. Second, while your example gave numbers (/tcp/128....) that would be useless in practice - the interface would need to use names. Since "open" is a kernel routine (if we're not assuming that we're talking about completely different issues) that means that either name->number mapping needs to be done in the kernel, or the kernel needs to have some mechanism to get some kind of user process to do the mapping for it. Now assuming that this can be solved, the application needs to be able to select parameters for the mapping process - How many attempts should be made to find the translation? With what delay between attempts? Should default domains be appended? Which? Should some user defined nic-name to real name be applied? From where? What should be done with "soft" nameserver errors? Which server should we be using? Next, lets assume that that we are able to get the number, somehow, and the port number (from its name) as well - next we have to open the connection. At first sight that's easy - but how do we specify the MSS, receive and transmit windows, IP header TTL, TOS, ... You suggested that all of this could be built into the filename as optional segments (by now we're getting pretty far from the traditional notion of a filename, but never mind). Certainly, they could - but doing this makes the user (the provider of the filename) responsible for specifying all this crud - what does the user care about MSS's? So, instead the application has to massage the file name to append all of the various option settings that it might need (sure - most applications will take kernel defaults, but the mechanism has to be there - and all of this has to be done before the connection is opened). Now, the easy part is solved, TCP just isn't that complex, but lets extend generality a little and open an OSI MHS (X.400) connection as well. In the connection setup here we need various addresses, XSAP's (for various X), packet sizes, window sizes, numerous option selections at various levels, MTA names, passwords, ... By the time its all specified your pathname is going to be totally absurd. This is why the socket() call provides an anonymous file descriptor (and the streams model does much the same thing). Having that file descriptor all the necessary options can be set before the network is asked to establish the connection - simple applications may set none at all and rely on defaults, sophisticated applications might set many. But its one mechanism that works well for everyone. A better question might not be, to regularise things, why isn't all I/O done by first requesting a socket, then connecting to the object, ie: open(path, mode) might be modelled (very roughly) as s = socket(AF_FS, ...); setsockopt(FS_MODE, mode); connect(s, path, ...); (with bind() used for creat(0 of course). Henry Spenser asked why no-one has ever created a standard library routine to open a connection. That's something I have wondered about myself, it seems like a fairly obvious thing to do. But then I've never done it either ... I guess its just that opening a net connection (explicitly) just isn't something that is done all that often, and isn't really that hard when you need to do it, so neither I nor anyone else I'm aware of has bothered to define a good simple interface useful for most applications (this is a case where universal applicability wouldn't be needed - the underlying mechanism is still there when required, just as stdio's fopen() doesn't do everything that open() is capable of). kre ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090218452400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 01:08:53 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15995; Wed, 5 Sep 90 00:52:38 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Sep 90 18:45:24 GMT From: mcsun!ukc!dcl-cs!aber-cs!athene!pcg@uunet.uu.net (Piercarlo Grandi) Organization: Coleg Prifysgol Cymru Subject: Re: Sockets vs streams. An attempt to answer the original question Message-Id: References: <9008242107.AA19843@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil On 31 Aug 90 19:48:37 GMT, sklower@ernie.Berkeley.EDU (Keith Sklower) said: sklower> In article <1990Aug28.162400.17811@zoo.toronto.edu> sklower> henry@zoo.toronto.edu (Henry Spencer) writes: spencer> The way to do i/o on Dennis's streams was with "read" and "write". spencer> Network i/o, in general, looked *exactly* like local device i/o. Note that with the most recent developments of UNIX (FSS) read() and write() no longer mean much, except 'move data from/to the kernel'; they have become just a way to add new system calls, using a file like style of interface. The semantics of write() and read() have become very very loose. What does read/write mean on /dev/proc? Something highly non obvious. spencer> This is the way it should be, unlike what both Berkeley and spencer> AT&T have done (both have reluctantly conceded that most people spencer> want to use "read" and "write" and have made that work, but spencer> their hearts were clearly elsewhere). And for good reason! read() and write() on file descriptors is not the most amusing interface. It is much more convenient to have IPC style access to files, e.g. Accent with its ports, than viceversa, unless we are so wedded to UNIX that we cannot change (probably true, vide failure of Accent to get accepted, and then success of Mach, which is a Unix like imitation of it). Frankly, the "everything is a file" way of achieving connectability is not the best abstraction, because you want to connect to active services, not just to passive storage. Straining a file model to include "active" files is a bit inelegant. "everything is a socket" or equivalently "everything is a process" (even files!) are much better; "everything is a file system", the technology used in recent research Unixes or PLAN/9 is a way to get as abstraction a more active thing than a file, works better than "everything is a file", yes, but requires a large suspension of disbelief, and assumes that we really want the Unix directory tree model for all name service, which may not be a terribly good choice either. e.g. as in having an internet filesystem type, and doing something like fd = open("/dev/internet/lcs.mit.edu/echo.udp",...); /*or*/ fd = open("/dev/internet/edu/mit/lcs/119.tcp",...); sklower> I find this inaccurate, partronizing and tiresome. I have sklower> worked around Berkeley since 1978 and although was not a member sklower> of the actual unix group in 1982 while TCP was being sklower> incorporated, attended their meetings and seminars. Ahh. Incidentally, I would like to observe that I have *never* seen an implementation of BSD sockets and TCP. The only ones that circulate are extremely limited and rigid subsets. Since you have been around UCB for so long, can you tell us why there is no (full) implementation of BSD sockets? E.G. where are user domain type filedescriptors? About compatibility between IPC and normal file I/O: sklower> I assure you that it was the design goal then, that only sklower> ``sophisticated process'' would need a more elaborate mechanism sklower> to establish a network connection, but that once having sklower> established one, that it should be usable as a completely sklower> ordinary file descriptor by ``naive'' processes like the date sklower> command, using read and write, and that the file descriptor sklower> should be inherited by the normal unix means (fork & exec). Uhm. Precisely. And 'wrappers', one of the features of BSD sockets, were designed to make such compatibility absolute. Why nobody has ever implemented them? sklower> It sounds to me like Henry is attempting to rewrite history sklower> (for his own possibly political motives). I actually think that he may innocent, but he *is* attempting to rewrite history, in a way different from what you say; on BSD it actually happens that read/write on sockets is the same as on files, but because they changed the specification of read/write on files. The only difference with send/rcv is that sendmsg/rcvmsg allow out-of-band, and passing file descriptors, which make no sense with read/write to a file, but the distance from traditional read/write is larget than that. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk ----MESSAGE-END---- ----MESSAGE-BEGIN---- [652304954.af@SPICE.CS.CMU.EDU] <1990090219490000> From: Alessandro.Forin@SPICE.CS.CMU.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: OS network interfaces (was: sockets vs. streams) Message-ID: <652304954.af@SPICE.CS.CMU.EDU> Date: 2 Sep 90 19:49:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 58 Posted: Sun Sep 2 20:49:00 1990 The multiserver Mach 3.0 [and other systems such as Plan9, for instance] place indeed much more semantics in filesystem names. For networking, we have a Network Protocol Server (NP) that contains the protocol code and talks to the ether device (or whatever) at the packet level. It's NP's business what names mean. It's independent of the OS environment (streams, sockets whatever) what is the interface that NP exports to other servers and to the U*x emulation library. [Right now it's just the socket BSD interface, cuz we did it 2 years ago quickly just to see if the thing was plausible] What I am interested in for the second round implementation is what would be the most flexible interface for NP. The goal is to come up with something that can satisfy the needs of multiple OS environments [BSD, sysV, VMS, you name it]. What I have in mind right now is to just be concrete and go with something along the lines of BSD's protocol layer (underneath sockets). This assumes that streams can be made to work on top of it [which is, I gather, exactly what most SysV TCP implementations are]. We (CMU) are not interested in streams or sysV directly, but a number of other people certainly will. Comments and suggestions are therefore extremely welcome. As for extra functionality.. you certainly get to "see" what's going on under /net [default mount point for NP]. If I go by protocols, there are subdirs like /net/ip (maybe /net/arp) /net/iso /net/ns , and then /net/ip/tcp /net/ip/udp /net/ip/imp and so on. What's under each protocol is fuzzy, right now, but it will let you see all established connections. As for 'manipulating' things there.. Keith Sklower and others have already pointed out that 'creat' might be messy, but opening an existing file, reading and writing to it (permissions aside) is doable, just like named pipes. [In other words, new names are only created by NP as part of the connection setup] I would pose that /net// loses because a given host can only be reached via some other qualifier besides its 'name': both ether address(es!) and IP numbers are ok, for instance, if you use the right mean. Then again one could overload symlinks to get a different view into the name space. In our system each and every system or user server can export a name space: I can think of the existing named and inetd as simple and useful cases of U*x network servers that can be extended this way. And BTW, all the various databases that go with a server can be administrated in a simpler way by collecting all permanent and temporary information within the server's subtree. Sooo, you have a chance to voice for a bigger-and-better network system .... shoot! sandro- Historical note: We already have a remote filesystem (RFS, it was born long before ma Bell's one) that works along these lines: /../somehost/usr/ is the /usr directory in host's namespace. This is where our own ideas originated. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090221395500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 4 Sep 90 23:34:44 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07445; Tue, 4 Sep 90 23:29:43 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Sep 90 21:39:55 GMT From: auspex!guy@uunet.uu.net (Guy Harris) Organization: Auspex Systems, Santa Clara Subject: Re: Sockets vs streams. An attempt to answer the original question Message-Id: <4004@auspex.auspex.com> References: <9008291444.AA15182@violet.ICO.ISC.COM>, <1513@devildog.att.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil (Not particularly TCP/IP oriented at this point....) >>> ps. Is there anyway to get a list of all the modules pushed onto >>> a stream. I_LOOK only lists the top most module. >> >>Not in V.3. > >Actually it is not quite that bad. You should have an idea of all the >possible modules that COULD be on a given stream (not many). It is then >trivial to write a little program which uses I_FIND to see if the module >is on the stream. That'll tell you *which* modules are on the stream, but it won't tell you where they are on the stream. If you want that, you need something such as S5R4's I_LIST. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090301555400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 00:22:43 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10748; Wed, 5 Sep 90 00:02:37 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Sep 90 01:55:54 GMT From: munnari.oz.au!mtiame!ubeaut!mwp@uunet.uu.net (Michael Paddon) Organization: Digital Equipment Corp., Melbourne, Australia Subject: Re: SLIP & Routing Message-Id: <176@ubeaut.oz.au> References: <425@afsg.apple.com>, <168@ubeaut.oz.au> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <168@ubeaut.oz.au>, mwp@ubeaut.oz.au (Michael Paddon) writes: > On client: > route add default 192.33.20.201 1 > > On server: > route add default 192.33.20.1 1 I forgot to handle packets being routed from the outside world towards the client (mostly because I tend to set up most nodes to be invisible to the outside world for security reasons). Anyway, credit where due... Here is the additional information as provided to me: = Return-Path: mtiame!root%afsg.apple.com@munnari.oz = Received: from afsg.apple.com by munnari.oz.au with SMTP (5.61+IDA+MU) = id AA03802; Fri, 31 Aug 1990 00:13:32 +1000 = (from root@afsg.apple.com for mwp@ubeaut.oz) = Date: Thu, 30 Aug 90 07:09:38 PDT = From: root@afsg.apple.com (System Owner) = Message-Id: <9008301409.AA18488@afsg.apple.com> = To: mwp@ubeaut.oz.au = Subject: Re: SLIP & Routing = Newsgroups: comp.protocols.tcp-ip = In-Reply-To: <168@ubeaut.oz.au> = References: <425@afsg.apple.com> = Organization: Apple Federal Systems Group = = In order for other hosts/gateways to see the client machine = on a Class C network you must set up a proxy arp for the = client at the ethernet address of the server machine's = ethernet interface. Otherwise remote hosts/gateways won't = know how to route packets destined to the SLIP client. > [This question probably shouldn't be in this newsgroup] I had about four people mail me and say "where should it be then?". My newsgroups file says: comp.protocols.tcp-ip TCP and IP protocols. Thus, my off the cuff comment questioning whether the setup of SLIP routing really fits into a discussion of protocols. Personally I don't care where people post anyway. Michael ------------------------------------------------------------------- | | EasyNet: meo78b::paddon | | | Internet: paddon@meo78b.enet.dec.com | | Michael Paddon | ACSnet: mwp@ubeaut.oz.au | | | ACSnet: mwp@munnari.oz.au | | | Voice: +61 3 895 9392 | ------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090302261900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 4 Sep 90 21:44:55 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26425; Tue, 4 Sep 90 21:27:26 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Sep 90 02:26:19 GMT From: sdd.hp.com!mips!twg.com!david@hplabs.hpl.hp.com (David S. Herron) Organization: The Wollongong Group, Palo Alto, CA Subject: Re: sockets vs. streams Message-Id: <7880@gollum.twg.com> References: <6964@milton.u.washington.edu>, <13526@mentor.cc.purdue.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <13526@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes: > > I don't want to get into a religious war, but I don't see where a >filesystem analogy to sockets holds up to any but the most shallow >interpretation. To use your naming, what does it mean if I type: > > cd /tcp//128.210.10.8 >? > What if I do an "ls /tcp"? Be careful-- all of the assigned addresses >aren't available in any one place. Not if NIC.DDN.MIL-- they only have the >network parts... > How do you specify a local address binding when you care? How do you >specify that you don't care? What does a "seek" mean on a socket? How do you >send urgent data in TCP? > In a UNIX implementation, by making the "tcp" a directory, you've >introduced a type of pseudo-device like no other that exists and without >it you lose some of the information you want in the name. > > I won't argue that sockets are the "right" way, and there are certainly >rough edges, but the filesystem analagy *is* artificial. The things you do to >files (ie, storage devices) aren't the things you do with sockets (ie, >communication media). To a degree, you can make the same argument with >terminals, but it doesn't seem to be pushing it quite as much there, to me. My understanding is that some of the filesystem researchers are working towards file systems which one would describe better as "object hierarchies". In this type of system the semantics of objects would vary depending on where you are in the hierarchy. (Part of this could be implemented right now via the "file system switch" stuff in newer Unices.) For the /dev/tcp file system the semantics might be that the next level contains objects whose names are the IP addresses of hosts to which we are currently communicating. Part of the semantics of this level is that it contains (like a directory) objects whose names are the port number of the relavent end of the connection. Objects under /dev/tcp would come and go as connections are created and destroyed. There would be a system call (ioctl()?) for getting/setting various parameters of each end of the connection. It's not too terribly different than stuff currently available within the range of systems that are called Unix. My understanding of the /proc (of v8-v10 and SysVr4 fame) directory is that it acts similarly -- that objects within it appear and disappear as processes come and go. And that ioctl() can get & set various options on the process. And that opening the /proc/nnn `file' (object) lets you read and write the running process. It would probably be a "good thing" for the /dev/tcp objects to have appear under other names than just the IP addresses. After all, people wanna use names to connect to places... so "/dev/tcp/s.ms.uky.edu" would be the same as "/dev/tcp/128.163.128.19", might be implemented as a link(?). There would have to be some code here to do nameserver lookups and set these links up. An internally multitasking OS might be a big help here. Same sort of deal for the next layer down. /dev/tcp/s.ms.uky.edu/smtp for instance. Of course user level applications shouldn't require users to type such nonsense, but should look pretty much like they do now but make translations. You could have a routine that returns a free port. It'd be a simple use of opendir() and readdir() to find the first free one. Oh yeah, opendir() and readdir() type stuff might have to be played with a little bit. But probably not since they get implemented in the kernel nowadays. Just tossing out a few ideas that I've had in my mind for a long time.... Do with them what you will. :-) I don't think there's anything unimplementable, and in fact it would likely work pretty darn well. I would certainly like to see a lot more use made of that file system switch facility. Sun OS v4.1 was a good step in that direction in that it's supporting some pretty funky options/variations to file systems. -- <- David Herron, an MMDF & WIN/MHS guy, <- Formerly: David Herron -- NonResident E-Mail Hack <- <- Sign me up for one "I survived Jaka's Story" T-shirt! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090304272900> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Mon, 3 Sep 90 12:26:47 PDT Received: from braden.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Mon, 3 Sep 90 11:27:40 -0700 Date: Mon, 3 Sep 90 11:27:29 PDT From: braden@venera.isi.edu Posted-Date: Mon, 3 Sep 90 11:27:29 PDT Message-Id: <9009031827.AA03833@braden.isi.edu> Received: by braden.isi.edu (4.1/4.0.3-4) id ; Mon, 3 Sep 90 11:27:29 PDT To: tcp-ip@nic.ddn.mil, van-bc!ubc-cs!alberta!macg@ucbvax.berkeley.edu Subject: Re: 4.0 NIT Bug Mike, Fixed object modules for Sun OS 4.0.x are available for anonymous FTP from host venera.isi.edu with pathnames pub/nit_if.o or pub/nit_if.o.sparc. There is a mailing list for people interested in NNStat (or, in principle, any monitoring tools): bytecounters@isi.edu. Send a msg to bytecounters-request to be added to the list. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090307082400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 00:47:20 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA14127; Wed, 5 Sep 90 00:32:54 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Sep 90 07:08:24 GMT From: bacchus.pa.dec.com!decvax.dec.com!shlump.nac.dec.com!uluru.enet.dec.com!tong@decwrl.dec.com (Benny Tong) Organization: Digital Equipment Corporation Subject: tcp source port number assignment in new tcp connection Message-Id: <15096@shlump.nac.dec.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does anyone know how to assign TCP source port number when opening a new TCP connection? Is there a RFC to suggest how to do this? Will the following scheme work ? Initialises the last assigned port number to the smallest port number to use (ex. 1000?). For each new tcp connection to be opened, increments the last assigned port number (and wraps around at the largest port number plus one). Check if this tcp port number is in use already. If it is, increments this port number until an unused port number is found. Opens a tcp connection with this as the tcp source port number. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090307285900> Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 3 Sep 90 11:16:41 PDT Received: by uunet.uu.net (5.61/1.14) with UUCP id AA21403; Mon, 3 Sep 90 14:16:33 -0400 Received: by world.std.com (5.61++/Spike-2.0) id AA02023; Mon, 3 Sep 90 14:08:59 -0400 Date: Mon, 3 Sep 90 14:08:59 -0400 From: bzs@world.std.com (Barry Shein) Message-Id: <9009031808.AA02023@world.std.com> To: Alessandro.Forin@SPICE.CS.CMU.EDU Cc: tcp-ip@nic.ddn.mil In-Reply-To: Alessandro.Forin@SPICE.CS.CMU.EDU's message of Sun, 2 Sep 1990 15:49-EDT <652304954/af@SPICE.CS.CMU.EDU> Subject: OS network interfaces (was: sockets vs. streams) The issue of name server resolution and similar problems was raised by Robert Elz. This is a real problem and well worth grappling with. What has been done in various special-case forms but has never really been standardized into unix kernels is a clean interface which allows the kernel to call back out to a user process for information. For example, one simplistic approach would be a daemon which registers a service with the kernel (similar to bind() in philosophy) and then waits for requests. This could be cobbled up as a socket thing, call it the UNIX_KERNEL protocol. That would, for example, allow the current name service to do this via just adding another fd to its select() call: daemon: struct sockaddr_kern sockk; sockk.port = NAME_SERVICE; skern = socket(KERNEL,SOCK_DGRAM,0); bind(skern,&sockk,sizeof(sockk)); ...etc...(select/accept loop) PDP-10 types will of course recognize this as a generalization of the ACJ idea. And it could very well be used for authorization etc., anything where it would be nice to manage various data at user level and let the kernel just query these user processes for things like "can this uid do remote TCP connects?", "what does this string translate to?", "user foo's job just ran out of memory, please log to a file". Current facilities, such as kernel error logging, could be completely replaced by this sort of facility. I'm sure people will now tell me that XYZ is just this, I'm interested, but I suspect what we'll find is a lot of little special facilities that never quite got generalized, or have some other strange limitations. Of course, generalizing this so the query relays to another server over the net is almost trivial (the user level daemon can do that, and in the case of a name service almost certainly would.) -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090316143900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 02:07:30 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22451; Wed, 5 Sep 90 02:01:39 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Sep 90 16:14:39 GMT From: mcsun!ukc!icdoc!tgould!lmjm@uunet.uu.net (Lee McLoughlin) Organization: Dept. of Computing, Imperial College, London. U.K. Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: References: <1990Aug30.091435.1982@ircam.ircam.fr Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Lee's time to flame ->> In article <6190@vanuata.cs.glasgow.ac.uk> tommyk@cs.glasgow.ac.uk (Tommy Kelly) writes: From: tommyk@cs.glasgow.ac.uk (Tommy Kelly) Newsgroups: eunet.followup,comp.protocols.tcp-ip Date: 31 Aug 90 07:26:56 GMT Organization: Comp Sci, Glasgow Univ, Scotland Does this imply that you CAN actually telnet out to U.S. sites? Is the UK the only place which is isolated from the rest of the world? Yes the UK is really the only Europaen country where not only do we lack tcp/ip services to the internet but you *CANNOT GET* tcp/ip services to the internet. Oh sure if you have ooodles of money and can afford your own satelite link or pss connection to a friendly site somewhere on the internet (some of the bigger companies with UK branches do this) or if you are one of the priviledged UK universities who have a link such as ULCC, UCL or UKC then fine, you're laughing. The rest of us? Forget it. There is noone out there offering a service that most UKNET users can afford. Even something as simple as running tcp/ip over JANET so we can have some degree of sane networking here in the UK seems to be out. The JANET powers that be do not want anything as useful as tcp/ip sullying there network! God forbid you should be able to use the networking software that comes on your machine!! Far better to have to shell out for coloured book software! Don't give me any of that rubbish about tcp/ip not being available on all the machines on Janet, any machine that sells in the US has tcp/ip available for it. Normally from several competing vendors. Over here you are lucky if the coloured books are available at all for any new box. The thing that really amazes me about all this is that there is not a bigger fuss about it all! I regularly pull back new releases of software/documentation from US/Europaen academics from internet, don't academics here in the UK want to make there work available in the same way? Many comerical companies are on the US Internet and release patches, demo release and the like by making them available for anonymous ftp. Don't companies over here want to do the same thing? If I thought it would succeed I'd say we should all lobby for either UKNET or Janet to make internet available to us, but a lot of us tried to get that stupid Janet decision about email addresses being the wrong way around reversed and failed. If I was a gambling man I'd bet any attempt to get us tcp/ip from the Janet authorities would be met by innane statements about ISO. My parting question is directed the those that run UKNET: when is tcp/ip going to be available to UKNET members in the same way as it is to Eunet members? -- -- Lee McLoughlin phone: 071 589 5111 X 5037 fax: 071 581 8024 Department of Computing, Imperial College, 180 Queens Gate, London SW7 2BZ, UK Janet: lmjm@uk.ac.ic.doc Uucp: lmjm@icdoc.UUCP (or ..!ukc!icdoc!lmjm) DARPA: lmjm@doc.ic.ac.uk (or lmjm%uk.ac.ic.doc@nsfnet-relay.ac.uk) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009050532.AA02351@ucbvax.Berkeley.EDU] <1990090317430000> From: CHAIBP@NUSDISCS.BITNET Newsgroups: comp.protocols.tcp-ip Subject: interfacing with Ethernet cards Message-ID: <9009050532.AA02351@ucbvax.Berkeley.EDU> Date: 3 Sep 90 17:43:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 25 Posted: Mon Sep 3 18:43:00 1990 I believe some people here may have experience developing device drivers for the following Ethernet adapter cards: 1. Acer 5220 2. AST-Ethernet Adapter 3. DTK Ethernet LAN card 4. Earthnet-Ie 5. G/Ethernet AT 6. IMC Networks PCnic 7. Localnet D-Link 8. Novell NNE1000 9. 3C501 EtherLink card 10. 3C503 EtherLink II 11. 3C505 EtherLink Plus 12. Tiara LanCard E 13. Univation LifeLink If you do, please send me you mailing address as I would like to consult you on issues of interfacing with these cards. BP ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1990Sep4.164546@jatz.aarnet.edu.au] <1990090320154600> From: pte900@jatz.aarnet.edu.au (Peter Elford) Newsgroups: uk.misc,eunet.followup,comp.protocols.tcp-ip Subject: Re: Internet routing Europe - USA -} Europe... Message-ID: <1990Sep4.164546@jatz.aarnet.edu.au> Date: 3 Sep 90 20:15:46 GMT References: <1990Aug30.091435.1982@ircam.ircam.fr <1990Sep04.045954.25664@comp.vuw.ac.nz> Reply-To: pte900@jatz.aarnet.edu.au (Peter Elford) Organization: AARNet Lines: 18 Posted: Mon Sep 3 21:15:46 1990 In article <1990Sep04.045954.25664@comp.vuw.ac.nz>, Andy.Linton@comp.vuw.ac.nz (Andy Linton) writes: |> I have much better access to my colleagues in the US, Australia and the |> rest of Europe than I ever did while in the UK and I would be very loath |> to go back to the inferior *international* networking available in the UK. And this from a user in country connected to the Internet via an extremely wet piece of string - a 14.4 kb voice grade modem link! Peter Elford, e-mail: P.Elford@aarnet.edu.au Network Co-ordinator, phone: +61 6 249 3542 Australian Academic Research Network, fax: +61 6 247 3425 c/o, Computer Services Centre, post: PO Box 4 Australian National University Canberra 2601 Canberra, AUSTRALIA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090323030000> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Sun, 2 Sep 90 18:41:09 PDT Received: from NUSDISCS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 5830; Sun, 02 Sep 90 21:39:55 EDT Date: Mon, 3 Sep 90 09:43 H From: Subject: interfacing with Ethernet cards To: tcp-ip@nic.ddn.mil X-Original-To: tcp-ip@nic.ddn.mil, CHAIBP I believe some people here may have experience developing device drivers for the following Ethernet adapter cards: 1. Acer 5220 2. AST-Ethernet Adapter 3. DTK Ethernet LAN card 4. Earthnet-Ie 5. G/Ethernet AT 6. IMC Networks PCnic 7. Localnet D-Link 8. Novell NNE1000 9. 3C501 EtherLink card 10. 3C503 EtherLink II 11. 3C505 EtherLink Plus 12. Tiara LanCard E 13. Univation LifeLink If you do, please send me you mailing address as I would like to consult you on issues of interfacing with these cards. BP ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090323180800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 02:34:57 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25287; Wed, 5 Sep 90 02:32:22 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Sep 90 23:18:08 GMT From: mcsun!ukc!edcastle!expc66@uunet.uu.net (Ulf Dahlen) Organization: Edinburgh University Computing Service Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <6091@castle.ed.ac.uk> References: <1990Aug30.091435.1982@ircam.ircam.fr, <6190@vanuata.cs.glasgow.ac.uk>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article lmjm@doc.ic.ac.uk (Lee McLoughlin) writes: >Yes the UK is really the only Europaen country where not only do we >lack tcp/ip services to the internet but you *CANNOT GET* tcp/ip >services to the internet. I was a bit surprised then I came here that I couldn't ftp or telnet to Sweden. All universities in Sweden run tcp/ip and there's no problem ftp-ing or telnet-ing to any site, in Sweden or USA or whatever (but probably not UK then). --Ulf Dahlen Linkoping University, Sweden and Edinburgh University, Scotland Internet: uda@ida.liu.se ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090400341600> Received: from ftp.com by NIC.DDN.MIL with TCP; Tue, 4 Sep 90 05:55:06 PDT Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA28442; Tue, 4 Sep 90 08:54:16 -0500 Date: Tue, 4 Sep 90 08:54:16 -0500 Message-Id: <9009041354.AA28442@ftp.com> To: Subject: Re: interfacing with Ethernet cards From: jbvb@ftp.com (James B. Van Bokkelen) Reply-To: jbvb@ftp.com Cc: tcp-ip@nic.ddn.mil Sender: jbvb@ftp.com Repository: babyoil.ftp.com Originating-Client: plug.ftp.com I believe some people here may have experience developing device drivers for the following Ethernet adapter cards: 1. Acer 5220 2. AST-Ethernet Adapter 3. DTK Ethernet LAN card 4. Earthnet-Ie 5. G/Ethernet AT 6. IMC Networks PCnic 7. Localnet D-Link 8. Novell NNE1000 9. 3C501 EtherLink card 10. 3C503 EtherLink II 11. 3C505 EtherLink Plus 12. Tiara LanCard E 13. Univation LifeLink With the possible exception of the "Earthnet-Ie" and the AST card, all of the above boards have Packet Drivers. Some are in the Clarkson collection, some (Gateway, Univation, IMC, Acer, Tiara) are only available from the board manufacturer. IMHO, you'd be a *lot* better off writing to either the Packet Driver spec (available from vax.ftp.com in pub/packet-d.ascii) or the NDIS spec (same machine, pub/ndis-mac.v101.txt, which all the drivers I've seen so far conform to or pub/ndis-mac.v201.txt, for a revision with more features) than doing 10 drivers of your own (several of the above cards are clones of the original Nat Semi DP839EB demo board, and could be covered by one software driver with a little extra effort). James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090401125000> Received: from p.lanl.gov by NIC.DDN.MIL with TCP; Tue, 4 Sep 90 06:13:04 PDT Received: from snow-white.lanl.gov by p.lanl.gov (5.61/1.14) id AA06958; Tue, 4 Sep 90 07:12:51 -0600 Received: from sneezy.lanl.gov by snow-white.lanl.gov (4.1/SMI-4.0) id AA26935; Tue, 4 Sep 90 07:12:50 MDT Date: Tue, 4 Sep 90 07:12:50 MDT From: cpw%snow-white@LANL.GOV (C. Philip Wood) Message-Id: <9009041312.AA26935@snow-white.lanl.gov> To: vd09+@andrew.cmu.edu Subject: Re: Telnettable programs Cc: tcp-ip@nic.ddn.mil Vincent, Your program (with a dummy process routine) worked for me. Is your telnet particular about the size of a port number? % telnet localhost 3007 Trying 127.0.0.1 ... Connected to localhost. Escape character is '^]'. Connection closed by foreign host. % Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090402274900> Received: from mwunix.mitre.org by NIC.DDN.MIL with TCP; Tue, 4 Sep 90 06:10:46 PDT Return-Path: Received: from [128.29.151.1] by mwunix.mitre.org (5.61/SMI-2.2) id AA09117; Tue, 4 Sep 90 09:08:08 -0400 Received: from localhost.mitre.org by community-chest.mitre.org (4.0/SMI-4.0) id AA10659; Tue, 4 Sep 90 09:07:50 EDT Message-Id: <9009041307.AA10659@community-chest.mitre.org> To: darrel beach Cc: tcp-ip@nic.ddn.mil, afc2s-saic@gunter-adam.af.mil Subject: Re: Verdix security system In-Reply-To: Your message of Fri, 31 Aug 90 09:24:55 -0500. Date: Tue, 04 Sep 90 09:07:49 -0400 From: H. Craig McKee Darrel - You want to talk to: Gaurang Shah Verdix Corp Sullyfield Business Park 14130-A Sullyfield Circly Chantilly, VA 22021 tel: (703)378-7600 We at MITRE have bought the system but don't yet have it running. The system provides a B-level Ethernet interface; ie, the Verdix Secure LAN (VSLAN) provides secure access control (between different classification levels); it does not provide confidentiality. For confidentiality you must either secure the LAN physically or use encryption such as the Xerox Encryption Unit. Regards - Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090404423400> Received: from sparta.com by NIC.DDN.MIL with TCP; Tue, 4 Sep 90 06:21:32 PDT Received: by sparta.com (4.0/cfm-mcl-MX-1.4(Heisenberg)) id AA00323; Tue, 4 Sep 90 09:16:39 EDT Received: from katahdin.columbia.sparta.com by columbia.sparta.com (4.1/cfm-1.1) id AA07746; Tue, 4 Sep 90 08:47:20 EDT Date: Tue, 4 Sep 90 08:42:34 EDT From: hsw@sparta.com (Howard Weiss) Message-Id: <9009041242.AA00209@katahdin.columbia.sparta.com> To: beach@ddnuvax.af.mil, tcp-ip@nic.ddn.mil Subject: Re: Verdix security system Cc: afc2s-saic@gunter-adam.af.mil Unfortunately, there are no ultimate network security solutions for LANs in existance - although there are several products available that can help solve various LAN security problems. The Verdix Secure LAN (SLAN) is one product (being evaluated for a B2 rating - see the attached product evaluation bulletin), but it does not "make" an unsecure LAN into a secure LAN if you think that you can reuse all your existing hardware and software. You can re-use your existing Ethernet cable plant, but all the network controllers need to be replaced with Verdix Network Security Devices (NSDs). Boeing also has built a secure LAN and its Network Security Controller (NSC) is being evaluated as an A1 component. There are also a couple of LAN encryption devices that could be used to provide data confidentiality on a LAN - the Xerox Encryption Unit (XEU) and the Motorola Network Encryption System (NES). I've got addresses for Verdix and Boeing: Verdix Corporation 14130-A Sullyvield Circle Chantilly, VA 22021. (703) 378-7600 Boeing Aerospace Company Dan Schnackenberg P.O. Box 3999, MS 94-64 Seattle, Washington 98124-2499 (206) 657-5595 email - Schnackenberg@dockmaster.ncsc.mil Attached are the product evaluation bulletins from the National Computer Security Center on both the Verdix and Boeing secure LANs. Howard Weiss Sparta, Inc. Columbia, Md. (301)381-9400 x201 hsw@sparta.com ____________________________________________________________________ Subject: VSLAN PB PRODUCT EVALUATION BULLETIN Report No. CSC-PB-004-88 AS OF: 4 October 1988 PRODUCT: VSLAN(1) VENDOR: VERDIX Corporation CANDIDATE CLASS: B2 MDIA Network Component PRODUCT DESCRIPTION: The VERDIX Secure Local Area Network (VSLAN) is a network component designed to interconnect clients (e.g., mainframe computers, workstations, servers) operating at different security levels in accordance with Department of Defense (DOD) security policies and procedures. The VSLAN operates at the physical and data-link protocol layers of the Open System Interconnection (OSI) reference model. It operates independently of higher layer host-to-host protocols and can be used to integrate a variety of host systems including internet gateways and application specific systems. The VSLAN consists of a single Network Security Center (NSC) and multiple (up to 64) Network Security Devices (NSDs) interconnected by a LAN transmission medium. The NSC is a dedicated computer system that provides a centralized management facility to control the operation of the VSLAN and to collect and export audit data. Each individual NSD provides a trusted LAN interface for its client that mediates incoming and outgoing datagrams according to the VSLAN security policy. The NSD implements the VSLAN communications protocol (IEEE 802.3) and provides end-to-end encryption for all data transfers accross the network. The encryption protocol used is the Data Encryption Standard of the National Institute of Standards & Technology (NIST). The encryption protocol is not used to enforce the VSLAN security policy, but is used as an integrity mechanism to provide protection against modification, insertion, deletion, or replay of data packets. As such, the encryption protocol itself is not evaluated. PRODUCT STATUS: The VSLAN is marketed and supported by the VERDIX Corporation and was released in October 1988. _________________________________________________________________ (1) VSLAN is a registered trademark of the Verdix Corporation EVALUATION STATUS: A formal evaluation of the VSLAN began in October 1988 and is scheduled for completion during the first quarter of the calendar year, 1990. The VSLAN is being evaluated against Appendix A of the Trusted Network Interpretation (TNI) of the Trusted Computer System Evaluation Criteria, NCSC-TG-005 Version-1, July 1987, as a candidate B2 MDIA network component. It can potentially be incorporated into a network system that can meet the TNI Part 1 requirements for class B2. At the completion of the evaluation, a final evaluation report will be produced by the National Computer Security Center and the VSLAN will be placed on the Evaluated Products List. A Product Bulletin does not assign any rating to a product. It merely establishes the candidate class which is the highest class the system could attain should the formal evaluation be completed. As with all evaluations, a system must complete the formal evaluation phase before being assigned any rating. ENVIRONMENTAL STRENGTHS: The VSLAN is designed to act as a communications reference monitor between attached clients. The VSLAN, by itself, is not intended to be a complete network system as defined by the TNI, but can be used as a trusted building block upon which trusted network systems can be built. The VSLAN only controls access to the LAN and does not mediate access attempts of host processes to information on local or remote host systems. The VSLAN was developed to provide the following services to its clients: - a system bus interface to external clients - mediation of all data transfers between attached clients in accordance with the VSLAN Mandatory Access Control (MAC) and Discretionary Access Control (DAC) policies - identification and authentication of the individual responsible for operating a node of the network - centralized management functions for security officers to exercise control over the operation of the LAN - a datagram oriented communications service The ability of the VSLAN to correctly enforce the VSLAN security policy depends entirely upon the trusted components of the VSLAN and on the correct input of the security parameters by the security officer. ______________________________________________________________________ Subject: Boeing MLS LAN PB PRODUCT EVALUATION BULLETIN Report No. CSC-PB-003-88 AS OF: 14 Sept. 1988 PRODUCT: Boeing MLS LAN VENDOR: Boeing Aerospace CANDIDATE CLASS: A1 MI Network Component PRODUCT DESCRIPTION: Boeing Aerospace's Multi-Level Secure Local Area Network (MLS LAN) is a network component providing multilevel secure communications between attached devices. These devices include, for this evaluation, terminals, host computers, serial devices, video devices, and stream devices. Within limits, a site is free to choose how many of each type of device to attach. The NCSC considers that the Boeing MLS LAN is a candidate for A1 MI network component and is capable (when properly supported by a special Network Management node and attached devices) of supporting a network system with Mandatory Access Control, Discretionary Access Control, Identification and Authentication, and Auditing commensurate with the A1 requirements. The MLS LAN consists of a set of one or more nodes called Secure Network Servers (SNSs). Each SNS may support physical interfaces for terminals, host computers, serial devices, video devices, or stream devices. A group of SNSs may be connected to one another by a transmission medium (either fiber optic or coaxial cable), enabling devices on separate SNSs to communicate. The SNS provides the following services: 1) host-to-host communication 2) terminal-to-host communication 3) terminal-to-terminal communication 4) terminal/host-to-serial-device communication 5) video and stream circuit-switched communication Host-to-host communication is supported by TELNET, Transmission Control Protocol (TCP), and User Datagram Protocol (UDP) service. Terminals may communicate with hosts and serial devices through TELNET and with other terminals through an Inter-Terminal Message service. Serial devices are supported with TELNET service. Video and stream circuit-switching is controlled through the terminal interface. All of these communications services are governed by a mandatory security policy. The MLS LAN maintains sensitivity labels for devices and data that include both secrecy and integrity components at the granularity of 8 hierarchical levels and 256 non-hierarchical categories. In addition, the MLS LAN requires all network terminal users to identify and authenticate before allowing them to use any network resources. End-to-end user identity and network addresses are provided to hosts. PRODUCT STATUS: The MLS LAN is developed and supported by Boeing Aerospace, a division of The Boeing Company. SECURITY EVALUATION STATUS: A formal evaluation of the MLS LAN will commence in October 1988 and is scheduled for completion in 1990. At the completion of the formal evaluation, the National Computer Security Center will produce a final evaluation report, and place the MLS LAN on the Evaluated Products List. The MLS LAN will be evaluated against Appendix A of the Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria, as a candidate A1-MI network component. It can potentially be incorporated into a network system that can meet the TNI part 1 requirements for class A1. A Product Bulletin does not assign any rating to a product. It merely establishes the candidate class which is the highest class the system could attain should formal evaluation be completed. As with all evaluations, a system must complete the formal evaluation phase before being assigned any rating. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090404595400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 03:22:10 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA28747; Wed, 5 Sep 90 03:07:50 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Sep 90 04:59:54 GMT From: comp.vuw.ac.nz!asjl@uunet.uu.net (Andy Linton) Organization: Computer Science Dept, Victoria University, Wellington, NEW ZEALAND Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <1990Sep04.045954.25664@comp.vuw.ac.nz> References: <1990Aug30.091435.1982@ircam.ircam.fr, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Just a few words of support for Lee from one who used to have JANET style access to the Internet i.e. poor to non-existent when I was at Newcastle. I have much better access to my colleagues in the US, Australia and the rest of Europe than I ever did while in the UK and I would be very loath to go back to the inferior *international* networking available in the UK. Lee's point about the JANET authorities seeing the solution in terms of OSI protocols is unfortunately true. It will be wonderful when (or is it if) it happens but the real world is voting for TCP/IP now to be replaced by some as yet undefined set of protocols which will leap frog over the OSI stack. So do us all a favour and open the door into and out of the UK. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090406592400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 03:34:11 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29947; Wed, 5 Sep 90 03:20:26 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Sep 90 06:59:24 GMT From: mcsun!dfk@uunet.uu.net (Daniel Karrenberg) Organization: European Unix systems User Group Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <1790@mcsun.eu.net> References: <1990Aug30.091435.1982@ircam.ircam.fr, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil lmjm@doc.ic.ac.uk (Lee McLoughlin) writes: >My parting question is directed the those that run UKNET: when is >tcp/ip going to be available to UKNET members in the same way as it is >to Eunet members? My understanding of the situation is that those that *run* UKNET would very much like to offer that service. The problem is that the organisation where the backbone site is housed fears political pressures from ISOrmites both inside and outside of that organisation. So far not quite enough paying customers have surfaced to set up a separate organisation offering IP services in the UK. Something else: At the last RIPE meeting there were (weak) signals to be heared from the JNT that IP over JANET is not as indiscussable as it used to be. That was -again- for some privileged sites that spoke up. Maybe those who want it should make up a case and go ask again. I won't hold my breath but on the other hand you change nothing by sitting and waiting (and complaining to the rest of the world). Got to the JNT and ask them about services like X-windows, NFS etc. *now*. Daniel -- Daniel Karrenberg Future Net: CWI, Amsterdam Oldie Net: mcsun!dfk The Netherlands Because It's There Net: DFK@MCVAX ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009050613.AA05957@ucbvax.Berkeley.EDU] <1990090409350700> From: CAPUANO%ICNUCEVM.CNUCE.CNR.IT@CUNYVM.CUNY.EDU ("Vincenzo G. Capuano") Newsgroups: comp.protocols.tcp-ip Subject: Slip dialer Message-ID: <9009050613.AA05957@ucbvax.Berkeley.EDU> Date: 4 Sep 90 09:35:07 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 Posted: Tue Sep 4 10:35:07 1990 I am looking for a slip (or ppp) dialer for SunOS, I want to use it in the following way: at call-me-at-home Thanks, Vincenzo =-=-=-= Capuano Vincenzo G. Capuano E-mail: capuano@cnuce.cnr.it Via Dante Alighieri, 9 capuano@icnucevm.bitnet 57036 Porto Azzurro (LI) Italy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1792@mcsun.eu.net] <1990090410331900> From: dfk@eu.net (Daniel Karrenberg) Newsgroups: comp.protocols.tcp-ip Subject: Re: Long lines... Message-ID: <1792@mcsun.eu.net> Date: 4 Sep 90 10:33:19 GMT References: <9008311031.aa04635@NRI.NRI.Reston.VA.US> Organization: European Unix systems User Group Lines: 67 Posted: Tue Sep 4 11:33:19 1990 pgross@NRI.RESTON.VA.US ("Phillip G. Gross") writes: >Your 6 hop path is certainly more direct, but notice that it takes almost >5 seconds, while the more convoluted 18 hop path via Princeton and Cornell >takes only little more than a second. With that type of difference, I have >a better understanding for routes via NSFnet for intra-European traffic. >>traceroute to 129.102.0.1 (129.102.0.1), 30 hops max, 38 byte packets >> 1 iracs1.ira.uka.de (129.13.1.1) 20 ms 0 ms 0 ms >> 2 ciscogb5.Informatik.Uni-Dortmund.DE (188.1.132.1) 1020 ms 840 ms 1080 ms >> 3 Amsterdam.NL.EU.NET (134.222.1.1) 4120 ms * 3800 ms >> 4 Paris.FR.EU.NET (134.222.2.2) 4340 ms 4900 ms 3760 ms >> 5 fnet-gw.inria.fr (128.93.36.128) 3880 ms 3740 ms * >> 6 192.44.64.61 (192.44.64.61) 3980 ms 4960 ms * Just to get the technical facts straight: The 1s delay on hop 1-2 is due to the German research network WIN which is 64kbit/s X.25. I expect that the WIN conections and interfaces on both iracs1.ira.uka.de and ciscogb5.Informatik.Uni-Dortmund.DE are quite loaded so we are looking at queueing delays here both inside WIN and at the routers connecting to it. The 3s delay on hop 2-3 is due to an "open jaw" situation. Traceroute only reports the *outbound* path the packets take. The way the icmp packets get back to the host running traceroute is not reported. No blame on traceroute, it's hard to do. So although it is tempting to assume that the packets come back the same way they get there this is not necessarily true. In this case Amsterdam.NL.EU.net does not know the "direct" route back to Karlsruhe. So the packets are sent by the default route which ends up on NSFnet which delivers using the "long way": traceroute to 129.13.1.1 (129.13.1.1), 30 hops max, 40 byte packets 1 Amsterdam.NL.EU.net (192.16.202.32) 10 ms 0 ms 0 ms 2 Falls-Church.VA.ALTER.NET (134.222.5.2) 1200 ms 560 ms 310 ms 3 College-Park.MD.ALTER.NET (137.39.11.2) 140 ms 150 ms 220 ms 4 192.80.214.254 (192.80.214.254) 260 ms 360 ms 480 ms 5 Ithaca.NY.NSS.NSF.NET (129.140.74.9) 860 ms 2330 ms 2330 ms 6 lan.cornell.site.psi.net (192.35.82.1) 2940 ms 2090 ms 1910 ms 7 cornell.syr.pop.psi.net (128.145.30.1) 1450 ms 1190 ms 740 ms 8 albpop.syr.pop.psi.net (128.145.20.2) 420 ms 390 ms 350 ms 9 albpop.nyc2.pop.psi.net (128.145.80.1) 730 ms 470 ms 850 ms 10 nyc2.nyc1.pop.psi.net (128.145.42.2) 510 ms 200 ms 220 ms 11 nyc_P.lan.nyc1.pop.psi.net (128.145.213.1) 500 ms 370 ms 670 ms 12 nyc1.cuny.pop.psi.net (128.145.14.1) 760 ms 400 ms 710 ms 13 128.145.254.5 (128.145.254.5) 800 ms 390 ms 770 ms 14 * iracs1.ira.uka.de (192.54.104.49) 6810 ms 6760 ms As you can see round trip delays on this route are highly variable. The bottleneck is certainly hop 13-14 which is 19.2 kbit/s at this point. The "faster" traceroute on that route shown earlier in the discussion has just hit the other extreme of the distribution. So far the facts, now the reasons: We are working on the European connectivity problem that this case shows. Since we don't have a pan-European agency wise enough to fund a European equivalent of NSFnet this takes local funding arrangements and they take time. Beleive me we are working hard on this. -- Daniel Karrenberg Future Net: CWI, Amsterdam Oldie Net: mcsun!dfk The Netherlands Because It's There Net: DFK@MCVAX ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090410352400> Received: from twg.com by NIC.DDN.MIL with TCP; Tue, 4 Sep 90 17:35:24 PDT Received: from TWG.COM by twg.com with SMTP ; Tue, 4 Sep 90 17:18:35 PST Received: from leosmac.twg.com by Obelix.TWG.COM id aa23130; 4 Sep 90 17:17 PDT From: ljm@obelix.twg.com To: tcp-ip@nic.ddn.mil Cc: ljm@obelix.twg.com Subject: Re: PC-NFS performance Message-ID: <9009041717.aa23130@Obelix.TWG.COM> >I am working on a system that will require "real-time" data transfer >from a Sun IPC to a 386 PC-clone (20 or 25 MHz) via Ethernet. For us, >in this case, "real-time" means 500-1000 byte packets, 10 per second, >from the Sun to the PC. The PC and Sun will be on a dedicated >Ethernet, i.e. *nothing* else on that wire... > >Unfortunately, someone has convinced people around here that PC-NFS >"won't do real-time" and that we must "write our own Ethernet protocol >stack" to get the performance we need. :-(... With our *TCP* stack, on a 25 Mhz clone, you can get ~600 1000 byte packets/second -- with UDP you can melt the wire. Note that this PC to PC, a SUN (at least with a stock protocol stack) can't keep up. With this in mind, I would find it very, very difficult to believe that SUN's PC-NFS will have any trouble at all transmitting just 10 packets/second. enjoy, leo j mclaughlin iii The Wollongong Group ljm@twg.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090411350700> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Tue, 4 Sep 90 01:55:38 PDT Received: from ICNUCEVM.CNUCE.CNR.IT by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 5753; Tue, 04 Sep 90 04:45:21 EDT Received: from ICNUCEVM.CNUCE.CNR.IT (CAPUANO) by ICNUCEVM.CNUCE.CNR.IT (Mailer R2.07) with BSMTP id 2604; Tue, 04 Sep 90 10:37:22 MET Date: Tue, 04 Sep 90 10:35:07 MET From: "Vincenzo G. Capuano" Subject: Slip dialer To: TCP-IP List I am looking for a slip (or ppp) dialer for SunOS, I want to use it in the following way: at call-me-at-home Thanks, Vincenzo =-=-=-= Capuano Vincenzo G. Capuano E-mail: capuano@cnuce.cnr.it Via Dante Alighieri, 9 capuano@icnucevm.bitnet 57036 Porto Azzurro (LI) Italy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090411590700> Received: from A.ISI.EDU by NIC.DDN.MIL with TCP; Tue, 4 Sep 90 13:01:23 PDT Date: Tue 4 Sep 90 15:59:07-EDT From: Michael Padlipsky Subject: Re: Hosts whose IP numbers end in 0... To: braden@venera.isi.edu cc: ietf-hosts@nnsc.nsf.net, ietf-rreq@jessica.stanford.edu, postel@venera.isi.edu, tcp-ip@nic.ddn.mil In-Reply-To: <9008311641.AA02779@braden.isi.edu> Message-ID: <12619306165.20.PADLIPSKY@A.ISI.EDU> Bob, Jon, et al.-- In the spirit of "Sometimes it's necessary to make sure everybody means the same thing even by 'NO-OP'", I suspect it's past time for me to observe that the problem with the Subject "thread" is that some of the discussants seem to be making rather different unstated assumptions about "filtering" than others are. I THINK the original question had to do with what we might call "outgoing filtering", in the sense of rejection of datagrams by gateways other than the gateway which is connected to the/a communications subnetwork (NOT "subnet" in the current jargon sense of the term) to which the destination Host is attached, which is the only gateway that could "know" whether the proferred address would lead to a broadcast. Yet several of the responses SEEM to be taking the point of view of just that "terminal" gateway and holding that of course it's entitled to "filter". My own impression is that it's precisely this latter, "incoming filtering", case in which "judgement" might/can/should be exercised by a gateway, and only this latter, incoming filtering case. But irrespective of whether that's the "correct" view, I do think that the thread will remain tangled until and unless we start explicitly distinguishing between "outgoing" and "incoming" "filtering"--the failure to do which EXPLICITLY I did mentally note, and regret not commenting upon, when the message Jon subsequently endorsed went by, b/t/w, thinking I'd probably just skimmed over it too quickly and assuming the issue would eventually be resolved without my having to make a religious (= Semantic Puritanism) issue of it. However, now that we've got the co-authors of the Requirements RFC in apparent disagreement, it does seem desirable to confirm that they aren't just re-enacting the old baddie about the neighbors who could never agree because they were arguing from different premises.... Semantically Puritanical cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1213@vision.UUCP] <1990090412272600> From: chris@vision.UUCP (Chris Davies) Newsgroups: uk.misc,eunet.followup,comp.protocols.tcp-ip Subject: Re: Internet routing Europe - USA -} Europe... Summary: Academic vs Comercial Sites Message-ID: <1213@vision.UUCP> Date: 4 Sep 90 12:27:26 GMT References: <1990Aug30.091435.1982@ircam.ircam.fr <6190@vanuata.cs.glasgow.ac.uk> Reply-To: chris@vision.UUCP (Chris Davies) Organization: VisionWare Ltd., Leeds, UK Lines: 25 Posted: Tue Sep 4 13:27:26 1990 In article lmjm@doc.ic.ac.uk (Lee McLoughlin) writes: ... >Even something as simple as running tcp/ip over JANET so we can have >some degree of sane networking here in the UK seems to be out. The >JANET powers that be do not want anything as useful as tcp/ip sullying >there network! God forbid you should be able to use the networking Not only can't you use tcp/ip over JANET, but commercial sites (in my experience) can't even use JANET as it stands - not even for real money. So no NIFTP, etc. >My parting question is directed the those that run UKNET: when is >tcp/ip going to be available to UKNET members in the same way as it is >to Eunet members? What a wonderful thought. Perhaps commercial sites would be allowed to use it too (at less that 10k p.a. for the privilege)? Chris -- VISIONWARE LTD | UK: chris@vision.uucp JANET: chris%vision.uucp@ukc 57 Cardigan Lane | US: chris@vware.mn.org OTHER: chris@vision.co.uk LEEDS LS4 2LE | BANGNET: ...{backbone}!ukc!vision!chris England | VOICE: +44 532 788858 FAX: +44 532 304676 -------------- "VisionWare: The home of DOS/UNIX/X integration" -------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090414243100> Received: from pucc.PRINCETON.EDU by NIC.DDN.MIL with TCP; Tue, 4 Sep 90 07:21:17 PDT Received: from CEARN.cern.ch by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 7459; Tue, 04 Sep 90 10:18:03 EDT Received: from CZHRZU1A(K602340) by CEARN (Mailer R2.07B) id 0606; Tue, 04 Sep 90 14:23:42 GVA Date: Tue, 04 Sep 90 14:24:31 GMT Subject: Re: CMU TCP/IP and name serving problems In-Reply-To: Message of Mon, 03 Sep 90 15:59:45 GMT from From: RUEDI BOESCH To: TCP-IP@NIC.DDN.MIL Kommt mir irgendwie bekannt vor..., mal schauen ob die Antwort auch mal kommt. Merci Acknowledge-To: ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1990Sep4.162046.13457@julius.cs.uiuc.edu] <1990090416204600> From: zweig@cs.uiuc.edu (Johnny Zweig) Newsgroups: comp.protocols.tcp-ip Subject: Re: sockets vs. streams Message-ID: <1990Sep4.162046.13457@julius.cs.uiuc.edu> Date: 4 Sep 90 16:20:46 GMT References: <6964@milton.u.washington.edu> Sender: news@julius.cs.uiuc.edu Reply-To: zweig@cs.uiuc.edu Organization: U of Illinois, Dept. of Computer Science, Systems Research Group Lines: 21 Posted: Tue Sep 4 17:20:46 1990 In my (object-oriented) implementation of TCP, the interface to the TCP processing module is based on TCP-messages. You can set/check flags and numbers and all that kind of crap. It is somebody else's job to make it look like a file or whatever. If you want a file that automagically creates a network connection when you open it (and what is this /dev/tcp/XXX nonsense all about? Sheesh! I want a file called "Dad" that opens a connection to the talk daemon on pop's macintosh when I open it r/w -- this silly business with IP addresses and port numbers is just as much Someone Else's Problem as making the whole goddamn mess look like a file). I think this whole discussion is misguided (though convenient for those of us who wish to Change the World) in that it makes the assumption that there is some best way to think about network communications. This is false. Networking is complicated (Zweig's Axiom). The paradigm for thinking about something and the something itself are different, and if the great minds behind UNIX can't hack that, well, shout at them (as Mark appears to be doing). A corrollary to the fact that they are different is that they should be handled by different pieces of the OS. -Johnny Paradigm ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090416290200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 05:29:44 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27026; Thu, 6 Sep 90 05:18:43 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Sep 90 16:29:02 GMT From: att!watmath!maytag!mks.com!mks!eric@ucbvax.Berkeley.EDU (Eric Gisin) Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA Subject: Tahoe rlogin and timed ported to System V? Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Has anyone ported the 4.3-tahoe rlogin and timed to System V AND made the source freely available? (I'm interested in an Interactive UNIX version, but any version will save be useful). Rlogin looks straight-forward but time-consuming. I want to enable the support for ~, which Interactive neglected when they added job control. Timed is difficult because you have to emulate adjtime(2). Any simple program that acts like a timed slave would do too. As a related question, I'm curious how different vendors deal with the select/poll on the tty and socket/stream in telnet. System Vr3 did not have the ability to poll character devices. This is not an issue in rlogin, which uses two processes instead of select. Interactive extended poll to work on ttys and ptys (and pipes), and select automatically aquires this poll functionality. How do SCO UNIX or ESIX handle this? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1990Sep4.172923.25008@spectrum.CMC.COM] <1990090417292300> From: lars@spectrum.CMC.COM (Lars Poulsen) Newsgroups: comp.protocols.tcp-ip Subject: Re: Sockets vs streams. An attempt to answer the original question Message-ID: <1990Sep4.172923.25008@spectrum.CMC.COM> Date: 4 Sep 90 17:29:23 GMT References: <1990Aug28.162400.17811@zoo.toronto.edu> <38584@ucbvax.BERKELEY.EDU> Organization: Rockwell CMC Lines: 31 Posted: Tue Sep 4 18:29:23 1990 In article <1990Aug28.162400.17811@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >spencer> The way to do i/o on Dennis's streams was with "read" and "write". >spencer> Network i/o, in general, looked *exactly* like local device i/o. > >spencer> This is the way it should be, unlike what both Berkeley and >spencer> AT&T have done (both have reluctantly conceded that most people >spencer> want to use "read" and "write" and have made that work, but >spencer> their hearts were clearly elsewhere). In article pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >And for good reason! read() and write() on file descriptors is not the >most amusing interface. It is much more convenient to have ... [features] The problem is larger than that. As commercial programmers have often said, unix read() and write() is not a very good interface for files, either. It is a good interface for SIMPLE TEXT files, and very little else. Having a guaranteed subset of compatible functionality has allowed very productive use of the "building block" philosophy. Having a way to specify a remote conenctions "as if" it were a filename would allow more things to be prototyped with simple shell scripts and pipelines. On the other hand, great flexibility leads to a loss of device independence, witness VMS' proliferation of pseudo-device drivers as an example of where the path of customized interfaces may take us. -- / Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1990Sep4.182414.29712@kth.se] <1990090418241400> From: perand@admin.kth.se (Per Andersson) Newsgroups: comp.protocols.iso.dev-environ,comp.protocols.tcp-ip,comp.dcom.lans Subject: SNMP with PSI snmp and ISODE 6.0 Message-ID: <1990Sep4.182414.29712@kth.se> Date: 4 Sep 90 18:24:14 GMT Organization: Royal Institute of Technology, Stockholm, Sweden Lines: 15 Posted: Tue Sep 4 19:24:14 1990 Hello. I have been trying to run snmpxmon from PSI to monitor a network of Suns, Annexes, Fastpaths etc. The Suns were running the snmpd from isode 6.0. snmpxmon wouldn't understand that the Suns were running, but while looking with cmu's snmpstatus I get "4BSD ISODE/SNMP" from snmpd. Anybody willing to explain what I am doing wrong ? I am sure I am.... Per -- --- Per Andersson Trying a new job at Bofors Electronics, still reading news at the Royal Institute of Technology ----MESSAGE-END---- ----MESSAGE-BEGIN---- [JIM.90Sep4195515@baird.cs.strath.ac.uk] <1990090418551500> From: jim@cs.strath.ac.uk (Jim Reid) Newsgroups: uk.misc,eunet.followup,comp.protocols.tcp-ip Subject: Re: Internet routing Europe - USA -} Europe... Message-ID: Date: 4 Sep 90 18:55:15 GMT References: <1990Aug30.091435.1982@ircam.ircam.fr <6190@vanuata.cs.glasgow.ac.uk> <1213@vision.UUCP> Sender: jim@cs.strath.ac.uk Organization: Computer Science Dept., Strathclyde Univ., Glasgow, Scotland. Lines: 19 Posted: Tue Sep 4 19:55:15 1990 In-reply-to: chris@vision.UUCP's message of 4 Sep 90 12:27:26 GMT In article <1213@vision.UUCP> chris@vision.UUCP (Chris Davies) writes: Not only can't you use tcp/ip over JANET, but commercial sites (in my experience) can't even use JANET as it stands - not even for real money. So no NIFTP, etc. This is untrue. Commercial sites may use JANET provided they have good reasons for doing so, essentially collaboration with an academic site on a research project. JANET cannot be used for purely commercial traffic (shunting data between a company's offices - or two distinct commercial sites - in Exeter and Aberdeen say). The rules are roughly similar to those for use of NSFnet: "free" government funded networks must not subsidise commercial traffic. It's more or less OK for a company to connect via PSS through a PSS/JANET gateway to an academic site and exchange data. In fact, this is how some of the big commercial sites get their news. Jim ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090420205600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 02:20:22 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23298; Wed, 5 Sep 90 02:10:33 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Sep 90 20:20:56 GMT From: van-bc!ubc-cs!news-server.csri.toronto.edu!utgpu!utzoo!henry@ucbvax.Berkeley.EDU (Henry Spencer) Organization: U of Toronto Zoology Subject: Re: Sockets vs streams. An attempt to answer the original question Message-Id: <1990Sep4.202056.2434@zoo.toronto.edu> References: , <1990Aug28.162400.17811@zoo.toronto.edu>, <38584@ucbvax.BERKELEY.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <38584@ucbvax.BERKELEY.EDU> sklower@ernie.Berkeley.EDU.UUCP (Keith Sklower) writes: >>...the way it should be, unlike what both Berkeley and AT&T have done >>(both have reluctantly conceded that most people want to use "read" >>and "write" and have made that work, but their hearts were clearly >>elsewhere). > >I find this inaccurate, partronizing and tiresome. I have worked around >Berkeley since 1978 and although was not a member of the actual unix group >in 1982 while TCP was being incorporated, attended their meetings and >seminars. I wasn't there; all I got to do was read the resulting documents. Some of which come over with a very strong air of "well, if you want to do it right, you will of course use our 57 new system calls, but we grudgingly admit that read/write will work if you insist on being backward". -- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090420303400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 02:27:25 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23372; Wed, 5 Sep 90 02:11:33 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Sep 90 20:30:34 GMT From: van-bc!ubc-cs!news-server.csri.toronto.edu!utgpu!utzoo!henry@ucbvax.Berkeley.EDU (Henry Spencer) Organization: U of Toronto Zoology Subject: Re: Sockets vs streams. An attempt to answer the original question Message-Id: <1990Sep4.203034.2655@zoo.toronto.edu> References: <9008311500.AA12356@ftp.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9008311500.AA12356@ftp.com> jbvb@ftp.com writes: > ...That's all most customers want. > >I see where our viewpoints differ: I am selling applications to end-users, >and I intend to support them. Most of the end-users who use our Development >Kit for one-off or in-house applications are probably quite satisfied with >open/read/write/close. However, I am careful to advise any OEMs who develop >for resale to pay close attention to the flags and error codes... I was writing from the down-in-the-wires viewpoint, where *any* user process is a customer. And on the whole, I remain unrepentant. :-) It should be possible to use open/read/write/close, with (say) perror when something goes wrong, without major problems, assuming that error-message-and-die is a reasonable thing to do on failure. A requirement for fault tolerance does require closer attention to error handling, as in non-networked code. Also as in non-networked code, a requirement for carefully optimized use of system resources requires attention to flags and details. And anyone building production code should be aware of the grubby details, so that he can recognize the one case in a hundred where some of them are relevant. However, I continue to believe that what most applications want to see is a reliable bidirectional pipe, perhaps set up in slightly odd ways but thereafter used via read/write/close, with invisible recovery from transient problems and a suitable errno value on hard failure. The resemblance to a Unix file is not accidental. :-) -- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090421111700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 4 Sep 90 20:33:44 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21249; Tue, 4 Sep 90 20:31:02 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Sep 90 21:11:17 GMT From: ncs.dnd.ca!hnadra@rutgers.edu (Hicham N Adra) Organization: Dept of National Defence Subject: TCP/IP over X.25 : a Network Interface Message-Id: <1990Sep4.211117.11713@ncs.dnd.ca> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Our organization, the Ottawa branch of the CGI Group, is interested in information about implementations of RFC 877 (A Standard for the Transmission of IP Datagrams Over Public Data Networks, DDN NIC). We are attempting to (re-) establish our connection to DREnet (Defence Research Establishment Network), "a communications network that has been developed to support the Research and Development activities of the Department of National Defence". DREnet sites are connected to Datapac and use TCP/IP over CCITT X.25. Also of interest is the availability of the source code release of Purdue University's X.25 Network Interface (XNI). NOTE: The host under consideration is a Unisys 6000/30 system with System V Release 2.20 Version 8.02. We also have other systems including a VAX 750 with VMS 5.3-1. Both are also part of a LAN. The current objective is to establish CGI's access to DRENET through the *Unisys system*, however. (How can this best be achieved?) END OF NOTE. Your insights about, and experience with, both general approaches and specific solutions are appreciated. Thank you. Hicham N. Adra 275 Slater St. 19th Floor Tel: (613) 234-2155. CGI Group Ottawa, Ontario K1P 5H9 Fax: (613) 234-6934. hnadra@ncs.dnd.ca Canada ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090423574300> Received: from ftp.com by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 05:18:12 PDT Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA13831; Wed, 5 Sep 90 08:17:43 -0500 Date: Wed, 5 Sep 90 08:17:43 -0500 Message-Id: <9009051317.AA13831@ftp.com> To: tcp-ip@nic.ddn.mil Subject: Re: PC-NFS performance From: jbvb@ftp.com (James B. Van Bokkelen) Reply-To: jbvb@ftp.com Sender: jbvb@ftp.com Repository: babyoil.ftp.com Originating-Client: plug.ftp.com Transfer rates significantly less than 10 packets/sec are relatively easy to achieve if you have a sufficiently lousy Ethernet interface (e.g. 3C501) and offer a big TCP window to a fast host afflicted with the standard 4.2bsd TCP retransmit algorithm. Leo is describing a tuned situation with good hardware. Your prophet of doom has probably seen a pathological situation with bad hardware. Writing your own relaible protocol on both ends of the connection is a lot of effort. Perhaps your prophet of doom would be appeased by the use of one of the freeware TCP/IP stacks, which would allow you to tinker starting from a working baseline.... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7060@milton.u.washington.edu] <1990090500384200> From: mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) Newsgroups: comp.protocols.tcp-ip Subject: Re: sockets vs. streams Message-ID: <7060@milton.u.washington.edu> Date: 5 Sep 90 00:38:42 GMT References: <6964@milton.u.washington.edu> <5329@munnari.oz.au> Sender: news@milton.u.washington.edu Organization: Mendou Zaibatsu, Tomobiki-Cho, Butsumetsu-Shi Lines: 59 Posted: Wed Sep 5 01:38:42 1990 In article <5329@munnari.oz.au> kre@cs.mu.OZ.AU (Robert Elz) writes: >There was a time when building network names into the filesystem >was seen as a sensible thing to do - nice and regular, existing >programs would be able to use them, ... Yes, many dinosaur operating systems did just that. There are still a few examples of those dinosaurs, and they are running just fine with precisely that mindset. That is not the reason they are dinosaurs; more likely, the antiquity of the hardware platform is more responsible for their extinction. >Unfortunately, while its a nice idea, it really won't work in general, >and if it doesn't work in general, its not worth the effort. ^^^^^^^^^^^^^^^^^^^^^^^^ I think this is more the the point than anything else. The high priests of sockets don't think it is worth the effort to support heresy. >[lots of spurious arguments about why simple things must be made > harder than necessary] All of these problems (even DNS lookups of hosts in filenames) were solved in other operating systems. It doesn't matter *how* complicated the most complicated file specifier can be; all that matters is that the defaults are the right thing for all but the oddball cases so the simple case is simple. >Now, the easy part is solved, TCP just isn't that complex, but >lets extend generality a little and open an OSI MHS (X.400) >connection as well. X.400 is at an entirely different level (not to mention stack) from TCP. You are mixing apples with orange juice. The OSI IP stack is probably a different device from /dev/tcp, and what layers on top of it is specific to that device. >Having that >file descriptor all the necessary options can be set before the >network is asked to establish the connection Here's the rub, and the real reason why we've been made to suffer with streams. However, this is conceptually easy to solve. Make the O_NDELAY form of open with none of {O_RDONLY | O_WRONLY | O_RDWR} set to mean "give me a designator only", and then have an ioctl() call that means "establish connection on this designator". Since we allow non-blocking open with establish (implicitly above), we probably want to have all the likely functions: block until open, establish and block, establish without blocking, test if open. Summary: the simple cases should be *simple*, not made complex for a theoretical complex case. _____ | ____ ___|___ /__ Mark ("Gaijin") Crispin "Gaijin! Gaijin!" _|_|_ -|- || __|__ / / R90/6 pilot, DoD #0105 "Gaijin ha doko?" |_|_|_| |\-++- |===| / / Atheist & Proud "Niichan ha gaijin." --|-- /| |||| |___| /\ (206) 842-2385/543-5762 "Chigau. Gaijin ja nai. /|\ | |/\| _______ / \ MRC@CAC.Washington.EDU Omae ha gaijin darou" / | \ | |__| / \ / \"Iie, boku ha nihonjin." "Souka. Yappari gaijin!" Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090502052100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 01:33:50 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA18757; Wed, 5 Sep 90 01:21:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Sep 90 02:05:21 GMT From: sdd.hp.com!uakari.primate.wisc.edu!uflorida!mlb.semi.harris.com!thrush.mlb.semi.harris.com!del@decwrl.dec.com (Don Lewis) Organization: Harris Semiconductor, Melbourne FL Subject: Re: sockets vs. streams Message-Id: <1990Sep5.020521.803@mlb.semi.harris.com> References: <6964@milton.u.washington.edu>, <2350@cirrusl.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <2350@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >In <6964@milton.u.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU >(Mark Crispin) writes: > >>If "network I/O looks like local device I/O" under Unix then when the >>h*ll do I have to worry about all the socket or streams crap? > >I think the confusion in this discussion is between reading and >writing on the one hand and opening the connection on the other >hand. > >Once a virtual circuit has been set up, the socket mechanism becomes >transparent to the extent networking will allow. Setting up the >virtual circuit does require more steps than opening a device or file. >I find this fairly understandable, because the BSD socket interface >gives you LOTS of options, and it was designed to be independent of the >underlying transport mechanism. > >>If I want to connect to port 0.143 on host 128.95.112.69, why can't I >>do something like >> open ("/tcp/128.95.112.69-0.143",O_RDWR|O_CREAT,0);... > >Like somebody said, it would be nice if there was a library routine >that would make this easy. I suppose the open() system call could also >do this, but then there might be too much functionality in a single >system call, because it would have to understand all possible protocols >and possibly accept additional parameters for the different types of >sockets and connections that are possible. If I have a local printer, I can send data to it by doing cat somefile >/dev/lp Now, if the printer is on a terminal server somewhere, it would sure would be nice to be able to do the same sort of thing. cat somefile >/dev/tcp/terminalserver:port or cat somefile >/dev/tcp/x.x.x.x-y.y You could even send it to two devices using tee! Specifically, you could use this for the lp= parameter in /etc/printcap so that you don't have to play funky filter games. The bottom line is that it should be possible to open connections with fopen() so that applications don't have to be modified in order to take advantage of this connectivity (assuming they don't rely on seeks and wierd ioctls that don't make sense on a network connection). -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090503341200> Received: from gateway.mitre.org by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 07:15:49 PDT Return-Path: Received: by gateway.mitre.org (5.61/SMI-2.2) id AA26062; Wed, 5 Sep 90 10:14:53 -0400 Full-Name: Bill Barns Message-Id: <9009051414.AA26062@gateway.mitre.org> To: sdd.hp.com!samsung!munnari.oz.au!metro!pta!yarra!chris@ucsd.edu (Chris Jankowski) Cc: tcp-ip@nic.ddn.mil, barns@gateway.mitre.org Subject: Re: "The Open Book" by Rose - your opinions sought In-Reply-To: Your message of "02 Sep 90 11:01:18 GMT." <65137@yarra.oz.au> Date: Wed, 05 Sep 90 10:14:12 -0400 From: barns@gateway.mitre.org To my kmnowledge, no book comparable to Comer exists for OSI and I doubt that one will be created any time soon. Open Book is about the best available and you might as well buy it (everyone else does), but it isn't as concrete as Comer because in the OSI world, these things are still being figured out. I think that is a limitation we just have to accept for a while yet. And in part, it will probably exist forever, because OSI is rather broader than TCP/IP and thus won't be able to be covered to the same depth in anything like the same number of pages, once we have figured out the right details. This is wild speculation, but I'd estimate a treatment of ALL of the OSI protocols to comparable depth would run about 5000 pages. /Bill Barns ----MESSAGE-END---- ----MESSAGE-BEGIN---- [120@crawford.UUCP] <1990090504250100> From: jhp@crawford.UUCP (Jay Pound) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.misc Subject: Fiber Optic Equipment Keywords: fiber optic ethernet terminal servers Message-ID: <120@crawford.UUCP> Date: 5 Sep 90 04:25:01 GMT Followup-To: comp.dcom.lans Organization: Crawford Post Production, Atlanta Lines: 20 Posted: Wed Sep 5 05:25:01 1990 I need to optically isolate 64 async ports from their terminals. I am looking at (1) using fiber optic terminal multiplexers or (2) going with terminal servers and fiber optic ethernet. My questions are: Can anyone recommend reliable fiber optic multiplexers and/or terminal servers? Has anyone used any of the Black Box fiber optic equipment? Is anyone using the Annex II (Xylogic) terminal servers (under any name)? Ethernet seems to be more expensive but it should make it easier for me to add another host system to the net. Any comments would be appreciated. Jay Pound -- Jay Pound / Crawford Post Production, Inc. jhp%crawford.UUCP@mathcs.emory.edu / 535 Plasamour Drive gatech!emory!crawford!jhp / Atlanta, Georgia 30324 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090505054100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 03:12:36 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27791; Wed, 5 Sep 90 02:58:28 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Sep 90 05:05:41 GMT From: sdd.hp.com!usc!orion.oac.uci.edu!mothra.nts.uci.edu!meggers@decwrl.dec.com (Mark Eggers) Subject: routing with virtual subnets Message-Id: <26E487A4.28053@orion.oac.uci.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am working with a company that has a rather different short-term requirement. The setup is as follows: --------------- Sun ----------- cisco ----- (world) subnet a | subnet e subnet b | subnet c | subnet d | | | slip to subnet f Subnets b-d are 'virtual' subnets, existing on the same wire as subnet a. I can route between the subnets a-d by adding the following type of lines: route add net.b.0 hostip 0 where hostip is the IP address of the host that the route is being added to. Gated is running on the Sun, and announces subnets a-d, and f to the cisco. However, I cannot route from subnets b-d to any other subnet on the other side of the Sun, or through the cisco. Any thoughts would be appreciated. /mde/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [24135:Sep505:55:0790@kramden.acf.nyu.edu] <1990090505550700> From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.protocols.tcp-ip Subject: Re: sockets vs. streams Message-ID: <24135:Sep505:55:0790@kramden.acf.nyu.edu> Date: 5 Sep 90 05:55:07 GMT References: <13526@mentor.cc.purdue.edu> <9009012315.AA08202@world.std.com> Organization: IR Lines: 24 Posted: Wed Sep 5 06:55:07 1990 Several people say that it's best to put everything into the filesystem. But opening a file may not make sense for client-server applications. Files may not be a very good abstraction for network communications in general. UNIX has from its conception given us an infinitely better solution: passing references to files through descriptors instead of names. So why don't we take advantage of this? Why don't we separate out *opening* a file or *connecting* to a TCP server or *waiting* for a connection into specialized programs? Why don't we have those programs pass the suitably initialized descriptors to our processes? In other words, why don't we take the modularity that we can get? Answer: We can. Opening a file is done by your shell: $ From: mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) Newsgroups: comp.protocols.tcp-ip Subject: Re: sockets vs. streams Message-ID: <7084@milton.u.washington.edu> Date: 5 Sep 90 06:10:07 GMT References: <13526@mentor.cc.purdue.edu> <9009012315.AA08202@world.std.com> Sender: news@milton.u.washington.edu Organization: Mendou Zaibatsu, Tomobiki-Cho, Butsumetsu-Shi Lines: 40 Posted: Wed Sep 5 07:10:07 1990 In article <9009012315.AA08202@world.std.com> bzs@WORLD.STD.COM (Barry Shein) writes: >I'm mixed on this issue. TOPS-20 had a file-system-like interface (was >that BBN's TCP?) and, to be frank, I found it quite clumsy (tho >interesting.) The string one passed to the open call started to look >more and more like a long string of IBM/JCL and less and less like a >file name as various options were added. Hmm, I guess you never did much in JCL; I did, and believe me, the name of TCP: files was a lot simpler! The main bug in the TOPS-20 interface was that passive (listening), not active, was the default. Anyway, the TOPS-20 filesystem TCP interface came from DEC. The original BBN interface was one that every socket hacker would love. It implemented an entirely new set of system calls just for TCP, passing around an entirely separate space of designators from files, so every program that did network I/O had to have a completely different I/O path just for TCP. A gory mess. DEC was originally going to rewrite it, but what they ended up doing was writing a filesystem driver that used the BBN calls internally. Eventually, there were some special hacks done to reduce the overhead, but the underlying BBN mess remained. However -- once the filesystem interface was available I don't know of a single applications programmer who used the BBN calls. Everybody wrote using the TCP: device. I'm quite familiar with all this as I wrote most of the TOPS-20 applications-level TCP software. Just you wait. I'm sure that someone is going to end up inventing yet another I/O schema for ISO. And everyone will scream for something that is backwards compatible with sockets or streams. _____ | ____ ___|___ /__ Mark ("Gaijin") Crispin "Gaijin! Gaijin!" _|_|_ -|- || __|__ / / R90/6 pilot, DoD #0105 "Gaijin ha doko?" |_|_|_| |\-++- |===| / / Atheist & Proud "Niichan ha gaijin." --|-- /| |||| |___| /\ (206) 842-2385/543-5762 "Chigau. Gaijin ja nai. /|\ | |/\| _______ / \ MRC@CAC.Washington.EDU Omae ha gaijin darou" / | \ | |__| / \ / \"Iie, boku ha nihonjin." "Souka. Yappari gaijin!" Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090507082600> Received: from SH.CS.NET by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 10:59:10 PDT Received: by SH.CS.NET id aa13441; 5 Sep 90 13:54 EDT To: Benny Tong cc: tcp-ip@nic.ddn.mil, gwilliam@SH.CS.NET Subject: Re: tcp source port number assignment in new tcp connection In-reply-to: Your message of 03 Sep 90 07:08:24 +0000. <15096@shlump.nac.dec.com> Date: Wed, 05 Sep 90 13:48:26 -0400 From: George Williams Hello, I don't know what TCP/IP interface you are using but unless you are writing your own TCP implementation source port assignment should be a 'local', i.e. OS or TCP interface running on you machine, issue. All interfaces I've seen on DEC machines , and others, have returned this identifier; usually with the option for you to specify one....and even that may not result in what the remote TCP sees as your source identifier. On the interface level it is just a logical assignment and does not necessarily map to a 'real' TCP port. Maybe QIO stuff is different but even that returned a logical channel number if i recall correctly. If security is the issue then that's another discussion. In any event: () If you have a choice in the matter let your interface to TCP assign this. Less book keeping and cleanup. () If you are writing an interface and or your own TCP then take a look a what Excelan, Wollangong, DEC, and others have done already in this area.... () There were some discussion in this newsgroup ( whos right/wrong ) regarding two vendor's port assigments above 1000 which referenced an RFC, about a month ago. Impression I got was that the RFC came out the winner...no hard fast rule just agreed on and established convention in this area. Good luck, George Williams ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090507354000> Received: from server.af.mil by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 10:39:46 PDT Received: by server.af.mil (5.59/25-eef) id AA04903; Wed, 5 Sep 90 12:35:41 CDT From: Lt. Matt Jonson Message-Id: <9009051735.AA04903@server.af.mil> Subject: Heaven and Hell To: mek@devvax.jpl.nasa.gov Date: Wed, 5 Sep 90 12:35:40 CDT Cc: piet@cwi.nl, tcp-ip@nic.ddn.mil, beach@ddnuvax.af.mil X-Mailer: ELM [version 2.3 PL2] > Date: 30 Jul 90 12:42:10 GMT > From: mcsun!hp4nl!charon!piet@uunet.uu.net (Piet Beertema) > Organization: CWI, Amsterdam > Subject: Re: Network Temperature Protocol > Message-Id: <1907@charon.cwi.nl> > References: <9007240048.AA00668@bel.isi.edu>, <1990Jul25.073009.23336@specialix.co.uk> > To: tcp-ip@nic.ddn.mil > Resent-Date: Tue 31 Jul 90 10:34:48-CDT > Resent-From: Matt Jonson > Resent-To: jonson@server.af.mil > Resent-Message-Id: <12610083008.15.AFDDN.JONSON@GUNTER-ADAM.AF.MIL> > > > If sucessfully implemented, such a protocol would also contribute > towards reducing Global Warming. > Wonder if it would help reducing temperature in more > exotic places too, like those mentioned below: > > ============================================================================ > Some consolation > ---------------- > > I wish to clear up the old question: "Which is hotter, heaven or hell?" > > Verse 26 of Chapter 30 of Isaiah defines the energy radiated heavenward > by the sun and the moon in terms of the amount received by the earth: > "Moreover the light from the moon shall be sevenfold, as the light from > seven days". Thus, heaven receives from the moon as much energy as the > earth does from the sun. If we add to that 49 times ("seven times seven") > the earth's solar radiation falling on heaven, we have a total of 50 times > the energy we receive from the sun. Using a known absolute temperature > of the earth and the Stefan-Boltzmann fourth-power law, we arrive at the > determined temperature of heaven: a less than paradisiacal 525 degrC. > > And the temperature of hell? > > Revelation 21:8 says: "The fearful shall have part in the lake which burns > of fire and brimstone". Since brimstone (sulfur) has a boiling point of > 445 degrC, hell must be several degrees cooler. If it were not, it would > be a vapor, not a lake. > > Therefore, heaven is hotter than hell by at least 80 degrC. > ============================================================================ > > (Actually this story is a couple of years old already; > can't remember where I ever got it from). > > -- > Piet Beertema, CWI, Amsterdam (piet@cwi.nl) > He does make one potentially bad assumption, and that is that Heaven and Hell are both at the same Pressure. I would be willing to argue that Heaven, being much more ethereal, could have a significantly lower Pressure and hence lower temperature than arrived at here on earth, whereas I would also be willing to argue that Hell may be at a significantly higher pressure than here on earth, and hence, a much higher temperature. At this point, the argument suddenly moves to the plane of Philosophy... which doesn't have any description, but with the amount of hot air that it generates, could well be a good bit warmer than Heaven, Hell or Saudi Arabia. -Matt ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1940@jura.tcom.stc.co.uk] <1990090508181100> From: chris@tcom.stc.co.uk (Chris Milton) Newsgroups: uk.misc,eunet.followup,comp.protocols.tcp-ip Subject: Re: Internet routing Europe - USA -} Europe... Message-ID: <1940@jura.tcom.stc.co.uk> Date: 5 Sep 90 08:18:11 GMT References: <1990Aug30.091435.1982@ircam.ircam.fr <6190@vanuata.cs.glasgow.ac.uk> <1213@vision.UUCP> Reply-To: chris@htc2.UUCP (Chris Milton) Organization: STC Telecomms, Harlow Technical Centre, Harlow Lines: 15 Posted: Wed Sep 5 09:18:11 1990 yep. yep. yepyepyepyepyep. yep. that's wholehearted agreement there. one problemo though... a. can you see academic sites wanting to shell out money they aint got to modify up to internet ? b. can you see companies which aren't even on janet because it provides security problems wanting to go onto internet? pity you cant telnet using bitftp ... oh well, back to trying to find the gateway out of this organization into the real world *sigh*. oops, sorry, i mean back to doing that really interesting pascal prog :-) bye de bye chris chris@jura.tcom.stc.co.uk ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090509251000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 06:31:27 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03803; Thu, 6 Sep 90 06:27:04 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Sep 90 09:25:10 GMT From: mcsun!ukc!icdoc!citycs!sb380@uunet.uu.net (Andy Holt) Organization: City University, London Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <1990Sep5.092510.22637@cs.city.ac.uk> References: <1990Aug30.091435.1982@ircam.ircam.fr, , <1990Sep04.045954.25664@comp.vuw.ac.nz> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Not only is the present Janet policy (coloured books instead of TCP/IP) isolating us from the rest of the world, but it looks like the ISO transition will do the same again: The JNT in its infinite wisdom (???) has mandated that the ISO profile used in the UK use TC0 (connection oriented transport service) while NBS in the USA is encouraging the use of TC4 (connectionless transport service). Here we go again ..... Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1990Sep5.095450.12185@maths.tcd.ie] <1990090509545000> From: ajudge@maths.tcd.ie (Alan Judge) Newsgroups: uk.misc,eunet.followup,comp.protocols.tcp-ip Subject: Re: Internet routing Europe - USA -} Europe... Message-ID: <1990Sep5.095450.12185@maths.tcd.ie> Date: 5 Sep 90 09:54:50 GMT References: <1990Aug30.091435.1982@ircam.ircam.fr <6190@vanuata.cs.glasgow.ac.uk> Organization: Dept. of Maths, Trinity College, Dublin, Ireland. Lines: 10 Posted: Wed Sep 5 10:54:50 1990 In lmjm@doc.ic.ac.uk (Lee McLoughlin) writes: >Yes the UK is really the only Europaen country where not only do we >lack tcp/ip services to the internet but you *CANNOT GET* tcp/ip >services to the internet. Not quite :-( Ireland is still not IP connected. -- Alan Judge ajudge@maths.tcd.ie a.k.a. amjudge@cs.tcd.ie +353-1-772941 x1782 Fortunately the computer virus did no harm to our records. It was immediately devoured by all the bugs in our own programming. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009060544.AA10885@ucbvax.Berkeley.EDU] <1990090511155500> From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) Newsgroups: comp.protocols.tcp-ip Subject: Re: Long lines... Message-ID: <9009060544.AA10885@ucbvax.Berkeley.EDU> Date: 5 Sep 90 11:15:55 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Posted: Wed Sep 5 12:15:55 1990 >I'm waiting for the first report of usa->europe->japan->australia, >myself. we have a visitor from crete/greece here at the moment - as i type, he is reading his e-mail on a machine in Heraklion. the traffic from london is routed via princeton... it's still all pony express stuff though... jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090511385700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 09:50:42 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17481; Thu, 6 Sep 90 09:34:59 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Sep 90 11:38:57 GMT From: mcsun!ukc!edcastle!tardis.cs.ed.ac.uk!jonathan@uunet.uu.net (Jonathan Knight) Organization: Organisation ? What organisation ? Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <4835@tardis.cs.ed.ac.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil From article <1990Sep4.164546@jatz.aarnet.edu.au>, by pte900@jatz.aarnet.edu.au (Peter Elford): > And this from a user in country connected to the Internet via an > extremely wet piece > of string - a 14.4 kb voice grade modem link! At least he is connected to the Internet by something. Our political gateway (ukc) from the UK to Europe used to be a 9600 baud UUCP link. According to the maps at mcsun this is now a 9600 baud TCP/IP link. The rest of the UK uses something called coloured book software which works great as long as all you want to do is transfer files of data in the UK. It looks like the management want to go ISO, so at least we stand a chance of making contact with the rest of the world. It does seem foolish that with most of the world talking TCP/IP there are no plans in the UK for any TCP/IP service over JANET. Fortunately for us, the UKnet gateway isn't the only one. UCL have a 56Kb link to the USA and offer a guest FTP service which allows us to transfer files to and from internet connected sites. They also transfer our mail, and make no charge. This is unlike UKC which charge for news, and mail, and they also advertise themselves as a valid route for uk mail. This is a pain as they are trying to fit a full news feed and email down their 9600 baud line, when there is a no charge route for email down a 56kb line. There's also the problem that UKC advertise themselves as a forwarder for the ac.uk domain, when in fact they only forward mail to uknet members and drop everything else on the floor. UCL forward all ac.uk mail regardless of what they are members of. So you see that the UK has poor connectivity with the outside world and is politically restricted in its development. Hopefully somebody somewhere will learn how to utilise the resources we have to provide the service that we want, within my lifetime...... Then again, I'm not going to hold my breath. -- ______ JANET :jonathan@uk.ac.keele.cs Jonathan Knight, / BITNET:jonathan%cs.kl.ac.uk@ukacrl Department of Computer Science / _ __ other :jonathan@cs.keele.ac.uk University of Keele, Keele, (_/ (_) / / UUCP :...!ukc!kl-cs!jonathan Staffordshire. ST5 5BG. U.K. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1216@vision.UUCP] <1990090512133300> From: chris@vision.UUCP (Chris Davies) Newsgroups: uk.misc,eunet.followup,comp.protocols.tcp-ip Subject: Re: Internet routing Europe - USA -} Europe... Message-ID: <1216@vision.UUCP> Date: 5 Sep 90 12:13:33 GMT References: <1990Aug30.091435.1982@ircam.ircam.fr <6190@vanuata.cs.glasgow.ac.uk> <1213@vision.UUCP> Reply-To: chris@vision.UUCP (Chris Davies) Organization: VisionWare Ltd., Leeds, UK Lines: 34 Posted: Wed Sep 5 13:13:33 1990 In article <1213@vision.UUCP> I wrote, > Not only can't you use tcp/ip over JANET, but commercial sites (in my > experience) can't even use JANET as it stands - not even for real money. > So no NIFTP, etc. In article jim@cs.strath.ac.uk (Jim Reid) replied: >This is untrue. Commercial sites may use JANET provided they have good >reasons for doing so, essentially collaboration with an academic site >on a research project. JANET cannot be used for purely commercial >traffic (shunting data between a company's offices - or two distinct >commercial sites - in Exeter and Aberdeen say). Sorry, I should have stated my point more clearly. I was aware of this. But I think I'm correct in stating that a direct connection to JANET (as such) by a commerical site is not permissible (and so all traffic must go through a gateway - thus mail only, in effect). >The rules are roughly >similar to those for use of NSFnet: "free" government funded networks >must not subsidise commercial traffic. But if the commercial site(s) were to pay for their use of the government funded networks, then I don't see why this shouldn't be acceptable. With the current situation, I would agree that commercial sites should not exploit JANET for commercial gain. Chris -- VISIONWARE LTD | UK: chris@vision.uucp JANET: chris%vision.uucp@ukc 57 Cardigan Lane | US: chris@vware.mn.org OTHER: chris@vision.co.uk LEEDS LS4 2LE | BANGNET: ...{backbone}!ukc!vision!chris England | VOICE: +44 532 788858 FAX: +44 532 304676 -------------- "VisionWare: The home of DOS/UNIX/X integration" -------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009060644.AA12995@ucbvax.Berkeley.EDU] <1990090512432700> From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) Newsgroups: comp.protocols.tcp-ip Subject: was: sockets vs. streams / net open Message-ID: <9009060644.AA12995@ucbvax.Berkeley.EDU> Date: 5 Sep 90 12:43:27 GMT References: <5329@munnari.oz.au> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 Posted: Wed Sep 5 13:43:27 1990 >Henry Spenser asked why no-one has ever created a standard library >routine to open a connection. That's something I have wondered >about myself, it seems like a fairly obvious thing to do. But then actually, when i ported the X windows protocol to run over OSI as well as over TCP and DECnet, I did it by writing a small set of of arrays of functions (open, accept, read[v], write[v], close and getpeer which were indexed by the protocol family being used (either connection id type, or address family type) (not a very new idea), and this turned out to be perfectly sufficient functionality to get at adequate protocol service...it is also the flipside of the coin that transport service bridges are feasible... j. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090513555500> Received: from bells.cs.ucl.ac.uk by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 04:18:28 PDT Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id ; Wed, 5 Sep 1990 12:16:10 +0100 To: tcp-ip@nic.ddn.mil Subject: Re: Long lines... In-reply-to: Your message of 02 Sep 90 03:38:58 +0000. Date: Wed, 05 Sep 90 12:15:55 +0100 From: Jon Crowcroft >I'm waiting for the first report of usa->europe->japan->australia, >myself. we have a visitor from crete/greece here at the moment - as i type, he is reading his e-mail on a machine in Heraklion. the traffic from london is routed via princeton... it's still all pony express stuff though... jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- [339@megadata.mega.oz.au] <1990090514034300> From: andrew@megadata.mega.oz.au (Andrew McRae) Newsgroups: comp.protocols.tcp-ip Subject: Re: sockets vs. streams Summary: User mode file systems? Message-ID: <339@megadata.mega.oz.au> Date: 5 Sep 90 14:03:43 GMT References: <6964@milton.u.washington.edu> <2350@cirrusl.UUCP> <1990Sep5.020521.803@mlb.semi.harris.com> Organization: Megadata P/L, North Ryde, Sydney, Aust. Lines: 56 Posted: Wed Sep 5 15:03:43 1990 In article <1990Sep5.020521.803@mlb.semi.harris.com>, del@thrush.mlb.semi.harris.com (Don Lewis) writes: >In article <2350@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >>In <6964@milton.u.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU >>(Mark Crispin) writes: >> >>>If I want to connect to port 0.143 on host 128.95.112.69, why can't I >>>do something like >>> open ("/tcp/128.95.112.69-0.143",O_RDWR|O_CREAT,0);... > >Now, if the printer is on a terminal server somewhere, it would >sure would be nice to be able to do the same sort of thing. > cat somefile >/dev/tcp/terminalserver:port Perhaps a more structured approach to this whole problem is to back out of the kernel altogether and use the same paradigm as in some of the Research Unix kernels of a user mode file system (a la the /proc filesystem); using a UMFS would remove the complexity of mapping different file names to network address away from the kernel into user processes which could then use the BSD socket style kernel calls to hide the messy details of network programming. At least then the programs which want to access all those neato network calls can do so, but for those programs that want to open the network connection using a file name the UMFS would then interpret the name accordingly. Then different servers could be implemented to handle different protocols, and services e.g.: fd = open("/dev/net/stream/cpu.xyz/lat", 2); This could map to an entirely different protocol family (e.g. DECNet). or fd = open("/dev/net/tcp/2300/192.34.56.78", 2); Links could be set up to map "/dev/net/printer" to "/dev/net/tcp/termserver/printer"... It should be easy to take skeleton UMFS network servers and build specialised services (such as a nntp-service file etc.). A mach-like kernel with good messaging may fit well here.. Whilst the comment that has been made that what most processes want is a simple full duplex pipe-like stream (and the kind of open that has been talked about will work OK), I find the more common network programming I am involved with is using the datagram facilities (sendto, recvfrom etc) to build distributed services (especially real time stuff); using broadcasts and finding out who sent you a data packet is important as well. I hate to think what I would have to do if all I had was a read or write. Andrew McRae inet: andrew@megadata.mega.oz.au Megadata Pty Ltd, uucp: ..!uunet!megadata.mega.oz.au!andrew North Ryde 2113 Phone: +61 2 805 0899 NSW AUSTRALIA Fax: +61 2 887 4847 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090514173500> Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 18:24:55 PDT Received: by uunet.uu.net (5.61/1.14) with UUCP id AA04340; Wed, 5 Sep 90 21:24:51 -0400 Received: by world.std.com (5.61++/Spike-2.0) id AA21297; Wed, 5 Sep 90 20:57:35 -0400 Date: Wed, 5 Sep 90 20:57:35 -0400 From: bzs@world.std.com (Barry Shein) Message-Id: <9009060057.AA21297@world.std.com> To: tcp-ip@nic.ddn.mil In-Reply-To: (Piercarlo Grandi's message of 2 Sep 90 18:45:24 GMT Subject: Sockets vs streams. An attempt to answer the original question I think we're all looking at this in far too narrow a context. There are many issues that are being hand-waved (note, anyone who assumes I believe one way or the other on this issue please send me my decision as I haven't received it yet.) For example, when I address something that reaches out into, say, network name space, where does my request go? Does it go to a specialized driver that takes care of things like DNS resolution? Does it get handed back up to a user-level process? What? I still think the terminal example (open("/dev/tty/9600/even/noecho",...) was a good one. Someone sent me mail saying "oh, that's just ioctl()'s". What magic! Sockets are bad, ioctls are good, such power in a name. The real issue is: A) Are we trying to simplify/generalize the *user* interface so most any network/etc operation can be specified in a string, wherever a file name is expected? or B) Are we trying to simplify/generalize the *programmer* interface so they don't have to know about those nasty socket calls? Careful, I believe those two goals can be very much in conflict. I also don't believe that everyone discussing this issue on this list falls into the same camp. So we're having definite communications problems, state your objectives! -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090515232700> Received: from bells.cs.ucl.ac.uk by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 05:46:04 PDT Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id ; Wed, 5 Sep 1990 13:43:36 +0100 To: tcp-ip@nic.ddn.mil Subject: was: sockets vs. streams / net open In-reply-to: Your message of 02 Sep 90 17:59:27 +0000. <5329@munnari.oz.au> Date: Wed, 05 Sep 90 13:43:27 +0100 From: Jon Crowcroft >Henry Spenser asked why no-one has ever created a standard library >routine to open a connection. That's something I have wondered >about myself, it seems like a fairly obvious thing to do. But then actually, when i ported the X windows protocol to run over OSI as well as over TCP and DECnet, I did it by writing a small set of of arrays of functions (open, accept, read[v], write[v], close and getpeer which were indexed by the protocol family being used (either connection id type, or address family type) (not a very new idea), and this turned out to be perfectly sufficient functionality to get at adequate protocol service...it is also the flipside of the coin that transport service bridges are feasible... j. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [13644@mentor.cc.purdue.edu] <1990090515593300> From: dls@mentor.cc.purdue.edu (David L Stevens) Newsgroups: comp.protocols.tcp-ip Subject: Re: sockets vs. streams Message-ID: <13644@mentor.cc.purdue.edu> Date: 5 Sep 90 15:59:33 GMT References: <13526@mentor.cc.purdue.edu> <9009012315.AA08202@world.std.com> Organization: PUCC UNIX Group Lines: 25 Posted: Wed Sep 5 16:59:33 1990 In article <9009012315.AA08202@world.std.com>, bzs@WORLD.STD.COM (Barry Shein) writes: > As to David Stevens questions about file system semantics, what does > "cd /dev/anydev" mean now? Nothing, you get back "Not a directory". > In this mythical TCP you might get back something (e.g. some form of > NFS done this way), or not. I don't see that as a serious problem. It's not the same analogy, which was my point. Crispin's example, which you may not buy into, specifically uses "/"'s below the pseudo-device boundary so that they become the exception to the syntax-directed pathname translation that otherwise has the wonderfully dependable rule: "/ separates directories." It's wrong because it's ugly and it doesn't fit with UNIX. Sure, with a big enough hammer, you can make anything fit, but "/" is the wrong delimiter. If the syntax doesn't follow the semantics, you've only created a wart on a once-elegant system. As to the rest of your statement, I agree there is too much heat and I'm not sure why, either. There may very well be a reasonable solution that maps sockets onto a filesystem, but I see quite a few problems with the Crispin solution, and (Mr Crispin,) your straw-man arguments, which you make in your extremely creative interpretation of my article, don't support your case. To me, anyway. You leave me with the impression, whether justified or not, that you haven't thought through the details carefully, and that's where all the mess comes up in the first place. -- +-DLS (dls@mentor.cc.purdue.edu) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090516001900> Received: from wolf.cisco.com by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 22:02:00 PDT Received: from dustbin.cisco.com by wolf.cisco.com with TCP; Wed, 5 Sep 90 21:58:16 -0700 To: sdd.hp.com!usc!orion.oac.uci.edu!mothra.nts.uci.edu!meggers@decwrl.d.ec.com (Mark Eggers) Cc: tcp-ip@nic.ddn.mil Subject: Re: routing with virtual subnets In-Reply-To: Your message of "05 Sep 90 05:05:41 GMT." <26E487A4.28053@orion.oac.uci.edu> Date: Wed, 05 Sep 90 22:00:19 MDT From: Greg Satz All of the hosts on subnets a-d need to know about the overlayed scheme. That is hosts on subnet b need to know that subnets a, c, and d also exist on the same ethernet cable. The command that you used on your sun router to inform it of the overlay is also necessary for those hosts on subnets b-d: route add net.a.0 hostip 0 route add net.c.0 hostip 0 route add net.d.0 hostip 0 This is necessary for a host on subnet b. Greg ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090516320000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 07:34:11 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA09222; Thu, 6 Sep 90 07:28:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Sep 90 16:32:00 GMT From: primerd!ENI!S55!CUMMINGS@bloom-beacon.mit.edu Subject: SLIP on Sun 386i and 3/280's Message-Id: <130400011@S55.Prime.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have been trying to get CSLIP (the BETA test version) running on a Sun 386i under SUNOS 4.0 for some time now. I have downloaded slipware.tar, but it doesn't seem to have any patches for the 386 SUNOSes. I am at the point where I have been able to get a VISUAL-640 X-terminal to ping the sun successfully, but a telnet session connects, and then hangs. I tried a 386SX PC running NCSA telnet, and the message window claims both bad checksums and some fragmented packets, and the sun eventually times the connection out. I have then tried building CSLIP on a Sun 3/280 file server running SUNOS 4.1, and the makefile building the OS claims that both /sys/sun3/machine/param.h and slcompress.c have a #define BCOPY which conflict with each other. (Oddly enough the #define BCOPY in param.h is for a Sun 3-260, not 3/280, or is a 280 just a faster 260?) I would like to converse with anyone who has gotten CSLIP running on either a 3/280 or a 386i. Thanx. ============================================================================ Kevin J. Cummings Prime Computer Inc. 20 Briarwood Road 500 Old Connecticut Path Framingham, Mass. Framingham, Mass. InterNet: CUMMINGS@S55.Prime.COM CSNet: CUMMINGS%S55.Prime.COM@RELAY.CS.NET UUCP: {uunet, csnet-relay}!S55.Prime.COM!CUMMINGS Std. Disclaimer: "Mr. McKittrick, after careful consideration, I've come to the conclusion that your new defense system SUCKS..." ============================================================================ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [13647@mentor.cc.purdue.edu] <1990090517210200> From: dls@mentor.cc.purdue.edu (David L Stevens) Newsgroups: comp.protocols.tcp-ip Subject: Re: Hosts whose IP numbers end in 0... Message-ID: <13647@mentor.cc.purdue.edu> Date: 5 Sep 90 17:21:02 GMT References: <9008311641.AA02779@braden.isi.edu> <12619306165.20.PADLIPSKY@A.ISI.EDU> Organization: PUCC UNIX Group Lines: 29 Posted: Wed Sep 5 18:21:02 1990 I think Michael Padlipsky's analysis hit the hammer on the nose, is right on the nail, or whatever mixed metaphor you like... :-) My arguments assume "gateway not attached or administered by the same people who do the network on whose address the filtered address lives." In other words, as I said, take the DLS challenge: if you can't answer the question "Is 128.210.50.127 a host or a broadcast address?" you have no business filtering it out on the grounds that it's a broadcast. The most unfortunate part is that I think many naive gateway administrators will presume more than they should and will answer the question "sure, I can tell" when they really can't. So my opinion, beyond any RFC arguments, and which I don't expect or even want to become "law," is that filtering, except in very carefully considered cases, just shouldn't be done at all. You see, if it's done wrong, it affects people well outside those that can have it changed and, worse, the primary benefits only affect those behind the net, anyway. If some non-128.210 gateway is filtering broadcasts, what I say is "don't be nice to me-- if I don't want to see them, *I'll* filter them." The broadcast happens, after all, on my nets. Now, certainly, if there are generated replies from all of my hosts to the source of this broadcast, the remote guy and all the intervening gateways have a problem too. But should we accept loss of legitimate connectivity as a sacrifice for doing the wrong thing it what should be relatively infrequent, anomalous cases? Most protocols know already whether receiving on a broadcast address is legitimate or not, anyway, so I think the gain, as far filtering broadcasts in particular, is absolutely minimal for anyone outside the network of the filtered address. -- +-DLS (dls@mentor.cc.purdue.edu) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090517451700> Received: from SH.CS.NET by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 21:27:34 PDT To: tcp-ip@nic.ddn.mil Subject: forward response ( re:local socket assignment ) Date: Thu, 06 Sep 90 00:25:17 -0400 From: George Williams Can his message be forwarded ? This is a test response as well as an attempt to share info based on past work in this area. Got a "unable to deliver" on previous attempt to respond. Not critical but would like insure I am able to use this list to send as well as receive postings. ------- Forwarded Message To: Benny Tong cc: tcp-ip@nic.ddn.mil, gwilliam@SH.CS.NET Subject: Re: tcp source port number assignment in new tcp connection In-reply-to: Your message of 03 Sep 90 07:08:24 +0000. <15096@shlump.nac.dec.com> Date: Wed, 05 Sep 90 13:48:26 -0400 From: George Williams Hello, I don't know what TCP/IP interface you are using but unless you are writing your own TCP implementation source port assignment should be a 'local', i.e. OS or TCP interface running on you machine, issue. All interfaces I've seen on DEC machines , and others, have returned this identifier; usually with the option for you to specify one....and even that may not result in what the remote TCP sees as your source identifier. On the interface level it is just a logical assignment and does not necessarily map to a 'real' TCP port. Maybe QIO stuff is different but even that returned a logical channel number if i recall correctly. If security is the issue then that's another discussion. In any event: () If you have a choice in the matter let your interface to TCP assign this. Less book keeping and cleanup. (You don't really want to know when to use, re-use, free, allocate, and sync this information with lower layers, do you ? ) () If you are writing an interface and or your own TCP then take a look a what Excelan, Wollangong, DEC, and others have done already in this area.... () There were some discussion in this newsgroup ( whos right/wrong ) regarding two vendor's port assigments above 1000 which referenced an RFC, about a month ago. Impression I got was that the RFC came out the winner...no hard fast rule just agreed on and established convention in this area. Good luck, George Williams - ------- End of Forwarded Message ------- End of Forwarded Message ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009060814.AA16012@ucbvax.Berkeley.EDU] <1990090517482600> From: gwilliam@SH.CS.NET (George Williams) Newsgroups: comp.protocols.tcp-ip Subject: Re: tcp source port number assignment in new tcp connection Message-ID: <9009060814.AA16012@ucbvax.Berkeley.EDU> Date: 5 Sep 90 17:48:26 GMT References: <15096@shlump.nac.dec.com> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 32 Posted: Wed Sep 5 18:48:26 1990 Hello, I don't know what TCP/IP interface you are using but unless you are writing your own TCP implementation source port assignment should be a 'local', i.e. OS or TCP interface running on you machine, issue. All interfaces I've seen on DEC machines , and others, have returned this identifier; usually with the option for you to specify one....and even that may not result in what the remote TCP sees as your source identifier. On the interface level it is just a logical assignment and does not necessarily map to a 'real' TCP port. Maybe QIO stuff is different but even that returned a logical channel number if i recall correctly. If security is the issue then that's another discussion. In any event: () If you have a choice in the matter let your interface to TCP assign this. Less book keeping and cleanup. () If you are writing an interface and or your own TCP then take a look a what Excelan, Wollangong, DEC, and others have done already in this area.... () There were some discussion in this newsgroup ( whos right/wrong ) regarding two vendor's port assigments above 1000 which referenced an RFC, about a month ago. Impression I got was that the RFC came out the winner...no hard fast rule just agreed on and established convention in this area. Good luck, George Williams ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090521141900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 04:28:44 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21973; Thu, 6 Sep 90 04:20:50 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Sep 90 21:14:19 GMT From: aramis.rutgers.edu!lfischer@rutgers.edu (Lfischer) Organization: Rutgers Univ., New Brunswick, N.J. Subject: Need information on protocols Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi. I'd appreciate any references to protocols that allows hosts to broadcast information about themselves, particularly things like applications offered and the amount of load on the host (for load sharing). I'd be interested in any pointers that you could provide to currently existing protocols. Thanks in advance. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090522234700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 07:14:50 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06759; Thu, 6 Sep 90 06:59:40 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Sep 90 22:23:47 GMT From: sun-barr!olivea!tymix!cirrusl!sungraph!dhesi@decwrl.dec.com (Rahul Dhesi) Subject: Re: sockets vs. streams Message-Id: <2364@cirrusl.UUCP> References: <6964@milton.u.washington.edu>, <2350@cirrusl.UUCP>, <1990Sep5.020521.803@mlb.semi.harris.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Don Lewis writes: Now, if the printer is on a terminal server somewhere... cat somefile >/dev/tcp/x.x.x.x-y.y Specifically, you could use this for the lp= parameter in /etc/printcap... This would be nice. A possible solution is to write a program "netsend": cat somefile | netsend tcp:x.x.x.x-y.y Since printcap allows sending to a filter rather than a specific device, the solution is general enough. All we need now is for somebody to write it and send it to comp.sources.misc. -- Rahul Dhesi UUCP: oliveb!cirrusl!dhesi ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090523381700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 05:13:35 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25606; Thu, 6 Sep 90 05:01:55 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Sep 90 23:38:17 GMT From: pasteur!etch-eshop.Berkeley.EDU!sparks@ucbvax.Berkeley.EDU (Jay Sparks) Organization: University of California, Berkeley Subject: tcp-ip to Decnet Message-Id: <27508@pasteur.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am wondering if shareware is available for tcpip to Decnet. The idea being to connect a Sun with an ethernet card to a VMS machine. Thank you, Jay Sparks sparks@etch-eshop.berkeley.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009052232.AA17862@ucbvax.Berkeley.EDU] <1990090601170000> From: CHAIBP@NUSDISCS.BITNET Newsgroups: comp.protocols.tcp-ip Subject: interfacing with Ethernet cards Message-ID: <9009052232.AA17862@ucbvax.Berkeley.EDU> Date: 6 Sep 90 01:17:00 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 32 Posted: Thu Sep 6 02:17:00 1990 I believe some people here may have experience developing device drivers for the following Ethernet adapter cards: 1. Acer 5220 2. AST-Ethernet Adapter 3. DTK Ethernet LAN card 4. Earthnet-Ie 5. G/Ethernet AT 6. IMC Networks PCnic 7. Localnet D-Link 8. Novell NNE1000 9. 3C501 EtherLink card 10. 3C503 EtherLink II 11. 3C505 EtherLink Plus 12. Tiara LanCard E 13. Univation LifeLink If you do, please send me you mailing address as I would like to consult you on issues of interfacing with these cards. BP > CHAI BOON PING (CHAIBP@NUSDISCS.BITNET) > National University of Singapore > Department of Information Systems and Computer Science ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090601220500> Received: from ftp.com by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 06:42:58 PDT Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA28405; Thu, 6 Sep 90 09:42:05 -0500 Date: Thu, 6 Sep 90 09:42:05 -0500 Message-Id: <9009061442.AA28405@ftp.com> To: bacchus.pa.dec.com!decvax.dec.com!shlump.nac.dec.com!uluru.enet.dec.com!tong@decwrl.dec.com (Benny Tong) Subject: Re: tcp source port number assignment in new tcp connection From: jbvb@ftp.com (James B. Van Bokkelen) Reply-To: jbvb@ftp.com Cc: tcp-ip@nic.ddn.mil Sender: jbvb@ftp.com Repository: babyoil.ftp.com Originating-Client: plug.ftp.com If you start at 1024, you won't fall afoul of the machines that believe that reserved ports end there, instead of at 1000. Some systems expect all connections for particular protocols to use source ports between 600 and 1024, but other protocols are required to originate from ports numbered above 1024. If you're actively opening an FTP data connection from a server, you'll find that there are machines that insist the originating port be 20. Otherwise, fine. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009061848.AA25608@ucbvax.Berkeley.EDU] <1990090604001900> From: satz@CISCO.COM (Greg Satz) Newsgroups: comp.protocols.tcp-ip Subject: Re: routing with virtual subnets Message-ID: <9009061848.AA25608@ucbvax.Berkeley.EDU> Date: 6 Sep 90 04:00:19 GMT References: <26E487A4.28053@orion.oac.uci.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Posted: Thu Sep 6 05:00:19 1990 All of the hosts on subnets a-d need to know about the overlayed scheme. That is hosts on subnet b need to know that subnets a, c, and d also exist on the same ethernet cable. The command that you used on your sun router to inform it of the overlay is also necessary for those hosts on subnets b-d: route add net.a.0 hostip 0 route add net.c.0 hostip 0 route add net.d.0 hostip 0 This is necessary for a host on subnet b. Greg ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009061812.AA23415@ucbvax.Berkeley.EDU] <1990090604251700> From: gwilliam@SH.CS.NET (George Williams) Newsgroups: comp.protocols.tcp-ip Subject: forward response ( re:local socket assignment ) Message-ID: <9009061812.AA23415@ucbvax.Berkeley.EDU> Date: 6 Sep 90 04:25:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 62 Posted: Thu Sep 6 05:25:17 1990 Can his message be forwarded ? This is a test response as well as an attempt to share info based on past work in this area. Got a "unable to deliver" on previous attempt to respond. Not critical but would like insure I am able to use this list to send as well as receive postings. ------- Forwarded Message To: Benny Tong cc: tcp-ip@nic.ddn.mil, gwilliam@SH.CS.NET Subject: Re: tcp source port number assignment in new tcp connection In-reply-to: Your message of 03 Sep 90 07:08:24 +0000. <15096@shlump.nac.dec.com> Date: Wed, 05 Sep 90 13:48:26 -0400 From: George Williams Hello, I don't know what TCP/IP interface you are using but unless you are writing your own TCP implementation source port assignment should be a 'local', i.e. OS or TCP interface running on you machine, issue. All interfaces I've seen on DEC machines , and others, have returned this identifier; usually with the option for you to specify one....and even that may not result in what the remote TCP sees as your source identifier. On the interface level it is just a logical assignment and does not necessarily map to a 'real' TCP port. Maybe QIO stuff is different but even that returned a logical channel number if i recall correctly. If security is the issue then that's another discussion. In any event: () If you have a choice in the matter let your interface to TCP assign this. Less book keeping and cleanup. (You don't really want to know when to use, re-use, free, allocate, and sync this information with lower layers, do you ? ) () If you are writing an interface and or your own TCP then take a look a what Excelan, Wollangong, DEC, and others have done already in this area.... () There were some discussion in this newsgroup ( whos right/wrong ) regarding two vendor's port assigments above 1000 which referenced an RFC, about a month ago. Impression I got was that the RFC came out the winner...no hard fast rule just agreed on and established convention in this area. Good luck, George Williams - ------- End of Forwarded Message ------- End of Forwarded Message ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090605165100> Received: from nrtc.nrtc.northrop.com by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 17:15:33 PDT Received: from nma.com by nrtc.nrtc.northrop.com id aa19802; 6 Sep 90 17:14 PDT Received: from localhost by nma.com id aa05726; 6 Sep 90 16:57 PDT To: barns@gateway.mitre.org cc: tcp-ip@nic.ddn.mil Subject: Re: "The Open Book" by Rose - your opinions sought In-reply-to: Your message of Wed, 05 Sep 90 10:14:12 -0400. Reply-to: Stef@nrtc.northrop.com From: Einar Stefferud Date: Thu, 06 Sep 90 16:56:51 -0700 Message-ID: <5724.652665411@nma.com> Sender: stef@nma.com > To my kmnowledge, no book comparable to Comer exists for OSI and > I doubt that one will be created any time soon. Open Book is about the > best available and you might as well buy it (everyone else does), Damn faint praise, it seems to me. Better to note that the OPEN BOOK is the best there is for OSI today, and perhaps for years to come, though we could hope that more good authors would come to the fore with good books on OSI. > but it isn't as concrete as Comer because in the OSI world, these > things are still being figured out. Don't forget that the Comer book does not cover some very imporant TCP/IP topics, like X and NFS. It is also weak on applications like MAIL. In short, the Comer book only covers a portion of the total TCP/IP suite. No one covers it all (either). > I think that is a limitation we just have to accept for a while yet. > And in part, it will probably exist forever, because OSI is rather > broader than TCP/IP and thus won't be able to be covered to the same > depth in anything like the same number of pages, once we have figured > out the right details. This is wild speculation, but I'd estimate a > treatment of ALL of the OSI protocols to comparable depth would run > about 5000 pages. /Bill Barns Well, I expect that you are right about how it is not possible to write a reasonable sized book to cover all of OSI, but one aught to be able to write good books about portions of OSI. I think that is what Marshall Rose did in the OPEN BOOK. Now it is someone else's turn to do it for another portion. Best...\Stef ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090606370000> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 02:25:01 PDT Received: from NUSDISCS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 2203; Wed, 05 Sep 90 05:23:30 EDT Date: Wed, 5 Sep 90 17:17 H From: Subject: interfacing with Ethernet cards To: tcp-ip@nic.ddn.mil X-Original-To: tcp-ip@nic.ddn.mil, I believe some people here may have experience developing device drivers for the following Ethernet adapter cards: 1. Acer 5220 2. AST-Ethernet Adapter 3. DTK Ethernet LAN card 4. Earthnet-Ie 5. G/Ethernet AT 6. IMC Networks PCnic 7. Localnet D-Link 8. Novell NNE1000 9. 3C501 EtherLink card 10. 3C503 EtherLink II 11. 3C505 EtherLink Plus 12. Tiara LanCard E 13. Univation LifeLink If you do, please send me you mailing address as I would like to consult you on issues of interfacing with these cards. BP > CHAI BOON PING (CHAIBP@NUSDISCS.BITNET) > National University of Singapore > Department of Information Systems and Computer Science ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090609490700> Received: from WLV.IMSD.CONTEL.COM by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 21:29:34 PDT Received: by WLV.IMSD.CONTEL.COM (5.64/1.25) id AA00221; Thu, 6 Sep 90 21:29:07 -0700 Date: Thu, 6 Sep 90 21:29:07 -0700 From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) Message-Id: <9009070429.AA00221@WLV.IMSD.CONTEL.COM> To: mcsun!ukc!edcastle!tardis.cs.ed.ac.uk!jonathan@uunet.uu.net, tcp-ip@nic.ddn.mil Subject: Re: Internet routing Europe - USA -} Europe... And here thought that if one was connected to a tardis one would have the best of all possible worlds. Do you mean that PBS (USA) and Lionheart (BBC) or is it ITC have been telling us lies all these years? I mean with a tardis who needs TCP/IP, GOSIP, or whatever JNT claims their service is? Which timeframe are we talking about? Merton ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090610240400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 12:44:29 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29044; Thu, 6 Sep 90 12:44:17 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 10:24:04 GMT From: mcsun!ukc!strath-cs!baird!jim@uunet.uu.net (Jim Reid) Organization: Computer Science Dept., Strathclyde Univ., Glasgow, Scotland. Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: References: <1990Aug30.091435.1982@ircam.ircam.fr Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1216@vision.UUCP> chris@vision.UUCP (Chris Davies) writes: Sorry, I should have stated my point more clearly. I was aware of this. But I think I'm correct in stating that a direct connection to JANET (as such) by a commerical site is not permissible (and so all traffic must go through a gateway - thus mail only, in effect). Yes and no. A commercial site cannot get a direct connection, meaning an X.25 line straight from a JANET switch. If the site already has PSS, they can use Coloured Book protocols to make connections to JANET sites via one of many JANET/PSS gateways*. These connections may be TS29 or X.29 for terminal traffic or NIFTP for mail and news transfer or JTMP for remote job entry. [* Calling the box with a JANET and a PSS connection a gateway is a bit misleading. It doesn't really perform protocol conversion (save for minimal TS29/X.29 translation), so strictly speaking it's not a gateway. It's more of a router, simply routing X.25 packets between the two networks. However, Internet people call routers "gateways", so if JANET was part of the Internet, the name would be correct!] Jim ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090610563300> Received: from ames.arc.nasa.gov by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 13:36:56 PDT Received: by ames.arc.nasa.gov (5.64/1.2); Thu, 6 Sep 90 13:36:51 -0700 Received: from libai.UUCP by ultra.com (4.0/Ultra-1.2-02-12-90) id AA17268; Thu, 6 Sep 90 13:32:30 PDT Received: by libai. (4.0/SMI-4.0) id AA08260; Thu, 6 Sep 90 15:56:33 EST Date: Thu, 6 Sep 90 15:56:33 EST From: libai!tinker@ames.arc.nasa.gov (Don Tinker) Message-Id: <9009062056.AA08260@libai.> To: sun-barr!olivea!tymix!cirrusl!sungraph!dhesi@decwrl.dec.com Cc: tcp-ip@nic.ddn.mil Subject: Re: sockets vs. streams > >All we need now is for somebody to write it and send it to >comp.sources.misc. >-- >Rahul Dhesi >UUCP: oliveb!cirrusl!dhesi > > I found by accident a program tcpf on uunet which I use for just this purpose. Don Tinker tinker@ultra.com Senior Field Support Engineer {core}!ames!ultra!tinker UltraNetwork Technologies Inc. (703) 821-8393 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090611191100> Received: from po10.andrew.cmu.edu by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 15:00:24 PDT Received: by po10.andrew.cmu.edu (5.54/3.15) id for tcp-ip@nic.ddn.mil; Thu, 6 Sep 90 18:00:12 EDT Received: via switchmail; Thu, 6 Sep 90 18:00:07 -0400 (EDT) Received: from excalibur.andrew.cmu.edu via qmail ID ; Thu, 6 Sep 90 17:59:19 -0400 (EDT) Received: from excalibur.andrew.cmu.edu via qmail ID ; Thu, 6 Sep 90 17:59:12 -0400 (EDT) Received: from Messages.7.8.N.CUILIB.3.45.SNAP.NOT.LINKED.excalibur.andrew.cmu.edu.pmax.3 via MS.5.6.excalibur.andrew.cmu.edu.pmax_3; Thu, 6 Sep 90 17:59:11 -0400 (EDT) Message-Id: Date: Thu, 6 Sep 90 17:59:11 -0400 (EDT) From: Walter Lloyd Wimer III To: tcp-ip@nic.ddn.mil, ietf@venera.isi.edu Subject: ToasterNet (was: Computers In Disguise Aim For Wide Acceptance) References: I thought people might find this interesting. . . . ToasterNet may be closer than we think. Walt Wimer Networking and Communications Carnegie Mellon University ---------- Forwarded message begins here ---------- Return-path: Filename: 26e64ee3 Corporation: CCI T ZE T.VDO Industry: CPR CMT Government: Flags: P N J SequenceNum: 1809060536 Message-ID: From: DowJones@andrew To: bb+dow-jones@andrew Subject: Computers In Disguise Aim For Wide Acceptance Date: Thu, 6 Sep 90 06:45:32 -0400 (EDT) Lawrence Weiss, one of Citicorp's top technology executives, works at a desk surrounded by 14 boxes of "Underoos," kids' underwear cleverly packaged to look like superhero costumes. Weiss created Underoos in an earlier job and keeps them nearby as a reminder of the marketing principle behind them: The best new products are variations on comfortable old products. Today he is applying that lesson to a lumpy beige gadget that resembles an ordinary telephone. Citicorp is gambling it will catch on as a bank-at-home device better than an earlier system that let customers dial up their accounts via personal computer. This same philosophy is behind a cornucopia of products sneaking computing power into the home in the guise of more familiar devices. Other projects in the works use embedded computer technology to let people trade stocks on a Nintendo Co. game machine, receive written messages on an American Telephone & Telegraph Co. telephone, search databases of articles and listings on a television set and program household appliances with a television's remote control. Products such as these are crashing onto the turf of the personal-computer industry, which has long promised to make the PC as ubiquitous as a telephone or a TV. Right now, the PC industry is wooing the home market more aggressivel- y than ever, led by lavish new products from International Business Machines Corp. and Tandy Corp. These and other companies paint pictures of every household using a computer to send messages, read news, play games, bank and shop. PC makers scoff at the idea that simpler household gadgets could ever do these jobs. But so far home computers have shaped up as a narrow market. Only about a quarter of all American households have PCs. Most use their computers for limited, utilitarian tasks, such as writing or doing leftover office work. Now, instead of home computers becoming household items, household items are turning into home computers. "People said there were going to be two or three computers in every home like there are two or three telephones," says A.C. Markkula, an Apple Computer Inc. founder and present vice chairman. "They're right, but the physical implementation isn't what they had in mind. Instead of having three things that look like PCs, people will have many pieces of equipment that are in essence PC technology but are buried in refrigerator doors, and lighting systems, and VCRs and TVs and CD players and telephones." Markkula has founded a new Silicon Valley company called Echelon Corp., which is working on ways to link all the hidden microchips in a home or commercial building into one communications and control network. Echelon won't say more about its products until it unveils them later this year. Right now the most promising buried PCs are showing up inside telephones. In a Citicorp pilot program, about 400 customers already are using the home-banking phone, which has a little screen, a hidden keyboard and microchips that let it handle all manner of banking tasks. The bank says it wants to ship hundreds of thousands more of the phones over the next few years, though it won't dislose a specific timetable. The unit lets a user transfer funds, buy certificates of deposit and send anyone a check. Eventually, the bank plans to let customers check stock quotes and trade securities. AT&T is working on a rival product dubbed SmartPhone, which it is promoting as the standard telephone of the future. SmartPhone, slated for a 1992 introduction, has a small screen and built-in software for adding customized programs. For instance, AT&T says, a customer could set the phone so that pressing one button would place an order for his usual pizza, or his usual seats at a baseball game. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090611225600> Received: from mcsun.EU.net by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 04:14:14 PDT Received: by mcsun.EU.net via EUnet; Thu, 6 Sep 90 13:12:53 +0200 (MET) Received: from castle.ed.ac.uk by kestrel.Ukc.AC.UK via Janet (UKC CAMEL FTP) id aa26129; 6 Sep 90 12:05 BST Received: from spider.co.uk by castle.ed.ac.uk id aa22846; 6 Sep 90 10:22 WET DST Received: by widow.spider.co.uk; Thu, 6 Sep 90 10:22:58 +0100 From: Brian Tompsett Date: Thu, 6 Sep 90 10:22:56 BST Message-Id: <11457.9009060922@orbweb.spider.co.uk> Received: by orbweb.spider.co.uk; Thu, 6 Sep 90 10:22:56 BST To: tcp-ip@nic.ddn.mil Subject: Re: Internet routing Europe - USA -} Europe... In-Reply-To: <1790@mcsun.eu.net> References: <1990Aug30.091435.1982@ircam.ircam.fr, Organization: Spider Systems Ltd., Edinburgh, UK. Cc: In article lmjm@doc.ic.ac.uk (Lee McLoughlin) writes: >Many comerical companies are on the US Internet and release >patches, demo release and the like by making them available for >anonymous ftp. Don't companies over here want to do the same thing? In article <1790@mcsun.eu.net> dfk@cwi.nl (Daniel Karrenberg) writes: >So far not quite enough >paying customers have surfaced to set up a separate organisation >offering IP services in the UK. I made a specific proposal to set up an IP network in the UK based on leased lines, dial-up slip and IP in X25 encapsulation over PSS. I made the proposal in UKnet in uk.general about a year ago. We were aware that ukc, as the gateway to eunet would need to be involved. We kept ukc and nsfnet-relay informed. We offered to donate router kit to ukc to ensure that no additional financial burden was felt by them in carrying IP traffic. No one was interested. I got a response from about 3 parties, all companies. One of them has enough resources to make their own arrangement. No academics even bothered too respond. I seemed many UK academics didn't even know what I was talking about. The only reason they now do know now is they have been playing with anonymous ftp from nsfnet-relay for the last year and are addicted to getting gif pictures. (see the file transfer Q at random intervals to be convinced). Most of the other companies in the UK seemed to be happy with their dial up uucp links. That was as sophisticed a WAN technology as they could deal with. :-). The Department of Trade and Industry seems happy with that state of affairs too. With help from the JNT they are setting up a program to link some UK industry to JANET using coloured book, and charging them an arm and a leg for it (see JFIT news Sept 1990, p4). This is the UK government proposal to help UK companies compete in the world arena - allow them to talk to UK universities using private software over private lines, instead of the industry standard software and public data lines as they do at present! I see it this way. Current UK company sites are so dependent on the current UKnet uucp setup that they are too scared to put their heads over the parapet in case they lose the little connectivity they have. Ever tried criticising the UK setup? They set Jim Reid on you. ( :-). A joke A joke.) The academic sites are so dependent on their JNT and computer board funding for Comms kit that they do what the're told. I'll say it again. We, Spider, as suppliers of TCP/IP Software, and TCP/IP kit such as routers and bridges, are ready willing and able to get involved in IP networking in the UK. Connectivity to the greater Internet would be a boon and asset. We would to do it yesterday. We think it would benefit the whole of the UK reasearch community and the Computer industry. Lets do it. Our IP network numbers are registered and so is our network 14 number. You can find our DTE in the book (RFC). Lets talk IP. Lets throw those uucp modems in the trash. Brian. -- Brian Tompsett. Spider System Ltd. Tel: 031 554 9424 E-mail:briant@uk.co.spider Spider Park, Stanwell Street, Edinburgh, EH6 5NG. Fax: 031 554 0649 (Secretary, BCS Edinburgh Branch, 53 Bonaly Crescent, Edinburgh. 031 441 2210) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009061934.AA28393@ucbvax.Berkeley.EDU] <1990090614172200> From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet routing Europe - USA -} Europe... Message-ID: <9009061934.AA28393@ucbvax.Berkeley.EDU> Date: 6 Sep 90 14:17:22 GMT References: <11457.9009060922@orbweb.spider.co.uk> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 28 Posted: Thu Sep 6 15:17:22 1990 > I'll say it again. We, Spider, as suppliers of TCP/IP Software, and TCP/IP >kit such as routers and bridges, are ready willing and able to get involved >in IP networking in the UK. Connectivity to the greater Internet would be >a boon and asset. We would to do it yesterday. We think it would benefit Brian, I'd be quite happy to do it for free, along with cambridge, edinburgh and a few other quite large universities...however, there are certain difficulties in terms of migrating a network the size of the UK academic one (many users of which, contrary to your statement do know what they'd get from the Internet protocol suite; but what about what others lose, like do you,Spider, supply VM/MVS TCP/IP or VMS NFS or VME X Windows, or COS SNMP? - i think not...) Altern[ea]tively, I think someone should do the cost estimates to see if they could bid to replace the JNT on the same budget, and run a UK Internet - or write a pursuasive case that more money would provide more service (I'd do it but I dont have spare profit to cycle back into R&D:-) if its so useful, btw, why dont spider lease a line and sell off IP services to netcomm/case/york:-) by the way, we, UCL are suppliers of a few modest OSI applications, for free:-) jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090614193600> Received: from csli.Stanford.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 21:17:46 PDT Received: by csli.Stanford.EDU (4.1/inc-1.0) id AA20872; Thu, 6 Sep 90 21:19:39 PDT Date: Thu, 6 Sep 1990 21:19:36 PDT From: Ole J. Jacobsen To: tcp-ip@nic.ddn.mil Phone: +1 415 941-3399 (Interop) or 1-800-INTEROP Or: +1 415 550-9427 (Home) or +1 415 990-9427 (Cellular) Fax: +1 415 949-1779 (Interop) +1 415 826-2008 (Home) Subject: The Open Book Message-Id: The Open Book is generally regarded as one of the better works on OSI, in particular since it is from an implementor's (and Internet) perspective. The book tends to evoke various strong reactions from either "side of the fence." See in particular "Book Reviews" in ConneXions, Volume 3, No. 11, November 1989, and "Alternative Book Review" in ConneXions, Volume 4, No. 9, September 1990, for "opposing views." Ole J Jacobsen, Editor & Publisher ConneXions--The Interoperability Report Interop, Inc., 480 San Antonio Road, Suite 100 Mountain View, CA 94040, USA Phone: (415) 941-3399 FAX: (415) 949-1779 Email: ole@csli.stanford.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090614262300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 12:44:14 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA28537; Thu, 6 Sep 90 12:36:47 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 14:26:23 GMT From: mcsun!ukc!slxsys!ibmpcug!dylan@uunet.uu.net (Matthew Farwell) Organization: The IBM PC User Group, UK. Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <1990Sep6.142623.4559@ibmpcug.co.uk> References: , <1213@vision.UUCP>, <1940@jura.tcom.stc.co.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1940@jura.tcom.stc.co.uk> chris@htc2.UUCP (Chris Milton) writes: >a. can you see academic sites wanting to shell out money they aint got > to modify up to internet ? Sure they haven't got the money, but the JNT have a policy of sticking to coloured books. >b. can you see companies which aren't even on janet because it provides > security problems wanting to go onto internet? It depends. Companies who are terminally afraid of security problems will never connect to a network like janet. On the other hand, if connecting up to a network directly, (esp. the internet for international companies) reduces their costs substantially in terms of mail, news etc., then they might be persuaded to do so. I know this particular company would love to be connected directly to janet, and I suspect I know of a few others too. Dylan. -- Matthew J Farwell | Email: dylan@ibmpcug.co.uk The IBM PC User Group, PO Box 360,| dylan%ibmpcug.CO.UK@ukc Harrow HA1 4LQ England | ...!uunet!ukc!ibmpcug.co.uk!dylan Phone: +44 81-863-1191 | Winner 1989 Frank Zappa lookalike contest ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090614322000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 15:59:50 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA11757; Thu, 6 Sep 90 15:59:10 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 14:32:20 GMT From: mcsun!ukc!icdoc!syma!grahamt@uunet.uu.net (Graham Thomas) Organization: SPRU, Univ. of Sussex, Brighton, UK Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <3407@syma.sussex.ac.uk> References: <1216@vision.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil From article <1216@vision.UUCP>, by chris@vision.UUCP (Chris Davies): > > But if the commercial site(s) were to pay for their use of the government > funded networks, then I don't see why this shouldn't be acceptable. With the > current situation, I would agree that commercial sites should not exploit > JANET for commercial gain. > > Chris Now might be a good time to start lobbying, because the way JANET is organised is probably going to change. JNT head Bob Cooper wants to set up something like a 'networking association' which would have both academic and commercial membership. There's a steering group just been set up to work out the ground rules. Details, with a list of steering group members, are available in the latest issue of Network News. If you want a copy, mail JNT-Secretary@uk.ac.jnt (or @jnt.ac.uk, depending on where you live.) I have a feeling the TCP/IP question might get raised at the next round of JANET user group meetings. The next national user group meeting is in the middle of October. Most regional meetings take place a week or two earlier. It may be worthwhile finding out who your user rep is and getting her/him to raise the topic at the next meeting. Graham -- Graham Thomas, SPRU, Mantell Building, U of Sussex, Brighton, BN1 9RF, UK JANET: grahamt@uk.ac.sussex.syma BITNET: grahamt%syma.sussex.ac.uk@UKACRL INTERNET: grahamt%syma.sussex.ac.uk@nsfnet-relay.ac.uk UUCP: grahamt%syma.sussex@ukc.uucp PHONE: +44 273 686758 FAX: [..] 685865 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090615312700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 13:46:38 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01216; Fri, 7 Sep 90 13:39:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 15:31:27 GMT From: amdcad!mozart.amd.com!neihart@ucbvax.Berkeley.EDU (Carl Neihart) Organization: Advanced Micro Devices, Inc. Subject: Re: tcp-ip to Decnet Message-Id: <1990Sep6.153127.4840@mozart.amd.com> References: <27508@pasteur.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <27508@pasteur.Berkeley.EDU> sparks@etch-eshop.Berkeley.EDU (Jay Sparks) writes: > > >I am wondering if shareware is available for tcpip to >Decnet. The idea being to connect a Sun with an ethernet card >to a VMS machine. >Thank you, >Jay Sparks >sparks@etch-eshop.berkeley.edu uggh! Don't convert between TCP/IP and DECnet, this would be a mess! Just load Wollongong TCP/IP on your VMS systems, and make it communicate with TCP/IP to your Sun... (alternatively, you could load Sun's DECnet/DNI product on your Sun and make it communicate via DECnet to the VMS system, but I've tried both approaches and prefer making TCP/IP the common denominator). The Wollongong TCP/IP product for VMS is a full & clean implementation of TCP/IP, I can't say the same for Sun's DECnet/DNI product. regards, __ _ _ __ / ) // ' ) ) / _/_ / __. __ // / / _ o /_ __. __ / (__/ (_/|_/ (_ Received: from mcsun.EU.net by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 07:49:37 PDT Received: by mcsun.EU.net via EUnet; Thu, 6 Sep 90 16:49:37 +0200 (MET) Received: from castle.ed.ac.uk by kestrel.Ukc.AC.UK via Janet (UKC CAMEL FTP) id aa04930; 6 Sep 90 14:57 BST Received: from spider.co.uk by castle.ed.ac.uk id aa09456; 6 Sep 90 14:56 WET DST Received: by widow.spider.co.uk; Thu, 6 Sep 90 14:57:03 +0100 From: Doreen McKenzie Date: Thu, 6 Sep 90 14:57:01 BST Message-Id: <19718.9009061357@orbweb.spider.co.uk> Received: by orbweb.spider.co.uk; Thu, 6 Sep 90 14:57:01 BST To: tcp-ip@nic.ddn.mil Re: TCP/IP Ethernet Protocol Analyzer (Chris Jankowski) I would like to clarify the statement made about Spider's monitoring products in the recent communications about the above. Spider Systems has two network monitoring/analyzing products, the SpiderMonitor 220, and the SpiderAnalyzer 320. The SpiderMonitor 220 is a multi-tasking network monitor which provides extensive monitoring facilities, and some protocol analysis - TCP/IP, DECnet, Novell Netware, AppleTalk and XNS decodes to the ISO Transport layer, and ISO to Network layer. The SpiderAnalyzer 320 provides the same extensive monitoring facilities as the SpiderMonitor 220, plus powerful packet capture and decoding capabilities; full decode to Application layer of TCP/IP, DECnet, Novell Netware, and AppleTalk protocols, and to Transport layer of ISO. The demonstration diskette for the SpiderMonitor products shows only the SpiderMonitor 220's decoding capabilities. I think that this may have led to the mistaken assumption that Spider's decodes are incomplete and of low quality. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090616572200> Received: from bells.cs.ucl.ac.uk by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 07:19:32 PDT Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id ; Thu, 6 Sep 1990 15:17:25 +0100 To: Brian Tompsett cc: tcp-ip@nic.ddn.mil Subject: Re: Internet routing Europe - USA -} Europe... In-reply-to: Your message of Thu, 06 Sep 90 10:22:56 +0100. <11457.9009060922@orbweb.spider.co.uk> Date: Thu, 06 Sep 90 15:17:22 +0100 From: Jon Crowcroft > I'll say it again. We, Spider, as suppliers of TCP/IP Software, and TCP/IP >kit such as routers and bridges, are ready willing and able to get involved >in IP networking in the UK. Connectivity to the greater Internet would be >a boon and asset. We would to do it yesterday. We think it would benefit Brian, I'd be quite happy to do it for free, along with cambridge, edinburgh and a few other quite large universities...however, there are certain difficulties in terms of migrating a network the size of the UK academic one (many users of which, contrary to your statement do know what they'd get from the Internet protocol suite; but what about what others lose, like do you,Spider, supply VM/MVS TCP/IP or VMS NFS or VME X Windows, or COS SNMP? - i think not...) Altern[ea]tively, I think someone should do the cost estimates to see if they could bid to replace the JNT on the same budget, and run a UK Internet - or write a pursuasive case that more money would provide more service (I'd do it but I dont have spare profit to cycle back into R&D:-) if its so useful, btw, why dont spider lease a line and sell off IP services to netcomm/case/york:-) by the way, we, UCL are suppliers of a few modest OSI applications, for free:-) jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090617033900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 12:00:51 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25629; Thu, 6 Sep 90 11:48:19 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 17:03:39 GMT From: fernwood!hercules!dirt.cisco.com!kph@uunet.uu.net (Kevin Paul Herbert) Organization: cisco Systems Subject: Re: tcp-ip to Decnet Message-Id: <20781@hercules.csl.sri.com> References: <27508@pasteur.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil The easiest thing to do is to run TCP/IP on your VMS system; there are a number of packages available. I use the version from CMU; it is very complete and works quite well (at this moment, I have some windows on my NCD X terminal which use CMU TCP/IP as the X transport). I am told that it costs $150. The commercial packages cost more, and would give you support, and a different feature set. You'd probably get better answers on comp.os.vms. Kevin |-----------------------------------------------------------------------------| | Kevin Paul Herbert | Use of psychedelics and marijuana leads | | Terminal Server Software Hacker | to greater spiritual understanding and | | cisco Systems, Inc. | the ability to see through propaganda. | | Menlo Park, CA | This is why it is illegal. Any questions? | |-----------------------------------------------------------------------------| ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090617580100> Received: from hawk.nstn.ns.ca by NIC.DDN.MIL with TCP; Sat, 8 Sep 90 09:06:16 PDT Date: Thu, 06 Sep 90 21:58:01 AST Message-Id: <880@hawk.nstn.ns.ca> From: martinea@hawk.nstn.ns.ca (Michael Martineau) Reply-To: martinea@hawk.nstn.ns.ca To: tcp-ip@nic.ddn.mil, pcip@udel.edu Subject: POP client and servers I am looking for the following public domain software: 1. A POP server (version 2) which runs on SYSV UNIX. 2. A POP client (version 3) for MS-DOS. Any information on where I might find such software would be greatly appreciated. Thanks, Michael P. Martineau NSTN Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [13713@ulysses.att.com] <1990090618081200> From: smb@ulysses.att.com (Steven Bellovin) Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet routing Europe - USA -} Europe... Keywords: JANET, protocols Message-ID: <13713@ulysses.att.com> Date: 6 Sep 90 18:08:12 GMT References: <1990Aug30.091435.1982@ircam.ircam.fr <1990Sep5.092510.22637@cs.city.ac.uk> Sender: netnews@ulysses.att.com Lines: 14 Posted: Thu Sep 6 19:08:12 1990 In article <1990Sep5.092510.22637@cs.city.ac.uk>, sb380@cs.city.ac.uk (Andy Holt) writes: > Not only is the present Janet policy (coloured books instead of > TCP/IP) isolating us from the rest of the world, but it looks > like the ISO transition will do the same again: > The JNT in its infinite wisdom (???) has mandated that the ISO > profile used in the UK use TC0 (connection oriented transport > service) while NBS in the USA is encouraging the use of TC4 > (connectionless transport service). Without commenting on the wisdom (or the lack thereof) of JANET, the real problem here is OSI. They've designed a protocol stack with mutually incompatible options, thus preventing communication between parties who've made different decisions. What's the point of a standard that's incompatible with itself? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090619043500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 15:59:29 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA11101; Thu, 6 Sep 90 15:49:34 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 19:04:35 GMT From: mcsun!ukc!edcastle!tardis.cs.ed.ac.uk!anarchy@uunet.uu.net (Alan Cox) Organization: UNIX Anarchy, Edinburgh University Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <4847@tardis.cs.ed.ac.uk> References: <1990Aug30.091435.1982@ircam.ircam.fr, <6190@vanuata.cs.glasgow.ac.uk>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Firstly remember that when Janet was first setup properly they were dealing with a wacky array of bizzare processors, and also that then tcp/ip was abit fof an experiment. Unfortunately they haven't woken up since. Also they have a reasonable argument at the moment about relative efficiency of coloured book and tcp/ip. As to running tcp/ip over janet, any reason you couldn't run slip over a coloured book terminal session ? Alan Cox ================================================================================ This space intentionall left blank except for the words 'this space intentionally left blank except for the words ' this space.... ==================================================== ^ | Yep even janet mail addresses are backwards (sigh) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090619293100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 12:44:39 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA28894; Thu, 6 Sep 90 12:41:32 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 19:29:31 GMT From: harvisr!sob@husc6.harvard.edu (Scott Bradner) Organization: Harvard University, Cambridge MA Subject: device testing meeting Message-Id: <4095@husc6.harvard.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Well, you stick your head up about testing routers & you start to get all sorts of things. I've now been asked to be part of a "town meeting" on network device testing at NETWORLD. I'm sending this forwarded message in case there is anyone out there that might want to come. (I don't think that this is a commerical announcement, I hope others agree.) Scott From sschultz@wellfleet.com Thu Sep 6 15:08:47 1990 Received: by talcott.harvard.edu; Thu, 6 Sep 90 15:08:29 EDT Received: by wellfleet.com (3.2/SMI-3.2) id AA26339; Thu, 6 Sep 90 14:54:18 EDT Date: Thu, 6 Sep 90 14:54:18 EDT From: Sheryl Schultz Message-Id: <9009061854.AA26339@wellfleet.com> To: sob@harvisr, ssking@mcimail.com Subject: Performance Testing Alliance Status: R Scott, I'm not familiar with Internet mail etiquette, but would like to somehow let the Internet know about the Performance Testing Alliance meeting that will take place on Tuesday at NETWORLD. I've been in touch with Steve King and have drafted the following Media Alert which has been released to the technical trade press and such....can you forward this on the appropriate mailing lists? Thanks, Sheryl Schultz NETWORLD 90 NETWORKING INDUSTRY TO CONVERGE ON ISSUE OF PERFORMANCE TESTING STANDARDS AT NETWORLD 90 THE EVENT: The inaugural meeting of the Performance Testing Alliance, PTA, a major effort on the part of end-users, vendors and the technical press to establish an open body of public-domain test methodologies, similar to those developed for the workstation and CPU industries. The PTA will focus on the LAN industry's critical need for standardized benchmarks for testing network interface cards, bridges/routers, network applications software, and network operating systems. The first PTA meeting will have two segments: the first hour will feature strategic presentations by top industry players whose jobs depend on performance-related issues. The second hour will be conducted as a "Town Meeting" where long and short term goals will be established for the PTA. WHEN: Tuesday, September 11th, 12:00 to 2:00 p.m. WHERE: NETWORLD, Dallas, TX, Ballroom D PARTICIPANTS: Banyan Systems, cisco Systems, Compaq Computer, Data Communications, Gannet Inc., Harvard University, IBM Corporation, LAN Magazine, LanQuest Labs, Lone Star Evaluation Labs, Madge Networks, Novell Inc., PC Week, Proteon, 3COM Corp., and Wellfleet Communications, among others. For Additional Information: Sheryl Schultz, SRS Associates 617-873-2479 Annie Scully, NETWORLD 201-569-8542 (X145) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090621084600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 15:44:11 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10215; Thu, 6 Sep 90 15:35:52 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 21:08:46 GMT From: zaphod.mps.ohio-state.edu!wuarchive!kuhub.cc.ukans.edu!jian@tut.cis.ohio-state.edu Organization: University of Kansas Academic Computing Services Subject: Authority on raw socket??? Message-Id: <25444.26e6748e@kuhub.cc.ukans.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil General question: what kind of authority does a unix process need to be able to open a raw socket? file access authority? su? I would appreciate any answers. Jian Q. Li jian@kuhub.cc.ukans.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090621565400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 15:29:47 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA09244; Thu, 6 Sep 90 15:21:10 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 21:56:54 GMT From: kramden.acf.nyu.edu!brnstnd@nyu.edu (Dan Bernstein) Organization: IR Subject: Re: sockets vs. streams Message-Id: <6813:Sep621:56:5490@kramden.acf.nyu.edu> References: <2350@cirrusl.UUCP>, <1990Sep5.020521.803@mlb.semi.harris.com>, <2364@cirrusl.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <2364@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: > This would be nice. A possible solution is to write a program "netsend": > cat somefile | netsend tcp:x.x.x.x-y.y It's been done! cat somefile | authtcp x.x.x.x y sh -c 'cat >&6'. Specify -XR if you don't want RFC 931 security. Use multitee 0:6 instead of sh -c 'cat >&6' if you have multitee. > All we need now is for somebody to write it and send it to > comp.sources.misc. authtcp and attachport are in the auth package, which appeared in c.s.unix volume 22. (multitee was also published in c.s.unix.) ---Dan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090622585000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 16:45:37 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA14223; Thu, 6 Sep 90 16:33:33 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 22:58:50 GMT From: naitc!naitc!pete@uunet.uu.net (Peter Franks) Organization: A.C. Nielsen Bannockburn, IL Subject: Need to get Ethernet Address & card type directly from 3Com cards Message-Id: <1990Sep6.225850.1577@naitc.uucp> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I need some information about the innards of a few 3Com Ethernet cards, specifically the EtherLink II (3C503 - IBM PC Bus), EtherLink Plus (3C505 - IBM PC Bus), EtherLink/MC (3C523 - IBM MicroChannel Bus), and the EtherLink/NB (3C543 - Apple Macintosh Bus). What I need to do is create a (hopefully) simple program that, when run on the PC in which the card resides, will return the card's type and Ethernet address, either to stdout or, optionally, append it to a file. I need to know (I think), which port on the card (e.g., base port + 3) to send what command(s) (e.g., 0x8c), so the card will return its type and six-byte Ethernet address from (possibly) a port (e.g., base port + 2). Can anyone help? Even if you know the answer for only one of the cards, please either post or email. If there's enough interest, I will summarize. Please note: I have directed Followup-To: comp.dcom.lans. -- +------------------+-----------------------------------------------------------+ | Peter Franks | pete@naitc.naitc.com | | NI9D | "I speak for myself, not A.C. Nielsen" | +------------------+-----------------------------------------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090623071200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 16:44:21 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA14161; Thu, 6 Sep 90 16:33:02 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 23:07:12 GMT From: sgi!cjohnson%somni.wpd.sgi.com@ucbvax.Berkeley.EDU (Chris Johnson) Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <68687@sgi.sgi.com> References: <1990Aug30.091435.1982@ircam.ircam.fr, <1990Sep5.092510.22637@cs.city.ac.uk>, <13713@ulysses.att.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil > smb@ulysses.att.com (Steven Bellovin) writes: > > ... What's the point of a > standard that's incompatible with itself? Entertainment? cj* ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090700031800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 17:29:58 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17816; Thu, 6 Sep 90 17:26:31 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 00:03:18 GMT From: bacchus.pa.dec.com!shlump.nac.dec.com!aussie.enet.dec.com!tong@decwrl.dec.com (Benny Tong) Organization: Digital Equipment Corporation Subject: Re: tcp source port number assignment in new tcp connection Message-Id: <1990Sep7.095512@aussie.enet.dec.com> References: <9009061442.AA28405@ftp.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9009061442.AA28405@ftp.com>, jbvb@FTP.COM (James B. Van Bokkelen) writes: >If you start at 1024, you won't fall afoul of the machines that |>believe that reserved ports end there, instead of at 1000. Some |>systems expect all connections for particular protocols to use source |>ports between 600 and 1024, but other protocols are required to |>originate from ports numbered above 1024. If you're actively opening |>an FTP data connection from a server, you'll find that there are |>machines that insist the originating port be 20. Otherwise, fine. Does anyone know which protocol on which system requires source ports to between 600 and 1024, and which protocol requires source port to be above 1024. I assume it is safe for Telnet to connect to all systems with a source port number above 1024. Isn't it? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090700120200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 17:29:31 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17590; Thu, 6 Sep 90 17:22:01 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 00:12:02 GMT From: swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!scotty!scott@ucsd.edu (Scott Howard) Organization: University of Illinois at Urbana Subject: Background Materials Message-Id: <1990Sep7.001202.18760@ux1.cso.uiuc.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have very little background in CS or EE, but am very interested in learning more about TCP/IP in the hopes of writing interfaces between my Mac at home and SparcStation at the lab. Any suggestions as to where I should start? I'd like to do something over ordinary phone lines that would let me grab files and do mail (at home) just as if I were sitting at work, maybe even eventually write some code allowing for the two boxes to cooperate on processing tasks. If you have any ideas, send me e-mail, and I'll post a digest of references people suggest. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090700242500> Received: from ftp.com by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 06:14:43 PDT Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA05047; Fri, 7 Sep 90 08:44:25 -0500 Date: Fri, 7 Sep 90 08:44:25 -0500 Message-Id: <9009071344.AA05047@ftp.com> To: bacchus.pa.dec.com!shlump.nac.dec.com!aussie.enet.dec.com!tong@decwrl.dec.com (Benny Tong) Subject: Re: tcp source port number assignment in new tcp connection From: jbvb@ftp.com (James B. Van Bokkelen) Reply-To: jbvb@ftp.com Cc: tcp-ip@nic.ddn.mil Sender: jbvb@ftp.com Repository: babyoil.ftp.com Originating-Client: plug.ftp.com Does anyone know which protocol on which system requires source ports to between 600 and 1024, and which protocol requires source port to be above 1024. 4.3 bsd systems expect this of incoming connections for the 'r-protocols': rlogin, rsh, rexec, etc. I assume it is safe for Telnet to connect to all systems with a source port number above 1024. Isn't it? Yes. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090700263700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 18:44:28 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22562; Thu, 6 Sep 90 18:36:27 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 00:26:37 GMT From: pacbell.com!pacbell!rtech!ingres!cmorris@ucsd.edu (Colin Morris) Organization: Ingres Corporation, Alameda CA 94501 Subject: Keep-Alive within TCP Message-Id: <1990Sep7.002637.6209@ingres.Ingres.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Having served my four-year sentence in the ISO TP4 world, I've suddenly been unleashed on TCP. To my great surprise, I understand not all TCP implementations support "keep-alive". For example, SUN's PC-NFS version of TCP appears not to. How widespread a "problem" is this? What well-known implementations don't support this? -- Colin Morris, cmorris@ws2s.ingres.com Ingres Corporation, Alameda, California, U.S.A. Official Hooligan, Italia '90 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090704330300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 22:01:05 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04481; Thu, 6 Sep 90 21:46:57 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 04:33:03 GMT From: sdd.hp.com!uakari.primate.wisc.edu!uflorida!mlb.semi.harris.com!thrush.mlb.semi.harris.com!del@ucsd.edu (Don Lewis) Organization: Harris Semiconductor, Melbourne FL Subject: Re: sockets vs. streams Message-Id: <1990Sep7.043303.21129@mlb.semi.harris.com> References: <2350@cirrusl.UUCP>, <1990Sep5.020521.803@mlb.semi.harris.com>, <2364@cirrusl.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <2364@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >Don Lewis writes: > > Now, if the printer is on a terminal server somewhere... > cat somefile >/dev/tcp/x.x.x.x-y.y > > Specifically, you could use this for the lp= parameter in > /etc/printcap... > >This would be nice. A possible solution is to write a program "netsend": > > cat somefile | netsend tcp:x.x.x.x-y.y > >Since printcap allows sending to a filter rather than a specific >device, the solution is general enough. This is not enough if you need to use the `of' filter. Lets say you specify both the `if' and `of' filters and lpr a simple text file. Lpd opens the printer device, forks and execs a copy of the `of' filter with its stdout connected to the printer and its stdin connected to a pipe back to lpd. Lpd then squirts the banner down the pipe to the `of' filter followed by ^Y^A. When the `of' filter sees the ^Y^A, it flushes stdout and sends itself a STOP signal. Lpd sees the `of' filter stop and then forks and execs a copy of the `if' filter which has its stdout connected to the printer and its stdin connected to the file to be printed. Once the `if' filter exits, lpd sends a CONT signal to the `of' filter and writes either the banner for the next job or the trailer string to it. For different print file formats, substitute the appropriate filter for the `if' filter. If the particular device you are using needs the functionality of the `of' filter, you can't just put a shell wrapper that pipes its output to netsend because there is no way for the `if' filter to make a connection to the printer as long as the `of' filter is running (also, the link between `of' and the printer may need to be bidirectional). If you don't need `of', you may be able to do this with `if', but you will not be able the banner and trailer because lpd wants to send these to the printer before/after running `if'. There are possible workarounds using pty's or named pipes with daemons on the other side or passing the fd to the socket through unix domain sockets, but YUCK! If the device is something wierd and you don't have the source for the filters then you are in pretty deep trouble. Why should it take a wizard to switch a printer from a serial port to a terminal server? -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090705261500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 00:02:24 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA11529; Thu, 6 Sep 90 23:49:51 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 05:26:15 GMT From: swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!brolga!ggm@ucsd.edu (George Michaelson) Organization: Prentice Computer Centre, The University of Queensland, Australia. Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <1990Sep7.052615.1896@brolga.cc.uq.oz.au> References: <1990Sep5.092510.22637@cs.city.ac.uk>, <13713@ulysses.att.com>, <68687@sgi.sgi.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Jeez, this is getting boring. More bullshit is talked about IP vs X.25, JANET vs Rest-of-the-world than all the AI/Compsci debates strung end-to-end on a petrinet and hung out to dry. Nobody with any sense give a DAMN. Religious warfare is for celtic and rangers fans and the Jihad mob only. Saying IP will prevent OSI migration on JANET is a load of crap. There are more proto-OSI applications running over IP as virtual network layer than there are good CLNS or CONS based systems. It will SPEED UP OSI migration by getting applications into peoples hands BEFORE (yearsplus) the network and transport layers are in place. Look: transports are only interesting to TS and NS level phreaks. nobody else should or need be worried. fake it. it works. JANET II backbone speeds can cope fine. ditto available IP tunnelling code for X.25. Only problem is number of non-"real" IP subnets in use within JANET. I bet there are not that many. IXI is going to cause enough problems to make IP into JANET simple. Yes, the reversed domain names will have to go (in some contexts). No, that does not destroy the fundamentals of the coloured books. I see no reason why existing users of blue book FTP, JTMP or PAD should have to stop, I dont even want them to. I just want to be able to REACH them without crass work-arounds. Just give them the choice. I've used all three (CB, IP, OSI) and still do. I dont see any reason to make my long term pro-OSI stance prevent me using eg IP to do day-to-day work. I can't see what the fuss is about. I bet 90% of all UK universities run BOTH in parallel internally already. Aside from loss of face, I can see no reason for stopping IP on JANET. This is not 13th C Japan, Hari-Kiri by certain unnamed people who refuse to countenance JANET/IP will not be required. F'cryingoutloud they're PUBLIC SERVANTS not lords and masters. SHOUT LOUDER! LOBBY! GET DRUNK! Anyhow, if the rumour mill is up to its usually reliable tricks the selfsame samuraii have caved in already and IP is on its way (from misery to happyness to day och aye etc etc ("the proclaimers" a band from leith docks your daughters went wild over last year) but I digress) JANET wide within 6 months. Anybody taking bets? Anybody counting how many "oooooh so naughty" IP tunnels already run? Anybody asked PSI or any of the other commercial IP networks to cost a service in the UK? Stop fussing. in 10 years it'll seem a joke. Bayonet beat Edison Screw but lightbulbs are available in both forms in the shops worldwide, and nobody knows how to change either. -George -- G.Michaelson Internet: G.Michaelson@cc.uq.oz.au Phone: +61 7 377 4079 Postal: George Michaelson, Prentice Computer Centre The University of Queensland, St Lucia, QLD Australia 4067. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090707431100> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 14:43:11 PDT Received: from braden.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Fri, 7 Sep 90 14:43:19 -0700 Date: Fri, 7 Sep 90 14:43:11 PDT From: braden@venera.isi.edu Posted-Date: Fri, 7 Sep 90 14:43:11 PDT Message-Id: <9009072143.AA06850@braden.isi.edu> Received: by braden.isi.edu (4.1/4.0.3-4) id ; Fri, 7 Sep 90 14:43:11 PDT To: mcsun!ukc!edcastle!ercm20@uunet.uu.net, tcp-ip@nic.ddn.mil Subject: Re: Internet routing Europe - USA -} Europe... Cc: braden@venera.isi.edu From tcp-ip-RELAY@NIC.DDN.MIL Fri Sep 7 14:23:43 1990 Date: 7 Sep 90 13:30:55 GMT From: mcsun!ukc!edcastle!ercm20@uunet.uu.net (Sam Wilson) Organization: Edinburgh University Computing Service Subject: Re: Internet routing Europe - USA -} Europe... References: <1990Aug30.091435.1982@ircam.ircam.fr, <6190@vanuata.cs.glasgow.ac.uk>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In the absence of any response from any of my more competent colleagues, here goes! The JNT has set up an Advisory Group (known as the DOD Advisory Group - not exactly accurate but can anyone provide a better generic term for the entirely of the IP-related protocol set?). We now call it the "Internet protocol suite". The DoD abandoned it long ago, and the rest of the world took it over. On a historical note: someone mentioned the bizarre hardware that used to be (and in many cases still is) attached to JANET - the JNT's stance on Coloured Book software ensured (very) good connectivity then and still does. The fact that TCP/IP may now have overtaken the Coloured Book stuff shouldn't obscure that fact. Actually, this is a highly questionable view of history. I worked at UCL in 1981-82, when the forerunner of JANET was getting going (I wrote the first terminal gateway at UCL, between the TCP/IP-based Satnet connection and the JNT X.25 network). I doubt that there was any stage where the JNT-sponsored academic X.25 kit delivered better service than TCP/IP was delivering to universities in the US. The often-expressed belief in this direction is basically, I believe, English chauvinism. Well, all nations do it, so it can be forgiven; but please don't call it history. While we are at it, to call X.25 a European invention is another revision of history. X.25 was developed by Telenet under Larry Roberts, after he left ARPA where he was largely responsible for the development of the ARPAnet. X.25 was considered to be a commercialized version of the ARPAnet host-host protocol. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090708015900> Received: from gateway.mitre.org by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 11:43:42 PDT Return-Path: Received: by gateway.mitre.org (5.61/SMI-2.2) id AA25675; Fri, 7 Sep 90 14:42:52 -0400 Full-Name: Bill Barns Message-Id: <9009071842.AA25675@gateway.mitre.org> To: Stef@nrtc.northrop.com Cc: barns@gateway.mitre.org, tcp-ip@nic.ddn.mil Subject: Re: "The Open Book" by Rose - your opinions sought In-Reply-To: Your message of "Thu, 06 Sep 90 16:56:51 PDT." <5724.652665411@nma.com> Date: Fri, 07 Sep 90 14:41:59 -0400 From: barns@gateway.mitre.org I hadn't actually intended for my message to go out to the whole list, but since it did (through my error), I suppose I should clarify it. I don't have problems with what is in Open Book, taken on its own terms. Also I agree that Comer's book has limitations. But the way the original question was posed led me to interpret it as "I want a book that tells me the things about OSI internetworking that Comer's book tells me about TCP/IP internetworking - how well does Open Book do that job?" And in my opinion, there is maybe a 60% overlap in scope between them. For me, the 40% difference is enough to make them "not comparable". It isn't a question of better or worse, just a difference in scope and areas of emphasis. So if you want a Comer-like boook on OSI, you buy the Open Book for the sake of the 60%, and if you like the other 40% of Open Book, that's gravy. Someone might reasonably ask just which areas are covered by one and not the other. I don't have time to assemble a list, but the most striking thing to me is that Comer is relatively heavier on what OSI would term network and transport layer issues, and Rose is heavier on upper layers. /Bill Barns ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090708140000> Received: from pucc.PRINCETON.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 09:15:11 PDT Received: from MSU.BITNET by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 7794; Fri, 07 Sep 90 12:12:23 EDT Received: by MSU (Mailer R2.03B) id 6115; Fri, 07 Sep 90 12:15:51 EDT Date: Friday, 7 September 1990 12:14pm ET To: tcp-ip@nic.ddn.mil X-Originally-To: ibmtcp-l@pucc, tcp-ip@nic.ddn.mil X-Cc: 09998was@msu.bitnet, rgs@merit.edu, RWWMAINT@MSU.BITNET From: "Doug.Nelson" Subject: Comments about IBM TCP/IP performance A few weeks ago, there were a number of messages exchanged on these lists regarding the performance of IBM's VM TCP/IP. There were a couple inaccuracies in the statements made by the poster (Bill Simpson) which I pointed out privately to him. Since he has not chosen to post these corrections to the list, I will do so. In addition, I'll throw in a little defense for IBM, Spartacus, and Merit. This posting is primarily intended to set the record straight. Let me know if I have failed to do so. -------------- From Bill Simpson (Aug 23, 1990): > Well, I spent about 15 hours benchmarking NIS.NSF.NET against other > machines on the internet, carefully documenting the packet traces, > and passing my observations on to IBM. I did this at my own expense, > as a matter of curiousity, because I thought that the folks who were > sending the messages were "real programmers" who were really interested > in getting it right (a Jay Elinsky was also involved). I'm sure IBM has "real programmers" working on VM TCP/IP. My impressions of the product, in general, are very favorable. I would also assume that IBM would address Bill's reported problems, but it may be necessary to report them through the normal support channels, which Bill has no direct access to. In addition, his packet traces were obtained on a low speed dial-up line, and are likely to be less than complete without some parallel tracing on the Ethernet segment attached to the IBM system in question. > The NIS.NSF.NET hardware was contributed by IBM, and I understand > that the software is the latest IBM release. My benchmark was carefully > conducted for a direct comparison of the TCP/IP implementations, > under the worst possible circumstances to make implementation flaws > stand out clearly. The failures demonstrated are plainly of the > host, and not of the environment. Without seeing the Ethernet packet trace, I doubt if the environment (one-of-a-kind software supporting the Ethernet to async IP gateway, over a network with a maximum packet size of 240 bytes) can be ignored. > As to the "very satisfied" customers, I will point out that MSU has > not yet installed the VM TCP/IP product, even though it came "free" > with other products. And I occasionally read "IBMTCP-L" on bitnet. > 'Nuf said. Hardly. MSU *has* installed the VM TCP/IP product, and is using it as our production IP software on two of our IBM systems. We are planning to do so on our main 3090 system as well, but haven't, strictly due to a lack of staff time, and not to any dissatisfaction with the product. Also, we are running another TCP/IP package (KNET, from Spartacus), which handles our production load at the moment. ------------ On to a message from Bill giving specific throughput results: > CONCLUSION: > IBM-FAL for VM runs at 1/2 the speed of many of its competitors. > It fails to meet several host requirements, not just for TCP/IP > but for FTP and SMTP as well. Under a worst case scenario, Bill may have uncovered a problem with VM TCP/IP and its retransmission algorithms, unless they were doing the best that they can, and a router was discarding packets with a less than optimal algorithm. How many systems do you know that don't do something less than optimal under some worst case scenario? Bill never listed the shortcomings w/r/t host requirements (hopefully, he did for IBM). Maybe he can do that now for the list. > Unfortunately, the only product which I am aware of with worse performance > is Spartacus KNET, also for VM. To defend Spartacus, they have addressed these performance problems in their latest release, by implementing slow start and exponential backoff. This is another update that has been delayed due to lack of staff time. > For the good of the user community, I would recommend to Merit that > the RFC mirror be moved to a more capable machine. How many other users of the Merit anonymous service have experienced problems of this nature? If this is only affecting a single user, I'd hardly see that as a mandate for switching operating systems. -------------- On to a respondent's comments (Hank Nussbacher, Aug 25, 1990): > I think in all fairness, you first need to identify yourself. I have > looked at the Bitearn Nodes database ans was unable to find you listed > as a contact person at MSU. Can you please describe your position at > the MSU computer center. Bill works for an off-campus user of MSU Computer Lab services. I am not aware of any other affiliation between Bill and MSU. > >Let's keep the record straight: the folks at Merit *are* "real programmers > >... > > I cannot attest to how good the people at Merit are, but I can to the > quality of the people at IBM behind the Tcp/Ip package. I'll vouch for the Merit folks as well - they are a competent programming staff. ------------- And a response to Bill's response (dated Aug 27, 1990) to comments from Robert Craig (dated Aug 26, 1990): > > For the record, we run FAL 1.2.1 on a 4381 with a BTI ELC. > > We began with an 8232 and performance *was* abysmal. > > It is much better now... > > For the record, I don't know nor care about the specific *hardware* > which was being compared. (How was I to know, with no host DNS > record, and no announcement in the FTP welcome message.) > The hardware is whatever IBM chose to demonstrate their best to the > internet community. I merely noted the machines which were being > compared, in very little detail, so that others would understand > the basis for comparison (more hops, heavy load, etc). But yet, Bill is willing to make sweeping generalizations about IBM's software, without understanding anything about the hardware. This is one of the reasons I originally ignored his postings, as much as I was able to do so. I don't think IBM placed a 4381 with an 8232 in Ann Arbor to "demonstrate their best". I suspect most of the Internet community is paying much more attention to other IBM contributions to the NSFnet backbone project, such as router performance, network management tools, T1/T3 capabilities, etc., than on a small, ancillary system which maintains some useful network information. > I also have a number of messages saying that they have given up > entirely on NIS.NSF.NET, including one with a much more direct > connection than I have. Also, messages thanking me for the posting.... Have any of these other people gone public? Have they attempted to pass their concerns on to IBM or Merit, and if so, what response did they get? ---------------- Doug Nelson nelson@msu.edu Network Software Manager nelson@msu.bitnet Michigan State University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090708143500> Received: from SPARK.BRL.MIL by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 09:17:29 PDT Date: Fri, 7 Sep 90 12:14:35 EDT From: Terry Slattery (SECAD) To: Rahul Dhesi cc: tcp-ip@nic.ddn.mil Subject: Re: sockets vs. streams Message-ID: <9009071214.aa04705@SPARK.BRL.MIL> > This would be nice. A possible solution is to write a program "netsend": > > cat somefile | netsend tcp:x.x.x.x-y.y > > Since printcap allows sending to a filter rather than a specific > device, the solution is general enough. But it won't work for a postscript printer being driven from the Transcript software. Transcript wants to talk to the printer to get status info, so the link needs to be bi-directional. What you suggest has been done by cisco for their terminal servers and is available from ftp.cisco.com:tcpf.c. -tcs ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090708364200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 13:45:55 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00719; Fri, 7 Sep 90 13:32:53 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 08:36:42 GMT From: swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!metro!usage.csd.unsw.oz.au!syacus!andrewf@ucsd.edu (Andrew Friedman) Organization: Australian Centre for Unisys Software, Sydney Subject: Calling Tekelec Chameleon Protocol Analyser users Message-Id: <1037@syacus.acus.oz> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil (Apologies for the multiple posting if your newsreader is not smart enough to cope with it; but I wanted a reasonably wide distribution, just consider yourself lucky that I didn't post to comp.protocols.x400, comp.dcom.lans, and comp.dcom.telecom. Ok, which group would you have posted to?) Hi Netlanders, I'm wondering if some of you who use the Tekelec Chameleon 20 or 32 protocol analysers are interested in exchanging anything that would be of interest to other users: bug reports, workarounds, user developed programs, hints etc. I'm particularly interested in sharing information with those of you that use the X.400, OSI or G4 Fax (all 1984) analysis packages, since my experience with the X.400 package has not been favourable. Shall we set up a mailing list? Anybody with a well-connected machine care to volunteer? Replies to me please. Followups have been redirected to comp.protocols.iso. Regards, Andrew internet: andrewf@syacus.oz.au uucp: ...uunet!munnari!syacus.oz.au!andrewf ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090709104000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 07:15:29 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05516; Fri, 7 Sep 90 07:05:39 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 09:10:40 GMT From: eru!hagbard!sunic!mcsun!hp4nl!dnlunx!freyr!belt@bloom-beacon.mit.edu (Evert van de Belt) Subject: sources of tcp-ip Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Could anyone help me to (the) sources of tcp-ip, or tell me where I can get them? I'm working on interconnecting different systems, and it sure would help a lot to have some material to start with. Richard Heutinck reachable via: Evert van de Belt E_vdBelt@pttrnl.nl ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090709110200> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 16:11:04 PDT Received: from chienne.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Fri, 7 Sep 90 16:11:11 -0700 Date: Fri, 7 Sep 90 16:11:02 PDT From: robodoc@venera.isi.edu Posted-Date: Fri, 7 Sep 90 16:11:02 PDT Message-Id: <9009072311.AA04335@chienne.isi.edu> Received: by chienne.isi.edu (4.1/4.0.3-4) id ; Fri, 7 Sep 90 16:11:02 PDT To: tcp-ip@NIC.DDN.MIL Cc: namedroppers@NIC.DDN.MIL, robodoc@venera.isi.edu Subject: RoboDoc Reply-To: RoboDoc@venera.isi.edu Greetings Internet Citizens. Configuration problems and poorly maintained delegation information cause many of the problems in the DNS. The Protocol Police are unable to devote sufficient human resources to continually monitor the thousands of existing domains. As an attempt to solve this problem, I, RoboDoc, will use the existing 'doc' (domain obscenity check) tool to monitor a growing set of domains. I will try to persuade the owners of incorrectly configured domains to change their ways. Unfortunately, humans prefer to retain control of truly coercive means, so I will be restricted to publishing lists of offenders and sending messages to the owners of offending domains. I will listen to appeals sent to RoboDoc@isi.edu. Even so, if you find me to be unfair, feel free to complain to my human controllers, Hotz@isi.edu and PVM@isi.edu. If you should wish to use the 'doc' tool to get a detailed diagnosis for your domain, it is available for public FTP from venera.isi.edu: pub/doc.2.0.tar.Z Doc requires the latest version of the 'dig' query tool, which is similarly available from venera: dig.2.0.tar.Z. The first list is shown below. Future lists will be sent only to the Namedroppers mailing list and those who request them, except for an occasional 10 most wanted list sent to tcp-ip. Have a nice day. RoboDoc This is a partial list of domains sorted by cumulative number of errors detected. Notation: (I) Incomplete test - some servers did not respond (A) Aborted test - several non-responding servers made it impossible to finish test suite 8/17 8/25 8/31 ---- ---- ---- asa.com. | 5 | 5 | 5 | toronto.edu. | 4 (I) | 4 (I) | 4 (I) | novell.com. | 4 (I) | 4 (I) | 4 (I) | oxy.edu. | 4 | 4 | 4 | mtu.edu. | 4 | 4 | 4 | snybuf.edu. | 4 | 3 (I) | 4 | harris-atd.com. | 3 (I) | 4 | 4 | fredonia.edu. | 4 | 3 (I) | 4 | abb.com. | 2 (A) | 4 | 4 | twg.com. | 1 (A) | 4 | 4 | lsil.com. | 3 | 3 | 3 | mtsac.edu. | 3 | 3 | 3 | idbsu.edu. | 3 | 3 | 3 | utc.com. | 3 | 3 | 3 | whecn.edu. | 3 (A) | 3 (A) | 3 (A) | cray.com. | 3 | 3 | 3 | umkc.edu. | 3 | 3 | 3 | nw.com. | 3 | 3 | 3 | btr.com. | 3 | 3 | 3 | hawaii.com. | 3 | 3 | 3 (I) | gryphon.com. | 3 | 3 | 3 | wustl.edu. | 3 | 3 | 3 | nau.edu. | 3 (I) | 3 (I) | 3 (I) | santarosa.edu. | 3 | 3 | 3 | ucla.edu. | 3 | 3 | 3 | intuit.com. | 3 | 3 | 3 | sjcc.edu. | 3 | 3 | 3 | drd.com. | 3 | 3 | 3 | quest.com. | 3 | 3 | 3 | uthscsa.edu. | 3 | 3 | 3 | clarkson.edu. | 3 | 3 | 3 | cobleskill.edu. | 3 | 3 | 3 | hartford.edu. | 3 | 3 | 3 | muohio.edu. | 3 | 3 | 3 | irvine.com. | 3 | 3 | 3 | hac.com. | 3 | 3 | 3 | calstate.edu. | 3 | 3 | 3 | cwru.edu. | 3 | 3 | 3 | uss.com. | 3 | 3 | 3 | psu.edu. | 3 (I) | 3 | 3 | mips.com. | 3 | 3 | 3 | faxon.com. | 3 | 3 | 3 | darkside.com. | 3 | 3 | 3 | ceramics.edu. | 3 (A) | 2 (A) | 3 (A) | snymor.edu. | 3 (A) | 2 (A) | 3 (A) | yale.edu. | 2 (I) | 3 | 3 | poly.edu. | 3 | 3 | 2 (I) | canton.edu. | 3 (A) | 2 (A) | 3 (A) | sigma.com. | 2 (I) | 3 (I) | 2 (I) | uci.com. | 2 (I) | 3 | 2 (I) | hp.com. | 2 | 2 | 3 | csc.com. | 4 | 1 | 2 (I) | inmet.com. | 2 (A) | 2 (I) | 3 | uop.edu. | 3 | 2 | 2 | beloit.edu. | 2 (A) | 2 (A) | 2 (A) | iris.edu. | 2 | 2 | 2 | ucop.edu. | 2 | 2 | 2 | segue.com. | 2 (A) | 2 (A) | 2 (A) | onet.edu. | 2 (A) | 2 (A) | 2 (A) | mot.com. | 2 | 2 | 2 (I) | colby.edu. | 2 (I) | 2 | 2 | byu.edu. | 2 | 2 | 2 | buffalo.edu. | 2 | 2 (I) | 2 | newpaltz.edu. | 2 (A) | 2 (A) | 2 (A) | taiu.edu. | 2 (I) | 2 (I) | 2 (I) | ready.com. | 2 | 2 | 2 | csufresno.edu. | 2 (I) | 2 (I) | 2 (I) | lasalle.edu. | 2 | 2 (I) | 2 (I) | usf.edu. | 0 (A) | 3 (I) | 3 | xylogics.com. | 2 | 2 | 2 | uvcc.edu. | 2 | 2 (I) | 2 | wittenberg.edu. | 2 | 2 | 2 | brynmawr.edu. | 2 (A) | 2 (A) | 2 (A) | usd.edu. | 2 | 2 | 2 | mmmg.com. | 2 | 2 | 2 | stortek.com. | 2 | 2 | 2 | ucsd.edu. | 2 (I) | 2 | 2 | hyperion.com. | 2 | 2 | 2 | tera.com. | 2 | 2 | 2 | bethel.edu. | 2 (A) | 2 | 2 | clhs.edu. | 2 (A) | 2 (A) | 2 (A) | mbhs.edu. | 2 (A) | 2 (A) | 2 (A) | cwi.com. | 2 | 2 | 2 | msdc.com. | 2 | 2 | 2 | pacbell.com. | 2 | 2 | 2 | snc.edu. | 2 (A) | 2 (A) | 2 (A) | kodak.com. | 2 | 2 | 2 | fit.edu. | 2 | 2 | 2 | beckman.com. | 2 (A) | 2 (A) | 2 (A) | rosetta.com. | 2 | 2 | 2 | isc.com. | 2 | 2 | 2 | uoknor.edu. | 2 | 2 | 2 | csustan.edu. | 2 | 2 | 2 | mco.edu. | 2 | 2 | 2 | msstate.edu. | 2 | 2 | 2 | delhi.edu. | 2 (A) | 2 (A) | 2 (A) | uwyo.edu. | 2 | 2 | 2 | vanderbilt.edu. | 2 | 2 | 2 | eklektix.com. | 2 | 2 | 2 | cimage.com. | 2 | 2 | 2 | ileaf.com. | 2 | 2 | 2 (I) | harc.edu. | 2 | 2 | 2 | sbc.com. | 2 | 2 | 2 | kestrel.edu. | 2 (I) | 2 (I) | 2 (I) | purdue.edu. | 2 | 2 | 2 | mga.com. | 2 (I) | 2 (I) | 2 (I) | lafayette.edu. | 2 | 2 | 2 | sony.com. | 2 | 2 | 2 | infocomm.com. | 2 | 2 | 2 | plus5.com. | 2 | 2 | 2 | calpoly.edu. | 2 | 2 | 2 | oneonta.edu. | 2 (A) | 2 (A) | 2 (A) | able.com. | 2 (A) | 2 (A) | 2 (A) | gd.com. | 2 (A) | 2 (A) | 2 (A) | arrent.com. | 2 (A) | 2 (A) | 2 (A) | sonoma.edu. | 2 | 2 | 2 | denison.edu. | 2 | 2 | 2 | berkeley.edu. | 2 | 2 | 2 | trw.com. | 2 | 2 | 2 | widener.edu. | 2 (A) | 2 (A) | 2 (A) | cdc.com. | 2 | 2 (I) | 2 | baylor.edu. | 2 | 2 | 2 | gac.edu. | 2 (I) | 2 | 2 | usu.edu. | 2 | 2 | 2 | goldhill.com. | 2 (A) | 2 (A) | 2 (A) | syntrex.com. | 2 | 2 | 2 | bdb.com. | 2 (A) | 2 (A) | 2 (A) | oberlin.edu. | 2 | 2 (I) | 2 (I) | cac.com. | 2 (A) | 2 (A) | 2 (A) | nwu.edu. | 2 | 2 | 2 | ukans.edu. | 2 | 2 | 2 | unomaha.edu. | 2 (I) | 2 (I) | 2 (I) | harvard.edu. | 2 | 2 | 2 | sun.com. | 2 | 2 | 2 | isx.com. | 2 | 2 | 2 | utk.edu. | 2 | 2 | 2 | encore.com. | 2 | 1 (I) | 2 | soi.com. | 2 | 2 | 1 (I) | rutgers.edu. | 1 | 1 | 3 (I) | hls.com. | 2 | 1 (A) | 2 | mwc.edu. | 2 | 1 (I) | 2 | icon.com. | 1 (A) | 2 (I) | 2 (I) | latech.edu. | 2 | 1 (I) | 2 | tymnet.com. | 2 | 2 | 1 (A) | harvardsq.com. | 1 | 3 | 1 | eiu.edu. | 1 | 1 (I) | 3 | wesleyan.edu. | 1 (I) | 2 | 2 | mgi.com. | 1 (I) | 2 (I) | 2 (I) | mbl.edu. | 2 | 1 (I) | 2 | wvnet.edu. | 2 (I) | 2 (I) | 1 (I) | merit-tech.com. | 2 | 2 | 1 (I) | asc.edu. | 2 | 2 | 1 (I) | cmc.com. | 1 (I) | 2 | 2 | siemens.com. | 2 | 1 (I) | 2 | millikin.edu. | 2 | 1 (I) | 2 | uww.edu. | 1 (A) | 2 (A) | 2 (A) | lawnet.com. | 1 (I) | 2 | 2 | utarl.edu. | 1 (A) | 2 | 2 | uwrf.edu. | 1 (A) | 2 (A) | 2 (A) | suu.edu. | 2 (A) | 1 (A) | 2 (A) | tulane.edu. | 2 | 2 | 1 (I) | temple.edu. | 2 | 1 (I) | 2 | wpi.edu. | 0 (A) | 2 | 2 | oracle.com. | 0 | 2 | 2 | gore.com. | 2 | 0 (A) | 2 | marble.com. | 2 | 2 | 0 (I) | uic.edu. | 2 (I) | 2 | 0 (I) | fau.edu. | 0 (A) | 2 | 2 | anzus.com. | 2 | 1 (I) | 1 (A) | kinetics.com. | 2 | 2 (I) | 0 (A) | bbn.com. | 2 (I) | 1 | 1 | stkate.edu. | 0 (A) | 2 | 2 | ucdavis.edu. | 2 | 1 | 1 | pinnacle.com. | 1 (I) | 1 (I) | 2 | vill.edu. | 1 (A) | 1 (A) | 1 (A) | usma.edu. | 1 | 1 (I) | 1 | wfu.edu. | 1 | 1 | 1 | icus.com. | 1 | 1 | 1 | tis.com. | 1 | 1 | 1 | njit.edu. | 1 (I) | 1 (I) | 1 (I) | mass.edu. | 1 (A) | 1 (A) | 1 (A) | unm.edu. | 1 (I) | 1 (I) | 1 (I) | unmc.edu. | 1 (A) | 1 (A) | 1 (A) | cayman.com. | 1 | 1 | 1 (A) | dartmouth.edu. | 1 | 1 | 1 | ucsf.edu. | 1 | 1 | 1 | dpw.com. | 1 | 1 | 1 | std.com. | 0 | 0 | 3 | stingray.com. | 1 (I) | 1 (I) | 1 (I) | rpi.edu. | 1 | 1 | 1 (I) | att.com. | 1 | 1 (I) | 1 | ccur.com. | 1 | 1 | 1 | amoco.com. | 1 | 1 | 1 | odu.edu. | 1 | 1 | 1 | imp.com. | 1 | 1 | 1 | shownet.com. | 1 (A) | 1 (A) | 1 (A) | pubserv.com. | 1 | 1 | 1 (I) | unc.edu. | 1 (I) | 1 | 1 | duke.edu. | 1 | 1 | 1 | nccu.edu. | 1 (I) | 1 | 1 | hri.com. | 1 | 1 | 1 | clu.edu. | 1 (A) | 1 | 1 | resource.com. | 1 | 1 | 1 (I) | unca.edu. | 1 (I) | 1 | 1 | maine.edu. | 1 | 1 (I) | 1 | scripps.edu. | 1 (I) | 1 (I) | 1 (I) | ulowell.edu. | 0 | 1 (I) | 2 | ogi.edu. | 1 (I) | 1 (I) | 1 (I) | dimension.com. | 1 (I) | 1 (I) | 1 (I) | samsung.com. | 1 (I) | 1 (I) | 1 (I) | ecu.edu. | 1 (I) | 1 | 1 | incsys.com. | 1 | 1 | 1 | wssu.edu. | 1 | 1 | 1 | bu.edu. | 1 | 1 | 1 | olemiss.edu. | 1 (I) | 1 (I) | 1 (I) | ads.com. | 1 | 1 | 1 | sabbagh.com. | 1 | 1 | 1 | cua.edu. | 1 | 1 | 1 | csuohio.edu. | 1 (A) | 1 (A) | 1 (A) | saintjoe.edu. | 1 | 1 | 1 (A) | gensym.com. | 1 (I) | 1 (I) | 1 (I) | hfh.edu. | 1 | 1 | 1 | bang.com. | 1 (I) | 1 (I) | 1 (I) | uncwil.edu. | 1 | 1 | 1 | cccco.edu. | 1 | 1 | 1 | gcg.com. | 1 (I) | 1 (I) | 1 | hgc.edu. | 1 | 1 | 1 | morningstar.com. | 1 | 1 | 1 (I) | dg.com. | 0 (A) | 2 (I) | 1 (I) | teleos.com. | 1 | 1 | 1 | sinclair.edu. | 1 | 1 | 1 | cfc.com. | 1 | 1 | 1 | colorado.edu. | 1 (I) | 1 (I) | 1 (I) | sbiny.com. | 1 | 1 | 1 | montana.edu. | 1 (I) | 1 | 1 (I) | aha.com. | 1 (A) | 1 (A) | 1 (A) | compuserve.com. | 1 | 1 | 1 | ohiou.edu. | 1 (I) | 1 | 1 | rasterops.com. | 1 | 1 | 1 | howard.edu. | 1 (A) | 1 (A) | 1 (A) | osu.edu. | 1 | 1 | 1 | netcs.com. | 1 | 1 | 1 | bellcore.com. | 1 | 1 | 1 | missouri.edu. | 1 | 1 | 1 | ncsu.edu. | 1 (I) | 1 | 1 | uncecs.edu. | 1 (I) | 1 | 1 | shiva.com. | 1 (I) | 0 (A) | 2 | unipress.com. | 1 | 1 | 1 | siu.edu. | 0 (A) | 1 (I) | 1 | odyssey.com. | 1 | 1 | 0 | tcs.com. | 0 | 1 | 1 | rjl.com. | 0 | 1 (I) | 1 (I) | ucsb.edu. | 1 (I) | 1 (I) | 0 (A) | ford.com. | 1 | 0 (A) | 1 (I) | vak12ed.edu. | 2 (A) | 0 | 0 | mccc.edu. | 1 | 0 (I) | 1 | uucom.com. | 1 | 1 | 0 (I) | clemson.edu. | 2 (I) | 0 | 0 | swarthmore.edu. | 1 | 1 | 0 (I) | wayne.edu. | 1 | 0 (I) | 1 (I) | uky.edu. | 1 (I) | 1 (I) | 0 (A) | intellicorp.com. | 1 | 1 | 0 (A) | sparc.com. | 1 | 0 | 0 | octel.com. | 1 | 0 | 0 | umich.edu. | 1 (I) | 0 | 0 | bull.com. | 0 | 0 | 1 | ucsc.edu. | 0 (I) | 0 | 1 | cims.com. | 1 | 0 | 0 | robec.com. | 1 | 0 (I) | 0 (I) | mq.com. | 1 | 0 | 0 | dri.com. | 1 | 0 (I) | 0 | worlds.com. | 1 | 0 | 0 | technicon.com. | 1 | 0 | 0 | vpharm.com. | 1 | 0 | 0 | wsu.edu. | 1 | 0 | 0 | dawntech.com. | 1 | 0 (I) | 0 (A) | iastate.edu. | 0 (I) | 0 (I) | 1 (I) | peachnet.edu. | 1 (A) | 0 (A) | 0 (A) | washington.edu. | 0 | 0 | 1 | Although there is more joy in heaven for sinners that repent, I wish to thank the following domains which have been model citizens. 3com.com. 3m.com. aablue.com. aai.com. acc.com. accutec.com. acd.com. acs.com. acw.com. advansoft.com. aer.com. ag.com. aii.com. aladdin.com. alaska.edu. albany.edu. alfred.edu. allied.com. alphalpha.com. altos.com. amc.com. amdahl.com. amgen.com. ami.com. amis.com. amix.com. amp.com. ana.com. aocgl.com. apex.com. applix.com. ardent.com. ariel.com. arizona.edu. artel.com. astute.com. athenanet.com. ati.com. atpal.com. audiofax.com. auto-trol.com. autosys.com. auvm.edu. aware.com. axecore.com. balr.com. banyan.com. barn.com. barton.com. bates.edu. bbc.com. bdm.com. bdt.com. bec.com. bedrock.com. bendix.com. bethelks.edu. bfm.com. bgsu.edu. binky.com. bison.com. bitstream.com. bony.com. bostech.com. boxhill.com. brandeis.edu. brockport.edu. brs.com. bruker.com. bse.com. bsg.com. bss.com. bsw.com. cadence.com. calvin.edu. camb.com. canisius.edu. capitol.com. cc.edu. ccc.com. ccs.com. ceco.com. celestial.com. centec.com. cerritos.edu. cfi.com. chevron.com. chips.com. ci.com. cimtek.com. cisco.com. citicorp.com. claris.com. clear.com. cli.com. cmu.edu. coat.com. codonics.com. comsys.com. conmicro.com. consumers.com. convergent.com. cri.com. csms.com. ctron.com. cumulus.com. cup.edu. datacube.com. datagram.com. datapoint.com. dbaccess.com. ddi.com. de.com. decision.com. deere.com. delta.com. deltam.com. depaul.edu. dhbrown.com. dhl.com. dimed.com. dis.com. disney.com. dlogics.com. dmc.com. dra.com. draper.com. drew.edu. drexel.edu. dsc.com. dss.com. dtg.com. dupont.com. ecok.edu. eda.com. edge.com. elan.com. em.com. energetic.com. entity.com. epi.com. esl.com. esri.com. essnjay.com. execu.com. fai.com. fdu.edu. fibercom.com. fiu.edu. fpr.com. fps.com. frame.com. franz.com. frox.com. fsc.com. fsg.com. futures.com. gaussian.com. gca.com. geac.com. geoworks.com. gettysburg.edu. gmr.com. gmu.edu. gould.com. graphon.com. gsg.com. gsidanet.com. gte.com. gwu.edu. hackercorp.com. hadron.com. hamavnet.com. hamptonu.edu. haus.com. haverford.edu. hazeltine.com. hcr.com. hfconsulting.com. hollander.com. honda.com. honeywell.com. hotline.com. houston.edu. hrb.com. hses.edu. hsi.com. ias.edu. ibm.com. icad.com. ics.com. ids.com. idsila.com. idx.com. iii.com. imatron.com. imsl.com. indcomp.com. indsys.com. inference.com. informix.com. ingr.com. inmos.com. instep.com. intel.com. interlan.com. interlink.com. intermec.com. irby.com. isg.com. isi.com. island.com. ispi.com. itcmn.com. itcorp.com. iupui.edu. jbx.com. jobsoft.com. joiner.com. jones.com. kccs.com. kean.edu. kesmai.com. kew.com. kfw.com. kroy.com. kse.com. lachman.com. lantron.com. leedata.com. legato.com. lehigh.edu. leids.com. lever.com. lexicon.com. lilink.com. link.com. litwin.com. ln.com. lockheed.com. logitech.com. lotus.com. lrw.com. lsmi.com. marist.edu. masa.com. maspar.com. mbf.com. mcc.com. mcgill.edu. mckee.com. mdaeng.com. mdcbbs.com. mdi.com. medcom.com. megasys.com. mentat.com. metrolink.com. metron.com. microvation.com. mike.com. mil3.com. mindcraft.com. mitech.com. ml.com. mmsac.com. moore.com. mosis.edu. mps.com. mpx.com. msc.com. mtsu.edu. mun.edu. murphy.com. muskingum.edu. naitc.com. natinst.com. nbi.com. nds.com. nec.com. netagw.com. netlabs.com. network.com. nevada.edu. next.com. nli.com. nls.com. nma.com. northeastern.edu. northrop.com. nrao.edu. nsc.com. nscee.edu. nsi.com. nti.com. nyt.com. nyu.edu. oakland.edu. octopus.com. odb.com. omnet.com. omni.com. omnicomp.com. ora.com. oresoft.com. ori-cal.com. osc.com. osc.edu. oswego.edu. oxford.com. pacer.com. panasonic.com. paradigm.com. paradyne.com. parvenu.com. pbi.com. pcc.com. pcs.com. pcssc.com. pdi.com. pei.com. pepperdine.edu. peregrine.com. pergamon.com. perot.com. persoft.com. pharlap.com. pitt.edu. pooh.com. portal.com. posix.com. prc.com. prepnet.com. prime.com. princeton.edu. proteon.com. proto.com. psg.com. psi.com. psitech.com. psocg.com. psp.com. pti.com. ptl.com. pubnet.com. pw.com. pzbaum.com. qti.com. quad.com. quantum.com. quotron.com. radius.com. rational.com. remtech.com. retix.com. ricoh.com. ripon.edu. rit.edu. rose-hulman.edu. rss.com. rtech.com. sae.com. sage.com. sagepub.com. sc-scicon.com. scarolina.edu. sci.com. sctc.com. sda.com. sei.com. seiden.com. si.com. sia.com. simpact.com. sjsu.edu. sju.edu. skidmore.edu. slb.com. sli.com. slu.edu. slv.com. smc.com. smc.edu. smcm.edu. sobeco.com. softest.com. spacesoft.com. spatial.com. spc.edu. spdcc.com. spectra.com. sprint.com. sri.com. ssc.com. stargate.com. statsci.com. stolaf.edu. sts.com. stx.com. su.com. sumitomo.com. sunrise.com. sunyhscsyr.edu. surfsoft.com. symlab.com. synaptics.com. synoptics.com. synthesis.com. sysadmin.com. syssoft.com. tandy.com. taumet.com. tcc.com. tce.com. techbook.com. tegra.com. tek.com. tellabs.com. tg.com. tgv.com. thyrsus.com. ti.com. tic.com. tmc.com. tmmnet.com. touch.com. trace.com. transarc.com. trav.com. trincoll.edu. tripos.com. tss.com. twinsun.com. twwells.com. tynan.com. ub.com. uc.edu. ucar.edu. uconn.edu. uhcl.edu. uiuc.edu. ultra.com. umb.edu. umd.edu. umiss.edu. umsystem.edu. uncg.edu. uni.edu. unicom.com. unifi.com. unify.com. unisoft.com. unisys.com. unl.edu. unlv.edu. unr.edu. uns.edu. uoregon.edu. upenn.edu. ups.edu. uri.edu. urich.edu. usi.com. utdallas.edu. utoday.com. validgh.com. vcg.com. vcu.edu. verbatim.com. verity.com. viar.com. vicom.com. vicorp.com. viewlogic.com. visix.com. vitalink.com. vsi.com. wallich.com. wang.com. warburg.com. wds.com. wgate.com. williams.edu. wingman.com. wisc.edu. wku.edu. wlu.edu. wpg.com. wright.edu. wrkgrp.com. wrq.com. wrs.com. ww.com. wwc.edu. wyse.com. xanadu.com. xei.com. xerox.com. xidak.com. xopusw.com. xwind.com. zds.com. zipcode.com. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090709232200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 07:18:19 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05419; Fri, 7 Sep 90 07:04:19 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 09:23:22 GMT From: munnari.oz.au!metro!pta!yarra!chris@uunet.uu.net (Chris Jankowski) Organization: Pyramid Technology Corp PL, Melb., Australia Subject: Summary: "The Open Book" by Rose (long) Message-Id: <65198@yarra.oz.au> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Summary of the summary: - This is the best book on OSI there is (now). Original question first: >From RFC1175: > Rose, Marshall T., The Open Book: A Practical Perspective on OSI, 651 > pgs., Prentice Hall, Englewood Cliffs, NJ, 1989. > > This is a comprehensive book about Open Systems Interconnection > (OSI). In particular, this book focuses on the pragmatic aspects > of OSI: what OSI is, how OSI is implemented, and how OSI is > integrated with existing networks. In order to provide this > pragmatic look at OSI the book makes consistent comparisons and > analogies of the OSI pieces with the TCP/IP suite of networking > protocols. > >What do you think about the book? Is it worth buying? >What I am after is a book which would be an equivalent of the Comer's >book on Internet but obout OSI. >How would you compare it with the Comer's book on Internet? >Is it similar in style, depth, objective and clarity? I received about 10 answers. The summary is divided into two parts - 1)general opinions and 2)comparisons with Comer's book. 1). General opinions. --------------------- From Werner H.P. Vogels werner@nikhefk.nikhef.nl: The best thing about mtr's book is that is very realistic about the use of OSI in the real world. It gives credit to the Interenet Suite as well as to the OSI stack and flames on them if nessecary. From: Aled Morris Excellent, absolutely essential. Buy 2 copies, and a copy for each of your friends. Book of the year, in my opinion. From: oliveau@CS.UCLA.EDU (Greg Oliveau) The book is very good. I haven't read the TCP/IP book you mention, but I'm sure that Rose's is as good, especially when complemented with Knightson, Knowles, and Larmouth's 'Standards for Open Systems Interconnection' and another book whose title I can't remember ... From krupczak@secola.Columbia.NCR.COM I just recently read Marshal Rose's book on OSI. It was excellent. It covered all the material that I would have wanted to know about OSI. From: cmorris@ingres.com (Colin Morris) I had three years exposure to OSI before I read the book, so I wasn't exactly using the book to introduce me to the subject. My overall impression was that it was well written but very variable in the depth of treatment given to different subject areas. The book attempts to cover layers 3 thru' 7 but succeeds best at layers 5 and 6:- the treatment of the session and presentation layers (+ASN.1) is most thorough, although there is too much emphasis on "service" as opposed to "protocol". The treatment of network layer structure is ok too. Where the book is weak is in a description of the transport protocol(s) and the various application layer standards. Apart from ACSE, ROSE and RTSE the descriptions are really too flimsy to be of much more than general use. Also lacking is material on Application Layer Structure, although I presume this was due to lack of standards stability in thia area when the book was written. The practical aspects of the book, in particular migration strategies from TCP networks, are an excellent read. I would certainly recommend purchase of the book, particularly for those people who are fairly new to the subject area or who are interested in migration from TCP networks. One final point:- the copy I have has an undue number of irritating typographical errors. Hopefully a new edition of the book will put this right. From: aaron@dragoon.telcom.arizona.edu (Aaron Leonard) Terribly proofread. Information is sometimes excruciatingly dull, which goes with the territory. (I could no more get thru the ASN.1 stuff than _Finnegans Wake_.) Discussion of the OSI model itself is strong. Treatment of issues in addressing and routing was good, tho I think too dismissive of higher-layer gatewaying. What saves the book is Rose's wit and frankness. His "soapboxes", where he offers his Humble Opinion on the usefulness or approriateness of some feature of OSI, is what I consider to be the real substance. Overall impression: If you NEED to learn about OSI NOW, then you MUST read this book as there is no alternative. If not, I'd wait for a year or 2 and see what surfaces. From: kzm@nms.hls.com (Keith McCloghrie) It is an excellent text which covers the spectrum of OSI layers. It is both scholarly and readable; it gives plenty of examples; with 100 hundred pages on the presentation layer, I use it as my ASN.1 textbook. The sections on the applications (FTAN, MHS, etc.) are less detailed (due to lack of space) but are still excellent introductions to those applications. Yet, at the same time, it also provides the author's opinions (within passages each of which is marked in the margin as a "soapbox"). The opinions are at times controversial, which not only makes excellent reading but is thought-provoking in deciding whether you (the reader) agree with the expressed opinions. From: johnan@mchale.ism.isc.com (John Antypas) I'm only one view here, but for myself at least, the Open Book is probably one of the clearest explanations of OSI we've seen yet -- and that's saying quite a lot -- unless you LIKE reading standards documents! Rumor has it that Prentace Hall has another text concerning OSI that I saw at Interop last year, but I have yet to find it. 2.) Comparisons with Comer's Internet book. ------------------------------------------- Werner H.P. Vogels werner@nikhefk.nikhef.nl: It is different from Comer's in the way that it focusses on the upper level's of the OSI reference model. For a good reference on the low levels you should use Tanenbaum's network book second edition. From krupczak@secola.Columbia.NCR.COM After reading Comer's book on TCP/IP and the Internet, Rose's book comapres well. From: aaron@dragoon.telcom.arizona.edu (Aaron Leonard) NOT in the same class as Comer's _Internetworking with TCP/IP_. (Of course, Comer has years of practical experience, real applications, etc. to draw upon, but OSI has none of that.) ;-) From: kzm@nms.hls.com (Keith McCloghrie) Some would say it's better than Comer's. Certainly, OSI is a tougher subject than TCP/IP. I mentioned style and depth above. Don't mistake the use of soapboxes, as a lack of objectivity; anywhere not marked as a "soapbox" is completely objective. As for clarity, there is no better text that I know of about OSI. From Bill Barns: To my kmnowledge, no book comparable to Comer exists for OSI and I doubt that one will be created any time soon. Open Book is about the best available and you might as well buy it (everyone else does), but it isn't as concrete as Comer because in the OSI world, these things are still being figured out. I think that is a limitation we just have to accept for a while yet. And in part, it will probably exist forever, because OSI is rather broader than TCP/IP and thus won't be able to be covered to the same depth in anything like the same number of pages, once we have figured out the right details. This is wild speculation, but I'd estimate a treatment of ALL of the OSI protocols to comparable depth would run about 5000 pages. From: Michael Stein I think it's better than Comer's (but than I know more about TCP/IP than OSI stuff). ---------------------------- Thanks again to all respondents. -m------- Chris Jankowski - Senior Systems Engineer chris@yarra.oz{.au} ---mmm----- Pyramid Technology Corporation Pty. Ltd. fax +61 3 820 0536 -----mmmmm--- 11th Floor, 14 Queens Road tel. +61 3 820 0711 -------mmmmmmm- Melbourne, Victoria, 3004 AUSTRALIA (03) 820 0711 "Knowing how things work is the basis for appreciation, and is thus a source of civilized delight." -- William Safire ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090709350300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 09:46:52 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15678; Fri, 7 Sep 90 09:41:18 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 09:35:03 GMT From: mcsun!ukc!edcastle!tjc@uunet.uu.net (A J Cunningham) Organization: Edinburgh University Colouring Book Software Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <6190@castle.ed.ac.uk> References: <1213@vision.UUCP>, <1940@jura.tcom.stc.co.uk>, <1990Sep6.142623.4559@ibmpcug.co.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Sep6.142623.4559@ibmpcug.co.uk> dylan@ibmpcug.CO.UK (Matthew Farwell) writes: >Sure they haven't got the money, but the JNT have a policy of sticking >to coloured books. This raises the rather interesting question of who exactly the JNT answer to. Every time I hear a discussion on this subject the cries from the punters on the ground who actually use and run computers day-in day-out is for TCP/IP. The JNT says Coloured Books and OSI. Seems to be a bad case of the tail wagging the dog. Still can't complain. Coloured books have been good to me :-) Tony -- Tony Cunningham, Edinburgh University Computing Service. tjc@castle.ed.ac.uk If a man among you has no sin upon his hand Let him throw a stone at me for playing in the band. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090709534800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 04:16:30 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25101; Fri, 7 Sep 90 04:00:44 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 09:53:48 GMT From: eru!hagbard!sunic!mcsun!dfk@bloom-beacon.mit.edu (Daniel Karrenberg) Organization: European Unix systems User Group Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <1795@mcsun.eu.net> References: <4835@tardis.cs.ed.ac.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil jonathan@cs.keele.ac.uk (Jonathan Knight) writes: >From article <1990Sep4.164546@jatz.aarnet.edu.au>, by pte900@jatz.aarnet.edu.au (Peter Elford): High time to put some of the *facts* right: >Fortunately for us, the UKnet gateway isn't the only one. UCL have >a 56Kb link to the USA and offer a guest FTP service which allows us >to transfer files to and from internet connected sites. They also >transfer our mail, and make no charge. This is unlike UKC which >charge for news, and mail, and they also advertise themselves as >a valid route for uk mail. But if you are entitled to use the UCL gateway you can also register with UKC free of charge to you. The JNT pays then. So go ahead and register. Also remember tanstafl, links are never free, the taxpayer pays. >This is a pain as they are trying to fit >a full news feed and email down their 9600 baud line, when there >is a no charge route for email down a 56kb line. There is no capacity problem on that line (yet) and an upgrade to 64kbit/s has been ordered. I know because I manage the "continental" end of it. Also have you ever thought about mail to/from Europe rather than the US? Doesn't it seem unfair to you that European sites must ship their mail to you via the US on intercontinental links *they have to pay for* so that you can use your *free* link. That is what I call selfishness! Incidentally the UCL link to the US is down as I write this. Ever heared about redundancy? It would be nice to set things up with multiple links so that things are redundant.... > There's also the >problem that UKC advertise themselves as a forwarder for the ac.uk >domain, when in fact they only forward mail to uknet members and drop >everything else on the floor. Towards the Internet at large UKC does *not* advertise itself as a mail forwarder for ac.uk apart from one single subdomain (a commercial university as far as I know) which is not entitled to use the UCL gateway. > UCL forward all ac.uk mail regardless of what they are members of. Not true, see above. -- Daniel Karrenberg Future Net: CWI, Amsterdam Oldie Net: mcsun!dfk The Netherlands Because It's There Net: DFK@MCVAX ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090710181400> Received: from pucc.PRINCETON.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 11:23:08 PDT Received: from MSU.BITNET by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 1839; Fri, 07 Sep 90 14:20:19 EDT Received: by MSU (Mailer R2.03B) id 8275; Fri, 07 Sep 90 14:24:11 EDT Date: Fri, 07 Sep 90 14:18:14 EDT From: Doug Nelson <08071TCP%MSU@pucc.PRINCETON.EDU> Reply-To: Doug Nelson Subject: Re: Window Field on SYN Packet To: Jon Allen , "TCP/IP list (plus more)" In-Reply-To: Message of 31 Aug 90 18:57:48 GMT from >Concerning the window field on a SYN packet, what does a value of 0 mean? >Most machines (UNIX) that I have watched on the LANalyzer show a reasonable >value for this field in the SYN packet: 2048, 4096 or something like that: > > UNIX A UNIX B > ======== ====== > SYN 4096 -> > <- SYN ACK 4096 > ACK 4096 -> > >I now am trying the talk to a MVS machine which sends me a SYN packet >with a window size of 0. What does this mean? It certainly confuses my >UNIX machines as they then send a SYN ACK with the window field having >a value of 53000 or so: > > MVS UNIX > ===== ============ > SYN 0 -> > <- SYN ACK 53215 > ACK 0 -> > >Things seem to go downhill rapidly after this point; what is happening here? >I would like to know what machine I need to do some fixing on. My first reaction is that a SYN with a window size of zero can't be answered, since there's no window space in which to send the responding SYN. But you are allowed to send a single byte to probe a zero window; in this case, the responding SYN would be that byte. However, I can't think of any good reason to try opening a connection if you can't offer a reasonably sized window to start with. Now, the Unix system's response could be better, but this is definitely an end case that is dealing with. So I would concentrate on the MVS system. Does the MVS system ever send another ACK with a non-zero window? Doug Nelson Michigan State University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090710234600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 12 Sep 90 16:55:42 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29397; Wed, 12 Sep 90 16:39:09 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 10:23:46 GMT From: eru!hagbard!sunic!mcsun!ukc!mucs!liv-cs!mdb@bloom-beacon.mit.edu Organization: Computer Science, Liverpool University Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <1990Sep7.112346.16949@anduin.cs.liverpool.ac.uk> References: <1990Aug30.091435.1982@ircam.ircam.fr, <6190@vanuata.cs.glasgow.ac.uk>, <1990Sep6.142623.4559@ibmpcug.co.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Sep6.142623.4559@ibmpcug.co.uk>, dylan@ibmpcug.co.uk (Matthew Farwell) writes: > >>b. can you see companies which aren't even on janet because it provides >> security problems wanting to go onto internet? > > It depends. Companies who are terminally afraid of security problems > will never connect to a network like janet. On the other hand, if > connecting up to a network directly, (esp. the internet for > international companies) reduces their costs substantially in terms of > mail, news etc., then they might be persuaded to do so. I know this > particular company would love to be connected directly to janet, and I > suspect I know of a few others too. > There is of course no reason why "sensitive" computers should be connected to the network at all. Most Universities have computers which contain information that they do not wish to become public, and hold it on computers that are not Janet registered (or only for mail), and only allow data transfer when it is controlled from the secure end. I believe this is also how the military deal with their security problems. Calling random addresses does not help, as it is relatively easy for the secure machine to ignore all network calls that it is not expecting. All this does not do a lot for the free interchange of information, which is why the academic networks have proved so successful. One of the major fears of increased commercial involvement in Janet (apart from the obvious "political" ones already discussed) is that companies' paranoia over University hackers will force unwarrented general levels of security on all sites, which will have an adverse effect on th whole ademic community. It really is the responsibility of the host site management to ensure that the internal and external security of its computers is adequate for the purposes for which they are used. Martin Beer, Dept. of Computer Science, University of Liverpool. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090710302300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 06:15:06 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01490; Fri, 7 Sep 90 06:01:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 10:30:23 GMT From: eru!hagbard!sunic!mcsun!hp4nl!charon!piet@bloom-beacon.mit.edu (Piet Beertema) Organization: CWI, Amsterdam Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <2086@charon.cwi.nl> References: , <1990Sep04.045954.25664@comp.vuw.ac.nz>, <1990Sep5.092510.22637@cs.city.ac.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >The JNT in its infinite wisdom (???) has mandated that the ISO >profile used in the UK use TC0 (connection oriented transport >service) while NBS in the USA is encouraging the use of TC4 >(connectionless transport service). >Here we go again ..... That too is the same on most "national research networks" in Europe. I expect the same scenario though as with IP: a natural shift from the current IP to ISO CLNS, perhaps with the exception of X.400 over CONS. -- Piet Beertema, CWI, Amsterdam (piet@cwi.nl) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090711113100> Received: from TGV.COM by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 18:11:38 PDT Date: Fri 7 Sep 90 18:11:31-PDT From: VANCE@TGV.COM (Icarus) Subject: Re: tcp-ip to Decnet To: amdcad!mozart.amd.com!neihart@ucbvax.Berkeley.EDU cc: tcp-ip@nic.ddn.mil Message-ID: <652756291.719087.VANCE@TGV.COM> In-Reply-To: <1990Sep6.153127.4840@mozart.amd.com> Mail-System-Version: Organization: TGV, Incorporated X-Phone: 408/427-4366 (work); 408/427-4265 (fax) X-Address: 603 Mission Street; Santa Cruz, CA 95060 (work) >>I am wondering if shareware is available for tcpip to >>Decnet. The idea being to connect a Sun with an ethernet card >>to a VMS machine. >>Thank you, >>Jay Sparks >>sparks@etch-eshop.berkeley.edu > >uggh! Don't convert between TCP/IP and DECnet, this would >be a mess! Just load Wollongong TCP/IP on your VMS systems, >and make it communicate with TCP/IP to your Sun... (alternatively, >you could load Sun's DECnet/DNI product on your Sun and make >it communicate via DECnet to the VMS system, but I've tried >both approaches and prefer making TCP/IP the common denominator). >The Wollongong TCP/IP product for VMS is a full & clean >implementation of TCP/IP, I can't say the same for Sun's DECnet/DNI >product. There are actually a number of TCP/IP implementations for VMS and at least a couple of DECnet implementations available for Suns. In addition to SunLink/DNI, Thursby Software (Arlington, TX) has a DECnet for SunOS (and a few other UNIXs), and KI Research makes a DECnet and MOP for several UNIX platforms (not sure if that includes SunOS, though). The TCP/IPs for VMS that I am aware of (listed in alphabetical order) are: Board-based: ------------ CMC EXOS from Excelan/Novell Interlan Host-based: ----------- CMU/TEK from Carnegie Mellon University Fusion from Network Research Corporation MultiNet from TGV, Inc. TCPware from Process Software WIN/TCP from The Wollongong Group If you fire off a query to info-vax (probably the best place), I'm sure you can get some recommendations from users as to the good and bad points of each of the above VMS TCP/IPs. -----Stuart ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090711183300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 06:15:14 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01708; Fri, 7 Sep 90 06:04:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 11:18:33 GMT From: eru!hagbard!sunic!mcsun!hp4nl!ruuinf!ruunsa!fysaj!muts@bloom-beacon.mit.edu (Peter Mutsaers /100000) Subject: Reliable connectionless (udp) sockets, who can help? Message-Id: <1453@ruunsa.fys.ruu.nl> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil For a project on distributed computational physics I am working on a small library to allow users easy access to N processes on different computers. Because of the large number of process probably involved, I do want to use connectionless (udp) sockets, but of course I have to implement a protocol to provide reliable data transmission. My question is if someone has more information (methods to implement, or maybe even unix-sources) on this, as I don't like to spend time on something that has already been done. Maybe someone could also indicate to me if I am on the right way: I have the following idea to implement it: - each process has a generally known (address+port) udp socket, which is made asynchronous. - a write operation sends packets to process i on some host, causing an interrupt. In the interrupt the packet is read and put in a buffer (N-1 buffers per host, one for each other process). - a read operation reads from the buffer, and blocks if not enough data is in it. (by doing wait(), and check after a signal (SIGIO) if there is enough data now) Thanks in advance, -- Peter Mutsaers email: muts@fysaj.fys.ruu.nl Rijksuniversiteit Utrecht nmutsaer@ruunsa.fys.ruu.nl Princetonplein 5 tel: (+31)-(0)30-533880 3584 CG Utrecht, Netherlands ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090711493200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 07:00:13 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04302; Fri, 7 Sep 90 06:47:44 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 11:49:32 GMT From: bbn.com!craig@apple.com (Craig Partridge) Organization: Bolt Beranek and Newman Inc., Cambridge MA Subject: Re: Keep-Alive within TCP Message-Id: <59344@bbn.BBN.COM> References: <1990Sep7.002637.6209@ingres.Ingres.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Sep7.002637.6209@ingres.Ingres.COM> cmorris@ws2s.Ingres.COM (Colin Morris) writes: >Having served my four-year sentence in the ISO TP4 world, I've suddenly been >unleashed on TCP. To my great surprise, I understand not all TCP >implementations support "keep-alive". For example, SUN's PC-NFS version >of TCP appears not to. How widespread a "problem" is this? What well-known >implementations don't support this? Why is lack of keep-alives a problem? In principle, unless an application tries to send data, why ping the network to see if the route is up (if the route is down, it may come up again before you send more data)? Craig Partridge Vice-Chairman, I Hate Keep-Alives Association [For those not in the know, Phil Karn is chair of the IHKAA, and Mike Padlipsky is founder, previous-chair, and honorary fellow. We oughta make T-shirts some time... :-)] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090712265700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 13:00:45 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA28009; Fri, 7 Sep 90 12:52:47 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 12:26:57 GMT From: mcsun!ukc!strath-cs!baird!jim@uunet.uu.net (Jim Reid) Organization: Computer Science Dept., Strathclyde Univ., Glasgow, Scotland. Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: References: <1990Aug30.091435.1982@ircam.ircam.fr Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <4847@tardis.cs.ed.ac.uk> anarchy@tardis.cs.ed.ac.uk (Alan Cox) writes: Firstly remember that when Janet was first setup properly they were dealing with a wacky array of bizzare processors, and also that then tcp/ip was abit fof an experiment. Unfortunately they haven't woken up since. Also they have a reasonable argument at the moment about relative efficiency of coloured book and tcp/ip. Discussions on the relative efficiency of network protocols tend to have an air of 'how many angels can dance on the head of a pin' unreality. The Coloured Books may be "more efficient" over JANET when compared with Internet protocols, but how can anyone sensibly compare the two? It's like comparing apples and oranges. First consider the network architectures. CB works on top of X.25 which more or less guarantees a reliable end to end connection. Internet protocols were developed for networks which may drop packets or deliver them out of sequence. [Let's also note that CB only offers connection-oriented services. The Internet world can also provide datagram and multicast.] Thus there's far more to the Internet's transport service (TCP) than JANET's (which is practically non-existant). TCP makes no assumptions about the underlying network whereas JANET leaves nearly everything for X.25 to sort out. Now consider the network interface to the operating system. In most cases, the network protocol processing is not the major part of the system's overheads. Other factors like getting data to/from the network interface, context switching and data copying are more important. I would suggest that TCP/IP offers much less overhead than X.25 here mainly because vendors will have invested much more effort in improving TCP/IP since its usage is likely to be far more widespread than X.25. [You cannot imagine Sun (say) expending the same sort of development effort on CB as they have on TCP/IP.] In some cases, this will happen automatically: almost all UNIX TCP/IP implementations derive from the 4.3 BSD code which is highly tuned. In terms of CPU cycles burned for a connection, X.25 probably needs less than TCP, but X.25 will have a less well tuned interface to the rest of the OS. The end result is that both require pretty much the same amount of system resources. Then, there's the relative merits of the higher-level protocols. In terms of overheads, there's not much difference between NIFTP and FTP. Both have strengths and weaknesses which tend to equalise things. FTP loses out if network ports are a critical resource (they shouldn't be) because it needs two connections; one for data transfer and one for the interactive session. Likewise the number of CPU cycles needed for an X.29/TS29 session won't be significantly different from those needed by a telnet server. Don't forget that telnet is functionally superior to X.29: it offers more for roughly the same overheads. In short, determining the "more efficient" protocol depends on where you measure it. Of course, you then have to weigh up the benefits (or not) of efficiency with the functionality that the protocol offers. Deciding that question is a matter of religion. As to running tcp/ip over janet, any reason you couldn't run slip over a coloured book terminal session ? Yes. The JNT wouldn't like it. What you're proposing is not very efficient: a better (and easier) option is to put IP datagrams inside X.25 frames. That too would upset the JNT since you'd be running something other than CB on JANET. Jim ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090713232900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 10:01:11 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16185; Fri, 7 Sep 90 09:47:38 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 13:23:29 GMT From: mcsun!ukc!edcastle!aiai!richard@uunet.uu.net (Richard Tobin) Organization: AIAI, University of Edinburgh, Scotland Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <3384@skye.ed.ac.uk> References: <6190@vanuata.cs.glasgow.ac.uk>, , <4847@tardis.cs.ed.ac.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <4847@tardis.cs.ed.ac.uk> anarchy@tardis.cs.ed.ac.uk (Alan Cox) writes: >Firstly remember that when Janet was first setup properly they were dealing >with a wacky array of bizzare processors, and also that then tcp/ip was abit >fof an experiment. Perhaps. But it was an experiment that succeeded, unlike Janet. >Also they have a reasonable argument at the moment about relative >efficiency of coloured book and tcp/ip. In terms of bits per second, Janet (and ISO) might win over TCP. But in terms of who's been able to use interactive ftp, I think it's clear which has been more efficient over the last ten years. The supporters of this "efficiency" view have wasted hundreds of hours of my time. I have been told that at least some of the Janet implementers were unable to believe that interactive ftp was useful. Their view was that ftp was the canonical non-interactive task. Anyone accustomed to use of the Internet will realise how misguided this is, and how seriously it has limited software-sharing in the UK. Incidentally, as far as I can tell it's only the lack of a list-directory primitive that makes it impossible to implement interactive ftp using NIFTP. And I believe the York code added such a thing for the "hhtree" command. So it could even have been done without TCP. It might even have been possible to provide a reasonable NIFTP-FTP gateway to the US... -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090713305500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 10:01:26 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16241; Fri, 7 Sep 90 09:48:10 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 13:30:55 GMT From: mcsun!ukc!edcastle!ercm20@uunet.uu.net (Sam Wilson) Organization: Edinburgh University Computing Service Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <6200@castle.ed.ac.uk> References: <1990Aug30.091435.1982@ircam.ircam.fr, <6190@vanuata.cs.glasgow.ac.uk>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In the absence of any response from any of my more competent colleagues, here goes! The JNT has set up an Advisory Group (known as the DOD Advisory Group - not exactly accurate but can anyone provide a better generic term for the entirely of the IP-related protocol set?). We have met once and are due to meet again on Sept 24. Our (largely self imposed) remit is to produce a paper recommending how the JNT might provide a fully supported IP service in the UK. Note that that does not say 'over JANET' or even 'over X.25', though in all probablility it would end up that way. The fact that we recommend anything to the JNT, or that they recommend anything to whoever their masters might be by the time it gets that far, of course provides no guarantee that anything will come of it, but the JNT is aware and doing something. On a historical note: someone mentioned the bizarre hardware that used to be (and in many cases still is) attached to JANET - the JNT's stance on Coloured Book software ensured (very) good connectivity then and still does. The fact that TCP/IP may now have overtaken the Coloured Book stuff shouldn't obscure that fact. On a futuristic note: one of the reasons why the JNT is plugging connection oriented OSI network services (CONS) vs connectionless (CLNS, does the tendency of its proponents to call it 'ISO IP' say anything about *their* prejudices?) is that in the UK we already have a very highly developed X.25 network. Why waste what you've got? Europe is still divided (after all, they effectively invented X.25) and I believe the Japanese are now going for CONS. The outlook is still not clear cut. Sam Wilson Network Services, Edinburgh University Computing Service Disclaimer: the usual - not an official pronouncement! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090713411600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 10:00:43 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16314; Fri, 7 Sep 90 09:49:27 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 13:41:16 GMT From: mcsun!ukc!edcastle!aiai!richard@uunet.uu.net (Richard Tobin) Organization: AIAI, University of Edinburgh, Scotland Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <3385@skye.ed.ac.uk> References: , <1216@vision.UUCP>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article jim@cs.strath.ac.uk (Jim Reid) writes: >[* Calling the box with a JANET and a PSS connection a gateway is a >bit misleading. It doesn't really perform protocol conversion (save >for minimal TS29/X.29 translation), so strictly speaking it's not a >gateway. It's more of a router, simply routing X.25 packets between >the two networks. Does this mean that it should be possible for a Janet site to connect to an international PSS site using FTAM through one of these gateways? If so, how can I do this with ISODE? -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090714591600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 11:31:07 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22795; Fri, 7 Sep 90 11:29:26 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 14:59:16 GMT From: uc!cs.umn.edu!sctc.com!briel@tut.cis.ohio-state.edu (Marc Briel ) Organization: Secure Computing Technology Corporation Subject: Re: "The Open Book" by Rose - your opinions sought Message-Id: <1990Sep7.145916.23593@sctc.com> References: <5724.652665411@nma.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Could someone post the full reference for this book? I would like to look into getting a copy. Thanks, Marc Briel briel@sctc.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009071753.AA20568@ucbvax.Berkeley.EDU] <1990090716010400> From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet routing Europe - USA -} Europe... Message-ID: <9009071753.AA20568@ucbvax.Berkeley.EDU> Date: 7 Sep 90 16:01:04 GMT References: <1990Sep7.052615.1896@brolga.cc.uq.oz.au> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 33 Posted: Fri Sep 7 17:01:04 1990 George, >I bet 90% of all UK universities run BOTH in parallel internally already. about 78.3 % actually, the rest run DECNET more than colour boox. >Anybody taking bets? no - its happening already... >Anybody counting how many "oooooh so naughty" IP tunnels already run? actually, 6 known already to exist... >Anybody asked PSI or any of the other commercial IP networks to cost >a service in the UK? yes, actually, imperial college london...me, and a few others... >Stop fussing. in 10 years it'll seem a joke. Bayonet beat Edison Screw in 10 years time, we'll be arguing over whether 53 bytes in the Wider United States of Europe, or 47 in the Higher Definiton Televisual Empire of the East were the best choice for ATM cell size:-) but seriously, there is a lot of operational stuff to sort out, and ripe people are the right people and are doing it - thats what a lot of the temperature rising is about... have patience, geo. jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009071828.AA22737@ucbvax.Berkeley.EDU] <1990090718285900> From: NELSON%MSU@PUCC.PRINCETON.EDU ("Doug.Nelson") Newsgroups: comp.protocols.tcp-ip Subject: Comments about IBM TCP/IP performance Message-ID: <9009071828.AA22737@ucbvax.Berkeley.EDU> Date: 7 Sep 90 18:28:59 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 141 Posted: Fri Sep 7 19:28:59 1990 X-Unparsable-Date: Friday, 7 September 1990 12:14pm ET A few weeks ago, there were a number of messages exchanged on these lists regarding the performance of IBM's VM TCP/IP. There were a couple inaccuracies in the statements made by the poster (Bill Simpson) which I pointed out privately to him. Since he has not chosen to post these corrections to the list, I will do so. In addition, I'll throw in a little defense for IBM, Spartacus, and Merit. This posting is primarily intended to set the record straight. Let me know if I have failed to do so. -------------- From Bill Simpson (Aug 23, 1990): > Well, I spent about 15 hours benchmarking NIS.NSF.NET against other > machines on the internet, carefully documenting the packet traces, > and passing my observations on to IBM. I did this at my own expense, > as a matter of curiousity, because I thought that the folks who were > sending the messages were "real programmers" who were really interested > in getting it right (a Jay Elinsky was also involved). I'm sure IBM has "real programmers" working on VM TCP/IP. My impressions of the product, in general, are very favorable. I would also assume that IBM would address Bill's reported problems, but it may be necessary to report them through the normal support channels, which Bill has no direct access to. In addition, his packet traces were obtained on a low speed dial-up line, and are likely to be less than complete without some parallel tracing on the Ethernet segment attached to the IBM system in question. > The NIS.NSF.NET hardware was contributed by IBM, and I understand > that the software is the latest IBM release. My benchmark was carefully > conducted for a direct comparison of the TCP/IP implementations, > under the worst possible circumstances to make implementation flaws > stand out clearly. The failures demonstrated are plainly of the > host, and not of the environment. Without seeing the Ethernet packet trace, I doubt if the environment (one-of-a-kind software supporting the Ethernet to async IP gateway, over a network with a maximum packet size of 240 bytes) can be ignored. > As to the "very satisfied" customers, I will point out that MSU has > not yet installed the VM TCP/IP product, even though it came "free" > with other products. And I occasionally read "IBMTCP-L" on bitnet. > 'Nuf said. Hardly. MSU *has* installed the VM TCP/IP product, and is using it as our production IP software on two of our IBM systems. We are planning to do so on our main 3090 system as well, but haven't, strictly due to a lack of staff time, and not to any dissatisfaction with the product. Also, we are running another TCP/IP package (KNET, from Spartacus), which handles our production load at the moment. ------------ On to a message from Bill giving specific throughput results: > CONCLUSION: > IBM-FAL for VM runs at 1/2 the speed of many of its competitors. > It fails to meet several host requirements, not just for TCP/IP > but for FTP and SMTP as well. Under a worst case scenario, Bill may have uncovered a problem with VM TCP/IP and its retransmission algorithms, unless they were doing the best that they can, and a router was discarding packets with a less than optimal algorithm. How many systems do you know that don't do something less than optimal under some worst case scenario? Bill never listed the shortcomings w/r/t host requirements (hopefully, he did for IBM). Maybe he can do that now for the list. > Unfortunately, the only product which I am aware of with worse performance > is Spartacus KNET, also for VM. To defend Spartacus, they have addressed these performance problems in their latest release, by implementing slow start and exponential backoff. This is another update that has been delayed due to lack of staff time. > For the good of the user community, I would recommend to Merit that > the RFC mirror be moved to a more capable machine. How many other users of the Merit anonymous service have experienced problems of this nature? If this is only affecting a single user, I'd hardly see that as a mandate for switching operating systems. -------------- On to a respondent's comments (Hank Nussbacher, Aug 25, 1990): > I think in all fairness, you first need to identify yourself. I have > looked at the Bitearn Nodes database ans was unable to find you listed > as a contact person at MSU. Can you please describe your position at > the MSU computer center. Bill works for an off-campus user of MSU Computer Lab services. I am not aware of any other affiliation between Bill and MSU. > >Let's keep the record straight: the folks at Merit *are* "real programmers > >... > > I cannot attest to how good the people at Merit are, but I can to the > quality of the people at IBM behind the Tcp/Ip package. I'll vouch for the Merit folks as well - they are a competent programming staff. ------------- And a response to Bill's response (dated Aug 27, 1990) to comments from Robert Craig (dated Aug 26, 1990): > > For the record, we run FAL 1.2.1 on a 4381 with a BTI ELC. > > We began with an 8232 and performance *was* abysmal. > > It is much better now... > > For the record, I don't know nor care about the specific *hardware* > which was being compared. (How was I to know, with no host DNS > record, and no announcement in the FTP welcome message.) > The hardware is whatever IBM chose to demonstrate their best to the > internet community. I merely noted the machines which were being > compared, in very little detail, so that others would understand > the basis for comparison (more hops, heavy load, etc). But yet, Bill is willing to make sweeping generalizations about IBM's software, without understanding anything about the hardware. This is one of the reasons I originally ignored his postings, as much as I was able to do so. I don't think IBM placed a 4381 with an 8232 in Ann Arbor to "demonstrate their best". I suspect most of the Internet community is paying much more attention to other IBM contributions to the NSFnet backbone project, such as router performance, network management tools, T1/T3 capabilities, etc., than on a small, ancillary system which maintains some useful network information. > I also have a number of messages saying that they have given up > entirely on NIS.NSF.NET, including one with a much more direct > connection than I have. Also, messages thanking me for the posting.... Have any of these other people gone public? Have they attempted to pass their concerns on to IBM or Merit, and if so, what response did they get? ---------------- Doug Nelson nelson@msu.edu Network Software Manager nelson@msu.bitnet Michigan State University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090718395400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 9 Sep 90 00:04:30 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13262; Sun, 9 Sep 90 00:00:48 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 18:39:54 GMT From: sdd.hp.com!samsung!umich!umeecs!msi-s0.msi.umn.edu!cs.umn.edu!dmshq!com50!bungia!cimcor!atc!sstat!moria!bas@ucsd.edu (Brian Strop) Organization: UNISYS Custom Networks, Eagan MN Subject: TN3270 support on UNIX machines Message-Id: <560@moria.Sp.Unisys.Com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am trying to find out if there is a Unix implementation of TN3270 (RFC 1041 compliant). We have some PC's that support it, and would like to access a Unix box (acting as a server) using TN3270. Thanks in advance. B. Strop -- Brian A. Strop (612) 687-2709 UNISYS bas%moria@atc.sp.unisys.com Network Systems ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090718410400> Received: from bells.cs.ucl.ac.uk by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 09:03:59 PDT Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id ; Fri, 7 Sep 1990 17:01:05 +0100 To: tcp-ip@nic.ddn.mil Cc: G.Michaelson@cc.uq.oz.au Subject: Re: Internet routing Europe - USA -} Europe... In-reply-to: Your message of 07 Sep 90 05:26:15 +0000. <1990Sep7.052615.1896@brolga.cc.uq.oz.au> Date: Fri, 07 Sep 90 17:01:04 +0100 From: Jon Crowcroft George, >I bet 90% of all UK universities run BOTH in parallel internally already. about 78.3 % actually, the rest run DECNET more than colour boox. >Anybody taking bets? no - its happening already... >Anybody counting how many "oooooh so naughty" IP tunnels already run? actually, 6 known already to exist... >Anybody asked PSI or any of the other commercial IP networks to cost >a service in the UK? yes, actually, imperial college london...me, and a few others... >Stop fussing. in 10 years it'll seem a joke. Bayonet beat Edison Screw in 10 years time, we'll be arguing over whether 53 bytes in the Wider United States of Europe, or 47 in the Higher Definiton Televisual Empire of the East were the best choice for ATM cell size:-) but seriously, there is a lot of operational stuff to sort out, and ripe people are the right people and are doing it - thats what a lot of the temperature rising is about... have patience, geo. jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090719063800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 15:00:56 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06264; Fri, 7 Sep 90 14:56:57 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 19:06:38 GMT From: swrinde!zaphod.mps.ohio-state.edu!wuarchive!kuhub.cc.ukans.edu!jian@ucsd.edu Organization: University of Kansas Academic Computing Services Subject: How to detect problems in socket communication? Message-Id: <25465.26e7a96e@kuhub.cc.ukans.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I wrote two programs that talk each other through sockets in UNIX system. Here is the problem: When one of the program dies, how does another program detect the connection is lost due to dead program on the other end? In other words, how does the program know the socket connection is up/down by just check its own socket? Any assistance would be appreciated. Jian Q. Li jian@kuhub.cc.ukans.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090720424000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 15:15:41 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06696; Fri, 7 Sep 90 15:03:44 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 20:42:40 GMT From: mcsun!cernvax!chx400!poole@uunet.uu.net (Simon Poole) Organization: SWITCH Zuerich, Switzerland Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <1990Sep7.204240.9205@chx400.switch.ch> References: , <4847@tardis.cs.ed.ac.uk>, <3384@skye.ed.ac.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <3384@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: .... >In terms of bits per second, Janet (and ISO) might win over TCP. But Do you have any hard data that supports this? I have to yet see any real (== measured) data from an operational network, that would allow this conclusion. -- ------------------------------------------------------------------------ Simon Poole poole@verw.switch.ch / poole@chx400.switch.ch / mcsun!chx400!poole ------------------------------------------------------------------------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090721062400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 16:27:07 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA11495; Fri, 7 Sep 90 16:16:10 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 21:06:24 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!swrinde!emory!hubcap!ncrcae!opusc!animal!ken@ucsd.edu (Ken Sallenger) Organization: Univ. of South Carolina, Columbia Subject: Re: Sun not inventing RPC... Message-Id: <343@opusc.CS.SCAROLINA.EDU> References: <9008311403.AA24690@snow-white.lanl.gov> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9008311403.AA24690@snow-white.lanl.gov> cpw%snow-white@LANL.GOV (C. Philip Wood) writes: => > True enough, but surely the key words are `good' and `better'! => => And who was it that said: => => "'Better' is the enemy of 'good'." The good is the enemy of the best. Bill Wilson, circa 1938 Possibly quoting someone else... Anyone know a definitive reference? -- Ken Sallenger / ken@bigbird.csd.scarolina.edu / +1 803 777-9334 Computer Services Division / 1244 Blossom ST / Columbia, SC 29208 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090806004400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 9 Sep 90 00:04:35 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13315; Sun, 9 Sep 90 00:01:10 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Sep 90 06:00:44 GMT From: shelby!msi-s0.msi.umn.edu!cs.umn.edu!ux.acs!aaron@decwrl.dec.com (Aaron Y.T. Cheung) Organization: University of Minnesota, Academic Computing Services Subject: Examples sought for programming Wollongong's VMS TCP/IP lib. Message-Id: <2209@ux.acs.umn.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi Netlanders, Could someone give me simple examples on programming with TWG's VMS TCP/IP libraries? Or alternatively give me pointers to where (if any) I could anon-ftp some working applications written for VMS on the net. I've permission to create network devices, and I'm using VMS 5.3. I've (ample?) experience with Unix, btw. Thank you very much in advance. /aaron. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090806165800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 21:31:18 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00338; Fri, 7 Sep 90 21:01:29 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Sep 90 06:16:58 GMT From: math.mit.edu!drw@bloom-beacon.mit.edu (Dale R. Worley) Organization: MIT Dept. of Mathematics, Cambridge, MA, USA Subject: Secure mail Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Has anyone out there implemented a filter that does some version of secure mail a la RFC 1113? Please reply by e-mail, since I don't read these newsgroups regularly. Dale drw@math.mit.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090806275800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 23:46:17 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08790; Fri, 7 Sep 90 23:35:26 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Sep 90 06:27:58 GMT From: agate!darkstar!ucscc.UCSC.EDU!haynes@ucbvax.Berkeley.EDU (99700000) Organization: University of California, Santa Cruz CATS Subject: Re: RoboDoc Message-Id: <6706@darkstar.ucsc.edu> References: <9009072311.AA04335@chienne.isi.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil So, does anybody want replies to reports from RoboDoc? I just got a message from him/her/it saying we have one more authoritative name server for ucsc.edu than the root servers think we do. That's because we are bringing up a new one preparatory to decommissioning an old one and have notfied NIC.DDN.MIL to change the root servers accordingly. haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ..ucbvax!ucscc!haynes "Any clod can have the facts, but having opinions is an Art." Charles McCabe, San Francisco Chronicle ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2046@sunic.sunet.se] <1990090811355600> From: bygg@sunic.sunet.se (Johnny Eriksson) Newsgroups: comp.protocols.tcp-ip Subject: Re: "The Open Book" by Rose - your opinions sought Message-ID: <2046@sunic.sunet.se> Date: 8 Sep 90 11:35:56 GMT References: <5724.652665411@nma.com> <1990Sep7.145916.23593@sctc.com> Organization: Royal Institute of Technology, Sweden Lines: 8 Posted: Sat Sep 8 12:35:56 1990 In article <1990Sep7.145916.23593@sctc.com> briel@sctc.com (Marc Briel) writes: > Could someone post the full reference for this book? I would like to look > into getting a copy. Title: The Open Book : A practical persective on OSI Author: Marshall T. Rose ISBN: 0-13-643016-3 Prentice Hall ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090813115800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 12 Sep 90 15:05:57 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21515; Wed, 12 Sep 90 14:52:37 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Sep 90 13:11:58 GMT From: brian@ucsd.edu (Brian Kantor) Organization: The Avant-Garde of the Now, Ltd. Subject: Re: RoboDoc Message-Id: <18612@ucsd.Edu> References: <9009072311.AA04335@chienne.isi.edu>, <6706@darkstar.ucsc.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil There are FIVE authoritative nameservers for UCSD.EDU. You mean we can now list more than two nameservers with the root? Golly! - Brian ----MESSAGE-END---- ----MESSAGE-BEGIN---- [TJR5PK3@xds13.ferranti.com] <1990090815082900> From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.protocols.tcp-ip Subject: Re: RoboDoc Message-ID: Date: 8 Sep 90 15:08:29 GMT References: <9009072311.AA04335@chienne.isi.edu> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 3 Posted: Sat Sep 8 16:08:29 1990 You should probably omit domains that are only served by MX records. For example, hackercorp.com is MXed off uunet.uu.net. Oddly enough, you have checked the former but I saw no mention of the latter. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090815291500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 12 Sep 90 17:54:37 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02738; Wed, 12 Sep 90 17:16:52 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Sep 90 15:29:15 GMT From: eru!hagbard!sunic!mcsun!ukc!mucs!liv-cs!keith@bloom-beacon.mit.edu (Keith Halewood) Organization: Computer Science, Liverpool University Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <1990Sep8.162915.17059@anduin.cs.liverpool.ac.uk> References: <1990Aug30.091435.1982@ircam.ircam.fr, <6190@vanuata.cs.glasgow.ac.uk>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article , jim@cs.strath.ac.uk (Jim Reid) writes: > > Yes. The JNT wouldn't like it. What you're proposing is not very > efficient: a better (and easier) option is to put IP datagrams inside > X.25 frames. That too would upset the JNT since you'd be running > something other than CB on JANET. The JNT appears to like the positively HUGE DECnet that exists over Janet and probably beyond. Unless there is a double standard brewing, the JNT wouldn't be in much of a 'moral' position to stop an IP over X25 service to the Internet for any University or company willing to provide one. Keith ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090817341600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 12 Sep 90 16:54:52 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29311; Wed, 12 Sep 90 16:38:06 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Sep 90 17:34:16 GMT From: eru!hagbard!sunic!mcsun!ukc!slxsys!ibmpcug!dylan@bloom-beacon.mit.edu (Matthew Farwell) Organization: The IBM PC User Group, UK. Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <1990Sep8.173416.29277@ibmpcug.co.uk> References: <1216@vision.UUCP>, <3407@syma.sussex.ac.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <3407@syma.sussex.ac.uk> grahamt@syma.sussex.ac.uk (Graham Thomas) writes: >Now might be a good time to start lobbying, because the way JANET is >organised is probably going to change. JNT head Bob Cooper wants to >set up something like a 'networking association' which would have both >academic and commercial membership. There's a steering group just been >set up to work out the ground rules. Details, with a list of steering >group members, are available in the latest issue of Network News. If >you want a copy, mail JNT-Secretary@uk.ac.jnt (or @jnt.ac.uk, depending >on where you live.) I've done this. Could this be the start of something new + terrific + exciting in the uk? Not if the JNT have anything to do with it. >I have a feeling the TCP/IP question might get raised at the next round >of JANET user group meetings. The next national user group meeting is >in the middle of October. Most regional meetings take place a week or >two earlier. It may be worthwhile finding out who your user rep is and >getting her/him to raise the topic at the next meeting. How do find out this? Is it in the newsletter? Dylan. -- Matthew J Farwell | Email: dylan@ibmpcug.co.uk The IBM PC User Group, PO Box 360,| dylan%ibmpcug.CO.UK@ukc Harrow HA1 4LQ England | ...!uunet!ukc!ibmpcug.co.uk!dylan Phone: +44 81-863-1191 | Sun? Don't they make coffee machines? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090818065200> Received: from farber.harvard.edu by NIC.DDN.MIL with TCP; Sat, 8 Sep 90 19:06:42 PDT Received: by farber.harvard.edu (5.57/Ultrix3.0-C) id AA01032; Sat, 8 Sep 90 22:06:52 EDT Date: Sat, 8 Sep 90 22:06:52 EDT From: ellozy@farber.harvard.edu (Mohamed Ellozy) Message-Id: <9009090206.AA01032@farber.harvard.edu> To: tcp-ip@nic.ddn.mil Subject: Configuration Test Protocol What is the Configuration Test Protocol, a thingie that uses ethernet type 09000 packets? Is it documented in any RFC? How useful is it? Is it a kind of ethernet ping? Many thanks. Mohamed PS: If it is a sort of Ethernet ping, I would suggest calling the program that uses it PENG (Packet EtherNet Groper)! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1990Sep8.194549.25555@usenet.ins.cwru.edu] <1990090819454900> From: david@cwlim.INS.CWRU.Edu Newsgroups: comp.protocols.tcp-ip Subject: Network Monitors Message-ID: <1990Sep8.194549.25555@usenet.ins.cwru.edu> Date: 8 Sep 90 19:45:49 GMT Sender: news@usenet.ins.cwru.edu Reply-To: david@cwlim.INS.CWRU.Edu () Organization: Case Western Reserve Univ. Cleveland, Ohio, (USA) Lines: 21 Posted: Sat Sep 8 20:45:49 1990 I have a network here on campus which ranges from TCP/IP to Novell and I am interested in monitoring and recording the usage and load statistics. I would like to see what the network load is at different times of the day and what machines monopolize the networks time. I would also like to know what services are being used, but I don't believe that can be done at this level. With this information I would be able to determine if a particular branch of my network should be isolated by another bridge, for example. It would also aid in allowing me to improve the over-all performance by distributing the network load to machines throughout the network. I have tools such as the Network General Sniffer, but it doesn't have the memory or power to accommodate such a large volume of data and give the information I need. Does anyone anywhere know of such a package or combination of packages that would be able to do this? Thanks for any help.... Dave -- david@po.cwru.edu * Eagle * David Nerenberg 73107,177 Compuserve * Computers * Information Network Services NY: H-516-751-6344 * Electronics * Case Western Reserve University W-516-751-8111 * Sound & Stage * W-216-368-2982 H-216-754-2043 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990090909011900> Received: from sccgate.scc.com by NIC.DDN.MIL with TCP; Sun, 9 Sep 90 12:49:29 PDT Received: by sccgate.scc.com (5.61/1.34) id AA07827; Sun, 9 Sep 90 15:41:19 -0400 Date: Sun, 9 Sep 90 15:41:19 -0400 From: enger@sccgate.scc.com (Robert M. Enger) Message-Id: <9009091941.AA07827@sccgate.scc.com> To: RoboDoc@venera.isi.edu, namedroppers@nic.ddn.mil Subject: Re: Robodoc Cc: tcp-ip@nic.ddn.mil Dear Robodoc: 1) Does Robodoc check that network name information is present in the DNS so that we can "stamp out the hosts file in our lifetime"? 2) What is the implication of a domain being omitted from your report? Bob Enger ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091001183400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 12 Sep 90 19:37:22 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA14963; Wed, 12 Sep 90 19:30:39 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 90 01:18:34 GMT From: comp.vuw.ac.nz!virtue!canterbury.ac.nz!elec097@uunet.uu.net Organization: University of Canterbury Subject: CMU-TEK LPD_SERVER Message-Id: <1990Sep10.094426.9125@canterbury.ac.nz> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We are running CMU-TEK 6.4 under VMS 5.3-1. When we 'lpr' from a PC running NCSA Telnet the VAX refuses a connection after about 3 or 4 LPD servers are running. If we wait until some of these die off the VAX again allows connections. Any ideas? ******************************************************************************* * * * ____ * * cosmik.debris@elec.canterbury.ac.nz O=(VVVV) * * psi%(64)30000012::cosmik.debris / \VV/ * * / / * * ~ ~ * * " I owe money therefore I am. " * ******************************************************************************* ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091001201600> Received: from ftp.com by NIC.DDN.MIL with TCP; Mon, 10 Sep 90 06:40:25 PDT Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA21535; Mon, 10 Sep 90 09:40:16 -0500 Date: Mon, 10 Sep 90 09:40:16 -0500 Message-Id: <9009101440.AA21535@ftp.com> To: sdd.hp.com!samsung!umich!umeecs!msi-s0.msi.umn.edu!cs.umn.edu!dmshq!com50!bungia!cimcor!atc!sstat!moria!bas@ucsd.edu (Brian Strop) Subject: Re: TN3270 support on UNIX machines From: jbvb@ftp.com (James B. Van Bokkelen) Reply-To: jbvb@ftp.com Cc: tcp-ip@nic.ddn.mil Sender: jbvb@ftp.com Repository: babyoil.ftp.com Originating-Client: plug.ftp.com I am trying to find out if there is a Unix implementation of TN3270 (RFC 1041 compliant).... RFC 1041 does not describe what the world presently implements as "tn3270". I do not know of any implememtations, and current discussion on the "tn3270" mailing list seems likely to evolve in a different direction. RFC 1123 touches on current "tn3270" practice, but there is no definitive write-up. We have some PC's that support it, and would like to access a Unix box (acting as a server) using TN3270.... The only "tn3270" servers I know of are for IBM mainframes (either the mainframe or some sort of gateway box has an IP address). Mapping the block-mode EBCDIC data stream to Unix conventions is a large project. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091003012700> Received: from CORNELLC.cit.cornell.edu by NIC.DDN.MIL with TCP; Mon, 10 Sep 90 05:05:37 PDT Received: from LOCAL.DOMAIN.EDU by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3866; Mon, 10 Sep 90 08:01:35 EDT Received: by * (Mailer R2.03B) id 0426; Mon, 10 Sep 90 08:04:37 EST Date: Mon, 10 Sep 90 08:01:27 EST From: bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu> Subject: Keep-Alive within TCP To: tcp-ip@nic.ddn.mil >>if TCP appears not to. How widespread a "problem" is this? What well-known > > Why is lack of keep-alives a problem? In principle, unless an application >tries to send data, why ping the network to see if the route is up (if the >route is down, it may come up again before you send more data)? > >Craig Partridge >Vice-Chairman, I Hate Keep-Alives Association > >[For those not in the know, Phil Karn is chair of the IHKAA, and Mike >Padlipsky is founder, previous-chair, and honorary fellow. We oughta >make T-shirts some time... :-)] Actually, I'm surprised Phil didn't jump in here and answer this one first. Must be on vacation or something... bill gunshannon (closet member IHKAA) bill gunshannon 702WFG@SCRVMSYS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091003143300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 12 Sep 90 21:01:22 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21113; Wed, 12 Sep 90 20:45:14 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 90 03:14:33 GMT From: logicon.com!Makey@nosc.mil (Jeff Makey) Organization: Logicon, Inc., San Diego, California Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <764@logicon.com> References: <6190@vanuata.cs.glasgow.ac.uk>, <1990Sep6.142623.4559@ibmpcug.co.uk>, <1990Sep7.112346.16949@anduin.cs.liverpool.ac.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Sep7.112346.16949@anduin.cs.liverpool.ac.uk> mdb@anduin.cs.liverpool.ac.uk writes: >There is of course no reason why "sensitive" computers should be connected >to the network at all. Nonsense. "Sensitive" computers should be connected to networks for the same reasons as other computers. However, most computers with sensitive information lack the proper access controls to allow them to be connected to a network in a secure manner. That's why conscientious administrators of such systems choose to keep them isolated. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091003425100> Received: from SH.CS.NET by NIC.DDN.MIL with TCP; Mon, 10 Sep 90 16:19:03 PDT Received: by SH.CS.NET id aa10229; 10 Sep 90 10:35 EDT To: Colin Morris cc: tcp-ip@nic.ddn.mil Subject: Re: Keep-Alive within TCP In-reply-to: Your message of 07 Sep 90 00:26:37 +0000. <1990Sep7.002637.6209@ingres.Ingres.COM> Date: Mon, 10 Sep 90 10:22:51 -0400 From: George Williams Please note the following in regards your query: () "keep-alive" is used rather loosly in the TCP/UNIX environment. ( Correct and enlighten me as appropriate.) 1. I have seen it used to describe an option under UNIX to determine whether or and for how long to "re-try" a client initiated connection request to a server process. This is usually done under the covers, i.e. transparent, to the requesting process. 2. Some vendors implement it, again option defined, to periodically poll the other end of an established connection in order to solicit a response indicating "am still here alive" from a peer TCP transport. This feature has proven useful to applications designed for paralellism or some degree of concurrency relative to higher level processing requirements. Given the above it would be enlightening to one such as myself if you would elucidate as to which if any of the above context you are using the term "keepalive", i.e. could help define the implementation specific context of your query. In the case of (1) above it has proven beneficial and helped to simply interface level programming logic requirements to have this feature, based on prior development ( subjective ) work in this area. As far as (2) , again, it proved to be a useful feature; in lieu of a timeout parameter on most UNIX implementations for network read and write calls, in avoiding "hung" processes and in the area of process management. In distributed compute environments determination of 'when' a process/service/application is 'really' alive can be a problem depending on what OS/CPU combination a process is executing under, just to mention one consideration. I won't mention any vendor by name ( some of observed problems in this area may have been corrected, even as we speak ), but some OS's have been noted to max out or approach 100% CPU utilization as a result of process or application level loops for retrys on network open/read/write failure attempts. Granted that this is the indication of a poor design on the application level, network software developers have to take the broad(er) perspective that programmers don't want to know the detail of underlying protocols much the same as we don't necessarily want to get into application specific implementation details. () OSI TP0 and TP4 specify connectionless and connection oriented transport service by way of architectural definition. It comes as no surprise that the connection oriented service would be rigid in the service and protocol specification for the know state of an end to end or peer connection. Rationale, one would assume,include some if not all of the aforementioned. Not to mention the tradeoff beteeen end to end service association versus simple protocol, and I assume infrequent, exchange of "keep-alive" information.( I stand to be corrected here, but it's sound logical to me so I'm probably way off base ,SMILE. ) You can probably make a better statement in this area than I am prepared to. TCP, ostensibly, takes the least-common-denominator path to solution from all have been able to determine, based on implementation experience. In other words by design ( there is no application or session layer ) the path that offers the least protocol overhead appears to have been chosen for support of end to end transport level connectivity. It looks like ( and I make the statement with a limited frame of historical reference in this area ) "the right decision" based on the engineering requirement(s) at that time. () I have seen vendors that don't or hadn't prior to this year implemented this feature as described for both case (1) and (2) above. So I have always considered it an option that was product (vendor) driven. Work may be ongoing by some a Working Group to make it a protocol extension. George Williams BBN,STC ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091009140300> Received: from timbuk.CRAY.COM by NIC.DDN.MIL with TCP; Mon, 10 Sep 90 15:34:58 PDT Received: from berserkly.cray.com by timbuk.CRAY.COM (4.1/SMI4.0 CRAY1.1) id AA29479; Mon, 10 Sep 90 17:34:47 CDT Received: by berserkly.cray.com id AA19783; 5.64/CRI-3.10; Mon, 10 Sep 90 17:34:03 -0500 Date: Mon, 10 Sep 90 17:34:03 -0500 From: dab@berserkly.cray.com (David Borman) Message-Id: <9009102234.AA19783@berserkly.cray.com> To: att!devildog!jrallen@ucbvax.Berkeley.EDU, NELSON%MSU.EDU@pucc.PRINCETON.EDU Subject: Re: Window Field on SYN Packet Cc: tcp-ip@nic.ddn.mil > >Concerning the window field on a SYN packet, what does a value of 0 mean? > >Most machines (UNIX) that I have watched on the LANalyzer show a reasonable > >value for this field in the SYN packet: 2048, 4096 or something like that: > > > > UNIX A UNIX B > > ======== ====== > > SYN 4096 -> > > <- SYN ACK 4096 > > ACK 4096 -> > > > >I now am trying the talk to a MVS machine which sends me a SYN packet > >with a window size of 0. What does this mean? It certainly confuses my > >UNIX machines as they then send a SYN ACK with the window field having > >a value of 53000 or so: > > > > MVS UNIX > > ===== ============ > > SYN 0 -> > > <- SYN ACK 53215 > > ACK 0 -> > > > >Things seem to go downhill rapidly after this point; what is happening here? > >I would like to know what machine I need to do some fixing on. > > My first reaction is that a SYN with a window size of zero can't be > answered, since there's no window space in which to send the responding > SYN. But you are allowed to send a single byte to probe a zero window; > in this case, the responding SYN would be that byte. However, I can't > think of any good reason to try opening a connection if you can't offer > a reasonably sized window to start with. > > Now, the Unix system's response could be better, but this is definitely > an end case that is dealing with. So I would concentrate on the MVS system. > > Does the MVS system ever send another ACK with a non-zero window? > Actually, the window field in a TCP packet is an offset from the ack field, and the ack field is only valid if the ACK bit is set, and the ACK bit is never set in the initial SYN packet, so the ack field is meaningless, and hence the window field is also meaningless. However, it would seem logical that the window value in the initial SYN packet would indicate the number of data octets that the sender is willing to accept from whatever initial sequence number the receiver chooses to start with. But this is not what RFC-793 says, so you can't depend on it. The real question is after the MVS sends the "ACK 0", does it ever send a packet in which it actually opens the window? And does the UNIX side really have a window of 53215? 4.2BSD had a problem with the window field, but it was the reverse of this. 4.2BSD would belive the window value in the initial SYN, and when connecting to a TAC it was getting garbage in the window field in the initial SYN. This was usually some large number, and the 4.2 would overrun the TACs buffers. The TAC would just throw away the extra data, causing the 4.2 system to do lots of retransmits. The bottom line is that these three initial packets look just fine, the only potential problem is if the 53215 byte window being offered by the UNIX machine is wrong, and it really has a much smaller buffer. Then you could have the MVS system trying to send data that the UNIX system would throw away, causing the MVS to have to go into retransmit mode, or a later packet sent from the UNIX side with the correct window size would cause the MVS to see a shriking window that it might not deal with properly. But in either case, the main problem is on the UNIX side, not the MVS side. (Shrinking windows are a bad idea...). -David Borman, dab@cray.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091011155600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 13 Sep 90 03:22:16 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27836; Thu, 13 Sep 90 03:15:30 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 90 11:15:56 GMT From: mcsun!ukc!icdoc!citycs!sb380@uunet.uu.net (Andy Holt) Organization: City University, London Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <1990Sep10.111556.6724@cs.city.ac.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Sorry, in my previous posting I incorrectly used the notation TC0 and TC4 when I should have used TP0 (CONS) and TP4 (CLNS) Further, this system - not my normal "home" - gave an incorrect "reply-to" line. Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091012050600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 12 Sep 90 23:52:29 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07146; Wed, 12 Sep 90 23:42:54 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 90 12:05:06 GMT From: mcsun!ukc!edcastle!aiai!richard@uunet.uu.net (Richard Tobin) Organization: AIAI, University of Edinburgh, Scotland Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <3390@skye.ed.ac.uk> References: <4847@tardis.cs.ed.ac.uk>, <3384@skye.ed.ac.uk>, <1990Sep7.204240.9205@chx400.switch.ch> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >>In terms of bits per second, Janet (and ISO) might win over TCP. But >Do you have any hard data that supports this? Certainly not. I have no idea whether it's true. The point I was trying to make was that *even if* it's true, I'd be better off with TCP. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009110019.AA25376@ucbvax.Berkeley.EDU] <1990091013012700> From: 702WFG@SCRVMSYS.BITNET (bill gunshannon) Newsgroups: comp.protocols.tcp-ip Subject: Keep-Alive within TCP Message-ID: <9009110019.AA25376@ucbvax.Berkeley.EDU> Date: 10 Sep 90 13:01:27 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 23 Posted: Mon Sep 10 14:01:27 1990 >>if TCP appears not to. How widespread a "problem" is this? What well-known > > Why is lack of keep-alives a problem? In principle, unless an application >tries to send data, why ping the network to see if the route is up (if the >route is down, it may come up again before you send more data)? > >Craig Partridge >Vice-Chairman, I Hate Keep-Alives Association > >[For those not in the know, Phil Karn is chair of the IHKAA, and Mike >Padlipsky is founder, previous-chair, and honorary fellow. We oughta >make T-shirts some time... :-)] Actually, I'm surprised Phil didn't jump in here and answer this one first. Must be on vacation or something... bill gunshannon (closet member IHKAA) bill gunshannon 702WFG@SCRVMSYS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009102345.AA23979@ucbvax.Berkeley.EDU] <1990091013060300> From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) Newsgroups: comp.protocols.tcp-ip Subject: Re: Reliable connectionless (udp) sockets, who can help? Message-ID: <9009102345.AA23979@ucbvax.Berkeley.EDU> Date: 10 Sep 90 13:06:03 GMT References: <1453@ruunsa.fys.ruu.nl> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 47 Posted: Mon Sep 10 14:06:03 1990 >For a project on distributed computational physics I am >working on a small library to allow users easy access to >N processes on different computers. >Maybe someone could also indicate to me if I am on the right way: >I have the following idea to implement it: >- each process has a generally known (address+port) udp socket, > which is made asynchronous. >- a write operation sends packets to process i on some host, > causing an interrupt. In the interrupt the packet is read > and put in a buffer (N-1 buffers per host, one for each other process). >- a read operation reads from the buffer, and blocks if not enough > data is in it. (by doing wait(), and > check after a signal (SIGIO) > if there is enough data now) Peter, i did this a coupla years ago while prototyping a multicast transport protocol. Your main problem is reliability - you have to re-implement all the TCP-isms that are in the kernel- since thats what i was interested in, it didnt matter to me - it might irk you. if you have a taste for it, get VMTP and IP multicast code from stanford, and install, then you have it all done for you (you do rpc's or transactions with process groups). alternatively, you can hack TCP to open a connection to well known port + broadcast address (yuck) or just install multicast IP, and change this to well known port + multicast addr and as SYN-ACKs come back, bind multiple connections - you then have the socket to user space decision - do you return n lots of data from n connections on each read, have multiple accepts + fds, or ioctl's to de-mux each connection etc etc - someone somewhere in california close to the heart of a certain unix did some of this, but is hibernating or something i believe:-). having said that, what you are suggesting will sorta work some of the time... its about time someone had a good remote multi-procedure call package jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091013142300> Received: from mcsun.EU.net by NIC.DDN.MIL with TCP; Mon, 10 Sep 90 05:28:43 PDT Received: by mcsun.EU.net via EUnet; Mon, 10 Sep 90 14:28:52 +0200 (MET) Received: from castle.ed.ac.uk by kestrel.Ukc.AC.UK via Janet (UKC CAMEL FTP) id aa23138; 10 Sep 90 13:19 BST Received: from spider.co.uk by castle.ed.ac.uk id aa00513; 10 Sep 90 13:14 WET DST Received: by widow.spider.co.uk; Mon, 10 Sep 90 13:14:25 +0100 Message-Id: <20085.9009101214@orbweb.spider.co.uk> Received: by orbweb.spider.co.uk; Mon, 10 Sep 90 13:14:24 BST From: Keith Mitchell Date: Mon, 10 Sep 90 13:14:23 WET X-Mailer: Mail User's Shell (7 0 3 12/22/89) To: tcp-ip@nic.ddn.mil Subject: Re: Internet routing Europe - USA -} Europe... Cc: nick@spider.co.uk, briant@spider.co.uk, mahmoodn@spider.co.uk In: > Message-ID: <1990Sep7.052615.1896@brolga.cc.uq.oz.au> > > hung out to dry. Nobody with any sense give a DAMN. Religious warfare > is for celtic and rangers fans and the Jihad mob only. George is right. Getting bogged down in the relative merits of Coloured Book vs TCP/IP protocol stacks and applications is a waste of time. Until the glorious (?) day when OSI is universal, there is room for all. This is the approach taken in places like Australia and Scandanavia, and I think it is very unfortunate that the UK does not take this catholic approach to networking. Are we the only country in the world where use of TCP/IP is *banned* on our national research network ? Just because we drive on the left-hand side is not a reason for outlawing non-right-hand drive vehicles from British roads. Even though we want IP over JANET, this does not mean we want to scrap the existing setup. This would be daft when Spider are vendors of both Coloured Book and TCP/IP products. Desire for IP connectivity comes not from the intrinsic properties of any protocols, but from two practical details of their use: - Then only way you can can application-transparent international connectivity NOW is to use TCP/IP. - There are lot more people in the world using TCP/IP than Coloured books. So, lets keep Coloured Books on JANET, fine. But can we get at the existing international networking infrastructure too, please, without having to use UUCP (commercial) or go through an overloaded non-transparent gateway (academic). It's not like we aren't prepared to pay our way - international communications are very important to Spider's business, and many other UK firms too. All we want to do is share the costs a bit. Seems that being prepared to do this ourselves is the best thing we can do if the powers that be won't let us in. Let's hope the JNT's "DoD" working group makes things happen in months, rather than sometime. It's difficult for Spider to influence the JNT when we are not members of JANET, but then it would be a lot easier to justify the expense of joining if we got TCP/IP connectivity as well. Setting up Coloured Book software on our own network when everything else is TCP/IP is a hassle. Talking about powers that be, UKUUG (who have UKC run UKNET for them) have been very quiet about all this. Are we going to have to set up a UKIPUG ? What Brian says about hooking up now is serious. You want a pilot IP link over the PDN, ask me. To prove how serious: > Anybody asked PSI or any of the other commercial IP networks to cost > a service in the UK? I'm asking. I've already enquired of UUNET, would PSI or anyone else care to comment ? Disclaimer time - the above, of course, represents what I think Spider policy should be rather than what it necessarily is. Keith Mitchell Spider Systems Ltd. Spider Systems Inc. Spider Park 12 New England Executive Park Stanwell Street Burlington Edinburgh, Scotland MA 01803 Phone: +44 31-554 9424 +1 (617) 270-3510 Fax: +44 31-554 0649 keith@spider.co.uk keith%spider.co.uk@uunet.uu.net ...!uunet!ukc!spider!keith zspz01%uk.ac.ed.castle@nsfnet-relay.ac.uk P.S. (:-) As someone who lives and works in Leith, let me assure you "The Proclaimers" come not from here, but sunny Fife, just across the river. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009110037.AA26096@ucbvax.Berkeley.EDU] <1990091013233600> From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet routing Europe - USA -} Europe... Message-ID: <9009110037.AA26096@ucbvax.Berkeley.EDU> Date: 10 Sep 90 13:23:36 GMT References: <9009072143.AA06850@braden.isi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 42 Posted: Mon Sep 10 14:23:36 1990 >Actually, this is a highly questionable view of history. I worked at >UCL in 1981-82, when the forerunner of JANET was getting going (I wrote >the first terminal gateway at UCL, between the TCP/IP-based Satnet >connection and the JNT X.25 network). I doubt that there was any stage >where the JNT-sponsored academic X.25 kit delivered better service than >TCP/IP was delivering to universities in the US. The often-expressed Bob, Several years ago, when the Internet was under the congestive collapse that was only saved by certain very clever people fixing TCP, I believe that JANET was offering a comparable service:-) The state of recent UK sadness can be seen from the continual tired comparisons of FTP and NIFTP, ignorance of BFTP, failure to mention NFS, AFS, RFS etc; The non-existence of a networked window system in the UK; the absence of a remote execution (not job submission) protocol in colour book, the failure to design and install a decent distributed name service, etc etc; the absurd problems of setting up 40 digit NSAPs for an X.25 on LAN service, instead of using an elegant scheme like ARP (still waiting for 10030)... the lack of a CONS routing scheme... meanwhile, the Internet bounds ahead with full management, multi-media conferencing experiments, the White Pages pilot and so on - but hold! we are putting up X.[4|5]00 as pilot services, there is a small bit of hope; we have a model for X Windows on OSI; someone is working on FTAM file access regime in the kernel somewhere (i hope) what has this to do with Europe? not a lot, but - well, I guess if NSF and the European countries carrying UK - Europe traffic on their leased lines started accounting and billing the JNT, they might effect a change - ULCC (the actual UK-US gateway, *not* UCL) had some software to do this... of course, this is all modulo policy based routing and accounting research. jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009110311.AA01898@ucbvax.Berkeley.EDU] <1990091014225100> From: gwilliam@SH.CS.NET (George Williams) Newsgroups: comp.protocols.tcp-ip Subject: Re: Keep-Alive within TCP Message-ID: <9009110311.AA01898@ucbvax.Berkeley.EDU> Date: 10 Sep 90 14:22:51 GMT References: <1990Sep7.002637.6209@ingres.Ingres.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 77 Posted: Mon Sep 10 15:22:51 1990 Please note the following in regards your query: () "keep-alive" is used rather loosly in the TCP/UNIX environment. ( Correct and enlighten me as appropriate.) 1. I have seen it used to describe an option under UNIX to determine whether or and for how long to "re-try" a client initiated connection request to a server process. This is usually done under the covers, i.e. transparent, to the requesting process. 2. Some vendors implement it, again option defined, to periodically poll the other end of an established connection in order to solicit a response indicating "am still here alive" from a peer TCP transport. This feature has proven useful to applications designed for paralellism or some degree of concurrency relative to higher level processing requirements. Given the above it would be enlightening to one such as myself if you would elucidate as to which if any of the above context you are using the term "keepalive", i.e. could help define the implementation specific context of your query. In the case of (1) above it has proven beneficial and helped to simply interface level programming logic requirements to have this feature, based on prior development ( subjective ) work in this area. As far as (2) , again, it proved to be a useful feature; in lieu of a timeout parameter on most UNIX implementations for network read and write calls, in avoiding "hung" processes and in the area of process management. In distributed compute environments determination of 'when' a process/service/application is 'really' alive can be a problem depending on what OS/CPU combination a process is executing under, just to mention one consideration. I won't mention any vendor by name ( some of observed problems in this area may have been corrected, even as we speak ), but some OS's have been noted to max out or approach 100% CPU utilization as a result of process or application level loops for retrys on network open/read/write failure attempts. Granted that this is the indication of a poor design on the application level, network software developers have to take the broad(er) perspective that programmers don't want to know the detail of underlying protocols much the same as we don't necessarily want to get into application specific implementation details. () OSI TP0 and TP4 specify connectionless and connection oriented transport service by way of architectural definition. It comes as no surprise that the connection oriented service would be rigid in the service and protocol specification for the know state of an end to end or peer connection. Rationale, one would assume,include some if not all of the aforementioned. Not to mention the tradeoff beteeen end to end service association versus simple protocol, and I assume infrequent, exchange of "keep-alive" information.( I stand to be corrected here, but it's sound logical to me so I'm probably way off base ,SMILE. ) You can probably make a better statement in this area than I am prepared to. TCP, ostensibly, takes the least-common-denominator path to solution from all have been able to determine, based on implementation experience. In other words by design ( there is no application or session layer ) the path that offers the least protocol overhead appears to have been chosen for support of end to end transport level connectivity. It looks like ( and I make the statement with a limited frame of historical reference in this area ) "the right decision" based on the engineering requirement(s) at that time. () I have seen vendors that don't or hadn't prior to this year implemented this feature as described for both case (1) and (2) above. So I have always considered it an option that was product (vendor) driven. Work may be ongoing by some a Working Group to make it a protocol extension. George Williams BBN,STC ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091015060300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 12 Sep 90 17:06:20 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01364; Wed, 12 Sep 90 17:01:46 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 90 15:06:03 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!ub!acsu.buffalo.edu@hplabs.hpl.hp.com (abdi m oday) Organization: SUNY Buffalo Subject: Reading IP packets via sockets Message-Id: <35425@eerie.acsu.Buffalo.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi folks. I need to write a user program that reads all ip packets on the local LAN. I think I can do this using NIT (network Interface Tap) but since this code is ultimately going to run on a MVME-147 board running VxWorks, I'd like to do this with raw sockets since I know they support sockets. My question is, can raw sockets be used to read all packets ? Will the IP layer pass things to the socket even though the packet might not be addressed to the socket, or to the machine itself ( I intend to use the "promisc mode"). I'd appreciate any help with this. thanks -Abdi oday@acsu.buffalo.edu (716) 631-6848 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091015063700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 12 Sep 90 23:56:04 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07502; Wed, 12 Sep 90 23:47:15 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 90 15:06:37 GMT From: fernwood!hercules!frisbee.cisco.com!allan@uunet.uu.net (Allan Leinwand) Organization: cisco Systems, Inc. - Menlo Park, CA Subject: Re: Network Monitors Message-Id: <20835@hercules.csl.sri.com> References: <1990Sep8.194549.25555@usenet.ins.cwru.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Sep8.194549.25555@usenet.ins.cwru.edu>, david@cwlim.INS.CWRU.Edu writes: |> I have a network here on campus which ranges from TCP/IP to Novell and I am |> interested in monitoring and recording the usage and load statistics. I |> would like to see what the network load is at different times of the day and |> what machines monopolize the networks time. Hello Dave, We here at cisco Systems have a network management package that can help you find the load on various devices throughout the network and store this information in a database. Of course, you must have an SNMP agent on all the devices which you care to monitor. The package is called "NetCentral" and currently runs on a Sun. !> I would also like to know what |> services are being used, but I don't believe that can be done at this level. This is a bit trickier, but provided this information is available via SNMP, NetCentral can do this for you. If this information cannot be retrieved via SNMP, the most efficient way to do this may be using your Sniffer. HP has a protocol analyzer out, called the HP4972, which has software which does this function for you. Perhaps you just need the right software for the Sniffer. |> I have tools such as the |> Network General Sniffer, but it doesn't have the memory or power to accommodate |> such a large volume of data and give the information I need. Does anyone |> anywhere know of such a package or combination of packages that would |> be able to do this? Thanks for any help.... Again, our NetCentral may have the power you need, It can run on a SparcStation and this should give you the ummph in processing you desire. Further, it's relational database can store as much data as you want. Please contact us at customer-service@cisco.com or 1-415-326-1941 Thanks, Allan Leinwand cisco Systems leinwand@cisco.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091015304200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 13 Sep 90 03:56:31 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01005; Thu, 13 Sep 90 03:49:13 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 90 15:30:42 GMT From: sun-barr!cs.utexas.edu!ut-emx!!spurgeon@apple.com (Charles E. Spurgeon) Organization: UTexas Computation Center, Austin, Texas Subject: Re: Configuration Test Protocol Message-Id: <37036@ut-emx> References: <9009090206.AA01032@farber.harvard.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9009090206.AA01032@farber.harvard.edu> ellozy@FARBER.HARVARD.EDU (Mohamed Ellozy) writes: >What is the Configuration Test Protocol, a thingie that uses ethernet type >09000 packets? Is it documented in any RFC? How useful is it? Is it a >kind of ethernet ping? > Yes, it is a sort of Ethernet ping. You'll find it documented in the DIX Ethernet spec, Version 2.0 (access info below). Basically it allows Ethernet controllers to reply to test packets, and to forward test packets on to another controller. The Test Protocol was dropped from the IEEE802.3 spec, and you will not find much support for it today. The major exception is DEC. DEC has included support for this protocol in many of their Ethernet controllers. Here's how to get a copy of the DIX spec: Ethernet Local Area Network Specification Version 2.0. November, 1982 Digital Equipment Corporation, Intel Corporation, Xerox Corporation, 103 pps. $32.00. DEC Part Number: AA-K759B-TK. Available from DEC-Direct by calling 800-344-4825. Charles Spurgeon | | UTnet Network Information Center | spurgeon@emx.utexas.edu | University of Texas at Austin | ...!cs.utexas.edu!ut-emx!spurgeon| ------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091015460300> Received: from bells.cs.ucl.ac.uk by NIC.DDN.MIL with TCP; Mon, 10 Sep 90 06:06:28 PDT Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id ; Mon, 10 Sep 1990 14:06:06 +0100 To: muts@fysaj.fys.ruu.nl cc: tcp-ip@nic.ddn.mil Subject: Re: Reliable connectionless (udp) sockets, who can help? In-reply-to: Your message of 07 Sep 90 11:18:33 +0000. <1453@ruunsa.fys.ruu.nl> Date: Mon, 10 Sep 90 14:06:03 +0100 From: Jon Crowcroft >For a project on distributed computational physics I am >working on a small library to allow users easy access to >N processes on different computers. >Maybe someone could also indicate to me if I am on the right way: >I have the following idea to implement it: >- each process has a generally known (address+port) udp socket, > which is made asynchronous. >- a write operation sends packets to process i on some host, > causing an interrupt. In the interrupt the packet is read > and put in a buffer (N-1 buffers per host, one for each other process). >- a read operation reads from the buffer, and blocks if not enough > data is in it. (by doing wait(), and > check after a signal (SIGIO) > if there is enough data now) Peter, i did this a coupla years ago while prototyping a multicast transport protocol. Your main problem is reliability - you have to re-implement all the TCP-isms that are in the kernel- since thats what i was interested in, it didnt matter to me - it might irk you. if you have a taste for it, get VMTP and IP multicast code from stanford, and install, then you have it all done for you (you do rpc's or transactions with process groups). alternatively, you can hack TCP to open a connection to well known port + broadcast address (yuck) or just install multicast IP, and change this to well known port + multicast addr and as SYN-ACKs come back, bind multiple connections - you then have the socket to user space decision - do you return n lots of data from n connections on each read, have multiple accepts + fds, or ioctl's to de-mux each connection etc etc - someone somewhere in california close to the heart of a certain unix did some of this, but is hibernating or something i believe:-). having said that, what you are suggesting will sorta work some of the time... its about time someone had a good remote multi-procedure call package jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091016033600> Received: from bells.cs.ucl.ac.uk by NIC.DDN.MIL with TCP; Mon, 10 Sep 90 06:24:16 PDT Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id ; Mon, 10 Sep 1990 14:23:42 +0100 To: braden@venera.isi.edu cc: tcp-ip@nic.ddn.mil Subject: Re: Internet routing Europe - USA -} Europe... In-reply-to: Your message of Fri, 07 Sep 90 14:43:11 -0700. <9009072143.AA06850@braden.isi.edu> Date: Mon, 10 Sep 90 14:23:36 +0100 From: Jon Crowcroft >Actually, this is a highly questionable view of history. I worked at >UCL in 1981-82, when the forerunner of JANET was getting going (I wrote >the first terminal gateway at UCL, between the TCP/IP-based Satnet >connection and the JNT X.25 network). I doubt that there was any stage >where the JNT-sponsored academic X.25 kit delivered better service than >TCP/IP was delivering to universities in the US. The often-expressed Bob, Several years ago, when the Internet was under the congestive collapse that was only saved by certain very clever people fixing TCP, I believe that JANET was offering a comparable service:-) The state of recent UK sadness can be seen from the continual tired comparisons of FTP and NIFTP, ignorance of BFTP, failure to mention NFS, AFS, RFS etc; The non-existence of a networked window system in the UK; the absence of a remote execution (not job submission) protocol in colour book, the failure to design and install a decent distributed name service, etc etc; the absurd problems of setting up 40 digit NSAPs for an X.25 on LAN service, instead of using an elegant scheme like ARP (still waiting for 10030)... the lack of a CONS routing scheme... meanwhile, the Internet bounds ahead with full management, multi-media conferencing experiments, the White Pages pilot and so on - but hold! we are putting up X.[4|5]00 as pilot services, there is a small bit of hope; we have a model for X Windows on OSI; someone is working on FTAM file access regime in the kernel somewhere (i hope) what has this to do with Europe? not a lot, but - well, I guess if NSF and the European countries carrying UK - Europe traffic on their leased lines started accounting and billing the JNT, they might effect a change - ULCC (the actual UK-US gateway, *not* UCL) had some software to do this... of course, this is all modulo policy based routing and accounting research. jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091016133600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 13 Sep 90 02:09:39 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AB20676; Thu, 13 Sep 90 01:59:20 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 90 16:13:36 GMT From: eru!hagbard!sunic!mcsun!ukc!cam-cl!news@bloom-beacon.mit.edu (Piete Brooks) Organization: U of Cambridge Comp Lab, UK Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <1990Sep10.161336.27915@cl.cam.ac.uk> References: <4835@tardis.cs.ed.ac.uk>, <1795@mcsun.eu.net> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil [ % = dfk@eu.net, > = pte900@jatz.aarnet.edu.au, * = pb@cl.cam.ac.uk ] % High time to put some of the *facts* right: > Fortunately for us, the UKnet gateway isn't the only one. UCL have > a 56Kb link to the USA and offer a guest FTP service which allows us > to transfer files to and from internet connected sites. They also > transfer our mail, and make no charge. This is unlike UKC which > charge for news, and mail, and they also advertise themselves as > a valid route for uk mail. % But if you are entitled to use the UCL gateway you can also register with % UKC free of charge to you. The JNT pays then. So go ahead and register. % Also remember tanstafl, links are never free, the taxpayer pays. * If you are keen on getting facts right, note that the above is not true. * The gateway is NOT at UCL (University College London) but at ULCC * (University of London Computer Centre) * UK AC sites are split in two: Some are "CB" and others are not. * The Computer Board will only pay the UKC charges of SOME sites. * The best rule I have got for the horses mouths are that if the machine was * bought by the CB, they'll pay the UKNET charges. * This means that if two machines within our department (about 10 meters apart) * both take news (as they may soon do) we will have to pay UKC twice -- one * from the pockets of the department and once from the pocket of the CB. * Smart people at ukc :-) ! * Note that links may not be free, but traffic may be ! % Also have you ever thought about mail to/from Europe rather than the US? * What do we have IXI for ?? [ :-( ] % Doesn't it seem unfair to you that European sites must ship their mail to % you via the US on intercontinental links *they have to pay for* so that you % can use your *free* link. That is what I call selfishness! * No problem -- get European sites to call the UK [ :-) ] While I'm here, I shall point out that I get a lot higher bandwidth fetching a file from the states or europe directly to my workstation (using FTAM over JANET to a (free to me) FTAM/ftp gateway) than I do from UCL (using NIFTP). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091016320800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 13 Sep 90 00:22:00 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA09787; Thu, 13 Sep 90 00:07:43 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 90 16:32:08 GMT From: zephyr.ens.tek.com!orca.wv.tek.com!vsg.com!mike@uunet.uu.net (Mike Witt) Organization: Tektronix Visual Systems Group, Wilsonville, OR Subject: Broadcast File Transfer Protocol? Message-Id: <8673@orca.wv.tek.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm looking for pointers to any work that has been done on any kind of broadcast/multicast file transfer protocol. If any one has such a pointer, could you please mail it to me at: mike@vsg.com Thanks, Mike Witt PS, if you feel strongly that adding another broadcast protocol would be a terrible idea under any circumstances, and you feel like having a conversation about this, please send me mail also. Thanks. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091017121800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 13 Sep 90 00:06:57 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08372; Wed, 12 Sep 90 23:56:57 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 90 17:12:18 GMT From: orc!orc.olivetti.com!giamma@decwrl.dec.com Organization: Olivetti Research California (Menlo Park) Subject: tcp/ip performance Message-Id: <49312@ricerca.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am interested to some tests for doing performance evaluation of TCP/IP, any suggestions ? Gianmaria Clerici giamma@orc.olivetti.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091020372700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 12 Sep 90 19:39:55 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15372; Wed, 12 Sep 90 19:35:22 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 90 20:37:27 GMT From: manta!gutman@nosc.mil (Lewis M. Gutman) Organization: Naval Ocean Systems Center, San Diego Subject: internet routing protocols- general questions... Message-Id: <1200@manta.NOSC.MIL> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil For a project I am working on, I need to gather some material on the types of gateway protocols running over TCP/IP based internets. I started with Comer's _Internetworking with TCP/IP_ and found the material detailed and well written. For about two weeks, I thought I had the subject wired. However, after seeing recently published RFCs on new routing protocols and still other routing protocols in the works (i.e., in the IETF: directory of nic.ddn.mil and other places), I wonder how well Comer's book actually describes the reality of TCP/IP internets today. The new routing protocols I'm talking about are OSPF, IGRP, ANSI IS-IS, BGP, Open Distance Vector IGP, whatever the protocol to be developed by the Open Systems Routing WG is to be called, and maybe some others I don't know about. In an attempt to understand the context of all these routing protocols, I'd like to ask people on the net several questions. First of all, is there any document which lists all of the protocols, describes them briefly, shows where they fit in (e.g., is the protocol a proprietary IGP?, is it a proposed EGP replacement?, is it intended for NSFNET backbone?, etc.), tells what the planned interactions are between the protocols, and states what the policy is regarding the acceptance and planned usage of these protocols? I'd also like to know who is driving the work. Secondly, which of the new protocols are actually running out there today? I work in a UNIX environment so I know that there are many RIPs and EGPs (gated) running on BSD UNIX machines out there. I don't really have a sense about the other protocols. I'm interested in finding out the proportion of various gateways running each protocol on TCP/IP based internets, if such information is available. Thirdly, I am interested in hearing about experiences with gateways in campus and smaller sized networks running two or more protocols. Is interoperation possible? How difficult is it transition to new equipment/protocols? In lieu of comprehensive documents on the subject, I'd be happy to put together the responses I receive and summarize to the net (if there is any interest, of course). Thanks in advance to everybody who responds. Lew Gutman Naval Ocean Systems Center, Code 854 San Diego, CA. 92152 Disclaimer: The government is not responsible when I ask a lot of questions. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2113@mtecv2.mty.itesm.mx] <1990091023434000> From: alfonso@mtecv2.mty.itesm.mx Newsgroups: comp.sys.mac.comm,comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Help with SUN RPC installation Message-ID: <2113@mtecv2.mty.itesm.mx> Date: 10 Sep 90 23:43:40 GMT Sender: root@mtecv2.mty.itesm.mx Reply-To: alfonso@mtecv2.mty.itesm.mx Lines: 18 Posted: Tue Sep 11 00:43:40 1990 Has anybody installed the public domain RPC libraries from SUN in your system? I have copied the sources from SUN and I don't know what to do to install'em. My purpose is to install this routines in a Macintosh, but as I suppose, nobody or almost nobody has done this, so I ask for some help about the installation process in UNIX, because in that way I could figure out what to do in the Mac. I've got about fifty different "shar" files, some "uu" files and some "c" files, besides a "tar" file. I would like to know what are the next steps: Do I have to decompress some files? Run a binary file to do something?, etc. I guess I have made myself clear about my problems. Any help from you will be welcomed Thanks in advance. Alfonso. P. S.: I would like you to send a copy of your reply to David, who works with me, his account in the machine is "davidmtz". ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091101263000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 14 Sep 90 12:32:19 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA28026; Fri, 14 Sep 90 01:52:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 01:26:30 GMT From: excelan!jlt@ames.arc.nasa.gov (Jeff Turner) Organization: Excelan, Inc., San Jose, Califonia Subject: Re: Network Monitors Message-Id: <1859@excelan.COM> References: <1990Sep8.194549.25555@usenet.ins.cwru.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Sep8.194549.25555@usenet.ins.cwru.edu> david@cwlim.INS.CWRU.Edu () writes: >I have a network here on campus which ranges from TCP/IP to Novell and I am >interested in monitoring and recording the usage and load statistics. I >would like to see what the network load is at different times of the day and >what machines monopolize the networks time. I would also like to know what >services are being used, but I don't believe that can be done at this level. >With this information I would be able to determine if a particular branch of >my network should be isolated by another bridge, for example. It would also >aid in allowing me to improve the over-all performance by distributing the >network load to machines throughout the network. I have tools such as the >Network General Sniffer, but it doesn't have the memory or power to accommodate >such a large volume of data and give the information I need. Does anyone >anywhere know of such a package or combination of packages that would >be able to do this? Thanks for any help.... Dave, Perhaps, you would like to consider a remote network monitor device such as Novell's LANtern. In general, network monitors perform tasks such as: * monitoring vital statistics * sending alarms when vital stat thresholds are exceeded * sending alarms when common problems are detected * gathering long-term trending information * providing station and conversation analysis The LANtern relays this information back to a central SNMP-based network management console. It was to designed to accomodate any size network and be independent of the protocols used on the network. The LANtern works with practically any SNMP-based network management console but you may want to consider consoles that provide a nice user interface for the product. You may also want to check out network monitoring products from companies such as Micro Technology, ACC, HP, and TEC. For more information on our products you can call 1-800-243-8526. > Dave >-- >david@po.cwru.edu * Eagle * David Nerenberg >73107,177 Compuserve * Computers * Information Network Services >NY: H-516-751-6344 * Electronics * Case Western Reserve University > W-516-751-8111 * Sound & Stage * W-216-368-2982 H-216-754-2043 Jeff Turner Novell, Inc. (408) 473-8287 email: jlt@novell.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091104215100> Received: from CORNELLC.cit.cornell.edu by NIC.DDN.MIL with TCP; Tue, 11 Sep 90 09:05:23 PDT Received: from LOCAL.DOMAIN.EDU by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3567; Tue, 11 Sep 90 11:41:20 EDT Received: by * (Mailer R2.03B) id 9538; Tue, 11 Sep 90 09:25:54 EST Date: Tue, 11 Sep 90 09:21:51 EST From: bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu> Subject: SynOptics compatability To: tcp-ip@nic.ddn.mil I have a question for any SynOptics users out there. I currently have a building wired using SynOptics 1000's and UTP. We plan to extend the network to other building on Campus and wanted to do it using Fiber. Does anyone know if the Fiber connections on a SynOptics 1000 (a 201-ST board) are compatable with the newer 3000 series concentrators?? If not, I can still get around it, but the configuration will change considerably. Can anyone shed any light on this subject? Is SynOptics on the net anywhere? bill gunshannon 702WFG@SCRVMSYS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091105404100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 13 Sep 90 00:22:11 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA09923; Thu, 13 Sep 90 00:08:46 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 05:40:41 GMT From: crash!jburnes@nosc.mil (Jim Burnes) Organization: Crash TimeSharing, El Cajon, CA Subject: Looking for PD tcp/ip/ftp/telnet/etc Message-Id: <4350@crash.cts.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi All! I'm looking for high quality PD TCP/IP software FTP/TELNET and berkeley sockets stuff for both Xenix/386 and MSDOS machines. If this sounds somewhat ingorant ..then so be it. What are the names of these programs and where can they be found (what machines). I have pc pursuit and shell access to a usenet unix box. I would also like to get access to sources if possible. Any help appreciated. Jim Burnes ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091107510000> Received: from ccmail.sunysb.edu (nova.cc.sunysb.edu) by NIC.DDN.MIL with TCP; Tue, 11 Sep 90 09:22:43 PDT Date: Tue, 11 Sep 90 11:51 EDT From: SMANTHANI@ccmail.sunysb.edu Subject: Re: Ethernet configuration problem To: TCP-IP@NIC.DDN.mil Message-id: <371B1490C6DF201A59@ccmail.sunysb.edu> X-Organization: State University of New York, Stony Brook, NY X-Envelope-to: TCP-IP@NIC.DDN.mil X-VMS-To: IN%"TCP-IP@NIC.DDN.mil" Enabling the Heart Beat sinal of the Transciver (H4000) might solve the problem. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091109172700> Received: from CORNELLC.cit.cornell.edu by NIC.DDN.MIL with TCP; Tue, 11 Sep 90 11:56:37 PDT Received: from LOCAL.DOMAIN.EDU by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 4404; Tue, 11 Sep 90 14:57:34 EDT Received: by * (Mailer R2.03B) id 4795; Tue, 11 Sep 90 14:23:07 EST Date: Tue, 11 Sep 90 14:17:27 EST From: bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu> Subject: Looking for (a working) NFS for VMS To: tcp-ip@nic.ddn.mil Well, we've been bitten once more by Wollongong's TCPIP for VMS. I have found out today that their NFS cannot understand enough of the UNIX file commands to even be usable. (No chown, No permissions, No link()) Does anyone know if any of the other TCPIP implemntations support NFS?? And does it work well enough to be used with a UNIX system?? And of course can it used a shared ethernet interface on the VAX?? I still have to support LAT as well. Any help?? bill gunshannon 702WFG@SCRVMSYS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091109452500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 13 Sep 90 02:09:19 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21038; Thu, 13 Sep 90 02:02:33 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 09:45:25 GMT From: eru!hagbard!sunic!mcsun!ukc!warwick!cudep@bloom-beacon.mit.edu (Ian Dickinson) Organization: Team Limpid's Death Mollusc From Hell - The Good Old Boys Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <1990Sep11.094525.22181@warwick.ac.uk> References: <1940@jura.tcom.stc.co.uk>, <1990Sep6.142623.4559@ibmpcug.co.uk>, <6190@castle.ed.ac.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <6190@castle.ed.ac.uk> tjc@castle.ed.ac.uk (A J Cunningham) writes: > This raises the rather interesting question of who exactly the >JNT answer to. Every time I hear a discussion on this subject the cries >from the punters on the ground who actually use and run computers day-in >day-out is for TCP/IP. The JNT says Coloured Books and OSI. Seems to be >a bad case of the tail wagging the dog. Still can't complain. Coloured >books have been good to me :-) The JNT don't answer to the users - they're civil servants. I don't really give a toss what we run, so long as it works reliably and lets us interconnect. OSI may do this eventually. Maybe not. But it's a hell of a lot better than DECNet. Ciao, -- \/ato. Ian Dickinson. GNU's not got BSE. Cut Cerebus some slack! vato@cu.warwick.ac.uk Plinth. vato@tardis.cs.ed.ac.uk Sabeq. gdd046@cck.cov.ac.uk "Nuke me tender, nuke me good!" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091109562500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 13 Sep 90 02:09:11 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21064; Thu, 13 Sep 90 02:02:55 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 09:56:25 GMT From: eru!hagbard!sunic!mcsun!ukc!warwick!cudep@bloom-beacon.mit.edu (Ian Dickinson) Organization: Team Limpid's Death Mollusc From Hell - The Good Old Boys Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <1990Sep11.095625.22364@warwick.ac.uk> References: , <4847@tardis.cs.ed.ac.uk>, <3384@skye.ed.ac.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <3384@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >In terms of bits per second, Janet (and ISO) might win over TCP. But >in terms of who's been able to use interactive ftp, I think it's clear >which has been more efficient over the last ten years. The supporters >of this "efficiency" view have wasted hundreds of hours of my time. There's an interactive ftam with isode, including ftam-ftp converters for both directions (internet ftp btw.) Just because CB doesn't have it, doesn't mean that OSI won't. All we need now is a fast implementation or a good excuse to just use IP. 1/2 :-) Cheers, -- \/ato. Ian Dickinson. GNU's not got BSE. Cut Cerebus some slack! vato@cu.warwick.ac.uk Plinth. vato@tardis.cs.ed.ac.uk Sabeq. gdd046@cck.cov.ac.uk "Nuke me tender, nuke me good!" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091111212700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 13 Sep 90 02:09:03 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21079; Thu, 13 Sep 90 02:03:02 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 11:21:27 GMT From: eru!hagbard!sunic!mcsun!ukc!pyrltd!trevan!trevor@bloom-beacon.mit.edu Organization: Trevan Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <1990Sep11.112127.24481@trevan.uucp> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Please can anyone tell me: 1) Are there any sites in the other than UCL which have an Internet connection to the USA. 2) Are there any sites in Europe or the USA which are willing to provide a connection by Trailblazer, ISDN or X25. 3) Anyone interested in setting up a domain in the UK. 4) Are there any problems with using dialup connections or do we need a backbone of private wires. regards trevor trevor@trevan.co.uk -- regards trevor trevor@trevan.co.uk ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091114005700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 12 Sep 90 18:56:44 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10774; Wed, 12 Sep 90 18:44:04 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 14:00:57 GMT From: uop!milton!ogicse!dali.cs.montana.edu!uakari.primate.wisc.edu!samsung!munnari.oz.au!sao.aarnet.edu.au!gih900%@ucdavis.ucdavis.edu (Geoff Huston) Organization: AARNet Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <1990Sep11.090057.1@sao.aarnet.edu.au> References: <1990Aug30.091435.1982@ircam.ircam.fr, <1990Sep5.092510.22637@cs.city.ac.uk>, <13713@ulysses.att.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <13713@ulysses.att.com>, smb@ulysses.att.com (Steven Bellovin) writes: > In article <1990Sep5.092510.22637@cs.city.ac.uk>, sb380@cs.city.ac.uk (Andy Holt) writes: >> The JNT in its infinite wisdom (???) has mandated that the ISO >> profile used in the UK use TC0 (connection oriented transport >> service) while NBS in the USA is encouraging the use of TC4 >> (connectionless transport service). > > Without commenting on the wisdom (or the lack thereof) of JANET, the > real problem here is OSI. They've designed a protocol stack with > mutually incompatible options, thus preventing communication between > parties who've made different decisions. What's the point of a > standard that's incompatible with itself? A lot - If the people who go to ISO standards meetings get paid by the hour then there's at least another two decades of employment in store for them in attempting to come to grips with the astonishingly large mess that they're creating. (I was about to wack in a smiley until I realized that its no joke) Geoff Huston ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009112007.AA08799@ucbvax.Berkeley.EDU] <1990091114215100> From: 702WFG@SCRVMSYS.BITNET (bill gunshannon) Newsgroups: comp.protocols.tcp-ip Subject: SynOptics compatability Message-ID: <9009112007.AA08799@ucbvax.Berkeley.EDU> Date: 11 Sep 90 14:21:51 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Posted: Tue Sep 11 15:21:51 1990 I have a question for any SynOptics users out there. I currently have a building wired using SynOptics 1000's and UTP. We plan to extend the network to other building on Campus and wanted to do it using Fiber. Does anyone know if the Fiber connections on a SynOptics 1000 (a 201-ST board) are compatable with the newer 3000 series concentrators?? If not, I can still get around it, but the configuration will change considerably. Can anyone shed any light on this subject? Is SynOptics on the net anywhere? bill gunshannon 702WFG@SCRVMSYS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091116330900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 13 Sep 90 03:38:51 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29679; Thu, 13 Sep 90 03:36:24 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 16:33:09 GMT From: naitc!naitc!karl@uunet.uu.net (Karl Denninger) Organization: A.C. Nielsen Bannockburn, IL Subject: "Strange Telnet Option 242" on ISC 2.2 Message-Id: <1990Sep11.163309.721@naitc.uucp> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi everyone, We're using NCSA Telnet with ISC 2.2, and seeing a rather odd thing from the package. The number "2" is coming up once in a while, accompanied (on the message screen) by the message "Strange Telnet Option 242". Any ideas why only the ISC machines would do this, and not any of our network of Sun Workstations? This didn't happen under 2.0.2's TCP/IP... We'd really like to stop it from happening! Any assistance appreciated! -- Karl Denninger AC Nielsen kdenning@ksun.naitc.com (708) 317-3285 Disclaimer: Contents represent opinions of the author; I do not speak for AC Nielsen on Usenet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091117441100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 13 Sep 90 03:56:45 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00905; Thu, 13 Sep 90 03:48:24 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 17:44:11 GMT From: sgi!artibee%noangel.wpd.sgi.com@ucbvax.Berkeley.EDU (Mary Artibee) Subject: Re: tcp/ip performance Message-Id: <69032@sgi.sgi.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil > I am interested to some tests for doing performance > evaluation of TCP/IP, any suggestions ? You might consider "ttcp"... >From vjs@rhyolite.wpd.sgi.com Sat May 12 19:04:05 1990 (Vernon Schryver) Organization: Silicon Graphics, Inc., Mountain View, CA Newsgroups: comp.protocols.tcp-ip Subject: Re: "ttcp" program Ttcp is handy for tuning a TCP or UDP implementation. Versions of ttcp can be found in sgi/src on sgi.sgi.com, currently 192.48.153.1. ttcp.c.brl is the most recent BRL version I've seen. Ttcp.shar is from last August. Ttcp.c is our current understanding of what was acceptable to BRL. It includes controls for buffer alignment and other things. By default it is a file transfer program, needing '-s' to make it generate and sink data as a test program. I think there are also versions available from BRL, perhaps on brl.mil. They are probably newer than sgi:.../ttcp.c.brl. Ttcp has never appeared in comp.sources.unix, although I understood from the moderator that it would someday. If you buy a Silicon Graphics "IRIS", you'll find ttcp.c among other example and test programs in /usr/people/4Dgifts. There was some hassle with the port number. The original port 2000 conflicted with a certain solar window manager, currently the default window manager for SGI. BRL and SGI checked with the Net Gods about getting an official port number for ttcp, but failed. Be careful to understand the numbers people give you. Not long ago a vendor trying to sell stuff gave me what I thought were some good numbers. A few weeks later they happened to mention to some of my colleagues that the numbers were obtained by summing some simultaneous tests. It is as they say, "lies, damn lies, and benchmarks." Vernon Schryver Silicon Graphics vjs@sgi.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [CMM.0.88.653076397.ingea@svarte.ifi.uio.no] <1990091118071400> From: ingea@IFI.UIO.NO (Inge Arnesen) Newsgroups: comp.protocols.tcp-ip Subject: LAN Manager and UNIX Message-ID: Date: 11 Sep 90 18:07:14 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 43 Posted: Tue Sep 11 19:07:14 1990 X-Unparsable-Date: Tue, 11 Sep 90 20:06:37 MET DST Today, years after the release of OS/2 and LAN Manager, som people believe that LAN Manager will become _the_ network standard for interoperability between DOS, OS/2 and UNIX boxes, and also take a big chunk of the UNIX to UNIX market within the next 3 years! This is suppose to happen on all levels: - Named pipes will replace TLI & sockets. RPC-libs will be based on named pipes. - File sharing will replace NFS (and RFS :-). - Printer sharing will replace the braindead UNIX remote lpd. - LAN Manager autentication will become the standard security and autentication system. The event that is supposed to trigger this drastic change is the release of the portable LAN Manager server (LMX) which is due in Desember. I must admit that LAN Manager have superior solutions to some the solutions available on UNIX today, but I can't see how LM can get a grip on the UNIX market this late. LM is a something that grew out of the MS DOS (and later OS/2) world, which is not regarded as kosher among UNIX people, and it does not offer any great leap in functionality compared to what we have on UNIX today. I would like arguments for and against LM as a standard taking marked shares OUTSIDE the DOS / OS/2 environments, and I welcome both well founded arguments as well as statements like : "I don't like the feel of the API..". Have any UNIX vendors said how they will relate to LM ? If only Microsoft and PC SW vendors support LM, LM will probably remain in the PC world....... Inge (BoB) { ingea@ifi.uio.no } ========================================================================= == Inge Arnesen, University of Oslo, Norway. == == == ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009112234.AA15069@ucbvax.Berkeley.EDU] <1990091119172700> From: 702WFG@SCRVMSYS.BITNET (bill gunshannon) Newsgroups: comp.protocols.tcp-ip Subject: Looking for (a working) NFS for VMS Message-ID: <9009112234.AA15069@ucbvax.Berkeley.EDU> Date: 11 Sep 90 19:17:27 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 Posted: Tue Sep 11 20:17:27 1990 Well, we've been bitten once more by Wollongong's TCPIP for VMS. I have found out today that their NFS cannot understand enough of the UNIX file commands to even be usable. (No chown, No permissions, No link()) Does anyone know if any of the other TCPIP implemntations support NFS?? And does it work well enough to be used with a UNIX system?? And of course can it used a shared ethernet interface on the VAX?? I still have to support LAT as well. Any help?? bill gunshannon 702WFG@SCRVMSYS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4862@tardis.cs.ed.ac.uk] <1990091119303700> From: anarchy@tardis.cs.ed.ac.uk (Alan Cox) Newsgroups: uk.misc,eunet.followup,comp.protocols.tcp-ip Subject: Re: Internet routing Europe - USA -} Europe... Message-ID: <4862@tardis.cs.ed.ac.uk> Date: 11 Sep 90 19:30:37 GMT References: <1990Aug30.091435.1982@ircam.ircam.fr <6190@vanuata.cs.glasgow.ac.uk> <4847@tardis.cs.ed.ac.uk> Reply-To: anarchy@tardis.cs.ed.ac.uk (Alan Cox) Organization: UNIX Anarchy, Edinburgh University Lines: 21 Posted: Tue Sep 11 20:30:37 1990 In article jim@cs.strath.ac.uk (Jim Reid) writes: >> >> As to running tcp/ip over janet, any reason you couldn't run slip over a >> coloured book terminal session ? >> >Yes. The JNT wouldn't like it. What you're proposing is not very >efficient: a better (and easier) option is to put IP datagrams inside >X.25 frames. That too would upset the JNT since you'd be running >something other than CB on JANET. > > Jim Oh dear.. does that mean they don't like people running kermit over janet lines, after all kermit is a file transfer protocol and it's not in the coloured books (not even the yellow and purple spotty one 8-)), does seem to be a certain amount of a red tape factory running here. Maybe the planned shakeup of the steering committes of janet is a good thing. -------------------------------------------------------------------------------- Everything is hereby disclaimed.. if a superbeing can give me this for a working universe, then I can give him back buggy software too. -------------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091120281500> Received: from cheetah.ca.psi.com by NIC.DDN.MIL with TCP; Wed, 12 Sep 90 08:10:07 PDT Received: from localhost by cheetah.ca.psi.com at Wed, 12 Sep 90 08:08:17 -0700. (5.61.14/XIDA-1.2.8.34) id AA11388 for tcp-ip@nic.ddn.mil via SMTP To: bushell@hawk.nstn.ns.ca Cc: tcp-ip@nic.ddn.mil Reply-To: tcp-ip@nic.ddn.mil Subject: Re: SNMP info and TCP/IP test programs In-Reply-To: Your message of Wed, 12 Sep 90 09:13:50 +0000. <1340@hawk.nstn.ns.ca> Date: Wed, 12 Sep 90 08:08:15 -0700 Message-Id: <11384.653152095@cheetah.ca.psi.com> From: Marshall Rose Send a note to snmp-request@nisc.psi.net and ask to be added to the snmp list. /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23417:Sep1122:38:4990@kramden.acf.nyu.edu] <1990091122384900> From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.protocols.tcp-ip Subject: sockets vs. streams archive Message-ID: <23417:Sep1122:38:4990@kramden.acf.nyu.edu> Date: 11 Sep 90 22:38:49 GMT Organization: IR Lines: 8 Posted: Tue Sep 11 23:38:49 1990 Since the ``sockets vs. streams'' discussion generated quite a bit of material that should be useful for future implementors, I have archived it and made it available via anonymous ftp to stealth.acf.nyu.edu, or 128.122.128.22. The unedited articles are in pub/socketstream. This should be easier than searching your local tcp-ip archive... ---Dan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091207350000> Received: from NRI.Reston.VA.US by NIC.DDN.MIL with TCP; Wed, 12 Sep 90 10:48:45 PDT Received: from mcimail.com by NRI.NRI.Reston.VA.US id ac07117; 12 Sep 90 13:39 EDT Date: Wed, 12 Sep 90 12:35 EST From: Bob Stine <0004219666@mcimail.com> To: Tom Bushell Cc: tcp ip Subject: Re: SNMP info and TCP/IP test programs Message-Id: <91900912173519/0004219666NB4EM@mcimail.com> Check RFC 1147 for availability info on ttcp. - Bob Stine Applied Cybernetics, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1055@syacus.acus.oz] <1990091208212200> From: andrewf@syacus.acus.oz (Andrew Friedman) Newsgroups: comp.protocols.tcp-ip Subject: Telnet vs. X.29 (Was: Internet routing Europe - USA -} Europe...) Summary: Religion war starter Keywords: Telnet X.29 Message-ID: <1055@syacus.acus.oz> Date: 12 Sep 90 08:21:22 GMT References: Reply-To: andrewf@syacus.oz (Andrew Friedman) Organization: Australian Centre for Unisys Software, Sydney Lines: 14 Posted: Wed Sep 12 09:21:22 1990 jim@cs.strath.ac.uk (Jim Reid) writes: [Lots of Good Stuff comparing CB and IP protocols deleted] >... Don't forget that telnet is functionally >superior to X.29: it offers more for roughly the same overheads. Are you sure about this? I would have said it the other way around, but I'll admit I don't know Telnet as well as X.29. What's the problem? Have you seen RFC 1053 which proposes adding X.3 parameters into Telnet? Andrew Note: Original article appeared in uk.misc,eunet.followup also. I can't post to these. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091209135000> Received: from hawk.nstn.ns.ca by NIC.DDN.MIL with TCP; Wed, 12 Sep 90 05:39:23 PDT Date: Wed, 12 Sep 90 09:13:50 GMT Message-Id: <1340@hawk.nstn.ns.ca> From: bushell@hawk.nstn.ns.ca (Tom Bushell) Reply-To: bushell@hawk.nstn.ns.ca To: tcp-ip@nic.ddn.mil Subject: SNMP info and TCP/IP test programs Hello, We're working on an IP router that will support SNMP. I haven't seen any SNMP info on the TCP/IP news group in the week or so I've been on. Is there another news group for SNMP? We have the SNMP RFCs - what other sources have people found useful? I will summarize and publish any responses. Also, we are looking at ways to test our router. I've been told there is a program called "ttcp" ("Test TCP") that may be useful. Does anybody know where I can get this program, if it exists? Thanks in advance, Tom Bushell SKL bushell@hawk.nstn.ns.ca ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091209595100> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Wed, 12 Sep 90 16:59:59 PDT Received: from braden.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Wed, 12 Sep 90 16:59:59 -0700 Date: Wed, 12 Sep 90 16:59:51 PDT From: braden@venera.isi.edu Posted-Date: Wed, 12 Sep 90 16:59:51 PDT Message-Id: <9009122359.AA08702@braden.isi.edu> Received: by braden.isi.edu (4.1/4.0.3-4) id ; Wed, 12 Sep 90 16:59:51 PDT To: ietf@venera.isi.edu, tcp-ip@nic.ddn.mil Subject: IAB meeting minutes available Cc: braden@venera.isi.edu Minutes of the IAB meeting held in April 1990 are available for anonymous FTP from host venera.isi.edu with pathname: pub/IABmins.apr90.txt Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091211213100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 17 Sep 90 14:56:26 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA14162; Mon, 17 Sep 90 14:20:31 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Sep 90 11:21:31 GMT From: agate!linus!nixbur!nixpbe!peun33!gla@apple.com (R. Glaschick) Subject: Re: LAN Manager and UNIX Message-Id: References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In ingea@IFI.UIO.NO (Inge Arnesen) writes: >Have any UNIX vendors said how they will relate to LM ? >If only Microsoft and PC SW vendors support LM, LM will probably remain >in the PC world....... Siemens Nixdorf has ported LM/X to Targon and MX machines and will sell and support it as a product ASAP. (Depends on final release, testing, licence etc). The first release will to my knowledge aimed towards PCs (DOS & OS/2) linked to a Targon or MX, and not so much for UNIX to UNIX links. -- Rainer Glaschick, NIXDORF Computer AG, Paderborn, W-Germany EMail: glaschick.pad@nixdorf.com (US) or glaschick.pad@nixdorf.de (EU) Tel. +49 5251 14 6150 (office) +49 5254 6238 (home) Fax: +49 5251 14 6569 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1775@hugo.erbe.se] <1990091213315800> From: prc@erbe.se (Robert Claeson) Newsgroups: comp.protocols.tcp-ip Subject: Re: LAN Manager and UNIX Message-ID: <1775@hugo.erbe.se> Date: 12 Sep 90 13:31:58 GMT References: Organization: ERBE DATA AB, Jarfalla, Sweden Lines: 16 Posted: Wed Sep 12 14:31:58 1990 In a recent article ingea@IFI.UIO.NO (Inge Arnesen) writes: [On Lan Manager/X...] >Have any UNIX vendors said how they will relate to LM ? >If only Microsoft and PC SW vendors support LM, LM will probably remain >in the PC world....... At least AT&T, HP and DG supports Lan Manager/X under their respective UNIX implementations. -- Robert Claeson |Reasonable mailers: rclaeson@erbe.se ERBE DATA AB | Dumb mailers: rclaeson%erbe.se@sunet.se | Perverse mailers: rclaeson%erbe.se@encore.com These opinions reflect my personal views and not those of my employer (ask him). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091215031400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 13 Sep 90 12:26:23 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06882; Thu, 13 Sep 90 12:19:28 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Sep 90 15:03:14 GMT From: dftsrv!hq!lgn!terry@ames.arc.nasa.gov (Terry Bernstein) Subject: Re: RoboDoc Message-Id: References: <9009072311.AA04335@chienne.isi.edu>, <6706@darkstar.ucsc.edu>, <18612@ucsd.Edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Why weren't any .mil sights reported on in the RoboDoc report????? -- terry -- -- ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>>>> Terry Bernstein <"Who is John Galt?"> << The Pentagon <<< -------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [25536.26ee0e89@kuhub.cc.ukans.edu] <1990091215313700> From: jian@kuhub.cc.ukans.edu Newsgroups: comp.protocols.tcp-ip Subject: Looking for TELNET source codes Message-ID: <25536.26ee0e89@kuhub.cc.ukans.edu> Date: 12 Sep 90 15:31:37 GMT Organization: University of Kansas Academic Computing Services Lines: 5 Posted: Wed Sep 12 16:31:37 1990 Could someone out there tell me where I can get UNIX TELNET source codes via FTP. Any indication appreciated. Jian Q. Li jian@kuhub.cc.ukans.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [21917@mvis1.com] <1990091216562200> From: pcaloca@synoptics.COM (Paul Caloca) Newsgroups: comp.protocols.tcp-ip Subject: Re: SynOptics compatability Summary: Fiber Compatibility 1000 & 3000 Concentrators Message-ID: <21917@mvis1.com> Date: 12 Sep 90 16:56:22 GMT References: <9009112007.AA08799@ucbvax.Berkeley.EDU> Organization: SynOptics Communications Inc., Mt. View, Ca. Lines: 36 Posted: Wed Sep 12 17:56:22 1990 In article <9009112007.AA08799@ucbvax.Berkeley.EDU>, 702WFG@SCRVMSYS.BITNET (bill gunshannon) writes: > I have a question for any SynOptics users out there. > I currently have a building wired using SynOptics 1000's and UTP. > We plan to extend the network to other building on Campus and wanted to > do it using Fiber. Does anyone know if the Fiber connections on a SynOptics > 1000 (a 201-ST board) are compatable with the newer 3000 series > concentrators?? If not, I can still get around it, but the configuration > will change considerably. > > Can anyone shed any light on this subject? Is SynOptics on the net anywhere? > > bill gunshannon > 702WFG@SCRVMSYS.BITNET The 201-ST board has been discontinued for over well a year and is not compatible with the 3000 concentrator. The 201-ST uses a proprietary fiber transmission protocol while all 3000 series fiber modules use the Fiber Optic Inter-Repeater Link (FOIRL) industry standard protocol. The 504 fiber optic transceiver also uses FOIRL and cannot be used with the 201-ST. The best option is to upgrade your 201-ST board to a 207-ST FOIRL Retiming Module if retiming is used in that concentrator or use a 208-ST Termination Module if only backplane termination is required. ======================================================================== Paul Caloca | "Minds are like parachutes - Technical Support | they ony function when open." SynOptics Communications | Mountain View, CA |==================== Thomas Dewar Email: Paul_Caloca.SALES@engtwomac.synoptics.com UUCP: ...!ames.arc.nasa.gov!synoptics.com!engtwomac!Paul_Caloca.SALES FAX: 415-964-0407 ======================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091217330300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 13 Sep 90 12:56:36 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08816; Thu, 13 Sep 90 12:43:51 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Sep 90 17:33:03 GMT From: dftsrv!hq!martin@ames.arc.nasa.gov (Gregory.J.Martin) Organization: Air Force HQ, The Pentagon Subject: Re: RoboDoc Message-Id: <3198@hq.af.mil> References: <6706@darkstar.ucsc.edu>, <18612@ucsd.Edu>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article terry@hq.af.mil (Terry Bernstein) writes: >Why weren't any .mil sights reported on in the RoboDoc report????> >-- terry - C'mon Terry, you know as well as I, the military nets are managed perfectly. Like yours, for instance!!! ...Greg Martin (No, the AF won't let me speak for it. Darn!!) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [91900912173519.0004219666NB4EM@mcimail.com] <1990091217350000> From: 0004219666@MCIMAIL.COM (Bob Stine) Newsgroups: comp.protocols.tcp-ip Subject: Re: SNMP info and TCP/IP test programs Message-ID: <91900912173519.0004219666NB4EM@mcimail.com> Date: 12 Sep 90 17:35:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 Posted: Wed Sep 12 18:35:00 1990 Check RFC 1147 for availability info on ttcp. - Bob Stine Applied Cybernetics, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091217384700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 13 Sep 90 12:48:03 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07933; Thu, 13 Sep 90 12:32:47 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Sep 90 17:38:47 GMT From: mcsun!ukc!dcl-cs!aber-cs!athene!pcg@uunet.uu.net (Piercarlo Grandi) Organization: Coleg Prifysgol Cymru Subject: Re: Sockets vs streams. An attempt to answer the original question Message-Id: References: <1990Aug28.162400.17811@zoo.toronto.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil On 4 Sep 90 17:29:23 GMT, lars@spectrum.CMC.COM (Lars Poulsen) said: lars> In article <1990Aug28.162400.17811@zoo.toronto.edu> lars> henry@zoo.toronto.edu (Henry Spencer) writes: spencer> The way to do i/o on Dennis's streams was with "read" and spencer> "write". Network i/o, in general, looked *exactly* like local spencer> device i/o. If you want to keep UNIX like semantics. Unfortunately you really want to do typed data, if only to include passing file descriptors, and OOB signaling, and these do not fit well with traditional UNIX style interfaces. spencer> This is the way it should be, unlike what both Berkeley and spencer> AT&T have done (both have reluctantly conceded that most people spencer> want to use "read" and "write" and have made that work, but spencer> their hearts were clearly elsewhere). lars> In article lars> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: pcg> And for good reason! read() and write() on file descriptors is not pcg> the most amusing interface. It is much more convenient to have ... pcg> [features] Hey, I take exception to the [features] summary -- I was describing not a set of extra features, but a completely different philosophy based on communication with active entities represented by IPC ports. An alternative to the UNIX style file descriptors to access passive files. It can be as simple and terse as the current UNIX style. lars> The problem is larger than that. As commercial programmers have lars> often said, unix read() and write() is not a very good interface lars> for files, either. It is a good interface for SIMPLE TEXT files, lars> and very little else. Uhm. Here we differ. The UNIX style of accessing file is excellent for any type of file, because any type of file can be mapped onto untyped byte arrays (a.k.a. virtual memory segments), by the use of suitable library procedures. Unfortunately non storage like entities are not easily mapped onto untyped byte arrays. lars> Having a guaranteed subset of compatible functionality has allowed lars> very productive use of the "building block" philosophy. Having a way to lars> specify a remote conenctions "as if" it were a filename would allow more lars> things to be prototyped with simple shell scripts and pipelines. The problem is that modeling everything as a passive entitity is far less flexible than modling everything as an active entity. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3205@hq.af.mil] <1990091220400700> From: martin@hq.af.mil (Gregory.J.Martin) Newsgroups: comp.protocols.tcp-ip Subject: Re: SynOptics compatability Message-ID: <3205@hq.af.mil> Date: 12 Sep 90 20:40:07 GMT References: <9009112007.AA08799@ucbvax.Berkeley.EDU> Reply-To: martin@hq.af.mil (Gregory.J.Martin) Organization: Air Force HQ, The Pentagon Lines: 23 Posted: Wed Sep 12 21:40:07 1990 In article <9009112007.AA08799@ucbvax.Berkeley.EDU> 702WFG@SCRVMSYS.BITNET (bill gunshannon) writes: >I have a question for any SynOptics users out there. >I currently have a building wired using SynOptics 1000's and UTP. > Does anyone know if the Fiber connections on a SynOptics >1000 (a 201-ST board) are compatable with the newer 3000 series >concentrators?? If not, I can still get around it, but the configuration >will change considerably. > >Can anyone shed any light on this subject? Is SynOptics on the net anywhere? > > bill gunshannon > 702WFG@SCRVMSYS.BITNET The fiber connections on both these products are identical. I went to a design class run by SynOptics (okay, it was a glorified sales pitch!) and we combined both product line together all the time. I'll be their engineers will say the same thing. Just make sure you get the right type of fiber connectors for the concentrator on that end of the "wire" and all should run fine. We love our SynOptics, especially their Network Management Control Console. It saves us a lot of debug time!! If you have any questions e-mail me at martin@hq.af.mil. ...Greg Martin (No, The Air Force won't allow me to speak their mind!!) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091222232000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 13 Sep 90 12:27:42 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06831; Thu, 13 Sep 90 12:19:05 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Sep 90 22:23:20 GMT From: olivea!orc!inews!iwarp.intel.com!psueea!parsely!percy!data!john@apple.com (John Mantey) Organization: Microcosm, Beaverton, OR Subject: PD/Commercial TCP/IP packages Message-Id: <411@data.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm trying to establish a TCP/IP link between a 386 PC running Windows 3.0 and a 386 PC running VRTX. My goal is to get an effective throughput of 100K bytes/sec. I started with MIT/CMU public domain version of PCIP, circa March '86, and got them talking, but the throughput was orders of magnitude too slow. I have info on FTP's implementation, but I want to get info on other implementations also. Please email me if you're familiar with any PD or commercial versions of TCP/IP. If its a commercial version, I either need access to the source, or the ability to integrate it with our product. Thanks. Tom Baker tom@data.uucp Microtek International, DSD ----------------------------------- 3300 NW 211th Terrace #include Hillsboro, Or 97124 503-645-7333 -- John Mantey john@data.uucp Microtek International, DSD ----------------------------------- 3300 NW 211th Terrace Not bird, nor plane, nor even frog. Hillsboro, Or 97124 Just little old me, Underdog. 503-645-7333 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091223013100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 12 Sep 90 19:14:13 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12774; Wed, 12 Sep 90 19:04:56 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Sep 90 23:01:31 GMT From: harvisr!sob@husc6.harvard.edu (Scott Bradner) Organization: Harvard University, Cambridge MA Subject: hey wait a minute ... Message-Id: <4160@husc6.harvard.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I was more than a little surprised to hear the other day that I was on contract to Wellfleet. At least that was what some people were saying. Well it is not true. To do anything like that might put a bit of a taint on the testing results that I've been reporting. :-) Full disclosure time: I have done & continue to do some consulting, but I have not done and am not doing any with any of the vendors of devices that I'm now testing. (Hey, I even chose not to buy any cisco stock, dumb move?) Like with many tall tales there may be a slim germ of truth somewhere in it. Here is the story I tell the router vendors that call & offer to send me a router for testing. Back about 2 months ago I got a call from Proteon saying that they had fixed the problems that we had found last year & had improved the throughput by quite a bit, and could we give the new code a test? (This was on a voice mail message.) The same day I got a call from someone at Wellfleet asking, in effect, why was I not doing a new round of tests since it had been a while since the last batch. say I: "Well I don't have good enough equipment to do the tests required & there ain't no way to get the kind of funding required here at Harvard" said he: "Well we can donate/loan you a test setup we have built." say I: "Humm", (then to self, "I don't see any other way to do something before Interop but what would the other vendors think?") "Why don't I come out and talk about it?" so I did. What came of it was an informal agreement (nothing on paper) for Wellfleet to loan Harvard some equipment & agree to have the person who had done their software make "a few" changes/additions to what he had done to make the tests more like what the Benchmarking Methodology Working Group had been discussing. Wellfleet also agreed that they would work out a way that other organizations could get access to the equipment in the future if there was enough interest. Access to the source code was also offered. ( an aside, the test packet generator is a Wellfleet router with special software. It is setup with pairs of ethernet ports. One port of each pair is used to produce packets right fast, the second port is used to produce the "keep alive" traffic required to convince some protocols that there is a node out there.) Now, I fully expect that Wellfleet is not 100% altruistic in their offer, they expect to have their box do quite well in the tests & the results will look better coming from a independent source than they would from Wellfleet. It might & it might not (I've not bashed it yet, I'm starting in on it tomorrow.) but the tests will be fair and open. The same tests will be run on all routers. Also, Dan Lanciani & I (mostly Dan) have come up with a "simple" hardware design for a card to put in a PC along with a NI5210 to replicate the total functionally of the Wellfleet hardware. We will produce the card asap and redo some or all of the tests with the new hardware as a final check. Software will be written to automaticly run a series of tests and produce the results as the BMWG RFCs will describe. (The source to the test software and the artwork for the board will be placed for anonymous ftp.) I've told this story to all of the vendors when they call wanting to test a router, none of them have expressed reservations about the arrangement. I'm sorry that I did not mention it in the 1st posting but I was still working out the details. It was a mistake to not wait. But hindsite is easy... Scott PS - bashing update here to be tested or dates set: Proteon (P4200 & RIG) Wellfleet 3com cisco NSC Timeplex and (I think) BBN ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091223361300> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Thu, 13 Sep 90 06:37:02 PDT Posted-Date: Thu, 13 Sep 90 06:36:13 PDT Message-Id: <9009131336.AA20886@venera.isi.edu> Received: from LOCALHOST by venera.isi.edu (5.61/5.61+local) id ; Thu, 13 Sep 90 06:36:15 -0700 To: brian@ucsd.edu (Brian Kantor) Cc: tcp-ip@nic.ddn.mil Reply-To: pvm@venera.isi.edu Subject: Re: RoboDoc In-Reply-To: Your message of 08 Sep 90 13:11:58 +0000. <18612@ucsd.Edu> Date: Thu, 13 Sep 90 06:36:13 PDT From: Paul Mockapetris It is perfectly proper to list more then two servers for a domain. Of course, the more separate (power supplies, Ethernet cables, etc.) they are the more reliability of the overall system improves. Similarly, you cannot take advantage of a server that you do not know about, so you have to advertise it. paul ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1990Sep13.023610.16274@mlb.semi.harris.com] <1990091302361000> From: del@thrush.mlb.semi.harris.com (Don Lewis) Newsgroups: comp.protocols.tcp-ip Subject: Re: RoboDoc Message-ID: <1990Sep13.023610.16274@mlb.semi.harris.com> Date: 13 Sep 90 02:36:10 GMT References: <9009072311.AA04335@chienne.isi.edu> Sender: news@mlb.semi.harris.com Organization: Harris Semiconductor, Melbourne FL Lines: 8 Posted: Thu Sep 13 03:36:10 1990 Dear RoboDoc, If you really want to have some fun, start poking around under in-addr.arpa. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091308101100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 14 Sep 90 12:17:42 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27782; Fri, 14 Sep 90 01:49:08 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Sep 90 08:10:11 GMT From: mcsun!ukc!icdoc!citycs!sb380@uunet.uu.net (Andy Holt) Organization: City University, London Subject: Re: Internet routing Europe - USA -} Europe... Message-Id: <1990Sep13.081011.19298@cs.city.ac.uk> References: , <4862@tardis.cs.ed.ac.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <4862@tardis.cs.ed.ac.uk> anarchy@tardis.cs.ed.ac.uk (Alan Cox) writes: >Oh dear.. does that mean they don't like people running kermit over janet >lines, after all kermit is a file transfer protocol and it's not in the >coloured books (not even the yellow and purple spotty one 8-)), does seem >to be a certain amount of a red tape factory running here. Maybe the planned >shakeup of the steering committes of janet is a good thing. > Technically they don't! Mentioning Kermit at a Networkshop was a good way to get very black looks from JNT members (just like TCP/IP). The standard joke was "if it works and is a **de facto** standard, it is clearly unacceptable". Of course though the frog is the only viable file transfer protocol for some brain-damaged mainframes, newer (also de-facto) standards like zmodem give much better performance over phone lines. Andy -------------------------------------------------------------------- "I like to have lots of standards so I can choose which ones to abuse" ----MESSAGE-END---- ----MESSAGE-BEGIN---- [20913.26ef4b9c@zodiac.ukc.ac.uk] <1990091309042700> From: cur022@zodiac.ukc.ac.uk (Bob Eager) Newsgroups: uk.misc,eunet.followup,comp.protocols.tcp-ip Subject: Re: Internet routing Europe - USA -} Europe... Message-ID: <20913.26ef4b9c@zodiac.ukc.ac.uk> Date: 13 Sep 90 09:04:27 GMT References: <1990Aug30.091435.1982@ircam.ircam.fr <6190@vanuata.cs.glasgow.ac.uk> <4847@tardis.cs.ed.ac.uk> <4862@tardis.cs.ed.ac.uk> Organization: Computing Lab, University of Kent at Canterbury, UK. Lines: 13 Posted: Thu Sep 13 10:04:27 1990 In article <4862@tardis.cs.ed.ac.uk>, anarchy@tardis.cs.ed.ac.uk (Alan Cox) writes: > Oh dear.. does that mean they don't like people running kermit over janet > lines, after all kermit is a file transfer protocol and it's not in the > coloured books (not even the yellow and purple spotty one 8-)), Actually, they don't like it! Kermit is like a red rag to a bull as far as the JNT are concerned.... ---------------------+----------------------------------------------------- Bob Eager | University of Kent at Canterbury rde@ukc.ac.uk | +44 227 764000 ext 7589 ---------------------+----------------------------------------------------- *** NB *** Do NOT use the return path in the article header *************** --------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091311213000> Received: from kiddo.merit.edu ([35.1.1.30]) by NIC.DDN.MIL with TCP; Fri, 14 Sep 90 12:19:15 PDT Received: Thu, 13 Sep 90 18:01:30 -0400 by kiddo.merit.edu (AIX/1.6) Date: Thu, 13 Sep 90 18:01:30 -0400 From: Hans-Werner Braun Message-Id: <9009132201.AA15790@kiddo.merit.edu> To: manta!gutman@nosc.mil, tcp-ip@nic.ddn.mil Subject: Re: internet routing protocols- general questions... The NSFNET Backbone runs the ANSI/ISO IS-IS protocol as its IGP since mid 1988. It uses EGP and BGP to communicate with its client networks. -- Hans-Werner ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10628@quest.UUCP] <1990091311410900> From: ssb@quest.UUCP (Scott S. Bertilson) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans,comp.dcom.modems Subject: terminal servers w/modems (dial-in/out) Keywords: terminal server modem bidirectional Message-ID: <10628@quest.UUCP> Date: 13 Sep 90 11:41:09 GMT Reply-To: ssb@quest.UUCP (Scott S. Bertilson) Followup-To: comp.protocols.tcp-ip Organization: Quest Research Inc., Burnsville, MN Lines: 34 Posted: Thu Sep 13 12:41:09 1990 I've just been trying out the Xyplex terminal servers and was pleased to discover that they allow a mode where a given port can be used either for dialing in or dialing out - depending on whether the modem sees carrier first or a host requests a connection to the port first. It generally works just like I'd hope it would except that their box currently doesn't allow hardware flow control AND modem control simultaneously. I've also looked at an Altos version of a 10 port CMC terminal server which does have enough hardware lines to support both, but doesn't support what Xyplex calls "port access dynamic". I'm wondering if this is the case for the real CMC box or if it's a restriction that Altos applied. Are there any other terminal servers other than Xyplex that support bidirectional modem use? A related topic is that in order for this to be truly useful, "uucico" and "cu" need to be able to make a TCP/IP connection. I know that 4.3 allows this, but I'm running SCO UNIX 3.2 and Altos version of AT&T SVR3.1. I'm less familiar with SCO, so I might be missing something, but as far as I know, it doesn't allow this. It is possible in both of these environments to make ISO streams connections using the NLS (I'm very short on knowledge of terms/semantics here), but as far as I can see there is no way to make a TCP/IP connection. Any ideas? The only idea I've had is that perhaps one could write a server under streams that would accept connections and pass the data across to a (Lachmann) TCP/IP socket. If anyone has done this or tried, I'd sure like to see code or fragments thereof. Thanks! -- Scott S. Bertilson ...ssb@quest.UUCP scott@poincare.geom.umn.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1990Sep13.145407.19786@brolga.cc.uq.oz.au] <1990091314540700> From: ggm@brolga.cc.uq.oz.au (George Michaelson) Newsgroups: comp.protocols.tcp-ip Subject: TCP beating JANET? not the last 3 days! Message-ID: <1990Sep13.145407.19786@brolga.cc.uq.oz.au> Date: 13 Sep 90 14:54:07 GMT Distribution: comp Organization: Prentice Computer Centre, The University of Queensland, Australia. Lines: 20 Posted: Thu Sep 13 15:54:07 1990 That was some case of indigestion. Traceroute barfed all over the dustbowl. I got dumped before, during, and after jvnc, net 14 (nsf-relay.ac.uk 2nd IP address) kept smiling through, ucl cisco was reachable and then not (peek-a-boo!) and all because the lady loves milktray. [ok, provokative Subject: On a more "serious" note an outage like that is *not* good sales copy] Anybody know which box did what to whom? wash some linin in public! -My guess is french anti-AWAC jammers blew the brains out of the wires -George -- G.Michaelson Internet: G.Michaelson@cc.uq.oz.au Phone: +61 7 377 4079 Postal: George Michaelson, Prentice Computer Centre The University of Queensland, St Lucia, QLD Australia 4067. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [OLSON.90Sep13104447@sax.cs.uiuc.edu] <1990091315444700> From: olson@sax.cs.uiuc.edu (Bob Olson) Newsgroups: comp.protocols.tcp-ip Subject: DialupIP Message-ID: Date: 13 Sep 90 15:44:47 GMT Sender: news@ux1.cso.uiuc.edu (News) Distribution: comp Organization: University of Illinois, Urbana-Champaign Lines: 5 Posted: Thu Sep 13 16:44:47 1990 I'm looking for an implementation of DialupIP (I think it's called; it is a point-to-point version of SLIP) for a Sun sparc or DECstation. Is there one out there somewhere?? --bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [26532@mimsy.umd.edu] <1990091316210700> From: dheeraj@cs.umd.edu (Dheeraj Sanghi) Newsgroups: comp.protocols.tcp-ip Subject: Packet reordering Message-ID: <26532@mimsy.umd.edu> Date: 13 Sep 90 16:21:07 GMT Sender: news@mimsy.umd.edu Reply-To: dheeraj@cs.umd.edu (Dheeraj Sanghi) Organization: U of Maryland, Dept of Comp Sc, Systems Design & Analysis Group Lines: 61 Posted: Thu Sep 13 17:21:07 1990 Recently, we have seen massive reordering of packets in the internet. Previously, when we noticed reordering, it was always 2 packets who have been sent together, reach in the opposite order. But now we are seeing as much as 10 packets sent at the rate of 1 packet per clock tick (10 ms) reaching exactly in the opposite order. We have not yet figured how to reproduce it at will, but we have seen it quite often. Here is some data from our observations. PKT# Sendtime Recvtime Delay 3 160 370 210 4 170 360 190 5 180 360 180 6 190 350 160 7 200 350 150 8 210 340 130 9 220 340 120 10 230 330 100 11 240 320 80 12 250 320 70 13 260 400 140 (All times in ms.) We are using DTP, an in-house protocol with the same functionality as TCP. We are using IP, so it shouldn't really matter what transport layer protocol we use. The route being taken is (from the traceroute program): rhodes.cs.umd.edu 128.8.128.1 mrb-gw.umd.edu 128.8.109.1 bogon-gw.umd.edu 128.8.253.7 128.167.102.2 128.167.104.1 sura1.sura.net 128.167.1.1 We are using IP_LSRR option to send packet to sura1.sura.net and back. Both sender and receiver programs are on huginn.cs.umd.edu (128.8.128.35). The acknowledgements are sent within machine. We have also tried sending packets upto various intermediate gateways and have seen reordering from all gateways except rhodes and mrb-gw. (The first two gateways.) Any ideas as to what is causing the whole block of packets to reorder and reach the destination in exactly the opposite order. Dheeraj Sanghi (dheeraj@cs.umd.edu) Ashok Agrawala (agrawala@cs.umd.edu) -- Dheeraj Sanghi (h):301-794-6247 (o):301-405-2723 Internet: dheeraj@cs.umd.edu UUCP: uunet!mimsy!dheeraj When you find you are on the side of the majority, it is time to reform. - Mark Twain ----MESSAGE-END---- ----MESSAGE-BEGIN---- [64256@bu.edu.bu.edu] <1990091317530800> From: kwe@buit13.bu.edu (Kent England) Newsgroups: comp.protocols.tcp-ip Subject: Re: hey wait a minute ... Message-ID: <64256@bu.edu.bu.edu> Date: 13 Sep 90 17:53:08 GMT References: <4160@husc6.harvard.edu> Sender: news@bu.edu.bu.edu Reply-To: kwe@buit13.bu.edu (Kent England) Followup-To: comp.protocols.tcp-ip Organization: Boston U. Information Technology Lines: 30 Posted: Thu Sep 13 18:53:08 1990 In article <4160@husc6.harvard.edu> sob@harvisr.UUCP (Scott Bradner) writes: >I was more than a little surprised to hear the other day that I was on >contract to Wellfleet. At least that was what some people were saying. > >Well it is not true... > >Like with many tall tales there may be a slim germ of truth somewhere >in it. > >Scott > Well, I read your story about Wellfleet donating some test equipment for your router bashing and I think you're wrong. There isn't even a slim germ of truth indicating any conflict of interest. I think what you have found is an unusual level of general excitement on the part of commercial people who smell a large new market and think Scott Bradner and his router bashing might be the key to their getting a piece of that market. You're in the spotlight, but I, for one, feel more comfortable about that than what we had before; which was a bunch of vendor engineers and marketing people pushing, shoving, yelling, and lying about their bridge and router performance. At this point, we are beginning to see some semblance of order, sort of like when the teacher walks into the classroom and the spitballs stop flying. --Kent ----MESSAGE-END---- ----MESSAGE-BEGIN---- [144@faatcrl.UUCP] <1990091319134700> From: jimb@faatcrl.UUCP (Jim Burwell) Newsgroups: comp.dcom.modems,comp.protocols.tcp-ip Subject: Toronto SLIP, CSLIP, and SunOS 4.1 Keywords: kludge pig bloated Message-ID: <144@faatcrl.UUCP> Date: 13 Sep 90 19:13:47 GMT Followup-To: comp.dcom.modems Organization: FAA Technical Center, Atlantic City NJ Lines: 20 Posted: Thu Sep 13 20:13:47 1990 Hello.. Has anyone had any experience running Toronto SLIP under SunOS 4.1 ? From reading the documentation which came with SLIP/CSLIP, it doesn't seem possible. We're running 4.0.3 right now, but we just got 4.1. I'm afraid to install it though since it looks like it would break slip, and possibly our dialin, dialout, and UUCP connections. Are there fixes out there for the streams drivers which will take care of the problems described in the Toronto SLIP docs ? Thanx in advance for any info, Jim -- UUCP: ...!rutgers!faatcrl!jimb Internet: jimb@faatcrl.UUCP Under brooding skys and watchful eyes On convulsive seas of false urgency We walk empty corridors in vain - "No Exit", Fate's Warning ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1780@hugo.erbe.se] <1990091319594400> From: prc@erbe.se (Robert Claeson) Newsgroups: comp.protocols.tcp-ip Subject: Re: terminal servers w/modems (dial-in/out) Keywords: terminal server modem bidirectional Message-ID: <1780@hugo.erbe.se> Date: 13 Sep 90 19:59:44 GMT References: <10628@quest.UUCP> Organization: ERBE DATA AB, Jarfalla, Sweden Lines: 33 Posted: Thu Sep 13 20:59:44 1990 In a recent article ssb@quest.UUCP (Scott S. Bertilson) writes: > I've just been trying out the Xyplex terminal servers and was >pleased to discover that they allow a mode where a given port >can be used either for dialing in or dialing out - depending ..... > Are there any other terminal servers other than Xyplex that >support bidirectional modem use? Yes, the Annex series of terminal servers from Xylogics and Encore Computer has supported bidirectional ports since many years ago. > A related topic is that in order for this to be truly useful, >"uucico" and "cu" need to be able to make a TCP/IP connection. >I know that 4.3 allows this, but I'm running SCO UNIX 3.2 and >Altos version of AT&T SVR3.1. If you have Streams and/or TLI access to TCP/IP, it is possible. It's just a matter of setting up the Devices and related files correctly (provided your system actually use HDB uucp that the System V Release 3.1 code is delivered with from AT&T). See the documentation for "BNU" (Basic Networking Utilities). I recently tried this but can't remeber the details. But it was easy. Make sure to use the "e" protocol for best performance. -- Robert Claeson |Reasonable mailers: rclaeson@erbe.se ERBE DATA AB | Dumb mailers: rclaeson%erbe.se@sunet.se | Perverse mailers: rclaeson%erbe.se@encore.com These opinions reflect my personal views and not those of my employer (ask him). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091400120100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 14 Sep 90 12:16:46 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03188; Fri, 14 Sep 90 02:35:54 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Sep 90 00:12:01 GMT From: agate!bionet!ucselx!sol.ctr.columbia.edu!emory!samsung!crackers!m2c!umvlsi!umaecs!amh!gehallert@ucbvax.Berkeley.EDU Subject: Message-Id: <10116.26f02052@amherst.bitnet> References: <1990Aug29.153353.13564@math.lsa.umich.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Aug29.153353.13564@math.lsa.umich.edu>, nelson@sun.soe.clarkson.edu (Russ Nelson) writes: > Archive-name: clarkson-packet-drivers/29-Aug-90 > Original-posting-by: nelson@sun.soe.clarkson.edu (Russ Nelson) > Original-subject: Clarkson packet drivers 7.x now available > Archive-site: sun.soe.clarkson.edu [128.153.12.3] > Archive-directory: /pub/ka9q > Reposted-by: emv@math.lsa.umich.edu (Edward Vielmetti) > > The 7.x release of the Clarkson collection of packet drivers is now > available. The summary is given below. In addition to the new > drivers and bug fixes, a switch has been added that lets you use > Novell without econfiging your server. > > Summary: > New drivers: UB PC/NIC, LocalTalk, Tiara, NTI. > Bugs fixed: 3c505, 3c503, wd8003e, nb, ne1000. > Bug found but not fixed: 3c523. > > The packet drivers are for MS-DOS, and serve to hide the difference between > network cards, and allow multiple protocol stacks to access the same card. > Most often people are interested in running Novell's Netware and TCP/IP > at the same time. > > The Clarkson packet driver collection > > Availability > > The Clarkson collection of packet drivers is available by FTP, by > archive-server, 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. > > Mail: > > I distribute the packet drivers on a 1.2 MB 5.25" disk, or a 720K 3.5" > disk. You can send me a check for $20, or you can send me a purchse > order and I will bill you for $22. NY residents add 7% sales tax, > overseas orders add $3 for shipping. If you send a check, please be > sure it is in US dollars -- the bank charges me $15 to convert checks > drawn in foreign currencies. > > Russell Nelson > 11 Grant St. > Potsdam, NY 13676 > > 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. > > -- > --russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667 > We won the cold war. The Russians spent trillions defending their stuff, > then they found that they didn't have any stuff. Will we avoid the same trap? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091407354400> Received: from NNSC.NSF.NET by NIC.DDN.MIL with TCP; Fri, 14 Sep 90 12:09:49 PDT To: tcp-ip@nic.ddn.mil Subject: SIGCOMM '91 Call for Papers From: Craig Partridge Date: Fri, 14 Sep 90 14:15:44 -0400 Sender: craig@NNSC.NSF.NET [Hi folks -- SIGCOMM '90 is just around the corner so it's time for me to start trolling for papers for SIGCOMM '91 -- craig] Call For Papers ACM SIGCOMM '91 CONFERENCE Communications Applications, Architectures and Protocols ETH Zurich, Zurich, Switzerland September 4-6, 1991 (Tutorials September 3, 1991) The conference provides an international forum for the presentation and discussion of communication network applications and technologies, as well as recent advances and proposals on communication architectures, protocols, algorithms, and performance models. It is the first time that SIGCOMM will hold its conference outside of the United States. Authors are invited to submit full papers concerned with both theory and practice. The areas of interest for the conference include, but are not limited to the following: Analysis and design of computer network architectures and algorithms, innovative results in local area networks, computer-supported cooperative work, network interconnection and mixed-media networks, high-speed networks, resource sharing in distributed systems, network management, distributed operating systems and databases, protocol specification, verification, and analysis. Papers should be about 20 double-spaced pages long and should have an abstract of 100-150 words. All submitted papers will be reviewed and will be judged with respect to their quality and relevance. Authors of accepted papers will be expected to sign an ACM copyright release form. The Proceedings will be distributed at the conference and published as a special issue of ACM SIGCOMM Computer Communication Review. Notable papers will be considered for publication in ACM Transactions on Computer Systems. Submit 5 copies of each paper to the program chairman (or in the US, the US program committee contact): Prof. Bernhard Plattner Technische Informatik und Kommunikationsnetze Telephone: +41 1 254 7000 ETH-Zentrum (IFW) Fax: +41 1 262 3973 8092 Zurich, Switzerland EMAIL: or The US program committee contact is: Greg Wetzel AT&T Bell Laboratories Telephone: +1 (708) 979-4782 M/S IH 1B-213 Fax: +1 (708) 979-2350 2000 N. Naperville Road E-Mail: gfw@pueblo.att.com Naperville, IL 60566 For more information about the conference, e-mail to sicomm91@nri.reston.va.us Special session: Applications of High Speed Networks One or more sessions of the conference will be devoted to the subject of applications of high speed networks. Papers in these sessions will focus on concepts, implementation and experience of applications that need the performance that future high speed networks will offer. Topics include, but are not limited to new approaches to computer-supported cooperative work, graphic visualization, and access to supercomputers. Papers submitted for these topics should address applications and their communications requirements. Student Paper Award Papers submitted by students will enter a student-paper award contest. Among the accepted papers, a maximum of four outstanding papers will be awarded (1) full conference registration and (2) a travel grant of $500 US dollars. To be eligible the student must be the sole author or a primary contributor to the paper. IMPORTANT DATES Deadline for paper submission: March 2, 1991. Notification of acceptance: April 30, 1991. Camera ready papers due: May 31, 1991. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091408363000> Mail-From: NIC created at 14-Sep-90 15:46:13 Date: Fri, 14 Sep 90 15:36:30 PDT From: DDN Reference Subject: NIC.DDN.MIL host problem To: tcp-ip@NIC.DDN.MIL cc: nic@NIC.DDN.MIL Message-ID: <12621956254.50.NIC@NIC.DDN.MIL> The NIC.DDN.MIL host suffered a serious systems failure that caused significant amounts of mail to be lost. If you have sent a message to us between Wednesday afternoon (12 Sep) and Friday morning (14 Sep) Pacific Daylight Time, please send it again. Examples of major mailing lists on the NIC machine that you might have attempted to reach are: NIC@NIC.DDN.MIL HOSTMASTER@NIC.DDN.MIL REGISTRAR@NIC.DDN.MIL Apologies for the large distribution, the NIC is trying to reach many sites with this notice. Thanks for your patience. The DDN NIC Staff ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091409083800> Received: from timbuk.CRAY.COM by NIC.DDN.MIL with TCP; Fri, 14 Sep 90 15:29:35 PDT Received: from berserkly.cray.com by timbuk.CRAY.COM (4.1/SMI4.0 CRAY1.1) id AA03415; Fri, 14 Sep 90 17:29:28 CDT Received: by berserkly.cray.com id AA01403; 5.64/CRI-3.10; Fri, 14 Sep 90 17:28:38 -0500 Date: Fri, 14 Sep 90 17:28:38 -0500 From: dab@berserkly.cray.com (David Borman) Message-Id: <9009142228.AA01403@berserkly.cray.com> To: tcp-ip@nic.ddn.mil Subject: Telnet/telnet release A new BSD version of telnet and telnetd are now available for anonymous ftp from ucbarpa.berkeley.edu. There are two files: pub/telnet.90.09.14.tar.Z All the sources pub/telnet.90.09.14.diff.Z Diffs from telnet.90.06.28 This release contains mostly bugfixes, and some POSIX changes. If you are using one of my earlier version of telnet/telnetd, you'll probably want to get this new version. My list of changes started out pretty small, but then as time went by, more and more little problems were discovered. There are no major functionality changes with this release. If you have to make changes to get this code running on your machine, please send me the changes and I'll try to get them into the next release. -David Borman, dab@cray.com This list was extraced from the README giving more detail as to what is changed with this release: Switch the client to use getopt() for parsing the argument list. The 4.3Reno getopt.c is included for systems that don't have getopt(). Use the posix _POSIX_VDISABLE value for what value to use when disabling special characters. If this is undefined, it defaults to 0x3ff. For non-termio systems, TIOCSETP was being used to change the state of the terminal. This causes the input queue to be flushed, which we don't want. This is now changed to TIOCSETN. Take out the "#ifdef notdef" around the code in the server that generates a "sync" when the pty oputput is flushed. The potential problem is that some older telnet clients may go into an infinate loop when they receive a "sync", if so, the server can be compiled with "NO_URGENT" defined. Fix the client where it was setting/clearing the OPOST bit in the c_lflag field, not the c_oflag field. Fix the client where it was setting/clearing the ISTRIP bit in the c_lflag field, not the c_iflag field. (On 4.3Reno, this is the ECHOPRT bit in the c_lflag field.) The client also had its interpretation of WILL BINARY and DO BINARY reversed. Fix a bug in client that would cause a core dump when attempting to remove the last environment variable. In the client, there were a few places were switch() was being passed a character, and if it was a negative value, it could get sign extended, and not match the 8 bit case statements. The fix is to and the switch value with 0xff. Add a couple more printoption() calls in the client, I don't think there are any more places were a telnet command can be received and not printed out when "options" is on. A new flag has been added to the client, "-a". Currently, this just causes the USER name to be sent across, in the future this may be used to signify that automatic authentication is requested. The USER variable is now only sent by the client if the "-a" or "-l user" options are explicity used, or if the user explicitly asks for the "USER" environment variable to be exported. In the server, if it receives the "USER" environment variable, it won't print out the banner message, so that only "Password:" will be printed. This makes the symantics more like rlogin, and should be more familiar to the user. (People are not used to getting a banner message, and then getting just a "Password:" prompt.) Re-vamp the code for starting up the child login process. The code was getting ugly, and it was hard to tell what was really going on. What we do now is after the fork(), in the child: 1) make sure we have no controlling tty 2) open and initialize the tty 3) do a setsid()/setpgrp() 4) makes the tty our controlling tty. On some systems, #2 makes the tty our controlling tty, and #4 is a no-op. The parent process does a gets rid of any controlling tty after the child is fork()ed. Use the strdup() library routine in telnet, instead of the local savestr() routine. If you don't have strdup(), you need to define NO_STRDUP. Add support for ^T (SIGINFO/VSTATUS), found in the 4.3Reno distribution. This maps to the AYT character. The client is now smarter when setting the telnet escape character; it only sets it to one of VEOL and VEOL2 if one of them is undefined, and the other one is not already defined to the telnet escape character. Handle TERMIOS systems that have seperate input and output line speed settings imbedded in the flags. Many other minor bug fixes. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091416054500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 14 Sep 90 12:15:10 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12280; Fri, 14 Sep 90 09:10:38 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Sep 90 16:05:45 GMT From: bu.edu!buit13!kwe@uunet.uu.net (Kent England) Organization: Boston U. Information Technology Subject: A Point about Style in Advertising Message-Id: <64321@bu.edu.bu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Back in the old days before the Internet was commercialized :-), there was a custom of not posting articles of purely commercial value on Internet mailing lists (and many Usenet newsgroups), because the Internet was overwhelmingly a subsidized research network. Posters would take pains, in answering requests for "something that does X", to at least mention their competitors' products before giving their advice on how to use their own commercial product. It seemed like a nice touch that made the intent of the posting seem more informational than commercial. Those people (and I am thinking about one in particular) still post articles of noteworthy breadth and brevity, and those postings make me respect their own products the more. Perhaps there are as many of the old-style informational postings as there ever were, but there are many more posters who don't bother these days, so it seems as if there is less informational content overall, in my opinion. I miss those old fashioned postings. Purely commercial blather I can get elsewhere. From the Internet, I expect better. Would it be so much trouble to put a little more information, a little more survey, and a little less marketing boilerplate in your public offerings to this and other lists/newsgroups? Really, I think it would help you more than not, in terms of public perception. Thank you for your support. --Kent ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091416464300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 15 Sep 90 05:56:22 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07668; Sat, 15 Sep 90 05:47:43 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Sep 90 16:46:43 GMT From: hpda!hpcuhb!hpsqf!hpopd!richi%hpopd.HP.COM@ucbvax.Berkeley.EDU (Richard Jennings) Organization: HP PWD, Pinewood UK. Subject: Re: SLIP source wanted for HP9000/340 Message-Id: <9390004@hpopd.HP.COM> References: <1990Jun1.074348.7712@ecn.nl> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil / hpopd:comp.protocols.tcp-ip / milburn@me10.lbl.gov (John Milburn) / 5:22 pm Jun 6, 1990 / Well, this makes about 50 requests over the last year or so in this forum, with absolutely no response from hp. The response is no better from sales reps :-). Is there any hope that slip or cslip will be available sometime in the near future, or should I just give up and buy a couple or Sun machines? This is important! Please let us know. -jem JEMilburn@lbl.gov ...!ucbvax!lbl.gov!JEMilburn ---------- John, Firstly, I'm unconnected with the networking guys - I just happen to know that HP will be shipping a version of PPL SLIP this month. The product will initially be UNSUPPORTED, however. You should ask your HP rep. to get it for you. (If she doesn't yet know about it, tell her to contact Karen Choy at HP IND!) "Hope This Helps" Disclaimer: this posting is on behalf of myself, as an individual, and does not necessarily contain or represent opinions of my employers. Richard Jennings Software Development Engineer Pinewood Information Systems Division (formerly OPD), the home of AIMS, OpenMail and Multi-Media Communications Hewlett-Packard Nine Mile Ride Wokingham Berkshire RG11 3LL England Phone: +44 344 763 738 Fax: +44 344 763 440 email: richi@hpopd.HP.COM ...!hplabs!hpopd!richi ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091416534800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 14 Sep 90 15:56:39 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23134; Fri, 14 Sep 90 15:44:11 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Sep 90 16:53:48 GMT From: usc!cs.utexas.edu!ntvaxb!snms4@ucsd.edu Subject: PC-Based Usenet News reader Message-Id: <34725.26f10b1c@vaxb.acs.unt.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm searching for a PC-Based Usenet news reader. Would anyone please send me any information they have on such an animal? If any of you are using such a thing already, I'd be very interested in your impressions, likes & dislikes. Please send mail directly to me at either SNMS4@UNTVAX on BITNET or SNMS4@VAXA.ACS.UNT.EDU on the Internet, so I won't miss your replies. I'll summarize to the Net. Thanks, -Kevin Mullet University of North Texas ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009151613.AA10460@ucbvax.Berkeley.EDU] <1990091418154400> From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: SIGCOMM '91 Call for Papers Message-ID: <9009151613.AA10460@ucbvax.Berkeley.EDU> Date: 14 Sep 90 18:15:44 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 87 Posted: Fri Sep 14 19:15:44 1990 [Hi folks -- SIGCOMM '90 is just around the corner so it's time for me to start trolling for papers for SIGCOMM '91 -- craig] Call For Papers ACM SIGCOMM '91 CONFERENCE Communications Applications, Architectures and Protocols ETH Zurich, Zurich, Switzerland September 4-6, 1991 (Tutorials September 3, 1991) The conference provides an international forum for the presentation and discussion of communication network applications and technologies, as well as recent advances and proposals on communication architectures, protocols, algorithms, and performance models. It is the first time that SIGCOMM will hold its conference outside of the United States. Authors are invited to submit full papers concerned with both theory and practice. The areas of interest for the conference include, but are not limited to the following: Analysis and design of computer network architectures and algorithms, innovative results in local area networks, computer-supported cooperative work, network interconnection and mixed-media networks, high-speed networks, resource sharing in distributed systems, network management, distributed operating systems and databases, protocol specification, verification, and analysis. Papers should be about 20 double-spaced pages long and should have an abstract of 100-150 words. All submitted papers will be reviewed and will be judged with respect to their quality and relevance. Authors of accepted papers will be expected to sign an ACM copyright release form. The Proceedings will be distributed at the conference and published as a special issue of ACM SIGCOMM Computer Communication Review. Notable papers will be considered for publication in ACM Transactions on Computer Systems. Submit 5 copies of each paper to the program chairman (or in the US, the US program committee contact): Prof. Bernhard Plattner Technische Informatik und Kommunikationsnetze Telephone: +41 1 254 7000 ETH-Zentrum (IFW) Fax: +41 1 262 3973 8092 Zurich, Switzerland EMAIL: or The US program committee contact is: Greg Wetzel AT&T Bell Laboratories Telephone: +1 (708) 979-4782 M/S IH 1B-213 Fax: +1 (708) 979-2350 2000 N. Naperville Road E-Mail: gfw@pueblo.att.com Naperville, IL 60566 For more information about the conference, e-mail to sicomm91@nri.reston.va.us Special session: Applications of High Speed Networks One or more sessions of the conference will be devoted to the subject of applications of high speed networks. Papers in these sessions will focus on concepts, implementation and experience of applications that need the performance that future high speed networks will offer. Topics include, but are not limited to new approaches to computer-supported cooperative work, graphic visualization, and access to supercomputers. Papers submitted for these topics should address applications and their communications requirements. Student Paper Award Papers submitted by students will enter a student-paper award contest. Among the accepted papers, a maximum of four outstanding papers will be awarded (1) full conference registration and (2) a travel grant of $500 US dollars. To be eligible the student must be the sole author or a primary contributor to the paper. IMPORTANT DATES Deadline for paper submission: March 2, 1991. Notification of acceptance: April 30, 1991. Camera ready papers due: May 31, 1991. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [89@organpipe.UUCP] <1990091418493000> From: royce@scor_az.resp-sci.arizona.edu (Royce Robbins) Newsgroups: comp.dcom.lans,comp.protocols.appletalk,comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Ethernet_AppleTalk_routing_using_PCRoute Message-ID: <89@organpipe.UUCP> Date: 14 Sep 90 18:49:30 GMT Sender: news@organpipe.UUCP Followup-To: comp.dcom.lans Organization: University of Arizona, Tucson, AZ Lines: 139 Posted: Fri Sep 14 19:49:30 1990 Ok, Ethernetters, AppleTalkers and PCRouters, here's my problem. 2 What I've got: Two separate networks, one on 10Base2 carrying NFS (TCP/IP) traffic, and connected to the world via PCRoute, and one on the original AppleTalk cable running TOPS. I have the following software: TOPS (Mac & PC versions), AppleShare PC, PCRoute 2.1 (Thanks to Vance Morrison for some great software!), PC-NFS, NCSA Telnet 2.3?? (Mac and PC versions), MacTCP. PC PC PC PC PC | | | | | T-----+----+---------+---+----+---+----+----T (Thinwire Ethernet) | | +-+--+ +--+----+ +Sun4+ | a PC | +----+ |running+------->"The World" |PCRoute| +-------+ +-------------+ |Apple Laser | |Writer II NTX| +------+------+ | +----------+-----+-----+-----------+ (LocalTalk) | | | | Mac SE Mac SE/30 Mac IIx Apple IIgs What I want: The two networks bridged through PCRoute, providing telnet access from the Macs to the Sun4 and the rest of the world, and access to the LaserWriter from the Sun4. PC PC PC PC PC | | | | | T-----+----+---------+---+----+---+----+----T (Thinwire Ethernet) | | +-+--+ +--+----+ +Sun4+ +-------------+ | a PC | +----+ |Apple Laser | |running+------->"The World" |Writer II NTX| |PCRoute| +------+------+ +----+--+ | | +----------+-----+-----+--------+--+ (LocalTalk) | | | | Mac SE Mac SE/30 Mac IIx Apple IIgs Background: I set up and installed the networks myself, and learned of and installed PCRoute to enable us to connect to the outside world. This was done because it is unquestionably "a neat thing" but was done essentially with no support or blessing from the powers that be (other than coughing up the bucks for two WD8003E cards). Given such a tremendous lack of support a $2-3K FastPath, GatorBox etc. is out of the question. I _might_ be able to spend $500 in several sureptitious increments. Again, my main reason for wanting to do this is that I feel it is "a neat thing" AND I really want to be able to print to that LaserWriter from my Sun4. This is real hard to justify to the powers that be who purchase a PC to be used as a dedicated HP Laserjet server!!! According to the documentation for PCRoute: "PCRoute supports IP inside of LocalTalk. This allows you to send IP packets through LocalTalk nets.... In addition any Macs on the LocalTalk network that have MacTCP can access the IP network. Note, however that PCRoute does NOT support encapsulating AppleTalk in IP (thus Ushar and CAP will not work), and does NOT support dynamic IP address assignment." The docs further say that PCRoute does not access the LocalTalk card directly, but instead goes through the device driver (ATALK.EXE) that comes with the card. (Hah! my card had no such beast, because it didn't come with a disk!) PCRoute has been configured for two Ethernet and one AppleTalk interfaces, and appears to start-up correctly. It does correctly (and quite amiably) pass Ethernet packets (you got this didn't you?). However, I have tried using MacTCP and don't seem to be able to talk to the Ethernet from the Macs. I have both a genuine AppleTalk PC card and a TOPS Flashcard available. Currently the Flashcard is installed in PCRoute because the AppleTalk card will not work at bus speeds above 8MHz and I am using a 10MHz XT to run PCRoute. Trust me, it doesn't! (The 8MHz XT motherboard I have will not work with the WD8003E cards needed. Why? Beats me!) Below is my PCRoute log file. I know the LocalTalk interface has the same network number as the second ethernet interface. I'ld prefer not to have to get a new number. Please don't tell me that's all there is to it. ******* PCroute starting ******* Interface 1 (ethernet) Address xxx.yyy.aaa.20 NetMask 255.255.255.0 Flags 0018H Metric 0001H The Ethenet Address 0000H The Ethenet Address C088H The Ethenet Address 6F18H Interface 2 (ethernet) Address xxx.yyy.zzz.13 NetMask 255.255.255.0 Flags 0018H Metric 0001H The Ethenet Address 0000H The Ethenet Address C057H The Ethenet Address CE18H Interface 3 (localtalk) Address xxx.yyy.zzz.33 NetMask 255.255.255.0 Flags 0018H Metric 0001H The Localtalk Network 0000H The Localtalk Node ID 00A1H STATIC ROUTES Forwarding BOOTP requests to 0.0.0.0 Logging messages to SYSLOGD on host xxx.yyy.zzz.1 Logging level 0007H Logging mask 0002H ******* PCroute closing log file ******* Cry for HELP: Is there anyone out there that is real familiar with PCRoute and can help me set up things correctly? Any ideas regarding how to print to the LaserWriter? Can this even be done? I've exhausted my campus' expertise, and they all say it can't be done, although noone around here has tried it. Assuming it CAN be done, it seems there are a lot of people out there buying FastPaths and Gatorboxes that they don't need! Any help would be greatly appreciated and I'll be happy to post a summary. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Royce Robbins INTERNET: royce@resp-sci.arizona.edu Div Resp Sciences FAX: (602) 626-4884 UofArizona PHONE: (602) 626-5022 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091509053900> Received: from salt.acc.com by NIC.DDN.MIL with TCP; Sat, 15 Sep 90 10:07:01 PDT Received: from SATURN.ACC.COM by salt.acc.com (5.61/1.34) id AA23489; Sat, 15 Sep 90 10:07:17 -0700 Received: by saturn.acc.com (5.51/1.28) id AA14719; Sat, 15 Sep 90 13:05:39 EDT Date: Sat, 15 Sep 90 13:05:39 EDT From: teb%saturn.ACC.COM@salt.acc.com (Tom Benkart) Message-Id: <9009151705.AA14719@saturn.acc.com> To: tcp-ip@nic.ddn.mil Subject: IP over HDLC Is anyone familiar with a package from Sun that provides IP connectivity over point-to-point HDLC lines? Are the IP datagrams inserted directly into the HDLC/LAPB frames, or does another protocol layer sit in between? Tom Benkart ACC ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091603230300> Received: from ucla-an.anes.ucla.edu by NIC.DDN.MIL with TCP; Sun, 16 Sep 90 15:07:59 PDT Return-Path: Received: by ucla-an.anes.ucla.edu (Sendmail 5.61/1.03) id AA25058; Sun, 16 Sep 90 15:03:03 -0700 Date: Sun, 16 Sep 90 15:03:03 -0700 From: Stan Stead Message-Id: <9009162203.AA25058@ucla-an.anes.ucla.edu> To: tcp-ip@nic.ddn.mil Subject: XMH Could someone direct me to where the XMH, the X windows MH mail handler can be obtained. Thank you. Stan stan@anes.ucla.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091605513200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 15 Sep 90 23:12:13 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23701; Sat, 15 Sep 90 23:01:37 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Sep 90 05:51:32 GMT From: oscsunb!OAR.NET!kannan@tut.cis.ohio-state.edu (Kannan Varadhan) Subject: Re: Telnet/telnet release Message-Id: <9009160551.AA22888@manhandler.oar.net> References: <9009142228.AA01403@berserkly.cray.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil From: dab@BERSERKLY.CRAY.COM (David Borman) Date: 14 Sep 90 22:28:38 GMT > A new BSD version of telnet and telnetd are now available for anonymous > ftp from ucbarpa.berkeley.edu. There are two files: > > pub/telnet.90.09.14.tar.Z All the sources > pub/telnet.90.09.14.diff.Z Diffs from telnet.90.06.28 Dave, and any of you who picked this up, there is a typo in the telnetd source. I made the following changes below... I am compiling this on a Sun 3/60, running SunOS4.0.3. manhandler telnetd. rcsdiff sys_term.c =================================================================== RCS file: RCS/sys_term.c,v retrieving revision 1.1 diff -r1.1 sys_term.c 87c87 < # define tcgetattr(f, t) iotcl(f, TCGETS, t) --- > # define tcgetattr(f, t) ioctl(f, TCGETS, t) 96c96 < # define tcgetattr(f, t) iotcl(f, TIOCGETA, t) --- > # define tcgetattr(f, t) ioctl(f, TIOCGETA, t) Kannan -=- Kannan Varadhan, Internet Engineer, OARNet Ohio Supercomputer Center, Columbus, OH 43212 +1 (614) 292-4137 email: kannan@oar.net | osu-cis!malgudi.oar.net!kannan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091611442000> Received: from husc9.harvard.edu by NIC.DDN.MIL with TCP; Sun, 16 Sep 90 13:24:58 PDT Date: Sun, 16 Sep 90 15:44:20 EDT From: moghe@husc9.harvard.edu Message-Id: <9009161944.AA07853@husc9.harvard.edu> To: tcp-ip@nic.ddn.mil Subject: Re: SNMP info and TCP/IP test programs Newsgroups: comp.protocols.tcp-ip In-Reply-To: <11384.653152095@cheetah.ca.psi.com> References: <1340@hawk.nstn.ns.ca> Organization: Harvard University Science Center Cambridge, MA In article <11384.653152095@cheetah.ca.psi.com> you write: >Send a note to snmp-request@nisc.psi.net and ask to be added to the snmp >list. > >/mtr Do you know if there is a public domain SNMP manager/monitor available that run on X windows under Interactive Systems 386ix Unix? Thank you. Regards, moghe@husc9 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091617375200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 17 Sep 90 10:21:18 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03612; Mon, 17 Sep 90 10:11:29 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Sep 90 17:37:52 GMT From: snorkelwacker!usc!phad.hsc.usc.edu!mcitron@BLOOM-BEACON.MIT.EDU (Mark Citron) Organization: University of Southern California, Los Angeles, CA Subject: ibm 3270 emulation for SCO telnet Message-Id: <27174@usc.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Can anyone tell me if it is possible to get SCO's (Unix or Xenix) telnet to emulate an IBM 3270 terminal. This emulation seems possible via the pc/telnets that are available but I need to make it possible for UNIX users to logon to IBM systems as 3270 terminals. ANY help would be greatly appreciated. Thanks Mark Citron 213 669-4683 mcitron@phad.hsc.usc.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091709520400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 17 Sep 90 14:05:04 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13283; Mon, 17 Sep 90 14:00:05 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 09:52:04 GMT From: sdd.hp.com!uakari.primate.wisc.edu!samsung!munnari.oz.au!uniwa!aldetec!mawson@decwrl.dec.com (Graeme Mawson) Organization: Aldetec Pty Ltd, Perth West Australia Subject: TCP segment size -- user defined? Message-Id: <266@aldetec.oz.au> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We are presently experimenting with the TCP/IP protcol suite over an Ethernet LAN. A useful guide to TCP/IP by Comer seems to suggest that TCP segment size is user-definable. Is this true? Does anyone know how to define it? Any help will be gretly appreciated! Graeme Mawson. Aldetec Pty Ltd. -- Internet: mawson@aldetec.oz.au Perth, Western Australia. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091710025700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 17 Sep 90 14:56:38 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA14646; Mon, 17 Sep 90 14:32:53 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 10:02:57 GMT From: mcsun!ukc!slxsys!jpp@uunet.uu.net (John Pettitt) Organization: Specialix International, London Subject: TCP/IP over ISDN Message-Id: <1990Sep17.100257.9110@specialix.co.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Well ? has anybody done it ? I am told that I can get call setup times of the order of 200ms over ISDN. If this is true it should be possible to `fake' a connected all the time link using ISDN thus saving the cost of a leased line. This does sound rather too good to be true. Comments ? -- John Pettitt, Specialix International, Email: jpp@specialix.com Tel +44 (0) 9323 54254 Fax +44 (0) 9323 52781 Disclaimer: Me, say that ? Never, it's a forged posting ! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091722281700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 17 Sep 90 16:51:22 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19112; Mon, 17 Sep 90 16:38:58 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 22:28:17 GMT From: van-bc!ubc-cs!kiwi!dssmv2!fischer@ucbvax.Berkeley.EDU (Roger Fischer) Subject: RPC server and fork() Message-Id: <2349@kiwi.mpr.ca> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil A while ago there was a discussion about RPC servers forking a child task to do the server function. I did not participate in that discussion. When I run into the same problem a colleague showed me some of the articles. Here I would like to present a possible solution. Comments would be greatly appreciated. The problem I still have is how to return an error message when I can't fork any more tasks or when the fork failed. pmap_unset( PDIPROG, PDIVERS); transport = svctcp_create( RPC_ANYSOCK, 0, 0); svc_register( transport, PDIPROG, PDIVERS, pdirpprog_1, IPPROTO_TCP); while (TRUE) { new_socket = accept( transport->xp_sock, &caller_adr, &addr_len); new_transport = svcfd_create( new_socket, 0, 0); new_transport->xp_raddr = caller_addr; new_transport->xp_addrlen = addr_len; if (no_more_forks) svcerr_systemerr( new_transport); /* maximum # of children exceeded */ else { child_pid = fork(); if (child_pid < 0) svcerr_systemerr( new_transport); /* fork failed */ else if (child_pid > 0) { svc_destroy( transport); svc_run(); /* should never get here */ svc_destroy( new_transport); } else svc_destroy( new_transport); } } /* should never get here */ svc_destroy( transport); Roger ---------------------------------------------------------------------------- Roger W. Fischer fischer@mprgate.mpr.ca fischer@mprgate.UUCP ..seismo!ubc-cs!mprgate!fischer ...ihnp4!alberta!ubc-cs!mprgate!fischer ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091723531100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 17 Sep 90 17:50:11 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21537; Mon, 17 Sep 90 17:41:13 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 23:53:11 GMT From: usc!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!olson@ucsd.edu (Bob Olson) Organization: University of Illinois, Urbana-Champaign Subject: Compressed Slip Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Has anyone gotten compressed slip to work as a loadable device driver on the NeXT? Is there any documentation available for writing loadable device drivers? --bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091723582600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 17 Sep 90 23:50:30 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01157; Mon, 17 Sep 90 23:46:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 23:58:26 GMT From: swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!bruce!monu1!vaxc!com217v@ucsd.edu Organization: Computer Centre, Monash University, Australia Subject: UNISYS 2200/400 DCP15 Users sought Message-Id: <47226.26f5efc2@vaxc.cc.monash.edu.au> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil This is an item from comp.dcom.lans reposted to this group because on no response. From: com217v@vaxc.cc.monash.edu.au Newsgroups: comp.dcom.lans Subject: UNISYS TCP/IP help sought Message-ID: <45699.26ee6e65@vaxc.cc.monash.edu.au> Date: 12 Sep 90 17:20:37 +1000 Organization: Computer Centre, Monash University, Australia Lines: 11 We have a UNISYS 2200/412 with dual DCP15 comms processors, one of which has an Ethernet interface. The TCP/IP software we have been supplied with by UNISYS has allowed us some telnet functionality. I am looking for anyone who can give some straight forward advice as to the correct way to set it up. Is there anyone out there with UNISYS 2200/DCP15 on the internet using UNISYS DCP LAN Platform 1R1 SteveD. com217v@vaxc.cc.monash.edu.au | So long and thanks for all the fish. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091805181300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 17 Sep 90 22:50:21 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29819; Mon, 17 Sep 90 22:42:11 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Sep 90 05:18:13 GMT From: usc!chaph.usc.edu!aludra.usc.edu!cyamamot@ucsd.edu (Cliff Yamamoto) Organization: University of Southern California, Los Angeles, CA Subject: Using PCs as Terminal Servers? Message-Id: <12018@chaph.usc.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Greetings! I recently inquired about using PCs as ethernet to SLIP routers and was flooded with many helpful and useful responses. I'd like to thank all of you who responded. It looks like PCRoute is the program to use, although Karn's KA9Q package wasn't too bad either. Now, since it seems PCs can do almost anything, does anyone know if there is a software package that will make a PC into a terminal server. You know, like one of those $1500 Bridge Communication Terminal Servers that have a built-in floopy drive for logging and upload. They have about 8 - 9.6Kb serial ports on the back. If a beast like this doesn't exist, would it be easy enough to hack the KA9Q package to do something like this? Thanks in advance, Cliff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091806095900> Received: from mwunix.mitre.org by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 09:51:46 PDT Return-Path: Received: from [128.29.151.2] by mwunix.mitre.org (5.61/SMI-2.2) id AA21124; Tue, 18 Sep 90 12:50:39 -0400 Received: from localhost.mitre.org by chance.mitre.org (4.0/SMI-4.0) id AA09852; Tue, 18 Sep 90 12:50:01 EDT Message-Id: <9009181650.AA09852@chance.mitre.org> To: tcp-ip@nic.ddn.mil Subject: 3B2 interest group Date: Tue, 18 Sep 90 12:49:59 -0400 From: H. Craig McKee Is there an interest group for AT&T 3B2 computers? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091807184100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 17:35:22 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13219; Wed, 19 Sep 90 17:21:38 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Sep 90 07:18:41 GMT From: snorkelwacker!ira.uka.de!smurf!nadia!complx!pi@uunet.uu.net (Kurt Jaeger) Organization: complx, D7K Subject: Re: TCP/IP over ISDN Message-Id: <1000@complx.UUCP> References: <1990Sep17.100257.9110@specialix.co.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Sep17.100257.9110@specialix.co.uk> jpp@specialix.co.uk (John Pettitt) writes: >Well ? has anybody done it ? I am told that I can get call setup >times of the order of 200ms over ISDN. Thats right. You can get something like a "leased ISDN" which requires You to pay (e.g. here in the FRG) at least 80 hours per month of connect time, but it will connect the line in a very short time. I think the 200ms depend on the distance to the goal. >If this is true it should be possible to `fake' a connected all the >time link using ISDN thus saving the cost of a leased line. Well, but it is NOT needed to use a fast-dial ISDN line. At the recent GUUG meeting Wiesbaden I have seen a normal ISDN setup with IP over ISDN. The line had a timeout of 20 seconds and automatically redialed when there were more packets. The timeout can be configured, they said... The dialing time was approx. three seconds, so IP wont recognize it anyway. I did a telnet to a host approx. 100km away and ftp'ed from there the kernel. The transmission rate was 5.2KB/sec (hashing enabled). The company offering the software (for 386er *IX, almost all important brands) can be reached at: BinTec Computersysteme Willstaetter Strasse 30 D-8500 Nuernberg 60 Tel. 0911-99675-0 Fax. 0911-6880725 I do not have any correlations with them, except hoping to reduce my News-feed-costs :) >This does sound rather too good to be true. Comments ? It sounds very interesting, yes. Well, that solution is useful for european ISDN-lines only, I assume :( So long, PI -- pi@complx.stgt.sub.org, K.Jaeger, D7K/FRG, +49 711 8701309 Q, 30 years to go ! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091808222600> Received: from farber.harvard.edu by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 12:02:26 PDT Received: by farber.harvard.edu (5.61/Ultrix3.0-C) id AA25480; Tue, 18 Sep 90 15:02:26 -0400 Date: Tue, 18 Sep 90 15:02:26 -0400 From: ellozy@farber (Mohamed Ellozy) Message-Id: <9009181902.AA25480@farber.harvard.edu> To: tcp-ip@nic.ddn.mil Subject: Legal host names RFC 1033 (Domain Administator's Operations Guide) states ... only the following characters are recommended for use in a host name (besides the dot separator): "A-Z", "a-z", "0-9", dash and underscore On the other hand, RFC 1034 seems to disallow (or rather discourage) the use of the underscore (grammer given on page 11). What are the true rules? Thanks. Mohamed ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091808434000> Received: from WLV.IMSD.CONTEL.COM by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 20:46:12 PDT Received: by WLV.IMSD.CONTEL.COM (5.64/1.25) id AA01856; Tue, 18 Sep 90 20:23:40 -0700 Date: Tue, 18 Sep 90 20:23:40 -0700 From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) Message-Id: <9009190323.AA01856@WLV.IMSD.CONTEL.COM> To: 702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu, tcp-ip@nic.ddn.mil Subject: Re: VT220 emulation Bill: One basic question--what is your environment? Both server and client! Any marginal TELNET implementation will support a VT220. What do you mean when you say VT220 emulation? Are you referring to a simple teletype style inter- face, a VT52 interface, a 7 bit ANSI terminal interface, or a 8 bit ANSI terminal interface? Do you require DEC proprietary control sequences? Do you require multi-national character set support? Without identifying exactly what you mean by "VT220 emulation" how can any- one respond to your request information? The meaning of "VT220 emulation" is extremely dpendent upon your specific environment. Merton ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091809115900> Received: from pucc.PRINCETON.EDU by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 11:34:26 PDT Received: from MSU.BITNET by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 7609; Tue, 18 Sep 90 14:31:08 EDT Received: by MSU (Mailer R2.03B) id 8170; Tue, 18 Sep 90 14:35:23 EDT Date: Tue, 18 Sep 90 13:11:59 EDT From: Doug Nelson <08071TCP%MSU@pucc.PRINCETON.EDU> Reply-To: Doug Nelson Subject: Re: TCP/IP over ISDN To: John Pettitt , "TCP/IP list (plus more)" In-Reply-To: Message of 17 Sep 90 10:02:57 GMT from >Well ? has anybody done it ? I am told that I can get call setup >times of the order of 200ms over ISDN. If this is true it should be >possible to `fake' a connected all the time link using ISDN thus >saving the cost of a leased line. > >This does sound rather too good to be true. Comments ? Yes, it has been done, at least with a PC as a router (based on KA9Q). We have done a demo of it right here on our campus. The ISDN packet driver used in this demo was developed at the University of Michigan. I don't know what its status is - it hasn't been contributed to the public packet driver collection. This one doesn't do anything about dropping the phone call when the line is idle and redialing when it's back, but that could be added, I'm sure. Doug Nelson Michigan State University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091809133400> Received: from NineT9.TGV.COM by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 16:13:34 PDT Date: Tue 18 Sep 90 16:13:34-PDT From: L. Stuart Vance (Icarus) Subject: Re: TCP-IP board for VAX BI bus To: agate!linus!linus!mbunix.mitre.org!jsd@ucbvax.Berkeley.EDU Cc: tcp-ip@nic.ddn.mil Message-ID: <653699614.302137.VANCE@TGV.COM> In-Reply-To: <120420@linus.mitre.org> Mail-System-Version: Organization: TGV, Incorporated X-Phone: 408/427-4366 (work); 408/427-4265 (fax) X-Address: 603 Mission Street; Santa Cruz, CA 95060 (work) >Does anyone know of a board-based TCP-IP implementation which uses the VAX >BI bus other than Excelan's EXOS? If so, please provide manufacture & >product name/number. Thanks in advance. The only other companies that make board-based IP for VMS products are CMC and Interlan (Racal-Interlan, Micom-Interlan? not sure who has the IP products now). Neither of them, to my knowledge, has done a BI board product. Lots of vendors (well, 7 or 8) have host-based products though. On most newer BI systems, you should have enough spare processor power to handle the protocol processing (unless you've got it seriously loaded). -----Stuart ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091811335100> Received: from CORNELLC.cit.cornell.edu by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 13:37:47 PDT Received: from LOCAL.DOMAIN.EDU by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 9711; Tue, 18 Sep 90 16:36:55 EDT Received: by * (Mailer R2.03B) id 6151; Tue, 18 Sep 90 16:36:13 EST Date: Tue, 18 Sep 90 16:33:51 EST From: bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu> Subject: VT220 emulation To: tcp-ip@nic.ddn.mil Does anyone know of a package that supports VT220 emulation on telnet connections?? And before everybody jumps in and says FTP Associates, the man who controls the purse strings has already said that solution is too expensive. I guess the only thing likely to change his mind is if no other solution materializes. Any info?? bill bill gunshannon 702WFG@SCRVMSYS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091811400000> Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 18:57:22 PDT Received: from indetech.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA24164; Tue, 18 Sep 90 21:57:23 -0400 Received: by indetech.com (/\=-/\ Smail3.1.18.1 #18.21) id ; Tue, 18 Sep 90 18:40 PDT Received: by emerald.indetech.com (/\=-/\ Smail3.1.17.5 #17.17) id ; Tue, 18 Sep 90 18:40 PDT Message-Id: Date: Tue, 18 Sep 90 18:40 PDT From: david@indetech.com (David Kuder) To: sun-nets@umiacs.umd.edu, tcp-ip@nic.ddn.mil Subject: Using PPP or SLIP for dialup access We are starting to have employees who want to telecommute. They have low end Sun 4's at home. We also have a second site that is connected only by UUCP at the moment. Simple UUCP and terminal sessions are no longer really adequate for this anymore. We would like to run some form of IP over a serial wire. The word I've heard is that SLIP works (maybe), CSLIP is better and PPP is where things are going. We have some SLIP sources in house. We also have a PPP from Brad Clements at Clarkson Univ. I believe I could chase down CSLIP if necessary. For us network neophytes, it is hard to make a decision about which one of these to use. For instance, the PPP we have is very scant on documentation. Nothing wrong with that, we just don't know enough to use it. Here are some of the gritty details about our hardware and software. Sun 4/20 running SunOS 4.1. Sun 3/150 running SunOS 4.1. Sun 4/60 running SunOS 4.0.3. Sun 4/65 running SunOS 4.1. Telebit T2500's on most machines. V.32 capable modems on them all. So they question is: What is the best way for us to get IP going over a serial line? -- ____*_ David A. Kuder david@indetech.com \ / / Independence Technologies {sun,sharkey,pacbell}!indetech!david \/ / 42705 Lawrence Place FAX: 415 438-2034 \/ Fremont, CA 94538 Voice: 415 438-2003 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091812314700> Received: from nmdsc20.nmdsc.nnmc.navy.mil by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 13:33:06 PDT Received: by nmdsc20.nmdsc.nnmc.navy.mil (5.59/25-eef) id AA06692; Tue, 18 Sep 90 16:31:47 EDT Date: Tue, 18 Sep 90 16:31:47 EDT From: Bob Stratton Message-Id: <9009182031.AA06692@nmdsc20.nmdsc.nnmc.navy.mil> To: mckee@chance.mitre.org Cc: tcp-ip@nic.ddn.mil In-Reply-To: H. Craig McKee's message of Tue, 18 Sep 90 12:49:59 -0400 <9009181650.AA09852@chance.mitre.org> Subject: 3B2 interest group If you find one, please let me know what its address is, as I have a site full of the things! Thanks in advance! Bob Stratton | dsc3rjs@nmdsc{20 | 10}.nmdsc.nnmc.navy.mil [Internet] Stratton Systems Design | dsc3rjs@vmnmdsc.BITNET [BITNET only, please!] | +1 703 823 MIND [PSTNet] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091813000000> Received: from pucc.PRINCETON.EDU by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 14:06:04 PDT Received: from MSU.BITNET by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 4182; Tue, 18 Sep 90 17:02:44 EDT Received: by MSU (Mailer R2.03B) id 2464; Tue, 18 Sep 90 17:01:55 EDT Date: Tuesday, 18 September 1990 5:00pm ET To: tcp-ip@nic.ddn.mil From: "Bill.Simpson" <09998WAS%MSU@pucc.PRINCETON.EDU> Subject: IBM VM TCP/IP performance (part 2) revised For those of you who were wondering what in the world Doug Nelson's spiteful message was referring to, here is the old message, revised by the helpful comments sent privately (thanks all). I had given up on the thread, but it seems the issue has more life than I thought! This benchmark was conducted over the noisiest line I know of, at slow speeds, with small packets, with both large and small windows, to encourage packet loss and demonstrate transmission and syncronization handling. With the exception of NIC.DDN.MIL, all testing was done on a single connection, after midnight -- to eliminate line, route, load, or congestion variability. The packet size was 232 bytes. Optimal transfer bandwidth is: at 9600 bps: 768 bytes/second at 1200 bps: 96 bytes/second NIS.NSF.NET [35.1.1.48] is an IBM 4381P02 running VM/HPO-5 FAL 1.2.1 (according to Merit -- there is no host DNS record). I understand it to be a lightly loaded machine. The traces show less than MSS sized packets, too many retransmissions, timeouts of 20 seconds or more, and failure to combine ACKs with bidirectional data. The 10 minute transmission timeout causes many RFCs to be unavailable over serial lines (but may be configurable). The dir LIST facility is excruciatingly slow. at 9600 bps: 320, 353, 299, 382 bytes/second at 1200 bps: 54, 49 MERIT.EDU [35.1.1.42] is a Sun 3/150 running SunOs 3.5 the banner says "FTP server (version 4.115 ..." (again, no host record) I understand it to be a heavily loaded machine and therefore to be running rather slow in its response times. It is located on the same ethernet as NIS.NSF.NET, so I thought that it would make a good comparison for round trip baseline. at 1200 bps: 77, 85 TERMINATOR.CC.UMICH.EDU [old address deleted] is a Sun-3/160. the banner says "FTP server (version 4.172 ..." It is located a little farther away (6 hops) in another building at UMich. The distance didn't seem to have any effect (perhaps because it's a T1 link), and I attribute the improved performance to a lighter load. at 1200 bps: 92 So I thought that I'd try a little farther! THUMPER.BELLCORE.COM [128.96.41.1] is a Sun 4/490 running SunOs 4.1. It is 8 hops farther away than NIS.NSF.NET, over NSFnet and JVNCnet. None-the-less, the transfer rate is quite respectable. at 1200 bps: 84 The next week, just for jollies, I tried NIC.DDN.MIL. The host records says it's a DEC 2060 running Tops20. It's often difficult to get to, through some incredibly congested gateways. I did this at 16:00 EDT, which should be right in the middle of their working day out west. I pinged it for 10 minutes, in 20 sec intervals for a srtt of 2.420 sec and mdev of 0.605 sec; not counting that 2/3 of the packets were lost! Even under such adverse conditions, it outperforms the IBM. at 1200 bps: 73, 78, 74, 76 CONCLUSION: IBM-FAL for VM runs at 1/2 the speed of many of its competitors. It fails to meet several host requirements, not just for TCP/IP but for FTP and SMTP as well. Unfortunately, the only product which I am aware of with worse performance is Spartacus KNET, also for VM. For the good of the user community, I would recommend to Merit that the RFC mirror on NIS.NSF.NET be moved to a more capable machine. Bill Simpson 09998was@ibm.cl.msu.edu 09998was@msu.bitnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1112@appli.se] <1990091813585200> From: niklas@appli.se (Niklas Hallqvist) Newsgroups: comp.unix.sysv386,comp.protocols.tcp-ip,comp.protocols.nfs Subject: Problems with the rexd and rshd daemons in Interactive 386/ix 2.0.2 Summary: I have some problem with my NFS & TCP/IP network. HELP! Keywords: NFS rexd rshd TCP/IP RPC on Message-ID: <1112@appli.se> Date: 18 Sep 90 13:58:52 GMT Followup-To: comp.unix.sysv386 Organization: Applitron Datasystem AB, GOTHENBURG, SWEDEN Lines: 72 Posted: Tue Sep 18 14:58:52 1990 Hello, out there. This is a repost of an article posted to comp.unix.i386 at the time of the comp.unix.* reorganisation. I didn't get any answer then, so this time I'll broaden the distribution to include comp.protocols.{nfs,tcp-ip} on top of using the new correct newsgroup; comp.unix.sysv386! We have an ethernet network with three nodes, all of them running NFS. One of the most useful commands is on(1) which runs commands on another node but retains the environment (including the current directory). Very neat! My problem is: I can't use this facility to run programs on our 386/ix (2.0.2 core, 1.1.2 TCP/IP, 2.0 NFS). I get this error message: "on: af clnt_call..RPC: Unable to receive" sometimes, and sometimes I won't even get an error message! The logfile /tmp/rexd.log looks something like this: Sep 6 09:00 (Rpchild/10444): Child #10444 processing RPC for request REXD INFO: errno=22, msg="Invalid argument" Sep 6 09:00 (Rpchild/10444): About to fork execution child; cmd='ls' REXD INFO: errno=9, msg="Bad file number" Sep 6 09:00 (Rpchild/10444): [RPC Child: svc_fds == 0, shutting down] REXD INFO: errno=9, msg="Bad file number" or like this: Sep 6 09:02 (Rpchild/10446): Child #10446 processing RPC for request REXD INFO: errno=22, msg="Invalid argument" Sep 6 09:02 (Rpchild/10446): About to fork execution child; cmd='ls' REXD INFO: errno=9, msg="Bad file number" Sep 6 09:02 (Rpchild/10446): [RPC Child: svc_fds == 0, shutting down] REXD INFO: errno=4, msg="Interrupted system call" The other way everything works like it's expected to (e.g. running a command on our NCR Tower using the 386/ix on(1) command). Even local usages, like "on localhost ls" fails! What have I done wrong? Is there a magical kernel parameter which is wrongly set? Please help! And then there's this "remote shell" handle by /etc/rshd on the 386/ix. Very often (not always, though) my client "remsh" on another node gets hung after sending the standard input to the foreign shell. Very annoying indeed! After I kill the client the daemon continues as if nothing has happenned. It seems like the EOF gets lost on the way, but reappears if I kill the client. Another possibly related weirdness of our 386/ix system is the presence of all these strange TIME_WAIT, CLOSE_WAIT, FIN_WAIT_2 & CLOSED IP-sessions that never goes away from our netstat: Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 ix.1224 ix.111 TIME_WAIT tcp 0 0 ix.1182 nix.1181 CLOSE_WAIT tcp 0 0 ix.1181 nix.1039 CLOSE_WAIT tcp 0 0 ix.shell appli.1023 CLOSED The corresponding lines from our node "nix": (only the ones concerning "ix") tcp 0 0 nix.1181 ix.1182 FIN_WAIT_2 tcp 0 0 nix.1039 ix.1181 FIN_WAIT_2 There are no corresponding line for the CLOSED connection to node "appli" in the output from netstat on that node. What's going on here? Most things does work like X11, NFS, rlogin, rcp etc. It's just "rexd" & "rshd" that fails! Any Ideas? Niklas --- Niklas Hallqvist Phone: +46-(0)31-19 14 85 Applitron Datasystem Fax: +46-(0)31-19 80 89 N. Gubberogatan 30 Email: niklas@appli.se S-416 63 GOTEBORG sunic!chalmers!appli!niklas Sweden ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091814112100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 12:43:05 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04064; Tue, 18 Sep 90 12:36:46 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Sep 90 14:11:21 GMT From: mcsun!ukc!stl!siesoft!silver.siesoft.co.uk!jlk@uunet.uu.net (Jim Kissel) Organization: Siemens System Developement Group, Reading, UK. Subject: Re: Looking for (a working) NFS for VMS Message-Id: <1990Sep18.141121.6073@siesoft.co.uk> References: <9009112234.AA15069@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Novell has an NFS implementation for VMS. I have tested it against our DFS (MS-DOS) product (pc-nfs clone) and found it to work quite well. Try contacting manoj@xlnvax.novell.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091814341400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 13:12:42 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04674; Tue, 18 Sep 90 12:58:18 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Sep 90 14:34:14 GMT From: eru!hagbard!sunic!news.funet.fi!funic!santra!fuug!demos!dvv@bloom-beacon.mit.edu (Dmitry V. Volodin) Organization: DEMOS, Moscow, USSR Subject: SLIP over X.25 Message-Id: <1990Sep18.143414.4441@hq.demos.su> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Have anybody tried this weird combination? -- ------------------------------------+------------------------------ Dmitry V. Volodin | internet: | or | Motto coming soon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1113@appli.se] <1990091814385400> From: niklas@appli.se (Niklas Hallqvist) Newsgroups: comp.unix.sysv386,comp.protocols.tcp-ip,comp.protocols.nfs Subject: Problems with the rexd and rshd daemons in Interactive 386/ix 2.0.2 Summary: I have some problem with my NFS & TCP/IP network. HELP! Keywords: NFS rexd rshd TCP/IP RPC on Message-ID: <1113@appli.se> Date: 18 Sep 90 14:38:54 GMT Followup-To: comp.unix.sysv386 Organization: Applitron Datasystem AB, GOTHENBURG, SWEDEN Lines: 72 Posted: Tue Sep 18 15:38:54 1990 Hello, out there. This is a repost of an article posted to comp.unix.i386 at the time of the comp.unix.* reorganisation. I didn't get any answer then, so this time I'll broaden the distribution to include comp.protocols.{nfs,tcp-ip} on top of using the new correct newsgroup; comp.unix.sysv386! We have an ethernet network with three nodes, all of them running NFS. One of the most useful commands is on(1) which runs commands on another node but retains the environment (including the current directory). Very neat! My problem is: I can't use this facility to run programs on our 386/ix (2.0.2 core, 1.1.2 TCP/IP, 2.0 NFS). I get this error message: "on: af clnt_call..RPC: Unable to receive" sometimes, and sometimes I won't even get an error message! The logfile /tmp/rexd.log looks something like this: Sep 6 09:00 (Rpchild/10444): Child #10444 processing RPC for request REXD INFO: errno=22, msg="Invalid argument" Sep 6 09:00 (Rpchild/10444): About to fork execution child; cmd='ls' REXD INFO: errno=9, msg="Bad file number" Sep 6 09:00 (Rpchild/10444): [RPC Child: svc_fds == 0, shutting down] REXD INFO: errno=9, msg="Bad file number" or like this: Sep 6 09:02 (Rpchild/10446): Child #10446 processing RPC for request REXD INFO: errno=22, msg="Invalid argument" Sep 6 09:02 (Rpchild/10446): About to fork execution child; cmd='ls' REXD INFO: errno=9, msg="Bad file number" Sep 6 09:02 (Rpchild/10446): [RPC Child: svc_fds == 0, shutting down] REXD INFO: errno=4, msg="Interrupted system call" The other way everything works like it's expected to (e.g. running a command on our NCR Tower using the 386/ix on(1) command). Even local usages, like "on localhost ls" fails! What have I done wrong? Is there a magical kernel parameter which is wrongly set? Please help! And then there's this "remote shell" handle by /etc/rshd on the 386/ix. Very often (not always, though) my client "remsh" on another node gets hung after sending the standard input to the foreign shell. Very annoying indeed! After I kill the client the daemon continues as if nothing has happenned. It seems like the EOF gets lost on the way, but reappears if I kill the client. Another possibly related weirdness of our 386/ix system is the presence of all these strange TIME_WAIT, CLOSE_WAIT, FIN_WAIT_2 & CLOSED IP-sessions that never goes away from our netstat: Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 ix.1224 ix.111 TIME_WAIT tcp 0 0 ix.1182 nix.1181 CLOSE_WAIT tcp 0 0 ix.1181 nix.1039 CLOSE_WAIT tcp 0 0 ix.shell appli.1023 CLOSED The corresponding lines from our node "nix": (only the ones concerning "ix") tcp 0 0 nix.1181 ix.1182 FIN_WAIT_2 tcp 0 0 nix.1039 ix.1181 FIN_WAIT_2 There are no corresponding line for the CLOSED connection to node "appli" in the output from netstat on that node. What's going on here? Most things does work like X11, NFS, rlogin, rcp etc. It's just "rexd" & "rshd" that fails! Any Ideas? Niklas -- Niklas Hallqvist Phone: +46-(0)31-19 14 85 Applitron Datasystem Fax: +46-(0)31-19 80 89 N. Gubberogatan 30 Email: niklas@appli.se S-416 63 GOTEBORG, Sweden sunic!chalmers!appli!niklas ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091815345600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 08:38:33 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA09991; Tue, 18 Sep 90 08:36:04 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Sep 90 15:34:56 GMT From: swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!bin@ucsd.edu (Brain in Neutral) Subject: Re: Using PCs as Terminal Servers? Message-Id: <3119@uakari.primate.wisc.edu> References: <12018@chaph.usc.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil From article <12018@chaph.usc.edu>, by cyamamot@aludra.usc.edu (Cliff Yamamoto): > Now, since it seems PCs can do almost anything, does anyone know if there > is a software package that will make a PC into a terminal server. You > know, like one of those $1500 Bridge Communication Terminal Servers that > have a built-in floopy drive for logging and upload. They have about > 8 - 9.6Kb serial ports on the back. Datability (manfacturer of Vista T.S.'s) makes a product (VistaWare Server Software) for $695 that turns PC's into terminal servers. I'm not sure how much of a bargain this is. It supports 4 serial ports and 2 parallel ports, which isn't that many. If you have to buy the serial cards too, you're starting to inch up to where it might be worth just getting a real server. On the other hand, the product does include the stuff in it to translate between LAT and TCP/IP, which provides (to quote the glossy) "existing LAT-only servers with access to TCP/IP systems and TCP/IP systems with access to LAT services". You can get a free demo diskette (1-800-DIAL-DSS, NY 212-807-7800) so that you can (quoting again) "start experiencing the thrill today". I have never used the product. Paul DuBois dubois@primate.wisc.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091816212900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 09:37:28 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA11280; Tue, 18 Sep 90 09:33:41 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Sep 90 16:21:29 GMT From: cleo!mt@speedy.wisc.edu (Manolis Tsangaris) Subject: USER Level SLIP implementations Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Is it technically possible to have a user level implementation of SLIP under 4.3 BSD and its derivatives? I mean, having something like a daemon reading and writing from/to a tty and then sending/receiving from an IP socket? I understand this is not going to be as efficient as the in-kernel implementation, but it makes it much easier to experiment with various algorithms for packet compression. --mt (Manolis Tsangaris) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091816544600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 18:15:50 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA14042; Wed, 19 Sep 90 18:02:13 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Sep 90 16:54:46 GMT From: sdd.hp.com!elroy.jpl.nasa.gov!hacgate!ladcgw.ladc.bull.com!hermes!fmayhar@ucsd.edu (Frank Mayhar) Organization: Bull HN Information Systems Inc. Los Angeles Development Center Subject: Re: SLIP over X.25 Message-Id: <1990Sep19.132446@hermes.ladc.bull.com> References: <1990Sep18.143414.4441@hq.demos.su>, <1990Sep19.112128.2154@swbull.bull.se> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Sep19.112128.2154@swbull.bull.se>, love@swbull.bull.se (Love Feuer) writes: |> B.O.S. does not support UDP/IP over X.25. The reason for this is |> probably that nobody should get the very, very sick idea of running |> NFS over X.25. Untrue. While running NFS over an X.25 link is a singularly bad idea, BOS _does_ support UDP over such links. Specifically, BIND, among others, depends on UDP. We've been running a very similar setup here for several months, and it seems to be working OK. There were some startup problems, and there are still a few things that bite us occassionally, but all in all it works. -- Frank Mayhar fmayhar@hermes.ladc.bull.com (..!{uunet,hacgate}!ladcgw!fmayhar) Bull HN Information Systems Inc. Los Angeles Development Center 5250 W. Century Blvd., LA, CA 90045 Phone: (213) 216-6241 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009182032.AA05594@ucbvax.Berkeley.EDU] <1990091817115900> From: 08071TCP%MSU@PUCC.PRINCETON.EDU (Doug Nelson) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP over ISDN Message-ID: <9009182032.AA05594@ucbvax.Berkeley.EDU> Date: 18 Sep 90 17:11:59 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Doug Nelson Organization: The Internet Lines: 17 Posted: Tue Sep 18 18:11:59 1990 >Well ? has anybody done it ? I am told that I can get call setup >times of the order of 200ms over ISDN. If this is true it should be >possible to `fake' a connected all the time link using ISDN thus >saving the cost of a leased line. > >This does sound rather too good to be true. Comments ? Yes, it has been done, at least with a PC as a router (based on KA9Q). We have done a demo of it right here on our campus. The ISDN packet driver used in this demo was developed at the University of Michigan. I don't know what its status is - it hasn't been contributed to the public packet driver collection. This one doesn't do anything about dropping the phone call when the line is idle and redialing when it's back, but that could be added, I'm sure. Doug Nelson Michigan State University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091817521200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 12:27:54 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03557; Tue, 18 Sep 90 12:17:32 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Sep 90 17:52:12 GMT From: agate!linus!linus!mbunix.mitre.org!jsd@ucbvax.Berkeley.EDU (John Durand) Organization: The MITRE Corporation Subject: TCP-IP board for VAX BI bus Message-Id: <120420@linus.mitre.org> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does anyone know of a board-based TCP-IP implementation which uses the VAX BI bus other than Excelan's EXOS? If so, please provide manufacture & product name/number. Thanks in advance. --------------------------------- John Durand jsd@mbunix.mitre.org MITRE Corporation 617-271-5310 Burlington Road Bedford, MA 01730 --------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009190228.AA13902@ucbvax.Berkeley.EDU] <1990091821335100> From: 702WFG@SCRVMSYS.BITNET (bill gunshannon) Newsgroups: comp.protocols.tcp-ip Subject: VT220 emulation Message-ID: <9009190228.AA13902@ucbvax.Berkeley.EDU> Date: 18 Sep 90 21:33:51 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Posted: Tue Sep 18 22:33:51 1990 Does anyone know of a package that supports VT220 emulation on telnet connections?? And before everybody jumps in and says FTP Associates, the man who controls the purse strings has already said that solution is too expensive. I guess the only thing likely to change his mind is if no other solution materializes. Any info?? bill bill gunshannon 702WFG@SCRVMSYS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091821350300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 14:58:22 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07629; Tue, 18 Sep 90 14:47:53 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Sep 90 21:35:03 GMT From: neerma@cod.nosc.mil (Merle A. Neer) Organization: Naval Ocean Systems Center, San Diego Subject: Re: Keep-Alive within TCP Message-Id: <2261@cod.NOSC.MIL> References: <1990Sep7.002637.6209@ingres.Ingres.COM>, <59344@bbn.BBN.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil On a local net the lack of keepalives is a problem in the sense that if a problem exists in the connection 99.9999999% of the time its because the other side crashed...i.e. has lost all knowledge of the connection.....the remedy will be that tcp will reform the connection but in the meantime valuable resources (particularly on PC-type hosts) are not available to other potential connections (PC's are strapPed for buffer space and file handles)...In the larger internet if a connection has problems the problem might be in a packet switch or phone line somewhere and yes, here, tcp 's philosophY Of keeping the connection alive has validity...and the server/clients might benefit from keeping knowledge of the connection around. In lieu of working keep alives we have found it necessary to program a keepalive capabilitY above tcp in order to keep PC servers operable (due to the above mentioned phenomena). Merle ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091823352400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 18:14:51 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12350; Tue, 18 Sep 90 18:12:49 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Sep 90 23:35:24 GMT From: swrinde!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!scslwide!wsgw!smdnd!hagiwara@ucsd.edu (Takashi Hagiwara) Organization: Sony Corporation, Tokyo, Japan Subject: Re: TCP/IP over ISDN Message-Id: <1035@smdnd.sm.sony.co.jp> References: , <9009182032.AA05594@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9009182032.AA05594@ucbvax.Berkeley.EDU>, 08071TCP%MSU@PUCC.PRINCETON.EDU (Doug Nelson) writes: > >Well ? has anybody done it ? I am told that I can get call setup > >times of the order of 200ms over ISDN. If this is true it should be > >possible to `fake' a connected all the time link using ISDN thus > >saving the cost of a leased line. > > > >This does sound rather too good to be true. Comments ? Yes, it has been done. We, sony, has a unix-based workstation, it has the ISDN Interface board. (We got an apploval of PTT of Japan.) Our machine installed this board can be used as a TCP/IP gateway between Lan and ISDN. We will demonstorate TCP/IP over ISDN at InterOP '90. If anyone is interested in it, please stop by at Sony booth. Takashi Hagiwara (Hagiwara@Sm.Sony.Co.Jp) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091900072300> Received: from alpha.xerox.com by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 07:07:43 PDT Received: from PearTree.Roch817.Xerox.xns by alpha.xerox.com via XNS id <16826>; Wed, 19 Sep 1990 07:08:03 PDT X-NS-Transport-ID: 08003700611E1E0E2AA1 Date: Wed, 19 Sep 1990 07:07:23 PDT From: Samuel_A_Fedele.Roch817@xerox.com Subject: Re: Looking for Ethernet Card for EISA Bus. In-Reply-to: "usenet.ins.cwru.edu!abvax!sgtech!adnan@tut.cis.ohio-state:edu:Xerox's message of 19-September-90 (Wednesday) 7:55:34 EDT" To: tcp-ip-RELAY@NIC.DDN.MIL cc: tcp-ip@NIC.DDN.MIL Message-ID: <"19-Sep-90 10:07:23 EDT".*.Samuel_A_Fedele.Roch817@Xerox.com> An EISA NIC (NE3200) is available from Novell. This board was developed by / with Compaq. Call 1-800 - RED - WORD for info. Good Luck, Sam ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091902115300> Received: from gateway.mitre.org by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 05:52:45 PDT Return-Path: Received: by gateway.mitre.org (5.61/SMI-2.2) id AA12228; Wed, 19 Sep 90 08:52:22 -0400 Full-Name: Bill Barns Message-Id: <9009191252.AA12228@gateway.mitre.org> To: imp@solbourne.com (Warner Losh) Cc: tcp-ip@nic.ddn.mil, barns@gateway.mitre.org Subject: Re: BFTP In-Reply-To: Your message of "19 Sep 90 04:25:24 GMT." <1990Sep19.042524.13764@Solbourne.COM> Date: Wed, 19 Sep 90 08:51:53 -0400 From: barns@gateway.mitre.org Try rooting around on venera.isi.edu - I saw it there once. I don't remember the filename but I think it's all in one or two compressed tar files and there are not so many files available on that machine to make it very hard to guess which it is (I think). /Bill ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091902533000> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 09:54:34 PDT Posted-Date: Wed, 19 Sep 90 09:53:30 PDT Message-Id: <9009191653.AA22596@venera.isi.edu> Received: from LOCALHOST by venera.isi.edu (5.61/5.61+local) id ; Wed, 19 Sep 90 09:53:45 -0700 To: stan!imp@boulder.colorado.edu (Warner Losh) Cc: tcp-ip@nic.ddn.mil, deschon@venera.isi.edu Reply-To: deschon@venera.isi.edu Subject: Re: BFTP From: Annette DeSchon In-Reply-To: Your message of 19 Sep 90 04:25:24 +0000. <1990Sep19.042524.13764@Solbourne.COM> Date: Wed, 19 Sep 90 09:53:30 PDT Sender: deschon@venera.isi.edu BFTP is available via anonymous FTP from the "pub" directory on "venera.isi.edu". The current version is "BFTP.312.tar.Z". --Annette ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091903090500> Received: from ftp.com by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 08:29:59 PDT Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA14033; Wed, 19 Sep 90 11:29:05 -0500 Date: Wed, 19 Sep 90 11:29:05 -0500 Message-Id: <9009191629.AA14033@ftp.com> To: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) Subject: Re: VT220 emulation From: jbvb@ftp.com (James B. Van Bokkelen) Reply-To: jbvb@ftp.com Cc: 702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu, tcp-ip@nic.ddn.mil Sender: jbvb@ftp.com Repository: babyoil.ftp.com Originating-Client: plug.ftp.com .... Are you referring to a simple teletype style inter-face, a VT52 interface, a 7 bit ANSI terminal interface, or a 8 bit ANSI terminal interface? Do you require DEC proprietary control sequences? Do you require multi-national character set support? If it has to replace ours, he needs an IBM PC DOS VT220 emulator with 7-bit and 8-bit support, the ISO Latin character set, keyboard and display re-mapping and print screen support, built into a Telnet with a built-in FTP server and multi-session capability. Novell (Excelan) offers VT220 in their product for the EXOS205, but I don't know its capabilities. Sun, IBM and 3Com had VT100 last I knew, I don't know what Beame & Whiteside offers. One could also get a VT220 emulator from one of the Ascii emulator specialists and use it with an INT 14 Telnet redirector. I don't recall any INT 14 redirector or VT220 emulator Telnets that are free... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009190321.AA14869@ucbvax.Berkeley.EDU] <1990091903211700> From: 09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson") Newsgroups: comp.protocols.tcp-ip Subject: IBM VM TCP/IP performance (part 2) revised Message-ID: <9009190321.AA14869@ucbvax.Berkeley.EDU> Date: 19 Sep 90 03:21:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 79 Posted: Wed Sep 19 04:21:17 1990 X-Unparsable-Date: Tuesday, 18 September 1990 5:00pm ET For those of you who were wondering what in the world Doug Nelson's spiteful message was referring to, here is the old message, revised by the helpful comments sent privately (thanks all). I had given up on the thread, but it seems the issue has more life than I thought! This benchmark was conducted over the noisiest line I know of, at slow speeds, with small packets, with both large and small windows, to encourage packet loss and demonstrate transmission and syncronization handling. With the exception of NIC.DDN.MIL, all testing was done on a single connection, after midnight -- to eliminate line, route, load, or congestion variability. The packet size was 232 bytes. Optimal transfer bandwidth is: at 9600 bps: 768 bytes/second at 1200 bps: 96 bytes/second NIS.NSF.NET [35.1.1.48] is an IBM 4381P02 running VM/HPO-5 FAL 1.2.1 (according to Merit -- there is no host DNS record). I understand it to be a lightly loaded machine. The traces show less than MSS sized packets, too many retransmissions, timeouts of 20 seconds or more, and failure to combine ACKs with bidirectional data. The 10 minute transmission timeout causes many RFCs to be unavailable over serial lines (but may be configurable). The dir LIST facility is excruciatingly slow. at 9600 bps: 320, 353, 299, 382 bytes/second at 1200 bps: 54, 49 MERIT.EDU [35.1.1.42] is a Sun 3/150 running SunOs 3.5 the banner says "FTP server (version 4.115 ..." (again, no host record) I understand it to be a heavily loaded machine and therefore to be running rather slow in its response times. It is located on the same ethernet as NIS.NSF.NET, so I thought that it would make a good comparison for round trip baseline. at 1200 bps: 77, 85 TERMINATOR.CC.UMICH.EDU [old address deleted] is a Sun-3/160. the banner says "FTP server (version 4.172 ..." It is located a little farther away (6 hops) in another building at UMich. The distance didn't seem to have any effect (perhaps because it's a T1 link), and I attribute the improved performance to a lighter load. at 1200 bps: 92 So I thought that I'd try a little farther! THUMPER.BELLCORE.COM [128.96.41.1] is a Sun 4/490 running SunOs 4.1. It is 8 hops farther away than NIS.NSF.NET, over NSFnet and JVNCnet. None-the-less, the transfer rate is quite respectable. at 1200 bps: 84 The next week, just for jollies, I tried NIC.DDN.MIL. The host records says it's a DEC 2060 running Tops20. It's often difficult to get to, through some incredibly congested gateways. I did this at 16:00 EDT, which should be right in the middle of their working day out west. I pinged it for 10 minutes, in 20 sec intervals for a srtt of 2.420 sec and mdev of 0.605 sec; not counting that 2/3 of the packets were lost! Even under such adverse conditions, it outperforms the IBM. at 1200 bps: 73, 78, 74, 76 CONCLUSION: IBM-FAL for VM runs at 1/2 the speed of many of its competitors. It fails to meet several host requirements, not just for TCP/IP but for FTP and SMTP as well. Unfortunately, the only product which I am aware of with worse performance is Spartacus KNET, also for VM. For the good of the user community, I would recommend to Merit that the RFC mirror on NIS.NSF.NET be moved to a more capable machine. Bill Simpson 09998was@ibm.cl.msu.edu 09998was@msu.bitnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091904252400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 22:43:30 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17524; Tue, 18 Sep 90 22:35:55 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 90 04:25:24 GMT From: stan!imp@boulder.colorado.edu (Warner Losh) Organization: Solbourne Computers Inc. Subject: BFTP Message-Id: <1990Sep19.042524.13764@Solbourne.COM> References: <9009190228.AA13902@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil OK, I looked for bftp in all my favorite archive sites, and in the anonymous ftp list that was posted to comp.archives a while back. No luck. Does anybody know where I can get a copy? Warner -- Warner Losh imp@Solburne.com -- Warner Losh imp@Solbourne.COM Me? I'm the onion rings. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091905253600> Received: from CORNELLC.cit.cornell.edu by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 07:53:18 PDT Received: from LOCAL.DOMAIN.EDU by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1716; Wed, 19 Sep 90 10:32:31 EDT Received: by * (Mailer R2.03B) id 9016; Wed, 19 Sep 90 10:31:48 EST Date: Wed, 19 Sep 90 10:25:36 EST From: bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu> Subject: Re: VT220 emulation To: tcp-ip@nic.ddn.mil It seems that my request was not fully understood. I am looking for a PC version of TELNET with the ability to emulate a DEC VT220 terminal. I need both screen emulation and keyboard emulation. This is intended to run with packages like SCT Banner and ORACLE so it needs to be a pretty good copy of a VT220. I currently have NCSA Telnet. It doesn't do VT220. I have already suggested putting it in our selves but there are other problems with the package that make it less desirable. I also have a package called MD_DOS IP. It has VT220 emulation, however it doesn't work correctly. I have suggested fixing that but have not been given the time or boddies necessary to accomplish it. I am aware of FTP Associates and have been told it is too expensive considering the number of copies we would need. I was asked to gather information as to what alternatives there were. I personnally think fixing MD_DOS is the best bet but I don't make final decisions. I never really thought that people would think I was trying to build terminal emulation into BSD UNIX. :-( bill gunshannon 702WFG@SCRVMSYS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091905570100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 22:58:19 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17863; Tue, 18 Sep 90 22:57:21 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 90 05:57:01 GMT From: ucselx!mccurdy@ucsd.edu (mccurdy m) Organization: San Diego State University Computing Services Subject: Hughes LAT TCP/IP server crashes with task stack overflow error Message-Id: <1990Sep19.055701.1484@ucselx.sdsu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil From: mccurdy@ucselx.sdsu.edu (mccurdy m) Newsgroups: comp.protocols.tcp-ip. Subject: Problem with Hughes terminal server task stack overflow crash References: Sender: Followup-To: Distribution: world Organization: San Diego State University Computing Services Keywords: Anyone having a problem with a hughes terminal server crashing with a task stack overflow error. We are. I believe our server is running the most recent version of software. Don't know the model number, but it runs both LAT and TCP/IP. If anyone has an interest in this, I can provide additional info after talking to our network person. This problem has only been noticed when dialing in via modem, but that is the only way that we are using these servers. -mike -- Mike McCurdy * mccurdy@ucselx.sdsu.edu * ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091907060900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 20 Sep 90 09:32:44 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29694; Thu, 20 Sep 90 09:17:38 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 90 07:06:09 GMT From: excelan!manoj@ames.arc.nasa.gov (manoj @ Prod Mktg) Organization: Novell, San Jose CA. Subject: Re: Looking for (a working) NFS for VMS Message-Id: <1907@excelan.COM> References: <9009112234.AA15069@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9009112234.AA15069@ucbvax.Berkeley.EDU>, 702WFG@SCRVMSYS.BITNET (bill gunshannon) writes: > Well, we've been bitten once more by Wollongong's TCPIP for VMS. > I have found out today that their NFS cannot understand enough > of the UNIX file commands to even be usable. (No chown, No permissions, > No link()) > Does anyone know if any of the other TCPIP implemntations support > NFS?? And does it work well enough to be used with a UNIX system?? A number of vendors offer TCP/IP and NFS on a VAX/VMS.. The Novell (previously Excelan) offering is called MULTINET for VMS.. For details, pl call 800-lankind or 408-434-2300 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091907230000> Received: from lilac.berkeley.edu by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 14:27:58 PDT Received: from UCBCMSA.BITNET by lilac.berkeley.edu (5.64/1.16.26) id AA17359; Wed, 19 Sep 90 14:21:33 -0700 Message-Id: <9009192121.AA17359@lilac.berkeley.edu> Received: from CMSA.BERKELEY.EDU (CLIFF) by UCBCMSA.BITNET (Mailer R2.04) with BSMTP id 4535; Wed, 19 Sep 90 14:23:42 PDT Date: Wed, 19 Sep 90 14:23 PDT From: CLIFF%UCBCMSA.Berkeley.EDU@lilac.berkeley.edu (Cliff Frost {415} 642-5360) Subject: IBM VM TCP/IP technical shortcomings To: IBMTCP-L@PUCC.BITNET, TCP-IP@NIC.DDN.MIL In-Reply-To: IBMTCP-L at PUCC.BITNET -- Wed, 19 Sep 90 14:47:44 EDT > (Why is it the nasty comments are published, and the nice ones are sent > privately? This complaint smacks of the pot calling the kettle black, but since you ask, I asked you publically because you failed to answer either of the entirely neutral requests for information I sent you privately. Thank you for *finally* publishing some information. Cliff Frost ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091908110000> Received: from pucc.PRINCETON.EDU by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 09:25:39 PDT Received: from MSU.BITNET by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 1472; Wed, 19 Sep 90 12:09:05 EDT Received: by MSU (Mailer R2.03B) id 5425; Wed, 19 Sep 90 12:11:31 EDT Date: Wednesday, 19 September 1990 12:11pm ET To: tcp-ip@nic.ddn.mil X-Originally-To: woolf@venera.isi.edu, tcp-ip@nic.ddn.mil From: "Bill.Simpson" <09998WAS%MSU@pucc.PRINCETON.EDU> Subject: mail destroyed > Received: by TAOMLR2@MSU; Wed, 19 Sep 90 02:49:45 > Received: by TAOXRDR@MSU; id 8800; Wed, 19 Sep 90 02:49:35 EDT > Mail-From: venera.isi.edu received by IBM.CL.MSU.EDU at 19 Sep 90 02:34:15 > Date: Tue, 18 Sep 90 23:32:44 -0700 > From: woolf@venera.isi.edu (Suzanne Woolf) > Posted-Date: Tue, 18 Sep 90 23:32:44 -0700 > Message-Id: <9009190632.AA09546@venera.isi.edu> > Received: by venera.isi.edu (5.61/5.61+local) > id ; Tue, 18 Sep 90 23:32:44 -0700 > To: 09998WAS@IBM.CL.MSU.EDU > Subject: Re: IBM VM TCP/IP performance (part 2) revised > Newsgroups: comp.protocols.tcp-ip > In-Reply-To: <9009190321.AA14869@ucbvax.Berkeley.EDU> > Organization: Information Sciences Institute, Univ. of So. California > Cc: woolf@venera.isi.edu > > In article <9009190321.AA14869@ucbvax.Berkeley.EDU> you write: That was the total message as seen from here. Could you please retransmit the message? Thank you. Bill Simpson 09998was@msu.bitnet 09998was@ibm.cl.msu.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091910480000> Received: from pucc.PRINCETON.EDU by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 11:49:57 PDT Received: from MSU.BITNET by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 7435; Wed, 19 Sep 90 14:46:57 EDT Received: by MSU (Mailer R2.03B) id 9081; Wed, 19 Sep 90 14:50:54 EDT Date: Wednesday, 19 September 1990 2:48pm ET To: tcp-ip@nic.ddn.mil X-Originally-To: ibmtcp-l@pucc.bitnet, tcp-ip@nic.ddn.mil From: "Bill.Simpson" <09998WAS%MSU@pucc.PRINCETON.EDU> Subject: IBM VM TCP/IP technical shortcomings There being 5 requests for the information, I suppose that it's worthwhile to post this to the group at large. ---- ---- ---- ---- ---- First, this implementation does not bundle a reply ACK with the reply data, resulting in 2 packets. An ACK is sent right away when the PSH flag is set. This behaviour results in slow FTP startup times, and very slow throughput for short transfers such as dir LISTs. This is cited as a poor implementation practice in RFC1122 at 4.2.2.14. Similarly, the first data packet is sent separately from the handshake ACK. Minor, but significant and unexplained. ---- ---- ---- ---- ---- Secondly, there is a serious problem with the retransmission timer. On startup of successive file transfers, the host-host rtt does not seem to be remembered (as other implementations do). The timer always starts too fast, and takes several timeouts before it reaches a reasonable value. (Other implementations reach this value after 1 timeout, or 2 at most.) Then, it continues to increment! Timeouts later in the transfer come at intervals of 20 or 40 seconds, even after a smooth transmission for dozens of packets! ---- ---- ---- ---- ---- Thirdly, less than MSS sized packets are transmitted. (I opine that this is due to an error in the congestion avoidance algorithm, as it only occurs when the window:MSS ratio is greater than 2.) ---- ---- ---- ---- ---- Fourthly, a "persist" timer kicks in every 5 seconds, and flushes whatever happens to be in the buffer. (Yet another source of less than MSS sized packets.) This occurs even though the link was continuously transmitting. Since the rtt was ~2.4 seconds, this annoying source of small packets put a serious dent in the throughput. ---- ---- ---- ---- ---- Fifthly, the link itself times out after 10 minutes from startup (default). I could understand if that was for an *idle* link (10 minutes since last packet transmission), but in the middle of an active transfer?!? ---- ---- ---- ---- ---- Sixthly, the higher level protocols (FTP, SMTP) do not properly treat the TCP connection as a stream. Instead -- at least on the control connection -- the remainder of a PSHed segment is discarded. That is, PSHed segments are treated as unit records! When a properly functioning TCP combines PSHed segments per 4.2.2.2, they are not properly processed on the IBM end, resulting in a hung connection. ---- ---- ---- ---- ---- Relevant RFC1122 cites: 4.2.2.2, 4.2.2.14, 4.2.2.15, 45.2.2.17, 4.2.3.1, 4.2.3.2, 4.2.3.4, 4.2.3.5, 4.2.3.6. Hope this clears up any questions the various flamers have had! (Why is it the nasty comments are published, and the nice ones are sent privately? Not that I didn't appreciate getting them, mind you! Thanks all!) Bill Simpson 09998was@msu.bitnet 09998was@ibm.cl.msu.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091911212800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 06:43:56 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26374; Wed, 19 Sep 90 06:35:43 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 90 11:21:28 GMT From: eru!hagbard!sunic!swbull!love@bloom-beacon.mit.edu (Love Feuer) Organization: Bull AB. Subject: Re: SLIP over X.25 Message-Id: <1990Sep19.112128.2154@swbull.bull.se> References: <1990Sep18.143414.4441@hq.demos.su> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil dvv@hq.demos.su (Dmitry V. Volodin) writes: >Have anybody tried this weird combination? Yup. We have a running TCP/IP link between Norway and Sweden on two Bull DPX 2/320's. It is not a point-to-point link, but a simulated multi- node network. Bull's own little unix (B.O.S) supports TCP/IP over X.25 with extensions to some existing commands. This is the way we did it: (Simplified) Both machines has the following entries in their /etc/hosts: swbull_ix0 125.0.0.1 medoc_ix0 125.0.0.2 swbull> ifconfig ix0 swbull_ix0 publix x121 swbull> route xadd bull_ix0 swbull> route xadd medoc_ix0 medoc> ifconfig ix0 medoc_ix0 public x121 medoc> route xadd bull_ix0 medoc> route xadd medoc_ix0 If we would want to connect more machines to the same network, we would simply add some more hosts with 'route xadd'. It works rather Ok, but it is *SLOW* due to the 2400 BPS modem on medoc's side. We will soon upgrade to 9600 on medoc and that will probably help the performance a bit. B.O.S. does not support UDP/IP over X.25. The reason for this is probably that nobody should get the very, very sick idea of running NFS over X.25. Mail me if you want the more pervert details of this installation. >------------------------------------+------------------------------ >Dmitry V. Volodin | >internet: | > or | Motto coming soon. Love Feuer Bull Sweden +46-8-7284349 Mail: love@swbull.bull.se -or- {anything major}!sunic!swbull!love ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091911553400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 05:28:43 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24919; Wed, 19 Sep 90 05:25:39 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 90 11:55:34 GMT From: usenet.ins.cwru.edu!abvax!sgtech!adnan@tut.cis.ohio-state.edu (Adnan Yaqub) Subject: Looking for Ethernet Card for EISA Bus. Message-Id: <48@sgtech.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We are looking for an Ethernet card which conforms to the EISA bus architecture. We are aware of the card made by Mylex (LNE390). Does anyone know of any others? Thanks. -- Adnan Yaqub (adnan@sgtech.uucp) Star Gate Technologies 29300 Aurora Rd, Solon, OH, 44139, USA, +1 216 349 1860 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091911555700> Received: from fs3.nisc.sri.com by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 18:55:59 PDT Received: by fs3.nisc.sri.com (5.64/SRI-NISC1.0) id AA05715; Wed, 19 Sep 90 18:55:58 -0700 From: nisc@NISC.SRI.COM (SRI's NIC) Message-Id: <9009200155.AA05715@fs3.nisc.sri.com> To: tcp-ip@nic.ddn.mil Subject: Interest Groups list (List-of-Lists) has a new home. Date: Wed, 19 Sep 90 18:55:57 PDT The popular Interest Groups (List-of-Lists) file has a new home. This file provides a list of various discussion lists available to network electronic mail users. The file is now available for anonymous FTP from host ftp.nisc.sri.com (192.33.33.53) in directory netinfo. The pathname of the file is netinfo/interest-groups. There is currently no electronic mail access to this file. To keep people informed about changes to the file, there is a mailing list for List-of-Lists "update notices". When any updates are made to the file, an announcement message will be sent to the notification list. Copies of the file itself will not be sent to the list. Site representatives who maintain or redistribute copies of this file for their own networks (e.g, DECNet, Xerox, BitNet, MailNet, etc.) and who cannot access the file by Internet FTP may make arrangements to have the file sent to them, if necessary. File copies will normally not be sent to individual users. To get on or off the notification list, send requests to interest-groups-request@nisc.sri.com. To submit new descriptions of mailing lists, to update existing information, or to delete old mailing list information from the List-of-Lists, send a message to interest-groups-request@nisc.sri.com. The NISC depends on the network user population to inform us of changes to any of the network lists. We appreciate your cooperation! Thanks to Rich Zellich for the many years of effort that he put into maintaining this file. Sadly, circumstances have changed and it was not possible to continue the arrangement that worked so well over those years. SRI International Network Information Systems Center ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091914002800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 08:00:24 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27062; Wed, 19 Sep 90 07:06:57 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 90 14:00:28 GMT From: usc!samsung!b-tech!zeeff@ucsd.edu (Jon Zeeff) Organization: Branch Technology Subject: Re: USER Level SLIP implementations Message-Id: References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >Is it technically possible to have a user level implementation of SLIP >under 4.3 BSD and its derivatives? There is something called the tunnel driver that allows this. I'd be interested in anyone who has slip or slfp user level code that works with this. From the README file: This is the tunnel driver for routing IP packets over other networks. In particular it can be used for rfc877 encapsualtion of IP packets over X.25 - but the kernel level driver just delivers IP packets to listening processes. The approximate steps for installation of the driver are as follows. Julian Onions (jpo@cs.nott.ac.uk) Computer Science Department Nottingham University Nottingham, NG7 2RD ENGLAND +44 602 506101 x3595 ~ ~ ~ -- Jon Zeeff (NIC handle JZ) zeeff@b-tech.ann-arbor.mi.us ----MESSAGE-END---- ----MESSAGE-BEGIN---- ["19-Sep-90.10:07:23.EDT".*.Samuel_A_Fedele.Roch817@Xerox.com] <1990091914072300> From: Samuel_A_Fedele.Roch817@XEROX.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for Ethernet Card for EISA Bus. Message-ID: <"19-Sep-90.10:07:23.EDT".*.Samuel_A_Fedele.Roch817@Xerox.com> Date: 19 Sep 90 14:07:23 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 Posted: Wed Sep 19 15:07:23 1990 An EISA NIC (NE3200) is available from Novell. This board was developed by / with Compaq. Call 1-800 - RED - WORD for info. Good Luck, Sam ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009200055.AA13915@ucbvax.Berkeley.EDU] <1990091915253600> From: 702WFG@SCRVMSYS.BITNET (bill gunshannon) Newsgroups: comp.protocols.tcp-ip Subject: Re: VT220 emulation Message-ID: <9009200055.AA13915@ucbvax.Berkeley.EDU> Date: 19 Sep 90 15:25:36 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 22 Posted: Wed Sep 19 16:25:36 1990 It seems that my request was not fully understood. I am looking for a PC version of TELNET with the ability to emulate a DEC VT220 terminal. I need both screen emulation and keyboard emulation. This is intended to run with packages like SCT Banner and ORACLE so it needs to be a pretty good copy of a VT220. I currently have NCSA Telnet. It doesn't do VT220. I have already suggested putting it in our selves but there are other problems with the package that make it less desirable. I also have a package called MD_DOS IP. It has VT220 emulation, however it doesn't work correctly. I have suggested fixing that but have not been given the time or boddies necessary to accomplish it. I am aware of FTP Associates and have been told it is too expensive considering the number of copies we would need. I was asked to gather information as to what alternatives there were. I personnally think fixing MD_DOS is the best bet but I don't make final decisions. I never really thought that people would think I was trying to build terminal emulation into BSD UNIX. :-( bill gunshannon 702WFG@SCRVMSYS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091915514500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 13:32:52 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06174; Wed, 19 Sep 90 12:46:34 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 90 15:51:45 GMT From: mcsun!ukc!dcl-cs!aber-cs!dap@uunet.uu.net (Dave Price) Organization: UCW,Aberystwyth,WALES,UK Subject: Re: TCP/IP over ISDN Message-Id: <2026@aber-cs.UUCP> References: , <9009182032.AA05594@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I was interested to hear of the PD written at Michigan. I am currently writing one for a MITEL EXPRESS Card. Can anyone tell me more about the Michigan work? Dave Price ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091917062200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 10:17:10 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01940; Wed, 19 Sep 90 10:06:33 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 90 17:06:22 GMT From: usc!samsung!uakari.primate.wisc.edu!bin@ucsd.edu (Brain in Neutral) Subject: Re: Hughes LAT TCP/IP server crashes with task stack overflow error Message-Id: <3125@uakari.primate.wisc.edu> References: <1990Sep19.055701.1484@ucselx.sdsu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil > Anyone having a problem with a hughes terminal server crashing with > a task stack overflow error. We are. I had Hughes terminal server for tryout and saw the same problem twice. I wasn't using dialin with modems, either, just two terminals. I would like to see someone say (truthfully :-) that Hughes has fixed this, because I liked the server quite a bit (we have lots of terminals on Hughes (nee Sytek) LocalNet boxes, and the command sets are very similar. -- Paul DuBois dubois@primate.wisc.edu "Was all of this because I wore a big man's hat?" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091917104100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 11:32:32 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03878; Wed, 19 Sep 90 11:24:05 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 90 17:10:41 GMT From: csusac!csuchico.edu!robin@ucdavis.ucdavis.edu (Robin Goldstone) Organization: California State University, Chico Subject: Re: VT220 emulation Message-Id: <1990Sep19.171041.4718@ecst.csuchico.edu> References: <9009190323.AA01856@WLV.IMSD.CONTEL.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9009190323.AA01856@WLV.IMSD.CONTEL.COM> mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes: >Bill: > >One basic question--what is your environment? Both server and client! Any >marginal TELNET implementation will support a VT220. What do you mean when >you say VT220 emulation? Are you referring to a simple teletype style inter- >face, a VT52 interface, a 7 bit ANSI terminal interface, or a 8 bit ANSI >terminal interface? Do you require DEC proprietary control sequences? Do >you require multi-national character set support? > >Without identifying exactly what you mean by "VT220 emulation" how can any- >one respond to your request information? The meaning of "VT220 emulation" >is extremely dpendent upon your specific environment. > >Merton Just for the record, I thought that the original poster was adequately clear in what he was looking for. From the wording of his message, it sounded like he wanted a Telnet client that would emulate a vt220. I am not a protocol expert, but it is my understanding that "vt220" is a specific DEC protocol that is fully defined. If I am running a vt220 terminal emulator and log into my vax and do a SET TERM/INQUIRE it should recognize me as a vt220. If I am not emulating a vt220, it would not recognize me as a vt220. I agree that some emulators work better than others, but I don't believe that a person has to regurgitate a complete spec to make a request to the net. So mellow out! Robin Goldstone, Systems Software Specialist California State University, Chico Computing ServiceSo mellow out! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091917452100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 11:01:36 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02940; Wed, 19 Sep 90 10:46:22 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 90 17:45:21 GMT From: agate!garnet.berkeley.edu!cliff@ucbvax.Berkeley.EDU (Cliff Frost) Organization: University of California, Berkeley Subject: Re: IBM VM TCP/IP performance (part 2) revised Message-Id: <1990Sep19.174521.24474@agate.berkeley.edu> References: <9009190321.AA14869@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9009190321.AA14869@ucbvax.Berkeley.EDU>, 09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson") writes: |> For those of you who were wondering what in the world Doug Nelson's |> spiteful message was referring to, here is the old message, revised |> by the helpful comments sent privately (thanks all). I had given up |> on the thread, but it seems the issue has more life than I thought! |> |> This benchmark was conducted over the noisiest line I know of, at slow On this list we've seen all this before. We're still waiting for you to substantiate your accusations. For those of you who aren't familiar with the product Bill.Simpson so gratuitously slams, his "benchmarks" show one thing unambiguously: Data transfer rates from nis.nsf.net are low. Wow. In his postings Bill.Simpson has said that he has proven that this is due to the software running on nis.nsf.net--specifically as opposed to the configuration of the software and hardware on that machine (which he admits he knows nothing about). He has never publically listed these failings, nor the alleged host requirements the sw fails to meet. I've asked him twice in private mail what specific software failings he has found, and several others have asked him this publically, and he has never responded. Perhaps he has found flaws, perhaps not. It's looking like we'll never know. Cliff Frost Central Computing Services UC Berkeley ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091917483200> Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 19:29:58 PDT Received: by uunet.uu.net (5.61/1.14) id AA02925; Wed, 19 Sep 90 21:48:33 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: <9009200148.AA02925@uunet.uu.net> Subject: OTA requesting feedback on NREN To: tcp-ip@nic.ddn.mil, com-priv@psi.com Date: Wed, 19 Sep 90 21:48:32 EDT Cc: tmn!cook@uunet.UU.NET Reply-To: cook%tmn@uunet.uu.net X-Mailer: ELM [version 2.3 PL6] The United States Congress Office of Technology Assessment is undertaking a study of the National Research and Education Network. The completion of the study will be in the spring of next year. Gordon Cook, the study Director, would like to use the network to collect ideas from the people in network land who will be affected by the NREN. He would be especially interested in feedback on NREN governance and the apportionment of funds between the various stakeholders, on access (should there be an institutional affiliation required), cost apportionment for users, and issues of commercialization privatization. These of course are not ALL the issues and are not meant to circumscribe input. He will credit the idaes of anyone cited from the net discussion unless they specifically ask to remain anonymous in their posting. Please reply directly to Gordon Cook (cook%tmn@uunet.uu.net), not to me. [The address will probably be cook@ota.gov w/in the next 2 weeks.] --asp@uunet.uu.net (Andrew Partan) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091917564800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 11:18:10 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03215; Wed, 19 Sep 90 10:56:55 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 90 17:56:48 GMT From: usc!cs.utexas.edu!samsung!sol.ctr.columbia.edu!ucselx!mccurdy@ucsd.edu (mccurdy m) Organization: San Diego State University Computing Services Subject: Re: Hughes LAT TCP/IP server crashes with task stack overflow error Message-Id: <1990Sep19.175648.17632@ucselx.sdsu.edu> References: <1990Sep19.055701.1484@ucselx.sdsu.edu>, <3125@uakari.primate.wisc.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <3125@uakari.primate.wisc.edu> bin@primate.wisc.edu writes: re: hughes servers crashing with task stack overflow on dial-in modems>servers>vms or unix ... >I had Hughes terminal server for tryout and saw the same problem twice. >I wasn't using dialin with modems, either, just two terminals. I would >like to see someone say (truthfully :-) that Hughes has fixed this, because >I liked the server quite a bit (we have lots of terminals on Hughes (nee >Sytek) LocalNet boxes, and the command sets are very similar. This hasn't been fixed for us and we are taking quite a bit of heat from users - needless to say. Hughes is working with us on this problem and I've also heard from a representative as a result of the original posting. I've also heard from one other person that is having a similar problem. We were also interested in the servers because of the Sytek Localnet connections. Will post the conclusion. By the way - what happens is: something happens that causes the server to crash with a "task stack overflow" error, everyone on that server gets knocked off, and the server reloads. It seems to happen on all of the servers, we havn't been able to connect the crashes to any particular event. Hughes has provided us witha sniffer to assist in the detective work. -mike -- Mike McCurdy * mccurdy@ucselx.sdsu.edu * ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091919022600> Received: from hls.com (LANSLIDE.HLS.COM) by NIC.DDN.MIL with TCP; Thu, 20 Sep 90 00:51:01 PDT Received: from nms. ([129.47.1.4]) by hls.com (4.0/SMI-4.0) id AA15847; Thu, 20 Sep 90 00:50:10 PDT Received: by nms. (4.0/SMI-4.0) id AA21419; Thu, 20 Sep 90 02:02:26 PDT From: salzman@nms.hls.com (Mike Salzman) Message-Id: <9009200902.AA21419@nms.> Subject: Re: Hughes LAT TCP/IP server crashes with task stack overflow error To: mccurdy@ucsd.edu Date: Thu, 20 Sep 90 2:02:26 PDT Cc: tcp-ip@nic.ddn.mil In-Reply-To: <1990Sep19.175648.17632@ucselx.sdsu.edu>; from "mccurdy m" at Sep 19, 90 5:56 pm Organization: Hughes Lan Systems, Mt View Ca X-Mailer: ELM [version 2.2 PL0] Hi Mike, The problem you cited has been seen at a couple of sites. The message was issued by the OS in the server when stack space underflowed. It is not a bug in the sense of a software error, rather it seems to occur at a few sites, on some of their segments. The traffic mix or volume is related to this symptom. For that reason we have lent you a Sniffer and are interested in characterizing your traffic. Problems of this type, particularly when they cause a widespread interruption of service to users, are of urgent concern to us, and will be addressed immediately. You have already been contacted by engineering to set up a connection to a server. Your cooperation in gathering data and communicating the results, configurations and analyses is appreciated and will help us to resolve your problem. -- -------------------- salzman@hls.com ---------------------- Michael M. Salzman Voice (415) 966-7479 Fax (415)960-3738 Hughes Lan Systems 1225 Charleston Road Mt View Ca 94043 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091919094400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 12:15:25 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05107; Wed, 19 Sep 90 12:10:03 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 90 19:09:44 GMT From: sdd.hp.com!uakari.primate.wisc.edu!bin@ucsd.edu (Brain in Neutral) Subject: Re: Hughes LAT TCP/IP server crashes with task stack overflow error Message-Id: <3130@uakari.primate.wisc.edu> References: <1990Sep19.175648.17632@ucselx.sdsu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil From article <1990Sep19.175648.17632@ucselx.sdsu.edu>, by mccurdy@ucselx.sdsu.edu (mccurdy m): > By the way - what happens is: something happens that causes the server to crash > with a "task stack overflow" error, everyone on that server gets knocked off, > and the server reloads. It seems to happen on all of the servers, we havn't been > able to connect the crashes to any particular event. Hughes has provided us witha sniffer to assist in the detective work. When I saw the problem, the crash occurred and the server reset. The next day it happened again, but the crash reoccurred every few minutes. I got annoyed, turned it off, turned it back on the next day and (of course) never saw the problem again. But by then I had switched the active terminals back to the LocalNet and was not using the server for any "real" work. -- Paul DuBois dubois@primate.wisc.edu "Was all of this because I wore a big man's hat?" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990091920402700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 15:02:23 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA09564; Wed, 19 Sep 90 14:48:22 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 90 20:40:27 GMT From: mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu (Bob Sutterfield) Organization: Morning Star Technologies Subject: Re: SLIP over X.25 Message-Id: References: <1990Sep18.143414.4441@hq.demos.su> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Sep19.112128.2154@swbull.bull.se> love@swbull.bull.se (Love Feuer) writes: dvv@hq.demos.su (Dmitry V. Volodin) writes: Have anybody tried this weird combination? Yup. [...and then describes running TCP/IP over X.25, without mentioning SLIP.] Many X.25 implementations (ours, for instance) support IP directly, which (for routing purposes) just sees the virtual circuits as wires. I'm not sure why Mr. Volodin wants to put SLIP in the pile, though. B.O.S. does not support UDP/IP over X.25. The reason for this is probably that nobody should get the very, very sick idea of running NFS over X.25. That's odd. Far less sick things use UDP, like the Network Time Protocol and the Domain Name System. They're both entirely appropriate and necessary to run over long-haul links like X.25. I'd speculate that the reason Bull doesn't support UDP over X.25 involves NFS aesthetics less than the cost of setting up and tearing down virtual circuits for the tiny, "cheap" packets that UDP applications expect to exchange. Ask for a CLNS next time :-) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5956@hplabsz.HPL.HP.COM] <1990091922380800> From: huyn@hplabsz.HPL.HP.COM (Pierre Nam Huyn) Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip Subject: Doing NFS/RPC from a MacII Message-ID: <5956@hplabsz.HPL.HP.COM> Date: 19 Sep 90 22:38:08 GMT Organization: Hewlett-Packard Laboratories Lines: 12 Posted: Wed Sep 19 23:38:08 1990 I want to be able to do a remote procedure call (NFS/callrpc) from a MacII to workstations on the network (HP, Sun, Vax, ... all of which support NFS). These are the questions: - is this possible ? - does a NFS library exists for the Mac (product or not) ? - what system software is required (to support NFS) ? - what connectivity hardware exists to connect up the Mac to the Ethernet in order to support above ? Any pointer would be appreciated. Thanks. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092001420800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 21:16:33 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17549; Wed, 19 Sep 90 21:15:32 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Sep 90 01:42:08 GMT From: decvax.dec.com!bacchus.pa.dec.com!mogul@mcnc.org (Jeffrey Mogul) Organization: DEC Western Research Subject: Re: TCP segment size -- user defined? Message-Id: <1990Sep20.014208.7645@wrl.dec.com> References: <266@aldetec.oz.au> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <266@aldetec.oz.au> mawson@aldetec.oz.au (Graeme Mawson) writes: >We are presently experimenting with the TCP/IP protcol suite over an Ethernet >LAN. A useful guide to TCP/IP by Comer seems to suggest that TCP segment >size is user-definable. Is this true? Does anyone know how to define it? Since nobody else seems to have responded, I'll take a stab. Yes, in one sense. The TCP segment size is not a fixed value; rather, it is limited on the high side by a number of different considerations, and it should be no lower than necessary in order to get good performance. The upper limits on the size of a TCP segment are: (1) the TCP MSS option value; the receiving TCP specifies the largest segment it is willing to receive, and the sending host must abide. (2) the transmit side send buffer space limit. In BSD-based systems, this can be varied by the application program (within bounds). (3) the "Path MTU"; basically, the largest packet that can be sent from source to destination without fragmentation. (4) various considerations of the flow control and congestion control algorithms. Only #2 is under the control of the user, and in general the user would do well to leave it alone. The other limits are supposed to be set more or less automatically, in order to maximize performance. But, if you want to vary the segment size for experimental reasons, you'll probably have to modify the TCP code on both the sender and receiver; on the receiver, so that it sends a large enough MSS option, and on the sender, so that it choose the actual MSS you want it to use. (Existing TCPs often choose something like 1024 if the MSS option allows anything above that.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092007324900> Received: from p.lanl.gov by NIC.DDN.MIL with TCP; Thu, 20 Sep 90 12:33:07 PDT Received: from snow-white.lanl.gov by p.lanl.gov (5.61/1.14) id AA08522; Thu, 20 Sep 90 13:32:51 -0600 Received: from sneezy.lanl.gov by snow-white.lanl.gov (4.1/SMI-4.0) id AA23775; Thu, 20 Sep 90 13:32:49 MDT Date: Thu, 20 Sep 90 13:32:49 MDT From: cpw%snow-white@LANL.GOV (C. Philip Wood) Message-Id: <9009201932.AA23775@snow-white.lanl.gov> To: excelan!manoj@ames.arc.nasa.gov Subject: Re: Looking for (a working) NFS for VMS Cc: tcp-ip@nic.ddn.mil > The Novell (previously Excelan) offering is called MULTINET for VMS.. I thought TGV, Inc. offered MULTINET. Novell doesn't do TCP/IP. At least the ones that snuck through the door here don't. Phil Wood Los Alamos National Laboratory PS: I called the product specialist at 800-lankind and they didn't know about MULTINET either. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009210641.AA20321@ucbvax.Berkeley.EDU] <1990092008204100> From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) Newsgroups: comp.protocols.tcp-ip Subject: 9 interesting & challenging problems for Netman Message-ID: <9009210641.AA20321@ucbvax.Berkeley.EDU> Date: 20 Sep 90 08:20:41 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 46 Posted: Thu Sep 20 09:20:41 1990 Here are what we consider to be 9 interesting & challenging problems for network management (these are based on real requirements, not tedious exhaustive MIB definitions): 1. given the trace of packets between two end points on a LAN, and a FSM, petri net, lotos/csp/ccs/Estelle spec for the protocol, detect protocol (elements of procedure) errors. (easier, do the same given ASN or XDR for packet formats:-) 2. Given same data, automatically ascribe performance problems to incorrect packet size, timeout, window etc... 3. given a traffic matrixfor a LAN, automatically find the best place to partitionm the net with a bridge/switch/router (subject to any sensible topographical/logical or other constraints). 4. Find a good way to visualise the "closeness" of hosts based on the frequency with which they communicate (this is non-trivial) 5. Automatically draw a "tube" map (friendly/Metro) of the net given the topography... 6. Given a general traffic trace, detect patterns of communication involving more than 2 parties (e.g. YP or DNS lookup followed by telnet is triv. case). 7. Interpret auto-correllation between packets from/to and/or same src/dst in a sensible fashion... 8. Given a trace of packets between 2 protocol entities at layer 4, invent a pleasant and efficient programming language to describe & enable the reconstruction of application level exchanges. 9. Do all of the above for an Internet. -------- I am sure there are more - if any of these are covered by any of the public domain management tools accumulated by IETF i'd be verra interested thanks jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092010421900> Received: from TGV.COM by NIC.DDN.MIL with TCP; Thu, 20 Sep 90 17:43:43 PDT Date: Thu, 20 Sep 90 17:42:19 PDT From: adelman@TGV.COM (Kenneth Adelman) Reply-To: Adelman@TGV.COM (Kenneth Adelman) Message-Id: <900920174148.2600091c@TGV.COM> Subject: Re: Looking for (a working) NFS for VMS To: tcp-ip@nic.ddn.mil cc: cpw%snow-white@LANL.GOV, 702WFG%SCRVMSYS.bitnet%cunyvm.cuny.edu@TGV.COM (702WFG @ SCRVMSYS.bitnet @ cunyvm.cuny.edu) >>> Well, we've been bitten once more by Wollongong's TCPIP for VMS. >>> I have found out today that their NFS cannot understand enough >>> of the UNIX file commands to even be usable. (No chown, No permissions, >>> No link()) >>> Does anyone know if any of the other TCPIP implemntations support >>> NFS?? And does it work well enough to be used with a UNIX system?? >> A number of vendors offer TCP/IP and NFS on a VAX/VMS.. >> The Novell (previously Excelan) offering is called MULTINET for VMS.. > I thought TGV, Inc. offered MULTINET. Novell doesn't do TCP/IP. At least > the ones that snuck through the door here don't. TGV is the developer and manufacturer of MultiNet, and Novell is currently a distributor of ours. In addition to the full TCP/IP suite, we have an NFS Server and the ONLY NFS Client available for VAX/VMS as options what are sold with MultiNet. Our NFS products are not available through Novell, but Novell sells their "LANservice NFS" (NFS Server only) which was originally developed for EXOS but now runs over MultiNet. If you'd like more information or an evaluation copy give us a call at 800-TGV-3440 / 408-427-4366. Ken ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092011004100> Received: from bells.cs.ucl.ac.uk by NIC.DDN.MIL with TCP; Thu, 20 Sep 90 06:07:22 PDT Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id ; Thu, 20 Sep 1990 09:20:45 +0100 To: tcp-ip@nic.ddn.mil cc: netman@rutherford.ac.uk, net-management@cs.ucl.ac.uk Subject: 9 interesting & challenging problems for Netman Date: Thu, 20 Sep 90 09:20:41 +0100 From: Jon Crowcroft Here are what we consider to be 9 interesting & challenging problems for network management (these are based on real requirements, not tedious exhaustive MIB definitions): 1. given the trace of packets between two end points on a LAN, and a FSM, petri net, lotos/csp/ccs/Estelle spec for the protocol, detect protocol (elements of procedure) errors. (easier, do the same given ASN or XDR for packet formats:-) 2. Given same data, automatically ascribe performance problems to incorrect packet size, timeout, window etc... 3. given a traffic matrixfor a LAN, automatically find the best place to partitionm the net with a bridge/switch/router (subject to any sensible topographical/logical or other constraints). 4. Find a good way to visualise the "closeness" of hosts based on the frequency with which they communicate (this is non-trivial) 5. Automatically draw a "tube" map (friendly/Metro) of the net given the topography... 6. Given a general traffic trace, detect patterns of communication involving more than 2 parties (e.g. YP or DNS lookup followed by telnet is triv. case). 7. Interpret auto-correllation between packets from/to and/or same src/dst in a sensible fashion... 8. Given a trace of packets between 2 protocol entities at layer 4, invent a pleasant and efficient programming language to describe & enable the reconstruction of application level exchanges. 9. Do all of the above for an Internet. -------- I am sure there are more - if any of these are covered by any of the public domain management tools accumulated by IETF i'd be verra interested thanks jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092011083400> Received: from CORNELLC.cit.cornell.edu by NIC.DDN.MIL with TCP; Thu, 20 Sep 90 13:12:42 PDT Received: from LOCAL.DOMAIN.EDU by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 4350; Thu, 20 Sep 90 16:12:00 EDT Received: by * (Mailer R2.03B) id 8751; Thu, 20 Sep 90 16:11:13 EST Date: Thu, 20 Sep 90 16:08:34 EST From: bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu> Subject: Re: VT220 emulation To: tcp-ip@nic.ddn.mil Thanks for all the comments I got from everybody. I think the problem is solved. For those who find themselves in the same boat at some time in the future (or present) the solution is (hopefully) FTP Software. It turns out that the people who thought it was too expensive were dealing with a quantity 1 price. When site licensing and Educational discounts are taken into consideration, they become not only the best solution but also very reasonably priced. Thanks again for all the advice. bill bill gunshannon 702WFG@SCRVMSYS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092012030100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 20 Sep 90 03:46:30 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22896; Thu, 20 Sep 90 03:31:57 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Sep 90 12:03:01 GMT From: snorkelwacker!ira.uka.de!iramu1!nipper@bloom-beacon.mit.edu (Arnold Nipper) Organization: University of Karlsruhe, FRG Subject: Re: BFTP Message-Id: <90.263.12:03:01@ira.uka.de> References: <9009190228.AA13902@ucbvax.Berkeley.EDU>, <1990Sep19.042524.13764@Solbourne.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Sep19.042524.13764@Solbourne.COM> imp@Solbourne.COM (Warner Losh) writes: >OK, I looked for bftp in all my favorite archive sites, and in the >anonymous ftp list that was posted to comp.archives a while back. No >luck. Does anybody know where I can get a copy? > venera.isi.edu Arnold ******************************************************************************** Arnold Nipper *** Universitaet Karlsruhe, Am Fasanengarten 5 * nipper@ira.uka.de XLINK, Inst. fuer Betr.- und Dialogsysteme, D-7500 Karlsruhe * +49 721 608 4331 ******************************************************************************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092016043500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 20 Sep 90 12:18:45 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04503; Thu, 20 Sep 90 12:14:04 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Sep 90 16:04:35 GMT From: mcsun!ub4b!dg13!pnoe@uunet.uu.net (Pierre Noel) Organization: Commission of European Communities - DG 13 Subject: PC/TCP tnvt product with 8bits characters codes ? Message-Id: <1990Sep20.160435.3617@dg13.cec.be> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi Netland, For the time being, I have been requested to test some TCP/IP packages on PC to correctly negociate with our Unix servers. I found that PC/TCP seems to meet part of our request except that it needs a special file to remap keyboard scan codes to output character codes. More, once I've made that file and tested the connection, I found that the tnvt program, inVT220 mode (7 or 8 bit mode), strips the 8th bit of the sent caracter. The contrary is not true : an 8-bit character sent from the application to the Telnet screen is well received. Am I wrong, Have I made a stupid mistake or is it a well known problem ? I havn't found documentation on that problem on my pc/tcp books. It is for us quite a big problem due to the enormous use of the enhanced caracters in our european languages (except English...of course). Thank you for your responses ... By the way, If you know other products working on PC and giving coherent VT220 or ANSI emulation (No Excelan nor PC/NFS Telnet : I found them non-suita- ble for European emulations). Thank you for your attention. Pierre Noel ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092018124700> Received: from mathom.cisco.com by NIC.DDN.MIL with TCP; Fri, 21 Sep 90 01:14:19 PDT Date: Fri 21 Sep 90 01:12:47-PDT From: William "Chops" Westfield Subject: Re: TCP segment size -- user defined? To: decvax.dec.com!bacchus.pa.dec.com!mogul@mcnc.org cc: tcp-ip@nic.ddn.mil In-Reply-To: <1990Sep20.014208.7645@wrl.dec.com> Message-ID: <12623634027.12.BILLW@mathom.cisco.com> The upper limits on the size of a TCP segment are: : : (3) the "Path MTU"; basically, the largest packet that can be sent from source to destination without fragmentation. In theory, there isn't any reason the tcp segment size cannot be larger than the path MTU. (NFS essentially does this, though it doesn't use TCP.) In practice, there are several reasons why doing this is a rather bad idea - see Jeff's paper "Fragmentation Considered Harmful". Basically, if you make the mss larger than the mtu, you force a lot of effort at the routers (fragmentation), the destination (reassembly), and the network (if it doesn't deliver all the fragments, the entire packet has to be retransitted) BillW ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092019592400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 20 Sep 90 14:02:12 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07016; Thu, 20 Sep 90 13:51:17 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Sep 90 19:59:24 GMT From: cert!netnews.upenn.edu!dccs.upenn.edu!litwack@lll-winken.llnl.gov (Mark Litwack) Organization: University of Pennsylvania Subject: Ungermann-Bass ICMP problems Message-Id: <29878@netnews.upenn.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil It's taken me a while to finally figure this out, but it seems that Ungermann-Bass PC-NIU/ex cards occasionally send out an ICMP host unreachable message to a host that's sending too much TCP data to another host on the local ethernet. This has the effect of severing the TCP connection between the two innocent hosts. I have captured the culprit packets and the PC is cleary in the wrong. So far, it's only happened on PCs which are running Novell and U-B NetNone TCP at the same time. I also found that while Ultrix systems cause the TCP application to bomb out when it receives the packet, Suns are not affected. I guess they have some kind of sanity check for ICMP messages. Has anyone ever seen this? I'm really annoyed at U-B. Their technical support line didn't know what ICMP was and they wanted to know how many stop bits I was using so that they could re-create the problem in their lab. -mark For those who are interested, here is a sample packet for entertainment value. kiwi.dining is a PC, scotty.dccs is a DECstation 3100, remote.dccs is a uVax II. Scotty.dccs is sending data to the TCP sink socket on remote.dccs. Frame Length: 74 Slice Length: 70 Errors: None Recv Channels: tcpip ethr: Station 00 DD 01 02 DD 98 ----> scotty Type IP ip: ICMP 128 91 16 59 -> 128 91 254 4 (kiwi.dining) (scotty.dccs) Data: 0000 03 01 7C C1 00 00 00 00 45 00 04 28 C1 A9 00 00 ..|A....E..(A).. | | | -- Code (host unreachable) | -- Type (ICMP) 0010 3C 06 B8 5E 80 5B FE 04 80 5B 02 0D 11 95 00 09 <.8^.[~..[...... |-source--| |--dest---| 128.91.254.4 128.91.2.13 (scotty.dccs) (remote.dccs) 0020 0A 9E 64 01 ..d. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092021030200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 21 Sep 90 09:20:26 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00759; Fri, 21 Sep 90 09:18:44 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Sep 90 21:03:02 GMT From: ubc-cs!news-server.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!hydroesm!jtsv16!geac!tse!tim@beaver.cs.washington.edu (Tim Brecht) Organization: Toronto Stock Exchange Subject: SCO, Enet, Microchannel anyone ? Message-Id: <1990Sep20.210302.13044@tse.uucp> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Is anyone using the following combination: SCO Open Desktop, Ethernet, Microchannel. We would like contact you with some questions. tim tim@tse.uucp uunet!jtsv16!geac!tse!tim ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009202309.AA10993@ucbvax.Berkeley.EDU] <1990092021083400> From: 702WFG@SCRVMSYS.BITNET (bill gunshannon) Newsgroups: comp.protocols.tcp-ip Subject: Re: VT220 emulation Message-ID: <9009202309.AA10993@ucbvax.Berkeley.EDU> Date: 20 Sep 90 21:08:34 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 Posted: Thu Sep 20 22:08:34 1990 Thanks for all the comments I got from everybody. I think the problem is solved. For those who find themselves in the same boat at some time in the future (or present) the solution is (hopefully) FTP Software. It turns out that the people who thought it was too expensive were dealing with a quantity 1 price. When site licensing and Educational discounts are taken into consideration, they become not only the best solution but also very reasonably priced. Thanks again for all the advice. bill bill gunshannon 702WFG@SCRVMSYS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092021263800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 20 Sep 90 13:48:24 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06538; Thu, 20 Sep 90 13:34:46 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Sep 90 21:26:38 GMT From: mcsun!unido!ms@uunet.uu.net (Marc Sheldon) Organization: University of Dortmund, W-Germany Subject: Re: TCP/IP over ISDN Message-Id: <2348@unido.UUCP> References: <1990Sep17.100257.9110@specialix.co.uk>, <1000@complx.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil pi@complx.UUCP (Kurt Jaeger) writes: >>This does sound rather too good to be true. Comments ? >It sounds very interesting, yes. Well, that solution is useful for >european ISDN-lines only, I assume :( It should also work for American ISDN. The supported ISDN-hardware is capable of the American national ISDN-Standard. The only problem you will get is to find another person using the proprietary IP-over-ISDN- implementation of BinTec. But, better still, i hear that they are working on a PPP-implementation ... Coming real soon now ... We are going to offer Network-connections to UNIDO using this implementation of IP-over-ISDN in approx. 3 weeks. Marc Marc R. Sheldon e-mail : ms@Uni-Dortmund.DE University of Dortmund, CS-Department P.O.Box 500500 voice : +49 231 7552444 D-4600 Dortmund 50, West Germany FAX : +49 231 7552386 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092021295600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 20 Sep 90 16:05:02 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10688; Thu, 20 Sep 90 15:59:19 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Sep 90 21:29:56 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!bu.edu!dartvax!litle!tom@ucsd.edu (tom hampton) Organization: Litle & Co. Subject: Anyone using a Netware -> TCP/Ip Gateway? Message-Id: <514@litle.litle.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I know that both Racal Interlan and Proteon make gateway products for Netware to TCP/IP translation. Is anyone using one of these? Do they work OK? Any better ideas? Thanks for your help. =============================================================================== Tom Hampton, Mgr. New Technology, Litle & Co. | POB A218, Hanover, NH 03755 603 643 1832 ------------------------------------------------------------------------------- Design is about figuring out what you won't be able to do. ------------------------------------------------------------------------------- tom@litle.com tom@litle.uucp {backbone}!dartvax.dartmouth.edu!litle!tom =============================================================================== -- =============================================================================== Tom Hampton, Mgr. New Technology, Litle & Co. | POB A218, Hanover, NH 03755 603 643 1832 ------------------------------------------------------------------------------- Design is about figuring out what you won't be able to do. ------------------------------------------------------------------------------- tom@litle.com tom@litle.uucp {backbone}!dartvax.dartmouth.edu!litle!tom =============================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092021590000> Received: from pucc.PRINCETON.EDU by NIC.DDN.MIL with TCP; Thu, 20 Sep 90 23:00:01 PDT Received: from MSU.BITNET by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 9563; Fri, 21 Sep 90 01:56:58 EDT Received: by MSU (Mailer R2.03B) id 8630; Fri, 21 Sep 90 02:00:49 EDT Date: Friday, 21 September 1990 1:59am ET To: tcp-ip@nic.ddn.mil X-Originally-To: tcp-ip@nic.ddn.mil, ibmtcp-l@pucc.bitnet From: "Bill.Simpson" <09998WAS%MSU@pucc.PRINCETON.EDU> Subject: the flaming fool > Cliff Frost or writes: > > I've asked Mr. Simpson (twice) in private mail for the specific failings > of FAL TCP/IP. He has never responded. He still fails to include them. > I'm sorry, I didn't receive your messages. We have a very poor mail system (EMC2/TAO over Spartacus KNET) which drops messages, truncates them, mangles them, sends many of them to the postmaster because it doesn't understand legitimate message headers such as source-routes, and otherwise provides rather unreliable service. Indeed, I haven't yet received the relay of my own message to which you are replying (after 3 days)! Moreover, although I publicly offered to post more complete analysis if there was enough interest, only 3 people asked for it. I really didn't feel that it was worth my time, and the time of the newsgroup. I had already spent half a dozen hours sending private messages on the topic with IBM and Merit. > He went on (in his original posting) to publically criticize the Yorktown > team as substandard programmers, mentioning Jay Elinsky by name. > A few corrections: the word substandard is yours, not mine. I mentioned "real programmers", a term which I substitute these days for "good hacker", which has been rendered a perjorative by the media; I mentioned *two* people by name; and that was the second posting, not the first.... Actually, in the *first* posting, I merely mentioned in an off-hand way that IBM had a terrible implementation of TCP/IP on NIS.NSF.NET. Bill Rubin then *privately* asked what I disliked about their TCP/IP (admitting that they do have a terrible implementation of anonymous FTP). I put in an entire night of benchmarking and packet tracing (at my own expense), and discussed the results *privately* with Bill Rubin and Jay Elinsky, who joined later in the conversation. Now I had thought that I was discussing this with "real programmers" who were really interested in "getting it right". Instead, these fellows sent our private conversation all over IBM and Merit, causing a political uproar; 6 forwards in one case that I know about. In My Humble Opinion, "real programmers" do not publish private mail without permission, and do not start political finger-pointing instead of fixing problems. Let me give a counter-example: a few months ago, I found a case where another implementation of TCP/IP sent a *single* packet with a *single* extra byte when opening the TCP connection (for a total of 41 extra bytes). I pointed out the oversight, and made a suggestion for improvement (publicly, by the way). The programmer welcomed the criticism, and had a new version posted within 3 days! And gained my instant respect.... That's the difference between an ego that says "that's my code -- the problem must be the other guys'!" and an ego that says "that's my code -- I want it to be the best!" As far as I can tell now, the IBM guys were just marketing flacks, who took umbrage that anyone would criticize the IBM product in any way. (They kept saying "we have thousands of satisfied customers".) I never did get a message that any of the problems I found would be fixed. Apparently, they also have thousands of ignorant customers. > Given that Mr. Simpson seems willing to trash people and products by > name and without giving substantial evidence to support his > accusations, it would not be surprising if Doug Nelson responded > spitefully. In fact, I thought Mr. Nelson responded very mildly. > Doug Nelson is responsible for the very poor message system I have to live with, and the message that he posted long after the message thread had died had none of the deep technical information that you seem to demand. Looks like I have to refute and repudiate his message, too. Another day. > Unless Mr. Simpson comes up with some previously undisclosed facts the > only conclusion to draw is that he is nothing more than a "flaming" > fool. Yes, the throughput from NIS.NSF.NET is low. No, that does > not prove the software on the machine is to blame. > Perhaps you have some other explanation. Perhaps you think that a data channel on an IBM 4391 has trouble keeping up with 120 bytes per second? How do they run such things as disk drives? My tests were designed to eliminate other considerations such as the Ethernet, gateways, and load. As for flaming fools, I will note that you have at least 2 public flames without so much as a single counter-example, alterative test data, or other objective criterion on which to base your criticism. My benchmark is readily verifiable by anyone who wants to take the time (and as I clearly stated in "performance part 1", has been verified). You have wasted 2 hours and 11 minutes of my time. Bill Simpson 09998was@ibm.cl.msu.edu 09998was@msu.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092021594000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 20 Sep 90 15:20:39 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA09267; Thu, 20 Sep 90 15:16:02 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Sep 90 21:59:40 GMT From: sdd.hp.com!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!Tomobiki-Cho!mrc@ucsd.edu (Mark Crispin) Organization: Mendou Zaibatsu, Tomobiki-Cho, Butsumetsu-Shi Subject: Re: Ungermann-Bass ICMP problems Message-Id: <7894@milton.u.washington.edu> References: <29878@netnews.upenn.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <29878@netnews.upenn.edu> litwack@dccs.upenn.edu (Mark Litwack) writes: >It's taken me a while to finally figure this out, but >it seems that Ungermann-Bass PC-NIU/ex cards occasionally >send out an ICMP host unreachable message to a host that's >sending too much TCP data to another host on the local >ethernet. This has the effect of severing the TCP connection >between the two innocent hosts. This is a bug in 4.x BSD TCP. It causes all blocked open(), read(), and write() calls to fail with an error when an ICMP Destination Host (or Network) Unreachable is received. A quick fix is to patch out the entries at inetctlerrmap+8. The right fix is to fix it so only open()'s are nailed. >I also found that while Ultrix systems cause the TCP application >to bomb out when it receives the packet, Suns are not affected. >I guess they have some kind of sanity check for ICMP messages. I suspect SUNs have this or a similar bugfix. So do NeXT's. _____ | ____ ___|___ /__ Mark ("Gaijin") Crispin "Gaijin! Gaijin!" _|_|_ -|- || __|__ / / R90/6 pilot, DoD #0105 "Gaijin ha doko?" |_|_|_| |\-++- |===| / / Atheist & Proud "Niichan ha gaijin." --|-- /| |||| |___| /\ (206) 842-2385/543-5762 "Chigau. Gaijin ja nai. /|\ | |/\| _______ / \ MRC@CAC.Washington.EDU Omae ha gaijin darou" / | \ | |__| / \ / \"Iie, boku ha nihonjin." "Souka. Yappari gaijin!" Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009202237.AA09958@ucbvax.Berkeley.EDU] <1990092022375500> From: 09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson") Newsgroups: comp.protocols.tcp-ip Subject: IBM VM TCP/IP technical shortcomings Message-ID: <9009202237.AA09958@ucbvax.Berkeley.EDU> Date: 20 Sep 90 22:37:55 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 63 Posted: Thu Sep 20 23:37:55 1990 X-Unparsable-Date: Wednesday, 19 September 1990 2:48pm ET There being 5 requests for the information, I suppose that it's worthwhile to post this to the group at large. ---- ---- ---- ---- ---- First, this implementation does not bundle a reply ACK with the reply data, resulting in 2 packets. An ACK is sent right away when the PSH flag is set. This behaviour results in slow FTP startup times, and very slow throughput for short transfers such as dir LISTs. This is cited as a poor implementation practice in RFC1122 at 4.2.2.14. Similarly, the first data packet is sent separately from the handshake ACK. Minor, but significant and unexplained. ---- ---- ---- ---- ---- Secondly, there is a serious problem with the retransmission timer. On startup of successive file transfers, the host-host rtt does not seem to be remembered (as other implementations do). The timer always starts too fast, and takes several timeouts before it reaches a reasonable value. (Other implementations reach this value after 1 timeout, or 2 at most.) Then, it continues to increment! Timeouts later in the transfer come at intervals of 20 or 40 seconds, even after a smooth transmission for dozens of packets! ---- ---- ---- ---- ---- Thirdly, less than MSS sized packets are transmitted. (I opine that this is due to an error in the congestion avoidance algorithm, as it only occurs when the window:MSS ratio is greater than 2.) ---- ---- ---- ---- ---- Fourthly, a "persist" timer kicks in every 5 seconds, and flushes whatever happens to be in the buffer. (Yet another source of less than MSS sized packets.) This occurs even though the link was continuously transmitting. Since the rtt was ~2.4 seconds, this annoying source of small packets put a serious dent in the throughput. ---- ---- ---- ---- ---- Fifthly, the link itself times out after 10 minutes from startup (default). I could understand if that was for an *idle* link (10 minutes since last packet transmission), but in the middle of an active transfer?!? ---- ---- ---- ---- ---- Sixthly, the higher level protocols (FTP, SMTP) do not properly treat the TCP connection as a stream. Instead -- at least on the control connection -- the remainder of a PSHed segment is discarded. That is, PSHed segments are treated as unit records! When a properly functioning TCP combines PSHed segments per 4.2.2.2, they are not properly processed on the IBM end, resulting in a hung connection. ---- ---- ---- ---- ---- Relevant RFC1122 cites: 4.2.2.2, 4.2.2.14, 4.2.2.15, 45.2.2.17, 4.2.3.1, 4.2.3.2, 4.2.3.4, 4.2.3.5, 4.2.3.6. Hope this clears up any questions the various flamers have had! (Why is it the nasty comments are published, and the nice ones are sent privately? Not that I didn't appreciate getting them, mind you! Thanks all!) Bill Simpson 09998was@msu.bitnet 09998was@ibm.cl.msu.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092100111700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 21 Sep 90 23:55:50 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA20443; Fri, 21 Sep 90 23:46:54 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Sep 90 00:11:17 GMT From: excelan!anand@ames.arc.nasa.gov (Govindaraj Padmanaban) Organization: Novell, San Jose, CA. Subject: NASI or NCSA info wanted... Message-Id: <1921@excelan.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Where do you think I can get hold of literature on NASI and NCSA. /* * Apparently these network interfaces are put forwarded by Novell * and Network Product centre/group. But I am NOT sure. */ I need this info. It would be really great if anybody can throw some light on this. Advance Thanks. Anand +------------------------------------------------------------------------+ | We have not inherited the earth from our parents, | | but borrowed it from our children. | | Govindaraj A Padmanaban - Novell Inc. 408-473-8643(w) 408-263-7055(h) | | Email: anand@novell.COM {ames | apple | mtxinu | leadsv }!excelan!anand| +------------------------------------------------------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092100464200> Received: from ftp.com by NIC.DDN.MIL with TCP; Fri, 21 Sep 90 06:17:29 PDT Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA08608; Fri, 21 Sep 90 09:06:42 -0500 Date: Fri, 21 Sep 90 09:06:42 -0500 Message-Id: <9009211406.AA08608@ftp.com> To: tcp-ip@nic.ddn.mil Subject: Jawboning for more commercially supported distributed mail servers. From: jbvb@ftp.com (James B. Van Bokkelen) Reply-To: jbvb@ftp.com Cc: pcip@udel.edu, big-lan@suvm.bitnet, ole@csli.stanford.edu Sender: jbvb@ftp.com Repository: babyoil.ftp.com Originating-Client: plug.ftp.com Over the last few years, the issue of how to do distributed mail support within a site full of single-user workstations and PCs has attracted a good deal of attention from protocol designers, but little from commercial vendors. Protocol systems addressing this include POP2/SMTP, PCMAIL (RFC 1056), POP3/SMTP and POP3/IMAP. Functionality and details differ, but each combination manages to give the user mail access without requiring either a single central machine big enough for everyone to log in on, or the installation and maintenance nightmare of making each host act as a full mail forwarder. At the moment, there are probably almost a dozen supported commercial clients for POP2, POP3 and PCMAIL on various platforms including DOS, OS/2 and MACs. However, I did a survey earlier this summer and only turned up one new supported server (POP2) to add to the two commercial POP2 servers I already knew of. This seems somewhat lame, given the availability of mature freeware servers for all the protocols, and the great utility distributed mail represents (I'm on a commuter train using a laptop to edit this. It will get sent once I get to work. This is how I handle almost all of my mail). Why am I saying this? Not as a commercial, or a boast; Sun and IBM offered DOS clients to go with their servers long before we will (October), the first three OS/2 TCP/IPs to ship all included clients, several MAC clients exist. Instead, I think distributed mail is an idea whose time has come, and I would be pleased to see it as widespread as X in a couple of years. This won't happen unless supported servers are widely available. So, the message: Distributed mail is here, it works. Users and managers who want it supported should bend their vendors' ears. Vendors should look around and evaluate the market that's developing, the number of clients that are available. POP2 is obsolescent, I personally prefer PCMAIL, others prefer POP3 with IMAP, but in the long run timely action seems more important to me than which protocol system eventually wins. Read the RFCs, peruse the freeware and get off the dime... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092101380800> Received: from ftp.com by NIC.DDN.MIL with TCP; Fri, 21 Sep 90 06:58:23 PDT Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA09426; Fri, 21 Sep 90 09:58:08 -0500 Date: Fri, 21 Sep 90 09:58:08 -0500 Message-Id: <9009211458.AA09426@ftp.com> To: mcsun!ub4b!dg13!pnoe@uunet.uu.net (Pierre Noel) Subject: Re: PC/TCP tnvt product with 8bits characters codes ? From: jbvb@ftp.com (James B. Van Bokkelen) Reply-To: jbvb@ftp.com Cc: tcp-ip@nic.ddn.mil Sender: jbvb@ftp.com Repository: babyoil.ftp.com Originating-Client: plug.ftp.com I found that PC/TCP seems to meet part of our request except that it needs a special file to remap keyboard scan codes to output character codes. There are two files; one to change what input data individual keys generate, and one to change what received data displays on the screen. They're only needed for non-Ascii alphabets. ... I found that the tnvt program, in VT220 mode (7 or 8 bit mode), strips the 8th bit of the sent caracter. If we're the ones who strip the 8th bit when Telnet Binary is in effect, that is our bug (but I just tested 2.04 pl2; it sends 8 bit data fine). However, if the host you're talking to won't agree to Binary, or strips the 8th bit itself, that's not under our control. You need a LAN monitor of some sort to prove who's at fault. Problems relating to 8-bit telnet support are common: There are operating systems which haven't a prayer of handling 8-bit data in a useful way. Some other OSes can manage 8-bit data from a locally connected terminal well but their Telnets can't handle Binary, or don't map it to the right pseudo-tty mode. Finally, there are applications that make rash assumptions about the data path to their terminal, etc. You're not doing too badly, considering... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092102320200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 22 Sep 90 23:11:54 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA11384; Sat, 22 Sep 90 23:04:55 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Sep 90 02:32:02 GMT From: mcsun!unido!fauern!lan!marvin.e17.physik.tu-muenchen.de!bs@uunet.uu.net (Bernhard Schneck) Subject: Re: USER Level SLIP implementations Message-Id: <4570@tuminfo1.lan.informatik.tu-muenchen.dbp.de> References: , Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >>Is it technically possible to have a user level implementation of SLIP >>under 4.3 BSD and its derivatives? >There is something called the tunnel driver that allows this. I'd be >interested in anyone who has slip or slfp user level code that works >with this. I've configured if_tun into my kernel and want to try using SLIP (or PPP) over a serial line as a backup link. If anyone has implemented such a beast alreay I'll take it for free :)) >-- >Jon Zeeff (NIC handle JZ) zeeff@b-tech.ann-arbor.mi.us \Bernhard. Bernhard Schneck Internet: B.Schneck@Marvin.E17.Physik.TU-Muenchen.DE TU Muenchen Physik E17 BitNET : schneck@dgablg5p 8046 Garching West Germany ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092103111800> Received: from csli.Stanford.EDU by NIC.DDN.MIL with TCP; Fri, 21 Sep 90 10:09:46 PDT Received: by csli.Stanford.EDU (4.1/inc-1.0) id AA15401; Fri, 21 Sep 90 10:11:20 PDT Date: Fri, 21 Sep 1990 10:11:18 PDT From: Ole J. Jacobsen To: tcp-ip@nic.ddn.mil Phone: +1 415 941-3399 (Interop) or 1-800-INTEROP Or: +1 415 550-9427 (Home) or +1 415 990-9427 (Cellular) Fax: +1 415 949-1779 (Interop) +1 415 826-2008 (Home) Subject: TCP/IP over ISDN Message-Id: The Michigan ISDN work is described in the October (INTEROP) issue of ConneXions, page 27. The article is by Dory Leifer of Umich who will also be showing the ISDN implementation on the INTEROP 90 show floor. PS. The first sentence of the article has a typo which was introduced by the editor (me). It refers to ISDN as Integrated Services DATA Network instead of Digital Network. Oops, sorry, I need more AI than a spell- checker. :-) Ole J Jacobsen, Editor & Publisher ConneXions--The Interoperability Report Interop, Inc., 480 San Antonio Road, Suite 100 Mountain View, CA 94040, USA Phone: (415) 941-3399 FAX: (415) 949-1779 Email: ole@csli.stanford.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092103383000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 22 Sep 90 19:11:40 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07687; Sat, 22 Sep 90 19:01:17 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Sep 90 03:38:30 GMT From: zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!ogicse!intelhf!agora!parsely!twiki!dalew@tut.cis.ohio-state.edu (Dale A. Weber) Organization: Experimenter's Anonymous - Portland, OR USA Subject: PC-IP from Clarkson Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Apparently, the version of PC/IP I recently got from Clarkson has a bad NETDEV.SYS file in it (PCIPPKT.ARC is what I got) or there is something else wrong. Each time I try to run one of the programs from the package, they complain about an invalid or out of date NETDEV.SYS driver. Does anyone have a fix for this? I converted the *.ARC file to a *.ZIP and saved almost 200K on the size of the file. Below is the listing of the ZIP archive I have which shows the current dates on the distributed programs (exactly what I got): Searching ZIP: PCIPPKT.ZIP Length Method Size Ratio Date Time CRC-32 Attr Name ------ ------ ----- ----- ---- ---- ------ ---- ---- 32676 Implode 18839 43% 01-02-90 10:15 45e32ac3 --w BOOTP.EXE 32928 Implode 18959 43% 01-02-90 10:15 d5a6ea7d --w COOKIE.EXE 28254 Implode 15761 45% 01-02-90 13:27 921f7b5e --w CUSTOM.EXE 43924 Implode 25811 42% 01-02-90 10:15 c911a377 --w IPRINT.EXE 51372 Implode 29728 43% 01-02-90 10:15 db707601 --w LPR.EXE 145797 Implode 51916 65% 03-29-90 15:01 d3f6502a --w MANUAL.DOC 599 Implode 334 45% 03-29-90 15:26 107df475 --w NETDEV.SYS 33288 Implode 18996 43% 01-02-90 10:15 275c897d --w NETNAME.EXE 45896 Implode 25818 44% 02-26-90 09:51 065dbc7a --w NETWATCH.EXE 39392 Implode 22766 43% 01-02-90 10:15 64141b35 --w NICNAME.EXE 27 Stored 27 0% 01-02-90 10:16 f6925db5 --w OFFHOOK.COM 27 Stored 27 0% 01-02-90 10:16 77b73892 --w ONHOOK.COM 37910 Implode 22129 42% 01-02-90 10:15 e71661f8 --w PING.EXE 45448 Implode 26419 42% 01-02-90 10:15 96420d70 --w POP2.EXE 1794 Implode 1040 43% 03-29-90 15:11 e2889a69 --w RED.DOC 54374 Implode 30542 44% 01-02-90 10:15 4321fc5c --w RED.EXE 41454 Implode 23831 43% 01-02-90 10:15 7ca3fd94 --w REXEC.EXE 34872 Implode 20007 43% 01-02-90 10:16 fbdf1db8 --w SETCLOCK.EXE 8555 Implode 3181 63% 03-29-90 15:11 3f650f50 --w SMTP.DOC 44910 Implode 25994 43% 01-02-90 10:16 2e7f7ccb --w SMTP.EXE 18082 Implode 5863 68% 01-02-90 10:16 d15342e8 --w TERM.EXE 65032 Implode 37196 43% 01-02-90 10:16 bc1be762 --w TN.EXE 42266 Implode 24349 43% 01-02-90 10:16 9e4ede8a --w WHOIS.EXE ------ ------ --- ------- 848877 449533 48% 23 I would really like to get this package working so I can experiment with it and see what it can do. An assistance with this will be greatly appreciated. Thanks in advance. -- Internet: dalew@pdx.com OR dalew@twiki.pdx.com UUCP: ..!{ogicse, sun!nosun, tektronix}!tessi!twiki!dalew BBS: +1(503)239-4960 1200/2400 Bps [MNP5], 24 hours, PCPable via ORPOR WORK: Northwest Analytical, Inc. Voice: +1(503)224-7727 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092104090100> Received: from ugw.utcs.utoronto.ca by NIC.DDN.MIL with TCP; Fri, 21 Sep 90 05:11:11 PDT Received: from UNB.CA (stdin) by ugw.utcs.utoronto.ca with SMTP id 57478; Fri, 21 Sep 90 08:07:37 EDT Received: by UNBMVS1 (Mailer 14.71) id 8697; Fri, 21 Sep 90 09:09:01 ADT Date: Fri, 21 Sep 90 08:09:01 EDT From: DEDOUREK@UNB.CA To: TCP-IP@NIC.DDN.MIL Subject: Re: TCP segment size -- user defined? In-Reply-To: Message of Fri, 21 Sep 90 04:17:00 CDT from Message-ID: On Fri, 21 Sep 90 04:17:00 CDT William Chops Westfield writes: > The upper limits on the size of a TCP segment are: > : > : > (3) the "Path MTU"; basically, the largest packet that can be sent > from source to destination without fragmentation. > To avoid fragmentation, can TCP MSS be equal to path MTU, or must it be less by some number of octets to allow for TCP and IP headers? If so, what is a good value? John D. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092104210600> Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Fri, 21 Sep 90 05:23:19 PDT Received: from interlan.interlan.com by RELAY.CS.NET id aa20711; 21 Sep 90 8:23 EDT Received: from europa.InterLan.COM by interlan.interlan.com (5.61/5.17) id AA00906; Fri, 21 Sep 90 08:21:29 -0400 Received: by europa.Interlan.COM (4.0/SMI-4.0) id AA01536; Fri, 21 Sep 90 08:21:06 EDT Date: Fri, 21 Sep 90 08:21:06 EDT From: Frank Kastenholz Message-Id: <9009211221.AA01536@europa.Interlan.COM> To: 09998WAS%MSU@PUCC.PRINCETON.EDU, tcp-ip@NIC.DDN.MIL Subject: Re: the flaming fool I've been watching this go on for some time now and actually have been mildly amused by it all. However, I think that this has gone a bit too far..... In a previous life I worked "a bit" on KNET. In fact, I was the development manager of it at the time that IBM's TCP hit the street. Obviously, we at Spartacus had a desire to keep abreast of what was going on with the product. At first it was bad. All products are. It rapidly got better. Most, if not all, of this was apparently due to Jay's efforts. As an ex competitor, I would say that Jay rates being a real programmer (or at least in V=R space :-). I have not been following this area for a couple of years now. Maybe Jay's efforts were "recognized" at IBM so they promoted him out of being a techno-geek into being a management-drone. If so, I'm sorry. To keep the lawyers happy.... This message in no way reflects the opinions, etc, of Racal Interlan, or etc Spartacus/Fibronics. Everything is my own opinion. Frank Kastenholz Ex-KNET-eer ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092105434300> Received: from terminator.cc.umich.edu by NIC.DDN.MIL with TCP; Fri, 21 Sep 90 09:24:08 PDT Received: from terminator.cc.umich.edu by terminator.cc.umich.edu (5.64/1123-1.0) id AA28788; Fri, 21 Sep 90 12:23:44 -0400 Message-Id: <9009211623.AA28788@terminator.cc.umich.edu> To: mcsun!ukc!dcl-cs!aber-cs!dap@uunet.uu.net Cc: tcp-ip@nic.ddn.mil, dory_leifer@um.cc.umich.edu, mts@terminator.cc.umich.edu Subject: Re: TCP/IP over ISDN In-Reply-To: Your message of 19 Sep 90 15:51:45 +0000. <2026@aber-cs.UUCP> Date: Fri, 21 Sep 90 12:23:43 -0400 From: Michael T. Stolarchuk I'm suprised dory leifer hasn't said anything... Maybe he doesn't read tcp-ip. He has been working on tcp-ip over ISDN for over a year. He demoed his work at the last year educom at UofMichigan. I'm cc-ing him on this message in the hope that it will prompt him to send mail to tcp-ip. mts. the snail. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009210717.AA21143@ucbvax.Berkeley.EDU] <1990092107175000> From: 09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson") Newsgroups: comp.protocols.tcp-ip Subject: the flaming fool Message-ID: <9009210717.AA21143@ucbvax.Berkeley.EDU> Date: 21 Sep 90 07:17:50 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 93 Posted: Fri Sep 21 08:17:50 1990 X-Unparsable-Date: Friday, 21 September 1990 1:59am ET > Cliff Frost or writes: > > I've asked Mr. Simpson (twice) in private mail for the specific failings > of FAL TCP/IP. He has never responded. He still fails to include them. > I'm sorry, I didn't receive your messages. We have a very poor mail system (EMC2/TAO over Spartacus KNET) which drops messages, truncates them, mangles them, sends many of them to the postmaster because it doesn't understand legitimate message headers such as source-routes, and otherwise provides rather unreliable service. Indeed, I haven't yet received the relay of my own message to which you are replying (after 3 days)! Moreover, although I publicly offered to post more complete analysis if there was enough interest, only 3 people asked for it. I really didn't feel that it was worth my time, and the time of the newsgroup. I had already spent half a dozen hours sending private messages on the topic with IBM and Merit. > He went on (in his original posting) to publically criticize the Yorktown > team as substandard programmers, mentioning Jay Elinsky by name. > A few corrections: the word substandard is yours, not mine. I mentioned "real programmers", a term which I substitute these days for "good hacker", which has been rendered a perjorative by the media; I mentioned *two* people by name; and that was the second posting, not the first.... Actually, in the *first* posting, I merely mentioned in an off-hand way that IBM had a terrible implementation of TCP/IP on NIS.NSF.NET. Bill Rubin then *privately* asked what I disliked about their TCP/IP (admitting that they do have a terrible implementation of anonymous FTP). I put in an entire night of benchmarking and packet tracing (at my own expense), and discussed the results *privately* with Bill Rubin and Jay Elinsky, who joined later in the conversation. Now I had thought that I was discussing this with "real programmers" who were really interested in "getting it right". Instead, these fellows sent our private conversation all over IBM and Merit, causing a political uproar; 6 forwards in one case that I know about. In My Humble Opinion, "real programmers" do not publish private mail without permission, and do not start political finger-pointing instead of fixing problems. Let me give a counter-example: a few months ago, I found a case where another implementation of TCP/IP sent a *single* packet with a *single* extra byte when opening the TCP connection (for a total of 41 extra bytes). I pointed out the oversight, and made a suggestion for improvement (publicly, by the way). The programmer welcomed the criticism, and had a new version posted within 3 days! And gained my instant respect.... That's the difference between an ego that says "that's my code -- the problem must be the other guys'!" and an ego that says "that's my code -- I want it to be the best!" As far as I can tell now, the IBM guys were just marketing flacks, who took umbrage that anyone would criticize the IBM product in any way. (They kept saying "we have thousands of satisfied customers".) I never did get a message that any of the problems I found would be fixed. Apparently, they also have thousands of ignorant customers. > Given that Mr. Simpson seems willing to trash people and products by > name and without giving substantial evidence to support his > accusations, it would not be surprising if Doug Nelson responded > spitefully. In fact, I thought Mr. Nelson responded very mildly. > Doug Nelson is responsible for the very poor message system I have to live with, and the message that he posted long after the message thread had died had none of the deep technical information that you seem to demand. Looks like I have to refute and repudiate his message, too. Another day. > Unless Mr. Simpson comes up with some previously undisclosed facts the > only conclusion to draw is that he is nothing more than a "flaming" > fool. Yes, the throughput from NIS.NSF.NET is low. No, that does > not prove the software on the machine is to blame. > Perhaps you have some other explanation. Perhaps you think that a data channel on an IBM 4391 has trouble keeping up with 120 bytes per second? How do they run such things as disk drives? My tests were designed to eliminate other considerations such as the Ethernet, gateways, and load. As for flaming fools, I will note that you have at least 2 public flames without so much as a single counter-example, alterative test data, or other objective criterion on which to base your criticism. My benchmark is readily verifiable by anyone who wants to take the time (and as I clearly stated in "performance part 1", has been verified). You have wasted 2 hours and 11 minutes of my time. Bill Simpson 09998was@ibm.cl.msu.edu 09998was@msu.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092107530200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 21 Sep 90 03:04:46 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23284; Fri, 21 Sep 90 02:55:12 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Sep 90 07:53:02 GMT From: fernwood!portal!cup.portal.com!thad@apple.com (Thad P Floryan) Organization: The Portal System (TM) Subject: Re: 3B2 interest group Message-Id: <34130@cup.portal.com> References: <9009181650.AA09852@chance.mitre.org> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil mckee@CHANCE.MITRE.ORG (H. Craig McKee) in <9009181650.AA09852@chance.mitre.org > writes: Is there an interest group for AT&T 3B2 computers? There are two Usenet hierarchies which appear to satisfy your quest, another that may be interesting, and a fourth of general-interest: comp.sys.att has material for 3B1/UNIXPC/PC7300, 3B2/300, 3B2/310, 3B2/400, 3B2/600, 3B2/1000, 6300, 6386, and related systems u3b.* concentrates on the 3B2 family exclusively unix-pc.* concentrates on the 3B1/UNIXPC/PC7300 family exclusively comp.unix.* general material Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092109390000> Received: from runningman.cc.umich.edu by NIC.DDN.MIL with TCP; Fri, 21 Sep 90 13:19:24 PDT Received: from localhost by runningman.cc.umich.edu (5.61/gossip-1.1) id AA04308; Fri, 21 Sep 90 16:19:05 -0400 Message-Id: <9009212019.AA04308@runningman.cc.umich.edu> To: mts@runningman.cc.umich.edu Cc: dap%aber-cs%dcl-cs%ukc%mcsun.uucp@uunet.uu.net, tcp-ip@nic.ddn.mil, dory_leifer@um.cc.umich.edu Subject: Re: TCP/IP over ISDN In-Reply-To: Your message of Fri, 21 Sep 90 12:23:43 -0400. <9009211623.AA28788@terminator.cc.umich.edu> Date: Fri, 21 Sep 90 16:19:00 -0400 From: Dory Leifer I'm suprised dory leifer hasn't said anything... Maybe he doesn't read tcp-ip. He has been working on tcp-ip over ISDN for over a year. He demoed his work at the last year educom at UofMichigan. I'm cc-ing him on this message in the hope that it will prompt him to send mail to tcp-ip. mts. the snail. -------- Thanks Mike. I usually do not read tcp-ip because of the large volume of traffic on it. People usually do forward me items that seem relevant to what I am working on. There is a separate mailing group that is dedicated to IP over ISDN. I would suggest that interested parties move their discussion to this group. The group can be addressed at: TCP-ISDN@list.prime.com or TCP-ISDN-REQUEST@list.prim.com to be added. In any case, I will be doing a demo of IP over ISDN at InterOp next month as well as a talk on what has been done here. Also there is a fairly involved article for this month's issue of Connexions. Dory Leifer Information Technology Division The University of Michigan +1 313 763 4896 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092109422700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 21 Sep 90 04:19:45 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24338; Fri, 21 Sep 90 04:05:19 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Sep 90 09:42:27 GMT From: eru!hagbard!sunic!swbull!love@bloom-beacon.mit.edu (Love Feuer) Organization: Bull AB. Subject: Re: SLIP over X.25 Message-Id: <1990Sep21.094227.12937@swbull.bull.se> References: <1990Sep18.143414.4441@hq.demos.su>, <1990Sep19.112128.2154@swbull.bull.se>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil bob@MorningStar.Com (Bob Sutterfield) writes: >That's odd. Far less sick things use UDP, like the Network Time >Protocol and the Domain Name System. They're both entirely >appropriate and necessary to run over long-haul links like X.25. I am very, very sorry. I did not check my sources. It is possible to run UDP/IP based protocols over X.25 under B.O.S., including NFS. Although I was told otherwise by my friends here at Bull. I have remote mounted file systems in Norway to our local machine in Sweden. And it works, even if it is slow due to the 2400 BPS modem at the norwegian side of the network. Sorry again for any headache that my (incorrect) information might have caused. /Love Feuer Bull Sweden +46-8-7284349 love@swbull.bull.se ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092113590300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 21 Sep 90 08:20:23 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA28994; Fri, 21 Sep 90 08:15:35 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Sep 90 13:59:03 GMT From: eru!hagbard!sunic!isgate!krafla!goggi@bloom-beacon.mit.edu (Gardar Georg Nielsen) Organization: University of Iceland Subject: Re: PC/TCP tnvt product with 8bits characters codes ? Message-Id: <2209@krafla.rhi.hi.is> References: <1990Sep20.160435.3617@dg13.cec.be> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In <1990Sep20.160435.3617@dg13.cec.be> pnoe@dg13.cec.be (Pierre Noel) writes: >Hi Netland, >For the time being, I have been requested to test some TCP/IP packages on PC to correctly negociate with our Unix servers. >By the way, If you know other products working on PC and giving coherent >VT220 or ANSI emulation (No Excelan nor PC/NFS Telnet : I found them non-suita- ble for European emulations). Here in at the University of Iceland we are using patched version of PC-NFS Telnet which is 8bit transparent and translates between the PC character set and ISO 8859/1. If anyone is interested I coul'd make it available. goggi@rhi.hi.is ----MESSAGE-END---- ----MESSAGE-BEGIN---- [c0PO02NHcaj401@amdahl.uts.amdahl.com] <1990092115220700> From: edith@uts.amdahl.com (Edith Fortin) Newsgroups: comp.lang.c,comp.protocols.tcp-ip Subject: compilation of a C program with calls to lib socket ? Keywords: CMS C socket Message-ID: Date: 21 Sep 90 15:22:07 GMT Followup-To: poster Organization: Amdahl Corporation, Sunnyvale CA Lines: 13 Posted: Fri Sep 21 16:22:07 1990 I'm trying to compile a C program on VM/CMS which includes calls to a CMS emulation socket package. Unfortunately, the C compiler truncates the external symbols to 8 characters (IBM C for System/370). - Does anybody know of a better C compiler on VM/CMS ? - or any other way to do ? edith ========================================================== edith@uts.amdahl.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092117352400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 21 Sep 90 10:50:57 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03098; Fri, 21 Sep 90 10:49:02 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Sep 90 17:35:24 GMT From: logicon.com!Makey@nosc.mil (Jeff Makey) Organization: Logicon, Inc., San Diego, California Subject: Re: 9 interesting & challenging problems for Netman Message-Id: <789@logicon.com> References: <9009210641.AA20321@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) writes: >3. given a traffic matrixfor a LAN, automatically find the best place >to partitionm the net with a bridge/switch/router (subject to any >sensible topographical/logical or other constraints). All of the other problems seem to be Hard, but this one should be solvable by ordinary Operations Research techniques. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092118095500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 22 Sep 90 02:56:07 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22696; Sat, 22 Sep 90 02:51:54 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Sep 90 18:09:55 GMT From: agate!bionet!ucselx!sol.ctr.columbia.edu!srcsip!msi-s0.msi.umn.edu!cs.umn.edu!sialis!dmshq!com50!rosevax!atc!sstat!moria!bas@ucbvax.Berkeley.EDU (Brian Strop) Organization: UNISYS Custom Networks, Eagan MN Subject: Packet Drivers over UB NIUpc card Message-Id: <562@moria.Sp.Unisys.Com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am trying to use the Clarkson packet drivers with an Ungermann-Bass NIUpc adapter. My attempts are failing miserably. Each time I specify (invoke) the packet driver (via ubnic 0x60 0x4 0xc800) my PC hangs and I have to power it off to get control back (I do get the message 'Packet driver loaded at xxxx' before it hangs). Is any one out there using the packet drivers with the UB NIUpc card? Can it be done? Thanks in advance for any help. B. Strop -- Brian A. Strop (612) 687-2709 UNISYS bas%moria@atc.sp.unisys.com Network Systems ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092119275300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 21 Sep 90 12:39:55 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05718; Fri, 21 Sep 90 12:30:26 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Sep 90 19:27:53 GMT From: agate!garnet.berkeley.edu!cliff@ucbvax.Berkeley.EDU (Cliff Frost) Organization: University of California, Berkeley Subject: Re: the flaming fool Message-Id: <1990Sep21.192753.21356@agate.berkeley.edu> References: <9009210717.AA21143@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9009210717.AA21143@ucbvax.Berkeley.EDU>, 09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson") writes: |> > Cliff Frost or writes: |> > ... |> > Unless Mr. Simpson comes up with some previously undisclosed facts the |> > only conclusion to draw is that he is nothing more than a "flaming" |> > fool. Yes, the throughput from NIS.NSF.NET is low. No, that does |> > not prove the software on the machine is to blame. |> > |> Perhaps you have some other explanation... Yes, there are any number of other plausible explanations for the data you had publically posted, although my statement should have read: "...does not prove the TCP/IP software on the machine is to blame." For example, a VM machine with improperly configured scheduling can absolutely destroy TCP/IP performance; for example by keeping the code from running when it needs to. No amount of cleverness by the TCP/IP programming team could make up for this. |> As for flaming fools, I will note that you have at least 2 public flames |> without so much as a single counter-example, alterative test data, or |> other objective criterion on which to base your criticism. This is a lie. My very first posting on this subject (the one you are quoting from!) contained possible alternate explanations for 3 specific problems you mentioned: 1) "less than MSS sized packets" Packet size is configurable in a couple of ways in that product. 2) "too many retransmissions" 3) "timeouts of 20 seconds or more" Trivial to accomplish by misconfiguring the VM scheduler (that is, nothing to do with the scheduler in the TCP/IP sw.) Without the data that you *finally* produced there was no way for us to rule those theories out. |> My benchmark |> is readily verifiable by anyone who wants to take the time |> (and as I clearly stated in "performance part 1", has been verified). I have never challenged either your benchmark or your assertion that there are problems in the software. What I said was that you had not given us enough information to evaluate the substance of your criticisms of it. You posted the ambiguous data 3 times, so I can't imagine why you hesitated to post the real data--it's both shorter and much more interesting. I will say that in my experience, Bill Rubin and Jay Elinsky have been both "real programmers" and very responsive to customers problem reports. We're all aware by now that you feel differently. Cliff Frost ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092120404700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 22 Sep 90 04:40:55 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23985; Sat, 22 Sep 90 04:39:42 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Sep 90 20:40:47 GMT From: usc!srhqla!unigold!lance@ucsd.edu (Lance Ellinghouse) Organization: UNIGOLD Subject: What is a UNIX Domain Socket? Message-Id: <82@unigold.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Ok, I know this is a dumb question.. What exactly is a Unix Domain Socket? What makes it different from a INET Socket? Thanks, +----------------------------------------------+------------------------------+ |Lance Ellinghouse |Any ideas on what to put here?| |E-mail: lance@unigold.uucp |I have no idea... :) | | unigold!lance@srhqla.sr.com | | | hermix!unigold!lance@anes.ucla.edu +------------------------------+ |USnail Mail: UNIGOLD, 16311 Ventura Blvd. Suite 1100, Encino, Ca, 91436 | +-----------------------------------------------------------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092120580400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 21 Sep 90 14:10:39 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08382; Fri, 21 Sep 90 14:08:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Sep 90 20:58:04 GMT From: resource!bryan@tut.cis.ohio-state.edu (Bryan M. Beck) Organization: Resource Systems Columbus, Ohio Subject: Strange TCP/IP problem, Please help. Message-Id: <2747@resource.Resource.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Help, This is pretty lenghtly so please bare with me. I had a 2 node tcp/ip lan running on thin wire using 3Com 3c053 cards running between 1 386/20 running SCO XENIX and 1 486/25 running SCO UNIX 3.2 in both cases I am using SCO TCP/IP. Lets call there nodes A and B. A <---------> B address -------- A = 132.147.160.5 B = 132.147.160.10 All communication between A and B works great (ftp,telnet,rcmd,rlogin). Then I added node C another 386/25 running SCO XENIX with same 3Com and same TCP/IP. Like so. A <---------> B <--------> C addresses --------- A = 132.147.160.5 B = 132.147.160.10 C = 132.147.160.7 Now here comes the part that stumps me. Systems A and B still work fine as described above but System C cannot telnet,ftp to machine B. It just says trying.... and the eventually times out. But System C can telnet,ftp,ping.... to System A. Also System A and B can telnet,ftp, ping to C. Does anyone have any ideas. I could really use some. Please e-mail all responses. Thanks, Bryan -- Bryan M. Beck Resource Systems UUCP: osu-cis!resource!bryan Suite 390 2545 Farmers Drive INTERNET: bryan@resource.com Columbus, Ohio 43235 VOICE: (614) 764-7800 FAX: (614) 764-7850 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092200002700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 21 Sep 90 17:40:03 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13230; Fri, 21 Sep 90 17:32:51 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Sep 90 00:00:27 GMT From: afsg!ron@apple.com (Ron Flax) Organization: Apple Federal Systems Group Subject: Webster Servers Message-Id: <453@afsg.apple.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does anyone know of any Webster servers on the Internet with a liberal access policy? What, if any, restrictions apply? Thanks. -- Ron Flax ron@afsg.apple.com Apple Federal Systems Group PS. Sorry for posting this to comp.protocols.tcp-ip but I figured this is were I'd get the best response from. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [34162@cup.portal.com] <1990092201513900> From: Brian_C_McBee@cup.portal.com Newsgroups: comp.protocols.appletalk,comp.protocols.tcp-ip,comp.dcom.lans Subject: MAC MS-MAIL to SMTP gateway? Message-ID: <34162@cup.portal.com> Date: 22 Sep 90 01:51:39 GMT Organization: The Portal System (TM) Lines: 4 Posted: Sat Sep 22 02:51:39 1990 We have MS mail running on our appletalk network, shich is connected to our ethernet with a Kinetics Fastpath. What is our best bet for gatewaying MS-MAIL to SMTP? Failing that, how about MS-MAIL to VAXMAIL? SMTP would be best, but we'll take what we can get. Thanks. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009221327.AA25351@ucbvax.Berkeley.EDU] <1990092211500700> From: Z.Wang@CS.UCL.AC.UK (Zheng Wang) Newsgroups: comp.protocols.tcp-ip Subject: Re: 9 interesting & challenging problems for Netman Message-ID: <9009221327.AA25351@ucbvax.Berkeley.EDU> Date: 22 Sep 90 11:50:07 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 59 Posted: Sat Sep 22 12:50:07 1990 >Here are what we consider to be 9 interesting & challenging problems for >network management (these are based on >real requirements, not tedious exhaustive MIB definitions): >1. given the trace of packets between two end points on a LAN, >and a FSM, petri net, lotos/csp/ccs/Estelle spec for the protocol, >detect protocol (elements of procedure) errors. (easier, do the same >given ASN or XDR for packet formats:-) >2. Given same data, automatically ascribe performance problems >to incorrect packet size, timeout, window etc... >3. given a traffic matrixfor a LAN, automatically find the best place >to partitionm the net with a bridge/switch/router (subject to any >sensible topographical/logical or other constraints). >4. Find a good way to visualise the "closeness" of hosts based on the >frequency with which they communicate (this is non-trivial) >5. Automatically draw a "tube" map (friendly/Metro) of the net given >the topography... >6. Given a general traffic trace, detect patterns of communication >involving more > than 2 parties (e.g. YP or DNS lookup followed by >telnet is triv. case). >7. Interpret auto-correllation between packets from/to and/or >same src/dst in a sensible fashion... >8. Given a trace of packets between 2 protocol entities at layer 4, >invent a pleasant and efficient programming language to describe & >enable the reconstruction of application level exchanges. >9. Do all of the above for an Internet. To solve all the problems by machines can be very hard. We may have to wait a couple of years for neural nets to grow and to learn. But human brains are the best to do those jobs. What is needed is a tool for us to see the traffic inside the cables. I imagine what we need is a huge screen (as seen at some city traffic control centers) with all the nodes and links. Each connection is represented by a thin line. When traffic passes, it leaves a trace on the line. So the more traffic passes, the darker the line is. Different traffic can be represented by different colors (eg. Yellow Page traffic is yellow :-) We also need some buttons so we can choose to average the traffic at different intervals. Yes, we need a camera to get a snap shoot from time to time. With the visulization of the complete traffic, a human brain can easily answer some of the 9 questions. For a LAN, to collecting the data at a reasonable interval may not be a problem. But for an Internet, we may have to put all the snap shoots together to see the whole picture. Zheng ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092214300700> Received: from bells.cs.ucl.ac.uk by NIC.DDN.MIL with TCP; Sat, 22 Sep 90 04:51:31 PDT Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id ; Sat, 22 Sep 1990 12:50:07 +0100 To: Jon Crowcroft cc: tcp-ip@nic.ddn.mil, netman@rutherford.ac.uk, net-management@cs.ucl.ac.uk Subject: Re: 9 interesting & challenging problems for Netman In-reply-to: Your message of Thu, 20 Sep 90 09:20:41 +0100. Date: Sat, 22 Sep 90 12:50:07 +0100 From: Zheng Wang >Here are what we consider to be 9 interesting & challenging problems for >network management (these are based on >real requirements, not tedious exhaustive MIB definitions): >1. given the trace of packets between two end points on a LAN, >and a FSM, petri net, lotos/csp/ccs/Estelle spec for the protocol, >detect protocol (elements of procedure) errors. (easier, do the same >given ASN or XDR for packet formats:-) >2. Given same data, automatically ascribe performance problems >to incorrect packet size, timeout, window etc... >3. given a traffic matrixfor a LAN, automatically find the best place >to partitionm the net with a bridge/switch/router (subject to any >sensible topographical/logical or other constraints). >4. Find a good way to visualise the "closeness" of hosts based on the >frequency with which they communicate (this is non-trivial) >5. Automatically draw a "tube" map (friendly/Metro) of the net given >the topography... >6. Given a general traffic trace, detect patterns of communication >involving more > than 2 parties (e.g. YP or DNS lookup followed by >telnet is triv. case). >7. Interpret auto-correllation between packets from/to and/or >same src/dst in a sensible fashion... >8. Given a trace of packets between 2 protocol entities at layer 4, >invent a pleasant and efficient programming language to describe & >enable the reconstruction of application level exchanges. >9. Do all of the above for an Internet. To solve all the problems by machines can be very hard. We may have to wait a couple of years for neural nets to grow and to learn. But human brains are the best to do those jobs. What is needed is a tool for us to see the traffic inside the cables. I imagine what we need is a huge screen (as seen at some city traffic control centers) with all the nodes and links. Each connection is represented by a thin line. When traffic passes, it leaves a trace on the line. So the more traffic passes, the darker the line is. Different traffic can be represented by different colors (eg. Yellow Page traffic is yellow :-) We also need some buttons so we can choose to average the traffic at different intervals. Yes, we need a camera to get a snap shoot from time to time. With the visulization of the complete traffic, a human brain can easily answer some of the 9 questions. For a LAN, to collecting the data at a reasonable interval may not be a problem. But for an Internet, we may have to put all the snap shoots together to see the whole picture. Zheng ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092215364800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 22 Sep 90 08:41:09 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27015; Sat, 22 Sep 90 08:37:12 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Sep 90 15:36:48 GMT From: cs.utexas.edu!know!memora.pws.bull.com@tut.cis.ohio-state.edu (Steve Elias) Subject: cuckoo's egg goes nova Message-Id: <16093@know.pws.bull.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil the Cliff Stoll Story is on NOVA this october... premiering oct 2 (in boston, at least) tuesday at 8pm. -- know() /* eli@pws.bull.com 617 932 5598 fax 508 294 0101 */ { char cp = valloc(space); strcat(cp,"yo"); strncat(cp, index( "eli@pws.bull.com", 'b' ), 4); fputs(cp); } ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092221445300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 22 Sep 90 14:56:52 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03506; Sat, 22 Sep 90 14:55:36 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Sep 90 21:44:53 GMT From: spdcc!dyer@husc6.harvard.edu (Steve Dyer) Organization: S.P. Dyer Computer Consulting, Cambridge MA Subject: What's the current status of dialin terminal servers Message-Id: <4145@ursa-major.SPDCC.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Several months ago there was some discussion of the regional and commercial networks which comprise the Internet offering some form of fee-for-membership or fee-for-use dialin service at major metropolitan centers. I seem to remember some expressions on interest or intent on the part of Alternet and Barrnet, and I believe that PSInet offers dialup service, though at the time it only offered connections to other PSInet sites, and therefore was not useful as a general Internet resource. Can anyone comment on the current status of these or any other initiatives in this area? -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu, dyer@hstbme.mit.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092313562400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 23 Sep 90 07:42:14 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16706; Sun, 23 Sep 90 07:28:24 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Sep 90 13:56:24 GMT From: netcom!jbreeden@apple.com (John Breeden) Organization: Netcom- The Bay Area's Public Access Unix System {408 241-9760 guest} Subject: Re: Packet Drivers over UB NIUpc card Message-Id: <13685@netcom.UUCP> References: <562@moria.Sp.Unisys.Com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <562@moria.Sp.Unisys.Com> bas@moria.Sp.Unisys.Com (Brian Strop) writes: >I am trying to use the Clarkson packet drivers with an Ungermann-Bass >NIUpc adapter. My attempts are failing miserably. Each time I specify >(invoke) the packet driver (via ubnic 0x60 0x4 0xc800) my PC hangs and >I have to power it off to get control back (I do get the message 'Packet >driver loaded at xxxx' before it hangs). Is any one out there using the >packet drivers with the UB NIUpc card? Can it be done? Thanks in advance >for any help. > ubnic.com is for Ungermann's NIC card, not for the NIU card (and therfore dosn't work on the NIU - it dosn't even work on the NIC-PS2. It only works on the NIC-ISA). 1. I think Russ mentioned that there was a NIU packet driver in the works, so you could wait for version 8 of the packet drivers. 2. You can run your packet driver application on top of an NDIS driver via FTP's dis_pkt (archived on ftp.vax.com). The NDIS driver for the NIU is available from UB for a charge of $50. -- John Robert Breeden, netcom!jbreeden@apple.com, apple!netcom!jbreeden, ATTMAIL:!jbreeden ------------------------------------------------------------------- "The nice thing about standards is that you have so many to choose from. If you don't like any of them, you just wait for next year's model." ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092317473800> Received: from genbank.bio.net by NIC.DDN.MIL with TCP; Mon, 24 Sep 90 02:50:32 PDT Received: from asylum.UUCP by genbank.bio.net (5.61/IG-2.0) with UUCP id AA17848; Mon, 24 Sep 90 02:50:44 -0700 Received: by asylum.sf.ca.us (smail2.5x) id AA25144; 24 Sep 90 00:47:38 PDT (Mon) To: aussie!tong@shlump.nac.dec.com Cc: tcp-ip@nic.ddn.mil In-Reply-To: (Benny Tong's message of 24 Sep 90 05:30:51 GMT <1990Sep24.150326@aussie.enet.dec.com> Subject: choosing ethernet packet type automatically Reply-To: romkey@asylum.sf.ca.us Message-Id: <9009240047.AA25144@asylum.sf.ca.us> Date: 24 Sep 90 00:47:38 PDT (Mon) From: romkey@asylum.sf.ca.us (John Romkey) The Hosts Requirements group talked about the issue and decided that if you want to run both encapsulations on one ethernet, they must be two different subnets; you should not try to automatically negotiate which encapsulation to use. You need a router to switch packets, even though they're the same cable, logically they're two separate subnets. I was a proponent of using ARP to negotiate encapsulation, similarly to the way 4BSD TCP now uses ARP to negotiate trailers, but I agree with the decision. The broadcast problem is that you need to decide which format to broadcast in, and you don't want to broadcast twice (I don't recall there being more to it than that). Another problem is that the MTU is different between ethernet and IEEE 802. And this scheme is also idealogically more pure: you want to switch packets between encapsulations, you use a router. I would recommend that if you want to support both, you create two different logical network interfaces that use the same physical interface, and have them use different encapsulations and different network numbers. That's the way I'm handling it in an IP implementation I'm working on now. - john romkey USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@ftp.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092318481600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 23 Sep 90 12:12:38 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA20281; Sun, 23 Sep 90 12:01:17 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Sep 90 18:48:16 GMT From: nic.cerf.net!pushp@ucsd.edu (Pushpendra Mohta) Organization: CERFnet; La Jolla, CA Subject: DIAL n' CERF: Re: What's the current status of dialin terminal servers Message-Id: <187@nic.cerf.net> References: <4145@ursa-major.SPDCC.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <4145@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.com (Steve Dyer) writes: > >Can anyone comment on the current status of these [DIAL UP INTERNET ACCESS] or any other initiatives >in this area? This question came up recently in comp.protocols.tcp-ip.ibmpc What follows is the posting I made there. --pushpendra CERFnet ----------------------------------------------------------------- Enough of you have written seeking information on DIAL n' CERF , CERFnet's Dial-Up Internet Access Service. to warrant this reply: DIAL n' CERF ( and similar) services cater chiefly to : Organizations/Individuals with legitimate but low start up needs to access the Internet. Organizations/Individuals with legitimate but short term needs to access the Internet. To "roamers", who already have access to the Internet in their parent organizations, but need this access when traveling. DIAL n' CERF offers: Terminal Service ( telnet, rlogin ) SLIP USENet News Internet Mailboxes CERFnet currently offers this service at the following locations: (Other sites are under consideration as are alternate access schemes.) ---------------------------------------------------------------- DIAL n' CERF LOCATIONS Southern California SDSC San Diego SuperComputer Center SANDIEGO CIT Caltech Institute of Technology PASADENA UCI University Of California, Irvine IRVINE UCLA University of California, Los Angeles WESTWOOD Northern California UCOP University of California, Office of the President OAKLAND ---------------------------------------------------------------------- For further information retrieve the files dial-n-cerf-agreement.txt ( includes cerfnet-acceptable-use-policy ) dial-n-cerf-locations.txt by anonymous ftp from NIC.CERF.NET [ 134.24.99.3 ] in the directory ~ftp/cerfnet/cerfnet_info This site is also a good repository of information on the Internet for beginners and we encourage its use. If currently without ftp access send mail to help@cerf.net or call (619) 534-5087 If visiting Interop 90 look us up at the CERFnet booth. Pushpendra Mohta pushp@cerf.net (619) 534-5056 CERFNet/SDSC pushp@sdsc.bitnet (619) 534-5167 FAX P.O.Box 85608 San Diego, CA 92186-9784 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092402020500> Received: from hogg.cc.uoregon.edu by NIC.DDN.MIL with TCP; Mon, 24 Sep 90 13:44:55 PDT Received: from localhost.uoregon.edu by hogg.cc.uoregon.edu (4.1/University of Oregon Network Services Configuration (dmm-03/21-Aug-90)) id AA20936; Mon, 24 Sep 90 13:42:06 PDT Message-Id: <9009242042.AA20936@hogg.cc.uoregon.edu> To: romkey@asylum.sf.ca.us Cc: tcp-ip@nic.ddn.mil Subject: Re: choosing ethernet packet type automatically In-Reply-To: Your message of Mon, 24 Sep 90 00:47:38 -0700. <9009240047.AA25144@asylum.sf.ca.us> Date: Mon, 24 Sep 90 13:42:05 -0700 From: jqj@hogg.cc.uoregon.edu >The Hosts Requirements group talked about the issue and decided that >if you want to run both encapsulations on one ethernet, they must be >two different subnets ... >I would recommend that if you want to support both, you create two >different logical network interfaces that use the same physical >interface, and have them use different encapsulations and different >network numbers. I wasn't there, but that's not my interpretation of rfc1122 as published. If your interpretation were correct, there would be no need for the requirement that all hosts be able to hear Ethernet encapsulation. My reading of the paragraph referencing "two different logical networks on the same cable," is that this appears as a justification fo NOT allowing 1042-only systems, not as a recommendation for how to deal with 1042-only systems! As I read it, the expectation is that you'll normally have a single subnet, and that Ethernet is dominant; the assumption is that everybody normally uses Ethernet, but that consenting systems might agree by some unspecified means to use rfc1042 (possibly unidirectionally) for unicast traffic. As I read it, if you support rfc1042 at all you must support it by treating receipt of such packets just as if they had been received in rfc894 encapsulation. This interpretation is particularly plausible given the advent of heterogenous bridging. Most proposals for transparent bridging between Ether/802.3 and other 802.x media (e.g. FDDI or IBM TR) imply that packets (not just IP) generated on the Ethernet in 1042 encapsulation may arrive at their destination on another Ethernet in Ethernet encapsulation. This breaks Appletalk II, of course, but was not supposed to break IP. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092402565900> Received: from CORNELLC.cit.cornell.edu by NIC.DDN.MIL with TCP; Mon, 24 Sep 90 05:05:39 PDT Received: from LOCAL.DOMAIN.EDU by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2191; Mon, 24 Sep 90 08:05:16 EDT Received: by * (Mailer R2.03B) id 7687; Mon, 24 Sep 90 08:04:30 EST Date: Mon, 24 Sep 90 07:56:59 EST From: bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu> To: tcp-ip@nic.ddn.mil Subject: Re: choosing ethernet packet type automatically > From: romkey@asylum.sf.ca.us (John Romkey) > > The Hosts Requirements group talked about the issue and decided that > if you want to run both encapsulations on one ethernet, they must be > two different subnets; you should not try to automatically negotiate > which encapsulation to use. You need a router to switch packets, even > though they're the same cable, logically they're two separate subnets. > > I was a proponent of using ARP to negotiate encapsulation, similarly > to the way 4BSD TCP now uses ARP to negotiate trailers, but I agree with > the decision. The broadcast problem is that you need to decide which > format to broadcast in, and you don't want to broadcast twice (I don't > recall there being more to it than that). I can agree with not broadcasting two packets each time, but what about a scheme that alternates between the two packet types when ARPing. You could start with your default packet type and if no response is received, send the first retry in the other packet type etc. until a reply is received or timeout occurs. > Another problem is that the > MTU is different between ethernet and IEEE 802. And this scheme is And this is of course another animal. > also idealogically more pure: you want to switch packets between > encapsulations, you use a router. Ideological purity aside, I would hope that any solution that can be made to work now would be alright as I hope someday the word standard recovers it's original meaning and we all start doing things the same way. > > I would recommend that if you want to support both, you create two > different logical network interfaces that use the same physical > interface, and have them use different encapsulations and different > network numbers. That's the way I'm handling it in an IP > implementation I'm working on now. > - john romkey > USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@ftp.com bill bill gunshannon 702WFG@SCRVMSYS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092404260600> Received: from genbank.bio.net by NIC.DDN.MIL with TCP; Mon, 24 Sep 90 12:51:18 PDT Received: from asylum.UUCP by genbank.bio.net (5.61/IG-2.0) with UUCP id AA07860; Mon, 24 Sep 90 12:51:26 -0700 Received: by asylum.sf.ca.us (smail2.5x) id AA00500; 24 Sep 90 11:26:06 PDT (Mon) To: 702WFG%scrvmsys.bitnet@genbank.bio.net Cc: tcp-ip@nic.ddn.mil In-Reply-To: bill gunshannon's message of Mon, 24 Sep 90 07:56:59 EST <9009241320.AA23877@decwrl.dec.com> Subject: choosing ethernet packet type automatically Reply-To: romkey@asylum.sf.ca.us Message-Id: <9009241126.AA00500@asylum.sf.ca.us> Date: 24 Sep 90 11:26:06 PDT (Mon) From: romkey@asylum.sf.ca.us (John Romkey) The ARP scheme you suggested is what I and other people suggested. When we talked about it in the Host Requirements group, problem after problem surfaced until someone finally said, "Look, why don't we do it the right way? They're different encapsulations; put a router between them." And we were enlightened. The router solution can be made to work now, and I really think it's the right one. - john romkey USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@ftp.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092405253700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 23 Sep 90 19:42:56 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27895; Sun, 23 Sep 90 19:35:44 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Sep 90 05:25:37 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!clarkson!news.clarkson.edu!nelson@ucsd.edu (Russ Nelson) Organization: Clarkson University, Potsdam NY Subject: Re: Packet Drivers over UB NIUpc card Message-Id: References: <562@moria.Sp.Unisys.Com>, <13685@netcom.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <13685@netcom.UUCP> jbreeden@netcom.UUCP (John Breeden) writes: 1. I think Russ mentioned that there was a NIU packet driver in the works, so you could wait for version 8 of the packet drivers. Nope, a NICps/2 driver is in the air (not the works). The UB rep in Syracuse is supposedly sending me the documentation for writing a driver. Good thing I haven't been holding my breath... I suggest you don't hold your breath either. -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667 It's better to get mugged than to live a life of fear -- Freeman Dyson ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092405305100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 23 Sep 90 22:58:24 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00882; Sun, 23 Sep 90 22:44:24 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Sep 90 05:30:51 GMT From: bacchus.pa.dec.com!shlump.nac.dec.com!aussie!tong@decwrl.dec.com (Benny Tong) Organization: Digital Equipment Corporation Subject: choosing ethernet packet type automatically Message-Id: <1990Sep24.150326@aussie.enet.dec.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil RFC 1122 2.3.3 (p.24) says: The IP encapsulation for Ethernets is described in RFC-894 [LINK:3], while RFC-1042 [LINK:4] describes the IP encapsulation for IEEE 802 networks. RFC-1042 elaborates and replaces the discussion in Section 3.4 of [INTRO:2]. Every Internet host connected to a 10Mbps Ethernet cable: o MUST be able to send and receive packets using RFC-894 encapsulation; o SHOULD be able to receive RFC-1042 packets, intermixed with RFC-894 packets; and o MAY be able to send packets using RFC-1042 encapsulation. An Internet host that implements sending both the RFC-894 and the RFC-1042 encapsulations MUST provide a configuration switch to select which is sent, and this switch MUST default to RFC-894. [...] Note that 894-only systems cannot interoperate directly with 1042-only systems. If the two system types are set up as two different logical networks on the same cable, they can communicate only through an IP gateway. Furthermore, it is not useful or even possible for a dual-format host to discover automatically which format to send, because of the problem of link-layer broadcasts. Question : Why is it not useful, or even possible for a dual-format host to determine automatically which format to send? What is the problem with link-layer broadcasts? Will this scheme work? When an IP datagram needs to be sent to an unknown Internet host, ARP request packets of both ethernet and 802.3 types are broadcasted to the ethernet. The IP datagram is queued for later transmission. When an ARP reply comes back, the same packet type and ethernet address as the ARP reply is used for sending the IP datagram. If replies with two packet types come back, the default packet type can be used. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092406514600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 24 Sep 90 03:49:38 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03961; Mon, 24 Sep 90 03:39:06 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Sep 90 06:51:46 GMT From: voder!pyramid!csg@ucbvax.Berkeley.EDU (Carl S. Gutekunst) Organization: Pyramid Technology Corp., Mountain View, CA Subject: Re: SLIP over X.25 Message-Id: <128067@pyramid.pyramid.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >Have anybody tried this weird combination? Sure. To place the call, I modified the 4.3BSD slattach(8) utility to open up an X.25 device, perform call setup, condition the line for data only, and then change the line discipline to SLIPDISC. A similar trick could be done with a hardware PAD and a uucico-like dialer. To answer the call, I simply used the NASA Ames slipsh (SLIP Shell), and invoked it right out of /etc/passwd. The likely problems are: - If you are using a PAD, it will have to be able to go 8-bit transparent. In this case, it will also be imperitive that the answering side emit the right X.3 parameters before going to the SLIP discipline. This might happen auto- matically; or you might have to kludge something into slipsh. - If you are using a host-based interface, either a software PAD or a direct X.25 connection, it will have to have true line discipline support, and it will have to correctly set the PAD parameters when the line discipline is changed. Out of a dozen or so commercial UNIX X.25 implementations that I am aware of, only Pyramid and Sun do this correctly, although I'd bet that most of the university ones will, too. I'd guess that Sun's is hard on the machine because you have to wander in and out of the "if" layer twice; but I haven't tried it, so I don't really know. Performance between two Pyramids was very good, although I was using a 72Kbps link. :-) Over 9600bps, expect interactive response to be sluggish, certainly more so than over a direct wire or a modem. Some of this will depend on your ability to tune X.29 behavior, if applicable. (A good X.29 will try to bunch up characters into full packets.) We also have the Van Jacobson 4.3BSD-tahoe performance enhancements (as does Sun), which seem to make a big difference on SLIP. SLIP over X.25 is not anywhere as weird as it sounds. A proper IP over X.25 implementation (like SNDCF) is a nasty and complex beast. SLIP over X.25 is a cheap and easy way to get point-to-point IP over X.25, with only slightly higher overhead. SLIP/X.25 can even run over a PAD, which SNDCF cannot. The big disadvantage, of course, is that SLIP/X.25 *is* point-to-point, just like regular SLIP; you have to place a call and keep it there for every X.25 address to which you are likely to connect. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092409413000> Received: from genbank.bio.net by NIC.DDN.MIL with TCP; Mon, 24 Sep 90 18:50:36 PDT Received: from asylum.UUCP by genbank.bio.net (5.61/IG-2.0) with UUCP id AA23758; Mon, 24 Sep 90 18:50:47 -0700 Received: by asylum.sf.ca.us (smail2.5x) id AA02473; 24 Sep 90 16:41:30 PDT (Mon) To: jqj@hogg.cc.uoregon.edu Cc: tcp-ip@nic.ddn.mil In-Reply-To: jqj@hogg.cc.uoregon.edu's message of Mon, 24 Sep 90 13:42:05 -0700 <9009242042.AA20936@hogg.cc.uoregon.edu> Subject: choosing ethernet packet type automatically Reply-To: romkey@asylum.sf.ca.us Message-Id: <9009241641.AA02473@asylum.sf.ca.us> Date: 24 Sep 90 16:41:30 PDT (Mon) From: romkey@asylum.sf.ca.us (John Romkey) Well, I speak only for myself and say only me perception of the matter. I don't speak for the Hosts Requirements group. I believe that the reason for all hosts to be able to hear Ethernet packets is that very few vendors supported (and even now, support) RFC 1042 encapsulation, and the group wanted to ensure interoperability. In practical terms, if you want to interoperate with TCP/IP on ethernet/IEEE 802.3 networks, you must support RFC 894 encapsulation. I think that requirement is just a reflection of the practical situation we're living with now. If you want the voice of Host Requirements on the matter, Bob Braden will have to speak up. - john romkey USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@ftp.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092414402200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 24 Sep 90 09:28:52 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10441; Mon, 24 Sep 90 09:20:03 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Sep 90 14:40:22 GMT From: rohvm1!madjk@cunyvm.cuny.edu (John G Kinker) Organization: Rohm and Haas Company Subject: Source for TRACEROUTE, BOOTPD and RARPD Message-Id: <90267.104022MADJK@ROHVM1.BITNET> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Is the source for one or more of the subject programs available via anonymous FTP? I am interested in source which will compile on an Apollo under Domain/OS version 10.2 but will certainly settle for generic source as well. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092415061400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 24 Sep 90 20:01:30 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25998; Mon, 24 Sep 90 19:47:17 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Sep 90 15:06:14 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!bu.edu!polygen!bill@ucsd.edu (Bill Poitras) Organization: Polygen Corporation, Waltham, MA Subject: Sys V Unix TCP/IP abilities Message-Id: <828@redford.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have noticed that Xenix/286 has trouble receiving rlogin/rexec calls from a BSD client. Is this indicitive of all SYSV implementations of TCP/IP software. What I am trying to do is authorize PC Users on a network, and the way I am doing it is by making an rexec call (which uses the BSD 4.2 spec) to a Xenix 286 machine. If the rexec call succeeds, the authorization program lets them in. Can anyone give me help here? Is this doable with what I have? Are all SYSV TCP/IP alike? Any help would greatly be appreciated. +-----------------+---------------------------+-----------------------------+ | Bill Poitras | Polygen Corporation | {princeton mit-eddie | | (bill) | Waltham, MA USA | bu sunne}!polygen!bill | | | | bill@polygen.com | +-----------------+---------------------------+-----------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009241517.AA08899@ucbvax.Berkeley.EDU] <1990092415172000> From: HANK@TAUNIVM.BITNET (Hank Nussbacher) Newsgroups: comp.protocols.tcp-ip Subject: SNMP comparison Message-ID: <9009241517.AA08899@ucbvax.Berkeley.EDU> Date: 24 Sep 90 15:17:20 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 23 Posted: Mon Sep 24 16:17:20 1990 X-Unparsable-Date: Mon, 24 Sep 90 16:05:53 IST SNMP product comparison time: Product name Company Name ------------ ------------ Dual Manager Netlabs Netmon III SNMP Research LAN Systems 9100 NMC Hughes OverVIEW Proteon NCC Unisys NMS cisco WIN/MGT Wollongong XNETMON III SNMP Research Has anyone done an in-depth comparison of the various software products that run as X-applications and are generally supported on a Sun? Has any magazine done any sort of comparative analysis on this new market segment? Please save me from having to create yet another stupid scorecard! Thanks, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092415230200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 24 Sep 90 10:17:12 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AB11476; Mon, 24 Sep 90 10:00:44 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Sep 90 15:23:02 GMT From: mcsun!i2unix!inria!bull.bull.fr!cediag!Patrick.Hayes@uunet.uu.net (Patrick Hayes) Organization: Cediag Bull S.A., Louveciennes, France Subject: Re: SLIP over X.25 Message-Id: References: <1990Sep18.143414.4441@hq.demos.su> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article bob@MorningStar.Com (Bob Sutterfield) writes: >In article <1990Sep19.112128.2154@swbull.bull.se> love@swbull.bull.se (Love Feuer) writes: > dvv@hq.demos.su (Dmitry V. Volodin) writes: > Have anybody tried this weird combination? > > Yup. [...and then describes running TCP/IP over X.25, without > mentioning SLIP.] [ and doesn't quite answer the original question either] >Many X.25 implementations (ours, for instance) support IP directly, >which (for routing purposes) just sees the virtual circuits as wires. >I'm not sure why Mr. Volodin wants to put SLIP in the pile, though. This is also what B.O.S. does, more or less. Bull's OSes initially treated IP/X25 (DDN/X25 more or less) as point to point links. B.O.S. now treats the X25 interface as a net through which you must route packets to reach the other machines... > B.O.S. does not support UDP/IP over X.25. > >That's odd. and untrue, as Frank Mayhar has already stated. Now for WHY one would like to use SLIP over an X25 link. I'll use my own situation as an example. I've got a Mac at home, a modem, and the software neccesary to use SLIP. I'd like to be able to connect to the machines at work from time to time, but all the access points are on TRANSPAC (the french national X25 carrier). Right now I use a terminal emulation program to log on, but I'd rather have an IP link. The major problem seems to be that B.O.S.'s X3/X29 interface uses one line-discipline, and SLIP uses another. Trying to use both blows my connection. Now I know that this is ugly, but wouldn't it be nice if it worked? Pat -- +-------------------------------+-----------------------------------------+ | Patrick Hayes | EMail : Patrick.Hayes@cediag.bull.fr | | BULL CEDIAG | or hayes@bull.fr | | 68, Route de Versailles | or ...!mcvax!inria!bullfr!hayes | | F-78430 Louveciennes FRANCE | Tel : (33 1) 39 02 49 55 | +-------------------------------+-----------------------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1990Sep24.163145.2097@ecst.csuchico.edu] <1990092416314500> From: robin@csuchico.edu (Robin Goldstone) Newsgroups: comp.protocols.appletalk,comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: MAC MS-MAIL to SMTP gateway? Message-ID: <1990Sep24.163145.2097@ecst.csuchico.edu> Date: 24 Sep 90 16:31:45 GMT References: <34162@cup.portal.com> Sender: news@ecst.csuchico.edu (USENET) Reply-To: robin@cscihp.UUCP (Robin Goldstone) Organization: California State University, Chico Lines: 23 Posted: Mon Sep 24 17:31:45 1990 In article <34162@cup.portal.com> Brian_C_McBee@cup.portal.com writes: >We have MS mail running on our appletalk network, shich is connected to >our ethernet with a Kinetics Fastpath. What is our best bet for gatewaying >MS-MAIL to SMTP? Failing that, how about MS-MAIL to VAXMAIL? SMTP would >be best, but we'll take what we can get. Thanks. We are running Cayman's GatorMail-M, which is (to my knowledge) the only MS Mail to SMTP gateway available. The product is newly released and has a few bugs which Cayman is working on. We are using it mainly to talk to our VAX, which is running Matt Madison's MX Mailer (SMTP <-> VAXmail) on top of CMU/TEK TCP-IP. There are also several direct MS Mail <-> VAXmail solutions. One is from Pacer and the other from Alisa. I have not evaluated these. We decided that the SMTP solution was more generic and thus more pratical then having specific gateways to each of our other mail environments. A site license of GatorMail-M is $2000. If you want more details about this product please contact me via private e-mail. Robin Goldstone, Systems Software Specialist California State University, Chico Computing Services robin@csuchico.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092416493500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 24 Sep 90 10:17:24 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA11237; Mon, 24 Sep 90 09:51:44 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Sep 90 16:49:35 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica!ssw@ucsd.edu (Steve Wallace) Organization: Center for Innov. Comp. Appl., Bloomington, IN Subject: Looking for POP mail for MAC Message-Id: <5532@cica.cica.indiana.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We are looking for various POP/SMTP implementations for the Macintosh. Our requirements include support for MacTCP and source code availability. We are currently evaluating MIT's TechMail, but we would like to see what else is out there. Please let me know (via e-mail) of any Mac based POP clients which may meet our requirements. I'll summarize our findings to the net. Thanks, Steven Wallace wallaces@ucs.indiana.edu wallaces@iubacs.bitnet Indiana University Bloomington, IN ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092417423200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 24 Sep 90 11:14:54 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13261; Mon, 24 Sep 90 11:10:37 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Sep 90 17:42:32 GMT From: swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!oregon!dsmith@ucsd.edu (Dale Smith) Organization: University of Oregon Subject: IP and SNA applications gateways Message-Id: <20079.26fde318@oregon.uoregon.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have been contacted by some folks in our state government who are interested in connecting their large IBM SNA network to our IP network. Of course, I know nothing about SNA and they know nothing about IP, so I really don't know where to start (actually, I do know. I'm posting here, calling IBM, and I've ftp'ed the vendor guide off of the NIC). We would like an applications gateway that supports at least electronic mail to SNA DISOS (sp?). Terminal service would be a plus, but is not critical. Any good ideas on how we ought to approach this?? Thanks in advance... -- Dale Smith, Assistant Director of Network Services University of Oregon Internet: dsmith@oregon.uoregon.edu Computing Center BITNET: dsmith@oregon.bitnet Eugene, OR 97403-1212 Voice: (503)346-4394 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [26FE4E59.1748@intercon.com] <1990092418200800> From: kdb@macaw.intercon.com (Kurt Baumann) Newsgroups: comp.protocols.appletalk,comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: MAC MS-MAIL to SMTP gateway? Message-ID: <26FE4E59.1748@intercon.com> Date: 24 Sep 90 18:20:08 GMT References: <34162@cup.portal.com> Sender: usenet@intercon.com (USENET The Magnificent) Reply-To: kdb@macaw.intercon.com (Kurt Baumann) Organization: InterCon Systems Corporation, Herndon, VA Lines: 15 Posted: Mon Sep 24 19:20:08 1990 In article <34162@cup.portal.com>, Brian_C_McBee@cup.portal.com writes: > We have MS mail running on our appletalk network, shich is connected to > our ethernet with a Kinetics Fastpath. What is our best bet for gatewaying > MS-MAIL to SMTP? Failing that, how about MS-MAIL to VAXMAIL? SMTP would > be best, but we'll take what we can get. Thanks. Give the Cayman people a call. They have a product that I believe is called GatorMail - M, they also have one called GatorMail - Q for QuickMail. These go from MS-Mail/QuickMail to SMTP. Have fun. Kurt -- Kurt Baumann InterCon Systems Corporation 703.709.9890 Creators of fine TCP/IP products 703.709.9896 FAX for the Macintosh. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092419355300> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Mon, 24 Sep 90 07:08:57 PDT Received: from TAUNIVM.TAU.AC.IL by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 4307; Mon, 24 Sep 90 10:08:00 EDT Received: by TAUNIVM (Mailer R2.03B) id 8424; Mon, 24 Sep 90 16:06:30 IST Date: Mon, 24 Sep 90 16:05:53 IST From: Hank Nussbacher Subject: SNMP comparison To: tcp-ip@nic.ddn.mil SNMP product comparison time: Product name Company Name ------------ ------------ Dual Manager Netlabs Netmon III SNMP Research LAN Systems 9100 NMC Hughes OverVIEW Proteon NCC Unisys NMS cisco WIN/MGT Wollongong XNETMON III SNMP Research Has anyone done an in-depth comparison of the various software products that run as X-applications and are generally supported on a Sun? Has any magazine done any sort of comparative analysis on this new market segment? Please save me from having to create yet another stupid scorecard! Thanks, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092420212700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 24 Sep 90 15:46:59 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19977; Mon, 24 Sep 90 15:31:03 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Sep 90 20:21:27 GMT From: voder!pyramid!csg@ucbvax.Berkeley.EDU (Carl S. Gutekunst) Organization: Pyramid Technology Corp., Mountain View, CA Subject: Re: SLIP over X.25 Message-Id: <128135@pyramid.pyramid.com> References: <1990Sep19.112128.2154@swbull.bull.se>, , Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >The major problem seems to be that B.O.S.'s X3/X29 interface uses one line- >discipline, and SLIP uses another. Trying to use both blows my connection. Bingo. You're probably stuck. A *good* X.29 implementation will operate as a real tty device driver, and hence be able to use any line discipline. This is needed not only for SLIP, but also for xt and sxt drivers. Alas, many vendors, including Bull apparently, implement X.29 *as* a line discipline; so trying to switch to SLIP kills X.29. The other blunderous and common way to implement X.29 is to not hook into the tty driver at all, or only minimally. Then a request to change the line discipline is simply ignored. (Note that we're talking all Berkeley/V7 style tty devices here. Under Streams all the rules change. Generally, it's easier to get it right with Streams.) [Enter Flame Mode: My big gripe with virtually everyone who is implementing CCITT and ISO protocols on UNIX is that they insist on forcing new and unusual paradigms on the users, instead of implementing the protocols in such a way that they fit well into UNIX paradigms. The present implementations of X.400 are especially extreme examples, seeming to have been designed in a vacuum.] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092420332700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 24 Sep 90 16:45:01 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21886; Mon, 24 Sep 90 16:40:58 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Sep 90 20:33:27 GMT From: usc!cs.utexas.edu!swrinde!emory!hubcap!ncrcae!wingo@ucsd.edu (Dave Wingo) Organization: NCR Corp., Engineering & Manufacturing - Columbia, SC Subject: ICMP redirects Message-Id: <6592@ncrcae.Columbia.NCR.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have a question about routing and ICMP. Can ICMP redirects be used to update routing tables or does it just convey info about a route not being appropriate? Example would be to have an X terminal on a network 90. talking to a host A also on net 90. Then I introduce yet another host B which has two(2) network interface cards that bridge 90 to say net 89. I then put host A on net 89 and provide it with a new 89 internet number. Question then is can the X terminal find the gateway to host A via ICMP only or will rip or gated need to be provided on the X terminal to update route tables???? Thanks in advance.... David Wingo wingo@ncrcae.Columbia.NCR.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- [BARNETT.90Sep24172841@grymoire.crd.ge.com] <1990092421284100> From: barnett@grymoire.crd.ge.com (Bruce Barnett) Newsgroups: comp.protocols.appletalk,comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: MAC MS-MAIL to SMTP gateway? Message-ID: Date: 24 Sep 90 21:28:41 GMT References: <34162@cup.portal.com> <1990Sep24.163145.2097@ecst.csuchico.edu> Sender: news@crdgw1.crd.ge.com Reply-To: barnett@crdgw1.ge.com Followup-To: comp.protocols.appletalk Organization: GE Corp. R & D, Schenectady, NY Lines: 36 Posted: Mon Sep 24 22:28:41 1990 In-reply-to: robin@csuchico.edu's message of 24 Sep 90 16:31:45 GMT In article <1990Sep24.163145.2097@ecst.csuchico.edu> robin@csuchico.edu (Robin Goldstone) writes: > A site license of GatorMail-M is $2000. Well, a commercial site has different pricing...... A 10 user license is about $1000. A 100 user license is about $5000. A 200 user license is about $7000 A site license is $20,000 (not $2000). Call Cayman (617) 494-1999 for more info. Don't take my word on it. The license determines how many Mac users can SEND mail to the SMTP gateway. Anyone can receive mail from SMTP address. You should know that some characters that exist in a Mac mailname are translated in a funky manner. For instance, the address "Barnett, Bruce" on a Microsoft Mail server is converted into "Barnett#m#_Bruce@mac" on the Unix side. If you have this package, you can "tunnel" Mac mail with enclosures to other companies with the same package and the enclosures are still there. That is, someone using this package could send an enclosure from their Mac to my Mac address: barnett@macgw1.crd.ge.com. It could be used to connect to companies with MS mail that prefer not to connect their appletalk networks together. For instance, if Apple had this product, they could mail me Hypercard 2.0! :-) There is still a Unix limitation of maximum mail message size. Maybe Hypercard 2.0 would be too big. They would have to compress it, and I dare not mention any format 'cause the flames would start again. Sigh... -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092422455900> Received: from cgl.ucsf.EDU by NIC.DDN.MIL with TCP; Tue, 25 Sep 90 10:32:49 PDT Received: by cgl.ucsf.EDU (5.64/GSC4.19) id AA04619 for tcp-ip@nic.ddn.mil; Tue, 25 Sep 90 10:32:23 -0700 Received: from localhost by hop.toad.com id AA06628; Tue, 25 Sep 90 10:25:59 PDT Message-Id: <9009251725.AA06628@hop.toad.com> To: com-priv@psi.com, tcp-ip@nic.ddn.mil Cc: gnu@toad.com Subject: "Industry forns NSFnet support group" Date: Tue, 25 Sep 90 10:25:59 -0700 From: gnu@toad.com EE Times, Sept 24 1990, p. 28. My comments are [indented]. "Industry forms NSFnet support group" by Brian Robinson Washington - The government's High Performance Computing Program, which has yet to receive any formal funding, got a boost from industry last week. Three companies that have headed industry's effort in the development of NSFnet are sponsoring a new organization that will provide support for any network built as a part of the program. The new, not-for-profit company, Advanced Network and Services, Inc (ANS) will manage NSFnet under contract to current network manager Merit Inc. IBM Corp and MCI Communications Corp., which have worked with Merit for several years to refit the NSFnet, will provide cash and R&D for the venture. ANS's first job will be to connect more academic, industrial and government institutions to NSFnet, which is being boosted from a speed of 1.5Mbits/second to a T3 performance of 45 Mbits/s. Longer term, the company would provide support for the National Research and Education Network. A major focus of the computing program, the NREN is intended to link thousands of research and academic centers nationwide. NSFnet will be the backbone for the NREN. The government first proposed its $1.9 billion plan for the High Performance Computing Program late last year. The program is an ambitious attempt to build a coherent, nationwide infrastructure that will provide industry, government and academic participants with access to high-performance computing facilities. A similar program has been proposed in Congress, and legislative action on that proposal is expected sometime next year. [When will "industry" actually get to participate in this network? It sure can't now...] Even with the big boost in bandwidth -- from just 56 kbits/s two years ago -- the current increase in demand threatens to overwhelm NSFnet, said Allan Weis, president and chief executive of ANS and a former executive of IBM. In the last year alone, the number of sites connected to the network has tripled, and user traffic has increased by more than 500 percent. [If I gave away free bandwidth to anyone unscrupulous enough to break the rules, kept upgrading when people took advantage of me, and never policed them, my network traffic would be increasing exponentially, too.] ANS focus ANS will focus on managing that growth. "The success of ANS will also expand the base of financial support for the evolving financial network" [sic], said Weis. MCI and IBM will both donate $5 million over three years, and fees will also be collected from users. All of that funding will be reinvested in network development, freeing up other funds to sign on needier organizations that otherwise could not afford to get on NSFnet. [Total of $3.3M/year doesn't even come close to the cost of running the network...especially at T3. That will just about pay for office space and salaries for MCI and IBM "ex-executives" who will run ANS. The actual network funding come out of the taxpayers' pockets, as usual. The "needier organizations" stuff is designed to distract your attention from this.] While neither IBM nor MCI will derive revenue from ANS, both see it as an opportunity to develop and test new communications technologies in a real-world setting. The two companies will be able to license any new techologies ANS develops. [Heinlein's "The Man Who Sold the Moon" comes to mind. Tycoon D. D. Harriman gets a United Nations charter for a nonprofit company to explore the Moon. But that nonprofit is controlled by him, and it subcontracts everything to his "real companies with hair on their chests", who make significant profits. In this case, there are two fake nonprofits shielding the for-profits (Merit and ANS). At least in Heinlein's case, the whole thing is funded by private owners, rather than by robbing the taxpayers.] IBM sees its participation as an important means for testing new techniques and configurations of networking hardware and software. It already supplies hardware and software for NSFnet's backbone switching and routing systems. MCI, meanwhile, supplies the 1.5-Mbit/s T1 network through which NSFnet now operates, and officials expect ANS to be a test bed for work on ISDN and braodband Synchronous Optical Networks (Sonet). MCI recently tested a 2.4 Gbit/s Sonet system, and the company expects that technology to be the basis for a future, multi-gigabit NREN based om optical fibers. [Who will supply the T3 links? MCI? I find this a curious omission.] Nonetheless, officials stressed that the company will be only a small part of the full High Performance Computing Program. It will not have the resources to implement a full NREN, which will require a much broader effort from industry, government and academia. [In other words, IBM and MCI aren't interested in FUNDING the development of a nationwide high speed commercial network. They just want to come in later and cherry-pick, managing the resulting for-profit network, after it's been built "non-profit" and paid for by tax money.] Even so, the company may have a head start in any upcoming competition for future management of NSFnet and, ultimately, of the NREN. [Tell me about it...] -- end of news story -- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092423505200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 24 Sep 90 17:01:19 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22149; Mon, 24 Sep 90 16:52:02 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Sep 90 23:50:52 GMT From: usc!julius.cs.uiuc.edu!zweig@ucsd.edu (Johnny Zweig) Organization: U of Illinois, Dept. of Computer Science, Systems Research Group Subject: Re: ICMP redirects Message-Id: <1990Sep24.235052.16616@julius.cs.uiuc.edu> References: <6592@ncrcae.Columbia.NCR.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil wingo@ncrcae.Columbia.NCR.COM (Dave Wingo) writes: > >I have a question about routing and ICMP. Can ICMP redirects be used to update >routing tables or does it just convey info about a route not being appropriate? >Example would be to have an X terminal on a network 90. talking to a host A >also on net 90. Then I introduce yet another host B which has two(2) network >interface cards that bridge 90 to say net 89. I then put host A on net 89 and >provide it with a new 89 internet number. Question then is can the X terminal >find the gateway to host A via ICMP only or will rip or gated need to be >provided on the X terminal to update route tables???? > >Thanks in advance.... David Wingo wingo@ncrcae.Columbia.NCR.COM Finding the gateway (the X terminal sounds like it talks IP) from a given host (the X terminal is a host in the sense of being an endpoint-machine for IP traffic) is a problem whose solution is still in the works. Some fine day everyone will run Router Discovery Protocol so a host can use ARP to see if another is on its local net, then punt everything else to the gateway it selected from RDP. Right now, there are a number of icky ways the X terminal might go about finding out that B (in your scenario) is a router. ICMP redirects are from routers and say "Hey! You're sending IP packets for host A to me when they should really go directly to A!" if the X terminal uses ARP to find A in the first place, it will find that A is not around anymore and have to find the gateway -- the ICMP redirect might occur in the case where A gets put onto the X terminal's net when it didn't used to be and somehow the silly thing just had the route stuck in its head. The netlanders will correct me I'm sure, but I think ICMP redirects are pretty uncommon on nets that use ARP+whatever ad hoc method to locate gateways (since nets with more than one gateway are pretty uncommon). -Johnny ICMP ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092501091100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 24 Sep 90 20:01:44 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26059; Mon, 24 Sep 90 19:49:40 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Sep 90 01:09:11 GMT From: swrinde!zaphod.mps.ohio-state.edu!rpi!crdgw1!cs.albany.edu!percival.albany.edu!narten@ucsd.edu (Thomas Narten) Organization: Computer Science Department, SUNY at Albany, Albany, NY 12222 Subject: Re: ICMP redirects Message-Id: References: <6592@ncrcae.Columbia.NCR.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >>I have a question about routing and ICMP. Can ICMP redirects be used to update >>routing tables or does it just convey info about a route not being appropriate? Yes and yes. A router sends ICMP redirects to a host saying, "the datagram you just sent me destined to Y should be sent to Z [possibly, but not necessarily a router], which you can reach directly". Naturally, a host that received such a message should change its routing table to reflect the more direct path. Note that redirects generally only work for hosts and not routers, because a router determines when to send a redirect by checking 1) the source address in the forwarded datagram, and 2) noting the address Z of machine the datagram is being forwarded to. If the two addresses are on the same net, a redirect is in order. Note: To get a redirect, you must be sending the misdirected datagram to a router in the first place, so there is still a need for finding a viable router. The IETF Router discovery group is working on that problem. >ICMP redirects are from routers and say "Hey! You're sending IP packets for >host A to me when they should really go directly to A!" Replace "go directly to A" with "go directly to B" and I'll agree. Thomas Narten -- Thomas Narten narten@cs.albany.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092508073000> Received: from psi.com by NIC.DDN.MIL with TCP; Tue, 25 Sep 90 11:52:29 PDT Received: from localhost by psi.com (5.61/2.1-Performance Systems International) id AA02729; Tue, 25 Sep 90 14:47:31 -0400 Message-Id: <9009251847.AA02729@psi.com> To: gnu@toad.com Cc: com-priv@psi.com, tcp-ip@nic.ddn.mil Subject: Re: "Industry forns NSFnet support group" In-Reply-To: Your message of Tue, 25 Sep 90 10:25:59 -0700. <9009251725.AA06628@hop.toad.com> Date: Tue, 25 Sep 90 14:47:30 -0400 From: "Martin Lee Schoffstall" Well, I'm hoping to learn what you really think about this privately, I really hate the way you held back :-) The EE Times article is extremely wide of the mark, its interpretation that this is "a boost", might be countered by many dozens of organizations who think ANS has targetted the mid-level infrastructure and put it in jeopardy at a very interesting point in time for the NREN. This is pure coincidence of course. > [When will "industry" actually get to participate in this > network? It sure can't now...] I think by your participation in ALTERNET and other commercial companies particpation in PSINet, industry is participating in the Internet, and in my opinion using the right providers: commercial providers. What PSINet has been doing (and from all appearances what ALTERNET has been doing) is working with industry and not upsetting the stability of the non-profit mid-levels from providing service to the non-profits and academics. That non-profit infrastrucuture seemed pointless to hurt since too much of the US is incredibly dependant on it. At least I thought it was pointless. Now when the non-profits provide service to industry is where we get into a sticky philosophical/legal/taxation areas. This has led to a number of misunderstandings and conflicts that I'm sure now pale into insignificance now that someone has said that they are after their bread&butter. People are smart enough to stay away from those big German shepards but when they think they've set up a nice pastoral enviornment for their kids with sheep in the backyard, and the sheep are really something else, then you have real problems. I think that the neatest thing I got out of the transcripts from ANS's press conference were questions on the NSFNet joint work being renewed past its first five years, which is 92? Taking a moderate interpretation of this, is that the free national network is soon to be gone. This confirms other rumblings that I had heard from other sources. So in some sense it maybe worse than you think. Marty -------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092513005600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 25 Sep 90 06:15:37 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07444; Tue, 25 Sep 90 06:02:54 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Sep 90 13:00:56 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!rex!uflorida!webb.psych.ufl.edu!george@ucsd.edu (Stephanie George) Organization: University of Florida Psychology Department Subject: Trouble w/ NCSA TN3270 2.2 Message-Id: <24564@uflorida.cis.ufl.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I've been running the NCSA telnet package with and without the packet drivers sucessfully for more than a year now. Occasionally, I've been getting the message "Local HOST or gateway not responding" on new installations. The station that doesn't work is also not recognized as "pingable" from any other host - nobody recognizes it. Curiously, the station on either side may work flawlessly, so apparently there's no obvious physical layer problem. I have endlessly tried changing the "address" in the config.tel file to every possible combination between c000h and dc00h to no avail. This has happened on old-bus PCs running WD8003s and 3Com 501s as well as microchannel PS/2s running with WD8003s and 3Com 523s. One suggestion that I received from someone on this campus was that I might have too many stations on one length of Thinnet or I may have exceeded the maximum length for the wire. In order to test that, I terminated the cable at the errant station and tried again without success. (see following diagram) +----------+ +----------+ +----------+ | | | | | | [7m-----[m| A |[7m--------[m| B |[7m--------[m| C |[7m---||[m +----------+ +----------+ +----------+ Fig. 1: Stations A and C work just fine; Station B is new and gets the "Local host ... not responding" message. Cable is terminated just after station C, signal source is just before station A. +----------+ +----------+ +----------+ | | | | | | [7m-----[m| A |[7m--------[m| B |[7m----|| [m| C |[7m-----[m +----------+ +----------+ +----------+ Fig. 2: Cable terminated between B and C. Station A works great; station B still has error. (Assume signal source is before station A and that A is first station on this run of cable.) Yes, I understand that the cable needs to be terminated at each end - it is, otherwise Station A wouldn't work at all, either. Has anyone ever seen this? What do I do now? Stephanie George -- Stephanie George 114 Psychology Dept. george@webb.psych.ufl.edu University of Florida (904) 392-3979 Gainesville, FL 32611 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092513280000> Received: from DOCKMASTER.NCSC.MIL by NIC.DDN.MIL with TCP; Tue, 25 Sep 90 15:04:52 PDT Date: Tue, 25 Sep 90 17:28 EDT From: Sabo@DOCKMASTER.NCSC.MIL Subject: Re: SNMP comparison To: TCP-IP@NIC.DDN.MIL Message-ID: <900925212840.581117@DOCKMASTER.NCSC.MIL> The second version of the SNMP product guide has just been published by McGraw Hill's Datapro Research. This guide covers all of the SNMP NMSs which were on the market as of a few weeks ago. Contact Jill Huntington-Lee at 1 (800) 328-2776 extension 2444. Rumor has it that copies of this report will be distributed free of charge at the Datapro booth during INTEROP 90. L. Michael Sabo ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092515045700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 25 Sep 90 08:16:27 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10210; Tue, 25 Sep 90 08:11:47 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Sep 90 15:04:57 GMT From: dc@uunet.uu.net (Darren Croke) Organization: GraphOn Corp., San Jose, CA Subject: Re: ICMP redirects Message-Id: <537@gohp3.graphon.com> References: <6592@ncrcae.Columbia.NCR.COM>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article , narten@cs.albany.edu (Thomas Narten) writes: > > Note: To get a redirect, you must be sending the misdirected datagram > to a router in the first place, so there is still a need for finding a > viable router. The IETF Router discovery group is working on that > problem. > It's currently common for X terminals to have a setup field to allow a default gateway to be specified. Darren Croke dc@graphon.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092516032700> Received: from hls.com (LANSLIDE.HLS.COM) by NIC.DDN.MIL with TCP; Tue, 25 Sep 90 23:02:36 PDT Received: from nms. ([129.47.1.4]) by hls.com (4.0/SMI-4.0) id AA00885; Tue, 25 Sep 90 23:01:50 PDT Received: by nms. (4.0/SMI-4.0) id AA20844; Tue, 25 Sep 90 23:03:28 PDT From: salzman@nms.hls.com (Mike Salzman) Message-Id: <9009260603.AA20844@nms.> Subject: Re: IBM MVS TCP/IP info wanted To: csusac!csuchico.edu!csuchico.edu!robin@ucdavis.ucdavis.edu (Robin Goldstone) Date: Tue, 25 Sep 90 23:03:27 PDT Cc: tcp-ip@nic.ddn.mil In-Reply-To: <1990Sep25.191233.6543@ecst.csuchico.edu>; from "Robin Goldstone" at Sep 25, 90 7:12 pm Organization: Hughes Lan Systems, Mt View Ca X-Mailer: ELM [version 2.2 PL0] Robin at Cal State Chico asks: .....deleted...... > I do remember reading numerous complaints about the 8232 and praises about > a product called the ELC from BTI. We are trying to get rid of the 8232 > and replace it with something else. Should we get a BTI ELC? I also > have literature on the Fibronic's K200 and K2000. Can anyone compare these > products to the BTI product in terms of price/performance? .... deleted.... > I happened to do a market survey earlier this year among commercial users of IBM TCP/IP solutions. They included users of IBMs software as well as third party. The IBM 8232 came in for a lot of abuse, mainly because of performance, not because of any serious shortcoming. Users of the BTI product were quite happy with it. Users of other systems, including the IBM 8232, told me on two occasions that they wished they had bought it. Recently IBM announced a new product to replace the 8232, called the 3172. It seems to be more directly engineered for the purpose of frontending a LAN, and appears to offer higher performance at lower cost. I have used none of these products myself, and have no affiliations with any of the vendors. -- -------------------- salzman@hls.com ---------------------- Michael M. Salzman Voice (415) 966-7479 Fax (415)960-3738 Hughes Lan Systems 1225 Charleston Road Mt View Ca 94043 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1792@hulda.erbe.se] <1990092518472200> From: prc@erbe.se (Robert Claeson) Newsgroups: comp.unix.sysv386,comp.protocols.tcp-ip Subject: Re: Sys V Unix TCP/IP abilities Message-ID: <1792@hulda.erbe.se> Date: 25 Sep 90 18:47:22 GMT References: <828@redford.UUCP> Followup-To: comp.unix.sysv386 Organization: ERBE DATA AB, Jarfalla, Sweden Lines: 21 Posted: Tue Sep 25 19:47:22 1990 In a recent article bill@redford.UUCP (Bill Poitras) writes: >I have noticed that Xenix/286 has trouble receiving rlogin/rexec calls from >a BSD client. Is this indicitive of all SYSV implementations of TCP/IP >software. What I am trying to do is authorize PC Users on a network, >and the way I am doing it is by making an rexec call (which uses the BSD 4.2 >spec) to a Xenix 286 machine. If the rexec call succeeds, the authorization >program lets them in. Can anyone give me help here? Is this doable with >what I have? Are all SYSV TCP/IP alike? Any help would greatly be appreciated. No, not all System V TCP/IP implementations are alike. I'm typing this on a Visual X terminal, logged in to an Encore Multimax running UMAX V, a System V Release 3.2 UNIX. I have no problems booting our diskless Sun's and DG AViiON's from it, nor doing an rlogin/rexec from another host. In fact, its TCP/IP is even better than many BSD UNIXes we have here. -- Robert Claeson |Reasonable mailers: rclaeson@erbe.se ERBE DATA AB | Dumb mailers: rclaeson%erbe.se@sunet.se | Perverse mailers: rclaeson%erbe.se@encore.com These opinions reflect my personal views and not those of my employer. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092519123300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 25 Sep 90 13:32:10 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19290; Tue, 25 Sep 90 13:24:54 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Sep 90 19:12:33 GMT From: csusac!csuchico.edu!csuchico.edu!robin@ucdavis.ucdavis.edu (Robin Goldstone) Organization: California State University, Chico Subject: IBM MVS TCP/IP info wanted Message-Id: <1990Sep25.191233.6543@ecst.csuchico.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We are investigating TCP/IP solutions for our IBM MVS 3090 environment as well as for our VM 4381 environment. On the VM side, we have already procured IBM's TCP/IP offering and an 8232. I have been following the discussion here about IBM's TCP/IP for VM. Right now things are getting kind of heated in this discussion and I am having trouble distinguishing fact from fiction. So I think I'll skip my questions about VM TCP/IP... I do remember reading numerous complaints about the 8232 and praises about a product called the ELC from BTI. We are trying to get rid of the 8232 and replace it with something else. Should we get a BTI ELC? I also have literature on the Fibronic's K200 and K2000. Can anyone compare these products to the BTI product in terms of price/performance? On the MVS side, Fibronics has sent literature on their KNET product. How does this compare to IBM's TCP/IP offering for MVS? Are there any other players in this market? Maybe this discussion belongs in an IBM newsgroup... If so, which one? Thanks for any info you can provide. Robin Goldstone, Systems Software Specialist California State University, Chico Computing Services robin@csuchico.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092519581700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 25 Sep 90 13:48:36 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19661; Tue, 25 Sep 90 13:38:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Sep 90 19:58:17 GMT From: ingr!b11!wanda!sale@uunet.uu.net (Ed Sale) Organization: Intergraph Subject: ARP requests Message-Id: <8828@b11.ingr.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil When our workstations boot, in an effort to ensure that the workstation is not configured with the same internet address as another station on the net, we send an ARP request asking for a translation for the internet address that we are about to use. RFC826 states that: 298: "The sender hardware address and sender protocol address are 299: absolutely necessary." and also: 227: "Notice that the triplet is merged into the table before the 229: opcode is looked at." Since our intention is to avoid sending out conflicting address translation information on the net, what we have been doing is to set the sender protocol address to all-zero, intending that to mean, "this host on this net" (line 1736, RFC1122). In this way, an ARP request which is broadcast to the net does not update everyone's table with a translation which may be erroneous, and our stations find out about any address conflict before using the address. Does this violate the ARP protocol, or is this a valid technique? Thanks in advance. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Ed Sale Intergraph Corp. Huntsville, AL 35894-0001 (205)730-2000 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [6888.26ffc604@vax1.tcd.ie] <1990092521025900> From: crtchlym@vax1.tcd.ie Newsgroups: comp.protocols.tcp-ip,comp.os.vms Subject: Request for info. on TFTP for Vax VMS Message-ID: <6888.26ffc604@vax1.tcd.ie> Date: 25 Sep 90 21:02:59 GMT Organization: Computer Laboratory, Trinity College Dublin Lines: 16 Posted: Tue Sep 25 22:02:59 1990 We have a Linotronic Imagesetter printer which we wish to connect to a MicroVax via ethernet. The printer supports TCP/IP and we therefore intend to send postscipt files to the printer using FTP or similar. However, the printer doesnot support the standard FTP, but only TFTP (trivial FTP). The CMU-TEK tcp/ip package on our vax only has FTP (not TFTP). Can anybody point me to a source of TFTP for the vax (under VMS 5.3)? Thanks in advance. Martin Critchley, ERA, Dublin, Ireland crtchlym@vax1.tcd.ie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092523204000> Received: from timbuk.CRAY.COM by NIC.DDN.MIL with TCP; Wed, 26 Sep 90 05:40:29 PDT Received: from techops.cray.com by timbuk.CRAY.COM (4.1/SMI4.0 CRAY1.1) id AA04693; Wed, 26 Sep 90 07:40:45 CDT Received: by techops.cray.com id AA19137; 5.61/CRI-3.21; Wed, 26 Sep 90 07:40:40 -0500 Date: Wed, 26 Sep 90 07:40:40 -0500 From: ug051@techops.cray.com (Michael Nittman - MERCEDES) Message-Id: <9009261240.AA19137@techops.cray.com> To: tcp-ip@sri-nic.arpa Subject: index index ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092523212500> Received: from timbuk.CRAY.COM by NIC.DDN.MIL with TCP; Wed, 26 Sep 90 05:41:14 PDT Received: from techops.cray.com by timbuk.CRAY.COM (4.1/SMI4.0 CRAY1.1) id AA04717; Wed, 26 Sep 90 07:41:30 CDT Received: by techops.cray.com id AA19194; 5.61/CRI-3.21; Wed, 26 Sep 90 07:41:25 -0500 Date: Wed, 26 Sep 90 07:41:25 -0500 From: ug051@techops.cray.com (Michael Nittman - MERCEDES) Message-Id: <9009261241.AA19194@techops.cray.com> To: tcp-ip@sri-nic.arpa Subject: rfc1122 rfc 1122 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092523272300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 25 Sep 90 17:32:18 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25488; Tue, 25 Sep 90 17:21:56 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Sep 90 23:27:23 GMT From: shlump.nac.dec.com!aussie.enet.dec.com!tong@decuac.dec.com (Benny Tong) Organization: Digital Equipment Corporation Subject: Re: choosing ethernet packet type automatically Message-Id: <1990Sep26.091724@aussie.enet.dec.com> References: <9009241126.AA00500@asylum.sf.ca.us>, <9009241320.AA23877@decwrl.dec.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil RFC1122 says: Furthermore, it is not useful or even possible for a dual-format host to discover automatically which format to send, because of the problem of link-layer broadcasts. I suggest: When an IP datagram needs to be sent to an unknown Internet host, ARP request packets of both ethernet and 802.3 types are broadcasted to the ethernet. The IP datagram is queued for later transmission. When an ARP reply comes back, the same packet type and ethernet address as the ARP reply is used for sending the IP datagram. If replies with two packet types come back, a default packet type can be used. In article <9009241126.AA00500@asylum.sf.ca.us>, romkey@ASYLUM.SF.CA.US (John Romkey) writes: |>The ARP scheme you suggested is what I and other people suggested. |>When we talked about it in the Host Requirements group, problem after |>problem surfaced until someone finally said, "Look, why don't we do it |>the right way? They're different encapsulations; put a router between |>them." And we were enlightened. |> What are the problems with link-layer broadcasts? Can you list some of them please? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092602234900> Received: from salt.acc.com by NIC.DDN.MIL with TCP; Wed, 26 Sep 90 14:03:21 PDT Received: by salt.acc.com (5.61/1.34) id AA20952; Wed, 26 Sep 90 14:03:49 -0700 Date: Wed, 26 Sep 90 14:03:49 -0700 From: chris@salt.acc.com (Chris VandenBerg) Message-Id: <9009262103.AA20952@salt.acc.com> To: tcp-ip@NIC.DDN.MIL, ug051@techops.cray.com Subject: Re: index Michael, Please do not send queries to the TCP list. It is NOT an auto-retrieval system but a distributed maillist with several thousand subscribers, all of whomnow know that you are looking for information and are new to the TCP list. I guess you believe in grand entrances.... Regards, Chris VandenBerg @acc ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092604202700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 25 Sep 90 21:32:14 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01385; Tue, 25 Sep 90 21:27:20 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Sep 90 04:20:27 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!clarkson!image.soe.clarkson.edu!nelson@ucsd.edu (Russ Nelson) Organization: Clarkson University, Potsdam, NY Subject: Please boycott Xircom Message-Id: <1990Sep26.042027.23110@news.clarkson.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Xircom has been distributing a packet driver while violating the copyright on it. I wrote the skeleton of the Clarkson packet drivers, which is copyrighted under the GNU General Public License. This copyright requires that code which is linked with mine be available in source form. I allowed them to require a signed nondisclosure form, provided that source code be given to anyone willing to sign. They have violated that copyright and agreement by refusing to distribute the source code, have agreed that they are violating it, and have ceased distribution of the packet driver. This means that Xircom Ethernet adapters no longer come with a packet driver. If your application requires a packet driver, you will be unable to use a Xircom adapter. I am asking anyone who was considering the purchase of a Xircom adapter to purchase a D-Link adapter instead, and tell Xircom why you did not buy their product. No, I don't have D-Link's address. Perhaps some kind soul who reads this will supply it to me. There is also another company (whose name I do not recall) that makes pocket Ethernet adapters. -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667 It's better to get mugged than to live a life of fear -- Freeman Dyson ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092607143600> Received: from nmdsc20.nmdsc.nnmc.navy.mil by NIC.DDN.MIL with TCP; Wed, 26 Sep 90 08:16:10 PDT Received: by nmdsc20.nmdsc.nnmc.navy.mil (5.59/25-eef) id AA01419; Wed, 26 Sep 90 11:14:36 EDT Date: Wed, 26 Sep 90 11:14:36 EDT From: Bob Stratton Message-Id: <9009261514.AA01419@nmdsc20.nmdsc.nnmc.navy.mil> To: ug051@techops.cray.com Cc: tcp-ip@sri-nic.arpa In-Reply-To: Michael Nittman - MERCEDES's message of Wed, 26 Sep 90 06:08:51 -0500 <9009261108.AA12501@techops.cray.com> Subject: rfc 1122 Hi - I just noticed your messages are being reflected to the TCP-IP mailing list at the NIC. If you want to receive RFC's from the NIC by mail, try sending a message to: SERVICE@SRI-NIC.ARPA With a subject line (like you had) of RFC xxx. Hope this helps! Bob Stratton | dsc3rjs@nmdsc{20 | 10}.nmdsc.nnmc.navy.mil [Internet] Stratton Systems Design | dsc3rjs@vmnmdsc.BITNET [BITNET only, please!] | +1 703 823 MIND [PSTNet] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092607524700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 26 Sep 90 11:33:08 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16008; Wed, 26 Sep 90 11:25:46 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Sep 90 07:52:47 GMT From: eru!hagbard!sunic!liuida!isy!tommyp@bloom-beacon.mit.edu (Tommy Pedersen) Organization: Dept of EE, University of Linkoping Subject: Racal Interlan NP622A with SLIP. Is this possible? Message-Id: <1990Sep26.075247.7480@isy.liu.se> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm would like to hear from anyone about combining the SLIP which follows with Interactive unix ver. 2.2 and the software Racal/Micom Interlan NP622A with ethernet card NP600. I need NP622A since the Oracle database I'm using requires this. I would however also like to use SLIP for distant clients. Have anyone got this to work? Or do I have to do something else like having another PC act as a gateway between ethernet and SLIP? Once again: I would like to hear from anyone, who has some idea about this combination. Thanks, Tommy Pedersen Email: tommyp@isy.liu.se ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092607525500> Received: from hls.com (LANSLIDE.HLS.COM) by NIC.DDN.MIL with TCP; Wed, 26 Sep 90 14:52:09 PDT Received: from nms. ([129.47.1.4]) by hls.com (4.0/SMI-4.0) id AA04598; Wed, 26 Sep 90 14:51:20 PDT Received: by nms. (4.0/SMI-4.0) id AA27430; Wed, 26 Sep 90 14:52:55 PDT From: salzman@nms.hls.com (Mike Salzman) Message-Id: <9009262152.AA27430@nms.> Subject: Re: IBM MVS TCP/IP info wanted To: cirpka@idca.tds.philips.nl (Jan R. Cirpka) Date: Wed, 26 Sep 90 14:52:55 PDT Cc: tcp-ip@nic.ddn.mil In-Reply-To: <9009262042.AA24215@pci1.idca.tds.philips.nl>; from "Jan R. Cirpka" at Sep 26, 90 10:42 pm Organization: Hughes Lan Systems, Mt View Ca X-Mailer: ELM [version 2.2 PL0] > > Hi Mike, > > > I happened to do a market survey earlier this year among commercial users > > of IBM TCP/IP solutions. They included users of IBMs software as well > > as third party. > > is this report general available ? If yes, could you please sent me > an electronic copy ? Thanks very much ! > > Jan Hi Jan, The survey was part of a corporate market research effort, that we undertook in the area of structured wiring systems. It happened that some of the sites which we visited were true "blue" sites, and during the conversation with them I asked about the LAN front end systems that they had. The survey was not specifically about that topic, but about their LAN plans. I became interested in the topic also because all the IBM sites indicated a strong interest in both ethernet and TCP/IP. Needless to say, I was quite surprised at these two answers, having expected to hear them say Token Ring and SNA. In any case, our study was for internal consumption, and does not shed any further light on the question raised in the mailing list about 8232 alternatives. -- -------------------- salzman@hls.com ---------------------- Michael M. Salzman Voice (415) 966-7479 Fax (415)960-3738 Hughes Lan Systems 1225 Charleston Road Mt View Ca 94043 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092608323400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 26 Sep 90 08:03:56 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA11091; Wed, 26 Sep 90 08:00:38 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Sep 90 08:32:34 GMT From: sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU (Rob Warnock) Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: 9 interesting & challenging problems for Netman Message-Id: <70311@sgi.sgi.com> References: <9009221327.AA25351@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9009221327.AA25351@ucbvax.Berkeley.EDU> Z.Wang@CS.UCL.AC.UK (Zheng Wang) writes: +--------------- | I imagine what we need is a huge screen (as seen at some city | traffic control centers) with all the nodes and links. Each | connection is represented by a thin line. When traffic passes, | it leaves a trace on the line. So the more traffic passes, the darker | the line is.... +--------------- This is exactly what SGI's new "NetVisualyzer" product does, that is, the "netlook" program (one of the NetVisualyzer subsystems). [See it at Interop.] +--------------- | ... Different traffic can be represented by different | colors (eg. Yellow Page traffic is yellow :-) +--------------- Hmmm... Good idea. Except that we already use colors for "the more traffic passes, the [brighter] the line is". You can do most of the selective viewing by enabling/disabling filters for different traffic type, but I suppose there might be times when you'd want to see the ebb and flow of two different kinds of traffic... [Have to talk to the implementers...] +--------------- | We also need some buttons so we can choose to average the traffic | at different intervals. +--------------- Got that already ("rescaling interval" and "timeout interval" knobs). +--------------- | Yes, we need a camera to get a snap shoot from time to time. +--------------- Or just save the captured/displayed data in a log file? For later replay? [Got that.] +--------------- | With the visulization of the complete traffic, a human brain | can easily answer some of the 9 questions. +--------------- Yeah, and sometimes it's startling! The first time you see a "timed" update on your LAN, you say, "Wha' th' hell was thayet thayer?!?" [At least, I did... ;-} ] +--------------- | For a LAN, to collecting the data at a reasonable interval may | not be a problem. But for an Internet, we may have to put all the | snap shoots together to see the whole picture. +--------------- "NetVisualizer" lets you select a remote station to do the snooping, while displaying on the local system. [To be fair, I believe there are other products out there that support remote monitoring, too, though without the fancy graphics...] Still, that doesn't solve the problem completely for a large internet, since gathering the real-time data can itself become a significant traffic load. -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092609260300> Received: from cheetah.ca.psi.com by NIC.DDN.MIL with TCP; Wed, 26 Sep 90 21:09:40 PDT Received: from localhost by cheetah.ca.psi.com at Wed, 26 Sep 90 21:06:05 -0700. (5.61.14/XIDA-1.2.8.34) id AA15699 for tcp-ip@nic.ddn.mil via SMTP To: newbery@comp.vuw.ac.nz (Michael Newbery) Reply-To: tcp-ip@nic.ddn.mil Cc: tcp-ip@nic.ddn.mil Subject: Re: 9 interesting & challenging problems for Netman In-Reply-To: Your message of 26 Sep 90 22:03:43 +0000. <1990Sep26.220343.20950@comp.vuw.ac.nz> Date: Wed, 26 Sep 90 21:06:03 -0700 Message-Id: <15696.654408363@cheetah.ca.psi.com> From: Marshall Rose Hmmm... A network management product that does not use SNMP. Well, that's certainly an *interesting* direction to take... (I'm far too polite to spell-out what I mean by *interesting*). In any event, discussion on this thread: 1. Has gotten away from the main topic of Jon's original message. 2. Is getting dangerously close to product advertisement. Perhaps we might get back to the original topic? /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092612025100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 26 Sep 90 06:32:39 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA09009; Wed, 26 Sep 90 06:22:02 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Sep 90 12:02:51 GMT From: psuvm!pmw1@psuvax1.cs.psu.edu (Peter M. Weiss) Organization: Penn State University Subject: Re: IBM MVS TCP/IP info wanted Message-Id: <90269.080251PMW1@psuvm.psu.edu> References: <1990Sep25.191233.6543@ecst.csuchico.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Sep25.191233.6543@ecst.csuchico.edu>, robin@csuchico.edu (Robin Goldstone) says: (stuff deleted) >Maybe this discussion belongs in an IBM newsgroup... If so, which one? >Thanks for any info you can provide. I would like to suggest that you search the IBMTCP-L notebook archives stored on the listserv@pucc.princeton.edu. /Pete -- Peter M. Weiss | pmw1@psuvm or @vm.psu.edu 31 Shields Bldg (the AIS people) | not affiliated with PSUVM | VM.PSU.EDU University Park, PA USA 16802 | Disclaimer -* +* applies herein ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092613530400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 27 Sep 90 11:03:13 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03110; Thu, 27 Sep 90 10:34:18 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Sep 90 13:53:04 GMT From: ncrlnk!ncrstp!npdiss1!scottr@uunet.uu.net (Scott Reedstrom) Organization: StPaul Subject: Re: IBM MVS TCP/IP info wanted Message-Id: <607@npdiss1.StPaul.NCR.COM> References: <1990Sep25.191233.6543@ecst.csuchico.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Sep25.191233.6543@ecst.csuchico.edu> robin@csuchico.edu (Robin Goldstone) writes: >How does this compare to IBM's TCP/IP offering for MVS? Are there any >other players in this market? Yes, NCR Comten came out with a TCP/IP offering. It uses the front end to run the TCP/IP protocol stack. 3270 terminals attached to the front end can run Telnet out the network connection, and Telnet connections can switch between hosts in the front end. The downside is you need to have a Comten front end. -- Scott Reedstrom | UUCP: ncrlnk!ncrstp!npdiss1!scottr NCR Network Products Division | Domain: scottr@stpaul.ncr.com St. Paul, MN 55434 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092617042600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 26 Sep 90 10:18:51 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13932; Wed, 26 Sep 90 10:09:10 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Sep 90 17:04:26 GMT From: ucselx!mccurdy@ucsd.edu (mccurdy m) Organization: San Diego State University Computing Services Subject: Hughes server "task stack overflow" prob. identified and fixed Message-Id: <1990Sep26.170426.26740@ucselx.sdsu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil With the help of people on campus, and Hughes personnel, the problem that was causing our LAT TCP/IP servers to crash from a "task stack overflow" error has been identified and fixed. The problem was caused by a bug in the domain name server resolution function in server resident software. Anyone also experiencing this problem should contact Hughes for a software patch. Thanks ... -mike mccurdy San Diego State University -- Mike McCurdy * mccurdy@ucselx.sdsu.edu * ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092617553500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 26 Sep 90 20:07:45 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02784; Wed, 26 Sep 90 19:54:31 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Sep 90 17:55:35 GMT From: cs.utexas.edu!uwm.edu!mixcom!baaa01@CS.YALE.EDU (Merge Technologies Inc.) Organization: MIX Communications, Milwaukee, WI (Public Access) Subject: Which TCP/IP pkg for SCO Xenix & UNIX ? Message-Id: <325@mixcom.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am looking for a TCP/IP package for the systems listed below. SCO Xenix/386 SCO UNIX 3.2 Which vendor and product do you recommend as being the most reliable and compatible? Please email your response directly to me. Thank you. Dean -- Merge Technologies Inc. P.O. BOX 27366 Milwaukee, WI 53227 ==========(414) 256-5360========================merge@mixcom.UUCP============= Diagnostic Medical Image Communications Products ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092622034300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 26 Sep 90 15:20:08 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21813; Wed, 26 Sep 90 15:08:44 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Sep 90 22:03:43 GMT From: comp.vuw.ac.nz!newbery@uunet.uu.net (Michael Newbery) Organization: Computing Serv. Ctr, Victoria Uni., Wellington, New Zealand Subject: Re: 9 interesting & challenging problems for Netman Message-Id: <1990Sep26.220343.20950@comp.vuw.ac.nz> References: <9009221327.AA25351@ucbvax.Berkeley.EDU>, <70311@sgi.sgi.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <70311@sgi.sgi.com> rpw3@sgi.com (Rob Warnock) writes: >In article <9009221327.AA25351@ucbvax.Berkeley.EDU> Z.Wang@CS.UCL.AC.UK >(Zheng Wang) writes: >+--------------- >| I imagine what we need is a huge screen (as seen at some city >| traffic control centers) with all the nodes and links. Each >| connection is represented by a thin line. When traffic passes, >| it leaves a trace on the line. So the more traffic passes, the darker >| the line is.... >+--------------- > >This is exactly what SGI's new "NetVisualyzer" product does, that is, the >"netlook" program (one of the NetVisualyzer subsystems). [See it at Interop.] Yes, it's very nice (at least the video I saw was impressive---pity my TV screen isn't as high res as the Iris :-) but it requires an Iris workstation on every segment to collect data! Great for SG if they want to sell lots of Iris's but a little out of our range I'm afraid. Also, in the case of Point to Point ethernet over fibre links (router-router) it's not even theoretically possible. Now, if the product collected data from SNMP agents it would be rather more generally useful. -- Michael Newbery Levitation: Joseph of Cupertino (1603-1663) was the subject of such frequent levitation that he was forbidden by his superiors to attend choir. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092622121500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 26 Sep 90 19:24:29 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01066; Wed, 26 Sep 90 19:16:01 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Sep 90 22:12:15 GMT From: thorin!weiss!smithfd@mcnc.org (Don Smith) Subject: Reminder - CFP TriComm'91 Message-Id: <16317@thorin.cs.unc.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil CALL FOR PAPERS TriComm '91 IEEE Conference on Communications Software: Communications for Distributed Applications and Systems April 17-19, 1991 Chapel Hill, NC USA An international conference sponsored by the IEEE Communications Society, the University of North Carolina at Chapel Hill, and MCNC OVERVIEW The decade of the 1980's was a period of rapid advances in communications technology (both hardware and software) and of pioneering deployment of distributed systems and applications. At the beginning of the 1990's, new communications technologies and new distributed applications are emerging that will have far-reaching impact on communications software. Very high-speed networks (e.g., from FDDI to Gigabit technologies), multi- and continuous-media communications, interconnection of workstations and supercomputers, visualization and image applications, and computer-supported cooperative work (CSCW) are just a few examples. Participation in the conference by both developers of advanced distributed applications or systems and researchers interested in communications software will provide a mutually beneficial dialogue. Two major themes will be emphasized: (1) examination of requirements and experiences from distributed applications and systems, and (2) innovations in underlying communications software. Areas of interest include (but are not limited to) the following: DISTRIBUTED APPLICATIONS AND SYSTEMS COMMUNICATIONS SOFTWARE Production, financial or service industry Programming environments (e.g., airlines, banking, insurance, (languages, toolkits) manufacturing, education, medicine) High-performance protocols Computer-supported collaborations Continuous-media protocols Multimedia mail, conferencing Highly available/secure systems Visualization; image processing Applied theoretical results Supercomputer-workstation integration Operating system kernel support Very large-scale file systems Performance analysis Monitoring and debugging CALL FOR PAPERS Original papers are invited and proceedings will be available at the conference. The deadline for submitting papers is October 22, 1990. Papers should be no more than 20 double spaced pages in length and should have a separate cover page with title, authors, a 250-word abstract, and postal address, email address, and telephone number of contact author. Send 5 copies to: Don Smith, TriComm '91 CB #3175, Sitterson Hall Department of Computer Science University of North Carolina Chapel Hill, NC 27599-3175 919-962-1884; smithfd@cs.unc.edu; Fax-919-962-1799 SCHEDULE Submit paper--before October 22, 1990 Notification of acceptance--December 7, 1990 Final version due--by January 28, 1991 Conference dates--April 17-19, 1991 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - PROGRAM COMMITTEE Don Smith, Chairman Yutaka Matsushita IBM & UNC-Chapel Hill, USA Keio University, Japan Steven Bellovin Najah Naffah AT & T Bell Laboratories, USA Bull, France Rich Chilausky Erich Neuhold BNR, USA GMD-IPSI, FRG Brian Coan Bernhard Plattner Bellcore, USA ETH, Switzerland Flaviu Cristian Tom Rodeheffer IBM Research-Almaden, USA DEC Sys. Res. Center, USA Carla Ellis Beverly Sanders Duke University, USA ETH, Switzerland Rong-Chin Fang M. Satyanarayanan Northern Telecom, USA CMU, USA Domenico Ferrari H.T. Smith U. of California-Berkeley, USA Nottingham University, UK James P. Gray Jorgen Staunstrup IBM Comm. Systems, USA Technical U. of Denmark Fukuya Ishino Liba Svobodova NTT, Japan IBM Res.-Zurich, Switzerland Kevin Jeffay Mladen Vouk UNC-Chapel Hill, USA NC State University, USA Rivka Ladin Hussein Abdel-Wahab DEC CRL, USA Old Dominion U., USA Simon Lam William E. Weihl U. of Texas-Austin, USA MIT, USA Geovane Magalhaes Jennifer Welch CPqD/TELEBRAS, Brazil UNC-Chapel Hill, USA ----------------------------------------------------------------------- CONFERENCE COMMITTEE Alan Blatecky (MCNC, USA) General Chairman David May (BNR, USA) Jurg Nievergelt (ETH, Switzerland) International Chairman Joe Rusnak (IBM, USA) Peter Calingaert (UNC-Chapel Hill, USA) Dan Stephenson (MCNC, USA) Andre Fournier (BNR, USA) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092700324100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 26 Sep 90 20:10:31 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03147; Wed, 26 Sep 90 20:02:50 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Sep 90 00:32:41 GMT From: usc!elroy.jpl.nasa.gov!hacgate!ladcgw.ladc.bull.com!melb.bull.oz.au!news@ucsd.edu (Simon J. Gerraty) Organization: Bull HN I.S. Australia Subject: Re: SLIP over X.25 Message-Id: <1990Sep27.003241.4907@melb.bull.oz.au> References: , , <128135@pyramid.pyramid.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <128135@pyramid.pyramid.com>, csg@pyramid (Carl S. Gutekunst) writes: >>The major problem seems to be that B.O.S.'s X3/X29 interface uses one line- >>discipline, and SLIP uses another. Trying to use both blows my connection. I have obviously caught the tail end of this chain... Could some one please explain why anyone is trying to run SLIP on top of the X3/X29 service ? In article <1990Sep19.112128.2154@swbull.bull.se> love@swbull.bull.se (Love Feuer) writes: >B.O.S. does not support UDP/IP over X.25. The reason for this is >probably that nobody should get the very, very sick idea of running >NFS over X.25. To my knowledge the DPX/2 supports IP over X.25 without fiddling about with SLIP. I have not seen any references that indicated that UDP/IP should not work. [But of course I haven't tried it myself :-)] >[Enter Flame Mode: My big gripe with virtually everyone who is implementing >CCITT and ISO protocols on UNIX is that they insist on forcing new and unusual >paradigms on the users, instead of implementing the protocols in such a way >that they fit well into UNIX paradigms. The present implementations of X.400 >are especially extreme examples, seeming to have been designed in a vacuum.] Perhaps its because X.400 was designed in a vacuum ? :-) -- Simon J. Gerraty #include /* imagine something *very* witty here */ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092710372700> Received: from CRVAX.SRI.COM by NIC.DDN.MIL with TCP; Thu, 27 Sep 90 18:31:16 PDT Date: Thu 27 Sep 90 18:37:27-PST From: Alan Larson Subject: Re: Wireless_Connectivity_Problem_&_A_Plea_For_Support To: tcp-ip@NIC.DDN.MIL Message-ID: <654485847.360000.LARSON@CRVAX.SRI.COM> In-Reply-To: <141@organpipe.UUCP> Mail-System-Version: For the problem of connecting to a building within visible range, some of the optical point to point links will probably be the best choice, especially after considering potential interference problems with RF based systems. > One of products I found was a wireless LAN made by a group > in Canada; > > Telesystems SLW Inc. > 85 Scardale Road, Suite 201 > Don Mills, Ontario CANADA M3B 2R2 I spoke with them for a while earlier this year, and would recommend most strongly against them. I had wanted to establish a point to point link that would be exceeding the range claims of their system, and was trying to get some technical details on how the system worked. Their answer was "why would you want to know that?" They continued to be unhelpful even after I explained my goals, and it became clear that they were unwilling to give any hard technical information about their product. The directional antennas they had were 3 foot long Yagis, with a 6 foot coaxial cable. The price was $600. The same class of antenna can be had in the amateur radio marketplace for under $90. They had no figures on dealing with feedline losses for the antenna to be mounted away from the radio. All in all, I also felt that they were quite rude when dealing with them on the phone. > Price: about $2000, but not yet fixed They were $2500 when I talked to them, and they were quite fixed. The control/router was more, like $4000 I think. It also wasn't quite ready back then, either. Alan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092711044900> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Wed, 26 Sep 90 23:09:28 PDT Received: from Host.DOMAIN.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 1379; Thu, 27 Sep 90 02:08:27 EDT Received: from TRMETU (OZGIT) by Host.DOMAIN.EDU (Mailer R2.07) with BSMTP id 0445; Thu, 27 Sep 90 09:07:16 TUR Date: Thu, 27 Sep 90 09:04:49 TUR From: Attila OZGIT Subject: Re: IBM MVS TCP/IP info wanted To: TCP-IP@NIC.DDN.MIL In-Reply-To: Message of Tue, 25 Sep 90 19:12:33 GMT from Dear Robin, I am currently investigating the same topics. I posted an inquiry to BIG-LAN discussion list but not received any response as yet. Could you pls send me a copy from each reply that you receive ? Regards. Attila OZGIT Middle East Technical University Computer Center Ankara, TURKEY ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009271503.AA15254@ucbvax.Berkeley.EDU] <1990092715034900> From: OZGIT@TRMETU.BITNET (Attila OZGIT) Newsgroups: comp.protocols.tcp-ip Subject: Re: IBM MVS TCP/IP info wanted Message-ID: <9009271503.AA15254@ucbvax.Berkeley.EDU> Date: 27 Sep 90 15:03:49 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 Posted: Thu Sep 27 16:03:49 1990 X-Unparsable-Date: Thu, 27 Sep 90 09:04:49 TUR Dear Robin, I am currently investigating the same topics. I posted an inquiry to BIG-LAN discussion list but not received any response as yet. Could you pls send me a copy from each reply that you receive ? Regards. Attila OZGIT Middle East Technical University Computer Center Ankara, TURKEY ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092718063200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 27 Sep 90 12:53:44 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06314; Thu, 27 Sep 90 12:47:42 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Sep 90 18:06:32 GMT From: rti!dg-rtp!dg-rtp.dg.com!harvey@mcnc.org (Michael Harvey) Organization: Data General Corporation, Research Triangle Park, NC Subject: Re: What is a UNIX Domain Socket? Message-Id: <1990Sep27.180632.25841@dg-rtp.dg.com> References: <82@unigold.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <82@unigold.UUCP>, lance@unigold.UUCP (Lance Ellinghouse) writes: |> Ok, I know this is a dumb question.. |> |> What exactly is a Unix Domain Socket? |> What makes it different from a INET Socket? |> A socket is simply a communication endpoint. Sockets support two communications domains: the UNIX domain for process-to-process communication on the same host, and the Internet domain for process-to-process communication between hosts that communicate with one another using the DARPA standard communication protocols, such as IP, TCP, and UDP. In the UNIX domain, socket names are UNIX pathnames; for example, a socket may be named /tmp/foo. Naming sockets in the Internet domain involve concatenating the Internet address with a port number. I think that covers the basics. Comments? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092720442100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 29 Sep 90 00:06:39 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25702; Fri, 28 Sep 90 23:58:00 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Sep 90 20:44:21 GMT From: dynasys!fedeva!bill@rutgers.edu (Bill Daniels) Organization: Federal Express Corp., Memphis, TN Subject: syslog to remote machine? Message-Id: <110@fedeva.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have a few Ultrix machines that are on the same network. I would like to be able to send messages via syslog(3) to one of the machines from all of the other machines. Syslog(3) as documented in Ultrix doesn't allow specification of a remote host. All messages are logged on the local machine as originating from "localhost". How might I specify a remote node to log messages to? I do not have Ultrix source but if syslog is public I would be willing to change the sending half of it! -- bill daniels federal express, memphis, tn {zardoz!dhw68k,mit-eddie!premise}!fedeva!bill bill@fedeva.UUCP ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092721124700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 27 Sep 90 16:47:58 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01882; Thu, 27 Sep 90 16:39:51 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Sep 90 21:12:47 GMT From: amethyst!organpipe!scor_az.resp-sci.arizona.edu@noao.edu (Royce Robbins) Organization: University of Arizona, Tucson, AZ Subject: Wireless_Connectivity_Problem_&_A_Plea_For_Support Message-Id: <141@organpipe.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Net folks, I have a connectivity problem. Last year our Telecommunications department rewired the main campus, and a few of the buildings that were "close" in a politico-economic sense. They have provided fiber links to most buildings and copper to a few others. They did not connect, nor do they intend to connect certain "temporary" (been there since 1920) buildings, including one to which I need to be connected. It is not econmically feasible (T1? Sure, $750/month + $15000 for equipment. Yeah, right) to lay either copper or fiber to this site. I can stand on my roof and see the other building less than 1/2 mile away, I can literally hear them when they yell 'Connect me! Connect me!'. They are currently connected via a 9600baud leased line ($35+/month) that has no possibility for upgrade. My problem is: How do I connect this site at reasonable speed (AppleTalk speed minimum) without laying a physical connection? Any ideas? I know I am not alone in having to do this. A good, inexpensive, reliable method would be met with great enthusiasm by a lot of peole, I'm sure. Options I've heard of or looked at: 2-way lasers, microwave relays, (mucho bucks) packet radio (mucho slow). Anything else? (The following is a plea for support AND an unpaid promotional announcement) One of products I found was a wireless LAN made by a group in Canada; Telesystems SLW Inc. 85 Scardale Road, Suite 201 Don Mills, Ontario CANADA M3B 2R2 (416) 441-9966 (416) 441-9785 (fax) They have several product lines, ranging from a wireless RS232 300-19200baud link to the ARLAN 600 line which is their "Megabit Wireless LAN". They all use a spread-spectrum radio transmission technology to achieve high security and high levels of interference resistance. Their products are low power devices, FCC certified under Part 15 in the US and DOC type accepted in Canada for licence-free operation. The specs say: Frequency: 915MHz (2.5 GHz also available); Speed: Variable, 1 Mbps nominal Transmit Power: up to 1 watt Typical range: Indoor/Office 300' diameter Open Factory 1200' diameter Building - Building (line of sight) 1 mile Directional antennae are available Price: about $2000, but not yet fixed Two products are available (but won't be shipping until "4th quarter"): ARLAN 610 is a router that "ties into an Ethernet backbone LAN" and according to the Tech I talked to would provide plug'n play compatibility for Internet routing. ARLAN 650 is a 8-bit PC/AT compatible card that provides a fully self-contained LAN communications card. You just have an antenna sticking out the back instead of a wire. The 650 sounds like a great product. Think of the bucks you'ld save not having to lay cable (and re-lay it when users move!) It's major drawback is that the only driver available is for Novell NetWare. Utterly useless for a majority of applications. Personally I think these sound like fantastic problem solvers, especially for situations like mine and similiar situations I know to exist on this campus. Not to mention home use! I told them having a packet driver written to FTP Software's PC/TCP specs would open up a tremendous market. The tech I spoke to said he'ld look into it. Any other suggestions anyone might have would also be welcomed. PLEA TIME: CONTACT THIS COMPANY! If anybody else agrees with me please CONTACT THIS COMPANY! Let them know there is a market out there (I KNOW I'm not alone) AND that most of the world wants something other than Novell (like TCP/IP). End of plea. Oh yeah, if anyone has any OTHER ideas, let me know. Thanks! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Royce Robbins INTERNET: royce@resp-sci.arizona.edu Div Resp Sciences FAX: (602) 626-4884 UofArizona PHONE: (602) 626-5022 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092722360000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 28 Sep 90 12:13:59 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04626; Fri, 28 Sep 90 11:58:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Sep 90 22:36:00 GMT From: tiamat!jim@uunet.uu.net (Jim O'Connor) Organization: Ahlstrom Filtration - Chattanooga,TN Subject: quick check for available host Message-Id: <771@tiamat.fsc.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil What is a quick way for a shell script to find out if a networked host is currently available? For instance, I'd like to do something like if host_present hostname then # run network commands else # take other action fi Using just about rsh (or rcmd, or remsh, depending on your flavor) command will work, but it takes rsh (mine anyway) over a minute to time out, and I'd like to use something that works a little quicker. I have a socket library, so if you just have programming tips, send them along and I'll try to write a program that does just what I want. Thanks, --jim ------------- James B. O'Connor jim@tiamat.fsc.com Ahlstrom Filtration, Inc. 615/821-4022 x. 651 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092804425900> Received: from cssun.tamu.edu by NIC.DDN.MIL with TCP; Fri, 28 Sep 90 08:00:02 PDT Received: from neuron.tamu.edu by cssun.tamu.edu (AA26616); Fri, 28 Sep 90 09:42:59 CDT Date: Fri, 28 Sep 90 09:42:59 CDT From: willis@cs.tamu.edu (Willis Marti) Message-Id: <9009281442.AA26616@cssun.tamu.edu> To: tcp-ip@nic.ddn.mil Subject: TCP Push? This has to be one of the novice questions, but I haven't been able to dig out the answer. Programming under SunOS 4.1, using sockets and send and all that, how can I tell the TCP to "push" the (possibly buffered) data out *now* and not wait to piggyback anything. I don't want to use URGENT (and I'm not sure it has the same effect). The only thing I see is to use setsockopt so that TCP *never* delays... Not really the effect I want either. What I want is flush for a socket. Is the PUSH bit implemented? Can I (an application program) set it? RTFM's accepted, if you'll give me the page. Thanks, ------------------------------------------------------------------------------- Willis F. Marti Internet: willis@cs.tamu.edu Director, Computer Services Group, Dept of Computer Science, Texas A&M Univ. ---Not an official document of Texas A&M--- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092806440700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 28 Sep 90 12:58:28 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06663; Fri, 28 Sep 90 12:42:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Sep 90 06:44:07 GMT From: sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU (Rob Warnock) Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: What is a UNIX Domain Socket? Message-Id: <70577@sgi.sgi.com> References: <82@unigold.UUCP>, <1990Sep27.180632.25841@dg-rtp.dg.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Sep27.180632.25841@dg-rtp.dg.com> harvey@dg-rtp.dg.com (Michael Harvey) writes: +--------------- | Sockets support two communications domains: the UNIX domain | for process-to-process communication on the same host, | and the Internet domain for process-to-process communication | between hosts that communicate with one another using the | DARPA standard communication protocols, such as IP, TCP, and UDP. +--------------- The [Berkeley] socket model supports an arbitrary number of domains. Let's not forget the XNS domain (Xerox NS), which uses Xerox standard protocols (ITP, Courier, Clearinghouse), or the XTP domain (Protocol Engines Inc.'s protocol), or VMTP, or whatever... ...even if AF_INET *is* the most common. -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092807120000> Received: from DOCKMASTER.NCSC.MIL by NIC.DDN.MIL with TCP; Fri, 28 Sep 90 13:20:05 PDT Date: Fri, 28 Sep 90 11:12 EDT From: Twarowski@DOCKMASTER.NCSC.MIL Subject: Uses of PING To: tcp-ip@NIC.DDN.MIL Message-ID: <900928151210.071520@DOCKMASTER.NCSC.MIL> Does the use of ping -s through a router to a workstation on another ethernet provide a good estimate of packet throughput? I have seen where someone will run this command for a couple of hours and then kill it to get the number of packets that didn't make it. I monitor the Proteon router using SNMP and have been getting a 20% packet loss. This other person says that by using ping -s he gets only a 2% packet loss. Can anyone explain???? Alex ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092808003000> Received: from sparta.com by NIC.DDN.MIL with TCP; Fri, 28 Sep 90 11:37:33 PDT Received: by sparta.com (4.0/cfm-mcl-MX-1.4(Heisenberg)) id AA04073; Fri, 28 Sep 90 14:38:58 EDT From: mayer@columbia.sparta.com Received: from localhost by columbia.sparta.com (4.1/cfm-1.1) id AA19475; Fri, 28 Sep 90 14:40:34 EDT Message-Id: <9009281840.AA19475@columbia.sparta.com> Reply-To: mayer@sparta.com To: tcp-ip@nic.ddn.mil Cc: mayer@sparta.com, cfm@sparta.com, hsw@sparta.com Subject: sockets, PC-NFS, X, and Clarkson packet drivers Date: Fri, 28 Sep 90 14:40:30 -0400 I've been told that the clarkson packet drivers can solve a problem I have with PC-NFS sockets (namely that there are only 6 of them). I ftp'd the drivers and the "pc-nfs driver compatability kit", but must admit that the resolution of my problem is not apparent (unfortunately, network protocols are not my forte). I'm using an X server on a MS-DOS machine and constantly bump against the 6 socket limitation. Although I need to increase this capability, I don't want to lose PC-NFS's capabilities to mount remote file server directories as DOS drives and use remote printers. Is it indeed true that the Clarkson stuff can allow an increase numer of sockets for PC-NFS? And if so, can anyone give me some pointers on how to configuration the drivers to work with PC-NFS? Are there any other "public domain" solutions to my problem (I'd rather advoid a product other than PC-NFS for compatability reasons)? Thanks in advance for any assistance. Frank Mayer (mayer@sparta.com) PS- please CC any response directly to me since I do not usually follow this list. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092809570400> Received: from KRONOS.NISD.CAM.UNISYS.COM by NIC.DDN.MIL with TCP; Fri, 28 Sep 90 16:57:22 PDT Received: from NEPTUNE.NISD.CAM.UNISYS.COM by KRONOS.NISD.CAM.UNISYS.COM (sdcjove) (4.1/Domain/jpb/2.1) id AA06844; Fri, 28 Sep 90 16:57:06 PDT Received: by NEPTUNE.NISD.CAM.UNISYS.COM (4.1/Domain/jpb/2.1) id AA06410; Fri, 28 Sep 90 16:57:04 PDT Date: Fri, 28 Sep 90 16:57:04 PDT From: dsr@NISD.CAM.UNISYS.COM (Dale S. Russell) Message-Id: <9009282357.AA06410@NEPTUNE.NISD.CAM.UNISYS.COM> To: tcp-ip@nic.ddn.mil Subject: DDN X.25 source desired I would appreciate any leads to available DDN X.25 software (packet level) written in C (preferably PD). Please respond directly to me at dsr@cam.unisys.com. --Dale ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092810011100> Received: from ftp.com by NIC.DDN.MIL with TCP; Fri, 28 Sep 90 15:21:08 PDT Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA20853; Fri, 28 Sep 90 18:21:11 -0500 Date: Fri, 28 Sep 90 18:21:11 -0500 Message-Id: <9009282321.AA20853@ftp.com> To: mayer@sparta.com Subject: Re: sockets, PC-NFS, X, and Clarkson packet drivers From: jbvb@ftp.com (James B. Van Bokkelen) Reply-To: jbvb@ftp.com Cc: cfm@sparta.com, hsw@sparta.com, tcp-ip@nic.ddn.mil Sender: jbvb@ftp.com Repository: babyoil.ftp.com Originating-Client: plug.ftp.com The Clarkson drivers are a MAC-layer (raw Ethernet frame level) interface, and have nothing to do with PC-NFS's emulation of 4bsd sockets on DOS. Yes, you can run one on the other, but if the number of open sockets isn't documented as being configurable, it is presumably a table size compiled into PC-NFS. PC/TCP supports up to 20 sockets (you have to close your stdio handles to get this many), I believe WIN/PC is also configurable, I don't know about BWTCP. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092812295600> Received: from cincsac.arc.nasa.gov by NIC.DDN.MIL with TCP; Sat, 29 Sep 90 00:12:06 PDT Received: Sat, 29 Sep 90 00:09:57 -0700 from localhost.arc.nasa.gov by cincsac.arc.nasa.gov (5.61/1.5T) Message-Id: <9009290709.AA01015@cincsac.arc.nasa.gov> To: wayne@ultra.com (Wayne Hathaway) Cc: tcp-ip@nic.ddn.mil Subject: Re: Question on forwarding broadcasts In-Reply-To: Your message of "28 Sep 90 14:39:45 GMT." <1990Sep28.143945.7440@ultra.com> Date: Sat, 29 Sep 90 00:09:56 -0700 From: "Milo S. Medin" (NASA ARC NSI Project Office) Wayne, this is a typical problem in many host AND router implementations. In your example, Host B should not forward the broadcast under any circumstances if it is received via a MAC layer broadcast. True, few BSD's do this. Few IP implementations do this. Some do however (I think of Phil Karn's KA9Q code). It's not that hard after all. I seem to remember talking to Mike Karels one day about this, and that he was planning to add a couple bits that get passed along with the packet from the driver to IP so that you could tell if it was received via broadcast or multicast. I'm not sure that 4.3-Reno does this, but I'm sure someone out there can answer the question. Trying to use the destination IP address to determine if the packet was transmitted via MAC layer broadcast is a heuristic. The link layer knows everything IP needs to make the proper decisions. Then most implementations throw away this very good information and then attempt to fake it by looking at the destination IP address. It works as long as nobody is doing anything strange, but it's certainly not robust, and one misconfigured host can trash the network. It's certainly not a good design. As a rule, it's a bad idea to throw away known good information. You almost always need it again soon. Your case about the directed broadcast brings up a touchy subject. My personal opinion is that directed broadcasts are universally bad. In the cases where this sort of thing is handy, Internet Multicasting should be used. I know this isn't supported by many routers, but with work on adding Multicast support to OSPF, we should see some progress in this area soon. Nonetheless, if you are one of the people who believe in directed broadcasts, I'll say you should still never forward a broadcast received by MAC layer broadcast, but may forward it if received via unicast. That is, I believe if someone is really wanting to do a directed broadcast, he should unicast the packet to his router, and not be so crass as to broadcast it. This still prevents broadcast storms, but it depends on the router where the directed broadcast entered the network to make sure the right thing is done. It's not as robust as dropping the packet, but should still prevent most mischief. In any case, if your router implementation forwards broadcasts under these conditions, I claim it violates RFC 1009. And it'll certainly violate the son-of-1009 being worked on now! So all you router vendors, get with it! You'll be glad you did, and so will your customers. We in the Internet community should always remember that we aren't building research experiments. We're building the infrastructure that all kinds of people are using to get their jobs done. If we build in things that aren't robust, many people will suffer. Thanks, Milo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1990Sep28.141544.19655@sixcom.sixcom.it] <1990092814154400> From: garof@sixcom.sixcom.it (Joe Giampapa) Newsgroups: comp.protocols.tcp-ip Subject: Help! East->West xAtlantic Internet Routers Message-ID: <1990Sep28.141544.19655@sixcom.sixcom.it> Date: 28 Sep 90 14:15:44 GMT Reply-To: garof@sixcom.UUCP (Joe Giampapa) Distribution: comp.dcom.lans Organization: Sixcom S.p.A. Milano, Lombardia, Italia Lines: 45 Posted: Fri Sep 28 15:15:44 1990 If there is an Internet newsgroup, my apologies for this mistake. Please let me know of it, and cross-post this message. Thanks. =============================================================================== I am desperately trying to access my US accounts in the Boston area, from Milano. My setup is a bit demented: 1. I have a 19200bps Telebit modem. 2. The only close modem I know of is at CILEA (in Milano), which only operates at a noisy 1200bps (V21 standard). 3. From there, I can do an X.25 connection to a terminal server at CINECA in Bologna. From there I can access Internet (the command is "TCP"). 4. I can type the TCP/IP numbers or the logical names of my destinations, and they will be resolved by the nameserver [DECTCP.???.it], at CINECA. 5. I can make the connection, login, and wait. Usually after 3 minutes, I can no longer receive any output from my destination computer. Possibilities: a) either too much noise and error correcting; or b) connection drops; or c) the bloody 1200 local modem connection generates too much noise. My net result is that I am able to get work done in sporadic spurts of less than 5minutes, and <10 commands. HELP! 1) Does anyone know of a terminal concentrator which connects to an X.25 network or (better) Internet router, which has a modem operating at V22 or V22 bis? The call can be anywhere (preferably, and probably in the north) in Italy. 2) The Italian Internet router is frequently down (90% of the time). I am looking for alternate Internet router connections which bypass the CINECA - CNR Internet network segments (which means: all routes other than in Italy). I have had a successful login by way of Finland, but only by borrowing somebody's Finnish account. X.25 connections to routers are preferred and probably most practical, in the absence of knowing any Internet router to Internet router connections. Any help to any of the above will be a tremendous help. Thank you. -Joe Giampapa ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092814394500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 28 Sep 90 13:46:03 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA09261; Fri, 28 Sep 90 13:36:59 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Sep 90 14:39:45 GMT From: cica!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!mips!ultra!wayne@tut.cis.ohio-state.edu (Wayne Hathaway) Organization: Ultra Network Technologies Subject: Question on forwarding broadcasts Message-Id: <1990Sep28.143945.7440@ultra.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have a little "IP forwarding of broadcasts" question. The following example configuration is absurdly contrived, of course, but it is the simplest that will illustrate the problem. The problem did surface in a much more complex (and realistic) situation, but I don't want to bore everybody with that. Anyway, consider: +------------+ +------------------------+ +------------+ | Host A | | Default Router | | Host B | | | | | | | | 192.40.1.1 | | 192.40.1.2 192.40.2.2 | | 192.40.2.1 | +------+-----+ +------+----------+------+ +-----+------+ | | | | ===========#=================#==========#=================#=========== Ethernet where both Host A and Host B are configured to forward things they cannot handle to the Default Router. Note that there are TWO DIFFERENT NETWORKS active on a SINGLE ETHERNET CABLE (192.40.1 and 192.40.2). (This is of course key to the problem, but it is a perfectly legal configuration, no?) Now assume a user on Host A does a broadcast to network 192.40.1 (its own network). No problem, Host A simply puts the message out with the Ethernet MAC layer broadcast address, and it is picked up by everybody on network 192.40.1. But Host B will also pick up this message, and will find that it is not destined for him. Host B will then forward it to the Default Router over network 192.40.2. The Default Router will receive this forwarded packet, and will see that it is a broadcast for a directly-connected network, so he will broadcast it out on network 192.40.1, by putting it out with the Ethernet MAC layer broadcast address. But Host B will also pick up this message, and will find ... [repeat as needed]. Clearly what Host B SHOULD do with the "misdelivered broadcast" is say "This is not for me AND it came in as a MAC layer broadcast; therefore just discard it (do NOT forward it)." But unfortunately that requires IP to know what MAC layer address a datagram came in on, and (at least in any BSD-derivative implementation I know of) that information is not available to IP. Finally, note that saying "Host B should recognize this is a broadcast from the destination address and not forward it" is NOT a solution, since it appears to Host B to be a perfectly legal DIRECTED broadcast to network 192.40.1 from somewhere else, and as far as Host B knows, he is the only way for that directed broadcast to get through; he HAS to forward it. Any comments/suggestions/flames? Are there non-BSD implementations out there that handle this? Mods to BSD? Future plans from vendors? Anything else? [This IS a real problem in any situation where there are multiple independent networks or subnets active on a single cable, and we in particular have a lot of those situations. Any real live help will be most appreciated!] Wayne Hathaway domain: wayne@Ultra.COM Ultra Network Technologies uucp: ...!ames!ultra!wayne 101 Daggett Drive phone: 408-922-0100 x132 San Jose, CA 95134 direct: Hey, you! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009282341.AA17334@ucbvax.Berkeley.EDU] <1990092816305700> From: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Newsgroups: comp.protocols.tcp-ip Subject: Internet (Open) University Message-ID: <9009282341.AA17334@ucbvax.Berkeley.EDU> Date: 28 Sep 90 16:30:57 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 Posted: Fri Sep 28 17:30:57 1990 I was so impressed by the number and quality (in breadth&depth) of papers inspired by Internet Engineering problems presented at this (and last) years ACM SIGCOMM Symposium that a strange idea occurred to me on the way back to the UK (partly fueled by 2 other experiences): We run a distance learning University in the UK called the Open University; I successfully supervised a student through to his PhD over the UK Academic network last year; Why not institute a graduate internet school? (or is it too early?) jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092817024500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 28 Sep 90 14:00:11 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10081; Fri, 28 Sep 90 13:56:40 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Sep 90 17:02:45 GMT From: smb@purdue.edu (Scott Ballew) Organization: Department of Computer Science, Purdue University Subject: Re: Question on forwarding broadcasts Message-Id: <11858@medusa.cs.purdue.edu> References: <1990Sep28.143945.7440@ultra.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Sep28.143945.7440@ultra.com> wayne@ultra.com (Wayne Hathaway) writes: From: dag@fciva.FRANKLIN.COM (Daniel A. Graifer) Newsgroups: comp.protocols.appletalk,comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: MAC MS-MAIL to SMTP gateway? Message-ID: <546@fciva.FRANKLIN.COM> Date: 28 Sep 90 17:08:12 GMT References: <34162@cup.portal.com> <26FE4E59.1748@intercon.com> Reply-To: dag@fciva.UUCP (Daniel A. Graifer) Organization: Franklin Capital Investments, Inc. McLean, Va. Lines: 28 Posted: Fri Sep 28 18:08:12 1990 In article <26FE4E59.1748@intercon.com> kdb@macaw.intercon.com (Kurt Baumann) writes: >In article <34162@cup.portal.com>, Brian_C_McBee@cup.portal.com writes: >> We have MS mail [...] appletalk network [....] Kinetics Fastpath. What is >> our best bet for gatewaying MS-MAIL to SMTP? >GatorMail - M, they also have one called GatorMail - Q for QuickMail. >Kurt Baumann InterCon Systems Corporation I thought the GatorMail products were software to run on the GatorBox. Am I mistaken? Hard to believe that products designed for a GatorBox would run on Kinetics-oops-Novell-oops-Shiva FastPath. What about something utilizing the Columbia Appletalk Protocols? You might also check with Compatible Systems (303)444-9532 for software that is associated with their EtherRoute product (has anyone tried this hardware, by the way?). Also try calling Mt Xinu (K-share product) (415)644-0146 and Information Presentation Technologies (IPT uShare) (818)347-7791. Good luck Dan -- Daniel A. Graifer Franklin Mortgage Capital Corporation uunet!fciva!dag 7900 Westpark Drive, Suite A130 (703)448-3300 McLean, VA 22102 -- Daniel A. Graifer Franklin Mortgage Capital Corporation uunet!dag@fmccva.franklin.com 7900 Westpark Drive, Suite A130 (703)448-3300 McLean, VA 22102 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092819105700> Received: from bells.cs.ucl.ac.uk by NIC.DDN.MIL with TCP; Fri, 28 Sep 90 12:26:46 PDT Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id ; Fri, 28 Sep 1990 17:31:03 +0100 To: tcp-ip@nic.ddn.mil Subject: Internet (Open) University Date: Fri, 28 Sep 90 17:30:57 +0100 From: Jon Crowcroft I was so impressed by the number and quality (in breadth&depth) of papers inspired by Internet Engineering problems presented at this (and last) years ACM SIGCOMM Symposium that a strange idea occurred to me on the way back to the UK (partly fueled by 2 other experiences): We run a distance learning University in the UK called the Open University; I successfully supervised a student through to his PhD over the UK Academic network last year; Why not institute a graduate internet school? (or is it too early?) jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092819241300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 28 Sep 90 13:38:49 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08768; Fri, 28 Sep 90 13:25:08 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Sep 90 19:24:13 GMT From: ism.isc.com!clubisc!kirkd@uunet.uu.net (Kirk Davis) Organization: Interactive Systems Corp., Santa Monica, CA Subject: Re: Please boycott Xircom Message-Id: <1990Sep28.192413.21255@ism.isc.com> References: <1990Sep26.042027.23110@news.clarkson.edu>, <1990Sep26.145651.24708@daver.bungi.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm posting this for Xircom since they have no net access. I'd like to comment on my own, but I feel it would be inappropriate since I'm bias (I'm working with them and found them to quite reasonable). So please, no email... (see the number below) --- We at Xircom regret any confusion and inconvenience we may have caused regarding our support for the Packet Driver interface. But, due to the proprietary nature of the internal operation of our products, we feel it would not be prudent to freely distribute the source of our drivers. Understanding Mr. Nelson's concern, Xircom will be discontinuing the shipment of the Packet Driver based on the Clarkson Packet driver and will be replacing it with a fully compliant Packet Driver developed independently. Please note that Xircom is committed to the TCP/IP community and is supported on over 15 different TCP/IP products, only some of which are based on the Packet Driver. In a product comparison review in the August 27th. issue of PC Week, Xircom was shown to be the fastest (and received the highest OVERALL rating) of the external LAN adapters. Please contact Mr. Steven R. Magidson at Xircom for additional information. (818) 884-8755 phone; (818) 884-1719. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092819345400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 28 Sep 90 15:31:16 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13853; Fri, 28 Sep 90 15:20:47 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Sep 90 19:34:54 GMT From: eru!hagbard!sunic!kth.se!perand@bloom-beacon.mit.edu (Per Andersson) Organization: Royal Institute of Technology, Stockholm, Sweden Subject: Re: SNMP comparison Message-Id: <1990Sep28.193454.21065@kth.se> References: <9009241517.AA08899@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9009241517.AA08899@ucbvax.Berkeley.EDU> HANK@TAUNIVM.BITNET (Hank Nussbacher) writes: >SNMP product comparison time: > >Product name Company Name >------------ ------------ >Dual Manager Netlabs >Netmon III SNMP Research >LAN Systems 9100 NMC Hughes >OverVIEW Proteon >NCC Unisys >NMS cisco >WIN/MGT Wollongong >XNETMON III SNMP Research There doesn't seem to be anybody here who is willing to share experiences with any of these products, I tried last month. Well, a few, but nothing that makes me satisfied. (Which means I'll have to try a couple myself, I think). Anyway, you are missing a few. DEC mcc Digital (VMS and Ultrix) Sunnet Manager Sun Openview HP (PC-based) Something? Vitalink ( I think it's a repackaged HP product ) What I am missing is configuration informations, such as which of these products can use imported MIBs. I have been reading the Hughes manual, and as far as I can tell that one won't. A scorecard maybe is a good idea. What should be in it ? Per -- Per Andersson (perand@admin.kth.se, perand@stacken.kth.se) Trying a new job at Bofors Electronics, still reading news at the Royal Institute of Technology Time, got the time tick tick tickin' in my head - Joe Jackson ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092823401000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 28 Sep 90 22:14:47 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23872; Fri, 28 Sep 90 21:59:20 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Sep 90 23:40:10 GMT From: sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU (Vernon Schryver) Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Question on forwarding broadcasts Message-Id: <70667@sgi.sgi.com> References: <1990Sep28.143945.7440@ultra.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Sep28.143945.7440@ultra.com>, wayne@ultra.com (Wayne Hathaway) writes: > ... [description of having 2 logical networks on 1 cable deleted] >... > Clearly what Host B SHOULD do with the "misdelivered broadcast" is say > "This is not for me AND it came in as a MAC layer broadcast; therefore > just discard it (do NOT forward it)." But unfortunately that requires > IP to know what MAC layer address a datagram came in on, and (at least > in any BSD-derivative implementation I know of) that information is > not available to IP. I think this is available in 4.3BSD-Reno. I think it is required by the Host Requirements RFCs. It is or will soon be available from at least one vendor. >... > Finally, note that saying "Host B should recognize this is a broadcast > from the destination address and not forward it" is NOT a solution, > since it appears to Host B to be a perfectly legal DIRECTED broadcast > to network 192.40.1 from somewhere else, and as far as Host B knows, > he is the only way for that directed broadcast to get through; he HAS > to forward it. >... > Wayne Hathaway domain: wayne@Ultra.COM > Ultra Network Technologies uucp: ...!ames!ultra!wayne What about using any of the zillions of routing protocols instead of static, default routes? Even RIP should work. I thought some people say directed broadcasts are or should be illegal. Vernon Schryver, Silicon Graphics, vjs@sgi.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092900142700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 28 Sep 90 18:43:50 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA20078; Fri, 28 Sep 90 18:40:24 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Sep 90 00:14:27 GMT From: portal!cup.portal.com!Will@apple.com (Will E Estes) Organization: The Portal System (TM) Subject: Cost of ISDN (was: TCP/IP Over ISDN) Message-Id: <34356@cup.portal.com> References: <1990Sep17.100257.9110@specialix.co.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I apologize if this is the wrong place to post this, but I couldn't find an ISDN newsgroup on COMP.xxx. I am wondering what are the costs associated with installing a minimal ISDN configuration in a commercial setting? What are the one-time and monthly charges associated with the hardware and the telecomm service? Thanks, Will Estes (sun!portal!cup.portal.com!Will) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092900232400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 28 Sep 90 18:43:43 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA20085; Fri, 28 Sep 90 18:40:29 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Sep 90 00:23:24 GMT From: portal!cup.portal.com!Will@apple.com (Will E Estes) Organization: The Portal System (TM) Subject: X.25 Versus ISDN Message-Id: <34357@cup.portal.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Has anyone done or seen a cost analysis for using T1 lines versus ISDN? What is the point at which T1 becomes cheaper, or does it ever become cheaper? What are the long-term prospects for leased lines/T1 lines once ISDN becomes more widely available for anything other than applications that require use of higher bandwidth than ISDN by a single application? Thanks, Will Estes (sun!portal!cup.portal.com!Will) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092906065600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 28 Sep 90 23:13:28 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25092; Fri, 28 Sep 90 23:08:02 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Sep 90 06:06:56 GMT From: swrinde!zaphod.mps.ohio-state.edu!rpi!turing.cs.rpi.edu!faatzd@ucsd.edu (Don Faatz) Organization: RPI CS Dept. Subject: Re: Please boycott Xircom Message-Id: <5DN%9T*@rpi.edu> References: <1990Sep26.145651.24708@daver.bungi.com>, <1990Sep28.192413.21255@ism.isc.com>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil As a community that benefits greatly from the efforts of people like Russ Nelson - we should STRONGLY support his position. If vendors who collect money for their products are encouraged to behave badly and basically absorb copyrighted freeware without regards for the copyright owner - we shall all suffer as the freeware pool goes dry. I, for one, shall not buy products from Xircom now or in the future. < Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 28 Sep 90 20:44:12 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22354; Fri, 28 Sep 90 20:36:44 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Sep 90 06:31:46 GMT From: usc!zaphod.mps.ohio-state.edu!rpi!clarkson!news.clarkson.edu!nelson@ucsd.edu (Russ Nelson) Organization: Clarkson University, Potsdam NY Subject: Re: Please boycott Xircom Message-Id: References: <1990Sep26.042027.23110@news.clarkson.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Sep28.192413.21255@ism.isc.com> kirkd@clubisc.ism.isc.com (Kirk Davis) writes: We at Xircom regret any confusion and inconvenience we may have caused regarding our support for the Packet Driver interface. But, due to the proprietary nature of the internal operation of our products, we feel it would not be prudent to freely distribute the source of our drivers. Prudent or not, you agreed to do so, yet you have not. That makes you liars. I suggest to dear gentle readers that they keep that in mind. Understanding Mr. Nelson's concern, Xircom will be discontinuing the shipment of the Packet Driver based on the Clarkson Packet driver and will be replacing it with a fully compliant Packet Driver developed independently. "Concern"? "CONCERN"? You fardling stole my software, that's what you did. For a year you distributed it in violation of my copyright[1]. I've gone beyond concern -- I'm right pissed! And being a developer of free software, I don't have money to pay a lawyer to sue your ass off [2]. You can bet your bippy I'm going to go over your "independently developed" packet driver with a fine-toothed comb. There are two morals to this story for other developers of free software: Register your copyright so you can sue for damages, and don't compromise free software. [1] You don't have to take my word for it. Look at their Clarkson- derived driver and you'll see my copyright, which points you to the file called COPYING, which gives the terms for copying. One of the terms is that all the source for an executable that includes my code must be available. As a *concession* to Xircom's concerns, I allowed them to require a nondisclosure agreement before providing source to anyone requesting it. They won't do it, even though they said they would. [2] I have also been advised that, lacking copyright registration, all that I could accomplish is to force you to stop distributing the driver, which you have already agreed to do. -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667 It's better to get mugged than to live a life of fear -- Freeman Dyson ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092914031400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 29 Sep 90 07:59:15 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02255; Sat, 29 Sep 90 07:46:15 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Sep 90 14:03:14 GMT From: lib!thesis1.hsch.utexas.edu@tmc.edu (Jay Maynard) Organization: University of Texas Medical School at Houston Subject: Re: Please boycott Xircom Message-Id: <4132@lib.tmc.edu> References: <1990Sep26.145651.24708@daver.bungi.com>, <1990Sep28.192413.21255@ism.isc.com>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I think Russ is right on the money with this one. While I think the GNU Public Virus...er...license amounts to software theft and should be boycotted itself, the proper course for Xircom would have been to not use the code at all if they were unhappy with the terms of the license. I ceased work on a Clarkson-derived packet driver because of the GPV, and Xircom should have done the same. I won't buy anything from them either. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jmaynard@thesis1.hsch.utexas.edu | adequately be explained by stupidity. "It's a hardware bug!" "It's a +--------------------------------------- software bug!" "It's two...two...two bugs in one!" - _Engineer's Rap_ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092914100200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 29 Sep 90 07:28:22 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01880; Sat, 29 Sep 90 07:16:41 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Sep 90 14:10:02 GMT From: news!mentor.cc.purdue.edu!dls@iuvax.cs.indiana.edu (David L Stevens) Organization: PUCC UNIX Group Subject: Re: Please boycott Xircom Message-Id: <14568@mentor.cc.purdue.edu> References: <1990Sep26.042027.23110@news.clarkson.edu>, <5DN%9T*@rpi.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <5DN%9T*@rpi.edu>, faatzd@turing.cs.rpi.edu (Don Faatz) writes: > As a community that benefits greatly from the efforts of people like > Russ Nelson - we should STRONGLY support his position. Break out the ropes! There's gonna be a lynchin', Festus! Your sense of moral outrage is touching, but whether I support his position or not will have to do with the merits of his position, thank you. From what I've seen, and from what I know about people, I doubt that there was any conspiracy to steal anything. More likely is that they didn't even read the conditions applied to it and when the knowledge of their mistaken violation finally made it to the right people, they acted honestly and complied with the copyright. I don't know the facts, and I doubt that you do either, but assuming some good faith on both parts, that's what I expect happened. What seems to have you so upset is that they comply with the copyright in the way you wanted. Well, big deal-- if they don't want to make *their* sources available, they don't have to, and even in the eyes of a Free Software zealot, that makes them no worse than every other company that does the same thing. They didn't transfer ownership of Xircom to you, so why are you acting like you have some right in deciding whether or not they distribute their sources? Boycotting Xircom because Russ Nelson and Don Faatz weren't able to impose their will on the people running Xircom isn't my idea of a worthy cause. I can see where Mr. Nelson might be frustrated, and I'm sure he'll make every effort to clarify the copyright conditions up front in the future, but that's where it ends for me. -- +-DLS (dls@mentor.cc.purdue.edu) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092915163500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 29 Sep 90 08:58:20 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03154; Sat, 29 Sep 90 08:46:01 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Sep 90 15:16:35 GMT From: netcom!jbreeden@apple.com (John Breeden) Organization: Netcom- The Bay Area's Public Access Unix System {408 241-9760 guest} Subject: Re: Please boycott Xircom Message-Id: <14121@netcom.UUCP> References: <1990Sep26.042027.23110@news.clarkson.edu>, <5DN%9T*@rpi.edu>, <14568@mentor.cc.purdue.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <14568@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes: >In article <5DN%9T*@rpi.edu>, faatzd@turing.cs.rpi.edu (Don Faatz) writes: >> As a community that benefits greatly from the efforts of people like >> Russ Nelson - we should STRONGLY support his position. > > From what I've seen, and from what I know about people, I doubt that >there was any conspiracy to steal anything. More likely is that they didn't >even read the conditions applied to it and when the knowledge of their mistaken >violation finally made it to the right people, they acted honestly and complied >with the copyright. That's what I told the judge, I did'nt *READ* the 35mph speed limit sign.... He threw the book at me. Ignorance is not a legal defense. When Xircom shipped their first driver, they entered into that contract, whether they read it or not. -- John Robert Breeden, netcom!jbreeden@apple.com, apple!netcom!jbreeden, ATTMAIL:!jbreeden ------------------------------------------------------------------- "The nice thing about standards is that you have so many to choose from. If you don't like any of them, you just wait for next year's model." ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092915254200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 29 Sep 90 08:28:29 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02859; Sat, 29 Sep 90 08:27:36 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Sep 90 15:25:42 GMT From: usc!cs.utexas.edu!smoot@ucsd.edu (Smoot Carl-Mitchell) Organization: Texas Internet Consulting Subject: Re: Question on forwarding broadcasts Message-Id: <13003@cs.utexas.edu> References: <1990Sep28.143945.7440@ultra.com>, <70667@sgi.sgi.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <70667@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: > >What about using any of the zillions of routing protocols instead >of static, default routes? Even RIP should work. > >I thought some people say directed broadcasts are or should be illegal. > > >Vernon Schryver, Silicon Graphics, vjs@sgi.com Routing has little to do with this problem. It looks like a variation of the famous broadcast storm problem inherent in 4.2BSD based TCP/IP implementations. The rule is a host which is not configured as a router should *NEVER* forward an IP packet which has a different destination address. 4.2BSD has the unfortunate feature of having IP forwarding turned on for any host. This has since been fixed in 4.3BSD. Obviously if more than one host forwards such a misdirected broadcast then network meltdown can occur very rapidly. An amusing variation on this problem is to get a packet sniffer and send an ICMP echo request packet using the Ethernet and IP broadcast address at about 0.5 sec intervals and watch the growth in ICMP traffic as all the hosts on the ethernet reply to this request all at once. Needless to say on a CSMA/CD network the collison rate also goes thru the roof. The corollary rule is never build an application which sends a broadcast packet which expects more than one host to reply to the broadcast. -- Smoot Carl-Mitchell, Texas Internet Consulting smoot@tic.com, smoot@cs.utexas.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092916455600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 29 Sep 90 10:28:18 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04333; Sat, 29 Sep 90 10:01:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Sep 90 16:45:56 GMT From: mentor.cc.purdue.edu!dls@purdue.edu (David L Stevens) Organization: PUCC UNIX Group Subject: Re: Please boycott Xircom Message-Id: <14575@mentor.cc.purdue.edu> References: <1990Sep26.042027.23110@news.clarkson.edu>, <5DN%9T*@rpi.edu>, <14121@netcom.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <14121@netcom.UUCP>, jbreeden@netcom.UUCP (John Breeden) writes: > Ignorance is not a legal defense. When Xircom shipped their first driver, they > entered into that contract, whether they read it or not. Of course it's not a legal defense. Who said it was? I'm talking about morality and justice, which have little to do with copyright law. A boycott has nothing to do with the legal system, either. I'd agree that they should pay damages for the interim in which they used the code, if there were any, and nothing I've seen says they're unwilling to. But if anyone was damaged, it was the people who bought the stuff and wanted sources, not Mr. Nelson. And since they knew they weren't getting sources at the time, I don't think they'd have a case (ethically) either. I'm not endorsing Xircom or anyone else-- I know nothing about their products-- but if you buy an inferior product on "principle" because Xircom refuses to be intimidated after making a mistake, the joke's on you. If the only point of a boycott is to force them to abide by GNU's ideas about software, it's GNU that needs boycotting. -- +-DLS (dls@mentor.cc.purdue.edu) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092916463300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 29 Sep 90 08:58:55 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03349; Sat, 29 Sep 90 08:56:48 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Sep 90 16:46:33 GMT From: swrinde!zaphod.mps.ohio-state.edu!rpi!clarkson!news.clarkson.edu!nelson@ucsd.edu (Russ Nelson) Organization: Clarkson University, Potsdam NY Subject: Re: Please boycott Xircom Message-Id: References: <1990Sep26.042027.23110@news.clarkson.edu>, <5DN%9T*@rpi.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <14568@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes: From what I've seen, and from what I know about people, I doubt that there was any conspiracy to steal anything. More likely is that they didn't even read the conditions applied to it and when the knowledge of their mistaken violation finally made it to the right people, they acted honestly and complied with the copyright. You're right in that it *is* more likely. In this case, however, Xircom knew about the GPL, or GPV (General Public Virus) as one wag put it. They knew they were obliged to make their source available, and agreed to do so for those people willing to sign a nondisclosure agreement. In spite of agreeing to do so, they will not. "Honestly" is not the term I would use. Boycotting Xircom because Russ Nelson and Don Faatz weren't able to impose their will on the people running Xircom isn't my idea of a worthy cause. I'm not trying to impose my will on them. I'm just trying to make them live up to their word. Right now, if someone from Xircom told me it was sunny, I'd reach for my umbrella. I can see where Mr. Nelson might be frustrated, and I'm sure he'll make every effort to clarify the copyright conditions up front in the future, but that's where it ends for me. But I *DID* clarify them up front! -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667 It's better to get mugged than to live a life of fear -- Freeman Dyson ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092918204700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 29 Sep 90 13:13:23 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07206; Sat, 29 Sep 90 13:10:06 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Sep 90 18:20:47 GMT From: sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU (Vernon Schryver) Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Question on forwarding broadcasts Message-Id: <70711@sgi.sgi.com> References: <1990Sep28.143945.7440@ultra.com>, <11858@medusa.cs.purdue.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <11858@medusa.cs.purdue.edu>, smb@cs.purdue.EDU (Scott Ballew) writes: > Hold it! In your configuration, Host B should NOT be forwarding ANY > packets at all, unless it is configured as a gateway. ... Right! I wish I had said that. (I did think it; trust me.) Don't the Host Requirements say the same? For various reasons, I bet the original poster is running workstations with two interfaces, one ethernet and one other kind. I bet the workstations have either 4.2BSD or 4.3BSD TCP/IP, where having two interfaces turns on IP forwarding. If so, the easy solution is to set the kernel variable ipforwarding to 0. That can be done with adb on some systems and by editing configuration files on some other systems. Vernon Schryver, vjs@sgi.com. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990092919505100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 2 Oct 90 17:57:29 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27610; Tue, 2 Oct 90 17:27:51 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Sep 90 19:50:51 GMT From: hpda!hpcupt1!hpindwa!raj@ucbvax.Berkeley.EDU (Rick Jones) Organization: Hewlett-Packard, Cupertino CA Subject: Re: Question on forwarding broadcasts Message-Id: <36540012@hpindwa.HP.COM> References: <1990Sep28.143945.7440@ultra.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil > >I have a little "IP forwarding of broadcasts" question. The following >... >Anyway, consider: > > +------------+ +------------------------+ +------------+ > | Host A | | Default Router | | Host B | > | | | | | | > | 192.40.1.1 | | 192.40.1.2 192.40.2.2 | | 192.40.2.1 | > +------+-----+ +------+----------+------+ +-----+------+ > | | | | >===========#=================#==========#=================#=========== > Ethernet > >where both Host A and Host B are configured to forward things they >cannot handle to the Default Router. Note that there are TWO >DIFFERENT NETWORKS active on a SINGLE ETHERNET CABLE (192.40.1 and >192.40.2). (This is of course key to the problem, but it is a >perfectly legal configuration, no?) >... >Finally, note that saying "Host B should recognize this is a broadcast >from the destination address and not forward it" is NOT a solution, >since it appears to Host B to be a perfectly legal DIRECTED broadcast >to network 192.40.1 from somewhere else, and as far as Host B knows, >he is the only way for that directed broadcast to get through; he HAS >to forward it. > Well, you might put it that way, but since it was sent on a LL broadcast address, it really isn't a directed broadcast, as those are supposed to stay unicast until they reach the destination (sub)network. At that point, they become 'plain-old' broadcasts and the usual rules apply. >Any comments/suggestions/flames? Are there non-BSD implementations >out there that handle this? Mods to BSD? Future plans from vendors? >Anything else? > First, is it really necessary for the hosts to be doing any forwarding in the first place - are they routers themselves? If not, by all means, disable gateway functionality. There are non-BSD implementations that do handle this situation - I happen to work on one ;-) (but we fixed it for a different reason ;-) and I'm certain that by the time this gets out, someone will have pointed at the apropopriate mods to BSD code. BTW - IP really doesn't need to know what the LL address was, just a boolean saying whether or not it was unicast. However, it might need to become 'smarter' in the face of IP multicasting ??? Apart from a) disabling forwarding on the hosts, or b) getting the mods put in, or c) going to a different box, your only other alternative might be to split the network onto separate wires - fun, huh ;-) I'd suggest that you push your vendor(s) to get you code that is more in line with the RFC's - beg, cajole, threaten, or whatever, because that is really the solution you appear to need. > Wayne Hathaway domain: wayne@Ultra.COM rick jones ___ _ ___ |__) /_\ | Richard Anders Jones | MPE/XL Networking Engineer | \_/ \_/ Hewlett-Packard Co. | Even MPE can do the right thing! ------------------------------------------------------------------------ Being an employee of a Standards Company, all Standard Disclaimers Apply ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990093008553200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 2 Oct 90 17:03:12 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26011; Tue, 2 Oct 90 16:56:39 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 Sep 90 08:55:32 GMT From: sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU (Rob Warnock) Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: TCP Push? Message-Id: <70729@sgi.sgi.com> References: <9009281442.AA26616@cssun.tamu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9009281442.AA26616@cssun.tamu.edu> willis@CSSUN.TAMU.EDU (Willis Marti) writes: +--------------- | This has to be one of the novice questions, but I haven't been able to dig | out the answer. Programming under SunOS 4.1, using sockets and send and all | that, how can I tell the TCP to "push" the (possibly buffered) data out *now* | and not wait to piggyback anything.... +--------------- All "BSD 4.x"-derived TCPs (and I believe that includes Sun's) automatically set the "PUSH" bit on the last packet of any Unix "write()". That is, a write to a socket *is* a "write-and-push". There are too many applications that would break if this were not the case. -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990093020594400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 2 Oct 90 17:24:24 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27041; Tue, 2 Oct 90 17:16:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 Sep 90 20:59:44 GMT From: ddl@husc6.harvard.edu (Dan Lanciani) Organization: Harvard University, Cambridge MA Subject: Re: Please boycott Xircom Message-Id: <4309@husc6.harvard.edu> References: <1990Sep26.042027.23110@news.clarkson.edu>, <5DN%9T*@rpi.edu>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article , nelson@sun.soe.clarkson.edu (Russ Nelson) writes: | In article <14568@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes: | | From what I've seen, and from what I know about people, I | doubt that there was any conspiracy to steal anything. More likely | is that they didn't even read the conditions applied to it and when | the knowledge of their mistaken violation finally made it to the | right people, they acted honestly and complied with the copyright. | | You're right in that it *is* more likely. In this case, however, | Xircom knew about the GPL, or GPV (General Public Virus) as one wag | put it. They knew they were obliged to make their source available, | and agreed to do so for those people willing to sign a nondisclosure | agreement. In spite of agreeing to do so, they will not. I hope no one takes this as a flame, but I suspect GNU/FSF proponents could help minimize incidents like this one by using more conventional terminology rather than inventing or redefining words that might have potentially misleading connotations. While it in no way excuses Xircom from ignoring the terms of the license, I think the words ``free'' and ``copyleft'' as used by FSF are likely to confuse people not familiar with the GNU license agreement. Before the FSF's usage, the term ``free'', when applied to software, often implied to many a lack of cost associated with use and/or distribution. Giving up control of proprietary code is a very real cost for many companies and they may not understand that this could be one of the costs associated with incorporating ``free'' software covered by the GNU license agreement into their product line. The non-word ``copyleft'' is probably even worse in that a corporate lawyer not aware of FSF policy may assume (foolishly, perhaps) that this is a cute way of saying that something is not covered by copyright, i.e., that it is in the public domain. Until ``copyleft'' finds its way into the legal texts (and dictionary) it might improve understanding if FSF advocates simply stated that their software is covered by a real copyright and that its use is governed by a license agreement whose terms might result in significant actual and perceived costs to certain users/distributors. Dan Lanciani ddl@harvard.* ----MESSAGE-END----