----MESSAGE-BEGIN---- <1990100109553500> Received: from ddnuvax.af.mil by NIC.DDN.MIL with TCP; Mon, 1 Oct 90 12:56:08 PDT Received: by ddnuvax.af.mil (5.57/Ultrix32) id AA09207; Mon, 1 Oct 90 14:55:41 CDT Date: Mon, 1 Oct 90 14:55:35 CDT From: darrel beach To: tcp-ip@nic.ddn.mil Cc: beach@ddnuvax.af.mil Subject: TCP/IP for DEPCA boards Message-Id: Another plea for info... Can anyone point me to drivers, software, vendors to let me run TCP/IP on PCs which have a DEPCA (Digitals Ethernet PC bus Adapter) cards. Packet drivers compatible with NCSA, KA9Q, or even a commercial package would be appreciated. Thanx in advance... Darrel Beach ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100111340000> Received: from ugw.utcs.utoronto.ca by NIC.DDN.MIL with TCP; Mon, 1 Oct 90 13:45:38 PDT Received: from UNCAMULT.BITNET (stdin) by ugw.utcs.utoronto.ca with SMTP id 57445; Mon, 1 Oct 90 16:26:35 EDT Acknowledge-To: Tom Seto Date: Mon, 1 Oct 90 15:34:00 EDT From: Tom Seto Subject: TCP/IP products To: tcp-ip@NIC.DDN.MIL Message-ID: <901001193428.521743@UNCAMULT.BITNET> Hello. We are currently putting together a RFP to obtain more computing power of the UNIX variety. While we were reviewing the various aspects of the request, a question came up: Is there a measure for the "Goodness" of a particular tcp/ip product, ie how well does it conform to the standards, how well does it perform, etc? We have in the passed tossed a package from one vendor and purchased one from another on our VAX/VMS. The UNIX systems presumably comes with a tcp in the system, but is there anyway to measure whether a vendor has done a particularly good or bad job of it? I would also welcome comments regarding products that are out there, especially products that come with a particular brand of hardware. Thanks for your time. Tom Seto Mgr, Data Comm ACS U of Calgary ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100113550700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 2 Oct 90 17:49:19 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27574; Tue, 2 Oct 90 17: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: 1 Oct 90 13:55:07 GMT From: mailrus!sharkey!cfctech!alexb@uunet.uu.net (Alex Beylin) Organization: Chrysler Financial Corporation, Southfield, MI. Subject: SLIP, IP Routers and Named Pipes Message-Id: <1990Oct1.135507.27559@cfctech.cfc.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil A project have come up around here that require multiple PCs to get dial-in access to the TCP/IP network. One of the major requirements is support for Named Pipes down to the PC. Current plan is to use SLIP and a router with dial-in ports. Would someone care to recommend a PC package that would do good SLIP emulation and a router that would be suitable for this job? Comments, suggestions are most welcome. Thanks in advance, -- Alex Alex Beylin, Unix Specialist | +1 313 948-3386 alexb@cfctech.cfc.com | Chrysler Financial Corp. sharkey!cfctech!alexb | MIS, Distributed Systems ATT Mail ID: attmail!abeylin | Southfield, MI 48034 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100115191000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 9 Oct 90 20:27:48 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24888; Tue, 9 Oct 90 20:12: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: 1 Oct 90 15:19:10 GMT From: bu.edu!rpi!zaphod.mps.ohio-state.edu!mips!ultra!wayne@bloom-beacon.mit.edu (Wayne Hathaway) Organization: Ultra Network Technologies Subject: Re: Question on forwarding broadcasts Message-Id: <1990Oct1.151910.10282@ultra.com> References: <1990Sep28.143945.7440@ultra.com>, <36540012@hpindwa.HP.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Thanks to all who responded to my "Question on forwarding broadcasts" posting. Two quickies. One, I apologize for over-simplifying the picture. In the real life situation both hosts do in fact have other network connections, so they really SHOULD be forwarding packets. If I had drawn a couple more lines it would have been clearer. But mostly, I should have read RFC 1009 more carefully, 'cause sure enough, there it is right on page 36: In general, a gateway must not forward a datagram which arrives via local network broadcast, and must not send an ICMP error message when dropping the datagram. A discussion of the rules will be found in Appendix A; see also [50]. (Interesting that this specific situation does NOT seem to be mentioned anywhere in Appendix A, however!) Now the only question is when the support for the above requirement (that is, Data Link telling IP whether a packet arrived via broadcast or multicast) will get out in the various host implementations. And THAT is what I should/would have asked, if I had read RFC 1009 better! Anyway, apologies for the wasted net bandwidth on red herrings. Now, about the REAL question ... ? 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---- <1990100116092200> Received: from WLV.IMSD.CONTEL.COM by NIC.DDN.MIL with TCP; Tue, 2 Oct 90 03:49:01 PDT Received: by WLV.IMSD.CONTEL.COM (5.64/1.25) id AA06180; Tue, 2 Oct 90 03:49:22 -0700 Date: Tue, 2 Oct 90 03:49:22 -0700 From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) Message-Id: <9010021049.AA06180@WLV.IMSD.CONTEL.COM> To: tcp-ip@nic.ddn.mil Subject: Maintainability of TELNET Sessions Over Marginal Circuits A site that I'm involved with has an interesting problem involving TELNET, specifically, and TCP/IP, in general, over encrypted and/or marginal links. I'm interested in comments from this group that might suggest a solution to this problem. For want of a better description, the organization of this network might be described as a WAN. It consists of a number of LANS each of which has, at least, one router with, at least, two direct links to other LANS. Each of the links is encrypted. The purpose of multiple direct links is to pro- vide redundant paths to a central system that provides a common database and a common set of services for the workstations on each of the LANS. When the user wishes to make use of the central system, the user establishes a TELNET connection to the central system through a process that also provides an emulation of a terminal supported by the central system. They had expected the router on loss of a circuit (loss of crypto synch) to switch over to an alternate circuit and maintain the TELNET connection. When they brought up the first LAN, they encountered two problems--the link was of poorer quality than they had thought and continually looses synch and the router did not switch circuits as they thought it would. When the TELNET connection is re-established, they are not reconnected to their pre- vious session. When crypto synchronization is lost, random data will appear on the circuit until both crypto units detect the loss of synchronization and have re-synched. The questions: 1. Do routers generally have the capability to re-route traffic over an alternate circuit? 2. How robust is IP in dealing with corrupted data streams when crypto synch is lost in the header? In the body? 3. How robust is TCP in dealing with corrupted data streams? 4. Would fudging IP, TCP, or TELNET timers by a "crypto resync constant" alleviate problems? Any comments would be appreciated. Merton , ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2707782A.6C5@intercon.com] <1990100117085800> 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: <2707782A.6C5@intercon.com> Date: 1 Oct 90 17:08:58 GMT References: <34162@cup.portal.com> <26FE4E59.1748@intercon.com> <546@fciva.FRANKLIN.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 Oct 1 18:08:58 1990 In article <546@fciva.FRANKLIN.COM>, dag@fciva.FRANKLIN.COM (Daniel A. Graifer) writes: > 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. I might be mistaken, but they do sell it as a seperate product. The last I knew it ran with any AppleTalk-IP gateway product. Course this might have changed as well. Anyone listening from Cayman, Brad? 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---- <1990100201310000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 01:51:41 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19758; Wed, 3 Oct 90 01:36: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: 2 Oct 90 01:31:00 GMT From: adelphi!news@uunet.uu.net (News Feed) Organization: Adelphi University, Garden City, NY Subject: Re: Please boycott Xircom Message-Id: <960@adelphi.edu> References: <1990Sep26.042027.23110@news.clarkson.edu>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article , nelson@sun.soe.clarkson.edu (Russ Nelson) writes: > > [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 I myself hold 3 copyrights on software I developed for the printing industry dealing with CAM and I remember posing the following question to my lawyer: How long do I have to register my copyright, and when does the copyright take effect? According to him and the form TX as well as the related booklet on filing form TX from the Library of Congress, you have up to 2 years to file your copyright registration, and the code that comes off ones pen is copyright by him/her, as long as it is not a work for hire or contracted oherwise. The implied registration covers the period before registration. As a matter of fact my lawyer told me, and I did in all cases, to just file the docuemtation and a binary listing of the code, thus leaving the source to be considered "trade secret". He stated this gives better protection. My point is, why is the above listed driver not copyright in the same manner. I certainly am confused now. Can anyone state the facts? I hate to see people get burned like that. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100201414700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 2 Oct 90 23:06:36 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12850; Tue, 2 Oct 90 22:56: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: 2 Oct 90 01:41:47 GMT From: brooks@apple.com (Kevin Brooks) Organization: Apple Computer Inc., Cupertino, CA Subject: HP TCP/IP router/bridge? Message-Id: <45306@apple.Apple.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does anyone know of a bridge or router that will allow HP hosts running TCP/IP which speak IEEE style packets (802.2 encapsulated) to communicate with ethernet style IP implementations? Do most of the router/bridge vendors support both IEEE and ethernet style IP packets? Thanks in advance Kevin -- Kevin Brooks A/UX Specialist, Apple Computer UUCP: {mtxinu,sun,nsc,voder}!apple!brooks APPLELINK: AUX.DUDE@applelink.apple.com Internet: brooks@apple.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100201485600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 00:48:53 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17494; Wed, 3 Oct 90 00:45: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: 2 Oct 90 01:48:56 GMT From: news@ncsuvx.ncsu.edu (Shahrooz A Alavi) Organization: NC State University Subject: >>> Internetworking with TCP/IP book FOR SALE <<< Message-Id: <1990Oct2.014856.12758@ncsuvx.ncsu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil NEW "Internetworking with TCP/IP. Principles, Protocols and Arch." by D Comer [Prentice Hall] $35 (includes shipping) Send me an email with your daytime mailing address and I will send it to you UPS/COD. ----------------------------------------------------------- S. Alavi (919) 467-7909 ssa@eceugs.ece.ncsu.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100202410900> Received: from mwunix.mitre.org by NIC.DDN.MIL with TCP; Tue, 2 Oct 90 06:22:49 PDT Return-Path: Received: from [128.29.151.2] by mwunix.mitre.org (5.61/SMI-2.2) id AA05329; Tue, 2 Oct 90 09:22:11 -0400 Received: from localhost.mitre.org by chance.mitre.org (4.0/SMI-4.0) id AA13109; Tue, 2 Oct 90 09:21:11 EDT Message-Id: <9010021321.AA13109@chance.mitre.org> To: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) Cc: tcp-ip@nic.ddn.mil Subject: Re: Maintainability of TELNET Sessions Over Marginal Circuits In-Reply-To: Your message of Tue, 02 Oct 90 03:49:22 -0700. Date: Tue, 02 Oct 90 09:21:09 -0400 From: H. Craig McKee >When they brought up the first LAN ... the link was of poorer quality >than they had thought and continually looses [crypto] synch .... Is the link protocol synchronous (eg, HDLC) or asynchronous (start/ stop bits)? My experience with synchronous links is that a crypto like the KG-84 rarely looses synch (because modem clock recovery circuits are generally very good). For some cryptos there is a mode of operation called CTAC that is self-synchronizing; it does not require loss-of- synch logic in another box. The site can get expert advice from their cryptologic support center or the National Security Agency. >2. How robust is IP in dealing with corrupted data streams when crypto > synch is lost in the header? In the body? >3. How robust is TCP in dealing with corrupted data streams? Corrupted data will be detected and discarded by error detection logic at the link, IP, and TCP layers. >4. Would fudging IP, TCP, or TELNET timers by a "crypto resync constant" > alleviate problems? Give it a try; it's not a good hack, but I've done some bizarre things when trying to get a circuit up. Regards - Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100203195100> Received: from ftp.com by NIC.DDN.MIL with TCP; Tue, 2 Oct 90 08:41:23 PDT Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA12212; Tue, 2 Oct 90 11:39:51 -0500 Date: Tue, 2 Oct 90 11:39:51 -0500 Message-Id: <9010021639.AA12212@ftp.com> To: darrel beach Subject: Re: TCP/IP for DEPCA boards 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'm posting to the list because this question gets asked awfully frequently: DEC's PCSA and DECNet/DOS products currently use a hardware-independent interface-sharing driver spec called "DLL". It is documented in the VaxMate Tech Ref. DEC supplies DLL drivers for various interfaces (theirs and 3Com's, I think) with PCSA and DECNet/DOS, and a number of other board vendors (e.g. Western Digital, Interlan that I know of) also offer DLL drivers for their own boards. FTP's PC/TCP (part PC-223) and Wollongong's WIN/PC can use DLL drivers. In addition, DEC has or will soon release an NDIS driver for the DEPCA. If you have this, you can use it with our freeware NDIS to Packet Driver adapter module (in pub/packet.driver/NDIS on vax.ftp.com, I won't mail it to you) and any of the TCP/IPs that support the Packet Driver (PC/TCP, WIN/PC, BWTCP, PCIP, KA9Q, NCSA, CUTCP, PCRoute, etc.). James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100205225200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 01:19:50 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA18568; Wed, 3 Oct 90 01:10: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 Oct 90 05:22:52 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: TCP/IP for DEPCA boards Message-Id: References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article beach@DDNUVAX.AF.MIL (darrel beach) writes: Can anyone point me to drivers, software, vendors to let me run TCP/IP on PCs which have a DEPCA (Digitals Ethernet PC bus Adapter) cards. Packet drivers compatible with NCSA, KA9Q, or even a commercial package would be appreciated. Not yet, but the picture is coming into focus. We've gone from "Digital refuses to release programming information" (that was just a rumor) to "How may I help get you the information you need to write a packet driver?" Maybe in a couple of months... -- --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---- <1990100209231400> Received: from NMSU.Edu by NIC.DDN.MIL with TCP; Tue, 2 Oct 90 14:24:54 PDT Received: from dante (dante.NMSU.Edu) by NMSU.Edu (4.1/NMSU-1.18) id AA17311; Tue, 2 Oct 90 15:23:14 MDT Date: Tue, 2 Oct 90 15:23:14 MDT From: Message-Id: <9010022123.AA17311@NMSU.Edu> Received: by dante (4.0/NMSU) id AA24729; Tue, 2 Oct 90 15:27:03 MDT To: tcp-ip@sri-nic.arpa subscribe Tim Baggett ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100212233400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 03:52:02 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25521; Wed, 3 Oct 90 03:43: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 Oct 90 12:23:34 GMT From: ingr!b11!usenet@uunet.uu.net (Usenet Network) Organization: Intergraph Corp. Huntsville, AL Subject: Re: SLIP, IP Routers and Named Pipes Message-Id: <8879@allen.ingr.com> References: <1990Oct1.135507.27559@cfctech.cfc.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil in article <1990Oct1.135507.27559@cfctech.cfc.com>, alexb@cfctech.cfc.com (Alex Beylin) says: > > Would someone care to recommend a PC package that would do good > SLIP emulation and a router that would be suitable for this job? --- The company I work for sells PC/NFS. I do not have experiance with the product over serial lines, but PC/NFS (from Sun) does support SLIP. SUN US SALES is listed as: 1-800-821-4643 For routers see cisco or there are terminal servers that support SLIP. I worked for an outfit that sold cisco and the company I work for now sells the Encore Annex II. cisco 415-326-1941 encore (terminal server with slip) 617-460-0500 NOTE: I am not endorsing these products, but they are worth investigation. -- * John E. Allen - Intergraph Corporation - (205) 730-8627 * * System Sales Support * * ingr!b23b!allen!jallen@uunet.uu.net * ************************************************************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100213283500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 03:05:17 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23309; Wed, 3 Oct 90 02:59: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: 2 Oct 90 13:28:35 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!rphroy!cfctech!sharkey!fmsrl7!slee01!hugh@ucsd.edu (Hugh Fader) Organization: Ford Motor Co, Sci. Res. Labs., Dearborn, MI Subject: Is there a program like telnet, but driven by a script? Message-Id: <26797@fmsrl7.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I need to duplicate UNIX-to-UNIX rsh functionality going UNIX-to-VMS. I am running a Sun Sparcstation and can communicate with the VAX using telnet and ftp via an ULTRIX gateway (the VAX only runs DECNET). One solution to my problem would be a telnet-like program which accepts a script containing expect/send pairs much like UUCP and some PC communications programs. Does such a program exist? I would also appreciate any suggestions of alternate solutions. Thanks in advance. -- Hugh Fader hugh@slee01.srl.ford.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100214203600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 02:19:05 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21341; Wed, 3 Oct 90 02:15: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: 2 Oct 90 14:20:36 GMT From: pacbell.com!pacbell!varian!vaxwaller!phil@ucsd.edu (Phil Newton) Organization: Varian Instruments, Walnut Creek CA Subject: HOW CAN I GET ON THE INTERNET??? Message-Id: <4597@vaxwaller.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am interested in finding out HOW to gain access to the Internet. Would anyone out there who knows how to so this please let me know, too? Thanks in advance for your assistance! -- Philip T. Newton (415)945-2272 Varian Instruments 2700 Mitchell Drive Walnut Creek, CA. 94598 {zehntel,pacbell,lll-winken}!varian!phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100217514900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 2 Oct 90 20:23:35 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05287; Tue, 2 Oct 90 20:12: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: 2 Oct 90 17:51:49 GMT From: prang!marciano@lll-winken.llnl.gov (marciano pitargue) Organization: Vitalink Comm. Corp. Subject: Re: SNMP comparison Message-Id: <1640@prang.UUCP> References: <9009241517.AA08899@ucbvax.Berkeley.EDU>, <1990Sep28.193454.21065@kth.se> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >Something? Vitalink ( I think it's a repackaged HP product ) ... >-- >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 it's called the Wan Manager. it's is _not_ a repackaged HP product. /marciano marciano@vitalink.com vitam6!marciano@uunet.uu.net ...uunet!!vitam6!marciano disclaimer: noun. 1. a denial or disavowal of legal claim: relinquishment of or formal refusal to accept an interest or estate. 2. a writing that embodies a legal disclaimer. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010021825.AA01847@ucbvax.Berkeley.EDU] <1990100218254100> From: HANK@TAUNIVM.BITNET (Hank Nussbacher) Newsgroups: comp.protocols.tcp-ip Subject: Router scorecard V1.6 Message-ID: <9010021825.AA01847@ucbvax.Berkeley.EDU> Date: 2 Oct 90 18:25:41 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Hank Nussbacher Organization: The Internet Lines: 452 Posted: Tue Oct 2 19:25:41 1990 X-Unparsable-Date: Tue, 02 Oct 90 15:03:34 IST 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. This report may be freely reproduced as long as nothing is altered or removed. 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 [The above employer has nothing to do with this scorecard so if something bothers you about it, I take full responsibility.] END OF CAVEATS -------------------------------------------------------------------- V1.6 update: Various vendors have been in contact with me but after expressing interest in having an entry for their machine they disappear. Other vendors have tried to change the particular hardware box that is being compared to another box. I hope that vendors will participate in keeping this scorecard up-to-date. -------------------------------------------------------------------- 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 October 1990 Version 1.6 +--------------+--------------+---------------+ Multiprotocol | cisco AGS+ | Wellfleet LN | Proteon p4200 | Router | Rel. 8.1(14) | Rel. 5.35 | | +--------------+--------------+---------------+ 1. General | | | | - # of slots | 9 | 4 | 7 | - Processor | 68020 | 68020 | 68020 | - Memory | 4Mbyte | 4Mbyte | 2Mbyte | - Updates via | ROM, TFTP | diskette,TFTP| diskette,TFTP | - Speed of bus | 530Mb/sec (a)| 320Mb/sec | | - Boot from | | | | - ROM | Yes | No | No | - Net-boot | | | | - IP | Yes | No | Yes | - Decnet (MOP) | No | No | No | - Diskette | No | Yes | No | - Another router | Yes | No | No | - Volatile changes | Yes (b) | No | Yes (h) | - CPU statistics | Yes (c) | No | Yes | - Memory stats | Yes | No | Yes | - Ease of install | Very easy | menu driven | | - Documentation | Difficult | Skimpy | Clear, orderly| - Autorestart (d) | Yes | Yes | Yes | - Restart for | | | | config changes | No | Yes | Yes | - Watchdog timer | Yes | | Yes | - Reboot time (e) | 29 sec (f) | 60 sec | 32 sec (i) | - Power-up time (g)| 29 sec | 120 sec | 32 sec (i) | 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. h. Only available for DECnet and OSPF, and only for a subset of available parameters. i. Booting via Proteon's Intergrated Boot Device, with running diagnostics. 2. Interfaces (a) | | | | - Ethernet | | | | (802.3 10Base5) | 24x10Mb | 8x10Mb | 7x10Mb | - Thin Ethernet (b)| | | | (802.3 10Base2) | No | 8x10Mb | No | - 4Mb Token Ring | 3x4Mb (i) | 4x4Mb | 7x4Mb | - 16Mb Token Ring | Rel 8.2 (j) | Rel 5.40 (c) | No | - RS232 | 24x64kb | 16x64kb | 14x64kb | - RS449 | 12x64kb | 16x64kb | 14x64kb | - V.35 | 12x64kb | 16x64kb | 14x64kb | - T1 | 12x1.544Mb | 8x1.544Mb | 14x1.544Mb | - CEPT DS1 (2Mb) | 12x2Mb | 8x2Mb | 12x2Mb | - FDDI | 2x100Mb | Rel 5.50 (d) | 2x100Mb | - DAS (Dual) (e)| Yes | Yes | Yes | - SAS (Single) | Yes | No | Yes | - Ultranet | Rel 8.2 (k)| | | - X.25 | | | | - Max # of VCs | Unlimited (f)| 254 | 255 | - Card types (g) | 6E, 1E2S, | 2E, 1E1S, | 1E, 2S, 4S, | per slot | 2E2S, 4S, | 1E2S, 2E2S, | 1TR, .5F | | 1TR, 1F (h)| 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, F: FDDI h. The 6E and 1F cards are for the faster cBus only. i. The AGS can take 4 Token Rings while the AGS+ can only take 3. j. To be supported in later release of Version 8.2. k. Ultranet support will be in a later release of 8.2 but will only support a 125Mb full-duplex connection to Ultranet's 1Gb LAN. 3. Interface part II | | | | - Frame Relay (a) | Rel 8.2 | | | - Ethernet | | | | encapsulation | | | | - Standard v2.0 | Yes | | Yes | - IEEE 802.3 | Yes | | Yes | - SNAP 802.2 | | | | (RFC1042) | Yes | Yes | No | - Serial | | | | encapsulation | | | | - HDLC | Yes | | Yes | - LAPB | Yes | | No | - PPP (RFC1134) | Yes | | | - DDCMP | No | No | No | - X.25 | Yes | | Yes | - SVC | Yes | Yes | Yes | - PVC | Yes | Yes | Yes | - Encryption (b) | Pulse-time | | | - Filtering by | | | | source/dest | Yes | 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. c. For CLNP only. 4. IP | | | | - Subnetting | | | | (RFC950) | Yes | Yes | Yes | - ARP (RFC826) | Yes | Yes | Yes | - RARP (RFC903) | Yes | No | No | - BOOTP (RFC951) | Yes | No | No | - proxy ARP | | | | (RFC1027) | Yes | Yes | Yes | - ICMP | Yes | Yes | Yes | - Name-server | Yes | No | No | - Accounting | Yes | No | No | - MTU | Yes | No | No | - Security - IPSO | Yes | No | | - Static routing | Yes | Yes | Yes | - Source routing | Yes | No | Yes | - Filters | | | | - source/dest | Yes | Yes | Yes | - TCP | Yes | | | - UDP | Yes | | | - ICMP | Yes | | | - by protocol (b)| Yes (a) | Yes | | - Routing protocols| | | | - RIP (RFC1058) | Yes | Yes | Yes | - EGP (RFC904) | Yes | Yes | Yes | - BGP (RFC1105) | Yes | No | | - Proprietary | IGRP | eRIP | No | - Filtering | Yes | No | Yes | - Default routes | Yes | 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 | Yes | - Area Router | Yes | No | Yes | - Phase IV+ (a) | Rel 8.2 | No | | - Phase IV-V | | | | Transitional gty | Rel 8.2 | | | - Phase V | Yes (b) | No | Yes (b) | - Address xlation | | | | gateway (c) | Yes | No | No | - NCP | | | | - area-max-cost | Yes | Yes | Yes | - area-max-hops | Yes | Yes | Yes | - max-address | Yes | Yes | Yes | - max-area | Yes | Yes | Yes | - max-cost | Yes | Yes | Yes | - max-hops | Yes | Yes | Yes | - max-visits | Yes | Yes | Yes | - router-priority| Yes | Yes | Yes (e) | - hello-timer | Yes | Yes | Yes | - routing-timer | Yes | Yes | Yes | - Filtering | | | | - source/dest | Yes | No | Yes | - by protocol | No | No | No | - by object | No | No | No | - routing | Yes (d) | No | Yes (d) | - MOP | Bridged | Bridged | Yes (f) | - Static routing | No | No | No | - Max routing table| 1023 | 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. e. On a per circuit basis, as required by DECnet specs. f. MOP System ID. 6. Bridging | | | | - Local bridging | Yes | Yes | No | - LAVC (a) | Yes | Yes | No | - Remote bridging | Yes (b) | Yes | No | - Transparent | | | | - Learning | Yes | Yes | No | - Spanning tree | | | | (IEEE 802.1) | Yes | Yes | No | - Priority (c) | Rel 8.2 | No | No | - Filtering | | | | - Multicast | Yes | Yes | No | - Protocol | Yes | Yes | No | - Source/dest | Yes | Yes (g) | No | - Masking (d) | No | No | No | - Load sharing | Yes (e) | Yes | | - Token Ring | | | | - Source route | Yes | | Yes | - Multi-ring (f) | Yes | | No | 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 | Yes | - UB derivitive | Yes | | Yes | - Appletalk | | | | - Phase 1 | Yes | Yes | Yes | - Phase 2 | Rel 8.2 | Rel 5.40 | No | - Tokentalk | Rel 8.2 | Yes | No | - Ethertalk | Yes | Yes | Yes | - Localtalk | No | | No | - RTMP | Yes | Rel 5.40 | Yes | - AARP | Yes | Rel 5.40 | Yes | - NBP | Yes | Rel 5.40 | Yes | - EP | Yes | Rel 5.40 | Yes | - ATP | Yes | | Yes | - ZIP | Yes | Rel 5.40 | Yes | - DDP | Yes | Yes | Yes | - ISO | | | | - ISO 8473 CLNP | Yes | No | Yes | - ISO 9542 ES-IS | Yes | No | Yes | - Apollo Domain | Yes | No | Yes | - Novell IPX | Yes (a) | Yes | Yes | - Banyan Vines | Rel 8.2 | | | - X.25 | Yes | Yes | Yes | - bridging | Rel 9.0 | Yes | No | - routing | Yes | Yes | Yes | - switching | Yes | Yes ??? | No | - 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 | Yes | - SNMP | | | | - Platform | Sun 3, Sparc | Sun 3 | 80286 AT | - External | | | | software (b) | No (c) | No | 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) | No | - Traceroute | Yes | No | | - Telnet | Yes (h) | Yes (i) | Yes (n) | - MOP Remote Cons. | Rel. 8.2 | Bridged | No | - NICE (j) | No | No | No | - Decnet connect | No | No | No | - Passwords (k) | Yes | Yes | Yes | - Netview support | | | | - Disable lines | | | | dynamically | Yes (l) | Yes | Yes | Notes: 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. n. Proteon is limited to 2 incoming and no outgoing sessions. 9. Debugging & | | | | Monitoring | | | | - Data-Link Layer | Yes | Yes | Yes | - LAN | Yes | Yes | Yes | - Link | Yes | Yes | Yes | - Decnet | Yes | Yes | Yes | - Tcp/Ip | Yes | Yes | Yes | - Event log | Yes | Yes | Yes | - Environmentals | Yes | No | 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) | No | - standby line (a)| No | No | No | - fault tolerant(b)| No | No | No | - field tolerant(c)| No | No | No | - broadcast storms | Yes | No | Yes | 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---- <1990100218333400> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Tue, 2 Oct 90 07:33:35 PDT Received: from TAUNIVM.TAU.AC.IL by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 1163; Tue, 02 Oct 90 10:32:02 EDT Received: by TAUNIVM (Mailer R2.03B) id 0056; Tue, 02 Oct 90 15:04:39 IST Date: Tue, 02 Oct 90 15:03:34 IST From: Hank Nussbacher Subject: Router scorecard V1.6 To: cisco@spot.colorado.edu, wellfleet@nstn.ns.ca, tcp-ip@nic.ddn.mil, ripe@mcsun.EU.NET, p4200@devvax.tn.cornell.edu Reply-To: Hank Nussbacher 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. This report may be freely reproduced as long as nothing is altered or removed. 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 [The above employer has nothing to do with this scorecard so if something bothers you about it, I take full responsibility.] END OF CAVEATS -------------------------------------------------------------------- V1.6 update: Various vendors have been in contact with me but after expressing interest in having an entry for their machine they disappear. Other vendors have tried to change the particular hardware box that is being compared to another box. I hope that vendors will participate in keeping this scorecard up-to-date. -------------------------------------------------------------------- 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 October 1990 Version 1.6 +--------------+--------------+---------------+ Multiprotocol | cisco AGS+ | Wellfleet LN | Proteon p4200 | Router | Rel. 8.1(14) | Rel. 5.35 | | +--------------+--------------+---------------+ 1. General | | | | - # of slots | 9 | 4 | 7 | - Processor | 68020 | 68020 | 68020 | - Memory | 4Mbyte | 4Mbyte | 2Mbyte | - Updates via | ROM, TFTP | diskette,TFTP| diskette,TFTP | - Speed of bus | 530Mb/sec (a)| 320Mb/sec | | - Boot from | | | | - ROM | Yes | No | No | - Net-boot | | | | - IP | Yes | No | Yes | - Decnet (MOP) | No | No | No | - Diskette | No | Yes | No | - Another router | Yes | No | No | - Volatile changes | Yes (b) | No | Yes (h) | - CPU statistics | Yes (c) | No | Yes | - Memory stats | Yes | No | Yes | - Ease of install | Very easy | menu driven | | - Documentation | Difficult | Skimpy | Clear, orderly| - Autorestart (d) | Yes | Yes | Yes | - Restart for | | | | config changes | No | Yes | Yes | - Watchdog timer | Yes | | Yes | - Reboot time (e) | 29 sec (f) | 60 sec | 32 sec (i) | - Power-up time (g)| 29 sec | 120 sec | 32 sec (i) | 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. h. Only available for DECnet and OSPF, and only for a subset of available parameters. i. Booting via Proteon's Intergrated Boot Device, with running diagnostics. 2. Interfaces (a) | | | | - Ethernet | | | | (802.3 10Base5) | 24x10Mb | 8x10Mb | 7x10Mb | - Thin Ethernet (b)| | | | (802.3 10Base2) | No | 8x10Mb | No | - 4Mb Token Ring | 3x4Mb (i) | 4x4Mb | 7x4Mb | - 16Mb Token Ring | Rel 8.2 (j) | Rel 5.40 (c) | No | - RS232 | 24x64kb | 16x64kb | 14x64kb | - RS449 | 12x64kb | 16x64kb | 14x64kb | - V.35 | 12x64kb | 16x64kb | 14x64kb | - T1 | 12x1.544Mb | 8x1.544Mb | 14x1.544Mb | - CEPT DS1 (2Mb) | 12x2Mb | 8x2Mb | 12x2Mb | - FDDI | 2x100Mb | Rel 5.50 (d) | 2x100Mb | - DAS (Dual) (e)| Yes | Yes | Yes | - SAS (Single) | Yes | No | Yes | - Ultranet | Rel 8.2 (k)| | | - X.25 | | | | - Max # of VCs | Unlimited (f)| 254 | 255 | - Card types (g) | 6E, 1E2S, | 2E, 1E1S, | 1E, 2S, 4S, | per slot | 2E2S, 4S, | 1E2S, 2E2S, | 1TR, .5F | | 1TR, 1F (h)| 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, F: FDDI h. The 6E and 1F cards are for the faster cBus only. i. The AGS can take 4 Token Rings while the AGS+ can only take 3. j. To be supported in later release of Version 8.2. k. Ultranet support will be in a later release of 8.2 but will only support a 125Mb full-duplex connection to Ultranet's 1Gb LAN. 3. Interface part II | | | | - Frame Relay (a) | Rel 8.2 | | | - Ethernet | | | | encapsulation | | | | - Standard v2.0 | Yes | | Yes | - IEEE 802.3 | Yes | | Yes | - SNAP 802.2 | | | | (RFC1042) | Yes | Yes | No | - Serial | | | | encapsulation | | | | - HDLC | Yes | | Yes | - LAPB | Yes | | No | - PPP (RFC1134) | Yes | | | - DDCMP | No | No | No | - X.25 | Yes | | Yes | - SVC | Yes | Yes | Yes | - PVC | Yes | Yes | Yes | - Encryption (b) | Pulse-time | | | - Filtering by | | | | source/dest | Yes | 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. c. For CLNP only. 4. IP | | | | - Subnetting | | | | (RFC950) | Yes | Yes | Yes | - ARP (RFC826) | Yes | Yes | Yes | - RARP (RFC903) | Yes | No | No | - BOOTP (RFC951) | Yes | No | No | - proxy ARP | | | | (RFC1027) | Yes | Yes | Yes | - ICMP | Yes | Yes | Yes | - Name-server | Yes | No | No | - Accounting | Yes | No | No | - MTU | Yes | No | No | - Security - IPSO | Yes | No | | - Static routing | Yes | Yes | Yes | - Source routing | Yes | No | Yes | - Filters | | | | - source/dest | Yes | Yes | Yes | - TCP | Yes | | | - UDP | Yes | | | - ICMP | Yes | | | - by protocol (b)| Yes (a) | Yes | | - Routing protocols| | | | - RIP (RFC1058) | Yes | Yes | Yes | - EGP (RFC904) | Yes | Yes | Yes | - BGP (RFC1105) | Yes | No | | - Proprietary | IGRP | eRIP | No | - Filtering | Yes | No | Yes | - Default routes | Yes | 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 | Yes | - Area Router | Yes | No | Yes | - Phase IV+ (a) | Rel 8.2 | No | | - Phase IV-V | | | | Transitional gty | Rel 8.2 | | | - Phase V | Yes (b) | No | Yes (b) | - Address xlation | | | | gateway (c) | Yes | No | No | - NCP | | | | - area-max-cost | Yes | Yes | Yes | - area-max-hops | Yes | Yes | Yes | - max-address | Yes | Yes | Yes | - max-area | Yes | Yes | Yes | - max-cost | Yes | Yes | Yes | - max-hops | Yes | Yes | Yes | - max-visits | Yes | Yes | Yes | - router-priority| Yes | Yes | Yes (e) | - hello-timer | Yes | Yes | Yes | - routing-timer | Yes | Yes | Yes | - Filtering | | | | - source/dest | Yes | No | Yes | - by protocol | No | No | No | - by object | No | No | No | - routing | Yes (d) | No | Yes (d) | - MOP | Bridged | Bridged | Yes (f) | - Static routing | No | No | No | - Max routing table| 1023 | 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. e. On a per circuit basis, as required by DECnet specs. f. MOP System ID. 6. Bridging | | | | - Local bridging | Yes | Yes | No | - LAVC (a) | Yes | Yes | No | - Remote bridging | Yes (b) | Yes | No | - Transparent | | | | - Learning | Yes | Yes | No | - Spanning tree | | | | (IEEE 802.1) | Yes | Yes | No | - Priority (c) | Rel 8.2 | No | No | - Filtering | | | | - Multicast | Yes | Yes | No | - Protocol | Yes | Yes | No | - Source/dest | Yes | Yes (g) | No | - Masking (d) | No | No | No | - Load sharing | Yes (e) | Yes | | - Token Ring | | | | - Source route | Yes | | Yes | - Multi-ring (f) | Yes | | No | 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 | Yes | - UB derivitive | Yes | | Yes | - Appletalk | | | | - Phase 1 | Yes | Yes | Yes | - Phase 2 | Rel 8.2 | Rel 5.40 | No | - Tokentalk | Rel 8.2 | Yes | No | - Ethertalk | Yes | Yes | Yes | - Localtalk | No | | No | - RTMP | Yes | Rel 5.40 | Yes | - AARP | Yes | Rel 5.40 | Yes | - NBP | Yes | Rel 5.40 | Yes | - EP | Yes | Rel 5.40 | Yes | - ATP | Yes | | Yes | - ZIP | Yes | Rel 5.40 | Yes | - DDP | Yes | Yes | Yes | - ISO | | | | - ISO 8473 CLNP | Yes | No | Yes | - ISO 9542 ES-IS | Yes | No | Yes | - Apollo Domain | Yes | No | Yes | - Novell IPX | Yes (a) | Yes | Yes | - Banyan Vines | Rel 8.2 | | | - X.25 | Yes | Yes | Yes | - bridging | Rel 9.0 | Yes | No | - routing | Yes | Yes | Yes | - switching | Yes | Yes ??? | No | - 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 | Yes | - SNMP | | | | - Platform | Sun 3, Sparc | Sun 3 | 80286 AT | - External | | | | software (b) | No (c) | No | 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) | No | - Traceroute | Yes | No | | - Telnet | Yes (h) | Yes (i) | Yes (n) | - MOP Remote Cons. | Rel. 8.2 | Bridged | No | - NICE (j) | No | No | No | - Decnet connect | No | No | No | - Passwords (k) | Yes | Yes | Yes | - Netview support | | | | - Disable lines | | | | dynamically | Yes (l) | Yes | Yes | Notes: 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. n. Proteon is limited to 2 incoming and no outgoing sessions. 9. Debugging & | | | | Monitoring | | | | - Data-Link Layer | Yes | Yes | Yes | - LAN | Yes | Yes | Yes | - Link | Yes | Yes | Yes | - Decnet | Yes | Yes | Yes | - Tcp/Ip | Yes | Yes | Yes | - Event log | Yes | Yes | Yes | - Environmentals | Yes | No | 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) | No | - standby line (a)| No | No | No | - fault tolerant(b)| No | No | No | - field tolerant(c)| No | No | No | - broadcast storms | Yes | No | Yes | 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---- <1990100218561400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 03:36:20 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24393; Wed, 3 Oct 90 03:21: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: 2 Oct 90 18:56:14 GMT From: bu.edu!buit13!kwe@uunet.uu.net (Kent England) Organization: Boston U. Information Technology Subject: Re: Maintainability of TELNET ... Message-Id: <65390@bu.edu.bu.edu> References: <9010021049.AA06180@WLV.IMSD.CONTEL.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010021049.AA06180@WLV.IMSD.CONTEL.COM> mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes: >... > 1. Do routers generally have the capability to re-route traffic over > an alternate circuit? ... > 4. Would fudging IP, TCP, or TELNET timers by a "crypto resync constant" > alleviate problems? > One problem with routing fallback has to do with the time constants of the routing protocols (and link level fault protocols, if any) and the time constant of the failure. Sounds to me like crypto sync loss is a fast time constant sort of error. This begs the question of whether the routing protocol should spend the time required to re-route or whether it should hold off and wait for the link to come back up. With the advent of open link state protocols which converge "instantly", perhaps this point is becoming moot, but with distance vector protocols it is very hard to deal with link level state "flapping" side effects and still keep routing traffic down. Same thinking applies to TCP or Telnet timers. Should they wait a short time or a long time? How should they treat redirects and black holes? I think that should be up to the application, since mail usually has a different idea than telnet would. Put me in the "hate TCP/IP keepalives" camp. --Kent ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100220585400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 07:06:44 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03123; Wed, 3 Oct 90 06:41: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: 2 Oct 90 20:58:54 GMT From: crash!ncr-sd!ncrcae!wingo@nosc.mil (Dave Wingo) Organization: NCR Corp., Engineering & Manufacturing - Columbia, SC Subject: network file backup Message-Id: <6613@ncrcae.Columbia.NCR.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does anyone know of a network based (TCP/IP) file system back-up/restore product that is currently available for UNIX 5.3 or 5.4. How about one that would also be available on OS/2 based systems..... We are very interested in this type of product.... Thanks in advance for your help..... David Wingo, NCR Corp System 3000 voice 803-791-6476 email: wingo@Columbia.NCR.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100221465800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 02:48:16 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22346; Wed, 3 Oct 90 02:36: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 Oct 90 21:46:58 GMT From: julius.cs.uiuc.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!wls@apple.com (Bill Stapleton) Organization: Computing Services, U of Wisc-Milwaukee Subject: IBM 9000 TCP/IP, lpr? Message-Id: <6727@uwm.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Another campus entity is looking into purchasing an IBM 9000 system, which would run VM, and comes with some sort of TCP/IP package. They want to be sure it works with our (BSD) network, especially for printing. Does anybody know if it's possible for an IBM 9000 VM system to talk Berkeley lpr protocol? Any information is most appreciated. -- Bill Stapleton wls@csd4.csd.uwm.edu uwmcsd4!wls ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100300583600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 04:33:35 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27171; Wed, 3 Oct 90 04:21: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: 3 Oct 90 00:58:36 GMT From: snorkelwacker!usc!zaphod.mps.ohio-state.edu!uwm.edu!srcsip!pserv!stevem@bloom-beacon.mit.edu (Steve Mestad) Organization: Honeywell CFS/MO, Mpls, MN Subject: Looking for Rarpd Message-Id: <10@pserv.CFSMO.Honeywell.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am looking for source for the rarp daemon. I would like it for HP-UX 7.0 on the HP 9000 series 300 systems but at this point I would be willing to take any source and hope for the best. Please let me know where I can find this beastie. Thanks. SM stevem@cfsmo.honeywell.com stevem%pserv@src.honeywell.com (if the above is ill from your location) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100302344900> Received: from wolf.cisco.com by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 08:34:29 PDT Received: from dustbin.cisco.com by wolf.cisco.com with TCP; Wed, 3 Oct 90 08:31:48 -0700 To: brooks@apple.com (Kevin Brooks) Cc: tcp-ip@nic.ddn.mil Subject: Re: HP TCP/IP router/bridge? In-Reply-To: Your message of "02 Oct 90 01:41:47 GMT." <45306@apple.Apple.COM> Date: Wed, 03 Oct 90 08:34:49 MDT From: Greg Satz The cisco router will do this and has for the last three year. Drop a note to customer-service@cisco.com for more information. Greg ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100303222200> Received: from ftp.com by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 08:41:58 PDT Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA26835; Wed, 3 Oct 90 11:42:22 -0500 Date: Wed, 3 Oct 90 11:42:22 -0500 Message-Id: <9010031642.AA26835@ftp.com> To: mailrus!sharkey!cfctech!alexb@uunet.uu.net (Alex Beylin) Subject: Re: SLIP, IP Routers and Named Pipes 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 want Named Pipes, you need LAN Manager, which means Netbios, which means RFC 1001/1002 if you want it over TCP/IP. I don't know of any RFC 1001/1002 Netbioses which implement "p-nodes" or "m-nodes", so you can't use a conventional router. TWG has a hack which uses static client configuration to avoid this problem, but a cleaner alternative (IMHO) is to use the cisco SLIP concentrator, which keeps the clients on the same net/subnet as its attached ethernet (fine as long as your servers are on that ethernet). If you use the latter approach, you can use our PC/TCP as well as TWG's WIN/PC. I can never remember if Beame & Whiteside has an RFC Netbios, but none of the others (Excelan, U-B, CMC, Interlan, Bridge) support SLIP. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100305121200> Received: from CORNELLC.cit.cornell.edu by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 13:24:36 PDT Received: from UCCVMA.UCOP.EDU by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 8331; Wed, 03 Oct 90 16:24:13 EDT Received: from UCCVMA.UCOP.EDU (SPGDRP) by UCCVMA.UCOP.EDU (Mailer R2.07) with BSMTP id 5134; Wed, 03 Oct 90 13:26:53 PST Date: Wed, 03 Oct 90 13:12:12 PST From: "Donald R. Proctor" Subject: Re: SLIP, IP Routers and Named Pipes To: Alex Beylin , tcp-ip@nic.ddn.mil In-Reply-To: Your message of Mon, 1 Oct 90 13:55:07 GMT >A project have come up around here that require multiple >PCs to get dial-in access to the TCP/IP network. One of the >major requirements is support for Named Pipes down to the PC. >Current plan is to use SLIP and a router with dial-in ports. > >Would someone care to recommend a PC package that would do good >SLIP emulation and a router that would be suitable for this job? > Alex: We intend on implementing a similar system here, although we don't have the named pipes requirement. We have a cisco terminal server that can be configured with several dial-in ports. The software angle is a bit more complex. As I understand it, the remote PC user will need to use a communications package like kermit or xmodem to connect to the terminal server. A commercial (such as FTP's PC/TCP) or public domain (such as NCSA telnet) TCP-IP package can then be run over SLIP. FTP's package can be ordered with SLIP, and there is a SLIP driver in Clarkson's pd packet driver distribution. I should point out that cisco's box can provide the telnet connection itself, so that a remote PC user can dial in and start a telnet session from the server without having the TCP-IP software installed on the PC. However, if need 3270 emulation (as we do), the current release of the cisco's software won't do the job. I hope my more knowledgeable colleagues will correct me if I have made any egregious errors... Don Proctor Information Systems & Computing University of California 415/987-0356 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100305270800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 5 Oct 90 19:56:56 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15415; Fri, 5 Oct 90 19:41: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: 3 Oct 90 05:27:08 GMT From: munnari.oz.au!mtiame!ubeaut!mwp@uunet.uu.net (Michael Paddon) Organization: Digital Equipment Corp., Melbourne, Australia Subject: Re: TCP segment size -- user defined? Message-Id: <256@ubeaut.oz.au> References: <266@aldetec.oz.au> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil From article <266@aldetec.oz.au>, by mawson@aldetec.oz.au (Graeme Mawson): > > 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? It surely is. On BSD based systems, the macro TCP_MSS is defined in /usr/include/netinet/tcp.h. This may be changed with impunity since the negotiation undergone at connection setup time chooses the smaller of the segment sizes supported by each implementation. There is not much point setting TCP_MSS to be greater than (maximum IP packet size - IP header size - TCP header size) [536 octets] since IP fragmentation will take place. Receipt of a fragmented packet is an all or nothing proposition; a good thing to avoid for throughput reasons. In general, the BSD TCP parameters in tcp.h and tcp_timers.h are close to optimal for ethernet (default RTT is a little pessimistic, but that is so the latter stages of backoff work properly). I found I had to do a fair bit of tuning to get everything right for a SLIP environment with flakey link hardware. Michael ------------------------------------------------------------------- | | Internet: paddon@meo78b.enet.dec.com | | | ACSnet: mwp@ubeaut.oz.au | | Michael Paddon | ACSnet: mwp@munnari.oz.au | | | EasyNet: meo78b::paddon | | | Voice: +61 3 895 9392 | ------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100305360100> Received: from CORNELLC.cit.cornell.edu by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 13:39:27 PDT Received: from UCCVMA.UCOP.EDU by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 8387; Wed, 03 Oct 90 16:38:43 EDT Received: from UCCVMA.UCOP.EDU (SPGDRP) by UCCVMA.UCOP.EDU (Mailer R2.07) with BSMTP id 5212; Wed, 03 Oct 90 13:41:24 PST Date: Wed, 03 Oct 90 13:36:01 PST From: "Donald R. Proctor" Subject: Re: Is there a program like telnet, but driven by a script? To: tcp-ip-relay@NIC.DDN.MIL, tcp-ip@nic.ddn.mil In-Reply-To: Your message of Tue, 2 Oct 90 13:28:35 GMT >I need to duplicate UNIX-to-UNIX rsh functionality going UNIX-to-VMS. >I am running a Sun Sparcstation and can communicate with the VAX using >telnet and ftp via an ULTRIX gateway (the VAX only runs DECNET). One >solution to my problem would be a telnet-like program which accepts a >script containing expect/send pairs much like UUCP and some PC >communications programs. Does such a program exist? > >I would also appreciate any suggestions of alternate solutions. > We run TGV's MultiNet on our VMS machine. It does a remarkable job of bringing Unix/Ultrix connectivity to the VMS world. Don Proctor Information Systems & Computing University of California 415/987-0356 Office of the President The opinions expressed do not necessarily reflect the opions of my employer. The University of California does not endorse any commercial products mentioned. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100307264300> Received: from TGV.COM by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 14:39:42 PDT Date: Wed 3 Oct 90 14:26:43-PDT From: VANCE@TGV.COM (Icarus) Subject: Re: Is there a program like telnet, but driven by a script? To: sdd.hp.com!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!rphroy!cfctech!sharkey!fmsrl7!slee01!hugh@ucsd.edu cc: tcp-ip@nic.ddn.mil Message-ID: <654989204.10350.VANCE@TGV.COM> In-Reply-To: <26797@fmsrl7.UUCP> 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 need to duplicate UNIX-to-UNIX rsh functionality going UNIX-to-VMS. >I am running a Sun Sparcstation and can communicate with the VAX using >telnet and ftp via an ULTRIX gateway (the VAX only runs DECNET). One >solution to my problem would be a telnet-like program which accepts a >script containing expect/send pairs much like UUCP and some PC >communications programs. Does such a program exist? One solution would be to put a TCP/IP package that supports rsh on your VAX. There are several that do (MultiNet, WIN/TCP, Fusion, possibly others...) Scripted TELNET is another issue. I don't know of any of the IP for VMS (or for other platforms for that matter) that support this. -----Stuart ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100311480000> Received: from Arizona.edu by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 18:58:45 PDT Date: Wed, 3 Oct 90 18:48 MST From: WIMMER@Arizona.edu Subject: UN-Subscribe To: TCP-IP@NIC.DDN.MIL Message-id: <25973B2A26694041BD@Arizona.edu> X-Envelope-to: TCP-IP@NIC.DDN.MIL X-VMS-To: IN%"TCP-IP@NIC.DDN.MIL" X-VMS-Cc: WIMMER Apologies to the Network for posting this here. Please drop me from this list. Terry Wimmer Wimmer@rvax.ccit.arizona.edu (old account address) or Wimmer@Arizona.edu (current address) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100316244600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 09:52:08 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07883; Wed, 3 Oct 90 09:46: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: 3 Oct 90 16:24:46 GMT From: usc!snorkelwacker!ai-lab!ai.mit.edu!dms@ucsd.edu (David M. Siegel) Organization: MIT Artificial Intelligence Laboratory Subject: Heathkit Weather Computer (IDW5001) Message-Id: <1990Oct3.122446@ai.mit.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We have just ordered a Heathkit IDW5001 weather computer. Our plans are to make the readings from the computer available over our network. It would be nice to use a "standard" weather TCP/UDP protocol for this purpose. Ideally, all Internet sites with weather data could support this protocol. The protocol should be extensible, since it is hard to anticipate all types of weather data that people might have. I'm wondering, does such a protocol exist? Also, does anyone else have IDW5001 weather computers. We'd be interested in obtaining your software to interface to the computer, and for client programs. Our plans are to run it on a Unix box, connected via the RS232 port. -Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100319234900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 13:19:23 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AB13703; Wed, 3 Oct 90 13:15: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: 3 Oct 90 19:23:49 GMT From: eru!hagbard!sunic!dkuug!resam!andrew@bloom-beacon.mit.edu (Leif Andrew Rump) Organization: RESAM Project Office, SAS, CPHML-V Subject: Does anybody know LM-X or Lackman? Message-Id: <1990Oct3.192349.781@resam.dk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Do any one of you know where we can get LM-X (Lan Manager) software for the 386-UNIX System V rel 4 running on top of TCP/IP. We would also like to know the address of a company called Lackman who supplies TCP/IP software for UNIX systems. Thank you in advance Leif Andrew Leif Andrew Rump, AmbraSoft A/S, Stroedamvej 50, DK-2100 Copenhagen OE, Denmark UUCP: andrew@ambra.dk, phone: +45 39 27 11 77 / Currently at Scandinavian Airline Systems =======/ UUCP: andrew@resam.dk, phone: +45 32 32 22 79 \ SAS, RESAM Project Office, CPHML-V, P.O.BOX 150, DK-2770 Kastrup, Denmark > > Read oe as: o / (slash) and OE as O / (slash) < < ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100320074900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 4 Oct 90 17:35:58 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA20743; Thu, 4 Oct 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: 3 Oct 90 20:07:49 GMT From: att!cbnewsk!lih@ucbvax.Berkeley.EDU (andrew.a.lih) Organization: AT&T Bell Laboratories Subject: Re: quick check for available host Message-Id: <1990Oct3.200749.16049@cbnewsk.att.com> References: <771@tiamat.fsc.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <771@tiamat.fsc.com>, jim@tiamat.fsc.com (Jim O'Connor) writes: > What is a quick way for a shell script to find out if a networked > host is currently available? If you just want to know if the host is alive, then the 'ping' program will suffice. It basically sends packets over to the host you specify and returns the round trip time for the packet. Most of the time it is used to detect delays and transmission times, but in this case you can use it to see if the machine is up. /lih AT&T Bell Labs Middletown, NJ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100320153500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 13:35:36 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13645; Wed, 3 Oct 90 13:14: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: 3 Oct 90 20:15:35 GMT From: swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!kriger@ucsd.edu (Sidney Kriger) Organization: Xylogics, Inc., Burlington MA Subject: Re: SLIP, IP Routers and Named Pipes Message-Id: <9987@xenna.Xylogics.COM> References: <1990Oct1.135507.27559@cfctech.cfc.com>, <8879@allen.ingr.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <8879@allen.ingr.com> usenet@b11.ingr.com (Usenet Network) writes: >For routers see cisco or there are terminal servers that support SLIP. >I worked for an outfit that sold cisco and the company I work for now >sells the Encore Annex II. > >encore (terminal server with slip) >617-460-0500 > > * John E. Allen - Intergraph Corporation - (205) 730-8627 * > * System Sales Support * > * ingr!b23b!allen!jallen@uunet.uu.net * Xylogics now manufactures the Annex II terminal server and has for about 2 years, not Encore. 800-225-3317 Sidney Kriger Xylogics, Inc. voice: 617-272-8140 53 Third Ave. fax: 617-273-5392 Burlington, MA 01803 email: kriger@Xylogics.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100320274500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 15:54:59 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17480; Wed, 3 Oct 90 15:45: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: 3 Oct 90 20:27:45 GMT From: bcstec!bcstec.uucp@uunet.uu.net (Charles Derykus) Organization: Boeing Computer Services Subject: Nameservice questions Message-Id: <465@bcstec.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have several questions regarding nameserver: (1) Can nameservice resolve reverse translation queries "up the tree" towards the root domain if the domains of the requested node and the requesting node are at the same level, e.g. Nameserver Node Domain --------------- ------ cabbage vegetable parsley herb.vegetable carrot underground.vegetable can "carrot" ask "cabbage" to reverse translate an I.P. in "herb.vegetable" and if so, how? We have gotten it to work only by specifying in the named.boot on carrot a line like the one below where 192.33.72.10 is the I.P. of parsley secondary 72.33.192.in-addr-arpa 192.33.72.10 herb.bak In other words, carrot seems to have to know that parsley is authoratative for the herb.vegetable domain and doesn't seem to be able to pull it down from a server such as cabbage in a higher domain. (2) A named.rev with multiple $ORIGIN lines worked fine on out primary nameserver for a while but then the secondary nameserver starting breaking. The only way we get it working now is by specifying separate reverse translation files for each $ORIGIN line, e.g. in the primary's named.boot: primary 207.128.in-addr.arpa herb.207.128.in-addr.arpa primary 79.33.192.in-addr.arpa herb.79.33.192.in-addr.arpa in the secondary's named.boot: (primary's I.P. is 128.207.254.44) secondary 207.128.in-addr.arpa 128.207.254.44 secondary 79.33.192.in-addr.arpa 128.207.254.44 Does nameservice break if these separate reverse files exceed some limit- either in number of files or memory capacity- as the "named.rev" file apparently does? Thanks for listening. Any help greatly appreciated. Charles DeRykus Internet: ced@bcstec.boeing.com Boeing Computer Services UUCP: ...!uunet!bcstec!ced Renton, WA. M/S 6R-37 (206) 938-4520 (home) (206) 234-9223 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010041120.AA01416@ucbvax.Berkeley.EDU] <1990100321121200> From: SPGDRP@UCCVMA.UCOP.EDU ("Donald R. Proctor") Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP, IP Routers and Named Pipes Message-ID: <9010041120.AA01416@ucbvax.Berkeley.EDU> Date: 3 Oct 90 21:12:12 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 33 Posted: Wed Oct 3 22:12:12 1990 >A project have come up around here that require multiple >PCs to get dial-in access to the TCP/IP network. One of the >major requirements is support for Named Pipes down to the PC. >Current plan is to use SLIP and a router with dial-in ports. > >Would someone care to recommend a PC package that would do good >SLIP emulation and a router that would be suitable for this job? > Alex: We intend on implementing a similar system here, although we don't have the named pipes requirement. We have a cisco terminal server that can be configured with several dial-in ports. The software angle is a bit more complex. As I understand it, the remote PC user will need to use a communications package like kermit or xmodem to connect to the terminal server. A commercial (such as FTP's PC/TCP) or public domain (such as NCSA telnet) TCP-IP package can then be run over SLIP. FTP's package can be ordered with SLIP, and there is a SLIP driver in Clarkson's pd packet driver distribution. I should point out that cisco's box can provide the telnet connection itself, so that a remote PC user can dial in and start a telnet session from the server without having the TCP-IP software installed on the PC. However, if need 3270 emulation (as we do), the current release of the cisco's software won't do the job. I hope my more knowledgeable colleagues will correct me if I have made any egregious errors... Don Proctor Information Systems & Computing University of California 415/987-0356 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010041401.AA03845@ucbvax.Berkeley.EDU] <1990100321360100> From: SPGDRP@UCCVMA.UCOP.EDU ("Donald R. Proctor") Newsgroups: comp.protocols.tcp-ip Subject: Re: Is there a program like telnet, but driven by a script? Message-ID: <9010041401.AA03845@ucbvax.Berkeley.EDU> Date: 3 Oct 90 21:36:01 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 20 Posted: Wed Oct 3 22:36:01 1990 >I need to duplicate UNIX-to-UNIX rsh functionality going UNIX-to-VMS. >I am running a Sun Sparcstation and can communicate with the VAX using >telnet and ftp via an ULTRIX gateway (the VAX only runs DECNET). One >solution to my problem would be a telnet-like program which accepts a >script containing expect/send pairs much like UUCP and some PC >communications programs. Does such a program exist? > >I would also appreciate any suggestions of alternate solutions. > We run TGV's MultiNet on our VMS machine. It does a remarkable job of bringing Unix/Ultrix connectivity to the VMS world. Don Proctor Information Systems & Computing University of California 415/987-0356 Office of the President The opinions expressed do not necessarily reflect the opions of my employer. The University of California does not endorse any commercial products mentioned. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100321484700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 15:04:40 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16196; Wed, 3 Oct 90 14:50: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: 3 Oct 90 21:48:47 GMT From: issm!wraith.wtp.contel.com!powell@uunet.uu.net (Mike Powell "CFS Net Ops") Organization: Contel Federal Systems (Telecom) Subject: Network Monitors/Managment ... again (repost) Message-Id: <901003154509@wraith.wtp.contel.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Since the first one appears to have gone to /dev/null due to a missing Date:, we will try again.... We are in the process of evaluating Network Monitor/Management packages. I missed most of the previous discussion. We have looked at/read glossies from Cisco, Cabletron, Excelan (Novell), Silicon Graphics, ACC, and Micro Technologies (inhouse demo, high pressure salesman). I've only read a short article about the HP stuff. MT is the only one we have taken an in-depth look at, but we are working on others. Three Questions: 1) anybody out there dealt with or have installed and operating any of these packages? how was the sales and technical staff? MT seems like they will eventually have a good product, but the level of the visible technical personnel is less than what I would expect of a major player in this game. 2) are the respective companies product groups reading this stuff? I would like to hear from you (I've already heard from two). 3) has anyone considered piecing one entity from one vendor with another? Direct replys appreciated, I will post a summary. Thanks, Mike -- Mike Powell PPASEL "arp, arp, arp" The mating call of the lonely packet. Disclaimer: I speak for myself. No relation to the DUAT folks. internet: powell@wraith.wtp.contel.com Usenet: {contel-fss}!powell ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100401213300> Received: from twg.com by NIC.DDN.MIL with TCP; Thu, 4 Oct 90 08:21:33 PDT Received: from TWG.COM by twg.com with SMTP ; Thu, 4 Oct 90 08:06:43 PST Received: from leosmac.twg.com by Mercury.TWG.COM id ab22040; 3 Oct 90 17:49 PDT From: ljm@mercury.twg.com To: tcp-ip@nic.ddn.mil Cc: Subject: Re: SLIP, IP Routers and Named Pipes In-Reply-To: Msg from Alex Beylin dated 1 Oct 90 13:55:07 GMT Message-ID: <9010031749.ab22040@Mercury.TWG.COM> >A project have come up around here that require multiple >PCs to get dial-in access to the TCP/IP network. One of the >major requirements is support for Named Pipes down to the PC. >Current plan is to use SLIP and a router with dial-in ports. > >Would someone care to recommend a PC package that would do good >SLIP emulation and a router that would be suitable for this job? > Given your Named Pipes requirement, you actually have a much more fun problem to solve. You need a TCP/IP with support for not only SLIP but also NetBIOS over TCP/IP which works through IP routers. I think we are currently the only TCP/IP product with both, but I think FTP Software will be able to provide a NetBIOS which works through routers in the near to medium future. By the way, I do have to ask. Why Named Pipes? enjoy, leo j mclaughlin iii ljm@twg.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100402400100> Received: from hp-sde.sde.hp.com by NIC.DDN.MIL with TCP; Thu, 4 Oct 90 09:41:21 PDT Received: from orac.sde.hp.com by hp-sde.sde.hp.com with SMTP (16.3/15.5+IOS 3.13) id AA04573; Thu, 4 Oct 90 09:40:10 -0700 Received: by hpsdel.sde.hp.com (15.7/SES42.42) id AA20637; Thu, 4 Oct 90 09:40:01 pdt Date: Thu, 4 Oct 90 09:40:01 pdt From: Walter Underwood Message-Id: <9010041640.AA20637@hpsdel.sde.hp.com> To: tcp-ip@nic.ddn.mil Subject: Re: HP TCP/IP router/bridge? Newsgroups: comp.protocols.tcp-ip In-Reply-To: article <45306@apple.Apple.COM> of Tue, 2 Oct 1990 01:41:47 GMT Does anyone know of a bridge or router that will allow HP hosts running TCP/IP which speak IEEE style packets (802.2 encapsulated) to communicate with ethernet style IP implementations? I've answered Kevin separately, but here is the info for everyone else: 1. The old-style HP 802.2/802.3 encapsulation pre-dates SNAP. It uses the SAP originally reserved for IP (06) and uses a separate protocol for address resolution (Probe). All this design was done back in 1981-82, when no one but the 802 committee and HP were interested in 802. 2. HP does not encourage new implementations of HP 802 and Probe, because there are standard, and thus better, alternatives. 3. All HP products now support Ethernet and ARP, so no one has to worry about the HP 802 encapsulation anymore. Just upgrade to the latest networking bits. wunder ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100404260000> Received: from p.Lanl.GOV by NIC.DDN.MIL with TCP; Thu, 4 Oct 90 09:25:36 PDT Received: from snow-white.lanl.gov by p.Lanl.GOV (5.61/1.14) id AA00455; Thu, 4 Oct 90 10:26:01 -0600 Received: from sneezy.lanl.gov by snow-white.lanl.gov (4.1/SMI-4.0) id AA28470; Thu, 4 Oct 90 10:26:00 MDT Date: Thu, 4 Oct 90 10:26:00 MDT From: cpw%snow-white@LANL.GOV (C. Philip Wood) Message-Id: <9010041626.AA28470@snow-white.lanl.gov> To: issm!wraith.wtp.contel.com!powell@uunet.uu.net Subject: Re: Network Monitors/Managment ... again (repost) Cc: tcp-ip@nic.ddn.mil My experience is with Sun Microsystems, Inc. Sun Network Management product (SNM) and HP's network management system. I have spent a lot of time using SNM and find it useful. It is especially good at allowing for the incorporation of user defined applications. However, it's many features and seemingly infinite configuration capabilities are not for the novice. HP has a good product which should be the network management answer for 85 percent of the networks out there. The user interface is easy. It can learn about the networks it is attached to and provides a number of useful problem solving features. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100414024300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 4 Oct 90 09:52:04 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07999; Thu, 4 Oct 90 09: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: 4 Oct 90 14:02:43 GMT From: eagle!news@ucbvax.Berkeley.EDU (Keith Jackson) Organization: NASA/Lewis Research Center, Cleveland Subject: Re: IBM MVS TCP/IP info wanted Message-Id: <1990Oct4.140243.16755@eagle.lerc.nasa.gov> References: <1990Sep25.191233.6543@ecst.csuchico.edu>, <90269.080251PMW1@psuvm.psu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil NASA Lewis has the KNET product running on our VM system and from what I gather it has not been entirely happy. TCP/IP was just installed on the MVS system and the same product was also installed on VM replacing KNET. Sorry about being so vaque, but I not in charge of those systems. If you would like more info, give my a call and I can get you in touch with the appropriate system people. -- ----------------------------------------------------------------------------- Keith Jackson | phone: 216-433-5105 or Sverdrup Technology, Inc | 216-891-2946 NASA Lewis Research Center | email: vvkmj@spica.lerc.nasa.gov ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100414324000> Received: from ugw.utcs.utoronto.ca by NIC.DDN.MIL with TCP; Thu, 4 Oct 90 14:39:14 PDT Received: from EMRCAN (stdin) by ugw.utcs.utoronto.ca with SMTP id 57521; Thu, 4 Oct 90 17:36:17 EDT Received: from CA*NONE*EMR by emr1-gw.emr.ca via QTFS with X.400; Thu, 4 Oct 90 17:32:51 -0500 X400-Trace: CA*NONE*EMR; arrival Thu, 4 Oct 90 17:32:40 -0500 action Relayed Date: Thu, 4 Oct 90 18:32:40 EDT Message-Id: <5A0A04111B2102B6-MTAEMR1*fillmore@emrcan> P1-Message-ID: CA*NONE*EMR; 5A0A04111B2102B6-MTAEMR1 UA-Content-ID: 5A0A04111B2102B6 From: fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca Subject: Reply to network file backup To: TCP-IP@NIC.DDN.MIL We back up our two Sun 3/60 workstations to a CDC Cyber 840 by using the standard "dump" command with the output directed to a NFS-mounted file on the Cyber. We do incremental dumps every night and full dumps once per week. It's all automatic - controlled by a crontab entry. This is a very efficient way of doing it - we can back up 100 megabytes in about 25 minutes, all unattended. You also have to back up the root partition to tape once in a while in case you have to do a full restore. Try it, you'll like it! - Bob Fillmore ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100415384200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 16:34:39 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA18685; Wed, 3 Oct 90 16:32: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: 4 Oct 90 15:38:42 GMT From: uokmax!munnari.oz.au!bruce!merlin!morgana!ianh@apple.com (Ian Hoyle) Subject: Re: TCP/IP for DEPCA boards Message-Id: References: , Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil nelson@sun.soe.clarkson.edu (Russ Nelson) writes: >In article beach@DDNUVAX.AF.MIL (darrel beach) writes: > Can anyone point me to drivers, software, vendors to let me run > TCP/IP on PCs which have a DEPCA (Digitals Ethernet PC bus Adapter) > cards. Packet drivers compatible with NCSA, KA9Q, or even a commercial > package would be appreciated. >Not yet, but the picture is coming into focus. We've gone from >"Digital refuses to release programming information" (that was just a >rumor) to "How may I help get you the information you need to write a >packet driver?" Wollongong's TCP for DOS has appropriate drivers etc. for DEPCA cards *but* like PCSA, they only seem to provide full functionality on the supported PC platforms ie IBM, Compaq etc. Clones of various types (with their myriad BIOS's) just don't work at all sometimes. This seems to occur with monotonous regularity. When it does work it's just fine :-) ian -- Ian Hoyle /\/\ Image Processing & Data Analysis Group / / /\ BHP Melbourne Research Laboratories / / / \ 245 Wellington Rd, Mulgrave, 3170 / / / /\ \ AUSTRALIA \ \/ / / / \ / / / Phone : +61-3-560-7066 \/\/\/ FAX : +61-3-561-6709 E-mail : ianh@bhpmrl.oz.au ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100416012800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 4 Oct 90 10:05:38 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08202; Thu, 4 Oct 90 09:54: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: 4 Oct 90 16:01:28 GMT From: swrinde!zaphod.mps.ohio-state.edu!samsung!ernie.viewlogic.com!curly!alan@ucsd.edu (Alan Medsker) Organization: Viewlogic Systems, Inc., Marlboro, MA Subject: Re: network file backup Message-Id: <1990Oct4.120128@curly.Viewlogic.COM> References: <6613@ncrcae.Columbia.NCR.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I think Legato, or some company with a similar name, has such a product. I don't see the ad in Sun Tech Journal that I think might have been the last issue. Alan -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alan Medsker Viewlogic Systems, Inc. Voice: (508) 480-0881 293 Boston Post Road West Fax: (508) 480-0882 Marlboro, MA 01752 Internet: amedsker@Viewlogic.COM cc:Mail: Alan Medsker at Viewlogic CI$: 76376,662 BIX: amedsker 2 Meters: WB0SQR =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= My opinions, of course. And don't hold me to them. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100416143500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 4 Oct 90 13:20:59 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13617; Thu, 4 Oct 90 13:08: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: 4 Oct 90 16:14:35 GMT From: bywater!arnor!news@uunet.uu.net Organization: IBM TJ Watson Research, Yorktown Heights, NY Subject: RE: IBM 9000 TCP/IP, lpr? Message-Id: <1990Oct4.161435.20874@arnor.uucp> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil > Another campus entity is looking into purchasing an IBM 9000 system, which > would run VM, and comes with some sort of TCP/IP package. They want to be > sure it works with our (BSD) network, especially for printing. Does anybody > know if it's possible for an IBM 9000 VM system to talk Berkeley lpr protocol? > Any information is most appreciated. > > -- > Bill Stapleton IBM's TCP/IP Version 2 for VM product, due out at the end of the year, includes an LPR client and LPD server. They have been written to interoperate with 4.3 LPR/LPD and work fine. If you're running our Version 1 product, I believe there is at least one LPR/LPD implementation available, from Columbia University. I believe it is free, but you'd have to contact them directly. Bill Rubin IBM TJ Watson Research rubin@ibm.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100416154800> Received: from sun2.nsfnet-relay.ac.uk by NIC.DDN.MIL with TCP; Thu, 4 Oct 90 06:55:47 PDT Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id aa03740; Thu, 4 Oct 90 13:44:49 +0000 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa08204; 4 Oct 90 13:42 BST Received: from [+JANET.000001501500.ncl.mts.ftp.mail] by uk.ac.newcastle; Thu, 4 Oct 90 14:37:01 +0100 Date: Thu, 04 Oct 90 14:35:48 +0100 From: Denis.Russell@newcastle.ac.uk Subject: IP over X.25 To: tcp-ip@nic.ddn.mil Message-Id: I have an interest in routing IP datagrams over an X.25 network, and would like some information on the characteristics actual products (routers) that do this. The kind of completely hypothetical (!) setup that interests me is a set of say 50 to 100 mainly Ethernet LANs connected by a wide-area X.25 network with X.25 speeds in the 9.6kbps-64kbps-2Mbps range. In the worst case one might imagine a permanent 2 * N^2 network of X.25 calls, and clearly some intermediate plan using an hierarchy of routers would be preferable. However, I am primarily interested in an intermediate scenario where the X.25 calls are established and cleared down as required. Clearly the practicality of this this would depend on the traffic pattern - but that is not the primary focus of this query. The primary focus is to find out whether routers that support X.25 as an IP bearer have the right sort of characteristic for such an application. For example, one would require support for a substantial number of such calls (10, 20, 30?), and the automatic clearing down of calls after some inactivity timeout. What speed X.25 is supported (preferably well beyond 64kbps)? Does a router exploit already existing inbound X.25 calls to send outbound datagrams or does traffic always result in two calls, one used in each direction? What other questions are important? As some examples of the clarifications we would value are that we understand that Sunlink supports only 4 X.25 calls by default, but can be configured for any larger number. On the other hand, the calls are never cleared due to inactivity. We don't know whether any routers exploit X.25 in a duplex manner or whether two calls are always/sometimes/never set up. I'll summarise to the list if there is interest in the results. Denis Russell JANET: Denis.Russell@uk.ac.newcastle Computing Laboratory Internet: Denis.Russell@newcastle.ac.uk The University Claremont Road Tel: (+44) 91 222 8243 Newcastle upon Tyne Fax: (+44) 91 222 8232 NE1 7RU Telex: 53 65 4 UNINEW G ENGLAND ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100416180900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 3 Oct 90 19:19:40 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22281; Wed, 3 Oct 90 19:16: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 Oct 90 16:18:09 GMT From: munnari.oz.au!murdu!viccol!gjocc@uunet.uu.net Organization: Computer Services, Victoria College, Melbourne Subject: Assigning IP addresses Message-Id: <6416.270b1a72@csv.viccol.edu.au> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil What is the best method for dynamically assigning IP addresses to PC's that are directly on our main ethernet? I have heard of the BOOTP and RARP protocols, so I guess what I need is BOOTP or RARP server software. Our main machines are VAX running VMS with 6.4 CMU TCP/IP and a Sequent S27 with DYNIX (BSD 4.2 UNIX). The PCs will probably be running NCSA telnet (which does RARP I believe). Any pointers to cheap software that can assign IP addresses to the PCs on our ethernet would be welcome. Greg O'Sullivan (gjocc@csv.viccol.edu.au) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100417100500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 4 Oct 90 10:21:07 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08629; Thu, 4 Oct 90 10:12: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: 4 Oct 90 17:10:05 GMT From: hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu (Lars Poulsen) Organization: Rockwell CMC Subject: Re: Does anybody know LM-X or Lackman? Message-Id: <1990Oct4.171005.11148@spectrum.CMC.COM> References: <1990Oct3.192349.781@resam.dk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Oct3.192349.781@resam.dk> andrew@resam.dk (Leif Andrew Rump) writes: >We would also like to know the address of a company called Lackman >who supplies TCP/IP software for UNIX systems. Results of WHOIS LACHMAN.COM: ---------------------------- Lachman Associates, Inc. (LACHMAN-DOM) 1901 North Naper Boulevard Naperville, IL 60540-1031 Domain Name: LACHMAN.COM Administrative Contact: Goldman, Ezra (EG56) ez%laidbak@SUN.COM (312) 505-9100 ext 233 Technical Contact, Zone Contact: Alexander, Steve (SA65) stevea@i88.isc.com (708) 505-9100 ext 256 Record last updated on 01-Sep-88. Domain servers in listed order: LAIZY.LACHMAN.COM 192.35.52.1 LAIDBAK.LACHMAN.COM 192.35.52.2 -- / Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100418140000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 4 Oct 90 14:37:37 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15607; Thu, 4 Oct 90 14:22: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: 4 Oct 90 18:14:00 GMT From: van-bc!ubc-cs!news-server.csri.toronto.edu!utgpu!cunews!bnrgate!bwdls49!linegar@ucbvax.Berkeley.EDU (Derick Linegar) Organization: Bell-Northern Research, Ltd. Ottawa Ontario CANADA Subject: Ethernet Address Uniqueness... Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In trying to debug a problem we are having here with our file server with 2 ethernet boards connected to 2 *different* subnets on the same network, our vendor eluded to us that the 2 ethernet cards assume the *same* Ethernet address, obtained from the primary ethernet board. Of course, warning bells are going of here. Now I've been searching the RFC and IEEE docs and I cannot find any documentation that sort of says that Ethernet Addresses are assigned to Ethernet boards, not hosts. Anyone have an idea where it might be. I cannot go back to the vendor and say " .... well everyone *knows* that ethernet addresses *must* be unique..." -derick- -- #include Derick Linegar, Internet Systems 4P27, Bell-Northern Research BITNET: LINEGAR@BNR.ca P.O. Box 3511 Station C UUCP: ...uunet!bnrgate!bwdls49!linegar Ottawa ONT. K1Y 4H7 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100419010800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 4 Oct 90 12:36:34 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12299; Thu, 4 Oct 90 12:29: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: 4 Oct 90 19:01:08 GMT From: synoptics!sblair@decwrl.dec.com (Steven Blair) Organization: SynOptics Communications Inc. Mountain View, Ca. Subject: Re: network file backup Message-Id: <1990Oct4.120108@synoptics.com> References: <6613@ncrcae.Columbia.NCR.COM>, <1990Oct4.120128@curly.Viewlogic.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We here use a very nive networked backup system called "budtool(BackUp Daemon Tool) from Delta Microsystems in Livermore Calif. Their phone is (415) 449-6881. We do nightly -0- backups of 10 Gbytes of machines. Without a hitch. Has an incredibly felxible timing mechanism, history mechanisms, scheduling tools, labeling tools, tape testing tools, and is affordable. We've got no releationship with them, than a very satisfied customer<->vendor relationship. They have always answered calls promptly, provided bug fixes promptly, and are generally very nice folks. The Legato Networker was evaluated here. We already had too much invested in Delta Micro's solution to justify using it. -- Steven C. Blair Network Operations Center SynOptics Communications Inc. Mountain View, California INTERNET: sblair@synoptics.com sblair@excalibur.synoptics.com PROBLEMS/EMAIL: HOSTMASTER@SYNOPTICS.COM postmaster@synoptics.com ---->>RIP Stevie Ray Vaughan 1954-1990 You Will Be *Missed*<<---- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100419591800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 4 Oct 90 13:36:28 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA14289; Thu, 4 Oct 90 13:35:23 -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 Oct 90 19:59:18 GMT From: eplrx7!mcneill@louie.udel.edu (Keith McNeill) Organization: DuPont Engineering Physics Lab Subject: Where is latest/greatest version of proxyarpd? Message-Id: <1990Oct4.195918.11933@eplrx7.uucp> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Subject says it....I tried comp.sources.wanted but I got no replies. Thanks, Keith -- Keith D. McNeill | E.I. du Pont de Nemours & Co. eplrx7!mcneill@uunet.uu.net | Engineering Physics Laboratory (302) 695-9353/7395 | P.O. Box 80357 | Wilmington, Delaware 19880-0357 -- The UUCP Mailer ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100422001200> Received: from hogg.cc.uoregon.edu by NIC.DDN.MIL with TCP; Fri, 5 Oct 90 09:40:01 PDT Received: from localhost.uoregon.edu by hogg.cc.uoregon.edu (4.1/UofO NetSvc-10/1/90) id AA26240; Fri, 5 Oct 90 09:40:15 PDT Message-Id: <9010051640.AA26240@hogg.cc.uoregon.edu> To: fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca Cc: tcp-ip@nic.ddn.mil Subject: Re: Reply to Ethernet Address Uniqueness... In-Reply-To: Your message of Fri, 05 Oct 90 12:05:47 -0400. <5A0A050B012801FE-MTAEMR1*fillmore@emrcan> Date: Fri, 05 Oct 90 09:40:12 -0700 From: jqj@hogg.cc.uoregon.edu Having the same MAC-level address for all interfaces (phrased differently, associating the MAC-level address with the NODE rather than with the INTERFACE) is part of the spec for both DECNET IV and XNS. It falls out of a design that has an algorithmic link between the MAC address and the protocol address. Many people believe that having a protocol address that belongs to the node rather than to the interface is a Good Idea, and that doing it the other way was a bad decision in the IP suite. I don't have a strong opinion, but I do know that the XNS/DECNET way of doing things makes routing to multihomed hosts easier. In the IP world there is no unambiguous way to decide whether 2 IP addresses refer to the same host; sure I can look in the DNS, but there is no guarantee that either or both addresses will be in the in-addr.arpa tree. Other people like the idea of algorithmic mapping from protocol to MAC address. It means that you don't need something like ARP, but it also limits your flexibility substantially, especially on physical networks like arcnet or 3mb Ethernet where the range of MAC addresses is very limited or hardwired in the interface. And it of course fails to generalize to cases where one needs to support multiple protocol stacks that each want to change the MAC address based on the protocol address! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100423361900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 4 Oct 90 19:51:23 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24034; Thu, 4 Oct 90 19:45: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: 4 Oct 90 23:36:19 GMT From: pilchuck!amc-gw!morpho!erik@uunet.uu.net (Erik Vollemaere) Organization: North American Morpho Systems Inc, Tacoma WA Subject: R/S 6000 raw I/O on Ethernet Message-Id: <386@morpho.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We're attempting to establish communications between an IBM R/S 6000 and a remote host with a CMC-20 board through Ethernet. The communication must be done through non-encapsulated Ethernet packets. The idea is to send it a packet of type AM and to wait untill we receive a -broadcast- packet from it of type PU. Then we send it a packet of type BS with the bootstrap program. The first portion of this works fine. We open the device (in this case /dev/ent0) and write() the packet. The remote host responds with alternating BR - and PU type packets (verified through an Ethernet analyzer). The problem is that we do not "recognize" the packets from the remote host. Reads fail with an EIO error ("An I/O error occurred while reading from the file system"). Even if we get the read to succeed (suggestions?), we prefer not to have to analyze every packet looking for our target. The question is: what call(s) do we use and how do we set it up to return an Ethernet broadcast packet of type PU and ignore everything else? We can accomplish this on different platforms using raw socket I/O but those same calls fail on the R/S 6000. The error messages are "Can't assign requested address" or "Destination address required" (protocol interference). IBM recommended using the device driver directly (/dev/ent0) and that works fine for the write portion of the problem, but we're now stuck on the read portion. We've been waiting for a solution from IBM but so far their suggestions have not given us the desired result. ___________________________________________________________________________ Standard disclaimer... the above opinions are mine, all mine. Erik J.P. Vollemaere (B) / (VL) ____________________________________________________________________________ amc-gw!morpho!erik ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100501203200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 18:38:47 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12803; Sat, 6 Oct 90 18:26: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: 5 Oct 90 01:20:32 GMT From: agate!linus!philabs!ttidca!quad1!srhqla!avatar!kory@ucbvax.Berkeley.EDU (Kory Hamzeh) Organization: Kory Hamzeh, Canoga Park, Ca, USA Subject: Need a RARP Demon Message-Id: <157@avatar.avatar.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does anyone know where I can get my hands on source code for a Reverse ARP demon to work on a Sun Sparcstation? I know Sun already has one, but we have a special application where we need to slightly modify the Sun version. Thanks, --kory -- ------------------------------------------------------------------------------- Kory Hamzeh UUCP: avatar!kory or ..!uunet!avatar!kory INTERNET: kory@avatar.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100501231900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 4 Oct 90 18:36:31 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22433; Thu, 4 Oct 90 18:25: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: 5 Oct 90 01:23:19 GMT From: bacchus.pa.dec.com!mogul@decwrl.dec.com (Jeffrey Mogul) Organization: DEC Western Research Subject: Re: 9 interesting & challenging problems for Netman Message-Id: <1990Oct5.012319.4609@wrl.dec.com> References: <9009210641.AA20321@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9009210641.AA20321@ucbvax.Berkeley.EDU> J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) writes: >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... > This is similar to research reported on by Bruce L. Hitson in "Knowledge-Based Monitoring and Control: An Approach to Understanding the Behavior of TCP/IP Network Protocols", Proc. SIGCOMM '88. This was a rule-based system, not a "specification-based" system, but perhaps that is not such a big difference. >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... Jon sent his message before he attended SIGCOMM '90 last week, where I gave a paper that touched on this topic. This is "work in progress" so it will be a while before I can publish a detailed paper. >7. Interpret auto-correllation between packets from/to and/or >same src/dst in a sensible fashion... I suppose this depends on one's definition of "sensible", but I've seen a few papers on this. For example, Mark J. Lorence and M. Satyanarayanan, "IPwatch: A Tool For Monitoring Network Locality", Operating Systems Review 24:1 (January 1990). These all seem to be fertile areas for research, as Jon has pointed out. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100501260200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 4 Oct 90 21:06:07 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25391; Thu, 4 Oct 90 20:52: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: 5 Oct 90 01:26:02 GMT From: asylum!sharon@decwrl.dec.com (Sharon Fisher) Organization: The Asylum; Belmont, CA Subject: Re: Does anybody know LM-X or Lackman? Message-Id: <12817@asylum.SF.CA.US> References: <1990Oct3.192349.781@resam.dk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Oct3.192349.781@resam.dk> andrew@resam.dk (Leif Andrew Rump) writes: >Do any one of you know where we can get LM-X (Lan Manager) software >for the 386-UNIX System V rel 4 running on top of TCP/IP. > >We would also like to know the address of a company called Lackman >who supplies TCP/IP software for UNIX systems. Lachman Associates -- the last address I have for them is 1901 N. Naper Blvd., Naperville, IL 60540-1031; (312) 505-9100; fax (312) 505-9133.-- "Drive carefully." "What is it with women and 'drive carefully'? 'No, I'm going to steer with my feet and read the comic paper.'" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100501292000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 4 Oct 90 18:36:12 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22541; Thu, 4 Oct 90 18:30: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: 5 Oct 90 01:29:20 GMT From: bacchus.pa.dec.com!mogul@decwrl.dec.com (Jeffrey Mogul) Organization: DEC Western Research Subject: Re: TCP segment size -- user defined? Message-Id: <1990Oct5.012920.4846@wrl.dec.com> References: , Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article DEDOUREK@UNB.CA writes: >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? The Path MTU Discovery document (now an Internet Draft, soon to be an RFC if all goes well) says: Note: The TCP MSS is defined to be the relevant IP datagram size minus 40 [see RFC879]. The default of 576 octets for the maximum IP datagram size yields a default of 536 octets for the TCP MSS. In other words, the TCP MSS should be at least 40 octets less than the path MTU. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100501515800> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Fri, 5 Oct 90 08:52:34 PDT Received: from bel.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Fri, 5 Oct 90 08:53:06 -0700 Date: Fri, 5 Oct 90 08:51:58 PDT From: postel@venera.isi.edu Posted-Date: Fri, 5 Oct 90 08:51:58 PDT Message-Id: <9010051551.AA06327@bel.isi.edu> Received: by bel.isi.edu (4.1/4.0.3-4) id ; Fri, 5 Oct 90 08:51:58 PDT To: tcp-ip@nic.ddn.mil Subject: Re: TCP segment size -- user defined? Hi. For further discussion of the TCP MSS see RFC 879. --jon. Date: 5 Oct 90 01:29:20 GMT From: bacchus.pa.dec.com!mogul@decwrl.dec.com (Jeffrey Mogul) Subject: Re: TCP segment size -- user defined? Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article DEDOUREK@UNB.CA writes: >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? The Path MTU Discovery document (now an Internet Draft, soon to be an RFC if all goes well) says: Note: The TCP MSS is defined to be the relevant IP datagram size minus 40 [see RFC879]. The default of 576 octets for the maximum IP datagram size yields a default of 536 octets for the TCP MSS. In other words, the TCP MSS should be at least 40 octets less than the path MTU. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100504232000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 02:23:34 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22378; Sat, 6 Oct 90 02:13: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: 5 Oct 90 04:23:20 GMT From: swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!bruce!trlluna!ilium!andrews@ucsd.edu (Murray Andrews) Organization: Telecom Research Laboratories, Melbourne, Australia Subject: SNMP product guide (was Re: SNMP comparison) Message-Id: <2320@trlluna.trl.oz> References: <900925212840.581117@DOCKMASTER.NCSC.MIL> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <900925212840.581117@DOCKMASTER.NCSC.MIL>, Sabo@DOCKMASTER.NCSC.MIL writes: > > 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 Does anyone have a fax number, email or snail mail address for this contact or an Australian distributor? An email response would be appreciated since I will be away for a couple of weeks and a response may get expired in my absence. But then again it might not. Thanks, Murray Andrews Telecom Australia Research Laboratories. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100504364300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 4 Oct 90 21:52:53 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26131; Thu, 4 Oct 90 21:38: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 Oct 90 04:36:43 GMT From: world!ddern@uunet.uu.net (Daniel P Dern) Organization: The World Subject: RFC 1174 in the news (also, Internet Toaster) Message-Id: <1990Oct5.043643.15250@world.std.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil The current (October 1990) issue of Data Communications has a news article on RFC 1174 (not mentioned by [name]), "Federal Networking Council to Widen Access to the Internet; Agrees to Drop Requirement that New Members Obtain a Government Sponsor." by yours truly. I haven't read through the final printed version carefully, but suspect there are some inaccuracies due to editing and condensing and late night phone discussions with the editors .... I'm considering posting an alternate version. For members of the Internet community up to date on what's happening, one or two paragraphs would say all; for others, it seemed to take more thousands of words than I was given... Also, on the last page, a preview of John Romkey's Internet Toaster, and other networked appliances/devices (some of which were discussed here in the past month or two...). Daniel Dern (Don't ask me for copies; call McGraw-Hill. Tnx) -- Daniel Dern, Ministry of Public Relations (MiniPurl) (617) 926-8743 High-tech journalism, PR and humor; substitute dance/Unix instructor Internet: ddern@world.std.com UncaSam: PO Box 114 Belmont MA 02178 "No! We Don't Sell Frozen Yogurt Here!" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100506032700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 11 Oct 90 19:25:03 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA11213; Thu, 11 Oct 90 19:10: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: 5 Oct 90 06:03:27 GMT From: mcsun!tuvie!edvvie!eliza!schweigl@uunet.uu.net (Johnny Schweigl) Organization: Edv GesmbH, Austria/Europa Subject: FTP client source available as PD ? Message-Id: <250@eliza.edvvie.at> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am looking for the source of an FTP client program. If something like this is available in the public domain could anyone please mail it to me? BTW: I've got no FTP access, so please use email Thanks in advance, Johnny -- This does not reflect the | Johann Schweigl | DOS? opinions of my employer. | johnny@edvvie.at | Kind of complicated I am busy enough by talking | | bootstrap loader ... about my own ... | EDVG Vienna | ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100507254400> Received: from nmdsc20.nmdsc.nnmc.navy.mil by NIC.DDN.MIL with TCP; Fri, 5 Oct 90 08:26:51 PDT Received: by nmdsc20.nmdsc.nnmc.navy.mil (5.59/25-eef) id AA06392; Fri, 5 Oct 90 11:25:44 EDT Date: Fri, 5 Oct 90 11:25:44 EDT From: Bob Stratton Message-Id: <9010051525.AA06392@nmdsc20.nmdsc.nnmc.navy.mil> To: TCP-IP@nic.ddn.mil Subject: Traceroute for 3B2/600's under sys V R3.2.2 Hello, I am looking for a copy of traceroute that runs on the AT&T 3B2/600, under System V Release 3.2.2. I am particularly curious as to whether Sys V requires the raw IP kernel hack that BSD systems do. Please mail your responses directly to me so as not to clog the list. Thanks in advance! Bob Stratton | dsc3rjs@nmdsc20.nmdsc.nnmc.navy.mil [DDN/Internet] NAVMEDATASERVCEN | dsc3rjs@vmnmdsc [BITNET only] (Innova Comms. / AT&T) | 295-3371 [AV] +1 301 295 3371 [PSTNet] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100507593800> Received: from xap (xap.xyplex.com) by NIC.DDN.MIL with TCP; Fri, 5 Oct 90 09:05:52 PDT Received: by xap id ; Fri, 5 Oct 90 11:59:38 EDT Date: Fri, 5 Oct 90 11:59:38 EDT From: Bob Stewart Message-Id: <9010051859.AA07361@xap> To: fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca Cc: TCP-IP@nic.ddn.mil In-Reply-To: fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca's message of Fri, 5 Oct 90 12:05:47 EDT <5A0A050B012801FE-MTAEMR1*fillmore@emrcan> Subject: Reply to Ethernet Address Uniqueness... >In the DEC VAX environment the unique Ethernet address on each board is >overridden by DECNET when it starts to use that board. The address is set >to four bytes of a constant value plus two bytes which contain the DECNET >area and node numbers. Lots of opportunity for duplication! >Does anyone know why DEC chose this scheme? > > - Bob Fillmore FILLMORE@EMRCAN.BITNET I believe it was to keep down the size of routing tables. Since the Ethernet address can be calculated from the DECnet address, you don't have to keep a 48-bit MAC address in your mapping from Network layer to Data Link layer. Bob ----------- Bob Stewart (rlstewart@eng.xyplex.com) Xyplex, Boxborough, Massachusetts (508) 264-9900 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100508054700> Received: from ugw.utcs.utoronto.ca by NIC.DDN.MIL with TCP; Fri, 5 Oct 90 08:17:52 PDT Received: from EMRCAN (stdin) by ugw.utcs.utoronto.ca with SMTP id 57524; Fri, 5 Oct 90 11:14:17 EDT Received: from CA*NONE*EMR by emr1-gw.emr.ca via QTFS with X.400; Fri, 5 Oct 90 11:07:16 -0500 X400-Trace: CA*NONE*EMR; arrival Fri, 5 Oct 90 11:05:47 -0500 action Relayed Date: Fri, 5 Oct 90 12:05:47 EDT Message-Id: <5A0A050B012801FE-MTAEMR1*fillmore@emrcan> P1-Message-ID: CA*NONE*EMR; 5A0A050B012801FE-MTAEMR1 UA-Content-ID: 5A0A050B012801FE From: fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca Subject: Reply to Ethernet Address Uniqueness... To: TCP-IP@NIC.DDN.MIL In the DEC VAX environment the unique Ethernet address on each board is overridden by DECNET when it starts to use that board. The address is set to four bytes of a constant value plus two bytes which contain the DECNET area and node numbers. Lots of opportunity for duplication! Does anyone know why DEC chose this scheme? - Bob Fillmore FILLMORE@EMRCAN.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100509552400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 5 Oct 90 19:14:47 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13815; Fri, 5 Oct 90 19:07: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: 5 Oct 90 09:55:24 GMT From: eru!hagbard!sunic!mcsun!hp4nl!nikhefh!a20@bloom-beacon.mit.edu (Marten Terpstra) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: Re: IP over X.25 Message-Id: <1010@nikhefh.nikhef.nl> References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article Denis.Russell@newcastle.ac.uk writes: [stuf deleted] >this query. The primary focus is to find out whether routers >that support X.25 as an IP bearer have the right sort of >characteristic for such an application. For example, one would >require support for a substantial number of such calls (10, 20, >30?), and the automatic clearing down of calls after some >inactivity timeout. What speed X.25 is supported (preferably >well beyond 64kbps)? Does a router exploit already existing >inbound X.25 calls to send outbound datagrams or does traffic >always result in two calls, one used in each direction? What >other questions are important? CISCO IP routers can provide you with everything you want. The max speed for normal serial interfaces in these boxes is T1 (or 1.544 Mbit/s). You can of course get higher speed interfaces. The set-up and clearing of calls can simply be done by specifying an idle timer. Only one call is needed for two way traffic. It will set up a call if it has traffic to route. CISCO even provides x25 switching if you want this. Ask CISCO for some info or drop a line at customer-support@cisco.com. Marten -- Marten Terpstra National Institute for Nuclear Internet : terpstra@nikhef.nl and High Energy Physics Oldie-net: {....}mcsun!nikhefh!terpstra (NIKHEF-H), PO Box 41882, 1009 DB Phone : +31 20 592 5102 Amsterdam, The Netherlands ----MESSAGE-END---- ----MESSAGE-BEGIN---- [14017@slice.ooc.uva.nl] <1990100511031600> From: matthew@ooc.uva.nl (Matthew Lewis) Newsgroups: comp.protocols.appletalk,comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: MAC MS-MAIL to SMTP gateway? Message-ID: <14017@slice.ooc.uva.nl> Date: 5 Oct 90 11:03:16 GMT References: <34162@cup.portal.com> <26FE4E59.1748@intercon.com> <546@fciva.FRANKLIN.COM> <2707782A.6C5@intercon.com> Followup-To: comp.protocols.appletalk Organization: Center for Innovation and Cooperative Technology, University of Amsterdam Lines: 35 Posted: Fri Oct 5 12:03:16 1990 kdb@macaw.intercon.com (Kurt Baumann) writes: >In article <546@fciva.FRANKLIN.COM>, dag@fciva.FRANKLIN.COM (Daniel A. Graifer) >writes: >> 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. >I might be mistaken, but they do sell it as a seperate product. The last >I knew it ran with any AppleTalk-IP gateway product. Course this might have >changed as well. Anyone listening from Cayman, Brad? >Kurt i When Cayman took over marketing the Mail*Link software from StarNine, they changed the name to GatorMail. This has no relationship to the GatorBox, except that the first 5 letters are the same :-). It will run on a QuickMail center with access to your Unix box via TCP/IP. That means via Ethernet FastPath Multigate GatorBox (Have I left any out? Probably!) We run GatorMail-Q via a Multigate, with no problems. Matthew Lewis -- Matthew Lewis, University of Amsterdam Grote Bickersstraat 72 +31-20-52 51 220 1013 KS Amsterdam Internet: matthew@ooc.uva.nl The Netherlands UUCP: uunet!mcsun!hp4nl!uvabick!matthew ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100511240000> Received: from lns61.tn.cornell.edu by NIC.DDN.MIL with TCP; Fri, 5 Oct 90 13:45:55 PDT Date: 5 Oct 90 16:24:00 EST From: system@lns61.tn.cornell.edu Subject: re: Reply to Ethernet Address Uniqueness... To: "tcp-ip" Bob, >In the DEC VAX environment the unique Ethernet address on each board is >overridden by DECNET when it starts to use that board. The address is set >to four bytes of a constant value plus two bytes which contain the DECNET >area and node numbers. Lots of opportunity for duplication! >Does anyone know why DEC chose this scheme? The "four constant bytes" are reserved to DEC (for DECnet) just as the high-order butes of the physical hardware Ethernet addresses in those Ethernet boards' address ROMs are also reserved to DEC. In a given DECnet wide-area network, all DECnet node addresses are required to be unique. As a result, there is no opportunity for duplication on a local Ethernet either. (I am ignoring the complications introduced by setting limits on the address ranges passed by routers.) One reason that DEC chose this scheme is that it allows "end-node" DECnet systems, which have no routing information whatsoever, to be able to send messages to other end-node systems on the same Ethernet even when there are no DECnet routers present. They just calculate what the Ethernet address must be and blindly transmit the message into the ether. Of course, the fact that DECnet addresses are limited to 16 bits means that larger networks are limited to a maximum of about 64K systems. My guess is that there are fewer than a dozen networks for which this causes problems. This address limitation in Phase IV DECnet is one of the reasons that DEC is moving to OSI for DECnet Phase V. I hope this helps. Selden E. Ball, Jr. (Wilson Lab's network and system manager) Cornell University Voice: +1-607-255-0688 Laboratory of Nuclear Studies FAX: +1-607-255-8062 Wilson Synchrotron Lab BITNET: SYSTEM@CRNLNS Judd Falls & Dryden Road Internet: SYSTEM@LNS61.TN.CORNELL.EDU Ithaca, NY, USA 14853-8001 HEPnet/SPAN: LNS61::SYSTEM = 44283::SYSTEM ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100511532300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 7 Oct 90 15:24:52 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00522; Sun, 7 Oct 90 15:12: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: 5 Oct 90 11:53:23 GMT From: att!mcdchg!ddsw1!proxima!olsa99!iosys!icl011!root@ucbvax.Berkeley.EDU (Super user) Organization: SEan Strand of ICL, Sandton, Jhb, South Africa. Subject: Re: Looking for POP mail for MAC Message-Id: <119@icl011.UUCP> References: <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. hi Steven Wallace of Indiana Uv did you ever find the POP/Coke for your Mac/Rain/Coats, will not to panic if've just the thing for you. 1. find a pen. 2. find a paper ( used may suit ) 3. use 'effort' to scribe pen on paper! 5(a) not what you may have wonted but it's a good, ain't it! /******************************************************************************* * Sean J & Associates. * * COPYRIGHT (c) 1984-1989 Sean J & Ass, Knockyrourke Co Cork, Ireland. * * All rights reserved. No part of this work covered by the * * copyright hereon may be reproduced or used in any form or by any means * * -- graphic, electronic, or mechanical, including photocopying, * * recording, taping, or information storage and retrieval systems -- * * without permission of Sean J & Associates. * ******************************************************************************/ Very Best Regards, SEan S. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100514555900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 18:08:47 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12416; Sat, 6 Oct 90 18:05: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: 5 Oct 90 14:55:59 GMT From: bu.edu!polygen!bill@uunet.uu.net (Bill Poitras) Organization: Polygen Corporation, Waltham, MA Subject: Re: SLIP, IP Routers and Named Pipes Message-Id: <835@redford.UUCP> References: <1990Oct1.135507.27559@cfctech.cfc.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Phil Karn's KA9Q package would do just fine. KA9Q is a program that allows connection to the PC via ftp, telnet, smtp, et. al. at the same time. It has a builtin multitasking mechanism. It also supports slip, and routing. I have used it for a slip to ethernet router before. You can find it on thumper.bellcore.com under the /pub/ka9q directory. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100514572300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 9 Oct 90 23:14:53 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03499; Tue, 9 Oct 90 22:57: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: 5 Oct 90 14:57:23 GMT From: swrinde!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!sun-barr!olivea!oliveb!felix!dhw68k!zardoz.cpd.com!durin!frankh@ucsd.edu (Frank Halsema) Organization: SPARTA Inc. Laguna Hills Operations. CA Subject: PCPOP hangs Message-Id: <4052@durin.sparta.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I just picked up PC POP from nasa.trident.gov. I set up the popd on my sun 3/280 running SunOS 4.1. I have had NCSA telnet with packet drivers for a while and they work fine. The set up is a com 3c503 card with the memory jumper on CC000 packet driver version 4.2 the command for the driver is c:\ncsa\3c503 0x7e 3 0x300 1 I enter set configtel=c:\ncsa\config.tel when i run pcpop in the directory pcpop I comes up with the initial configuration screen. If I type with minimal delays I can get the information in but after entering yes to confirm the configuration it hangs. Also if I delay in entering the configuration data I get a hang immediately. I have taken everything out of my config.sys except for the ANSI.SYS, FILES, and BUFFERS lines. There is also a break=on. below is my config.tel. Any help would be greatly appreciated. # # Example host file for Telnet 2.2 # # "funny, this configuration file is readable ..." # # This file is free form # Separators are any char <33 and :;= # # The form is keyword=value for each parameter. # The first set of parameters refer to the whole program's defaults. # These parameter values can be in any order. # Following this are the individual machine specs. # If the first machine is name "default", then it contains default # values for the rest of the machines. # myip=192.42.141.101 name=pippin netmask=255.255.255.0 # subnetting mask hardware=packet # values are: 3c501,ni5210,pcnic,wd8003 # for ps/2: nicps2,3c523 tek=yes # enable tektronix graphics video=ega # type of video screen # Legal values for video are: # cga,ega,no9,hercules bios=no # don't use slow BIOS screen access # bios=yes to reduce flicker on cga # bios=yes for TopView or Windows interrupt=3 # hardware IRQ interrupt for 3C501 board address=0 ioaddr=7E # base address for I/O registers ftp=yes # do you want ftp enabled? rcp=yes # do you want rcp enabled? capfile=mycap # default name for capture file domain="sparta.com" # default domain for name lookups hpfile=hp.out # file to write HPGL to, # COM1 can be used for attached plotter psfile=ps.out # file to write postscript to tekfile=tek.out # file to write Tek codes to arptime=4 # arp timeout in seconds # affects machines on your local network #passfile="c:\ncsa\ftppass" # name of file to find FTP passwords in # # Following are individual machine specifications # Gateways are used in order that they appear in the file # Nameservers rotate, #1, #2, #3, #1, #2 when a request fails # # The machine named "default" contains the fields which are automatically # filled in for other hosts. name=default machine should appear first. # name = default # Session name, "default" is a reserved name # Not a real machine, default parameters only # # #gateway=1 # This machine is a gateway for me # scrollback=100 # number of lines of scrollback per session erase=delete # use delete code or backspace code for <- key? # legal values are "delete" and "backspace" vtwrap=yes # should VT100 be in wrap mode or not? nfcolor=green # normal, foreground nbcolor=black # normal, background rfcolor=black # reverse, foreground rbcolor=white # reverse, background ufcolor=blue # underline, foreground ubcolor=black # underline, background #crmap=4.3BSDCRNUL # map of the CR key for compatibility #duplex=half # modifier for non-echo mode, forces send clearsave=yes # save lines on clear screen yes/no # The following entries affect the tuning of TCP connections to this host. # They should be set by the network administrator who is familiar with # the requirements of your specific network. contime=20 # timeout in seconds to try connection retrans=7 # starting retransmit time out in ticks # 1/18ths of sec mtu=512 # maximum transmit unit in bytes # outgoing packet size, MAX=1024 maxseg=512 # largest segment we can receive # whatever the hardware can take, MAX=1536 rwin=512 # TCP window size, MAX=4096 # # Below this line, most of the communication parameters are obtained # from the "default" host entry. # Machine names, IP addresses, and special communication parameters are # present when needed. # name=durin ; hostip=192.42.141.7 ; nameserver=1 #name=mynameserver ; hostip=127.0.0.2 ; nameserver=1 -- Frank Halsema UUCP: durin!frankh SPARTA, Inc. Internet: frankh%durin@uunet.uu.net 23041 de la Carlota, Suite 400 Laguna Hills Ca, 92653 (714) 768-8161 EXT 339 (714)583-9114 FAX ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100515223100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 5 Oct 90 19:56:27 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15864; Fri, 5 Oct 90 19:51: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: 5 Oct 90 15:22:31 GMT From: world!esegue!johnl@uunet.uu.net (John R. Levine) Organization: Segue Software, Cambridge MA Subject: Re: Does anybody know LM-X or Lackman? Message-Id: <1990Oct05.152231.21219@esegue.segue.boston.ma.us> References: <1990Oct3.192349.781@resam.dk>, <12817@asylum.SF.CA.US> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <12817@asylum.SF.CA.US> sharon@asylum.UUCP (Sharon Fisher) writes: >Lachman Associates -- the last address I have for them is 1901 N. >Naper Blvd., Naperville, IL 60540-1031; (312) 505-9100; fax (312) 505-9133. Lachman is now a subsidiary of Interactive Systems, but they're still at the same address. On the net they're known as laidbak.uucp or i88.isc.com. The telephone area code has changed from 312 to 708, the postal zip to 60563-8895. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|spdcc|world}!esegue!johnl Atlantic City gamblers lose $8200 per minute. -NY Times ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100516231600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 16:23:54 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10617; Sat, 6 Oct 90 16:19: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: 5 Oct 90 16:23:16 GMT From: sdd.hp.com!usc!isi.edu!gremlin!nrtc.northrop.com!domae@ucsd.edu (Terry Domae) Organization: Northrop Research & Technology Center, Palos Verdes, CA Subject: CSLIP/PPP Status? Message-Id: <10640@gremlin.nrtc.northrop.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does anyone know the current status of CSLIP and PPP? I have not seen any real news in almost a year. Terry Domae Northrop Research and Technology Center Terry Domae ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100516415900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 11:45:33 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06006; Sat, 6 Oct 90 11:37: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 Oct 90 16:41:59 GMT From: hpda!hpcupt1!hpindwa!raj@ucbvax.Berkeley.EDU (Rick Jones) Organization: Hewlett-Packard, Cupertino CA Subject: Re: SLIP, IP Routers and Named Pipes Message-Id: <36540014@hpindwa.HP.COM> References: <1990Oct1.135507.27559@cfctech.cfc.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil A few new-to-named-pipes questions... Am I correct in assuming that it is the 'non-passing' for certain IP/UDP broadcast packets that prevents 'stock' named-pipes from working across IP routers? If that is the only reason, then could one expect named-pipes to work across a router that could be configured to pass these broadcasts in a controlled manner? (no loops and all that...) inquireing minds and all... rick ___ _ ___ |__) /_\ | Richard Anders Jones | MPE/XL Networking Engineer | \_/ \_/ Hewlett-Packard Co. | 'Tis nobler to suffer... ------------------------------------------------------------------------ Being an employee of a Standards Company, all Standard Disclaimers Apply ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100517031300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 01:42:05 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA20723; Sat, 6 Oct 90 01:27: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: 5 Oct 90 17:03:13 GMT From: ogicse!plains!kapoor%plains.NoDak.edu@decwrl.dec.com (Sanju Kapoor) Organization: North Dakota State University, Fargo Subject: Broadcasting on Sockets Message-Id: <6142@plains.NoDak.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am sending this for a friend of mine who does not have access to this net group. I would send all replies to him. Here is his question : /****************************************************************************** I am having problems with broadcasting on socket. I keep getting the message "Can't assign requested address" when I call the function sendto. What am I doing WRONG. I am sending the code where I am having the problem. When I do "ifconfig le0" on the interface I do see the broadcast address of my network interface(lance ethernet). ALL machines are SUN SPARCstation SLC running SunOS 4.1. I am trying to write a function that will find a resource on the network. On each of the host machine on the network there is a server which keeps track of the resources available on the local host. When a client needs a resource "X" it sends a broadcast message to locate the resource and waits for the response from the server which owns the resource. Assume that the resources uniquely exist on the network. I may be doing something wrong here but can't seem to fix it. If anyone can give suggestions I would appreciate it . Also, I would like to know how does the server on the host listen for broadcast message. Thanks in advance. *******************************************************************************/ int find_resource(resource,location) char *resource, /* resource to be located */ *location; /* location of the resource */ /* to be set by this function */ { int brd_socket, brd_on, cnt, len; char buf[BUFSIZ]; struct sockaddr_in clnt_addr, serv_addr; struct sockaddr dest_addr; struct ifconf ifc; struct ifreq *ifr; if ((brd_socket = socket(AF_INET,SOCK_DGRAM,0)) < 0) return (-1); brd_on = 1; if (setsockopt(brd_socket,SOL_SOCKET,SO_BROADCAST, &brd_on,sizeof(brd_on)) == -1) return(-1); clnt_addr.sin_family = AF_INET; clnt_addr.sin_addr.s_addr = htonl(INADDR_ANY); clnt_addr.sin_port = 0; len = sizeof(clnt_addr); if (bind(brd_socket,(struct sockaddr *) &clnt_addr,len) < 0) return(-1); ifc.ifc_len = sizeof(buf); ifc.ifc_buf = buf; if (ioctl(brd_socket,SIOCGIFCONF,(char *) &ifc) < 0) return(-1); ifr = ifc.ifc_req; for (cnt = ifc.ifc_len/sizeof(struct ifreq); --cnt >0 ; ifr++) { if (ifr->ifr_addr.sa_family != AF_INET) continue; if (ioctl(brd_socket,SIOCGIFFLAGS,(char *) ifr) < 0) return(-1); if (((ifr->ifr_flags & IFF_UP) == 0) || (ifr->ifr_flags & IFF_LOOPBACK) || ((ifr->ifr_flags & IFF_BROADCAST) == 0)) continue; if (ifr->ifr_flags & IFF_BROADCAST) if (ioctl(brd_socket,SIOCGIFBRDADDR,(char *) ifr) < 0) return(-1); bcopy(ifr->ifr_broadaddr,(char *)&dest_addr, sizeof(ifr->ifr_broadaddr)); len = strlen(resource); if (sendto(brd_socket,resource,len,0,(struct sockaddr *) &dest_addr,sizeof(dest_addr))== -1) return(-1); } if (recvfrom(brd_socket,location,sizeof(location),0, (struct sockaddr*)&serv_addr,&len) == -1) return(-1); return(0); } ---------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100517262800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 9 Oct 90 19:53:59 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23259; Tue, 9 Oct 90 19:42: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: 5 Oct 90 17:26:28 GMT From: zaphod.mps.ohio-state.edu!samsung!olivea!oliveb!felix!dhw68k!fedeva!bill@tut.cis.ohio-state.edu (Bill Daniels) Organization: Federal Express Corp., Memphis, TN Subject: is syslog(3) to remote possible? Message-Id: <111@fedeva.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I posted a similar request about a week or two ago. Just as luck would have it my news machine went away for a couple of days right afterwards. I have need to log operator messages via syslog(3) on a remote machine. I am sure that this is possible because of the way the docs and headers read. It seems however that Ultrix has coded up syslog() so that all messages go to the local machine. If there is a way around this I would be ever grateful to the one who shares the insight. If there is not a workaround, could someone mail me the source to syslog(3) and syslog(8) if it is publicly available? Thanks for your help bill daniels -- bill daniels federal express, memphis, tn {zardoz!dhw68k,mit-eddie!premise}!fedeva!bill bill@fedeva.UUCP ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100517541400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 01:38:55 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21145; Sat, 6 Oct 90 01:37: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: 5 Oct 90 17:54:14 GMT From: tjh+@andrew.cmu.edu (Tom Holodnik) Organization: Computing Systems, Carnegie Mellon, Pittsburgh, PA Subject: SLIP for the NeXT machine? Message-Id: <4b3AX6i00WCoF9DoBX@andrew.cmu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Is there a (preferably free) SLIP implementation for the NeXT machine? Thanks in advance. ____________________________ Tom Holodnik Networking & Communications Carnegie-Mellon University UCC-137 4910 Forbes Avenue Pittsburgh PA 15213 (412)-268-2028 ____________________________ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100519092200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 02:26:06 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21834; Sat, 6 Oct 90 01:57: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: 5 Oct 90 19:09:22 GMT From: rogue.llnl.gov!oberman@lll-winken.llnl.gov Subject: Re: Reply to Ethernet Address Uniqueness... Message-Id: <1990Oct5.120922.1@rogue.llnl.gov> References: <5A0A050B012801FE-MTAEMR1*fillmore@emrcan> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <5A0A050B012801FE-MTAEMR1*fillmore@emrcan>, fillmore@emrcan.BITNET writes: > In the DEC VAX environment the unique Ethernet address on each board is > overridden by DECNET when it starts to use that board. The address is set > to four bytes of a constant value plus two bytes which contain the DECNET > area and node numbers. Lots of opportunity for duplication! > Does anyone know why DEC chose this scheme? Basic answer- They messed up! DECnet Phase V will abandon this ill concieved idea. It was a clever idea to allow a direct and unambiguous translation from DECnet address to Ehternet address which eliminates the need for ARP or some similar method of Ethernet address resolution. They have since learned the folly of this and do the reverse in Phase V. They code the 6 bytes of the Ethernet address into the system's NSAP (OSI address). R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100519103300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 02:24:45 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22508; Sat, 6 Oct 90 02:17: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 Oct 90 19:10:33 GMT From: sunquest!alpha.sunquest.com!gavron@arizona.edu (Ehud Gavron) Organization: Sunquest VMS Internals, Tucson AZ Subject: Re: Reply to Ethernet Address Uniqueness... Message-Id: <8601@sunquest.UUCP> References: <5A0A050B012801FE-MTAEMR1*fillmore@emrcan> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <5A0A050B012801FE-MTAEMR1*fillmore@emrcan>, fillmore@emrcan.BITNET writes... #In the DEC VAX environment the unique Ethernet address on each board is #overridden by DECNET when it starts to use that board. The address is set #to four bytes of a constant value plus two bytes which contain the DECNET #area and node numbers. Lots of opportunity for duplication! #Does anyone know why DEC chose this scheme? On one ethernet, the duplication only occurs if two nodes have the same DECnet address -- which is not only a no-no but since both would have terrible problems, this condition would not persist long. There is therfore not "lots of opportunity for duplication." It also is completely immaterial why DEC chose this scheme. Suffice to say that the next major DECnet release (now targeted for '92) will be completely different. # # - Bob Fillmore FILLMORE@EMRCAN.BITNET ^^^^^^ Ehud /----------------------------------------------------------------------------\ | Ehud Gavron, Systems analyst | gavron@vesta.sunquest.com (Internet) | | Sunquest Information Systems | uunet!sunquest!gavron (UUCP) | | 930 N. Finance Center Drive | gavron@lampf (BITNET) | | Tucson, Arizona, 85710 | (602)722-7546/885-7700 x.2546 (AT&Tnet) | |----------------------------------------------------------------------------| | your cute quote here | \----------------------------------------------------------------------------/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100519163500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 03:53:41 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26795; Sat, 6 Oct 90 03:48: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 Oct 90 19:16:35 GMT From: bu.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!aero!ctw@bloom-beacon.mit.edu (Charles T. Wolverton) Organization: The Aerospace Corporation, El Segundo, CA Subject: Re: TCP/IP for DEPCA boards Message-Id: <87753@aerospace.AERO.ORG> References: , , Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In Article: 13237, ianh@bhpmrl.oz.au (Ian Hoyle) says: > Wollongong's TCP for DOS has appropriate drivers etc. for DEPCA cards ... ian My Wollongong documentation has installation instructions for 1. "an existing DEC LAN in working condition" 2. "an existing 3com 3+Open LAN in working condition" Is this equivalent to: 1.' "a network card with the appropriate DEC DLL-compliant driver" 2.' "a network card with the appropriate MS NDIS-compliant driver and protocol manager software" ??? If no, I don't understand the response quoted above. If yes, wouldn't the restated versions (possibly corrected, since I don't really understand yet how NDIS works and know nothing about DLL) be more generally useful?? Edification, please. -chas ctw@aero.org -- *** Charles T. Wolverton ***** Aerospace Corporation *** *** ctw@aerospace.aero.org ***** P.O. Box 92957 M1-023 *** *** (213) 336-5204 ***** Los Angeles, CA 90009 *** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100519232300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 04:10:10 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27770; Sat, 6 Oct 90 04:07: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: 5 Oct 90 19:23:23 GMT From: olivea!orc!bu.edu!mirror!roskuski@apple.com (Barry J. Roskuski) Organization: Mirror Systems. Cambridge, Mass. Subject: Long distance TCP/IP Message-Id: <48185@mirror.tmc.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Please excuse the dumb question, but I am utterly ignorant about this stuff. What is necessary to set up a TCP/IP network between two UNIX systems at 2 different sites? I've guessed that we can use SLIP over a modem, but performance probably wouldn't be what we'd like. I've heard mention of T1 lines, but am not sure how I would connect to them (or even what they are for that matter). Can you hang a T1 line off of an ethernet with the appropriate bridge? Is this what I need, or am I way off base? And how does X.25 fit into this. Any help or pointers in the right direction would be appreciated. --- Barry J. Roskuski Mirror Systems 2067 Massachusetts Ave. Cambridge, MA 01240 roskuski@mirror.TMC.COM {mit-eddie, pyramid, harvard!wjh12, xait}!mirror!roskuski ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100519334900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 03:08:30 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24253; Sat, 6 Oct 90 02:54: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 Oct 90 19:33:49 GMT From: arizona.edu!leonard@arizona.edu Organization: University of Arizona Subject: Re: Ethernet Address Uniqueness... Message-Id: <1990Oct5.123350.145@arizona.edu> References: <5A0A050B012801FE-MTAEMR1*fillmore@emrcan> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <5A0A050B012801FE-MTAEMR1*fillmore@emrcan>, fillmore@emrcan.BITNET writes: > In the DEC VAX environment the unique Ethernet address on each board is > overridden by DECNET when it starts to use that board. The address is set > to four bytes of a constant value plus two bytes which contain the DECNET > area and node numbers. Lots of opportunity for duplication! > Does anyone know why DEC chose this scheme? Sure, it saves DECnet having to have an address resolution protocol a la ARP ... if a DECnet node wants to find the MAC address for a given DECnet address, it already knows what the address *should* be. There's a couple of problems with this approach: 1. If you are running different network protocols on the same Ethernet board, then obviously they can't *all* do this! I believe that Novell's IPX similarly hacks the Ethernet address, which (if true) means that DECnet and IPX can't share the same board. 2. A DECnet node can't have multiple Ethernet interfaces running DECnet on the same bridge-extended Ethernet. (Because the bridges will see the same Ethernet addr on both sides!) This may seem like a perverse topology to IP oriented folks, but given DEC's historical MAC layer uber alles approach, in some situations this can be exactly what you would want. In DECnet Phase V (due out twelve months from any given point in time ;-) ), DECnet is supposed to stop resetting the hardware addresses on its Ethernet adapters, and will presumably adopt some ARP protocol. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100519523700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 04:08:56 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27063; Sat, 6 Oct 90 03:54: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 Oct 90 19:52:37 GMT From: sun-barr!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@decwrl.dec.com (Henry Spencer) Organization: U of Toronto Zoology Subject: Re: Ethernet Address Uniqueness... Message-Id: <1990Oct5.195237.2176@zoo.toronto.edu> References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article linegar@bwdls49.bnr.ca (Derick Linegar) writes: >our vendor eluded to us that the 2 ethernet cards assume the *same* Ethernet >address, obtained from the primary ethernet board. Of course, warning bells >are going of here. Now I've been searching the RFC and IEEE docs and I cannot >find any documentation that sort of says that Ethernet Addresses are assigned >to Ethernet boards, not hosts. This seems to come up fairly often... The original intent of Ethernet was quite specifically to assign addresses to hosts, not boards, which is one reason why Ethernet addresses are required to be programmable instead of being locked into the boards. The XNS protocols use Ethernet addresses as host numbers and *must* have exactly one address per host. With TCP/IP, the Ethernet addresses are largely invisible to the upper levels and it doesn't really matter much either way, unless for some reason you've got two boards on the same network (in which case you will have other problems...). -- Imagine life with OS/360 the standard | Henry Spencer at U of Toronto Zoology operating system. Now think about X. | henry@zoo.toronto.edu utzoo!henry ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100520335000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 02:24:15 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22682; Sat, 6 Oct 90 02:21: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: 5 Oct 90 20:33:50 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!rphroy!cfctech!alexb@decwrl.dec.com (Alex Beylin) Organization: Chrysler Financial Corporation, Southfield, MI. Subject: Re: SLIP with Named Pipes Message-Id: <1990Oct5.203350.12118@cfctech.cfc.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil First, thanks to everyone for many helpfull responces regarding SLIP and Named Pipes. From the responces I see that more details are in order. What ww would like to do is allow users with portable computers and modems to user DCA's CommServer in order to access 3090 resources. As James Van Bokkelen pointed out, we have to use Lan Manager. CommServer can use a number of APIs, but Named Pipes seems the cleanest. In order to carry it all the way to the PC we will need NetBios and SLIP software on the PC. The solution seems to be cisco SLIP concentrator and PC/TCP (Thank you, James). We will be running tests late October. I will post results to this group. Again, thanks to everyone for all the help. -- Alex Alex Beylin, Unix Specialist | +1 313 948-3386 alexb@cfctech.cfc.com | Chrysler Financial Corp. sharkey!cfctech!alexb | MIS, Distributed Systems ATT Mail ID: attmail!abeylin | Southfield, MI 48034 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010052216.AA10852@ucbvax.Berkeley.EDU] <1990100521240000> From: system@LNS61.TN.CORNELL.EDU Newsgroups: comp.protocols.tcp-ip Subject: re: Reply to Ethernet Address Uniqueness... Message-ID: <9010052216.AA10852@ucbvax.Berkeley.EDU> Date: 5 Oct 90 21:24:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 42 Posted: Fri Oct 5 22:24:00 1990 Bob, >In the DEC VAX environment the unique Ethernet address on each board is >overridden by DECNET when it starts to use that board. The address is set >to four bytes of a constant value plus two bytes which contain the DECNET >area and node numbers. Lots of opportunity for duplication! >Does anyone know why DEC chose this scheme? The "four constant bytes" are reserved to DEC (for DECnet) just as the high-order butes of the physical hardware Ethernet addresses in those Ethernet boards' address ROMs are also reserved to DEC. In a given DECnet wide-area network, all DECnet node addresses are required to be unique. As a result, there is no opportunity for duplication on a local Ethernet either. (I am ignoring the complications introduced by setting limits on the address ranges passed by routers.) One reason that DEC chose this scheme is that it allows "end-node" DECnet systems, which have no routing information whatsoever, to be able to send messages to other end-node systems on the same Ethernet even when there are no DECnet routers present. They just calculate what the Ethernet address must be and blindly transmit the message into the ether. Of course, the fact that DECnet addresses are limited to 16 bits means that larger networks are limited to a maximum of about 64K systems. My guess is that there are fewer than a dozen networks for which this causes problems. This address limitation in Phase IV DECnet is one of the reasons that DEC is moving to OSI for DECnet Phase V. I hope this helps. Selden E. Ball, Jr. (Wilson Lab's network and system manager) Cornell University Voice: +1-607-255-0688 Laboratory of Nuclear Studies FAX: +1-607-255-8062 Wilson Synchrotron Lab BITNET: SYSTEM@CRNLNS Judd Falls & Dryden Road Internet: SYSTEM@LNS61.TN.CORNELL.EDU Ithaca, NY, USA 14853-8001 HEPnet/SPAN: LNS61::SYSTEM = 44283::SYSTEM ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100602381700> Received: from genbank.bio.net by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 10:49:51 PDT Received: from asylum.UUCP by genbank.bio.net (5.61/IG-2.0) with UUCP id AA06436; Sat, 6 Oct 90 10:50:27 -0700 Received: by asylum.sf.ca.us (smail2.5x) id AA24469; 6 Oct 90 09:38:17 PDT (Sat) To: oberman@rogue.llnl.gov Cc: tcp-ip@nic.ddn.mil In-Reply-To: decwrl!lll-winken.llnl.gov!rogue.llnl.gov!oberman's message of 5 Oct 90 19:09:22 GMT <1990Oct5.120922.1@rogue.llnl.gov> Subject: Reply to Ethernet Address Uniqueness... Reply-To: romkey@asylum.sf.ca.us Message-Id: <9010060938.AA24469@asylum.sf.ca.us> Date: 6 Oct 90 09:38:17 PDT (Sat) From: romkey@asylum.sf.ca.us (John Romkey) Date: 5 Oct 90 19:09:22 GMT From: decwrl!lll-winken.llnl.gov!rogue.llnl.gov!oberman References: <5A0A050B012801FE-MTAEMR1*fillmore@emrcan> Sender: tcp-ip-relay@nic.ddn.mil They code the 6 bytes of the Ethernet address into the system's NSAP (OSI address). What a great idea. So if you change your ethernet card, your machine's address changes too? - john romkey USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@ftp.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100603323700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 04:10:27 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27464; Sat, 6 Oct 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: 6 Oct 90 03:32:37 GMT From: shelby!msi.umn.edu!cs.umn.edu!peiffer@decwrl.dec.com (Tim Peiffer (The Net Guy)) Organization: University of Minnesota, Minneapolis - CSCI Dept. Subject: Re: SLIP, IP Routers and Named Pipes Message-Id: <1990Oct6.033237.27399@cs.umn.edu> References: <1990Oct1.135507.27559@cfctech.cfc.com>, <8879@allen.ingr.com>, <9987@xenna.Xylogics.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9987@xenna.Xylogics.COM> kriger@Xylogics.COM (Sidney Kriger) writes: >In article <8879@allen.ingr.com> usenet@b11.ingr.com (Usenet Network) writes: >>I worked for an outfit that sold cisco and the company I work for now >>sells the Encore Annex II. >Xylogics now manufactures the Annex II terminal server and has for about >2 years, not Encore. 800-225-3317 I have both the Encore and Xylogics varients of the Annex II terminal server running some ports under slip. I am very happy with the ease in configuration, but I would like to see something that supports the Van Jacobsen hdr compression algorithms( RFC 1144). Does anyone know of a product that supports this scheme? SLIP is sssoooo easy to configure slip on an Annex. It seems like a shame to waste it, but ftp and telnet are so gawdawfully slow even over a 38.4k link that I still resist putting it in place. For those that care, Xylogics is the Manufacturer of the Annex now, but Encore still oem's the product, and they have their own software line to support the normal Encore line of multimaxen. Tim -- ----------- Tim Peiffer peiffer@cs.umn.edu or Computer Science Dept ..!rutgers!umn-cs!peiffer University of Minnesota ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100603562500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 04:54:39 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29161; Sat, 6 Oct 90 04:39: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: 6 Oct 90 03:56:25 GMT From: agate!shelby!msi.umn.edu!cs.umn.edu!peiffer@apple.com (Tim Peiffer (The Net Guy)) Organization: University of Minnesota, Minneapolis - CSCI Dept. Subject: Re: Nameservice questions Message-Id: <1990Oct6.035625.29037@cs.umn.edu> References: <465@bcstec.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <465@bcstec.UUCP> ced@bcstec.uucp (Charles Derykus) writes: > (1) Can nameservice resolve reverse translation queries "up the tree" > towards the root domain if the domains of the requested node and > the requesting node are at the same level, e.g. [...} > can "carrot" ask "cabbage" to reverse translate an I.P. in > "herb.vegetable" and if so, how? Yes, you can forward unresolved entries (those not in your domain or in your secondary zones) by using the forwarding construct in named.boot. ; forward name-service request when we can't (won't) handle them forwarders first_forwarder_ipaddr second_forwarder_ipaddr > (2) A named.rev with multiple $ORIGIN lines worked fine on out primary > nameserver for a while but then the secondary nameserver starting > breaking. The only way we get it working now is by specifying separate > reverse translation files for each $ORIGIN line, e.g. I do not really understand. I would answer your question with no. The in-addr.arpa domain is rather unusual and should be treated differently than most others. The declaration in named.boot specifies service for a particular domain. I think that your declaration would break unless it were of the following form: named.boot ---------- primary 207.128.in-addr.arpa. herb.file_name herb.file_name ---------- $ORIGIN 254.207.128.in-addr.arpa. 44 IN PTR parsley.herb.blah.blah. $ORIGIN 253.207.128.in-addr.arpa. 1 IN PTR oregano.herb.blah.blah. Tim -- ----------- Tim Peiffer peiffer@cs.umn.edu or Computer Science Dept ..!rutgers!umn-cs!peiffer University of Minnesota ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100604002900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 04:23:56 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27984; Sat, 6 Oct 90 04:12: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: 6 Oct 90 04:00:29 GMT From: agate!shelby!msi.umn.edu!cs.umn.edu!peiffer@apple.com (Tim Peiffer (The Net Guy)) Organization: University of Minnesota, Minneapolis - CSCI Dept. Subject: Re: quick check for available host Message-Id: <1990Oct6.040029.29288@cs.umn.edu> References: <771@tiamat.fsc.com>, <1990Oct3.200749.16049@cbnewsk.att.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Oct3.200749.16049@cbnewsk.att.com> lih@cbnewsk.att.com (andrew.a.lih) writes: >In article <771@tiamat.fsc.com>, jim@tiamat.fsc.com (Jim O'Connor) writes: >> What is a quick way for a shell script to find out if a networked >> host is currently available? If you want more than what 'ping' offers, but not the mess that rwho provides, check out rup(), and rusers(). Tim -- ----------- Tim Peiffer peiffer@cs.umn.edu or Computer Science Dept ..!rutgers!umn-cs!peiffer University of Minnesota ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100604325600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 16:23:42 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10482; Sat, 6 Oct 90 16:12: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: 6 Oct 90 04:32:56 GMT From: mimos!rangkom!napi@uunet.uu.net (Mazli Hashim) Organization: MIMOS, Malaysia Subject: Problem with remote printing Message-Id: <291@rangkom.MY> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi netters When I send a job for remote printing from a Convex via an Apollo workstation which is attached to an Apple Laser Writer II, the 'lpd' on the Convex gives this error message in 'lpd-errs':- /usr/lib/lpd: lw: lost connection or error in recvjob and the 'lpd' on the Apollo gives this error message in its 'lpd-errs':- Oct 6 12:05:28 t1a lpd[1537]: cannot find device 1222352, 1 What could be the problem(s)? Any pointers are appreciated. Napi ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100615132900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 16:09:44 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10243; Sat, 6 Oct 90 15:54: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: 6 Oct 90 15:13:29 GMT From: att!cbnews!junk1@ucbvax.Berkeley.EDU (eric.a.olson) Organization: AT&T Bell Laboratories Subject: Re: Does anybody know LM-X or Lackman? Message-Id: <1990Oct6.151329.22919@cbnews.att.com> References: <1990Oct3.192349.781@resam.dk>, <12817@asylum.SF.CA.US>, <1990Oct05.152231.21219@esegue.segue.boston.ma.us> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have heard that if you run a program on a virtual console (vt??), the console will not be subject to screen-scrambling with console error messages. This appears to be true, as my machine running X never gets bothered by the messages. How do I force the console into this mode? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100619073400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 11:08:29 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05557; Sat, 6 Oct 90 11:08: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: 6 Oct 90 19:07:34 GMT From: swrinde!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucsd.edu (Edward Vielmetti) Organization: University of Michigan Math Dept., Ann Arbor MI. Subject: Re: Is there a program like telnet, but driven by a script? Message-Id: References: <26797@fmsrl7.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <26797@fmsrl7.UUCP> hugh@slee01.srl.ford.com (Hugh Fader) writes: I need to duplicate UNIX-to-UNIX rsh functionality going UNIX-to-VMS. I am running a Sun Sparcstation and can communicate with the VAX using telnet and ftp via an ULTRIX gateway (the VAX only runs DECNET). One solution to my problem would be a telnet-like program which accepts a script containing expect/send pairs much like UUCP and some PC communications programs. Does such a program exist? See "expect" from Don Libes, ftp'able from durer.cme.nist.gov. An extract from the man page: expect is a program that "talks" to other interactive pro- grams according to a script. Following the script, expect knows what can be expected from a program and what the correct response should be. An interpreted language pro- vides branching and high-level control structures to direct the dialogue. In addition, the user can take control and interact directly when desired, afterward returning control to the script. Since this is a program which isn't necessarily related to tcp/ip, please follow up to comp.unix.misc. --Ed Edward Vielmetti, U of Michigan math dept moderator, comp.archives ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100621211300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 14:38:49 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA09129; Sat, 6 Oct 90 14:29: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: 6 Oct 90 21:21:13 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!pluto!rstevens@ucsd.edu (Rich Stevens) Organization: National Center for Supercomputing Applications Subject: Re: >>> Internetworking with TCP/IP book FOR SALE <<< Message-Id: <1990Oct6.212113.24948@ux1.cso.uiuc.edu> References: <1990Oct2.014856.12758@ncsuvx.ncsu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Be aware that the 2nd edition of this book was just published by Prentice Hall. I've only glanced at it, so I can't give a list of what's changed, but it is about 150 pages longer. This 2nd edition retains the subtitle "Principles, Protocols, and Architectures" and is listed as Volume I. The back cover lists Volume II with the subtitle "Implementation and Internals" and its by Comer and David L. Stevens. I believe that Volume II will be out in 1991 and will contain the source code to the Xinu implementation of TCP/IP. Richard Stevens ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100700044800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 6 Oct 90 17:10:17 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA11416; Sat, 6 Oct 90 17:05: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: 7 Oct 90 00:04:48 GMT From: zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!news@tut.cis.ohio-state.edu (Cliff Yamamoto) Organization: Jet Propulsion Laboratory, Pasadena, CA Subject: Our Sun isn't "RIPing" Message-Id: <1990Oct7.000448.26450@elroy.jpl.nasa.gov> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Greetings network gurus! We have a Sun Sparc+ running as a file server and router for our building's LAN. We also have a Banyan server running as passive router on the same physical ethernet. On this same ethernet, we have various PCs. Some are running PC-NFS while others are running PC/TCP on top of Vines. A picture is probably in order: PC . . . PC . . . PC . . . etc Banyan | | | +--Server--+ | | | | | x.x.63.1 +-----------+-----------+---------------+----------+-----------+ x.x.63.10 x.x.91.20 x.x.91.21 x.x.63.107 x.x.91.1 | Sun Sparc+ where: x.x.63.x is Tcp/Ip & NFS | x.x.91.x is Banyan/Vines x.x.1.137 x.x.1.xxx | x.x.1.xx is Labwide backbone ----------------------------+ | | x.x.1.165 Sun other A hosts & subnets The situation: - We have /etc/gateways on the Sun Sparc+ configured as required. - All the PCs on the 63.x and 91.x subnets can ping each other fine. - All the PCs on the 63.x can ping the x.x.1.xxx hosts and vice-versa. - The Sun Sparc+ can ping all hosts on all subnets. The problem: - NONE of the 91.x hosts can ping the x.x.1.xxx hosts and vice-versa. The probable cause? - The Sun Sparc+ is not sending out RIP info to the hosts on x.x.1.xxx about the 91.x subnet. The test: - We added an explicit /etc/gateway routing entry at Sun A. It basically tells Sun A that all x.x.91.0 traffic should route to x.x.1.165 with a metric of 1 and passive. THIS WORKED!! Sun A was able to ping all PCs on the 91.x subnet and vice-versa. The question: So does anyone know what causes this? We don't have access to a sniffer so it makes it difficult to see if the Sparc+ is sending out info. Is there something we missed? Any help would be appreciated. Thanks in advance! Cliff Yamamoto ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100715444800> Received: from mathom.cisco.com by NIC.DDN.MIL with TCP; Sun, 7 Oct 90 22:46:32 PDT Date: Sun 7 Oct 90 22:44:48-PDT From: William "Chops" Westfield Subject: Re: SLIP, IP Routers and Named Pipes To: shelby!msi.umn.edu!cs.umn.edu!peiffer@decwrl.dec.com cc: tcp-ip@nic.ddn.mil In-Reply-To: <1990Oct6.033237.27399@cs.umn.edu> Message-ID: <12628063537.11.BILLW@mathom.cisco.com> Does anyone know of a product that supports [cslip]? SLIP is sssoooo easy to configure slip on an Annex. It seems like a shame to waste it, but ftp and telnet are so gawdawfully slow even over a 38.4k link that I still resist putting it in place. Really? FTP is slow? Our experience at cisco (with our own terminal servers, of course) was that FTP was quite zippy - the sliding window of TCP bought you much more than you lost from the big headers. Compared to DEC-20 to PC kermit, FTP's FTP over slip was nearly twice as fast. Telnet, however, was quite painful, and I don't even want to think about running telnet and FTP at the same time. BillW ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100722501200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 7 Oct 90 15:54:52 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01309; Sun, 7 Oct 90 15:51: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 Oct 90 22:50:12 GMT From: bionet!turbo.bio.net!lear@apple.com (Eliot) Organization: GenBank Computing Resource for Mol. Biology Subject: Re: Need a RARP Demon Message-Id: References: <157@avatar.avatar.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Kory Hamzeh asks for information on a PD rarpd. I don't know about rarpd, but would bootp serve your purposes? -- Eliot Lear [lear@turbo.bio.net] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100807044800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 8 Oct 90 17:38:29 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02032; Mon, 8 Oct 90 17:23: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: 8 Oct 90 07:04:48 GMT From: wuarchive!zaphod.mps.ohio-state.edu!usc!neuro.usc.edu!dra@decwrl.dec.com (Diane Annala) Organization: University of Southern California, Los Angeles, CA Subject: Re: Please boycott Xircom Message-Id: <27414@usc.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 In article nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) writes: # #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. # # 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. # #You can bet your bippy I'm going to go over your "independently developed" #packet driver with a fine-toothed comb. Of course, Xircom could include a provision in their copyright notice forbidding nelson@image.clarkson.edu from disassembling, decompiling, or otherwise going over the new packet driver with a fine toothed comb. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100820392900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 14 Oct 90 02:07:43 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16408; Sun, 14 Oct 90 02:03: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: 8 Oct 90 20:39:29 GMT From: news!german@iuvax.cs.indiana.edu (Chad W. German) Organization: Univ. of Notre Dame Subject: NCSA TELNET / BANYAN Message-Id: <478@news.nd.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does anyone have Telnet running concurrently along with Banyan Vines network.... What set-up are you using. With Telnet installed on each workstation every thing works fine as long as your not logged into the file server. Once logged in or having Telnet reside on a network drive, the PC and network loses communications. I'm fimiliar with the way Novell can function with Telnet by the use of packet drivers..... What is the secret for Vines.....?? Thanks in advance for any info../ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100823351100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 9 Oct 90 20:10:03 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24413; Tue, 9 Oct 90 20:03: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: 8 Oct 90 23:35:11 GMT From: gohp3!dc@uunet.uu.net (Darren Croke) Organization: GraphOn Corp., San Jose, CA. Subject: Re: TCP segment size -- user defined? Message-Id: <538@gohp3.graphon.com> References: <266@aldetec.oz.au>, <256@ubeaut.oz.au> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <256@ubeaut.oz.au> mwp@ubeaut.oz.au (Michael Paddon) writes: > > text deleted > >There is not much point setting TCP_MSS to be greater than > (maximum IP packet size - IP header size - TCP header size) >[536 octets] since IP fragmentation will take place. Receipt of a >fragmented packet is an all or nothing proposition; a good thing to >avoid for throughput reasons. > The 536 octects in brackets is the minimum but by no means always equal to (maximum IP packet size - IP header size - TCP header size). Look at the packets on an Ethernet sometime. I am running a 4.3 BSD TCP/IP implementation here that quite happily negotiates a MSS of 1000 bytes and then proceeds to send unfragmented 1000 byte packets. I think you will find that it is common for IP implementations to send and accept datagrams without fragmentation up to (connected network MTU - IP header size - TCP header size). Darren Croke. dc@graphon.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [13855@ulysses.att.com] <1990100902030200> From: smb@ulysses.att.com (Steven Bellovin) Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: rfc1183: new RR types Message-ID: <13855@ulysses.att.com> Date: 9 Oct 90 02:03:02 GMT Sender: netnews@ulysses.att.com Lines: 26 Posted: Tue Oct 9 03:03:02 1990 I just retrieved an RFC defining some new RR types for the DNS. A few things bother me. First, it isn't clear to me that X25 address and ISDN address should be separate types. There are a number of other media where a similar record is needed, such as the Datakit VCS(R) and dial-up SLIP or PPP. I think I'd prefer a media address RR, with a subtype field first. I understand why in some cases one might opt for different records (and the matter is discussed in the RFC for an Andrew File System RR), but I'd vote differently than did the authors. My reasoning is simple: there are, I think, many different media for which the concept is applicable. If the vendor supports media address, I can create my own subtypes; it's much harder to add new RR types without the vendor's name server source. Second, it isn't clear to me who should be using the Route Through RR. Under what circumstances should a router do this (expensive) query? When there's no route to the host? To the network? What if the router doesn't have a direct link to the preferred forwarding host? Route towards is, and hope that the next hop knows enough to use the new record? I'm not saying RT is a bad idea, or hasn't been thought through; I am saying that I'd like to see some discussion on how it's intended to be used in a real Internet. --Steve Bellovin smb@ulysses.att.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100910151300> Received: from VMD.CSO.UIUC.EDU by NIC.DDN.MIL with TCP; Tue, 9 Oct 90 13:18:15 PDT Received: from VMD.CSO.UIUC.EDU by VMD.CSO.UIUC.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 1668; Tue, 09 Oct 90 15:20:23 CDT Received: by UIUCVMD (Mailer R2.07) id 1665; Tue, 09 Oct 90 15:20:21 CDT Date: 9 October 1990 15:15:13 CDT From: To: Subject: .netrc equivalent I'm porting an UNIX/VMS TCP/IP based application written in C to VM/CMS. This application normally refers to the .netrc file to get password information. Are there any convensions on CMS for the equivalent? Also, the program does not like to send the password across the net in clear text so it calls the standard UNIX crypt command to do the DES encryption of the password. Is the DES encription available on VM/CMS systems if I don't own the standard IBM box to do this? What is the standard calling procedure for programs using an IBM DES configuration? -- Daniel Pommert pommert@uiuc.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100910151700> Received: from ugw.utcs.utoronto.ca by NIC.DDN.MIL with TCP; Tue, 9 Oct 90 10:27:52 PDT Received: from EMRCAN (stdin) by ugw.utcs.utoronto.ca with SMTP id 57539; Tue, 9 Oct 90 13:24:54 EDT Received: from CA*NONE*EMR by emr1-gw.emr.ca via QTFS with X.400; Tue, 9 Oct 90 13:20:02 -0500 X400-Trace: CA*NONE*EMR; arrival Tue, 9 Oct 90 13:15:17 -0500 action Relayed Date: Tue, 9 Oct 90 14:15:17 EDT Message-Id: <5A0A090C1F1A031C-MTAEMR1*fillmore@emrcan> P1-Message-ID: CA*NONE*EMR; 5A0A090C1F1A031C-MTAEMR1 UA-Content-ID: 5A0A090C1F1A031C From: fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca Subject: Reply to Re: Ethernet Address Uniqueness... To: TCP-IP@NIC.DDN.MIL In my recent message about DECNET Ethernet address non-uniqueness I should have mentioned that my site works in a mixed DECNET - TCP/IP environment (plus Appletalk, etc.). Problems arise in VAXes which run both DECNET and TCP/IP on the same Ethernet interface - the Ethernet address used in ARP responses depends on whether DECNET was started before or after TCP/IP, because DECNET changes the Ethernet address in the interface hardware (in RAM memory). If the TCP/IP software uses the modified DECNET Ethernet address then there might be address duplication because IP addresses are connection oriented, not node oriented. ________________________ Bob Fillmore, Systems Software & Communications BITNET: FILLMORE@EMRCAN Computer Services Centre, BIX: bfillmore Energy, Mines, & Resources Canada Voice: (613) 992-2832 588 Booth St., Ottawa, Ontario, Canada K1A 0E4 FAX: (613) 996-2953 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100910262900> Received: from ftp.com by NIC.DDN.MIL with TCP; Tue, 9 Oct 90 15:49:58 PDT Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA29376; Tue, 9 Oct 90 18:46:29 -0500 Date: Tue, 9 Oct 90 18:46:29 -0500 Message-Id: <9010092346.AA29376@ftp.com> To: zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!news@tut.cis.ohio-state.edu (Cliff Yamamoto) Subject: Re: Our Sun isn't "RIPing" 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 VINES servers act as very simple IP routers, and as far as I know do not support any dynamic routing protocols (no RIP). If the Sun doesn't hear about about the VINES subnet via RIP, it has to be told via a static route. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100910263100> Received: from ftp.com by NIC.DDN.MIL with TCP; Tue, 9 Oct 90 15:46:14 PDT Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA29384; Tue, 9 Oct 90 18:46:31 -0500 Date: Tue, 9 Oct 90 18:46:31 -0500 Message-Id: <9010092346.AA29384@ftp.com> To: fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca Subject: Re: Reply to Re: Ethernet Address Uniqueness... 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 This is a standard gotcha of using protocols that change the address. There is no solution other than to make sure that DECNet is always started before anything else that cares about the Ethernet address. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100913352900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 9 Oct 90 18:23:06 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA18605; Tue, 9 Oct 90 18:16: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: 9 Oct 90 13:35:29 GMT From: usenet.ins.cwru.edu!po.CWRU.Edu!cjs@tut.cis.ohio-state.edu (Christopher J. Seline) Organization: Case Western Reserve University, Cleveland, Ohio, (USA) Subject: How do I make 'calls' to Standford TCPIP for the PC Message-Id: <1990Oct9.133529.21465@usenet.ins.cwru.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi, We've got Stanford's PC TCPIP software on our PCs. Is there some type of standard for placing calls to it? thanks in advance, cjs@cwru.cwru.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100913440600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 10 Oct 90 02:53:55 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12612; Wed, 10 Oct 90 02:52: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: 9 Oct 90 13:44:06 GMT From: sun-barr!newstop!texsun!letni!mic!supernet!gtoye@decwrl.dec.com (Gene Toye) Organization: Harris Adacom Corporation Subject: Info on TN3270 Protocol Message-Id: <1990Oct9.134406.5185@supernet.haus.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does anyone know where I can get a specification for the protocol used by TN3270 for communicating with the IBM host/controller? I specifically mean the protocol for data to/from the TN3270 application, not SNA or 3270 Data Stream. Thanks for your assistance. -- Gene Toye: Harris Adacom Corporation / 16001 Dallas Pkwy. / Dallas, TX 75248 Internet: gtoye@supernet.haus.com or gtoye@supernet.lonestar.org Usenet: uunet!{iex,ntvax}!supernet!gtoye DISCLAIMER: My employer never knows what I am going to say next. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010091715.AA05649@ucbvax.Berkeley.EDU] <1990100914540100> From: PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD) Newsgroups: comp.protocols.tcp-ip Subject: in-addr.arpa used? Message-ID: <9010091715.AA05649@ucbvax.Berkeley.EDU> Date: 9 Oct 90 14:54:01 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 48 Posted: Tue Oct 9 15:54:01 1990 Our name server, on a VM system, receives reverse mapping queries. One reason found is mailing on Unix systems, that also produces other strange requests (sendmail.mx on SunOS, see below). I am wondering how many such requests will come from the Internet when we will be connected. So, my question is: how useful is it to ask our administrators to implement their in-addr.arpa domains? Is it usually done? Andr'e PIRARD SEGI, Univ. de Li`ege B26 - Sart Tilman B-4000 Li`ege 1 (Belgium) pirard@vm1.ulg.ac.be or PIRARD@BLIULG11 on EARN/BITNET Received: from BLIULG11 by BLIULG11 (Mailer R2.07) with BSMTP id 5355; Tue, 09 Oct 90 15:49:11 +0100 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP R1.2.2MX) with TCP; Tue, 09 Oct 90 15:49:09 +01 Received: from rib1 ([139.165.8.17]) by montefiore.ulg.ac.be (4.0/SMI-4.0) id AA08359; Tue, 9 Oct 90 15:49:38 +0100 Received: by rib1 (4.0/SMI-4.0) id AA06469; Tue, 9 Oct 90 15:49:26 +0100 Date: Tue, 9 Oct 90 15:49:26 +0100 From: pirard@montefiore.ulg.ac.be (PIRARD ANDRE tel 4932 SEGI) Message-Id: <9010091449.AA06469@rib1> To: pirard@vm1.ulg.ac.be datagram from 139.165.16.1 port 2013, fd 8, len 43 req: nlookup(17.8.165.139.in-addr.arpa) id 2 type=12 req: missed '17.8.165.139.in-addr.arpa' as '' (cname=0) forw: forw -> 139.165.2.1 8 (53) nsid=80 id=2 3225ms retry 6 sec datagram from 139.165.2.1 port 53, fd 8, len 43 send_msg -> 139.165.16.1 (UDP 11 2013) id=2 datagram from 139.165.16.1 port 2014, fd 8, len 42 req: nlookup(vm1.montefiore.ulg.ac.be) id 3 type=1 req: found 'vm1.montefiore.ulg.ac.be' as 'vm1.montefiore.ulg.ac.be' (cname=0) req: answer -> 139.165.16.1 11 (2014) id=3 Local datagram from 139.165.16.1 port 2015, fd 8, len 31 req: nlookup(vm1.ulg.ac.be) id 4 type=1 req: found 'vm1.ulg.ac.be' as 'vm1.ulg.ac.be' (cname=0) req: answer -> 139.165.16.1 11 (2015) id=4 Local datagram from 139.165.16.1 port 2016, fd 8, len 31 req: nlookup(vm1.ulg.ac.be) id 5 type=15 req: found 'vm1.ulg.ac.be' as 'vm1.ulg.ac.be' (cname=0) req: answer -> 139.165.16.1 11 (2016) id=5 Local ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100917340100> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Tue, 9 Oct 90 08:47:00 PDT Received: from BLIULG11 by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 3380; Tue, 09 Oct 90 11:45:24 EDT Received: from vm1.ulg.ac.be by BLIULG11 (Mailer R2.07) with BSMTP id 5397; Tue, 09 Oct 90 16:35:44 +0100 Date: Tue, 09 Oct 90 15:54:01 +0100 From: Andr'e PIRARD Subject: in-addr.arpa used? To: tcp-ip@nic.ddn.mil, IBM TCP/IP List Our name server, on a VM system, receives reverse mapping queries. One reason found is mailing on Unix systems, that also produces other strange requests (sendmail.mx on SunOS, see below). I am wondering how many such requests will come from the Internet when we will be connected. So, my question is: how useful is it to ask our administrators to implement their in-addr.arpa domains? Is it usually done? Andr'e PIRARD SEGI, Univ. de Li`ege B26 - Sart Tilman B-4000 Li`ege 1 (Belgium) pirard@vm1.ulg.ac.be or PIRARD@BLIULG11 on EARN/BITNET Received: from BLIULG11 by BLIULG11 (Mailer R2.07) with BSMTP id 5355; Tue, 09 Oct 90 15:49:11 +0100 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP R1.2.2MX) with TCP; Tue, 09 Oct 90 15:49:09 +01 Received: from rib1 ([139.165.8.17]) by montefiore.ulg.ac.be (4.0/SMI-4.0) id AA08359; Tue, 9 Oct 90 15:49:38 +0100 Received: by rib1 (4.0/SMI-4.0) id AA06469; Tue, 9 Oct 90 15:49:26 +0100 Date: Tue, 9 Oct 90 15:49:26 +0100 From: pirard@montefiore.ulg.ac.be (PIRARD ANDRE tel 4932 SEGI) Message-Id: <9010091449.AA06469@rib1> To: pirard@vm1.ulg.ac.be datagram from 139.165.16.1 port 2013, fd 8, len 43 req: nlookup(17.8.165.139.in-addr.arpa) id 2 type=12 req: missed '17.8.165.139.in-addr.arpa' as '' (cname=0) forw: forw -> 139.165.2.1 8 (53) nsid=80 id=2 3225ms retry 6 sec datagram from 139.165.2.1 port 53, fd 8, len 43 send_msg -> 139.165.16.1 (UDP 11 2013) id=2 datagram from 139.165.16.1 port 2014, fd 8, len 42 req: nlookup(vm1.montefiore.ulg.ac.be) id 3 type=1 req: found 'vm1.montefiore.ulg.ac.be' as 'vm1.montefiore.ulg.ac.be' (cname=0) req: answer -> 139.165.16.1 11 (2014) id=3 Local datagram from 139.165.16.1 port 2015, fd 8, len 31 req: nlookup(vm1.ulg.ac.be) id 4 type=1 req: found 'vm1.ulg.ac.be' as 'vm1.ulg.ac.be' (cname=0) req: answer -> 139.165.16.1 11 (2015) id=4 Local datagram from 139.165.16.1 port 2016, fd 8, len 31 req: nlookup(vm1.ulg.ac.be) id 5 type=15 req: found 'vm1.ulg.ac.be' as 'vm1.ulg.ac.be' (cname=0) req: answer -> 139.165.16.1 11 (2016) id=5 Local ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100918443100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 9 Oct 90 20:24:10 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25194; Tue, 9 Oct 90 20:18: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: 9 Oct 90 18:44:31 GMT From: maytag!focsys!larry@iuvax.cs.indiana.edu (Larry Williamson) Organization: Focus Automation Systems Inc. Waterloo, Ontario. Subject: telnet & rlogin set /dev/ttyp* mod differently Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil people that rlogin to machines here have their /dev/ttp* entries mod's set differently. In particular, if one telnets, then /dev/ttyp* is set with mod 111, whereas if one logs in with rlogin, then it is set 666. Why is this? How can I define what the setting should be? I don't want to put chmod commands in /etc/profile or the user's profiles. the systems involved here are Interactive's 386/ix 2.2. Rlogins and telnets are from many different types of machines and terminal servers. -Larry ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010092136.AA09846@ucbvax.Berkeley.EDU] <1990100920151300> From: DANIEL@UIUCVMD Newsgroups: comp.protocols.tcp-ip Subject: .netrc equivalent Message-ID: <9010092136.AA09846@ucbvax.Berkeley.EDU> Date: 9 Oct 90 20:15:13 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Posted: Tue Oct 9 21:15:13 1990 I'm porting an UNIX/VMS TCP/IP based application written in C to VM/CMS. This application normally refers to the .netrc file to get password information. Are there any convensions on CMS for the equivalent? Also, the program does not like to send the password across the net in clear text so it calls the standard UNIX crypt command to do the DES encryption of the password. Is the DES encription available on VM/CMS systems if I don't own the standard IBM box to do this? What is the standard calling procedure for programs using an IBM DES configuration? -- Daniel Pommert pommert@uiuc.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100920280200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 9 Oct 90 22:57:33 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02739; Tue, 9 Oct 90 22:41: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: 9 Oct 90 20:28:02 GMT From: mcsun!ukc!dcl-cs!aber-cs!athene!pcg@uunet.uu.net (Piercarlo Grandi) Organization: Coleg Prifysgol Cymru Subject: Re: What is a UNIX Domain Socket? Message-Id: References: <82@unigold.UUCP>, <1990Sep27.180632.25841@dg-rtp.dg.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil On 27 Sep 90 18:06:32 GMT, harvey@dg-rtp.dg.com (Michael Harvey) said: harvey> In article <82@unigold.UUCP>, lance@unigold.UUCP (Lance harvey> Ellinghouse) writes: lance> Ok, I know this is a dumb question.. What exactly is a Unix lance> Domain Socket? What makes it different from a INET Socket? harvey> A socket is simply a communication endpoint. Sockets support harvey> two communications domains: the UNIX domain for harvey> process-to-process communication on the same host, and the harvey> Internet domain for process-to-process communication between harvey> hosts that communicate with one another using the DARPA standard harvey> communication protocols, such as IP, TCP, and UDP. harvey> In the UNIX domain, socket names are UNIX pathnames; harvey> for example, a socket may be named /tmp/foo. harvey> Naming sockets in the Internet domain involve concatenating harvey> the Internet address with a port number. harvey> I think that covers the basics. Comments? I think I can do better :-). Under Unix all out-of-address space communication (except for ptrace(2) and signals) is via file descriptors; file descriptors have a common interface, based on read/write readv/writev, and ioctl(), etc..., and a type. One of the types of a file descriptor is socket; when a file descriptor is a socket, it is attached using a full duplex channel to another socket file descriptor somewhere. Socket file descriptors have a number of properties that normal file descriptors do not have; among these are the type of communication (stream, message, etc...), an identifier, two modes of connecting a socket to another for transmitting data, and whether there is the possibility to transmit file descriptors over the channel. Socket file descriptors are supported by a a set of protocol implementations called a 'domain'; only sockets in the same domain may be connected. The UNIX domain is a domain where there is only one socket type, only one protocol, the pipe protocol, where the only socket type allowed is stream, where socket identifiers are pathnames in the UNIX filesystem, and where filedescriptors may be passed thru the communication channel between two sockets. By contrast the INET domain supports three socket types (stream, datagram and raw), a number of protocols, socket identifiers are internet 32 bit numbers, and filedescriptors may not be passed thru the channel between two sockets. Many other domains exist. In the original 4.2BSD design it was to be possible to have user processes implement domains, by putting the protocol code in the user process, and having all communications between two sockets in that user domain be interepted by the user process implementing that domain. This is still possible by using the UNIX domain, even if in a contrived way (in particular it is not possible to support other than stream sockets), by having users for that domain connect in the UNIX domain to the user implemented domain server, that would return a socket in that domain (actually a socket to itself, usually, in the UNIX domain). -- 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---- <1990100921290500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 9 Oct 90 23:10:15 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03829; Tue, 9 Oct 90 23:04: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: 9 Oct 90 21:29:05 GMT From: elroy.jpl.nasa.gov!aero!obrien@decwrl.dec.com (Michael O'Brien) Organization: The Aerospace Corporation Subject: Use of TCP/IP with satellite delays Message-Id: <88084@aerospace.AERO.ORG> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Someone recently asked a question about use of TCP/IP over a satellite link, and since I've never worked in that realm, the ground got mushy under my feet. I'd like a reality check. I seem to recall that TCP/IP is perfectly usable over a satellite link that has reasonably high bandwidth, but 300msec propagation delays. Adaptive retransmission and multi-packet frames get around this problem, no? Of course, char-at-a-time telnet will lose no matter what, but mail and file transfers should move acceptably, right? More specifically I'm talking about something like a KA9Q implementation running via satellite radio link from a research vessel at sea. -- Mike O'Brien obrien@aerospace.aero.org ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100921530600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 9 Oct 90 22:26:43 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01333; Tue, 9 Oct 90 22:10: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: 9 Oct 90 21:53:06 GMT From: mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu (Bob Sutterfield) Organization: Morning Star Technologies Subject: Re: in-addr.arpa used? Message-Id: References: <9010091715.AA05649@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010091715.AA05649@ucbvax.Berkeley.EDU> PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD) writes: ...how useful is it to ask our administrators to implement their in-addr.arpa domains? Is it usually done? See RFC1123 ("Requirements for Internet Hosts -- Application and Support"), section 6.1.1: Every host MUST implement a resolver for the Domain Name System (DNS), and it MUST implement a mechanism using this DNS resolver to convert host names to IP addresses and vice-versa [DNS:1, DNS:2]. Yes, it's very useful. It's usually done. Addresses for which reverse mapping is not maintained are not in conformance to the applicable standards, and should receive a firm finger-wagging. If your local administrators hesitate, bash them over the head with a printed copy of RFC1123, all 98 pages. Hmmm, I just noticed upon closer reading that this requirement only applies to the resolver that must be available on each host. It doesn't say that an authoritative reverse mapping must be available (from some name server somewhere) for every address. So bash them gently, if you must :-) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100922184300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 9 Oct 90 22:30:43 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01761; Tue, 9 Oct 90 22:19: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: 9 Oct 90 22:18:43 GMT From: ubc-cs!news-server.csri.toronto.edu!utgpu!cunews!bnrgate!bwdls56!fortinp@beaver.cs.washington.edu (Pierre Fortin) Organization: Bell-Northern Research, Ltd. Ottawa Ontario CANADA Subject: Re: SLIP, IP Routers and Named Pipes Message-Id: <1990Oct9.221843.20145@bnrgate.bnr.ca> References: <1990Oct6.033237.27399@cs.umn.edu>, <12628063537.11.BILLW@mathom.cisco.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <12628063537.11.BILLW@mathom.cisco.com>, BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes: > > Does anyone know of a product that supports [cslip]? SLIP is > sssoooo easy to configure slip on an Annex. It seems like a shame > to waste it, but ftp and telnet are so gawdawfully slow even over > a 38.4k link that I still resist putting it in place. > > Really? FTP is slow? Our experience at cisco (with our own terminal > servers, of course) was that FTP was quite zippy - the sliding window > of TCP bought you much more than you lost from the big headers. Compared > to DEC-20 to PC kermit, FTP's FTP over slip was nearly twice as fast. Care to share the test configuration with us? I use SLIP over a Microcom AX/9624c MNP Class 6 modem and a cisco terminal server. I see the modem lights grinding away, waiting..., grinding away, waiting..., etc. It's almost as though the VJ algorithms were throttling... I found I could get more files through by starting 2-3 FTPs so that one is still running when the other 1-2 are stalled. Sort of round-robin FTP transfers; doesn't work if I've only got one file to transfer though... :^( > > Telnet, however, was quite painful, and I don't even want to think about > running telnet and FTP at the same time. When you're FTPing and your only link is tied up, you're quite happy to be able to get *any* response to keep working. If only I had what ammounts to "local echo" or tn3270-type buffering on telnet over SLIP... sigh. > > BillW > ------- Pierre Fortin Bell-Northern Research I know, my postings are Internet Systems P.O.Box 3511, Stn C terse and humourless. So? (613)763-2598 Ottawa, Ontario RIP: aptly named protocol fortinp@bnr.ca Canada K1Y 4H7 AppleTalk: Adam&Eve's design ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100922583600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 9 Oct 90 22:26:50 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01834; Tue, 9 Oct 90 22:21: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: 9 Oct 90 22:58:36 GMT From: apple.com!erekose@apple.com (Erik Scheelke) Organization: Apple Computer Inc, Cupertino, CA Subject: File Broadcast Message-Id: <45509@apple.Apple.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We have a local area network of UNIX based PCs running TCP-IP, and I was asked if there was any software that will broadcast a file to all machines on the network. I didn't know of any and was wondering if anyone out there in netland knew of any. If not, I guess I will have to write something myself. I would appreciate any infomation about programs or algorithms that do file broadcasting. It must use a broadcast, not a copy to one machine then copy to another method (i.e. UDP), and if a machine is up it must reliably send the file. Thanks in advance for any help! Erik Scheelke ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100923115100> Received: from WLV.IMSD.CONTEL.COM by NIC.DDN.MIL with TCP; Wed, 10 Oct 90 10:52:54 PDT Received: by WLV.IMSD.CONTEL.COM (5.64/1.25) id AA08638; Wed, 10 Oct 90 10:51:51 -0700 Date: Wed, 10 Oct 90 10:51:51 -0700 From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) Message-Id: <9010101751.AA08638@WLV.IMSD.CONTEL.COM> To: elroy.jpl.nasa.gov!aero!obrien@decwrl.dec.com, tcp-ip@nic.ddn.mil Subject: Re: Use of TCP/IP with satellite delays It works fine. TELNET on the other hand is something of a pain. I have done a TELNET connection between Stuttgart-Vaihingen, FRG and Westlake Village CA (LA area) with two satellite hops and a 9600 baud link between Westlake and Marina Del Rey. Found you forget what you typed and can almost go out- side for a smoke waiting for the echo. Merton ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990100923165400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 9 Oct 90 17:25:45 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15650; Tue, 9 Oct 90 17:15: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: 9 Oct 90 23:16:54 GMT From: spdcc!dyer@husc6.harvard.edu (Steve Dyer) Organization: S.P. Dyer Computer Consulting, Cambridge MA Subject: Bad SLIP performance (was Re: SLIP, IP Routers and Named Pipes) Message-Id: <4401@spdcc.SPDCC.COM> References: <1990Oct6.033237.27399@cs.umn.edu>, <12628063537.11.BILLW@mathom.cisco.com>, <1990Oct9.221843.20145@bnrgate.bnr.ca> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I think your problems are more to do with the nature of your modems than any inherent problems with medium speed SLIP links. I lived for two years quite happily with a LADS circuit supporting a full time point-to-point SLIP connection running at 19.2kb. No fancy modems, just a pair of local data sets. 19.2kb SLIP is subjectively quite reasonable, and I found that even on a heavily loaded line supporting NNTP, a couple of telnet/rlogin sessions, regular SMTP traffic and the occasional FTP, the delay wasn't all THAT bad. All bets are off when you start talking about pseudo-full-duplex modems like Telebit Trailblazers or MNP6, or noisy lines or lossy serial interfaces. But let's identify *these* as potential areas of problems, and not tar the underlying technology unjustly. -- 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---- <1990101003162600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 9 Oct 90 23:08:32 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03322; Tue, 9 Oct 90 22:53: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: 10 Oct 90 03:16:26 GMT From: brunix!euclid.math.temple.edu!freedman@uunet.uu.net (Avi Freedman) Organization: Math Department, Temple University, Philadelphia Subject: Can I use the Berkeley lp protocol for remote DOS prints from COM1? Message-Id: <52631@brunix.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I've got NCSA telnet configured and printing remotely off of a Sun, but is there any commercial/pd program out there which lets me trap what goes to com1/com2/prn from an application? (I've got an application which can't print to a file). Any pointers would be greatly appreciated. - Avi ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101005244400> Received: from mathom.cisco.com by NIC.DDN.MIL with TCP; Wed, 10 Oct 90 12:27:08 PDT Date: Wed 10 Oct 90 12:24:44-PDT From: William "Chops" Westfield Subject: Re: SLIP, IP Routers and Named Pipes To: fortinp@bnr.ca cc: tcp-ip@nic.ddn.mil In-Reply-To: <1990Oct9.221843.20145@bnrgate.bnr.ca> Message-ID: <12628737090.25.BILLW@mathom.cisco.com> > > Really? FTP is slow? Our experience at cisco (with our own terminal > servers, of course) was that FTP was quite zippy - the sliding window > of TCP bought you much more than you lost from the big headers. Compared > to DEC-20 to PC kermit, FTP's FTP over slip was nearly twice as fast. Care to share the test configuration with us? I use SLIP over a Microcom AX/9624c MNP Class 6 modem and a cisco terminal server. I see the modem lights grinding away, waiting..., grinding away, waiting..., etc. It's almost as though the VJ algorithms were throttling... I found I could get more files through by starting 2-3 FTPs so that one is still running when the other 1-2 are stalled. Sort of round-robin FTP transfers; doesn't work if I've only got one file to transfer though... :^( The configuration was a 286 based PC clone running either (old, non-sliding window, 92 byte packet) MSDOS kermit or FTP software's package v 1.16, connected vai a 19.2kbps direct line to aa cisco terminal server (v6.1 software? This was slightly before SLIP was released on the cisco TS) We were talking to either HPUX or TOPS20 (no VJ algorthims in sight!) FTP software was configured with a window size of 1024, and an MSS of 512, if I remember correctly. It's sort of important (with no slow start) that the number of MSS packets in a window be both larger than 1 and smaller than the effective queue-size on the terminal server (then 3, now settable). (Your description of the problem sounds exactly like the MSS is > window/2, so that you end up operating lock-step instead of sliding windows, by the time SWS algorithms come into play.) FTP file transfer speeds were about 13kbps, while kermit was about half that. I haven't done those tests in a couple of years, though - I would hope that everything still works at least as well as it did then! Bill Westfield cisco Systems. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101006044000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 10 Oct 90 02:39:11 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12141; Wed, 10 Oct 90 02:36: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: 10 Oct 90 06:04:40 GMT From: cbmvax!grr@uunet.uu.net (George Robbins) Organization: Commodore, West Chester, PA Subject: Re: is syslog(3) to remote possible? Message-Id: <15020@cbmvax.commodore.com> References: <111@fedeva.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <111@fedeva.UUCP> bill@fedeva.UUCP (Bill Daniels) writes: > I posted a similar request about a week or two ago. Just as luck would > have it my news machine went away for a couple of days right afterwards. > > I have need to log operator messages via syslog(3) on a remote machine. I > am sure that this is possible because of the way the docs and headers read. > It seems however that Ultrix has coded up syslog() so that all messages go > to the local machine. The Ultrix syslog seems to be able to capture and display remote syslog messages, but doesn't seem to be able to direct it's own messages to another system. Other people have claimed that the BSD 4.3 syslog stuff is easy to get working with Ultrix, but I haven't tried it (yet). Note that having Ultrix syslog capture messages originating from a Sun system results in a ugly syslog file, apparently there is some format divergence. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101006292600> Received: from mazatzal.merit.edu by NIC.DDN.MIL with TCP; Wed, 10 Oct 90 07:31:09 PDT Received: Wed, 10 Oct 90 10:29:26 EDT by mazatzal.merit.edu (5.51/1.6) Date: Wed, 10 Oct 90 10:29:26 EDT From: Chris Weider Message-Id: <9010101429.AA15374@mazatzal.merit.edu> To: system@lns61.tn.cornell.edu, tcp-ip@nic.ddn.mil Subject: re: Reply to Ethernet Address Uniqueness... In a recent message (10/5), Selden E. Ball, Jr. states that: >Of course, the fact that DECnet addresses are limited to 16 bits >means that larger networks are limited to a maximum of about 64K >systems. My guess is that there are fewer than a dozen networks >for which this causes problems. I think this estimate is conservative. :) On CICNet, we've had to jerry-rig our routers to get a true heirarchical DECNet architechture; I suspect that a lot of other regionals have had to also. I'm eagerly awaiting DECnet Phase 5. Chris Weider ----------------------------------------------------------------------------- Chris Weider | -Geteilte Freude ist MERIT's CICNet Technical Rep. | doppelte Freude email: clw@merit.edu | -Goethe Phone: (313) 936-2090 or | -Party on, dudes! 1-800-66-MERIT | -Abraham Lincoln, "Bill and Ted" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101013545800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 10 Oct 90 07:10:21 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21653; Wed, 10 Oct 90 07:08: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: 10 Oct 90 13:54:58 GMT From: mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu (Bob Sutterfield) Organization: Morning Star Technologies Subject: Re: Bad SLIP performance (was Re: SLIP, IP Routers and Named Pipes) Message-Id: References: <1990Oct6.033237.27399@cs.umn.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <4401@spdcc.SPDCC.COM> dyer@spdcc.COM (Steve Dyer) writes: All bets are off when you start talking about pseudo-full-duplex modems like Telebit Trailblazers or MNP6, or noisy lines or lossy serial interfaces. But let's identify *these* as potential areas of problems, and not tar the underlying technology unjustly. We see very reasonable performance with compressed-header SLIP or PPP between Sun-4/60s over a pair or Trailblazer Plusses: 1.3-1.5Kb/sec FTP throughput with PPP, nearing the modem's advertised pipe diameter. Interactive response OK too, though not what you'd call "pleasant" if you're used to fatter hoses. I haven't tried high values of MNP or HST. Don't bother with Classic SLIP, particularly not with TBs. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101016364600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 10 Oct 90 10:55:19 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA28290; Wed, 10 Oct 90 10:47: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: 10 Oct 90 16:36:46 GMT From: clyde.concordia.ca!news-server.csri.toronto.edu!utgpu!cunews!mentor.gandalf.ca!ddrg@uunet.uu.net (Duncan Glendinning) Organization: Gandalf Data Ltd., Nepean, Ontario, Canada Subject: Re: Use of TCP/IP with satellite delays Message-Id: <1990Oct10.163646.3709@mentor.gandalf.ca> References: <88084@aerospace.AERO.ORG> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <88084@aerospace.AERO.ORG> obrien@aero.aero.org (Michael O'Brien) writes: >Someone recently asked a question about use of TCP/IP over a satellite >link, and since I've never worked in that realm, the ground got mushy >under my feet. I'd like a reality check. > >I seem to recall that TCP/IP is perfectly usable over a satellite link >that has reasonably high bandwidth, but 300msec propagation delays. >Adaptive retransmission and multi-packet frames get around this problem, >no? Of course, char-at-a-time telnet will lose no matter what, but >mail and file transfers should move acceptably, right? > >More specifically I'm talking about something like a KA9Q implementation >running via satellite radio link from a research vessel at sea. >-- >Mike O'Brien >obrien@aerospace.aero.org We've successfully run SLIP over a satelite link between our offices here in Ottawa, and both Wheeling IL, and Warrington UK. Though a bit slow for interactive use (9600 baud) it was possible. The primary use was for large (>1M byte) file transfers, where we saw better throughput than kermit. Here are some results: Wheeling IL to Ottawa Ont: file size: 2744320 bytes ftp: 76 min kermit: 995 min Please note that the 9600 baud channel is just one of a number that are stat muxed. -- Duncan Glendinning CAnet: ddrg@mentor.gandalf.ca, ddrg@gandalf.ca Gandalf Data Ltd. Voice: (613) 723-6500 Nepean, Ontario Fax: (613) 226-1717 Canada K2E 7M4 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101017110200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 10 Oct 90 11:56:00 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29775; Wed, 10 Oct 90 11:40: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: 10 Oct 90 17:11:02 GMT From: psuvm!drj100@psuvax1.cs.psu.edu (Daniel R. Jeuch) Organization: Penn State University Subject: Re: Bad SLIP performance (was Re: SLIP, IP Routers and Named Pipes) Message-Id: <90283.131102DRJ100@psuvm.psu.edu> References: <1990Oct6.033237.27399@cs.umn.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article , bob@MorningStar.Com (Bob Sutterfield) says: > >We see very reasonable performance with compressed-header SLIP or PPP >between Sun-4/60s over a pair or Trailblazer Plusses: 1.3-1.5Kb/sec >FTP throughput with PPP, nearing the modem's advertised pipe diameter. >Interactive response OK too, though not what you'd call "pleasant" if >you're used to fatter hoses. I haven't tried high values of MNP or >HST. > >Don't bother with Classic SLIP, particularly not with TBs. Unfortunately, here at Penn State, all we have is MNP5 9600 V.32 dial-in lines... I get throughput with classic SLIP (PSU also doesn't use compression) of somewhere between .8-.9kb/sec. Not great, but it's free for Penn State students... (Kind of important for my budget!) TN3270 does suffer, though! ----- Daniel R. Jeuch Microsoft Corp. Student Rep. 10 Vario Blvd., Box 185 DRJ100@PSUVM, drj100@psuvm.psu.edu State College, PA 16803 (814) 867-4622, (800) 232-5129 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101018002200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 10 Oct 90 11:09:33 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA28666; Wed, 10 Oct 90 11:01: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: 10 Oct 90 18:00:22 GMT From: timbuk!redwood22!nrd@uunet.uu.net (Neal Dalton) Organization: Cray Research, inc. Subject: I there a Compressed SLIP for Sun OS 4.1 Message-Id: <124830.20231@timbuk.cray.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I've seen slip for Sun OS 4.1 and am tring to find out how to implement cslip on Sun OS 4.1 In cslip for Sun OS 4.0 they provided a tty driver modified for compression. Will this work for OS 4.1 or did 4.1 fix the problems with 4.0. -- Neal /\ / _ / \|||/ Neal Dalton / \ / _ _\ / / \ Cray Research, inc / \/_ From: GHOLAN@vm.ucs.UAlberta.CA (Geoffrey Holan) Newsgroups: comp.protocols.appletalk,comp.protocols.tcp-ip Subject: runing ka9q on appletalk Message-ID: <1044@vm.ucs.UAlberta.CA> Date: 10 Oct 90 18:12:47 GMT Reply-To: GHOLAN@vm.ucs.UAlberta.CA Organization: University of Alberta VM/CMS Lines: 9 Posted: Wed Oct 10 19:12:47 1990 Disclaimer: Author bears full responsibility for contents of this article Has anyone got the localtlk packet driver working, this is for use with a ka9q router. I am unable to load-up the correct appletalk drivers for localtlk to talk to. I am using the lsl.com, atalk.com and ltalkp.com, but none of them seem to be the proper driver(s) that localtlk needs to use to talk to the ibm pc appletalk board. I am using the 7 version of Clarkson's packet drivers.. any hints would be appr. thanks ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101019180000> Received: from paxrv-nes.navy.mil by NIC.DDN.MIL with TCP; Wed, 10 Oct 90 23:03:18 PDT Date: 10 Oct 90 23:18:00 EDT From: "SWEIGERT, DAVID" Subject: SNMP Agent by Proxy To: "tcp-ip" From: David Sweigert supporting U.S. Special Operations Command We are trying to find the public domain software for a SNMP package that can run off a PC. We would like to modify the source code to acquire data from a Veristron TCU. Anyone know where we can get an SNMP Agent for a PC. ??? po box 4423 annapolis, md 21403 301-637-5098 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101020030700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 12 Oct 90 03:25:30 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19828; Fri, 12 Oct 90 03:12: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: 10 Oct 90 20:03:07 GMT From: pacbell.com!pacbell!dplace!hicom!toshiya@decwrl.dec.com (Toshiya Itoh) Organization: Hitachi Computer Products,Santa Clara,CA Subject: Connectathon?? Message-Id: <2160001@hicom.hitachi.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does anybody know the word "Connectathon?" (may not be right spell) I heard it's the name of a kind of competition of TCP/IP implementations. If it was true, how can I get the information about the result of this competition? Thank you very much in advance, Toshiya Itoh. ========================================================== Software Engineer Hitachi Computer Products Inc. 3101 Tasman Dr. Santa Clara, Ca. 95054 E-mail t_itoh@hitachi.com ========================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101100222500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 11 Oct 90 02:21:29 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16035; Thu, 11 Oct 90 02:15: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: 11 Oct 90 00:22:25 GMT From: munnari.oz.au!metro!natmlab.dap.csiro.au!megadata!andrew@uunet.uu.net (Andrew McRae) Organization: Megadata P/L, North Ryde, Sydney, Aust. Subject: Looking for in_cksum for 68k. Message-Id: <347@megadata.mega.oz.au> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does anyone have a 68000 specific in_cksum routine for doing IP checksums? I have been using the machine independent version, but I have looked at the VAX and CCI routines that came with the 4.3 BSD network source, and it seems it would be a big win to have a 68k version. I am actually running a 68000 rather than a 68020, but a 68020 version would be useful as a starting point. Thanks! 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---- <1990101103143300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 11 Oct 90 13:12:16 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00922; Thu, 11 Oct 90 12:47: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 Oct 90 03:14:33 GMT From: pyrdc!pyrnj!bartal!monymsys!sonyd1.Broadcast.Sony.COM!blilly.UUCP!balilly.UUCP!bruce@uunet.uu.net (Bruce Lilly) Organization: Bruce Lilly, Flushing, NY Subject: Re: Ethernet Address Uniqueness... Message-Id: <1990Oct11.031433.3032@blilly.UUCP> References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article linegar@bwdls49.bnr.ca (Derick Linegar) writes: > >[ ... ] > Now I've been searching the RFC and IEEE docs and I cannot >find any documentation that sort of says that Ethernet Addresses are assigned >to Ethernet boards, not hosts. > >Anyone have an idea where it might be. I cannot go back to the vendor and >say > > " .... well everyone *knows* that ethernet addresses *must* be unique..." ``For information on global (U) address administration contact the Secretary, IEEE Standards Board, 345 East 47 Street, New York, NY 10017.'' (Footnote on page 26 of ANSI/IEEE Standard 802.3-1985 ISO/DIS 8802/3) My recollection is that each manufacturer is assigned a group of addresses and is expected to make the hardware address unique for each interface. As has been pointed out (for the specific case of DECnet) it is also possible to override the hardware address via software, and that may be a part of your problem. The IEEE Secretary ought to be able to clarify this situation, and may be able to tell you what range of addresses are assigned to your particular vendor. Late flash: after checking several references, I found: ``14.4.2 Ethernet addresses Host computers on Ethernet are identified by two addresses, the Ethernet address (a 48-bit hardware address) and an IP or software address. Ethernet addresses are guaranteed unique because vendors building Ethernet interfaces have a set of addresses assigned to them. The IEEE Standards Board in New York City assigns the first 24 bits to a manufacturer, which then allocates the last 24 bits sequentially. The address is either built into the interface board or stored in ROM on the board.'' (From _UNIX(R)_System_Administration_Handbook_ by Nemeth, Snyder, and Seebass, published by Prentice-Hall, p. 243) An excellent book, by the way, although it is heavily biased toward BSD. Note however that the IEEE standard permits either 16-bit or 48-bit addresses, so don't take that too literally. Hope this helps. -- Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010111259.AA19945@ucbvax.Berkeley.EDU] <1990101103180000> From: dsweigert@PAXRV-NES.NAVY.MIL ("SWEIGERT, DAVID") Newsgroups: comp.protocols.tcp-ip Subject: SNMP Agent by Proxy Message-ID: <9010111259.AA19945@ucbvax.Berkeley.EDU> Date: 11 Oct 90 03:18:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 Posted: Thu Oct 11 04:18:00 1990 From: David Sweigert supporting U.S. Special Operations Command We are trying to find the public domain software for a SNMP package that can run off a PC. We would like to modify the source code to acquire data from a Veristron TCU. Anyone know where we can get an SNMP Agent for a PC. ??? po box 4423 annapolis, md 21403 301-637-5098 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101104140000> Received: from tawc1.eglin.af.mil by NIC.DDN.MIL with TCP; Thu, 11 Oct 90 07:20:53 PDT Date: 11 Oct 90 09:14:00 CDT From: "Nunez, Paul" Subject: Need SMB Info To: "tcp-ip" I need information on SMB. I've seen it referred to as both Server Message Block protocol and Server Management Block protocol - which is correct? Where can I get more information on what it is and how it works? Also, would those of you running in an SMB client/server environment please pass on information concerning your server product (Company names, phone numbers, problems, etc.). I am especially interested in a comparison of Wollongong's SMB server product vs. Syntax's. Someone told me Syntax's product (name unknown) is licensed by Wollongong (is OEM'd the correct term?). Is this true? We have 6 uVAX 3600's running VMS 5.3-1 and Wollongong's WIN/TCP for VMS V5.1. Please reply to me directly; I'll summarize and post if enough interest. Thanks, ======================================================================= PAUL E. NUNEZ (nunez@tawc1.eglin.af.mil) or (nunez@uv4.eglin.af.mil) USAFTAWC/SCAM EGLIN AFB, FL 32542 (904-882-4100) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101107414100> Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Thu, 11 Oct 90 08:43:42 PDT Received: from interlan.interlan.com by RELAY.CS.NET id aa24653; 11 Oct 90 11:43 EDT Received: from europa.InterLan.COM by interlan.interlan.com (5.61/5.17) id AA12632; Thu, 11 Oct 90 11:41:20 -0400 Received: by europa.Interlan.COM (4.0/SMI-4.0) id AA00944; Thu, 11 Oct 90 11:41:41 EDT Date: Thu, 11 Oct 90 11:41:41 EDT From: Frank Kastenholz Message-Id: <9010111541.AA00944@europa.Interlan.COM> To: munnari.oz.au!metro!natmlab.dap.csiro.au!megadata!andrew@UUNET.UU.NET, tcp-ip@NIC.DDN.MIL Subject: Re: Looking for in_cksum for 68k. > > Does anyone have a 68000 specific in_cksum routine for > doing IP checksums? > > I have been using the machine independent version, > but I have looked at the VAX and CCI routines that came > with the 4.3 BSD network source, and it seems it would be > a big win to have a 68k version. I am actually running a > 68000 rather than a 68020, but a 68020 version would be > useful as a starting point. Look at RFC 1071.... 1071 Braden, R.T.; Borman, D.A.; Partridge, C. Computing the Internet checksum. 1988 September; 24 p. (Format: TXT=54941 bytes) (Updated by RFC 1141) Frank Kastenholz Racal Interlan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101107592600> Received: from nmdsc20.nmdsc.nnmc.navy.mil by NIC.DDN.MIL with TCP; Thu, 11 Oct 90 09:01:28 PDT Received: by nmdsc20.nmdsc.nnmc.navy.mil (5.59/25-eef) id AA08428; Thu, 11 Oct 90 11:59:26 EDT Date: Thu, 11 Oct 90 11:59:26 EDT From: Bob Stratton Message-Id: <9010111559.AA08428@nmdsc20.nmdsc.nnmc.navy.mil> To: TCP-IP@NIC.DDN.MIL Subject: traceroute on 3B2/600 under TWG's TCP/IP Hello all, I am in the process of porting traceroute to an AT&T 3B2/600 with the AT&T Enhanced WIN/3B TCP/IP software from Wollongong. Will the IPPROTO_RAW work as delivered? I noticed that the docs for traceroute indicate a mod to the BSD kernel's raw IP output routine is required, but I have no clue as to whether the same is true for System V/3.2.2. On execution, I get SO_SNDBUF: Bad protocol option, which would lead me to believe that there is some lower-lever work needed. Of course, if I #undef SO_SNDBUF, the code runs, but all I see are lines with "* * *". Failing that, does anyone know where I might find a version of traceroute already written for System V machines? Thanks in advance! Bob Stratton | dsc3rjs@nmdsc20.nmdsc.nnmc.navy.mil [DDN/Internet] NAVMEDATASERVCEN | dsc3rjs@vmnmdsc [BITNET] (Innova Comms. / AT&T) | 295-3371 [AV] +1 301 295 3371 [PSTNet] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101110211800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 11 Oct 90 08:06:52 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22865; Thu, 11 Oct 90 07:57: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: 11 Oct 90 10:21:18 GMT From: mcsun!i2unix!alessia!athena@uunet.uu.net (Matteo Frigo) Organization: DEI Padova University Subject: Strange bahaviour of an LSX3020 with tcp protocol Message-Id: <6610@alessia.dei.unipd.it> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have an Olivetti LSX3020 with Ethernet card, 8Mb ram and 280MB hard disk. I am on Internet. I have this problem: I can connect to Europe from here (Padova, Italy) and and to East Coast (NY and Boston), but I cannot have any tcp service from Berkeley, ucsd and so on. Next to the LSX I have a Sun 3 which works and has no problem in telnetting and ftp-ing to the entire world. I suspect it is a problem of timeouts, but I have absolutely no idea of where to put my hands on. I noted the machine worked before the new link between CNUCE and SURA, and in some moments it works again for a few minutes. Any help would be appreciated. I am quite disperate because the LSX acts as nameserver and mail exchanger for the domain dei.unipd.it, as other machines cannot be used for that for technical and administrative reasons, and my system has stopped working with no apparent reason. Matteo Frigo athena@alessia.dei.unipd.it ( try to reply with athena%alessia.dei.unipd.it@mcsun.eu.net because of these problems) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101113352500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 11 Oct 90 07:06:24 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21172; Thu, 11 Oct 90 06:54: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: 11 Oct 90 13:35:25 GMT From: van-bc!ubc-cs!news-server.csri.toronto.edu!utgpu!cunews!bnrgate!bwdlh131!mleech@ucbvax.Berkeley.EDU (Marcus Leech) Organization: Bell-Northern Research, Ltd. Ottawa Ontario CANADA Subject: Re: Use of TCP/IP with satellite delays Message-Id: <1990Oct11.133525.12689@bnrgate.bnr.ca> References: <88084@aerospace.AERO.ORG> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <88084@aerospace.AERO.ORG>, obrien@aero.aero.org (Michael O'Brien) writes: > More specifically I'm talking about something like a KA9Q implementation > running via satellite radio link from a research vessel at sea. KA9Q works very well in this type of environment--Phils round-trip-timer algorithm is generally acknowledged to be the best in the business. It's quite accurate, and converges quickly. I've used KA9Q over a satellite link between Ottawa, and Calgary. Provided you have a low BER, you can simply crank up your TCP WINDOW and MSS and expect to get quite good performance for FTP, etc. ----------------- Marcus Leech, 4Y11 Bell-Northern Research |opinions expressed mleech@bnr.ca P.O. Box 3511, Stn. C |are my own, and not VE3MDL@VE3JF.ON.CAN.NA Ottawa, ON, CANADA |necessarily BNRs ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010120148.AA10719@ucbvax.Berkeley.EDU] <1990101114140000> From: nunez@TAWC1.EGLIN.AF.MIL ("Nunez, Paul") Newsgroups: comp.protocols.tcp-ip Subject: Need SMB Info Message-ID: <9010120148.AA10719@ucbvax.Berkeley.EDU> Date: 11 Oct 90 14:14:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 19 Posted: Thu Oct 11 15:14:00 1990 I need information on SMB. I've seen it referred to as both Server Message Block protocol and Server Management Block protocol - which is correct? Where can I get more information on what it is and how it works? Also, would those of you running in an SMB client/server environment please pass on information concerning your server product (Company names, phone numbers, problems, etc.). I am especially interested in a comparison of Wollongong's SMB server product vs. Syntax's. Someone told me Syntax's product (name unknown) is licensed by Wollongong (is OEM'd the correct term?). Is this true? We have 6 uVAX 3600's running VMS 5.3-1 and Wollongong's WIN/TCP for VMS V5.1. Please reply to me directly; I'll summarize and post if enough interest. Thanks, ======================================================================= PAUL E. NUNEZ (nunez@tawc1.eglin.af.mil) or (nunez@uv4.eglin.af.mil) USAFTAWC/SCAM EGLIN AFB, FL 32542 (904-882-4100) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101117153400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 11 Oct 90 11:07:32 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27879; Thu, 11 Oct 90 10:57: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: 11 Oct 90 17:15:34 GMT From: usc!cs.utexas.edu!execu!sequoia!cb@ucsd.edu (Christopher D. Brown) Organization: Execucom Systems Corp. Subject: TCP/IP (socket library) for MS Windows 3 Message-Id: <25696@sequoia.execu.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Execucom is building an MS Windows 3.0 software product which supports TCP/IP using the socket library model. Frankly, we were hoping that Sun would have already delivered the supporting network software ... In any case, we need to get on with this aspect of the project and are looking for commercial software supporting TCP/IP via sockets under Windows 3 (including 386 enhanced mode). I am doubtful about using the public domain software so frequently discussed here. This route would seem to require a good deal more technical expertise than a commercial package. A commercial package would also seem to reduce legal difficulties when reselling the software. Is this too conservative? "Network Windows (TM) Software Development Kit" from Distinct Corporation in Saratoga, CA claims to meet my requirements. I would appreciate hearing from anyone who has experience with this product and/or company. Pointers to alternate products would be gratefully accepted. If there appears to be any interest, I post any alternate vendors and product reviews. Thanks in advance. Chris -- Christopher D. Brown Digital: {uunet|cs.utexas.edu}!execu!cb Analog: (512) 327-7070 Physical: Execucom, 108 Wild Basin Road, Two Wild Basin, Austin, TX 78764 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101118184300> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Thu, 11 Oct 90 09:06:18 PDT Received: from VM1.calc.ucl.ac.be by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8125; Thu, 11 Oct 90 12:05:00 EDT Received: by BUCLLN11 (Mailer R2.07) id 2029; Thu, 11 Oct 90 17:04:56 +0100 Date: Thu, 11 Oct 90 16:38:43 +0100 From: "Alain FONTAINE (Postmaster - NAD)" Message-Id: <901011.163843.+0100.af@sei.ucl.ac.be> Subject: Re: Heathkit Weather Computer (IDW5001) To: TCP-IP@NIC.DDN.MIL In-Reply-To: Your message of Wed, 3 Oct 90 16:24:46 GMT On Wed, 3 Oct 90 16:24:46 GMT David M. Siegel said: >would be nice to use a "standard" weather TCP/UDP protocol for this >purpose. Ideally, all Internet sites with weather data could support >this protocol. The protocol should be extensible, since it is hard to >anticipate all types of weather data that people might have. > >I'm wondering, does such a protocol exist? > This question has been discussed some months ago. The conclusion was that no new protocol is needed: this is an ideal application for SNMP. Just define a weather-report MIB.... P.S. I tried a private reply, but it was bounced at uunet..... Alain FONTAINE +--------------------------------+ Universite Catholique de Louvain | If your mail software barks at | Service d'Etudes Informatiques | my address, you may try : | Batiment Pythagore | | Place des Sciences, 4 | FNTA80@BUCLLN11.BITNET | B-1348 Louvain-la-Neuve, BELGIUM +--------------------------------+ phone +32 (10) 47-2625 z * * * 47745578 'Alain FONTAINE (Pos David M. Siegel 10/11/90*Heathkit Weather Computer (IDW ----MESSAGE-END---- ----MESSAGE-BEGIN---- [691@axiom.maths.uq.oz] <1990101123555000> From: jay@axiom.maths.uq.oz.au (Joseph Young) Newsgroups: comp.protocols.appletalk,comp.dcom.lans,comp.protocols.tcp-ip Subject: Mac Access to TCP/IP Keywords: Novell, TCP/IP, ethernet Message-ID: <691@axiom.maths.uq.oz> Date: 11 Oct 90 23:55:50 GMT Followup-To: comp.protocols.appletalk Distribution: comp Organization: Mathematics, Uni of Queensland, Australia Lines: 28 Posted: Fri Oct 12 00:55:50 1990 I'm faced with the following configuration: +-----+ +-----+ ! Mac ! ! IBM ! +--+--+ ! PCs ! ! +--------+ +--+--+ Novell Trunk - LocalTalk ! Novell ! Novell Trunk - Ethernet ! -------------+----------------+ File +----------+-----------------+---> ! Server ! ! +--------+ ! (NetWare 2.15) +--+---+ !Bridge!(Brand: Wellfleet) !Router! +--+---+ Ethernet to remote hosts ! (TCP/IP) ---------------------------------------+----------------------- Question: How can I get the Macintoshes on the Novell LocalTalk trunk talking to the remote hosts on the Ethernet running TCP/IP. The type of services I'm interested in are Telnet, FTP and mail. Any help would be greatly appreciated .. I'm fairly new at this type of thing. Joe Young jay@axiom.maths.uq.oz.au ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101202330000> Received: from nprdc.navy.mil by NIC.DDN.MIL with TCP; Fri, 12 Oct 90 09:31:42 PDT Received: from atlantic.nprdc.navy.mil by nprdc.navy.mil (5.59/SMI-4.0) id AA02921; Fri, 12 Oct 90 09:31:14 PDT Received: by atlantic.nprdc.navy.mil (4.1/SMI-4.0) id AA00795; Fri, 12 Oct 90 09:33:04 PDT From: stanonik@nprdc.navy.mil (Ron Stanonik) Message-Id: <9010121633.AA00795@atlantic.nprdc.navy.mil> Date: 12 October 1990 0933-PDT (Friday) To: tcp-ip@nic.ddn.mil Subject: Re: Re: Ethernet Address Uniqueness... Reply-To: stanonik@nprdc.navy.mil The 10base5 NI cards in our AT&T 3b2's were all delivered with the same ethernet address. This was a big surprise, because we too had come to expect manufacturer's would assign unique addresses. The similar ethernet addresses didn't cause any problems because the IP layer in each machine filtered out only those packets destined for the local machine. Everyone ARP'ed to the same ethernet address. Sort of like multicasting (unicasting?). We didn't realize what was happening until packet tracing to find an unrelated problem. We've since found an undocumented command which allows setting the ethernet address and the machines now all have unique ethernet addresses. Ron Stanonik stanonik@nprdc.navy.mil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101203405800> Received: from ugw.utcs.utoronto.ca by NIC.DDN.MIL with TCP; Fri, 12 Oct 90 04:42:17 PDT Received: from UNB.CA (stdin) by ugw.utcs.utoronto.ca with SMTP id 57693; Fri, 12 Oct 90 07:40:01 EDT Received: by UNBMVS1 (Mailer 14.71) id 3870; Fri, 12 Oct 90 08:40:58 ADT Date: Fri, 12 Oct 90 07:40:58 EDT Comments: <12OCT90.09365370.0050.MUSIC@UNB.CA> From: R17G000 To: Subject: Can I use the Berkeley lp protocol for remote DOS prints fromCOM1? In-Reply-To: In reply to your message of WED 10 OCT 1990 00:16:26 EDT Message-ID: > I've got NCSA telnet configured and printing remotely off of a Sun, but > is there any commercial/pd program out there which lets me trap what goes > to com1/com2/prn from an application? (I've got an application which > can't print to a file). Any pointers would be greatly appreciated. > > - Avi Could you please post your findings to the list if applicable or forward them to me at R17G@UNB.CA ? Thanks in advance. ---------------------------------------------------------------+ Abdulaziz Al-Zoman | R17G@UNB + Faculty of Computer Science | -or- | University of New Brunswick | r17g@unb.ca + F'ton, N.B | -or- | CANADA E3B 5A3 | r17g@unb.bitnet + ---------------------------------------------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101207425600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 12 Oct 90 00:55:58 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17717; Fri, 12 Oct 90 00:51: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: 12 Oct 90 07:42:56 GMT From: mintaka!olivea!samsung!sol.ctr.columbia.edu!ira.uka.de!i32fs2!nipper@bloom-beacon.mit.edu (Arnold Nipper) Organization: University of Karlsuhe, West-Germany Subject: Re: access to polydos.uni-konstanz.de Message-Id: <90.285.07:42:56@ira.uka.de> References: <9010110544.AA12667@violet.berkeley.edu>, <1627.655631099@munnari> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1627.655631099@munnari> kre@MUNNARI.OZ.AU (Robert Elz) writes: >For TCP-IP reades, this was (part of a message) sent to INFO-NETS ... > > Date: Wed, 10 Oct 90 22:44:14 PDT > From: netinfo@violet.berkeley.edu (Postmaster & BITINFO) > Message-ID: <9010110544.AA12667@violet.berkeley.edu> > > I get to Germany in 17 hops, then beyond 188.1.132.24 (21st hop) > packets appear to go into a black hole. > >I didn't believe that number when I first saw it ... thought >it must be a typo, or something, so I just had to try it >for myself... > >But sure enough, its correct, there is something out there, >pretending to be net 188.1, and connected to the Internet. Yes, the netname is WIN-IP (WIssenschaftsNetz) and this net is an IP/X.25 net connecting most of the German universities and other research institutions. > >Unless some very strange thigs have happened, net 188.1 is >not yet allocated to anyone (and perhaps by the time it is >no-one will really care anyway, as its so close to the end >of the available class B numbers). Certainly there are no >allocated 188.* nets listed in the NIC's network-contacts.txt >file. Nets 188.1 - 191.254 are preallocated to what is called PDN cluster. This net clustering is the basis for the PDN cluster addressing scheme which uses it to do efficient routing. Contact C.-H. Rokitansky ( roki@dhafeu52.bitnet ) to get more information about this. He is the former chairman of the IETF working group on PDN. > >Is there some proper person to get in contact with these >people and politely, or very impolitely, suggest that if >they want to be connected to the internet, they should be >using properly allocated numbers? > For more information about this, please contact: Martin Wilhelm Verein zur Foerderung eines Deutschen Forschungsnetzes (DFN) e.V. Zentrale Projektleitung Pariser Strasse 40 W-1000 Berlin 15 Federal Republic of Germany +49 30 884299 30 wilhelm@zpl.dfn.dbp.de If you have problems to reach uni-konstanz.de please contact me or: Jochen Bruening University of Konstanz Universitaetsstrasse 10 Postfach 5560, D-7750 Konstanz +49 7531 88 2410 rzbng@dknkurz1.bitnet >Its no wonder that routing isn't working... Net 188.1 is only the backbone for IP/WIN. Therefor there should be no problems to reach any site in Germany connected to the internet. Of course if you want to connect to some backbone machine with a 188.1 address you will fail. 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---- <1990101208564900> Received: from twg.com by NIC.DDN.MIL with TCP; Fri, 12 Oct 90 15:56:49 PDT Received: from TWG.COM by twg.com with SMTP ; Fri, 12 Oct 90 15:04:46 PST Received: from lefty.twg.com by Mercury.TWG.COM id aa02504; 12 Oct 90 10:17 PDT To: tcp-ip@nic.ddn.mil From: lefty@TWG.COM Subject: Re: Connectathon?? Message-ID: <9010121017.aa02504@Mercury.TWG.COM> >Does anybody know the word "Connectathon?" (may not be right spell) > >I heard it's the name of a kind of competition of TCP/IP implementations. Connectathon is actually an interoperability testing event for ONC/NFS implementations. Many vendors who have NFS products set them up on a shared network and attempt to run a standard set of test suites in an attempt to get everybody's implementations to work against everybody else's. Connectathon 1991 is scheduled to be held this coming March, in San Jose. -- David N. Schlesinger | Internet: lefty@twg.com The Wollongong Group | AppleLink: D6122 1129 San Antonio Road | AOL: lefty3 Palo Alto, CA 94303 | ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010121038.AA20192@ucbvax.Berkeley.EDU] <1990101209092600> From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) Newsgroups: comp.protocols.tcp-ip Subject: Re: Use of TCP/IP with satellite delays Message-ID: <9010121038.AA20192@ucbvax.Berkeley.EDU> Date: 12 Oct 90 09:09:26 GMT References: <1990Oct10.163646.3709@mentor.gandalf.ca> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 Posted: Fri Oct 12 10:09:26 1990 >>Someone recently asked a question about use of TCP/IP over a satellite >>link, and since I've never worked in that realm, the ground got mushy >>under my feet. I'd like a reality check. You should see paper by Seo et al in sigcomm 88 for measurement of TCP & IP over SATNET - the relevant bits include: slow start and mean+variance RTT estimator TCP over the atalantic packet satellite network - even a mere RSRE algoritm RTT TCP ran in service over SATNET for a decade ...it just isnt a problem any more :-) jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101210124900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 12 Oct 90 12:16:09 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04009; Fri, 12 Oct 90 12:08: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: 12 Oct 90 10:12:49 GMT From: apple.com!erekose@apple.com (Erik Scheelke) Organization: Apple Computer Inc, Cupertino, CA Subject: Reliable Datagram Protocols Message-Id: <45598@apple.Apple.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does anyone know of a reliable connectionless datagram protocol that runs on top of UDP? Is so, is there a library out there I can get? Thanks in advance, Erik Scheelke ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101210245900> Received: from munnari.oz.au by NIC.DDN.MIL with TCP; Thu, 11 Oct 90 00:46:17 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA00651; Thu, 11 Oct 1990 17:45:04 +1000 (from kre for tcp-ip@nic.ddn.mil) To: netinfo@violet.berkeley.edu (Postmaster & BITINFO) Cc: info-nets@Think.COM, TCP-IP@Nic.DDN.MIL Subject: Re: access to polydos.uni-konstanz.de In-Reply-To: Your message of Wed, 10 Oct 90 22:44:14 -0700. <9010110544.AA12667@violet.berkeley.edu> Date: Thu, 11 Oct 90 17:44:59 +1000 Message-Id: <1627.655631099@munnari> From: Robert Elz For TCP-IP reades, this was (part of a message) sent to INFO-NETS ... Date: Wed, 10 Oct 90 22:44:14 PDT From: netinfo@violet.berkeley.edu (Postmaster & BITINFO) Message-ID: <9010110544.AA12667@violet.berkeley.edu> I get to Germany in 17 hops, then beyond 188.1.132.24 (21st hop) packets appear to go into a black hole. I didn't believe that number when I first saw it ... thought it must be a typo, or something, so I just had to try it for myself... But sure enough, its correct, there is something out there, pretending to be net 188.1, and connected to the Internet. Unless some very strange thigs have happened, net 188.1 is not yet allocated to anyone (and perhaps by the time it is no-one will really care anyway, as its so close to the end of the available class B numbers). Certainly there are no allocated 188.* nets listed in the NIC's network-contacts.txt file. Is there some proper person to get in contact with these people and politely, or very impolitely, suggest that if they want to be connected to the internet, they should be using properly allocated numbers? Its no wonder that routing isn't working... kre ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101211492600> Received: from bells.cs.ucl.ac.uk by NIC.DDN.MIL with TCP; Fri, 12 Oct 90 02:10:22 PDT Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <3185-0@bells.cs.ucl.ac.uk>; Fri, 12 Oct 1990 10:09:29 +0100 To: ddrg@mentor.gandalf.ca cc: tcp-ip@nic.ddn.mil Subject: Re: Use of TCP/IP with satellite delays In-reply-to: Your message of 10 Oct 90 16:36:46 +0000. <1990Oct10.163646.3709@mentor.gandalf.ca> Date: Fri, 12 Oct 90 10:09:26 +0100 From: Jon Crowcroft >>Someone recently asked a question about use of TCP/IP over a satellite >>link, and since I've never worked in that realm, the ground got mushy >>under my feet. I'd like a reality check. You should see paper by Seo et al in sigcomm 88 for measurement of TCP & IP over SATNET - the relevant bits include: slow start and mean+variance RTT estimator TCP over the atalantic packet satellite network - even a mere RSRE algoritm RTT TCP ran in service over SATNET for a decade ...it just isnt a problem any more :-) jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101214562800> Received: from pucc.PRINCETON.EDU by NIC.DDN.MIL with TCP; Fri, 12 Oct 90 08:12:59 PDT Received: from EDVZ.Uni-Wien.AC.AT by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 3095; Fri, 12 Oct 90 11:10:39 EDT Received: from AWIUNI11 (Z00EJR01) by EDVZ.Uni-Wien.AC.AT (Mailer R2.07) with BSMTP id 8256; Fri, 12 Oct 90 13:58:48 MEZ Date: Fri, 12 Oct 90 13:56:28 MEZ From: Ewald Jenisch Subject: ISO Country codes To: tcp-ip@nic.ddn.mil Does anybody out there in the netland know where I can find a listing of all ISO Country Codes. As far as I remember there was such a list hanging around for anonymous FTP but I don't remember which server. Thanks in advance for any help, Ewald JENISCH University Computer Center University of Vienna, Austria -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E-mail: Z00EJR01@AWIUNI11.BITNET Snail-mail: Z00EJR01@helios.edvz.univie.ac.at Universitaetsstrasse 7 Tel.: (+43 222) 43-61-11/251 A-1010 Vienna, Austria Fax: (+43 222) 43-61-11/170 Europe ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010121643.AA28145@ucbvax.Berkeley.EDU] <1990101216435300> From: Z00EJR01%AWIUNI11@PUCC.PRINCETON.EDU (Ewald Jenisch) Newsgroups: comp.protocols.tcp-ip Subject: ISO Country codes Message-ID: <9010121643.AA28145@ucbvax.Berkeley.EDU> Date: 12 Oct 90 16:43:53 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 Posted: Fri Oct 12 17:43:53 1990 X-Unparsable-Date: Fri, 12 Oct 90 13:56:28 MEZ Does anybody out there in the netland know where I can find a listing of all ISO Country Codes. As far as I remember there was such a list hanging around for anonymous FTP but I don't remember which server. Thanks in advance for any help, Ewald JENISCH University Computer Center University of Vienna, Austria -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E-mail: Z00EJR01@AWIUNI11.BITNET Snail-mail: Z00EJR01@helios.edvz.univie.ac.at Universitaetsstrasse 7 Tel.: (+43 222) 43-61-11/251 A-1010 Vienna, Austria Fax: (+43 222) 43-61-11/170 Europe ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101217042400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 12 Oct 90 10:15:35 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA28808; Fri, 12 Oct 90 10:07: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: 12 Oct 90 17:04:24 GMT From: sdd.hp.com!uakari.primate.wisc.edu!aplcen!haven!ni.umd.edu!sayshell.umd.edu!louie@ucsd.edu (Louis A. Mamakos) Organization: The University of Maryland, College Park Subject: Re: Looking for in_cksum for 68k. Message-Id: <1990Oct12.170424.20226@ni.umd.edu> References: <347@megadata.mega.oz.au> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <347@megadata.mega.oz.au> andrew@megadata.mega.oz.au (Andrew McRae) writes: >Does anyone have a 68000 specific in_cksum routine for >doing IP checksums? The is the checksum routing that I use in the Amiga port of the KA9Q TCP/IP package. It seems to work. louie ; ; Compute the 1's complement sum of data buffer. Called from C as ; ; unsigned short ; lcsum(buf, cnt) ; unsigned short *buf; ; unsigned short cnt; ; ; _lcsum: MOVE.L 4(A7),A0 ; get pointer to data block MOVE.L 8(A7),D1 ; get number of 16bit words to sum MOVE D2,A1 ; save D2 in a volitile register MOVE D1,D2 ; save a copy of the count LSR.L #1,D1 ; convert from words to longs MOVEQ.L #0,D0 ; D0 used to accumulate the sum, clear CC BRA.S endl ; jump to end of loop to start things off ; ; Take advantage of 68010 loop mode cache and add 2 words at a time until ; a carry propagates out. 68020 users win 'cause of instruction cache. ; loop: ADD.L (A0)+,D0 ; add two words in endl: DBCS D1,loop BCC.S done ; jump if done ADDQ.L #1,D0 ; add in carry BRA.S endl ; resume loop done: BTST #0,D2 ; was word count odd? BEQ.S done2 MOVEQ.L #0,D2 MOVE.W (A0),D2 ; get the last word ADD.L D2,D0 ; add it in BCC.S done2 ; did that cause a carry? ADDQ.L #1,D0 ; yes done2: MOVE.L A1,D2 ; restore register MOVE.L D0,D1 ; get copy of sum D0=ABCD D1=ABCD SWAP.W D1 ; into low order part of D1 D0=ABCD D1=CDAB AND.L #$FFFF,D1 ; zap (is this necessary?) D0=ABCD D1=00AB ADD.W D0,D1 ; two halfs of sum together MOVEQ.L #0,D0 ADDX.W D0,D1 ; get last carry MOVE.W D1,D0 RTS ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101219420900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 12 Oct 90 13:00:31 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07027; Fri, 12 Oct 90 12: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: 12 Oct 90 19:42:09 GMT From: media-lab!media-lab.media.mit.edu!dnb@eddie.mit.edu (David N. Blank) Organization: M.I.T. Media Laboratory Subject: netdiag? Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Howdy- In my travels along the anonymous ftp byways I encountered a file called netdiag.tar.Z that had what appeared to be a really handy network debug/display tool with some problems: 1) It was a set of Sun 3 binaries with no source code that ran only under Suntools. 2) The README file was truncated at 512 bytes, (in mid-sentence, even). 3) There were not docs external to the program. Does anyone have any information on this program and where I could get a more complete version of it? Thanks muchly in advance. Peace, dNb ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101223001000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 12 Oct 90 16:21:05 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02124; Fri, 12 Oct 90 16:17: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: 12 Oct 90 23:00:10 GMT From: sdd.hp.com!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!atmos.washington.edu!harry@ucsd.edu (Harry Edmon) Organization: Dept. of Atmospheric Sciences, University of Washington Subject: Where can I find source to PPP or SLIP? Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Where can I get source to PPP or SLIP for SunOS 4.1? Please mail responses directly to me. Thanks. -- Harry Edmon INTERNET: harry@atmos.washington.edu (206) 543-0547 UUCP: uw-beaver!atmos.washington.edu!harry Dept of Atmospheric Sciences, AK-40 University of Washington ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101300214300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 05:05:51 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22133; Sat, 13 Oct 90 05:02: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: 13 Oct 90 00:21:43 GMT From: excelan!donp@ames.arc.nasa.gov (don provan) Organization: Novell, Inc., San Jose, California Subject: Re: Ethernet Address Uniqueness... Message-Id: <2126@excelan.COM> References: <5A0A050B012801FE-MTAEMR1*fillmore@emrcan>, <1990Oct5.123350.145@arizona.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Oct5.123350.145@arizona.edu> leonard@arizona.edu writes: >I believe that Novell's IPX similarly hacks the Ethernet address.... This has nothing to do with TCP-IP, but i don't want this rumor to spread. IPX does not modify the ethernet address. don provan donp@novell.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101303440200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 12 Oct 90 19:51:22 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06793; Fri, 12 Oct 90 19:45: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: 13 Oct 90 03:44:02 GMT From: sdd.hp.com!uakari.primate.wisc.edu!caen!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucsd.edu (Edward Vielmetti) Organization: University of Michigan Math Dept., Ann Arbor MI. Subject: connect: Network is unreachable, (or) I want my FTP Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil From: emv@math.lsa.umich.edu (Edward Vielmetti) My site gets a feed of the sub.* and dnet.* newsgroups, which are in German. There is a fair amount of interesting stuff discussed in these groups, and it's a good way to put that high school German to practice. More to the point, there is a fair amount of software developed in Germany which is made available for anonymous FTP, that is to say stuff available there and nowhere else. So, when I see in sub.tex that there's an interesting set of TeX macros to be had from "forwiss.uni-passau.de", my first inclination is to go and take a look and get them. And the last thing that I want to see is "Network is unreachable" with the traceroute stopping at my local NSS. It is extremely frustrating, that I can learn about European internet resources via Usenet, but when I go to connect to the the NSF backbone blocks my access. Do any of the USA "commercial" internet service providers provide access to the European networks which aren't permitted to use the NSF backbone? I.e., if my regional network were to get say an Alternet or PSI connection they could receive the Euro-routes that way and there would be access. Or perhaps my regional already has a transatlantic link, and they could bypass the backbone that way? One way or another there has to be a legit way to be "part of" the Euro-internet and not get blockaded by the NSF. --Ed Edward Vielmetti, U of Michigan math dept moderator, comp.archives ps. forwiss.uni-passau.de [132.231.1.10], in /archive/tex/macros/nice20.zoo. "Jetzt hoffe ich, dass das Makropaket einen groesseren Kreis von Anwendern findet." ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101303583800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 12 Oct 90 21:21:17 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08245; Fri, 12 Oct 90 21:07: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: 13 Oct 90 03:58:38 GMT From: jarthur!bridge2!api!gpz@uunet.uu.net (G. Paul Ziemba) Subject: TFTP: should ERROR be ACK-ed? Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Please forgive me if this question has been beaten to death in previous discussions; I am new to this group. I have seen some TFTP clients exhibit the following behavior, and I would like to know if it is correct: 1. client sends a RRQ (read request) to a server. 2. server decides it cannot perform the request, so server sends an ERROR to the client. 3. client sends an ACK to the server. Should the client have sent an ACK? ~!paul -- Paul Ziemba api!gpz gpz@ESD.3com.com 408.764.5390 OS/2: just say no. "How much char could a char star star if char star could star char?" (quote stolen from mspercy@clemson.clemson.edu) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101304051500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 12 Oct 90 20:21:00 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07173; Fri, 12 Oct 90 20:06: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: 13 Oct 90 04:05:15 GMT From: swrinde!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucsd.edu (Edward Vielmetti) Organization: University of Michigan Math Dept., Ann Arbor MI. Subject: Re: connect: Network is unreachable, (or) I want my FTP Message-Id: References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article emv@math.lsa.umich.edu (Edward Vielmetti) writes: macros to be had from "forwiss.uni-passau.de", my first inclination is to go and take a look and get them. And the last thing that I want to see is "Network is unreachable" with the traceroute stopping at my My local friendly network service trouble desk informs me that the NSFnet has a request to add this to their routing tables, so I guess you should tone down some of the rhetoric of the previous message. --Ed Edward Vielmetti, U of Michigan math dept moderator, comp.archives ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101312260000> Received: from pucc.PRINCETON.EDU by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 13:23:14 PDT Received: from vaxsar.bitnet by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 0159; Sat, 13 Oct 90 16:21:46 EDT Date: Sat, 13 Oct 90 16:26 EDT From: BIWINE%vassar.bitnet@pucc.PRINCETON.EDU Subject: Protocol analyzer Sender: "Bill Wine, system manager, 437-7226" To: tcp-ip@nic.ddn.mil Reply-to: BIWINE%vassar.bitnet@pucc.PRINCETON.EDU Message-id: <1DCF56A03A7F203D05@vaxsar.bitnet> X-Envelope-to: tcp-ip@nic.ddn.mil X-VMS-To: IN%"tcp-ip@nic.ddn.mil" Is anyone aware of pd software that would turn a workstation (U*ix, VMS, MS-DOS, or Mac) into an Ethernet protocol analyzer? Thanks for your help. Bill Wine biwine@vassar.bitnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101312282200> Received: from kiddo.merit.edu by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 16:08:16 PDT Received: Sat, 13 Oct 90 19:08:22 -0400 by kiddo.merit.edu (AIX/1.6) Date: Sat, 13 Oct 90 19:08:22 -0400 From: Hans-Werner Braun Message-Id: <9010132308.AA16298@kiddo.merit.edu> To: emv@math.lsa.umich.edu Subject: Re: connect: Network is unreachable, (or) I want my FTP Cc: hwb@merit.edu, tcp-ip@nic.ddn.mil Ed Vielmetti: Given all your frequent interactions with the Merit/UMnet/NSFNET NOC with the hope for increased knowledge on your part about how things interact, I find it regrettable that you have to air your frustrations in public, in particular given the tone you used. Look, you describe access to a University, for which in general NSF takes a quite liberal view. If there is a University in at least a country that the US is friends with, NSF, to the best of my knowledge, never objected to have them be known to the NSFNET. With some international sites we need to get concurrance from a national coordination body, in the case you mentioned, University of Passau in Germany, we need concurrance from, e.g., DFN as a german national coordination body. Once we receive a confirmation we need to request permission from the NSF for each and every international network to be configured. The NSF confirmation is to protect both NSF as well as Merit. Sometimes, including in this case, where a network is requested to be configured via multiple NSS entry points, we also need to confirm the announcements with all the sites a network should be configured for, to allow for the proper coordination as well as the proper metric configuration for primary, secondary, etc. paths. All of this is standard procedure and should not take more than a few days. If a network is unknown, it has typically either not been requested for addition to the policy data base or it is not been dynamically announced at the time you tried by the client network to the NSS where it would be announced to or there is a time window between a request and the configuration (which should typically not last for more than a few days and only happen once until it is configured). I will attach some relevant messages which show you that you got caught in the window between request and configuration. An intelligent approach towards dealing with these kind of issues would be to communicate with your local provider of campus networking. Generally this should work fine with most campuses, which then deal with the appropriate regional network and/or the NSFNET NOC. In your case, as you know, they are all the same (UMnet + Merit + NSFNET) and you should have been able to get the information easily. You are otherwise wasting alot of time, effort and bandwidth. Hans-Werner Braun ------------------------------------------------------------------------------- To: nsfnet-admin@merit.edu Subject: Network Announcement Change Request Cc: hostmaster@mcsun.EU.net, hostmaster@germany.eu.net, kaehler@zpl.dfn.dbp.de, wilhelm@zpl.dfn.dbp.de, staff@sunic.sunet.se, ops@uunet.uu.net, Ruediger Volk From: hostmaster@mcsun.EU.net X-Organisation: EUnet/Alternet X-Phone: +31 20 5924112 Date: Wed, 10 Oct 90 19:50:39 +0100 Sender: dfk@mcsun.EU.net Hi, Please add the following networks to the NSFnet routing database. All networks are in Germany (no problems with east and west anymore :-). All of them have ICS sponsored by NSF according to their admins. Routing is coordinated within RIPE and US connectivity is via EUnet/Alternet with backup via NORDUnet. Thank you for your cooperation Daniel Karrenberg EUnet/Alternet Routing Contact ***** Network Announcement Change Request ***** Inbound Announcements Add/Del to NSFNET or Change --------------------------- --------- Network Number/Name 1stAS# 2ndAS# 3rdAS# 4thAS# A/D/C Country ------------------- ------ ------ ------ ------ --------- ------- 130.149 TUB 701 224 97 A Germany 132.180 UNIBT-LAN 701 224 97 A Germany 132.231 UNI-PASSAU 701 224 97 A Germany 134.100 UNIHH 701 224 97 A Germany 134.107 MPPMU-LAN 701 224 97 A Germany 141.1 DFN-WIN1 (ECRCNET) 701 224 97 A Germany 141.2 DFN-WIN2 (UNI-FFM) 701 224 97 A Germany 192.54.41 EMBNET 701 224 97 A Germany ------------------------------------------------------------------------------ Date: 12 Oct 90 15:47 GMT+0100 From: Martin Wilhelm To: ip-register@MERIT.EDU Cc: hostmaster%germany.eu.dbp.de@RELAY.CS.NET Subject: Request for Handling Sheri, can you please process the following request of Ruediger Volk ? All he institutes mentioned below belong to the academia and are members of the DFN association. Best regards and thanks a lot -martin ------------------------------ cut here --------------------------------- >From rv Mon Oct 8 07:57:35 1990 To: kaehler@zpl.dfn.dbp.de, wilhelm@zpl.dfn.dbp.de Subject: Zulassung zum NSFnet Cc: hostmaster@Germany.EU.net, hostmaster@noc.EU.net Dear Colleagues, please, forward this request to admit the following IP networks to use the NSFnet backbone to MERIT. To enable us and other people involved to follow the procedure and help if anything should hang I suggest to use Cc: hostmaster@noc.EU.net, hostmaster@Informatik.Uni-Dortmund.DE on all transactions. net name net number organization DMSWWU-ETHER 128.176 Univ. Muenster UEGNET 132.252 Univ. Essen UNI-OLDENBURG 134.106 Univ. Oldenburg WICOB 192.55.244 Wissenschaftskolleg Berlin For the first three networks listed the appropriate NOCs will be sending requests for including routing information into the NSFnet routing policy data base in parallel. The appropriate NOCs also will request routing support at MERIT for the following networks, which - to my knowledge - already have NSF's approval; for smoothing the procedure I ask you to confirm these networks to MERIT as well. Net name net number Organization TUB 130.149 TU Berlin UNIBT-LAN 132.180 Univ. Bayreuth UNI-PASSAU 132.231 Uni Passau UNIHH 134.100 Univ. Hamburg MPPMU-LAN 134.107 MPI f. Physik, Munich EMBNET 192.54.41 EMBL Heidelberg DFN-WIN1 (ECRCNET) 141.1 ECRC Munich DFN-WIN2 (UNIFFM-NET) 141.2 Univ. Frankfurt Thanks for your cooperation, Ruediger Volk ---------- End of Copy ---------- ------------------------------------------------------------------------------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101312460200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 15:06:58 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16301; Sat, 13 Oct 90 15:06: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: 13 Oct 90 12:46:02 GMT From: usc!srhqla!quad1!ttidca!mb@ucsd.edu (Michael Bloom) Organization: Citicorp/TTI, Santa Monica Subject: Re: Looking for in_cksum for 68k. Message-Id: <20491@ttidca.TTI.COM> References: <347@megadata.mega.oz.au> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <347@megadata.mega.oz.au> andrew@megadata.mega.oz.au (Andrew McRae) writes: >Does anyone have a 68000 specific in_cksum routine for >doing IP checksums? > >I have been using the machine independent version, >but I have looked at the VAX and CCI routines that came >with the 4.3 BSD network source, and it seems it would be >a big win to have a 68k version. I am actually running a >68000 rather than a 68020, but a 68020 version would be >useful as a starting point. A number of years back, I posted a request similar to yours and got not a single response. So I went ahead and hand optimized the assembly output from compiling the machine independent version, taking a few hints from RFC 1071. I measured about 35 % improvement over the straight C file compiled by PCC. It might be the case that compiling the straight C source with GNU C is nearly as good as (or perhaps better than) a hand optimized version. I don't know. We didn't have gcc when I did this. There's still almost certainly room for some more optimization. I'd like to see your improvements. I've been using this for a couple of years on our machines. If you use it, please do not remove the notice at the start of the file. By the way, although the routine won't be re-entered if you are using the bsd networking code, if you are using some other networking code, you might want to move s_util to the stack. #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create: # in_cksum.s # This archive created: Sat Oct 13 05:34:53 1990 export PATH; PATH=/bin:/usr/bin:$PATH echo shar: "extracting 'in_cksum.s'" '(6279 characters)' if test -f 'in_cksum.s' then echo shar: "will not over-write existing file 'in_cksum.s'" else sed 's/^ X//' << \SHAR_EOF > 'in_cksum.s' X# X# Please do not remove this comment. X# X# This file was created by Michael Bloom (mb@ttidca.tti.com) by hand X# optimizing the assembly output from compiling the source file "in_cksum.c" X# which is covered by the following notice allowing redistribution: X# X# /* X# * Copyright (c) 1988 Regents of the University of California. X# * All rights reserved. X# * X# * Redistribution and use in source and binary forms are permitted X# * provided that this notice is preserved and that due credit is given X# * to the University of California at Berkeley. The name of the University X# * may not be used to endorse or promote products derived from this X# * software without specific prior written permission. This software X# * is provided ``as is'' without express or implied warranty. X# * X# * @(#)in_cksum.c 7.1 (Berkeley) 3/29/88 X# */ X# X file "in_cksum.c" X data 1 X lcomm s_util,2 X text X global nin_cksum,in_cksum X# X# in_cksum(m,len) X# m -> %a0 X# len -> %d2 X# X# locals: X# scratch: %a1,%d0,%d1 X# sum: %d3 X# mlen: %d4 X# Xin_cksum: Xnin_cksum: X link.l %fp,&F%1 X movm.l &M%1,(4,%sp) X mov.l (8,%fp),%a0 # m X mov.l (12,%fp),%d2 # len X X clr.l ((S%1-4).w,%fp) # 59 int byte_swapped = 0; X X mov.l &0,%d3 # 60 register sum = 0;3 X mov.l &0,%d4 # register mlen = 0; XL%cksm50: # 63 for (;m && len; m = m->m_next) { X mov.l %a0,%d0 X beq L%cksm49 X tst.l %d2 X beq L%cksm49 X tst.w (%a0,8.w) # if (m->m_len == 0) X beq L%cksm48 # continue; XL%cksm51: X mov.l %a0,%d0 # w = (( u_short *)((int)(m) + (m)->m_off)); X add.l (%a0,4.w),%d0 # X mov.l %d0,%a1 # X mov.l &-1,%d0 # X cmp.l %d4,%d0 # if (mlen == -1) { X bne.b L%cksm52 X# The first byte of this mbuf is the continuation of a word spanning X# between this mbuf and the last mbuf. s_util.c[0] was already saved X# when scanning previous mbuf. X X mov.b (%a1),s_util+1 # s_util.c[1] = *(char *)w; X mov.l &0,%d0 # X mov.w s_util,%d0 # X add.l %d0,%d3 # sum += s_util.s; X lea.l (%a1,1.w),%a1 # w = (u_short *)((char *)w + 1); X mov.w (%a0,8.w),%d0 # mlen = m->m_len - 1; X ext.l %d0 # X sub.l &1,%d0 # X mov.l %d0,%d4 # "" X sub.l &1,%d2 # len--; X bra.b L%cksm53 # } else { XL%cksm52: # not a cont. of word spanning 2 mbufs X mov.w (%a0,8.w),%d0 # X ext.l %d0 # X mov.l %d0,%d4 # mlen = m->m_len; XL%cksm53: # } X cmp.l %d2,%d4 # if (len < mlen) X bge.b L%cksm54 # X mov.l %d2,%d4 # mlen = len; XL%cksm54: # X sub.l %d4,%d2 # len -= mlen; X# # X# Force to even boundary # X# # X mov.l %a1,%d0 # if ((1 & (int) w) && (mlen > 0)) { X and.l &1,%d0 # X beq.b L%cksm55 # X tst.l %d4 # X ble.b L%cksm55 # X mov.l %d3,%d0 # REDUCE X swap %d0 # X add.w %d0,%d3 # X mov.l &0,%d0 # X addx.w %d0,%d3 # X and.l &0xffff,%d3 # "" X X lsl.l &8,%d3 # sum <<= 8; X mov.b (%a1),s_util # s_util.c[0] = *(u_char *)w; X lea.l (%a1,1.w),%a1 # w = (u_short *)((char *)w + 1); X sub.l &1,%d4 # mlen--; X mov.l &1,((S%1-4).w,%fp)# byte_swapped = 1; X # } XL%cksm55: # if ((2 & (int) w) && (mlen > 0)) { X mov.l %a1,%d0 # if >= 2 bytes left and now X and.l &2,%d0 # short aligned, add first X beq.b L%cksm56 # short so rest is long X mov.l &2,%d0 # aligned. X cmp.l %d4,%d0 # X blt.b L%cksm56 # X mov.l &0,%d0 # sum += *w++; X mov.w (%a1)+,%d0 # X add.l %d0,%d3 # X sub.l &2,%d4 # mlen-=2; X # } XL%cksm56: X mov.l %d4,%d1 # X mov.l %d1,%d0 # X lsr.l &6,%d1 # number of times in loop = mlen/64 X and.l &0x3c,%d0 # X neg.l %d0 # X add.l %d0,%d4 # X and.b &0xf,%cc # X jmp 66(%pc,%d0.b) # jump into middle of table for first iter Xnextloop: X mov.l (%a1)+,%d0 X addx.l %d0,%d3 X mov.l (%a1)+,%d0 X addx.l %d0,%d3 X mov.l (%a1)+,%d0 X addx.l %d0,%d3 X mov.l (%a1)+,%d0 X addx.l %d0,%d3 X mov.l (%a1)+,%d0 X addx.l %d0,%d3 X mov.l (%a1)+,%d0 X addx.l %d0,%d3 X mov.l (%a1)+,%d0 X addx.l %d0,%d3 X mov.l (%a1)+,%d0 X addx.l %d0,%d3 X mov.l (%a1)+,%d0 X addx.l %d0,%d3 X mov.l (%a1)+,%d0 X addx.l %d0,%d3 X mov.l (%a1)+,%d0 X addx.l %d0,%d3 X mov.l (%a1)+,%d0 X addx.l %d0,%d3 X mov.l (%a1)+,%d0 X addx.l %d0,%d3 X mov.l (%a1)+,%d0 X addx.l %d0,%d3 X mov.l (%a1)+,%d0 X addx.l %d0,%d3 X mov.l (%a1)+,%d0 X addx.l %d0,%d3 Xendloop: X mov.l &0,%d0 # (move does not affect X bit) X addx.l %d0,%d3 # add in carry from addx last operation X dbra %d1,nextloop # (dbra does not affect X bit) X and.l &0x3,%d4 # above loop got all but possibly last 4 bytes X # if (mlen == 0 && byte_swapped == 0) X # continue X bne.b L%cksm57 X tst.l ((S%1-4).w,%fp) X beq.b L%cksm48 X# REDUCE XL%cksm57: X mov.l %d3,%d1 X swap %d1 X add.w %d1,%d3 X mov.l &0,%d0 X addx.w %d0,%d3 X and.l &0xffff,%d3 XL%cksm_11: XL%cksm58: # while ((mlen -= 2) >= 0) { X sub.l &2,%d4 X blt.b L%cksm59 X mov.l &0,%d0 # sum += *w++; X mov.w (%a1)+,%d0 X add.l %d0,%d3 X bra.b L%cksm58 # } XL%cksm59: X tst.l ((S%1-4).w,%fp) # if (byte_swapped) { X beq.b L%cksm60 X # REDUCE X mov.l %d3,%d1 X swap %d1 X add.w %d1,%d3 X mov.l &0,%d0 X addx.w %d0,%d3 X and.l &0xffff,%d3 XL%cksm_13: X lsl.l &8,%d3 # sum <<= 8; X clr.l ((S%1-4).w,%fp) # byte_swapped = 0; X mov.l &-1,%d0 # if (mlen == -1) { X cmp.l %d4,%d0 X bne.b L%cksm61 X mov.b (%a1),s_util+1 # s_util.c[1] = *(char *)w; X mov.l &0,%d0 # sum += s_util.s; X mov.w s_util,%d0 X add.l %d0,%d3 X mov.l &0,%d4 # mlen = 0; X # } else X bra.b L%cksm62 XL%cksm61: X mov.l &-1,%d4 # mlen = -1; XL%cksm62: X bra.b L%cksm63 # } else if (mlen == -1) XL%cksm60: X mov.l &-1,%d0 X cmp.l %d4,%d0 X bne.b L%cksm64 X mov.b (%a1),s_util # s_util.c[0] = *(char *)w; X # } XL%cksm64: XL%cksm63: XL%cksm48: X mov.l (%a0),%a0 X bra L%cksm50 XL%cksm49: X tst.l %d2 # if (len) X beq.b L%cksm65 X data 2 # printf("cksum: out of data\n"); XL%cksm67: X byte 'c,'k,'s,'u,'m,':,0x20,'o X byte 'u,'t,0x20,'o,'f,0x20,'d,'a X byte 't,'a,'\n,0x00 X text X mov.l &L%cksm67,(%sp) X jsr printf XL%cksm65: # if (mlen == -1) { X mov.l &-1,%d0 X cmp.l %d4,%d0 X bne.b L%cksm68 X clr.b s_util+1 # s_util.c[1] = 0; X mov.l &0,%d0 # sum += s_util.s; X mov.w s_util,%d0 X add.l %d0,%d3 X mov.l &0,%d0 X addx.l %d0,%d3 # handle carry X # 183 } X # REDUCE XL%cksm68: X mov.l %d3,%d1 X swap %d1 X add.w %d1,%d3 X mov.l &0,%d0 X addx.w %d3,%d0 X and.l &0xffff,%d0 X not.w %d0 # return (~sum & 0xffff); X # 186 } X movm.l (4,%sp),&M%1 X unlk %fp X rts X set S%1,0 X set T%1,0 X set F%1,-28 X set M%1,0x001c X data 1 SHAR_EOF if test 6279 -ne "`wc -c < 'in_cksum.s'`" then echo shar: "error transmitting 'in_cksum.s'" '(should have been 6279 characters)' fi fi exit 0 # End of shell archive ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101314225500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 07:36:24 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00723; Sat, 13 Oct 90 07:24: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: 13 Oct 90 14:22:55 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!i32fs2!nipper@ucsd.edu (Arnold Nipper) Organization: University of Karlsuhe, West-Germany Subject: Re: connect: Network is unreachable, (or) I want my FTP Message-Id: <90.286.14:22:55@ira.uka.de> References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article emv@math.lsa.umich.edu (Edward Vielmetti) writes: >From: emv@math.lsa.umich.edu (Edward Vielmetti) > >My site gets a feed of the sub.* and dnet.* newsgroups, which are in >German. There is a fair amount of interesting stuff discussed in >these groups, and it's a good way to put that high school German to >practice. More to the point, there is a fair amount of software >developed in Germany which is made available for anonymous FTP, that >is to say stuff available there and nowhere else. > >So, when I see in sub.tex that there's an interesting set of TeX >macros to be had from "forwiss.uni-passau.de", my first inclination is >to go and take a look and get them. And the last thing that I want to >see is "Network is unreachable" with the traceroute stopping at my >local NSS. It is extremely frustrating, that I can learn about >European internet resources via Usenet, but when I go to connect to >the the NSF backbone blocks my access. That's not the right point of view. Obviously U Passau does not want to have access to the Internet. There are at least four access points to the Internet in Germany ( via EASInet, DFN, Unido, XLINK ). > >Do any of the USA "commercial" internet service providers provide >access to the European networks which aren't permitted to use the NSF >backbone? I.e., if my regional network were to get say an Alternet or >PSI connection they could receive the Euro-routes that way and there >would be access. Or perhaps my regional already has a transatlantic XLINK provides access to PSI net for everyone in Germany who wants. But of course you have to pay for services. :-) >link, and they could bypass the backbone that way? One way or another >there has to be a legit way to be "part of" the Euro-internet and not >get blockaded by the NSF. > >--Ed > 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---- <1990101321181600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 15:52:22 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17351; Sat, 13 Oct 90 15:23:23 -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 Oct 90 21:18:16 GMT From: sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU (Vernon Schryver) Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Reply to Re: Ethernet Address Uniqueness... Message-Id: <72094@sgi.sgi.com> References: <9010092346.AA29384@ftp.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010092346.AA29384@ftp.com>, jbvb@FTP.COM (James B. Van Bokkelen) writes: > This is a standard gotcha of using protocols that change the address. > There is no solution other than to make sure that DECNet is always > started before anything else that cares about the Ethernet address. I do not see the problem. When our DECNET stuff changes the MAC address as it starts, it tells the ethernet driver to call arpwhohas() again, just as if the driver were starting from scratch. The result is that the rest of the IP network sees nothing stranger than if you had quickly taken your system down, switched ethernet cards, and rebooted. The general mechanism can be encapsulated in an ioctl() so that all media can be wishywashy about MAC addresses. Changing ethernet MAC addresses using this ioctl() works just fine on our systems. I can't imagine anyone doing less (for DECNET if not the ioctl()), so I'm sure Sun, DEC, and the other UNIX DECNET vendors do the same or better. It is true that bad things happen if you try to start DECNET on two different boxes with the same node and area numbers, or otherwise try to share a single MAC address with more than one machine. However, this is not much worse than assigning a single IP address to more than host. Vernon Schryver, vjs@sgi.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101321351200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 14:52:21 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA14589; Sat, 13 Oct 90 14:39: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: 13 Oct 90 21:35:12 GMT From: swrinde!cs.utexas.edu!sun-barr!newstop!exodus!cs%Eng.Sun.COM@ucsd.edu (Carl Smith) Organization: Sun Microsystems, Inc. Subject: Re: Connectathon?? Message-Id: <1366@exodus.Eng.Sun.COM> References: <2160001@hicom.hitachi.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil > Does anybody know the word "Connectathon?" (may not be right spell) > > I heard it's the name of a kind of competition of TCP/IP implementations. > > If it was true, how can I get the information about the result of this > competition? Connectathon (TM) is the name of an event whose original purpose was to bring together NFS implementations and ensure that they interoperated. In later years, X Window System testing has also been added. I've been there as a vendor and as part of the group putting it on. It was never intended to be a competition. Nor is it intended to be a trade show (although there is a press event at its conclusion). It is purely an engineering event. Any NFS or X Window System implementation is eligible (and should make a concerted effort) to attend. An announcement is normally published in comp.protocols.nfs and comp.windows.x when the dates and location have been decided. Testing results are never published. Sun (the event's major sponsor) doesn't even allow access to the results by any of our employees who aren't directly involved in running the event. Carl ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101322075200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 15:51:52 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA18662; Sat, 13 Oct 90 15:45: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: 13 Oct 90 22:07:52 GMT From: mcsun!hp4nl!star.cs.vu.nl!rvdp@uunet.uu.net (=Ronald van der Pol) Subject: 3com ethernetcard + SCO TCP/IP Message-Id: <7947@star.cs.vu.nl> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have some problems with a 3COM 503 Ethernet card. It only seems to work with SCO UNIX 3.2.0 TCP/IP (Lachmann) when I use the default IRQ vector of 2. When I try to set the IRQ to 5 it doesn't work (e.g. when I install the Unix e3B driver). Should I use some additional (MS-DOS??) setup software? (there is no interrupt conflict!) -- Ronald van der Pol ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101402551700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 21:37:24 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06185; Sat, 13 Oct 90 21: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: 14 Oct 90 02:55:17 GMT From: sdd.hp.com!wuarchive!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@ucsd.edu (Henry Spencer) Organization: U of Toronto Zoology Subject: Re: Re: Ethernet Address Uniqueness... Message-Id: <1990Oct14.025517.23959@zoo.toronto.edu> References: <9010121633.AA00795@atlantic.nprdc.navy.mil> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010121633.AA00795@atlantic.nprdc.navy.mil> stanonik@nprdc.navy.mil writes: >The 10base5 NI cards in our AT&T 3b2's were all delivered with >the same ethernet address... AT&T has probably been bitten by a problem that has affected a number of established companies when they tried to build Ethernet gear: traditional production facilities have a very strong mindset towards building utterly identical boxes, and the only thing they are set up to do with PROMs is to duplicate them. If you simply hand them the new design and tell them to build it, the odds are very good that you will get identical Ethernet addresses, even if it says in the fine print that they should be different. And testing the new boards one at a time won't catch it! -- "...the i860 is a wonderful source | Henry Spencer at U of Toronto Zoology of thesis topics." --Preston Briggs | henry@zoo.toronto.edu utzoo!henry ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101403345300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 21:07:16 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04495; Sat, 13 Oct 90 20:55: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: 14 Oct 90 03:34:53 GMT From: mintaka!spdcc!dyer@BLOOM-BEACON.MIT.EDU (Steve Dyer) Organization: S.P. Dyer Computer Consulting, Cambridge MA Subject: Re: connect: Network is unreachable, (or) I want my FTP Message-Id: <4450@spdcc.SPDCC.COM> References: <9010132308.AA16298@kiddo.merit.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010132308.AA16298@kiddo.merit.edu> hwb@MERIT.EDU (Hans-Werner Braun) writes: >Given all your frequent interactions with the Merit/UMnet/NSFNET NOC with >the hope for increased knowledge on your part about how things interact, I >find it regrettable that you have to air your frustrations in public, in >particular given the tone you used...You are otherwise wasting alot of time, >effort and bandwidth. Sitting here, it is not at all clear which was the more obnoxious message, nor which the greater waste of bandwidth. I'd rather read a bit of enthusiastic questioning given the spirit of this list than the same amount of pompous bureaucratese offered in response. -- 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---- [NELSON.90Oct15001139@sun.clarkson.edu] <1990101423113900> From: nelson@sun.soe.clarkson.edu (Russ Nelson) Newsgroups: comp.protocols.nfs,sci.skeptic,comp.protocols.tcp-ip Subject: New product announcement: NFSper Summary: I broke my resolution not to post after midnight... Message-ID: Date: 14 Oct 90 23:11:39 GMT Sender: news@news.clarkson.edu Reply-To: nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) Distribution: comp Organization: Clarkson University, Potsdam NY Lines: 55 Posted: Mon Oct 15 00:11:39 1990 Nntp-Posting-Host: sun.soe.clarkson.edu FOR IMMEDIATE PUBLICATION OCT 14, 1990 ESP Software 11 Grant St. Potsdam, NY 13676 ESP Software would like to announce their newest product, NFSper. NFSper is a NFS server with an order of magnitude better performance than any existing NFS server. NFSper uses a proprietary technique to cache NFS requests on the client before they are transmitted to the server. Lab tests have shown that the NFS packet are available on the client an average of 100 microseconds before the client sends the request. Under test conditions, we have observed packets a full 250 uSec before the request transmission! NFSper avoids paradoxical effects by caching the packet rather than actually upcalling it. If the request packet falls on the floor, or the client fails to carry out its intent to send the request, then the client will never request the packet from the cache. Of course, in the case of high network loads or indecisive software, NFSper will rapidly fill your cache, removing any performance advantage. NFSper comes with programmers guidlines for stern, decisive coding. The sooner a decision is made to request a packet, the sooner NFSper can start sending the reply. We have found that most software makes this decision soon enough, but new software should of course take advantage of this new technology. We are currently working on TelePathWay, "All the Network without all the wiring." TelePathWay does away with the need to run coax or twisted pair. TelePathWay plugs into the AUI port found on most Ethernet equipment. You must supply your own telepath. Deliveries are expected by 4Q91. Direct all inquiries To: Russell N. Nelson, President ESP Software 11 Grant St. Potsdam, NY 13696 (315)265-5655 -- --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---- <1990101503244300> Received: from twg.com by NIC.DDN.MIL with TCP; Mon, 15 Oct 90 10:24:43 PDT Received: from TWG.COM by twg.com with SMTP ; Mon, 15 Oct 90 10:20:37 PST Received: from craigsmac.twg.com by Mercury.TWG.COM id ak05147; 14 Oct 90 17:22 PDT From: ljm@mercury.twg.com To: tcp-ip@nic.ddn.mil Cc: Subject: Re: Can I use the Berkeley lp protocol for remote DOS prints from COM1? In-Reply-To: Msg from Avi Freedman dated 10 Oct 90 03:16:26 GMT Message-ID: <9010141722.ak05147@Mercury.TWG.COM> >I've got NCSA telnet configured and printing remotely off of a Sun, but >is there any commercial/pd program out there which lets me trap what goes >to com1/com2/prn from an application? (I've got an application which >can't print to a file). Any pointers would be greatly appreciated. Wollongong will provide LPR print redirector software in December, FTP Software should also be shipping something 'real soon now'. enjoy, leo j mclaughlin iii The Wollongong Group ljm@twg.com P.S. Please post any follow up comments which require a distribution list audience to pcip@udel.edu. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101504104800> Received: from twg.com by NIC.DDN.MIL with TCP; Mon, 15 Oct 90 11:10:48 PDT Received: from TWG.COM by twg.com with SMTP ; Mon, 15 Oct 90 10:20:07 PST Received: from craigsmac.twg.com by Mercury.TWG.COM id ac05147; 14 Oct 90 17:21 PDT From: ljm@mercury.twg.com To: tcp-ip@nic.ddn.mil Cc: Subject: All nets broadcasts (was: SLIP, IP Routers and Named Pipes) In-Reply-To: Msg from Rick Jones dated 5 Oct 90 16:41:59 GMT Message-ID: <9010141721.ac05147@Mercury.TWG.COM> > >Am I correct in assuming that it is the 'non-passing' for certain >IP/UDP broadcast packets that prevents 'stock' named-pipes from >working across IP routers? > Yes. > >If that is the only reason, then could one expect named-pipes to work >across a router that could be configured to pass these broadcasts in a >controlled manner? (no loops and all that...) > The basic problem is that Lan Manager is trying to overcome its lack of a directory services with a mechanism, all-nets-broadcast, which just doesn't belong in an network with over a million users. If you really need to support LM's naming mechanisms, a more reasonable approach is to catch those broadcast NetBIOS name requests and translate them into DNS requests. enjoy, leo j mclaughlin iii ljm@twg.com P.S. Please pass any comments about the number of nodes/users to /dev/null or just read the archives of the last 'size of the Internet' debates. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101504170000> Received: from NRI.Reston.VA.US by NIC.DDN.MIL with TCP; Mon, 15 Oct 90 07:28:56 PDT Received: from mcimail.com by NRI.NRI.Reston.VA.US id ag11050; 15 Oct 90 10:19 EDT Date: Mon, 15 Oct 90 09:17 EST From: Bob Stine <0004219666@mcimail.com> To: "SWEIGERT, DAVID" Cc: tcp-ip Subject: RE: SNMP Agent by Proxy Message-Id: <54901015141745/0004219666NB2EM@mcimail.com> I checked RFC 1147, and found that the CMU SNMP Distribution includes code for an SNMP agent for a Kenetics Fastpath2/3/4, the machine independent portions of which "run on CMU's IBM PC/AT based router." It would be better than starting from scratch... As given in RFC 1147, the CMU SNMP distribution is available via anonymous FTP from lancaster.andrew.cmu.edu (128.2.13.21), as files pub/cmu-snmp.9.tar, and pubkip-snmp.9.tar. You might look for a higher release number. I'm sure that the CMU SNMP has been updated more recently than has its catalog entry. - Bob Stine Applied Cybernetics, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101504233200> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Mon, 15 Oct 90 11:25:05 PDT Received: from bel.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Mon, 15 Oct 90 11:25:17 -0700 Date: Mon, 15 Oct 90 11:23:32 PDT From: postel@venera.isi.edu Posted-Date: Mon, 15 Oct 90 11:23:32 PDT Message-Id: <9010151823.AA00837@bel.isi.edu> Received: by bel.isi.edu (4.1/4.0.3-4) id ; Mon, 15 Oct 90 11:23:32 PDT To: apple.com!erekose@apple.com, tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols Hi. "Reliable Datagram" is an oxymoron. --jon. From tcp-ip-RELAY@NIC.DDN.MIL Fri Oct 12 17:39:16 1990 Date: 12 Oct 90 10:12:49 GMT From: apple.com!erekose@apple.com (Erik Scheelke) Subject: Reliable Datagram Protocols Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does anyone know of a reliable connectionless datagram protocol that runs on top of UDP? Is so, is there a library out there I can get? Thanks in advance, Erik Scheelke ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101504270000> Received: from NRI.Reston.VA.US by NIC.DDN.MIL with TCP; Mon, 15 Oct 90 07:39:42 PDT Received: from mcimail.com by NRI.NRI.Reston.VA.US id ag11233; 15 Oct 90 10:34 EDT Date: Mon, 15 Oct 90 09:27 EST From: Bob Stine <0004219666@mcimail.com> To: BIWINE Cc: tcp-ip Subject: RE: Protocol analyzer Message-Id: <43901015142734/0004219666NB2EM@mcimail.com> Bill, A quick scan of RFC 1147 did not turn up a product that would exactly satisfy your request. There is, however, a publically available package that monitors ethernet traffic and displays header fields. It's called "Netwatch". According to RFC 1147, Netwatch is available as a utility program in the pcip distribution from host husc6.harvard.edu, in directory pub/pcip. Its also available as a standalone package from windom.ucar.edu, in file pc/network/netwatch.arc. (A binary "dearc" program is also available from windom.ucar.edu.) Regards, Bob Stine Applied Cybernetics, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101506181900> Received: from timbuk.CRAY.COM by NIC.DDN.MIL with TCP; Mon, 15 Oct 90 13:39:40 PDT Received: from berserkly.cray.com by timbuk.CRAY.COM (4.1/SMI4.0 CRAY1.1) id AA08267; Mon, 15 Oct 90 14:41:06 CDT Received: by berserkly.cray.com id AA07112; 5.64/CRI-3.10; Mon, 15 Oct 90 14:38:19 -0500 Date: Mon, 15 Oct 90 14:38:19 -0500 From: dab@berserkly.cray.com (David Borman) Message-Id: <9010151938.AA07112@berserkly.cray.com> To: elroy.jpl.nasa.gov!aero!obrien@decwrl.dec.com, mcc@WLV.IMSD.CONTEL.COM, tcp-ip@nic.ddn.mil Subject: Re: Use of TCP/IP with satellite delays > From tcp-ip-RELAY@NIC.DDN.MIL Thu Oct 11 01:16:19 1990 > Return-Path: > Date: Wed, 10 Oct 90 10:51:51 -0700 > From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) > Message-Id: <9010101751.AA08638@WLV.IMSD.CONTEL.COM> > To: elroy.jpl.nasa.gov!aero!obrien@decwrl.dec.com, tcp-ip@nic.ddn.mil > Subject: Re: Use of TCP/IP with satellite delays > > It works fine. TELNET on the other hand is something of a pain. I have > done a TELNET connection between Stuttgart-Vaihingen, FRG and Westlake Village > CA (LA area) with two satellite hops and a 9600 baud link between Westlake > and Marina Del Rey. Found you forget what you typed and can almost go out- > side for a smoke waiting for the echo. > > Merton But if you have Linemode Telnet, then the tty echo and line buffering happens locally, making a long-delay link like this very usable for interactive traffic, as long as you run line-oriented applications. If you run "vi" or some other screen oriented application that wants to do its own terminal echoing, you switch into remote echo and lose just like before... -David Borman, dab@cray.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101508560400> Received: from WLV.IMSD.CONTEL.COM by NIC.DDN.MIL with TCP; Mon, 15 Oct 90 20:36:04 PDT Received: by WLV.IMSD.CONTEL.COM (5.64/1.25) id AA01484; Mon, 15 Oct 90 20:36:04 -0700 Date: Mon, 15 Oct 90 20:36:04 -0700 From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) Message-Id: <9010160336.AA01484@WLV.IMSD.CONTEL.COM> To: prism!ccastjr@gatech.edu, tcp-ip@nic.ddn.mil Subject: Re: The network John: > Somewhere on campus here, we had a Post script formatted > map of the network (showing who is on .mil, and who is on .com > etc etc)...does anyone know where I can find this? Not particularly germane to your question, but this sounds like an interesting map. How is the "class" of the user related to the network to which it is connected? Upon which network would I find *.gov, *.mil, *.com, *.edu, *.de, *.au, *.nz, etc.? How was this determined? As a discrete example, on which network would you find "contel.com"? (A hint--name all network(s) to which contel.com is a member--*.gov, *.mil, *.com, etc. doesn't suggest anything accept the "class" of activity in which the organization is involved.) Merton ----MESSAGE-END---- ----MESSAGE-BEGIN---- [54901015141745.0004219666NB2EM@mcimail.com] <1990101514170000> From: 0004219666@MCIMAIL.COM (Bob Stine) Newsgroups: comp.protocols.tcp-ip Subject: RE: SNMP Agent by Proxy Message-ID: <54901015141745.0004219666NB2EM@mcimail.com> Date: 15 Oct 90 14:17:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 Posted: Mon Oct 15 15:17:00 1990 I checked RFC 1147, and found that the CMU SNMP Distribution includes code for an SNMP agent for a Kenetics Fastpath2/3/4, the machine independent portions of which "run on CMU's IBM PC/AT based router." It would be better than starting from scratch... As given in RFC 1147, the CMU SNMP distribution is available via anonymous FTP from lancaster.andrew.cmu.edu (128.2.13.21), as files pub/cmu-snmp.9.tar, and pubkip-snmp.9.tar. You might look for a higher release number. I'm sure that the CMU SNMP has been updated more recently than has its catalog entry. - Bob Stine Applied Cybernetics, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [43901015142734.0004219666NB2EM@mcimail.com] <1990101514270000> From: 0004219666@MCIMAIL.COM (Bob Stine) Newsgroups: comp.protocols.tcp-ip Subject: RE: Protocol analyzer Message-ID: <43901015142734.0004219666NB2EM@mcimail.com> Date: 15 Oct 90 14:27:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 Posted: Mon Oct 15 15:27:00 1990 Bill, A quick scan of RFC 1147 did not turn up a product that would exactly satisfy your request. There is, however, a publically available package that monitors ethernet traffic and displays header fields. It's called "Netwatch". According to RFC 1147, Netwatch is available as a utility program in the pcip distribution from host husc6.harvard.edu, in directory pub/pcip. Its also available as a standalone package from windom.ucar.edu, in file pc/network/netwatch.arc. (A binary "dearc" program is also available from windom.ucar.edu.) Regards, Bob Stine Applied Cybernetics, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101515425400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 15 Oct 90 08:54:51 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA09818; Mon, 15 Oct 90 08:47: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: 15 Oct 90 15:42:54 GMT From: sdd.hp.com!samsung!sol.ctr.columbia.edu!cica!greg@ucsd.edu (Gregory TRAVIS) Organization: IU Center for Innovative Computing, Bloomington IN Subject: Need Ethernet driver for CT Megaframe Message-Id: <6342@cica.cica.indiana.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Posting for a friend, reply to below address. Looking for Ethernet driver for a Convergent Technologies MegaFrame AKA S1280. Running CTIX version 5.1. Willing to pay, vendor won't sell it to us. No "get a new vendor" comments please. Thanks, Mike Mason, ph 202-382-1274 obpa1!mem.UUCP -- Gregory R. Travis Indiana University, Bloomington IN 47405 greg@cica.cica.indiana.edu Center for Innovative Computer Applications ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101517424600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 16:00:11 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04654; Tue, 16 Oct 90 10:09: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: 15 Oct 90 17:42:46 GMT From: agate!bionet!uwm.edu!rpi!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!evax!utacfd!letni!mic!ernest!alan@ucbvax.Berkeley.EDU (Alan Edmonds) Organization: Texas Instruments, Inc. Plano TX Subject: Re: Can I use the Berkeley lp protocol for remote DOS prints fromCOM1? Message-Id: <1455@ernest.ti.com> References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article R17G@UNB.CA (R17G000) writes: >> I've got NCSA telnet configured and printing remotely off of a Sun, but >> is there any commercial/pd program out there which lets me trap what goes >> to com1/com2/prn from an application? (I've got an application which >> can't print to a file). Any pointers would be greatly appreciated. >> >> - Avi > >Could you please post your findings to the list if applicable or forward >them to me at R17G@UNB.CA ? Me too. -- Alan Edmonds Texas Instruments, Inc. My opinions are only my own. M/S 8513 Work phone: (214)575-6427 6620 Chase Oaks Blvd. Email: alan@ernest.UUCP or alan@ernest.ti.com Plano, Texas 75023 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101518540900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 13:17:17 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA18271; Wed, 17 Oct 90 13:37: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: 15 Oct 90 18:54:09 GMT From: dino!sharkey!fmsrl7!teemc!fmeed1!wehr@uunet.uu.net (Bruce Wehr) Organization: Ford Electronics Division, Dearborn MI Subject: Re: HP TCP/IP router/bridge? Message-Id: <8445@fmeed1.UUCP> References: <45306@apple.Apple.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <45306@apple.Apple.COM>, brooks@Apple.COM (Kevin Brooks) writes: > > Does anyone know of a bridge or router that will allow HP hosts running > TCP/IP which speak IEEE style packets (802.2 encapsulated) to > communicate with ethernet style IP implementations? Do most of the > router/bridge vendors support both IEEE and ethernet style IP packets? I don't have much experience here, but I'm installing a small ethernet network (about a dozen hosts) here at work - and I'm learning while doing. My design includes a bridge in each lab, primarily to aid in fault isolation. The bridge I've chosen is the Retix 2255. The manual says it will pass both style packets transparently, which (I think) answers your second question. It also states that the software on each respective host must deal with packet differences themselves, which (I think) answers your first question (that is, if I understand your first question correctly - you're looking for a bridge that will convert one style packet to another - right? This bridge explicitly *won't* [and I don't know of one that will]. But, it will pass both types, no problem). I hope this helps. -- Bruce Wehr (wehr%dptc.decnet@srlvx0.srl.ford.com) (...uunet!mailrus!sharkey!fmeed1!wehr) (wehr%fmeed1.uucp@mailgw.cc.umich.edu) Ford Motor Company - Electronics Division 17000 Rotunda Drive, ETC Room LN081, Dearborn, Michigan 48121 (313)845-3039 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101519154100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 15 Oct 90 01:09:46 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25602; Mon, 15 Oct 90 01:00: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: 15 Oct 90 19:15:41 GMT From: bacchus.pa.dec.com!deccrl!shlump.nac.dec.com!tkou02.enet.dec.com!jituha!jitgmn.enet.dec.com!shimizu@decwrl.dec.com (Hidetoshi Shimizu) Organization: Digital Equipment Corporation Japan Subject: Re: 3com ethernetcard + SCO TCP/IP Message-Id: References: <7947@star.cs.vu.nl> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <7947@star.cs.vu.nl> rvdp@cs.vu.nl (=Ronald van der Pol) writes: > Xref: jituha comp.unix.sysv386:1390 comp.dcom.lans:12626 comp.protocols.tcp-ip:13626 > Path: jituha!tkou02.enet.dec.com!shlump.nac.dec.com!bacchus.pa.dec.com!decwrl!uunet!mcsun!hp4nl!star.cs.vu.nl!rvdp > From: rvdp@cs.vu.nl (=Ronald van der Pol) > Newsgroups: comp.unix.sysv386,comp.dcom.lans,comp.protocols.tcp-ip > Date: 13 Oct 90 22:07:52 GMT > Sender: news@cs.vu.nl > Lines: 10 > > > I have some problems with a 3COM 503 Ethernet card. It only > seems to work with SCO UNIX 3.2.0 TCP/IP (Lachmann) when I > use the default IRQ vector of 2. When I try to set the IRQ > to 5 it doesn't work (e.g. when I install the Unix e3B driver). > Should I use some additional (MS-DOS??) setup software? > (there is no interrupt conflict!) > > -- > Ronald van der Pol You should use a EtherLink-II Diagnostic Software under the MS-DOS and setup Interrupt vector . -- Hidetoshi Shimizu Digital Equipment Corporation Japan Financial-2 EIC Urbannet Ikebukuro bldg 3-16-3 Higashi Ikebukuro Toshima-ku Tokyo 170 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101520260000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 15 Oct 90 15:55:31 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22983; Mon, 15 Oct 90 15:42: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: 15 Oct 90 20:26:00 GMT From: swrinde!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!mtecv2!vmtecmex.cem.itesm.mx!gcavazos@ucsd.edu (Gustavo Cavazos) Organization: ITESM CEM Subject: What is SNMP Message-Id: <2396@mtecv2.mty.itesm.mx> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil What is SNMP? Here we have a Fastpath IV, when I check the network, besides registering as a Gateway it registers itself as a SNMP. So what is SNMP? -Gus Cavazos -gcavazos at vmtecmex.bitnet -gcavazos at vmtecmex.cem.itesm.mx ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101520334800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 15 Oct 90 17:10:59 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25289; Mon, 15 Oct 90 17:08: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: 15 Oct 90 20:33:48 GMT From: asylum!sharon@decwrl.dec.com (Sharon Fisher) Organization: The Asylum, Belmont, CA Subject: Looking for SNMP network manager software for article Message-Id: <12837@asylum.SF.CA.US> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm doing a story on SNMP network manager software (as opposed to agent) for a story for Business Communication Review. If you produce or know of such software, available to users (i.e., not OEM-only), please let me know...or if there's some kind of global list, that'd be great. Thanks! The story will be an overview of the various packages available, with a chart comparing their features. -- "Drive carefully." "What is it with women and 'drive carefully'? 'No, I'm going to steer with my feet and read the comic paper.'" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101520392000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 15 Oct 90 13:56:25 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19535; Mon, 15 Oct 90 13:54:23 -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: 15 Oct 90 20:39:20 GMT From: prism!ccastjr@gatech.edu (COOOooOoooooOOOOoOOoOOooKIE!!!!!) Organization: Georgia Institute of Technology Subject: The network Message-Id: <15234@hydra.gatech.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have some questions. This might be better suited to another group (is there one dedicated to arpa/internet access besides this one?), but here goes. What is the cost of having access to the net (via your own machine)? Somewhere on campus here, we had a Post script formatted map of the network (showing who is on .mil, and who is on .com etc etc)...does anyone know where I can find this? thanks John -- Emporers Thought for the Day: | John E. Rudd jr. Only the insane have the strength to prosper; | ccastjr@prism.gatech.edu Only those who prosper judge what is sane. | (ex- kzin@ucscb.ucsc.edu) #include Send all comments, flames, and complaints to /dev/null. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101522200600> Received: from alpha.xerox.com by NIC.DDN.MIL with TCP; Tue, 16 Oct 90 06:05:24 PDT Received: from Ripple.Wbst128.Xerox.xns by alpha.xerox.com via XNS id <16534>; Tue, 16 Oct 1990 06:06:12 PDT X-NS-Transport-ID: 0000AA003113B5C82AD5 Date: Tue, 16 Oct 1990 05:20:06 PDT From: Elayne_McFaul.Wbst128@xerox.com Subject: Protocol specification for Unix rcp To: TCP-IP-Internet-NS.all_areas@Xerox.com, TCP-IP-NS.all_areas@Xerox.com, tcp-ip@nic.ddn.MIL cc: McFaul.WBST128@Xerox.com Reply-to: McFaul.WBST128@Xerox.com Message-ID: <"16-Oct-90 8:20:06 EDT".*.Elayne_McFaul.Wbst128@Xerox.com> Where can I find a protocol specification for rcp, the 4.3BSD remote copy utility? Elayne McFaul Xerox Corporation mcfaul.wbst128@xerox.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101600490700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 15 Oct 90 18:25:43 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27363; Mon, 15 Oct 90 18:22: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: 16 Oct 90 00:49:07 GMT From: netcom!jbreeden@apple.com (John Breeden) Organization: Netcom- The Bay Area's Public Access Unix System {408 241-9760 guest} Subject: Re: What is SNMP Message-Id: <14824@netcom.UUCP> References: <2396@mtecv2.mty.itesm.mx> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <2396@mtecv2.mty.itesm.mx> gcavazos@vmtecmex.cem.itesm.mx (Gustavo Cavazos) writes: >What is SNMP? >Here we have a Fastpath IV, when I check the network, besides registering >as a Gateway it >registers itself as a SNMP. >So what is SNMP? Simple Network Management Protocol - for more info, get Marshall Rose's book, "The Simple Book", Prentice Hall. ISBN # 0138126119. -- 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---- <1990101601042400> Received: from salt.acc.com by NIC.DDN.MIL with TCP; Tue, 16 Oct 90 12:43:32 PDT Received: by salt.acc.com (5.61/1.34) id AA14875; Tue, 16 Oct 90 12:44:24 -0700 Date: Tue, 16 Oct 90 12:44:24 -0700 From: bbrooks@salt.acc.com (Bill Brooks) Message-Id: <9010161944.AA14875@salt.acc.com> To: tcp-ip@nic.ddn.mil snmp@psi.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101601064900> Received: from salt.acc.com by NIC.DDN.MIL with TCP; Tue, 16 Oct 90 12:45:57 PDT Received: by salt.acc.com (5.61/1.34) id AA14931; Tue, 16 Oct 90 12:46:49 -0700 Date: Tue, 16 Oct 90 12:46:49 -0700 From: bbrooks@salt.acc.com (Bill Brooks) Message-Id: <9010161946.AA14931@salt.acc.com> To: tcp-ip@nic.ddn.mil plase add me to the mail list at bbrooks@salt.acc.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101602241300> Received: from SH.CS.NET by NIC.DDN.MIL with TCP; Tue, 16 Oct 90 06:39:56 PDT Received: by SH.CS.NET id aa03553; 16 Oct 90 9:16 EDT To: Sharon Fisher cc: tcp-ip@nic.ddn.mil Subject: Re: Looking for SNMP network manager software for article In-reply-to: Your message of 15 Oct 90 20:33:48 +0000. <12837@asylum.SF.CA.US> Date: Tue, 16 Oct 90 09:04:13 -0400 From: jcurran@SH.CS.NET Refer to RFC 1147 (Network Management Tool Catalog) as it lists several SNMP network management tools. It's not necessarily complete, but it's a good start.. /John ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101602530000> Received: from NRI.Reston.VA.US by NIC.DDN.MIL with TCP; Tue, 16 Oct 90 06:05:10 PDT Received: from mcimail.com by NRI.NRI.Reston.VA.US id ac03051; 16 Oct 90 8:53 EDT Date: Tue, 16 Oct 90 07:53 EST From: Bob Stine <0004219666@mcimail.com> To: Sharon Fisher Cc: tcp ip Subject: Re: Looking for SNMP network manager software for article Message-Id: <61901016125316/0004219666NB1EM@mcimail.com> Datapro has compiled a list of SNMP management systems. For information on getting their list, dial 1-800-DATAPRO, and ask to speak with Jill Huntington-Lee. Also, RFC 1147, available via anonymous FTP or email from nic.ddn.mil, lists several SNMP packages. - Bob Stine Applied Cybernetics, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101603151800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 15 Oct 90 19:58:23 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29650; Mon, 15 Oct 90 19:49: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: 16 Oct 90 03:15:18 GMT From: faatcrl!warb@rutgers.edu (Dan Warburton) Organization: FAA Technical Center, Atlantic City NJ Subject: Re: The network Message-Id: <227@faatcrl.UUCP> References: <15234@hydra.gatech.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil ccastjr@prism.gatech.EDU (COOOooOoooooOOOOoOOoOOooKIE!!!!!) writes: > What is the cost of having access to the net (via your >own machine)? The Answer is: ........... it Depends!!! It depends mostly on how close the nearest access point is to your computer and what kind of computer you have and what you purpose for connection is and and how much bandwitdh to the net you would like. Maybe a couple of examples might clarify. Ex. 1 Your network connection is a local machine across the room. Just string some ethernet cable across the room. Get the SysAdm to assign you a spare internet number and zoom! You are on the net. Ex. 2 You don't have a campus connection and want a 56k baud connection. Start with about 25k in equipment costs, add line connect charges, annual rental of line (say 40 miles), add private network gateway cost you should end up with 30k startup plus 20k recurring. This IS just an example, your milage my vary. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101604401400> Received: from NNSC.NSF.NET by NIC.DDN.MIL with TCP; Tue, 16 Oct 90 08:24:45 PDT Received: by NNSC.NSF.NET id ab20026; 16 Oct 90 11:22 EDT To: tcp-ip@nic.ddn.mil Subject: SIGCOMM '91 Call for Papers From: Craig Partridge Date: Tue, 16 Oct 90 11:20:14 -0400 Sender: craig@NNSC.NSF.NET 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: g_f_wetzel@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---- <1990101605490200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 14:56:56 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA14166; Tue, 16 Oct 90 14:18: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: 16 Oct 90 05:49:02 GMT From: encore!zelig!jdarcy@husc6.harvard.edu (Floating Exception) Subject: Re: Reliable Datagram ??? Protocols Message-Id: References: <9010151823.AA00837@bel.isi.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil apple.com!erekose@apple.com (Erik Scheelke): > Does anyone know of a reliable connectionless datagram protocol that > runs on top of UDP? Is so, is there a library out there I can get? postel@VENERA.ISI.EDU writes: >Hi. > >"Reliable Datagram" is an oxymoron. Very funny. Really. I would guess, however, that Erik is referring to a connectionless protocol that preserves message boundaries and guarantees delivery but not necessarily sequencing or non-duplication. I'm sure such beasts exist somewhere. -- Jeff d'Arcy, Generic Software Engineer - jdarcy@encore.com Nothing was ever achieved by accepting reality ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101606051400> Received: from hydra.gatech.edu by NIC.DDN.MIL with TCP; Tue, 16 Oct 90 09:44:28 PDT Received: by hydra.gatech.edu (5.61/3.1) id AA00510; Tue, 16 Oct 90 12:45:14 -0400 Date: Tue, 16 Oct 90 12:45:14 -0400 From: ccastjr@prism.gatech.edu (COOOooOoooooOOOOoOOoOOooKIE!!!!!) Message-Id: <9010161645.AA00510@prism.gatech.edu> To: WLV.IMSD.CONTEL.COM!mcc@gatech.gatech.edu, tcp-ip@nic.ddn.mil Subject: Re: The network well, there was a horizontal line and off from that broke the basic networks (.com .mil .gov etc) in vertical directions (some up, some down). Each "T" in the network was a further sub net (so, when the .edu broke off the base line, there were further breakoffs to .gatech and .mit and .berkeley etc) I think they put commercial orgs on .com even if they had an additional .mil address.. it wasn't meant to be a geographic map (from what I saw) but a network topology map. hope that explains it..if I find a copy, I'll send it to you. John ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101607352600> Received: from tecnet1.jcte.jcs.mil by NIC.DDN.MIL with TCP; Tue, 16 Oct 90 08:55:43 PDT Received: by tecnet1.jcte.jcs.mil (5.54/SMI-4.0) id AA11076; Tue, 16 Oct 90 11:35:26 EDT Date: Tue, 16 Oct 90 11:35:26 EDT From: kate@tecnet1.jcte.jcs.mil Message-Id: <9010161535.AA11076@tecnet1.jcte.jcs.mil> To: tcp-ip@nic.ddn.mil Posted: Oct 16 11:32 EDT Subject: route needed I am trying to send a message to the UK. The address is: user@company.co.uk I know it is a valid address over there but my DOD machine doesn't know how to get it there. I was wondering if there is a static route I could type that will get it over there? Thanks ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101609061400> Received: from WLV.IMSD.CONTEL.COM by NIC.DDN.MIL with TCP; Tue, 16 Oct 90 22:46:52 PDT Received: by WLV.IMSD.CONTEL.COM (5.64/1.25) id AA01889; Tue, 16 Oct 90 20:46:14 -0700 Date: Tue, 16 Oct 90 20:46:14 -0700 From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) Message-Id: <9010170346.AA01889@WLV.IMSD.CONTEL.COM> To: dab@berserkly.cray.com, elroy.jpl.nasa.gov!aero!obrien@decwrl.dec.com, mcc@WLV.IMSD.CONTEL.COM, tcp-ip@nic.ddn.mil Subject: Re: Use of TCP/IP with satellite delays David: As the author you well know that a valid TELNET line mode didn't exist until you did the necessary work. 4.3 BSD always devolves to an equivalent of an rlogin connection with single character frames. There are toooo many products for other platforms that don't really support all TELNET options and in fact don't work when faced with a system that doesn't devolve to the 4.3 BSD default. Now that you've completed a legitimate line mode are you going to implement a valid NVDET option? Merton ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101609390800> Received: from WLV.IMSD.CONTEL.COM by NIC.DDN.MIL with TCP; Tue, 16 Oct 90 21:19:31 PDT Received: by WLV.IMSD.CONTEL.COM (5.64/1.25) id AA01909; Tue, 16 Oct 90 21:19:08 -0700 Date: Tue, 16 Oct 90 21:19:08 -0700 From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) Message-Id: <9010170419.AA01909@WLV.IMSD.CONTEL.COM> To: WLV.IMSD.CONTEL.COM!mcc@gatech.edu, ccastjr@prism.gatech.edu, tcp-ip@nic.ddn.mil Subject: Re: The network John: I like your statements--they follow the party line. Let me insert a little reality before you send any maps--actually send the maps, I would like to take a look at this make believe world. The point of my interest was that the networks never devolved in the conceptual outlines that were anticipated years earlier. There is no *.org, *.gov, *.edu, or *.com networks. There is an *.mil network but it incorporates all of the preceding "classes" of users. There are regional networks that incorporate these "classes" of users. There are no networks, to my knowledge, that are composed of a single "class" of user. For example, *.contel.com is a member of several networks. The membership is partly historical, it is partly a matter of emphasis, and it is partly a matter of entry and sponsorship in the ARPA and MILNET domains. Actually, one might want to consider the role of acquisition in network membership. The domain *.imsd.contel.com is a MILNET member, all other *.contel.com domains are members of SURAnet. Another example is the *.radc.af.mil domain. The tops20.radc.af.mil system is part of NYSERnet. The lonex.radc.af.mil and subsidiary systems are strictly a part of MILNET. One can access the *.radc.af.mil domain either through NYSERnet or MILNET. Merton ----MESSAGE-END---- ----MESSAGE-BEGIN---- ["16-Oct-90..8:20:06.EDT".*.Elayne_McFaul.Wbst128@Xerox.com] <1990101612200600> From: Elayne_McFaul.Wbst128@xerox.com Newsgroups: comp.protocols.tcp-ip Subject: Protocol specification for Unix rcp Message-ID: <"16-Oct-90..8:20:06.EDT".*.Elayne_McFaul.Wbst128@Xerox.com> Date: 16 Oct 90 12:20:06 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: McFaul.WBST128@Xerox.com Organization: The Internet Lines: 5 Posted: Tue Oct 16 13:20:06 1990 Where can I find a protocol specification for rcp, the 4.3BSD remote copy utility? Elayne McFaul Xerox Corporation mcfaul.wbst128@xerox.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [61901016125316.0004219666NB1EM@mcimail.com] <1990101612530000> From: 0004219666@mcimail.com (Bob Stine) Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for SNMP network manager software for article Message-ID: <61901016125316.0004219666NB1EM@mcimail.com> Date: 16 Oct 90 12:53:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 Posted: Tue Oct 16 13:53:00 1990 Datapro has compiled a list of SNMP management systems. For information on getting their list, dial 1-800-DATAPRO, and ask to speak with Jill Huntington-Lee. Also, RFC 1147, available via anonymous FTP or email from nic.ddn.mil, lists several SNMP packages. - Bob Stine Applied Cybernetics, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010162042.AA12953@ucbvax.Berkeley.EDU] <1990101613041300> From: jcurran@SH.CS.NET Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for SNMP network manager software for article Message-ID: <9010162042.AA12953@ucbvax.Berkeley.EDU> Date: 16 Oct 90 13:04:13 GMT References: <12837@asylum.SF.CA.US> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 Posted: Tue Oct 16 14:04:13 1990 Refer to RFC 1147 (Network Management Tool Catalog) as it lists several SNMP network management tools. It's not necessarily complete, but it's a good start.. /John ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010162109.AA13830@ucbvax.Berkeley.EDU] <1990101615201400> From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: SIGCOMM '91 Call for Papers Message-ID: <9010162109.AA13830@ucbvax.Berkeley.EDU> Date: 16 Oct 90 15:20:14 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 84 Posted: Tue Oct 16 16:20:14 1990 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: g_f_wetzel@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---- <1990101615452500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 14:38:56 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16541; Tue, 16 Oct 90 15:27: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: 16 Oct 90 15:45:25 GMT From: asylum!sharon@decwrl.dec.com (Sharon Fisher) Organization: The Asylum, Belmont, CA Subject: Looking for users who run SNMP in their bridges & routers Message-Id: <12843@asylum.SF.CA.US> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I've also gotten an assignment from Datamation to write about the use of SNMP in bridges and routers. I am looking for users in this area. If you're a user, or if you're a vendor who can provide users I can talk to, please let me know. Thanks! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101616313700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 14:48:36 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08925; Tue, 16 Oct 90 11:54: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: 16 Oct 90 16:31:37 GMT From: rogue.llnl.gov!oberman@lll-winken.llnl.gov Subject: Re: Reply to Re: Ethernet Address Uniqueness... Message-Id: <1990Oct16.093137.1@rogue.llnl.gov> References: <9010092346.AA29384@ftp.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010092346.AA29384@ftp.com>, jbvb@FTP.COM (James B. Van Bokkelen) writes: > This is a standard gotcha of using protocols that change the address. > There is no solution other than to make sure that DECNet is always > started before anything else that cares about the Ethernet address. This is getting a bit far afield from tcp-ip, but the above is not quite true. By setting the SYSGEN value for SCSSYSTEMID to the value ((DECnet area*1024) + node), the order in which products are started in no longer significant as the MAC address of the Ethernet cards is rewritten before any layered software is run. 48.168 would yield an SCSSYSTEMID of 49320, (48*1024)+168. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101616342800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 14:25:12 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10744; Tue, 16 Oct 90 12:42: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: 16 Oct 90 16:34:28 GMT From: mcsun!i2unix!alessia!athena@uunet.uu.net (Matteo Frigo) Organization: DEI Padova University Subject: Re: Strange bahaviour of an LSX3020 with tcp protocol Message-Id: <6702@alessia.dei.unipd.it> References: <6610@alessia.dei.unipd.it> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil [ I reply to myself :-) ] I have been able to solve the problem, and as it is a bug of of X/OS 2.2 I post the solution . The problem was in the incorrect TTL (time to live of tcp packets) which was set to 15, while the sun had 30. The constant TCP_TTL is defined in netinet/tcp_timer.h. My kernel was compiled with this low value, which inhibits tcp connections which far hosts. As I have not access to Olivetti kernel's sources, I made a patch directly on /usr/mixos/kernel/tcpip/libtcp_ip.a, using as guide the tcp sources from BSD4.3 . The constant is used in two object modules. I believe this is a problem of all LSX machines with X/OS 2.2 and I can give details on patching the kernel to anyone who is interested in. I would also thank all the people who gave me suggestions after my news. Matteo Frigo athena@alessia.dei.unipd.it (it works now !) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101620545400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 15:21:40 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15718; Tue, 16 Oct 90 15:06: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: 16 Oct 90 20:54:54 GMT From: wuarchive!emory!hubcap!mmccann@eddie.mit.edu (Mike McCann) Organization: Clemson University, Clemson, SC Subject: Need phone numbers... Message-Id: <10981@hubcap.clemson.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am interested in subnetting several building off our Ethernet backbone (passing TCP-IP, DECnet and AppleTalk packets) to cut down on the amount of backbone traffic and inefficient IP number usage. Anyone have phone numbers for networking companies (such as Proteon or Sysco)? I also want these routers to be managed by SNMP. Any suggestions? Thanks in advance for your help, -- Mike McCann (803) 656-2721 Internet = mmccann@hubcap.clemson.edu Engineering Computer Operations Bitnet = mmccann@clemson.bitnet Clemson University Clemson, S.C. 29634-2803 DISCLAIMER = I speak only for myself. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101621300000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 11:44:41 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13303; Wed, 17 Oct 90 10:08: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: 16 Oct 90 21:30:00 GMT From: snorkelwacker!mintaka!spdcc!ima!mirror!frog!tdh@apple.com (T. Dave Hudson) Organization: Charles River Data Systems Subject: single tcpcb loopback bug Message-Id: <19897@frog.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil This seems to be a previously unpublished bug. (Do 4.3BSD TCP/IP bugs belong in comp.bugs.4bsd.ucb-fixes instead?) We are using the following base revisions of 4.3BSD TCP/IP source modules: @(#)tcp_input.c 7.15.1.3 (Berkeley) 2/15/89 @(#)tcp_output.c 7.13.1.4 (Berkeley) 2/15/89 When a user program (which I did not write) does 1) socket(PF_INET, SOCK_STREAM, 0) 2) bind() {PF_INET, port=3000, INADDR_ANY} 3) connect() {PF_INET, port=3000, local host's IP address} the kernel goes into an infinite "loop" (dump indicates many ACKs but little data in tcpstats) presumably scheduling SYN/ACK (and possibly something else; dump only showed last message) messages to and from presumably the same tcpcb. The tcpcb is in SYN SENT state, with tcp_output() called from the dropafterack section of tcp_input(), and with tcp_output() having successfully sent a message, contents unknown except that the last freed mbuf, appropriately, is SYN/ACK with both ports equal to 3000 and using the local node's Ethernet interface's IP address. The SYN/ACK message contains an ISN that disagrees (having been incremented) with the tcpcb's idea of it, but an acknowledgement number that (matching the SYN/ACK's ISN, properly incremented from the tcpcb's ISN) is OK. I suspect that a workable fix is to use the tcpcb's ISN when sending any SYN, although I haven't tried this yet. However, the failure to do this ought to have generated a RST, IMHO, so I guess there are actually two bugs here. Has anyone already worked out a fix for this? (I will summarize responses received by email. My guess is that it will be another month or two before I can spend time working out a fix myself.) David Hudson ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101621394300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 14:22:57 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA18349; Tue, 16 Oct 90 16: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: 16 Oct 90 21:39:43 GMT From: sgi!cjohnson%somni.wpd.sgi.com@ucbvax.Berkeley.EDU (Chris Johnson) Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Reliable Datagram ??? Protocols Message-Id: <72306@sgi.sgi.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil > postel@VENERA.ISI.EDU sez: > > "Reliable Datagram" is an oxymoron. > > --jon. Perhaps reliable datagram using UDP is an oxymoron, depending on the transport layer. However XTP datagrams *are* reliable. Mail to xtp-request@pei.com for information or a XTP spec. Chris Johnson cjohnson@pei.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101701415900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 14:48:23 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29432; Tue, 16 Oct 90 23:40: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: 17 Oct 90 01:41:59 GMT From: sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU (Rob Warnock) Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: File Broadcast Message-Id: <72341@sgi.sgi.com> References: <45509@apple.Apple.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <45509@apple.Apple.COM> erekose@apple.com (Erik Scheelke) writes: +--------------- | We have a local area network of UNIX based PCs running TCP-IP, and I | was asked if there was any software that will broadcast a file to all | machines on the network. I didn't know of any and was wondering if | anyone out there in netland knew of any. If not, I guess I will have | to write something myself. I would appreciate any infomation about | programs or algorithms that do file broadcasting. It must use a broadcast, | not a copy to one machine then copy to another method (i.e. UDP), and | if a machine is up it must reliably send the file. +--------------- Using the multicast features of the XTP protocol, you could do what you want with something like the following: for i in $MACHINELIST do # start each receiver listening rsh $i 'txtp -r -s -M | tar xf - &' done # now multicast the file txtp -t -s -M Received: from ftp.com by NIC.DDN.MIL with TCP; Wed, 17 Oct 90 07:33:33 PDT Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA22340; Wed, 17 Oct 90 10:33:48 -0500 Date: Wed, 17 Oct 90 10:33:48 -0500 Message-Id: <9010171533.AA22340@ftp.com> To: news!german@iuvax.cs.indiana.edu (Chad W. German) Subject: Re: NCSA TELNET / BANYAN 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 VINES doesn't use packet drivers. Instead, they have a hardware device sharing interface built into VINES. We offer a version of PC/TCP which talks to it, and gives the functionality you want. I don't know if any of the freeware developers have ever considered doing drivers for this. I have heard rumors of VINES which can use NDIS, and if you could get it, this could be combined with the NDIS-Packet Driver adapter to use freeware. If this is in fact a feature of their 4.0 release, I have been told it will be available sometime this winter. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101703230000> Received: from NRI.Reston.VA.US by NIC.DDN.MIL with TCP; Wed, 17 Oct 90 06:31:38 PDT Received: from mcimail.com by NRI.NRI.Reston.VA.US id ae03969; 17 Oct 90 9:23 EDT Date: Wed, 17 Oct 90 08:23 EST From: Bob Stine <0004219666@mcimail.com> To: Merton Campbell Crockett Cc: tcp ip Subject: Re: The network Message-Id: <53901017132335/0004219666NB1EM@mcimail.com> >The point of my interest was that the networks never devolved in the conceptual >outlines that were anticipated years earlier. There is no *.org, *.gov, *.edu, >or *.com networks... There is an *.mil network but it incorporates all of the >preceding "classes" of users. There are regional networks that incorporate >these "classes" of users. There are no networks, to my knowledge, that are >composed of a single "class" of user. My understanding on this issue (such as it is :-) ) is that the name space is independent from the actual network topology. E.g., having an "edu" domain does _NOT_ mean that one should expect to find an education net. If this thread goes much further, it would probably be more appropriate for name-droppers. Bob Stine Applied Cybernetics, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101706241900> Received: from TGV.COM by NIC.DDN.MIL with TCP; Wed, 17 Oct 90 13:25:55 PDT Date: Wed 17 Oct 90 13:24:19-PDT From: VANCE@TGV.COM (Icarus) To: marge%masbull.my.bull.fr@TGV.COM cc: tcp-ip@nic.ddn.mil Message-ID: <656195059.375947.VANCE@TGV.COM> In-Reply-To: <9010171730.AA17315@masbull.my.bull.fr> 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 product that supports DOS diskless station on >TCP/IP with UNIX server using TFTP and BOOTP. I know of two. Try: Beame & Whiteside (416) 648-6556 FTP Software (617) 246-0900 Regards, -----Stuart ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101707145800> Received: from server.af.mil by NIC.DDN.MIL with TCP; Wed, 17 Oct 90 10:20:16 PDT Received: by server.af.mil (5.59/25-eef) id AA01958; Wed, 17 Oct 90 12:15:02 CDT From: mailing list Message-Id: <9010171715.AA01958@server.af.mil> Subject: Re: The network To: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) Date: Wed, 17 Oct 90 12:14:58 CDT Cc: tcp-ip@nic.ddn.mil In-Reply-To: <9010170419.AA01909@WLV.IMSD.CONTEL.COM>; from "Merton Campbell Crockett" at Oct 16, 90 9:19 pm X-Mailer: ELM [version 2.3 PL2] > The point of my interest was that the networks never devolved in the conceptual > outlines that were anticipated years earlier. There is no *.org, *.gov, *.edu, > or *.com networks. There is an *.mil network but it incorporates all of the > preceding "classes" of users. There are regional networks that incorporate > these "classes" of users. There are no networks, to my knowledge, that are > composed of a single "class" of user. > Yes, even the milnet has its non-military users. I guess what I wanted to say, is that the map that John is referring to is a map of the Domains of the internet. I remember seeing it once, and it is strictly a break-out of all the domains registered with the SRI-NIC... I don't know that that means you can get it from the NIC, however. I am sure that I did not get it from the NIC myself. I also remember that I got this "map" early this year, and it hadn't been revised since 88. If anyone does run across a really current one, I'd be interested in seeing how well it reflects our af.mil reality (:-> /matt jonson@server.af.mil I speak not for my organization. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101709172300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 13:09:34 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23199; Wed, 17 Oct 90 17:16: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: 17 Oct 90 09:17:23 GMT From: mcsun!hp4nl!dnlunx!dnlts!icp@uunet.uu.net (R. Sonneveld, ICP, NAD, ICP@HLSDNL5.BITnet, +31 70 435362) Organization: PTT Research Neher Laboratories, The Netherlands Subject: Re: ISO Country codes Message-Id: <54413.271c2fb3@pttrnl.nl> References: <9010121643.AA28145@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010121643.AA28145@ucbvax.Berkeley.EDU>, Z00EJR01%AWIUNI11@PUCC.PRINCETON.EDU (Ewald Jenisch) writes: > Does anybody out there in the netland know where I can find a listing > of all ISO Country Codes. As far as I remember there was such a list > hanging around for anonymous FTP but I don't remember which server. Try your nearest NETSERV, for the file: COUNTRY ISOCODES. Rolf Sonneveld PTT Research The Netherlands ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101711030700> Received: from sun2.nsfnet-relay.ac.uk by NIC.DDN.MIL with TCP; Wed, 17 Oct 90 01:40:09 PDT Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <1091-11@sun2.nsfnet-relay.ac.uk>; Wed, 17 Oct 1990 09:29:42 +0100 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa01718; 17 Oct 90 8:24 BST Received: from [+JANET.000001501500.ncl.mts.ftp.mail] by uk.ac.newcastle; Wed, 17 Oct 90 09:23:15 +0100 Date: Wed, 17 Oct 90 09:23:07 +0100 From: Denis.Russell@newcastle.ac.uk Subject: Re: route needed To: kate@tecnet1.jcte.jcs.mil Cc: tcp-ip@nic.ddn.mil Message-Id: In-Reply-To: <9010161535.AA11076@tecnet1.jcte.jcs.mil> Re: > I am trying to send a message to the UK. The address is: > user@company.co.uk > I know it is a valid address over there but my DOD machine doesn't know how > to get it there. I was wondering if there is a static route I could type > that will get it over there? > Thanks Try routing it via nsfnet-relay.ac.uk, i.e. try either user%company.co.uk@nsfnet-relay.ac.uk or user%uk.co.company@nsfnet-relay.ac.uk (The second form might just be required because our mail addresses are the other way round). If you look at the trace of this message to you, you should be able to see this gateway in the route. Denis Denis Russell JANET: Denis.Russell@uk.ac.newcastle Computing Laboratory Internet: Denis.Russell@newcastle.ac.uk The University Claremont Road Tel: (+44) 91 222 8243 Newcastle upon Tyne Fax: (+44) 91 222 8232 NE1 7RU Telex: 53 65 4 UNINEW G ENGLAND ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101712060000> Received: from ugw.utcs.utoronto.ca by NIC.DDN.MIL with TCP; Wed, 17 Oct 90 13:13:43 PDT Received: from NOS.CRNL.AECL.CA (stdin) by ugw.utcs.utoronto.ca with SMTP id 57574; Wed, 17 Oct 90 16:08:00 EDT Received: From NVE.AECL.CA by NOS.AECL.CA via RCNET; Wed, 17 Oct 1990 16:08 EDT Received: From CC1 by NVE.AECL.CA ; Wed, 17 Oct 1990 16.08.01,46 EDT Date: Wed, 17 Oct 90 16:06:00 EDT From: CHRISTOPHER TANNER Subject: WIN$LPD on VMS To: tcp-ip@NIC.DDN.MIL Message-id: <1AAD8E9AD8BF401F39@CRL.AECL.CA> X-Envelope-to: tcp-ip@nic.ddn.mil X-VMS-To: IN%"tcp-ip@nic.ddn.mil" X-VMS-Cc: TANNERC Greetings Using Wollongong's version of LPD on VMS, is it possible to specify parameters for the VMS PRINT commands such as /FLAG and /FORM=xxx? I would like an lpr -Pxx (on UNIX) to become PRINT /Q=xx/FLAG/FORM=yy on the VMS system. Thanks for your help Chris Tanner AECL Research ----MESSAGE-END---- ----MESSAGE-BEGIN---- [53901017132335.0004219666NB1EM@mcimail.com] <1990101713230000> From: 0004219666@mcimail.com (Bob Stine) Newsgroups: comp.protocols.tcp-ip Subject: Re: The network Message-ID: <53901017132335.0004219666NB1EM@mcimail.com> Date: 17 Oct 90 13:23:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 Posted: Wed Oct 17 14:23:00 1990 >The point of my interest was that the networks never devolved in the conceptual >outlines that were anticipated years earlier. There is no *.org, *.gov, *.edu, >or *.com networks... There is an *.mil network but it incorporates all of the >preceding "classes" of users. There are regional networks that incorporate >these "classes" of users. There are no networks, to my knowledge, that are >composed of a single "class" of user. My understanding on this issue (such as it is :-) ) is that the name space is independent from the actual network topology. E.g., having an "edu" domain does _NOT_ mean that one should expect to find an education net. If this thread goes much further, it would probably be more appropriate for name-droppers. Bob Stine Applied Cybernetics, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101717064500> Received: from sparta.com by NIC.DDN.MIL with TCP; Wed, 17 Oct 90 21:14:31 PDT Received: by sparta.com (4.0/cfm-mcl-MX-1.4(Heisenberg)) id AA12447; Thu, 18 Oct 90 00:15:00 EDT From: cfm@sparta.com (Carl Muckenhirn) Received: from localhost by columbia.sparta.com (4.1/cfm-1.1) id AA08184; Wed, 17 Oct 90 23:46:49 EDT Message-Id: <9010180346.AA08184@columbia.sparta.com> To: ccastjr@prism.gatech.edu (COOOooOoooooOOOOoOOoOOooKIE!!!!!) Cc: WLV.IMSD.CONTEL.COM!mcc@gatech.gatech.edu, tcp-ip@nic.ddn.mil Subject: Network Maps (was: The network) In-Reply-To: Your message of "Tue, 16 Oct 90 12:45:14 EDT." <9010161645.AA00510@prism.gatech.edu> Date: Wed, 17 Oct 90 23:46:45 -0400 the map you are refering to used to be available from the DDN NIC (NIC.DDN.MIL). It has nothing to do with network geography or topology, but is a listing of the domains that are registered with the NIC. It was (is, it is probably still out there somewhere) basically a tree with the "INTERNET" as the root node, .com, .mil, .gov, .org, .us, .uk, ... as the first level descendents, .af.mil, .sparta.com, .mitre.org, ... etc. For the most part the tree is very shallow, but some branches are fairly deep (mit.edu comes to mind). This whole map is just a layout of administrative domains. There are a number (most?) of domains that consist of several "networks" (a group of computers organized under a single network number). There is no reason that a domain (sparta.com for example) cannot be geographically diverse (for example with a "network" in Washington, D.C. and another in Baltimore, MD) but sharing the administrative and naming structure provided by the DNS (all hosts on these networks have hostnames of the form .sparta.com ( maybe or . or ....... [you get the picture]). If you want a picture of the "network topology" you need to start looking at the network addresses, find the gateways on those networks, hook the gateway's different network addresses together, then go to the next layer of networks and so on. This should be doable (I've been working on related pieces of this problem for the last 2 years on and off) with the information in the NIC (and NSFNET NISC). The hard part comes when you try to display it, what is the point of reference (if I start at the nsfnet the picture is much different than if I start at a stub network), what symbology is appropriate (are the connected networks lines, clouds, layers of an onion) and so on. And once you've figured that out, someone will say, "But WHERE are these things?" and you now have to get all the addresses for the gateways, and now the pretty layered picture is a bowl of spaghetti. (Are there any idle topologists out there?) All this is to say, I doubt that there are any "network maps" out there that show the entire internet. There are some very good geographic maps of some of the regional and educational nets (THENet sticks in my mind) out there, but I think that all were manually done (a Mac, some clip-art, a lot of time). I can't remember right off where they can be found, if anyone is interested drop me a line and I'll see if I can dig it out. A few people here at Sparta have done a lot of thinking about how to do automated generation of topographic and geographic network maps, and we have some of the basics down but we are between contracts and don't know if this work will continue (being a defense contractor is the pits sometimes). If anyone has any other insights on this topic I'd be happy to hear from you. carl. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101717064800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 12:07:15 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15216; Wed, 17 Oct 90 11:27: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: 17 Oct 90 17:06:48 GMT From: VAX1.CC.UAKRON.EDU!mcs.kent.edu!usenet.ins.cwru.edu!cwns1!chet@tut.cis.ohio-state.edu (Chet Ramey) Organization: Case Western Reserve Univ. Cleveland, Ohio, (USA) Subject: Re: Protocol specification for Unix rcp Message-Id: <1990Oct17.170648.5422@usenet.ins.cwru.edu> References: <"16-Oct-90..8:20:06.EDT".*.Elayne_McFaul.Wbst128@Xerox.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >Where can I find a protocol specification for rcp, the 4.3BSD remote copy utility? /usr/src/bin/rcp.c :-) Chet -- Chet Ramey ``As I recall, Doug was keen on boxing. But Network Services Group when he learned to walk, he took up puttin' Case Western Reserve University the boot in the groin.'' chet@ins.CWRU.Edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101717161000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 11:35:26 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA14742; Wed, 17 Oct 90 11:06: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: 17 Oct 90 17:16:10 GMT From: prism!ccastjr@gatech.edu (COOOooOoooooOOOOoOOoOOooKIE!!!!!) Organization: Georgia Institute of Technology Subject: Re: The network Message-Id: <15357@hydra.gatech.EDU> References: <9010170419.AA01909@WLV.IMSD.CONTEL.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Sorry if my statements were misleading. I know that the *.mil and *.edu\ don't denote a PHYSICAL network.. but a "logical" network.. The map is drawn along this "logical" network. I understood this, but I guess that didn't come across.. sorry. John -- Emporers Thought for the Day: | John E. Rudd jr. Only the insane have the strength to prosper; | ccastjr@prism.gatech.edu Only those who prosper judge what is sane. | (ex- kzin@ucscb.ucsc.edu) #include Send all comments, flames, and complaints to /dev/null. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101717483200> Received: from phoebus.nisc.sri.com by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 01:03:22 PDT Received: by phoebus.nisc.sri.com (5.64/SRI-NISC 1.0 (Phoebus special)) id AA15867; Thu, 18 Oct 90 00:48:32 -0700 Date: Thu, 18 Oct 1990 0:48:32 PDT From: SRI Network Information Systems Center To: tcp-ip@nic.ddn.mil Subject: Domain Survey Results Message-Id: Network Information Systems Center October 1, 1990 SRI International Domain Survey INTERNET DOMAIN SURVEY The Domain Survey statistics are compiled by ZONE, the Zealot Of Name Edification. ZONE runs on a DEC-2065 mainframe connected to the Internet. ZONE begins with a list of top-level domains and their associated name-servers. For each domain, ZONE attempts to make a TCP connection to one of the listed name-servers. Once connected, ZONE requests a dump (called a zone transfer) of the domain being served. ZONE collects information on host names, nicknames, addresses, mail exchanger records (MX records) and name-server records. If a name-server record refers to a subdomain, then that subdomain is added to the list of domains that ZONE searches. In this way, ZONE descends through the entire domain tree trying to find all existing domains. ZONE cycles through its list of domains left to search until it has gone through the entire list without receiving any new information. When ZONE finishes, it dumps out a table of all the information it has collected in a format similar to HOSTS.TXT. ZONE also creates a file with a list of all the domains it has found. Sometimes a domain can't be searched because the servers can't be reached, or because of administrative restrictions that disallow zone transfers. ZONE reports the total number of hosts and domains it has found. The total elapsed and cpu time to run ZONE are also indicated in the statistics, along with the size of the generated host table. ZONE also keeps track of how many different IP addresses each individual host has assigned to it. This table is listed under "Number of Addresses per Host". Hosts with zero addresses are really just mail forwarding entries, usually to a host that is not connected to the Internet. Many of these entries are wildcards for entire domains that are not on the Internet. A search of a few popular keywords (names of machines and operating systems) was done on the resulting host table. The results are listed in the section "String Searches on Host Table". No attempt was made to make sure one of these strings wasn't just a substring of a larger (possibly unrelated) string. The first component of each domain name was stripped off and a list of 'host names' was generated. The top 72 most popular host names are listed along with the number of occurrences of each. DOMAIN SURVEY RESULTS Statistics Hosts: 313,000 [minimum] Domains: 9300 [approximately] Total elapsed time: 5 days Total cpu time: 4.5 hours Host table generated: 25 megabytes Number of Addresses per Host Addresses Hosts 0 22964 [MX-only entries] 1 306516 2 4929 3 626 4 328 5 148 6 135 7 63 8 43 9 20 10 13 String Searches on Host Table pc 46600 unix 38700 sun 37700 mac 28400 hp.com 24500 ibm 20700 vax 14300 vms 5900 tops-20 30 Top 72 Most Popular Host Names 171 mars 108 gauss 93 earth 83 hermes 74 europa 68 polaris 169 venus 107 opus 93 athena 82 moe 74 bach 68 odin 168 pluto 107 newton 90 larry 81 sneezy 73 uranus 67 sparky 147 jupiter 104 grumpy 89 titan 81 mozart 71 math 67 maxwell 138 zeus 103 sirius 89 sleepy 81 gandalf 71 falcon 66 pc2 138 mercury 103 gw 89 fred 80 vega 71 alpha 66 bashful 134 iris 100 merlin 87 doc 80 mickey 70 spock 66 altair 133 cs 97 eagle 85 dopey 80 astro 70 pollux 65 ra 130 orion 97 calvin 84 rigel 79 happy 70 pegasus 65 curly 125 saturn 96 thor 84 phoenix 79 cisco 70 hydra 65 castor 123 neptune 96 sol 84 io 78 helios 70 frodo 64 max 117 hobbes 96 apollo 83 snoopy 75 hal 69 euler 64 gemini ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101719405900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 11:58:57 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA20368; Wed, 17 Oct 90 15:07: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: 17 Oct 90 19:40:59 GMT From: rogue.llnl.gov!oberman@lll-winken.llnl.gov Subject: Re: The network Message-Id: <1990Oct17.124059.1@rogue.llnl.gov> References: <9010170419.AA01909@WLV.IMSD.CONTEL.COM>, <9010171715.AA01958@server.af.mil> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010171715.AA01958@server.af.mil>, tcpip@server.af.mil (mailing list) writes: > > I don't know that that means you can get it from the NIC, however. I am > sure that I did not get it from the NIC myself. I also remember that I got > this "map" early this year, and it hadn't been revised since 88. If > anyone does run across a really current one, I'd be interested in seeing > how well it reflects our af.mil reality (:-> The file (in PostScript) is available from nic.ddn.mil. It is netinfo:domain-chart.ps. It has not been updated since it was created in Sept. 1988. It is quite large and prints about 20 pages as I recall. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101719452100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 13:06:21 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21930; Wed, 17 Oct 90 16:13: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: 17 Oct 90 19:45:21 GMT From: portal!cup.portal.com!Will@apple.com (Will E Estes) Organization: The Portal System (TM) Subject: Can One API Support Both TCP/IP and LU 6.2? Message-Id: <34953@cup.portal.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Do TCP/IP and and IBM's LU 6.2 share enough in common as peer-to-peer protocols that it would be possible to build a single API on top of both? I have heard some discussion that IBM's Common Programming Interface - Communications (CPI-C) might evolve into such an approach. Obviously one impediment to a common API is that the two protocols use different naming systems, but assuming you could bridge that difference are the protocols - as protocols only - semantically and syntactically similar enough that one could build a generic model that bridges the two? Thanks, Will Estes (sun!portal!cup.portal.com!Will) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101720100800> Received: from inria.inria.fr by NIC.DDN.MIL with TCP; Wed, 17 Oct 90 11:07:19 PDT Received: from bull.bull.fr by inria.inria.fr (5.64+/89.0.8) via Fnet-EUnet id AA27777; Wed, 17 Oct 90 19:07:59 +0100 (MET) Received: from mybull.my.bull.fr by bull.bull.fr; Wed, 17 Oct 90 18:28:45 +0100 (MET) Received: by mybull.my.bull.fr ; Wed, 17 Oct 90 18:29:44 +0100 (MET) Received: by masbull.my.bull.fr (BULLNET-1.2); Wed, 17 Oct 90 18:30:08 +0100 (MET) Date: Wed, 17 Oct 90 18:30:08 +0100 From: marge@masbull.my.bull.fr (Alain Margeride) Message-Id: <9010171730.AA17315@masbull.my.bull.fr> To: tcp-ip@nic.ddn.mil Does anyone know of a product that supports DOS diskless station on TCP/IP with UNIX server using TFTP and BOOTP. Alain MARGERIDE BULL email: margeride@my.bull.fr ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101722245000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 13:37:41 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26018; Wed, 17 Oct 90 19:46: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: 17 Oct 90 22:24:50 GMT From: bionet!synoptics!sblair@apple.com (Steven Blair) Organization: SynOptics Communications Inc. Mountain View, Ca. Subject: Re: Message-Id: <1990Oct17.152450@synoptics.com> References: <9010171730.AA17315@masbull.my.bull.fr>, <656195059.375947.VANCE@TGV.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I've tried to respond to the poster, but was unsuccessful. Here's another: Espirit Systems Inc. (408)954-9900 I used to have a friend there, but he quit. Never used their product(s), but know that they're diskless PC's.... -- Steven C. Blair Network Operations Center SynOptics Communications Inc. Mountain View, California INTERNET: sblair@synoptics.com sblair@excalibur.synoptics.com PROBLEMS/EMAIL: HOSTMASTER@SYNOPTICS.COM postmaster@synoptics.com ---->>RIP Stevie Ray Vaughan 1954-1990 You Will Be *Missed*<<---- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1990Oct17.191507@cs.Buffalo.EDU] <1990101723150700> From: palter@cs.Buffalo.EDU (Bill Palter) Newsgroups: comp.protocols.tcp-ip,comp.os.vms Subject: Re: WIN$LPD on VMS Message-ID: <1990Oct17.191507@cs.Buffalo.EDU> Date: 17 Oct 90 23:15:07 GMT References: <1AAD8E9AD8BF401F39@CRL.AECL.CA> Sender: news@acsu.Buffalo.EDU Reply-To: palter@twg.com Organization: The Wollongong Group Lines: 23 Posted: Thu Oct 18 00:15:07 1990 Nntp-Posting-Host: sybil.cs.buffalo.edu Originator: palter@sybil.cs.Buffalo.EDU In article <1AAD8E9AD8BF401F39@CRL.AECL.CA>, TANNERC@CRL.AECL.CA (CHRISTOPHER TANNER) writes: > Greetings > Using Wollongong's version of LPD on VMS, is it possible to specify parameters > for the VMS PRINT commands such as /FLAG and /FORM=xxx? I would like an > lpr -Pxx (on UNIX) to become PRINT /Q=xx/FLAG/FORM=yy on the VMS system. Yes it is, for some reason the text of the /FORM qualifier was omitted from the documentation. In your printcap entry for the printer just specify /FORM=formname. /FLAG is more difficult, since it is basicly useless due to the fact that the filename that would be displayed on it is the name of the spool file and not that of the file that was printed. But if you want it you could take the sample USRJBC procedure from the manual and change the text of the USRJBC_OPEN routine to be: jbc_info.flags |= LPDSMB_M_FILE_FLAG; This with change the attributes of the print job to /FLAG when it is created in the VMS print queue. Bill Palter The Wollongong Group palter@twg.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101800250100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 13:38:29 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00972; Thu, 18 Oct 90 00:00: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: 18 Oct 90 00:25:01 GMT From: ubc-cs!van-bc!mdivax1!zintel@beaver.cs.washington.edu Organization: Mobile Data International, Richmond, B.C., Canada Subject: Redirecting console IO Message-Id: <1990Oct18.002501.2673@mdivax1.uucp> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am developing software on a SPARC for a Motorola delta 3400 System V box. Both boxes are on an ethernet. I am using rsh and rlogin to copy files and run tests. I would like to be able to access the console (hardware port 0) of the delta box in a window under sun-os. Any hints would be greatly appreciated. -- Mike Zintel It is wiser to be kind than to be wise. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101800351000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 14:25:08 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00499; Wed, 17 Oct 90 23:38: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: 18 Oct 90 00:35:10 GMT From: netcom!jbreeden@apple.com (John Breeden) Organization: Netcom- The Bay Area's Public Access Unix System {408 241-9760 guest} Subject: Re: NCSA TELNET / BANYAN Message-Id: <15052@netcom.UUCP> References: <9010171533.AA22340@ftp.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010171533.AA22340@ftp.com> jbvb@ftp.com writes: >I have heard rumors of VINES which can use NDIS, and if you could get >it, this could be combined with the NDIS-Packet Driver adapter to use >freeware. If this is in fact a feature of their 4.0 release, I have >been told it will be available sometime this winter. > The multi-protocol NDIS interface for Vines 4.0 is available from Banyan N/C - it's patch # 1W. James' NDIS-Packet driver adapter works with Vines 4.0 P1W and cutcp or ka9q. -- 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---- <1990101803340900> Received: from NNSC.NSF.NET (WS6.NNSC.NSF.NET) by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 07:15:46 PDT To: tcp-ip@nic.ddn.mil To: ietf@isi.edu Subject: SIGCOMM '90 materials From: Craig Partridge Date: Thu, 18 Oct 90 10:14:09 -0400 Sender: craig@NNSC.NSF.NET Hi folks: I'm getting queries about the SIGCOMM '90 proceedings and hope this note will help reduce the flow. If you are a member of ACM SIGCOMM, you should receive the proceedings in the mail any day now. If you are not a member of ACM SIGCOMM you can order a copy of the proceedings from the ACM Order Dept at 1-800-342-6626. The item number is 533900. Also, yes there are some extra copies of the notes for the tutorial on high speed networking given by Van Jacobson and Harry Rudin. CNRI is processing orders -- send a note to Lisa Duncan (lduncan@nri.reston.va.us) for pricing and shipping info. Craig PS: Unfortunately, we're out of T-shirts... :-) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101803362800> Received: from ub.d.umn.edu by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 06:33:42 PDT Received: by ub.d.umn.edu (5.59/UMD-891211) id AA24761; Thu, 18 Oct 90 08:36:29 CDT From: wmarko@ub.d.umn.edu (William J. Marko) Message-Id: <9010181336.AA24761@ub.d.umn.edu> Subject: please use the d key To: tcp-ip@nic.ddn.mil (tcp-ip group) Date: Thu, 18 Oct 90 8:36:28 CDT X-Mailer: ELM [version 2.3 PL5] please excuse...just a test -- Bill Marko wmarko@ub.d.umn.edu internet UMD Information Services wmarko@umndul bitnet 10 University Drive 218-726-8842 work Duluth, MN 55812 218-724-7617 home ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101805304300> Received: from uga.cc.uga.edu by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 06:30:03 PDT Received: from rigel.econ.uga.edu by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with TCP; Thu, 18 Oct 90 09:30:00 EDT Received: from sirius.econ.uga.edu by rigel.econ.uga.edu (4.0/25-eef) id AA16787; Thu, 18 Oct 90 09:30:01 EDT Received: by sirius.econ.uga.edu (4.0/SMI-4.0) id AA06061; Thu, 18 Oct 90 09:30:43 EDT Date: Thu, 18 Oct 90 09:30:43 EDT From: glenn@sirius.econ.uga.edu (Glenn F. Leavell) Message-Id: <9010181330.AA06061@sirius.econ.uga.edu> To: TCP-IP%NIC.DDN.MIL@uga.cc.uga.edu Subject: Re: Domain Survey Results Thanks! That's interesting. I see that 'rigel' is the 33rd most popular host name. You can't beat the originality. --Glenn ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101805592200> Received: from po.cis.brown.edu by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 09:39:03 PDT Received: from cis_staff-kntx29.cis.brown.edu by po.cis.brown.edu (5.61/2.1) id AA14322; Thu, 18 Oct 90 12:39:22 -0400 Date: Thu, 18 Oct 90 12:39:22 -0400 From: Steven_Carmody@brown.edu Message-Id: <9010181639.AA14322@po.cis.brown.edu> To: TCP-IP@NIC.DDN.MIL Subject: SNMP monitors WeUre in the process of looking at SNMP based monitors, and expect to use one to monitor gateways and services in the campus network. ThereUs a discussion starting in this digest which seems headed toward developing a RscorecardS comparing many of the currently available products. I think everyone will benefit if the community creates a such a yardstick. However, in an interest in getting our site moving, and at the great risk of oversimplification, IUd like to get a sense of whatUs out there. So far, I can see three groups of products: 1) the PC-based monitors (wollongong, the recently announced novell one, etc), 2) the NyserNet/PSI monitor, and 3) a large number of commercially available, UNIX based monitors (often from router vendors). IUve separated 2 and 3 because the NyserNet package is available to universities for approximately 1/10 the cost of the packages in category 3. The question is -- are there any generalizations which can be made about each of the categories? can the PC-based packages handle a large campus sized network? are there major problems with the NyserNet monitor that the packages in category 3 have corrected? Any info and experiences would be appreciated. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101806220000> Received: from nprdc.navy.mil by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 13:20:42 PDT Received: from atlantic.nprdc.navy.mil by nprdc.navy.mil (5.59/SMI-4.0) id AA27246; Thu, 18 Oct 90 13:20:06 PDT Received: by atlantic.nprdc.navy.mil (4.1/SMI-4.0) id AA25195; Thu, 18 Oct 90 13:22:08 PDT From: stanonik@nprdc.navy.mil (Ron Stanonik) Message-Id: <9010182022.AA25195@atlantic.nprdc.navy.mil> Date: 18 October 1990 1322-PDT (Thursday) To: tcp-ip@nic.ddn.mil Subject: 4.3bsd/watching icmp traffic Reply-To: stanonik@nprdc.navy.mil We've modified a copy of 4.3bsd ping to just watch icmps received; ie, not ping, just watch. We've got it running on our gateway, a vax running 4.3bsd. We'd also like to see icmps being forwarded through the vax. Any suggestions? Maybe using some socket type other than SOCK_RAW? Or maybe 4.3bsd just doesn't give applications a chance to get their hands on packets being forwarded? Thanks, Ron Stanonik stanonik@nprdc.navy.mil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101809555000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 19:32:30 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24592; Thu, 18 Oct 90 17:55: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: 18 Oct 90 09:55:50 GMT From: psuvm!barilvm!p88036@psuvax1.cs.psu.edu Organization: Bar-Ilan University Computing Center, Israel Subject: station name Message-Id: <90291.115550P88036@BARILVM.BITNET> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi, here is my question: Is there a way to get the name of the station I actually logged in from, ( this can be an X terminal or another workstation) so that I could direct Xwindows output to this screen in some automatic way ? Any information will be appriciated. Ephraim. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101810461900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 19:43:24 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA28501; Thu, 18 Oct 90 19:33: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: 18 Oct 90 10:46:19 GMT From: mcsun!ub4b!dg13!pnoe@uunet.uu.net (Pierre Noel) Organization: Commission of European Communities - DG 13 Subject: Enormous difference of speed between PC/TCP and PCNFS Message-Id: <1990Oct18.104619.13394@dg13.cec.be> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi NetLand, I made a program using socket protocols under TCP/IP Ethernet, to communicate with a Unix Server (in that case, SCO-ODT Unix on a Olivetti's XP9 with a 3COM's 3C503 Ethernet Card), I also made the Server part of the protocol then I can control both sides of the problem. My problem seems to be in the client side of the program : due to our site configuration, I gave two versions of the product, one for PC/TCP (Release 2.04) and the other for PC-NFS (Release 3.01). The main purpose of the application is to download lot of files (2/3 Mbytes each time) from the Server to the Client requesting them; the download is segmented, at the socket level, in records of 1024 bytes each, using the send() and recv() function calls. The sources of the PC/TCP and PC-NFS application are excactly the same, only the libraries linked to are different. I made test on the same machine (Olivetti M300 with a 3COM 3C501 Ethernet Card), the result is absolutely uncomprehensible : the relation between the time spent by the PC/TCP and the PC-NFS application is about 1 to 10 !!! I've checked where was the problem and what I've seen is that the difference of performance is located in the time spent between reception of records. I've also encountered the same kind of problem with PC-NFS when trying to rcp multiple small file one after another : the 2 firsts were transmitted ok but theother ones had also big delay. My question is : do someone has knowledge of similar problem and do you know if it is possible to tune the product to have acceptable performance ? I know that the solution is maybe changing all our PC-NFS to PC/TCP but as our park is about 700 PCs and our needs for the application are really urgent, it must not be the right solution now. I would be very happy to receive clues. Thank you for your attention and apologies for spelling mistakes Pierre Noel pnoe@dg13.cec.be ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101812271800> Received: from hitl.vrnet.washington.edu by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 19:28:39 PDT Received: by hitl.vrnet.washington.edu (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.19 ) id AA05271; Thu, 18 Oct 90 19:27:18 PDT Date: Thu, 18 Oct 90 19:27:18 PDT From: David Doll Message-Id: <9010190227.AA05271@hitl.vrnet.washington.edu> To: craig@nnsc.nsf.net Cc: tcp-ip@nic.ddn.mil, ietf@isi.edu In-Reply-To: Craig Partridge's message of Thu, 18 Oct 90 10:14:09 -0400 <9010181736.AA04762@hitl.vrnet.washington.edu> Subject: SIGCOMM '90 materials So can you let us know when there are more t-shirts? :) David Doll Programmer/Analyst Human Interface Technology Lab FU - 20 Seattle, WA 98195 (206) 543-5075 davidd@hitl.vrnet.washington.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010201814.AA22561@ucbvax.Berkeley.EDU] <1990101812532900> From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) Newsgroups: comp.protocols.tcp-ip Subject: load sharing telnet/rlogin/route to mainframe Message-ID: <9010201814.AA22561@ucbvax.Berkeley.EDU> Date: 18 Oct 90 12:53:29 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 24 Posted: Thu Oct 18 13:53:29 1990 we have a mainframe with a lot of timesharers who rlogin/telnet from workstations - the mainframe ethernet i/f is a bit slow so we've put several on the machine... can we set up clients so that they pick which i/f to route to uniform random, or even deterministically - we dont want users to know and we dont want to hack rlogin (we've done this before the other way round to loadsare users round a lot of workstations)... could we magic it up by setting a route metric differently for each of the masionframes i/f IP addressses in different clients perhaps? (routing seems the natural place to add loadsharing) but remembering they are all on same net & even subnet...(i.e. add a host route for each i/f/?)? what have other people done (and no humerous remarks about buy a different mainframe or get different i/fs we didnt really have a choice:-) ? thanks jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101813405500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 19:32:13 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26643; Thu, 18 Oct 90 18:47: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: 18 Oct 90 13:40:55 GMT From: shlump.nac.dec.com!shug.enet.dec.com!ciarfella@decuac.dec.com (Paul Ciarfella) Organization: Digital Equipment Corporation Subject: Does ICMP optional data include IP header + options? Message-Id: <16468@shlump.nac.dec.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does the Internet header + 64 bits of data copied into the data field of an ICMP error message include the options from the original IP packet (if present), ie., data = IP header + options + 64 bits of data or data = IP header + 64 bits of data Thanks, Paul C --------------------------------------------------------------------------- Paul Ciarfella Digital Equipment Corporation Littleton, MA --------------------------------------------------------------------------- Disclaimer : My opinions are my own. | When in doubt, mumble. Address : ciarfella@shug.enet.dec.com --------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101814442000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 19:29:53 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27510; Thu, 18 Oct 90 19:08: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: 18 Oct 90 14:44:20 GMT From: princeton.edu!tengi@princeton.edu (Christopher Tengi) Subject: Re: in-addr.arpa used? Message-Id: <3430@idunno.Princeton.EDU> References: <9010091715.AA05649@ucbvax.Berkeley.EDU>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil If you are going to get them to implement in-addr.arpa on your local nameserver, don't forget to have them get authority delegeted to them from the NIC. ie Princeton has authority for Princeton.EDU and 112.128.in-addr.arpa. /Chris -- ==========----------==========---------+---------==========----------========== UUCP: ...princeton!tengi VOICEnet: 609-258-6799 INTERNET: tengi@princeton.edu FAX: 609-258-3943 BITNET: TENGI@PUCC ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101815332900> Received: from bells.cs.ucl.ac.uk by NIC.DDN.MIL with TCP; Sat, 20 Oct 90 08:01:06 PDT Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <19179-0@bells.cs.ucl.ac.uk>; Thu, 18 Oct 1990 13:53:30 +0100 To: tcp-ip@nic.ddn.mil Subject: load sharing telnet/rlogin/route to mainframe Date: Thu, 18 Oct 90 13:53:29 +0100 From: Jon Crowcroft we have a mainframe with a lot of timesharers who rlogin/telnet from workstations - the mainframe ethernet i/f is a bit slow so we've put several on the machine... can we set up clients so that they pick which i/f to route to uniform random, or even deterministically - we dont want users to know and we dont want to hack rlogin (we've done this before the other way round to loadsare users round a lot of workstations)... could we magic it up by setting a route metric differently for each of the masionframes i/f IP addressses in different clients perhaps? (routing seems the natural place to add loadsharing) but remembering they are all on same net & even subnet...(i.e. add a host route for each i/f/?)? what have other people done (and no humerous remarks about buy a different mainframe or get different i/fs we didnt really have a choice:-) ? thanks jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101816215000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 23:43:31 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07672; Thu, 18 Oct 90 23:39: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: 18 Oct 90 16:21:50 GMT From: hpda!hpcuhb!hpindda!subbu@ucbvax.Berkeley.EDU (MCV Subramaniam) Organization: HP Information Networks, Cupertino, CA Subject: Re: single tcpcb loopback bug Message-Id: <6200036@hpindda.cup.hp.com> References: <19897@frog.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >This seems to be a previously unpublished bug. Yes, it is unpublished, but not unreported. We, at HP have found this bug in 4.3 BSD, and have submitted a fix to Mike Karels. You may not believe it, but 4.3 BSD cannot handle crossing SYNs! (i.e. if two 4.3 machines send SYN to each other and they cross each other, the machines will go in an infinite loop sending SYN|ACKs to each other). Connecting to the same port number causes a similar situation to happen. You send a SYN and go into SYN_SENT state, and you receive the SYN while in SYN_SENT state! The fix involves handling a SYN correctly while in the SYN_SENT state. >I suspect that a workable fix is to use the tcpcb's ISN when sending >any SYN, although I haven't tried this yet. However, the failure to >do this ought to have generated a RST, IMHO, so I guess there are >actually two bugs here. The ISN is already used while sending a SYN. -Subbu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101816420000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 19:40:39 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA28344; Thu, 18 Oct 90 19:29: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: 18 Oct 90 16:42:00 GMT From: csusac!csuchico.edu!csuchico.edu!robin@ucdavis.ucdavis.edu (Robin Goldstone) Organization: California State University, Chico Subject: question about SMTP MX records Message-Id: <1990Oct18.164200.5699@ecst.csuchico.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am trying to send a message to someone@applelink.apple.com. This host has no TYPE A record, only an MX record. My mailer currently cannot resolve MX records. As a workaround, I thought I would just send to someone%applelink.apple.com@apple.com. It is my (limited) understanding that addresses are parsed from right to left, so this message would be sent to apple.com, who would then be able to forward it to applelink.apple.com. Some questions: 1) is the syntax of the address I am trying to use valid? 2) am I violating any network rules by routing my message through another host? 3) should this message be getting delivered? I have sent several test messages that have disappeared into a black hole... Thanks in advance for any help you can provide! Robin Goldstone, Systems Software Specialist California State University, Chico Computing Services robin@csuchico.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101818524900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 22:45:45 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05500; Thu, 18 Oct 90 22:39: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: 18 Oct 90 18:52:49 GMT From: cunixf.cc.columbia.edu!cs.columbia.edu!ji@rutgers.edu (John Ioannidis) Organization: Columbia University Department of Computer Science Subject: Re: File Broadcast Message-Id: <1990Oct18.185249.216@cs.columbia.edu> References: <45509@apple.Apple.COM>, <72341@sgi.sgi.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >In article <45509@apple.Apple.COM> erekose@apple.com (Erik Scheelke) writes: > > We have a local area network of UNIX based PCs running TCP-IP, and I > was asked if there was any software that will broadcast a file to all > machines on the network. I didn't know of any and was wondering if > anyone out there in netland knew of any. If not, I guess I will have > to write something myself. I would appreciate any infomation about > programs or algorithms that do file broadcasting. It must use a broadcast, > not a copy to one machine then copy to another method (i.e. UDP), and > if a machine is up it must reliably send the file. > > We have written a protocol we call "A Coherent File Transfer Protocol" (RFC number pending). The idea is that the server broadcasts packets from a file, and all the clients grab them as they fly by. If they miss any, they send block requests to the server. We are in the process of polishing the reference port, which will be available from cs.columbia.edu [128.59.16.20] for anonymous ftp. Watch this space! /ji In-Real-Life: John "Heldenprogrammer" Ioannidis E-Mail-To: ji@cs.columbia.edu V-Mail-To: +1 212 854 8120 P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101818563800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 17:58:49 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24327; Thu, 18 Oct 90 17:49: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: 18 Oct 90 18:56:38 GMT From: pyramid!lstowell@hplabs.hpl.hp.com (Lon Stowell) Organization: Pyramid Technology Corp., Mountain View, CA Subject: Re: Can One API Support Both TCP/IP and LU 6.2? Message-Id: <130905@pyramid.pyramid.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Yes, you can build a common API. CPI-C on the AS/400 is such a product, you can run TCP/IP, OSI, SNA from the same API. The difficulty in naming conventions is hidden in the fine print of such API's....as are the other differences in these protocol stacks. All of them provide essentially similar services, but the LAYER within which a specific service is performed as well as the implementation method varies widely. The IBM technique is to note that all of the naming, route discovery, etc. methods are "implementation specific" and that they are utility functions performed by the Physical Unit. Not only do the naming conventions of LU 6.2 differ from TCP/IP, the techniques for route discovery and routing differ as well. About the only thing the two have in common is the ability to provide a high level common API. Such a "generic" API implementation will never be as efficient as a protocol specific one, but it sure makes things a LOT easier on programmers, user's etc. RAM is cheap, and MIPS are always available. Programmer's blood pressure and sanity are a little more precious..... /| \'o.O' =(___)= U THPTH! ACKHH! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101821590300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 18 Oct 90 23:15:54 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06116; Thu, 18 Oct 90 22:56: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: 18 Oct 90 21:59:03 GMT From: harvisr!sob@husc6.harvard.edu (Scott Bradner) Organization: Harvard University, Cambridge MA Subject: router tests volume 3 Message-Id: <4471@husc6.harvard.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Well here it is, the results of the 3rd round of router testing. This round consists of local Ethernet to Ethernet routers, all of them I could get. This document is copyright 1990 by Scott Bradner. You can repoduce this posting in any way you want as long as the copy is complete with no modifications. A set of files for the slides that I used in the InterOp report are on husc6.harvard.edu in pub/rtests (the old stuff is in "old"), lots of nice graphs etc. Scott Bradner, Harvard University, 33 Kirkland St., Cambridge MA 02138 (617)495-3864, sob@harvard.edu First some history: I got a call from Wellfleet back in August wondering if I was going to go through another round of tests. I said that I did not have the required equipment, since many of the vendors now had equipment that was faster than the test setup we had used last year. "We will give you some equipment to do your tests." he said. "Well..." said I, "how about a loan?", "Sure" he said. So after some discussion they agreed to loan me some of the equipment that they were using for in house testing. They also agreeed to provide access to Terry Bradley who had done all the programming on the test bed. (I, naturally, wanted some changes in the test software.) Terry spent quite a while making the changes I requested and getting out a number of small bugs, and I sent out a call for equipment to be tested. I got back quite a few devices and herein report the results of the tests. All but one of the vendors sent a person along with the router to do setup. (So I would not have to read all those manuals and set the things up wrong in the end.) The tests for each of the devices were done over one or two days at a lab at Harvard. The test setup: A modified Wellfleet router was used a a test source. This device had two separate channels of test traffic. Each channel consisted of one packet source port and one "keep alive" port. The "keep alive" port sent out groups of frames designed to convince the router that a node existed on this "net" that spoke some specific protocols. The supported protocols were: IP ( keep alive was a ARP response) DECNET (hello packet) AppleTalk II (AARP packet) IPX (IPX-RIP? response) bridge mode ( a packet with a specific source MAC address) The device-to-be-tested was attached so that an "input" port was attached to one of the test frame sources and an "output" port was attached to the corresponding "keep alive" port. If the device had four or more ports, both sets of test channels were used. The modified Wellfleet router generated a stream of test frames consisting of a specific number of frames, in a selected protocol, of a selected size and with a selected interframe gap (ifg). One of the test channels (channel 3) was used for all of the tests and the 2nd channel was used only for the dual stream test. test source frame rate: size theoretical channel "3" channel "4" 64 14880 14489 14549 128 8445 8324 8340 256 4528 4494 4498 512 2349 2340 2341 1024 1197 1195 1195 1518 812 812 812 (The Wellfleet test code can do quite a bit more than I made use of, it can generate mixed protocol packet streams for example, additional work needs to be done to create a set of test specifications that better emulate a "real" data network.) The counter: A HP 4972A Lan Protocol Analyzer was used to find the frame rates and to count the output frames. The HP ran the "stats" program to monitor the network. The router configuration: The router was configured at the start of the test suite and the configuration was not changed throughout the first set of tests. The configuration was then altered to add a single "filter" condition, tests were run on that, then the configuration was changed to add 9 more filter conditions and tests were run on that. The bridge tests were configured for and run separately. The tests: Note: The design of these tests comes from the work of the IETF Benchmarking Methodology Working Group. single channel: "delay" Aim - find delay through router. A Tektronix 2337 scope was attached to both the input and output router ports. A stream of frames with a large ifg was sent through the router. The scope was used to measure the time delay between the end of the input frame and the start of the output frame. "raw rate" Aim - find out impact of max rate input data rate. The HP was connected to the "output" port of the router. A stream of frames of a specific protocol and a specific size with the minimum ifg, was sent to the input port on the router. The number of frames was selected to produce about 30 sec of data stream. The "stats" program was reset after the start of the data stream and the "10 sec avg" value was watched to get the "raw rate". "max rate" Aim - find highest rate at which router passes 100% of input frames. The HP was connected to the "output" port of the router. A stream of frames of a specific protocol and a specific size with a selected inter frame gap, was sent to the input port on the router. The number of frames was selected to produce about 20 sec of data stream. The "stats" program was reset before the data stream was started. The "total frames" value was used to see if all of the offered frames were forwarded. If not, the ifg was increased, if yes the ifg was reduced. This process was followed until the point at which a reduction of "1" in the ifg would not pass all the frames. The HP was then attached to the frame source and the test rerun with the determined ifg to get the frame rate. "dual stream" Aim - find effect of more than one data stream through router. "raw rate" test run but with both frame sources sending frames with the minimum ifg. The HP was first connected to one "output", a test was run to find the rate, then the HP was moved to the other output and the test rerun. NOTE: this test is flawed, the "right" way to do this is the same as for the "max rate" test, putting the same frame rate into both inputs and counting the outputs. But this was just to much work, strong need for automation. Some nomenclature: "one filter" permit traffic from ip address 192.32.100.1 to 192.32.200.1 "10 filter" permit traffic from ip address 192.32.100.11 to 192.32.200.11 permit traffic from ip address 192.32.100.12 to 192.32.200.12 permit traffic from ip address 192.32.100.13 to 192.32.200.13 permit traffic from ip address 192.32.100.14 to 192.32.200.14 permit traffic from ip address 192.32.100.15 to 192.32.200.15 permit traffic from ip address 192.32.100.16 to 192.32.200.16 permit traffic from ip address 192.32.100.17 to 192.32.200.17 permit traffic from ip address 192.32.100.18 to 192.32.200.18 permit traffic from ip address 192.32.100.19 to 192.32.200.19 permit traffic from ip address 192.32.100.1 to 192.32.200.1 "between interface cards" for the single channel tests means a data stream that goes in a port on one Ethernet interface card and out a port on a 2nd Ethernet interface card. "within interface card" for the single stream tests means a data stream that goes in a port on an Ethernet interface card and out on another port on the same card. "between interface cards" for the dual stream tests means two data streams, both of which come in ports on one Ethernet interface card and both of which exit from ports on a 2nd Ethernet interface card. "within interface card" for the dual stream tests means one data stream that comes in a port on one Ethernet interface card and exits via another port on the same card, and a 2nd stream that enters on one port on a separate Ethernet interface card and exits via a 2nd port on this separate card. The results: (I have checked these numbers but there may be transcription or typing errors.) 3com NETBuilder - TCP/IP - within interface card size theo test ip_max ip_fld 64 14880 14489 6404 6401 128 8445 8324 6648 6553 256 4528 4494 4004 3953 512 2349 2340 2202 2183 1024 1197 1195 1010 1153 1518 812 812 799 792 3com NETBuilder - Bridge Mode - within interface card size theo test br_max br_fld 64 14880 14489 9830 9750 128 8445 8324 6735 6564 256 4528 4494 3994 3953 512 2349 2340 2202 2183 1024 1197 1195 1159 1153 1518 812 812 805 792 BBN T20 - TCP/IP - within interface card size theo test ip_max ip_fld 1f_max 1f_fld 10f_max 10f_fld 64 14880 14489 4315 4664 2620 2778 2620 2775 128 8445 8324 4339 4654 2433 2777 2433 2777 256 4528 4494 4493 4493 2231 2772 2231 2774 512 2349 2340 2340 2340 2340 2340 2340 2340 1024 1197 1195 1194 1194 1194 1194 1194 1194 1518 812 812 811 811 811 811 811 811 cisco AGS+ - TCP/IP - between interface cards size theo test ip_max ip_fld 1f_max 1f_fld 10f_max 10f_fld 64 14880 14489 14488 14488 14488 14488 14488 14488 128 8445 8324 8324 8324 8324 8324 8324 8324 256 4528 4494 4493 4493 4494 4494 4494 4494 512 2349 2340 2340 2340 2340 2340 2340 2340 1024 1197 1195 1194 1194 1195 1195 1195 1195 1518 812 812 811 811 812 812 812 812 cisco AGS+ - AppleTalk II - between interface cards size theo test at2_max at2_fld 64 14880 14489 14488 14488 128 8445 8324 8324 8324 256 4528 4494 4494 4494 512 2349 2340 2340 2340 cisco AGS+ - DECNET - between interface cards size theo test dn_max dn_fld 64 14880 14489 13097 13270 128 8445 8324 8324 8324 256 4528 4494 4494 4494 512 2349 2340 2340 2340 1024 1197 1195 1195 1195 1518 812 812 812 812 cisco AGS+ - IPX - between interface cards size theo test ipx_max ipx_fld 64 14880 14489 14488 14488 128 8445 8324 8324 8324 256 4528 4494 4494 4494 512 2349 2340 2340 2340 1024 1197 1195 1195 1195 1518 812 812 812 812 cisco AGS+ - Bridge Mode - between interface cards size theo test br_max br_fld 64 14880 14489 14488 14488 128 8445 8324 8324 8324 256 4528 4494 4494 4494 512 2349 2340 2340 2340 1024 1197 1195 1195 1195 1518 812 812 812 812 cisco AGS+ - Dual IP Streams - between interface cards size theo test1 test2 d1_fld d2_fld 64 14880 14489 14549 9682 9700 128 8445 8324 8340 8324 8340 256 4528 4494 4498 4493 4498 512 2349 2340 2341 2340 2341 1024 1197 1195 1195 1194 1195 1518 812 812 812 812 812 cisco AGS+ - TCP/IP - within interface card size theo test ip_max ip_fld 1f_max 1f_fld 10f_max 10f_fld 64 14880 14489 14488 14488 14488 14488 14488 14488 128 8445 8324 8324 8324 8324 8324 8324 8324 256 4528 4494 4494 4494 4494 4494 4494 4494 512 2349 2340 2340 2340 2340 2340 2340 2340 1024 1197 1195 1195 1195 1194 1194 1194 1194 1518 812 812 812 812 811 811 811 811 cisco AGS+ - AppleTalk II - within interface card size theo test at2_max at2_fld 64 14880 14489 14488 14488 128 8445 8324 8324 8324 256 4528 4494 4494 4494 512 2349 2340 2340 2340 cisco AGS+ - DECNET - within interface card size theo test dn_max dn_fld 64 14880 14489 13097 13256 128 8445 8324 8323 8323 256 4528 4494 4494 4494 512 2349 2340 2340 2340 1024 1197 1195 1195 1195 1518 812 812 812 812 cisco AGS+ - IPX - within interface card size theo test ipx_max ipx_fld 64 14880 14489 14488 14488 128 8445 8324 8324 8324 256 4528 4494 4494 4494 512 2349 2340 2340 2340 1024 1197 1195 1195 1195 1518 812 812 812 812 cisco AGS+ - Bridge Mode - within interface card size theo test br_max br_fld 64 14880 14489 14488 14488 128 8445 8324 8324 8324 256 4528 4494 4494 4494 512 2349 2340 2340 2340 1024 1197 1195 1195 1195 1518 812 812 812 812 cisco AGS+ - Dual IP Streams - within interface card size theo test1 test2 d1_fld d2_fld 64 14880 14489 14549 9689 9698 128 8445 8324 8340 8323 8340 256 4528 4494 4498 4494 4498 512 2349 2340 2341 2340 2341 1024 1197 1195 1195 1194 1195 1518 812 812 812 812 812 Network Systems Corporation EN640-8 - TCP/IP - between interface cards size theo test ip_max ip_fld 1f_max 1f_fld 10f_max 10f_fld 64 14880 14489 6327 6233 4636 4413 1718 1670 128 8445 8324 5105 5189 4111 3875 1629 1576 256 4528 4494 3755 3752 3745 3756 1599 1536 512 2349 2340 2124 2123 2122 2123 1565 1493 1024 1197 1195 1137 1136 1138 1138 1141 1135 1518 812 812 786 784 787 786 788 784 Network Systems Corporation EN640-8 - AppleTalk II - between interface cards size theo test at2_max at2_fld 64 14880 14489 827 0 128 8445 8324 808 0 256 4528 4494 770 0 512 2349 2340 702 269 Network Systems Corporation EN640-8 - DECNET - between interface cards size theo test dn_max dn_fld 64 14880 14489 919 0 128 8445 8324 886 0 256 4528 4494 825 0 512 2349 2340 727 280 1024 1197 1195 588 452 1518 812 812 443 381 Network Systems Corporation EN640-8 - Dual IP Streams - between interface cards size theo test1 test2 d1_fld d2_fld 64 14880 14489 14549 3224 3396 128 8445 8324 8340 2832 2975 256 4528 4494 4498 2638 2651 512 2349 2340 2341 2335 2123 1024 1197 1195 1195 1138 1195 1518 812 812 812 786 812 Network Systems Corporation EN640-8 - TCP/IP - within interface card size theo test ip_max ip_fld 1f_max 1f_fld 10f_max 10f_fld 64 14880 14489 5986 6604 4775 4630 1732 1702 128 8445 8324 5259 5732 4605 4164 1662 1629 256 4528 4494 3727 3757 3729 3641 1541 1523 512 2349 2340 2128 2123 2122 2123 1508 1450 1024 1197 1195 1140 1138 1139 1135 1139 1135 1518 812 812 788 784 788 783 780 782 Network Systems Corporation EN640-8 - AppleTalk II - within interface card size theo test at2_max at2_fld 64 14880 14489 828 0 128 8445 8324 805 0 256 4528 4494 767 0 512 2349 2340 701 266 Network Systems Corporation EN640-8 - DECNET - within interface card size theo test dn_max dn_fld 64 14880 14489 919 0 128 8445 8324 885 0 256 4528 4494 826 0 512 2349 2340 719 278 1024 1197 1195 580 453 1518 812 812 439 381 Novell NetWare 386 - TCP/IP - between interface cards size theo test ip_max ip_fld 64 14880 14489 3275 3270 128 8445 8324 3207 3202 256 4528 4494 2892 2856 512 2349 2340 1822 1764 1024 1197 1195 1050 1030 1518 812 812 744 731 Novell NetWare 386 - IPX - between interface cards size theo test ipx_max ipx_fld 64 14880 14489 3295 3240 128 8445 8324 3274 3172 256 4528 4494 2953 2852 512 2349 2340 1861 1768 1024 1197 1195 1078 1031 1518 812 812 787 731 Proteon P4200 - TCP/IP - between interface cards size theo test ip_max ip_fld 1f_max 1f_fld 10f_max 10f_fld 64 14880 14489 3616 3576 2675 2054 2675 2050 128 8445 8324 3081 3058 2247 1674 2258 1668 256 4528 4494 1667 1529 1493 1253 1493 1248 512 2349 2340 948 896 875 815 876 814 1024 1197 1195 508 473 465 447 465 447 1518 812 812 348 325 324 313 325 313 Proteon P4200 - DECNET - between interface cards size theo test dn_max dn_fld 64 14880 14489 1747 1469 128 8445 8324 1595 1453 256 4528 4494 1505 1401 512 2349 2340 968 804 1024 1197 1195 539 452 1518 812 812 405 310 Proteon P4200 - IPX - between interface cards size theo test ipx_max ipx_fld 64 14880 14489 1881 1593 128 8445 8324 1718 1560 256 4528 4494 1608 1503 512 2349 2340 970 812 1024 1197 1195 519 450 1518 812 812 411 310 Proteon P4200 - Dual IP Streams - between interface cards size theo test1 test2 d1_fld d2_fld 64 14880 14489 14549 1085 1181 128 8445 8324 8340 U U 256 4528 4494 4498 825 833 512 2349 2340 2341 665 1107 1024 1197 1195 1195 1109 665 1518 812 812 812 270 433 Proteon rig - TCP/IP - between interface cards size theo test ip_max ip_fld 1f_max 1f_fld 10f_max 10f_fld 64 14880 14489 12802 12142 4622 4513 4605 4530 128 8445 8324 7896 7998 4233 4212 4222 4204 256 4528 4494 4351 4350 2964 2944 2964 2943 512 2349 2340 2287 2294 1850 1835 1850 1837 1024 1197 1195 1186 1181 1060 1047 1060 1048 1518 812 812 812 805 749 741 749 742 Proteon rig - Dual IP Streams - between interface cards size theo test1 test2 d1_fld d2_fld 64 14880 14489 14549 8516 7749 128 8445 8324 8340 8027 6989 256 4528 4494 4498 4494 3936 512 2349 2340 2341 2333 4098 1024 1197 1195 1195 1193 1192 1518 812 812 812 810 809 Timeplex TIME/LAN 100 - TCP/IP - between interface cards size theo test ip_max ip_fld 64 14880 14489 5480 4822 128 8445 8324 4865 4162 256 4528 4494 3287 3253 512 2349 2340 1969 1949 1024 1197 1195 977 973 1518 812 812 691 687 Wellfleet Link Node - TCP/IP - between interface cards size theo test ip_max ip_fld 1f_max 1f_fld 10f_max 10f_fld 64 14880 14489 14473 14473 11107 10778 9708 9998 128 8445 8324 8322 8322 8322 8322 8324 8324 256 4528 4494 4493 4493 4494 4494 4494 4494 512 2349 2340 2340 2340 2340 2340 2340 2340 1024 1197 1195 1196 1196 1193 1193 1195 1195 1518 812 812 811 811 811 811 812 812 Wellfleet Link Node - AppleTalk II - between interface cards size theo test at2_max at2_fld 64 14880 14489 12676 13629 128 8445 8324 8324 8324 256 4528 4494 4493 4493 512 2349 2340 2341 2341 Wellfleet Link Node - DECNET - between interface cards size theo test dn_max dn_fld 64 14880 14489 10151 10404 128 8445 8324 8322 8322 256 4528 4494 4494 4494 512 2349 2340 2340 2340 1024 1197 1195 1194 1194 1518 812 812 812 812 Wellfleet Link Node - IPX - between interface cards size theo test ipx_max ipx_fld 64 14880 14489 10420 10642 128 8445 8324 8324 8324 256 4528 4494 4493 4493 512 2349 2340 2340 2340 1024 1197 1195 1194 1194 1518 812 812 812 812 Wellfleet Link Node - Bridge Mode - between interface cards size theo test br_max br_fld 64 14880 14489 14488 14488 128 8445 8324 8324 8324 256 4528 4494 4494 4494 512 2349 2340 2340 2340 1024 1197 1195 1195 1195 1518 812 812 812 812 Wellfleet Link Node - Dual IP Streams - between interface cards size theo test1 test2 d1_fld d2_fld 64 14880 14489 14549 7790 7780 128 8445 8324 8340 7186 7196 256 4528 4494 4498 4491 4493 512 2349 2340 2341 2340 2339 1024 1197 1195 1195 1194 1194 1518 812 812 812 811 811 Wellfleet Link Node - TCP/IP - within interface card size theo test ip_max ip_fld 1f_max 1f_fld 1f_max 1f_fld 64 14880 14489 11086 12646 8983 9636 8930 9655 128 8445 8324 8322 8322 8324 8324 8324 8324 256 4528 4494 4493 4493 4494 4494 4494 4494 512 2349 2340 2340 2340 2340 2340 2340 2340 1024 1197 1195 1196 1196 1193 1193 1193 1193 1518 812 812 811 811 811 811 811 811 Wellfleet Link Node - AppleTalk II - within interface card size theo test at2_max at2_fld 64 14880 14489 10707 11390 128 8445 8324 8322 8322 256 4528 4494 4493 4493 512 2349 2340 2339 2339 Wellfleet Link Node - DECNET - within interface card size theo test dn_max dn_fld 64 14880 14489 8634 8982 128 8445 8324 8322 8322 256 4528 4494 4494 4494 512 2349 2340 2340 2340 1024 1197 1195 1193 1193 1518 812 812 811 811 Wellfleet Link Node - IPX - within interface card size theo test ipx_max ipx_fld 64 14880 14489 8780 9109 128 8445 8324 8322 8322 256 4528 4494 4494 4494 512 2349 2340 2340 2340 1024 1197 1195 1194 1194 1518 812 812 811 811 Wellfleet Link Node - Bridge Mode - within interface card size theo test br_max br_fld 64 14880 14489 14488 14488 128 8445 8324 8324 8324 256 4528 4494 4494 4494 512 2349 2340 2340 2340 1024 1197 1195 1195 1195 1518 812 812 812 812 Wellfleet Link Node - Dual IP Streams - within interface card size theo test1 test2 d1_fld d2_fld 64 14880 14489 14549 12652 13024 128 8445 8324 8340 8324 8337 256 4528 4494 4498 4491 4497 512 2349 2340 2341 2334 2341 1024 1197 1195 1195 1195 1195 1518 812 812 812 811 811 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1990Oct18.231854.6973@panews] <1990101823185400> From: brunner@bullhead.uucp Newsgroups: comp.sys.ibm.pc.rt,comp.protocols.tcp-ip Subject: Re: X25 for RT running BSD 4.3 Keywords: X25 Message-ID: <1990Oct18.231854.6973@panews> Date: 18 Oct 90 23:18:54 GMT References: <788@nikhefk.UUCP> Sender: news@panews (news id) Reply-To: brunner@ibmsupt.UUCP () Organization: IBM AWD Palo Alto Lines: 19 Posted: Fri Oct 19 00:18:54 1990 In article <788@nikhefk.UUCP> werner@nikhefk.UUCP (Werner Vogels) writes: > >Does anybody know anything about a X25 board and software for a RT running >BSD4.3 . > >Werner H.P. Vogels >Software Expertise Centrum >Haagse Hogeschool, Intersector Informatica tel: +31 70 618419 >Louis Couperusplein 2-19, 2514 HP Den Haag E-mail: werner@nikhefk.nikhef.nl >The Netherlands or werner@hhinsi.uucp I don't know of one, if there is one I would like to know also. I'm cross posting this to the tcp-ip list as someone on the tcp-ip list may know of an X.25 board for the IBM RT running 4.3bsd. #include Eric Brunner, Consultant, IBM AWD Palo Alto (415) 855-4486 inet: brunner@monet.berkeley.edu uucp: uunet!ibmsupt!brunner trying to understand multiprocessing is like having bees live inside your head. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101901153700> Received: from devvax.TN.CORNELL.EDU by NIC.DDN.MIL with TCP; Fri, 19 Oct 90 04:55:49 PDT Received: from CHUMLEY.TN.CORNELL.EDU by devvax.TN.CORNELL.EDU (5.64/1.3-Cornell-Theory-Center) id AA28341; Fri, 19 Oct 90 07:55:25 -0400 Received: from CHUMLEY.TN.CORNELL.EDU by chumley.TN.Cornell.EDU (5.64/2.0) with SMTP id AA27875; Fri, 19 Oct 90 07:55:38 -0400 Message-Id: <9010191155.AA27875@chumley.TN.Cornell.EDU> To: tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols In-Reply-To: Chris Johnson's message of 16 Oct 90 21:39:43 +0000. <72306@sgi.sgi.com> Date: Fri, 19 Oct 90 07:55:37 -0400 From: Scott Brim And don't forget about VMTP. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101903195800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 19 Oct 90 03:11:02 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12322; Fri, 19 Oct 90 03:00: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: 19 Oct 90 03:19:58 GMT From: olivea!samsung!munnari.oz.au!mtiame!ubeaut!mwp@apple.com (Michael Paddon) Organization: Digital Equipment Corp., Melbourne, Australia Subject: Re: TCP segment size -- user defined? Message-Id: <264@ubeaut.oz.au> References: <538@gohp3.graphon.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil From article <538@gohp3.graphon.com>, by dc@gohp3.graphon.com (Darren Croke): > In article <256@ubeaut.oz.au> mwp@ubeaut.oz.au (Michael Paddon) writes: >> >>There is not much point setting TCP_MSS to be greater than >> (maximum IP packet size - IP header size - TCP header size) >>[536 octets] since IP fragmentation will take place. Receipt of a >>fragmented packet is an all or nothing proposition; a good thing to >>avoid for throughput reasons. >> > I think you will find that it is common for IP implementations to > send and accept datagrams without fragmentation up to > (connected network MTU - IP header size - TCP header size). You are, of course, correct. The link-layer MTU is the important variable here, determining the maximum size of datagrams (up to 64K octets). I pulled the value 536 from some work I was doing with a SLIP implementation, forgetting at the time that it was a special case. Michael ------------------------------------------------------------------- | | Internet: paddon@meo78b.enet.dec.com | | | ACSnet: mwp@ubeaut.oz.au | | Michael Paddon | ACSnet: mwp@munnari.oz.au | | | EasyNet: meo78b::paddon | | | Voice: +61 3 895 9392 | ------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101903410000> Received: from NRI.Reston.VA.US by NIC.DDN.MIL with TCP; Fri, 19 Oct 90 06:54:09 PDT Received: from mcimail.com by NRI.NRI.Reston.VA.US id ai04056; 19 Oct 90 9:46 EDT Date: Fri, 19 Oct 90 08:41 EST From: Bob Stine <0004219666@mcimail.com> To: Chris Johnson To: tcp-ip Subject: Re: Reliable Datagram ??? Protocols Message-Id: <85901019134158/0004219666NB4EM@mcimail.com> Your message suggests that you are differing over facts, when it's clear that the difference is in terminology. I'd bet that Jon is one of the original coiners of the term 'datagram'. (If not, I'm sure he rubbed shoulders with the fellow that coined the term.) The XTP use of the term could be considered inappropriate. Perhaps it should have been called something else. (Reliable transaction packet? Unit message?) - Bob Stine ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101908004000> Received: from SALAD.BBN.COM by NIC.DDN.MIL with TCP; Fri, 19 Oct 90 11:49:07 PDT To: tcp-ip@nic.ddn.mil Cc: tmallory@BBN.COM Subject: Re: Reliable Datagram Protocol Date: Fri, 19 Oct 90 14:40:40 -0400 From: tmallory@BBN.COM I've didn't save the original message because I felt sure someone would chip in the following: from rfc-index.txt.1174: 1151 Partridge, C.; Hinden, R.M. Version 2 of the Reliable Data Protocol (RDP). 1990 April; 4 p. (Format: TXT=8293 bytes) (Updates RFC 908) This is really an addendum to RFC 908, which must also be retrieved. [the first name for this protocol WAS Reliable Datagram Protocol] Not that you will find this widely implemented, but it surely ought to be mentioned given the original request. Tracy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101911031700> Received: from sun2.nsfnet-relay.ac.uk by NIC.DDN.MIL with TCP; Sat, 20 Oct 90 09:40:31 PDT Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <657-4@sun2.nsfnet-relay.ac.uk>; Fri, 19 Oct 1990 09:24:04 +0100 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa00831; 19 Oct 90 8:18 BST Received: from uk.ac.ncl.mts by uk.ac.newcastle; Fri, 19 Oct 90 09:27:00 +0100 Date: Fri, 19 Oct 90 09:23:17 +0100 From: Denis.Russell@newcastle.ac.uk Subject: IP over X.25 - summary To: tcp-ip@nic.ddn.mil Message-Id: On 4th Oct I sent out a query about routing extensive IP over an X.25 network. This is a brief summary of the responses, and other information gathered at the same time. Many thanks to all those who responded. I got several messages in reply. It seems that the main commercial routers have the right characteristics for the task. They can support high speed, have settable inactivity timers, multiple X.25 calls, use X.25 calls for two-way traffic. All the things we'd hoped for, even expected, but weren't actually certain about. It was confirmed that the Sun software established permanent X.25 calls and never cleared them down, but several people referred us to the Nottingham software that did not suffer from these problems. Several people warned us that large packet and window sizes were an absolute must for throughput. Sadly, and despite a couple of specific queries, there were no responses directly from people relating experience of setting up an extensive IP network on top of an X.25 network rather than just operating a few links. However, the second-hand wisdom (which I do not doubt) was that it was not an ideal way to run an IP network, but that, subject to tuning, etc, it would work OK. Denis. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101911061600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 19 Oct 90 10:11:05 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA20459; Fri, 19 Oct 90 09:56: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: 19 Oct 90 11:06:16 GMT From: clyde.concordia.ca!news-server.csri.toronto.edu!utgpu!watserv1!ria!ria.ccs.uwo.ca!peter@uunet.uu.net (Peter Marshall) Organization: CCS, University of Western Ontario, Canada Subject: Re: Ethernet Address Uniqueness... Message-Id: <1990Oct19.120616@ria.ccs.uwo.ca> References: <5A0A050B012801FE-MTAEMR1*fillmore@emrcan>, <1990Oct5.123350.145@arizona.edu>, <2126@excelan.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <2126@excelan.COM>, donp@na.excelan.com (don provan) writes: |> In article <1990Oct5.123350.145@arizona.edu> leonard@arizona.edu writes: |> >I believe that Novell's IPX similarly hacks the Ethernet address.... |> |> This has nothing to do with TCP-IP, but i don't want this rumor to |> spread. IPX does not modify the ethernet address. While DECnet IV wants to change the ethernet number to match the DECnet node and host number, IPX only requires the same ethernet number to be used on all interfaces to a machine. It doesn't care what they are set to. This allows DECnet and IPX to coexist on the same router as long as you get the DECnet running first and then start the IPX. -- Peter Marshall, Manager (Academic Networking) CCS, NSC, U. of Western Ontario, London, Canada N6A 5B7 (519)661-2111x6032 peter.marshall@uwo.ca pm@uwovax (BITNET); peter@ria.uucp ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101911235100> Received: from SH.CS.NET by NIC.DDN.MIL with TCP; Fri, 19 Oct 90 15:04:30 PDT To: Erik Scheelke cc: tcp-ip@nic.ddn.mil, gwilliam@SH.CS.NET Subject: Re: Reliable Datagram Protocols In-reply-to: Your message of 12 Oct 90 10:12:49 +0000. <45598@apple.Apple.COM> Date: Fri, 19 Oct 90 18:03:51 -0400 From: George Williams All semantics aside there was a working group that had outlined a draft RFC xxxx for doing " OSI Connectionless XPORT Services on top of UDP ".....heresy I know (smile). It was in memo format and comments email addr was listed as 'chi@osf.org'. That is as close as you may come to a non proprietary implementation of what you are looking for. I don't even know if the group still exists, but the draft had some interesting possibilities for certain applications and services over an IP backbone. Good Luck George Williams ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101912063400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 19 Oct 90 06:55:57 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16013; Fri, 19 Oct 90 06:53: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 Oct 90 12:06:34 GMT From: bbn.com!craig@apple.com (Craig Partridge) Organization: Bolt Beranek and Newman Inc., Cambridge MA Subject: Re: question about SMTP MX records Message-Id: <60201@bbn.BBN.COM> References: <1990Oct18.164200.5699@ecst.csuchico.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Oct18.164200.5699@ecst.csuchico.edu> robin@csuchico.edu (Robin Goldstone) writes: >... As a workaround, I thought I would just >send to someone%applelink.apple.com@apple.com. It is my (limited) >understanding that addresses are parsed from right to left, so this >message would be sent to apple.com, who would then be able to forward >it to applelink.apple.com. >1) is the syntax of the address I am trying to use valid? Yes the syntax is correct. >2) am I violating any network rules by routing my message through >another host? No, though doing this sort of thing frequently (like sending all your mail via another system because your system doesn't support MX) is considered rude. >3) should this message be getting delivered? Yes. Apple.com is the MX for applelink.apple.com, so it should accept mail for applelink.apple.com. Note that if Apple.com was not the MX for applelink.apple.com, then all bets are off. You should not assume that via j random host using the %-hack is safe or reasonable. You mention your mail is going into a black hole, that's definitely a problem. Mail should not vanish without a trace... Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101916054300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 19 Oct 90 09:17:39 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19230; Fri, 19 Oct 90 09:09: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 Oct 90 16:05:43 GMT From: swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu (Kent England) Organization: Boston U. Information Technology Subject: Re: SNMP monitors Message-Id: <66559@bu.edu.bu.edu> References: <9010181639.AA14322@po.cis.brown.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010181639.AA14322@po.cis.brown.edu> Steven_Carmody@BROWN.EDU writes: >... I'd like to get a sense of what's out there. So far, I >can see three groups of products: 1) the PC-based monitors (wollongong, the >recently announced novell one, etc), 2) the NyserNet/PSI monitor, and 3) a >large number of commercially available, UNIX based monitors (often from >router vendors)... > >The question is -- are there any generalizations which can be made about >each of the categories? I can generalize. :-) 1) I don't like PC based packages because I need workstation power and multitasking. You will need multitasking and virtual memory to do good fault management and data gathering. Of course, you could use a pile of PCs. And I do understand the need for a low end PC package for smallish PC networks. So I would say they are OK for small nets with unsophisticated tool requirements, but not suitable for largish nets. The Proteon Overview PC tool is pretty good, even in its earliest release, with which I am most familiar. 2) The NYSERnet stuff is still pretty good in comparison to other software, and that is disappointing. It indicates that the development of tools has stalled or gotten sidetracked. Some points of interest: 3) Fancy graphics. Migrating from an early X window environment to Motif doesn't buy the network manager a lot. This has distracted developers excessively. But Motif is very pretty; witness the Cabletron displays. Nice pastels, shadows, pictures, etc. Value? To be determined. The people running the InterOp show network used ping and traceroute a lot, but then they may be old fashioned. :-) Databases. A database is an important feature of an advanced network management fault monitor and data gatherer. Early implementations fall short in the ease of use category. We need some database interfaces that match the window environment more closely. Configuration. It is very difficult to adopt or change a tool in a large network if the tool does not help the network manager configure the tool. This is one area where the NYSERnet tool is just awful, requiring the same data to be entered multiple times consistently in the snmpxmon.cf file. Dynamic configuration of commercial products is on the drawing board in the tools I have examined closely, but is not available in a production release. Data gathering and interpretation. This area has been entirely neglected in the tools I have seen. Data gathering and analysis should be database driven. Report generators should be supplied and should be customizable. The database must be accessible outside the network management tool. The database must be custom extensible to deal with such local issues as inventory and cost accounting. There should be utilities for automagic aging and compression of performance data timelines, reducing the demand for disk space growth and easing back-up and archiving. No one is addressing these issues, in the tools I have examined. NYSERnet is still as good as any of the other tools, which is disappointing. One reason I think that progress is disappointing is that the network management market is limited. Developers are getting enamored of the "Distributed Computing Environment Management". I have heard more than one developer talk about stuffing every conceivable variable and extension into the MIB for managing PCs, workstations, and servers and this is a distraction away from the purely Network Management needs of largish networks. However, I understand that tools for DCE management are useful. Sun's tool is interesting. If it saves sysadmin time, it's a good thing. DCE management tools have a wider market than purely NM tools. But DCE management is more embryonic than NM, so I would rather see some vendors concentrate on solving NM problems before turning to DCEM. They could learn from us. One bright note: Cabletron's Network Virtual Machine and object oriented development environment are powerful architectural elements of next generation tools. The NVM can scale well, and holds out some hope of unified Internet management (if such could happen politically and organizationally and could be standardized for interoperability). The OOP model in the Cabletron Spectrum tool is an apparently powerful technique for allowing user customization and for MIB and device tracking. I think object oriented techniques will prove very useful in managing development of sophisticated NM tools, but that is just my embryonic gut feel; it has yet to be demonstrated. --Kent ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101917523300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 19 Oct 90 11:57:35 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23989; Fri, 19 Oct 90 11:45: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: 19 Oct 90 17:52:33 GMT From: agate!shelby!msi.umn.edu!cs.umn.edu!ux.acs!aaron@ucbvax.Berkeley.EDU (Aaron Y.T. Cheung) Organization: University of Minnesota, Academic Computing Services Subject: Which is the correct/standard way to set up a mail forwarder w/ MX ? Message-Id: <2511@ux.acs.umn.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Question being: I want to set up host abc.edu as MX forwarder for domain xyz.org, whereas host def.edu (which takes to abc.edu via smtp) takes care of all xyz.org mails, could someone point me to the standard way to have it set up, with sendmail.cf (or elsewhere)? Eg., how does major MX gateways running SMTP do that, TECHNICALLY? In short and again, host abc.edu will receive all mails for xyz.org and forward it to def.edu for final delivery. NOTE: root@xyz.org should NOT be forwarded to root@abc.edu (ie, xyz.org is not to be set up as an alias of abc.edu.) You can assumption: 1. the MX record for xyz.org is already in the DNS system & readily resolvable. 2. abc.edu and def.edu can talk to each other via smtp Thanks in advance, /aaron. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010201341.AA18699@ucbvax.Berkeley.EDU] <1990101918404000> From: tmallory@BBN.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: Reliable Datagram Protocol Message-ID: <9010201341.AA18699@ucbvax.Berkeley.EDU> Date: 19 Oct 90 18:40:40 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 Posted: Fri Oct 19 19:40:40 1990 I've didn't save the original message because I felt sure someone would chip in the following: from rfc-index.txt.1174: 1151 Partridge, C.; Hinden, R.M. Version 2 of the Reliable Data Protocol (RDP). 1990 April; 4 p. (Format: TXT=8293 bytes) (Updates RFC 908) This is really an addendum to RFC 908, which must also be retrieved. [the first name for this protocol WAS Reliable Datagram Protocol] Not that you will find this widely implemented, but it surely ought to be mentioned given the original request. Tracy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101920361200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 19 Oct 90 13:49:07 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27421; Fri, 19 Oct 90 13:38: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: 19 Oct 90 20:36:12 GMT From: rogue.llnl.gov!oberman@lll-winken.llnl.gov Subject: Re: question about SMTP MX records Message-Id: <1990Oct19.133612.1@rogue.llnl.gov> References: <1990Oct18.164200.5699@ecst.csuchico.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Oct18.164200.5699@ecst.csuchico.edu>, robin@csuchico.edu (Robin Goldstone) writes: > I am trying to send a message to someone@applelink.apple.com. This > host has no TYPE A record, only an MX record. My mailer currently > cannot resolve MX records. As a workaround, I thought I would just > send to someone%applelink.apple.com@apple.com. It is my (limited) > understanding that addresses are parsed from right to left, so this > message would be sent to apple.com, who would then be able to forward > it to applelink.apple.com. > > Some questions: > 1) is the syntax of the address I am trying to use valid? > 2) am I violating any network rules by routing my message through > another host? > 3) should this message be getting delivered? > I have sent several test messages that have disappeared into a black hole... The use of the '%' hack is not a part of any standard. But it usually works. So the syntax of the address is probably OK. APPLE.COM is the mail exchanger for APPLE and APPLELINK, so it SHOULD work, but only by convention. It does not violate any "rules", such as they aren't. But this type of routing is quite undesireable--but very common. Mail to APPLELINK is staged on APPLE.COM for delivery, so maybe the route between APPLELINK and APPLE is down. You should really try to get a mailer that handles MX records some day. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010201634.AA20968@ucbvax.Berkeley.EDU] <1990101922035100> From: gwilliam@SH.CS.NET (George Williams) Newsgroups: comp.protocols.tcp-ip Subject: Re: Reliable Datagram Protocols Message-ID: <9010201634.AA20968@ucbvax.Berkeley.EDU> Date: 19 Oct 90 22:03:51 GMT References: <45598@apple.Apple.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 Posted: Fri Oct 19 23:03:51 1990 All semantics aside there was a working group that had outlined a draft RFC xxxx for doing " OSI Connectionless XPORT Services on top of UDP ".....heresy I know (smile). It was in memo format and comments email addr was listed as 'chi@osf.org'. That is as close as you may come to a non proprietary implementation of what you are looking for. I don't even know if the group still exists, but the draft had some interesting possibilities for certain applications and services over an IP backbone. Good Luck George Williams ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990101922314600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 19 Oct 90 17:07:26 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05190; Fri, 19 Oct 90 17:02: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: 19 Oct 90 22:31:46 GMT From: swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!lth.se!newsuser@ucsd.edu (Jan Engvald) Organization: Communication Systems, Lund Institute of Technology, Sweden Subject: Re: Ethernet Address Uniqueness... Message-Id: <1990Oct19.223146.14613@lth.se> References: <1990Oct5.123350.145@arizona.edu>, <2126@excelan.COM>, <1990Oct19.120616@ria.ccs.uwo.ca> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >While DECnet IV wants to change the ethernet number to match the DECnet node >and host number, IPX only requires the same ethernet number to be used on all >interfaces to a machine. It doesn't care what they are set to. This allows >DECnet and IPX to coexist on the same router as long as you get the DECnet >running first and then start the IPX. No, NO. *NOVELL* IPX routers/servers don't change the Ethernet address of any interface card (*). We have several servers with two Ethernet cards. One card uses type 8137 protocoll and the other Novells ISO-like protocoll. Both are connected to the *SAME* Ethernet segment, and if they used the same Ethernet address it would mean disaster. Looking with an Ethernet monitor you can see that at the link layer each card uses its own address that it was born with. However, at the network layer Novell IPX uses 32 bits of network id + 48 bits node id, and the node id is the Ethernet address of the first (LAN A) card. (*) The Cisco router, for some reason I don't understand, say they do change the adress of its interfaces when Novell IPX routing is turned on. Jan Engvald, Lund University Computing Center ________________________________________________________________________ Address: Box 783 E-mail: xjeldc@ldc.lu.se S-220 07 LUND Earn/Bitnet: xjeldc@seldc52 SWEDEN (Span/Hepnet: Sweden::Gemini::xjeldc) Office: Soelvegatan 18 VAXPSI: psi%2403732202020::xjeldc Telephone: +46 46 107458 (X.400: C=se; A=TeDe; P=Sunet; O=lu; Telefax: +46 46 138225 OU=ldc; S=Engvald; G=Jan) Telex: 33533 LUNIVER S ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102007511200> Received: from cwns11.INS.CWRU.Edu by NIC.DDN.MIL with TCP; Sat, 20 Oct 90 11:31:15 PDT Received: by cwns11.INS.CWRU.Edu (5.61+ida+/CWRU-1.3-client) id AA03781; Sat, 20 Oct 90 14:31:12 -0400 (from ah335 for tcp-ip@nic.ddn.mil) Message-Id: <9010201831.AA03781@cwns11.INS.CWRU.Edu> Date: Sat, 20 Oct 90 14:31:12 -0400 From: ah335@cleveland.Freenet.Edu (Richard Banks) To: tcp-ip@nic.ddn.mil Subject: Test; Please ignore. Reply-To: ah335@cleveland.Freenet.Edu This is a test, I don't think i'm receiveing the lsit ! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102009350000> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Fri, 19 Oct 90 05:17:10 PDT Received: from NUSDISCS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 2914; Fri, 19 Oct 90 08:15:49 EDT Date: Fri, 19 Oct 90 20:15 H From: Subject: Why Sun adopted UDP-based RPC to implement NFS, but not TCP-based RPC? To: tcp-ip@nic.ddn.mil X-Original-To: tcp-ip@nic.ddn.mil, TAYBENGH Hi, netlander! The title says it all. What is your opinions of why Sun adopted UDP-based RPC to implement NFS, not TCP-based RPC? Since in NFS, the client and server normally would like to maintain the relationship for quite a long time, using TCP-based RPC is supposed to be more economical/efficient (am I rite?). Moreover, by using TCP-based RPC, there is no need to implement a end-to-end mechanism for relaibility, since TPC has the necessary realibility built in. Any ideas/opinions. Thanks - beng hang (email: taybengh@nusdiscs) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102012253000> Received: from gaak.LCS.MIT.EDU by NIC.DDN.MIL with TCP; Sat, 20 Oct 90 13:25:45 PDT Received: by gaak.LCS.MIT.EDU id AA26279; Sat, 20 Oct 90 16:25:30 EDT Date: Sat, 20 Oct 90 16:25:30 EDT Message-Id: <9010202025.AA26279@gaak.LCS.MIT.EDU> To: wuarchive!emory!hubcap!mmccann@EDDIE.MIT.EDU Cc: tcp-ip@nic.ddn.mil In-Reply-To: (Mike McCann's message of 16 Oct 90 20:54:54 GMT <10981@hubcap.clemson.edu> Subject: Need phone numbers... From: Michael A. Patton Sender: map@gaak.LCS.MIT.EDU Date: 16 Oct 90 20:54:54 GMT From: wuarchive!emory!hubcap!mmccann@eddie.mit.edu (Mike McCann) ... networking companies (such as Proteon or Sysco)? Proteon and Sysco are both Boston area companies and while Proteon does do networking, Sysco is a food service company. (You probably meant cisco, it's pronounced the same :-). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102017425900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 20 Oct 90 11:50:22 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23028; Sat, 20 Oct 90 11: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: 20 Oct 90 17:42:59 GMT From: mcsun!unido!wrkof!dksoft!dirk@uunet.uu.net (Dirk Koeppen) Organization: Koeppen EDV-Beratung, D-6050 Offenbach, Germany Subject: How to configure the network files in the right way ? Message-Id: <1407@dksoft.incom.de> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil When I look at other TCP/IP boxes I mostly find strange configured networks. Some loopback networks do not use the 127.0.0.1 address and so on. Therefore I would like to put the following statements into discussion. I am very interested if the way I configured my network is the right way to do. The machine I configure is called dksoft (192.1.1.99) the network is called incom (my full address is dksoft@incom.de). First the /etc/hosts file: 127.0.0.1 loopback loop 192.1.1.99 dksoft dksoft.incom.de localhost local 192.1.1.100 nix nix.incom.de Note that I put the localhost entry behind the name of the local host. Most hosts have the localhost entry behind the kernel loopback entry. Also an entry loopback names the kernel loopback address. Some systems I have seen (especially SCO-UNIX) return a NULL-pointer on the gethostbyname() call if the domain address is not set in the same line where the hostname appears. Therefore I also addred the *.incom.de entry. The /etc/networks file then looks like: loopback 127 loopback-net software-loopback-net incom 192.1.1 local-net Another important point is how to load the network devices. The Ethernet device I use is wd0, the kernel-loopback is lo0. I found that most standard installations load the lo0 device with localhost. This would set the Internet-address to the lo0 device. I therefore changed my /etc/netd.cf file to the following: ifconfig "wd0" dksoft up ifconfig "lo0" loopback up If I now use netstat -i everything seem all right: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Collis wd0 1500 incom dksoft.incom 2790 0 9522 2 0 lo0 2048 loopback loopback 14418 0 14418 0 0 or netstat -in: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Collis wd0 1500 192.1.1 192.1.1.99 2790 0 9522 2 0 lo0 2048 127 127.0.0.1 14422 0 14422 0 0 Waiting for comments... Dirk -- .............. ............. ........... .......... ........ Dirk Koeppen - Holzwiesenweg 22 - D-6050 Offenbach - Germany ....... ..... Phone: +49 69 89 3000 - FAX: +49 69 89 3004 - uucp: dirk@incom.de ..... ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102021254800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 21 Oct 90 12:51:39 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12903; Sun, 21 Oct 90 12:44: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: 20 Oct 90 21:25:48 GMT From: unmvax!pprg.unm.edu!topgun!mustang!nntp-server.caltech.edu!ggumby!tim@ucbvax.Berkeley.EDU (Timothy L. Kay) Organization: California Institute of Technology, Pasadena Subject: Re: question about SMTP MX records Message-Id: References: <1990Oct18.164200.5699@ecst.csuchico.edu>, <1990Oct19.133612.1@rogue.llnl.gov> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil oberman@rogue.llnl.gov writes: >You should really try to get a mailer that handles MX records some day. Fine, but how do we get Silicon Graphics to provide a mailer that supports MX records? Is there a way of putting pressure on them, such as being able to claim that their machines violate internet standards or somesuch? Tim ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102102225800> Received: from NRI.Reston.VA.US by NIC.DDN.MIL with TCP; Sun, 21 Oct 90 03:23:47 PDT Date: Sun, 21 Oct 90 06:22:58 EDT X-Mailer: Mail User's Shell (6.5 4/17/89) From: Vint Cerf To: Craig Partridge , tcp-ip@nic.ddn.mil, ietf@isi.edu Subject: Re: SIGCOMM '90 materials Cc: lduncan@NRI.Reston.VA.US Message-ID: <9010210622.aa12201@NRI.NRI.Reston.VA.US> Regarding Tutorial Notes from SIGCOMM 90, please be aware that we have ONLY the tutorial notes from Rudin/Van Jacobson (tutorial number 1). We don't have any from the other tutorial. The cost for the R/VJ tutorial notes is $30 which includes shipping and handling for North American destinations. Air shipment to places farther away will vary. Vint Cerf CNRI ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102105191800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 20 Oct 90 22:37:58 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02456; Sat, 20 Oct 90 22:32: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: 21 Oct 90 05:19:18 GMT From: bbs!karl@uunet.uu.net (Karl Denninger) Organization: A.C. Nielsen Bannockburn, IL Subject: 3c523 packet drivers -- what's the trick? Message-Id: <1990Oct21.051918.5813@naitc.naitc.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil HELP! We're trying to get a few PS/2s running with the packet drivers, and are having no luck at all. All we get is a "Timed out initializing board" message...... and no function! If anyone out there has this working, PLEASE let me know immediately. Email appreciated with hints, tricks, traps, and new code if we need something other than what we have. The drivers we have are dated mid-august of this year. We really need this working Monday AM! Thanks MUCH in advance! -- 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---- <1990102108115500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 21 Oct 90 01:51:11 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05833; Sun, 21 Oct 90 01:44: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: 21 Oct 90 08:11:55 GMT From: zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!rsiatl!jgd@tut.cis.ohio-state.edu (John G. DeArmond) Organization: Radiation Systems, Inc. (a thinktank, motorcycle, car and gun works facility) Subject: Re: 3c523 packet drivers -- what's the trick? Message-Id: <4409@rsiatl.UUCP> References: <1990Oct21.051918.5813@naitc.naitc.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil karl@naitc.naitc.com (Karl Denninger) writes: >HELP! >We're trying to get a few PS/2s running with the packet drivers, and are >having no luck at all. All we get is a "Timed out initializing board" >message...... and no function! I had the same problem last year. I stumbled onto a work-around that you probably won't like. :-) I found that if an old beta version of the driver was loaded, the machine warm booted and then the new version loaded, everything worked OK. Great, eh? One must assume that some memory location is getting twiddled by one or the other but I never had time to run this one down. If you find out what it takes to make the new ones work, I'd appreciate hearing. Since terminal emulation is about all a PS/2 is good for, I expect to run into a couple more someday. John -- John De Armond, WD4OQC | "The truly ignorant in our society are those people Radiation Systems, Inc. | who would throw away the parts of the Constitution Atlanta, Ga | they find inconvenient." -me Defend the 2nd {emory,uunet}!rsiatl!jgd| with the same fervor as you do the 1st. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102114154700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 21 Oct 90 07:36:21 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08742; Sun, 21 Oct 90 07:23: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 Oct 90 14:15:47 GMT From: bbn.com!craig@apple.com (Craig Partridge) Organization: Bolt Beranek and Newman Inc., Cambridge MA Subject: Re: Reliable Datagram Protocol Message-Id: <60240@bbn.BBN.COM> References: <9010201341.AA18699@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010201341.AA18699@ucbvax.Berkeley.EDU> tmallory@BBN.COM writes: >from rfc-index.txt.1174: >1151 Partridge, C.; Hinden, R.M. Version 2 of the Reliable Data Protocol > (RDP). 1990 April; 4 p. (Format: TXT=8293 bytes) (Updates RFC 908) > >[the first name for this protocol WAS Reliable Datagram Protocol] A quick comment on RDP -- there's considerable misunderstanding about what RDP is and is not. When people ask for a reliable datagram protocol (and before Jon Postel jumps on me, yes Jon, I know it is an oxymoron) what they typically mean is a transaction protocol -- a protocol that allows them to exchange data units reliably with multiple remote systems. A sort of reliable version of UDP. RDP should be viewed as a record-oriented TCP. I.e. RDP uses connections, and transmits a reliable stream of delimited data. It is not a transaction protocol. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102200583500> Received: from ftp.com by NIC.DDN.MIL with TCP; Mon, 22 Oct 90 06:19:14 PDT Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA03839; Mon, 22 Oct 90 09:18:35 -0500 Date: Mon, 22 Oct 90 09:18:35 -0500 Message-Id: <9010221418.AA03839@ftp.com> To: encore!zelig!jdarcy@husc6.harvard.edu (Floating Exception) Subject: Re: Reliable Datagram ??? Protocols 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 apple.com!erekose@apple.com (Erik Scheelke): > Does anyone know of a reliable connectionless datagram protocol that > runs on top of UDP? Is so, is there a library out there I can get? postel@VENERA.ISI.EDU writes: >Hi. > >"Reliable Datagram" is an oxymoron. Very funny. Really. I would guess, however, that Erik is referring to a connectionless protocol that preserves message boundaries and guarantees delivery but not necessarily sequencing or non-duplication. I'm sure such beasts exist somewhere. What Jon said was the very, very condensed summary of an issue that he has no doubt seen hashed over far too many times. Even though I've been over it twice as many times on the phone to customers as I've seen it discussed here, I'll try my hand at laying it out in long form. "Datagrams" are defined as single messages. Sometimes you send one and you don't expect an answer. Sometimes you kind of hope for a reply, but the transaction you are attempting isn't worth the overhead of setting up a connection; if you don't get an answer, the request may have been lost, the server may be down, or the reply may have been lost. You don't care, there are many servers, and your timeout handler has just sent a duplicate query to another of them... "Connectionless" means that there is no state at either the source or the destination of the message. Thus, a connectionless protocol cannot guarantee delivery. If the sender keeps enough state and includes enough information in each message to guarantee delivery (e.g. some sort of unique ID, and a timeout if the guaranteed response doesn't arrive), you only need to add a little state to the receiver to allow sequencing and non-duplication. If the application must keep track because the transport doesn't, it still looks like a connection to me... So, every time this came up in the past, the next stage was to ask the person looking for a "reliable connectionless protocol" or somesuch what was really needed. The most frequent goal has been some sort of transport for a little machine, or a new one for which there is no networking software yet. The searcher doesn't want to implement all of TCP, and sees "datagrams" as being easier, particularly on a single Ethernet. Another common goal has been to get very high throughput by avoiding the "excessive overhead" of TCP, but Van Jacobsen's research has more or less laid that one to rest. A third one has been "preservation of message boundaries". There are a number of 'reliable' alternatives to TCP, including NETBLT (optimized for block transfers over lossy links), ISO TP, RDP and others. Those I'm familiar with offer built-in functionality for preserving message boundaries, along with varying approaches to connection establishment and acknowlegement. However, it does not appear that they provide enough extra functionality, or require enough less effort to develop that they (except for ISO TP) will ever become very widespread. Frequently, having been made aware of the alternatives, the searcher reads the specs and decides that he won't save anything. Sometimes the next stage is a complaint about excessive complexity containing the assertion "I never see *any* packet loss between my Frobozz boxes on my FooNeT". Whereupon a large number of people jump down the complainer's throat, mostly network maintainers suffering the slings and arrows of trying to make protocols designed for 'little' nets run on 'big, bad' nets... In summary, if you need reliability in an "internet" protocol, those "in tune with the Tao of the Internet" assert that you need a connection, flow control and an end-to-end data integrity check. If all of your transactions are guaranteed to fit in one packet, you can replace the connection state with server idempotency. If not, message boundaries are best not tied to packet boundaries, lest you fall afoul of differing MTUs and fragmentation (see RFC 1001/1002 Netbios over TCP for an example of a header/length-based scheme). If you leave the integrity check out, that's your and your customers' risk, but leaving the flow control out could get hosts ostracized by offended backbone router operators... "Those who do not understand TCP are doomed to re-invent it..." (??? who said that ???) James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102204154200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 21 Oct 90 20:37:18 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21582; Sun, 21 Oct 90 20:32: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: 22 Oct 90 04:15:42 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: 3c523 packet drivers -- what's the trick? Message-Id: References: <1990Oct21.051918.5813@naitc.naitc.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Oct21.051918.5813@naitc.naitc.com> karl@naitc.naitc.com (Karl Denninger) writes: We're trying to get a few PS/2s running with the packet drivers, and are having no luck at all. All we get is a "Timed out initializing board" message...... and no function! The trick is to fetch sun.soe.clarkson.edu:pub/packet-drivers/3c523.com (in binary mode, of course). I just got it working in the past week. -- --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---- <1990102205175600> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Mon, 22 Oct 90 12:20:21 PDT Received: from bel.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Mon, 22 Oct 90 12:20:14 -0700 Date: Mon, 22 Oct 90 12:17:56 PDT From: postel@venera.isi.edu Posted-Date: Mon, 22 Oct 90 12:17:56 PDT Message-Id: <9010221917.AA04212@bel.isi.edu> Received: by bel.isi.edu (4.1/4.0.3-4) id ; Mon, 22 Oct 90 12:17:56 PDT To: shlump.nac.dec.com!shug.enet.dec.com!ciarfella@decuac.dec.com, tcp-ip@nic.ddn.mil Subject: Re: Does ICMP optional data include IP header + options? Paul Ciarfella: Yes. --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102206374200> Received: from xap (xap.xyplex.com) by NIC.DDN.MIL with TCP; Mon, 22 Oct 90 07:44:55 PDT Received: from gryphon.xyplex.com.119.12.192.in-addr.arpa by xap id ; Mon, 22 Oct 90 10:37:42 EDT Date: Mon, 22 Oct 90 10:37:42 EDT Message-Id: <9010221737.AA16959@xap> From: Bob Stewart To: tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols > > postel@VENERA.ISI.EDU sez: > > > > "Reliable Datagram" is an oxymoron. > > > > --jon. > > Chris Johnson responded: > > Perhaps reliable datagram using UDP is an oxymoron, depending on the > transport layer. > > However XTP datagrams *are* reliable. Mail to xtp-request@pei.com > for information or a XTP spec. If they're "datagrams", then they're not reliable. That's part of the definition. What you might call a "reliable datagram" could also be called a "single-exchange virtual circuit" (yuk). I haven't really thought about the techniques, but I'd expect to see a protocol that looks sort of like a connection setup with data and an implied disconnect. "Reliable datagram" is sort of like "reliable mail", wishing can't make it so. It's really reliable only when the destination application (!) says it got it. Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102207003100> Received: from WLV.IMSD.CONTEL.COM by NIC.DDN.MIL with TCP; Mon, 22 Oct 90 18:57:50 PDT Received: by WLV.IMSD.CONTEL.COM (5.64/1.25) id AA07826; Mon, 22 Oct 90 18:40:31 -0700 Date: Mon, 22 Oct 90 18:40:31 -0700 From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) Message-Id: <9010230140.AA07826@WLV.IMSD.CONTEL.COM> To: BILLW@mathom.cisco.com, jbvb@ftp.com Subject: Re: Reliable Datagram ??? Protocols Cc: encore!zelig!jdarcy@husc6.harvard.edu, tcp-ip@nic.ddn.mil I may have missed the point but doesn't a PUSH accomplish the same thing? In which case no modification is required. Merton ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102208283500> Received: from suzzy.cs.utk.edu by NIC.DDN.MIL with TCP; Mon, 22 Oct 90 09:28:54 PDT Received: from LOCALHOST.cs.utk.edu by suzzy.cs.utk.edu with SMTP (5.61++/2.6c-UTK) id AA00835; Mon, 22 Oct 90 12:28:39 -0400 Message-Id: <9010221628.AA00835@suzzy.cs.utk.edu> To: tcp-ip@nic.ddn.mil Cc: key@cs.utk.edu Subject: Looking for PPP for Ultrix (4.0) Date: Mon, 22 Oct 90 12:28:35 EDT From: key@cs.utk.edu Has anyone (DEC?) done PPP for Ultrix 4.0 (RISC) yet? I've seen the BSD 4.3 and SunOS4.0.1/386i distributions. Is there a PPP implementor's mail-list/archive? Thanks in Advance, Ken Key (key@utkux1.utk.edu) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102208351400> Received: from mathom.cisco.com by NIC.DDN.MIL with TCP; Mon, 22 Oct 90 15:40:44 PDT Date: Mon 22 Oct 90 15:35:14-PDT From: William "Chops" Westfield Subject: Re: Reliable Datagram ??? Protocols To: jbvb@ftp.com cc: encore!zelig!jdarcy@husc6.harvard.edu, tcp-ip@nic.ddn.mil In-Reply-To: <9010221418.AA03839@ftp.com> Message-ID: <12631917498.27.BILLW@mathom.cisco.com> I occasionally wonder whether we should just take TCP, add a comment that says "you WILL preserve packet boundries", change the IP protocol type, and say "poof, here is a reliable datagram protocol". BillW ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102210520900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 12:26:39 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA18598; Wed, 24 Oct 90 12:14: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: 22 Oct 90 10:52:09 GMT From: mcsun!inria!ircam!mf@uunet.uu.net (Michel Fingerhut) Organization: IRCAM, Paris (France) Subject: named going into an infinite loop ... Message-Id: <1990Oct22.105209.28006@ircam.ircam.fr> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Machine: DECsystem 5820 (RISC) OS: Ultrix 4.0 (Rev. 179) Every once in a while (every 3-4 days), the name daemon starts eating CPU time, goes to the top of the queue, and fills the syslog error message table with messages of the form Oct 22 10:23:37 localhost: 93 named: accept: Too many open files (one a second, approximately) until it is killed and/or chokes /usr/spool. Upon restart, it works fine. There is no apparent flood of requests prior to that. Does anyone have a suggestion on how to approach the problem? Thanks, Michael Fingerhut ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102211213100> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Mon, 22 Oct 90 10:46:51 PDT Received: from BLIULG11 by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 7818; Mon, 22 Oct 90 13:45:10 EDT Received: from vm1.ulg.ac.be by BLIULG11 (Mailer R2.07) with BSMTP id 4053; Mon, 22 Oct 90 09:55:32 +0100 Date: Mon, 22 Oct 90 09:41:31 +0100 From: Andr'e PIRARD Subject: Re: 3c523 packet drivers -- what's the trick? To: TCP-IP@NIC.DDN.MIL In-Reply-To: Message of Sun, 21 Oct 90 08:11:55 GMT from On Sun, 21 Oct 90 08:11:55 GMT said: >karl@naitc.naitc.com (Karl Denninger) writes: >>We're trying to get a few PS/2s running with the packet drivers, and are >>having no luck at all. All we get is a "Timed out initializing board" >>message...... and no function! > >I had the same problem last year. I stumbled onto a work-around that >you probably won't like. :-) I found that if an old beta version of >the driver was loaded, the machine warm booted and then the new version >loaded, everything worked OK. Great, eh? Indeed 3c523_5 looks to have been included in release 7 for that purpose. But one doesn't need to warm boot. TERMIN will do the trick. >One must assume that some memory location is getting twiddled by one >or the other but I never had time to run this one down. If you find >out what it takes to make the new ones work, I'd appreciate hearing. >Since terminal emulation is about all a PS/2 is good for, I expect >to run into a couple more someday. I have traced the problem some day to occur during board RAM tests. I have suggested that the cause is that the CPU can't accessed that RAM until the chip is initialized, what's apparently done after RAM test. Unfortunately, I haven't got a 523 any more. Will someone who has one give Russ a help? Andr'e PIRARD SEGI, Univ. de Li`ege B26 - Sart Tilman B-4000 Li`ege 1 (Belgium) pirard@vm1.ulg.ac.be or PIRARD@BLIULG11 on EARN/BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102212042000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 01:08:17 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16384; Wed, 24 Oct 90 00:55: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: 22 Oct 90 12:04:20 GMT From: bbn.com!craig@eddie.mit.edu (Craig Partridge) Organization: Bolt Beranek and Newman Inc., Cambridge MA Subject: Re: question about SMTP MX records Message-Id: <60248@bbn.BBN.COM> References: <1990Oct18.164200.5699@ecst.csuchico.edu>, <1990Oct19.133612.1@rogue.llnl.gov>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article tim@ggumby.cs.caltech.edu (Timothy L. Kay) writes: >Fine, but how do we get Silicon Graphics to provide a mailer that supports >MX records? Is there a way of putting pressure on them, such as being able >to claim that their machines violate internet standards or somesuch? Any host which does not support MX RR's in the mailer is not Host Requirements conformant. See page 65 of RFC 1123. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102216370200> Received: from mathom.cisco.com by NIC.DDN.MIL with TCP; Mon, 22 Oct 90 23:39:59 PDT Date: Mon 22 Oct 90 23:37:02-PDT From: William "Chops" Westfield Subject: Re: Reliable Datagram ??? Protocols To: mcc@WLV.IMSD.CONTEL.COM cc: jbvb@ftp.com, encore!zelig!jdarcy@husc6.harvard.edu, tcp-ip@nic.ddn.mil In-Reply-To: <9010230140.AA07826@WLV.IMSD.CONTEL.COM> Message-ID: <12632005207.2.BILLW@mathom.cisco.com> I may have missed the point but doesn't a PUSH accomplish the same thing? [make TCP a datagram-oriented protocol] Well, no. A major part that is missing is a specification for the interface between TCP and the next layer up (in ISO, this would likely be a whole separtate document.) In particular, if a receiver gets two packets with PUSH set, the interface may put both packets in a single buffer. To quote RFC793: The exact push point might not be visible to the receiving user and the push function does not supply a record boundary marker. Also, on the sender side, push does not preclude use of algorithms such as slow start, Nagle, or re-packetization on retransmit. (Hopefully, a system using a datagram oriented protocol does not involve situations where these are important (well, slow start would still be useful - you just have to do it with datagrams rather than stream data)) Finally, TCP as is will send many datagrams if you present more than a packet-sizes worth of data. For a datagram oriented system, you would force it to send a fragmented IP packets instead (and the maximum segment size would have a slightly different meaning.) The changes to any particular TCP to achieve a reliable datagram model would not be significant, but it would take a little work. BillW ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102217282000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 03:23:44 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23014; Wed, 24 Oct 90 03:18: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: 22 Oct 90 17:28:20 GMT From: phri!marob!slhisc!jlister@nyu.edu (John Lister) Organization: Shearson Lehman Brothers, Inc. Subject: Re: Can One API Support Both TCP/IP and LU 6.2? Message-Id: <1990Oct22.172820.16535@slhisc.uucp> References: <34953@cup.portal.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Interesting thought. The answer seems to be that you could implement something on top of RPC that would have similar functionality to LU6.2 for particular applications. Although IBM has been pushing LU6.2 as a commun- ications panacea, in actuality, most implementations use it for transaction processing, and the orientation is definitely towards Logical Units of Work and the questions of atomicity that Distributed Transaction Processing raise. I have been wondering about starting a project to look at writing an RPC interface for CICS Distributed Transaction Processing for some time but haven't actually done anything about it. Is there anyone out there who has already got their fingers wet? John Lister. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102220400700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 03:40:14 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23924; Wed, 24 Oct 90 03:36: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: 22 Oct 90 20:40:07 GMT From: agate!bionet!synoptics!sblair@ucbvax.Berkeley.EDU (Steven Blair) Organization: SynOptics Communications Inc. Mountain View, Ca. Subject: *looking for implementations of RFC-1112* Message-Id: <1990Oct22.134007@synoptics.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have several users who've recently become aware of RFC1112 written by S.Deering of Stanford(1989) on Host Extensions on IP Multicasting. We're reviewing the paper for possible interest. Questions are: 1) Has any router/bridge company done this? If not, are any working on it. 2) Are there any networks supporting this at this time? Or in the future? 3) Any more interesting comments you can add to this. IP Multicasting, for those of you who'd like to know, is: [quoting from the RFC] "IP multicasting is the transmission of an IP datagram to a "host group", a set of zero, or more hosts identified by a single IP destination address". The RFC112 goes into many unique details that could make this a very flexible protocol to implement, and we'd like to know more. For those of of us with Internet DNS sites, dealing with potential DNS forgeries, this could indeed offer an additional level of complexity in the future, if many adopt it... Please email: craigj@synoptics.com & sblair@synoptics.com -- Steven C. Blair Network Operations Center SynOptics Communications Inc. Mountain View, California INTERNET: sblair@synoptics.com sblair@excalibur.synoptics.com PROBLEMS/EMAIL: HOSTMASTER@SYNOPTICS.COM postmaster@synoptics.com ***Bring Back The USENET Backbone/ARPA Backbone, NOW*** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102221193600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 03:53:48 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24759; Wed, 24 Oct 90 03:53: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: 22 Oct 90 21:19:36 GMT From: dino!atanasoff!jacobson@uunet.uu.net (Doug Jacobson) Subject: subnets Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have two general questions about subnetting in TCP/IP. At Iowa State University we have a class B address and our campus network consists of a four large bridged Ethernet segments with a FDDI backbone used to connect these segments. Some of the segments contain IP Gateways. The campus was using transparent subnetting until about a month aao when the campus changed to unsubnetted. The Broadcast addresses and the Netmasks have been changed. (Broadcast changed from 129.186.X.255 to 129.186.255.255 and the netmask changed from 255.255.0.0 to 255.255.255.0). The questions I are: 1) Should we have changed the campus to not support transparent subnetting even though we do have some true subnets within our domain. 2) How do other organizations with class B addresses set up their networks and do they use transparent subnetting. You can mail your responses to me at doug@isuee1.ee.iastate.edu if there is enough interest I will post the results to question 2. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102221341800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 03:52:19 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24523; Wed, 24 Oct 90 03:48: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: 22 Oct 90 21:34:18 GMT From: cs.utexas.edu!usc!orion.oac.uci.edu!mothra.nts.uci.edu!meggers@CS.YALE.EDU (Mark Eggers) Subject: RPC interface across various platforms Message-Id: <272365DA.17102@orion.oac.uci.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Are there any commercial or public domain packages that will allow the construction of a distributed application running on such diverse platforms as IBM MVS/XA, VAX VMS, Macintoshes, PCs, and various BSD flavors of UNIX? thanks for any information - /mde/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102222123800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 04:22:11 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25647; Wed, 24 Oct 90 04:09: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: 22 Oct 90 22:12:38 GMT From: hplred!haddad@hplabs.hpl.hp.com (R. Peter Haddad) Organization: Hewlett Packard Labs, Palo Alto CA Subject: Re: Need phone numbers... Message-Id: <11080001@hplred.HP.COM> References: <10981@hubcap.clemson.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil cisco can be reached at 415 326-1941. They probably have an 800 number, but I haven't a clue what it is. I'm suprised they haven't called you. They generally read this notes group. You can also send mail to cs@clash.cisco.com, this is genrally read by sales/technical people at cisco. Good Luck. Peter Haddad HPLabs Network Engineering (415) 857-5618 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102222262800> Received: from hogg.cc.uoregon.edu by NIC.DDN.MIL with TCP; Tue, 23 Oct 90 10:06:56 PDT Received: from localhost.uoregon.edu by hogg.cc.uoregon.edu (4.1/UofO NetSvc-10/1/90) id AA25446; Tue, 23 Oct 90 10:06:31 PDT Message-Id: <9010231706.AA25446@hogg.cc.uoregon.edu> To: tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols In-Reply-To: Your message of Tue, 23 Oct 90 10:22:37 -0500. <9010231522.AA18327@ftp.com> Date: Tue, 23 Oct 90 10:06:28 -0700 From: jqj@hogg.cc.uoregon.edu I think we are being a bit ingenuous in assuming that the only reason one might want "reliable datagrams" is to implement a sequenced packet protocol, or that the only good way to get reliable packet delivery over IP is by using TCP. The current discussion does not, for example, address reliable broadcast or any of a miriad of other real transaction-oriented applications for reliable packet exchange where the cost of setting up a VC is prohibitive. I would even go so far as to suggest that the lack of a standard RPX protocol in the IP suite has inhibited development of reasonable applications that would use it! As an aside, 4.2bsd included Eric Cooper's courier compiler that implemented a Xerox SPP-like protocol over TCP (message boundaries and message types are needed to implement the semantics of Courier). As I recall, Eric just used a simple counted string approach, where messages could span multiple strings and end was delimited by an EOM bit in the message header, totally ignoring IP packet boundaries, PUSHes, etc. (you have to guarantee a PUSH after the EOM, I suppose). Worked just fine if what you wanted was packet boundaries on TCP; no changes to TCP needed. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102302023700> Received: from ftp.com by NIC.DDN.MIL with TCP; Tue, 23 Oct 90 07:22:02 PDT Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA18327; Tue, 23 Oct 90 10:22:37 -0500 Date: Tue, 23 Oct 90 10:22:37 -0500 Message-Id: <9010231522.AA18327@ftp.com> To: William "Chops" Westfield Subject: Re: Reliable Datagram ??? Protocols 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 .... Finally, TCP as is will send many datagrams if you present more than a packet-sizes worth of data. For a datagram oriented system, you would force it to send a fragmented IP packets instead (and the maximum segment size would have a slightly different meaning.) Given my druthers, I'd much rather make message boundaries independent of IP datagrams, because deliberate fragmentation is EEEVIIILLL!!!. Also, you'll never hear the end of "why are records limited to 65Kb" and "why can't I use records bigger than 8Kb on my FooNix system"? If you're willing to re-implement everywhere If you're willing to settle for 16 bits of record length Do something really gross with the Urgent pointer and unused bits in the TCP header. Else Define a new TCP Record Option as: opt_type, opt_len followed by (opt_len - 2)/2 "start of record offsets within this segment". Else Define a formal "Record-Oriented TCP Extension" which uses header/length and let the applications that want it use it. If enough of them do so, someone will move support into a library, and then someone else will put it in the kernel. You could even use ISO Session and get ASN.1 data abstraction in the ?bargain? James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102302122400> Received: from NNSC.NSF.NET by NIC.DDN.MIL with TCP; Tue, 23 Oct 90 05:54:12 PDT To: Steven Blair cc: tcp-ip@nic.ddn.mil Subject: re: Flexible, Host Extensions for IP Multicasting From: Craig Partridge Date: Tue, 23 Oct 90 08:52:24 -0400 Sender: craig@NNSC.NSF.NET Steve: I can answer some of your questions -- Steve Deering or David Waitzman will presumably chime in to answer the rest. > 1) Has any router/bridge company done this? If not, are any > working on it. BBN and Stanford did experiments using Butterfly gateways about two years ago. We also did experiments with the publicly available multicast code for BSD from Stanford. (I don't know where the current multicast code is on-line, however, it will appear in 4.4BSD). The experiments involved trying to do multicast routing over large areas. The answer is, you can do it, and SPF looks like the better base on which to build. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102303281400> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Tue, 23 Oct 90 10:28:27 PDT Received: from braden.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Tue, 23 Oct 90 10:28:24 -0700 Date: Tue, 23 Oct 90 10:28:14 PDT From: braden@venera.isi.edu Posted-Date: Tue, 23 Oct 90 10:28:14 PDT Message-Id: <9010231728.AA03948@braden.isi.edu> Received: by braden.isi.edu (4.1/4.0.3-4) id ; Tue, 23 Oct 90 10:28:14 PDT To: BILLW@mathom.cisco.com, jbvb@ftp.com Subject: Re: Reliable Datagram ??? Protocols Cc: tcp-ip@nic.ddn.mil If you need records, you can build a trivial framing protocol on top of TCP. There have been many examples of this... Mike Muuss' PKG, records in Sun's XDR, and Dave Clark's USP come immediately to mind. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102303313200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 08:42:25 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07512; Wed, 24 Oct 90 08:12: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: 23 Oct 90 03:31:32 GMT From: usc!samsung!munnari.oz.au!mel.dit.csiro.au!yarra!melba.bby.oz.au!gnb@ucsd.edu (Gregory N. Bond) Organization: Burdett, Buckeridge and Young Ltd. Subject: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols) Message-Id: References: <9010221418.AA03839@ftp.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Well, on a similar note.... I understand James' and Jon's arguments. Reliable datagrams are best implemented with TCP and a "write(len); write(data);" layer. I am looking for something a little different. Consider a net with a server and many (say, 100) workstations, and a data feed that goes to each workstation. At the moment, I have to open 100 TCP streams, and so each packet of data generates 200 TCP packets, all more-or-less identical. What would be nice would be to broadcast the packet to the local net, and have the clients request missed packets, thus implementing a sort of reliable broadcast. I would be happy for some sort of overhead for the reliability (e.g. server broadcasts empty packets with the highest serial number once every 10 seconds), but before I re-invent wheels, has someone done something like this? Greg. -- Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia Internet: gnb@melba.bby.oz.au non-MX: gnb%melba.bby.oz@uunet.uu.net Uucp: {uunet,pyramid,ubc-cs,ukc,mcvax,prlb2,nttlab...}!munnari!melba.bby.oz!gnb ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102305225500> Received: from ftp.com by NIC.DDN.MIL with TCP; Tue, 23 Oct 90 10:43:32 PDT Received: from nancy.tlb.ftp.com by ftp.com via PCMAIL with DMSP id AA23604; Tue, 23 Oct 90 13:42:55 -0500 Date: Tue, 23 Oct 90 13:42:55 -0500 Message-Id: <9010231842.AA23604@ftp.com> To: fun@ftp.com Subject: French experience needed From: nancy@ftp.com (Nancy L. Connor) Reply-To: nancy@ftp.com Cc: tcp-ip@nic.ddn.mil Sender: nancy@ftp.com Repository: babyoil.ftp.com Originating-Client: tlb.ftp.com Does anyone know what the following phrase translates to? ..but as they say in French ca me fait une belle jambe. Thanks for any help. -Nancy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102306020000> Received: from MVST.OAC.UCLA.EDU by NIC.DDN.MIL with TCP; Tue, 23 Oct 90 13:03:12 PDT Received: from UCLAMVS.BITNET by MVST.OAC.UCLA.EDU (IBM MVS SMTP R1.0.1) with BSMTP id 9662; Tue, 23 Oct 90 13:02:14 PDT Date: Tue, 23 Oct 90 13:02 PDT To: tcp-ip@NIC.DDN.MIL From: Michael Stein Subject: Re: Reliable Datagram ??? Protocols > Given my druthers, I'd much rather make message boundaries > independent of IP datagrams, because deliberate fragmentation > is EEEVIIILLL!!!. Also, you'll never hear the end of "why are > records limited to 65Kb" and "why can't I use records bigger > than 8Kb on my FooNix system"? 1000% correct. > If you're willing to re-implement everywhere > If you're willing to settle for 16 bits of record length > Do something really gross with the Urgent pointer and unused bits in the > TCP header. > Else > Define a new TCP Record Option as: opt_type, opt_len followed by > (opt_len - 2)/2 "start of record offsets within this segment". > Else > Define a formal "Record-Oriented TCP Extension" which uses header/length > and let the applications that want it use it. If enough of them do so, > someone will move support into a library, and then someone else will put > it in the kernel. You could even use ISO Session and get ASN.1 data > abstraction in the ?bargain? And what do you do if you *need* to be able to abort a "packet" send before it all makes it through? Say I send a 16M "packet" and change my mind in the middle (but don't want to close the connection...). For this you need some "out of band" alert and flush capability -- TCP urgent data won't do it. (Besides that's 16M of binary data, I'd rather avoid scanning it for escape sequences...) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102306330200> Received: from SH.CS.NET by NIC.DDN.MIL with TCP; Tue, 23 Oct 90 10:15:49 PDT To: Merton Campbell Crockett cc: BILLW@mathom.cisco.com, jbvb@ftp.com, encore!zelig!jdarcy@husc6.harvard.edu, tcp-ip@nic.ddn.mil, jcurran@SH.CS.NET Subject: Re: Reliable Datagram ??? Protocols In-reply-to: Your message of Mon, 22 Oct 90 18:40:31 -0700. <9010230140.AA07826@WLV.IMSD.CONTEL.COM> Date: Tue, 23 Oct 90 13:13:02 -0400 From: jcurran@SH.CS.NET >> I may have missed the point but doesn't a PUSH accomplish the same thing? In >> which case no modification is required. "A PSH bit is not a record marker and is independent of segment boundaries." "Passing a received PSH flag to the application layer is now OPTIONAL." (RFC1122) Work on a TCP extension for record information rather than taking a step back.. /John Policy Routing, 2000: "Through the networks according to their abilities, to the applications according to their need." ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102306441800> Received: from mathom.cisco.com by NIC.DDN.MIL with TCP; Tue, 23 Oct 90 13:47:02 PDT Date: Tue 23 Oct 90 13:44:18-PDT From: William "Chops" Westfield Subject: Re: Reliable Datagram ??? Protocols To: braden@venera.isi.edu cc: jbvb@ftp.com, tcp-ip@nic.ddn.mil In-Reply-To: <9010231728.AA03948@braden.isi.edu> Message-ID: <12632159446.18.BILLW@mathom.cisco.com> If you need records, you can build a trivial framing protocol on top of TCP. There have been many examples of this... Mike Muuss' PKG, records in Sun's XDR, and Dave Clark's USP come immediately to mind. Yes, yes. This is not difficult, and is clearly the way to do things within the framework of the currently defined protocols. In fact, the cisco routers do exactly this sort of thing for running X.25 over TCP. Aesthetically, though, it bothers me to have to do the extra work of converting datagrams to streams and back when the underlying transmission scheme is almost certainly datagram based. (Hmm, is anyone running TCP over anything other than IP?) BillW ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102307194700> Received: from ftp.com by NIC.DDN.MIL with TCP; Tue, 23 Oct 90 12:40:02 PDT Received: from bruce.motion.ftp.com by ftp.com via PCMAIL with DMSP id AA25554; Tue, 23 Oct 90 15:39:47 -0500 Date: Tue, 23 Oct 90 15:39:47 -0500 Message-Id: <9010232039.AA25554@ftp.com> To: nancy@ftp.com Subject: Re: French experience needed From: bruce@128.127.2.105 Reply-To: bruce@ftp.com Cc: tcp-ip@nic.ddn.mil, fun@ftp.com Sender: bruce@ftp.com Repository: babyoil.ftp.com Originating-Client: motion.ftp.com >Does anyone know what the following phrase translates to? >..but as they say in French ca me fait une belle jambe. >Thanks for any help. > -Nancy I think a literal translation is something like "that I make myself a beautiful leg". I am not sure what the colloquialism means. Bruce ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102307354900> Received: from SH.CS.NET by NIC.DDN.MIL with TCP; Tue, 23 Oct 90 11:21:02 PDT To: Merton Campbell Crockett cc: BILLW@mathom.cisco.com, jbvb@ftp.com, encore!zelig!jdarcy@husc6.harvard.edu, tcp-ip@nic.ddn.mil, gwilliam@SH.CS.NET Subject: Re: Reliable Datagram ??? Protocols In-reply-to: Your message of Mon, 22 Oct 90 18:40:31 -0700. <9010230140.AA07826@WLV.IMSD.CONTEL.COM> Date: Tue, 23 Oct 90 14:15:49 -0400 From: George Williams The "push" flag, present on tcp packets has nothing to do with reliabilty. It just says ' forwards what's in the receiving application buffer ' up...now ! It has nothing to do with Datagram or Reliabilty but is associated with fragmentation and re-assembly. Additionally, most APIs don't make this flag user accessible; as a good working knowledge of systems and protocol(s) as they pertain to overall response time and throughput is assumed for those who massage this flag. It can result in overall system degradation in a distributed compute environment is set inappropriately.. A final word on UDP...if I may: () Architecturally, UDP is the connection-less transport for IP. Reliability as in pertains to delivery and retranmissions is the assumed burden of associated HLPs (higer level protocols) or service(s) present. I did not write the protocol but did enough implementations to state this as fact. () It is generally the protocol of choice when the transmisssion media has a low error rate or an HLP (e.g. interactive ) that compensates for deficiencies. George Williams ( The above are my own humble views and opinions and are not a critique ) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102308230100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 07:24:21 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04685; Wed, 24 Oct 90 07:14: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: 23 Oct 90 08:23:01 GMT From: eru!hagbard!sunic!lth.se!newsuser@bloom-beacon.mit.edu (Ricard Wolf) Organization: Lund Institute of Technology, Sweden Subject: Re: telnet problem Message-Id: <1990Oct23.082301.5335@lth.se> References: <9010230414.AA04281@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010230414.AA04281@ucbvax.Berkeley.EDU> KCPENG@TWNCTU01.BITNET writes: >Hi, > >the following telnet problem appears after system has booted up a period >of time: > > % telnet xxx > Trying... > Connected to xxx. > Escape charcter is '^[' > >then system hangs. It seems the remote telnetd has been connected, cuz the >escape sequence is in effect. And likely this problem appears only in Sun >W/Ss. Any hint is highly welcome. > >Kai-Chih Peng >kcpeng@twnctu01 Actually, the above message indicates that the remote TCP has responded to the request, not that telnetd has answered. Of course, the telnetd must tell the TCP to open a port for listening (a "passive" port in TCP terminology), but the telnetd doesn't print the above message. Instead, it is the local telnet that desides that once the remote TCP has responded, the connection is fully opened. The escape character mentioned is actually handled by the local telnet, and doesn't have anything to do with the remote telnetd server. -- Ricard Wolf +--------------------------+-------------------------------------+ | Ricard Wolf | Lund Institute of Technology | | email: e85rw@efd.lth.se | If you can't buy 'em - build 'em !! | +--------------------------+-------------------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102309344900> Received: from SPARK.BRL.MIL by NIC.DDN.MIL with TCP; Tue, 23 Oct 90 10:39:17 PDT Date: Tue, 23 Oct 90 13:34:49 EDT From: Phil Dykstra To: William Chops Westfield cc: tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols Message-ID: <9010231334.aa08454@SPARK.BRL.MIL> > The changes to any particular TCP to achieve a reliable datagram model > would not be significant, but it would take a little work. It is easy to layer a reliable message protocol on top of TCP. We designed one such protocol at BRL call PKG (Package Protocol) and have used it for several distributed applications over the past five years (e.g. in BRL-CAD). Messages have user defined "types" and both synchronous and asynchronous message exchanges are supported. At one time a version of it even ran over DECNET, but our current code is BSD socket library oriented only. We should have written an RFC about it years ago. If anyone is interested they can look at brl-cad/pkg.shar.Z via anonymous FTP on ftp.brl.mil (a.k.a. vgr.brl.mil, 192.5.23.6). - Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102313594800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 08:56:41 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA09073; Wed, 24 Oct 90 08:43: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: 23 Oct 90 13:59:48 GMT From: bu.edu!rpi!zaphod.mps.ohio-state.edu!usc!bbn.com!craig@bloom-beacon.mit.edu (Craig Partridge) Organization: Bolt Beranek and Newman Inc., Cambridge MA Subject: Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols) Message-Id: <60282@bbn.BBN.COM> References: <9010221418.AA03839@ftp.com>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article gnb@bby.oz.au (Gregory N. Bond) writes: >Well, on a similar note.... > >Consider a net with a server and many (say, 100) workstations, and a >data feed that goes to each workstation. At the moment, I have to >open 100 TCP streams, and so each packet of data generates 200 TCP >packets, all more-or-less identical. What would be nice would be to >broadcast the packet to the local net, and have the clients request >missed packets, thus implementing a sort of reliable broadcast. There's been some muttering over beers that this might be feasible in TCP. If you think about the idea, it isn't so crazy. To make sure the workstations are in sync, you'll need some sort of windowing mechanism. To be sure everyone has data, you'll need an acknowledgment scheme. That's pretty close to the basic service TCP offers. So if you could open a TCP connection to an IP multicast address, and figure out how to handle the remote ends cleanly at the sender, you'd be pretty far along. (And 1 sending workstation gets, at worst, 100 acks from 100 receivers -- less if receivers ack every 2nd segment). I believe Van Jacobson and Jon Crowcroft looked at this problem in more detail and may well have something more to add. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102314471400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 10:55:24 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA14594; Wed, 24 Oct 90 10:46: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: 23 Oct 90 14:47:14 GMT From: eru!hagbard!sunic!dkuug!daimi!pe!phl@bloom-beacon.mit.edu (Per H Larsen) Organization: Purup Electronics A/S, Denmark Subject: TCP/IP on MS-DOS PC Message-Id: <1012@pe.dk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm involved in a project where we want our Unix computer to function as a server to some MS/DOS PC's. I want to write MY OWN applications on the PC that communicates with the Unix server. My plan is to do this in a TCP/IP - Ethernet enviroment so I'm looking for Software that implements TCP/IP on a MS/DOS PC and additionally has an Application Programmers Interface from C. Further I'm looking for a realy good Ethernet controler for the PC's. I have heard of Wollongong WIN/TCP but there must be other products ? Has any one had experience with Wollongong WIN/TCP ? or any other product ? Any product is of interest. Please Email me directly. I'll send a summary to the net if there appers to be any interest. ***************************************************************************! ! +-----------------------------------------------------------------------+ ! ! + Per Hyttel Larsen --- Telephone : +45-86 22 25 22 + ! ! + Purup Electronics /---\ Facsimile : +45-86 22 25 11 + ! ! + Soenderskovvej 5 | . . | Telex : 68242 purel dk + ! ! + DK - 8520 Lystrup \ U / Email : phl@pe.dk + ! ! + Denmark \-/ Uucp : ...!dkuug!pe!phl + ! ! +-----------------------------------------------------------------------+ ! *************************************************************************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102315330200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 12:39:16 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19625; Wed, 24 Oct 90 12:38: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: 23 Oct 90 15:33:02 GMT From: dsl.pitt.edu!pitt!elvis.cs.pitt.edu!field@pt.cs.cmu.edu (Gus) Organization: Computer Science Dept., Univ. of Pittsburgh Subject: UDP/IP over ether weirdness Message-Id: <8945@pitt.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I've got an application that would like to send the largest UDP packet it can. (sun3 - sun3 running 4.0.3 over 10MB ethernet). The only reference to max UDP packet size is in the RPC section where it says the max size the UDP transport mechanism can handle is 8K bytes. (sendto () does not return EMSGSIZE until I try to send >9000 bytes per datagram). Anyway, when I send 8K byte packets, sendto () doesn't complain, but the packets never arrive at the receiver. In fact, if I attempt to send a datagram larger than 2048 bytes, it never arrives at the receiver. Running etherfind on a third machine, and watching the traffic between the UDP src and dst's I see: ----- 2048 byte packet: 1514 udp pebbles wilma 1788 4343 * 610 udp This datagram is delivered correctly to the destination application. ----- 2049 byte packet: 1066 udp pebbles wilma 1790 4343 * 611 udp Now, something is definitely wrong here. ----- So, what is the limit on UDP size messages (besides the 16 bit length field limit)? Is 2048 bytes per UDP datagram the limit? Thanks Brian ----- field@cs.pitt.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102317290700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 10:37:48 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13771; Wed, 24 Oct 90 10: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: 23 Oct 90 17:29:07 GMT From: hercules!frisbee.cisco.com!allan@apple.com (Allan Leinwand) Organization: cisco Systems, Inc. - Menlo Park, CA Subject: Re: Need phone numbers... Message-Id: <21861@hercules.csl.sri.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hello all, If there are multiple copies of this around, sorry to waste the bandwidth. I fought the news reader and I think it won.... The cisco 800 number for customer service is 1-800-553-NETS or 1-800-553-6387. Thanks, Allan Leinwand cisco Systems leinwand@cisco.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102317364000> Received: from bells.cs.ucl.ac.uk by NIC.DDN.MIL with TCP; Tue, 23 Oct 90 07:59:52 PDT Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <7870-0@bells.cs.ucl.ac.uk>; Tue, 23 Oct 1990 15:56:42 +0100 To: William Chops Westfield cc: tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols In-reply-to: Your message of Mon, 22 Oct 90 23:37:02 -0700. <12632005207.2.BILLW@mathom.cisco.com> Date: Tue, 23 Oct 90 15:56:40 +0100 From: Jon Crowcroft the world used to divide into datagram & virtual circuit it now cuts many ways - connection oriented versus connectionless is on dimension, but reliability is another orthogonal issue ... some people would assert that using a 'first' datagram to establish buffer allocation for an entry in a router's tables to decide on who gets packets dropped is connection oriented ... it's just not reliable...on the other hand, asking for the right TOS may insure reliability, even though the packet format is datagram... so i dont agree with jon postel...however, "reliable internet" may be an oxymoron:-) but seriously, 'reliable virtual circuits' is an oxymoron if you've ever tries using (I)PSS...calls get ripped out with disconnection reasons like 'congestion' , which doesnt sound too dissimilar from routers dropping packets (except you have to wait a while longer before sending your next packet - or do you - well prob. not if you are running slow start x.25, now there's an idea:-)) jon crowcroft ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102318091600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 08:08:18 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06722; Wed, 24 Oct 90 07:55: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: 23 Oct 90 18:09:16 GMT From: hplred!haddad@hplabs.hpl.hp.com (R. Peter Haddad) Organization: Hewlett Packard Labs, Palo Alto CA Subject: Re: subnets Message-Id: <11080002@hplred.HP.COM> References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil / hplred:comp.protocols.tcp-ip / jacobson@cs.iastate.edu (Doug Jacobson) / 2:19 pm Oct 22, 1990 / I have two general questions about subnetting in TCP/IP. At Iowa State University we have a class B address and our campus network consists of a four large bridged Ethernet segments with a FDDI backbone used to connect these segments. Some of the segments contain IP Gateways. The campus was using transparent subnetting until about a month aao when the campus changed to unsubnetted. The Broadcast addresses and the Netmasks have been changed. (Broadcast changed from 129.186.X.255 to 129.186.255.255 and the netmask changed from 255.255.0.0 to 255.255.255.0). The questions I are: 1) Should we have changed the campus to not support transparent subnetting even though we do have some true subnets within our domain. 2) How do other organizations with class B addresses set up their networks and do they use transparent subnetting. You can mail your responses to me at doug@isuee1.ee.iastate.edu if there is enough interest I will post the results to question 2. ---------- Doug : Perhaps I am missing something here. Your broadcast address seems to have changed to accomodate a 0 length subnet field, therefore a 16 bit host field. Your netmask however has been changed to allow an 8 bit subnet field, and therefore an 8 bit host field. Am I misunderstanding the situation ? What do you mean by "transparent" subnetting ? Peter Haddad HPLabs Network Eng. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102319224600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 11:38:52 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16760; Wed, 24 Oct 90 11:36: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: 23 Oct 90 19:22:46 GMT From: mips!ultra!rajiv@apple.com (Rajiv Dhingra) Organization: Ultra Network Technologies Subject: tcp delayed acks Message-Id: <1990Oct23.192246.3050@ultra.com> References: <9010230140.AA07826@WLV.IMSD.CONTEL.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have a question regarding acks sent out by SUNs implementation of TCP/IP. If SUNs TCP receives a data packet of 1024 bytes followed by a second data packet of 410 bytes, it sends an ACK packet acknowledging the 1434 bytes immediately. However, if it receives a data packet of 1024 bytes followed by a second data packet of 409 bytes, it delays sending an ACK packet for 200 milli-seconds. The window that it advertises in both cases is 4096 bytes. Under what cases does it decide to delay sending out an ACK packet? Thanx in advance for replies. Rajiv Dhingra Ultra Network Technologies domain: rajiv@Ultra.COM 101 Daggett Drive Internet: ultra!rajiv@Ames.ARC.NASA.GOV San Jose, CA 95134 uucp: ...!ames!ultra!rajiv 408-922-0100 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [PCG.90Oct23213428@athene.cs.aber.ac.uk] <1990102321342800> From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.protocols.nfs,sci.skeptic,comp.protocols.tcp-ip Subject: Re: New product announcement: NFSper Message-ID: Date: 23 Oct 90 21:34:28 GMT References: Sender: pcg@aber-cs.UUCP Distribution: comp Organization: Coleg Prifysgol Cymru Lines: 31 Posted: Tue Oct 23 22:34:28 1990 Nntp-Posting-Host: athene In-reply-to: nelson@sun.soe.clarkson.edu's message of 14 Oct 90 23:11:39 GMT On 14 Oct 90 23:11:39 GMT, nelson@sun.soe.clarkson.edu (Russ Nelson) said: nelson> ESP Software would like to announce their newest product, nelson> NFSper. NFSper is a NFS server with an order of magnitude nelson> better performance than any existing NFS server. NFSper uses a nelson> proprietary technique to cache NFS requests on the client before nelson> they are transmitted to the server. Lab tests have shown that nelson> the NFS packet are available on the client an average of 100 nelson> microseconds before the client sends the request. Under test nelson> conditions, we have observed packets a full 250 uSec before the nelson> request transmission! Such blatant advertising! Not to mention that the technology used by ESP may be infringing on the original rights held by Prof. Donald Knuth for anticipative algorithms (the so called 'Pasadena street' style), as described in ACP vol. 1, chapter on coroutines. It is also true that Dr. Isaac Asimov, the distinguished inventor of tiotimoline, the intensional solvent, may have also a valid claim to rights on anticipative technologies. I cannot resist mentioning a major player in this market, which is rumoured be on the verge of adopting 'not responding -- still trying' as corporate trademark (unfortunately for them quick research has revealed that many of its competitors have already adopted it, at least in spirit), and maybe make a major product name change, something along the lines of "Archeological File System". -- 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---- <1990102322192800> Received: from cwns9.INS.CWRU.Edu by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 02:02:43 PDT Received: by cwns9.INS.CWRU.Edu (5.61+ida+/CWRU-1.3-client) id AA03450; Wed, 24 Oct 90 04:59:28 -0400 (from ah335 for tcp-ip@nic.ddn.mil) Message-Id: <9010240859.AA03450@cwns9.INS.CWRU.Edu> Date: Wed, 24 Oct 90 04:59:28 -0400 From: ah335@cleveland.Freenet.Edu (Richard Banks) To: tcp-ip@nic.ddn.mil Subject: Help Reply-To: ah335@cleveland.Freenet.Edu I would like to join this list if the moderator sees this please add me, Thanks. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102322503200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 13:11:59 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21182; Wed, 24 Oct 90 13: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: 23 Oct 90 22:50:32 GMT From: pacbell.com!tandem!ernest@ucsd.edu (Ernest Hua) Organization: Tandem Computers, Inc. Subject: QUESTION on how to set up reverse mapping for subnets Message-Id: <1990Oct23.225032.15065@tandem.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Here is an example of a net with a subnet: | | 199.99.44.1 199.99.55.1 | ---------------------------------- | | | | | | 199.99.55.* 199.99.66.* 199.99.77.2 | | 199.99.77.* 199.99.44.1 (inside address is 199.99.55.1) is the name server. What if I want to have, say 199.99.77.88, visible by reverse name resolution (address to name mapping)? What is the proper way to set things up? Assuming that I don't really want any other 199.99.77.* hosts to be visible via reverse mapping, except maybe 199.99.77.2 (only if that's necessary). Please E mail replies to ernest@tandem.com. Thanks! Ernest Hua Tandem Computers 408-285-5580 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102323420000> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Mon, 22 Oct 90 19:35:56 PDT Received: from TWNCTU01.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8148; Mon, 22 Oct 90 22:34:37 EDT Date: Tue, 23 Oct 90 10:22 U From: Subject: telnet problem To: tcp-ip@nic.ddn.mil X-Original-To: tcp-ip@nic.ddn.mil, KCPENG Hi, the following telnet problem appears after system has booted up a period of time: % telnet xxx Trying... Connected to xxx. Escape charcter is '^[' then system hangs. It seems the remote telnetd has been connected, cuz the escape sequence is in effect. And likely this problem appears only in Sun W/Ss. Any hint is highly welcome. Kai-Chih Peng kcpeng@twnctu01 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102403060600> Received: from gateway.mitre.org by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 06:46:48 PDT Return-Path: Received: by gateway.mitre.org (5.61/SMI-2.2) id AA21437; Wed, 24 Oct 90 09:46:23 -0400 Full-Name: Allison J. Mankin Message-Id: <9010241346.AA21437@gateway.mitre.org> To: stanonik@nprdc.navy.mil Cc: tcp-ip@nic.ddn.mil Subject: Re: 4.3bsd/watching icmp traffic In-Reply-To: Your message of "Thu, 18 Oct 90 13:22:00 PDT." <9010182022.AA25195@atlantic.nprdc.navy.mil> Date: Wed, 24 Oct 90 09:46:06 -0400 From: mankin@gateway.mitre.org Ron, We distribute a program that gets compiled into the 4.3 kernel and lets applications read any or all IP traffic that is being forwarded. It is called NETMON/iptrace. The code and a document explaining how it works and how to install it can be anonymously ftp'd from aelred-3.ie.org (192.48.115.36): pub/netmon.tar or pub/netmon.tar.Z. For your requirement, you would want to compile only the instrumented ip_input.c. Otherwise, follow the directions as given. By the way, the overhead of NETMON is about 5% or less, depending on the packet arrival rate. And iptrace uses CPU on the same order as the gated executable. A. Mankin mankin@gateway.mitre.org MITRE-Washington Networking Center ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102405523200> Received: from ftp.com by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 22:13:42 PDT Received: from stev.d-cell.ftp.com by ftp.com via PCMAIL with DMSP id AA01693; Wed, 24 Oct 90 14:12:32 -0500 Date: Wed, 24 Oct 90 14:12:32 -0500 Message-Id: <9010241912.AA01693@ftp.com> To: Bob Stewart Subject: Re: [swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu: Re: SNMP monitors] From: stev@ftp.com Cc: snmp@nisc.nyser.net, tcp-ip@nic.ddn.mil Sender: stev@ftp.com Repository: babyoil.ftp.com Originating-Client: d-cell.ftp.com > 3) Fancy graphics. Migrating from an early X window environment > to Motif doesn't buy the network manager a lot. This has distracted > developers excessively. But Motif is very pretty; witness the > Cabletron displays. Nice pastels, shadows, pictures, etc. Value? To > be determined. The people running the InterOp show network used ping > and traceroute a lot, but then they may be old fashioned. :-) > > --Kent wait a minute here.:) you could say that i had a prat in the Interop show network. you could also say i was there for 95% of the debugging that went on. while we used ping alot to debug the network, we also used SNMP often. checking ARP caches and routing was a popular pastime, as was checking interface status. the real story is *much* different than this simple statement implies, though. SNMP was not used as much as it could have been for one simple reason. no matter what people tell you, the tools currently on the market are not easy to use. in general, the SNMP tools that got used most were the ones that had people who knew how to use them there to use them. personally, i used command line tools (like ping, tracert, and get), because that was what i knew how to use. one of the press people who talked to me asked me which of the SNMP monitors i liked best. i told him it was none of his business, since he should form his own opinions, but the *real* answer was that i was too busy to learn how to use *any* of them (with one exception, the command line tools were easy enough to use). if we are talking about what tools need, allow me to enlighten you for a moment. from my experience at interop, i can tell you some interesting things. 1) SNMP is useless if the network doesnt work. large monitoring stations with great graphics are useless if they are not connected to the network. a small, command line of character based tool would have been more useful, since it could have been toted around on a portable to the sections of the network that worked. 2) SNMP graphics tools are useless if they provide too much information on the screen. this may have been a configuration problem, but most of the screens were *so* crowded, that a significant amount of time was used trying to find the node you wanted to query, so you could click on it. 3) maybe i am too anxious, but i also dont like tools that make me click on several things before i can query a router. lord forbid that the name resolution calls are blocking, and lock the window, so i cant kill it and try an IP address. 4) none of the tools seemed smart enough to figure out that their router went down, and that was why everything was failing. no one pinged the router they were using when things started to rapidly fail, to see if they had become isolated. 5) few, if any, of the tools seemed to back off to ping to see if a machine was there. sooo, non-snmp machines status could not be checked, even to a rough approximation. basically, SNMP was useful, but the functionality needed for dealing with a network in the process of being brought up and configured was not there. too bad so few of the people who are trying to sell products into this market tried to help us fix our problems to see how to make their tools better. i hope the people that did show up took notes, there are alot of things that could have been changed to make life easier. larger, more computionally intensive applications are not, in my opinion, the only place to be spending more resources. portable tools are going to remain vaulable for a long time, campers . . . . . . stev knowles ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102405544200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 17:41:07 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02756; Wed, 24 Oct 90 17:37: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: 24 Oct 90 05:54:42 GMT From: att!emory!samsung!munnari.oz.au!uniwa!bilby.cs.uwa.oz.au!bison!jamesp@ucbvax.Berkeley.EDU (James Pinakis) Organization: Dept. Computer Science, University of Western Australia. Subject: Re: Reliable Datagram ??? Protocols Message-Id: References: <9010231728.AA03948@braden.isi.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Maybe I've missed something here, but what happens if you have multiple entities which want to send datagrams between each other, and it may be the case that only one datagram is sent between any given pair. In this case, isn't the overhead of establishing a TCP connection merely to send one "datagram" (or "data which preserves message boundaries" or whatever the pedants like to call it) too great? Isn't this the exact situation when a different protocol is required and building a scheme on top of TCP is bad? And if I don't _want_ a connection between two sites (i.e. I only want to send discrete messages) then why should I create one, send the data, and then pull it down? I agree that such a protocol is not really connectionless and that state must be maintained at both ends, but at least from the application layer (assuming it's implemented as a transport layer protocol) it _looks_ like I am reliably sending datagrams. I've spend some time over the last few months implementing just such a protocol. Basically it is a fairly straightforward implementation of a sliding window protocol (protocol 6 from Tanenbaum actually) optimised to support a particular sort of client/server model. The main thing which it has over TCP, I believe, is that establishing the state information is sufficiently "lightweight" so that the cost of a client sending a small number of packets to a server is not prohibitive. james jamesp@bison.cs.uwa.oz.au ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102408332600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 18:14:26 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03398; Wed, 24 Oct 90 17:58: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 Oct 90 08:33:26 GMT From: sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU (Rob Warnock) Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols) Message-Id: <73099@sgi.sgi.com> References: <9010221418.AA03839@ftp.com>, , <60282@bbn.BBN.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <60282@bbn.BBN.COM> craig@ws6.nnsc.nsf.net.BBN.COM (Craig Partridge) writes: +--------------- | So if you could open a TCP connection to an IP multicast address, and | figure out how to handle the remote ends cleanly at the sender, you'd be | pretty far along. (And 1 sending workstation gets, at worst, 100 | acks from 100 receivers -- less if receivers ack every 2nd segment). +--------------- XTP multicast receivers send the ACKs to the multicast address too, which allows for something the XTP spec calls "damping" (which I prefer to call "stifling"). If receiver "A" hears another receiver "B" emit an ACK with "worse" news than what "A" was going to ACK, then "A" "damps" its ACK (stifles itself, stays quiet). A helpful related feature is "slotting", wherein a receiver delays a random amount of time before sending an ACK, in the hopes that someone else will send "worse" news and it can stifle itself. Damping/slotting are optional features in XTP; with a small number of receivers, they have some negative throughput implication due to the increased delay on the ACKs and the (slightly) increased overhead of running the damping algorithm. But with very large numbers of receivers they can save a good bit of network bandwidth. What would otherwise be a large burst of ACKs (one from every station) is replaced by a much smaller flurry of ACKs, each one bearing "worse news" than its predecessor. The sender retransmits based on the "worst news" (lowest ACK number) heard during each epoch of ACK-gathering (called "buckets", in the XTP spec.) And all this works in the absence of a reliable group-membership protocol. However, in order to avoid "leaving a receiver behind", you have to extend your retransmission buffers and ensure that you get "enough" epochs of ACK-gathering (enough "buckets") so that the probability of losing "too many" consecutive ACKs from the receiver with the worst news is "as low as you like". But increasing the number of epochs per unit time increases the number of ACKs, and thus the network overhead. (*sigh*) [The tradeoffs between retransmission buffer size, ACKs per RTT, and probability of losing a receiver are discussed in detail in "Appendix B" of the "XTP Protocol Definition, Revision 3.5".] Anyway, as Vernon Schryver mentioned, it certainly *ought* to be be possible to graft the XTP/multicast "bucket algorithm" onto TCP + IP/multicast... -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---- <1990102409432900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 08:47:55 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01832; Thu, 25 Oct 90 08:44: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: 24 Oct 90 09:43:29 GMT From: mcsun!ukc!pyrltd!root44!hrc63!fddi@uunet.uu.net (FDDI Group (Ian Wakeman - A26)) Organization: GEC Hirst Research Centre Subject: Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols) Message-Id: <1990Oct24.094329.5037@gec-rl-hrc.co.uk> References: <9010221418.AA03839@ftp.com>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article gnb@bby.oz.au (Gregory N. Bond) writes: >I would be happy for some sort of overhead for the reliability (e.g. >server broadcasts empty packets with the highest serial number once >every 10 seconds), but before I re-invent wheels, has someone done >something like this? >Greg. although it may be heresy to say it in this group, XTP has some reliable multicast features inside of it, although I doubt whether they've been tested on a WAN, and claiming reliable multicast without group management facilities is a trifle absurd - how do you know that all possible respondees have replied? (Yes, I know that group management is then delegated to the session management :-) ian ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102411430000> Received: from QUCDN.QueensU.CA by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 12:45:30 PDT Received: from QUCDN.QueensU.CA by QUCDN.QueensU.CA (IBM VM SMTP R1.2.2MX) with BSMTP id 4703; Wed, 24 Oct 90 15:44:35 EDT Received: by QUCDN (Mailer R2.07+QK) id 9618; Wed, 24 Oct 90 15:44:34 EDT Date: Wed, 24 Oct 1990 15:43 EDT To: tcp-ip@nic.ddn.mil From: Andy Hooper Message-ID: <90297.153558HOOPER@QUCDN.QueensU.CA> Subject: Re: Reliable Datagram ??? Protocols If you look closely at RFC 1006 (ISODE transport service on TCP), and strip out all the stuff about TPDUs, what's left is a record boundary protocol for TCP. It basically just puts a byte count in front of each "record" (or NPDU in the ISODE context). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102411505000> Received: from sun2.nsfnet-relay.ac.uk by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 02:56:34 PDT Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <1728-4@sun2.nsfnet-relay.ac.uk>; Wed, 24 Oct 1990 10:47:19 +0100 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa03753; 24 Oct 90 10:46 BST Via: dcs.leeds.ac.uk (csvax1.ARPA); Wed, 24 Oct 90 10:52:29 GMT Received: from csunb0.dcs.leeds.ac.uk (csunb0.ARPA) by dcs.leeds.ac.uk; Wed, 24 Oct 90 10:50:45 GMT From: J Jackson Date: Wed, 24 Oct 90 10:50:50 BST Message-Id: <21894.9010240950@csunb0.dcs.leeds.ac.uk> Received: from csunb6.dcs.leeds.ac.uk by csunb0.dcs.leeds.ac.uk; Wed, 24 Oct 90 10:50:50 BST To: tcp-ip@nic.ddn.mil Subject: WANTED: bootpd (RFC951) source Can anybody point me to a public copy of a bootp daemon for Unix - by preference System V (if it makes any difference). Cheers Jim Jackson School of Computer Studies JANET Email: jj@uk.ac.leeds.dcs Leeds University INTERNET: jj@dcs.leeds.ac.uk Leeds Phone: +44 532 335451 LS2 9JT ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102412270200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 12:53:40 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA20301; Wed, 24 Oct 90 12:51: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: 24 Oct 90 12:27:02 GMT From: otter.hpl.hp.com!otter!gcaw@hplabs.hpl.hp.com (Greg Watson) Organization: Hewlett-Packard Laboratories, Bristol, UK. Subject: Re: French experience needed Message-Id: <2190003@otter.hpl.hp.com> References: <9010231842.AA23604@ftp.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil It's a familiar way of saying ".... it might be interesting to you, but it's of absolutely no interest to me" -Greg ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102413045700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 09:30:32 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10812; Wed, 24 Oct 90 09:17: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: 24 Oct 90 13:04:57 GMT From: harvisr!sob@husc6.harvard.edu (Scott Bradner) Organization: Harvard University, Cambridge MA Subject: router tests V.3 - PS Message-Id: <4501@husc6.harvard.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil oops - a few things about the router testing posting the correct name for the "Proteon RIG" is the "Proteon XP 20000" the "fld" on the table is the "raw" rate (i.e. frames input at the maximum rate that the test equipment can produce) and here is the delay values (I seem to have missed one of the cisco cases - sorry) ------------------------------------------------------------------- 3com NETBuilder - delay size min avg max 64 .2 .21 .25 128 .2 .21 .25 256 .2 .21 .25 512 .2 .21 .25 1024 .2 .21 .25 1518 .2 .21 .25 BBN T20 - delay size min avg max 64 .2 5 10 128 .2 5 10 256 .2 5 10 512 .2 5 10 1024 .2 5 10 1518 .2 5 10 NSC between - delay size min avg max 64 .41 .41 .42 128 .5 .5 .6 256 .5 .5 .6 512 .5 .55 .6 1024 .5 .55 .6 1518 .5 .55 .6 NSC - within - delay size min avg max 64 .21 .21 .21 128 .22 .22 .22 256 .24 .24 .24 512 .25 .25 .25 1024 .25 .25 .25 1518 .25 .25 .25 Novell NetWare - delay size min avg max 64 .5 .55 .6 128 .55 .58 .62 256 .6 .625 .65 512 .62 .65 .7 1024 .78 .8 .82 1518 .8 .85 .9 Timeplex TIMELAN - delay size min avg max 64 .15 .15 .15 128 .15 .15 .2 256 .18 .18 .25 512 .2 .2 .3 1024 .2 .2 .3 1518 .28 .28 .28 Wellfleet - between - delay size min avg max 64 .4 .4 .41 128 .41 .41 .42 256 .42 .42 .42 512 .5 .5 .51 1024 .59 .59 .6 1518 .65 .65 .68 Wellfleet - within - delay size min avg max 64 .28 .28 .28 128 .28 .28 .28 256 .28 .28 .28 512 .28 .28 .28 1024 .28 .28 .28 1518 .28 .28 .28 cisco - within - delay size min avg max 64 .8 .8 .8 128 .8 .8 .8 256 .8 .8 .8 512 .8 .8 .8 1024 .8 .8 .8 1518 .8 .8 .8 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102413080000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 18:14:36 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03608; Wed, 24 Oct 90 18:04: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: 24 Oct 90 13:08:00 GMT From: sdd.hp.com!apollo!apollo.hp.com!mishkin@ucsd.edu (Nathaniel Mishkin) Organization: Hewlett-Packard Company - Cooperative Object Computing Operation Subject: Re: Reliable Datagram ??? Protocols Message-Id: <1990Oct24.090841@apollo.HP.COM> References: <9010221418.AA03839@ftp.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010221418.AA03839@ftp.com>, jbvb@FTP.COM (James B. Van Bokkelen) writes: >So, every time this came up in the past, the next stage was to ask the >person looking for a "reliable connectionless protocol" or somesuch what >was really needed. The most frequent goal has been some sort of transport >for a little machine, or a new one for which there is no networking >software yet. The searcher doesn't want to implement all of TCP, and sees >"datagrams" as being easier, particularly on a single Ethernet. Another >common goal has been to get very high throughput by avoiding the "excessive >overhead" of TCP, but Van Jacobsen's research has more or less laid that >one to rest. A third one has been "preservation of message boundaries". Good summary. Having made the mistake (no doubt through initial fuzzy-headedness on my part), of having built an RPC system whose protocol I called "datagram-oriented" (and which I now call "connection-oriented, but designed with the knowledge that RPC is the application that wants to use it" -- at least to people who might understand what I mean), I try to be very careful when I say "datagram" these days. Anyway, one other goal of some people in search of something other than TCP is the reduction in the number of network messages that need to be exchanged for short-lived connections (which often occur when you're doing RPC), in particular eliminating some of the connection setup and tear-down messages. E.g., for the purposes of RPC, it sure would have been nice if I could do something like send data (i.e., the remote call's input parameters) in a SYN. (I've never seen an implementation that allows this; I can't point to the place in the TCP spec that disallows it, but I imagine it is disallowed.) Maybe it's not really so bad to have the number of control messages be more than the number of data-carrying messages in case I make one remote call to a server, but my assumption is that the overall system will behave better if the number of control-only messages is reduced. -- -- Nat Mishkin Cooperative Object Computing Operation Hewlett-Packard Company mishkin@apollo.hp.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102413100700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 17:40:06 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02717; Wed, 24 Oct 90 17:35: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: 24 Oct 90 13:10:07 GMT From: mcgill-vision!clyde.concordia.ca!ganymede!bussiere@bloom-beacon.mit.edu (Luc Bussieres) Organization: Universite de Sherbrooke, Quebec Subject: Re: French experience needed Message-Id: <1990Oct24.131007.10184@DMI.USherb.CA> References: <9010232039.AA25554@ftp.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >>Does anyone know what the following phrase translates to? >>..but as they say in French ca me fait une belle jambe. >>Thanks for any help. >> -Nancy > >I think a literal translation is something like "that I make myself a >beautiful leg". I am not sure what the colloquialism means. > >Bruce A more correct literal translation would be "That make me a beautiful leg". The meaning is "we really don't care about it" -- Luc Bussieres ---- Analyste - Dep. de Mathematiques et Informatique Universite de Sherbrooke Internet : bussiere@dmi.usherb.ca Tel: (819) 821-7981 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102414570500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 13:26:33 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02234; Thu, 25 Oct 90 13:12: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 Oct 90 14:57:05 GMT From: amgraf!cpsolv!psp!loethen@uunet.uu.net Organization: PARS SERVICE PARTNERSHIP Subject: TOKEN RING VS ETHERNET Message-Id: <3084@psp.psp.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil X-NEWS: psp comp.dcom.lans: 425 GREETINGS TO ALL ON THE NET. FIRST, PRELIMINARIES. I AM POSTING THIS TO COMP.SYS.DEC,COMP.PROTOCOLS.TCP-IP, & COMP.DCOM.LANS. OUTSIDE IF THAT, CROSS-POST TO WHAT EVER YOU THINK MIGHT BE HELPFUL. ALSO, PLEASE ANSWER VIA EMAIL. MY NEWS FEED IS SPOTTY AND OCCASIONALLY UNRELIABLE. I HAVE HELPED SPECIFY AND TEST A ETHERNET - TCP/IP NETWORK TO PROVIDE BROADBAND CONNECTIVITY FOR A DEPARTMENT CONSISTING OF DEC (WORKSTATIONS, 3100 AND 3800), TANDEM AND PCS (AT AND MC BUS). AS WE HAVE COMPLETED THE TESTING OF THIS SYSTEM AND WERE MAKING PREPERATIONS TO PURCHASE SAID HARDWARE AND SOFTWARE, OUR CORPORATE SUPPORT GROUPS HAVE ASK US TO RE-EVALUATE OUR DECISIONS AND ANALYZE WHAT IT WOULD TAKE TO MAKE THIS A TOKEN-RING NETWORK INSTEAD (RUNNING NOVELL ON THE RING FOR PCs). SOME FACTS: WE NEED FILE SHARING, REMOTE LOGIN, REMOTE BACKUP, PRINTER SHARING, TERMINAL EMULATION (OBVIOUSLY) AND EVENTUALLY, REMOTE PROCEDURE CALLS. THE COMPANY GOAL IS TO MIGRATE TO OSI THERE ARE ALREADY TWO LARGE (75-100) TOKEN RINGS IN THE COMPANY, RUNNING NOVELL AND PROVIDING CONNECTIVITY FOR PC TO THE IBM MAINFRAME. QUESTIONS: IS THIS A VIABLE SOLUTION (USING TOKEN RING)? HOW MIGHT IT BE DONE? IF T/R IS NOT A BETTER SOLUTION, WHAT ARE SOME REASONS THAT MIGHT SUPPORT THE ETHERNET TCP/IP SOLUTION? I HAVE DONE SOME CHECKING INTO THIS, OF COURSE, BUT I COULD USE SOME FEEDBACK ON DIRECTIONS OR ALTERNATIVES I HAVEN'T THOUGHT OF YET. THANKS AGAIN. -- ******************************************************************************* * Shelly Loethen * "Only By Attempting the Absurd, * * * Can We Achieve the Impossible" * *=============================================================================* * ...uunet!amgraf!brian386!swl386!shellyl // loethen@psp.psp.com * ******************************************************************************* * Disclaimer: "My opinions are my own, thank you!" * ******************************************************************************* ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102415030400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 18:24:36 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03941; Wed, 24 Oct 90 18:12: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: 24 Oct 90 15:03:04 GMT From: mintaka!olivea!samsung!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!verber@bloom-beacon.mit.edu (Mark Verber) Organization: Ohio State University; Physics Department Subject: Re: WANTED: bootpd (RFC951) source Message-Id: References: <21894.9010240950@csunb0.dcs.leeds.ac.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil There is a bootp daemon (bsd 4.3) for anonymous ftp on the machine lancaster.andrew.cmu.edu in the directory /bootp. Cheers, Mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102415111200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 18:49:16 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04562; Wed, 24 Oct 90 18:27: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: 24 Oct 90 15:11:12 GMT From: mintaka!ogicse!plains!tinguely@bloom-beacon.mit.edu (Mark Tinguely) Organization: North Dakota State University, Fargo Subject: Re: named going into an infinite loop ... Message-Id: <6439@plains.NoDak.edu> References: <1990Oct22.105209.28006@ircam.ircam.fr> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Oct22.105209.28006@ircam.ircam.fr> mf@ircam.fr (Michel Fingerhut) writes: >Machine: DECsystem 5820 (RISC) >OS: Ultrix 4.0 (Rev. 179) >Every once in a while (every 3-4 days), the name daemon starts eating CPU >time, goes to the top of the queue, and fills the syslog error message >table with messages of the form > Oct 22 10:23:37 localhost: 93 named: accept: Too many open files Do you have machines that queries the name server by TCP rather than UDP? This can be found by using `netstat'. We had the same problem with a IBM 3090 querying our the BIND 4.8.1 (and earlier releases) nameserver. I am sure the Ultrix server is based upon BIND 4.8. About 7 months ago I posted the fix to this problem, and (though I did not check), I think a simular fix went into BIND 4.8.2. There are two problems, but both are based on the fact that TCP queries are queued. It is possible with the orginal BIND code, that these queries are not properly released as they sit waiting on a time queue. UDP resolutions are just discarded if they can not be resolved right away, and do not cause this problem. If you do not want to update your nameserver to BIND (boy did I find out this week how many people think I am a radical for running public-domain software [that works correctly]), then ask at DEC to update the server. Last week I removed my "diff" files for the BIND error (assuming these were picked up in BIND 4.8.3 located at ucbarpa.berrkeley.edu in the 4.3 directory). I just quickly scanned the areas that I modified in the BIND 4.8.3 files and did not see the removal of queued TCP entries, but since I don't follow the BIND mailing list, they may have implemented the solution in a different fashion than I did (or did not pick the changes at all). If there is a need for the TCP BIND fixes, I can restore them to our anonymous ftp partition. -- Mark Tinguely North Dakota State University, Fargo, ND 58105 UUCP: ...!uunet!plains!tinguely BITNET: tinguely@plains.bitnet INTERNET: tinguely@plains.NoDak.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102415442200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 11:38:28 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16643; Wed, 24 Oct 90 11:32: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: 24 Oct 90 15:44:22 GMT From: princeton.edu!tengi@princeton.edu (Christopher Tengi) Organization: Princeton University - CIT Subject: Re: telnet problem Message-Id: <3555@idunno.Princeton.EDU> References: <9010230414.AA04281@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Do you eventually get the login prompt? I have seen this type of thing happen when telnetting to Suns from a machine whose IP address cannot be resolved into a name using a DNS lookup. Basically, if I am telnetting from 128.112.129.118, the machine I am telnetting into cannot get an answer when it tries to look up 118.129.112.128.in-addr.arpa in the domain name system. Might this be the problem you are having? /Chris ==========----------==========---------+---------==========----------========== UUCP: ...princeton!tengi VOICEnet: 609-258-6799 INTERNET: tengi@princeton.edu FAX: 609-258-3943 BITNET: TENGI@PUCC ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102415485000> Received: from mcsun.EU.net by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 09:36:21 PDT Received: by mcsun.EU.net with SMTP; Wed, 24 Oct 90 17:35:59 +0100 Received: from castle.ed.ac.uk by kestrel.Ukc.AC.UK via Janet (UKC CAMEL FTP) id aa19833; 24 Oct 90 15:48 BST Received: from spider.co.uk by castle.ed.ac.uk id aa04015; 24 Oct 90 15:48 WET DST Received: by widow.spider.co.uk; Wed, 24 Oct 90 15:02:17 +0100 From: Ian Heavens Message-Id: <16419.9010241448@redrump.spider.co.uk> Received: by redrump.spider.co.uk; Wed, 24 Oct 90 15:48:53 +0100 To: tcp-ip@nic.ddn.mil Date: Wed, 24 Oct 90 15:48:50 WET DST Subject: ttcp X-Mailer: Elm [version 1.5b] What are the copyright issues with ttcp? Are vendors permitted to distribute it with their software? We would like to do this. If Mike Muus (the author) reads this, or anyone knows his email address, please email me. Thanks. Ian Heavens Spider Systems Limited Spider Park, Stanwell Street Edinburgh, EH6 5NG, Scotland +44 31 554 9424 (Ext 4166) ian@spider.co.uk ian%spider.co.uk@uunet.uu.net ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102418381400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 24 Oct 90 20:16:15 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08600; Wed, 24 Oct 90 20:10: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: 24 Oct 90 18:38:14 GMT From: mtxinu!rtech!wrs!hwajin@ucbvax.Berkeley.EDU (Hwa Jin Bae) Organization: Wind River Systems, Inc. Subject: Re: Reliable Datagram ??? Protocols Message-Id: <1273@wrs.wrs.com> References: <9010231522.AA18327@ftp.com>, <9010231706.AA25446@hogg.cc.uoregon.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010231706.AA25446@hogg.cc.uoregon.edu> jqj@HOGG.CC.UOREGON.EDU writes: >As an aside, 4.2bsd included Eric Cooper's courier compiler that implemented a >Xerox SPP-like protocol over TCP (message boundaries and message types are >needed to implement the semantics of Courier). As I recall, Eric just used >a simple counted string approach, where messages could span multiple strings >and end was delimited by an EOM bit in the message header, totally ignoring IP >packet boundaries, PUSHes, etc. (you have to guarantee a PUSH after the EOM, >I suppose). Worked just fine if what you wanted was packet boundaries on TCP; >no changes to TCP needed. pretty much the same thing is done with sun rpc over tcp. the following is from sunrpc 4.0 release: /* * xdr_rec.c, Implements TCP/IP based XDR streams with a "record marking" * layer above tcp (for rpc's use). * * These routines interface XDRSTREAMS to a tcp/ip connection. * There is a record marking layer between the xdr stream * and the tcp transport level. A record is composed on one or more * record fragments. A record fragment is a thirty-two bit header followed * by n bytes of data, where n is contained in the header. The header * is represented as a htonl(u_long). Thegh order bit encodes * whether or not the fragment is the last fragment of the record * (1 => fragment is last, 0 => more fragments to follow. * The other 31 bits encode the byte length of the fragment. */ -- hwajin@wrs.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102419310600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 06:35:22 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00839; Fri, 26 Oct 90 06:26: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: 24 Oct 90 19:31:06 GMT From: swrinde!zaphod.mps.ohio-state.edu!rpi!bu.edu!bbn.com!papaya.bbn.com!rsalz@ucsd.edu (Rich Salz) Organization: BBN Systems and Technology, Inc. Subject: Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols) Message-Id: <2939@litchi.bbn.com> References: <9010221418.AA03839@ftp.com>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In gnb@bby.oz.au (Gregory N. Bond) writes: |Consider a net with a server and many (say, 100) workstations, and a |data feed that goes to each workstation. At the moment, I have to |open 100 TCP streams, and so each packet of data generates 200 TCP |packets, all more-or-less identical. What would be nice would be to |broadcast the packet to the local net, and have the clients request |missed packets, thus implementing a sort of reliable broadcast. I believe this is what the ISIS distributed programming environment provides. Write to ken@gvax.cs.cornell.edu for more info, or read the Usenet newsgroup comp.sys.isis. /rich $alz -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010241957.AA13413@ferrari.nmc.ed.ray.com] <1990102419573800> From: smiles@ferrari.nmc.ed.ray.com (Kevin Ruddy) Newsgroups: comp.protocols.tcp-ip Subject: Intelligent bridges vs. routers Message-ID: <9010241957.AA13413@ferrari.nmc.ed.ray.com> Date: 24 Oct 90 19:57:38 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 14 Posted: Wed Oct 24 20:57:38 1990 I was just asked by an officemate of mine what the disadvantages of using an intelligent bridge over a dedicated router would be. We have about 20 SPARCstation 1s on a subnet, and another bunch of PCs and things on another subnet. Since most of the traffic on these two subnets is local to their segment, what problems would we encounter by removing the dedicated routers and replacing them with intelligent bridges? It would keep the local traffic local, but I know we would be vulnerable to broadcast storms. The company is, of course, interested in cost-savings. So what are the downfalls? Thanks for your help. Kevin Ruddy smiles@ferrari.nmc.ed.ray.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [BZS.90Oct24174403@world.std.com] <1990102422440300> From: bzs@world.std.com (Barry Shein) Newsgroups: comp.protocols.tcp-ip Subject: Re: Reliable Datagram ??? Protocols Message-ID: Date: 24 Oct 90 22:44:03 GMT References: <9010231728.AA03948@braden.isi.edu> <12632159446.18.BILLW@mathom.cisco.com> Sender: bzs@world.std.com (Barry Shein) Organization: The World Lines: 24 Posted: Wed Oct 24 23:44:03 1990 In-Reply-To: BILLW@MATHOM.CISCO.COM's message of 23 Oct 90 20:44:18 GMT >Aesthetically, though, it bothers me to have to do the extra work of >converting datagrams to streams and back when the underlying transmission >scheme is almost certainly datagram based. (Hmm, is anyone running TCP >over anything other than IP?) > >BillW But it's orders of magnitude easier than trying to add reliability (and performance, once you've added that reliability) to UDP or similar. All you basically need is to add a count field to each "packet" if you put it over TCP. (One can get fancier, depends on the real need of the application, originally I think all that was asked was that a write of X bytes at this end can be turned into a read of X bytes at the other end, record boundaries, that's trivial over TCP as it's all sequenced and reliable already.) -- -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---- <1990102423023800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 11:03:46 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08341; Thu, 25 Oct 90 11:03: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: 24 Oct 90 23:02:38 GMT From: wuarchive!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!nuug!ifi!enag@decwrl.dec.com (Erik Naggum) Organization: Naggum Software, Oslo, Norway Subject: Re: French experience needed Message-Id: References: <9010231842.AA23604@ftp.com>, <2190003@otter.hpl.hp.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil My excellent French-English translator's dictionary suggests the phrase a fat lot of good it does to me! with a small note that this is "informal usage" in both languages. I wouldn't use either expression, however. -- [Erik Naggum] Naggum Software; Gaustadalleen 21; 0371 OSLO; NORWAY I disclaim, , therefore I post. +47-295-8622, +47-256-7822, (fax) +47-260-4427 -- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102423475000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 14:07:32 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04297; Thu, 25 Oct 90 13:59: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: 24 Oct 90 23:47:50 GMT From: hercules!frisbee.cisco.com!allan@apple.com (Allan Leinwand) Organization: cisco Systems, Inc. - Menlo Park, CA Subject: Re: Intelligent bridges vs. routers Message-Id: <21892@hercules.csl.sri.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I can think of a few downfalls other than broadcast storms: 1. an intelligent bridge will not separate your address space like a router. Thus, your two subnets will exist on one logical LAN. This may result in configuring routers to understand this situation. 2. a bridge will not allow you to control the network for security reasons as well as a router if you are running multiple protocols (such as IP and DECnet). With a bridge all of your security control is usually based upon the MAC level address of a host. Keeping up with boards swaps and changing MAC addresses can become a configuration nightmare. With a router, the security can usually be setup to understand the network protocol level addresses. This usually makes security management a bit easier. 3. dare I say this? With many routers having SNMP agents, this gives you a basis for network management. Yet, (contradicting myself :-)) some bridges now answer SNMP. 4. the cost of a low end, two port router (which has router functionality AND bridge functionality) may surprise you.... Thanks, Allan Leinwand cisco Systems leinwand@cisco.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102500144900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 10:47:58 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07601; Thu, 25 Oct 90 10:48: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: 25 Oct 90 00:14:49 GMT From: qualcom.qualcomm.com!edmund@ucsd.edu (The Silver Surfer) Organization: Qualcomm Inc., San Diego, CA Subject: POP3 client for a pc Message-Id: <1990Oct25.001449.6021@qualcomm.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does anybody know of a POP3 client for the pc? It would be nice to have one that works with the Clarkson Packet Drivers, or with FTP software's PC/TCP. Thanx -- ------- / / /----- / /--/ /--- / / / /----- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102501144100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 14:42:37 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05362; Thu, 25 Oct 90 14:22: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: 25 Oct 90 01:14:41 GMT From: ucselx!sol.ctr.columbia.edu!samsung!umich!umeecs!msi.umn.edu!cs.umn.edu!dmshq!com50!kksys!jhereg!imp@ucsd.edu (Charles T. Lukaszewski) Organization: Open Systems Architects, Inc. Subject: DECnet & IPX Message-Id: <1990Oct25.011441.7834@jhereg.osa.com> References: <1990Oct5.123350.145@arizona.edu>, <2126@excelan.COM>, <1990Oct19.120616@ria.ccs.uwo.ca> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Oct19.120616@ria.ccs.uwo.ca> peter@ria.ccs.uwo.ca writes: >While DECnet IV wants to change the ethernet number to match the DECnet node >and host number, IPX only requires the same ethernet number to be used on all >interfaces to a machine. It doesn't care what they are set to. This allows >DECnet and IPX to coexist on the same router as long as you get the DECnet >running first and then start the IPX. This is correct, but does not guarantee coexistence. Remember that all VAX Ethernet controllers are Version 2 devices, NOT 802.3 devices. Netware, on the other hand, DEFAULTS to 802.3 operation. While you can certainly run both protocols simultaneously on the same cable, if you want to gateway the two environments, you have to backpatch the IPX card drivers with a utility called 'econfig.' Basically, econfig allows you to select whether you want your Novell net to run using Ethernet Version 2 (type field IPX=8037) or 802.3 (length field). This gets at a topology issue, because to avoid losing sight of your servers, you need to econfig every station on a given subnetwork. A quicker solution may be to put DEC devices on their own net hanging from a Netware server, and simply econfig just the card in the server. The Netware server, acting as a bridge, will deal with the differences internally. -- _______________________________________________________________________________ Charles T. Lukaszewski imp@osa.com 612 525-0000 Managing Partner & Chairman Open Systems Architects, Inc. "Who needs a disclaimer? I liked the opinions so much, I bought the company!" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102502401300> Received: from hpseso.sde.hp.com by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 09:40:24 PDT Received: from orac.sde.hp.com by hpseso.sde.hp.com with SMTP (15.11/SES42.42) id AA13365; Thu, 25 Oct 90 09:40:22 pdt Received: by hpsdel.sde.hp.com (15.7/SES42.42) id AA01218; Thu, 25 Oct 90 09:40:13 pdt Date: Thu, 25 Oct 90 09:40:13 pdt From: Walter Underwood Message-Id: <9010251640.AA01218@hpsdel.sde.hp.com> To: tcp-ip@nic.ddn.mil Subject: Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols) Newsgroups: comp.protocols.tcp-ip In-Reply-To: article of Tue, 23 Oct 1990 03:31:32 GMT I'm surprised that no one has mentioned Cornell's ISIS system. ISIS is a reliable multicast system with ordering guarantees. The hard part about multicast designs is not the protocol, but proving that the resulting system behaves correctly. ISIS provides a choice of orderings; two of the choices are causal ordering within the process group and causal ordering across all groups. This ordering makes designs much, much simpler. If you are already guaranteed that processes will see the same messages in the same order, then any deterministic calulations will get the same result. Notification of failures in the process group (or processes joining or leaving) are ordered like other messages. For more info, see the newsgroup comp.sys.isis, or send mail to Ken Birman (ken@cs.cornell.edu). The ISIS code is available, and runs on LOTS of systems. wunder ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102502534200> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 09:53:42 PDT Received: from braden.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Thu, 25 Oct 90 09:53:46 -0700 Date: Thu, 25 Oct 90 09:53:42 PDT From: braden@venera.isi.edu Posted-Date: Thu, 25 Oct 90 09:53:42 PDT Message-Id: <9010251653.AA05374@braden.isi.edu> Received: by braden.isi.edu (4.1/4.0.3-4) id ; Thu, 25 Oct 90 09:53:42 PDT To: sdd.hp.com!apollo!apollo.hp.com!mishkin@ucsd.edu, tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols Anyway, one other goal of some people in search of something other than TCP is the reduction in the number of network messages that need to be exchanged for short-lived connections (which often occur when you're doing RPC), in particular eliminating some of the connection setup and tear-down messages. E.g., for the purposes of RPC, it sure would have been nice if I could do something like send data (i.e., the remote call's input parameters) in a SYN. (I've never seen an implementation that allows this; I can't point to the place in the TCP spec that disallows it, but I imagine it is disallowed.) Nat, It certainly is NOT disallowed, and all of the early research TCP's tried to support it. A favorite test in "bake-offs" was to send a "Kamakazii packet", with SYN, data, and FIN all in one segment. Not all TCP's survived the test, but some did... However, sending data with the original SYN (sic) is not a big win because a full 3-way handshake is necessary before the data can be passed to the receiving application. Other protocols, e.g., delta-T and VMTP, use a timer-based mechanism to avoid 3-way handshakes; this leads to what is commonly called a "transaction transport protocol" (see RFC-955). Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102505135500> Received: from nisc.jvnc.net by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 08:54:24 PDT Received: by nisc.jvnc.net (5.61/1.34) id AA02760; Thu, 25 Oct 90 11:53:55 -0400 Date: Thu, 25 Oct 90 11:53:55 -0400 From: aggarwal@nisc.jvnc.net (Vikas Aggarwal) Message-Id: <9010251553.AA02760@nisc.jvnc.net> To: stev@ftp.com, stewart@xyplex.com Subject: Re: [swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu: Re: SNMP monitors] Cc: snmp@nisc.nyser.net, tcp-ip@nic.ddn.mil >> SNMP was not used as much as it could have been for one simple reason. no >> matter what people tell you, the tools currently on the market are not easy >> to use. Another fact is that systems supporting SNMP do not consider snmp as a high priority task- as a result I have routers that do not respond to SNMP is they are busy passing traffic. As a consequence, during the better parts of most afternoons, I would have sites change status to "unknown" or "down" all the time because the routers would not respond to SNMP. Now, if I use dear old fashioned "ping", to quote from Comer: ' Because the destination machine's Internet software handles ICMP, it is usually possible to obtain an echo even if the machine is overloaded'. I do realize that an overloaded router should be addressed, but if SNMP could gaurantee me a reply if a router was UP and doing its primary funtion, I would stop using ping to monitor our routers and pay *serious* attention to snmp based monitoring programs, as opposed to *saying* I use SNMP to prove that I am in sync with the new technologies that exist. That is to say, is there someone out there who relies *only* on SNMP to monitor the net ? Or will 'ping' be used as a monitoring tool for the rest of IP's life ? -vikas vikas@nisc.jvnc.net (609) 258-2403 Network Engineering JvNCnet, Princeton, NJ ----------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102505254800> Received: from mail.unet.umn.edu by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 11:50:43 PDT Received: from norge.unet.umn.edu by mail.unet.umn.edu (5.61/1.14) id AA17695; Thu, 25 Oct 90 13:45:20 -0500 Date: Thu, 25 Oct 90 13:45:48 -0500 From: "Craig A. Finseth" Message-Id: <9010251845.AA14599@unet.unet.umn.edu> Received: by unet.unet.umn.edu; Thu, 25 Oct 90 13:45:48 -0500 To: aggarwal@nisc.jvnc.net Cc: stev@ftp.com, stewart@xyplex.com, snmp@nisc.nyser.net, tcp-ip@nic.ddn.mil In-Reply-To: Vikas Aggarwal's message of Thu, 25 Oct 90 11:53:55 -0400 <9010251553.AA02760@nisc.jvnc.net> Subject: [swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu: Re: SNMP monitors] I do realize that an overloaded router should be addressed, but if SNMP could gaurantee me a reply if a router was UP and doing its primary funtion, I would stop using ping to monitor our routers and pay *serious* attention to snmp based monitoring programs, as opposed to *saying* I use SNMP to prove that I am in sync with the new technologies that exist. That is to say, is there someone out there who relies *only* on SNMP to monitor the net ? Or will 'ping' be used as a monitoring tool for the rest of IP's life ? I see no reason why it is desirable to stop using ping (or, more precisely, the ICMP Echo mechanism). Most checking just wants to know "are you there" and the ICMP Echo mechanism does that with much less overhead than SNMP ever could. For example, the network monitoring here at the U uses ICMP Echo for most checking, reserving SNMP for those "higher level" tasks such as checking routing tables and interface configurations. The software also knows not to perform the higher level checks unless the device is known to be up. (It also knows not to check hosts behind a down router, but that is not related to SNMP). Craig A. Finseth fin@unet.umn.edu [CAF13] University Networking Services +1 612 624 3375 desk University of Minnesota +1 612 625 0006 problems 130 Lind Hall, 207 Church St SE +1 612 626 1002 FAX Minneapolis MN 55455-0134, U.S.A. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102506094400> Received: from SH.CS.NET by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 10:01:15 PDT Received: by SH.CS.NET id aa10860; 25 Oct 90 13:02 EDT To: Mark Eggers cc: tcp-ip@nic.ddn.mil Subject: Re: RPC interface across various platforms In-reply-to: Your message of 22 Oct 90 21:34:18 +0000. <272365DA.17102@orion.oac.uci.edu> Date: Thu, 25 Oct 90 12:49:44 -0400 From: George Williams Sorry if this is received more than one time...problem in original parse of your addr. Ditto for cc: list. This is the $64k question..... Are there any commercial or public domain packages that will allow th e construction of a distributed application running on such diverse pla tform as..... >>> While most of the aforementioned have solutions that are designed >>> for distributed computing environments most of them tend to >>> be product-based, perhaps by design. That is there is no "one" >>> technical solution to the problem as stated; that of a generic >>> application programming interface for distributed computing >>> environments that every one uses to make the same calls on >>> any machine.( the OS may accomplish this before the API's ) >>> This is where most vendors seem to be drawing the line in the >>> sand as to which side of the open computing fence they stand >>> (straddle) on and probably for good reason; it will be the >>> one that keeps software from becoming a commodity ( oops ). >>> The good news is that everyone is making an effort to talk >>> to everyone else. The other side of the coin is "what can be >>> said" i.e. what application functionality can you access without >>> buying a specific API for you machine . >>> The companies moving in the direction of "common APIs and open network >>> toolkits" have the jump on the rest of the pack. This the area >>> where the biggest gains are to be made not just dollar-wise >>> but in the are of engineering and programming productivity. It >>> is becoming clear that the "one" solution for a generic RPC >>> will have support for many Application Program Interfaces. Suggested >>> system analysis, prior to making a strategic choice. >>> IBM MVS/XA - solutions under an SAA/CPI umbrella >>> VAX VMS - ditto OAA >>> Macintoshes- MAC everything (smile) >>> PCs - VINES,NETWARE,NETBIOS,APPC,LU.6.2 >>> BSD flavors- Take your pick from SUN,etc's ONC to OSF(oops Mach) >>> et al DCEs and see below. >>> UNIX? - appears to be the LCD when choosing, to date. >>> common API/RPC running under this will probably have broadest base with respect to mix and match capabilities and ease of implementation.. >>> Note: I have seen proprietary solutions that are nice...in fact so nice >>> elements of them will make it into standards. George Williams (Disclaimer: subjective observations. I'm sures other have specifics....) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102506342100> Received: from ftp.com by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 12:03:35 PDT Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA15469; Thu, 25 Oct 90 14:54:21 -0500 Date: Thu, 25 Oct 90 14:54:21 -0500 Message-Id: <9010251954.AA15469@ftp.com> To: att!emory!samsung!munnari.oz.au!uniwa!bilby.cs.uwa.oz.au!bison!jamesp@ucbvax.Berkeley.EDU (James Pinakis) Subject: Re: Reliable Datagram ??? Protocols 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 can fit your entire message in one MAC-layer packet, and you only have one, a formal connection can be replaced by server idempotency. However, if you have more than one message (or they are larger than one MAC-layer packet), consider the following: Dir Flags Data. <- SYN Transaction 1 request. -> SYN ACK Transaction 1 response. <- ACK FIN Transaction 2 request. -> ACK FIN Transaction 2 response. <- ACK Two transactions, five packets, perfectly legal TCP, and the server doesn't have to be idempotent. Four is the absolute minimum with UDP if the server is idempotent. I am not contending that any existing TCP API will allow this streamlined an exchange, or that all TCPs can handle data with the SYN (almost all can handle data with the FIN). However, I will argue that work in this direction offers more bang per buck than developing both the sophisticated API and a new protocol to go under it. One might criticize my scenario on the grounds that transaction processing might delay things enough to cause retransmissions. However, the same problem afflicts any transport in this situation. If processing time is predictable, the API must allow setting initial timeout values. If not, the net suffers regardless of the API. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102507473200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 13:49:11 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03404; Thu, 25 Oct 90 13:39: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: 25 Oct 90 07:47:32 GMT From: munnari.oz.au!uhccux!okumura@uunet.uu.net (Chad Okumura) Organization: University of Hawaii Subject: Please Help Me ! ! ! Message-Id: <10016@uhccux.uhcc.Hawaii.Edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Can anyone out there PLEASE e-mail me the 'Hitchhiker's guide to Internet'. The consultant here at U.H. told me that this group could help me find it. Thanks in advance... --chad ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102507483700> Received: from ftp.com by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 13:08:04 PDT Received: from stev.d-cell.ftp.com by ftp.com via PCMAIL with DMSP id AA17154; Thu, 25 Oct 90 16:08:37 -0500 Date: Thu, 25 Oct 90 16:08:37 -0500 Message-Id: <9010252108.AA17154@ftp.com> To: aggarwal@nisc.jvnc.net (Vikas Aggarwal) Subject: Re: [swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu: Re: SNMP monitors] From: stev@ftp.com Cc: snmp@nisc.nyser.net, tcp-ip@nic.ddn.mil, stev@ftp.com, stewart@xyplex.com Sender: stev@ftp.com Repository: babyoil.ftp.com Originating-Client: d-cell.ftp.com That is to say, is there someone out there who relies *only* on SNMP to monitor the net ? Or will 'ping' be used as a monitoring tool for the rest of IP's life ? i have been arguing this for years now. in an earlier version of the PSI code, we added it to the XMON program (what i am refering to is "ping backoff", if we fails SNMP, we tried ping) this adds a degree of usefulness to our software, in that it can tell you if non SNMP stuff is "UP" or not. our current monitor tool "MON", backs off to ping, displaying a hostname in green if SNMP thinks it is up, yellow if ping finds it up, and red if it cant be found. this tends to be very useful in environments with "old" equipments . . . . . . . . as near as i can tell, and no one has come out and said this, but it seems to be an undercurrent in alot of people's minds, is that SNMP is enough, and ping is somehow dirty, and shouldnt be used. (*geesh*) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102507595000> Received: from uga.cc.uga.edu by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 09:07:54 PDT Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 9164; Thu, 25 Oct 90 12:08:02 EDT Received: from UGA.CC.UGA.EDU by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 4326; Thu, 25 Oct 90 12:07:49 EDT Date: Thu, 25 Oct 90 11:59:50 EDT From: Harold Pritchett Subject: Re: named going into an infinite loop ... To: TCP-IP@NIC.DDN.MIL In-Reply-To: Message of Mon, 22 Oct 90 10:52:09 GMT from On Mon, 22 Oct 90 10:52:09 GMT Michel Fingerhut said: >Machine: DECsystem 5820 (RISC) >OS: Ultrix 4.0 (Rev. 179) > >Every once in a while (every 3-4 days), the name daemon starts eating CPU >time, goes to the top of the queue, and fills the syslog error message >table with messages of the form > > Oct 22 10:23:37 localhost: 93 named: accept: Too many open files > >(one a second, approximately) until it is killed and/or chokes /usr/spool. >Upon restart, it works fine. There is no apparent flood of requests prior >to that. Boy, do I have news for you. We had that same problem here for approx a month!! DEC looked at it, we sent them dumps, they remotely logged onto our machine, and finally they told us what was wrong! The "/etc/resolv.conf" file was mis-configured. Make SURE that the first nameserver entry in the file points to the loopback address. It should look something like this: domain your.domain.edu nameserver 127.0.0.1 We fixed ours, and have not had the problem since and that has been over two weeks. We also found that before we fixed the file, named would not dump cache or stats in response to a kill -INT or kill -IOT command, and this seems to have fixed that also. For more information, you may want to contact Therese Grise in the DEC Nashua, NH office, or Larry Pruitt in Atlanta, GA at (404) 772 2665. Harold C Pritchett | BITNET: HAROLD@UGA BITNET TechRep | ARPA: harold@uga.cc.uga.edu The University of Georgia | Athens, GA 30602 | fido: 1:370/60 (404) 542-3135 | Bbs: SYSOP at (404) 354-0817 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102508295300> Received: from p.Lanl.GOV by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 13:29:49 PDT Received: from snow-white.lanl.gov by p.Lanl.GOV (5.61/1.14) id AA25510; Thu, 25 Oct 90 14:29:53 -0600 Received: from sneezy.lanl.gov by snow-white.lanl.gov (4.1/SMI-4.0) id AA11656; Thu, 25 Oct 90 14:29:53 MDT Date: Thu, 25 Oct 90 14:29:53 MDT From: cpw%snow-white@LANL.GOV (C. Philip Wood) Message-Id: <9010252029.AA11656@snow-white.lanl.gov> To: stev@ftp.com Subject: Re: SNMP monitors] Cc: tcp-ip@nic.ddn.mil UP WITH ICMP! SNMP is not enough. What good is SNMP if the nodes on a network do not support it. And why should they. They were on the net before SNMP was a gleam in some relational database guru's eyes. ICMP offers a lot more than SNMP cause it's there and SNMP is not. I'm a raving supporter of TRACEROUTE and PING! Five years from now I'll switch to SNMP or something like it. Hmmm, is that five or ten years from now? I forget. Phil PS: I actually brought up some snmp stuff. And for the nodes on the network that support it, cisco router's, a couple of UNIX machines running PSI stuff, and Multinet on VMS, it's hunkydory! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102511430000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 14:08:39 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04255; Thu, 25 Oct 90 13:58: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: 25 Oct 90 11:43:00 GMT From: eru!hagbard!sunic!lth.se!tts.lth.se!xjeldc@bloom-beacon.mit.edu (Jan Engvald) Organization: Lund University Computing Center, Sweden Subject: LANtastic on the backbone Message-Id: <1990Oct25.114300.10385@lth.se> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have earlier reported that we had problem with Lantastic networks when they were connected to the backbone. Their ISO-like protocol caused interference to other ISO protocols ("HP-IP" in our case, most probably also AppleTalk Phase 2, Decnet Phase 5 and ISO-IP). This because they had no ISO headers following the length field. For quite a while we have now been running a new Lantastic version, the "Xerox" version. It is an Ethernet-2 protocol, they have changed the length field to have Ethernet type 81d6 instead. They are also using the following multicast addresses (in our case, they may differ in your case): ffff00600004 ffff00400001 ffff01e00004 The multicast traffic is about the same as for an Ethernet based VAX-cluster. Thanks to the Ethernet type we have had no problems what so ever with this Xerox version of Lantastic. If you want to filter it in a bridge, it can now also easily be done with just a type filter. The Lantastic users report the Xerox Lantastic to be stable. And all the previous features are retained, like very small memory consumption and easy installation and maintenance. If Lantastic is what you want, ensure you get the Xerox version and you don't any longer have to fear any interference with other traffic. Jan Engvald, Lund University Computing Center ________________________________________________________________________ Address: Box 783 E-mail: Jan.Engvald@ldc.lu.se S-220 07 LUND Earn/Bitnet: xjeldc@seldc52 SWEDEN (Span/Hepnet: Sweden::Gemini::xjeldc) Office: Soelvegatan 18 VAXPSI: psi%2403732202020::xjeldc Telephone: +46 46 107458 (X.400: C=se; A=TeDe; P=Sunet; O=lu; Telefax: +46 46 138225 OU=ldc; S=Engvald; G=Jan) Telex: 33533 LUNIVER S ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102512221400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 14:23:39 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04811; Thu, 25 Oct 90 14:11: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: 25 Oct 90 12:22:14 GMT From: eru!hagbard!sunic!mcsun!hp4nl!ruuinf!ruunsa!fysaj!muts@bloom-beacon.mit.edu (Peter Mutsaers /100000) Subject: Re: Reliable Datagram ??? Protocols Message-Id: <1662@ruunsa.fys.ruu.nl> References: <9010231728.AA03948@braden.isi.edu>, <12632159446.18.BILLW@mathom.cisco.com>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil bzs@world.std.com (Barry Shein) writes: >>Aesthetically, though, it bothers me to have to do the extra work of >>converting datagrams to streams and back when the underlying transmission >>scheme is almost certainly datagram based. (Hmm, is anyone running TCP >>over anything other than IP?) >> >>BillW >But it's orders of magnitude easier than trying to add reliability >(and performance, once you've added that reliability) to UDP or >similar. All you basically need is to add a count field to each >"packet" if you put it over TCP. There may well be another reason not to use TCP. I for example am busy with distributing programs over dozens of workstations. Every program must be able to talk to any other one, 30 TCP connections is often the maximum possible. I could automatically close a connection if a new one must be opened, but how do I know if no data is to be read, or underway, to the connection I want to close? If someone has another solution for this problem than making a reliable UDP I'd like to hear it. -- 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---- <1990102513140400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 14:50:26 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06036; Thu, 25 Oct 90 14:37: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: 25 Oct 90 13:14:04 GMT From: bbn.com!craig@eddie.mit.edu (Craig Partridge) Organization: Bolt Beranek and Newman Inc., Cambridge MA Subject: Re: Reliable Datagram ??? Protocols Message-Id: <60337@bbn.BBN.COM> References: <9010231728.AA03948@braden.isi.edu>, <12632159446.18.BILLW@mathom.cisco.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <12632159446.18.BILLW@mathom.cisco.com> BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes: > >Aesthetically, though, it bothers me to have to do the extra work of >converting datagrams to streams and back when the underlying transmission >scheme is almost certainly datagram based. (Hmm, is anyone running TCP >over anything other than IP?) Well, if you really wanna talk esthetics, I'm sure that somewhere in the world, someone is running the cisco X.25 over TCP, over an IP, which at some point in the path gets sent over an X.25 channel.... Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [15403@paperboy.OSF.ORG] <1990102513212500> From: santi@osf.org (Michael Santifaller) Newsgroups: comp.protocols.tcp-ip Subject: Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols) Message-ID: <15403@paperboy.OSF.ORG> Date: 25 Oct 90 13:21:25 GMT References: <9010221418.AA03839@ftp.com> Sender: news@OSF.ORG Reply-To: santi@osf.org (Michael Santifaller) Organization: Open Software Foundation Lines: 32 Posted: Thu Oct 25 14:21:25 1990 In article , gnb@bby.oz.au (Gregory N. Bond) writes: > Well, on a similar note.... > > I understand James' and Jon's arguments. Reliable datagrams are best > implemented with TCP and a "write(len); write(data);" layer. I am > looking for something a little different. > > Consider a net with a server and many (say, 100) workstations, and a > data feed that goes to each workstation. At the moment, I have to > open 100 TCP streams, and so each packet of data generates 200 TCP > packets, all more-or-less identical. What would be nice would be to > broadcast the packet to the local net, and have the clients request > missed packets, thus implementing a sort of reliable broadcast. > I would use broadcast RPC do this. SunRPC for example allows broadcasts to several servers simultaneously, you can get a reply from each and compare this with your list of recepients. I have no idea what the overhead for such a algorithm is, since the broadcasts are done through the portmapper on each system. Give it a try and make some measurements to find out its feasibility. RPC programming is easy to do. Michael Santifaller ------------------------------------------------------------------------ --------Michael Santifaller, PentaCom GmbH (Yes, OSF uses NCS, but then -- I'm not an OSF employee) -------------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102514081700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 15:07:17 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06727; Thu, 25 Oct 90 14:52: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 Oct 90 14:08:17 GMT From: bbn.com!craig@eddie.mit.edu (Craig Partridge) Organization: Bolt Beranek and Newman Inc., Cambridge MA Subject: Re: Reliable Datagram ??? Protocols Message-Id: <60340@bbn.BBN.COM> References: <12632159446.18.BILLW@mathom.cisco.com>>, , <1662@ruunsa.fys.ruu.nl> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >There may well be another reason not to use TCP. I for example am busy >with distributing programs over dozens of workstations. Every program >must be able to talk to any other one, 30 TCP connections is often the >maximum possible. >I could automatically close a connection if a new one must be opened, but >how do I know if no data is to be read, or underway, to the connection >I want to close? From a protocol designer's point of view this is a terrible argument (from an implementer's perspective, I understand the issues, but allow me to wear my designer hat for a while). To develop a "reliable UDP", you'll need state information (sequence number, retransmission counts, round-trip time estimator), in principle you'll need just about all the information currently in the TCP connection block. So building a "reliable UDP" is essentially as difficult as doing a TCP. And the only reason to do it is that your operating system constrains the number of connection blocks you can get, while the UDP interface allows you more connection blocks, because you can put the connection blocks in your application's memory space, rather than your kernel space (which is putting dumb restrictions on you). In the long run, you would almost certainly be better off fixing enhancing the kernel to support more connection blocks, than doing a "reliable UDP." You'll get a more flexible kernel, access to the protocol you really want, and won't get caught in the quagmire of maintaining yet another reliable protocol. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102514150700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 19:24:10 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17515; Thu, 25 Oct 90 19:18: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: 25 Oct 90 14:15:07 GMT From: sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU (Rob Warnock) Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols) Message-Id: <73238@sgi.sgi.com> References: <9010221418.AA03839@ftp.com>, , <1990Oct24.094329.5037@gec-rl-hrc.co.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Oct24.094329.5037@gec-rl-hrc.co.uk> fddi@hrc63.UUCP (FDDI Group (Ian Wakeman - A26)) writes: +--------------- | although it may be heresy to say it in this group, XTP has some reliable | multicast features inside of it, although I doubt whether they've been | tested on a WAN,... +--------------- True. All of the XTP/multicast applications I know of are on LANs. But XTP incorporates most of the current thinking about "slow-open", RTT estimation, and congestion control [shamelessly borrowed from TCP!], so XTP/multicast ought to work on a WAN (except there aren't any XTP routers... yet). +--------------- | ...and claiming reliable multicast without group management | facilities is a trifle absurd - how do you know that all possible respondees | have replied? +--------------- In XTP's "mostly reliable" mode, you set a service parameter (called "E" in Appendix "B" of the XTP 3.5 spec) which is how many *consecutive* negative-ACKs from any *single* station you want to be able to tolerate losing. The XTP "bucket algorithm" then ensures that at least that many attempts have been made to hear from everyone before releasing data from retransmisison buffers. Larger values of "E" require larger retransmission buffers (or you can keep the size of the retranmission buffers down by cranking up another parameter "N", at the cost of more control packet and ACK traffic -- nothing's free). If the probability of dropping an ACK from a given station is "p" (presumably much less than 1), then the probability of that station falsely being "left behind" is not worse than p^E. As long as you have a finite error rate and enough memory for retransmission buffers (or enough spare network bandwidth), you can make p^E "as small as you like". For example, you might choose to set E such that p^E was less than the probability that the station will spontaneously crash before the connection completes. In that case, "mostly" reliable is as reliable as it gets. ;-} +--------------- | (Yes, I know that group management is then delegated to the session | management :-) | ian +--------------- Not really. There is *no* group management in the "mostly reliable" mode. Stations can join and drop out of a connection, while getting reliability "as good as they like" during the time that they're joined. Maybe the following [admittedly loose anthropomorphic] analogy will help: When you first arrive at a cocktail party, you aren't a member of, say, "that conversation over there", and no-one pays any attention to whether you are hearing or missing what's being said. But if you like, you can walk over and stand within hearing range. Still, you have done nothing overt to "join" the conversation. But now it is possible for you to send negative-ACKs ["excuse me? what did you say?"] to cause retransmission. Provided the speaker is willing to back up often and far enough for you [his "retransmission buffers" are large enough] and your ACK traffic does not exceed what is considered good taste, you can get reliability "as good as you like". Yet all you have to do to leave the conversation is walk away and cease sending NACKs. Again, no overt group membership protocol was utilized. In fact, the only effect on the conversation may be, especially if you were slow or hard of hearing, that the average data rate goes up somewhat after you leave as the RTT or congestion estimators adapt to the new set of listeners [i.e., minus you]. (Of course, if you had a good receiver [ears], a high input processing rate, and a bit of patience, you may never have had to send a NACK -- someone else may have always beat you to it. I mentioned this in a previous message about XTP's "damping" and "slotting" of ACKs.) Anyway, the "cocktail party" analogy is intended to indicate why the "mostly reliable" mode of multicast might have some domains of applicabililty. In fact, this is the mode in which most of the known XTP multicast users are operating. -Rob p.s. There is an XTP TAB sub-group activity on group management stuff to support "fully reliable" XTP multicast, but it looks to me like a longer-term standards activity... ----- 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---- <1990102514160000> Received: from nic.cerf.net by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 21:16:02 PDT Received: by nic.cerf.net (4.0/4.7) id AA00747; Thu, 25 Oct 90 21:16:00 PDT Date: Thu, 25 Oct 90 21:16:00 PDT From: Pushpendra Mohta Message-Id: <9010260416.AA00747@nic.cerf.net> To: aggarwal@nisc.jvnc.net, stev@ftp.com Subject: Re: [swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu: Re: SNMP monitors] Cc: snmp@nisc.nyser.net, stewart@xyplex.com, tcp-ip@nic.ddn.mil >> >>as near as i can tell, and no one has come out and said this, but it seems >>to be an undercurrent in alot of people's minds, is that SNMP is enough, and >>ping is somehow dirty, and shouldnt be used. (*geesh*) >> >> >> And not to mention the fact that only traceroute and ping will work when debugging problems with boxes you dont know the SNMP community names of ... --pushpendra CERFnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010260504.AA21636@ucbvax.Berkeley.EDU] <1990102515595000> From: HAROLD@UGA.CC.UGA.EDU (Harold Pritchett) Newsgroups: comp.protocols.tcp-ip Subject: Re: named going into an infinite loop ... Message-ID: <9010260504.AA21636@ucbvax.Berkeley.EDU> Date: 25 Oct 90 15:59:50 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 38 Posted: Thu Oct 25 16:59:50 1990 On Mon, 22 Oct 90 10:52:09 GMT Michel Fingerhut said: >Machine: DECsystem 5820 (RISC) >OS: Ultrix 4.0 (Rev. 179) > >Every once in a while (every 3-4 days), the name daemon starts eating CPU >time, goes to the top of the queue, and fills the syslog error message >table with messages of the form > > Oct 22 10:23:37 localhost: 93 named: accept: Too many open files > >(one a second, approximately) until it is killed and/or chokes /usr/spool. >Upon restart, it works fine. There is no apparent flood of requests prior >to that. Boy, do I have news for you. We had that same problem here for approx a month!! DEC looked at it, we sent them dumps, they remotely logged onto our machine, and finally they told us what was wrong! The "/etc/resolv.conf" file was mis-configured. Make SURE that the first nameserver entry in the file points to the loopback address. It should look something like this: domain your.domain.edu nameserver 127.0.0.1 We fixed ours, and have not had the problem since and that has been over two weeks. We also found that before we fixed the file, named would not dump cache or stats in response to a kill -INT or kill -IOT command, and this seems to have fixed that also. For more information, you may want to contact Therese Grise in the DEC Nashua, NH office, or Larry Pruitt in Atlanta, GA at (404) 772 2665. Harold C Pritchett | BITNET: HAROLD@UGA BITNET TechRep | ARPA: harold@uga.cc.uga.edu The University of Georgia | Athens, GA 30602 | fido: 1:370/60 (404) 542-3135 | Bbs: SYSOP at (404) 354-0817 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010260855.AA26330@ucbvax.Berkeley.EDU] <1990102516494400> From: gwilliam@SH.CS.NET (George Williams) Newsgroups: comp.protocols.tcp-ip Subject: Re: RPC interface across various platforms Message-ID: <9010260855.AA26330@ucbvax.Berkeley.EDU> Date: 25 Oct 90 16:49:44 GMT References: <272365DA.17102@orion.oac.uci.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 57 Posted: Thu Oct 25 17:49:44 1990 Sorry if this is received more than one time...problem in original parse of your addr. Ditto for cc: list. This is the $64k question..... Are there any commercial or public domain packages that will allow th e construction of a distributed application running on such diverse pla tform as..... >>> While most of the aforementioned have solutions that are designed >>> for distributed computing environments most of them tend to >>> be product-based, perhaps by design. That is there is no "one" >>> technical solution to the problem as stated; that of a generic >>> application programming interface for distributed computing >>> environments that every one uses to make the same calls on >>> any machine.( the OS may accomplish this before the API's ) >>> This is where most vendors seem to be drawing the line in the >>> sand as to which side of the open computing fence they stand >>> (straddle) on and probably for good reason; it will be the >>> one that keeps software from becoming a commodity ( oops ). >>> The good news is that everyone is making an effort to talk >>> to everyone else. The other side of the coin is "what can be >>> said" i.e. what application functionality can you access without >>> buying a specific API for you machine . >>> The companies moving in the direction of "common APIs and open network >>> toolkits" have the jump on the rest of the pack. This the area >>> where the biggest gains are to be made not just dollar-wise >>> but in the are of engineering and programming productivity. It >>> is becoming clear that the "one" solution for a generic RPC >>> will have support for many Application Program Interfaces. Suggested >>> system analysis, prior to making a strategic choice. >>> IBM MVS/XA - solutions under an SAA/CPI umbrella >>> VAX VMS - ditto OAA >>> Macintoshes- MAC everything (smile) >>> PCs - VINES,NETWARE,NETBIOS,APPC,LU.6.2 >>> BSD flavors- Take your pick from SUN,etc's ONC to OSF(oops Mach) >>> et al DCEs and see below. >>> UNIX? - appears to be the LCD when choosing, to date. >>> common API/RPC running under this will probably have broadest base with respect to mix and match capabilities and ease of implementation.. >>> Note: I have seen proprietary solutions that are nice...in fact so nice >>> elements of them will make it into standards. George Williams (Disclaimer: subjective observations. I'm sures other have specifics....) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102518110900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 16:50:17 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA11462; Thu, 25 Oct 90 16:42: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: 25 Oct 90 18:11:09 GMT From: rti!ntpdvp1!samc@mcnc.org (Sam Christie) Organization: Northern Telecom DMS-10 Div., Raleigh, NC Subject: 3278 Terminal emulation over TCP/IP Message-Id: <644@ntpdvp1.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Some time back I posted a request for code to TN3278 which has been ported to the Interactive SysV/386 ( 386/IX ) environment. We have a copy which compiles under HP/UX, but have been told we can not spend the time to do the port. If you have made this port, are willing to do this port for a reasonable :-) fee, or know of a commercial port, please e-mail the particulars to me. Since I can't read all the news groups, this is one I normally miss. Sam Christie Standard Disclaimer Applies Northern Telecom - DMS-10 Research Triangle Park, NC EMAIL ...!uunet!mcnc!rti!ntpdvp1!samc 919/992-3917 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102518301000> Received: from gaak.LCS.MIT.EDU by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 19:30:13 PDT Received: by gaak.LCS.MIT.EDU id AA14610; Thu, 25 Oct 90 22:30:10 EDT Date: Thu, 25 Oct 90 22:30:10 EDT Message-Id: <9010260230.AA14610@gaak.LCS.MIT.EDU> To: stev@ftp.com Cc: snmp@nisc.nyser.net, tcp-ip@nic.ddn.mil In-Reply-To: stev@ftp.com's message of Wed, 24 Oct 90 14:12:32 -0500 <9010241912.AA01693@ftp.com> Subject: Re^n: SNMP monitors From: Michael A. Patton Sender: map@gaak.LCS.MIT.EDU This started out to be a simple reply, but I found it inspired me and I ran on for about three printed pages. It was started by a couple of messages I got early this morning, and I decided to expound a little about what was good and bad about various systems for managing the network, be it a single over-all NMS program or flashing from xterm to xterm running pings and traceroutes. This message describes many of the ideas and feelings I have about managing my network and how this has affected the way I do it, including the design of an NMS program I wrote (starting over 3 years ago) and the supporting operations. This message was written over a period of many elapsed hours (>12 at least) as I sat here flipping to various management tasks, coming back to the message and flitting off again. I think there may be useful hints in here for NMS developers in designing their systems and for network managers in deciding what's important to them in their tools and, perhaps, hints on how to evaluate them. This is one person's view, but I hope some of you find value in it. It seems to have turned out rather self-promotional in parts, but since the code is available free this isn't a commercial message :-). __ /| /| /| \ Michael A. Patton, Network Manager / | / | /_|__/ Laboratory for Computer Science / |/ |/ |atton Massachusetts Institute of Technology P.S. Since it's somewhat promotional, I at least should promote something else, too: If you want more info on the tool, see the entry in RFC1147 which is briefer and contains contact info, or I can send you some of the descriptive files (I think this is destined to turn into one of them :-). If this inspired you, maybe you should look over the rest of 1147 as well. (See, Bob, I do promote your work :-) ---------------------------------------------------------------- In an ongoing discussion of NMS features and other stuff, Kent England (I think) wrote, in part: The people running the InterOp show network used ping and traceroute a lot, but then they may be old fashioned. Which inspired Stev Knowles to respond with a well thought description of what in fact did and didn't work to manage the Interop Shownet, including pointing out that SNMP was used a bit more than the above statement implied, but perhaps not as much as it could have. He pointed out that one reason the use of the SNMP NMSs was limited was training, but goes on to make five points where the limitations of the more advanced tools was a problem. This list caused me to think quite a bit and I realized I may have a point of view that develops these ideas more. My main job is day-to-day management of an operational network with about a dozen main subnets, but in my copious (ref Tom Lehrer) free time I have developed a system for managing the network which hinges on an NMS program I developed (about .2MB of source). The reasons I originally developed it, use it, and continue to expend time extending it---rather than switching to any of the more "popular" systems---are that it addresses all of Stev's points to some degree (either in the programs or the way I use them), plus a few I find important but he didn't mention. On the other hand, there are a lot of things the other systems do that have never made it to mine, after all I'm one (very) part-time programmer vs frequently a full-time or even hordes of full-time programmers. This is in part a description of why I find my tool with fewer total "features" to be more useful. The interesting thing was that until I read Stev's message, I hadn't thought to characterize it that way, I just used one of the phrases, "They have lots of shine, but no substance" or "They give good demo, but I don't see how I'd manage a real net with them" to describe the alternatives and left it at that. The main difference between the approach of these other systems and mine seems to stem from how and why they were developed. Most systems I've seen (say at Interop) were written by programmers whose job is to develop programs for sale. The time I get to put into mine comes solely from the time I spend doing direct management/planning/etc. Also my tool(s) are directed towards a narrow audience, while the others, to be a product, need to appeal to a wide audience, and especially the administrators who buy, not just the technicians who use (I had trouble not using the word manager in two different senses as both sides of that). Most features I put in my system are conceived as I work on a specific problem running the network. I collect these ideas in a file. Then when I do have some spare time, I look over the list and decide which is likely to have the best payback in future time saved. Each feature goes in because I see a specific way that it will let me do my job easier. Much of the earliest design of some of its operation are very different, because I had some of Stev's points (you knew I'd get back to these, didn't you) on my initial agenda, let me address them one at a time (and then add my own), describing how I eliminate that "problem" and why I did it that way: 1) "large ... stations with great graphics are useless if they are not [on the right part of] the network": Although my program will draw pretty pictures if you have a display, ALL the functionality is available from a dumb serial interface (except pretty pictures, but you could have a pre-printed hardcopy with you :-). In fact, I use exactly the same set of tools when managing the network over a dialup from my H19 as I do at work on my color workstation. These programs contain all the code to do the fancy stuff, they just don't call it when I'm out on a limb, so to speak. I've never tried to build a stripped down version that would fit in a portable, but it shouldn't be hard (given other conditionalizations I've put in) and sounds like an interesting new idea for my list. Thanks, Stev. 2) "screens were [too] crowded": This may not be a program feature as much as what diagrams you build, on the other hand my main diagram tool is one large window with a fairly bare bones diagram. I try hard to make the layouts as simple and as logical as possible. The idea is to not busy up the screen until you start asking for stuff. The stuff I put on a given display is the things I expect to want to get right away to isolate a problem. If there isn't a problem, I can afford slightly more leisurely access. The one thing I can't afford is an "improvement" in my non-problem access that hinders me when there's an actual failure to try and isolate. 3) many things that slow you down, including needing to "click on several things" to do something and "name resolution calls blocking": My goal from the outset (a side note here, I started this before SNMP existed) was that frequent things were fast and that anything I do regularly has to be possible with complete network failure (of course it only reports failures :-) and that near total failure should affect ability to operate to the absolute minimum. That's pretty much part of the SNMP philosophy. This also harks back to the development process, my decision on what is "frequent" or "regularly" is from observing me manage my network. Things are made easy because I find I need to do them a lot rather than I do some things a lot because that's what the NMS writer made easy. All actions used to track problems are single clicks of the correct button on the appointed thing, with perhaps a bucky bit. The only time you need multiple anything is if you need a host that's not on the display, and that's ALL done on the keyboard. As long as I'm going to have to type to get the name in, I may as well make max use of the keyboard. I don't have to click somewhere to get a form, move the mouse around to enter things in various places (hands back and forth from mouse to keyboard). An "action" that I want to perform is all mouse or all keyboard, flipping back and forth slows me down. A few things that are used less frequently or not useful in the "Quick! Track this down mode." do this, but it matters less here. All the names I am likely to resolve have been done by a seperate process that is out of the management loop and are stored on the local disk (not over NFS!). If the network stays up long enough for it to get a new set of data (yes you CAN read that as zone-transfer, though not in all cases) it does a careful atomic replacement. I always have consistant data, it's only outdated in the cases where direct queries would probably fail anyway, and the interactive part never stops to to this (unless you have real slow disks :-). This is currently done with crontab and shell scripts and is one of the areas where I am less satisfied than I might be, but every other system I've looked at has problems I find much worse. I'll probably write a real program to do this eventually and couple it to the master a little better than the scripts can, but it's quite adequate for now since it's also loosely coupled to the actual scripts that do the real DNS data. There is still one point left in my current design where you need to wait, but for at most a single network timeout. Fixing this one is REAL HIGH on my ToDo list. I really want to have the ability to suddenly say "Oh no, that was all the wrong stuff, forget all those things I asked for and go do this other NOW!" 4) "tools [didn't] figure out that their router went down": The polling loop and the diagram and interactive operation are in seperate processes (which at present are only coupled by being nearby windows I use cut-and-paste between, this is another area I think needs work on my system, they should really talk, but I'm using my experience of what I cut-and-paste to design the paradigm for how these parts will talk). Remember the goal of best possible operation under worse case failure? This is one of the specific cases I keep thinking about. If the nearby router goes down the polling may stop, but the piles of errors going by alert you that something really fatal is at hand and you immediately move to the point on the map where your workstation shows and move out. If the next nearest thing doesn't work, you've already eliminated (probably) 90% or so of the possible points to investigate and the map is working fine, you now know enough to realize the reports af things miles away not responding are easily ignored. This isn't so much "the tool noticed" as the "design made the failure softer". This can be as important sometimes. 5) "few ... back off to ping": My program treats protocols as a stack. Ping is basic to IP, SNMP runs on top of IP. If IP connectivity doesn't exist, don't try SNMP. It's also possible to set how aggressive the program should be with SNMP. Do you want it to try SNMP anytime it might possibly work, only when other status indicates it should, or not at all unless specifically requested (i.e. use ping as the normal status check). A large part of this is due to the fact that most of the structure and functionality of the system was in place before SNMP came into being, in fact most of the system doesn't use SNMP. It's a relative latecomer. 6) [This is the one Stev didn't say but is as important to me as the others if not more so] how well does it allow me to extend the supported protocols? My network runs two protocol stacks, one of them an "invented here and barely heard of (let alone supported) outside" stack of the same age as IP. The two protocols have always been equal partners in all aspects (except the other stack never had an equivalent of SNMP developed). In part the ability to add anything I want on is because I wrote it, so I can. But, I have always had a vision of how someone with a similar situation should be able to add their "funny" protocol with little work and make it coequal with the other two. In fact I have had a couple of people express interest in it just for this reason. Although (since I give out the source) I've never done the final details, the design was intentionally one that would lead itself to "you want another protocol, just write a small interface in C, compile it and link with the object library". You don't need the other source (it's just nice because, right now, there isn't any other documentation for adding protocols :-). So all of Stev's points are important to at least one other network manager, sufficiently so that I've put effort into solving them locally and they've been part of what keeps me from going to a big name NMS. What I have now addresses these six points. They are, perhaps, the most important points to my being able to diagnose and track problems on a moderate size net of mixed protocols, systems, media, etc. I've never really seen another NMS that addresses them as well as I desire. So I'll stick with my stodgy old system. It doesn't have the flash, but it stands up to the punishment of the net I have to manage and comes back for more... (and finally, because I have the source, it runs on all six different brands of workstation here and looks identical :-) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102519185200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 18:05:25 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA14236; Thu, 25 Oct 90 17: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: 25 Oct 90 19:18:52 GMT From: att!cbnewsh!cs@ucbvax.Berkeley.EDU (cetin.seren) Organization: AT&T Bell Laboratories Subject: need help w/IBM PC LAN (HEEEELP!!!) Message-Id: <1990Oct25.191852.16126@cbnewsh.att.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil As a mostly UNIX land dweller, I've come across a task which puts me into the uncharted (for me, anyway!) jungles of the DOS land. Here's my problem: There is a nice DOS fileserver that I'd like my 386 to talk to. The DOS fileserver is running IBM's PC LAN, version 1.2. Here's one thing (god forbid) I might have to do: boot my 386 with DOS, and use PC LAN to make my 386 a client to the DOS fileserver. I'm hoping some folks out there have a better solution for me. Isthere any software available for UNIX so that I can make my 386 look like it is just another client to the fileserver so that I can keep using my 386 under UNIX while gaining access to the fileserver? Technically, this should be easy enough to do, since the PC LAN is TCP/IP based, but I imagine it would be a bitch to be able to obtain the protocol specifications. Anyway, I'll appreciate any ideas, pointers (like where I can get some public domain source code, if there is any), related to this matter. My e-mail address is: (I hope I still remember my arpanet and bitnet adresses right): cs%speedy.att.com@att.arpa (BITNET) cs%speedy.att.com (ARPANET) uunet!att!speedy!cs (UUCP) If all else fails: (201) 957 3086 !!!!!!! Thanks a lot for reading the message, folks... Cetin Seren ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102519242900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 17:49:28 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13744; Thu, 25 Oct 90 17:38: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: 25 Oct 90 19:24:29 GMT From: eru!hagbard!sunic!chalmers.se!afs-news!trout!dahlstr@bloom-beacon.mit.edu (Gunnar Dahlstrom) Organization: Chalmers University of Technology, Gothenburg, Sweden. Subject: Re: LANtastic on the backbone Message-Id: <1990Oct25.192429.26058@afs-news.utc.chalmers.se> References: <1990Oct25.114300.10385@lth.se> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Why write in English, i ett svensk mote!!! Bara en liten undran. Gunnar =============================================================================== Gunnar Dahlstrom Chalmers University of Technology Div. Building Technology 412 96 Gothenbourg, Sveden E-Mail: dahlstr@hus.chalmers.se =============================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102520554500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 18:06:26 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA14626; Thu, 25 Oct 90 18:01: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: 25 Oct 90 20:55:45 GMT From: bellcore-2!envy!karn@rutgers.edu (Phil Karn) Organization: Packet Communications Research Group (Bellcore) Subject: Re: Reliable Datagram ??? Protocols Message-Id: <1990Oct25.165545@envy.bellcore.com> References: <9010221418.AA03839@ftp.com>, <1990Oct24.090841@apollo.HP.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Oct24.090841@apollo.HP.COM>, mishkin@apollo.HP.COM (Nathaniel Mishkin) writes: |> E.g., for the purposes of RPC, it sure would have |> been nice if I could do something like send data (i.e., the remote call's |> input parameters) in a SYN. (I've never seen an implementation that |> allows this; I can't point to the place in the TCP spec that disallows |> it, but I imagine it is disallowed.) I don't think anything in the TCP spec specifically disallows the piggybacking of data with SYN bits. The only possible argument against it is the fact that the active initiator of a TCP connection doesn't yet know the receiver's window size yet. But even here the the worst that should happen under the Robustness Principle is that the receiver might not have buffer space for all (or any) of the data, requiring the sender to retransmit it once the connection is fully open. This is an efficiency issue, not a protocol correctness issue, and is identical to that associated with the "optimistic window" send policy. But assuming no problems with buffer allocation, I see no reason why an entire TCP connection couldn't consist of only three packets: A->B: SYN, FIN and data B->A: SYN, FIN, ACK (and optional data) A->B: ACK Of course, most application interfaces don't provide for sending such "christmas tree" packets, but a correct implementation of TCP should be able to handle them when received. It's hard to think of a "reliable datagram protocol" that would take less than three packets to provide at-most-once semantics for a single message in each direction. Even with applications that don't require a "reliable datagram protocol", I think that the ability of TCP to piggyback control and data should be much more widely used. There's no reason why a SMTP or FTP server's opening banner couldn't be piggybacked on the server's SYN/ACK segment, saving two packets, and no reason why FIN can't be piggybacked on the last segment of a data transfer, also saving two packets. Again, a correct implementation of TCP should handle such packets just fine. While we're on the subject of piggybacking, another thing I would really like to see is widespread use of batched SMTP on the Internet. I think the number of packets it takes for most SMTP implementations to transfer a short mail message is criminal, especially when the message has several recipients on the same system. There's no reason that you shouldn't be able to send a series of SMTP commands in a single TCP segment and receive a series of responses, except that many SMTP servers inexplicably blow up when you try this. Given that TCP is supposed to be a reliable byte stream protocol, the designers of these systems must have gone well out of their way to keep this from working. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102523413600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 23:21:42 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16776; Fri, 26 Oct 90 23:10: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: 25 Oct 90 23:41:36 GMT From: dynasys!alana!jaa@rutgers.edu (Alan Anderson [068]) Organization: United Dominion Buildings Subject: SLIP Drivers SCO-ODT Message-Id: <5@alana.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am trying to install a SLIP tcp-ip driver on a system that is currently using a Western Digital 8003 for ethernet. They need to be used concurrently. Steps Performed were: mkdev tcp added a SLIP driver defined the tty set the source and destination IP address set baud rate to 9600 used the SLIP Interface default netmask when the Kernel was re-linked and the system re-booted, it hung up at TCP initialization. Please respond on sco.opendesktop, I don't trust MMDF yet. Thanks Alan Anderson (901) 762-6068 United Dominion Building 6000 Poplar Suite 400 Memphis, TN 38119 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102601142000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 19:24:22 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17299; Thu, 25 Oct 90 19:12: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 Oct 90 01:14:20 GMT From: portal!cup.portal.com!lan@apple.com (Los Altos Networks) Organization: The Portal System (TM) Subject: TELEBIT NETBLAZER Message-Id: <35266@cup.portal.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil LOS ALTOS NETWORKS IS PLEASED TO PRESENT THE FOLLOWING NEW PRODUCTS INFORMATION: T E L E B I T N E W S R E L E A S E TELEBIT ANNOUNCES DIAL-UP INTERNETWORKING NetBlazer(tm) is the first in a family of products SUNNYVALE, Calif., INTEROP '90, October 8, 1990 -- Telebit Corporation, pioneer of the high-speed dial-up modem, introduced today the industry's first automated dial-up TCP/IP router. The NetBlazer(tm) integrated communications server is the first product to use modems and the public switched telephone network (PSTN) to automatically provide virtual wide area networking for TCP/lP-based ethernets. By automating the modems' connection establishment, the NetBlazer offers seamless wide area network connections between diverse computers and/or local area networks (LANs). In addition to its virtual routing functions, NetBlazer also integrates traditional terminal server capabilities, LAN-based modem sharing, a 56K bps leased line connection, dial back-up, and ethernet to ethernet routing functions, all in a single product. The introduction of the NetBIazer represents the next major step in Telebit's strategic diversification and fuels the new dial-up internetworking marketplace. NetBlazer Answers Customers' Demands Prior to NetBlazer, expanding networks was a time consuming and costly process due to technical obstacles. NetBlazer, however, represents the marriage of the power of internetworking to the flexibility of the PSTN. As a result, the enterprise wide network has greatly increased flexibility because the PSTN offers immediate, low-cost, on-demand access. NetBlazer enables an organization to expand its network to any location in the world where there is a public telephone system. This flexibility creates a number of applications including telecommuting, which is the ability of NetBlazer to bring the network into the users' home, allowing them to become a node on the network using their personal computer or workstation in cobination with a modem. Yet another application is the ability to cost effectively connect remote sites on the PSTN as opposed to incurring the expense of a leased line. This, for example, enables large companies to tie their smaller offices together in a virtual wide area network. "We chose to begin with support for TCP/IP and Ethernet because our customers asked for a product that combines open systems standards in high- speed modems with today's most widely installed open system networking protocols, TCP/IP, and media, Ethernet. NetBlazer's open architecture will allow support for other networking protocols and media as the market demands," said Michael Ballard, Director of Telebit's Network Systems unit. Cost Effectiveness is Major Benefit to Customers NetBlazer is a cost-effective wide area networking tool with combined functionality that offers numerous additional features to the end-user. Some of these include three levels of security, multi-vendor connectivity, and on-board SNMP network management software. "Our aim with this new dial- up internetworking product is to provide the customer with more solutions within a single product (NetBlazer), easing the expense and technical obstacles associated with using different devices to provide these communications services," said Ballard. Telebit is introduced NetBlazer at Interop '90, a major conference and exhibition for the internetworking industry. Prices for the NetBlazer begin at $2,995, not including modem(s), and increase depending on the configuration. The product includes a one-year warranty on parts and labor. NetBlazer will be avaiiable by the end of November 1990. Telebit Corporation designs, manufactures and markets advanced high-speed products for dial-up networking and wide-area communications. The company's proprietary digital signal processing technologies provide extremely reliable error-free communications across the worldwide switched telephone network. Telebit markets its products worldwide through distributors, original equipment manufacturers and value-added resellers. Located in Sunnyvale, California, Telebit is a publicly held corporation and is traded on the National Association of Security Dealers Automated Quotations (NASDAQ) OTC market under the symbol TBIT. ### Telebit and NetBlazer are registered trademarks or credits of Telebit Corporation. Other trademarks or credits used are those of their respective holders. LOS ALTOS NETWORKS IS AN AUTHORIZED AND STOCKING TELEBIT VALUE-ADDED DISTRIBUTOR PROVIDING UNIX DATA COMMUNICATIONS PRODUCTS AND SERVICES. FOR MORE INFORMATION ON THIS AND ALL TELEBIT PRODUCTS, PLEASE CALL 1-415-941-8031. ============================================================================== Cerafin E. Castillo || //\\ ||\\ || Network Consultant || //__\\ || \\ || Los Altos Los Altos Networks || // ---\\|| \\|| Networks 340 Second St. #6 ||___// \|| \\| Los Altos, CA 94022 (415) 941-8031 UUCP: {apple,sun,uunet}!portal!cup.portal.com!cec NTERNET: cec@cup.portal.com "...No hay mal que por bien no venga..." =============================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102601321400> Received: from gateway.mitre.org by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 05:12:35 PDT Return-Path: Received: by gateway.mitre.org (5.61/SMI-2.2) id AA13709; Fri, 26 Oct 90 08:12:48 -0400 Full-Name: Bill Barns Message-Id: <9010261212.AA13709@gateway.mitre.org> To: craig@bbn.com (Craig Partridge) Cc: tcp-ip@nic.ddn.mil, barns@gateway.mitre.org Subject: Re: question about SMTP MX records In-Reply-To: Your message of "19 Oct 90 12:06:34 GMT." <60201@bbn.BBN.COM> Date: Fri, 26 Oct 90 08:12:14 -0400 From: barns@gateway.mitre.org Ouch, Craig, I hope I didn't hear you say that every host X that is an MX for another host Y is required to support the percent hack, that is, treat user%Y@X equivalently to user@Y? It works in most places, probably, but I don't remember this ever being raised as even a proposed requirement... Bill Barns / MITRE-Washington / barns@gateway.mitre.org ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102602132700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 25 Oct 90 22:23:45 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21915; Thu, 25 Oct 90 22:15: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: 26 Oct 90 02:13:27 GMT From: sgi!root@ucbvax.Berkeley.EDU (Superuser) Subject: MX-capable sendmail for Iris 4D machines Message-Id: <73327@sgi.sgi.com> References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In response to requests from some of our customers, a prototype version of MX-capable sendmail for Silicon Graphics Iris 4D series computers is now available for anonymous ftp from SGI.COM [192.48.153.1]. This version of sendmail is based upon Berkeley sendmail version 5.64 and includes the IDA and BIND enhancements. A compressed tar file containing the sendmail binary, the sendmail.hf file, a skeleton sendmail.cf, and a self explanatory README file can be found in the ftp directory under the pathname sgi/sendmail/MX_sendmail/MX_sendmail.tar.Z Those wishing to experiment with this code should note that it is to be considered an unsupported prototype and that the following disclaimers apply in full: ---------- This software is provided without support and without any obligation on the part of Silicon Graphics, Inc. to assist in its use, correction, modification or enhancement. There is no guarantee that this software will be included in future software releases. THIS SOFTWARE IS PROVIDED "AS IS" WITH NO WARRANTIES OF ANY KIND INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE. In no event will Silicon Graphics, Inc. be liable for any lost revenue or profits or other special, indirect and consequential damages, even if Silicon Graphics, Inc. has been advised of the possibility of such damages. ---------- Please address all comments and observations to: mxcomments@sgi.com Robert L. Stephens Silicon Graphics Inc. Mountain View, CA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102602165300> Received: from mail.unet.umn.edu by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 08:41:06 PDT Received: from norge.unet.umn.edu by mail.unet.umn.edu (5.61/1.14) id AA20448; Fri, 26 Oct 90 10:36:22 -0500 Date: Fri, 26 Oct 90 10:36:53 -0500 From: "Craig A. Finseth" Message-Id: <9010261536.AA16881@unet.unet.umn.edu> Received: by unet.unet.umn.edu; Fri, 26 Oct 90 10:36:53 -0500 To: don@usna.navy.MIL Cc: aggarwal@nisc.jvnc.net, stev@ftp.com, stewart@xyplex.com, snmp@nisc.nyser.net, tcp-ip@NIC.DDN.MIL In-Reply-To: "Mr. Donald W. Garner (CADIG STAFF) "'s message of Fri, 26 Oct 90 11:12:47 EDT <90Oct26.111251edt.76@staff.ecs.usna.navy.mil> Subject: [swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu: Re: SNMP monitors] Is that monitoring done by SunNet Manager? Has anyone had any experience with this package? No, it is a package that I wrote. I wanted one that worked, not one that was pretty. I don't know anything about SunNet. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102603280400> Received: from ftp.com by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 08:47:18 PDT Received: by ftp.com id AA00976; Fri, 26 Oct 90 11:48:04 -0500 Date: Fri, 26 Oct 90 11:48:04 -0500 From: fks@ftp.com (Frances Selkirk) Message-Id: <9010261648.AA00976@ftp.com> To: qualcom.qualcomm.com!edmund@ucsd.edu, tcp-ip@nic.ddn.mil Subject: Re: POP3 client for a pc The latest version of our software (Version 2.05, released two days ago) includes a POP3 client. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102604202500> Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 05:25:59 PDT Received: from interlan.interlan.com by RELAY.CS.NET id aa23336; 26 Oct 90 8:22 EDT Received: from europa.InterLan.COM by interlan.interlan.com (5.61/5.17) id AA05955; Fri, 26 Oct 90 08:20:08 -0400 Received: by europa.InterLan.Com (4.0/SMI-4.0) id AA01390; Fri, 26 Oct 90 08:20:25 EDT Date: Fri, 26 Oct 90 08:20:25 EDT From: Frank Kastenholz Message-Id: <9010261220.AA01390@europa.InterLan.Com> To: aggarwal@NISC.JVNC.NET, stev@FTP.COM, stewart%xyplex.com@RELAY.CS.NET Subject: Re: [swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu: Re: SNMP monitors] Cc: snmp@NS.PSI.NET, tcp-ip@NIC.DDN.MIL > From snmp-ok-forw@nisc.psi.net Thu Oct 25 20:44:29 1990 > From: aggarwal@nisc.jvnc.net (Vikas Aggarwal) > To: stev@ftp.COM, stewart@xyplex.COM > Subject: Re: [swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu: Re: SNMP monitors] > Cc: snmp@nisc.nyser.net, tcp-ip@nic.ddn.mil > > >> SNMP was not used as much as it could have been for one simple reason. no > >> matter what people tell you, the tools currently on the market are not easy > >> to use. > > Another fact is that systems supporting SNMP do not consider snmp as a > high priority task- as a result I have routers that do not respond to To all of those box builders (including Racal Interlan :-) To structure your in-box priorities in such a way as to make management (and, for bridges and routers, Spanning tree and your routing protocols) run at a lower priority than the "main" purpose of the box (e.g. forwarding packets for bridges/routers) is ABSOLUTELY BASS ACKWARDSLY WRONG. As Vikas described in his memo - when a network starts to depart for the Twinkie zone, the bridge/router may spend absolutely 100% of its time bridging/routing. Regardless of the efficiency of the network management protocol and it underlying transport, the NM packets will not be processed by the box. The manager will not be able to find out what's wrong, nor will s/he be able to take effective action (similarly for bridges - if the max out at 100% doing bridging, then spanning tree packets get ignored and the spanning tree algorithm breaks and you may wind up with loops in the net, meaning that offered load will increase - can you say melt down?) When everything else is going completely bonkers, NM, etc, MUST WORK. One of the reasons that NM protocols and agent load must be kept small is to reduce the amount of work that the box must do at this highest priority. Now, I hear the masses crying out - "I don't want NM to be highest priority - then anybody with a network management station can bring a box to its knees". Well, I hate to say this but, if someone has an NM station, they can do this anyway (set ifOperStatus.* to down). Besides which, this is not a problem of network management, this is a problem of security. If you have unauthorised people doing NM on your network, then you have a security problem, NOT a NM protocol problem. Btw, this is not just smoke, this is heat and light. Here at Interlan, we learned the hard way that what I've just said is true. During development of our bridges, under heavy load, our bridges would lock up from a NM/Spanning Tree point of view. NM said the bridges were down. For the "working" bridges, spanning tree indicated that those bridges failed. Yet there they were, forwarding packets..... In fact, sometimes they would lock up so hard that even the local console would stop working. The only way we had of solving the problems was to partition the network until things got better. Cheers Frank Kastenholz Racal Interlan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102605215500> Received: from NNSC.NSF.NET by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 09:04:05 PDT To: barns@gateway.mitre.org cc: tcp-ip@nic.ddn.mil Subject: re: question about SMTP MX records From: Craig Partridge Date: Fri, 26 Oct 90 12:01:55 -0400 Sender: craig@NNSC.NSF.NET > Ouch, Craig, I hope I didn't hear you say that every host X that is > an MX for another host Y is required to support the percent hack, > that is, treat user%Y@X equivalently to user@Y? RFC 1123 doesn't explicitly require it, but it suggests that support for the %-hack is expected (the discussion in Section 5.2.16 being my primary source). Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102605270300> Received: from operations.dccs.upenn.edu by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 09:07:03 PDT Return-Path: Date: Fri, 26 Oct 90 12:07:03 -0400 From: magill@operations.dccs.upenn.edu (PennNet Tech. Services) Message-Id: <9010261607.AA07192@operations.dccs.upenn.edu> To: fin@unet.unet.umn.edu Cc: aggarwal@nisc.jvnc.net, stev@ftp.com, stewart@xyplex.com, snmp@nisc.nyser.net, tcp-ip@nic.ddn.mil Subject: Re: SNMP monitors >> I do realize that an overloaded router should be addressed, but if >> SNMP could gaurantee me a reply if a router was UP and doing its >> primary funtion, I would stop using ping to monitor our routers and >> pay *serious* attention to snmp based monitoring programs, as opposed >> to *saying* I use SNMP to prove that I am in sync with the new >> technologies that exist. >> >> That is to say, is there someone out there who relies *only* on SNMP >> to monitor the net ? Or will 'ping' be used as a monitoring tool for >> the rest of IP's life ? > > I see no reason why it is desirable to stop using ping (or, more > precisely, the ICMP Echo mechanism). Most checking just wants to know > "are you there" and the ICMP Echo mechanism does that with much less > overhead than SNMP ever could. > > For example, the network monitoring here at the U uses ICMP Echo for > most checking, reserving SNMP for those "higher level" tasks such as > checking routing tables and interface configurations. The software > also knows not to perform the higher level checks unless the device is > known to be up. (It also knows not to check hosts behind a down > router, but that is not related to SNMP). > The problem with ping in a trouble situation is just exactly what is described in the last paragraph. One doesn't simply want to know if the router exists, but rather one wants to know "what the hell it is doing!" One needs to look a the routing tables or to up or down an interface, for example. A device that can't tell me what it is doing simply because "it's too busy" is one that is about to crash - or maybe it already did - or maybe it's simply routing the same packet over and over again - or maybe it isn't routing anything, just replying to the ICMP echo! While the routers in question seem to be pretty damm reliable and we usually discover via the telephone that it is possible to get from here to there but at reduced performance level because the router is "too busy routing". ie it's OVERLOADED. And had begun to perform a clasic utility process called "load shedding". Maybe that means that these routers aren't quite as reliable as we thought they were, or maybe it means that we have too much traffic, or maybe it means that all the traffic is bogus. Without SNMP access and statistical information, we have no way of knowing what is happeing. We can only try the forensic approach and reconstruct things after the crisis goes away and we get our queries answered. Knowing that "something exists" is not part of network management. Knowing what something is doing IS. It is not enough to simply know that something is "working" one must know that it is "working correctly". A "network technician" may only need to know that "something exists", but a "network manger" needs to know what is going on. (That's also my beef with the present "Network Management Stations". They are "trouble shooting tools", not "management tools".) William H. Magill Manager, PennNet Technical Services Data Communications and Computing Services (DCCS) University of Pennsylvania Internet: magill@dccs.upenn.edu magill@eniac.seas.upenn.edu magill@upenn.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102605334200> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 12:33:51 PDT Received: from braden.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Fri, 26 Oct 90 12:33:45 -0700 Date: Fri, 26 Oct 90 12:33:42 PDT From: braden@venera.isi.edu Posted-Date: Fri, 26 Oct 90 12:33:42 PDT Message-Id: <9010261933.AA06091@braden.isi.edu> Received: by braden.isi.edu (4.1/4.0.3-4) id ; Fri, 26 Oct 90 12:33:42 PDT To: ietf@venera.isi.edu, tcp-ip@nic.ddn.mil Subject: IAB meeting minutes available Cc: iab@venera.isi.edu, iesg@venera.isi.edu Minutes of the June 1990 IAB meeting are now available for anonymous FTP from host venera.isi.edu with the pathname: pub/IABmins.jun90.txt Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102607124700> Received: from staff.ecs.usna.navy.mil by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 08:16:37 PDT Received: by staff.ecs.usna.navy.mil id 76; Fri, 26 Oct 90 11:12:51 EDT From: "Mr. Donald W. Garner (CADIG STAFF) " To: "Craig A. Finseth" cc: aggarwal@nisc.jvnc.net, stev@ftp.com, stewart@xyplex.com, snmp@nisc.nyser.net, tcp-ip@NIC.DDN.MIL Subject: Re: [swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu: Re: SNMP monitors] Message-Id: <90Oct26.111251edt.76@staff.ecs.usna.navy.mil> Date: Fri, 26 Oct 90 11:12:47 EDT >For example, the network monitoring here at the U uses ICMP Echo ... Is that monitoring done by SunNet Manager? Has anyone had any experience with this package? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102607540400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 01:20:02 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25541; Fri, 26 Oct 90 01: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: 26 Oct 90 07:54:04 GMT From: eru!hagbard!sunic!lth.se!newsuser@BLOOM-BEACON.MIT.EDU (Ricard Wolf) Organization: Lund Institute of Technology, Sweden Subject: Re: UDP/IP over ether weirdness Message-Id: <1990Oct26.075404.25595@lth.se> References: <8945@pitt.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <8945@pitt.UUCP> field@elvis.cs.pitt.edu (Gus) writes: > >I've got an application that would like to send the largest UDP packet >it can. (sun3 - sun3 running 4.0.3 over 10MB ethernet). The only >reference to max UDP packet size is in the RPC section where it says >the max size the UDP transport mechanism can handle is 8K bytes. >(sendto () does not return EMSGSIZE until I try to send >9000 >bytes per datagram). Anyway, when I send 8K byte packets, sendto () >doesn't complain, but the packets never arrive at the receiver. In >fact, if I attempt to send a datagram larger than 2048 bytes, it never >arrives at the receiver. Running etherfind on a third machine, and >watching the traffic between the UDP src and dst's I see: > >----- >2048 byte packet: > > 1514 udp pebbles wilma 1788 4343 >* 610 udp > >This datagram is delivered correctly to the destination application. > >----- >2049 byte packet: > > 1066 udp pebbles wilma 1790 4343 >* 611 udp > >Now, something is definitely wrong here. > >----- > > >So, what is the limit on UDP size messages (besides the 16 bit length >field limit)? Is 2048 bytes per UDP datagram the limit? > >Thanks >Brian >----- >field@cs.pitt.edu Sending more than (1500-UDP&IP header length) over an ethernet connection requires IP to fragment the data upon transmission. This isn't a very common case, since protocols like TCP automatically reduce transmitted packets to a reasonably size (like 1K or 536 bytes). Since IP isn't called to fragment upon transmission very often, it isn't very well tested. Even a UDP based protocol like TFTP automatically blocks data into 512 data bytes, so IP never has to fragment here either. I remember having similar weird problems when testing an IP implementation. In order to test the IP reassembly,we sent UDP packets from a Sun 3/80 that were roughly 2K in length. At a certain size, things just didn't work right, and after several hours of head scratching and network monitoring we finally deduced that something was amiss in the Sun UDP transmission. We didn't pursue the thing further, though; we had no intention of debugging the whole Sun network code! :-) I don't even remember at what size things went wrong, but your 2K rings a bell... -- Ricard Wolf +--------------------------+-------------------------------------+ | Ricard Wolf | Lund Institute of Technology | | email: e85rw@efd.lth.se | If you can't buy 'em - build 'em !! | +--------------------------+-------------------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102608492900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 02:51:24 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27119; Fri, 26 Oct 90 02:46: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: 26 Oct 90 08:49:29 GMT From: mcsun!hp4nl!ruuinf!ruunsa!fysaj!muts@uunet.uu.net (Peter Mutsaers /100000) Subject: Re: Reliable Datagram ??? Protocols Message-Id: <1666@ruunsa.fys.ruu.nl> References: , <1662@ruunsa.fys.ruu.nl>, <60340@bbn.BBN.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil craig@bbn.com (Craig Partridge) writes: >>There may well be another reason not to use TCP. I for example am busy >>with distributing programs over dozens of workstations. Every program >>must be able to talk to any other one, 30 TCP connections is often the >>maximum possible. >>I could automatically close a connection if a new one must be opened, but >>how do I know if no data is to be read, or underway, to the connection >>I want to close? >So building a "reliable UDP" is essentially as difficult as doing a TCP. >And the only reason to do it is that your operating system constrains the >number of connection blocks you can get, while the UDP interface allows >you more connection blocks, because you can put the connection blocks in >your application's memory space, rather than your kernel space (which is >putting dumb restrictions on you). But suppose I want 1000's of processes to be able to communicate. Couldn't the overhead of just having that many connections become to big if only few of them communicate at the same time? It would be very helpful if I could use TCP indeed, but have a kind of a 'safe' close, which does indicate if more data could be underway. Besides, for my particular application I use the select() system call, which only operates on the lowest 32 file descriptors. -- 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---- <1990102609272100> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 16:27:29 PDT Received: from akamai.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Fri, 26 Oct 90 16:27:34 -0700 Date: Fri, 26 Oct 90 16:27:21 PDT From: jkrey@venera.isi.edu Posted-Date: Fri, 26 Oct 90 16:27:21 PDT Message-Id: <9010262327.AA03142@akamai.isi.edu> Received: by akamai.isi.edu (4.1/4.0.3-4) id ; Fri, 26 Oct 90 16:27:21 PDT To: munnari.oz.au!uhccux!okumura@uunet.uu.net Subject: Re: Please Help Me ! ! ! Cc: jkrey@venera.isi.edu, tcp-ip@nic.ddn.mil Chad, You should find a copy of the "Hitchhiker's Guide to Internet" (RFC1118) in your email. Happy reading. Joyce ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010261332.AA00997@ucbvax.Berkeley.EDU] <1990102610170300> From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) Newsgroups: comp.protocols.tcp-ip Subject: Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols) Message-ID: <9010261332.AA00997@ucbvax.Berkeley.EDU> Date: 26 Oct 90 10:17:03 GMT References: <60282@bbn.BBN.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 37 Posted: Fri Oct 26 11:17:03 1990 >So if you could open a TCP connection to an IP multicast address, and >figure out how to handle the remote ends cleanly at the sender, you'd be >pretty far along. > (And 1 sending workstation gets, at worst, 100 >acks from 100 receivers -- less if receivers ack every 2nd segment). >I believe Van Jacobson and Jon Crowcroft looked at this problem in >more detail and may well have something more to add. Craig, we kind of figured out the small change necessary to TCP essentially, you send to multicast address, but receive acks from each member of the multicast groups individual clas a-c addresses you have a tcpcb per member, and run each connection state machine as normal, but link the tcpcb's so you know its a group communcation to start the whole shebang, you send a syn to group, you get syn acks back and gradually build up the set of tcpcb's (instead of just alocating one at start)...when you have the full group connection, you then allow the sender to do writes on the socket... each write may block if we are still flow controlled or not acked on any one connection... for a many to one (i.e. lotsa folks sending to us) you can overload the readv interface, and return a vector of single reads... it shouldnt take a bright person with BSD source more than a day to change, and a week to debug... the same thing could be done with broadcast, without the multicast IP, but is certainly a VERY BAD IDEA:-) jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102612060200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 06:20:32 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00557; Fri, 26 Oct 90 06:09: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: 26 Oct 90 12:06:02 GMT From: usc!bbn.com!craig@ucsd.edu (Craig Partridge) Organization: Bolt Beranek and Newman Inc., Cambridge MA Subject: Re: Reliable Datagram ??? Protocols Message-Id: <60365@bbn.BBN.COM> References: <1662@ruunsa.fys.ruu.nl>, <60340@bbn.BBN.COM>, <1666@ruunsa.fys.ruu.nl> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1666@ruunsa.fys.ruu.nl> muts@fysaj.fys.ruu.nl (Peter Mutsaers /100000) writes: > >>So building a "reliable UDP" is essentially as difficult as doing a TCP. >>And the only reason to do it is that your operating system constrains the >>number of connection blocks you can get, while the UDP interface allows >>you more connection blocks, because you can put the connection blocks in >>your application's memory space, rather than your kernel space (which is >>putting dumb restrictions on you). > >But suppose I want 1000's of processes to be able to communicate. Couldn't >the overhead of just having that many connections become to big if >only few of them communicate at the same time? Let me repeat my assertion, slightly differently. IF you want reliability, THEN you have no choice but to have connection blocks. If you have 1,000's of processes continuously talking, you will have 1,000s (or more) connection blocks. If they are not continuously talking, then you can just as easily deallocate TCP connection blocks as "reliable UDP" connection blocks. >Besides, for my particular application I use the select() system call, which >only operates on the lowest 32 file descriptors. This has suddenly become a UNIX discussion, but read the manual page again. Select uses arbitrary sized bitmasks, and takes a parameter telling it how large the bitmasks passed to it are. [32 is just the maximum size some systems support]. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102612570300> Received: from bells.cs.ucl.ac.uk by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 03:18:29 PDT Received: from tamdhu.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <5360-0@bells.cs.ucl.ac.uk>; Fri, 26 Oct 1990 11:17:05 +0100 To: tcp-ip@nic.ddn.mil Subject: Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols) In-reply-to: Your message of 23 Oct 90 13:59:48 +0000. <60282@bbn.BBN.COM> Date: Fri, 26 Oct 90 11:17:03 +0100 From: Jon Crowcroft >So if you could open a TCP connection to an IP multicast address, and >figure out how to handle the remote ends cleanly at the sender, you'd be >pretty far along. > (And 1 sending workstation gets, at worst, 100 >acks from 100 receivers -- less if receivers ack every 2nd segment). >I believe Van Jacobson and Jon Crowcroft looked at this problem in >more detail and may well have something more to add. Craig, we kind of figured out the small change necessary to TCP essentially, you send to multicast address, but receive acks from each member of the multicast groups individual clas a-c addresses you have a tcpcb per member, and run each connection state machine as normal, but link the tcpcb's so you know its a group communcation to start the whole shebang, you send a syn to group, you get syn acks back and gradually build up the set of tcpcb's (instead of just alocating one at start)...when you have the full group connection, you then allow the sender to do writes on the socket... each write may block if we are still flow controlled or not acked on any one connection... for a many to one (i.e. lotsa folks sending to us) you can overload the readv interface, and return a vector of single reads... it shouldnt take a bright person with BSD source more than a day to change, and a week to debug... the same thing could be done with broadcast, without the multicast IP, but is certainly a VERY BAD IDEA:-) jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102613303600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 16:14:45 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27224; Fri, 26 Oct 90 16:03: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: 26 Oct 90 13:30:36 GMT From: mcsun!inria!mirsa!jerry.inria.fr!huitema@uunet.uu.net (Christian Huitema) Organization: INRIA, Sophia-Antipolis (Fr) Subject: Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols) Message-Id: <8900@mirsa.inria.fr> References: <9010221418.AA03839@ftp.com>, , <1990Oct24.094329.5037@gec-rl-hrc.co.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil The subject of reliable broadcast protocols had been adressed in the early 80's in two different contexts, i.e. satellite networks and distributed systems. An interesting approach to the use of broadcast addresses for distributed systems (in fact, broadcast LANs) is that of Dr. Maxemchuck, which proposed a token passing "conference" protocol. Basically, the station which receives the token synchronize first with the previous stations, requesting a copy of all "missed" messages; options are to deliver this copy "point to point" or globally. The procedure uses a single packet counter, and maintains a global ordering of the messages -- which is indeed very useful for managing consistently a given systems. It sort of minimizes the ack flow, as acks are only transmitted during the token exchange; there is however a large overhead in semi silent systems, due to the rotations of the token. As far as satellite network are concerned, a quite exhaustive work was conducted at INRIA in the NADIR project between 1981 and 1985, for devolopping a performant and reliable "bulk broadcasting" protocol. In this protocol, the need for "1 ACK per station per packet" was alleviated by assuming a constant (unidirectional) message flow; the ACK are explicitly requested at well spaced "check points", e.g. at end of file. An option is to use unsollicited "NACKs" in order to request rapid resynchronisation of a particular recipient; another option to pass a list of "missing packets ids" upon a check point. These protocol variants have been described in several papers by the members of the project, e.g. J-L. Grange', I. Valet, J. Radureau or myself. The project is now terminated, and I am not aware of any continuation work. The use of either of these techniques in an internet (by constrast with a simple LAN or a controlled satellite channel) would pose at least two severe problems: * a group composition problems: in order to control the reception by "a group", one must be able to individually identify all the members of a group. What if this membership changes in the course of time? * a potentially severe flow control problem: when the routes to the members of the group have widely different capacities, how does one organize the slow down of the transmission to match the most constrained channel? Anyhow, this could be the basis of an interesting research work... Christian Huitema ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102615390900> Received: from hls.com (LANSLIDE.HLS.COM) by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 22:49:16 PDT Received: from nms. (nms.hls.com) by hls.com (4.0/SMI-4.0) id AA03042; Fri, 26 Oct 90 22:48:17 PDT Received: by nms. (4.0/SMI-4.0) id AA03233; Fri, 26 Oct 90 22:39:10 PDT From: salzman@nms.hls.com (Mike Salzman) Message-Id: <9010270539.AA03233@nms.> Subject: Re: Intelligent bridges vs. routers To: allan@cisco.com Date: Fri, 26 Oct 90 22:39:09 PDT Cc: tcp-ip@nic.ddn.mil In-Reply-To: <21892@hercules.csl.sri.com>; from "Allan Leinwand" at Oct 24, 90 11:47 pm Organization: Hughes Lan Systems, Mt View Ca X-Mailer: ELM [version 2.2 PL0] Allan Leinwand of cisco writes: > > I can think of a few downfalls other than broadcast storms: > > 1. an intelligent bridge will not separate your address space like a > router. Thus, your two subnets will exist on one logical LAN. This > may result in configuring routers to understand this situation. > Alan, it is disingenuous to argue the case of routers vs bridges on the basis of the damage that bridges inflict on the router. More importantly, routers impose an absolutely necessary management overhead on the installer/user of the router, while bridges can be plug and play (for the simple bridging functions). I have seen articles written by network managers of two major corporations ogling over their routers and all the wonderful ingenious schemes that they came up with to partition their subnets and address spaces so that they could use their routers. While they struggled to deal with organizational movements and the subsequent impact on address allocations, they could have simply moved the users in a bridged environment and be done with it. The burden of planning and administering a routered system is neglected by purveyors of routers to the detriment of innocent users who view routers as a better alternative to bridges. More about this issue later. > 2. a bridge will not allow you to control the network for security > reasons as well as a router if you are running multiple protocols (such > as IP and DECnet). With a bridge all of your security control is usually > based upon the MAC level address of a host. Keeping up with boards > swaps and changing MAC addresses can become a configuration nightmare. > With a router, the security can usually be setup to understand the > network protocol level addresses. This usually makes security > management a bit easier. > Here too, you are furthering half truths. Stopping at the network layer is not the magical solution. You imply that the MAC address is insufficient, yet you make the point that protocol independence is a necessary attribute of security. I agree with your assertion that the router can more finely control its activity. Today's bridges, however, offer filtering options which can effectively accomplish the same task, via protocol filtering and masking. Moreover, we find it quite usefule to specify the MAC address of those machines which we permit to access the net, regardless of the protocols they use. I can also argue that the next layer up would offer an even finer level of control, and stopping at the IP layer is not necessarily the optimal answer. Kerberos offers an even better answer. The conclusion is that routers offer a different, finer granularity, and more complex form of access control, which may be appropriate in certain cases. > 3. dare I say this? With many routers having SNMP agents, this > gives you a basis for network management. Yet, (contradicting myself > :-)) some bridges now answer SNMP. > In the 89 Interop, we demonstrated several bridges with SNMP management. This argument is clearly a red herring. > 4. the cost of a low end, two port router (which has router > functionality AND bridge functionality) may surprise you.... > Touche. Your recent announcement is indeed a triumph and an innovation. It still does not replace bridges. You do not need to denigrate bridges in order to gain a place for routers -- they are not head to head competitors. In competitive situations, vendors often pitch one against the other, based on the rule that you sell what you have, or what will win the bid. Nevertheless, routers have a role in backbone applications, in wide area applications, and in cases where the address management features are fruitfully applicable. Bridges have an equally important role in subnet traffic management, and providing connectivity behind the backbone, within a building, or within a facility. Bridges will remain easier and cheaper to operate simply because they operate at lower levels than routers. Similarly, repeaters operate at an even lower level, and are correspondingly easier to administer. > Thanks, > > Allan Leinwand > cisco Systems > leinwand@cisco.com > You're welcome. -- -------------------- 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---- [9010270002.AA00258@ucbvax.Berkeley.EDU] <1990102616015500> From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: re: question about SMTP MX records Message-ID: <9010270002.AA00258@ucbvax.Berkeley.EDU> Date: 26 Oct 90 16:01:55 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 10 Posted: Fri Oct 26 17:01:55 1990 > Ouch, Craig, I hope I didn't hear you say that every host X that is > an MX for another host Y is required to support the percent hack, > that is, treat user%Y@X equivalently to user@Y? RFC 1123 doesn't explicitly require it, but it suggests that support for the %-hack is expected (the discussion in Section 5.2.16 being my primary source). Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102616051300> Received: from hls.com (LANSLIDE.HLS.COM) by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 23:15:20 PDT Received: from nms. (nms.hls.com) by hls.com (4.0/SMI-4.0) id AA03081; Fri, 26 Oct 90 23:14:20 PDT Received: by nms. (4.0/SMI-4.0) id AA03263; Fri, 26 Oct 90 23:05:13 PDT From: salzman@nms.hls.com (Mike Salzman) Message-Id: <9010270605.AA03263@nms.> Subject: Re: SNMP monitors] To: cpw%snow-white@LANL.GOV (C. Philip Wood) Date: Fri, 26 Oct 90 23:05:13 PDT Cc: tcp-ip@nic.ddn.mil, peterf@lanslide.hls.com (Peter Filice), mark@elmer.hls.com (Mark Gang) In-Reply-To: <9010252029.AA11656@snow-white.lanl.gov>; from "C. Philip Wood" at Oct 25, 90 2:29 pm Organization: Hughes Lan Systems, Mt View Ca X-Mailer: ELM [version 2.2 PL0] Several messages have recently flamed SNMP, perhaps as a reaction to or byproduct of the Marshall and Karl debate society. The comments are incongruous since both ICMP and SNMP and other techniques have a role to play in the process of installing, monitoring, maintaining, testing and diagnosing a network. Although SNMP is a relatively recent development, and is a popular protocol targeted at network management applications, its developers never claimed that it should replace all other techniques and applications. It also does not address all network managment issues. The flavor of universal ompnipotence and the consequent exclusion of all other methods, techniques and applications is a byproduct of simplistic jounalistic reporting that afflicts our industry, and of marketing hype. SNMP is intended to manage operational networks. The fact that a router between manager X and device Y has failed does not preclude the manager station from using out-of-band (i.e. non ethernet) transmission channels to reach device Y. The lack of robustness is to a large extent an application design shortcoming, not an attribute of the protocol. The layering of the protocol in its most popular incarnation (over UDP) is also not an inherent aspect of the protocol, although it is highly recommended. Poor network design may have as much to do with preventing the operation of SNMP 'links' to managed devices, as does the depedence on IP. Clearly, however, it is necessary to use tools other than and in addition to SNMP to bring up the network. These include Ping. At a higher layer, it may be necessary to use PING-LIKE techniques to bounce data from EIA ports for example. Here again SNMP is not directly applicable. The conclusions are: 1. SNMP is a useful, interoperable protocol 2. It is not the sole and universal protocol 3. SNMP is not a replacement for well thought out, practical management applications -- it is an application tool 4. Poor design of network facilities and fallback routes is not an attribute of the protocol. -------------------- 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---- <1990102616480000> Received: from WSMR-SIMTEL20.ARMY.MIL by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 21:50:40 PDT Date: Fri, 26 Oct 1990 22:48 MDT Message-ID: From: "Frank J. Wancho" To: Jan.Engvald@LDC.LU.SE Cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL, TCP-IP@NIC.DDN.MIL Subject: LANtastic on the backbone In-reply-to: Msg of 25 Oct 1990 05:43-MDT from eru!hagbard!sunic!lth.se!tts.lth.se!xjeldc at bloom-beacon.mit.edu (Jan Engvald) Jan, Artisoft added support to use the Ethernet-2 compatible packets in "all recent versions" of their AILANBIOS by the use of the /XEROX option on the AILANBIOS command line. If you type AILANBIOS /HELP and XEROX shows up in the list of switches, your copy supports the option. --Frank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010270139.AA04758@ucbvax.Berkeley.EDU] <1990102616555900> From: Z.Wang@CS.UCL.AC.UK (Zheng Wang) Newsgroups: comp.protocols.tcp-ip Subject: Re: Reliable Datagram Protocols Message-ID: <9010270139.AA04758@ucbvax.Berkeley.EDU> Date: 26 Oct 90 16:55:59 GMT References: <45598@apple.Apple.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 3 Posted: Fri Oct 26 17:55:59 1990 The easiest way of getting a "reliable datagram" is to run IP over TCP :-) Zheng ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102617231600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 11:50:54 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13206; Fri, 26 Oct 90 11:43: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: 26 Oct 90 17:23:16 GMT From: lll-crg.llnl.gov@lll-winken.llnl.gov (Mark Boolootian) Organization: Lawrence Livermore National Laboratory Subject: How can you tell when too many ethernet collisions are occuring? Message-Id: <69374@lll-winken.LLNL.GOV> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does anyone have any information (or can you point me at some) regarding the number of expected ethernet collisions given some network utilization. I can well imagine one needs to consider (the distribution of) frame size and access patterns. I'm interested in knowing when the number of collisions occuring is excessive. Any info is appreciated. Thanks. mb booloo@lll-crg.llnl.gov ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102617594100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 11:23:44 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA11472; Fri, 26 Oct 90 11:13: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: 26 Oct 90 17:59:41 GMT From: usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!buit13!kwe@ucsd.edu (Kent England) Organization: Boston U. Information Technology Subject: Re: SNMP monitors Message-Id: <67189@bu.edu.bu.edu> References: <9010251553.AA02760@nisc.jvnc.net> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010251553.AA02760@nisc.jvnc.net> aggarwal@NISC.JVNC.NET (Vikas Aggarwal) writes: > >Another fact is that systems supporting SNMP do not consider snmp as a >high priority task- as a result I have routers that do not respond to >SNMP is they are busy passing traffic. As a consequence, during the >better parts of most afternoons, I would have sites change status to >"unknown" or "down" all the time because the routers would not respond >to SNMP. > SNMP should be given higher priority as ICMP usually is, but that does not guarantee that CPU utilization will be requested by the network management station. Perhaps you are lucky that your routers are telling you something you need to know that you otherwise would not ask. Even though you are unable to get your routers to respond to SNMP queries, this situation is indirectly giving you network management information that you could use. Go forth and upgrade your router CPUs and add memory or go get skinnier pipes for your overwrought routers. --Kent ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102619355900> Received: from bells.cs.ucl.ac.uk by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 09:57:19 PDT Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <18916-0@bells.cs.ucl.ac.uk>; Fri, 26 Oct 1990 17:56:00 +0100 To: tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram Protocols In-reply-to: Your message of 12 Oct 90 10:12:49 +0000. <45598@apple.Apple.COM> Date: Fri, 26 Oct 90 17:55:59 +0100 From: Zheng Wang The easiest way of getting a "reliable datagram" is to run IP over TCP :-) Zheng ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102621295600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 15:22:14 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24787; Fri, 26 Oct 90 15:16: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: 26 Oct 90 21:29:56 GMT From: amdahl!datta@apple.com (Diptish Datta) Organization: Amdahl Corporation, Sunnyvale CA Subject: Telnet echo negotiation question Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does any one out there know of two machines communicating with the telnet protocol and not using remote echo? If so, then the remote server should not be echoing characters typed in at the client and the local client should echo the keyboard entries to the screen - right? Well, I have a lana analyzer trace of a MVS machine logging in to a Unisys unix machine. The MVS machine seems to negotiate no remote echo but it looks to me like the remote machine echoes data any way. Here is what the echo option negotiation looks like: C <------ will echo S L dont echo ------> E I <------ wont echng the server not to echo E dont echo ------> V N wont echo ------> E T <------ dont echo R The way I read this is that the server offers to echo, the client refuses, and server agrees. Then the client says that he wont echo and server says no problem. Then I see the login prompt from the server and the user id data from the client. The server then echoes the user id right back! Basically the Unisys machine seems to have negotiated no remote echo but echoes anyway. Does any one out there have an explanation? Mail direct to me at datta@amdahl.uts.amdahl.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102622545500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 16:21:42 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27747; Fri, 26 Oct 90 16:14: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 Oct 90 22:54:55 GMT From: munnari.oz.au!uhccux!okumura@uunet.uu.net (Chad Okumura) Organization: University of Hawaii Subject: Thanks for the HHGs Message-Id: <10047@uhccux.uhcc.Hawaii.Edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi. This is chad...thanks for sending me all the stuff on the Hitchhiker's guide to Internet...you can all stop now...my mbox is overloaded already...THANKS SOOOO MUCH ! ! ! I appreciate you your prompt responses.... =============================================================================== --chad | "A cat will blink when struck University of Hawaii | with a hammer." Computing Center | =============================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102701370400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 26 Oct 90 19:55:36 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07947; Fri, 26 Oct 90 19:48: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 Oct 90 01:37:04 GMT From: portal!cup.portal.com!lan@apple.com (Los Altos Networks) Organization: The Portal System (TM) Subject: Re: Misposting Apology Message-Id: <35301@cup.portal.com> References: <35266@cup.portal.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We would like to acknowledge and apologize for our wreckless misuse of the network and, in particular, this newsgroup. Our lack of proper netiquette and knowledge of network guidelines has given us a hard lesson, but one that will also serve as a good lesson to us on the proper treatment of the network and its community of users. We have been properly repremanded by the network users, authority, and the Portal Communications supervisors, and will adhere to their guidelines, as well. Once again, we are sorry for this inconvenience. We thank you for your comments, suggestions, opinions, and patience in concerns to our trespass. Los Alto Networks ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102707120000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 27 Oct 90 02:06:57 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24101; Sat, 27 Oct 90 01:56: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: 27 Oct 90 07:12:00 GMT From: eru!hagbard!sunic!nuug!ifi!enag@bloom-beacon.mit.edu (Erik Naggum) Organization: Naggum Software, Oslo, Norway Subject: Batched SMTP (was Reliable Datagram ??? Protocols) Message-Id: References: <9010221418.AA03839@ftp.com>, <1990Oct24.090841@apollo.HP.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Phil Karn writes, in article <1990Oct25.165545@envy.bellcore.com>: >>> While we're on the subject of piggybacking, another thing I would >>> really like to see is widespread use of batched SMTP on the Internet. >>> I think the number of packets it takes for most SMTP implementations >>> to transfer a short mail message is criminal, especially when the >>> message has several recipients on the same system. There's no reason >>> that you shouldn't be able to send a series of SMTP commands in a >>> single TCP segment and receive a series of responses, except that many >>> SMTP servers inexplicably blow up when you try this. Given that TCP is >>> supposed to be a reliable byte stream protocol, the designers of these >>> systems must have gone well out of their way to keep this from working. If you do this, it isn't SMTP. RFC821, page 37: 4.3. SEQUENCING OF COMMANDS AND REPLIES The communication between the sender and receiver is intended to be an alternating dialogue, controlled by the sender. As such, the sender issues a command and the receiver responds with a reply. The sender must wait for this response before sending further commands. In recently standardized parlance, the session is two-way alternate (a.k.a. half-duplex) with implicit turn giving. I assume that you mean that batching should be done as follows: In the first segment, send HELO MAIL RCPT... wait for and check incoming 250 results, then DATA . QUIT in the next segment if all went well, otherwise send a QUIT, only. So we have this minimal packet exchange with a conforming SMTP server: SMTP Client SMTP Server SYN SYN+ACK + "220" ACK + "HELO/MAIL/RCPT..." ACK + "250" ACK "250" { ACK "250" } repeat ACK + "DATA/msg/./QUIT" ACK + "354" ACK "250" ACK FIN + "221" FIN+ACK ACK We could be really, really optimistic and assume that the server was aware of the status of the incoming queue, and make it like this: SMTP Client SMTP Server SYN SYN+ACK + "220" ACK + "HELO/MAIL/RCPT..." ACK + "250/250/250..." ACK + "DATA/msg/./QUIT" ACK + "354/250/221" ACK+FIN FIN+ACK ACK Alternatively, we could be really perverse and do this: SMTP Client SMTP Server SYN + "HELO/MAIL/RCPT..." SYN+ACK + "220/250/250/250..." ACK+FIN + "DATA/msg/./QUIT" ACK+FIN "354/250/221" ACK There are several immense problems in this scheme, and the very desire to minimize use of sequence number space like this. Unless we tell TCP not to send ACKs before we have written all we need to it and do a PUSH, replies will not be piggy-backed on ACKs, and those will be two segments instead of one. Unless the SMTP server knows that there is more input, it can't delay the PUSH until all input is processed, which will be separate segments with separate ACKs, unless the SMTP client knows that more is coming, and can tell TCP not to ACK until it writes more data and does a PUSH. Unless we redefine SMTP to allow commands before the 220 reply, we can't send HELO before we get it. Unless we redefine SMTP to allow commands to be sent before the reply to the previous command has been received, we can't group commands. Unless we disregard the wasted processing and the behavior when receiving an out-of-sequence RCPT by the server when the MAIL is rejected, we can't group MAIL and the first RCPT. Unless we're very brilliant with respect to the individual 25x and 55x replies to the RCPTs, we shouldn't group them. Unless we ignore all sorts of local problems at the server side, we can't group DATA and the message, and in particular, we can't group DATA, the message, AND the final dot. Unless we demand only one connection per message or ignore message delivery problems at a late stage, we shouldn't group the final dot and the QUIT. Unless the STMP server is able to recognize the QUIT properly, it can't set the FIN bit in the last data segment. Unless we have support for half-closing connections, the SMTP client can't group the FIN and the QUIT, again unless you redefine SMTP not to acknowledge the QUIT with a 221. I think I have pointed to several severe problems in control and status information propagation between TCP and the application, some problems in end-to-end application acks of operations, and that these, by themselves, make it very inappropriate to squeeze the living daylight out of SMTP. In result, I think that we will produce a lot of hair on the client side to take care of a server which thinks it's seeing and replying to individual commands, and that the gain in number of packets will be minimal, such as three, in the common case. --- Rather, if you want a fast, inexpensive mail transfer protocol, define one with two pieces of information transferred and acked: Envelope Message One pair per exchange, and the FIN bit used as the end-of-message indicator, if you can handle one-sided close operations gracefully. Most operating systems doesn't support this feature. (I.e. the last data segment has FIN set, but it still awaits a data segment with the other side's FIN segment.) It could go like this: FMDP client FMDP server SYN + Envelope SYN+ACK + Envelope OK ACK+FIN + Message ACK+FIN + Message OK ACK FMDP stands for "Futuristic Message Delivery Protocol". Most probably, you will get something on the order of: FMDP client FMDP server SYN SYN+ACK ACK Envelope ACK Envelope OK ACK Message ACK FIN ACK Message OK ACK FIN ACK If you know the size of the message, you can send that information in the envelope and relieve yourself of the one-sided close problem. I believe this scheme has been used in a different set of protocols, which has its own set of fans, not necessarily on this list/group. --- I like SMTP the way it is. That doesn't mean I dislike improvements, just don't call them SMTP, and don't expect my SMTP client or server to accept your bogus idea of what the underlying transport protocol provides and I therefore have to accept at a higher layer. Just because ARM (Arpanet Reference Model) doesn't have a session layer, doesn't mean it isn't implicit in some of the protocols. ARM just doesn't think it's worth a whole layer. That's why. Try pulling the plug at the Session layer to the mighty Priests of the Holy Seven, and they'll react with even more rationale for it's existence than I have provided above. -- [Erik Naggum] Naggum Software; Gaustadalleen 21; 0371 OSLO; NORWAY I disclaim, , therefore I post. +47-295-8622, +47-256-7822, (fax) +47-260-4427 -- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102708043200> Received: from EXXON-VALDEZ.FT.CS.CMU.EDU by NIC.DDN.MIL with TCP; Sat, 27 Oct 90 09:05:00 PDT From: Christopher Maeda Date: Sat, 27 Oct 90 12:04:32 EDT To: lll-crg.llnl.gov@lll-winken.llnl.gov CC: tcp-ip@nic.ddn.mil In-reply-to: Mark Boolootian's message of 26 Oct 90 17:23:16 GMT <69374@lll-winken.LLNL.GOV> Subject: How can you tell when too many ethernet collisions are occuring? Reply-to: cmaeda@CS.CMU.EDU Roy Maxion did a paper on this in the last Fault Tolerant Computing Conference (FTCS-20). Basically, he keeps a vector of expected values for collisions (also load, packet counts, etc) for each monitoring epoch (currently 1 minute). Newly observed data is compared with the expected values and alarms are triggered if the values are not consistent with expectations. Note that the meaning of "consistent with expectations" is a topic of current research. One heuristic is if the number of collisions is 3 stds above the mean. The models are also updated to take new observations into account using a kind of exponential regression Chris ps: Maxion, Roy A., Anomaly Detection for Diagnosis. In 20th International Symposium on Fault-Tolerant Computing (FTCS20), (1990) 20-27. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102715100100> Received: from ico.isc.com by NIC.DDN.MIL with TCP; Sat, 27 Oct 90 20:09:57 PDT Received: from violet.ico.isc.com by ico.isc.com (5.61/1.35) id AA01461; Sat, 27 Oct 90 21:10:04 -0600 Date: Sat, 27 Oct 90 21:10:01 MDT Message-Id: <9010280310.AA26849@violet.ICO.ISC.COM> To: jhereg!imp Cc: tcp-ip@nic.ddn.mil From: "Doug McCallum" Subject: Re: DECnet & IPX In reply to your message of 25 Oct 90 01:14:41 GMT ------- > This is correct, but does not guarantee coexistence. Remember that all VAX > Ethernet controllers are Version 2 devices, NOT 802.3 devices. Netware, on > the other hand, DEFAULTS to 802.3 operation. While you can certainly run > both protocols simultaneously on the same cable, if you want to gateway the > two environments, you have to backpatch the IPX card drivers with a utility > called 'econfig.' Basically, econfig allows you to select whether you want > your Novell net to run using Ethernet Version 2 (type field IPX=8037) or > 802.3 (length field). Actually, what Novell calls 802.3 is not quite what the rest of the world thinks of as 802.3. Novell is 802.3 at the MAC level and used the 802.3 length field. They do not then use an 802.2 LLC layer as the rest of the world does and thus frequently cannot coexist on a true 802.3 based LAN. In any mixed environment, it would probably be best to econfig all the Netware systems anyway since there are systems that have problems dealing with the Novell broadcast packets that also appear to have both LSAP values (destination and source) being the broadcast SAP. Its too bad Novell chose to implement something that almost follows the IEEE standards rather than doing the nearly trivial additional work to do it "right". Doug McCallum dougm@ico.isc.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010271814.AA17575@ucbvax.Berkeley.EDU] <1990102716043200> From: cmaeda@EXXON-VALDEZ.FT.CS.CMU.EDU (Christopher Maeda) Newsgroups: comp.protocols.tcp-ip Subject: How can you tell when too many ethernet collisions are occuring? Message-ID: <9010271814.AA17575@ucbvax.Berkeley.EDU> Date: 27 Oct 90 16:04:32 GMT References: <69374@lll-winken.LLNL.GOV> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: cmaeda@CS.CMU.EDU Organization: The Internet Lines: 18 Posted: Sat Oct 27 17:04:32 1990 Roy Maxion did a paper on this in the last Fault Tolerant Computing Conference (FTCS-20). Basically, he keeps a vector of expected values for collisions (also load, packet counts, etc) for each monitoring epoch (currently 1 minute). Newly observed data is compared with the expected values and alarms are triggered if the values are not consistent with expectations. Note that the meaning of "consistent with expectations" is a topic of current research. One heuristic is if the number of collisions is 3 stds above the mean. The models are also updated to take new observations into account using a kind of exponential regression Chris ps: Maxion, Roy A., Anomaly Detection for Diagnosis. In 20th International Symposium on Fault-Tolerant Computing (FTCS20), (1990) 20-27. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102720024700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 27 Oct 90 13:22:45 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22053; Sat, 27 Oct 90 13:23: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: 27 Oct 90 20:02:47 GMT From: sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU (Vernon Schryver) Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: How can you tell when too many ethernet collisions are occuring? Message-Id: <73460@sgi.sgi.com> References: <69374@lll-winken.LLNL.GOV>, <9010271814.AA17575@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010271814.AA17575@ucbvax.Berkeley.EDU>, cmaeda@EXXON-VALDEZ.FT.CS.CMU.EDU (Christopher Maeda) writes: > Roy Maxion did a paper on this in the last Fault Tolerant Computing > Conference (FTCS-20). Basically, he keeps a vector of expected values > for collisions (also load, packet counts, etc) ... This work is interesting for detecting anomalies like suddenly broken hardware, but how do you know if your net is "normally" overloaded? If you have 90% collisions every day between 10 am and 4 pm, the envelope/standard deviation calculation will tell you that everything is just peachy. We've been using a rule of thumb that says if more than 30% of an active station's packets collide, it is time to split the network. That is, does it make sense to say things are bad if the quotient of the "Opkts" and "Coll" columns of netstat are >= .3, provided Opkts>100,000? Ethernets that met this criterion here have been painfully slow. (Yes, rather BSD-network-UNIX oriented. Sorry.) Vernon Schryver, vjs@sgi.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102809224700> Received: from po5.andrew.cmu.edu by NIC.DDN.MIL with TCP; Sun, 28 Oct 90 14:44:55 PST Received: by po5.andrew.cmu.edu (5.54/3.15) id for tcp-ip@nic.ddn.mil; Sun, 28 Oct 90 17:45:04 EST Received: via switchmail; Sun, 28 Oct 90 17:44:59 -0500 (EST) Received: from valkyries.andrew.cmu.edu via qmail ID ; Sun, 28 Oct 90 17:42:53 -0500 (EST) Received: from valkyries.andrew.cmu.edu via qmail ID ; Sun, 28 Oct 90 17:42:50 -0500 (EST) Received: from Messages.7.8.N.CUILIB.3.45.SNAP.NOT.LINKED.valkyries.andrew.cmu.edu.pmax.3 via MS.5.6.valkyries.andrew.cmu.edu.pmax_3; Sun, 28 Oct 90 17:42:47 -0500 (EST) Message-Id: Date: Sun, 28 Oct 90 17:42:47 -0500 (EST) From: Drew Daniel Perkins To: tcp-ip@nic.ddn.mil Subject: ISDN RRs/RFC 1183 opinions sought References: I'm curious about people's opinions on the ISDN provisions of RFC 1183, "New DNS RR Definitions", C. Everhart, L. Mamakos, R. Ullmann, P. Mockapetris. Do people think these RRs are useful? Are they likely to be used? How were they intended to be used? How would these integrate routing protocols? The description in RFC 1183 seems a bit confusing to me. In particular, domains like "Relay.Prime.COM" are used, rather than domains like IN-ADDR.ARPA. I imagine the intended purpose of the ISDN RR is to be able to automatically establishe connections over an ISDN link upon receipt of the first IP packet. I would think that you would want to do lookups by IP address, although I can imagine looking for a PTR record first and then looking for a corresponding ISDN record. I also find it confusing exactly how the RT record is intended to work. Here's one scenario that I think these might be useful in. Imagine two isolated island networks NA and NB, such as might exist in two companies or universities. Each island network has a one or more routers, maybe RC and RD, with ISDN connections which can establish links to other networks. Now let's say I try to telnet from one non-ISDN machine HE on network NA to a non-ISDN machine HR on network NB. One way I could imagine things working is that router RC might advertise a default route to hosts on its network including HE. So, when I telnet, HE would send its packets to RC. Now, when RC received the packet addressed to HF, it might look up RRs for HF and it might find an RT RR for RD. Looking up RD it might find an ISDN RR with RD's number. It could then forward the packet through to RD, which would then forward it to HF. HF's response would hopefully be sent back through RD (due to having corrrect updated routing information) which would then realize that it already has a connection open to RC, and would simply send it through. When we start scaling this simple example up, I see a lot of problems start popping up. Imagine I just have a single host (at home maybe) with an ISDN connection. Now, I want to telnet to a host which is somewhere on the Internet, behind maybe dozens of router hops. It's hard to imagine that every host on the internet will have an RT RR in the DNS. If I were a random site with hosts on the Internet, but no ISDN connections, what RT RR would I want to advertise? There might be thousands of other hosts/routers on the Internet with ISDN connections. Which would I choose, and how? Drew ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102811351700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 28 Oct 90 09:53:45 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA11436; Sun, 28 Oct 90 09:49:17 -0800 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 Oct 90 11:35:17 GMT From: eru!hagbard!sunic!mcsun!ukc!slxsys!dircon!sys0001@BLOOM-BEACON.MIT.EDU (Ben Knox) Organization: The Direct Connection, UK Subject: TCP/IP on SCO Message-Id: <1990Oct28.113517.19385@dircon.uucp> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have some questions about TCP/IP on SCO UNIX: 1. If I have two PCs running UNIX, will I need to buy two separate copies of SCO's TCP/IP package -- one for each system? (or can I buy one copy but two serial numbers/activation keys). 2. If I want to later upgrade to NFS, will I need two separate copies of that as well? 3. Which Ethernet cards are supported. Which is the most reliable, best supported etc (and least likely to conflict with other hardware -- especially Adaptec 1542B disk controller and VEGA 8-bit VGA card)? 4. Is it possible to use (cheaper) unbranded Ethernet cards? 5. What is the difference between thicknet and thin-net? What is 10BASET? 6. Can I perform backup to tape across the network under TCP/IP (using tar, ctar or...?)? 7. Is it possible to use one of the PD TCP/IP packages on a DOS PC to perform TCP logins and file transfers with SCO's package? If so, which is best for this purpose? 8. What are 'packet drivers' and TCP/IP boot PROMS ...do I need them? 9. Are there any other things I should consider before buying and installing the network? 10. Can anyone recommend any good books or papers which cover the practical aspects of TCP/IP Lans, bridging between lans, ethernet etc? My configuration is: SCO UNIX 3.2.2 on two 16MHz 386s (these may be upgraded to faster systems at a later date). Please reply by email. Thank you! -- sys0001@dircon.UUCP or sys0001%dircon@ukc.ac.uk ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102811385800> Received: from decpa.pa.dec.com by NIC.DDN.MIL with TCP; Sun, 28 Oct 90 19:38:50 PST Received: by decpa.pa.dec.com; id AA14240; Sun, 28 Oct 90 19:38:55 -0800 Message-Id: <9010290338.AA14240@decpa.pa.dec.com> Received: from ecdnt5.enet; by decwrl.enet; Sun, 28 Oct 90 19:38:58 PST Date: Sun, 28 Oct 90 19:38:58 PST From: christopher raczka To: tcp-ip@nic.ddn.mil Subject: RE: Internet/NSFNet proposal to be run by IBM -- call to action! Cc: DECWRL::"chris@ecdnt5.enet.dec.com", chris I think many people share Karl Denninger's feelings and Karl you are right people will have to speak up an be heard I also think the "other side" of the story does need to be told and this much I do know... Sometime in September, Merit, IBM Corp, and MCI established Advanced Network and Services Inc. (ANS) ANS, a NOT FOR PROFIT organization, is to manage and operate the NSFNET backbone under subcontract to Merit Allan Weis was named President and CEO IBM and MCI are funding ANS, and Merit is providing Network Operations, Network engineering, network planning and network services. I'm not sure if Eric Aupperle (Merit President) reads this newsgroup but it would be interesting to hear Merit's feelings on this, both as a compnay and some personal feelings Anyone from Merit care to offer any insight? regards, christopher raczka DIGITAL Equipment e-mail: chris@ecdnt5.enet.dec.com phone: 313-347-5108 ============================================================================= My opinions DO NOT reflect those of DIGITAL Equipment Corporation and sometimes vice versa ============================================================================= ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102817025400> Received: from WLV.IMSD.CONTEL.COM by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 06:23:03 PST Received: by WLV.IMSD.CONTEL.COM (5.64/1.25) id AA01169; Mon, 29 Oct 90 06:22:54 -0800 Date: Mon, 29 Oct 90 06:22:54 -0800 From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) Message-Id: <9010291422.AA01169@WLV.IMSD.CONTEL.COM> To: ddsw1!karl@gargoyle.uchicago.edu, tcp-ip@nic.ddn.mil Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! >This is a call to action by all interested parties. >There is wind of a proposal stirring in Washington that would place the >NSFNet backbone, and eventually the entire government-run part of the >Internet, into the hands of IBM. >IBM has supposedly pledged to run this on a non-profit basis for some >number of years. Of course, the number that's being bandied about is >small, like "2"..... This is, more or less, standard for Government service contracts. Two years on the basic contract with 1 to 3 optional extensions of 1 year each. >Anyone want to bet how long the Internet remains accessible to non-IBM >people? Or whether the Internet ends up another Prodidy, with active >censorship? Whether you'll have to buy an IBM system to hook into it, >since they might decide that TCP/IP is no longer any good and now it's >time to go to SNA or worse? I guess we could have Digital with DECnet, ALL-IN-FUN, or OSI; Apple with AppleTalk; Novell with NETWARE; usw. >Folks, if you love the Internet, and want to see it expand and grow, we need >to insure that a few things happen: >1) The "acceptable use" policy on the NSFNet needs to be scrapped. > Sure, this will bring problems. But it will also mean that > commercial companies can tie in, pay their fair share, and make sure > that the network capacity has the funding to continue to grow. >2) The backbone needs to be run as a regulated commodity. Perhaps even > run by the Government, strange as that may seem. The goal of > universal connectivity is not that far off right now, but there are > companies and special interests who would like to see that never > happen. We MUST insure that it does. It is run by the Government! How does the Government provide technical sup- port and services? Does it hire people to do it? No. It issues contracts to profit or non-profit companies and consortiums. >3) We must maintain and increase our lead as the information-processing > leader in the world. It's the only area of superiority that we have > left in world markets. A universally-accessible Internet is one way > to achieve this goal. Face it, the "bright minds" aren't all in > colleges or doing business with schools or the government. Many are > in private industry or independant, and they should have access to > this resource as well. I believe we might be superior in farming. I suspect we may be ahead in networking only because of the absence of Harvard Business School graduates and their short term management philosophies. >4) Finally, a freely accessible information exchange medium may be the > second-best guarantee of freedom in this country (the first being > the ability of the people to depose a despotic government). By > keeping the passing of information from coast to coast available, > fast and cheap, we keep the people informed. >How to proceed: > 1) A tax on access devices for the network may be the best > way to fund it. I'm not sure about this, but it seems as > though a "user fee" is one of the better ways to pay for the > connectivity that we all enjoy and want to see furthered. The AT&T solution. Assign a $2.00 monthly access fee on every modem regardless of usage. A wonderful solution! > 2) General subsidy isn't a bad idea either, but it's not ideal. > Selling it to the general public will be difficult, > especially with the things that hit the press now and again > about X-rated GIF sites and the like. > 3) Keep control in the hands of the many, or in the hands of a > non-profit corporation funded EXCLUSIVELY to run this beast. > Giving it to IBM or another pseudo-government company is as > good as letting the fox loose in the henhouse -- the > potential for abuse and profiteering is just too great to > ignore. And now back to the MCI and IBM consortium who've proposed a non-profit corp- oration funded EXCLUSIVELY to run this beast. I wonder what a "pseudo-govern- ment" company is? Large? Merton ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102817535000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 13:10:20 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12327; Mon, 29 Oct 90 13:03:02 -0800 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 Oct 90 17:53:50 GMT From: mcsun!inria!ircam!mf@uunet.uu.net (Michel Fingerhut) Organization: IRCAM, Paris (France) Subject: Re: French experience needed Message-Id: <1990Oct28.175350.7766@ircam.ircam.fr> References: <9010231842.AA23604@ftp.com>, <2190003@otter.hpl.hp.com>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Since I was the one to use this expression in a disgruntled article about routing, let me confirm Erik Naggum's reply: "a fat lot of good it does to me!". Now back to tcp-ip (which is not about "talking colloquial Parisian in public") business. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102819091700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 28 Oct 90 17:24:14 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19032; Sun, 28 Oct 90 17:24:12 -0800 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 Oct 90 19:09:17 GMT From: zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!smurf!urlichs@tut.cis.ohio-state.edu (Matthias Urlichs) Organization: University of Karlsruhe, FRG Subject: Batching vs lock-step Message-Id: References: <9010221418.AA03839@ftp.com>, <1990Oct24.090841@apollo.HP.COM>, <1990Oct25.165545@envy.bellcore.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In comp.protocols.tcp-ip, article <1990Oct25.165545@envy.bellcore.com>, karn@thumper.bellcore.com writes: < < While we're on the subject of piggybacking, another thing I would < really like to see is widespread use of batched SMTP on the Internet. < I think the number of packets it takes for most SMTP implementations < to transfer a short mail message is criminal, especially when the < message has several recipients on the same system. There's no reason < that you shouldn't be able to send a series of SMTP commands in a < single TCP segment and receive a series of responses, except that many < SMTP servers inexplicably blow up when you try this. Given that TCP is < supposed to be a reliable byte stream protocol, the designers of these < systems must have gone well out of their way to keep this from working. < The problem is that on top of TCP there's the C stdio library which tends to buffer your data when a program does an fgets(). After reading the first request, said program is likely to say "wait on the _connection_ for ten minutes until data become available". No programmer bothers to examine the stdio buffer first becase - the protocol is supposed to be lock-step anyway, - examining a stdio buffer on whether it contains data is not standardized, - the alternative is to use alarm() and signal(), but longjmp()ing from a signal handler back into a program, bypassing the stdio library on the way out, may not be what the system designers had in mind. A side effect of this is that sending a single character to such an implementation, and leaving the TCP stream open, will hang it indefinitely. ;-) -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102822043200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 28 Oct 90 15:33:32 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16927; Sun, 28 Oct 90 15:24:04 -0800 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 Oct 90 22:04:32 GMT From: ddsw1!karl@gargoyle.uchicago.edu (Karl Denninger) Organization: Macro Computer Solutions, Inc. - Wheeling, IL Subject: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: <1990Oct28.220432.521@ddsw1.MCS.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil This is a call to action by all interested parties. There is wind of a proposal stirring in Washington that would place the NSFNet backbone, and eventually the entire government-run part of the Internet, into the hands of IBM. IBM has supposedly pledged to run this on a non-profit basis for some number of years. Of course, the number that's being bandied about is small, like "2"..... Anyone want to bet how long the Internet remains accessible to non-IBM people? Or whether the Internet ends up another Prodidy, with active censorship? Whether you'll have to buy an IBM system to hook into it, since they might decide that TCP/IP is no longer any good and now it's time to go to SNA or worse? Folks, if you love the Internet, and want to see it expand and grow, we need to insure that a few things happen: 1) The "acceptable use" policy on the NSFNet needs to be scrapped. Sure, this will bring problems. But it will also mean that commercial companies can tie in, pay their fair share, and make sure that the network capacity has the funding to continue to grow. 2) The backbone needs to be run as a regulated commodity. Perhaps even run by the Government, strange as that may seem. The goal of universal connectivity is not that far off right now, but there are companies and special interests who would like to see that never happen. We MUST insure that it does. 3) We must maintain and increase our lead as the information-processing leader in the world. It's the only area of superiority that we have left in world markets. A universally-accessible Internet is one way to achieve this goal. Face it, the "bright minds" aren't all in colleges or doing business with schools or the government. Many are in private industry or independant, and they should have access to this resource as well. 4) Finally, a freely accessible information exchange medium may be the second-best guarantee of freedom in this country (the first being the ability of the people to depose a despotic government). By keeping the passing of information from coast to coast available, fast and cheap, we keep the people informed. How to proceed: 1) A tax on access devices for the network may be the best way to fund it. I'm not sure about this, but it seems as though a "user fee" is one of the better ways to pay for the connectivity that we all enjoy and want to see furthered. 2) General subsidy isn't a bad idea either, but it's not ideal. Selling it to the general public will be difficult, especially with the things that hit the press now and again about X-rated GIF sites and the like. 3) Keep control in the hands of the many, or in the hands of a non-profit corporation funded EXCLUSIVELY to run this beast. Giving it to IBM or another pseudo-government company is as good as letting the fox loose in the henhouse -- the potential for abuse and profiteering is just too great to ignore. Get involved NOW folks. I didn't know about this until last night, and it knocked my socks off. People I've talked to think this is a universally bad thing, but they don't know how to stop it. I suggest that a million loud voices would have a significant impact. -- Karl Denninger (karl@ddsw1.MCS.COM, !ddsw1!karl) Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102822431900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 28 Oct 90 15:39:00 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17084; Sun, 28 Oct 90 15:33:44 -0800 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 Oct 90 22:43:19 GMT From: stan!marvin!imp@boulder.colorado.edu (Warner Losh) Organization: Solbourne Computers Inc. Subject: Re: question about SMTP MX records Message-Id: <1990Oct28.224319.21554@Solbourne.COM> References: <9010270002.AA00258@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010270002.AA00258@ucbvax.Berkeley.EDU> craig@NNSC.NSF.NET (Craig Partridge) writes: >RFC 1123 doesn't explicitly require it, but it suggests that support >for the %-hack is expected (the discussion in Section 5.2.16 being >my primary source). However, in existing practice there is at least one mailer that uses the % for a gateway between internet and decnet. The address of the form "imp%node.decnet@twg.com" will cause mail to be sent to NODE::IMP from the internet host TWG.COM. This being the case, mail sending programs should not assume that is the same as "<@c:a@b>". Warner -- Warner Losh imp@Solbourne.COM How does someone declare moral bankruptcy? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102822583700> Received: from mail.unet.umn.edu by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 07:01:13 PST Received: from norge.unet.umn.edu by mail.unet.umn.edu (5.61/1.14) id AA25105; Mon, 29 Oct 90 08:58:07 -0600 Date: Mon, 29 Oct 90 08:58:37 -0600 From: "Craig A. Finseth" Message-Id: <9010291458.AA19884@unet.unet.umn.edu> Received: by unet.unet.umn.edu; Mon, 29 Oct 90 08:58:37 -0600 To: Gene.Saunders@West.Sun.COM Cc: snmp@nisc.nyser.net, tcp-ip@NIC.DDN.MIL In-Reply-To: Gene Saunders - Regional SE's message of Fri, 26 Oct 1990 21:59:25 PDT <9010270459.AA04401@sunkist.West.Sun.Com> Subject: SNMP monitors, clarification Recently, Mr. Donald W. Garner (CADIG STAFF) asked: > >For example, the network monitoring here at the U uses ICMP Echo ... > Is that monitoring done by SunNet Manager? Has anyone had any experience > with this package? and I responded with: > Is that monitoring done by SunNet Manager? Has anyone had any experience > with this package? >No, it is a package that I wrote. I wanted one that worked, not one >that was pretty. I don't know anything about SunNet. Apparently my reply was worded so as to be ambiguous. Unfortunately, one of the interpretations (not the intended one) caused offense to people at Sun Microsystems. I apologize for the unintended offense. The first part of my statement "I wanted one that worked, not one that was pretty" referred to the package that I wrote, the second part referred to the "SNMP graphics tools packages" that were mentioned to in the original posting by Stev Knowles on 24 October. The statement that I am not familiar with SunNet Manager is true. Since I am not familiar with it, I do not know what category it falls into (other than proprietary software, which makes it uninteresting to us (:-)). Hence, I did not forsee the ambiguity. Craig A. Finseth fin@unet.umn.edu [CAF13] University Networking Services +1 612 624 3375 desk University of Minnesota +1 612 625 0006 problems 130 Lind Hall, 207 Church St SE +1 612 626 1002 FAX Minneapolis MN 55455-0134, U.S.A. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102901222400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 28 Oct 90 17:54:10 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19400; Sun, 28 Oct 90 17:45:59 -0800 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 Oct 90 01:22:24 GMT From: zaphod.mps.ohio-state.edu!mips!dimacs.rutgers.edu!aramis.rutgers.edu!athos.rutgers.edu!hedrick@tut.cis.ohio-state.edu (Charles Hedrick) Organization: Rutgers Univ., New Brunswick, N.J. Subject: Re: Reliable Datagram ??? Protocols Message-Id: References: <9010231728.AA03948@braden.isi.edu>, <12632159446.18.BILLW@mathom.cisco.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Since TCP handles all errors, flow control, etc., about all your trivial framing protocol needs to be is a byte count followed by the data. As long as your TCP implementation pushes every write (which is typical of those that I know), this is about all you need. In order to catch coding errors, it's probably a good idea to include some way of catching missynchronization, like some tacking on a -1 word at the end of each message. The esthetics of this do not bother me. Converting messages to streams and back will be a no-op in the simple case, and useful in other cases. That is, if you do single query and response, TCP will simply send off your packets one by one, handling only the sorts of issues you'd really rather not have to handle for yourself, such as retransmission. If you send more than one datagram in a given direction (e.g. you respond to a query with lots of data), then combining datagrams, sequencing, etc., are useful. If TCP were really a high-overhead thing, I'd worry about this, but lots of smart people are putting lots of time into optimizing TCP. They have almost certainly done a better job than you will do. The main places I recommend avoiding TCP are when queries are being sent to varying destinations, e.g. named, or when you need to use broadcasts. And frankly I sometimes think it would have been better to have done named only over TCP. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102901335400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 28 Oct 90 21:24:25 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23479; Sun, 28 Oct 90 21:14:30 -0800 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 Oct 90 01:33:54 GMT From: sdd.hp.com!mips!prls!pyramid!csg@ucsd.edu (Carl S. Gutekunst) Organization: Pyramid Technology Corp., Mountain View, CA Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: <132136@pyramid.pyramid.com> References: <1990Oct28.220432.521@ddsw1.MCS.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Karl, there is a *much* simpler solution. Scrap NSFNet. We don't need it. T1 and 64K DDS lines are ***cheap*** these days, so cheap that UUNet can build a truly commercial TCP/IP service, give excellent service, and charge less than $2000/month for it. NSFNet is the government's network. Let them have it for anyone who wants to live under the government's terms and conditions. Just as the Europeans are throwing off the yokes of their PTTs, it's time for us to throw off the yoke of state-sponsored communications networks, and start building our own. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102902555700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 06:24:55 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02671; Mon, 29 Oct 90 06:20:50 -0800 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 Oct 90 02:55:57 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!ub!acsu.buffalo.edu@ucsd.edu (Paul Graham) Organization: University at Buffalo Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: <43054@eerie.acsu.Buffalo.EDU> References: <1990Oct28.220432.521@ddsw1.MCS.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil karl@mcs.MCS.COM (Karl Denninger) writes: |There is wind of a proposal stirring in Washington that would place the |NSFNet backbone, and eventually the entire government-run part of the |Internet, into the hands of IBM. people who are *really* concerned about this should first subscribe to, and get the archives of, the commercialization/privitization mailing list (com-priv-requests@psi.com). this plan is generally well known in the networking community and while there is no clear consensus i don't think the degree of alarm displayed by the previous posting is necessary. in any event com-priv is an excellent place to move this discussion since many of the movers and shakers are active there. -- pjg@acsu.buffalo.edu / rutgers!ub!pjg / pjg@ubvms (Bitnet) opinions found above are mine unless marked otherwise. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102906040800> Received: from VAX.BBN.COM by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 08:13:15 PST Date: Mon, 29 Oct 90 11:04:08 EST From: Charles Lynn To: Phil Karn cc: tcp-ip@nic.ddn.mil Subject: Re: Reliable Datagram ??? Protocols Doesn't TCP require the connection to be in the ESTABLISHED state before it is permitted to deliver data to the application? If so, I think B cannot see the data until it gets the ACK of its SYN from A, thus the response from B cannot be includes with B's SYN ACK. Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102907202900> Received: from devvax.TN.CORNELL.EDU by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 12:40:20 PST Received: from CHUMLEY.TN.CORNELL.EDU by devvax.TN.CORNELL.EDU (5.64/1.3-Cornell-Theory-Center) id AA05406; Mon, 29 Oct 90 15:40:17 -0500 Received: from CHUMLEY.TN.CORNELL.EDU by chumley.TN.Cornell.EDU (5.64/2.0) with SMTP id AA13349; Mon, 29 Oct 90 15:40:30 -0500 Message-Id: <9010292040.AA13349@chumley.TN.Cornell.EDU> To: sblair@synoptics.com (Steven Blair) Cc: tcp-ip@nic.ddn.mil Subject: Re: *looking for implementations of RFC-1112* In-Reply-To: Steven Blair's message of 22 Oct 90 20:40:07 +0000. <9010222332.AA23240@risci.TN.CORNELL.EDU> Date: Mon, 29 Oct 90 15:40:29 -0500 From: Scott Brim We (Cornell, gated) and Proteon are both working on implementing routing multicast packets in OSPF; Steve Deering's involved too. After we get that nailed down Cornell plans on building multicast support into either BGP or IDPR. although I expect the inter-administration protocols to be significantly more difficult. The algorithms are more or less worked out for doing all of this, but it'll be a while. Scott I have several users who've recently become aware of RFC1112 written by S.Deering of Stanford(1989) on Host Extensions on IP Multicasting. We're reviewing the paper for possible interest. Questions are: 1) Has any router/bridge company done this? If not, are any working on it. 2) Are there any networks supporting this at this time? Or in the future? 3) Any more interesting comments you can add to this. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102907484300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 00:54:33 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27937; Mon, 29 Oct 90 00:47:30 -0800 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 Oct 90 07:48:43 GMT From: cs.utexas.edu!wuarchive!emory!rsiatl!jgd@tut.cis.ohio-state.edu (John G. DeArmond) Organization: Radiation Systems, Inc. (a thinktank, motorcycle, car and gun works facility) Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: <4532@rsiatl.UUCP> References: <1990Oct28.220432.521@ddsw1.MCS.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil karl@ddsw1.MCS.COM (Karl Denninger) writes: >This is a call to action by all interested parties. >There is wind of a proposal stirring in Washington that would place the >NSFNet backbone, and eventually the entire government-run part of the >Internet, into the hands of IBM. This is part of the disgusting Senator from my home state, Albert Gore, Sr as part of his supernet that will cure all the nation's technology ills, make is a world competator and brush our teeth, all in one fell swoop. He is being "assisted" by that "gentleman" we've all come to know and loathe, (bob?) Abernathy of the Houston Chronicle. Remember the Great Internet Smut Controversy of 1990. Yep, same guy. He posted to a mailing list the articles he wrote for the paper on the subject. I didn't keep an archive copy but here's what I remember: IBM and >>> Compuserv <<< have steped forward and volunteered to sink about 10 million into the management effort. They are proposing to institute a "user fee" schedule based on the quantity of data transmitted. BUT they still propose to keep the network "closed" and only available to those who have a "need" to be on there. In other words, enjoy the Internet while it lasts because will soon become a mutant offspring of an incestuous inbreeding of IBM, Compuserv, and the government. Can you imagine an ftp session that is billed by the hour and by the bytes transfered all the while, advertisements scroll across the screen? No smileys. As is typical of Gore, he proposed to dump buckets of money into the project and create a backbone of gigabit-per-second links that no one but the government could afford to interface to. He calls upon those old worn phrases of motherhood, apple pie, and another Apollo-like mission to the moon of networks. The articles that Abernathy writes glow so from yellow journalism that I feel that I need my cobalt glasses just to read them. Even as he promotes this grandois scheme, he executes a perfect self-pat-on-the back by noting that a "controversy" has grown out of the exclusive investigative article by the Chronicle. Then he uses the previous dose of yellow to justify a "remedy". And we know how the Democrats "remedy" a problem. At least our wallets do. Perhaps someone else on the list will post a couple of Abernathy's articles. What to do? As usual, make noise. Lobby for incremental funding to handle the growth of the internet, incremental funding for higher speed technologies and the creation of a mechanism for commercial users with research as opposed to business need to get on the net. Lobby for the congress to do that but otherwise leave what works alone. And hey, if anyone out there has enough money to buy a congresslime, then please do so. (and just in case Abernathy wants to quote me out of context.) This article is copyright 1990 John De Armond. All rights reserved. No journalistic use whatsoever permitted. John -- John De Armond, WD4OQC | "The truly ignorant in our society are those people Radiation Systems, Inc. | who would throw away the parts of the Constitution Atlanta, Ga | they find inconvenient." -me Defend the 2nd {emory,uunet}!rsiatl!jgd| with the same fervor as you do the 1st. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102908444200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 07:25:27 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03848; Mon, 29 Oct 90 07:15:21 -0800 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 Oct 90 08:44:42 GMT From: pacbell.com!pacbell!indetech!fiver!palowoda@ucsd.edu (Bob Palowoda) Organization: Fiver Communications, Fremont, Ca Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: <1990Oct29.084442.28373@fiver> References: <1990Oct28.220432.521@ddsw1.MCS.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil From article <1990Oct28.220432.521@ddsw1.MCS.COM>, by karl@ddsw1.MCS.COM (Karl Denninger): > This is a call to action by all interested parties. > > There is wind of a proposal stirring in Washington that would place the > NSFNet backbone, and eventually the entire government-run part of the > Internet, into the hands of IBM. This is a very bad idea. For one the Internet, NFSFNet, and all the other local networks stand for something opposite of the corporate sturctures. Don't get me wrong I think IBM is a good company but they do not have a policy for controling goverment resources. > IBM has supposedly pledged to run this on a non-profit basis for some > number of years. Of course, the number that's being bandied about is > small, like "2"..... If what you mean by "run" as in IBM runs the networks. NO this cannot do. If they want to help why not give cash or equiptment donations to NSFNet just as any other large corporation (i.e. Xerox) would give to a public broadcasting station. > Anyone want to bet how long the Internet remains accessible to non-IBM > people? I believe IBM has thier own network(s). > Or whether the Internet ends up another Prodidy, with active > censorship? This also brings up a point of conflict in interest. > 3) Keep control in the hands of the many, or in the hands of a > non-profit corporation funded EXCLUSIVELY to run this beast. > Giving it to IBM or another pseudo-government company is as > good as letting the fox loose in the henhouse -- the > potential for abuse and profiteering is just too great to > ignore. I agree 100 percent. > Get involved NOW folks. I didn't know about this until last night, and it > knocked my socks off. People I've talked to think this is a universally bad > thing, but they don't know how to stop it. I suggest that a million loud > voices would have a significant impact. Is there any goverment email address we can write to about this? ---Bob -- Bob Palowoda palowoda@fiver | *Home of Fiver BBS* Home {sun}!ys2!fiver!palowoda | 415-623-8809 1200/2400 {pacbell}!indetech!fiver!palowoda | An XBBS System Work {sun,pyramid,decwrl}!megatest!palowoda| 415-623-8806 1200/2400/19.2k TB+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1990Oct29.095330.3479@tubsibr.uucp] <1990102909533000> From: schoenw@tubsibr.uucp (Juergen Schoenwaelder) Newsgroups: comp.protocols.tcp-ip Subject: What is a SNMP community? Message-ID: <1990Oct29.095330.3479@tubsibr.uucp> Date: 29 Oct 90 09:53:30 GMT Reply-To: schoenw@tubsibr.UUCP (Juergen Schoenwaelder) Distribution: eunet Organization: TU Braunschweig, Informatik, Bueltenweg, W. Germany Lines: 15 Posted: Mon Oct 29 10:53:30 1990 We have some confusion about the definition of a SNMP (Simple Network Management Protocol) community. RFC 1157 says: "A pairing of an SNMP agent with some arbitrary set of SNMP application entities is called an SNMP community." We think of a community as a management station with a set of network elements running SNMP agents. Can anyone help us to understand the definition given in RFC 1157 ? ----- Juergen Schoenwaelder (schoenw@tubsibr.uucp) Technische Universitaet Braunschweig, Inst. f. Betriebssysteme & Rechnerverbund Bueltenweg 74/75, 3300 Braunschweig, Germany, Tel. +0049 531 / 391-3101 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102910004600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 04:10:03 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00449; Mon, 29 Oct 90 03:56:47 -0800 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 Oct 90 10:00:46 GMT From: eru!hagbard!sunic!nuug!ifi!enag@bloom-beacon.mit.edu (Erik Naggum) Organization: Naggum Software, Oslo, Norway Subject: Re: Batching vs lock-step Message-Id: References: <9010221418.AA03839@ftp.com>, <1990Oct24.090841@apollo.HP.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article urlichs@smurf.sub.org (Matthias Urlichs) writes: The problem is that on top of TCP there's the C stdio library which tends to buffer your data when a program does an fgets(). After reading the first request, said program is likely to say "wait on the _connection_ for ten minutes until data become available". No programmer bothers to examine the stdio buffer first becase - the protocol is supposed to be lock-step anyway, - examining a stdio buffer on whether it contains data is not standardized, - the alternative is to use alarm() and signal(), but longjmp()ing from a signal handler back into a program, bypassing the stdio library on the way out, may not be what the system designers had in mind. A side effect of this is that sending a single character to such an implementation, and leaving the TCP stream open, will hang it indefinitely. ;-) I didn't get this. Are you saying you switch between stdio routines and raw socket reads at some point after the first fgets? Why would anyone do this? I've used the stdio library, which presents to me a stream of characters, to read from sockets bound to a TCP port, and this maps very elegantly on top of TCP, which is also a stream. I haven't had problems of any kind. In particular, I can't think of any real situation where your "side effect" would occur. What are you doing? Phil Karn wrote: > Given that TCP is supposed to be a reliable byte stream protocol, > the designers of these systems must have gone well out of their way > to keep this from working. If the above scenario is real, I agree completely with Phil, here. I've seen NNTP get slightly confused when GNUS (a GNU Emacs news reader) stuffed a whole bunch of command lines down its throat, and the cause was that NNTP used select(2) to wait for input. Apparently, it read the data into a large buffer, strchr'ed for '\n', replaced it with a '\0', and parsed the command. Of course, this failed miserably when GNUS was waiting for more than one reply code. I don't think this implies that the programmer has gone out of his way to keep it from working, since he's only supposed to get one command line at a time. Anyway, it works with a conforming NNTP client, although a bit on the "be conservative in what you accept and liberal in what you send" side. -- [Erik Naggum] Naggum Software; Gaustadalleen 21; 0371 OSLO; NORWAY I disclaim, , therefore I post. +47-295-8622, +47-256-7822, (fax) +47-260-4427 -- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102910223200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 04:09:50 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00730; Mon, 29 Oct 90 04:09:22 -0800 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 Oct 90 10:22:32 GMT From: eru!hagbard!sunic!news.funet.fi!funic!fuug!tuura!timok@bloom-beacon.mit.edu (Timo Kettunen) Organization: Nokia Data Systems Oy Subject: JSB MultiView DeskTop 1.2 Network Supplement? What is it? Message-Id: <819@tuura.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi there, I've got following problem: When I'am trying to establish connection with JSB MultiView DeskTop v1.2 via SCO TCP/IP to NFS-server using PC-NFS 3.0.1 on my 286 AT as a TCP/IP software providing the connection, I experience following error message: "JSB MultiView DeskTop Network Supplement not installed" and I'am unable to create the connection. Does this message indicate that I lack the supplement on my AT or on the host? What does this supplement contains? I have configured the host to which I'm going to get the connection on my AT in \NFS\HOSTS file. The connection works fine when I use FTP Software PC/TCP v2.04 as a TCP/IP software providing the connection. Thanks for any kind of help! -timo- -- ------------------------------------------------------------------------------- Timo Kettunen | +358-0-567 3143 | As the world becomes more primitive, Nokia Data | timok@yj.data.nokia.fi | it's treasures become more fabulous. General Systems | | -- Kiss Me Deadly, USA, 1955 ------------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102911020800> Received: from CORNELLC.cit.cornell.edu by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 14:02:12 PST Received: from LOCAL.DOMAIN.EDU by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 4800; Mon, 29 Oct 90 17:02:19 EST Received: by * (Mailer R2.03B) id 4644; Mon, 29 Oct 90 16:13:01 EST Date: Mon, 29 Oct 90 16:02:08 EST From: bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu> Subject: Packet Driver for PRONET To: tcp-ip@nic.ddn.mil Does anyone know the whereabouts of a packet driver that would let me run TCPIP over PRONET with Proteon's cards?? bill bill gunshannon 702WFG@SCRVMSYS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102911034600> Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 14:17:51 PST Received: from s5.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA17202; Mon, 29 Oct 90 17:17:55 -0500 Received: from s6.Morgan.COM by Morgan.COM id AA29394; Mon, 29 Oct 90 16:03:47 EST Received: by s6.Morgan.COM (4.0/SMI-4.0) id AA27879; Mon, 29 Oct 90 16:03:46 EST Date: Mon, 29 Oct 90 16:03:46 EST From: jordan@Morgan.COM (Jordan Hayes) Message-Id: <9010292103.AA27879@s6.Morgan.COM> To: tcp-ip@nic.ddn.mil Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Newsgroups: comp.protocols.tcp-ip In-Reply-To: <9010290338.AA14240@decpa.pa.dec.com> Organization: Morgan Stanley, & Co., Inc. / New York City, NY Christopher Raczka writes: I also think the "other side" of the story does need to be told and this much I do know... Sometime in September, Merit, IBM Corp, and MCI established Advanced Network and Services Inc. (ANS) ANS, a NOT FOR PROFIT organization, is to manage and operate the NSFNET backbone under subcontract to Merit Funny to see the NOT FOR PROFIT emphasis. Wasn't NYSERNET also started that way? /jordan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102912154000> Received: from kiddo.merit.edu by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 17:35:45 PST Received: Mon, 29 Oct 90 20:35:40 -0500 by kiddo.merit.edu (AIX/1.6) Date: Mon, 29 Oct 90 20:35:40 -0500 From: Hans-Werner Braun Message-Id: <9010300135.AA12143@kiddo.merit.edu> To: tcp-ip@nic.ddn.mil Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Cc: hwb@merit.edu This discussion is somewhat based on somewhat unreal assumptions. What happened some while ago was that the partnership that manages and operates the NSFNET on behalf of and under a cooperative aggreement with the National Science Foundation have created a new company to be more responsive to the everchanging requirements of the Internet. While IBM is one of the three parent corporations of this new company, they do not control it at all. There is only one IBM person on the Board of Directors who has no more rights than any of the other seven members. Also, IBM is putting money *into* this company and not getting money out of it. Just like the comment someone else made here or on the com-priv mailing list where other companies contribute to PBS stations for benefits like visibility and such. Given the non-for-profit nature of the new company it would not even be legal for IBM to have a revenue stream coming in from that company. There is absolutely no desire to be more restrictive on the network than there are restrictions today and there is also no desire to abandon current protocols. Over time, the network should even support more protocols, like OSI CLNP in parallel to IP, as demonstrated on the NSFNET backbone already. Also, over time people should look into ways to abandon as many traffic restrictions as possible. All this is an evolving process and won't happen over night and this new company is just one of several who are trying to foster the evolution of the Internet. There are other companies that came earlier, there are likely more to come in the future, all of which play important parts of the network. Soooo, IBM running the NSFNET and/or the Internet is really a little far fetched. -- Hans-Werner ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102912361200> Received: from hls.com (LANSLIDE.HLS.COM) by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 20:36:29 PST Received: by hls.com (4.0/SMI-4.0) id AA15160; Mon, 29 Oct 90 20:36:12 PST Date: Mon, 29 Oct 90 20:36:12 PST From: chuck@hls.com (Chuck Maricle) Message-Id: <9010300436.AA15160@hls.com> To: dougm@ico.isc.com, jhereg!imp@ico.isc.com Subject: Re: DECnet & IPX Cc: tcp-ip@nic.ddn.mil Sort of like their NetBios. Chuck MAricle SE Houston ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102912400700> Received: from hls.com (LANSLIDE.HLS.COM) by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 19:50:41 PST Received: from nms. (nms.hls.com) by hls.com (4.0/SMI-4.0) id AA14776; Mon, 29 Oct 90 19:50:25 PST Received: by nms. (4.0/SMI-4.0) id AA15183; Mon, 29 Oct 90 19:40:07 PST From: salzman@nms.hls.com (Mike Salzman) Message-Id: <9010300340.AA15183@nms.> Subject: Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols) To: tcp-ip@nic.ddn.mil Date: Mon, 29 Oct 90 19:40:07 PDT In-Reply-To: <73238@sgi.sgi.com>; from "Rob Warnock" at Oct 25, 90 2:15 pm Organization: Hughes Lan Systems, Mt View Ca X-Mailer: ELM [version 2.2 PL0] I suspect that the notion of reliable and group membership dealt not with the ephemeral group that exists while a message is being multicast, but rather with the commercial application that requires the confirmation that all members of a designated group obtained the set of messages to which they were entitled. Examples include updates of Price Lists, of Catalogs, of reservations, of inventories, etc. The presumption in XTP is that all those who are alive, awake and listening will received the multicast "reliably". XTP does not, to my knowledge, address itself to the administration of a group which is addressed by a multicast. -- -------------------- 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---- <1990102914241400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 08:26:48 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05241; Mon, 29 Oct 90 08:19:49 -0800 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 Oct 90 14:24:14 GMT From: usc!bbn.com!cosell@ucsd.edu (Bernie Cosell) Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: <60411@bbn.BBN.COM> References: <1990Oct28.220432.521@ddsw1.MCS.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil karl@ddsw1.MCS.COM (Karl Denninger) writes: }This is a call to action by all interested parties. }There is wind of a proposal stirring in Washington that would place the }NSFNet backbone, and eventually the entire government-run part of the }Internet, into the hands of IBM. .. }Anyone want to bet how long the Internet remains accessible to non-IBM }people? I'll take that bet --- I suspect this would never happen. ]Or whether the Internet ends up another Prodidy, with active }censorship? This is a possibility, but 'censorship' is a bit strong here. Fact is that we're using the network's comm resources for purposes quite a bit beyond the intent of the folks who chartered the thing. This is, sooner or later, going to come to a head: either the screws will be tightened, restricting the network to its narrowly-defined actual purposes [the case that you fear], or else some set of folk will manage to get the 'powers-that-be' [actually it is the 'powers-that-pay'] to acknowlegd the utility of the network in its broader uses. I, actually, think that the latter is fairly unlikely: as the gov't financial world gets more constrained, it will prove harder and harder to defend the somewhat amorphous 'general good' served by running the communications service, especially in the face of _concrete_ research projects having to be discontinued for lack of funds. Whether you'll have to buy an IBM system to hook into it, }since they might decide that TCP/IP is no longer any good and now it's }time to go to SNA or worse? This is spectacularly unlikely. If anything, TCP/IP will be abandoned in favor of ISO stacks, but even that is not going to happen any time soon. }Folks, if you love the Internet, and want to see it expand and grow, we need }to insure that a few things happen: }1) The "acceptable use" policy on the NSFNet needs to be scrapped. } Sure, this will bring problems. But it will also mean that } commercial companies can tie in, pay their fair share, and make sure } that the network capacity has the funding to continue to grow. What would you replace the policy with? I think that the NSF charter constrains their budget to be used as grants to further research. I'd bet that they can divert funds to running a communications service only as long as such a service more-or-less directly supports their research mandate. [I know that we had such a problem with ARPANET funding, way back when: when it became obvious that the ARPANET, per se, had become a communications service and not a subject of research in and of itself [indeed, if we did any real messing-around with the ARPANET we got near-instantaneous complaints from all over the world! :-)], ARPA got unhappy about funding it for precisely those two reasons: (1) it was beyond ARPA's mandate, and so would not withstand Congressional scrutiny, and (2) it preempted funds from other (real) research projects. The result was that the ARPANET operation was transferred to DCA,a nd eventually resulted in the ARPANET being decommitted entirely [the argument being that that sort of general comm facility was not an appropriate activity for the gov't to be running] }2) The backbone needs to be run as a regulated commodity. Perhaps even } run by the Government, strange as that may seem. The goal of } universal connectivity is not that far off right now, but there are } companies and special interests who would like to see that never } happen. We MUST insure that it does. I think you'll have a VERY hard time making a really rational case for this. There are commercial alternatives to the gov't-subsidized internet, and one might argue that there might well be more of 'em, and they'd be more economical, if the gov't weren't gigantically perturbing the market by making so much capacity available 'for free' [that is, 'paid for by someone else']. The easiest way to achieve your goal [of universial connectivity] is to be exploring ways to PAY for the sort of communications services you envision, rather than just thumping the drum that the gov't should provide it. }4) Finally, a freely accessible information exchange medium may be the } second-best guarantee of freedom in this country (the first being } the ability of the people to depose a despotic government). By } keeping the passing of information from coast to coast available, } fast and cheap, we keep the people informed. Granted. The only debate is the perennial one: WHO SHOULD PAY. Why not argue for a self-supporting communications service, instead of a taxpayer-supported one. The problem with the gov't-run solution is the obvious ones that crop up whenever you let the gov't run stuff: 1) if they pay for it, they'll expect to have some say about what it is used for. 2) if they pay for it, they'll make blanket rules about how it is glued together The problem with (2) is that (via the taxes we pay) we're all going to have to subsidize this communications facility even if it doesn't serve our purposes. As for (1), one need only look at the 55mph stuff and the DFWF extortion programs to see how overall nasty it can be to suckle at the gov't's teat. } 1) A tax on access devices for the network may be the best } way to fund it. I'm not sure about this, but it seems as } though a "user fee" is one of the better ways to pay for the } connectivity that we all enjoy and want to see furthered. If this is adequate to PAY for the network [I cannot imagine that it is --- do you have any clue how expensive the operating costs for something like this is?], why not simply have it be privately operated? Then the gov'ts opinion on what the net does, and what people send over it, becomes irrelevant. } 2) General subsidy isn't a bad idea either, but it's not ideal. } Selling it to the general public will be difficult, } especially with the things that hit the press now and again } about X-rated GIF sites and the like. Bingo. } 3) Keep control in the hands of the many, or in the hands of a } non-profit corporation funded EXCLUSIVELY to run this beast. } Giving it to IBM or another pseudo-government company is as } good as letting the fox loose in the henhouse -- the } potential for abuse and profiteering is just too great to } ignore. Perhaps. Going back to your original 'the sky is falling' cry, you only say "... into the hands of IBM". What does that mean? In the past, in the various networks that have contracted out to be 'run' [including the long-standing contract from ARPA, and later DCA, to BBN to operate the ARPANET and the MILNET, and one from NSF to operate the old CSNET] have been quite clear as to the responsibilites and prerogatives of the operations-entity. I cannot believe that NSF either would want, or would be legally allowed, to turn over the policy and planning of the NFSnet to IBM: the purpose of the network would still be as it was [to serve NSF's research interests] and only the NSF can evaluate and balance those purposes. It feels to me that you're doing two things here, neither of which serves us well: first is blowing the "danger" all out of proportion. Second, I think you're vastly underestimating just how much it costs to run one of these things. [and so you're being a bit cavalier at just how easy it would be to find enough money to make this 'non profit corp' to actually be able to pay its bills]. Instead of pushing for MORE gov't involvement in usenet, what is wrong with pushing for LESS: how about we eschew those 'free' govt-supplied links [which we really, probably, oughtn't have been using for rec.pets in the first place] and instead push to have more "pay for play" links? If we make our own communications arrangments [which could include using Telenet, or even, as you suggest, starting some kind of non-profit corp to provide some kind of backbone facilities], in addition to getting the connectivity you want, we have two BIG other advantages: (1) we don't have to keep groveling before Congress for funds, and (2) we don't have to duck reporters. /Bernie\ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102915120100> Received: from po9.andrew.cmu.edu by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 21:00:13 PST Received: by po9.andrew.cmu.edu (5.54/3.15) id for tcp-isdn@list.prime.com; Mon, 29 Oct 90 23:34:13 EST Received: via switchmail; Mon, 29 Oct 90 23:34:08 -0500 (EST) Received: from valkyries.andrew.cmu.edu via qmail ID ; Mon, 29 Oct 90 23:32:07 -0500 (EST) Received: from valkyries.andrew.cmu.edu via qmail ID ; Mon, 29 Oct 90 23:32:03 -0500 (EST) Received: from Messages.7.8.N.CUILIB.3.45.SNAP.NOT.LINKED.valkyries.andrew.cmu.edu.pmax.3 via MS.5.6.valkyries.andrew.cmu.edu.pmax_3; Mon, 29 Oct 90 23:32:01 -0500 (EST) Message-Id: Date: Mon, 29 Oct 90 23:32:01 -0500 (EST) From: Drew Daniel Perkins To: Robert Ullmann , TCP/ISDN list , TCP/IP list Subject: Re: RFC1183 ISDN and RT In-Reply-To: References: > Excerpts from mail: 29-Oct-90 re: RFC1183 ISDN and RT Robert > Ullmann@Relay.Pri (4646) > > From: Drew Daniel Perkins > > > > I also find it confusing exactly how the RT record is intended to work. > > > > Here's one scenario that I think these might be useful in. Imagine two > > isolated island networks NA and NB, such as might exist in two companies > > or universities. Each island network has a one or more routers, maybe > > RC and RD, with ISDN connections which can establish links to other > > networks. Now let's say I try to telnet from one non-ISDN machine HE on > > network NA to a non-ISDN machine HF on network NB. One way I could > > imagine things working is that router RC might advertise a default route > > to hosts on its network including HE. So, when I telnet, HE would send > > its packets to RC. Now, when RC received the packet addressed to HF, it > > might look up RRs for HF and it might find an RT RR for RD. Looking up > > RD it might find an ISDN RR with RD's number. It could then forward the > > packet through to RD, which would then forward it to HF. HF's response > > would hopefully be sent back through RD (due to having correct updated > > routing information) which would then realize that it already has a > > connection open to RC, and would simply send it through. > The routers, of course, don't see datagrams as requests/responses, but > route in each direction independently. (datagrams from HF in the example > route back to HE much as the original path from HE to HF was set up) > Usually this will result in the same path in both directions, but it > doesn't have to. (no, I don't think that is a problem: given a choice > between not reaching a host, and reaching it by an asymmetrical path, > I'll take the latter :-) I had intended to mention this problem, but I forgot. I do think that this might be a problem, particularly if there is only one ISDN connection into a net. If there is an asymmetrical path, the other router may try to establish a connection and get a busy signal. What if NB had two routers, RD and RG, both of which typically advertised routes to NA/HE/RC. Now, if RC established it's one and only connection with RD, but somehow the response packet got routed to RG, there would be a problem. Unfortunately I don't see a good solution other than having a routing protocol which made sure this doesn't happen. Perhaps RD and RG ought to advertise routes to NA/HE/RC with a very high metric when they do not have connections established, and change to a low metric upon connection establishment in order to avoid asymmetry. > Good example. First, note that your host is going to need an initial > default route to bootstrap itself: another host (the one at work, > presumably, or perhaps a service like uunet or PSI). It has to know > a priori the Internet and ISDN or X.25 address of that host. Presumably the ISDN and X.25 addresses would be configured at startup time as hints to your local DNS resolver. > Second case: you are on a net _not_ advertised to the core. No, > they can't reach you if they don't use RT/ISDN themselves. But > they couldn't reach you anyway ... () I don't believe they could reach you even if they did use RT/ISDN themselves, unless every other router between them and the router to which RT/ISDN refers also uses RT/ISDN. Drew ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102915230300> Received: from Relay.Prime.COM by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 17:20:37 PST Received: (from user ARIEL) by Relay.Prime.COM; 29 Oct 90 20:23:03 EST To: TCP/ISDN list , TCP/IP list , Drew Daniel Perkins From: Robert Ullmann Subject: re: RFC1183 ISDN and RT Date: 29 Oct 90 20:23:03 EST Hi, [ I am copying a larger than usual amount of text from the previous message, and sending to both TCP-IP and TCP-ISDN; I think the discussion can/should continue on TCP-ISDN. To subscribe to TCP-ISDN, send a note (content irrelevent) to TCP-ISDN-Subscribe@List.Prime.COM ] Re RFC1183, ISDN, X.25, and RT records: > From: Drew Daniel Perkins > > I also find it confusing exactly how the RT record is intended to work. > > Here's one scenario that I think these might be useful in. Imagine two > isolated island networks NA and NB, such as might exist in two companies > or universities. Each island network has a one or more routers, maybe > RC and RD, with ISDN connections which can establish links to other > networks. Now let's say I try to telnet from one non-ISDN machine HE on > network NA to a non-ISDN machine HF on network NB. One way I could > imagine things working is that router RC might advertise a default route > to hosts on its network including HE. So, when I telnet, HE would send > its packets to RC. Now, when RC received the packet addressed to HF, it > might look up RRs for HF and it might find an RT RR for RD. Looking up > RD it might find an ISDN RR with RD's number. It could then forward the > packet through to RD, which would then forward it to HF. HF's response > would hopefully be sent back through RD (due to having correct updated > routing information) which would then realize that it already has a > connection open to RC, and would simply send it through. For someone who finds it confusing, you have given a perfect example :-) The routers, of course, don't see datagrams as requests/responses, but route in each direction independently. (datagrams from HF in the example route back to HE much as the original path from HE to HF was set up) Usually this will result in the same path in both directions, but it doesn't have to. (no, I don't think that is a problem: given a choice between not reaching a host, and reaching it by an asymmetrical path, I'll take the latter :-) Note that they don't have to be "isolated island networks" for this to be useful: for example, Prime runs its internal net using a private X.25 network, configured as part of several PSDNS; some (most) of Prime's traffic would be inappropriate on the Internet-proper (to, say, one of our customers), being purely commercial. > When we start scaling this simple example up, I see a lot of problems > start popping up. Imagine I just have a single host (at home maybe) > with an ISDN connection. Now, I want to telnet to a host which is > somewhere on the Internet, behind maybe dozens of router hops. It's > hard to imagine that every host on the internet will have an RT RR in > the DNS. If I were a random site with hosts on the Internet, but no > ISDN connections, what RT RR would I want to advertise? There might be > thousands of other hosts/routers on the Internet with ISDN connections. > Which would I choose, and how? > Drew Good example. First, note that your host is going to need an initial default route to bootstrap itself: another host (the one at work, presumably, or perhaps a service like uunet or PSI). It has to know a priori the Internet and ISDN or X.25 address of that host. For hosts that do not have RT or ISDN records, you continue to use the default(s). This may be desired behavior anyway, since reaching connected-internet hosts is probably best accomplished via your work/service. By "connected-internet", I mean hosts on nets known to the core routers. How do they reach you? Two cases. In the first case, you have an IP address on a net advertised to the core (by your service host); they reach you by routing in the normal way, your service host finds you a priori. Second case: you are on a net _not_ advertised to the core. No, they can't reach you if they don't use RT/ISDN themselves. But they couldn't reach you anyway ... () About every host (or domain, using wildcards at some level) having RT or X.25/ISDN records: IMHO, an ISDN interface is going to be commonplace soon; sites (even hosts) that do not have their own will be very unusual indeed. (Put Down the Flame-Thrower, Sir! Go back and take note of the "IMHO" :-) IMHO: (<-- note again :-) with the extension of the Internet into more and more commercial domains, and extensive use that would be completely unacceptable to the research Internet (Prime and customers exchanging EDI, for example), the new routing core must be based on the ISDN, with real unrestricted access between organizations. Best Regards, Robert Ullmann Prime Computer, Inc. +1 508 620 2800 ext 1736 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010292045.AA11871@ucbvax.Berkeley.EDU] <1990102916040800> From: clynn@BBN.COM (Charles Lynn) Newsgroups: comp.protocols.tcp-ip Subject: Re: Reliable Datagram ??? Protocols Message-ID: <9010292045.AA11871@ucbvax.Berkeley.EDU> Date: 29 Oct 90 16:04:08 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 Posted: Mon Oct 29 17:04:08 1990 Doesn't TCP require the connection to be in the ESTABLISHED state before it is permitted to deliver data to the application? If so, I think B cannot see the data until it gets the ACK of its SYN from A, thus the response from B cannot be includes with B's SYN ACK. Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102917370000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 13:40:48 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12941; Mon, 29 Oct 90 13:34:13 -0800 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 Oct 90 17:37:00 GMT From: elroy.jpl.nasa.gov!usc!wuarchive!umich!accuvax.nwu.edu!casbah.acns.nwu.edu!eecs.nwu.edu!matt@lll-winken.llnl.gov (Matt Larson) Organization: ACNS DSS Subject: Looking for utility to monitor RIP packets Message-Id: <775@casbah.acns.nwu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am looking for a UNIX utility that will listen for all the RIP packets on a network and display their contents. I am essentially trying to duplicate the output of a cisco router with RIP debugging turned on. The output looks something like: Received RIP update from xxx.xxx.xxx.xxx: network yyy.yyy.yyy.yyy in n hops network zzz.zzz.zzz.zzz in m hops ... This would be really handy on a large network with no ciscos. I know that gated has a debugging mode, but it doesn't provide quite the information that I am looking for. If anyone knows of a utility to do something like this, I would be interested to hear about it. If I can't find one, I'm going to write it myself. Of course, if it has already been written, then I'm not going to bother. Thanks for any information, -- Matt Larson, Distributed Systems Analyst Academic Computing and Network Services, Northwestern University matt@acns.nwu.edu (708) 491-5366 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1990Oct29.182022.2227@terminator.cc.umich.edu] <1990102918202200> From: baw@terminator.cc.umich.edu (Brian Wolfe) Newsgroups: comp.protocols.tcp-ip,comp.os.vms Subject: Cheap (or Free) TCP-IP for VMS Message-ID: <1990Oct29.182022.2227@terminator.cc.umich.edu> Date: 29 Oct 90 18:20:22 GMT Sender: usenet@terminator.cc.umich.edu (usenet news) Organization: Rush Medical Center, Chicago IL Lines: 29 Posted: Mon Oct 29 19:20:22 1990 I'm trying to get a few departments of my company to get together to help finance an Internet connection and unfortunately not all of them have money to pay for the connection and the TCP-IP software for VMS. (One of the machines we need it for is a Vax 6440, soon to be traded in for a Vax 9000) Is there any free or very cheap TCP-IP software for VMS available? Telnet and FTP would be the only applications they need. I'm already familiar with DEC's UCX, Wollengong, TGV, Fusion & Process Software, Unfortunately they are just too expensive. I'd appreciate any pointers and I will gladly summarize for the net. regards, Brian Wolfe Rush Medical Center Chicago, IL bwolfe@rpslmc.edu (312)-942-5781 -- ------------------------------------------------------------------------- Brian Wolfe Internet: baw@terminator.cc.umich.edu Systems Analyst UUCP: {rutgers,uunet}!sharkey!hfhrv!brian Henry Ford Hospital Voice: (313)-876-7461 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102918525700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 11:13:58 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA09552; Mon, 29 Oct 90 11:08:01 -0800 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 Oct 90 18:52:57 GMT From: ken@cu-arpa.cs.cornell.edu (Ken Birman) Organization: Cornell Univ. CS Dept, Ithaca NY Subject: Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols) Message-Id: <47714@cornell.UUCP> References: , <9010251640.AA01218@hpsdel.sde.hp.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010251640.AA01218@hpsdel.sde.hp.com> wunder@HPSDEL.SDE.HP.COM (Walter Underwood) writes: >I'm surprised that no one has mentioned Cornell's ISIS system.... ... I don't normally follow this group, but someone pointed out the two postings that mention ISIS, so I am including some information on our system, below. The version of ISIS mentioned here (V2.1) has been available since early September and is apparently quite solid. You can copy it anonymously from several places and it does solve the reliable broadcast (and datagram!) problems. As noted in this posting, there is also a newsgroup for ISIS-related discussion. It tends to run in broadcast mode, but questions can certainly be posted there and one of my group members will respond, or I will. We have a forthcoming commercial release of ISIS, from a company called ISIS Distributed Systems Incorporated. Email to me for details and I can see to it that you get on the IDS mailing list. The company version of ISIS is somewhat extended over the public one, and faster in some modes of use, but the public copy should be fine for figuring out what ISIS is all about. In fact, many companies are using ISIS as part of distributed systems products now. The product will be priced "aggressively", and has some nice distributed application management utilities layered over it. As noted below, all the ISIS papers and the manual are available upon request, and many can be copied anonymously if you have a postscript printer. Ken Birman (reply to me, as I can't afford to follow any more newsgroups!) --- ISIS V2.1 blurb --- This is to announce the availability of a public distribution of the ISIS System, a toolkit for distributed and fault-tolerant programming. The initial version of ISIS runs on UNIX on SUN, DEC, GOULD, AUX and HP systems; ports to other UNIX-like systems are planned for the future. No kernel changes are needed to support ISIS; you just roll it in and should be able to use it immediately. The current implementation of ISIS performs well in networks of up to about 100-200 sites. Most users, however, run on a smaller number of sites (16-32 is typical) and other sites connect as "remote clients" that don't actually run ISIS directly. In this mode many hundreds of ISIS users can be clustered around a smaller set of ISIS "mother sites"; many users with large networks favor such an architecture. --- Who might find ISIS useful? --- You will find ISIS useful if you are interested in developing relatively sophisticated distributed programs under UNIX (eventu- ally, other systems too). These include programs that distribute computations over multiple processes, need fault-tolerance, coor- dinate activities underway at several places in a network, recover automatically from software and hardware crashes, and/or dynamically reconfigure while maintaining some sort of distri- buted correctness constraint at all times. ISIS is also useful in building certain types of distributed real time systems. Here are examples of problems to which ISIS has been applied: o On the factory floor, we are working with an industrial research group that is using ISIS to program decentralized cell controllers. They need to arrive at a modular, expand- able, fault-tolerant distributed system. ISIS makes it pos- sible for them to build such a system without a huge invest- ment of effort. (The ISIS group also working closely with an automation standards consortium called ANSA, headed by Andrew Herbert in Cambridge). o As part of a network file system, we built an interface to the UNIX NFS (we call ours "DECEIT") that supports tran- sparent file replication and fault-tolerance. DECEIT speaks NFS protocols but employs ISIS internally to maintain a consistent distributed state. For most operations, DECEIT performance is at worst 50-75% of that of a normal NFS -- despite supporting file replication and fault-tolerance. Interestingly, for many common operations, DECEIT substantially outperforms NFS (!) and it is actually fairly hard to come up with workloads that demonstate replication-related degradation. o A parallel "make" program. Here, ISIS was used within a control program that splits up large software recompilation tasks and runs them on idle workstations, tolerating failures and dynamically adapting if a workstation is reclaimed by its owner. o A system for monitoring and reacting to sensors scattered around the network, in software or in hardware. This system, Meta, is actually included as part of our ISIS V2.1 release. We are adding a high level language to it now, Lomita, in which you can specify reactive control rules or embed such rules into your C or Fortran code, or whatever. o In a hospital, we have looked at using ISIS to manage repli- cated data and to coordinate activities that may span multi- ple machines. The problem here is the need for absolute correctness: if a doctor is to trust a network to carry out orders that might impact on patient health, there is no room for errors due to race conditions or failures. At the same time, cost considerations argue for distributed systems that can be expanded slowly in a fully decentralized manner. ISIS addresses both of these issues: it makes it far easier to build a reliable, correct, distributed system that will manage replicated data and provide complex distributed behaviors. And, ISIS is designed to scale well. o For programming numerical algorithms. One group at Cornell used ISIS to distribute matrix computations over large numbers of workstations. They did this because the worksta- tions were available, mostly idle, and added up to a tremen- dous computational engine. Another group, at LANL, uses ISIS in a parallel plasma physics application. o In a graphics rendering application. Over an extended period, a Cornell graphics group (not even in our department) has used ISIS to build distributed rendering software for image generation. They basically use a set of machines as a parallel processor, with a server that farms out rendering tasks and a variable set of slave computing units that join up when their host machine is fairly idle and drop out if the owner comes back to use the machine again. This is a nice load sharing paradigm and makes for sexy demos too. o In a wide-area seismic monitoring system (i.e. a system that has both local-area networks and wide-area connections between them), developed by a company called SAIC on a DARPA contract. The system gathers seismic data remotely, preprocesses it, and ships event descriptions to a free-standing analysis "hub", which must run completely automatically (their people in San Diego don't like to be phoned in the middle of the night to debug problems in Norway). The hub may request data transfers and other complex computations, raising a number of wide-area programming problems. In addition, the hub system itself has a lot of programs in various languages and just keeping it running can be a challenge. o On brokerage and banking trading floors. Here, ISIS tends to be an adjunct to a technology for distributing quotes, because the special solutions for solving that specific problem are so fast that it is hard for us to compete with them (we normally don't have the freedom of specifying the hardware... many "ticker plant vendors" wire the whole floor for you). However, to the extent that these systems have problems requiring fault-tolerance, simple database integration mechanisms, dynamic restart of services, and in general need "reactive monitoring and control" mechanisms, ISIS works well. And, with our newer versions of the ISIS protocols, performance is actually good enough to handle distribution of stock quotes or other information directly in ISIS, although one has to be a bit careful in super performance intensive settings. (The commercial ISIS release should compete well with the sorts of commercial alternatives listed above on a performance basis, but more than 10 trading groups are using ISIS V2.1 despite the fact that it is definitely slower!). The problems above are characterized by several features. First, they would all be very difficult to solve using remote procedure calls or transactions against some shared database. They have complex, distributed correctness constraints on them: what hap- pens at site "a" often requires a coordinated action at site "b" to be correct. And, they do a lot of work in the application program itself, so that the ISIS communication mechanism is not the bottleneck. If you have an application like this, or are interested in taking on this kind of application, ISIS may be a big win for you. Instead of investing resources in building an environment within which to solve your application, using ISIS means that you can tackle the application immediately, and get something working much faster than if you start with RPC (remote procedure calls). On the other hand, don't think of ISIS as competing with RPC or database transactions. We are oriented towards online control and coordination problems, fault-tolerance of main-memory databases, etc. ISIS normally co-exists with other mechanisms, such as conventional streams and RPC, databases, or whatever. The system is highly portable and not very intrusive, and many of our users employ it to control some form of old code running a computation they don't want to touch at any price. --- What ISIS does --- The ISIS system has been under development for several years at Cornell University. After an initial focus on transactional "resilient objects", the emphasis shifted in 1986 to a toolkit style of programming. This approach stresses distributed con- sistency in applications that manage replicated data or that require distributed actions to be taken in response to events occurring in the system. An "event" could be a user request on a distributed service, a change to the system configuration result- ing from a process or site failure or recovery, a timeout, etc. The ISIS toolkit uses a subroutine call style interface similar to the interface to any conventional operating system. The pri- mary difference, however, is that ISIS functions as a meta- operating system. ISIS system calls result in actions that may span multiple processes and machines in the network. Moreover, ISIS provides a novel "virtual consistency" property to its users. This property makes it easy to build software in which currently executing processes behave in a coordinated way, main- tain replicated data, or otherwise satisfy a system-wide correct- ness property. Moreover, virtual synchrony makes even complex operations look atomic, which generally implies that toolkit functions will not interfere with one another. One can take advantage of this to develop distributed ISIS software in a sim- ple step-by-step style, starting with a non-distributed program, then adding replicated data or backup processes for fault- tolerance or higher availability, then extending the distributed solution to support dynamic reconfiguration, etc. ISIS provides a really unique style of distributed programming -- at least if your distributed computing problems run up against the issues we address. For such applications, the ISIS programming style is both easy and intuitive. ISIS is really intended for, and is good at, problems that draw heavily on replication of data and coordination of actions by a set of processes that know about one another's existence. For example, in a factory, one might need to coordinate the actions of a set of machine-controlled drills at a manufacturing cell. Each drill would do its part of the overall work to be done, using a coordinated scheduling policy that avoids collisions between the drill heads, and with fault-tolerance mechanisms to deal with bits breaking. ISIS is ideally suited to solving prob- lems like this one. Similar problems arise in any distributed setting, be it local-area network software for the office or a CAD problem, or the automation of a critical care system in a hospital. ISIS is not intended for transactional database applications. If this is what you need, you should obtain one of the many such systems that are now available. On the other hand, ISIS would be useful if your goal is to build a front-end in a setting that needs databases. The point is that most database systems are designed to avoid interference between simultaneously executing processes. If your application also needs cooperation between processes doing things concurrently at several places, you may find this aspect hard to solve using just a database because databases force the interactions to be done indirectly through the shared data. ISIS is good for solving this kind of problem, because it provides a direct way to replicate control informa- tion, coordinate the actions of the front-end processes, and to detect and react to failures. ISIS itself runs as a user-domain program on UNIX systems sup- porting the TCP/IP protocol suite. It currently is operational on SUN, DEC, GOULD and HP versions of UNIX. Language interfaces for C, C++, FORTRAN, and Common LISP (both Lucid and Allegro) are included, and a new C-Prolog interface is being tested now. Recent ports available in V2.1 include AUX for the Apple Mac. II, AIX on the IBM RS/6000 and also the older PC/RT. A Cray UNICOS port is (still) under development at LANL, and a DEC VMS port is being done by ISIS Distributed Systems, Inc. ISIS runs over Mach on anything that supports Mach but will probably look a little unnatural to you if you use the Mach primitives. We are planning a version of ISIS that would be more transparent in a Mach context, but it will be some time before this becomes available. Meanwhile, you can use ISIS but may find some aspects of the interface inconsistent with the way that Mach does things. The actual set of tools includes the following: o High performance mechanisms supporting lightweight tasks in UNIX, a simple message-passing facility, and a very simple and uniform addressing mechanism. Users do not work directly with things like ports, sockets, binding, connect- ing, etc. ISIS handles all of this. o A process "grouping" facility, which permits processes to dynamically form and leave symbolically-named associations. The system serializes changes to the membership of each group: all members see the same sequence of changes. Groups names can be used as a location-transparent address. o A suite of broadcast protocols integrated with a group addressing mechanism. This suite operates in a way that makes it look as if all broadcasts are received "simultane- ously" by all the members of a group, and are received in the same "view" of group membership. o Ways of obtaining distributed executions. When a request arrives in a group, or a distributed event takes place, ISIS supports any of a variety of execution styles, ranging from a redundant computation to a coordinator-cohort computation in which one process takes the requested actions while oth- ers back it up, taking over if the coordinator fails. o Replicated data with 1-copy consistency guarantees. o Synchronization facilities, based on token passing or read/write locks. o Facilities for watching a for a process or site (computer) to fail or recover, triggering execution of subroutines pro- vided by the user when the watched-for event occurs. If several members of a group watch for the same event, all will see it at the same "time" with respect to arriving mes- sages to the group and other events, such as group member- ship changes. o A facility for joining a group and atomically obtaining copies of any variables or data structures that comprise its "state" at the instant before the join takes place. The programmer who designs a group can specify state information in addition to the state automatically maintained by ISIS. o Automatic restart of applications when a computer recovers from a crash, including log-based recovery (if desired) for cases when all representatives of a service fail simultane- ously. o Ways to build transactions or to deal with transactional files and database systems external to ISIS. ISIS itself doesn't know about files or transactions. However, as noted above, this tool is pretty unsophisticated as transactional tools go... o Spooler/long-haul mechanism, for saving data to be sent to a group next time it recovers, or for sending from one ISIS LAN to another, physically remote one (e.g. from your Norway site to your San Diego installation). Note: ISIS will not normally run over communication links subject to frequent failures, al- though this long-haul interface has no such restrictions. Everything in ISIS is fault-tolerant. Our programming manual has been written in a tutorial style, and gives details on each of these mechanisms. It includes examples of typical small ISIS applications and how they can be solved. The distribution of the system includes demos, such as the parallel make facility men- tioned above; this large ISIS application program illustrates many system features. To summarize, ISIS provides a broad range of tools, including some that require algorithms that would be very hard to support in other systems or to implement by hand. Performance is quite good: most tools require between 1/20 and 1/5 second to execute on a SUN 3/60, although the actual numbers depend on how big processes groups get, the speed of the network, the locations of processes involved, etc. Overall, however, the system is really quite fast when compared with, say, file access over the network. For certain common operations a five to ten-fold performance improvement is expected within two years, as we implement a col- lection of optimizations. The system scales well with the size of the network, and system overhead is largely independent of network size. On a machine that is not participating in any ISIS application, the overhead of having ISIS running is negligible. In certain communication scenarios, ISIS performance can be quite good. These involve streaming data within a single group or certain client-server interaction patterns, and make use of a new BYPASS communication protocol suite. Future ISIS development is likely to stress extensions and optimizations at this level of the system. In addition, a lot of effort is going into scaling the system to larger environments. --- You can get a copy of ISIS now --- Version V2.1 of ISIS is now fully operational and is being made available to the public. This version consists of a C implementations for UNIX, and has been ported to AIX, SUN, UNIX, MACH, ULTRIX, Gould UNIX, HP-UX, AUX and APOLLO UNIX (release 10.1). Performance is uniformly good. A 400 page tutorial and sys- tem manual containing numerous programming examples is also available. Online manual pages are also provided. The remainder of this posting focuses on how to get ISIS, and how to get the manual. Everything is free except bound copies of the manual. Source is included, but the system is in the public domain, and is released on condition that any ports to other sys- tems or minor modifications remain in the public domain. The manual is copyrighted by the project and is available in hard- copy form or as a DVI file, with figures available for free on request. We have placed a compressed TAR images in the following places: * cu-arpa.cs.cornell.edu (anonymous login, binary mode pub/ISISV21.TAR.Z) * Doc: cu-arpa.cs.cornell.edu (pub/ISISV21-DOC.TAR.Z) * uunet.uu.net (anonymous login, binary mode networks/ISIS/ISISV21.TAR.Z) * mcsun.eu.net (anonymous login, binary mode networks/ISIS/ISISV21.TAR.Z) Also available are DVI and PS versions of our manual. Bound copies will be available at $25 each. A package of figures to glue into the DVI version will be provided free of charge. A tape containing ISIS will be provided upon payment of a charge to cover our costs in making the tape. Our resources are limited and we do not wish to do much of this. --- Copyright, restrictions --- V2.1 of ISIS is subject to a restrictive copyright; basically, you can use it without changing it in any way you like, but are not permitted to develop "derivative versions" without discussing this with us. V2.1 differs substantially from V1.3.1, which was released in the public domain and remains available without any restrictions whatsoever. On the other hand, whereas previous versions of ISIS required export licenses to be sent to certain eastern-block countries, the present version seems not to be subject to this restriction. Contact the US Dept. of Commerce for details if you plan to export ISIS to a country that might be subject to restrictions. Any place in Europe, Japan, etc. should be fine and no license is required. --- Commercial support --- We are working with a local company, ISIS Distributed Systems Inc., to provide support services for ISIS. This company will prepare distributions and work to fix bugs. Support contracts are available for an annual fee; without a contract, we will do our best to be helpful but make no promises. Other services that IDS plans to provide will include consulting on fault-tolerant distributed systems design, instruction on how to work with ISIS, bug identification and fixes, and contractual joint software development projects. The company is also prepared to port ISIS to other systems or other programming languages. Contact "birman@gvax.cs.cornell.edu" for more information. --- If you want ISIS, but have questions, let us know --- Send mail to isis@cs.cornell.edu, subject "I want ISIS", with electronic and physical mailing details. We will send you a form for acknowledging agreement with the conditions for release of the software and will later contact you with details on how to actually copy the system off our machine to yours. --- You can read more about ISIS if you like --- The following papers and documents are available from Cornell. We don't distribute papers by e-mail. Requests for papers should be transmitted to "isis@cs.cornell.edu". 1. Exploiting replication. K. Birman and T. Joseph. This is a preprint of a chapter that will appear in: Arctic 88, An advanced course on operating systems, Tromso, Norway (July 1988). 50pp. 2. Reliable broadcast protocols. T. Joseph and K. Birman. This is a preprint of a chapter that will appear in: Arctic 88, An advanced course on operating systems, Tromso, Norway (July 1988). 30pp. 3. ISIS: A distributed programming environment. User's guide and reference manual. K. Birman, T. Joseph, F. Schmuck. Cornell University, March 1988. 275pp. 4. Exploiting virtual synchrony in distributed systems. K. Birman and T. Joseph. Proc. 11th ACM Symposium on Operating Systems Principles (SOSP), Nov. 1987. 12pp. 5. Reliable communication in an unreliable environment. K. Birman and T. Joseph. ACM Transactions on Computer Systems, Feb. 1987. 29pp. 6. Low cost management of replicated data in fault-tolerant distributed systems. T. Joseph and K. Birman. ACM Transac- tions on Computer Systems, Feb. 1986. 15pp. 7. Fast causal multicast. K. Birman, A. Schiper, P. Stephenson. Dept. of Computer Science TR, May 1990. 8. Distributed application management. K. Marzullo, M. Wood, R. Cooper, K. Birman. Dept. of Computer Science TR, June 1990. We will be happy to provide reprints of these papers. Unless we get an overwhelming number of requests, we plan no fees except for the manual. We also maintain a mailing list for individuals who would like to receive publications generated by the project on an ongoing basis. The last two papers can be copied using FTP from cu-arpa.cs.cornell.edu. If you want to learn about the virtual synchrony as an approach to distributed computing, the best place to start is with refer- ence [1]. If you want to learn more about the ISIS system, how- ever, start with the manual. It has been written in a tutorial style and should be easily accessible to anyone familiar with the C programming language. References [7] and [8] are typical of our recent publications (there are others -- contact Maureen Robinson for details). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102920524400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 21:41:10 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24966; Mon, 29 Oct 90 21:32:13 -0800 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 Oct 90 20:52:44 GMT From: usc!samsung!olivea!sun-barr!newstop!male!texsun!vector!egsner!mic!supernet!cluther@ucsd.edu (Clay Luther) Organization: Harris Adacom Corporation Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: <1990Oct29.205244.2051@supernet.haus.com> References: <1990Oct28.220432.521@ddsw1.MCS.COM>, <132136@pyramid.pyramid.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >Karl, there is a *much* simpler solution. Scrap NSFNet. We don't need it. T1 >and 64K DDS lines are ***cheap*** these days, so cheap that UUNet can build >a truly commercial TCP/IP service, give excellent service, and charge less >than $2000/month for it. > Since when was $2000/month cheap? This is more than most people in the US make in a month! $2000/month is in no way cheap, with triple astericks. It is well out of the reach of the common man and beyond the means of many small companies that would profit greatly by having internet access. Internet will not be cheap until it drops to say, $100/month, or less. -- Clay Luther, Postmaster cluther@supernet.haus.com postmaster@supernet.haus.com clay.luther@supernet.haus.com Harris Adacom Corporation MS 23, PO Box 809022, Dallas, Tx 75380-9022 214/386-2356 Your mileage may vary. Void where prohibited. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010300553.AA25380@ucbvax.Berkeley.EDU] <1990102921020800> From: 702WFG@SCRVMSYS.BITNET (bill gunshannon) Newsgroups: comp.protocols.tcp-ip Subject: Packet Driver for PRONET Message-ID: <9010300553.AA25380@ucbvax.Berkeley.EDU> Date: 29 Oct 90 21:02:08 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 Posted: Mon Oct 29 22:02:08 1990 Does anyone know the whereabouts of a packet driver that would let me run TCPIP over PRONET with Proteon's cards?? bill bill gunshannon 702WFG@SCRVMSYS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102921100600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 14:56:48 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15019; Mon, 29 Oct 90 14:42:37 -0800 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 Oct 90 21:10:06 GMT From: logicon.com!Makey@nosc.mil (Jeff Makey) Organization: Logicon, Inc., San Diego, California Subject: Re: Reliable Datagram ??? Protocols Message-Id: <827@logicon.com> References: <9010221418.AA03839@ftp.com>, <1990Oct24.090841@apollo.HP.COM>, <1990Oct25.165545@envy.bellcore.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Oct25.165545@envy.bellcore.com> karn@thumper.bellcore.com writes: >There's no reason >that you shouldn't be able to send a series of SMTP commands in a >single TCP segment and receive a series of responses, except that many >SMTP servers inexplicably blow up when you try this. Given that TCP is >supposed to be a reliable byte stream protocol, the designers of these >systems must have gone well out of their way to keep this from working. Five years ago, my internet host was a PDP-11/70 running PWB UNIX (vintage 1978, for those who don't know their history). The wonderful folks at BBN had somehow managed to make this beast talk TCP/IP, and had provided implementations of TELNET, FTP, and SMTP. The SMTP code blissfully assumed that every read() call would return exactly one line of text, and this assumption was correct about 90% of the time. Eventually I wanted the other 10% to work and I added buffering to the SMTP daemon independent of TCP, but nobody had gone to any great effort to produce the broken implementation; it was just plain old lazy programming. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Domain: Makey@Logicon.COM UUCP: {ucsd,nosc}!snoopy!Makey ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102921135400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 13:43:21 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13167; Mon, 29 Oct 90 13:40:29 -0800 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 Oct 90 21:13:54 GMT From: mintaka!spdcc!spdcc.com!raisch@eddie.mit.edu Organization: Control Technology Corporation Subject: Industrial Computing Society - Call for Papers Message-Id: <4697@spdcc.SPDCC.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil ********************* INDUSTRIAL COMPUTING SOCIETY ********************* ********************* >>>>> CALL FOR PAPERS <<<<< ********************* The Industrial Computing Society (ICS), an international network of people involved in industrial applications of computers, announces the first annual Industrial Computing Conference (ICC/91) to be held in conjunction with the ISA conference in Anaheim, California on October 28-31, 1991. We are actively recruiting session developers, as well as paper sessions, panel discussions, workshops, and roundtables that cover industrial computing hardware, software, peripherals and integration. Specific platforms addressed will include hardened computers, PLCs, DCSs, and mainframe level computing. All sessions will concentrate on technology and applications; promotional sessions are strictly forbidden. >>>>> SUGGESTED TOPICS CIM Technology Industrial Computing: Technology and Applications Distributed Control Systems Programmable Logic Controllers Flexible Manufacturing Systems Case Studies of Automation Applications Networking: Industrial LANs, Communications Protocols, MAP/TOP, Ethernet, Fieldbus MRP and Manufacturing Information Systems Manufacturing Databases Artificial Intelligence, Expert Systems, Neural Networks Selecting a Computer-based Control System Data Acquisition and Control Statistical Process Control Operator Interfaces Operating Systems for Plant Floor Control Bus Interfaces in Computer-based Control Systems Automation Standards Development Robotics, Machine Vision You may make a submission for a conference session by completing an ISA/ICC "Intent to Present" form. These forms can be obtained from Shari Worthington, ICC/91 Assistant Program Chair, by calling (508)755-5242 or FAXing to (508)795-1636. >>>>> DEADLINES Paper Sessions (to be published in ICC proceedings): - Abstracts due 1 DEC 1990 - Draft Papers due 8 FEB 1991 - Camera-ready Manuscripts due 3 JUN 1991 Panel Discussions, Workshops, Roundtables (not published): - Abstracts due 1 DEC 1990 - Final List of Session Speakers due 3 JUN 1991 ************ ** FREE ** SOCIETY MEMBERSHIP ************ For a limited time, FREE first-year founding memberships are available in the Industrial Computing Society. For an application form, contact: Industrial Computing Society c/o Instrument Society of America PO Box 12277 Research Triangle Park, NC 27709 Telephone (919) 549-8411 E-mail inquiries may be directed to Ken Crater (ken@control.com), member, ICS Steering Committee, and will be forwarded to the appropriate officer. Please be patient. --------------------------------------------------------------------------- Ken Crater -- member, Steering Committee, ICS Control Technology Corporation, Hopkinton, MA 01748 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102922523100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 16:41:11 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA18095; Mon, 29 Oct 90 16:32:51 -0800 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 Oct 90 22:52:31 GMT From: njin!uupsi!schoff@rutgers.edu (Martin Schoffstall) Organization: Performance Systems International, Inc. Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: <1990Oct29.225231.17042@uu.psi.com> References: <1990Oct28.220432.521@ddsw1.MCS.COM>, <132136@pyramid.pyramid.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I don't think that eveyone needs to scrap the NSFNet right now, especially since it is free. What we need to consider are several levels of service/capabilities/restrictions in the US and Internationally. For those organizations willing to abide by the restrictions let them have the academic regionals and NSFNet. For those who don't let them leave and migrated to TYMNET, TELENET, ALTERNET, PSINET, and XYZNet. Of course in october 92 when the NSFNet funding is finished there will probably be even more choices. Because as a good friend of mine said once: who can compete with free? Marty ------------------ >Karl, there is a *much* simpler solution. Scrap NSFNet. We don't need it. T1 >and 64K DDS lines are ***cheap*** these days, so cheap that UUNet can build >a truly commercial TCP/IP service, give excellent service, and charge less >than $2000/month for it. > >NSFNet is the government's network. Let them have it for anyone who wants to >live under the government's terms and conditions. Just as the Europeans are >throwing off the yokes of their PTTs, it's time for us to throw off the yoke >of state-sponsored communications networks, and start building our own. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990102922573100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 16:40:48 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA18079; Mon, 29 Oct 90 16:32:29 -0800 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 Oct 90 22:57:31 GMT From: njin!uupsi!schoff@rutgers.edu (Martin Schoffstall) Organization: Performance Systems International, Inc. Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: <1990Oct29.225731.17269@uu.psi.com> References: <1990Oct28.220432.521@ddsw1.MCS.COM>, <1990Oct29.084442.28373@fiver> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil > > Is there any goverment email address we can write to about this? > >---Bob You can start with steve@note.nsf.gov who is responsible for "infrastructure", but as pointed out in another posting, com-priv@psi.com is where this is being discussed in depth, and both the government and the participants are all at least watching. Marty ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103001033300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 18:25:49 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA20842; Mon, 29 Oct 90 18:24:00 -0800 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 Oct 90 01:03:33 GMT From: usc!samsung!sol.ctr.columbia.edu!ira.uka.de!smurf!urlichs@ucsd.edu (Matthias Urlichs) Organization: University of Karlsruhe, FRG Subject: Re: Batching vs lock-step Message-Id: References: <1990Oct25.165545@envy.bellcore.com>, , Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In comp.protocols.tcp-ip, article , enag@ifi.uio.no (Erik Naggum) writes: < In article urlichs@smurf.sub.org (Matthias Urlichs) writes: < < The problem is that on top of TCP there's the C stdio library which tends to < buffer your data when a program does an fgets(). < < After reading the first request, said program is likely to say "wait on the < _connection_ for ten minutes until data become available". < [...] < A side effect of this is that sending a single character to such an < implementation, and leaving the TCP stream open, will hang it indefinitely. < ;-) < < I didn't get this. Are you saying you switch between stdio routines < and raw socket reads at some point after the first fgets? < No, I said (and quite a few programs actually do it) that the programs alternate between reading via stdio and using select() on the raw socket. < In particular, I can't think of any real situation where your "side < effect" would occur. < Consider a program which does: - while(TCP stream OK) - select(TCP stream, 10 minutes) - fgets(stream, data) - process (data) Now if you send a single character to this program, the select call will say OK, but the fgets() will hang, waiting for a Newline. Alterntely, if you send two short lines, the fgets will read both into its buffer (and return the first to the program), and next time 'round the select will block. < I've seen NNTP get slightly confused when GNUS (a GNU Emacs news < reader) stuffed a whole bunch of command lines down its throat, and < the cause was that NNTP used select(2) to wait for input. Apparently, < it read the data into a large buffer, strchr'ed for '\n', replaced it < with a '\0', and parsed the command. [...] It's far simpler -- see above. < Anyway, it works with a conforming NNTP client, although a bit < on the "be conservative in what you accept and liberal in what you < send" side. < That seems to be the problem. ;-) -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010301059.AA00278@ucbvax.Berkeley.EDU] <1990103001230300> From: Ariel@RELAY.PRIME.COM (Robert Ullmann) Newsgroups: comp.protocols.tcp-ip Subject: re: RFC1183 ISDN and RT Message-ID: <9010301059.AA00278@ucbvax.Berkeley.EDU> Date: 30 Oct 90 01:23:03 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 95 Posted: Tue Oct 30 02:23:03 1990 Hi, [ I am copying a larger than usual amount of text from the previous message, and sending to both TCP-IP and TCP-ISDN; I think the discussion can/should continue on TCP-ISDN. To subscribe to TCP-ISDN, send a note (content irrelevent) to TCP-ISDN-Subscribe@List.Prime.COM ] Re RFC1183, ISDN, X.25, and RT records: > From: Drew Daniel Perkins > > I also find it confusing exactly how the RT record is intended to work. > > Here's one scenario that I think these might be useful in. Imagine two > isolated island networks NA and NB, such as might exist in two companies > or universities. Each island network has a one or more routers, maybe > RC and RD, with ISDN connections which can establish links to other > networks. Now let's say I try to telnet from one non-ISDN machine HE on > network NA to a non-ISDN machine HF on network NB. One way I could > imagine things working is that router RC might advertise a default route > to hosts on its network including HE. So, when I telnet, HE would send > its packets to RC. Now, when RC received the packet addressed to HF, it > might look up RRs for HF and it might find an RT RR for RD. Looking up > RD it might find an ISDN RR with RD's number. It could then forward the > packet through to RD, which would then forward it to HF. HF's response > would hopefully be sent back through RD (due to having correct updated > routing information) which would then realize that it already has a > connection open to RC, and would simply send it through. For someone who finds it confusing, you have given a perfect example :-) The routers, of course, don't see datagrams as requests/responses, but route in each direction independently. (datagrams from HF in the example route back to HE much as the original path from HE to HF was set up) Usually this will result in the same path in both directions, but it doesn't have to. (no, I don't think that is a problem: given a choice between not reaching a host, and reaching it by an asymmetrical path, I'll take the latter :-) Note that they don't have to be "isolated island networks" for this to be useful: for example, Prime runs its internal net using a private X.25 network, configured as part of several PSDNS; some (most) of Prime's traffic would be inappropriate on the Internet-proper (to, say, one of our customers), being purely commercial. > When we start scaling this simple example up, I see a lot of problems > start popping up. Imagine I just have a single host (at home maybe) > with an ISDN connection. Now, I want to telnet to a host which is > somewhere on the Internet, behind maybe dozens of router hops. It's > hard to imagine that every host on the internet will have an RT RR in > the DNS. If I were a random site with hosts on the Internet, but no > ISDN connections, what RT RR would I want to advertise? There might be > thousands of other hosts/routers on the Internet with ISDN connections. > Which would I choose, and how? > Drew Good example. First, note that your host is going to need an initial default route to bootstrap itself: another host (the one at work, presumably, or perhaps a service like uunet or PSI). It has to know a priori the Internet and ISDN or X.25 address of that host. For hosts that do not have RT or ISDN records, you continue to use the default(s). This may be desired behavior anyway, since reaching connected-internet hosts is probably best accomplished via your work/service. By "connected-internet", I mean hosts on nets known to the core routers. How do they reach you? Two cases. In the first case, you have an IP address on a net advertised to the core (by your service host); they reach you by routing in the normal way, your service host finds you a priori. Second case: you are on a net _not_ advertised to the core. No, they can't reach you if they don't use RT/ISDN themselves. But they couldn't reach you anyway ... () About every host (or domain, using wildcards at some level) having RT or X.25/ISDN records: IMHO, an ISDN interface is going to be commonplace soon; sites (even hosts) that do not have their own will be very unusual indeed. (Put Down the Flame-Thrower, Sir! Go back and take note of the "IMHO" :-) IMHO: (<-- note again :-) with the extension of the Internet into more and more commercial domains, and extensive use that would be completely unacceptable to the research Internet (Prime and customers exchanging EDI, for example), the new routing core must be based on the ISDN, with real unrestricted access between organizations. Best Regards, Robert Ullmann Prime Computer, Inc. +1 508 620 2800 ext 1736 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103002471100> Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Tue, 30 Oct 90 04:50:24 PST Received: from interlan.interlan.com by RELAY.CS.NET id aa02434; 30 Oct 90 7:48 EST Received: from europa.InterLan.COM by interlan.interlan.com (5.61/5.17) id AA21537; Tue, 30 Oct 90 07:46:43 -0500 Received: by europa.Interlan.COM (4.0/SMI-4.0) id AA01053; Tue, 30 Oct 90 07:47:11 EST Date: Tue, 30 Oct 90 07:47:11 EST From: Frank Kastenholz Message-Id: <9010301247.AA01053@europa.Interlan.COM> To: hwb@MERIT.EDU, tcp-ip@NIC.DDN.MIL Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! > From tcp-ip-RELAY@NIC.DDN.MIL Tue Oct 30 07:05:31 1990 > From: Hans-Werner Braun > To: tcp-ip@nic.ddn.mil > Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! > Cc: hwb@merit.edu > > all of which play important parts of the network. Soooo, IBM running the > NSFNET and/or the Internet is really a little far fetched. Awwwwww, and I just threw out my System/370 Yellow Cards with the EBCDIC Encodings :-) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103002575200> Received: from SALAD.BBN.COM by NIC.DDN.MIL with TCP; Tue, 30 Oct 90 08:31:11 PST Received: by SALAD.BBN.COM id aa02571; 30 Oct 90 11:21 EST To: Bernie Cosell cc: tcp-ip@nic.ddn.mil Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! In-reply-to: Your message of 29 Oct 90 14:24:14 +0000. <60411@bbn.BBN.COM> Date: Tue, 30 Oct 90 11:17:52 -0500 From: tmallory@BBN.COM The IBM/NSFnet discussion has, for some reason or another, brought to mind the ATT divestiture boondoggle. I used to be able to get basic phone service for $4.50/month that allowed people to call me, and to make a few local calls in the bargain, and they threw in the phone rental too! The most similar service now is $14.46, and I have to buy and service my own phone. The inexpensive rate was apparently made possible by charging extra for long-distance service in order to subsidize universal access, but it seems to me that a lot of individuals benefitted, where now you have to be a business in order to save money. There's got to be a connection: at the very least it's not clear that allowing a single company to run the show will necessarily be bad. Tracy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103003270600> Received: from ftp.com by NIC.DDN.MIL with TCP; Tue, 30 Oct 90 08:36:46 PST Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA01687; Tue, 30 Oct 90 11:47:06 -0500 Date: Tue, 30 Oct 90 11:47:06 -0500 Message-Id: <9010301647.AA01687@ftp.com> To: bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu> Subject: Re: Packet Driver for PRONET 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 the whereabouts of a packet driver that would let me run TCPIP over PRONET with Proteon's cards?? To my knowlege, there have never been any Class 2 (ProNET-10) packet drivers. Given that at least PC-IP and NCSA support the basic packet formats, it wouldn't be hard to do one, but you'd probably want Netware support too... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103005211400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 30 Oct 90 06:42:18 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03551; Tue, 30 Oct 90 06:32:58 -0800 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 Oct 90 05:21:14 GMT From: usc!bbn.com!drilex!dricejb@ucsd.edu (Craig Jackson drilex1) Organization: DRI/McGraw-Hill, Lexington, MA Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: <16121@drilex.UUCP> References: <1990Oct28.220432.521@ddsw1.MCS.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Oct28.220432.521@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes: >This is a call to action by all interested parties. > >There is wind of a proposal stirring in Washington that would place the >NSFNet backbone, and eventually the entire government-run part of the >Internet, into the hands of IBM. It would seem to me, in the absence of *much* more detailed information, that this is just so much conspiracy theory. >Anyone want to bet how long the Internet remains accessible to non-IBM >people? Or whether the Internet ends up another Prodidy, with active >censorship? Whether you'll have to buy an IBM system to hook into it, >since they might decide that TCP/IP is no longer any good and now it's >time to go to SNA or worse? Assuming that IBM has made such a proposal, why should they spend money to turn something working in to something that doesn't work? Not that I think that IBM has turned out many good products over the years, but they don't exist solely to torture computer programmers--they're actually trying to make a buck. Quite a few, in fact. The principal reason why IBM would volunteer to run the NFSNet, etc would be to enhance their standing in the academic technical community. This would encourage them to do a good job--the 'net' community is not one that is easily swayed by appealing to a CEO or two. >Karl Denninger (karl@ddsw1.MCS.COM, !ddsw1!karl) >Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200] >Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price" P.S. I know people who love Prodigy--just because it can give them a stock quote quickly. As for the active censorship, it seems from reports that they are a bit touchy about criticism. However, any company with "deep pockets" who does not actively censor a bbs service is a bunch of fools--there are simply too many people willing to file a civil suit or criminal charges over all sorts of nonsense. -- Craig Jackson dricejb@drilex.dri.mgh.com {bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb} ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103005415800> Received: from psi.com by NIC.DDN.MIL with TCP; Tue, 30 Oct 90 10:58:59 PST Received: from localhost by psi.com (5.61/2.1-Performance Systems International) id AA20615; Tue, 30 Oct 90 14:01:59 -0500 Message-Id: <9010301901.AA20615@psi.com> To: jordan@Morgan.COM (Jordan Hayes) Cc: tcp-ip@nic.ddn.mil, com-priv@psi.com Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! In-Reply-To: Your message of Mon, 29 Oct 90 16:03:46 -0500. <9010292103.AA27879@s6.Morgan.COM> Date: Tue, 30 Oct 90 14:01:58 -0500 From: "Martin Lee Schoffstall" Jordan, Circa 1985 (half the lifetime of operational tcp/ip ago) a number of non-profit organizations and consortiums were put together to address the perceived needs, the included NYSERNet, SURANET, BARRNET, etc, they were started as non-profits for the reasons of that period. In the same period UUNET started. In 1990 PSINet fissioned off of NYSERNet, and it would appear ALTERNet fissioned off of UUNET, for a number of reasons. For PSINet they included: investment in infrastructure, tax issues including new IRS reporting and the concept of taxation on "unrelated business income" for a non-profit, and the concept of fair business practices, where a non-profit for many reasons (including taxation, but also liability) competes with commercial organizations unfairly. [This is why RPI pays no taxes on its physical plant or income, except on the portion that is related to its growing technology park] It has been rumored that a number of the mid-levels are discussing ways to turn their services into for-profit endeavors for possibly many of the reasons of above. But ironically we have a "back to the future" movement of ANS repeating what was done in 1985, hence the A in ANS "Advanced". But of course this is the story for 1990, we'll see how things evolve. Marty PS: There is a great ANS marketing article in the Link Letter (contact nsfnet-linkletter-request@merit.edu) front page, complete with a picture of "Uncle Al", children, (but no flag) supported by NSF Grant No. NCR 8720904 no less (at least according to the publication) PPS: I thought I'd cc com-priv on this. -------------- Christopher Raczka writes: I also think the "other side" of the story does need to be told and this much I do know... Sometime in September, Merit, IBM Corp, and MCI established Advanced Network and Services Inc. (ANS) ANS, a NOT FOR PROFIT organization, is to manage and operate the NSFNET backbone under subcontract to Merit Funny to see the NOT FOR PROFIT emphasis. Wasn't NYSERNET also started that way? /jordan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103007360000> Received: from pucc.PRINCETON.EDU by NIC.DDN.MIL with TCP; Tue, 30 Oct 90 09:10:30 PST Received: from MSU.BITNET by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 2360; Tue, 30 Oct 90 11:37:58 EST Received: by MSU (Mailer R2.03B) id 7295; Tue, 30 Oct 90 11:38:40 EST Date: Tuesday, 30 October 1990 11:36am ET To: tcp-ip@nic.ddn.mil From: "Bill.Simpson" <09998WAS%MSU@pucc.PRINCETON.EDU> Subject: Re: Internet/NSFnet to be run by IBM -- call to action! > Christopher Raczka writes: > > I also think the "other side" of the story does need to be told > and this much I do know... Sometime in September, Merit, IBM > Corp, and MCI established Advanced Network and Services Inc. > (ANS) ANS, a NOT FOR PROFIT organization, is to manage and > operate the NSFNET backbone under subcontract to Merit > > Funny to see the NOT FOR PROFIT emphasis. > > Wasn't NYSERNET also started that way? > > /jordan First, the new structure (as I understand it) is pretty strange: Merit holds the NSFnet grant --> ANS holds a sub-contract to manage the grant --> Merit was hired by ANS to operate the network Looks to me that ANS is a rather unneccessary intermediary! This is IBM's point of control. Second, note the incorporation of ANS. Merit is a Michigan academic non-profit consortium. MCI is also a Michigan company. But ANS is incorporated in New Jersey (near IBM). The new president was hired directly from IBM (a former VP there). As far as I can ascertain, ANS exists solely to pay this fellow's salary. Third, when I suggested a few months ago that NIS.NSF.NET be moved to to a more capable machine (because of problems accessing the RFCs stored there), I was informed that IBM wouldn't allow the use of non-IBM equipment in the NOC. It seems to me that IBM is already firmly in (political) control. Fourth, has anyone actually looked at the ANS incorporation charter? Is ANS *really* a non-profit? By what definition? How are the corporate directors selected? Fifth, I've heard of the NYSERnet/PSI debacle, but don't know the history. Could someone take the time to post a summary of events to this group? Sixth, I'll go read the com-pri archive at PSI.com, but believe this discussion is appropriate to this group, as the general network administration/questions base. Bill Simpson 09998was@msu.bitnet 09998was@ibm.cl.msu.edu [ANS is usually pronounced the same as the bodily orifice -- a particularly bad choice of acronym. Of course, ANSI was already taken....] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103008405000> Received: from sol.end.tufts.edu by NIC.DDN.MIL with TCP; Tue, 30 Oct 90 10:41:14 PST Return-Path: Received: by sol.end.tufts.edu (CAD-END.Tufts.MJS.900925); Tue, 30 Oct 90 13:40:50 EST; id AA04727; from Date: Tue, 30 Oct 90 13:40:50 EST From: "Michael J. Saletnik - Local Unix Wizard's Apprentice" Message-Id: <9010301840.AA04727@sol.end.tufts.edu> To: tcp-ip@nic.ddn.mil Subject: Programming question Hi. I've got a question for all the experienced TCP/IP programmers out there. I've been trying to find this in the manuals, but I can't anywhere. I'd greatly appreciate confirmation of my technique and answers to the random questions.. In any case: System: Sun 3/50,3/180 OS: SunOS 4.1 Given a bound and listening socket, can I use fcntl(socket, F_SETFL, FNDELAY); to cause it to be non-blocking, and that way when I call accept() I'll either get back a new socket for a new connection, or errno = EWOULDBLOCK And when do I make the fcntl() call? Given a newly connected socket from an accept(), do I use fcntl(socket, F_SETFL, FASYNC); to enable SIGIO signals, and fcntl(socket, F_SETOWN, getpid()); to point those signals at my process, and signal(SIGIO, handler); to establish my handler? What order should these be? Finally, if my signal handler is declared handler(sig, code, scp, addr) int sig, code; struct sigcontext *scp; char *addr; how can I find out which socket (or file descriptor) caused that signal? Thanks in advance, Michael J. Saletnik icarus@end.tufts.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103011213000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 30 Oct 90 04:11:15 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01203; Tue, 30 Oct 90 03:59:18 -0800 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 Oct 90 11:21:30 GMT From: eru!hagbard!sunic!mcsun!hp4nl!philapd!ssp18!aruit@bloom-beacon.mit.edu (A. de Ruiter) Organization: Philips Information Systems, Apeldoorn, The Netherlands Subject: Looking for X.25 network cards and NetBIOS/TCP/IP software Message-Id: <1144@ssp18.idca.tds.philips.nl> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Dear Netreaders, I am searching for X.25 network cards and NetBIOS software which can make use of these X.25 network cards. Our application runs at this moment on NetBIOS over TCP/IP via NI5210 in an ethernet network. We want, without adaptations in our application, to support beside ethernet also X.25, by changing the version of TCP/IP ( and NetBIOS ) and the network card. We do not support MCA and EISA, but only XT and AT bus in our 386 PCs. Please email me more information about X.25 network cards and NetBIOS and/ or TCP/IP software which support X.25 ( and ethernet ). Thank you in advance and kind regards. +----------------------------------------------------------------------------+ | |Philips Information Systems | | _ __ |Optical Filing Systems, BK-C2 | | /_| __ /_ _ __ __/_ /__) ./_ _ _|Anton de Ruiter | |/ |/ /(_ (_)/ / (_/(-' / \ (_//(_ (-'/ |Post Office Box 245 | | |7300 AE Apeldoorn, The Netherlands| | |-----------------------------------| | __ __ |Internet: aruit@idca.tds.philips.nl| | / )_ /_ ._ _ / /_ ./ .__ __ |UUCP : ..!mcsun!philapd!aruit | | (__//_)(_ /(_(_|(_ / /(_ // /(_/ |Phone : 31 55 433514 (Business)| | / _/ |Phone : 31 5486 18199 (Home) | | |Fax : 31 55 433488 | +----------------------------------------------------------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103014305500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 30 Oct 90 18:14:19 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21307; Tue, 30 Oct 90 18:05:25 -0800 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 Oct 90 14:30:55 GMT From: att!devildog!jrallen@ucbvax.Berkeley.EDU (Jon Allen) Organization: AT&T IMS - Piscataway, NJ Subject: Re: Looking for utility to monitor RIP packets Message-Id: <1635@devildog.att.com> References: <775@casbah.acns.nwu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <775@casbah.acns.nwu.edu> matt@acns.nwu.edu writes: >I am looking for a UNIX utility that will listen for all the RIP >packets on a network and display their contents. I am essentially >trying to duplicate the output of a cisco router with RIP debugging >turned on. The output looks something like: > >Received RIP update from xxx.xxx.xxx.xxx: > network yyy.yyy.yyy.yyy in n hops > network zzz.zzz.zzz.zzz in m hops > ... Actually, most 4.XX based TCP/IP implementations used on various flavors of UNIX have options to the 'routed' command to print out just the information you are talking about. All packets received by routed (and those sent out) are printed. I don't have the man page handy, but on System V I have used the -t or log option to output this information. This has proved to be a very useful debugging tool on networks with many routers exchaning info. -Jon jrallen@devildog.att.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010301830.AA08855@ucbvax.Berkeley.EDU] <1990103016175200> From: tmallory@BBN.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-ID: <9010301830.AA08855@ucbvax.Berkeley.EDU> Date: 30 Oct 90 16:17:52 GMT References: <60411@bbn.BBN.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 15 Posted: Tue Oct 30 17:17:52 1990 The IBM/NSFnet discussion has, for some reason or another, brought to mind the ATT divestiture boondoggle. I used to be able to get basic phone service for $4.50/month that allowed people to call me, and to make a few local calls in the bargain, and they threw in the phone rental too! The most similar service now is $14.46, and I have to buy and service my own phone. The inexpensive rate was apparently made possible by charging extra for long-distance service in order to subsidize universal access, but it seems to me that a lot of individuals benefitted, where now you have to be a business in order to save money. There's got to be a connection: at the very least it's not clear that allowing a single company to run the show will necessarily be bad. Tracy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103016333900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 29 Oct 90 21:26:05 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24680; Mon, 29 Oct 90 21:19:34 -0800 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 Oct 90 16:33:39 GMT From: comp.vuw.ac.nz!windy!srwmcln@uunet.uu.net Organization: DSIR, Wellington, New Zealand Subject: Re: Telnet echo negotiation question Message-Id: <18691.272dab64@windy.dsir.govt.nz> References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Many implementations of Telnet are broken in one way or another, often in the area of echo (or other option) negotiation. A common problen is that some refuse to allow, no remote/no local echo. Then there is the 8 bit binary situation...... Many implementations are just copies of other broken implementations, and so it goes on. Clive. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103018070600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 30 Oct 90 10:42:07 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA09175; Tue, 30 Oct 90 10:41:27 -0800 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 Oct 90 18:07:06 GMT From: usc!julius.cs.uiuc.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!midway!tartarus.uchicago.edu!faustus@ucsd.edu (Kurt Ackermann) Organization: University of Chicago Subject: cross-post on this topic Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil On the IBM-NSFNet discussion, cross-post to comp.org.eff.talk This group will have interesting insights and contributions to make as well, and it falls within their general scope of discussions. BTW, EFF is the Electronic Frontier Foundation, well worth looking into... :-) I told them to look in news.admin, etc. to get the conversation so far... Kurt Ackermann "Grey, dear friend, are all your theories; --Mephisto. in the golden tree of life is green!" Goethe's Faust ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103019084700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 31 Oct 90 08:28:04 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10706; Wed, 31 Oct 90 08:24:17 -0800 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 Oct 90 19:08:47 GMT From: mstan!jordan@uunet.uu.net (Jordan Hayes) Organization: Morgan Stanley, & Co., Inc. / New York City, NY Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: <2043@s6.Morgan.COM> References: <1990Oct29.205244.2051@supernet.haus.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Clay Luther writes: Since when was $2000/month cheap? Since when have you priced Internet access? PSI charges $60k/year for T1. I'm sure most of the other ones are similar. /jordan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9010301940.AA10654@ucbvax.Berkeley.EDU] <1990103019401600> From: 09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson") Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet/NSFnet to be run by IBM -- call to action! Message-ID: <9010301940.AA10654@ucbvax.Berkeley.EDU> Date: 30 Oct 90 19:40:16 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 51 Posted: Tue Oct 30 20:40:16 1990 X-Unparsable-Date: Tuesday, 30 October 1990 11:36am ET > Christopher Raczka writes: > > I also think the "other side" of the story does need to be told > and this much I do know... Sometime in September, Merit, IBM > Corp, and MCI established Advanced Network and Services Inc. > (ANS) ANS, a NOT FOR PROFIT organization, is to manage and > operate the NSFNET backbone under subcontract to Merit > > Funny to see the NOT FOR PROFIT emphasis. > > Wasn't NYSERNET also started that way? > > /jordan First, the new structure (as I understand it) is pretty strange: Merit holds the NSFnet grant --> ANS holds a sub-contract to manage the grant --> Merit was hired by ANS to operate the network Looks to me that ANS is a rather unneccessary intermediary! This is IBM's point of control. Second, note the incorporation of ANS. Merit is a Michigan academic non-profit consortium. MCI is also a Michigan company. But ANS is incorporated in New Jersey (near IBM). The new president was hired directly from IBM (a former VP there). As far as I can ascertain, ANS exists solely to pay this fellow's salary. Third, when I suggested a few months ago that NIS.NSF.NET be moved to to a more capable machine (because of problems accessing the RFCs stored there), I was informed that IBM wouldn't allow the use of non-IBM equipment in the NOC. It seems to me that IBM is already firmly in (political) control. Fourth, has anyone actually looked at the ANS incorporation charter? Is ANS *really* a non-profit? By what definition? How are the corporate directors selected? Fifth, I've heard of the NYSERnet/PSI debacle, but don't know the history. Could someone take the time to post a summary of events to this group? Sixth, I'll go read the com-pri archive at PSI.com, but believe this discussion is appropriate to this group, as the general network administration/questions base. Bill Simpson 09998was@msu.bitnet 09998was@ibm.cl.msu.edu [ANS is usually pronounced the same as the bodily orifice -- a particularly bad choice of acronym. Of course, ANSI was already taken....] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103022172900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 30 Oct 90 14:57:32 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16572; Tue, 30 Oct 90 14:56:53 -0800 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 Oct 90 22:17:29 GMT From: sdcc6!jclark@ucsd.edu (John Clark) Organization: University of California, San Diego Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: <13740@sdcc6.ucsd.edu> References: <60411@bbn.BBN.COM>, <9010301830.AA08855@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010301830.AA08855@ucbvax.Berkeley.EDU> tmallory@BBN.COM writes: + +There's got to be a connection: at the very least it's not clear that allowing +a single company to run the show will necessarily be bad. May Teddy Roosevelt roll over in his grave and shoot a bull moose! The only reason it was so 'good' is because ATT was so 'restricted' by the government. Don't think for a minute that ATT wouldn't have raised the price to what the market could bear if it had had the chance. -- John Clark jclark@ucsd.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103023050100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 30 Oct 90 20:28:10 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24126; Tue, 30 Oct 90 20:20:32 -0800 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 Oct 90 23:05:01 GMT From: usc!zaphod.mps.ohio-state.edu!mips!prls!pyramid!csg@ucsd.edu (Carl S. Gutekunst) Organization: Pyramid Technology Corp., Mountain View, CA Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: <132364@pyramid.pyramid.com> References: <1990Oct28.220432.521@ddsw1.MCS.COM>, <132136@pyramid.pyramid.com>, <1990Oct29.225231.17042@uu.psi.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >I don't think that eveyone needs to scrap the NSFNet right now, especially >since it is free. Beg yer pardon? That's for Universities. Doesn't NSFNet charge something like $5000/month just in fees, not including network equipment costs? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103023115700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 30 Oct 90 20:28:26 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24177; Tue, 30 Oct 90 20:21:28 -0800 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 Oct 90 23:11:57 GMT From: voder!pyramid!csg@ucbvax.Berkeley.EDU (Carl S. Gutekunst) Organization: Pyramid Technology Corp., Mountain View, CA Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: <132366@pyramid.pyramid.com> References: <1990Oct28.220432.521@ddsw1.MCS.COM>, <132136@pyramid.pyramid.com>, <1990Oct29.205244.2051@supernet.haus.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >Since when was $2000/month cheap? We were talking about NFSNet. Your "common man" can't connect to it at all. If you're talking about 1.544Mbps worldwide TCP/IP connections, with routing, nameservice, and network administration all done for you, $2000 per month is very cheap. And the price will continue to drop. On-the-order-of $100 per month Internet access is out there, too. Isn't that what PSI is doing? But you aren't going to support a supercomputer or several hundred sessions off that. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103100330000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 30 Oct 90 14:00:32 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA14802; Tue, 30 Oct 90 13:55:57 -0800 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: 31 Oct 90 00:33:00 GMT From: usc!julius.cs.uiuc.edu!rpi!clarkson!news.clarkson.edu!nelson@ucsd.edu (Russ Nelson) Organization: Clarkson University, Potsdam NY Subject: Re: Packet Driver for PRONET Message-Id: References: <9010300553.AA25380@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010300553.AA25380@ucbvax.Berkeley.EDU> 702WFG@SCRVMSYS.BITNET (bill gunshannon) writes: Does anyone know the whereabouts of a packet driver that would let me run TCPIP over PRONET with Proteon's cards?? As far as I know, there is no packet driver for any Proteon cards, nor is anyone working on one. -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) FAX 315-268-7600 It's better to get mugged than to live a life of fear -- Freeman Dyson I joined the League for Programming Freedom, and I hope you'll join too. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103101295900> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Wed, 31 Oct 90 09:29:50 PST Received: from braden.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Wed, 31 Oct 90 09:30:03 -0800 Date: Wed, 31 Oct 90 09:29:59 PST From: braden@venera.isi.edu Posted-Date: Wed, 31 Oct 90 09:29:59 PST Message-Id: <9010311729.AA07194@braden.isi.edu> Received: by braden.isi.edu (4.1/4.0.3-4) id ; Wed, 31 Oct 90 09:29:59 PST To: tcp-ip@nic.ddn.mil Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! I would like to suggest that IBM-bashing, no matter how enjoyable a pastime for some, is not an appropriate use of this mailing list. Besides, it is very BORING. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103102085300> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Wed, 31 Oct 90 10:08:43 PST Received: from braden.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Wed, 31 Oct 90 10:08:59 -0800 Date: Wed, 31 Oct 90 10:08:53 PST From: braden@venera.isi.edu Posted-Date: Wed, 31 Oct 90 10:08:53 PST Message-Id: <9010311808.AA07256@braden.isi.edu> Received: by braden.isi.edu (4.1/4.0.3-4) id ; Wed, 31 Oct 90 10:08:53 PST To: clynn@bbn.com, jbvb@ftp.com Subject: Re: Reliable Datagram ??? Protocols Cc: tcp-ip@nic.ddn.mil You're right: RECEIVE calls are supposed to be queued until the connection reaches ESTABLISHED (RFC 793, pg 58). The discussion of OPEN, SEND and RECEIVE in that section seems somewhat out of line with the requirement elsewhere in the RFC that TCPs accept data with the initial SYN, because it appears that the API specified in section 3.9 can't generate it (SENDs are queued until the connection reaches ESTABLISHED as well). I will raise this as an issue with the HR WG. My own initial feeling is that the API's restriction is unnecessary, and could be relaxed at considerable benefit to the Internet... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 James, I believe that the API defined in RFC-793 was intended to describe the MINIMUM set of capabilities required of an implementation; in fact, there are weasel-words about that in the RFC. Thus, it was not intended to be a "restriction"; an implementation could go beyond it, to include for example, a call: OPENandSEND(...). I also believe, however, that the detailed protocol description in RFC-793 is inconsistent in a number of little ways with the 5-packet minimum request-response exchange that TCP could in principle provide: 1. SYN, req-data, FIN -----> 2. <--------- SYN, ACK 3. ACK --------> (deliver data to application) 4. <--------- ACK, rep-data, FIN 5. ACK --------> There are problems both in the state diagram and in the event processing rules. Although some of the early research TCP's could handle this 5-packet exchange, the issue did not get a lot of attention when the DoD put the heat on the research group to tie down the TCP spec. Maybe there is a job here for Host Requirements Man (leaps tall buildings at a single bound, etc). Pardon me while I wax philosphical for a moment. The early TCPs were all designed to implement "what the protocol meant" (as Charlie Lynn can attest). The words in RFC-793 were written later, and getting them exactly right was (and is!) HARD. Witness the Milspec spectacle. Implementors are still advised to implement what the protocol means, not what the spec says. It is arguably a defect of TCP as a protocol (and an advantage of TP4?) that TCP is very subtle, and therefore it is complex and difficult to describe in detail. Writing an efficient and fully correct TCP ab initio is still a great programming challenges, I believe (as I think you will agree, James!) I wonder of there are ANY fully correct implementations of the (entire) TCP protocol in the world today? Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103102515900> Received: from ftp.com by NIC.DDN.MIL with TCP; Wed, 31 Oct 90 07:11:38 PST Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA29259; Wed, 31 Oct 90 11:11:59 -0500 Date: Wed, 31 Oct 90 11:11:59 -0500 Message-Id: <9010311611.AA29259@ftp.com> To: Charles Lynn Subject: Re: Reliable Datagram ??? Protocols From: jbvb@ftp.com (James B. Van Bokkelen) Reply-To: jbvb@ftp.com Cc: tcp-ip@nic.ddn.mil, Phil Karn Sender: jbvb@ftp.com Repository: babyoil.ftp.com Originating-Client: plug.ftp.com From: Charles Lynn Doesn't TCP require the connection to be in the ESTABLISHED state before it is permitted to deliver data to the application? If so, I think B cannot see the data until it gets the ACK of its SYN from A, thus the response from B cannot be includes with B's SYN ACK. You're right: RECEIVE calls are supposed to be queued until the connection reaches ESTABLISHED (RFC 793, pg 58). The discussion of OPEN, SEND and RECEIVE in that section seems somewhat out of line with the requirement elsewhere in the RFC that TCPs accept data with the initial SYN, because it appears that the API specified in section 3.9 can't generate it (SENDs are queued until the connection reaches ESTABLISHED as well). I will raise this as an issue with the HR WG. My own initial feeling is that the API's restriction is unnecessary, and could be relaxed at considerable benefit to the Internet... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103102574300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 30 Oct 90 19:13:21 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22748; Tue, 30 Oct 90 19:13:23 -0800 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: 31 Oct 90 02:57:43 GMT From: swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!uhccux!okumura@ucsd.edu (Chad Okumura) Organization: University of Hawaii Subject: HELP ! ! ! ! ! Message-Id: <10090@uhccux.uhcc.Hawaii.Edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Can anyone out there tell me where I can find a copy of 'lharc' ??? or better yet...send me a copy??? I need this file in order to look at the gif files I've just gotten. Also, how do I ftp to SIMTEL20.arpa??? I have tried the command: 'ftp SIMTEL20.arpa', but this doesn't seem to work....Thanks in advance... --chad University of Hawaii Computing Center ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103104384900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 31 Oct 90 02:30:16 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04182; Wed, 31 Oct 90 02:21:50 -0800 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: 31 Oct 90 04:38:49 GMT From: usc!samsung!emory!stiatl!srchtec!mra@apple.com (Michael Almond) Organization: search technology, inc. Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: <291@srchtec.UUCP> References: <1990Oct28.220432.521@ddsw1.MCS.COM>, <132136@pyramid.pyramid.com>, <1990Oct29.205244.2051@supernet.haus.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Oct29.205244.2051@supernet.haus.com> cluther@supernet.haus.com (Clay Luther) writes: >csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: > >>and 64K DDS lines are ***cheap*** these days, so cheap that UUNet can build >>a truly commercial TCP/IP service, give excellent service, and charge less >>than $2000/month for it. >Internet will not be cheap until it drops to say, $100/month, or less. Well I don't know when the price will drop to $100/month, but you can get Internet access at $250/month, which isn't bad. We here at Search are planning to join the Internet through PSINet. They charge $250/month for dialup SLIP, I think eventually they'll have ISO once it is stable. With a NetBlazer at your sight, it is almost as good as a dedicated line connection. As time goes by the prices of the hardware will drop an maybe we'll reach the $100/month mark. --- Michael R. Almond mra@srchtec.uucp (registered) search technology, inc. emory!stiatl!srchtec!mra Atlanta, Georgia (404) 441-1457 (office) .'.'.'.'.'.'.'.'.'.'.'.'.'. Georgia Tech Alumnus .'.'.'.'.'.'.'.'.'.'.'.'.'.'.'. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103104390700> Received: from rand.org by NIC.DDN.MIL with TCP; Wed, 31 Oct 90 13:02:33 PST Received: from condor.rand.org by rand.org; Wed, 31 Oct 90 12:39:16 -0800 Received: from localhost by condor.rand.org; Wed, 31 Oct 90 12:39:09 PST Message-Id: <9010312039.AA18204@condor.rand.org> To: mstan!jordan@uunet.uu.net (Jordan Hayes) Cc: tcp-ip@nic.ddn.mil, guyton%condor@rand.org Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Reply-To: guyton@rand.org Date: Wed, 31 Oct 90 12:39:07 PST From: guyton%condor@rand.org > PSI charges $60k/year for T1. > > I'm sure most of the other ones are similar. Fyi, our Los Nettos bill (T1) is $60k for 1st year, about $30k per year after that. [initial estimates, we've been on for a couple years now and I've not gone back to check to see how accurate the estimates turned out] -- Jim Guyton guyton@Rand.org p.s. Los Nettos := LA area region, gateway'd to Cerfnet. No NSF funding ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103105234900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 30 Oct 90 23:57:31 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01301; Tue, 30 Oct 90 23:51:53 -0800 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: 31 Oct 90 05:23:49 GMT From: att!emory!rsiatl!jgd@ucbvax.Berkeley.EDU (John G. DeArmond) Organization: Radiation Systems, Inc. (a thinktank, motorcycle, car and gun works facility) Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: <4562@rsiatl.UUCP> References: <1990Oct28.220432.521@ddsw1.MCS.COM>, <16121@drilex.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil dricejb@drilex.UUCP (Craig Jackson drilex1) writes: >It would seem to me, in the absence of *much* more detailed information, >that this is just so much conspiracy theory. Well Senate Bill 1976 may be a conspiracy but is a damn threatening one. Read my previous post to see how theory is reduced to practice. >Assuming that IBM has made such a proposal, why should they spend money >to turn something working in to something that doesn't work? You ever used IBM products? If you have, how can you ask that question? >they're actually trying to make a buck. Quite a few, in fact. Precicely. Which has NOTHING to do with our being able to actually USE what they provide for us. Witness, the PC Jr. Or any Series/1. Etc. >The principal reason why IBM would volunteer to run the NFSNet, etc would >be to enhance their standing in the academic technical community. No, according to IBM's news release, they will be in it along with Compu$erve and McGraw-Hill and others STRICTLY to make a buck. >paid for like roads. Let's hope nobody gets to send their packets over >the Mianus River bridge.> No, I hope the net turns into something like the Interstate system here in Atlanta. Here, the goverment (more or less) builds enough roads to keep up with growth. I can hit I-75 (a 10 lane interstate), get onto the perimeter I-285 (another 10 lane interstate) and be 30 miles across town in not much more than 30 minutes. Yes, it does congest during times of high usage but it is also one of the main fuelers of growth in the metro area. A properly designed and managed FREE data highway could do the same thing on a national basis. John -- John De Armond, WD4OQC | "The truly ignorant in our society are those people Radiation Systems, Inc. | who would throw away the parts of the Constitution Atlanta, Ga | they find inconvenient." -me Defend the 2nd {emory,uunet}!rsiatl!jgd| with the same fervor as you do the 1st. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103108130400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 31 Oct 90 00:29:15 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02517; Wed, 31 Oct 90 00:26:49 -0800 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: 31 Oct 90 08:13:04 GMT From: eru!hagbard!sunic!lth.se!newsuser@bloom-beacon.mit.edu (Ricard Wolf) Organization: Lund Institute of Technology, Sweden Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: <1990Oct31.081304.14531@lth.se> References: <1990Oct28.220432.521@ddsw1.MCS.COM>, <16121@drilex.UUCP>, <4562@rsiatl.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <4562@rsiatl.UUCP> jgd@rsiatl.UUCP (John G. DeArmond) writes: ... >>Assuming that IBM has made such a proposal, why should they spend money >>to turn something working in to something that doesn't work? > >You ever used IBM products? If you have, how can you ask that question? :-) :-) :-) >>they're actually trying to make a buck. Quite a few, in fact. > >Precicely. Which has NOTHING to do with our being able to actually >USE what they provide for us. Witness, the PC Jr. Or any Series/1. >Etc. > >>The principal reason why IBM would volunteer to run the NFSNet, etc would >>be to enhance their standing in the academic technical community. > >No, according to IBM's news release, they will be in it along with >Compu$erve and McGraw-Hill and others STRICTLY to make a buck. EXACTLY!!!!! Please remember that IBM is not interested in making anything else but money! If the machine works, it's an added bonus, but not really part of the specification :-) :-). If they could have made money marketing peas they would have done so ("oh, you want a container to transport the peas home in? well that is an optional extra"). -- Ricard Wolf +--------------------------+-------------------------------------+ | Ricard Wolf | Lund Institute of Technology | | email: e85rw@efd.lth.se | If you can't buy 'em - build 'em !! | +--------------------------+-------------------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103111491800> Received: from note.nsf.gov by NIC.DDN.MIL with TCP; Wed, 31 Oct 90 16:31:29 PST Received: from z.nsf.gov by Note.NSF.GOV id aa00784; 31 Oct 90 16:47 EST Received: by z.nsf.gov (4.0/SMI-4.0) id AA07742; Wed, 31 Oct 90 16:49:19 EST Message-Id: <9010312149.AA07742@z.nsf.gov> From: "Michael H. Morse" Date: Wed, 31 Oct 1990 16:49:18 EST X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: tcp-ip@NSF.GOV Subject: Problem with Xmodem and 3Com terminal server I am having a problem getting Xmodem to work between a Sun workstation and a PC running a terminal emulator. The PC uses a modem and a dial-up line to communicate, but it cannot get to the workstation directly because the workstation has no serial ports. Instead, the PC logs on to some other host, and then uses telnet to get to the workstation. We have a 3Com terminal server that is normally used in this situation, but we've found that Xmodem does not work (the PC nacks everything it gets) in this configuration. However, if the PC logs onto one of our Ultrix hosts, and in effect uses it for a terminal server to telnet to the workstation, Xmodem works fine. Subsequent tests have absolved the terminal emulator (on the PC) and the xmodem program on the workstation, leaving suspicion around the telnet implementation on the terminal server. I suspect this has something to do with parity, since the ASCII characters transmitted by Xmodem, and received by the PC are identical. Has anybody run into a similar problem? Any information on how telnet reacts when raw mode is selected would be appreciated. Thanks in advance. --Mike -- Michael Morse Internet: mmorse@note.nsf.gov National Science Foundation BITNET: mmorse@NSF Telephone: (202) 357-7659 FAX: (202) 357-7663 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103111504500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 31 Oct 90 13:13:39 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA18442; Wed, 31 Oct 90 13:02:16 -0800 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: 31 Oct 90 11:50:45 GMT From: mcsun!inria!bull.bull.fr!cediag!Patrick.Hayes@uunet.uu.net (Patrick Hayes) Organization: Cediag Bull S.A., Louveciennes, France Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: References: <9010290338.AA14240@decpa.pa.dec.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010290338.AA14240@decpa.pa.dec.com> chris@ecdnt5.enet.dec.com (christopher raczka) writes: >Sometime in September, Merit, IBM Corp, and MCI established Advanced >Network and Services Inc. (ANS) > >ANS, a NOT FOR PROFIT organization, is to manage and operate the NSFNET >backbone under subcontract to Merit Shades of D.D. Harriman and "The Man Who Sold The Moon"... Pat #include -- +-------------------------------+-----------------------------------------+ | 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---- <1990103113540600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 31 Oct 90 06:57:58 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08637; Wed, 31 Oct 90 06:48:34 -0800 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: 31 Oct 90 13:54:06 GMT From: usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!scotty.dccs.upenn.edu!kehoe@ucsd.edu (Brendan Kehoe) Organization: University of Pennsylvania Subject: Re: HELP ! ! ! ! ! Message-Id: <32034@netnews.upenn.edu> References: <10090@uhccux.uhcc.Hawaii.Edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In <10090@uhccux.uhcc.Hawaii.Edu>, okumura@uhccux.uhcc.Hawaii.Edu writes: > Can anyone out there tell me where I can find a copy of >'lharc' ??? or better yet...send me a copy??? Redirected to comp.sys.ibm.pc. Brendan Kehoe | Soon: brendan@cs.widener.edu [ Well, in 1990 I hope. ] For now: kehoe@scotty.dccs.upenn.edu | Also: brendan.kehoe@cyber.widener.edu "It's a distinctly non-trivial task to decompile a stripped, encrypted binary into something that can be understood." - Keith Bostic, on the Internet worm ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103115200400> Received: from note.nsf.gov by NIC.DDN.MIL with TCP; Wed, 31 Oct 90 23:26:15 PST Received: from mathom.cisco.com by Note.NSF.GOV id aa13201; 1 Nov 90 2:20 EST Date: Wed 31 Oct 90 23:20:04-PST From: William Chops Westfield Subject: Re: Problem with Xmodem and 3Com terminal server To: mmorse@z.nsf.gov cc: tcp-ip@NSF.GOV In-Reply-To: <9010312149.AA07742@z.nsf.gov> Message-ID: <12634372337.2.BILLW@mathom.cisco.com> Even when transferring text files, XMODEM needs a clear 8-bit path to accomadate its block counts and checksum. By definition, telnet is a 7 bit protocol, and you must negotiate "binary" mode to get an 8-bit path. The terminal server may be refusing binary mode negotiations, may just do binary incorrectly, or may just need configured differently. Also, some telnet implementations ignore the "7-bit" definition, and routinely send 8 bit data anyway. This is useful, but means that a telnet terminal server strictly adhering to the standard might not work as well as one with a more flexible interpretation. The Hosts Requirement document was carefully worded to allow 8-bit transmission, as long as you were doing actual "parity". Bill Westfield cisco Systems. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103117325800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 31 Oct 90 11:00:22 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA14774; Wed, 31 Oct 90 10:58:23 -0800 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: 31 Oct 90 17:32:58 GMT From: swrinde!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!watserv1!sunee!erick@ucsd.edu (Erick Engelke) Organization: University of Waterloo Subject: Re: Packet Driver for PRONET Message-Id: <1990Oct31.173258.26232@sunee.waterloo.edu> References: <9010301647.AA01687@ftp.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010301647.AA01687@ftp.com> jbvb@ftp.com writes: >> >> Does anyone know the whereabouts of a packet driver that would let me run >> TCPIP over PRONET with Proteon's cards?? >> >To my knowlege, there have never been any Class 2 (ProNET-10) packet drivers. >Given that at least PC-IP and NCSA support the basic packet formats, it >wouldn't be hard to do one, but you'd probably want Netware support too... > We run a big proNET 10 system with about 20 interconnected token rings. We found the most useful solution was to make a packet driver which fully emulates the Ethernet card. Other than multicasts, this is actually quite easy. This allows us to use PC-IP, NCSA, etc. in the mode they were written and tested in-Ethernet mode. Unfortunately, our driver must also handle our local routing, network card demultiplexing, etc., so it is not particularly useful for you. If you are interested in doing the work yourself, I could mail you some tips. Erick Network Systems Manager Faculty of Engineering University of Waterloo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [344.272f12e2@cai.com] <1990103118073000> From: manager@cai.com Newsgroups: comp.os.vms,comp.protocols.tcp-ip Subject: Re: Cheap (or Free) TCP-IP for VMS Message-ID: <344.272f12e2@cai.com> Date: 31 Oct 90 18:07:30 GMT References: <1990Oct29.182022.2227@terminator.cc.umich.edu> Organization: Computer Associates International Lines: 57 Posted: Wed Oct 31 19:07:30 1990 In article <1990Oct29.182022.2227@terminator.cc.umich.edu>, baw@terminator.cc.umich.edu (Brian Wolfe) writes: > I'm trying to get a few departments of my company to get together to > help finance an Internet connection and unfortunately not all of them > have money to pay for the connection and the TCP-IP software for VMS. > (One of the machines we need it for is a Vax 6440, soon to be traded in > for a Vax 9000) > > Is there any free or very cheap TCP-IP software for VMS available? > Telnet and FTP would be the only applications they need. > > Brian Wolfe > Rush Medical Center > Chicago, IL > bwolfe@rpslmc.edu > (312)-942-5781 I highly recommend Carnegie Mellon Universities CMU-TEK TCP/IP. The following information is from the latest newsletter: Kdren Heilman (412)268-5896 KH55@andrew.cmu.edu Carnegie Mellon University 4910 Forbes Avenue UCC 124 Pittsburgh, PA 15213 $125 for the license add $25 for TK50 add $25 for Purchase Order add $50 for outside US Requests to get on the mailing list go to 'cmu-tek-tcp-request@andrew.cmu.edu'. The mailing list is 'cmu-tek-tcp@andrew.cmu.edu'. To preempt some common questions: 1. It doesn't do NFS. 2. It can do TELNET, FTP, Domain Name Service, LPR 3. It works with (at least) VMS 4.7 through 5.4. 4. Most of it is in Bliss, sources are included. 5. The pre-compiled system provides for a DEC Ethernet driver. 6. You can build an IP-over-DECnet driver, a SLIP driver, and and IP-over-X.25 driver, but you may experience great anguish in getting them to work in your environment. 7. There is a DECwindows transport for CMU-TEK TCP/IP, so your favorite Unix box can be an X client to your VAXstation. I have absolutely no affiliation with CMU. I am providing this information of my own free will in hopes of improving the quality of your network life. Flames to /dev/null, NLA0:, or whatever passes for your local bitbucket. -- Todd Aven Manager, Mid-range Computer Services Computer Associates International Internet: manager@cai.com UUCP: uupsi!usgcdh!manager ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103118151300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 31 Oct 90 13:29:10 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19461; Wed, 31 Oct 90 13:28:37 -0800 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: 31 Oct 90 18:15:13 GMT From: intercon!news@uunet.uu.net (Kurt Baumann) Organization: InterCon Systems Corporation, Herndon, VA Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: <272F14B1.A50@intercon.com> References: <16121@drilex.UUCP>, <4562@rsiatl.UUCP>, <1990Oct31.081304.14531@lth.se> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Oct31.081304.14531@lth.se>, e85rw@efd.lth.se (Ricard Wolf) writes: > EXACTLY!!!!! Please remember that IBM is not interested in making > anything else but money! If the machine works, it's an added bonus, but not > really part of the specification :-) :-). If they could have made money > marketing peas they would have done so ("oh, you want a container to transport > the peas home in? well that is an optional extra"). The government would be much less responsive. At least if you needed a container from IBM or whomever you could get one. With the government running things you might get a container if you could prove that everyone needed one and then only after the peas had spoilt. Things work well because we have a org that is not keeping a strick close eye on things. With the budget in the shambles that it is in, do you really think that the US government is not going to take a much more active role in the who/what/when/where of the network? Is this really what you all want? -- 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---- <1990103118330800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 31 Oct 90 16:16:19 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24258; Wed, 31 Oct 90 16:04:39 -0800 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: 31 Oct 90 18:33:08 GMT From: bywater!dagobah!mis@uunet.uu.net (Mark Seiden) Organization: Seiden and Associates, Inc, Stamford, CT Subject: Re: Internet/NSFnet to be run by IBM -- call to action! Message-Id: <3615@dagobah.UUCP> References: <9010301940.AA10654@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil as usual, several of the important little details seem to be wrong... 09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson") writes: >[...] note the incorporation of ANS. Merit is a Michigan academic >non-profit consortium. MCI is also a Michigan company. But ANS is >incorporated in New Jersey (near IBM). The new president was hired >directly from IBM (a former VP there). As far as I can ascertain, new jersey is near ibm, in new york? it's also near washington dc... what relevance does state of incorporation have other than limiting director's liability in the case of a nonprofit? this is a non-issue. weis' most interesting job was at ibm research where he directed the computing systems department (i.e. the comp center and research internet as well as tcp and nsfnet development)... by the way, he retired after 30 years at ibm. >ANS exists solely to pay this fellow's salary. i suspect you haven't tried too hard to "ascertain" that there seem to be several other employees. the ex-ibm corporate officers reportedly are precluded from any "right of return" to ibm should something go awry. they do seem to be hiring, or at least looking. >Third, when I suggested a few months ago that NIS.NSF.NET be moved to >to a more capable machine (because of problems accessing the RFCs >stored there), I was informed that IBM wouldn't allow the use of >non-IBM equipment in the NOC. It seems to me that IBM is already >firmly in (political) control. i agree that a good test of independence is how equipment is chosen. i believe ANS was founded partly because of frustration experienced in getting a difficult job done within the confines of large organizational politics. the problem you cite (if accurately) would be a perfect example of how hard such things would be to do this within IBM (or many other large organizations) compared with as an independent entity. >Fourth, has anyone actually looked at the ANS incorporation charter? >Is ANS *really* a non-profit? By what definition? How are the >corporate directors selected? yeah, i've heard it really is, though i haven't looked. nonprofit is an IRS term. i'm not sure what x value is (for 501c(x) of the tax code). looked to me like the directors were a pretty good distribution of folks. >[ANS is usually pronounced the same as the bodily orifice -- a particularly >bad choice of acronym. Of course, ANSI was already taken....] thanks for your delicacy in pointing out this important issue to all of us... (now go away...) i usually pronounce it like the Brooklyn department store: A&S. >>dricejb@drilex.UUCP (Craig Jackson drilex1) writes: >>they're actually trying to make a buck. Quite a few, in fact. >john dearmond replies: >Precicely. Which has NOTHING to do with our being able to actually >USE what they provide for us. Witness, the PC Jr. Or any Series/1. >Etc. (what an idiotic argument.) yes, companies make mistakes sometimes, and in retrospect it's easy to point them out. these people are supposed to be independent of ibm. >>The principal reason why IBM would volunteer to run the NFSNet, etc would >>be to enhance their standing in the academic technical community. >john dearmond replies: >No, according to IBM's news release, they will be in it along with >Compu$erve and McGraw-Hill and others STRICTLY to make a buck. well, i'll bet john is the usual loose cannon on the facts. what did that quote say EXACTLY? it isn't legal for IBM to derive special benefit from the *nonprofit* status of ANS. in particular, taking money out of ANS isn't possible. maybe the partners are thinking they'll make more money in the longterm if there's a better internet. there are lots of products and services that can't be provided without a better internet. so what? some others of us will doubtless benefit as well... (well, at least he didn't call anybody a slut this time)... ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990103118445100> Received: from A.ISI.EDU by NIC.DDN.MIL with TCP; Wed, 31 Oct 90 23:38:28 PST Date: Wed 31 Oct 90 23:44:51-EST From: Dan Lynch Subject: SMDS Interest Group Meeting To: tcp-ip@nic.ddn.mil, smds@nri.reston.va.us, frame-relay@nri.reston.va.us cc: lynch@A.ISI.EDU, ekearney@interop.com Message-ID: <12634344080.27.LYNCH@A.ISI.EDU> There will be a one day meeting on Nov 15 at the Red Lion Inn in San Jose, CA open to anyone interested in potentially forming a working group to further the avaiability of SMDS service both in the US and internationally. The intention is to have the "interest group" be composed of users, service providers (local and long distance carriers), computer manufacturers and router/switch manufacturers. Essentially we all have a stake in seeing to it that such an "offering of service" is defined and provided in a way that is useful for both buyers and sellers. If you are interested in coming to this meeting, please contact Elaine Kearney at 415-941-3399 or as ekearney@interop.com for further meeting details. We have set aside a room for 200 for this meeting and if that is not enough we need to know soon. Dan ------- ----MESSAGE-END----