----MESSAGE-BEGIN---- [8707041716.AA08738@ucbvax.Berkeley.EDU] <1987070112033700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CRB@NIHCUDEC.BITNET ("C. BACON") Newsgroups: comp.protocols.tcp-ip Subject: DECnet-TCP/IP gateway? Message-ID: <8707041716.AA08738@ucbvax.Berkeley.EDU> Date: Wed, 1-Jul-87 16:03:37 EDT Article-I.D.: ucbvax.8707041716.AA08738 Posted: Wed Jul 1 16:03:37 1987 Date-Received: Sat, 4-Jul-87 20:21:11 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Looking for gateway software, preferably layered atop Wollongong, for a MicroVax. In and out via shared DEQNA. Mail is the biggest need. FTP strongly desired. Telnet desired, but let's be realistic. Charles Bacon, CRB@NIHCUDEC (bitnet) (OK to send braces $ and caret X now) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707041845.AA09556@ucbvax.Berkeley.EDU] <1987070112033701> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CRB@NIHCUDEC.BITNET ("C. BACON") Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP for PC/IX? Message-ID: <8707041845.AA09556@ucbvax.Berkeley.EDU> Date: Wed, 1-Jul-87 16:03:37 EDT Article-I.D.: ucbvax.8707041845.AA09556 Posted: Wed Jul 1 16:03:37 1987 Date-Received: Sat, 4-Jul-87 20:32:44 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 PC/IP has opened up the DOS side of my aging XT marvelously. But PC/IX languishes for the moment. Does anyone know of a port of PC/IP or other TCP/IP for PC/IX? Free preferred, of course. [Usual disclaimer: I am a satisfied customer of free software, etc.] Chuck Bacon, CRB@NIHCUDEC (bitnet) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987070112033702> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Thu 2 Jul 87 12:07:14-PDT Received: from NIHCUDEC.BITNET by wiscvm.wisc.edu ; Wed, 01 Jul 87 15:11:41 CDT To: CC: From: "C. BACON" Date: Wed, 01 Jul 87 16:03:37 EDT Subject: DECnet-TCP/IP gateway? Looking for gateway software, preferably layered atop Wollongong, for a MicroVax. In and out via shared DEQNA. Mail is the biggest need. FTP strongly desired. Telnet desired, but let's be realistic. Charles Bacon, CRB@NIHCUDEC (bitnet) (OK to send braces $ and caret X now) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987070112033703> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Thu 2 Jul 87 12:09:14-PDT Received: from NIHCUDEC.BITNET by wiscvm.wisc.edu ; Wed, 01 Jul 87 15:11:51 CDT To: CC: From: "C. BACON" Date: Wed, 01 Jul 87 16:03:37 EDT Subject: TCP/IP for PC/IX? PC/IP has opened up the DOS side of my aging XT marvelously. But PC/IX languishes for the moment. Does anyone know of a port of PC/IP or other TCP/IP for PC/IX? Free preferred, of course. [Usual disclaimer: I am a satisfied customer of free software, etc.] Chuck Bacon, CRB@NIHCUDEC (bitnet) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987070119131900> Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Fri 3 Jul 87 05:44:51-PDT Received: from ucl-cs-pyr1 by nss.Cs.Ucl.AC.UK via Ethernet with SMTP id aa09769; 1 Jul 87 17:37 BST To: tcp-ip@sri-nic.arpa Subject: Asyncio on Sockets Date: Wed, 01 Jul 87 17:33:19 +0100 From: Jon Crowcroft I know this is a Unix question and not really appropriate here, but Berkeley and Sun people seem to read this list a lot. Has anyone found problems setting async io on a RAW IP socket? Under 3.2 on a Sun, it just doesn't seem to work; at least I never get a SIGIO even when I see packets (using a net wathcer) arriving at the machine. The manual pages and tutorials are somewhat thin in this area. Also, when using asyncio on a UDP socket, the process doesn't get a SIGIO unless it has had another signal first. Jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987070205133300> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Fri 3 Jul 87 02:38:24-PDT To: tcp-ip@SRI-NIC.ARPA cc: kirschen%multimax.arpa@CCV.BBN.COM Subject: connection establish timeout query Date: Thu, 02 Jul 87 11:53:33 -0400 From: Mike Brescia I would interpret this question as "What should the open timeout be for telnet, ftp, and mail user and server programs?" What sort of numbers are used in the software? mike ---- forwarded message ---- Received: by multimax.ARPA (4.12/25-eef) id AA02553; Wed, 1 Jul 87 09:02:23 edt Date: Wed, 1 Jul 87 09:02:23 edt From: David Kirschen Message-Id: <8707011302.AA02553@multimax.ARPA> Subject: Arpanet Timeouts Hi - Could you tell me if there is a way to determine if we are seeing a reasonable number of connection timeouts over the Arpanet? We get lots of connections failing, for various applications (mail, ftp, telnet). We'd like to know what the commonly used timeout constant is (i.e., how long should it take when establishing a connection before the initiator just gives up?). Thanks !! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707022145.AA16150@beno.CSS.GOV] <1987070213452300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mo@SEISMO.CSS.GOV (Mike O'Dell) Newsgroups: comp.protocols.tcp-ip Subject: TCP-IP for SCO Xenix 2.2 on AT's and 386's Message-ID: <8707022145.AA16150@beno.CSS.GOV> Date: Thu, 2-Jul-87 17:45:23 EDT Article-I.D.: beno.8707022145.AA16150 Posted: Thu Jul 2 17:45:23 1987 Date-Received: Tue, 7-Jul-87 01:30:21 EDT Sender: usenet@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 We have seen the Micom product. Anybody have any comments about it, and has anybody seen anything else which would work in this setting. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707030140.AA19759@orville.arpa] <1987070217404500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lekash@ORVILLE.ARPA (John Lekashman) Newsgroups: comp.protocols.tcp-ip Subject: Re: NSC HyperchannelB - Ethernet TCP/IP gateway Message-ID: <8707030140.AA19759@orville.arpa> Date: Thu, 2-Jul-87 21:40:45 EDT Article-I.D.: orville.8707030140.AA19759 Posted: Thu Jul 2 21:40:45 1987 Date-Received: Sat, 4-Jul-87 20:48:18 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 36 hi. There are things that will move IP packets between hyperchannels and other networks. vaxes running bsd. suns. Various vendors have mentioned the idea of building it into their gatways. Most that I have seen operate on hyperchannel A, the 50 mbit version. Porting to hyperchannel B should not be that hard. We just don't have any, because ethernets are so much cheaper. There is a spec from NSC on how to encapsulate IP over hyperchannel. It will likely occur as an RFC one day soon. The distribution hyperchannel driver on a BSD tape is broken, and doesn't follow this spec besides. I have drivers for: vaxes running 4.3 BSD. (4.2 is trivial from that) silicon graphics Irises, running 3.5 (or it may be 3.6 by now) you can have these for free. Wollongong has installed this driver on a VMS vax for us, you can probably give them some amount of money for it, but they shouldn't charge you much, because I gave it to them. Availability: public ftp from orville.arpa. I don't guarantee it is as up to date as whatever I last built. I'll probably copy the current version over next week. Upgrades include things to deal with special NSC hardware, so its no great need. john ----MESSAGE-END---- ----MESSAGE-BEGIN---- [13128@topaz.rutgers.edu] <1987070301580300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@topaz.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: revised TCP/IP document, part I of II Message-ID: <13128@topaz.rutgers.edu> Date: Fri, 3-Jul-87 05:58:03 EDT Article-I.D.: topaz.13128 Posted: Fri Jul 3 05:58:03 1987 Date-Received: Sat, 4-Jul-87 11:25:10 EDT Organization: Rutgers Univ., New Brunswick, N.J. Lines: 900 The following is a revised (and I hope final) version of the TCP/IP introduction I posted a week ago. It takes into account comments that I got from a number of helpful people, and adds a good deal of extra material. Originally, I intended it to give my own staff enough background to read the RFC's. It appears that there was a need for a bit more general introduction. I have tried to do that, to the extent that I could. Various people asked for permission to distribute it to their staff (or even customers). I have added a copyright that tries to make it clear that this is OK. If you don't have TCP/IP, and this convinces you that you should get it, the NIC (whose address is given in the last section) has a list of implementations. However these days, most equipment vendors can supply TCP/IP, or point you to a 3rd party who can. This posting is in two parts, because inews claimed that postings over 64K bytes were a bad idea. ----------------------------------- Introduction to the Internet Protocols C R C S Computer Science Facilities Group C I L S RUTGERS The State University of New Jersey 3 July 1987 This is an introduction to the Internet networking protocols (TCP/IP). It includes a summary of the facilities available and brief descriptions of the major protocols in the family. Copyright (C) 1987, Charles L. Hedrick. Anyone may reproduce this document, in whole or in part, provided that: (1) any copy or republication of the entire document must show Rutgers University as the source, and must include this notice; and (2) any other use of this material must reference this manual and Rutgers University, and the fact that the material is copyright by Charles Hedrick and is used by permission. Unix is a trademark of AT&T Technologies, Inc. Table of Contents 1. What is TCP/IP? 1 2. General description of the TCP/IP protocols 5 2.1 The TCP level 7 2.2 The IP level 10 2.3 The Ethernet level 11 3. Well-known sockets and the applications layer 12 3.1 An example application: SMTP 15 4. Protocols other than TCP: UDP and ICMP 17 5. Keeping track of names and information: the domain system 18 6. Routing 20 7. Details about Internet addresses: subnets and broadcasting 21 8. Datagram fragmentation and reassembly 23 9. Ethernet encapsulation: ARP 24 10. Getting more information 25 i This document is a brief introduction to TCP/IP, followed by advice on what to read for more information. This is not intended to be a complete description. It can give you a reasonable idea of the capabilities of the protocols. But if you need to know any details of the technology, you will want to read the standards yourself. Throughout the text, you will find references to the standards, in the form of "RFC" or "IEN" numbers. These are document numbers. The final section of this document tells you how to get copies of those standards. 1. What is TCP/IP? TCP/IP is a set of protocols developed to allow cooperating computers to share resources across a network. It was developed by a community of researchers centered around the ARPAnet. Certainly the ARPAnet is the best-known TCP/IP network. However as of June, 87, at least 130 different vendors had products that support TCP/IP, and thousands of networks of all kinds use it. First some basic definitions. The most accurate name for the set of protocols we are describing is the "Internet protocol suite". TCP and IP are two of the protocols in this suite. (They will be described below.) Because TCP and IP are the best known of the protocols, it has become common to use the term TCP/IP or IP/TCP to refer to the whole family. It is probably not worth fighting this habit. However this can lead to some oddities. For example, I find myself talking about NFS as being based on TCP/IP, even though it doesn't use TCP at all. (It does use IP. But it uses an alternative protocol, UDP, instead of TCP. All of this alphabet soup will be unscrambled in the following pages.) The Internet is a collection of networks, including the Arpanet, NSFnet, regional networks such as NYsernet, local networks at a number of University and research institutions, and a number of military networks. The term "Internet" applies to this entire set of networks. The subset of them that is managed by the Department of Defense is referred to as the "DDN" (Defense Data Network). This includes some research-oriented networks, such as the Arpanet, as well as more strictly military ones. (Because much of the funding for Internet protocol developments is done via the DDN organization, the terms Internet and DDN can sometimes seem equivalent.) All of these networks are connected to each other. Users can send messages from any of them to any other, except where there are security or other policy restrictions on access. Officially speaking, the Internet protocol documents are simply standards adopted by the Internet community for its own use. More recently, the Department of Defense issued a MILSPEC definition of TCP/IP. This was intended to be a more formal definition, appropriate for use in purchasing specifications. However most of the TCP/IP community continues to use the Internet standards. The MILSPEC version is intended to be consistent with it. Whatever it is called, TCP/IP is a family of protocols. A few provide 1 "low-level" functions needed for many applications. These include IP, TCP, and UDP. (These will be described in a bit more detail later.) Others are protocols for doing specific tasks, e.g. transferring files between computers, sending mail, or finding out who is logged in on another computer. Initially TCP/IP was used mostly between minicomputers or mainframes. These machines had their own disks, and generally were self-contained. Thus the most important "traditional" TCP/IP services are: - file transfer. The file transfer protocol (FTP) allows a user on any computer to get files from another computer, or to send files to another computer. Security is handled by requiring the user to specify a user name and password for the other computer. Provisions are made for handling file transfer between machines with different character set, end of line conventions, etc. This is not quite the same thing as more recent "network file system" or "netbios" protocols, which will be described below. Rather, FTP is a utility that you run any time you want to access a file on another system. You use it to copy the file to your own system. You then work with the local copy. (See RFC 959 for specifications for FTP.) - remote login. The network terminal protocol (TELNET) allows a user to log in on any other computer on the network. You start a remote session by specifying a computer to connect to. From that time until you finish the session, anything you type is sent to the other computer. Note that you are really still talking to your own computer. But the telnet program effectively makes your computer invisible while it is running. Every character you type is sent directly to the other system. Generally, the connection to the remote computer behaves much like a dialup connection. That is, the remote system will ask you to log in and give a password, in whatever manner it would normally ask a user who had just dialed it up. When you log off of the other computer, the telnet program exits, and you will find yourself talking to your own computer. Microcomputer implementations of telnet generally include a terminal emulator for some common type of terminal. (See RFC's 854 and 855 for specifications for telnet. By the way, the telnet protocol should not be confused with Telenet, a vendor of commercial network services.) - computer mail. This allows you to send messages to users on other computers. Originally, people tended to use only one or two specific computers. They would maintain "mail files" on those machines. The computer mail system is simply a way for you to add a message to another user's mail file. There are some problems with this in an environment where microcomputers are used. The most serious is that a micro is not well suited to receive computer mail. When you send mail, the mail software expects to be able to open a connection to the addressee's computer, in order to send the mail. If this is a microcomputer, it may be turned off, or it may be running an application other than the mail system. For this reason, mail is normally handled by a larger system, where it is practical to have a mail server running all the time. Microcomputer mail software then becomes a 2 user interface that retrieves mail from the mail server. (See RFC 821 and 822 for specifications for computer mail. See RFC 937 for a protocol designed for microcomputers to use in reading mail from a mail server.) These services should be present in any implementation of TCP/IP, except that micro-oriented implementations may not support computer mail. These traditional applications still play a very important role in TCP/IP-based networks. However more recently, the way in which networks are used has been changing. The older model of a number of large, self-sufficient computers is beginning to change. Now many installations have several kinds of computers, including microcomputers, workstations, minicomputers, and mainframes. These computers are likely to be configured to perform specialized tasks. Although people are still likely to work with one specific computer, that computer will call on other systems on the net for specialized services. This has led to the "server/client" model of network services. A server is a system that provides a specific service for the rest of the network. A client is another system that uses that service. (Note that the server and client need not be on different computers. They could be different programs running on the same computer.) Here are the kinds of servers typically present in a modern computer setup. Note that these computer services can all be provided within the framework of TCP/IP. - network file systems. This allows a system to access files on another computer in a somewhat more closely integrated fashion than FTP. A network file system provides the illusion that disks or other devices from one system are directly connected to other systems. There is no need to use a special network utility to access a file on another system. Your computer simply thinks it has some extra disk drives. These extra "virtual" drives refer to the other system's disks. This capability is useful for several different purposes. It lets you put large disks on a few computers, but still give others access to the disk space. Aside from the obvious economic benefits, this allows people working on several computers to share common files. It makes system maintenance and backup easier, because you don't have to worry about updating and backing up copies on lots of different machines. A number of vendors now offer high-performance diskless computers. These computers have no disk drives at all. They are entirely dependent upon disks attached to common "file servers". (See RFC's 1001 and 1002 for a description of PC-oriented NetBIOS over TCP. In the workstation and minicomputer area, Sun's Network File System is more likely to be used. Protocol specifications for it are available from Sun Microsystems.) - remote printing. This allows you to access printers on other computers as if they were directly attached to yours. (The most commonly used protocol is the remote lineprinter protocol from Berkeley Unix. Unfortunately, there is no protocol document for this. However the C code is easily obtained from Berkeley, so implementations are common.) 3 - remote execution. This allows you to request that a particular program be run on a different computer. This is useful when you can do most of your work on a small computer, but a few tasks require the resources of a larger system. There are a number of different kinds of remote execution. Some operate on a command by command basis. That is, you request that a specific command or set of commands should run on some specific computer. (More sophisticated versions will choose a system that happens to be free.) However there are also "remote procedure call" systems that allow a program to call a subroutine that will run on another computer. (There are many protocols of this sort. Berkeley Unix contains two servers to execute commands remotely: rsh and rexec. The man pages describe the protocols that they use. The user-contributed software with Berkeley 4.3 contains a "distributed shell" that will distribute tasks among a set of systems, depending upon load. Remote procedure call mechanisms have been a topic for research for a number of years, so many organizations have implementations of such facilities. The most widespread commercially-supported remote procedure call protocols seem to be Xerox's Courier and Sun's RPC. Protocol documents are available from Xerox and Sun. There is a public implementation of Courier over TCP as part of the user-contributed software with Berkeley 4.3. An implementation of RPC was posted to Usenet by Sun, and also appears as part of the user-contributed software with Berkeley 4.3.) - name servers. In large installations, there are a number of different collections of names that have to be managed. This includes users and their passwords, names and network addresses for computers, and accounts. It becomes very tedious to keep this data up to date on all of the computers. Thus the databases are kept on a small number of systems. Other systems access the data over the network. (RFC 822 and 823 describe the name server protocol used to keep track of host names and Internet addresses on the Internet. This is now a required part of any TCP/IP implementation. IEN 116 describes an older name server protocol that is used by a few terminal servers and other products to look up host names. Sun's Yellow Pages system is designed as a general mechanism to handle user names, file sharing groups, and other databases commonly used by Unix systems. It is widely available commercially. Its protocol definition is available from Sun.) - terminal servers. Many installations no longer connect terminals directly to computers. Instead they connect them to terminal servers. A terminal server is simply a small computer that only knows how to run telnet (or some other protocol to do remote login). If your terminal is connected to one of these, you simply type the name of a computer, and you are connected to it. Generally it is possible to have active connections to more than one computer at the same time. The terminal server will have provisions to switch between connections rapidly, and to notify you when output is waiting for another connection. (Terminal servers use the telnet protocol, already mentioned. However any real terminal server will also have to support name service and a 4 number of other protocols.) - network-oriented window systems. Until recently, high- performance graphics programs had to execute on a computer that had a bit-mapped graphics screen directly attached to it. Network window systems allow a program to use a display on a different computer. Full-scale network window systems provide an interface that lets you distribute jobs to the systems that are best suited to handle them, but still give you a single graphically-based user interface. (The most widely-implemented window system is X. A protocol description is available from MIT's Project Athena. A reference implementation is publically available from MIT. A number of vendors are also supporting NeWS, a window system defined by Sun. Both of these systems are designed to use TCP/IP.) Note that some of the protocols described above were designed by Berkeley, Sun, or other organizations. Thus they are not officially part of the Internet protocol suite. However they are implemented using TCP/IP, just as normal TCP/IP application protocols are. Since the protocol definitions are not considered proprietary, and since commercially-support implementations are widely available, it is reasonable to think of these protocols as being effectively part of the Internet suite. Note that the list above is simply a sample of the sort of services available through TCP/IP. However it does contain the majority of the "major" applications. The other commonly-used protocols tend to be specialized facilities for getting information of various kinds, such as who is logged in, the time of day, etc. However if you need a facility that is not listed here, we encourage you to look through the current edition of Internet Protocols (currently RFC 1011), which lists all of the available protocols, and also to look at some of the major TCP/IP implementations to see what various vendors have added. 2. General description of the TCP/IP protocols TCP/IP is a layered set of protocols. In order to understand what this means, it is useful to look at an example. A typical situation is sending mail. First, there is a protocol for mail. This defines a set of commands which one machine sends to another, e.g. commands to specify who the sender of the message is, who it is being sent to, and then the text of the message. However this protocol assumes that there is a way to communicate reliably between the two computers. Mail, like other application protocols, simply defines a set of commands and messages to be sent. It is designed to be used together with TCP and IP. TCP is responsible for making sure that the commands get through to the other end. It keeps track of what is sent, and retransmitts anything that did not get through. If any message is too large for one datagram, e.g. the text of the mail, TCP will split it up into several datagrams, and make sure that they all arrive correctly. Since these functions are needed for many applications, they are put together into a separate protocol, rather than being part 5 of the specifications for sending mail. You can think of TCP as forming a library of routines that applications can use when they need reliable network communications with another computer. Similarly, TCP calls on the services of IP. Although the services that TCP supplies are needed by many applications, there are still some kinds of applications that don't need them. However there are some services that every application needs. So these services are put together into IP. As with TCP, you can think of IP as a library of routines that TCP calls on, but which is also available to applications that don't use TCP. This strategy of building several levels of protocol is called "layering". We think of the applications programs such as mail, TCP, and IP, as being separate "layers", each of which calls on the services of the layer below it. Generally, TCP/IP applications use 4 layers: - an application protocol such as mail - a protocol such as TCP that provides services need by many applications - IP, which provides the basic service of getting datagrams to their destination - the protocols needed to manage a specific physical medium, such as Ethernet or a point to point line. TCP/IP is based on the "catenet model". (This is described in more detail in IEN 48.) This model assumes that there are a large number of independent networks connected together by gateways. The user should be able to access computers or other resources on any of these networks. Datagrams will often pass through a dozen different networks before getting to their final destination. The routing needed to accomplish this should be completely invisible to the user. As far as the user is concerned, all he needs to know in order to access another system is an "Internet address". This is an address that looks like 128.6.4.194. It is actually a 32-bit number. However it is normally written as 4 decimal numbers, each representing 8 bits of the address. (The term "octet" is used by Internet documentation for such 8-bit chunks. The term "byte" is not used, because TCP/IP is supported by some computers that have byte sizes other than 8 bits.) Generally the structure of the address gives you some information about how to get to the system. For example, 128.6 is a network number assigned by a central authority to Rutgers University. Rutgers uses the next octet to indicate which of the campus Ethernets is involved. 128.6.4 happens to be an Ethernet used by the Computer Science Department. The last octet allows for up to 254 systems on each Ethernet. (It is 254 because 0 and 255 are not allowed, for reasons that will be discussed later.) Note that 128.6.4.194 and 128.6.5.194 would be different systems. The structure of an Internet address is described in a bit more detail later. Of course we normally refer to systems by name, rather than by Internet address. When we specify a name, the network software looks it up in a database, and comes up with the corresponding Internet address. Most of the network software deals strictly in terms of the 6 address. (RFC 882 describes the name server technology used to handle this lookup.) TCP/IP is built on "connectionless" technology. Information is transfered as a sequence of "datagrams". A datagram is a collection of data that is sent as a single message. Each of these datagrams is sent through the network individually. There are provisions to open connections (i.e. to start a conversation that will continue for some time). However at some level, information from those connections is broken up into datagrams, and those datagrams are treated by the network as completely separate. For example, suppose you want to transfer a 15000 octet file. Most networks can't handle a 15000 octet datagram. So the protocols will break this up into something like 30 500-octet datagrams. Each of these datagrams will be sent to the other end. At that point, they will be put back together into the 15000-octet file. However while those datagrams are in transit, the network doesn't know that there is any connection between them. It is perfectly possible that datagram 14 will actually arrive before datagram 13. It is also possible that somewhere in the network, an error will occur, and some datagram won't get through at all. In that case, that datagram has to be sent again. Note by the way that the terms "datagram" and "packet" often seem to be nearly interchangable. Technically, datagram is the right word to use when describing TCP/IP. A datagram is a unit of data, which is what the protocols deal with. A packet is a physical thing, appearing on an Ethernet or some wire. In most cases a packet simply contains a datagram, so there is very little difference. However they can differ. When TCP/IP is used on top of X.25, the X.25 interface breaks the datagrams up into 128-byte packets. This is invisible to IP, because the packets are put back together into a single datagram at the other end before being processed by TCP/IP. So in this case, one IP datagram would be carried by several packets. However with most media, there are efficiency advantages to sending one datagram per packet, and so the distinction tends to vanish. 2.1 The TCP level Two separate protocols are involved in handling TCP/IP datagrams. TCP (the "transmission control protocol") is responsible for breaking up the message into datagrams, reassembling them at the other end, resending anything that gets lost, and putting things back in the right order. IP (the "internet protocol") is responsible for routing individual datagrams. It may seem like TCP is doing all the work. And in small networks that is true. However in the Internet, simply getting a datagram to its destination can be a complex job. A connection may require the datagram to go through several networks at Rutgers, a serial line to the John von Neuman Supercomputer Center, a couple of Ethernets there, a series of 56Kbaud phone lines to another NSFnet site, and more Ethernets on another campus. Keeping track of the routes to all of the destinations and handling incompatibilities among different transport media turns out to be a complex job. Note 7 that the interface between TCP and IP is fairly simple. TCP simply hands IP a datagram with a destination. IP doesn't know how this datagram relates to any datagram before it or after it. It may have occurred to you that something is missing here. We have talked about Internet addresses, but not about how you keep track of multiple connections to a given system. Clearly it isn't enough to get a datagram to the right destination. TCP has to know which connection this datagram is part of. This task is referred to as "demultiplexing." In fact, there are several levels of demultiplexing going on in TCP/IP. The information needed to do this demultiplexing is contained in a series of "headers". A header is simply a few extra octets tacked onto the beginning of a datagram by some protocol in order to keep track of it. It's a lot like putting a letter into an envelope and putting an address on the outside of the envelope. Except with modern networks it happens several times. It's like you put the letter into a little envelope, your secretary puts that into a somewhat bigger envelope, the campus mail center puts that envelope into a still bigger one, etc. Here is an overview of the headers that get stuck on a message that passes through a typical TCP/IP network: We start with a single data stream, say a file you are trying to send to some other computer: ...................................................... TCP breaks it up into manageable chunks. (In order to do this, TCP has to know how large a datagram your network can handle. Actually, the TCP's at each end say how big a datagram they can handle, and then they pick the smallest size.) .... .... .... .... .... .... .... .... TCP puts a header at the front of each datagram. This header actually contains at least 20 octets, but the most important ones are a source and destination "port number" and a "sequence number". The port numbers are used to keep track of different conversations. Suppose 3 different people are transferring files. Your TCP might allocate port numbers 1000, 1001, and 1002 to these transfers. When you are sending a datagram, this becomes the "source" port number, since you are the source of the datagram. Of course the TCP at the other end has assigned a port number of its own for the conversation. Your TCP has to know the port number used by the other end as well. (It finds out when the connection starts, as we will explain below.) It puts this in the "destination" port field. Of course if the other end sends a datagram back to you, the source and destination port numbers will be reversed, since then it will be the source and you will be the destination. Each datagram has a sequence number. This is used so that the other end can make sure that it gets the datagrams in the right order, and that it hasn't missed any. (See the TCP specification for details.) TCP doesn't number the datagrams, but the octets. So if there are 500 octets of data in each datagram, the first datagram might be numbered 0, the second 500, the next 1000, the next 1500, etc. Finally, I will mention the Checksum. This is a number that is computed by adding up all the octets in the datagram 8 (more or less - see the TCP spec). The result is put in the header. TCP at the other end computes the checksum again. If they disagree, then something bad happened to the datagram in transmission, and it is thrown away. So here's what the datagram looks like now. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | your data ... next 500 octets | | ...... | If we abbreviate the TCP header as "T", the whole file now looks like this: T.... T.... T.... T.... T.... T.... T.... You will note that there are items in the header that I have not described above. They are generally involved with managing the connection. In order to make sure the datagram has arrived at its destination, the recipient has to send back an "acknowledgement". This is a datagram whose "Acknowledgement number" field is filled in. For example, sending a packet with an acknowledgement of 1500 indicates that you have received all the data up to octet number 1500. If the sender doesn't get an acknowledgement within a reasonable amount of time, it sends the data again. The window is used to control how much data can be in transit at any one time. It is not practical to wait for each datagram to be acknowledged before sending the next one. That would slow things down too much. On the other hand, you can't just keep sending, or a fast computer might overrun the capacity of a slow one to absorb data. Thus each end indicates how much new data it is currently prepared to absorb by putting the number of octets in its "Window" field. As the computer receives data, the amount of space left in its window decreases. When it goes to zero, the sender has to stop. As the receiver processes the data, it increases its window, indicating that it is ready to accept more data. Often the same datagram can be used to acknowledge receipt of a set of data and to give permission for additional new data (by an updated window). The "Urgent" field allows one end to tell the other to skip ahead in its processing to a particular octet. This is often useful for handling asynchronous events, for example when you type a control character or other command that interrupts output. The other fields are beyond the scope of this document. 9 2.2 The IP level TCP sends each of these datagrams to IP. Of course it has to tell IP the Internet address of the computer at the other end. Note that this is all IP is concerned about. It doesn't care about what is in the datagram, or even in the TCP header. IP's job is simply to find a route for the datagram and get it to the other end. In order to allow gateways or other intermediate systems to forward the datagram, it adds its own header. The main things in this header are the source and destination Internet address (32-bit addresses, like 128.6.4.194), the protocol number, and another checksum. The source Internet address is simply the address of your machine. (This is necessary so the other end knows where the datagram came from.) The destination Internet address is the address of the other machine. (This is necessary so any gateways in the middle know where you want the datagram to go.) The protocol number tells IP at the other end to send the datagram to TCP. Although most IP traffic uses TCP, there are other protocols that can use IP, so you have to tell IP which protocol to send the datagram to. Finally, the checksum allows IP at the other end to verify that the header wasn't damaged in transit. Note that TCP and IP have separate checksums. IP needs to be able to verify that the header didn't get damaged in transit, or it could send a message to the wrong place. For reasons not worth discussing here, it is both more efficient and safer to have TCP compute a separate checksum for the TCP header and data. Once IP has tacked on its header, here's what the message looks like: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TCP header, then your data ...... | | | If we represent the IP header by an "I", your file now looks like this: IT.... IT.... IT.... IT.... IT.... IT.... IT.... Again, the header contains some additional fields that have not been discussed. Most of them are beyond the scope of this document. The flags and fragment offset are used to keep track of the pieces when a datagram has to be split up. This can happen when datagrams are forwarded through a network for which they are too big. (This will be discussed a bit more below.) The time to live is a number that is decremented whenever the datagram passes through a system. When it goes to zero, the datagram is discarded. This is done in case a loop 10 develops in the system somehow. Of course this should be impossible, but well-designed networks are built to cope with "impossible" conditions. At this point, it's possible that no more headers are needed. If your computer happens to have a direct phone line connecting it to the destination computer, or to a gateway, it may simply send the datagrams out on the line (though likely a synchronous protocol such as HDLC would be used, and it would add at least a few octets at the beginning and end). 2.3 The Ethernet level However most of our networks these days use Ethernet. So now we have to describe Ethernet's headers. Unfortunately, Ethernet has its own addresses. The people who designed Ethernet wanted to make sure that no two machines would end up with the same Ethernet address. Furthermore, they didn't want the user to have to worry about assigning addresses. So each Ethernet controller comes with an address builtin from the factory. In order to make sure that they would never have to reuse addresses, the Ethernet designers allocated 48 bits for the Ethernet address. People who make Ethernet equipment have to register with a central authority, to make sure that the numbers they assign don't overlap any other manufacturer. Ethernet is a "broadcast medium". That is, it is in effect like an old party line telephone. When you send a packet out on the Ethernet, every machine on the network sees the packet. So something is needed to make sure that the right machine gets it. As you might guess, this involves the Ethernet header. Every Ethernet packet has a 14-octet header that includes the source and destination Ethernet address, and a type code. Each machine is supposed to pay attention only to packets with its own Ethernet address in the destination field. (It's perfectly possible to cheat, which is one reason that Ethernet communications are not terribly secure.) Note that there is no connection between the Ethernet address and the Internet address. Each machine has to have a table of what Ethernet address corresponds to what Internet address. (We will describe how this table is constructed a bit later.) In addition to the addresses, the header contains a type code. The type code is to allow for several different protocol families to be used on the same network. So you can use TCP/IP, DECnet, Xerox NS, etc. at the same time. Each of them will put a different value in the type field. Finally, there is a checksum. The Ethernet controller computes a checksum of the entire packet. When the other end receives the packet, it recomputes the checksum, and throws the packet away if the answer disagrees with the original. The checksum is put on the end of the packet, not in the header. The final result is that your message looks like this: 11 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet destination address (first 32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet dest (last 16 bits) |Ethernet source (first 16 bits)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet source address (last 32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP header, then TCP header, then your data | | | ... | | | end of your data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If we represent the Ethernet header with "E", and the Ethernet checksum with "C", your file now looks like this: EIT....C EIT....C EIT....C EIT....C EIT....C When these packets are received by the other end, of course all the headers are removed. The Ethernet interface removes the Ethernet header and the checksum. It looks at the type code. Since the type code is the one assigned to IP, the Ethernet device driver passes the datagram up to IP. IP removes the IP header. It looks at the IP protocol field. Since the protocol type is TCP, it passes the datagram up to TCP. TCP now looks at the sequence number. It uses the sequence numbers and other information to combine all the datagrams into the original file. The ends our initial summary of TCP/IP. There are still some crucial concepts we haven't gotten to, so we'll now go back and add details in several areas. (For detailed descriptions of the items discussed here see, RFC 793 for TCP, RFC 791 for IP, and RFC's 894 and 826 for sending IP over Ethernet.) 3. Well-known sockets and the applications layer So far, we have described how a stream of data is broken up into datagrams, sent to another computer, and put back together. However something more is needed in order to accomplish anything useful. There has to be a way for you to open a connection to a specified computer, log into it, tell it what file you want, and control the transmission of the file. (If you have a different application in mind, e.g. computer mail, some analogous protocol is needed.) This is done by "application protocols". The application protocols run "on top" of TCP/IP. That is, when they want to send a message, they give the message to TCP. TCP makes sure it gets delivered to the other end. Because TCP and IP take care of all the networking details, the 12 applications protocols can treat a network connection as if it were a simple byte stream, like a terminal or phone line. Before going into more details about applications programs, we have to describe how you find an application. Suppose you want to send a file to a computer whose Internet address is 128.6.4.7. To start the process, you need more than just the Internet address. You have to connect to the FTP server at the other end. In general, network programs are specialized for a specific set of tasks. Most systems have separate programs to handle file transfers, remote terminal logins, mail, etc. When you connect to 128.6.4.7, you have to specify that you want to talk to the FTP server. This is done by having "well-known sockets" for each server. Recall that TCP uses port numbers to keep track of individual conversations. User programs normally use more or less random port numbers. However specific port numbers are assigned to the programs that sit waiting for requests. For example, if you want to send a file, you will start a program called "ftp". It will open a connection using some random number, say 1234, for the port number on its end. However it will specify port number 21 for the other end. This is the official port number for the FTP server. Note that there are two different programs involved. You run ftp on your side. This is a program designed to accept commands from your terminal and pass them on to the other end. The program that you talk to on the other machine is the FTP server. It is designed to accept commands from the network connection, rather than an interactive terminal. There is no need for your program to use a well-known socket number for itself. Nobody is trying to find it. However the servers have to have well-known numbers, so that people can open connections to them and start sending them commands. The official port numbers for each program are given in "Assigned Numbers". Note that a connection is actually described by a set of 4 numbers: the Internet address at each end, and the TCP port number at each end. Every datagram has all four of those numbers in it. (The Internet addresses are in the IP header, and the TCP port numbers are in the TCP header.) In order to keep things straight, no two connections can have the same set of numbers. However it is enough for any one number to be different. For example, it is perfectly possible for two different users on a machine to be sending files to the same other machine. This could result in connections with the following parameters: Internet addresses TCP ports connection 1 128.6.4.194, 128.6.4.7 1234, 21 connection 2 128.6.4.194, 128.6.4.7 1235, 21 Since the same machines are involved, the Internet addresses are the same. Since they are both doing file transfers, one end of the connection involves the well-known port number for FTP. The only thing that differs is the port number for the program that the users are running. That's enough of a difference. Generally, at least one end of the connection asks the network software to assign it a port number that is guaranteed to be unique. Normally, it's the user's end, since the server has to use a well-known number. 13 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [13129@topaz.rutgers.edu] <1987070301592200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@topaz.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP intro, part II of II Message-ID: <13129@topaz.rutgers.edu> Date: Fri, 3-Jul-87 05:59:22 EDT Article-I.D.: topaz.13129 Posted: Fri Jul 3 05:59:22 1987 Date-Received: Sat, 4-Jul-87 11:25:46 EDT Organization: Rutgers Univ., New Brunswick, N.J. Lines: 827 Now that we know how to open connections, let's get back to the applications programs. As mentioned earlier, once TCP has opened a connection, we have something that might as well be a simple wire. All the hard parts are handled by TCP and IP. However we still need some agreement as to what we send over this connection. In effect this is simply an agreement on what set of commands the application will understand, and the format in which they are to be sent. Generally, what is sent is a combination of commands and data. They use context to differentiate. For example, the mail protocol works like this: Your mail program opens a connection to the mail server at the other end. Your program gives it your machine's name, the sender of the message, and the recipients you want it sent to. It then sends a command saying that it is starting the message. At that point, the other end stops treating what it sees as commands, and starts accepting the message. Your end then starts sending the text of the message. At the end of the message, a special mark is sent (a dot in the first column). After that, both ends understand that your program is again sending commands. This is the simplest way to do things, and the one that most applications use. File transfer is somewhat more complex. The file transfer protocol involves two different connections. It starts out just like mail. The user's program sends commands like "log me in as this user", "here is my password", "send me the file with this name". However once the command to send data is sent, a second connection is opened for the data itself. It would certainly be possible to send the data on the same connection, as mail does. However file transfers often take a long time. The designers of the file transfer protocol wanted to allow the user to continue issuing commands while the transfer is going on. For example, the user might make an inquiry, or he might abort the transfer. Thus the designers felt it was best to use a separate connection for the data and leave the original command connection for commands. (It is also possible to open command connections to two different computers, and tell them to send a file from one to the other. In that case, the data couldn't go over the command connection.) Remote terminal connections use another mechanism still. For remote logins, there is just one connection. It normally sends data. When it is necessary to send a command (e.g. to set the terminal type or to change some mode), a special character is used to indicate that the next character is a command. If the user happens to type that special character as data, two of them are sent. We are not going to describe the application protocols in detail in this document. It's better to read the RFC's yourself. However there are a couple of common conventions used by applications that will be described here. First, the common network representation: TCP/IP is intended to be usable on any computer. Unfortunately, not all computers agree on how data is represented. There are differences in character codes (ASCII vs. EBCDIC), in end of line conventions (carriage return, line feed, or a representation using counts), and in whether terminals expect characters to be sent individually or a line at a time. In order to allow computers of different kinds to communicate, each applications protocol defines a standard 14 representation. Note that TCP and IP do not care about the representation. TCP simply sends octets. However the programs at both ends have to agree on how the octets are to be interpreted. The RFC for each application specifies the standard representation for that application. Normally it is "net ASCII". This uses ASCII characters, with end of line denoted by a carriage return followed by a line feed. For remote login, there is also a definition of a "standard terminal", which turns out to be a half-duplex terminal with echoing happening on the local machine. Most applications also make provisions for the two computers to agree on other representations that they may find more convenient. For example, PDP-10's have 36-bit words. There is a way that two PDP-10's can agree to send a 36-bit binary file. Similarly, two systems that prefer full-duplex terminal conversations can agree on that. However each application has a standard representation, which every machine must support. 3.1 An example application: SMTP In order to give a bit better idea what is involved in the application protocols, I'm going to show an example of SMTP, which is the mail protocol. (SMTP is "simple mail transfer protocol.) We assume that a computer called TOPAZ.RUTGERS.EDU wants to send the following message. Date: Sat, 27 Jun 87 13:26:31 EDT From: hedrick@topaz.rutgers.edu To: levy@red.rutgers.edu Subject: meeting Let's get together Monday at 1pm. First, note that the format of the message itself is described by an Internet standard (RFC 822). The standard specifies the fact that the message must be transmitted as net ASCII (i.e. it must be ASCII, with carriage return/linefeed to delimit lines). It also describes the general structure, as a group of header lines, then a blank line, and then the body of the message. Finally, it describes the syntax of the header lines in detail. Generally they consist of a keyword and then a value. Note that the addressee is indicated as LEVY@RED.RUTGERS.EDU. Initially, addresses were simply "person at machine". However recent standards have made things more flexible. There are now provisions for systems to handle other systems' mail. This can allow automatic forwarding on behalf of computers not connected to the Internet. It can be used to direct mail for a number of systems to one central mail server. Indeed there is no requirement that an actual computer by the name of RED.RUTGERS.EDU even exist. The name servers could be set up so that you mail to department names, and each department's mail is routed automatically to an appropriate computer. It is also possible that the part before the @ is something other than a user name. It is possible for programs to be set up to process mail. There are also provisions to handle mailing lists, and generic names such as 15 "postmaster" or "operator". The way the message is to be sent to another system is described by RFC's 821 and 974. The program that is going to be doing the sending asks the name server several queries to determine where to route the message. The first query is to find out which machines handle mail for the name RED.RUTGERS.EDU. In this case, the server replies that RED.RUTGERS.EDU handles its own mail. The program then asks for the address of RED.RUTGERS.EDU, which is 128.6.4.2. Then the mail program opens a TCP connection to port 25 on 128.6.4.2. Port 25 is the well-known socket used for receiving mail. Once this connection is established, the mail program starts sending commands. Here is a typical conversation. Each line is labelled as to whether it is from TOPAZ or RED. Note that TOPAZ initiated the connection: RED 220 RED.RUTGERS.EDU SMTP Service at 29 Jun 87 05:17:18 EDT TOPAZ HELO topaz.rutgers.edu RED 250 RED.RUTGERS.EDU - Hello, TOPAZ.RUTGERS.EDU TOPAZ MAIL From: RED 250 MAIL accepted TOPAZ RCPT To: RED 250 Recipient accepted TOPAZ DATA RED 354 Start mail input; end with . TOPAZ Date: Sat, 27 Jun 87 13:26:31 EDT TOPAZ From: hedrick@topaz.rutgers.edu TOPAZ To: levy@red.rutgers.edu TOPAZ Subject: meeting TOPAZ TOPAZ Let's get together Monday at 1pm. TOPAZ . RED 250 OK TOPAZ QUIT RED 221 RED.RUTGERS.EDU Service closing transmission channel First, note that commands all use normal text. This is typical of the Internet standards. Many of the protocols use standard ASCII commands. This makes it easy to watch what is going on and to diagnose problems. For example, the mail program keeps a log of each conversation. If something goes wrong, the log file can simply be mailed to the postmaster. Since it is normal text, he can see what was going on. It also allows a human to interact directly with the mail server, for testing. (Some newer protocols are complex enough that this is not practical. The commands would have to have a syntax that would require a significant parser. Thus there is a tendency for newer protocols to use binary formats. Generally they are structured like C or Pascal record structures.) Second, note that the responses all begin with numbers. This is also typical of Internet protocols. The allowable responses are defined in the protocol. The numbers allow the user program to respond unambiguously. The rest of the response is text, which is normally for use by any human who may be watching or looking at a log. It has no effect on the operation of the programs. (However there is one point at which the protocol uses part of the text of the response.) The commands themselves simply allow the mail program on one end to tell the mail server the 16 information it needs to know in order to deliver the message. In this case, the mail server could get the information by looking at the message itself. But for more complex cases, that would not be safe. Every session must begin with a HELO, which gives the name of the system that initiated the connection. Then the sender and recipients are specified. (There can be more than one RCPT command, if there are several recipients.) Finally the data itself is sent. Note that the text of the message is terminated by a line containing just a period. (If such a line appears in the message, the period is doubled.) After the message is accepted, the sender can send another message, or terminate the session as in the example above. Generally, there is a pattern to the response numbers. The protocol defines the specific set of responses that can be sent as answers to any given command. However programs that don't want to analyze them in detail can just look at the first digit. In general, responses that begin with a 2 indicate success. Those that begin with 3 indicate that some further action is needed, as shown above. 4 and 5 indicate errors. 4 is a "temporary" error, such as a disk filling. The message should be saved, and tried again later. 5 is a permanent error, such as a non-existent recipient. The message should be returned to the sender with an error message. (For more details about the protocols mentioned in this section, see RFC's 821/822 for mail, RFC 959 for file transfer, and RFC's 854/855 for remote logins. For the well-known port numbers, see the current edition of Assigned Numbers, and possibly RFC 814.) 4. Protocols other than TCP: UDP and ICMP So far, we have described only connections that use TCP. Recall that TCP is responsible for breaking up messages into datagrams, and reassembling them properly. However in many applications, we have messages that will always fit in a single datagram. An example is name lookup. When a user attempts to make a connection to another system, he will generally specify the system by name, rather than Internet address. His system has to translate that name to an address before it can do anything. Generally, only a few systems have the database used to translate names to addresses. So the user's system will want to send a query to one of the systems that has the database. This query is going to be very short. It will certainly fit in one datagram. So will the answer. Thus it seems silly to use TCP. Of course TCP does more than just break things up into datagrams. It also makes sure that the data arrives, resending datagrams where necessary. But for a question that fits in a single datagram, we don't need all the complexity of TCP to do this. If we don't get an answer after a few seconds, we can just ask again. For applications like this, there are alternatives to TCP. The most common alternative is UDP ("user datagram protocol"). UDP is designed for applications where you don't need to put sequences of datagrams together. It fits into the system much like TCP. There is 17 a UDP header. The network software puts the UDP header on the front of your data, just as it would put a TCP header on the front of your data. Then UDP sends the data to IP, which adds the IP header, putting UDP's protocol number in the protocol field instead of TCP's protocol number. However UDP doesn't do as much as TCP does. It doesn't split data into multiple datagrams. It doesn't keep track of what it has sent so it can resend if necessary. About all that UDP provides is port numbers, so that several programs can use UDP at once. UDP port numbers are used just like TCP port numbers. There are well-known port numbers for servers that use UDP. Note that the UDP header is shorter than a TCP header. It still has source and destination port numbers, and a checksum, but that's about it. No sequence number, since it is not needed. UDP is used by the protocols that handle name lookups (see IEN 116, RFC 882, and RFC 883), and a number of similar protocols. Another alternative protocol is ICMP ("Internet control message protocol"). ICMP is used for error messages, and other messages intended for the TCP/IP software itself, rather than any particular user program. For example, if you attempt to connect to a host, your system may get back an ICMP message saying "host unreachable". ICMP can also be used to find out some information about the network. See RFC 792 for details of ICMP. ICMP is similar to UDP, in that it handles messages that fit in one datagram. However it is even simpler than UDP. It doesn't even have port numbers in its header. Since all ICMP messages are interpreted by the network software itself, no port numbers are needed to say where a ICMP message is supposed to go. 5. Keeping track of names and information: the domain system As we indicated earlier, the network software generally needs a 32-bit Internet address in order to open a connection or send a datagram. However users prefer to deal with computer names rather than numbers. Thus there is a database that allows the software to look up a name and find the corresponding number. When the Internet was small, this was easy. Each system would have a file that listed all of the other systems, giving both their name and number. There are now too many computers for this approach to be practical. Thus these files have been replaced by a set of name servers that keep track of host names and the corresponding Internet addresses. (In fact these servers are somewhat more general than that. This is just one kind of information stored in the domain system.) Note that a set of interlocking servers are used, rather than a single central one. There are now so many different institutions connected to the Internet that it would be impractical for them to notify a central authority whenever they installed or moved a computer. Thus naming authority is delegated to individual institutions. The name servers form a tree, corresponding to institutional structure. The names themselves follow a similar structure. A typical example is the name BORAX.LCS.MIT.EDU. This is a computer at the Laboratory for Computer Science (LCS) at MIT. In order to find its Internet address, you might potentially have to consult 4 different servers. First, you would ask a central server 18 (called the root) where the EDU server is. EDU is a server that keeps track of educational institutions. The root server would give you the names and Internet addresses of several servers for EDU. (There are several servers at each level, to allow for the possibly that one might be down.) You would then ask EDU where the server for MIT is. Again, it would give you names and Internet addresses of several servers for MIT. Generally, not all of those servers would be at MIT, to allow for the possibility of a general power failure at MIT. Then you would ask MIT where the server for LCS is, and finally you would ask one of the LCS servers about BORAX. The final result would be the Internet address for BORAX.LCS.MIT.EDU. Each of these levels is referred to as a "domain". The entire name, BORAX.LCS.MIT.EDU, is called a "domain name". (So are the names of the higher-level domains, such as LCS.MIT.EDU, MIT.EDU, and EDU.) Fortunately, you don't really have to go through all of this most of the time. First of all, the root name servers also happen to be the name servers for the top-level domains such as EDU. Thus a single query to a root server will get you to MIT. Second, software generally remembers answers that it got before. So once we look up a name at LCS.MIT.EDU, our software remembers where to find servers for LCS.MIT.EDU, MIT.EDU, and EDU. It also remembers the translation of BORAX.LCS.MIT.EDU. Each of these pieces of information has a "time to live" associated with it. Typically this is a few days. After that, the information expires and has to be looked up again. This allows institutions to change things. The domain system is not limited to finding out Internet addresses. Each domain name is a node in a database. The node can have records that define a number of different properties. Examples are Internet address, computer type, and a list of services provided by a computer. A program can ask for a specific piece of information, or all information about a given name. It is possible for a node in the database to be marked as an "alias" (or nickname) for another node. It is also possible to use the domain system to store information about users, mailing lists, or other objects. There is an Internet standard defining the operation of these databases, as well as the protocols used to make queries of them. Every network utility has to be able to make such queries, since this is now the official way to evaluate host names. Generally utilities will talk to a server on their own system. This server will take care of contacting the other servers for them. This keeps down the amount of code that has to be in each application program. The domain system is particularly important for handling computer mail. There are entry types to define what computer handles mail for a given name, to specify where an individual is to receive mail, and to define mailing lists. (See RFC's 882, 883, and 973 for specifications of the domain system. RFC 974 defines the use of the domain system in sending mail.) 19 6. Routing The description above indicated that the IP implementation is responsible for getting datagrams to the destination indicated by the destination address, but little was said about how this would be done. The task of finding how to get a datagram to its destination is referred to as "routing". In fact many of the details depend upon the particular implementation. However some general things can be said. First, it is necessary to understand the model on which IP is based. IP assumes that a system is attached to some local network. We assume that the system can send datagrams to any other system on its own network. (In the case of Ethernet, it simply finds the Ethernet address of the destination system, and puts the datagram out on the Ethernet.) The problem comes when a system is asked to send a datagram to a system on a different network. This problem is handled by gateways. A gateway is a system that connects a network with one or more other networks. Gateways are often normal computers that happen to have more than one network interface. For example, we have a Unix machine that has two different Ethernet interfaces. Thus it is connected to networks 128.6.4 and 128.6.3. This machine can act as a gateway between those two networks. The software on that machine must be set up so that it will forward datagrams from one network to the other. That is, if a machine on network 128.6.4 sends a datagram to the gateway, and the datagram is addressed to a machine on network 128.6.3, the gateway will forward the datagram to the destination. Major communications centers often have gateways that connect a number of different networks. (In many cases, special-purpose gateway systems provide better performance or reliability than general-purpose systems acting as gateways. A number of vendors sell such systems.) Routing in IP is based entirely upon the network number of the destination address. Each computer has a table of network numbers. For each network number, a gateway is listed. This is the gateway to be used to get to that network. Note that the gateway doesn't have to connect directly to the network. It just has to be the best place to go to get there. For example at Rutgers, our interface to NSFnet is at the John von Neuman Supercomputer Center (JvNC). Our connection to JvNC is via a high-speed serial line connected to a gateway whose address is 128.6.3.12. Systems on net 128.6.3 will list 128.6.3.12 as the gateway for many off-campus networks. However systems on net 128.6.4 will list 128.6.4.1 as the gateway to those same off-campus networks. 128.6.4.1 is the gateway between networks 128.6.4 and 128.6.3, so it is the first step in getting to JvNC. When a computer wants to send a datagram, it first checks to see if the destination address is on the system's own local network. If so, the datagram can be sent directly. Otherwise, the system expects to find an entry for the network that the destination address is on. The datagram is sent to the gateway listed in that entry. This table can get quite big. For example, the Internet now includes several hundred individual networks. Thus various strategies have been developed to reduce the size of the routing table. One strategy is to depend upon "default routes". Often, there is only one gateway out of a network. 20 This gateway might connect a local Ethernet to a campus-wide backbone network. In that case, we don't need to have a separate entry for every network in the world. We simply define that gateway as a "default". When no specific route is found for a datagram, the datagram is sent to the default gateway. A default gateway can even be used when there are several gateways on a network. There are provisions for gateways to send a message saying "I'm not the best gateway -- use this one instead." (The message is sent via ICMP. See RFC 792.) Most network software is designed to use these messages to add entries to their routing tables. Suppose network 128.6.4 has two gateways, 128.6.4.59 and 128.6.4.1. 128.6.4.59 leads to several other internal Rutgers networks. 128.6.4.1 leads indirectly to the NSFnet. Suppose we set 128.6.4.59 as a default gateway, and have no other routing table entries. Now what happens when we need to send a datagram to MIT? MIT is network 18. Since we have no entry for network 18, the datagram will be sent to the default, 128.6.4.59. As it happens, this gateway is the wrong one. So it will forward the datagram to 128.6.4.1. But it will also send back an error saying in effect: "to get to network 18, use 128.6.4.1". Our software will then add an entry to the routing table. Any future datagrams to MIT will then go directly to 128.6.4.1. (The error message is sent using the ICMP protocol. The message type is called "ICMP redirect.") Most IP experts recommend that individual computers should not try to keep track of the entire network. Instead, they should start with default gateways, and let the gateways tell them the routes, as just described. However this doesn't say how the gateways should find out about the routes. The gateways can't depend upon this strategy. They have to have fairly complete routing tables. For this, some sort of routing protocol is needed. A routing protocol is simply a technique for the gateways to find each other, and keep up to date about the best way to get to every network. RFC 1009 contains a review of gateway design and routing. However rip.doc is probably a better introduction to the subject. It contains some tutorial material, and a detailed description of the most commonly-used routing protocol. 7. Details about Internet addresses: subnets and broadcasting As indicated earlier, Internet addresses are 32-bit numbers, normally written as 4 octets (in decimal), e.g. 128.6.4.7. There are actually 3 different types of address. The problem is that the address has to indicate both the network and the host within the network. It was felt that eventually there would be lots of networks. Many of them would be small, but probably 24 bits would be needed to represent all the IP networks. It was also felt that some very big networks might need 24 bits to represent all of their hosts. This would seem to lead to 48 bit addresses. But the designers really wanted to use 32 bit addresses. So they adopted a kludge. The assumption is that most of the networks will be small. So they set up three different ranges of address. Addresses beginning with 1 to 126 use only the first octet for the network number. The other three octets are available for the host number. Thus 24 bits are available for hosts. These numbers are 21 used for large networks. But there can only be 126 of these very big networks. The Arpanet is one, and there are a few large commercial networks. But few normal organizations get one of these "class A" addresses. For normal large organizations, "class B" addresses are used. Class B addresses use the first two octets for the network number. Thus network numbers are 128.1 through 191.254. (We avoid 0 and 255, for reasons that we see below. We also avoid addresses beginning with 127, because that is used by some systems for special purposes.) The last two octets are available for host addesses, giving 16 bits of host address. This allows for 64516 computers, which should be enough for most organizations. (It is possible to get more than one class B address, if you run out.) Finally, class C addresses use three octets, in the range 192.1.1 to 223.254.254. These allow only 254 hosts on each network, but there can be lots of these networks. Addresses above 223 are reserved for future use, as class D and E (which are currently not defined). Many large organizations find it convenient to divide their network number into "subnets". For example, Rutgers has been assigned a class B address, 128.6. We find it convenient to use the third octet of the address to indicate which Ethernet a host is on. This division has no significance outside of Rutgers. A computer at another institution would treat all datagrams addressed to 128.6 the same way. They would not look at the third octet of the address. Thus computers outside Rutgers would not have different routes for 128.6.4 or 128.6.5. But inside Rutgers, we treat 128.6.4 and 128.6.5 as separate networks. In effect, gateways inside Rutgers have separate entries for each Rutgers subnet, whereas gateways outside Rutgers just have one entry for 128.6. Note that we could do exactly the same thing by using a separate class C address for each Ethernet. As far as Rutgers is concerned, it would be just as convenient for us to have a number of class C addresses. However using class C addresses would make things inconvenient for the rest of the world. Every institution that wanted to talk to us would have to have a separate entry for each one of our networks. If every institution did this, there would be far too many networks for any reasonable gateway to keep track of. By subdividing a class B network, we hide our internal structure from everyone else, and save them trouble. This subnet strategy requires special provisions in the network software. It is described in RFC 950. 0 and 255 have special meanings. 0 is reserved for machines that don't know their address. In certain circumstances it is possible for a machine not to know the number of the network it is on, or even its own host address. For example, 0.0.0.23 would be a machine that knew it was host number 23, but didn't know on what network. 255 is used for "broadcast". A broadcast is a message that you want every system on the network to see. Broadcasts are used in some situations where you don't know who to talk to. For example, suppose you need to look up a host name and get its Internet address. Sometimes you don't know the address of the nearest name server. In that case, you might send the request as a broadcast. There are also cases where a number of systems are interested in information. It is then less expensive to send a single broadcast than to send datagrams individually to each host that is interested in the information. In 22 order to send a broadcast, you use an address that is made by using your network address, with all ones in the part of the address where the host number goes. For example, if you are on network 128.6.4, you would use 128.6.4.255 for broadcasts. How this is actually implemented depends upon the medium. It is not possible to send broadcasts on the Arpanet, or on point to point lines. However it is possible on an Ethernet. If you use an Ethernet address with all its bits on (all ones), every machine on the Ethernet is supposed to look at that datagram. Although the official broadcast address for network 128.6.4 is now 128.6.4.255, there are some other addresses that may be treated as broadcasts by certain implementations. For convenience, the standard also allows 255.255.255.255 to be used. This refers to all hosts on the local network. It is often simpler to use 255.255.255.255 instead of finding out the network number for the local network and forming a broadcast address such as 128.6.4.255. In addition, certain older implementations may use 0 instead of 255 to form the broadcast address. Such implementations would use 128.6.4.0 instead of 128.6.4.255 as the broadcast address on network 128.6.4. Finally, certain older implementations may not understand about subnets. Thus they consider the network number to be 128.6. In that case, they will assume a broadcast address of 128.6.255.255 or 128.6.0.0. Until support for broadcasts is implemented properly, it can be a somewhat dangerous feature to use. Because 0 and 255 are used for unknown and broadcast addresses, normal hosts should never be given addresses containing 0 or 255. Addresses should never begin with 0, 127, or any number above 223. Addresses violating these rules are sometimes referred to as "Martians", because of rumors that the Central University of Mars is using network 225. 8. Datagram fragmentation and reassembly TCP/IP is designed for use with many different kinds of network. Unfortunately, network designers do not agree about how big packets can be. Ethernet packets can be 1500 octets long. Arpanet packets have a maximum of around 1000 octets. Some very fast networks have much larger packet sizes. At first, you might think that IP should simply settle on the smallest possible size. Unfortunately, this would cause serious performance problems. When transferring large files, big packets are far more efficient than small ones. So we want to be able to use the largest packet size possible. But we also want to be able to handle networks with small limits. There are two provisions for this. First, TCP has the ability to "negotiate" about datagram size. When a TCP connection first opens, both ends can send the maximum datagram size they can handle. The smaller of these numbers is used for the rest of the connection. This allows two implementations that can handle big datagrams to use them, but also lets them talk to implementations that can't handle them. However this doesn't completely solve the problem. The most serious problem is that the two ends don't necessarily know about all of the steps in 23 between. For example, when sending data between Rutgers and Berkeley, it is likely that both computers will be on Ethernets. Thus they will both be prepared to handle 1500-octet datagrams. However the connection will at some point end up going over the Arpanet. It can't handle packets of that size. For this reason, there are provisions to split datagrams up into pieces. (This is referred to as "fragmentation".) The IP header contains fields indicating the a datagram has been split, and enough information to let the pieces be put back together. If a gateway connects an Ethernet to the Arpanet, it must be prepared to take 1500-octet Ethernet packets and split them into pieces that will fit on the Arpanet. Furthermore, every host implementation of TCP/IP must be prepared to accept pieces and put them back together. This is referred to as "reassembly". TCP/IP implementations differ in the approach they take to deciding on datagram size. It is fairly common for implementations to use 576-byte datagrams whenever they can't verify that the entire path is able to handle larger packets. This rather conservative strategy is used because of the number of implementations with bugs in the code to reassemble fragments. Implementors often try to avoid ever having fragmentation occur. Different implementors take different approaches to deciding when it is safe to use large datagrams. Some use them only for the local network. Others will use them for any network on the same campus. 576 bytes is a "safe" size, which every implementation must support. 9. Ethernet encapsulation: ARP There was a brief discussion earlier about what IP datagrams look like on an Ethernet. The discussion showed the Ethernet header and checksum. However it left one hole: It didn't say how to figure out what Ethernet address to use when you want to talk to a given Internet address. In fact, there is a separate protocol for this, called ARP ("address resolution protocol"). (Note by the way that ARP is not an IP protocol. That is, the ARP datagrams do not have IP headers.) Suppose you are on system 128.6.4.194 and you want to connect to system 128.6.4.7. Your system will first verify that 128.6.4.7 is on the same network, so it can talk directly via Ethernet. Then it will look up 128.6.4.7 in its ARP table, to see if it already knows the Ethernet address. If so, it will stick on an Ethernet header, and send the packet. But suppose this system is not in the ARP table. There is no way to send the packet, because you need the Ethernet address. So it uses the ARP protocol to send an ARP request. Essentially an ARP request says "I need the Ethernet address for 128.6.4.7". Every system listens to ARP requests. When a system sees an ARP request for itself, it is required to respond. So 128.6.4.7 will see the request, and will respond with an ARP reply saying in effect "128.6.4.7 is 8:0:20:1:56:34". (Recall that Ethernet addresses are 48 bits. This is 6 octets. Ethernet addresses are conventionally shown in hex, using the punctuation shown.) Your system will save this information in its ARP table, so future packets will go directly. Most systems treat the ARP table as a cache, and clear entries in it 24 if they have not been used in a certain period of time. Note by the way that ARP requests must be sent as "broadcasts". There is no way that an ARP request can be sent directly to the right system. After all, the whole reason for sending an ARP request is that you don't know the Ethernet address. So an Ethernet address of all ones is used, i.e. ff:ff:ff:ff:ff:ff. By convention, every machine on the Ethernet is required to pay attention to packets with this as an address. So every system sees every ARP requests. They all look to see whether the request is for their own address. If so, they respond. If not, they could just ignore it. (Some hosts will use ARP requests to update their knowledge about other hosts on the network, even if the request isn't for them.) Note that packets whose IP address indicates broadcast (e.g. 255.255.255.255 or 128.6.4.255) are also sent with an Ethernet address that is all ones. 10. Getting more information This directory contains documents describing the major protocols. There are literally hundreds of documents, so we have chosen the ones that seem most important. Internet standards are called RFC's. RFC stands for Request for Comment. A proposed standard is initially issued as a proposal, and given an RFC number. When it is finally accepted, it is added to Official Internet Protocols, but it is still referred to by the RFC number. We have also included two IEN's. (IEN's used to be a separate classification for more informal documents. This classification no longer exists -- RFC's are now used for all official Internet documents, and a mailing list is used for more informal reports.) The convention is that whenever an RFC is revised, the revised version gets a new number. This is fine for most purposes, but it causes problems with two documents: Assigned Numbers and Official Internet Protocols. These documents are being revised all the time, so the RFC number keeps changing. You will have to look in rfc-index.txt to find the number of the latest edition. Anyone who is seriously interested in TCP/IP should read the RFC describing IP (791). RFC 1009 is also useful. It is a specification for gateways to be used by NSFnet. As such, it contains an overview of a lot of the TCP/IP technology. You should probably also read the description of at least one of the application protocols, just to get a feel for the way things work. Mail is probably a good one (821/822). TCP (793) is of course a very basic specification. However the spec is fairly complex, so you should only read this when you have the time and patience to think about it carefully. Fortunately, the author of the major RFC's (Jon Postel) is a very good writer. The TCP RFC is far easier to read than you would expect, given the complexity of what it is describing. You can look at the other RFC's as you become curious about their subject matter. Here is a list of the documents you are more likely to want: rfc-index list of all RFC's 25 rfc1012 somewhat fuller list of all RFC's rfc1011 Official Protocols. It's useful to scan this to see what tasks protocols have been built for. This defines which RFC's are actual standards, as opposed to requests for comments. rfc1010 Assigned Numbers. If you are working with TCP/IP, you will probably want a hardcopy of this as a reference. It's not very exciting to read. It lists all the offically defined well-known ports and lots of other things. rfc1009 NSFnet gateway specifications. A good overview of IP routing and gateway technology. rfc1001/2 netBIOS: networking for PC's rfc973 update on domains rfc959 FTP (file transfer) rfc950 subnets rfc937 POP2: protocol for reading mail on PC's rfc894 how IP is to be put on Ethernet, see also rfc825 rfc882/3 domains (the database used to go from host names to Internet address and back -- also used to handle UUCP these days). See also rfc973 rfc854/5 telnet - protocol for remote logins rfc826 ARP - protocol for finding out Ethernet addresses rfc821/2 mail rfc814 names and ports - general concepts behind well-known ports rfc793 TCP rfc792 ICMP rfc791 IP rfc768 UDP rip.doc details of the most commonly-used routing protocol ien-116 old name server (still needed by several kinds of system) ien-48 the Catenet model, general description of the 26 philosophy behind TCP/IP The following documents are somewhat more specialized. rfc813 window and acknowledgement strategies in TCP rfc815 datagram reassembly techniques rfc816 fault isolation and resolution techniques rfc817 modularity and efficiency in implementation rfc879 the maximum segment size option in TCP rfc896 congestion control rfc827,888,904,975,985 EGP and related issues To those of you who may be reading this document remotely instead of at Rutgers: The most important RFC's have been collected into a three-volume set, the DDN Protocol Handbook. It is available from the DDN Network Information Center, SRI International, 333 Ravenswood Avenue, Menlo Park, California 94025 (telephone: 800-235-3155). You should be able to get them via anonymous FTP from sri-nic.arpa. File names are: RFC's: rfc:rfc-index.txt rfc:rfcxxx.txt IEN's: ien:ien-index.txt ien:ien-xxx.txt rip.doc is available by anonymous FTP from topaz.rutgers.edu, as /pub/tcp-ip-docs/rip.doc. Sites with access to UUCP but not FTP may be able to retreive them via UUCP from UUCP host rutgers. The file names would be RFC's: /topaz/pub/pub/tcp-ip-docs/rfc-index.txt /topaz/pub/pub/tcp-ip-docs/rfcxxx.txt IEN's: /topaz/pub/pub/tcp-ip-docs/ien-index.txt /topaz/pub/pub/tcp-ip-docs/ien-xxx.txt /topaz/pub/pub/tcp-ip-docs/rip.doc Note that SRI-NIC has the entire set of RFC's and IEN's, but rutgers and topaz have only those specifically mentioned above. 27 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707031252.AA19327@ucbvax.Berkeley.EDU] <1987070304532600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jon@CS.UCL.AC.UK (Jon Crowcroft) Newsgroups: comp.protocols.tcp-ip Subject: Asyncio on Sockets Message-ID: <8707031252.AA19327@ucbvax.Berkeley.EDU> Date: Fri, 3-Jul-87 08:53:26 EDT Article-I.D.: ucbvax.8707031252.AA19327 Posted: Fri Jul 3 08:53:26 1987 Date-Received: Sat, 4-Jul-87 13:14:07 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 13 I know this is a Unix question and not really appropriate here, but Berkeley and Sun people seem to read this list a lot. Has anyone found problems setting async io on a RAW IP socket? Under 3.2 on a Sun, it just doesn't seem to work; at least I never get a SIGIO even when I see packets (using a net wathcer) arriving at the machine. The manual pages and tutorials are somewhat thin in this area. Also, when using asyncio on a UDP socket, the process doesn't get a SIGIO unless it has had another signal first. Jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987070306391200> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Fri 3 Jul 87 10:37:41-PDT To: Mills@LOUIE.UDEL.EDU cc: tcp-ip@SRI-NIC.ARPA, ineng-tf@VENERA.ISI.EDU, nsfnet@SH.CS.NET, brescia@CCV.BBN.COM Subject: Re: Chrenobyl revisited In-reply-to: Your message of Tue, 30 Jun 87 02:22:54 -0400. <8706300222.a002889@Huey.UDEL.EDU> Date: Fri, 03 Jul 87 13:19:12 -0400 From: Mike Brescia Beginning sometime on Tuesday, apparent (very real, in fact) meltdown of routing seems to have been caused by: 1. frequent making and breaking of egp neighbor connections, due to 2. frangible egp neighbor-alive procedures or parameters, shattered by 3. long queues (or short queues and many dropped packets) on interfaces connected to the arpanet, because of 4. changes in arpanet topology and delay characteristics. Each change in neighborliness leads to routing changes in EGP which propogate at one hop per 2(?) minutes, and in GGP (the core routing) cause burgeoning of traffic as the protocol scurries to get the routing settled again. The core gateways were being rejected (EGP cease message sent) by many of the neighbors on the arpanet, and then later acquired again. This may have been caused by long queues on the sending end toward the core gateway, or by the long queues frequently observed in the core gateways. Thursday afternoon, the arpanet problem was cleared up. I think the routing explosion has settled to a dull roar after that. I expect that the arpanet analysts will have a description of the problem and its solution after the holiday. Mike Brescia (Gateway group) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707031135.a008342@Huey.UDEL.EDU] <1987070307350100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Chrenobyl revisited Message-ID: <8707031135.a008342@Huey.UDEL.EDU> Date: Fri, 3-Jul-87 11:35:01 EDT Article-I.D.: Huey.8707031135.a008342 Posted: Fri Jul 3 11:35:01 1987 Date-Received: Sat, 4-Jul-87 13:32:15 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 16 Peter, Welcome to the swamps. If your gateway is peeping EGP with the core, you will see a lot of this. The stuff I see sloshing by linkabit-gw is truly awsome and includes many instances like yours. Even after I disabled all reachability to all nets from that gateway for several hours various hosts and gateways continued to route traffic for j-random nets via it. Not knowing whether the senders were hosts or gateways, linkabit-gw spat back redirects, but few seemed to believe them (probably gateways masked in host clothing). In spite of the fact the core gateways (for the moment) correctly reveal the routes for that gateway, about two packets per second averaged throughout the day are being routed incorrectly to linkabit-gw. See what you might be in for? Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707031752.AA22798@ucbvax.Berkeley.EDU] <1987070309535900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@CCV.BBN.COM (Mike Brescia) Newsgroups: comp.protocols.tcp-ip Subject: Re: Chrenobyl revisited Message-ID: <8707031752.AA22798@ucbvax.Berkeley.EDU> Date: Fri, 3-Jul-87 13:53:59 EDT Article-I.D.: ucbvax.8707031752.AA22798 Posted: Fri Jul 3 13:53:59 1987 Date-Received: Sat, 4-Jul-87 13:51:09 EDT References: <8706300222.a002889@Huey.UDEL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 31 Beginning sometime on Tuesday, apparent (very real, in fact) meltdown of routing seems to have been caused by: 1. frequent making and breaking of egp neighbor connections, due to 2. frangible egp neighbor-alive procedures or parameters, shattered by 3. long queues (or short queues and many dropped packets) on interfaces connected to the arpanet, because of 4. changes in arpanet topology and delay characteristics. Each change in neighborliness leads to routing changes in EGP which propogate at one hop per 2(?) minutes, and in GGP (the core routing) cause burgeoning of traffic as the protocol scurries to get the routing settled again. The core gateways were being rejected (EGP cease message sent) by many of the neighbors on the arpanet, and then later acquired again. This may have been caused by long queues on the sending end toward the core gateway, or by the long queues frequently observed in the core gateways. Thursday afternoon, the arpanet problem was cleared up. I think the routing explosion has settled to a dull roar after that. I expect that the arpanet analysts will have a description of the problem and its solution after the holiday. Mike Brescia (Gateway group) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [585@houxa.UUCP] <1987070311152700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mel1@houxa.UUCP (M.HAAS) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Smart Ethernet boards Message-ID: <585@houxa.UUCP> Date: Fri, 3-Jul-87 15:15:27 EDT Article-I.D.: houxa.585 Posted: Fri Jul 3 15:15:27 1987 Date-Received: Sat, 4-Jul-87 14:38:27 EDT References: <283@sering.cwi.nl> <8212@utzoo.UUCP> <17346@amdcad.AMD.COM> <365@parcvax.Xerox.COM> Organization: AT&T Bell Laboratories, Holmdel Lines: 23 I think there are two performance factors to consider. If one wants to devote CPU cycles to Ethernet processing, then an off-board TCP/IP makes sense and high network traffic rates can be achieved. If the CPU is already burdened by having to handle too many time-share users or by just being too small, then an on-board TCP/IP makes sense (with network traffic rates limited by the board/CPU combination's power). If the on-board TCP/IP imposes more load on the CPU than an off-board TCP/IP, then something is radically wrong with the design. If anyone has evidence of such a situation, please post it here so we can avoid purchasing that board. For small systems with 80386 and 68020 class CPUs, I would think that an on-board TCP/IP with similar CPU and decent memory buffers would give optimum performance. Does anyone have figures or thoughts as to what impedes performance? One article here commented on the multiple copies being made of the data being transferred. Is that necessary or desirable? Couldn't the on-board TCP/IP processor just handle the headers on the board and DMA the data to/from user's I/O space? (i.e. no copying, just pointer shuffling) Are there TCP/IP implementations that do this? Mel Haas , odyssey!mel ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707040011.a014183@Huey.UDEL.EDU] <1987070320115500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Chrenobyl revisited Message-ID: <8707040011.a014183@Huey.UDEL.EDU> Date: Sat, 4-Jul-87 00:11:55 EDT Article-I.D.: Huey.8707040011.a014183 Posted: Sat Jul 4 00:11:55 1987 Date-Received: Sat, 4-Jul-87 17:22:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 45 Mike, I'm not sure I agree with your comment that the non-core EGP gateways are terminating associations with the core gateways; in fact, I believe it's the other way around. Following is a summary of data collected over a 36-hour interval from old fuzzball EGP slugger dcn-gw, which ordinarily sustains associations with all three core EGPspeakers ISI [10.3.0.27], BBN2 [10.7.0.63] and PURDUE [10.2.0.37]. As specified in the initial dialog, the hello interval is 60 seconds, while the poll interval is 180 seconds. The table below shows the events and actions of the state machine for each peer as specified in RFC-904. A Cease event represents a termination on the part of the core gateway, while a Cease action represents a termination on the part of dcn-gw, almost always as the result of an extended period when no messages whatsoever have been received. As can be seen, the core gateway terminates the association between two and four times as often as dcn-gw. Hello interval 60 Poll interval 180 Neighbor -> [10.3.0.27] [10.7.0.63] [10.2.0.37] Tally Event Action Event Action Event Action -------------------------------------------------------------- Request 0 65 0 8 0 36 Confirm 29 0 5 0 19 0 Refuse 2 0 0 0 0 0 Cease 26 9 3 1 16 4 Cease-ack 4 26 1 3 2 16 Hello 0 2172 0 2284 0 2232 I-H-U 1568 0 1904 0 1735 0 Poll 699 609 829 741 750 667 Update 532 669 656 824 604 736 Down 221 52 123 Bad sequence 151 129 148 Note the rather high incidence of Down events. Using the j,k parameters suggested in RFC-904 and the 60-second hello interval, a Down event would occur if three out of four reachability indications during the last four minutes were lost. This sounds rather extreme. Note also the rather high incidence of Bad sequence events, which occur when a reply to a hello message has incorrect sequence number and is discarded. There is a strong argument for ignoring the sequence-number check, since the order of reachability events is seldom meaningful. It may be useful in the present regime of positive network void coefficents to do that to avoid further meltdown. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707021834.AA03576@dbnet.cs.washington.edu] <1987070406570700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: randy@DBNET.CS.WASHINGTON.EDU (Randy Day) Newsgroups: comp.protocols.tcp-ip Subject: Re: IP options implementation Message-ID: <8707021834.AA03576@dbnet.cs.washington.edu> Date: Sat, 4-Jul-87 10:57:07 EDT Article-I.D.: dbnet.8707021834.AA03576 Posted: Sat Jul 4 10:57:07 1987 Date-Received: Sat, 4-Jul-87 20:00:49 EDT References: <8707021807.AA00878@ward.cs.washington.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 28 Been looking at this code in the last few days myself. I've been looking at the 4.2BSD and 4.3BSD implementations of ip_output() in /sys/netinet/ip_output.c. As far as I can tell (and I feel fairly confident about this), the 4.2BSD code just ignores any options passed to the ip_output routine. The 4.3 code replaces the initial call to m_free(opt) with if (opt) m = ip_insertoptions(m, opt, &hlen); Where ip_insertopitons() is a new function that does about what you would expect: it inserts mbufs containing the options in the data about to blasted out over the net. The 4.3BSD "Changes to the Kernel in 4.3BSD" manual section says: "Support was added for IP source routing and other IP options....IP properly updates source-route and record-route options when forwarding (and leaves them in the packet, unlike 4.2 which stripped them out after updating)." The 4.2BSD networking code is brain damaged, and would certainly not pass even the most modest validation suite if one existed for TCP/IP implementations. Randy Day. Internet (ARPA): randy@dbnet.cs.washington.edu CSNET: randy%washington@relay.cs.net UUCP: {decvax|ihnp4}!uw-beaver!uw-june!randy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707041529.AA24545@lbl-csam.arpa] <1987070407294900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: van@LBL-CSAM.ARPA (Van Jacobson) Newsgroups: comp.protocols.tcp-ip Subject: Re: IP options implementation Message-ID: <8707041529.AA24545@lbl-csam.arpa> Date: Sat, 4-Jul-87 11:29:49 EDT Article-I.D.: lbl-csam.8707041529.AA24545 Posted: Sat Jul 4 11:29:49 1987 Date-Received: Sat, 4-Jul-87 20:08:31 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 31 >Why didn't Berkeley implement the security option? Those of us selling systems >to the DOD need to add it anyway and it would probably be nice if a common >implementation across all users of 4.3BSD TCP existed. Why do I care? The >security option requires some user space changes to programs like FTP and >TELNET besides just kernel changes. The part of the security option ftp & telnet need is implemented in 4.3. User level programs can stick a security option on any TCP, UDP or IP socket. The option will be tacked onto every IP datagram sent on that socket. The code to do this looks something like /* format a legal security option in a 12 byte array */ ipopt[IPOPT_OPTVAL] = IPOPT_SECURITY; ipopt[IPOPT_OLEN] = 11; ... ipopt[11] = IPOPT_NOP; /* pad */ /* put the option on socket "s" */ if (setsockopt(s, IPPROTO_IP, IP_OPTIONS, ipopt, 12) < 0) perror ("setsockopt:ipopt:"); On the incoming side, 4.3 ip ignores the security option and 4.3 tcp discards it. But the option is passed intact up to the tcp layer and it would be trivial to change tcp_input to process it (If you were trying to make a secure Unix, you'd be re-writing the kernel. This change would be the least of your worries and, anyway, it couldn't be done until the rest of the system security model was in place.) - Van ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707041608.AA08157@ucbvax.Berkeley.EDU] <1987070407464200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: Re: connection establish timeout query Message-ID: <8707041608.AA08157@ucbvax.Berkeley.EDU> Date: Sat, 4-Jul-87 11:46:42 EDT Article-I.D.: ucbvax.8707041608.AA08157 Posted: Sat Jul 4 11:46:42 1987 Date-Received: Sat, 4-Jul-87 20:09:01 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 37 Mike and David, You are asking a question that covers many sins. The usual numbers for "open connection" timeouts range from 30-120 seconds. If you are using numbers much smaller than these you wil see lots of timeouts. The problem of selcting the "right" timeout is a bit complex because of what you (the initiator) might be trying to accomplish. E.g., if it is a Telnet session then the user is a human and can abort the (presumably hopeless) connection attempt by some local action (escape character or its functional equivalent on each system -- if you don't have the equivalent of an "interrupt now" initiated by the user from the keyboard, then...) so you may as well select a long timeout (2 minutes) and let the connection get established if at all possible. The same goes for FTP because it is user initiated. However, for mail (SMTP) things can get different. It is usually implemented as a background process that slurps over the file system looking for mail files to send out. If this SMTP process uses a long timeout and it runs into a bunch of mail for a dead site it has to get smart about what is (not) happening and not spend a lot of time waiting for a connection to the dead host. Thus a short timeout (30 seconds) might be in order. Big systems that do lots of mail have had to take more hurculean efforts in this arena, like running a number of SMTP mail processes in parallel and having some scheme for staying out of each other's way... The reason for along timeout can lie with many sources: the local host might not have a good retransmission timout for the original "open packet", the network(s) may be congested, or the remote host may take some time to set up a process to respond to the open request. Anyway, the major crime is to have client programs choosing a timeout that is smaller than the retransmission timeout that the TCP is using to detect a lost packet and try the open SYN again. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987070407464201> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sat 4 Jul 87 08:49:05-PDT Date: 4 Jul 1987 11:46:42 EDT Subject: Re: connection establish timeout query From: Dan Lynch To: Mike Brescia cc: tcp-ip@SRI-NIC.ARPA, kirschen%multimax.arpa@CCV.BBN.COM, LYNCH@A.ISI.EDU In-Reply-To: (Message from "Mike Brescia " of Thu, 02 Jul 87 11:53:33 -0400) Mike and David, You are asking a question that covers many sins. The usual numbers for "open connection" timeouts range from 30-120 seconds. If you are using numbers much smaller than these you wil see lots of timeouts. The problem of selcting the "right" timeout is a bit complex because of what you (the initiator) might be trying to accomplish. E.g., if it is a Telnet session then the user is a human and can abort the (presumably hopeless) connection attempt by some local action (escape character or its functional equivalent on each system -- if you don't have the equivalent of an "interrupt now" initiated by the user from the keyboard, then...) so you may as well select a long timeout (2 minutes) and let the connection get established if at all possible. The same goes for FTP because it is user initiated. However, for mail (SMTP) things can get different. It is usually implemented as a background process that slurps over the file system looking for mail files to send out. If this SMTP process uses a long timeout and it runs into a bunch of mail for a dead site it has to get smart about what is (not) happening and not spend a lot of time waiting for a connection to the dead host. Thus a short timeout (30 seconds) might be in order. Big systems that do lots of mail have had to take more hurculean efforts in this arena, like running a number of SMTP mail processes in parallel and having some scheme for staying out of each other's way... The reason for along timeout can lie with many sources: the local host might not have a good retransmission timout for the original "open packet", the network(s) may be congested, or the remote host may take some time to set up a process to respond to the open request. Anyway, the major crime is to have client programs choosing a timeout that is smaller than the retransmission timeout that the TCP is using to detect a lost packet and try the open SYN again. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707041947.AA26543@topaz.rutgers.edu] <1987070411474500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: IP options implementation Message-ID: <8707041947.AA26543@topaz.rutgers.edu> Date: Sat, 4-Jul-87 15:47:45 EDT Article-I.D.: topaz.8707041947.AA26543 Posted: Sat Jul 4 15:47:45 1987 Date-Received: Sat, 4-Jul-87 20:46:47 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 4 Because nobody at the time had any idea what you would use the security option for. -R t ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707050126.AA13137@ucbvax.Berkeley.EDU] <1987070417274900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@CCV.BBN.COM (Mike Brescia) Newsgroups: comp.protocols.tcp-ip Subject: connection establish timeout query Message-ID: <8707050126.AA13137@ucbvax.Berkeley.EDU> Date: Sat, 4-Jul-87 21:27:49 EDT Article-I.D.: ucbvax.8707050126.AA13137 Posted: Sat Jul 4 21:27:49 1987 Date-Received: Sun, 5-Jul-87 02:40:55 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 22 I would interpret this question as "What should the open timeout be for telnet, ftp, and mail user and server programs?" What sort of numbers are used in the software? mike ---- forwarded message ---- Received: by multimax.ARPA (4.12/25-eef) id AA02553; Wed, 1 Jul 87 09:02:23 edt Date: Wed, 1 Jul 87 09:02:23 edt From: David Kirschen Message-Id: <8707011302.AA02553@multimax.ARPA> Subject: Arpanet Timeouts Hi - Could you tell me if there is a way to determine if we are seeing a reasonable number of connection timeouts over the Arpanet? We get lots of connections failing, for various applications (mail, ftp, telnet). We'd like to know what the commonly used timeout constant is (i.e., how long should it take when establishing a connection before the initiator just gives up?). Thanks !! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870705025745.0a3@Sds.Sdsc.Edu] <1987070418574400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gkn@SDS.SDSC.EDU Newsgroups: comp.protocols.tcp-ip Subject: RE: Mac/Ip Message-ID: <870705025745.0a3@Sds.Sdsc.Edu> Date: Sat, 4-Jul-87 22:57:44 EDT Article-I.D.: Sds.870705025745.0a3 Posted: Sat Jul 4 22:57:44 1987 Date-Received: Sun, 5-Jul-87 03:19:30 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 40 From: Henry Nussbacher Subject: Mac/Ip Date: Thu, 25 Jun 87 10:34:42 P Can someone fill me in on the latest on Mac/Ip - does it support Ethernet directly or does one still need a gateway between an Appletalk LAN to Ethernet? Does it support FTP, Telnet and SMTP? The version of MAC-IP I have supports ethernet communications through one of two boxes manufactured by Kinetics in Walnut Creek. The first (and older) of these two boxes is called the FastPath, and is capable of acting as bridge between Appletalk and ethernet. It can operate in a pure-Appletalk mode, or it can operate in a combined Appletalk and "user datagram" mode, which lets it carry IP. One FastPath can serve several MACs connected to an Appletalk network. The second box is called the EtherSC, and connects a MAC directly up to thinwire ethernet via the SCSI port. So far I only have it carrying IP traffic. There is one EtherSC per MAC, and the EtherSC is considerably cheaper than the FastPath. The heritage of the TCP code I'm using is a bit fuzzy, so I'm reluctant to comment on it for fear of being wrong. However, there is an excellent TELNET/FTP server program available from NCSA (National Center for Supercomputing Applications) at the University of Illinois. Contact Gaige Paulson there for more information. There's no SMTP support that I'm aware of ... but if anyone knows of something I'd sure like to hear about it. gkn -------------------------------------- Arpa: GKN@SDS.SDSC.EDU Bitnet: GKN@SDSC Span: SDSC::GKN (27.1) USPS: Gerard K. Newman San Diego Supercomputer Center P.O. Box 85608 San Diego, CA 92138 AT&T: 619.534.5076 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2364@hoptoad.uucp] <1987070419311300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gnu@hoptoad.uucp (John Gilmore) Newsgroups: comp.protocols.tcp-ip Subject: Re: IP options implementation Message-ID: <2364@hoptoad.uucp> Date: Sat, 4-Jul-87 23:31:13 EDT Article-I.D.: hoptoad.2364 Posted: Sat Jul 4 23:31:13 1987 Date-Received: Sun, 5-Jul-87 05:36:27 EDT References: <8706301311.AA01944@gswd-vms.Gould.COM> Organization: Nebula Consultants in San Francisco Lines: 13 tucker%mycroft@gswd-vms.Gould.COM (Tim Tucker) wrote: > Why didn't Berkeley implement the security option? Those of us selling systems > to the DOD need to add it anyway and it would probably be nice if a common > implementation across all users of 4.3BSD TCP existed. I have an idea -- why doesn't Gould implement it, and post the changes to the net, or send them to Berkeley? You seem to be the first to need it, and making it available for free, like Berkeley did with the whole protocol implementation, makes it likely that "a common implementation across all users" will exist. -- {dasys1,ncoast,well,sun,ihnp4}!hoptoad!gnu gnu@ingres.berkeley.edu Alt.all: the alternative radio of the Usenet. Contributions welcome - post 'em ----MESSAGE-END---- ----MESSAGE-BEGIN---- [834@mcgill-vision.UUCP] <1987070420192300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mouse@mcgill-vision.UUCP (der Mouse) Newsgroups: comp.unix.wizards,comp.protocols.tcp-ip Subject: Re: Serial Line IP and ULTRIX-32 2.0 Message-ID: <834@mcgill-vision.UUCP> Date: Sun, 5-Jul-87 00:19:23 EDT Article-I.D.: mcgill-v.834 Posted: Sun Jul 5 00:19:23 1987 Date-Received: Sat, 11-Jul-87 00:49:33 EDT References: <662@moogvax.UUCP> <1358@decuac.DEC.COM> Organization: McGill University, Montreal Lines: 62 In article <1358@decuac.DEC.COM>, avolio@decuac.dec.com (Fred Avolio) writes: > In article <662@moogvax.UUCP>, dave@moogvax.UUCP (Dave Szczepanski) writes: >> [I]s it possible to install [SLIP] if you are binary site. > I see no easy way to install it with a binary kit since you need to > modify init_main, Fortunately it *is* possible. It is not especially easy, and it is a dreadful hack, but until we manage to stamp out binary distributions this trick may come in handy to someone. What we do is to patch the "_loattach" symbol in the init_main.o symbol table to something like "_F_Avolio" (Hi Fred!) and then configure in a file containing something like the following (or add it to an existing file we have source to): F_Avolio() { do_whatever_we_want(); loattach(); } (Why F_Avolio? No particular reason. You can use derMouse if you'd rather - Fred might even prefer you did :-). Anything the same length as "loattach" will do perfectly well, provided it doesn't conflict with anything already present in the kernel.) How do we patch the symbol table? Assuming a normal Ultrix system, # strings - -o init_main.o | egrep _loattach 1234 _loattach # adb -w init_main.o init_main.o 0t1234/S 4d2: _loattach .+1/W 'vA_F' 4d3: 74616f6c = 76415f46 0t1234/S 4d2: _F_Avtach .+5/W 'oilo' 4d7: 68636174 = 6f696c6f 0t1234/S 4d2: _F_Avolio $q # We give adb the file name twice so we can use the offset strings gave us: since the file is an a.out, adb does address mapping for a.outs, which is good in general, but doesn't help here, so we get around by giving the filename twice and using the / forms of the examine and deposit commands. You can also do this by using $m and a little arithmetic, but it's much simpler to just do the above. It works because the .o file is not a valid core image, so adb doesn't do its address mapping for the / command forms. (F_Av and olio are spelled backwards because adb is too dumb to fix the order of the characters in 'xxxx' constants.) If you do try this, I MOST STRONGLY urge you to keep backup copies of EVERYTHING you touch! der Mouse (mouse@mcgill-vision.uucp) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987070522440000> Mail-From: STJOHNS created at 6-Jul-87 05:45:27 Date: 6 Jul 1987 05:44-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: IP options implementation From: STJOHNS@SRI-NIC.ARPA To: van@LBL-CSAM.ARPA Cc: TCP-IP@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA] 6-Jul-87 05:44:11.STJOHNS> In-Reply-To: <8707041529.AA24545@lbl-csam.arpa> For single level systems (those evaluated at less than B2), the only place you need to deal with the IP security option is at the IP level. You need to have a configuration item which sets the level of your system. This must be reflected in the outgoing packets, and muct also be checked in the incomoing packets. Incoming packets without the proper security option in them must be logged and dropped. (Err, this is what the rules say, if I were imple,menting this, I'd add a configuration item for dropping non-compliant incoming datagrams and leave it off until you connect to BLACKER, or are reasonably certain everyone else is in compliance.) By the way, which IP security option is everyone out there concerned about? The one in the RFC? If so, hang on to your horses. You might want to take a look at the revised IPSO in [NIC]ps:ipso.txt. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[SRI-NIC.ARPA].6-Jul-87.05:44:11.STJOHNS] <1987070604440000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: STJOHNS@SRI-NIC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: IP options implementation Message-ID: <[SRI-NIC.ARPA].6-Jul-87.05:44:11.STJOHNS> Date: Mon, 6-Jul-87 08:44:00 EDT Article-I.D.: <[SRI-NIC.ARPA].6-Jul-87.05:44:11.STJOHNS> Posted: Mon Jul 6 08:44:00 1987 Date-Received: Tue, 7-Jul-87 05:19:13 EDT References: <8707041529.AA24545@lbl-csam.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 For single level systems (those evaluated at less than B2), the only place you need to deal with the IP security option is at the IP level. You need to have a configuration item which sets the level of your system. This must be reflected in the outgoing packets, and muct also be checked in the incomoing packets. Incoming packets without the proper security option in them must be logged and dropped. (Err, this is what the rules say, if I were imple,menting this, I'd add a configuration item for dropping non-compliant incoming datagrams and leave it off until you connect to BLACKER, or are reasonably certain everyone else is in compliance.) By the way, which IP security option is everyone out there concerned about? The one in the RFC? If so, hang on to your horses. You might want to take a look at the revised IPSO in [NIC]ps:ipso.txt. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [17001.552573412@gremlin.nrtc.northrop.com] <1987070604523900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mrose@GREMLIN.NRTC.NORTHROP.COM (Marshall Rose) Newsgroups: comp.protocols.tcp-ip Subject: Re: status of POP Message-ID: <17001.552573412@gremlin.nrtc.northrop.com> Date: Mon, 6-Jul-87 08:52:39 EDT Article-I.D.: gremlin.17001.552573412 Posted: Mon Jul 6 08:52:39 1987 Date-Received: Tue, 7-Jul-87 01:56:26 EDT References: <56@laura.irb.informatik> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 24 Well, being Marshall T. Rose, I guess I should respond. There are several POP protocols. As to which one is the official one, that's a good question. The original POP was done at USC/ISI. The people working on MH liked this quite a bit but weren't able to quite implement it, so I did an alternate service/protocol specification and put that in MH. Shortly thereafter, USC/ISI came out with POP2, which pretty much fixed all the problems in the original POP. For reasons not worth going into, MH's POP and ISI's POP2 never merged, so future POP work in MH used MH's POP. This future work included support for remote BBoards (which you can also get with NNTP, I think) and support for Stanford's version of MH for the PC. About 10 months ago, the parties involved were supposed to get together and solve this problem (multiple versions), but we never got around to it. Hence the current situation. The question as to which version is official and which version(s) are useful, being widely implemented, is problematic. The original POP is history. That leaves POP2 and MH's POP. /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707061258.AA00354@multimax.ARPA] <1987070604584900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kirschen@MULTIMAX.ARPA (David Kirschen) Newsgroups: comp.protocols.tcp-ip Subject: connection establish timeout query Message-ID: <8707061258.AA00354@multimax.ARPA> Date: Mon, 6-Jul-87 08:58:49 EDT Article-I.D.: multimax.8707061258.AA00354 Posted: Mon Jul 6 08:58:49 1987 Date-Received: Tue, 7-Jul-87 02:52:41 EDT References: <8707031201.AA01847@multimax.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 35 Date: Thu, 02 Jul 87 11:53:33 -0400 From: Mike Brescia Mike, thanks for getting back to me. I'm not sure what timeout values we are currently using here - that's why I asked the question. Do you have a feel for what is "common" around the Arpanet ? I would expect that about the same timeout limits are used almost everywhere, and I'd like to know what those values are. We understand that the timeout's are determined by the software, and we just want to see if we are "in the ballpark" compared to other sites. Thanks again! ---------------------- I would interpret this question as "What should the open timeout be for telnet, ftp, and mail user and server programs?" What sort of numbers are used in the software? mike ---- forwarded message ---- Received: by multimax.ARPA (4.12/25-eef) id AA02553; Wed, 1 Jul 87 09:02:23 edt Date: Wed, 1 Jul 87 09:02:23 edt From: David Kirschen Message-Id: <8707011302.AA02553@multimax.ARPA> Subject: Arpanet Timeouts Hi - Could you tell me if there is a way to determine if we are seeing a reasonable number of connection timeouts over the Arpanet? We get lots of connections failing, for various applications (mail, ftp, telnet). We'd like to know what the commonly used timeout constant is (i.e., how long should it take when establishing a connection before the initiator just gives up?). Thanks !! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987070605190000> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Mon 6 Jul 87 16:13:39-PDT Received: from YMIR.BITNET by wiscvm.wisc.edu ; Mon, 06 Jul 87 18:13:07 CDT Received: from ENGVAX.SCG.HAC.COM by YMIR.BITNET; Mon, 6 Jul 87 16:11 PDT Date: Mon, 6 Jul 87 12:19 PDT From: Kevin Carosso <@YMIR.BITNET:KVC@ENGVAX.SCG.HAC.COM> Subject: Re: DECnet-TCP/IP gateway To: tcp-ip@sri-nic.ARPA X-VMS-To: IN%"tcp-ip@sri-nic.arpa" > Looking for gateway software, preferably layered atop Wollongong, > for a MicroVax. In and out via shared DEQNA. > Mail is the biggest need. FTP strongly desired. Telnet desired, > but let's be realistic. > Charles Bacon, CRB@NIHCUDEC (bitnet) As far as mail goes, you could run the PMDF mail system which supports Wollongong and DECnet channels (also bitnet, phonenet, and others). Contact Ned Freed at Harvey Mudd College for more info (714) 621-8006. /Kevin Carosso kvc@engvax.scg.hac.com Hughes Aircraft Co. kvc%engvax@oberon.usc.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987070606524700> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Mon 6 Jul 87 09:15:48-PDT Received: from SUVM.BITNET by wiscvm.wisc.edu ; Mon, 06 Jul 87 10:55:07 CDT Received: by SUVM (Mailer X1.23b) id 5767; Mon, 06 Jul 87 11:56:26 LCL Date: Mon, 6 Jul 1987 11:52:47 LCL From: John M. Wobus To: IBM-NETS@BITNIC, TCP-IP Discussion Group , Monthly guide to BITNET Servers and Services , IBM7171@MARIST, Proteon P4200 Gateway Discussion , INFO-PROTEON@UXC.CSO.UIUC.EDU Subject: New mailing list. I am starting a new mailing list on LAN issues for large campus networks (e.g. multiprotocol, multivendor, etc). See blurb below. Please excuse this message if you've already received it through another list. John Wobus Syracuse University ------------------------------- BIG-LAN@SUVM (Bitnet) (Internet) This list is for the discussion of issues in designing and operating Campus-Size Local Area Networks, especially complex ones utilizing multiple technologies and supporting multiple protocols. Topics include repeaters, bridges, routers and gateways; how to incorporate smaller Personal-Computer type LANs into the campus-wide LAN; how to unify the mail systems, etc. This is an ideal list in which to debate the relative merits of bridges vs routers. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to BIG-REQ@SUVM (Bitnet) or (Internet). Those familiar with revised LISTSERV can subscribe with LISTSERV@SUVM (Bitnet) or (Internet). Archives are available through revised LISTSERV. Coordinator: John Wobus ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987070607190000> Received: from afsc-sd.arpa by SRI-NIC.ARPA with TCP; Mon 6 Jul 87 14:37:27-PDT Date: 6 Jul 87 14:19:00 MST From: "HOLT JC SSGT DOASS 32254" Subject: Wollongong TALKING to DEC-20's To: "tcp-ip" Reply-To: "HOLT JC SSGT DOASS 32254" I N T E R O F F I C E M E M O R A N D U M Date: 6-Jul-1987 13:58 PST From: Jack C. Holt, SSgt HOLTJ Dept: 2080CS/DOAS Tel No: 643-2254 TO: _MAILER! ( _DDN[MRC%PANDA.COM@SUMEX-AIM.STANFORD.EDU] ) TO: _MAILER! ( _DDN[TCP-IP@SRI-NIC.ARPA] ) CC: TSgt Thomas ( THOMASJR ) CC: Communications Administration ( COMADM ) CC: DANAHY, DANIEL J. ( DANAHY ) Subject: Wollongong "talking" to DEC-20's This is in reference to your message to TCP-IP@SRI-NIC.arpa on 6 July 87 concerning the subject. Could you be more specific about some of the problems people are having? We have also experienced problems talking to at least some DEC-20's and are running Wollongong's WIN/TCP version 3.0 on a VAX 11/785. We have unexplained instances of undeliverable mail when trying to send mail to SRI-NIC.arpa and GUNTER-ADAM.arpa. We are also experiencing "Connection Refused..." errors when using GETTABLE to retrieve the HOST table from SRI-NIC.arpa. ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [863@geac.UUCP] <1987070607403200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: daveb@geac.UUCP (Dave Brown) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Smart Ethernet boards Message-ID: <863@geac.UUCP> Date: Mon, 6-Jul-87 11:40:32 EDT Article-I.D.: geac.863 Posted: Mon Jul 6 11:40:32 1987 Date-Received: Tue, 7-Jul-87 01:17:50 EDT References: <283@sering.cwi.nl> <8212@utzoo.UUCP> <17346@amdcad.AMD.COM> <365@parcvax.Xerox.COM> <585@houxa.UUCP> Reply-To: daveb@geac.UUCP (Dave Brown) Organization: The little blue rock next to that twinkly star Lines: 32 Summary: a side comment re programmability In article <585@houxa.UUCP> mel1@houxa.UUCP (M.HAAS) writes: >For small systems with 80386 and 68020 class CPUs, I would think that >an on-board TCP/IP with similar CPU and decent memory buffers would give >optimum performance. Does anyone have figures or thoughts as to what >impedes performance? One article here commented on the multiple >copies being made of the data being transferred. Is that necessary >or desirable? Couldn't the on-board TCP/IP processor just handle >the headers on the board and DMA the data to/from user's I/O space? > > Mel Haas , odyssey!mel A side point that might be of interest here: "an on-board TCP/IP with similar CPU and decent memory buffers would give optimum performance" implies that the TCP/IP board could be programmed from the host. If you have the choice of such a board, go for it. CP-6 (and possibly CP-V) has a mechanism for compiling parts of major programs (like editors) to run on the front-end processors. As a result the front ends tended to be accesable, programmable in something other than assembler and maintainable. A performance improvement was there too: the two parts of the "same" program tended to know how to communicate with each other effectively, using the basic comms primitives the system provided. Especially minimizing redundant copying. So look for boards with big ram buffers and hooks for user programmability/downloading: you may bless your foresight. -- David (Collier-) Brown. | Computer Science Geac Computers International Inc., | loses its memory 350 Steelcase Road,Markham, Ontario, | (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707061638.AA08697@ucbvax.Berkeley.EDU] <1987070609110300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JMWOBUS@SUVM.BITNET (John M. Wobus) Newsgroups: comp.protocols.tcp-ip Subject: New mailing list. Message-ID: <8707061638.AA08697@ucbvax.Berkeley.EDU> Date: Mon, 6-Jul-87 13:11:03 EDT Article-I.D.: ucbvax.8707061638.AA08697 Posted: Mon Jul 6 13:11:03 1987 Date-Received: Tue, 7-Jul-87 05:54:47 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 30 I am starting a new mailing list on LAN issues for large campus networks (e.g. multiprotocol, multivendor, etc). See blurb below. Please excuse this message if you've already received it through another list. John Wobus Syracuse University ------------------------------- BIG-LAN@SUVM (Bitnet) (Internet) This list is for the discussion of issues in designing and operating Campus-Size Local Area Networks, especially complex ones utilizing multiple technologies and supporting multiple protocols. Topics include repeaters, bridges, routers and gateways; how to incorporate smaller Personal-Computer type LANs into the campus-wide LAN; how to unify the mail systems, etc. This is an ideal list in which to debate the relative merits of bridges vs routers. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to BIG-REQ@SUVM (Bitnet) or (Internet). Those familiar with revised LISTSERV can subscribe with LISTSERV@SUVM (Bitnet) or (Internet). Archives are available through revised LISTSERV. Coordinator: John Wobus ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12316245218.8.MRC@PANDA] <1987070609553700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MRC@PANDA.COM (Mark Crispin) Newsgroups: comp.protocols.tcp-ip Subject: Wollongong TCP/IP for VAX/VMS Message-ID: <12316245218.8.MRC@PANDA> Date: Mon, 6-Jul-87 13:55:37 EDT Article-I.D.: PANDA.12316245218.8.MRC Posted: Mon Jul 6 13:55:37 1987 Date-Received: Tue, 7-Jul-87 06:39:35 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 17 I received my nth bug report from a Wollongong site today complaining that mail didn't work between them and a DEC-20. This is a ritual that I end up undergoing multiple times a week. The problem is, of course, that the Wollongong software simply does not work (even its original author, who is now behind a competing software package, admits it) and that Wollongong simply does not care. I would like to see a policy statement forbidding US government sites from wasting any more taxpayers' money on Wollongong software, and some note from the NIC to that effect in the TCP/IP Vendors List. Since Wollongong presumably does care about its revenue, this might induce them to fix the bugs...or go out of business, an equally acceptable alternative. -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [519@btnix.axion.bt.co.uk] <1987070610234400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: titley@btnix.axion.bt.co.uk (Nigel Titley) Newsgroups: comp.protocols.tcp-ip Subject: Excelan tcp-ip hangs on System V (NUXI) Message-ID: <519@btnix.axion.bt.co.uk> Date: Mon, 6-Jul-87 14:23:44 EDT Article-I.D.: btnix.519 Posted: Mon Jul 6 14:23:44 1987 Date-Received: Sun, 12-Jul-87 09:22:30 EDT Organization: British Telecom Research Labs, Martlesham Heath, IPSWICH, UK Lines: 26 We run a small network of miscellaneous machines, mostly Vaxen (VMS and UNIX) but some SUNS, MG1s, Bleasdales etc. We decided sometime ago to standardize on TCP/IP as our networking protocol, and on the Excelan product as the interface on all our Vaxen. On all machines except the two 750s and a microVax II running NUXI (The Instruction Set's version of System V) we have no problems at all. However on these machines we have problems with tcp/ip connections hanging. Excelan don't want to know because we are not running standard System V and the NUXI driver is not supported by them. Inset have fiddled around for several months and say it is something to do with the Excelan firmware. They also say that it is something that occurs with `standard' System V as well, which Excelan will not admit. Has anyone else had this sort of problem with the Excelan product? If so please let me know and perhaps I can beat Excelan round the head with it? Even better, if someone knows what causes the problem or has a fix then please, please let me know. I've just had the final note from Inset saying that they are dropping the problem, and I'm feeling desparate. -- Email: NTitley@axion.bt.co.uk Snail: British Telecom Research labs, Martlesham Heath, Ipswich, Suffolk, UK ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707062323.AA17697@ucbvax.Berkeley.EDU] <1987070611190000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: KVC@ENGVAX.SCG.HAC.COM (Kevin Carosso) Newsgroups: comp.protocols.tcp-ip Subject: Re: DECnet-TCP/IP gateway Message-ID: <8707062323.AA17697@ucbvax.Berkeley.EDU> Date: Mon, 6-Jul-87 15:19:00 EDT Article-I.D.: ucbvax.8707062323.AA17697 Posted: Mon Jul 6 15:19:00 1987 Date-Received: Wed, 8-Jul-87 01:28:58 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 > Looking for gateway software, preferably layered atop Wollongong, > for a MicroVax. In and out via shared DEQNA. > Mail is the biggest need. FTP strongly desired. Telnet desired, > but let's be realistic. > Charles Bacon, CRB@NIHCUDEC (bitnet) As far as mail goes, you could run the PMDF mail system which supports Wollongong and DECnet channels (also bitnet, phonenet, and others). Contact Ned Freed at Harvey Mudd College for more info (714) 621-8006. /Kevin Carosso kvc@engvax.scg.hac.com Hughes Aircraft Co. kvc%engvax@oberon.usc.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707062223.AA16336@ucbvax.Berkeley.EDU] <1987070613190000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: holtj@AFSC-SD.ARPA ("HOLT JC SSGT DOASS 32254") Newsgroups: comp.protocols.tcp-ip Subject: Wollongong TALKING to DEC-20's Message-ID: <8707062223.AA16336@ucbvax.Berkeley.EDU> Date: Mon, 6-Jul-87 17:19:00 EDT Article-I.D.: ucbvax.8707062223.AA16336 Posted: Mon Jul 6 17:19:00 1987 Date-Received: Wed, 8-Jul-87 01:18:31 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "HOLT JC SSGT DOASS 32254" Distribution: world Organization: The ARPA Internet Lines: 34 I N T E R O F F I C E M E M O R A N D U M Date: 6-Jul-1987 13:58 PST From: Jack C. Holt, SSgt HOLTJ Dept: 2080CS/DOAS Tel No: 643-2254 TO: _MAILER! ( _DDN[MRC%PANDA.COM@SUMEX-AIM.STANFORD.EDU] ) TO: _MAILER! ( _DDN[TCP-IP@SRI-NIC.ARPA] ) CC: TSgt Thomas ( THOMASJR ) CC: Communications Administration ( COMADM ) CC: DANAHY, DANIEL J. ( DANAHY ) Subject: Wollongong "talking" to DEC-20's This is in reference to your message to TCP-IP@SRI-NIC.arpa on 6 July 87 concerning the subject. Could you be more specific about some of the problems people are having? We have also experienced problems talking to at least some DEC-20's and are running Wollongong's WIN/TCP version 3.0 on a VAX 11/785. We have unexplained instances of undeliverable mail when trying to send mail to SRI-NIC.arpa and GUNTER-ADAM.arpa. We are also experiencing "Connection Refused..." errors when using GETTABLE to retrieve the HOST table from SRI-NIC.arpa. ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707062148.AA24354@manta.nosc.mil] <1987070613481400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@MANTA.NOSC.MIL (Ron Broersma) Newsgroups: comp.protocols.tcp-ip Subject: Re: status of POP Message-ID: <8707062148.AA24354@manta.nosc.mil> Date: Mon, 6-Jul-87 17:48:14 EDT Article-I.D.: manta.8707062148.AA24354 Posted: Mon Jul 6 17:48:14 1987 Date-Received: Wed, 8-Jul-87 01:29:13 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 13 It would be nice if someone decided what was the official version of POP. We assumed some time ago that the official version was POP2 because at the time that was the latest POP protocol documented in an RFC. I had the MH version but it clearly didn't implement POP2 although it did some other things nicely. We have our own PC mail implementation. It uses POP2 because we like to stick with standards and we thought POP2 was it. If someone is going to merge POP2 and MH-POP into POP3 and call it the standard, that would be great. However, I'd like a chance to have input because we have found POP2 to be deficient in a couple of minor ways and were required to modify it and hence stray from the "standard", sigh. --Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707070445.AA04813@MACOM4.ARPA] <1987070620455800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brady@MACOM4.ARPA (Sean Brady) Newsgroups: comp.protocols.tcp-ip Subject: Re: Asyncio on Sockets Message-ID: <8707070445.AA04813@MACOM4.ARPA> Date: Tue, 7-Jul-87 00:45:58 EDT Article-I.D.: MACOM4.8707070445.AA04813 Posted: Tue Jul 7 00:45:58 1987 Date-Received: Wed, 8-Jul-87 06:18:28 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 37 In reference to your question, we are using asynch io through raw sockets on Sun3's (under release 3.2), and have had little problems getting things going once the initial slugging is done. If you look in the documentation, you will be hopelessly confused unless you take the time to play with it for a bit. This is how we set up a asynch io socket under suntools (another confusing beast): make_my_socket(proto) int proto; { int s; if ((s = socket(AF_INET, SOCK_RAW, proto)) < 0) { perror("socket"); } fcntl(s, F_SETFL, FASYNC); fcntl(s, F_SETOWN, pktpid); (void) notify_set_input_func(frame, process, s); return(s); } where pktpid is the process id that is setting up the socket. If you are outside the suntools environment, just substitute a signal(SIGIO,process); for the notify_set_input_func(bla...bla), where process is your socket reader. That should give you a live socket that interupts when a packet of type "socket" arrives. You could then use the "recvfrom" call to read from and the "sendto" call to write to the socket created. Hope this helps... -Sean (He who Laughs, Lasts) *********************************************************************** "Mistakes are often the stepping stones to utter failure." ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707071930.AA08177@nic.nyser.net] <1987070711304000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: weltyc@NIC.NYSER.NET (Christopher A. Welty) Newsgroups: comp.protocols.tcp-ip Subject: Wollongong TCP/IP for VAX/VMS Message-ID: <8707071930.AA08177@nic.nyser.net> Date: Tue, 7-Jul-87 15:30:40 EDT Article-I.D.: nic.8707071930.AA08177 Posted: Tue Jul 7 15:30:40 1987 Date-Received: Mon, 13-Jul-87 01:17:15 EDT References: <12316245218.8.MRC@PANDA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 You might also tell DEC about it, since they sell TWG software for VMS as the official VAX?VMS TCP/IP product. --- Christopher Welty - Asst. Director, RPI CS Labs weltyc@cs.rpi.edu ...!seismo!rpics!weltyc ----MESSAGE-END---- ----MESSAGE-BEGIN---- [562@iscuva.ISCS.COM] <1987070714513900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dennisw@iscuva.ISCS.COM (Dennis Weaver) Newsgroups: comp.protocols.tcp-ip Subject: Request for info on public domain TCP-IP source Message-ID: <562@iscuva.ISCS.COM> Date: Tue, 7-Jul-87 18:51:39 EDT Article-I.D.: iscuva.562 Posted: Tue Jul 7 18:51:39 1987 Date-Received: Fri, 10-Jul-87 06:29:36 EDT Organization: ISC Systems Corporation, Spokane, Wa. Lines: 5 Keywords: public domain tcp-ip ftp telnet We are interested in locating "Public Domain" source of TCP-IP, FTP & TELNET written in "C" (if such a thing exists). Does anyone know where we can find these sources ??? Thanks in advance. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987070801450000> Received: from afsc-sd.arpa by SRI-NIC.ARPA with TCP; Wed 8 Jul 87 08:50:43-PDT Date: 8 Jul 87 08:45:00 PDT From: "ZEUS::HOLTJ" Subject: The fixing of problems with Wollongong WIN/TCP 3.0 To: "tcp-ip" Reply-To: "ZEUS::HOLTJ" I N T E R O F F I C E M E M O R A N D U M Date: 8-Jul-1987 07:41 PST From: Jack C. Holt, SSgt HOLTJ Dept: 2080CS/DOAS Tel No: 643-2254 TO: _MAILER! ( _DDN[MRC%PANDA.COM@SUMEX-AIM.STANFORD.EDU] ) TO: _MAILER! ( _DDN[TCP-IP@SRI-NIC.ARPA] ) CC: TSgt Thomas ( THOMASJR ) CC: Communications Administration ( COMADM ) CC: DANAHY, DANIEL J. ( DANAHY ) Subject: The fixing of problems with Wollongong WIN/TCP 3.0 In following up the message which I sent yesterday in reply to Mark Crispin's message about the Wollongong to DEC20 interface: I contacted Jerry Scott of Wollongong yesterday about our problems talking to DEC20's as well as other problems. It appears that our problems with talking to SRI-NIC.arpa (a DEC20) were caused by an incorrect installation (gateways were properly set up). After working with Mr. Scott things seem to have cleared up and we have been able to send several messages to SRI-NIC.arpa with no problems. Also, Mr. Scott showed a great deal of concern about solving our problems with mailer. ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707081643.AA28692@ucbvax.Berkeley.EDU] <1987070806094200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HANK@BARILVM.BITNET (Henry Nussbacher) Newsgroups: comp.protocols.tcp-ip Subject: Israel Tcp/Ip Plans Message-ID: <8707081643.AA28692@ucbvax.Berkeley.EDU> Date: Wed, 8-Jul-87 10:09:42 EDT Article-I.D.: ucbvax.8707081643.AA28692 Posted: Wed Jul 8 10:09:42 1987 Date-Received: Sat, 11-Jul-87 04:13:47 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 908 Conversion Plans from RSCS to Tcp/Ip for Israel Academic Network by Henry Nussbacher July 7th, 1987 Table of Contents Acknowledgments I. Reasons for conversion A. Background B. Reasons II. Why Tcp/Ip and not something else? A. SNA B. DECNET C. ISO D. TCP/IP E. Caveats III. What will it cost? A. Alternatives 1. High speed LAN (Ethernet) 2. BSC driver for leased lines 3. Tcp/Ip "black" boxes B. VM C. MVS D. Unix E. VMS F. Primos G. NOS H. Intercampus I. Total cost for all systems IV. Timetable for conversion A. Stage I - The test B. Stage II - Tcp/Ip for everyone C. Stage III - The Tcp/Ip<->RSCS gateway D. Stage IV - Conversion to ISO V. Appendix 1 - List of Israeli EARN nodes Appendix 2 - Cost of connecting PC's to a Tcp/Ip Network Appendix 3 - List of Tcp/Ip software and hardware vendors Appendix 4 - The Tcp/Ip Reference Model Appendix 5 - Glossary of acronyms Appendix 6 - References Appendix 7 - EARN Migration Plans Appendix 8 - Israel viewpoint on EARN Migration Plans Acknowledgements: Many people have provided valuable input but there are a few whom I wish to single out: John Klensin - MIT Mike Kramer - Nynex Scott Brim - Cornell University Marshall Rose - Northrop Research Dan Lynch - ACE --------------------------------------------------------------------- I. REASONS FOR CONVERSION ====================== I.A: Background: This report is based on meetings held by the Israeli University Telecommunications Subcommittee. Various pros and cons of the following proposal were discussed and argued. All members of the Telecommunications Subcommittee have reviewed this proposal and have stated their views to me via electronic mail. I.B: Reasons: Quite often people ask, "Why do we need to change something if it works perfectly and gets the job done correctly?" This is a valid question and this section will answer it. Currently, there are 43 computers connected to the Israeli section of EARN (European Academic Research Network - sister network of Bitnet). The six operating systems are: VMS 14 Unix 11 VM 8 NOS 4 MVS 3 Primos 3 --- Total 43 The protocol in use today is known as RSCS, also known as NJE (Network Job Entry). This protocol was developed within IBM and resulted in the creation of VNET - IBM's internal use network that currently numbers 2297 nodes (as of Nov 26th 1986). The reason for its successful growth within IBM was for one reason: its simplicity. One could install RSCS in one hour on a VM system and be talking to another node within the same amount of time. RSCS provides two protocols for communication: file transfer and interactive messages. There is no remote login (this is supplied within Vnet by a parallel network known as PASSTHRU), no mail protocol, no topology management and very little network control. In addition, when IBM released RSCS to the public in 1972 (along with VM Release 1), it only allowed for the connection of IBM operating systems (VM, MVS, DOS) and no other operating system. As Bitnet started to develop, various universities developed NJE simulators for their own operating systems. Urep (for Unix systems) was developed at Penn State University, jnet (for VMS systems) was also developed at Penn State University, and the author later sold the software to Joiner Associates for a healthy profit. Some vendors have taken it upon themselves to develop the NJE emulation - as Prime has recently announced for their Primos operating system. Over half the nodes in Israel only have a limited access to the NJE protocol. These nodes cannot send any interactive messages and some of them cannot send any files other than RFC822 (Request For Comments #822) mail. Therefore, Israel currently has the situation where some nodes have greater "connectivity" to the network than others. That is one of the problems that needs to be resolved. All nodes in the network should be able to supply the same level of service to their users - no matter where that node happens to be in Israel. Even if the network topology was rearranged so that only a very few nodes with limited software were to be assigned the status of end-nodes, we would still have the problem of the limited functionality that RSCS provides. Users have been asking for remote login for a long time and this can currently only be provided to VM sites and at a high cost to network performance. In the area of performance, RSCS loses out. First of all it uses a BSC protocol that requires an acknowledgement for every block received over a link. This requires line turnaround time and a loss of throughput. A full duplex protocol (HDLC) over our existing 9600 baud lines would effectively increase throughput by approximately 30%-40%. In addition, RSCS does not do any sort of dynamic or adaptive routing. If a link goes down (which we are already very familiar with), then data communication to that node is shut off completely. II. WHY TCP/IP AND NOT SOMETHING ELSE? ================================== There are other networking protocols that exist and I will review three of them: SNA, Decnet and ISO. II.A: SNA: It is interesting to note that IBM's strategic networking system is not used for its own internal network, but instead RSCS is used. IBM has been trying to convince the people within its own network that SNA will be "good" for them, but till this date nothing has happened. In a lecture by Tom Piatkowski, currently at SUNY Binghamtom, but more importantly one of the original architects of SNA, he noted that SNA was designed for the central management of a small network and not for a globe spanning network. SNA excels in managing a campus network; a network confined to a limited number of buildings and other small geographic entities. A recent internal memo within IBM detailed the performance tradeoff between using SNA and RSCS over a 9600 baud line or CTCA. The file transfer times were almost identical for both protocols but the SNA system took 40%-60% more CPU time to execute the transfer. This is understandable when one looks at the size of the RSCS program compared to the size of the RSCS/SNA/VTAM program. SNA's other major problem is also spelled with 3 letters: IBM. Other operating systems may create gateways from their networks to IBM's, but only a small number have done so to date and the only places that have installed these gateways are those installations that had to. No installation to my knowledge has planned a network from the start with the assumption of using SNA gateways to four non-IBM operating systems (three of which do not exist yet). Europe and for that matter the rest of the world, have decided that IBM is not to be followed with their networking protocols. For that reason they have created the ISO, which I will get to shortly. II.B: DECNET: Much of what has been discussed in the section on SNA pertains also to DECNET. VMS, Ultrix and TOPS-20 are the only operating system that can use Decnet and three months ago, Technology Concepts Inc. announced CommUnity, which allows Unix systems to participate in a DECNET environment. For our purposes, DECNET only supports two of our operating systems along with a gateway to SNA - exactly the same numbers that SNA claims. II.C: OSI: The International Standards Organization (ISO) created the Open Systems Interconnect (OSI) Reference Model because they saw that a uniform approach needed to be created for the entire world. In five years time, I expect we will see 4 OSI implementations: VM, MVS, VMS and Unix. I do not see that a NOS or Primos implementation will be available within that time frame but I am always ready to be pleasantly surprised. As of the end of 1986, there were only three X.400 implementations available (the mail protocol of OSI) - all of them on an unofficial basis. It is important to remember that X.400 is not an OSI protocol but rather a CCITT protocol that the ISO is considering to be part of its OSI protocol suite. No FTAM (file transfer) or Rlogin (remote login) implementations have been heard of. Clearly, people are working on developing the OSI protocols but we are currently looking for a networking standard that will last us through 1992. It is interesting to note that OSI is not a protocol but rather a reference model that provides for several families of standards. All that one has to do to become an "OSI product" is to document what your software does in terms of the reference model. DECNET claims that DNA is an OSI product as IBM claims that SNA is an OSI product. Different vendors will interpret the OSI reference model differently and in that case we will have many OSI products, unable to talk to each other. That is why the NBS (National Bureau of Standards) in the United States has created OSINET - a test bed where vendors can try out their software to see if their OSI will talk to someone else's OSI. II.D: TCP/IP: So what is so great about Tcp/Ip? For one, it is the oldest networking protocol around, predating DNA and SNA. There are 124 different Tcp/Ip implementations that run on 28 different brands of hardware (see Appendix 3). In addition there are 23 companies that make hardware (boxes or cards) that connect various computers to a Tcp/Ip network. If we ever need to add other operating systems to our network (example: MS/DOS), Tcp/Ip can handle it. Tcp/Ip works in full duplex so a leased line is fully utilized. Arpanet and Csnet in the United States use it, as well as numerous individual installations in Europe. It provides three standard applications protocols: SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol) and TELNET (Remote Login). All operating systems in Israel have Tcp/Ip implementations (NOS Tcp/Ip to be available from CDC - April 1987). Tcp/Ip can run on leased lines (9600 baud up to T1 speed), Ethernet, X.25 circuits, Pronet, etc. It is more in the spirit of the OSI reference model than SNA or DECNET since the physical and at least part of the link layer can be swapped out and substituted for with no change in the transport or session layers. Some Israeli universities have already made a heavy commitment to Tcp/Ip. Hebrew University, Ben Gurion University, Weizmann Institute of Science and Tel Aviv University have most of their own computers interconnected via Tcp/Ip. By installing a Tcp/Ip network we will be gaining access to the many Sun workstations, Lisp machines and other unique hardware that exists at each campus. Currently, these machines are available locally at individual campuses via local Tcp/Ip networks. Since Machba (Israeli InterUniversity Organization) has been considering the purchase or sharing of a Cray, it should be noted that Cray has developed a Tcp/Ip implementation for their Unicos operating system. Most importantly, the DOD (Department of Defense) has stated that it intends to convert to ISO standards when such standards are made available. To this end, the Northrop Research and Technology Center has recently introduced RFC983 - which defines a strategy for conversion in an evolutionary manner as opposed to a revolutionary manner. They offer a free ISO Development Environment that they have developed (written in C) that currently runs on Unix, VMS and PC/DOS. It is clear that the conversion route from Tcp/Ip to ISO (since they are so similar and parts of ISO are drawn directly from Tcp/Ip) will be the smoothest. The alternatives before us are few: either to sit still and continue to use the RSCS protocol for many years to come or to convert now to Tcp/Ip, under the assumption that it will be replaced by the ISO suite of protocols when they become available. It is my personal feeling that the upper layers of the ISO protocol (levels 5-7) are at least 5-8 years away from implementation. II.E: Caveats: There is also a negative side to Tcp/Ip. Certain implementations are buggy and will require a large amount of systems programming intervention. We will try to avoid those implementations but it should be known from the start that Tcp/Ip is not bug free (neither is any other networking or operating system) and we may run into a glitch along the way with certain implementations. The implementations that do work properly may be lacking some feature that we will realize later on that we need. It is impossible to know at this stage of the game what all the features that are in Tcp/Ip (i.e. dynamic routing, adaptive routing, ICMP, UDP) that will be needed. Tcp/Ip lacks certain features that we may need to develop in the future (but do not exist today). These include: accounting - there is no facility to gather statistics on path usage, data transfer rates, etc.; authentication and access control - suppose we wish to limit data transfer limits for students - currently there is no mechanism to accomplish this with Tcp/Ip. The Arpanet realizes these requirements and has informed vendors to be prepared in the future to include access-control and accounting machanisms in their gateways. Most of the assumptions for a smooth conversion depend that the Tcp/Ip network and RSCS network work in parallel for a period of two years. This involves an added cost that needs to be considered. Lastly, a network of this nature needs staffing. It doesn't run by itself and it doesn't fix itself. In general, you need more staff to run a network than not to run a network. Of the 6 operating systems in Israel, four have sufficient systems expertise scattered through the various universities. The two systems that lack "networking & system hackers" are Primos and VMS. All computer centers should be prepared to have one full-time person whose major responsibility is the running of their LAN. III. WHAT WILL IT COST? ================== ... this section removed for EARN and Bitnet distribution ... IV. TIMETABLE FOR CONVERSION ======================== IV.A: Stage I: This stage involves the interconnection of 2 or more separate Tcp/Ip LANs. Currently, there are Tcp/Ip networks at Hebrew University (CS Department only), Tel Aviv University (CS Department only), Bar Ilan University (CS Department only) and Weizmann Institute of Science (CS Department and Computer Center). There are two alternatives to accomplish this: A) VM to VM: The Wiscnet package comes with a BSC driver that can run a point to point leased line. All 4 Universities mentioned above have VM systems but currently only one of them runs Wiscnet. B) Tcp/Ip boxes (Bridge GS/3M): This would allow any of the current LANs mentioned above to interconnect. ... two paragraphs removed for EARN and Bitnet distribution ... Synopsis: identify potential and willing sites with the necessary software, then order necessary hardware. This stage should be completed no later than September 1987. IV.B: Stage II: This stage is just an extension of Stage I. All 43 Israeli EARN sites should be running Tcp/Ip on their system and a parallel Tcp/Ip network should exist alongside the current RSCS network. This stage will be the one to work out all the bugs between the various systems (inter-machine translation problems, performance and optimization, etc.) While this work is going on, the sites from Stage I should start experimenting with using their local Tcp/Ip services to send and receive data from the RSCS EARN network. Makeshift solutions will be made and the specific problems and necessary global solutions for Israel will be identified in this stage. This stage depends on the fact that alternate lines will exist for each of the 43 computers currently connected. These alternate lines can be either 9.6Kb or 64Kb Sifranet lines. The important point in this matter is that alternate lines have to exist for this to work. Synopsis: Order equipment for all 43 Israeli nodes, install software and hardware. This stage should be completed no later than June 1988. IV.C: Stage III: This is the final stage. It involves the disconnection of the 9600 baud leased lines and the end to the RSCS network that is currently in place in Israel. But before this can be done, a gateway needs to exist at Tel Aviv University (our EARN gateway for the country) that will send and receive Tcp/Ip datagrams from one side and send and receive RSCS files and interactive messages from the other. It will be up to each site to decide whether they wish to use the new Tcp/Ip functions (i.e. SMTP or FTP) or whether they wish to take their old RSCS user interfaces and make the necessary modifications (on a local basis) so that they can communicate via the Tcp/Ip network. It will not be Tel Aviv University's responsibility to modify every user program on all 43 systems that currently communicate with EARN. It will be Tel Aviv University's responsibility to design a gateway with the following capabilities: FTP: If a file arrives via EARN, destined for an Israeli user, then an FTP transaction should be created for delivering the file to the user. In certain cases, FTP to a system may not be possible. In that case, TAU must provide the necessary modifications for that system so that they can receive FTP transactions. An example would be a file destined to a VM site. Since FTP requires a write password to the person's disk - a vanilla FTP would not work. Possible alternatives might be: a) sending the file to an FTP sink user at the intended node, along with a mail file to the intended user informing him that a file has arrived and can be received from his local FTP sink user; b) modifications to Wiscnet FTP that would allow FTP to the user's VM spool (preferred solution). The reverse also needs to be handled. If a user in Israel wishes to send a file to a user in Germany via EARN, then the gateway at TAU must accept the FTP request and receive all the intended packets on behalf of the user in EARN. It will then issue a sendfile on the user's behalf, counterfeiting the original user's id and nodename instead of its own. There are many details that need to be worked out for this gateway (such as what format to send data in: netdata, disk dump, punch, print, specifying RSCS dependent options on the FTP request - like priority, class, forms, etc.) SMTP: Israel will register itself as being a domain of AC.IL and that all mail destined for this domain should be sent to MAILER@TAUNIVM. This mailer will then deliver the mail via SMTP methods rather than RSCS methods. The reverse must also be taken care of. This area is considered to be the easiest since other installations throughout the world have already tackled this problem and have come up with software solutions that we can use. It should be noted that Arpanet has already assigned an upper level domain to Israel (.IL) and that there is already a node at Hebrew University listed as a host in Arpanet (HUJI.AC.IL). It would then be a trivial matter to define all other hosts in Israel in the Arpanet hosts table, thereby giving us equal access to Bitnet (via the planned gateway at TAU), and via the X.25 link to Arpanet from Hebrew University. TELNET: This will not be supported in the direction of EARN since it is not supported today. Users will only be allowed to TELNET within Israel. RSCS Interactive messages: This is one area that we may not be able to implement. The ISO protocols do not support this kind of facility and neither does the Tcp/Ip protocol. We will only be able to determine whether we can implement this near the end of stage III. A while back, Arpanet implemented a SEND protocol that was fairly similar to RSCS interactive messages. It required a SEND server at the origin and destination sites. This service did not catch on with Arpanet users since they found it a bother to know whether a user was logged on at the time. Several people within Arpanet have indicated that the SEND protocol is very easy to implement since it never waits for an acknowledgement but rather just sends a datagram and exits. We may be able to use some of the early Arpanet work but it will have to remain as a low priority work item during the general timetable. It should be noted that some of this development work could be done in the framework of a graduate student project. Ariel Frank (Bar Ilan University) has indicated that he has graduate students that he could assign with subsets of the above stated work. Various other universities may also have graduate students that could be utilized to develop certain components that have been delineated above. Synopsis: A lot of software development should have already been started by the end of Stage I. This stage should be completed no later than January 1989. IV.D: Stage IV: This stage involves the conversion to ISO. As solutions become available on Arpanet (i.e. RFC983; see Appendix 6), we will adopt them. I foresee this stage lasting over a period of 2-3 years after January 1989. It is quite possible, that development projects will be assigned to Israel (i.e. from IBM, CDC, DEC, etc.) in this area over the next five years. V. APPENDIX 1: List of nodes in Israel =================================== ... this section removed for EARN and Bitnet distribution ... APPENDIX 2: Connecting PC's to the Tcp/Ip network ================================================= ... this section removed for EARN and Bitnet distribution ... APPENDIX 3: List of Tcp/Ip Hardware and Software Vendors ======================================================== ... this section removed for EARN and Bitnet distribution ... APPENDIX 4: The Tcp/Ip Reference Model ====================================== Applications Layer (7) Presentation Layer (6) Session Layer (5) Transport Layer (4) Network Layer (3) Data Link Layer (2) Physical Layer (1) APPENDIX 5: Glossary of acronyms ================================ Application Level: FTP - File Transfer Protocol - transfer of files and directories between computers TELNET - Virtual Terminal Protocol - interactive remote logon SMTP - Simple Mail Transfer Protocol - RFC822 mail BSMTP - Batch Simple Mail Transfer Protocol NFS - Network File System - SUN protocol for accessing remote files Transport Level: TCP - Transmission Control Protocol - sliding window protocol, connection oriented, flow control, multiplexing Network Level: IP - Internet Protocol - packet addressing and fragmentation UDP - User Datagram Protocol - connectionless service for host to host comunications ICMP - Internet Control Message Protocol - reports on transmission errors, flow control, first-hop gateway redirection and routing information ARP - Address Resolution Protocol - converts 32-bit Internet addresses to 48-bit Ethernet addresses. EGP - Exterior Gateway Protocol - used to exchange information between gateways Data Link Level: DLP - Data Link Protocol (also known as DLAP - Data Link Access Protocol) - provides connectionless service for sending and receiving datagrams APPENDIX 6: References ====================== 1) RFC942 - Transport Protocols for the Department of Defense Data Networks; Feb 1985 2) RFC983 - ISO Transport Services on Top of the TCP; Northrop Research; April 1986 3) RFC985 - Requirements for Internet Gateways; NSF; May 1986 4) Tcp/Ip Vendor's Guide; SRI; Feb 1987 5) DDN Protocol Handbook; SRI; Dec 1985 6) Ethernet: Distributed Packet Switching for Local Computer Networks; Metcalfe and Boggs; ACM Communications, July 1976 7) Introduction to Local Area Networks; DEC; 1982, EB-22714-18 8) Proceedings of Campus Network Plans and Pc/Ip Workshop; University of Maryland; Dec 1985 9) Computer Networks for Scientists; Jennings, Landweber, Fuchs, Farber, Adrion; Science; Feb 28, 1986 10) Notable Computer Networks; Quarterman and Hoskins; ACM Communications, Oct 1986 APPENDIX 7: EARN Migration Plans ================================ EUROPEAN ACADEMIC RESEARCH NETWORK The migration of EARN to use ISO protocols, summary of the proposed strategy and tactics. Subject to ratification by the EARN Board of Directors and further study issued by P Bryant 20 April 1987 _______________________________________________________________________ 1 Summary EARN is determined to migrate to use ISO protocols as soon as possible. It is vital that during this migration there is no significant loss of service to the users. Until recently there have not been the products available to start a migration. There are now a number of developments which suggest that the first stages of a migration could now be undertaken. The completion of the process will take several years. The EARN Board of Directors set up a working party to define the migration path which is just concluding its work. This paper is a summary of their report. The full report is now under discussion. 2 Why migrate? There are three reasons for EARN wishing to use ISO protocols: - EARN had to obtain permission from the various national regulatory authorities in order to operate. This was because it infringed the PTT monopolies in some countries. CEPT, the European advisory body for such matters, agreed to recommend EARN should be permitted as long as they migrated to ISO protocols by the end of 1987. - EARN uses the fairly primitive IBM NJE protocols which provide a store and forward network for file transfer and mail. The use of ISO protocols would provide a broader range of services. ISO protocols are expected to be available under most systems whereas NJE is restricted to the more popular ones. - All the west European countries (and many others) are expected to base their academic networking on ISO protocols. EARN must cooperate and interwork with these networks. 3 The state of protocols The CCITT X.25 protocol is widely available but only in its 1980 version. The 1984 version is required for the support of ISO protocols. The PTT's planed dates for the 1984 version are not yet clear. Various private switch suppliers now provide it. The X.400 mail protocol is available in a number of experimental or pilot versions. The use of this protocol is likely to expand rapidly as the PTTs provide services based on it in the near future. FTAM (the ISO file transfer protocol) is only now becoming stable and implementations are not expected for some time. VTP (virtual terminal protocol) and JTP (job transfer protocol) are both unstable and implementations are not expected for a long time. 4 The parts of EARN EARN can be regarded as two parts - the national parts and the international ones. The migration of EARN within a country must be undertaken in close cooperation with other national activities and will therefore not be directed centrally. The migration of the international parts will be directed by the EARN Board. All the international EARN nodes are IBM ones. This is the principle subject of this paper. It is essential that the international and national migrations are carefully coordinated. 5 The first stage, strategy The only ISO protocol that can currently be adopted is X.25. The strategy is to operate the IBM NJE protocol over X.25. This can be achieved using IBM products. The users will not need to be aware of the change since the strategy will not alter the services provides or the interface to the user. The use of NJE over X.25 demands the use of X.25 permanent virtual circuits. These cannot be provided internationally by the PTTs and therefore EARN will have to provide an interim private X.25 network. This has the secondary advantage that X.25 (1984) can be used which is not currently available from the PTTs and this needed to support the higher level ISO protocols. 6 The first stage, tactics A survey has shown that private switches which provide permanent virtual circuits and X.25 1984 are available. The number of switches and their location depend on the cost of switches and the cost of lines. An incomplete study suggests that initially there should be two switches- one serving the north of Europe and one the south. There will need to be some relocation of lines but this is expected to be done over a fairly long period of a year. It is intended to use the X.121 address scheme. This defines the first four digits of an address. Eight digits will remain for use within a country which will be allocated according to national needs although it is suggested that four digits define a site and four for use within a site. A two digit subaddress will not be policed by the network. Initially only a few sites with good networking expertise will be connected. The rest of the international sites will be migrated at a later date and in some cases when lines are relocated. A few sites will need additional software which may also cause a slight delay. The EARN services will be enhanced by the addition of the X.3, X.28, and X.29 services on some sites. This will not be very useful until the national parts of EARN have migrated to X.25 or gateways are provided to other X.25 networks. The tactics within a country will be the responsibility of the country. Some countries will want to migrate in step with the international parts of EARN. Others will want to wait. Others may want to provide gateways and relays to existing or proposed national networks. The use of Coloured Book protocols and DECNET will be allowed for an interim period to meet the needs of some specific groups of users. This will allow good connectivity between Ireland, the UK, and some other sites who use Coloured Books. DECNET is popular with the astronomy, space physics and high energy physics communities. 7 The second stage, strategy The first higher level ISO protocol to be promoted will be X.400 mail protocol. Some countries are expected to migrate with the international part of EARN. They will be installing switches for this purpose. These switches may be used to enhance the international parts of EARN and require some change to the EARN topology. 8 The second stage, tactics There are a number of X.400 systems now available. In particular the IBM Heidelberg system will operate on IBM VM systems and so it will be mounted on many of the international nodes. This system has the property that parts of the system can be located remotely over the NJE network thus allowing greater penetration of EARN by X.400 than the extent of the X.25 network would suggest. Other X.400 systems, such as EAN, are expected to interwork with the Heidelberg one and recent tests are encouraging. These will be of greatest interest within a country. Some countries are expected to be part of the EARN address space as they migrate. Other will have different schemes and gateways and relays will be provided to maintain a service. Various promising products are in existence or being produced. The most important relay will be between X.400 and RSCS mail systems. A suitable product is being produced in Germany. 9 The fourth stage, strategy The use of NJE, DECNET, and Coloured Book protocols will be phased out leaving a pure ISO network. At this stage it will be possible to use the public networks. The removal of these protocols depends on the provision of FTAM (the ISO file transfer protocols) which should be available in a year or two. 10 The fourth stage, tactics Currently there are no suitable versions of FTAM available and no firm indication of dates. EARN will wait for suitable products and promote them as soon as possible. The fourth stage will require further study. It is unlikely to be concluded before 1989. 11 Time scales The international switches plus a few connections could be provided by the end of 1987. The complete migration of the international part of EARN to X.25 will take to the middle or end of 1988. NJE services must be provided immediately. X.400 can be provided on some nodes by early in 1988 with all international nodes operating it at the end of 1988. The use of Coloured Book and DECNET protocols will only be provided where needed. Planning will be on a bilateral basis. The migration of countries has not yet been studied in detail. There will be gateways and relays to some existing X.25 national networks at the end of 1987. a small number of national networks within the EARN address scheme are expected towards the end of 1988. Implementations of FTAM are expected in 1988 or 1989. NJE will be phased out as soon as FTAM is proved to be able to offer a comparable service. Manufacturers plans and timescales are not available. 12 Standards EARN will follow the emerging functional standards being elaborated by CEN/CENELEC. EARN is also following the activities of RARE. This is important to ensure that EARN can interwork with other academic networks which are all expected to follow the same standards and functional standards. It must be noted that EARN is a service provider and does not intend to take part in standards activities as a primary activity. In addition, EARN does not intend to develop products but to use those provided by others. 13 Conclusions EARN is moving towards the use of ISO protocols as fast as possible. The main delay is caused by the lack of implementations of protocols which is not surprising considering the unstable nature of some of them. EARN is dedicated and will remain dedicated to providing the best possible service to the European academic and research community. APPENDIX 8: Israel viewpoint on EARN Migration Plans ==================================================== Date: July 1, 1987 This section will address some of the points raised in the EARN Transition paper (April 20, 1987) by Paul Bryant (Appendix #7). In order to follow the points made, it is advised to have a copy of the EARN Transition paper available. 1) Israel is determined to migrate to the ISO protocols. 2) Israel agrees entirely with the need to abandon the NJE protocols and adopt the OSI international standards. 3) The 1984 X.400 standard finally has a few experimental implementations available. IBM's announcement of X.400 support for MVS systems fails to mention that availability is 3Q88. As yet, IBM has not announced X.400 support for VM. We also realize that ISO has not adopted the CCITT X.400 standard and that the newly revised 1988 X.400 standard will be (on certain levels) incompatible with the 1984 version (i.e. mailing and distribution lists). If we take X.400 as an example, we can assume that it takes 4 years from the time a standard is finalized until the first half dozen supported implementations appear in the marketplace. OSI's timetable in 1985 stated that CASE, FTAM, JTM, MOTIS and VTP (the top application level) were all to become IS (International Standards) by 1987. Unfortunately, all of them are still DP or DIS and some (JTM for example) are therefore approximately 4 years behind schedule. ISO has also published a timetable for the Management Framework which includes standards for fault management, accounting, security, configuration, etc. Their initial timetable states IS completion by 4Q90. If we assume that ISO will meet this deadline then we can only hope to see the first half dozen supported implementations of the *complete* OSI model by 1994 (if we are to use the X.400 model as an example). It is the period of the next 7 years that the national academic network of Israel will follow an alternate path to the ultimate OSI solution. 4) Israel will be a full partner in all EARN decisions on the international segment of the network. It is Israel's intention to implement all EARN recommendations for its international link. 5) Israel will participate in the interim private X.25 network that EARN wishes to construct between the various country gateways. 6) It is stated in this section that each country is responsible for what occurs within its own country. "Others may want to provide gateways and relays to existing and proposed national networks." Ireland and England are mentioned as two examples. Israel will fall into this category. 7) Agreed. 8) As X.400 products become available we will implement them. As EARN proceeds with X.400, so too shall Israel on an international level. 9) Agreed. DECNET and Coloured Book protocols will be phased out as ISO protocols become available. We are just not quite as optimistic ("should be available in a year or two") as EARN is and therefore see the conversion to Tcp/Ip as a strategy for supplying all the services that ISO is planning, on an interim basis. If for some reason the ISO deadlines slip, we will continue to function with our national Tcp/Ip network until the necessary protocols are available. 10) It is stated in the Transition paper that the conversion is "unlikely to be concluded before 1989." The OSI FTAM standards (all 4 parts: 8571/1, 8571/2, 8571/3, and 8571/4) are still DIS (Draft International Standard), the same status they have been since 1986. If they do turn to IS before the year is over, I do not foresee more than 5-6 supported implementation available before 1990. A more realistic timeframe would be 1992. 11) Israel views these timescales to be extremely optimistic. When dealing with existing services (file transfer, interactive messages and mail) currently provided by EARN, it is very important to have contigency plans in case of unforeseen delays. We view the conversion to Tcp/Ip as an insurance policy that starts paying dividends today. 12) Agreed. 13) "EARN is moving towards the use of ISO protocols as fast as possible, the main delay is caused by the lack of implementations of protocols which is not suprising considering the unstable nature of some of them". That is EARN's conclusion. Israel is committed to ISO conversion as the standards become available. We see Tcp/Ip as an interim solution over the next 7 years. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707081440.AA00679@topaz.rutgers.edu] <1987070806403200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Ethernet meltdowns Message-ID: <8707081440.AA00679@topaz.rutgers.edu> Date: Wed, 8-Jul-87 10:40:32 EDT Article-I.D.: topaz.8707081440.AA00679 Posted: Wed Jul 8 10:40:32 1987 Date-Received: Sat, 11-Jul-87 06:59:46 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 179 During the last week or so we have run into several oddities on our Ethernets that I thought might interest this group. Nothing that will surprise any veterans, but sometimes war stories are useful to people trying to figure out what is going on with their own net. For several months, we have been having mysterious software problems on one Ethernet. THis is our "miscelleanous" network. No diskless Suns. Several Unix timesharing systems, a few VMS machines, a DEC-20, and some Xerox Interlisp-D machines. The problems: - every week or so, all of our Bridge terminal servers crashed. When it happened, they all crashed at the same time. - fairly rarely, a Celerity Unix system would run out of mbufs. - a Kinetics Ethernet/Appletalk gateway running the kip code would hang or crash (not sure which) every few days We sent a dump of the Bridge crash to Bridge. Celerity wouldn't talk to us because we made a few changes to the kernel. Kinetics swapped hardware for us, so we knew it wasn't hardware, but we still haven't figured out how to debug the problem. (The author of the software suspects the Ethernet device driver, but it's going to take us months to learn enough about the infamous Intel Ethernet chip to find a subtle device-level problem. Typical known problem: packet sizes that are a multiple of 18 bytes hang the hardware when the phase of the moon is wrong. How's a bunch of poor Unix hackers gonna debug a system where the critical chip has a 1/4 inch thick bug list, which we don't have a copy of.) Anyway, Bridge finally came back with a response that unfortunately I have only second-hand "We got a very high rate of packets from two different Ethernet addresses each claiming to be the same Internet address. This shouldn't cause us problems, but does. We found the problem, and it will be fixed in the next release." They gave us the two Ethernet addresses and the Internet address. Two Celerities were claiming to be some other machine. So we break out our trusty copy of etherfind. (This is a Sun utility that lets you look at packets. There's a fairly general way of specifying which ones you want to see, and they will decode the source, destination, and protocol types for IP. We've got lots of Ethernet debugging tools, but this is by far the most useful for this kind of problem.) It turns out that the Celerities have the infamous bug that causes them to get the addresses wrong in ICMP error messages. Before proceeding with the war story, let me list the classic 4.2 bugs that lead to network problems: 1) Somebody sends to a broadcast address that you don't understand. There are 6 possible broadcast addresses. For a subnetted network 128.6.4, they are 255.255.255.255, 128.6.4.255, (the correct ones by current standards) 128.6.255.255 (for machines that don't know about subnetting), and the corresponding ones for machines that use the old standards: 0.0.0.0, 128.6.4.0, and 128.6.0.0. We have enough of a combination of software versions that there is no one broadcast address that all of our machines understand. So suppose somebody sends to 128.6.4.255. Our 4.2 machines, which expect 0.0.0.0 or 128.6.0.0, see this as an attempt to connect to host 255 on the local subnet. Since IP forwarding is on by default, they helpfully decide to forward it. Thus they issue ARP requests for the address 128.6.4.255. Presumably nobody responds. So the net effect is that each broadcast results in every 4.2 machine on the Ethernet issing an ARP request, all at the same time. This causes massive collisions, and also every machine has to look at all those the ARP requests and throw it away. This will tend to cause a momentary pause in normal processing. 2) Same scenario, but somebody has turned off ipforwarding on all the 4.2 machines. Alas, this simply causes all the 4.2 machines to issue ICMP unreachable messages back to the original sender. This still results in massive collisions, but at least this time only one machine (the one that sent the broadcast) has to process the fallout. That's if everything works. Unfortunately, some 4.2 versions have an error in setting up the headers for the error message. They forget to reverse the source and destination, as I recall. 3) Somebody sends a broadcast UDP packet, e.g. routed routing information. Hosts that are not running routed (or whatever) attempt to send back ICMP port unreachable. They are supposed to avoid doing this for broadcasts, but the test for broadcastedness in udp_usrreq doesn't agree with the one in ip_input, so for certain broadcast addresses, every machine on the network that isn't running the appropriate daemon will send back an ICMP error. Again, lots of collisions. If you have a few gateawys running routed, but most hosts not running it, you'll have network interference every 30 sec. Then again, there are those machines where the ICMP messages have the wrong source and destination address. Now back to the war story. The case I actually saw with etherfind was caused by routed broadcasts. Our 2 Celerities would each respond with ICMP port unreachable. Unfortunately, they have the bug that caused the IP addresses in the ICMP error message to be wrong. I think it ended up sending packets with source address == the machine that had sent the routed's, and destination == the broadcast address. This would explain why our Bridge terminal servers were seeing packets from two different Ethernet addresses, both claiming to be a different machine. We had certainly been seeing spotty network response, and as far as I can see, it went away when we fixed these problems. As far as we know, the Bridge terminal servers and Kinetics gateways have both stopped crashing, and the Celerities have stopped losing mbuf's. What we suspect is that some obscure case came up that create a problem more serious than the one we saw with etherfind. Note that one of the failure modes is that certain broadcasts can lead to error messages sent to the broadcast address. We haven't analysed the code carefully enough to be sure exactly what conditions trigger it, but we suspect that the two machines may have gotten into an infinite loop of error messages. Since the messages would be broadcasts, everyone on the network would see them. This is generally called a "broadcast storm". The best guess is that both the Bridge and Kinetics crashes were caused by subtle bugs in their low-level code that fail under very heavy broadcast loads. Probably the Celerity "mbuf leak" is something similar. Unfortunately, without a record of the packets on the network at the exact time of failure, it is impossible to be sure what was going on. But Bridge's crash analysis seems to indicate a broadcast storm involving the Celerities. The fix to this is to make sure every one of your 4.2 systems has been made safe in the following fashion: - turn off ipforwarding, in ip_input - in the routine ip_forward (in ip_input), very near the beginning of the routine, there is a test with lots of conditions, that ends up throwing away the packet and exiting. Add "! ipforwarding || " to the beginning of the test. - in udp_usrreq, a few pages into the routine, in_pcblookup is called to see whether there is a port for the UDP packet. If not (it returns NULL), normally icmp_error is called to send port unreachable. However there is a test to see whether the packet was send as a broadcast. If so, it is simply discarded. That test must agree with the test for broadcastedness in ip_input. This seems to differ in various implementations, so I can't tell you the code to use. One common bug is to forget that ip_input recognizes 255.255.255.255 as a broadcast address. It normally does this in a completely different place than it tests for other broadcast addresses. So you may be able to add something like "ui->ui_dst.s_addr == -1 || " to the test in udp_usrreq. These apply to 4.2. 4.3 probably doesn't need them all, and may not need any of them. Now for the second war story. Our computer center recently bought a few diskless Suns for staff use. Until then, all diskless Suns had been on separate Ethernets separated from our other Ethernets by carefully-designed IP gateways. However the computer center figured that a small number of these things wasn't going to kill their network, so they connected them to their main Ethernet. On it is a VAXcluster (2 8650's), a few 780's, some terminal servers and other random stuff, and level 2 bridges (Applitek broadband Ethernet bridges and Ungerman-Bass remote bridges) to more or less everywhere else on campus. Since they were still setting up the configuration, it isn't surprising that a diskless Sun 3/50 got turned on before its server was properly configured to respond. Nobody thought anything of this. We first discovered there were problems when we got a call from somebody in a building half a mile away that his VAX was suddenly not doing any useful work. Then we got a call from our branch in Newark saying the same thing about their VAXes. Then someone noticed that the cluster was suddenly very slow. Well, it turns out that the Suns were sitting there sending out requests for their server to boot them. These were broadcast TFTP requests. Unfortunately, they used a new broadcast address, which the Wollongong VMS code doesn't understand. So VMS attempted to forward them. This means that it issued an ARP request for the broadcast address. There is some problem in the Wollongong TCP that we don't quite understand yet. It seems that whenever there are lots of requests to talk to a host that doesn't respond to ARP's, the whole CPU ends up being used up in issuing ARP's. For example, when something goes wrong with our IBM-compatible mainframe (which is used to handle most of the printer output for the cluster, using Unix lpd implementations on both systems) the VAX cluster becomes unusable. As far as we can tell, it is spending all of its time trying to ARP the mainframe. In this case, the same phenomenon was triggered by the attempt to forward broadcast packets. Since our VMS systems mostly sit on networks that are connected by level 2 bridges instead of real IP gateways, broadcasts go throughout the whole campus, and essentially every VMS system is brought to its knees. Unfortunately, there is no way we can fix this. The Sun broadcast is being issued by its boot ROM, which is the one piece of software we aren't equipped to change, and we don't have source to the Wollongong code. So the solution for the moment is to put the Suns on a subnet that is safely isolated behind an IP gateway. This fixes the problem, because IP gateways don't pass broadcasts, or they only pass very carefully selected ones. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707081557.AA27557@ucbvax.Berkeley.EDU] <1987070807450000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: holtj%zeus.DECnet@AFSC-SD.ARPA ("ZEUS::HOLTJ") Newsgroups: comp.protocols.tcp-ip Subject: The fixing of problems with Wollongong WIN/TCP 3.0 Message-ID: <8707081557.AA27557@ucbvax.Berkeley.EDU> Date: Wed, 8-Jul-87 11:45:00 EDT Article-I.D.: ucbvax.8707081557.AA27557 Posted: Wed Jul 8 11:45:00 1987 Date-Received: Sat, 11-Jul-87 04:09:59 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "ZEUS::HOLTJ" Distribution: world Organization: The ARPA Internet Lines: 33 I N T E R O F F I C E M E M O R A N D U M Date: 8-Jul-1987 07:41 PST From: Jack C. Holt, SSgt HOLTJ Dept: 2080CS/DOAS Tel No: 643-2254 TO: _MAILER! ( _DDN[MRC%PANDA.COM@SUMEX-AIM.STANFORD.EDU] ) TO: _MAILER! ( _DDN[TCP-IP@SRI-NIC.ARPA] ) CC: TSgt Thomas ( THOMASJR ) CC: Communications Administration ( COMADM ) CC: DANAHY, DANIEL J. ( DANAHY ) Subject: The fixing of problems with Wollongong WIN/TCP 3.0 In following up the message which I sent yesterday in reply to Mark Crispin's message about the Wollongong to DEC20 interface: I contacted Jerry Scott of Wollongong yesterday about our problems talking to DEC20's as well as other problems. It appears that our problems with talking to SRI-NIC.arpa (a DEC20) were caused by an incorrect installation (gateways were properly set up). After working with Mr. Scott things seem to have cleared up and we have been able to send several messages to SRI-NIC.arpa with no problems. Also, Mr. Scott showed a great deal of concern about solving our problems with mailer. ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707081701.AA29119@ucbvax.Berkeley.EDU] <1987070808190000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: WGRCU@CUNYVM.BITNET (Bill Rubin) Newsgroups: comp.protocols.tcp-ip Subject: New Mailing List on IBM TCP/IP for VM product Message-ID: <8707081701.AA29119@ucbvax.Berkeley.EDU> Date: Wed, 8-Jul-87 12:19:00 EDT Article-I.D.: ucbvax.8707081701.AA29119 Posted: Wed Jul 8 12:19:00 1987 Date-Received: Sat, 11-Jul-87 04:14:32 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 A new mailing list has been established at CUNYVM. Information is as follows. * * IBMTCP-L IBM TCP/IP For VM List * * IBMTCP-L is intended for discussion of the IBM TCP/IP For VM * program offering (5798-FAL). It is also for discussion of the * IBM DACU (7170), 8232, 9370 Ethernet adapter and other similar * hardware, as they relate to the IBM product. * To sign up, send the following message to LISTSERV at CUNYVM: SUBSCRIBE IBMTCP-L Your name Bill Rubin (Sorry for the duplicate mailings) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987070808190001> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Wed 8 Jul 87 09:43:48-PDT Received: from CUNYVM.BITNET by wiscvm.wisc.edu ; Wed, 08 Jul 87 11:28:28 CDT Received: by CUNYVM (Mailer X1.23b) id 6005; Wed, 08 Jul 87 12:29:09 EDT Date: Wed, 8 Jul 1987 12:19 EDT From: Bill Rubin Subject: New Mailing List on IBM TCP/IP for VM product To: , , , A new mailing list has been established at CUNYVM. Information is as follows. * * IBMTCP-L IBM TCP/IP For VM List * * IBMTCP-L is intended for discussion of the IBM TCP/IP For VM * program offering (5798-FAL). It is also for discussion of the * IBM DACU (7170), 8232, 9370 Ethernet adapter and other similar * hardware, as they relate to the IBM product. * To sign up, send the following message to LISTSERV at CUNYVM: SUBSCRIBE IBMTCP-L Your name Bill Rubin (Sorry for the duplicate mailings) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707081702.AA03732@topaz.rutgers.edu] <1987070809025700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong TCP/IP for VAX/VMS Message-ID: <8707081702.AA03732@topaz.rutgers.edu> Date: Wed, 8-Jul-87 13:02:57 EDT Article-I.D.: topaz.8707081702.AA03732 Posted: Wed Jul 8 13:02:57 1987 Date-Received: Sat, 11-Jul-87 04:20:36 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 28 Would you like to propose an alternative. The other major commercial offering (DTC/COMPION/GOULD/Whatever) ACCESS for VMS is WORSE. In addition the morons at the current company (Internet Solutions or Network Solutions, I can't remember) had little understanding of the internet at all. Their primary VMS worker kept insisting that when they got a name server implementation working it would fix their broken routing problems. I posted a rather lengthy description of the problem after that to the net and got some more calls from the management of the company but the code never got fixed. Woolengong, in addition to being blastedly expensive, falls short of being useful. In addition to having no name server support and no mail system to speak of, their low level Ethernet kills the entire system trying to ARP. This happens when it receives broadcast datagrams that it is trying to forward, or even if a host it has traffic for is down. It spurts a continuous stream of ARP's that never get answered which seem to be done at some priority that causes the VAX's to become virtually unresponive. Their inability to deal with any sort of broadcast means we have to segregate them from nets with real hosts on them. I frequently have to proxy arp for downed hosts when it is busy arping for them and they aren't capable of answering. Someday, someone will make a commercial VMS TCP offering that works worth a damn, and when they do RUTGERS will immediately put it on every single VMS machine we have (and we have a lot). -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707081839.AA26178@XN.LL.MIT.EDU] <1987070810391300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jcollas@XN.LL.MIT.EDU (Juan Collas) Newsgroups: comp.protocols.tcp-ip Subject: SNAP Protocol Message-ID: <8707081839.AA26178@XN.LL.MIT.EDU> Date: Wed, 8-Jul-87 14:39:13 EDT Article-I.D.: XN.8707081839.AA26178 Posted: Wed Jul 8 14:39:13 1987 Date-Received: Sat, 11-Jul-87 17:09:56 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 People, I've been reading the ULANA spec, and am curious about the SNAP protocol, mentioned twice but never defined. What is it? There's supposed to be an RFC for it, but I can't find that either. (ULANA is the Air Force's Unified LAN Architecture Phase I.) Any knowledgeable types out there? -Juan Collas, MIT Lincoln Labs ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5990@hc.DSPO.GOV] <1987070817133600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tomlin@hc.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong TCP/IP for VAX/VMS Message-ID: <5990@hc.DSPO.GOV> Date: Wed, 8-Jul-87 21:13:36 EDT Article-I.D.: hc.5990 Posted: Wed Jul 8 21:13:36 1987 Date-Received: Sat, 11-Jul-87 15:44:37 EDT References: <8707081702.AA03732@topaz.rutgers.edu> Distribution: world Organization: Los Alamos National Laboratory Lines: 14 in article <8707081702.AA03732@topaz.rutgers.edu>, ron@TOPAZ.RUTGERS.EDU (Ron Natalie) says: > > Would you like to propose an alternative. The other major > commercial offering (DTC/COMPION/GOULD/Whatever) ACCESS for > VMS is WORSE. What about Fusion TCP? It seems to work OK (they have a couple problems, such as no name server yet). And at least you can talk to reasonably intelligent technical people instead of the Wollongong marketing staff. It's also more resonably priced. -- Bob Tomlinson -- tomlin@hc.dspo.gov -- (505) 667-8495 Los Alamos National Laboratory -- MEE-10/Data Systems ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707090227.AA01230@sluggo.sun.com] <1987070818273700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: melohn@SUN.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: SNAP Protocol Message-ID: <8707090227.AA01230@sluggo.sun.com> Date: Wed, 8-Jul-87 22:27:37 EDT Article-I.D.: sluggo.8707090227.AA01230 Posted: Wed Jul 8 22:27:37 1987 Date-Received: Sat, 11-Jul-87 11:33:34 EDT References: <8707081839.AA26178@XN.LL.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: sun!melohn (Bill Melohn) Distribution: world Organization: Sun Microsystems, Mountain View Lines: 3 Refer to pages 12-13 of the latest "Assigned Numbers" RFC1010. I'm in the process of revising RFC948 to include the information about SNAP encoding worked out last fall in Monterey. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987070820394200> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Wed 8 Jul 87 09:22:12-PDT Received: from BARILVM.BITNET by wiscvm.wisc.edu ; Wed, 08 Jul 87 09:20:38 CDT Received: by BARILVM (Mailer X1.24) id 3886; Wed, 08 Jul 87 17:11:22 P Date: Wed, 08 Jul 87 17:09:42 P From: Henry Nussbacher Subject: Israel Tcp/Ip Plans To: tcp-ip@sri-nic.ARPA Conversion Plans from RSCS to Tcp/Ip for Israel Academic Network by Henry Nussbacher July 7th, 1987 Table of Contents Acknowledgments I. Reasons for conversion A. Background B. Reasons II. Why Tcp/Ip and not something else? A. SNA B. DECNET C. ISO D. TCP/IP E. Caveats III. What will it cost? A. Alternatives 1. High speed LAN (Ethernet) 2. BSC driver for leased lines 3. Tcp/Ip "black" boxes B. VM C. MVS D. Unix E. VMS F. Primos G. NOS H. Intercampus I. Total cost for all systems IV. Timetable for conversion A. Stage I - The test B. Stage II - Tcp/Ip for everyone C. Stage III - The Tcp/Ip<->RSCS gateway D. Stage IV - Conversion to ISO V. Appendix 1 - List of Israeli EARN nodes Appendix 2 - Cost of connecting PC's to a Tcp/Ip Network Appendix 3 - List of Tcp/Ip software and hardware vendors Appendix 4 - The Tcp/Ip Reference Model Appendix 5 - Glossary of acronyms Appendix 6 - References Appendix 7 - EARN Migration Plans Appendix 8 - Israel viewpoint on EARN Migration Plans Acknowledgements: Many people have provided valuable input but there are a few whom I wish to single out: John Klensin - MIT Mike Kramer - Nynex Scott Brim - Cornell University Marshall Rose - Northrop Research Dan Lynch - ACE --------------------------------------------------------------------- I. REASONS FOR CONVERSION ====================== I.A: Background: This report is based on meetings held by the Israeli University Telecommunications Subcommittee. Various pros and cons of the following proposal were discussed and argued. All members of the Telecommunications Subcommittee have reviewed this proposal and have stated their views to me via electronic mail. I.B: Reasons: Quite often people ask, "Why do we need to change something if it works perfectly and gets the job done correctly?" This is a valid question and this section will answer it. Currently, there are 43 computers connected to the Israeli section of EARN (European Academic Research Network - sister network of Bitnet). The six operating systems are: VMS 14 Unix 11 VM 8 NOS 4 MVS 3 Primos 3 --- Total 43 The protocol in use today is known as RSCS, also known as NJE (Network Job Entry). This protocol was developed within IBM and resulted in the creation of VNET - IBM's internal use network that currently numbers 2297 nodes (as of Nov 26th 1986). The reason for its successful growth within IBM was for one reason: its simplicity. One could install RSCS in one hour on a VM system and be talking to another node within the same amount of time. RSCS provides two protocols for communication: file transfer and interactive messages. There is no remote login (this is supplied within Vnet by a parallel network known as PASSTHRU), no mail protocol, no topology management and very little network control. In addition, when IBM released RSCS to the public in 1972 (along with VM Release 1), it only allowed for the connection of IBM operating systems (VM, MVS, DOS) and no other operating system. As Bitnet started to develop, various universities developed NJE simulators for their own operating systems. Urep (for Unix systems) was developed at Penn State University, jnet (for VMS systems) was also developed at Penn State University, and the author later sold the software to Joiner Associates for a healthy profit. Some vendors have taken it upon themselves to develop the NJE emulation - as Prime has recently announced for their Primos operating system. Over half the nodes in Israel only have a limited access to the NJE protocol. These nodes cannot send any interactive messages and some of them cannot send any files other than RFC822 (Request For Comments #822) mail. Therefore, Israel currently has the situation where some nodes have greater "connectivity" to the network than others. That is one of the problems that needs to be resolved. All nodes in the network should be able to supply the same level of service to their users - no matter where that node happens to be in Israel. Even if the network topology was rearranged so that only a very few nodes with limited software were to be assigned the status of end-nodes, we would still have the problem of the limited functionality that RSCS provides. Users have been asking for remote login for a long time and this can currently only be provided to VM sites and at a high cost to network performance. In the area of performance, RSCS loses out. First of all it uses a BSC protocol that requires an acknowledgement for every block received over a link. This requires line turnaround time and a loss of throughput. A full duplex protocol (HDLC) over our existing 9600 baud lines would effectively increase throughput by approximately 30%-40%. In addition, RSCS does not do any sort of dynamic or adaptive routing. If a link goes down (which we are already very familiar with), then data communication to that node is shut off completely. II. WHY TCP/IP AND NOT SOMETHING ELSE? ================================== There are other networking protocols that exist and I will review three of them: SNA, Decnet and ISO. II.A: SNA: It is interesting to note that IBM's strategic networking system is not used for its own internal network, but instead RSCS is used. IBM has been trying to convince the people within its own network that SNA will be "good" for them, but till this date nothing has happened. In a lecture by Tom Piatkowski, currently at SUNY Binghamtom, but more importantly one of the original architects of SNA, he noted that SNA was designed for the central management of a small network and not for a globe spanning network. SNA excels in managing a campus network; a network confined to a limited number of buildings and other small geographic entities. A recent internal memo within IBM detailed the performance tradeoff between using SNA and RSCS over a 9600 baud line or CTCA. The file transfer times were almost identical for both protocols but the SNA system took 40%-60% more CPU time to execute the transfer. This is understandable when one looks at the size of the RSCS program compared to the size of the RSCS/SNA/VTAM program. SNA's other major problem is also spelled with 3 letters: IBM. Other operating systems may create gateways from their networks to IBM's, but only a small number have done so to date and the only places that have installed these gateways are those installations that had to. No installation to my knowledge has planned a network from the start with the assumption of using SNA gateways to four non-IBM operating systems (three of which do not exist yet). Europe and for that matter the rest of the world, have decided that IBM is not to be followed with their networking protocols. For that reason they have created the ISO, which I will get to shortly. II.B: DECNET: Much of what has been discussed in the section on SNA pertains also to DECNET. VMS, Ultrix and TOPS-20 are the only operating system that can use Decnet and three months ago, Technology Concepts Inc. announced CommUnity, which allows Unix systems to participate in a DECNET environment. For our purposes, DECNET only supports two of our operating systems along with a gateway to SNA - exactly the same numbers that SNA claims. II.C: OSI: The International Standards Organization (ISO) created the Open Systems Interconnect (OSI) Reference Model because they saw that a uniform approach needed to be created for the entire world. In five years time, I expect we will see 4 OSI implementations: VM, MVS, VMS and Unix. I do not see that a NOS or Primos implementation will be available within that time frame but I am always ready to be pleasantly surprised. As of the end of 1986, there were only three X.400 implementations available (the mail protocol of OSI) - all of them on an unofficial basis. It is important to remember that X.400 is not an OSI protocol but rather a CCITT protocol that the ISO is considering to be part of its OSI protocol suite. No FTAM (file transfer) or Rlogin (remote login) implementations have been heard of. Clearly, people are working on developing the OSI protocols but we are currently looking for a networking standard that will last us through 1992. It is interesting to note that OSI is not a protocol but rather a reference model that provides for several families of standards. All that one has to do to become an "OSI product" is to document what your software does in terms of the reference model. DECNET claims that DNA is an OSI product as IBM claims that SNA is an OSI product. Different vendors will interpret the OSI reference model differently and in that case we will have many OSI products, unable to talk to each other. That is why the NBS (National Bureau of Standards) in the United States has created OSINET - a test bed where vendors can try out their software to see if their OSI will talk to someone else's OSI. II.D: TCP/IP: So what is so great about Tcp/Ip? For one, it is the oldest networking protocol around, predating DNA and SNA. There are 124 different Tcp/Ip implementations that run on 28 different brands of hardware (see Appendix 3). In addition there are 23 companies that make hardware (boxes or cards) that connect various computers to a Tcp/Ip network. If we ever need to add other operating systems to our network (example: MS/DOS), Tcp/Ip can handle it. Tcp/Ip works in full duplex so a leased line is fully utilized. Arpanet and Csnet in the United States use it, as well as numerous individual installations in Europe. It provides three standard applications protocols: SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol) and TELNET (Remote Login). All operating systems in Israel have Tcp/Ip implementations (NOS Tcp/Ip to be available from CDC - April 1987). Tcp/Ip can run on leased lines (9600 baud up to T1 speed), Ethernet, X.25 circuits, Pronet, etc. It is more in the spirit of the OSI reference model than SNA or DECNET since the physical and at least part of the link layer can be swapped out and substituted for with no change in the transport or session layers. Some Israeli universities have already made a heavy commitment to Tcp/Ip. Hebrew University, Ben Gurion University, Weizmann Institute of Science and Tel Aviv University have most of their own computers interconnected via Tcp/Ip. By installing a Tcp/Ip network we will be gaining access to the many Sun workstations, Lisp machines and other unique hardware that exists at each campus. Currently, these machines are available locally at individual campuses via local Tcp/Ip networks. Since Machba (Israeli InterUniversity Organization) has been considering the purchase or sharing of a Cray, it should be noted that Cray has developed a Tcp/Ip implementation for their Unicos operating system. Most importantly, the DOD (Department of Defense) has stated that it intends to convert to ISO standards when such standards are made available. To this end, the Northrop Research and Technology Center has recently introduced RFC983 - which defines a strategy for conversion in an evolutionary manner as opposed to a revolutionary manner. They offer a free ISO Development Environment that they have developed (written in C) that currently runs on Unix, VMS and PC/DOS. It is clear that the conversion route from Tcp/Ip to ISO (since they are so similar and parts of ISO are drawn directly from Tcp/Ip) will be the smoothest. The alternatives before us are few: either to sit still and continue to use the RSCS protocol for many years to come or to convert now to Tcp/Ip, under the assumption that it will be replaced by the ISO suite of protocols when they become available. It is my personal feeling that the upper layers of the ISO protocol (levels 5-7) are at least 5-8 years away from implementation. II.E: Caveats: There is also a negative side to Tcp/Ip. Certain implementations are buggy and will require a large amount of systems programming intervention. We will try to avoid those implementations but it should be known from the start that Tcp/Ip is not bug free (neither is any other networking or operating system) and we may run into a glitch along the way with certain implementations. The implementations that do work properly may be lacking some feature that we will realize later on that we need. It is impossible to know at this stage of the game what all the features that are in Tcp/Ip (i.e. dynamic routing, adaptive routing, ICMP, UDP) that will be needed. Tcp/Ip lacks certain features that we may need to develop in the future (but do not exist today). These include: accounting - there is no facility to gather statistics on path usage, data transfer rates, etc.; authentication and access control - suppose we wish to limit data transfer limits for students - currently there is no mechanism to accomplish this with Tcp/Ip. The Arpanet realizes these requirements and has informed vendors to be prepared in the future to include access-control and accounting machanisms in their gateways. Most of the assumptions for a smooth conversion depend that the Tcp/Ip network and RSCS network work in parallel for a period of two years. This involves an added cost that needs to be considered. Lastly, a network of this nature needs staffing. It doesn't run by itself and it doesn't fix itself. In general, you need more staff to run a network than not to run a network. Of the 6 operating systems in Israel, four have sufficient systems expertise scattered through the various universities. The two systems that lack "networking & system hackers" are Primos and VMS. All computer centers should be prepared to have one full-time person whose major responsibility is the running of their LAN. III. WHAT WILL IT COST? ================== ... this section removed for EARN and Bitnet distribution ... IV. TIMETABLE FOR CONVERSION ======================== IV.A: Stage I: This stage involves the interconnection of 2 or more separate Tcp/Ip LANs. Currently, there are Tcp/Ip networks at Hebrew University (CS Department only), Tel Aviv University (CS Department only), Bar Ilan University (CS Department only) and Weizmann Institute of Science (CS Department and Computer Center). There are two alternatives to accomplish this: A) VM to VM: The Wiscnet package comes with a BSC driver that can run a point to point leased line. All 4 Universities mentioned above have VM systems but currently only one of them runs Wiscnet. B) Tcp/Ip boxes (Bridge GS/3M): This would allow any of the current LANs mentioned above to interconnect. ... two paragraphs removed for EARN and Bitnet distribution ... Synopsis: identify potential and willing sites with the necessary software, then order necessary hardware. This stage should be completed no later than September 1987. IV.B: Stage II: This stage is just an extension of Stage I. All 43 Israeli EARN sites should be running Tcp/Ip on their system and a parallel Tcp/Ip network should exist alongside the current RSCS network. This stage will be the one to work out all the bugs between the various systems (inter-machine translation problems, performance and optimization, etc.) While this work is going on, the sites from Stage I should start experimenting with using their local Tcp/Ip services to send and receive data from the RSCS EARN network. Makeshift solutions will be made and the specific problems and necessary global solutions for Israel will be identified in this stage. This stage depends on the fact that alternate lines will exist for each of the 43 computers currently connected. These alternate lines can be either 9.6Kb or 64Kb Sifranet lines. The important point in this matter is that alternate lines have to exist for this to work. Synopsis: Order equipment for all 43 Israeli nodes, install software and hardware. This stage should be completed no later than June 1988. IV.C: Stage III: This is the final stage. It involves the disconnection of the 9600 baud leased lines and the end to the RSCS network that is currently in place in Israel. But before this can be done, a gateway needs to exist at Tel Aviv University (our EARN gateway for the country) that will send and receive Tcp/Ip datagrams from one side and send and receive RSCS files and interactive messages from the other. It will be up to each site to decide whether they wish to use the new Tcp/Ip functions (i.e. SMTP or FTP) or whether they wish to take their old RSCS user interfaces and make the necessary modifications (on a local basis) so that they can communicate via the Tcp/Ip network. It will not be Tel Aviv University's responsibility to modify every user program on all 43 systems that currently communicate with EARN. It will be Tel Aviv University's responsibility to design a gateway with the following capabilities: FTP: If a file arrives via EARN, destined for an Israeli user, then an FTP transaction should be created for delivering the file to the user. In certain cases, FTP to a system may not be possible. In that case, TAU must provide the necessary modifications for that system so that they can receive FTP transactions. An example would be a file destined to a VM site. Since FTP requires a write password to the person's disk - a vanilla FTP would not work. Possible alternatives might be: a) sending the file to an FTP sink user at the intended node, along with a mail file to the intended user informing him that a file has arrived and can be received from his local FTP sink user; b) modifications to Wiscnet FTP that would allow FTP to the user's VM spool (preferred solution). The reverse also needs to be handled. If a user in Israel wishes to send a file to a user in Germany via EARN, then the gateway at TAU must accept the FTP request and receive all the intended packets on behalf of the user in EARN. It will then issue a sendfile on the user's behalf, counterfeiting the original user's id and nodename instead of its own. There are many details that need to be worked out for this gateway (such as what format to send data in: netdata, disk dump, punch, print, specifying RSCS dependent options on the FTP request - like priority, class, forms, etc.) SMTP: Israel will register itself as being a domain of AC.IL and that all mail destined for this domain should be sent to MAILER@TAUNIVM. This mailer will then deliver the mail via SMTP methods rather than RSCS methods. The reverse must also be taken care of. This area is considered to be the easiest since other installations throughout the world have already tackled this problem and have come up with software solutions that we can use. It should be noted that Arpanet has already assigned an upper level domain to Israel (.IL) and that there is already a node at Hebrew University listed as a host in Arpanet (HUJI.AC.IL). It would then be a trivial matter to define all other hosts in Israel in the Arpanet hosts table, thereby giving us equal access to Bitnet (via the planned gateway at TAU), and via the X.25 link to Arpanet from Hebrew University. TELNET: This will not be supported in the direction of EARN since it is not supported today. Users will only be allowed to TELNET within Israel. RSCS Interactive messages: This is one area that we may not be able to implement. The ISO protocols do not support this kind of facility and neither does the Tcp/Ip protocol. We will only be able to determine whether we can implement this near the end of stage III. A while back, Arpanet implemented a SEND protocol that was fairly similar to RSCS interactive messages. It required a SEND server at the origin and destination sites. This service did not catch on with Arpanet users since they found it a bother to know whether a user was logged on at the time. Several people within Arpanet have indicated that the SEND protocol is very easy to implement since it never waits for an acknowledgement but rather just sends a datagram and exits. We may be able to use some of the early Arpanet work but it will have to remain as a low priority work item during the general timetable. It should be noted that some of this development work could be done in the framework of a graduate student project. Ariel Frank (Bar Ilan University) has indicated that he has graduate students that he could assign with subsets of the above stated work. Various other universities may also have graduate students that could be utilized to develop certain components that have been delineated above. Synopsis: A lot of software development should have already been started by the end of Stage I. This stage should be completed no later than January 1989. IV.D: Stage IV: This stage involves the conversion to ISO. As solutions become available on Arpanet (i.e. RFC983; see Appendix 6), we will adopt them. I foresee this stage lasting over a period of 2-3 years after January 1989. It is quite possible, that development projects will be assigned to Israel (i.e. from IBM, CDC, DEC, etc.) in this area over the next five years. V. APPENDIX 1: List of nodes in Israel =================================== ... this section removed for EARN and Bitnet distribution ... APPENDIX 2: Connecting PC's to the Tcp/Ip network ================================================= ... this section removed for EARN and Bitnet distribution ... APPENDIX 3: List of Tcp/Ip Hardware and Software Vendors ======================================================== ... this section removed for EARN and Bitnet distribution ... APPENDIX 4: The Tcp/Ip Reference Model ====================================== Applications Layer (7) Presentation Layer (6) Session Layer (5) Transport Layer (4) Network Layer (3) Data Link Layer (2) Physical Layer (1) APPENDIX 5: Glossary of acronyms ================================ Application Level: FTP - File Transfer Protocol - transfer of files and directories between computers TELNET - Virtual Terminal Protocol - interactive remote logon SMTP - Simple Mail Transfer Protocol - RFC822 mail BSMTP - Batch Simple Mail Transfer Protocol NFS - Network File System - SUN protocol for accessing remote files Transport Level: TCP - Transmission Control Protocol - sliding window protocol, connection oriented, flow control, multiplexing Network Level: IP - Internet Protocol - packet addressing and fragmentation UDP - User Datagram Protocol - connectionless service for host to host comunications ICMP - Internet Control Message Protocol - reports on transmission errors, flow control, first-hop gateway redirection and routing information ARP - Address Resolution Protocol - converts 32-bit Internet addresses to 48-bit Ethernet addresses. EGP - Exterior Gateway Protocol - used to exchange information between gateways Data Link Level: DLP - Data Link Protocol (also known as DLAP - Data Link Access Protocol) - provides connectionless service for sending and receiving datagrams APPENDIX 6: References ====================== 1) RFC942 - Transport Protocols for the Department of Defense Data Networks; Feb 1985 2) RFC983 - ISO Transport Services on Top of the TCP; Northrop Research; April 1986 3) RFC985 - Requirements for Internet Gateways; NSF; May 1986 4) Tcp/Ip Vendor's Guide; SRI; Feb 1987 5) DDN Protocol Handbook; SRI; Dec 1985 6) Ethernet: Distributed Packet Switching for Local Computer Networks; Metcalfe and Boggs; ACM Communications, July 1976 7) Introduction to Local Area Networks; DEC; 1982, EB-22714-18 8) Proceedings of Campus Network Plans and Pc/Ip Workshop; University of Maryland; Dec 1985 9) Computer Networks for Scientists; Jennings, Landweber, Fuchs, Farber, Adrion; Science; Feb 28, 1986 10) Notable Computer Networks; Quarterman and Hoskins; ACM Communications, Oct 1986 APPENDIX 7: EARN Migration Plans ================================ EUROPEAN ACADEMIC RESEARCH NETWORK The migration of EARN to use ISO protocols, summary of the proposed strategy and tactics. Subject to ratification by the EARN Board of Directors and further study issued by P Bryant 20 April 1987 _______________________________________________________________________ 1 Summary EARN is determined to migrate to use ISO protocols as soon as possible. It is vital that during this migration there is no significant loss of service to the users. Until recently there have not been the products available to start a migration. There are now a number of developments which suggest that the first stages of a migration could now be undertaken. The completion of the process will take several years. The EARN Board of Directors set up a working party to define the migration path which is just concluding its work. This paper is a summary of their report. The full report is now under discussion. 2 Why migrate? There are three reasons for EARN wishing to use ISO protocols: - EARN had to obtain permission from the various national regulatory authorities in order to operate. This was because it infringed the PTT monopolies in some countries. CEPT, the European advisory body for such matters, agreed to recommend EARN should be permitted as long as they migrated to ISO protocols by the end of 1987. - EARN uses the fairly primitive IBM NJE protocols which provide a store and forward network for file transfer and mail. The use of ISO protocols would provide a broader range of services. ISO protocols are expected to be available under most systems whereas NJE is restricted to the more popular ones. - All the west European countries (and many others) are expected to base their academic networking on ISO protocols. EARN must cooperate and interwork with these networks. 3 The state of protocols The CCITT X.25 protocol is widely available but only in its 1980 version. The 1984 version is required for the support of ISO protocols. The PTT's planed dates for the 1984 version are not yet clear. Various private switch suppliers now provide it. The X.400 mail protocol is available in a number of experimental or pilot versions. The use of this protocol is likely to expand rapidly as the PTTs provide services based on it in the near future. FTAM (the ISO file transfer protocol) is only now becoming stable and implementations are not expected for some time. VTP (virtual terminal protocol) and JTP (job transfer protocol) are both unstable and implementations are not expected for a long time. 4 The parts of EARN EARN can be regarded as two parts - the national parts and the international ones. The migration of EARN within a country must be undertaken in close cooperation with other national activities and will therefore not be directed centrally. The migration of the international parts will be directed by the EARN Board. All the international EARN nodes are IBM ones. This is the principle subject of this paper. It is essential that the international and national migrations are carefully coordinated. 5 The first stage, strategy The only ISO protocol that can currently be adopted is X.25. The strategy is to operate the IBM NJE protocol over X.25. This can be achieved using IBM products. The users will not need to be aware of the change since the strategy will not alter the services provides or the interface to the user. The use of NJE over X.25 demands the use of X.25 permanent virtual circuits. These cannot be provided internationally by the PTTs and therefore EARN will have to provide an interim private X.25 network. This has the secondary advantage that X.25 (1984) can be used which is not currently available from the PTTs and this needed to support the higher level ISO protocols. 6 The first stage, tactics A survey has shown that private switches which provide permanent virtual circuits and X.25 1984 are available. The number of switches and their location depend on the cost of switches and the cost of lines. An incomplete study suggests that initially there should be two switches- one serving the north of Europe and one the south. There will need to be some relocation of lines but this is expected to be done over a fairly long period of a year. It is intended to use the X.121 address scheme. This defines the first four digits of an address. Eight digits will remain for use within a country which will be allocated according to national needs although it is suggested that four digits define a site and four for use within a site. A two digit subaddress will not be policed by the network. Initially only a few sites with good networking expertise will be connected. The rest of the international sites will be migrated at a later date and in some cases when lines are relocated. A few sites will need additional software which may also cause a slight delay. The EARN services will be enhanced by the addition of the X.3, X.28, and X.29 services on some sites. This will not be very useful until the national parts of EARN have migrated to X.25 or gateways are provided to other X.25 networks. The tactics within a country will be the responsibility of the country. Some countries will want to migrate in step with the international parts of EARN. Others will want to wait. Others may want to provide gateways and relays to existing or proposed national networks. The use of Coloured Book protocols and DECNET will be allowed for an interim period to meet the needs of some specific groups of users. This will allow good connectivity between Ireland, the UK, and some other sites who use Coloured Books. DECNET is popular with the astronomy, space physics and high energy physics communities. 7 The second stage, strategy The first higher level ISO protocol to be promoted will be X.400 mail protocol. Some countries are expected to migrate with the international part of EARN. They will be installing switches for this purpose. These switches may be used to enhance the international parts of EARN and require some change to the EARN topology. 8 The second stage, tactics There are a number of X.400 systems now available. In particular the IBM Heidelberg system will operate on IBM VM systems and so it will be mounted on many of the international nodes. This system has the property that parts of the system can be located remotely over the NJE network thus allowing greater penetration of EARN by X.400 than the extent of the X.25 network would suggest. Other X.400 systems, such as EAN, are expected to interwork with the Heidelberg one and recent tests are encouraging. These will be of greatest interest within a country. Some countries are expected to be part of the EARN address space as they migrate. Other will have different schemes and gateways and relays will be provided to maintain a service. Various promising products are in existence or being produced. The most important relay will be between X.400 and RSCS mail systems. A suitable product is being produced in Germany. 9 The fourth stage, strategy The use of NJE, DECNET, and Coloured Book protocols will be phased out leaving a pure ISO network. At this stage it will be possible to use the public networks. The removal of these protocols depends on the provision of FTAM (the ISO file transfer protocols) which should be available in a year or two. 10 The fourth stage, tactics Currently there are no suitable versions of FTAM available and no firm indication of dates. EARN will wait for suitable products and promote them as soon as possible. The fourth stage will require further study. It is unlikely to be concluded before 1989. 11 Time scales The international switches plus a few connections could be provided by the end of 1987. The complete migration of the international part of EARN to X.25 will take to the middle or end of 1988. NJE services must be provided immediately. X.400 can be provided on some nodes by early in 1988 with all international nodes operating it at the end of 1988. The use of Coloured Book and DECNET protocols will only be provided where needed. Planning will be on a bilateral basis. The migration of countries has not yet been studied in detail. There will be gateways and relays to some existing X.25 national networks at the end of 1987. a small number of national networks within the EARN address scheme are expected towards the end of 1988. Implementations of FTAM are expected in 1988 or 1989. NJE will be phased out as soon as FTAM is proved to be able to offer a comparable service. Manufacturers plans and timescales are not available. 12 Standards EARN will follow the emerging functional standards being elaborated by CEN/CENELEC. EARN is also following the activities of RARE. This is important to ensure that EARN can interwork with other academic networks which are all expected to follow the same standards and functional standards. It must be noted that EARN is a service provider and does not intend to take part in standards activities as a primary activity. In addition, EARN does not intend to develop products but to use those provided by others. 13 Conclusions EARN is moving towards the use of ISO protocols as fast as possible. The main delay is caused by the lack of implementations of protocols which is not surprising considering the unstable nature of some of them. EARN is dedicated and will remain dedicated to providing the best possible service to the European academic and research community. APPENDIX 8: Israel viewpoint on EARN Migration Plans ==================================================== Date: July 1, 1987 This section will address some of the points raised in the EARN Transition paper (April 20, 1987) by Paul Bryant (Appendix #7). In order to follow the points made, it is advised to have a copy of the EARN Transition paper available. 1) Israel is determined to migrate to the ISO protocols. 2) Israel agrees entirely with the need to abandon the NJE protocols and adopt the OSI international standards. 3) The 1984 X.400 standard finally has a few experimental implementations available. IBM's announcement of X.400 support for MVS systems fails to mention that availability is 3Q88. As yet, IBM has not announced X.400 support for VM. We also realize that ISO has not adopted the CCITT X.400 standard and that the newly revised 1988 X.400 standard will be (on certain levels) incompatible with the 1984 version (i.e. mailing and distribution lists). If we take X.400 as an example, we can assume that it takes 4 years from the time a standard is finalized until the first half dozen supported implementations appear in the marketplace. OSI's timetable in 1985 stated that CASE, FTAM, JTM, MOTIS and VTP (the top application level) were all to become IS (International Standards) by 1987. Unfortunately, all of them are still DP or DIS and some (JTM for example) are therefore approximately 4 years behind schedule. ISO has also published a timetable for the Management Framework which includes standards for fault management, accounting, security, configuration, etc. Their initial timetable states IS completion by 4Q90. If we assume that ISO will meet this deadline then we can only hope to see the first half dozen supported implementations of the *complete* OSI model by 1994 (if we are to use the X.400 model as an example). It is the period of the next 7 years that the national academic network of Israel will follow an alternate path to the ultimate OSI solution. 4) Israel will be a full partner in all EARN decisions on the international segment of the network. It is Israel's intention to implement all EARN recommendations for its international link. 5) Israel will participate in the interim private X.25 network that EARN wishes to construct between the various country gateways. 6) It is stated in this section that each country is responsible for what occurs within its own country. "Others may want to provide gateways and relays to existing and proposed national networks." Ireland and England are mentioned as two examples. Israel will fall into this category. 7) Agreed. 8) As X.400 products become available we will implement them. As EARN proceeds with X.400, so too shall Israel on an international level. 9) Agreed. DECNET and Coloured Book protocols will be phased out as ISO protocols become available. We are just not quite as optimistic ("should be available in a year or two") as EARN is and therefore see the conversion to Tcp/Ip as a strategy for supplying all the services that ISO is planning, on an interim basis. If for some reason the ISO deadlines slip, we will continue to function with our national Tcp/Ip network until the necessary protocols are available. 10) It is stated in the Transition paper that the conversion is "unlikely to be concluded before 1989." The OSI FTAM standards (all 4 parts: 8571/1, 8571/2, 8571/3, and 8571/4) are still DIS (Draft International Standard), the same status they have been since 1986. If they do turn to IS before the year is over, I do not foresee more than 5-6 supported implementation available before 1990. A more realistic timeframe would be 1992. 11) Israel views these timescales to be extremely optimistic. When dealing with existing services (file transfer, interactive messages and mail) currently provided by EARN, it is very important to have contigency plans in case of unforeseen delays. We view the conversion to Tcp/Ip as an insurance policy that starts paying dividends today. 12) Agreed. 13) "EARN is moving towards the use of ISO protocols as fast as possible, the main delay is caused by the lack of implementations of protocols which is not suprising considering the unstable nature of some of them". That is EARN's conclusion. Israel is committed to ISO conversion as the standards become available. We see Tcp/Ip as an interim solution over the next 7 years. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987070823210200> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Wed 8 Jul 87 19:24:03-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA09191; Wed, 8 Jul 87 18:45:20 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Jul 87 23:21:02 GMT From: hoptoad!gnu@ucbvax.Berkeley.EDU (John Gilmore) Organization: Nebula Consultants in San Francisco Subject: X.400 gateways to RFC822 mail systems Message-Id: <2379@hoptoad.uucp> References: <8707081643.AA28692@ucbvax.Berkeley.EDU> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa The messages on EARN and Israeli conversion reminded me of an issue that's worth airing. The early efforts to provide X.400 mail gateways are not very encouraging. Here is a message I received from such a gateway at AT&T: Return-Path: Received: by hoptoad.uucp (1.1/SMI-3.0DEV3) id AA21284; Thu, 12 Mar 87 20:24:45 PST From: ihnp4!ihlpa!sft Message-Id: <8703130424.AA21284@hoptoad.uucp> Received: by ihnp4.ATT.COM id AA16275; 12 Mar 87 08:07:23 CST (Thu) Message-Version: 2 >To: /addr=ihnp4!hoptoad!gnu Date: Thu, 12 Mar 1987 08:06 CST Message-Service: Mail Message-Protocol: EMail End-Of-Header: Email-Version: 2 X-Postmark: scott.thompson attbl ih5c422 55669 3129792594 ihlpa!sft To: hoptoad!gnu Subject: Re: Wanted: agef program Ua-Message-Id: End-Of-Protocol: Thank you for the reply, but I already received a copy. THANKS :-) To me it looks like a core dump of a binary message header. I asked Mark Horton about this and he said it was from an X.400 gateway and that it was unlikely that it could get fixed, e.g. to remove all the trash headers. This must be political rather than technical since even I can write a sed script that will fix this message right up, and another one to insert meaningless headers on messages going the other way. It strongly reminds me of Geoff Collyer's joke messages that poke fun at RFC822 by inserting silly header lines. But I think these guys are serious, and they're The Telephone Company. -- {dasys1,ncoast,well,sun,ihnp4}!hoptoad!gnu gnu@ingres.berkeley.edu Alt.all: the alternative radio of the Usenet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707090344.aa02151@SEM.BRL.ARPA] <1987070823442000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dpk@BRL.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Internet Uselessness Message-ID: <8707090344.aa02151@SEM.BRL.ARPA> Date: Thu, 9-Jul-87 03:44:20 EDT Article-I.D.: SEM.8707090344.aa02151 Posted: Thu Jul 9 03:44:20 1987 Date-Received: Sat, 11-Jul-87 18:01:30 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 43 Well, I am again trying to use the Internet to accomplish real work and finding it almost impossible due to the almost none-existent throughput. IETF*/BBN/DCA/DARPA have yet to be able to solve the performance problems that have been plaguing the Internet for months. There was a time when I could easily sit here at BRL on the East Coast and manipulate files and programs at Berkeley with ease. This is no longer possible to do reliably. It has gotten to the point now that phone calls at 1200 baud will get more work done. I am getting ready to dust off my UUCP... Lest some of you misunderstand, there are parts of the Internet that are reasonably healthy, such as the MILNET proper, which while its had its problems (e.g. C300 software that falls on its face), in general works fairly well. But the MILNET is only a part of the much larger Internet. The MILNET alone is of little use to us if we cannot talk successfully to the rest of the Internet. Under one hat I am a member of IETF so I am aware of the nature of many of these problems. But under my other hat as a simple "user" of the network, I don't care why its broken, it just needs to get fixed. IETF understands many of the problems, but seems to lack power to get those with the resources to take action. There are ways to fix the network but it takes money and priority on the problem. This need to happen soon. The Internet is needlessly getting a black eye because its not working. Telling me that the load went up and therfore performance went down is no excuse. If we expected to be successful, we should have expected the load. The Internet is too important to all of us (including the military) to let this continue. Do DCA/BBN/DARPA have any comments on this? Who do we have to push to get this fixed? Cheers, -Doug- Doug Kingston Advanced Computer Systems Team Systems Engineering and Concepts Analysis Division U.S. Army Ballistic Research Laboratory * - Internet Engineering Task Force ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987070902261000> Received: from NNSC.NSF.NET by SRI-NIC.ARPA with TCP; Thu 9 Jul 87 06:15:42-PDT To: tcp-ip@sri-nic.ARPA Subject: Internet Protocol #77 Date: Thu, 09 Jul 87 09:06:10 -0400 From: Craig Partridge Here at the CSNET CIC we're collecting some statistics to help us figure out why the CSNET relay is in the top-10 traffic list. One of the things we've done is to start tracking the protocol field in each IP header (to show us which protocols are causing most of our traffic). And before I've even analyzed our data I've found a small anomaly. It clearly isn't causing our traffic problems, but we're receiving packets with the IP protocol field set to 77 decimal. So far it is 21 packets in the past 16 hours). According to RFC 1010 that protocol number is unassigned. Anyone have any guesses what these things are? Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707091325.AA20521@ucbvax.Berkeley.EDU] <1987070905270100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: craig@NNSC.NSF.NET.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Internet Protocol #77 Message-ID: <8707091325.AA20521@ucbvax.Berkeley.EDU> Date: Thu, 9-Jul-87 09:27:01 EDT Article-I.D.: ucbvax.8707091325.AA20521 Posted: Thu Jul 9 09:27:01 1987 Date-Received: Sat, 11-Jul-87 19:39:52 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 15 Here at the CSNET CIC we're collecting some statistics to help us figure out why the CSNET relay is in the top-10 traffic list. One of the things we've done is to start tracking the protocol field in each IP header (to show us which protocols are causing most of our traffic). And before I've even analyzed our data I've found a small anomaly. It clearly isn't causing our traffic problems, but we're receiving packets with the IP protocol field set to 77 decimal. So far it is 21 packets in the past 16 hours). According to RFC 1010 that protocol number is unassigned. Anyone have any guesses what these things are? Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987070905364200> Received: from NNSC.NSF.NET by SRI-NIC.ARPA with TCP; Fri 10 Jul 87 00:34:05-PDT To: tcp-ip@sri-nic.ARPA, ietf-interest@gateway.mitre.org, nsfnet@NNSC.NSF.NET Subject: calendar service Date: Thu, 09 Jul 87 12:16:42 -0400 From: Craig Partridge Hi Folks, The NSF Network Service Center is now maintaining an on-line calendar of events of interest to the Internet/NSFNET community. The hope is that this will help us all manage our time a bit better :-). I've appended the calendar for August as an example below. Calendar entries are available by anonymous FTP from sh.cs.net (calendar/ where is the three letter abbreviation for the month) or through the CSNET Info-Server (info@sh.cs.net) using a request of the form: request: calendar topic: request: end Again, is the three letter abbreviation, or the full month name, e.g. "aug" or "august". If you have meetings or conferences you would like included on this list, mail to calendar-request@nnsc.nsf.net. Thanks, Craig ------------------------- Request: calendar Topic: august Document Updated: 30 June 87 Subject: Internet Calendar for August AUGUST 1987 Aug 3-6 Santa Clara, CA (ACE) TCP/IP Tutorials (Internet, Unix,VMS) Open, for fee. Dan Lynch (Lynch@A.ISI.EDU) 408-996-2042 Aug 4-7 Colo Springs, CO *Symposium on Simulation of Computer Networks Contact: Mitchell Spiegel, GTE 1700 Research Blvd, Rockville, MD 20850 (301)294-8434 Aug 10-12 Vancouver, BC CANADA *6th ACM SIGACT-SIGOPS Symposium on Principles of Distributed Computing (PODC) Contact: David Kirkpatrick, Dept. of Computer Science, U. of British Columbia Vancouver, BC Canada V6T 1W5 Aug 10-15 Honolulu, Hawaii 2nd Int'l Conference on Human-Computer Interaction Contact:Gavriel Salvendy, School of Industrial Engineering, Purdue University, W. Lafayette, IN 47097 (317)494-5426 Aug 11-14 Stowe, VT *SIGCOMM Workshop Sponsors: ACM SIGCOMM Contact: Walter Kosinski Box 4328, Greenwich, CT 06830 Aug 17-21 University Pk, PA *1987 Int'l Conference on Parallel Pro- Penn State U cessing Contact: 1987 International Conference on Parallel Processing, E.E. East Bldg, Penn State University, U. Park, PA 16802 Aug 31-Sep 2 Monterey, CA (ACE) ISO Development Seminar Open, for fee. Dan Lynch (Lynch@A.ISI.EDU) * Taken from "Communications of the ACM", June 1987, Volume 30, Number 6 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707091526.AA01889@MACOM3.ARPA] <1987070907262500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: woody@MACOM3.ARPA (robert a woodburn) Newsgroups: comp.protocols.tcp-ip Subject: talking to sri-nic.arpa Message-ID: <8707091526.AA01889@MACOM3.ARPA> Date: Thu, 9-Jul-87 11:26:25 EDT Article-I.D.: MACOM3.8707091526.AA01889 Posted: Thu Jul 9 11:26:25 1987 Date-Received: Sun, 12-Jul-87 17:58:42 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 Why can't I get through to sri-nic to get a host table update? Did I miss something in the last month? I can send and receive mail just fine, but I cannot use ftp or even ping. Could it be our gateway? Hello? Toto I don't think we're in Vienna, VA anymore.... wood y ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870709155208.970993@RADC-MULTICS.ARPA] <1987070907520000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Ata@RADC-MULTICS.ARPA ("John G. Ata") Newsgroups: comp.protocols.tcp-ip Subject: Re: Israel Tcp/Ip Plans Message-ID: <870709155208.970993@RADC-MULTICS.ARPA> Date: Thu, 9-Jul-87 11:52:00 EDT Article-I.D.: RADC-MUL.870709155208.970993 Posted: Thu Jul 9 11:52:00 1987 Date-Received: Sun, 12-Jul-87 16:53:22 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 11 Henry, SMTP has, within its design, the capablility of sending/receiving interactive messages which appear on the destination addresses terminal. Take a look at the command in RFC 821. I realize that not many implementations may use this, but it is part of the SMTP spec. You might want to check it out. It might be fairly trivial to adapt the mailer to recognize that command, and to have a user interface to send the message. John G. Ata ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707091725.AA07858@cod.nosc.mil] <1987070909253200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: neerma@COD.NOSC.MIL.UUCP Newsgroups: comp.protocols.tcp-ip Subject: TCP between IBM AT and SUN problem Message-ID: <8707091725.AA07858@cod.nosc.mil> Date: Thu, 9-Jul-87 13:25:32 EDT Article-I.D.: cod.8707091725.AA07858 Posted: Thu Jul 9 13:25:32 1987 Date-Received: Sun, 12-Jul-87 03:03:34 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 40 We have several IBM ATs(and compatibles) on an Ethernet along with SUN terminals . We are developing network code on the ATs to interface with Network Research's FUSION TCP package. Basically the AT act as servers. To test our servers we hav e client programs on the SUNs. The server ATs send data to the Suns as fast as the TCP can accept it. Since the client on the SUN is relatively slow(scrolling data to SUN screen) TCP's flow control mechanism is invoked. The problem is that at some point the AT will stop sending data for long periods of time(on the order of minutes). Using a netmonitor program the packet trace reveals the following phenomena: the SUN TCP apparantly ACKs the same data 'bokoo' times; that is the trace shows at some times the SUN is the only one generating packets the packets are TCP only packets(no data) the ACK and SEQ #s are the same on all the packets, the AT is sending nothing in response, the SUN fills up a couple of screens with these, the AT comes to a screeching halt. The packets from the SUN show a large window being advertised yet no data comes from the AT. After several minutes the AT seems to 'wake up' and start sending again. From the netmonitor viewpoint it looks as though the SUN inundates the AT with ACKs; the AT gets uptight and refuses to send any data for a while. It seems the SUN is misbehaving by ACKing data more than once. Since the data field is 0 and only the ACK flag is on it seems the only purose of these packets is to ACK data but maybe I'm missing something. Maybe its trying(correctly) to open a window. (If so, taking a RAMBO approach). The AT by the way has a 3COM 505 interface to the ethernet. Another problem we have seen during this developement are what I would call silly windows being advertised by the SUN. Do SUNs still suffer from this problem? I thought this was done away with long ago? Merle Neer NOSC ------- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [532@saturn.ucsc.edu] <1987070910513500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: haynes@ucscc.UCSC.EDU.ucsc.edu (99700000) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong TCP/IP for VAX/VMS Message-ID: <532@saturn.ucsc.edu> Date: Thu, 9-Jul-87 14:51:35 EDT Article-I.D.: saturn.532 Posted: Thu Jul 9 14:51:35 1987 Date-Received: Sun, 12-Jul-87 15:49:35 EDT References: <8707081702.AA03732@topaz.rutgers.edu> Sender: usenet@saturn.ucsc.edu Reply-To: haynes@ucscc.UCSC.EDU (Jim Haynes) Distribution: world Organization: California State Home for the Weird Lines: 11 In article <8707081702.AA03732@topaz.rutgers.edu> ron@TOPAZ.RUTGERS.EDU (Ron Natalie) writes: >Would you like to propose an alternative. The other major I've heard there is a new package from SRI, and there is also a package from Tektronix that is something like free for big VAXen and not free for Microvaxen.Sorry, I don't have any further info. Jim haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ..ucbvax!ucscc!haynes ----MESSAGE-END---- ----MESSAGE-BEGIN---- [97@rdlvax.UUCP] <1987070911012700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: salzman@rdlvax.UUCP (Gumby) Newsgroups: comp.protocols.tcp-ip,comp.unix.wizards Subject: Problems with internetwork routing in 4.2bsd Message-ID: <97@rdlvax.UUCP> Date: Thu, 9-Jul-87 15:01:27 EDT Article-I.D.: rdlvax.97 Posted: Thu Jul 9 15:01:27 1987 Date-Received: Sun, 12-Jul-87 10:18:13 EDT Reply-To: salzman@rdlvax.UUCP (Gumby) Distribution: world Organization: Research Development Labs, Culver City, CA. Lines: 26 Keywords: 4.2bsd tcp/ip routing gateway Does anyone know of any inherent problems/bugs in vanilla 4.2bsd internetwork routing? Our machine has just been put on the ARPANET via a 19.2K baud leased line to an imp off site (using an ACC HDH interface). We can't seem to connect to any site outside of the ARPANET (i.e. any site that does not have an address of 10.?.?.?). Every attempt times out. I realize there's the possibility of the gateways being too loaded, but, I can get from another machine that lies on another net (i.e. milnet) to our host without any problems -- so it only effects outgoing attempts. Doing a netstat shows that the state it's hung in is "SYN_SENT", and it seems to never change that state. Doing a netstat -r shows that some attempt has been made to connect on the gateway (there will be a number in the "use" column for that gateway). Does anyone have any clue why this is happening? Are there any fixes that can be obtained? This is a vanilla 4.2bsd system on a VAX 11/780. We are planning an upgrade to 4.3bsd fairly soon, but not soon enough. Any help would be greatly appreciated.... Thanks. -- * Isaac Salzman - Systems Analyst/Admin. ---- * Research Development Labs (RDL) /o o/ / * 5721 W. Slauson Ave., Culver City, CA. 90230 | v | | * AT&T: +1 213 410 1244, x118 _| |_/ * ARPA: salzman@rdlvax.RDL.COM / | | * UUCP: ...!{psivax,csun,sdcrdcf,ttidca}!rdlvax!salzman | | | ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12317178690.17.MKL@SRI-NIC.ARPA] <1987070923232000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MKL@SRI-NIC.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: talking to sri-nic.arpa Message-ID: <12317178690.17.MKL@SRI-NIC.ARPA> Date: Fri, 10-Jul-87 03:23:20 EDT Article-I.D.: SRI-NIC.12317178690.17.MKL Posted: Fri Jul 10 03:23:20 1987 Date-Received: Sun, 12-Jul-87 08:59:04 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 I can't tell you why you couldn't get thru to the NIC for a host table update. I can tell you that on July 9th, 60 people did get thru and retrieve a host table, despite some network related problems we had. If you can supply specific details of your problem to ACTION@SRI-NIC.ARPA we will investigate. Mark ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707100828.AA11167@ucbvax.Berkeley.EDU] <1987071000295000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: craig@NNSC.NSF.NET.UUCP Newsgroups: comp.protocols.tcp-ip Subject: calendar service Message-ID: <8707100828.AA11167@ucbvax.Berkeley.EDU> Date: Fri, 10-Jul-87 04:29:50 EDT Article-I.D.: ucbvax.8707100828.AA11167 Posted: Fri Jul 10 04:29:50 1987 Date-Received: Sun, 12-Jul-87 08:59:28 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 82 Hi Folks, The NSF Network Service Center is now maintaining an on-line calendar of events of interest to the Internet/NSFNET community. The hope is that this will help us all manage our time a bit better :-). I've appended the calendar for August as an example below. Calendar entries are available by anonymous FTP from sh.cs.net (calendar/ where is the three letter abbreviation for the month) or through the CSNET Info-Server (info@sh.cs.net) using a request of the form: request: calendar topic: request: end Again, is the three letter abbreviation, or the full month name, e.g. "aug" or "august". If you have meetings or conferences you would like included on this list, mail to calendar-request@nnsc.nsf.net. Thanks, Craig ------------------------- Request: calendar Topic: august Document Updated: 30 June 87 Subject: Internet Calendar for August AUGUST 1987 Aug 3-6 Santa Clara, CA (ACE) TCP/IP Tutorials (Internet, Unix,VMS) Open, for fee. Dan Lynch (Lynch@A.ISI.EDU) 408-996-2042 Aug 4-7 Colo Springs, CO *Symposium on Simulation of Computer Networks Contact: Mitchell Spiegel, GTE 1700 Research Blvd, Rockville, MD 20850 (301)294-8434 Aug 10-12 Vancouver, BC CANADA *6th ACM SIGACT-SIGOPS Symposium on Principles of Distributed Computing (PODC) Contact: David Kirkpatrick, Dept. of Computer Science, U. of British Columbia Vancouver, BC Canada V6T 1W5 Aug 10-15 Honolulu, Hawaii 2nd Int'l Conference on Human-Computer Interaction Contact:Gavriel Salvendy, School of Industrial Engineering, Purdue University, W. Lafayette, IN 47097 (317)494-5426 Aug 11-14 Stowe, VT *SIGCOMM Workshop Sponsors: ACM SIGCOMM Contact: Walter Kosinski Box 4328, Greenwich, CT 06830 Aug 17-21 University Pk, PA *1987 Int'l Conference on Parallel Pro- Penn State U cessing Contact: 1987 International Conference on Parallel Processing, E.E. East Bldg, Penn State University, U. Park, PA 16802 Aug 31-Sep 2 Monterey, CA (ACE) ISO Development Seminar Open, for fee. Dan Lynch (Lynch@A.ISI.EDU) * Taken from "Communications of the ACM", June 1987, Volume 30, Number 6 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987071003450000> Mail-From: STJOHNS created at 10-Jul-87 10:46:17 Date: 10 Jul 1987 10:45-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: SNAP Protocol From: STJOHNS@SRI-NIC.ARPA To: jcollas@XN.LL.MIT.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]10-Jul-87 10:45:14.STJOHNS> In-Reply-To: <8707081839.AA26178@XN.LL.MIT.EDU> Without reading the document, I'd guess that SNAP stands for "Sub Network Access Protocol". and as such refers to not one, but several protocols including the Etherenet, DDN X.25 and AHIP, Hyperchannel, Proteon ring... etc... Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870710143745.001@M5.Sdsc.Edu] <1987071006374300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gkn@SDS.SDSC.EDU Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP for VMS Message-ID: <870710143745.001@M5.Sdsc.Edu> Date: Fri, 10-Jul-87 10:37:43 EDT Article-I.D.: M5.870710143745.001 Posted: Fri Jul 10 10:37:43 1987 Date-Received: Mon, 13-Jul-87 03:42:02 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 21 We used to run TWG's stuff here until I got tired of it crashing the VAXcluster and flooding the local ethernet with garbage. We've been using SRI's MultiNet-Plus for about a year now, and are quite pleased with it. It not only works, it works well. You have your choice of mail systems (Pony Express, PMDF, and Software Tools), an excellent TELNET and FTP implementation, QIO compataibility with TWG's stuff, a name server, dynamic routing (EGP, RIP, and Hello), nice tools to maintain the network configuration and server database. In addition to TCP/UDP, it supports Chaos and PUP. gkn -------------------------------------- Arpa: GKN@SDS.SDSC.EDU Bitnet: GKN@SDSC Span: SDSC::GKN (27.1) USPS: Gerard K. Newman San Diego Supercomputer Center P.O. Box 85608 San Diego, CA 92138 AT&T: 619.534.5076 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [318@blisierra.BLI.COM] <1987071007572500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: stephen@blisierra.BLI.COM (Stephen Belair) Newsgroups: comp.protocols.misc,comp.protocols.tcp-ip Subject: Seeking info on the AMD 7992A ("LANCE") Ethernet controller Message-ID: <318@blisierra.BLI.COM> Date: Fri, 10-Jul-87 11:57:25 EDT Article-I.D.: blisierr.318 Posted: Fri Jul 10 11:57:25 1987 Date-Received: Sun, 12-Jul-87 13:55:57 EDT Distribution: na Organization: Britton Lee, Los Gatos, CA Lines: 9 Does anyone out there have any experience with the AMD Ethernet chip, or with the Mostek 68590 LANCE Ethernet controller? Any nice features with either? Any nasty bugs? Performance? Any comments or experience with these are welcomed and would be greatly appreciated. stephen belair ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1168@ccicpg.UUCP] <1987071008243700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cracraft@ccicpg.UUCP (Stuart Cracraft) Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet Uselessness Message-ID: <1168@ccicpg.UUCP> Date: Fri, 10-Jul-87 12:24:37 EDT Article-I.D.: ccicpg.1168 Posted: Fri Jul 10 12:24:37 1987 Date-Received: Sun, 12-Jul-87 12:32:11 EDT References: <8707090344.aa02151@SEM.BRL.ARPA> Reply-To: cracraft@ccicpg.UUCP (Stuart Cracraft) Distribution: world Organization: CCI CPG, Irvine CA Lines: 26 In article <8707090344.aa02151@SEM.BRL.ARPA> dpk@BRL.ARPA (Doug Kingston) writes: >Well, I am again trying to use the Internet to accomplish real >work and finding it almost impossible due to the almost none-existent >throughput. > There have been some real performance problems lately. Multi-second delays between characters on TAC access from a TAC local to the area code of the destination host. >Lest some of you misunderstand, there are parts of the Internet >that are reasonably healthy, such as the MILNET proper... >But the MILNET is only a part of the much larger Internet. >The MILNET alone is of little use to us if we cannot talk >successfully to the rest of the Internet. > The situation described above occurred on a MILNET TAC. Response from NIC and the host (a central hub) indicated that it was a known problem that BBN is actively working on. TAC performance has improved somewhat since then though multi-second delays still occur, frequently. >... >Who do we have to push to get this fixed? Talk with NIC and BBN. Stuart ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707102001.AA04611@seismo.CSS.GOV] <1987071008390000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: RCL@uokucs.UUCP ("Rich Lewis : Black Dragon") Newsgroups: comp.protocols.tcp-ip Subject: User Message-ID: <8707102001.AA04611@seismo.CSS.GOV> Date: Fri, 10-Jul-87 12:39:00 EDT Article-I.D.: seismo.8707102001.AA04611 Posted: Fri Jul 10 12:39:00 1987 Date-Received: Sun, 12-Jul-87 14:24:08 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 62 I have been recieving messages addressed to JAY at this site, there does not exists any such user. Enclosed is a copy of one such letter with the path. Please make the necessary changes to you mailing list. Thanks for your consideration, Rich Lewis, Postmaster. ------------------------------------------------------------------------------- > Received: from uokmax.uucp by uokucs.uucp; Thu, 9 Jul 87 02:39 CST > Received: from texsun by uokmax.uucp id aa32127; 9 Jul 87 1:40 CDT > Received: from snail.sun.com (snail-swanbb) by Central.Sun.COM (3.2/SMI-3.2) > id AA02309; Wed, 8 Jul 87 23:22:19 CDT > Received: from Sun.COM (arpa-dev) by snail.sun.com (4.0/SMI-3.2) > id AA19753; Wed, 8 Jul 87 21:19:27 PDT > Received: from devvax.TN.CORNELL.EDU by Sun.COM (4.0/SMI-3.2) > id AA06233; Wed, 8 Jul 87 21:19:58 PDT > Received: by devvax.TN.CORNELL.EDU (5.54/1.3-Cornell-Theory-Center) > id AA06593; Thu, 9 Jul 87 00:22:10 EDT > Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Tue 7 Jul 87 20:01:03-PDT > Received: by ucbvax.Berkeley.EDU (5.58/1.27) > id AA16474; Tue, 7 Jul 87 19:47:22 PDT > Received: from USENET by ucbvax.Berkeley.EDU with netnews > for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) > (contact usenet@ucbvax.Berkeley.EDU if you have questions) > Date: 7 Jul 87 22:51:39 GMT > From: Dennis Weaver > Organization: ISC Systems Corporation, Spokane, Wa. > Subject: Request for info on public domain TCP-IP source > Message-Id: <562@iscuva.ISCS.COM> > Sender: tcp-ip-request@sri-nic.arpa > To: tcp-ip%sri-nic.arpa@texsun.uucp > > We are interested in locating "Public Domain" source of TCP-IP, FTP & TELNET > written in "C" (if such a thing exists). Does anyone know where we can find > these sources ??? > > Thanks in advance. ------------------------------------------------------------------------------- Richard C. Lewis, Jr. University of Oklahoma University Computing Services 601 Elm, PhSC 235 Norman, Ok 73019 USA Voice: (405) 325-6988 E-Mail in order of preference. USEnet: rcl%uokucs@uokmax.uucp rcl@uokucs.uucp rich@uokmax.uucp UUCP: uokucs!rcl uokmax!uokucs!rcl seismo!okstate!uokmax!uokucs!rcl ihnp4!gorgo!rcl Internet: rcl@gorgo.att.com Pick a net, ANY net. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[SRI-NIC.ARPA]10-Jul-87.10:45:14.STJOHNS] <1987071009450000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: STJOHNS@SRI-NIC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: SNAP Protocol Message-ID: <[SRI-NIC.ARPA]10-Jul-87.10:45:14.STJOHNS> Date: Fri, 10-Jul-87 13:45:00 EDT Article-I.D.: <[SRI-NIC.ARPA]10-Jul-87.10:45:14.STJOHNS> Posted: Fri Jul 10 13:45:00 1987 Date-Received: Mon, 13-Jul-87 04:23:46 EDT References: <8707081839.AA26178@XN.LL.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Without reading the document, I'd guess that SNAP stands for "Sub Network Access Protocol". and as such refers to not one, but several protocols including the Etherenet, DDN X.25 and AHIP, Hyperchannel, Proteon ring... etc... Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707101749.AA06655@mitre.arpa] <1987071009494200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA (H. Craig McKee) Newsgroups: comp.protocols.tcp-ip Subject: Re: X.400 gateways to RFC822 mail systems Message-ID: <8707101749.AA06655@mitre.arpa> Date: Fri, 10-Jul-87 13:49:42 EDT Article-I.D.: mitre.8707101749.AA06655 Posted: Fri Jul 10 13:49:42 1987 Date-Received: Mon, 13-Jul-87 05:06:13 EDT References: <2379@hoptoad.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The MITRE Corp., Washington, D.C. Lines: 8 >The messages on EARN and Israeli conversion reminded me of an issue >that's worth airing. The early efforts to provide X.400 mail gateways >are not very encouraging. Your message had 15 header lines on my screen, the X.400 example had 18; it doesn't seem that big a difference. I'm not a mail expert but I suspect the header lines will necessary during trouble shooting. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1044.552936056@limbo.uci.edu] <1987071010313100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: netser@limbo.UCI.EDU (Richard Johnson) Newsgroups: comp.protocols.tcp-ip Subject: Strange ICMP messages Message-ID: <1044.552936056@limbo.uci.edu> Date: Fri, 10-Jul-87 14:31:31 EDT Article-I.D.: limbo.1044.552936056 Posted: Fri Jul 10 14:31:31 1987 Date-Received: Sun, 12-Jul-87 12:16:27 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 14 I was looking at ICMP packets on our network this morning and noticed that we're getting LOTS (about 1 every 5 seconds!) of "time exceeded" ICMP messages from ai-gw.ai.mit.edu (128.52.22.8) destined to icsd.uci.edu (192.5.19.4). The strange thing about this is that we don't have any connections with any place at MIT! I check icsd for current connections and find there are only 4 and that all 4 are to other machines on our local network! Maybe this has something to do with the fact that the whole Internet seems to be terribly bogged down these days? Does anyone have an explanation? ---------------------------------------------------------------------------- Richard Johnson netser@ics.uci.edu (Internet) UCI ICS Network Services ...!ucbvax!ucivax!netser (UUCP) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707110734.AA19906@umd5.UMD.EDU] <1987071023342700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jac@UMD5.UMD.EDU (Joseph A. Cimmino Jr.) Newsgroups: comp.protocols.tcp-ip Subject: Re: SNAP Protocol Message-ID: <8707110734.AA19906@umd5.UMD.EDU> Date: Sat, 11-Jul-87 03:34:27 EDT Article-I.D.: umd5.8707110734.AA19906 Posted: Sat Jul 11 03:34:27 1987 Date-Received: Sun, 12-Jul-87 14:31:06 EDT References: <8707081839.AA26178@XN.LL.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 15 It's been a long time since I've looked at the ULANA spec, but the SNAP you're intersted in may be the "SubNetwork Access Protocol" that is used to encapsulate IP/ARP on IEEE 802 LANS. Snap is used on the IBM Token Ring in the IBM implementation of PC/IP. See RFC-990 "Assigned Numbers", page 36, section on IEEE numbers of interest for a spec. There may also be an RFC on SNAP itself and/or a later issue of "Assigned Numbers". Hope this is a helpful start. /joe ------------------------------ Joseph A. Cimmino, Jr. University of Maryland, Systems jac@umd5.umd.edu 1+ 301 454 2946 PC/IP Group cimminoj@umdd.bitnet Bertolt Brecht: You made your bed, so you lie in it. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987071107061500> Received: from lindy.stanford.edu by SRI-NIC.ARPA with TCP; Sat 11 Jul 87 21:03:44-PDT Received: by lindy.stanford.edu; Sat, 11 Jul 87 21:04:44 PDT Date: Sat, 11 Jul 87 14:06:15 PDT From: Bill Yundt To: tcp-ip@sri-nic.arpa Subject: fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin REPLY TO 07/07/87 11:46 FROM KHANNA@AHWAHNEE.STANFORD.EDU "Raman Khanna": fyi Mr. Crispin, Wollongong's CURRENT release ....v 3.0....seems to work quite well, contrary to your pathetically ill informed view. I suggest you look into your facts before ventilating your hot air. People who call you should be encouraged to move to the correct version of the software ....which does appear to have bugs fixed...in addition to supporting domains, etc. The Wollongong Group got a deservedly bad reputation some time back because they didn't put any inside effort in to the product...relying on Dave Kashtan for everything. They appear to have remedied that problem and become independent of Mr. Kashtan's availability....both of which are probably constructive. Bill Yundt, Director, Networking and Communications Systems Stanford University To: TCP-IP@SRI-NIC.ARPA cc: KHANNA@AWANEE ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707111735.AA09270@ucbvax.Berkeley.EDU] <1987071109194100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: Re: Israel Tcp/Ip Plans Message-ID: <8707111735.AA09270@ucbvax.Berkeley.EDU> Date: Sat, 11-Jul-87 13:19:41 EDT Article-I.D.: ucbvax.8707111735.AA09270 Posted: Sat Jul 11 13:19:41 1987 Date-Received: Sun, 12-Jul-87 16:12:11 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Hank, Thanks for posting your large document on Israel's plan for adopting TCP/IP while waiting for the ISO protocols to get more fully defined and supported. It certainly shows a lot of thought and effort has been made in arriving at this decision. I noticed that you left out a number of sections that deal with costing data in order to comply with Bitnet and EARN strictures. Since you sent this directly to the TCP/IP list you could put them back in and make the description and analysis much more complete. Thanks, Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987071109194101> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sat 11 Jul 87 10:26:31-PDT Date: 11 Jul 1987 13:19:41 EDT Subject: Re: Israel Tcp/Ip Plans From: Dan Lynch To: Henry Nussbacher cc: tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU In-Reply-To: (Message from "Henry Nussbacher " of Wed, 08 Jul 87 17:09:42 P) Hank, Thanks for posting your large document on Israel's plan for adopting TCP/IP while waiting for the ISO protocols to get more fully defined and supported. It certainly shows a lot of thought and effort has been made in arriving at this decision. I noticed that you left out a number of sections that deal with costing data in order to comply with Bitnet and EARN strictures. Since you sent this directly to the TCP/IP list you could put them back in and make the description and analysis much more complete. Thanks, Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707111851.AA27739@topaz.rutgers.edu] <1987071110514500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong TCP/IP for VAX/VMS Message-ID: <8707111851.AA27739@topaz.rutgers.edu> Date: Sat, 11-Jul-87 14:51:45 EDT Article-I.D.: topaz.8707111851.AA27739 Posted: Sat Jul 11 14:51:45 1987 Date-Received: Sun, 12-Jul-87 16:44:05 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 It appears that Wollongong's attitude may be changing. After posting my comments (which were not critical of Wollongong in any case, since as we as I know, we had never reported this problem to them) I got a call from one of their folks, with some suggestions for short-term fixes, and assurances that the newest release (which we just got, but have not yet installed) will provide more permanent solutions. He was extremely helpful and knowledgeable. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707120420.AA16047@ucbvax.Berkeley.EDU] <1987071113061500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: GD.WHY@FORSYTHE.STANFORD.EDU (Bill Yundt) Newsgroups: comp.protocols.tcp-ip Subject: fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin Message-ID: <8707120420.AA16047@ucbvax.Berkeley.EDU> Date: Sat, 11-Jul-87 17:06:15 EDT Article-I.D.: ucbvax.8707120420.AA16047 Posted: Sat Jul 11 17:06:15 1987 Date-Received: Sun, 12-Jul-87 18:03:12 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 25 REPLY TO 07/07/87 11:46 FROM KHANNA@AHWAHNEE.STANFORD.EDU "Raman Khanna": fyi Mr. Crispin, Wollongong's CURRENT release ....v 3.0....seems to work quite well, contrary to your pathetically ill informed view. I suggest you look into your facts before ventilating your hot air. People who call you should be encouraged to move to the correct version of the software ....which does appear to have bugs fixed...in addition to supporting domains, etc. The Wollongong Group got a deservedly bad reputation some time back because they didn't put any inside effort in to the product...relying on Dave Kashtan for everything. They appear to have remedied that problem and become independent of Mr. Kashtan's availability....both of which are probably constructive. Bill Yundt, Director, Networking and Communications Systems Stanford University To: TCP-IP@SRI-NIC.ARPA cc: KHANNA@AWANEE ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707120607.AA00586@gyre.umd.edu] <1987071122075200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: chris@GYRE.UMD.EDU (Chris Torek) Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet Protocol #77 Message-ID: <8707120607.AA00586@gyre.umd.edu> Date: Sun, 12-Jul-87 02:07:52 EDT Article-I.D.: gyre.8707120607.AA00586 Posted: Sun Jul 12 02:07:52 1987 Date-Received: Mon, 13-Jul-87 00:38:07 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Protocol number 77 is Sun's ND (not to be confused with NFS, which uses UDP). None of these should ever appear on the Internet! Someone is leaking local traffic. Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707120337.a026370@Huey.UDEL.EDU] <1987071123371100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: talking to sri-nic.arpa Message-ID: <8707120337.a026370@Huey.UDEL.EDU> Date: Sun, 12-Jul-87 03:37:11 EDT Article-I.D.: Huey.8707120337.a026370 Posted: Sun Jul 12 03:37:11 1987 Date-Received: Mon, 13-Jul-87 00:39:34 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Woody, The Wicked Witch of the East wasn't zapped by Dorothy's house after all. She managed to axe some useful nets from the linkabit-gw tables, including 192.5.39 (us). The tables, after all, are too small. As for SRI-NIC, try to connect to its ARPANET address 10.0.0.51 directly, rather than its hosts.txt address, which is on MILNET. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707121735.AA13677@topaz.rutgers.edu] <1987071209351700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet Protocol #77 Message-ID: <8707121735.AA13677@topaz.rutgers.edu> Date: Sun, 12-Jul-87 13:35:17 EDT Article-I.D.: topaz.8707121735.AA13677 Posted: Sun Jul 12 13:35:17 1987 Date-Received: Mon, 13-Jul-87 03:48:29 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 4 77 is Sun's network disk protocol. This is the predecessor to NFS, and will be phased out near the end of the year. Apparently this number was not assigned by the number Czar, but will simply pulled out of a hat and used unofficially. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [432@umbc3.UMD.EDU] <1987071213345400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jeff@umbc3.UMD.EDU (Jeffrey Burgan) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong TCP/IP for VAX/VMS Message-ID: <432@umbc3.UMD.EDU> Date: Sun, 12-Jul-87 17:34:54 EDT Article-I.D.: umbc3.432 Posted: Sun Jul 12 17:34:54 1987 Date-Received: Mon, 13-Jul-87 04:11:06 EDT References: <12316245218.8.MRC@PANDA> Reply-To: jeff@umbc3.umd.edu (Jeffrey Burgan) Distribution: world Organization: University of Maryland, Baltimore County Lines: 32 In article <12316245218.8.MRC@PANDA> MRC@PANDA.COM (Mark Crispin) writes: > > I received my nth bug report from a Wollongong site today complaining >that mail didn't work between them and a DEC-20. > > The problem is, of course, that the Wollongong software simply does >not work ... and that Wollongong simply does not care. We have been running Wollongong's software for 2 years and have never experienced any problems sending to a TOPS-20 machine. This is not to say that mail always makes it through the first time, but remember we are talking about the Internet. For a resolution to most problems, people should possibly look no further than there own systems to make sure they have configured them correctly and that nothing has "mysteriously" changed. Set-up changes do not constitute a software bug. All that you have accomplished with this article is to misrepresent the facts. If people are really reporting bugs to you, would it not be more productive (both to you and us) to report it so that if there is a bug, it can be fixed? If you call them and tell them something is not working, they will at least work with you to solve the problem. Simply, my Wollongong software DOES work. In the past 2 years, I have made my criticism of the software known to them, bugs and all. Although not perfect, their software and support have improved greatly over the last year, and they have worked with me through several bugs and/or software modifications. What would you have VMS user's use? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987071216530000> Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Sun 12 Jul 87 13:57:59-PDT Received: from rsre.mod.uk by nss.Cs.Ucl.AC.UK via PSS with NIFTP id aa06867; 12 Jul 87 21:52 BST To: Doug Kingston <@Cs.Ucl.AC.UK:dpk@brl.arpa> Cc: ietf <@Cs.Ucl.AC.UK:ietf@gateway.mitre.org>, tcp-ip <@Cs.Ucl.AC.UK:tcp-ip@sri-nic.arpa> From: John Laws (on UK.MOD.RSRE) Date: Sun, 12 Jul 87 21:53 In-reply-to: <8707090344.aa02151@SEM.BRL.ARPA> Message-Id: <12 JUL 1987 21:53:25 LAWS@RSRE> Subject: Re: Internet Uselessness Doug, I also have suffered (not quietly) for the last 10 months with the terrible state of the Internet. I know some people in DARPA/BBN/DCA but seemingly not the ones who "can make it happen" - (no offence intended to those I know). More than the Internet getting a black eye consider the following. The Internet uses TCP/IP. There are elements of the Internet (Arpanet, Milnet) that are under-resourced for the traffic - the performance can be so bad that my remote host timeouts on me whem I'm trying to login. TCP/IP is pushed by many members of DOD as the right protocol to be used for networks in a military environment. Yes, they are going to transition to ISO OSI - same protocols almost, TP4 and IP (via NBS). Now my vision of a military Internet is that it starts off in peacetime with JUST enough resource for peacetime traffic (budget problems on the Defence Vote we'll plug it next year etc (I think you call it Get Well Later in the US)). Then the action starts to warm up a little (the Gulf - Iraq/Iran) and the Internet falls over the knee of the curve. In part this is a consequence of some very stupid implementations of TCP/IP, some elements of the protocol which if implemented in a straightforward way cause congestion once it has occured, and seemingly a complete failure to develop some other concepts (access control sensitive to traffic volume, precedence and priority) to the same degree. While the PTT X25 solution does potentially have its problems in a hostile environment (note - X25 is more an interface than an end-to-end protocol and the spec does not forbid self-healing nets being built - it just needs the market to pay for it) its performance is generally to a high standard. For good reason, revenue depends on connection time AND traffic volume. Maybe the answer is to fund the Internet a different way - the PTT way. John ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12.JUL.1987.21:53:25.LAWS@RSRE] <1987071220530000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE) Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet Uselessness Message-ID: <12.JUL.1987.21:53:25.LAWS@RSRE> Date: Mon, 13-Jul-87 00:53:00 EDT Article-I.D.: RSRE.12.JUL.1987.21:53:25.LAWS Posted: Mon Jul 13 00:53:00 1987 Date-Received: Mon, 13-Jul-87 05:12:35 EDT References: <8707090344.aa02151@SEM.BRL.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 38 Doug, I also have suffered (not quietly) for the last 10 months with the terrible state of the Internet. I know some people in DARPA/BBN/DCA but seemingly not the ones who "can make it happen" - (no offence intended to those I know). More than the Internet getting a black eye consider the following. The Internet uses TCP/IP. There are elements of the Internet (Arpanet, Milnet) that are under-resourced for the traffic - the performance can be so bad that my remote host timeouts on me whem I'm trying to login. TCP/IP is pushed by many members of DOD as the right protocol to be used for networks in a military environment. Yes, they are going to transition to ISO OSI - same protocols almost, TP4 and IP (via NBS). Now my vision of a military Internet is that it starts off in peacetime with JUST enough resource for peacetime traffic (budget problems on the Defence Vote we'll plug it next year etc (I think you call it Get Well Later in the US)). Then the action starts to warm up a little (the Gulf - Iraq/Iran) and the Internet falls over the knee of the curve. In part this is a consequence of some very stupid implementations of TCP/IP, some elements of the protocol which if implemented in a straightforward way cause congestion once it has occured, and seemingly a complete failure to develop some other concepts (access control sensitive to traffic volume, precedence and priority) to the same degree. While the PTT X25 solution does potentially have its problems in a hostile environment (note - X25 is more an interface than an end-to-end protocol and the spec does not forbid self-healing nets being built - it just needs the market to pay for it) its performance is generally to a high standard. For good reason, revenue depends on connection time AND traffic volume. Maybe the answer is to fund the Internet a different way - the PTT way. John ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]13-Jul-87.07:55:25.CERF] <1987071303550000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet meltdowns Message-ID: <[A.ISI.EDU]13-Jul-87.07:55:25.CERF> Date: Mon, 13-Jul-87 07:55:00 EDT Article-I.D.: <[A.ISI.EDU]13-Jul-87.07:55:25.CERF> Posted: Mon Jul 13 07:55:00 1987 Date-Received: Tue, 14-Jul-87 03:34:17 EDT References: <8707081440.AA00679@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Charles, In case I haven't said it earlier, I just want you to know that your concrete contributions to the Internet technology and practical comments on various pieces of software and hardware have been extremely helpful. Keep up the good work (fight the good fight?). Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707131458.AA12502@nic.nyser.net] <1987071306582700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: weltyc@NIC.NYSER.NET (Christopher A. Welty) Newsgroups: comp.protocols.tcp-ip Subject: fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin Message-ID: <8707131458.AA12502@nic.nyser.net> Date: Mon, 13-Jul-87 10:58:27 EDT Article-I.D.: nic.8707131458.AA12502 Posted: Mon Jul 13 10:58:27 1987 Date-Received: Tue, 14-Jul-87 05:35:18 EDT References: <8707131403.AA24872@csv.rpi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 18 > Wollongong's CURRENT release ....v 3.0....seems to work quite well, > contrary to your pathetically ill informed view. I suggest you look > into your facts before ventilating your hot air. Unnecessary, quite unnecessary. One of the problems we've been having is the fact that the TWG software for VMS and UNIX V doesn't support subnetting. Is this fixed with the new release? Is there a new releasee of the System V stuff? We are using version 1.1 (which is what ATT distributes). I don't remember what release we're running for the VMS machines... --- Christopher Welty - Asst. Director, RPI CS Labs weltyc@cs.rpi.edu ...!seismo!rpics!weltyc ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707131311.a011655@Huey.UDEL.EDU] <1987071309115000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet Protocol #77 Message-ID: <8707131311.a011655@Huey.UDEL.EDU> Date: Mon, 13-Jul-87 13:11:50 EDT Article-I.D.: Huey.8707131311.a011655 Posted: Mon Jul 13 13:11:50 1987 Date-Received: Wed, 15-Jul-87 00:41:46 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 22 Chris, Is "protocol number 77" expressed in octal or decimal? Protocol number 63 (decimal) or 77 (octal) is reserved for local use, according to the assigned- numbers list. My interpretation of this is that gateways should not forward IPgrams carrying this number, so the NSFNET Backbone gateways, at least, do not; therefore, your traffic certianly did not rumble that way. Having said this, I am somewhat concerned about loopback and other things intended to have only local relevance and "never escape the local net." Some things, in particular local routing information and local broadcasts seem in tune with this notion, since they depend on addressing independent of local-network characteristics. However, some others (ND, NFS?) depend on the characteristics of the local net (delay, discard rate, etc.) as an intrinsic requirement for acceptable service. The use of addressing scope to delimit service range in such cases seems conuterproductive. What you really want is scope determined by maximum acceptable delay; in other words, some mapping of type-of-service plus maybe a new IP option. This is the same thing needed for packet speech and, in fact, implemented in those gateways supporting the Stream (ST) Protocol. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987071310410000> Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Mon 13 Jul 87 08:05:10-PDT Received: from rsre.mod.uk by nss.Cs.Ucl.AC.UK via PSS with NIFTP id aa08038; 13 Jul 87 15:40 BST To: Bill Yundt <@Cs.Ucl.AC.UK:GD.WHY@forsythe.stanford.edu> Cc: tcp-ip <@Cs.Ucl.AC.UK:tcp-ip@sri-nic.arpa> From: John Laws (on UK.MOD.RSRE) Date: Mon, 13 Jul 87 15:41 Message-Id: <13 JUL 1987 15:41:17 LAWS@RSRE> Subject: Re: fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin Bill, I was delighted to hear your good news on Wollongong's TCP/IP implementation. The current version in the UK does have the bad habit of sending single byte TCP packets from Telnet - not being very kind to the current congestion of parts of the Internet. We have found no way to make it send multi-byte. Does the new version solve this? Do Wollongong US see the TCP-IP discussion? If they do, I would appreciate the UK supplier GEC Software getting the new version quickly. I think our current version is 2.3. John ----MESSAGE-END---- ----MESSAGE-BEGIN---- [13.JUL.1987.15:41:17.LAWS@RSRE] <1987071314410000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE) Newsgroups: comp.protocols.tcp-ip Subject: Re: fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin Message-ID: <13.JUL.1987.15:41:17.LAWS@RSRE> Date: Mon, 13-Jul-87 18:41:00 EDT Article-I.D.: RSRE.13.JUL.1987.15:41:17.LAWS Posted: Mon Jul 13 18:41:00 1987 Date-Received: Tue, 14-Jul-87 06:37:27 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 13 Bill, I was delighted to hear your good news on Wollongong's TCP/IP implementation. The current version in the UK does have the bad habit of sending single byte TCP packets from Telnet - not being very kind to the current congestion of parts of the Internet. We have found no way to make it send multi-byte. Does the new version solve this? Do Wollongong US see the TCP-IP discussion? If they do, I would appreciate the UK supplier GEC Software getting the new version quickly. I think our current version is 2.3. John ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1604@phred.UUCP] <1987071316332600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: marcg@phred.UUCP (Marc Greisen) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans Subject: Vaxes and the System 38 Message-ID: <1604@phred.UUCP> Date: Mon, 13-Jul-87 20:33:26 EDT Article-I.D.: phred.1604 Posted: Mon Jul 13 20:33:26 1987 Date-Received: Thu, 16-Jul-87 03:26:58 EDT Reply-To: marcg@phred.UUCP (Marc Greisen) Distribution: world Organization: Physio-Control Corp., Seattle, WA Lines: 46 Summary: We have several vaxes that run either VMS and Ultrix and talk on ethernet. We want to talk to two IBM system 38's that talk together on a X.25 network. At present our vaxes talk on ethernet. What we need is to talk to the system 38 with something other then sneaker net. What we want is a tcp/ip implementation for the system 38, with ftp,telnet,smtp,ect... Solutions we have looked at: 1. Dec SNA gateway software/hardware Our Dec sales person has told us the current implementation of SNA on the 38 will not support a connection to dec's gateway. 2. Kodaks Syncra software/hardware We have only looked at the manuals but it seems that they implement a black box solution. Their software will transfer files and provide terminal emulation, but only with menu driven utilities, no hooks into the software to build our own applications. They run tcp/ip on the LAN but you can't do anything with it. Possibilities: 1. The system 38's run some kind of X.25 network. I don't know anything about x.25, is there some equivalent to ftp,smtp ect...? I do know there are boxes made that do ethernet to x.25 bridging. 2. Unknown vendor of tcp/ip for the 38 3. Hyper-channel? It seems thought that there are no real flexible solutions. Any suggestions I could get that would provide possibilities or solutions would be gratefully accepted. Marc Greisen Physio-Control Corp. ...tikal!phred!marcg (206)867-4535 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [670@julian.UWO.CDN] <1987071317212800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: peter@julian.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong TCP/IP for VAX/VMS Message-ID: <670@julian.UWO.CDN> Date: Mon, 13-Jul-87 21:21:28 EDT Article-I.D.: julian.670 Posted: Mon Jul 13 21:21:28 1987 Date-Received: Wed, 15-Jul-87 01:32:04 EDT References: <12316245218.8.MRC@PANDA> <8707071930.AA08177@nic.nyser.net> Reply-To: peter@julian.UUCP (Peter Marshall) Distribution: world Organization: University of Western Ontario, London Lines: 14 In article <8707071930.AA08177@nic.nyser.net> weltyc@NIC.NYSER.NET (Christopher A. Welty) writes: > > You might also tell DEC about it, since they sell TWG software >for VMS as the official VAX?VMS TCP/IP product. In my last conversation with Digital about this, they said that Digital had had so much support trouble with The Wollongong Group that they were now recommending the Fusion product for TCP/IP under VMS. I suppose that this might be just a Canadian phenomenon. -- Peter Marshall, CCS, U. of Western Ontario, London, Canada N6A 5B7 (519)661-2151x6032 pm@uwovax.BITNET; pm@uwovax.uwo.cdn; pm@julian.uucp; ...!watmath!julian!peter ----MESSAGE-END---- ----MESSAGE-BEGIN---- [352@louie.udel.EDU] <1987071320255800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: garrett@udel.EDU (Joel Garrett) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong TCP/IP for VAX/VMS Message-ID: <352@louie.udel.EDU> Date: Tue, 14-Jul-87 00:25:58 EDT Article-I.D.: louie.352 Posted: Tue Jul 14 00:25:58 1987 Date-Received: Wed, 15-Jul-87 03:19:55 EDT References: <8707111851.AA27739@topaz.rutgers.edu> Organization: University of Delaware Lines: 18 Summary: Re: Wollongong WIN/TCP v3.0 We have been running WIN/TCP v3.0 for about a week now and have had few problems beyond the initial installation. The new release supports domains and name-servers and fixes a LOT of problems with the old 2.x releases. Their documentation and installation procedures have improved drastically from their earlier releases. There are still a lot of things you can't do without their companion product, Eunice, but the documentation has changed from just copies of man pages to very detailed installation, operation, and programming notes We used to have a lot of system crashes that seemed to be related to the telnet daemon, but since we have upgraded there haven't been any crashes. Hopefully the system won't prove me wrong now, but so far, I'm pretty pleased with the installation. Joel J. Garrett Research Associate University of Delaware Center for Composite Materials arpa address: garrett@udel-ccm.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [353@louie.udel.EDU] <1987071320302200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: garrett@udel.EDU (Joel Garrett) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP for VMS Message-ID: <353@louie.udel.EDU> Date: Tue, 14-Jul-87 00:30:22 EDT Article-I.D.: louie.353 Posted: Tue Jul 14 00:30:22 1987 Date-Received: Wed, 15-Jul-87 03:20:50 EDT References: <870710143745.001@M5.Sdsc.Edu> Organization: University of Delaware Lines: 9 Summary: RE: TCP/IP for VMS Info on sri's product, please? I've been hearing a lot of talk about a VMS implementation of TCP/IP from either Tektronix or SRI. Who can I get in contact with for more information about this product? Joel Garrett University of Delaware Center for Composite Materials arpa address: garrett@udel-ccm.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [354@louie.udel.EDU] <1987071320393700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: garrett@udel.EDU (Joel Garrett) Newsgroups: comp.protocols.tcp-ip Subject: Re: fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin Message-ID: <354@louie.udel.EDU> Date: Tue, 14-Jul-87 00:39:37 EDT Article-I.D.: louie.354 Posted: Tue Jul 14 00:39:37 1987 Date-Received: Wed, 15-Jul-87 03:21:44 EDT Organization: University of Delaware Lines: 18 Summary: subnet routing in win/tcp v3.0 > One of the problems we've been having is the fact that the TWG > software for VMS and UNIX V doesn't support subnetting. Is this fixed > with the new release? According to the docs for the VMS version, yes subnetting is supported now. I wouldn't know about whether they have a new version of their AT&T stuff out, but I'd imagine that they would. On this same line, if any of you who use the sysv wollongong stuff could drop me a line and give me some of your impressions of this product, I would really appreciate it. We have several 3bs that were donated to our department by at&t and they are basically sitting idle now as they can't talk to our other tcp/ip hosts. If I get enough of a response I'll summarize to the net. Thanks, Joel Garrett UofD, CCM arpa: garrett@udel-ccm.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707140550.AA25652@ucbvax.Berkeley.EDU] <1987071321362100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet meltdowns Message-ID: <8707140550.AA25652@ucbvax.Berkeley.EDU> Date: Tue, 14-Jul-87 01:36:21 EDT Article-I.D.: ucbvax.8707140550.AA25652 Posted: Tue Jul 14 01:36:21 1987 Date-Received: Wed, 15-Jul-87 04:05:54 EDT References: <8707081440.AA00679@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 14 Charles, I just had a chance to digest your "meltdown" note. I have seen no response on the net suggesing any cures for your ailments. Nor do I expect any... You describe the "state of the art". Ane they say there is little need for testing of TCP/IP!!! I am extremely curious if the testing planning that is going on at COS for the ISO stack(s) is looking at the kind of grief that you are currently experiencing? ON the other hand don't most of your problems come from multiple interpretations of the "broadcast" address? Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987071321362101> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Mon 13 Jul 87 22:37:08-PDT Date: 14 Jul 1987 01:36:21 EDT Subject: Re: Ethernet meltdowns From: Dan Lynch To: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) cc: tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU In-Reply-To: <8707081440.AA00679@topaz.rutgers.edu> Charles, I just had a chance to digest your "meltdown" note. I have seen no response on the net suggesing any cures for your ailments. Nor do I expect any... You describe the "state of the art". Ane they say there is little need for testing of TCP/IP!!! I am extremely curious if the testing planning that is going on at COS for the ISO stack(s) is looking at the kind of grief that you are currently experiencing? ON the other hand don't most of your problems come from multiple interpretations of the "broadcast" address? Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707140733.AA09249@topaz.rutgers.edu] <1987071323334500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet meltdowns Message-ID: <8707140733.AA09249@topaz.rutgers.edu> Date: Tue, 14-Jul-87 03:33:45 EDT Article-I.D.: topaz.8707140733.AA09249 Posted: Tue Jul 14 03:33:45 1987 Date-Received: Wed, 15-Jul-87 04:19:24 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 36 Well, I know the cure for broadcast storms, and I think plenty of other people do as well. I mostly give it in the message. You simply have to be very careful to do validity checking before forwarding packets or generating ICMP error messages. As far as I can tell, 4.3 is fairly good, so it's mostly a matter of waiting for vendors to catch up to 4.3. All the Unix vendors we deal with have either just released 4.3-based network code or are about to do so. I agree with your implication that validation of TCP/IP implementations would be useful. I understand that it is hard to design a test setup that will make sure a TCP follows all the best performance guidelines. But it is not at all hard to make sure that an IP is designed so it won't contribute to broadcast storms. My first inclination is to say that it will be easy for ISO to avoid this problem. It isn't hard to come up with a set of implementation guidelines that avoid broadcast storms. What really triggered this was the Internet changing its idea of the broadcast address. I mean, it shouldn't have been hard to forsee this problem when 0 was changed to -1. (On the other hand, subnetting probably required enough of a change that things would have broken anyway, so there might have been no way to avoid problems.) However this may be giving too much credit to people. The people who will be implementing ISO are exactly the same people who have ignored the TCP/IP implementation guidelines. If people can do IP's that don't respond to ICMP echo, presumably they can find ways to mess up ISO as well. It seems to me that ISO's equivalent of the broadcast address change is going to be the incredibly complex address structure. It seems likely that few people will implement every possible address format. (Indeed probably they couldn't if they wanted to.) My intuition says that when different implementations implement different sets of address formats, there are bound to be some interesting interactions somewhere. And with the worldwide PTT network built into the addressing structure, I'll bet at some point we'll manage to see some sort of storm that involves several continentne ----MESSAGE-END---- ----MESSAGE-BEGIN---- [WANCHO.12318234098.BABYL@SIMTEL20.ARPA] <1987071400000000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: WANCHO@SIMTEL20.ARPA ("Frank J. Wancho") Newsgroups: comp.protocols.tcp-ip Subject: Wollongong TCP/IP for VAX/VMS Message-ID: Date: Tue, 14-Jul-87 04:00:00 EDT Article-I.D.: SIMTEL20.WANCHO.12318234098.BABYL Posted: Tue Jul 14 04:00:00 1987 Date-Received: Wed, 15-Jul-87 04:22:12 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 52 I have a somewhat different viewpoint and solution to the ongoing commentary concerning the Wollongong implementations of TCP/IP and supporting software for various operating systems. First, let me point out that I get a different set of complaints than Mark gets. As the postmaster for this DEC-20 site, which is the origin/relay point for several large mailing lists, I get a certain set of complaints from the postmasters at BITNET sites who are having problems with our headers. What has made the difference is that in most cases, I have been able to deal directly with the authors of the software in question to resolve the problems in interpretation of the RFCs using our real-world (Internet) messages. What is different with dealing with users of Wollongong software is that they are in the position of having to report problems into a corporate environment which has never had to interface their software into a large heterogenous network such as ours. In house, they test their software against other implementations of their own software, and it's kinda hard to duplicate a problem, much less be aware that a problem exists in that situation. Recall the early days surrounding the rapid implementation and heterogeneous testing of various TCP/IP implementations just a few short years ago and you'll understand my point. The solution is obvious: The Wollongong Group should have a host on the Internet so that they can find and fix problems before their customers do, among other things. This is not without precedent. Not too long ago, when the predominant operating system on the net was TOPS20, DEC had, and still has one or more of their own TOPS20 hosts on the net, testing their TCP/IP implementations (as was BBN testing their versions). I'm sure there are other examples, and I would suppose that there were and still are other reasons for DEC to be on the net. In a recent analysis I made of the various operating systems listed in the NIC HOSTS.TXT file, by far the most predominant was Unix, in various flavors on various machines. Those hosts are mostly running the 4.xbsd version, with Berkeley certainly represented directly on the net. The second was VMS systems, presumeably with a majority of them running Wollongong software. Well, it appears such a Wollongong host does exist, according to the NIC HOSTS.TXT file and the WHOIS database: TWG.ARPA, 26.5.0.73. However, it appears to be non-operational or a reserved designation. At least I have not been able to get a response from that host, yet. I firmly believe that the sooner they get on the net as an operational host, we will see a significant and radical improvement in the situation. Anything that can be done to speed up their connection would be of great benefit to all of us. Note carefully: I'm not necessarily advocating that only by virtue of having a TCP/IP software package should every developer have a host on the Internet. Such developers should at least adopt a host for in resident beta tests. I suspect that every major developer already has such a connection, except Wollongong... --Frank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4491@videovax.Tek.COM] <1987071406305700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: stever@videovax.Tek.COM (Steven E. Rice, P.E.) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP for VMS Message-ID: <4491@videovax.Tek.COM> Date: Tue, 14-Jul-87 10:30:57 EDT Article-I.D.: videovax.4491 Posted: Tue Jul 14 10:30:57 1987 Date-Received: Fri, 17-Jul-87 04:57:29 EDT References: <870710143745.001@M5.Sdsc.Edu> <353@louie.udel.EDU> Reply-To: stever@videovax.Tek.COM (Steven E. Rice, P.E.) Organization: Tektronix Television Systems, Beaverton, Oregon Lines: 16 Summary: Call your local Tektronix field office. In article <353@louie.udel.EDU>, Joel Garrett (garrett@udel.EDU) writes: > I've been hearing a lot of talk about a VMS implementation of TCP/IP > from either Tektronix or SRI. Who can I get in contact with for more > information about this product? Some time back, I was asked this question by mail. After a bit of calling around inside Tektronix, I wound up talking to The Right Person. The answer (for the Tektronix software) is, "Call your local Tektronix field office." (I don't know the answer for SRI.) Steve Rice ----------------------------------------------------------------------------- new: stever@videovax.tv.Tek.com old: {decvax | hplabs | ihnp4 | uw-beaver | cae780}!tektronix!videovax!stever ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707141453.AA15834@monk.proteon.com] <1987071406535200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jas@MONK.PROTEON.COM (John A. Shriver) Newsgroups: comp.protocols.tcp-ip Subject: Routers and Internet Protocol #77 Message-ID: <8707141453.AA15834@monk.proteon.com> Date: Tue, 14-Jul-87 10:53:52 EDT Article-I.D.: monk.8707141453.AA15834 Posted: Tue Jul 14 10:53:52 1987 Date-Received: Thu, 16-Jul-87 06:29:10 EDT References: <8707131311.a011655@Huey.UDEL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 18 I've never seen any specification that requires IP routers to examine the Protocol field in an IP datagram being forwarded. I would argue that it is improper for a IP router to do so. This prevents consenting users of the internet to use an experimental Protocol across the Internet since some "router czar" has forbidden this protocol. My idea of IP, and IP routers, is that it should be completely blind to what protocol is in use above it (with the exception of ICMP). This is the spirit of layering. Another reason not to do this is that it's just *another* field to have to check in the main forwarding loop of a router. If everyone solves all of the Internet's "control" problems in routers "with just one little check" here or there, we'll never get the sort of performance out of routers that the Internet community seems to want. We have to keep forwarding packets as *simple* as possible, or we'll have 68030 routers running at 50 (exaggeration) packets/second. (Obviously, these are my opinions, not Proteon's...) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707141611.AA17326@topaz.rutgers.edu] <1987071408114100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin Message-ID: <8707141611.AA17326@topaz.rutgers.edu> Date: Tue, 14-Jul-87 12:11:41 EDT Article-I.D.: topaz.8707141611.AA17326 Posted: Tue Jul 14 12:11:41 1987 Date-Received: Thu, 16-Jul-87 06:31:14 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 2 The Wollongong VMS code we are running now, which is not the 4.3 stuff, supports subnets and setting the broadcast address. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987071409030000> Received: from bluto.scc.com by SRI-NIC.ARPA with TCP; Tue 14 Jul 87 11:15:35-PDT Date: 14 Jul 87 14:03:00 EST From: "GBURG::ENGER" Subject: WOLLONGONG TCP/IP for VMS To: "tcp-ip" cc: enger Reply-To: "GBURG::ENGER" A number of individuals have criticized Wollongong for having many bugs and shortcomings in their TCP/IP for VMS product. Other individuals provide testimonials about how Wollongong provided help, once informed of the problem. I found out that Wollongong has been trying to get connected to the Internet for some time. They wish to improve their service by being able to provide help across the net (as SUN Microsystems, and other responsible vendors do). It has been said that a number of government sites are in need of help with their Wollongong TCP/IP software. Would it not make sense to contact the network administrators and request some expediting of Wollongong's Internet connection? Bob Enger ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707141444.a027403@Huey.UDEL.EDU] <1987071410441600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Routers and Internet Protocol #77 Message-ID: <8707141444.a027403@Huey.UDEL.EDU> Date: Tue, 14-Jul-87 14:44:16 EDT Article-I.D.: Huey.8707141444.a027403 Posted: Tue Jul 14 14:44:16 1987 Date-Received: Thu, 16-Jul-87 06:52:24 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 John, My remarks were confined strictly to the local-use issue and only when the firewall is necessary. It turns out that the fuzzballs use IP protocol 63 (decimal) for routing purposes, so they have to check that field anyway. Should it be advisable, I have no problem with this overhead in the general case. It is surely no more intrusive than the address checking suggested for generic IP gateways on this list and in recent RFCs. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707141838.AA05876@ucbvax.Berkeley.EDU] <1987071411030000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: enger%gburg.DECnet@BLUTO.SCC.COM ("GBURG::ENGER") Newsgroups: comp.protocols.tcp-ip Subject: WOLLONGONG TCP/IP for VMS Message-ID: <8707141838.AA05876@ucbvax.Berkeley.EDU> Date: Tue, 14-Jul-87 15:03:00 EDT Article-I.D.: ucbvax.8707141838.AA05876 Posted: Tue Jul 14 15:03:00 1987 Date-Received: Thu, 16-Jul-87 06:49:33 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "GBURG::ENGER" Distribution: world Organization: The ARPA Internet Lines: 15 A number of individuals have criticized Wollongong for having many bugs and shortcomings in their TCP/IP for VMS product. Other individuals provide testimonials about how Wollongong provided help, once informed of the problem. I found out that Wollongong has been trying to get connected to the Internet for some time. They wish to improve their service by being able to provide help across the net (as SUN Microsystems, and other responsible vendors do). It has been said that a number of government sites are in need of help with their Wollongong TCP/IP software. Would it not make sense to contact the network administrators and request some expediting of Wollongong's Internet connection? Bob Enger ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [13322@topaz.rutgers.edu] <1987071411245200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@topaz.rutgers.edu (Ron Natalie) Newsgroups: comp.protocols.tcp-ip,comp.unix.wizards Subject: Re: Problems with internetwork routing in 4.2bsd Message-ID: <13322@topaz.rutgers.edu> Date: Tue, 14-Jul-87 15:24:52 EDT Article-I.D.: topaz.13322 Posted: Tue Jul 14 15:24:52 1987 Date-Received: Fri, 17-Jul-87 01:14:37 EDT References: <97@rdlvax.UUCP> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 18 Keywords: 4.2bsd tcp/ip routing gateway It's not a bug. You must make routing table entries for nets other than net 10. You do this by using the "route" command (in /etc or /usr/etc depending on where you got your software from). The easiest thing to do is to set a default route to point to one of the ARPANET-MILNET gateways, they will send you back an ICMP redirect to set the route to the correct gateway if they are not it. The gateways to use for this are available from SRI-NIC.ARPA in the file ARPA-MAILBRIDGE-HOMINGS.TXT Since rdl appears to be on IMP22, use the gateways MILNET-GW.ISI.EDU SRI-MILNET-GW.ARPA 10.2.0.22 10.4.0.51 You set this up by saying route add 0 10.2.0.22 1 -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4819@columbia.UUCP] <1987071416095400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dupuy@amsterdam.columbia.edu (Alexander Dupuy) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet meltdowns Message-ID: <4819@columbia.UUCP> Date: Tue, 14-Jul-87 20:09:54 EDT Article-I.D.: columbia.4819 Posted: Tue Jul 14 20:09:54 1987 Date-Received: Fri, 17-Jul-87 01:02:09 EDT References: <8707140733.AA09249@topaz.rutgers.edu> Sender: nobody@columbia.UUCP Reply-To: dupuy@amsterdam.columbia.edu (Alexander Dupuy) Followup-To: comp.protocols.tcp-ip Distribution: world Organization: Columbia University Computer Science Dept. Lines: 37 We once had a similar problem with a broadcast storm started by a diskless Sun-3 trying to boot without a server. Although you are correct when you say that the boot broadcast address is hardwired in the Sun-3 PROMs, there is a workaround, at least if you aren't on a class A or B network with subnets (which is the case here at Columbia, and probably at Rutgers, *sigh*). When a Sun 3 (diskless or otherwise) tries to boot, it looks in the EEPROM on the CPU board for a default boot device. If none is found, it takes the first bootable device it finds, in the order it looks for them: disk, tape, ethernet. A device spec looks something like this: ty(#,#,#), where ty is the board type and the three numbers are the controller #, unit #, and partition #. The defaults for these are all 0. In the case of an ethernet device, the unit # is actually the last component of an internet host number, with 0 signifying the broadcast address (which is all ones, not zeros). When a fresh-from-the-factory diskless Sun-3 boots, the PROM, not finding anything better than an ethernet device to boot from, starts a TFTP boot from the device ie(0,0,0) or le(0,0,0), which can result in network meltdown if no server responds (and sometimes even when one does). However, if the server is at address 128.59.0.110 (say) you can set the default boot device to be ie(0,110,0), and the only broadcasts which the booting sun will generate will be the initial RARP and ARP requests that can be answered by any machine, not just the server. The catch in this is that if the server is at address 128.59.16.110, the host part of the address (by the pre-subnetting rules, anyhow) is the number 4206, and the largest possible unit number is 255. One hopes that Sun will someday support subnets in the boot PROM, so that this is no longer a problem; in the meantime, one might consider using subnet 0 (if that's legal) for Sun diskless clients and servers. @alex --- arpanet: dupuy@columbia.edu uucp: ...!seismo!columbia!dupuy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [122@casetek.casetek.UUCP] <1987071416140000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: pml@casetek.casetek.UUCP (Pat Lashley) Newsgroups: comp.protocols.tcp-ip Subject: PD TCP/IP requests Message-ID: <122@casetek.casetek.UUCP> Date: Tue, 14-Jul-87 20:14:00 EDT Article-I.D.: casetek.122 Posted: Tue Jul 14 20:14:00 1987 Date-Received: Fri, 17-Jul-87 01:19:43 EDT Organization: CASE Technology Inc., Mtn View, CA Lines: 22 In the past couple of weeks, I have seen several requests for Public Domain TCP/IP implementations; and no responses (presumably e-mailed to requestor ?). This has led me to wonder if there is any such beast. Anyone out there with information about ANY public domain or freely redistributable TCP/IP implementation for ANY hardware/operating system configuration, please e-mail me what information you have, and I will post a summary (or statement of lack of response... :-). Thanks, -Pat P.S. This is not _just_ idle curiosity. I think that the only way that I can convince our managment to install TCP/IP on our VMS VAXen or PCs is to find a way to reduce the cost per host to something that I could afford out of my own pocket. -- Internet: casetek!patl@sun.com PM Lashley uucp: ...sun!casetek!patl CASE Technology, Inc. arpa: casetek@crvax.sri.com Mountain View, CA 94087 >> Anyone can have the facts; having an opinion is an art. << ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987071416300700> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Tue 14 Jul 87 18:55:10-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA14407; Tue, 14 Jul 87 18:48:35 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Jul 87 16:30:07 GMT From: ihnp4!alberta!auvax!louis@ucbvax.Berkeley.EDU (Louis Schmittroth) Organization: Athabasca U., Alberta, Canada Subject: PC UNIX wide area networking Message-Id: <272@auvax.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa We are starting to plan for wide-area networking of PCs with our central UNIX machines. The PCs will be spread out across the Province of Alberta with dial-in access and/or Datapac (X.25) access to the central machines. At the central site we now have Berkeley UNIX on VAXEN and SUNs connected by Ethernet, but we will also be considering 3B2s. The PCs will be used by students to run CAI courseware on MS/DOS but with administration and tutorial services from the central UNIX systems. Some CAI will also be delivered directly from the UNIX systems. We will be starting with 1200 and 2400 baud lines. The PCs will be standalone workstations with only a modicum of computer skills assumed for a typical student. What experience has anyone had using TCP-IP on PCs for wide-area networking? Where can we get information on SLIP? Any other suggestions? Please e-mail me and if there is enough response I will summarize. -- Louis Schmittroth My employer has no opinions. Computer Science Athabasca University ...{ubc-vision, ihnp4}!alberta!auvax!louis ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707150135.AA01091@topaz.rutgers.edu] <1987071417354700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet Protocol #77 Message-ID: <8707150135.AA01091@topaz.rutgers.edu> Date: Tue, 14-Jul-87 21:35:47 EDT Article-I.D.: topaz.8707150135.AA01091 Posted: Tue Jul 14 21:35:47 1987 Date-Received: Fri, 17-Jul-87 01:37:55 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 14 You indicate that there is a maximum acceptable delay for NFS. That's not quite the case. NFS does not adjust its timeouts and retransmission times dynamically on a per-connection basis as TCP does. However you can set the constants as options in the mount. It should be possible to use NFS over connections with a long delay, as long as the system administrator is able to choose reasonable values. (A connection where values changed a lot would be a problem, of course.) This is obviously not the best way to design a protocol. On the other hand, they needed higher speed than is typical with TCP. The evidence from this mailing list is that the commonly-used techniques for choosing retransmission times and the like do not always lead to the best results. So I can understand a pragmatic decision to optimize for local Ethernets and let the administrator tune it for other connections. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707150224.a004192@Huey.UDEL.EDU] <1987071422243200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet Protocol #77 Message-ID: <8707150224.a004192@Huey.UDEL.EDU> Date: Wed, 15-Jul-87 02:24:32 EDT Article-I.D.: Huey.8707150224.a004192 Posted: Wed Jul 15 02:24:32 1987 Date-Received: Fri, 17-Jul-87 04:08:14 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Charles, Well, we might both be on a spinnaker run. In fact, pals of mine have mounted NFS over some interesting creeks in the NSF swamps, so what are we tacking about? I think the pertinent points have been butted and rebutted and thus would like to rest the case. We still need a type-of-service architecture independent of addressing and protocol specifications. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1319@brahma.cs.hw.ac.uk] <1987071501355100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: iad@cs.hw.ac.uk (Iain A Donaldson) Newsgroups: comp.protocols.tcp-ip,comp.os.vms,comp.sys.dec Subject: TEKTCP request Message-ID: <1319@brahma.cs.hw.ac.uk> Date: Wed, 15-Jul-87 05:35:51 EDT Article-I.D.: brahma.1319 Posted: Wed Jul 15 05:35:51 1987 Date-Received: Sat, 18-Jul-87 07:26:26 EDT Organization: Computer Science, Heriot-Watt U., Scotland Lines: 18 Keywords: tcp/ip ip/tcp protocol Does your site use the public domain tcp/ip software implemented for VMS which originated with Tektronix (or the CMU enhanced version) ?. If so I would be pleased to hear your comments as we are in the process of requesting a user licence from Tek. Also, if your site subscribes to the TEKTCP mailing list, perhaps you could forward mail items to us in the interval while we join the mailing list. If you can help with the mailing list, please e-mail first and I will select a feed with the shortest path. Some day we will give the DEQNA Ethernet board inside our microVAX some work to do ! ------------- -Iain Donaldson JANET: iad@uk.ac.hw.cs Heriot-Watt University ARPA: iad@cs.hw.ac.uk Dept of C.S. UUCP: ..!ukc!cs.hw.ac.uk!iad Edinburgh, Scotland. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707151356.AA01298@jvnca.csc.org] <1987071505560600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: heker@JVNCA.CSC.ORG (Sergio Heker) Newsgroups: comp.protocols.tcp-ip Subject: Re: fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin Message-ID: <8707151356.AA01298@jvnca.csc.org> Date: Wed, 15-Jul-87 09:56:06 EDT Article-I.D.: jvnca.8707151356.AA01298 Posted: Wed Jul 15 09:56:06 1987 Date-Received: Fri, 17-Jul-87 06:01:40 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 17 Christopher, We have been using TWG on our VMS VAXs in a subnetted environment without problems major problems for almost two years. In fact, for about 6 months, we used a VAX8600 running VMS4.2 and TWG to drive two ethernets and 4 T1 lines, until we switched to ULTRIX, ( I was not in favor of using a VAX/VMS as an ip gateway but at that time we had no choice ). -- Sergio ----------------------------------------------------------------------------- Sergio Heker tel: (609) 520-2000 Internet: "heker@jvnca.csc.org" Bitnet: "heker@jvnc" JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER, JVNCnet Network Manager ----------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707151440.AA25042@nic.nyser.net] <1987071506403600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: weltyc@NIC.NYSER.NET (Christopher A. Welty) Newsgroups: comp.protocols.tcp-ip Subject: fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin Message-ID: <8707151440.AA25042@nic.nyser.net> Date: Wed, 15-Jul-87 10:40:36 EDT Article-I.D.: nic.8707151440.AA25042 Posted: Wed Jul 15 10:40:36 1987 Date-Received: Fri, 17-Jul-87 06:02:16 EDT References: <8707151356.AA01298@jvnca.csc.org> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Thanks. I have forwarded your message to our VMS system manager, who had claimed that subnetting in VMS was impossible. However I still have the problem of doing subnetting with the TWG software for SYS V on 3B2's....any clues? --- Christopher Welty - Asst. Director, RPI CS Labs weltyc@cs.rpi.edu ...!seismo!rpics!weltyc ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987071507294500> Received: from STAR.STANFORD.EDU by SRI-NIC.ARPA with TCP; Wed 15 Jul 87 14:31:00-PDT Date: Wed 15 Jul 87 14:29:45-PDT From: JERRY@STAR.STANFORD.EDU To: tcp-ip@SRI-NIC.ARPA Subject: RE: Wollongong TCP/IP for VAX/VMS This is Dave Crocker, not Jerry Scott. I recently joined The Wollongong Group as Vice President, Software Engineering. We will soon be a host on MilNet, so I have not established an interim mailbox elsewhere. Please direct any short-term mail to me via Jerry at this address. The recent flurry of messages about Wollongong requires a formal response. As you are aware, The Wollongong Group has been selling TCP/IP-based products for some years. While we have been successful in doing so, we have been less successful in maintaining an unblemished reputation within the Internet community. Recently, we began taking actions to improve user perceptions. From a technical standpoint, the most significant of these actions involves upgrades to our VAX/VMS product called WIN/TCP, especially converting to the use of 4.3BSD as a code base for the TCP/IP implementation. By doing so, many long-standing problems were solved and performance has been substantially improved. On reviewing the messages that were sent to this distribution list, it appears that the basis for two of the three explicitly critical notes was a) system administration errors, and b) the use of very old software. At the present time, the new release (3.0) does not have any major TCP/IP bugs known to us, nor does it crash the operating system. The immediately previous version (2.3) has not had any bugs that crash VAXes for a time longer that any Wollongong personnel can remember. It is our policy to work closely with all users of our products to satisfy their needs. Mark Crispin's July 6 email message, while it contained no specific details, has been partially addressed in a public reply citing cockpit error, rather than faulty software. The message was sent by a system administrator whose contact with Mark triggered Mark's note. The system administrator cockpit error we identified does not involve any software bugs, but it does result in setting the hosts's own name to a constant ("Unknown"). To eliminate this confusion, we are changing the software to simply use the text version of the IP address, whenever a similar administrator error is made. As part of a test against one of the systems running Mark's TCP, we did encounter a client SMTP bug. WIN/TCP 3.1, which will be released shortly, fixes it. It was only discovered because of high delay in the Arpanet, thereby causing an extraordinary timeout. In addition to providing technically competent software, Wollongong must provide support for our products. This is critical. Although admittedly flawed in the past, this, too, is being significantly improved, as the recent TCP/IP activity cited above demonstrates. "Support" is a separate product and has to be purchased. There have been some customers who purchased the TCP product but did not, for whatever reason, purchase support. They then passed on the product to the real end-users and claimed, falsely, that we would not provide support. The cited case of our software crashing a VAX cluster appears to be an example of this. Although we subsequently established direct contact with a portion of the actual end-users affected in this way, we were unfortunately unable to find the remainder. The suggestion about our connecting the the Internet is extremely well- taken. Part of the reason I was asked to join Wollongong was to bring some Internet experience in-house. The wheels were already in motion, I discovered, to get a connection when I came on-board. We were supposed to be on MilNet about 4 months ago, and are in the final stages of debugging the telecom link. Lastly, with regard to our AT&T version of TCP/IP...it should be noted that we developed this product at the specification of AT&T and we are not free to add features on our own (AT&T markets the product; we do not). Hence, please ask them to suggest to us any changes that you deem appropriate. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [371@root44.co.uk] <1987071507414000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kelly@root.co.uk (Kelly Dunlop) Newsgroups: comp.sources.wanted,comp.protocols.tcp-ip,comp.sys.ibm.pc Subject: PCP/IP package for IBM PCs Message-ID: <371@root44.co.uk> Date: Wed, 15-Jul-87 11:41:40 EDT Article-I.D.: root44.371 Posted: Wed Jul 15 11:41:40 1987 Date-Received: Sat, 18-Jul-87 07:28:59 EDT Organization: Root Computers Ltd., London, England Lines: 18 Keywords: PCP/IP IBM PC TCP/IP I have a vague recollection of a mention on the net of a TCP/IP package for IBM PCs called PCP/IP. I think it comes from MIT and is possibly public domain. Any information about how I can get hold of this, or information from anyone who has used this will be gratefully received. Please mail replies and if there is sufficient interest I will post a summary to the net. Thanks in advance, Kelly ===== Kelly Dunlop, Root Technical Systems, 3 Hayne Street, London, EC1A 9HH. Phone: +44 1 606 7799 Fax: +44 1 726 8158 Telex: 885995 ROOT G ----MESSAGE-END---- ----MESSAGE-BEGIN---- [626@ucdavis.UUCP] <1987071508360100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ccruss@ucdavis.UUCP (Russ Hobby) Newsgroups: comp.protocols.tcp-ip,comp.sys.ibm.pc Subject: Re: PC UNIX wide area networking Message-ID: <626@ucdavis.UUCP> Date: Wed, 15-Jul-87 12:36:01 EDT Article-I.D.: ucdavis.626 Posted: Wed Jul 15 12:36:01 1987 Date-Received: Fri, 17-Jul-87 07:25:18 EDT References: <272@auvax.UUCP> Reply-To: ccruss@ucdavis.edu.UUCP (Russ Hobby) Organization: University of California, Davis Lines: 39 SLIP connections seem to be a hot topic this summer so I thought I would post a description of a summer project we have at UC Davis. SLIP is a cheap and easy method to get a computer connected to a network and is particularly good for microcomputers since additional hardware is not required. SLIP is lacking in a few areas however. Throughput on slow serial lines (1200/2400 baud) can be quite bad because of the minimum packet size (all those header fields). Also there is no standard method of establishing a SLIP connection for temporary network hookups. Our project addresses the first problem by using an abbreviated IP packet on the SLIP line and have the SLIP gateway build legal packets before sending them onto the network. Likewise, incoming packets will be reduced before sending them down the SLIP line. Many of the fields in the IP packet header are either static or unnecessary, IF you consider the host at the end of the SLIP is a leaf on the network and will not be routing. Static fields are established at login. Our current plans are for four or eight byte headers, depending if the to/from address has changed from the last packet. To solve the second problem, we are creating a standard logon procedure that will make the connection and set the static fields. We plan to support connections via campus serial connection (up to 19.2k) as well as via dialup modems (300/1200/2400 baud, although I can not imagine it working well at 300!). We doing the development with an IBM PC clone on one end and a VAX with 4.3bsd on the other. We have started with some of the MIT PC/IP derivations on the PC side, so that if the project works out, it will usable by others using the same software. If there is interest, I will post information on how well it works. Russell Hobby Data Communications Manager U. C. Davis Computing Services BITNET: RDHOBBY@UCDAVIS Davis Ca 95616 UUCP: ...!ucbvax!ucdavis!rdhobby (916) 752-0236 INTERNET: rdhobby@ucdavis.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [64200001@uiucuxe] <1987071511570000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: heisterb@uiucuxe.cso.uiuc.edu Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong TCP/IP for VAX/VMS Message-ID: <64200001@uiucuxe> Date: Wed, 15-Jul-87 15:57:00 EDT Article-I.D.: uiucuxe.64200001 Posted: Wed Jul 15 15:57:00 1987 Date-Received: Sat, 18-Jul-87 18:32:05 EDT References: <8@<12316245218> Lines: 14 Nf-ID: #R:<12316245218:8:uiucuxe:64200001:000:577 Nf-From: uiucuxe.cso.uiuc.edu!heisterb Jul 15 14:57:00 1987 /* Written 1:51 pm Jul 9, 1987 by haynes@ucscc.UCSC.EDU.ucsc.edu in uiucuxe:comp.protocols.tcp-ip */ In article <8707081702.AA03732@topaz.rutgers.edu> ron@TOPAZ.RUTGERS.EDU (Ron Natalie) writes: >Would you like to propose an alternative. The other major I've heard there is a new package from SRI, and there is also a package from Tektronix that is something like free for big VAXen and not free for Microvaxen.Sorry, I don't have any further info. Jim haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ..ucbvax!ucscc!haynes /* End of text from uiucuxe:comp.protocols.tcp-ip */ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707152153.AA04238@ucbvax.Berkeley.EDU] <1987071513294500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JERRY@STAR.STANFORD.EDU Newsgroups: comp.protocols.tcp-ip Subject: RE: Wollongong TCP/IP for VAX/VMS Message-ID: <8707152153.AA04238@ucbvax.Berkeley.EDU> Date: Wed, 15-Jul-87 17:29:45 EDT Article-I.D.: ucbvax.8707152153.AA04238 Posted: Wed Jul 15 17:29:45 1987 Date-Received: Sat, 18-Jul-87 01:23:34 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 72 This is Dave Crocker, not Jerry Scott. I recently joined The Wollongong Group as Vice President, Software Engineering. We will soon be a host on MilNet, so I have not established an interim mailbox elsewhere. Please direct any short-term mail to me via Jerry at this address. The recent flurry of messages about Wollongong requires a formal response. As you are aware, The Wollongong Group has been selling TCP/IP-based products for some years. While we have been successful in doing so, we have been less successful in maintaining an unblemished reputation within the Internet community. Recently, we began taking actions to improve user perceptions. From a technical standpoint, the most significant of these actions involves upgrades to our VAX/VMS product called WIN/TCP, especially converting to the use of 4.3BSD as a code base for the TCP/IP implementation. By doing so, many long-standing problems were solved and performance has been substantially improved. On reviewing the messages that were sent to this distribution list, it appears that the basis for two of the three explicitly critical notes was a) system administration errors, and b) the use of very old software. At the present time, the new release (3.0) does not have any major TCP/IP bugs known to us, nor does it crash the operating system. The immediately previous version (2.3) has not had any bugs that crash VAXes for a time longer that any Wollongong personnel can remember. It is our policy to work closely with all users of our products to satisfy their needs. Mark Crispin's July 6 email message, while it contained no specific details, has been partially addressed in a public reply citing cockpit error, rather than faulty software. The message was sent by a system administrator whose contact with Mark triggered Mark's note. The system administrator cockpit error we identified does not involve any software bugs, but it does result in setting the hosts's own name to a constant ("Unknown"). To eliminate this confusion, we are changing the software to simply use the text version of the IP address, whenever a similar administrator error is made. As part of a test against one of the systems running Mark's TCP, we did encounter a client SMTP bug. WIN/TCP 3.1, which will be released shortly, fixes it. It was only discovered because of high delay in the Arpanet, thereby causing an extraordinary timeout. In addition to providing technically competent software, Wollongong must provide support for our products. This is critical. Although admittedly flawed in the past, this, too, is being significantly improved, as the recent TCP/IP activity cited above demonstrates. "Support" is a separate product and has to be purchased. There have been some customers who purchased the TCP product but did not, for whatever reason, purchase support. They then passed on the product to the real end-users and claimed, falsely, that we would not provide support. The cited case of our software crashing a VAX cluster appears to be an example of this. Although we subsequently established direct contact with a portion of the actual end-users affected in this way, we were unfortunately unable to find the remainder. The suggestion about our connecting the the Internet is extremely well- taken. Part of the reason I was asked to join Wollongong was to bring some Internet experience in-house. The wheels were already in motion, I discovered, to get a connection when I came on-board. We were supposed to be on MilNet about 4 months ago, and are in the final stages of debugging the telecom link. Lastly, with regard to our AT&T version of TCP/IP...it should be noted that we developed this product at the specification of AT&T and we are not free to add features on our own (AT&T markets the product; we do not). Hence, please ask them to suggest to us any changes that you deem appropriate. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707152133.AA21437@jvnca.csc.org] <1987071513335600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: heker@JVNCA.CSC.ORG (Sergio Heker) Newsgroups: comp.protocols.tcp-ip Subject: Re: fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin Message-ID: <8707152133.AA21437@jvnca.csc.org> Date: Wed, 15-Jul-87 17:33:56 EDT Article-I.D.: jvnca.8707152133.AA21437 Posted: Wed Jul 15 17:33:56 1987 Date-Received: Sat, 18-Jul-87 06:34:26 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Sorry, we don't have any system V. -- Sergio ----------------------------------------------------------------------------- Sergio Heker tel: (609) 520-2000 Internet: "heker@jvnca.csc.org" Bitnet: "heker@jvnc" JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER, JVNCnet Network Manager ----------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707152300.AA06270@faline.bellcore.com] <1987071515001100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@FALINE.BELLCORE.COM (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet meltdowns Message-ID: <8707152300.AA06270@faline.bellcore.com> Date: Wed, 15-Jul-87 19:00:11 EDT Article-I.D.: faline.8707152300.AA06270 Posted: Wed Jul 15 19:00:11 1987 Date-Received: Sat, 18-Jul-87 01:34:49 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 As I've said before, I think the notion of an "IP broadcast address" is utterly meaningless. Broadcasting is a notion limited solely to certain subnets; the Internet itself has no notion of broadcasting. (I'll ignore the experimental multicast work for the time being). Therefore it is completely bogus to look at anything other than the SUBNET destination address when determining whether an incoming packet is a broadcast or not. Getting an Ethernet packet with all 1's in the destination field is both necessary and sufficient to label it as a broadcast packet that must not be forwarded or answered with an ICMP message even if the type field says it's an IP datagram. The IP address field should be completely ignored; therefore it is irrelevant to even specify a "standard" IP broadcast address. It is arguable whether broadcast packets should even use UDP/IP at all, although I suppose it is handy because of the port multiplexing and checksumming provided by UDP. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987071516450000> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Wed 15 Jul 87 18:40:55-PDT Received: from CUNYVMS1.BITNET by wiscvm.wisc.edu ; Wed, 15 Jul 87 20:40:50 CDT Date: Wed, 15 Jul 87 21:45 EST From: Subject: tcp-ip for VAX/VMS To: tcp-ip@sri-nic.arpa X-Original-To: tcp-ip@sri-nic.arpa I am looking for a bare-bone Public Domian TCP/IP for the VAX/VMS which could do the following for our Symbolics, and RT's 1] Receive mail and files from the outside world as mail and provide an equivalent of cftp from VAX to the RT's and send mail to Symbolics and RT's. 2] Let the Lisp Machine transfer files via the VAX to the RT's and other non VAX machines. 3] internal mail between the VAX's and non-VAX machines. At present we have DECNET on the VAX and frankly as far as the the Symbolics DNA for Decnet is concerned I am not too happy. Plus it is not feasible for RT to send its code and files to LispM easily. We do have tcp/ip for RT's and want the VAX 11/780 to be a go-between the other machines so that outside mail could be routed to the other machines. Pointers to any Public Domian tcp/ip and who to get them would be greatly appreciated......................................... Thanks in advance Anil Khullar {Ph.D. Prog in Psychology C.U.N.Y. Grad. Center. 33 W 42 St. Box 295, New York NY 10036 } BITNET:virgo@cunyvms1 INTERNET:virgo%cunyvms1.BITNET@wiscvm.edu UUCP: ..columbia!cunygs!virgo {Tentative} UUCP: virgo@cunygs.UUCP ========================================================================== [DISCLAIMER: They say after Boston there is heaven, I agree; I say after LispM there is nirvana, they don't. This and other opinion of mine are held dearly by me, My employers and the institution I represent do not necessarily hold that view. I am sole culprit of such fantasies. No living being is responsible, however unsolicited support is welcome] ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707160150.AA08806@ucbvax.Berkeley.EDU] <1987071518450000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: VIRGO@CUNYVMS1.BITNET Newsgroups: comp.protocols.tcp-ip Subject: tcp-ip for VAX/VMS Message-ID: <8707160150.AA08806@ucbvax.Berkeley.EDU> Date: Wed, 15-Jul-87 22:45:00 EDT Article-I.D.: ucbvax.8707160150.AA08806 Posted: Wed Jul 15 22:45:00 1987 Date-Received: Sat, 18-Jul-87 02:51:12 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 43 I am looking for a bare-bone Public Domian TCP/IP for the VAX/VMS which could do the following for our Symbolics, and RT's 1] Receive mail and files from the outside world as mail and provide an equivalent of cftp from VAX to the RT's and send mail to Symbolics and RT's. 2] Let the Lisp Machine transfer files via the VAX to the RT's and other non VAX machines. 3] internal mail between the VAX's and non-VAX machines. At present we have DECNET on the VAX and frankly as far as the the Symbolics DNA for Decnet is concerned I am not too happy. Plus it is not feasible for RT to send its code and files to LispM easily. We do have tcp/ip for RT's and want the VAX 11/780 to be a go-between the other machines so that outside mail could be routed to the other machines. Pointers to any Public Domian tcp/ip and who to get them would be greatly appreciated......................................... Thanks in advance Anil Khullar {Ph.D. Prog in Psychology C.U.N.Y. Grad. Center. 33 W 42 St. Box 295, New York NY 10036 } BITNET:virgo@cunyvms1 INTERNET:virgo%cunyvms1.BITNET@wiscvm.edu UUCP: ..columbia!cunygs!virgo {Tentative} UUCP: virgo@cunygs.UUCP ========================================================================== [DISCLAIMER: They say after Boston there is heaven, I agree; I say after LispM there is nirvana, they don't. This and other opinion of mine are held dearly by me, My employers and the institution I represent do not necessarily hold that view. I am sole culprit of such fantasies. No living being is responsible, however unsolicited support is welcome] ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707160703.AA06365@utah-ced.ARPA] <1987071523031200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cetron%ced@CS.UTAH.EDU (Ed Cetron) Newsgroups: comp.protocols.tcp-ip Subject: twg, and nic not knowing its domain name.... Message-ID: <8707160703.AA06365@utah-ced.ARPA> Date: Thu, 16-Jul-87 03:03:12 EDT Article-I.D.: utah-ced.8707160703.AA06365 Posted: Thu Jul 16 03:03:12 1987 Date-Received: Sat, 18-Jul-87 05:44:45 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 69 I tried to send an article into the tcp-ip mailing list (twice) and I keep getting the mail back....(with some headers removed) here is the letter and returned mail: From MAILER-DAEMON@cs.utah.edu Thu Jul 16 00:58:47 1987 Date: Thu, 16 Jul 87 01:02:47 MDT From: MAILER-DAEMON@cs.utah.edu (Mail Delivery Subsystem) Subject: Returned mail: Host unknown To: ----- Transcript of session follows ----- 550 ... Host unknown ----- Unsent message follows ----- Date: Thu, 16 Jul 87 00:58:32 MDT From: cetron@utah-ced (Ed Cetron) Message-Id: <8707160658.AA06350@utah-ced.ARPA> To: tcp-ip@nic.sri.com Subject: twg and nic not knowing its domain name? I recently tried to post to the tcp-ip newsgroup and had this result: >From MAILER-DAEMON@cs.utah.edu Wed Jul 15 23:30:05 1987 Date: Wed, 15 Jul 87 23:34:10 MDT From: MAILER-DAEMON@cs.utah.edu (Mail Delivery Subsystem) Message-Id: <8707160534.AA02006@cs.utah.edu> Subject: Returned mail: Host unknown To: cetron@cs.utah.edu Status: RO ----- Transcript of session follows ----- 550 tcp-ip@nic.sri.com... Host unknown ----- Unsent message follows ----- From: cetron (Edward J Cetron) Message-Id: <8707160534.AA02003@cs.utah.edu> Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong TCP/IP for VAX/VMS References: <8707152153.AA04238@ucbvax.Berkeley.EDU> Reply-To: cs.utah.edu.uucp!cetron (Edward J Cetron) Organization: Center for Engineering Design, Univ of Utah Apparently-To: tcp-ip@nic.sri.com Well, I for one have been one of the more vociferous critics of the WIN/VX product for quite some time. I have seen too many sites complain of brain-damage and poor support. In addition, we ran the 2.3 version against the Tek-CMU code and the WIN/VX just couldn't cut it. HOWEVER, given the current number of sites running 3.0 and saying it is quite capable, and the kind of response TWG has been putting forth (witness Dave Crocker's article) and the very good experience support-wise reported from new 3.0 sites, I think I might reserve judgement. Now, if only they can make it as inexpensive as the Tek-CMU code :-)....... -ed cetron cetron@cs.utah.edu nic.sri.com is in the host tables, it nic just not answering right??? -ed cetron@cs.utah.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12318755656.17.MKL@SRI-NIC.ARPA] <1987071523455200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MKL@SRI-NIC.ARPA (Mark Lottor) Newsgroups: comp.protocols.tcp-ip Subject: Re: twg, and nic not knowing its domain name.... Message-ID: <12318755656.17.MKL@SRI-NIC.ARPA> Date: Thu, 16-Jul-87 03:45:52 EDT Article-I.D.: SRI-NIC.12318755656.17.MKL Posted: Thu Jul 16 03:45:52 1987 Date-Received: Sat, 18-Jul-87 05:45:31 EDT References: <8707160703.AA06365@utah-ced.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 2 NIC.SRI.COM is not and was never the official name of any host. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [553428818.0.PERRY@VAX.DARPA.MIL] <1987071602133800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL (Dennis G. Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: Routers and Internet Protocol #77 Message-ID: <553428818.0.PERRY@VAX.DARPA.MIL> Date: Thu, 16-Jul-87 06:13:38 EDT Article-I.D.: VAX.553428818.0.PERRY Posted: Thu Jul 16 06:13:38 1987 Date-Received: Sat, 18-Jul-87 06:33:42 EDT References: <8707141453.AA15834@monk.proteon.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 John, I tend to agree with you. IP routers need to be kept simple under the current architectural concepts. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987071603422000> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Thu 16 Jul 87 07:24:51-PDT To: Mark Lottor cc: tcp-ip@SRI-NIC.ARPA, brescia@CCV.BBN.COM Subject: Name of NIC (was: twg, and nic not knowing its domain name..) In-reply-to: Your message of Thu, 16 Jul 87 00:45:52 -0700. <12318755656.17.MKL@SRI-NIC.ARPA> Date: Thu, 16 Jul 87 10:22:20 -0400 From: Mike Brescia NIC.SRI.COM is not and was never the official name of any host. SRI-NIC.ARPA is equally hard to remember. I suggest that NIC be a name at the top level of the domain tree, and be the obvious place. The reason is that the Net.Info.Ctr is a top level resource, not actually some branch of SRI.COM. Suppose SRI changes its corporate name? Suppose ARPA removes its support of the internet, and the ARPA domain goes away? The (THE) NIC service should still be available by name. Mike. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987071604263300> Received: from spam.istc.sri.com by SRI-NIC.ARPA with TCP; Thu 16 Jul 87 16:04:20-PDT Received: by spam.istc.sri.com (5.51/5.00) id AA05920 for tcp-ip@sri-nic.arpa; Thu, 16 Jul 87 16:06:34 PDT Message-Id: <8707162306.AA05920@spam.istc.sri.com> To: tcp-ip@sri-nic.arpa Cc: desiree@kl.sri.com, brunner@kl.sri.com, kashtan@stripe.sri.com Subject: Re: TCP-IP on VMS from SRI Date: Thu, 16 Jul 87 16:06:33 -0700 From: Thomas Eric Brunner The Right Person is desiree@kl.sri.com. Some relevent traffic included below for context. ------- Forwarded Message >In article <353@louie.udel.EDU>, Joel Garrett (garrett@udel.EDU) writes: > >> I've been hearing a lot of talk about a VMS implementation of TCP/IP >> from either Tektronix or SRI. Who can I get in contact with for more >> information about this product? > >Some time back, I was asked this question by mail. After a bit of >calling around inside Tektronix, I wound up talking to The Right Person. >The answer (for the Tektronix software) is, "Call your local Tektronix >field office." (I don't know the answer for SRI.) > > Steve Rice > ------- End of Forwarded Message ------- Forwarded Message >We have been using TWG on our VMS VAXs in a subnetted environment without >problems major problems for almost two years. In fact, for about 6 months, >we used a VAX8600 running VMS4.2 and TWG to drive two ethernets and 4 T1 lines, >until we switched to ULTRIX, ( I was not in favor of using a VAX/VMS as an >ip gateway but at that time we had no choice ). > > -- Sergio ------- End of Forwarded Message /teb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707161232.AA03351@gateway.mitre.org] <1987071604324600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gross@GATEWAY.MITRE.ORG (Phill Gross) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet meltdowns Message-ID: <8707161232.AA03351@gateway.mitre.org> Date: Thu, 16-Jul-87 08:32:46 EDT Article-I.D.: gateway.8707161232.AA03351 Posted: Thu Jul 16 08:32:46 1987 Date-Received: Sat, 18-Jul-87 06:54:32 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 > The people who > will be implementing ISO are exactly the same people who have ignored > the TCP/IP implementation guidelines. If people can do IP's that > don't respond to ICMP echo ... At least in theory, this is not the way it is supposed to work. A principal reason for eventually converting to ISO protocols is that they will be off-the-shelf, conforming products freely available from all vendors, where `conformance' is meant to imply both adherence to the standard and interoperation between vendor implementations. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870716093012.7.CRAWLEY@FLIGHTLESS-WATERFOWL.SCRC.Symbolics.COM] <1987071605300000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Crawley@ALDERAAN.SCRC.SYMBOLICS.COM (Eric S. Crawley) Newsgroups: comp.protocols.tcp-ip Subject: SCRC Ethernet change Message-ID: <870716093012.7.CRAWLEY@FLIGHTLESS-WATERFOWL.SCRC.Symbolics.COM> Date: Thu, 16-Jul-87 09:30:00 EDT Article-I.D.: FLIGHTLE.870716093012.7.CRAWLEY Posted: Thu Jul 16 09:30:00 1987 Date-Received: Sat, 18-Jul-87 08:16:58 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 [Please excuse the wide distribution I know this shouldn't be necessary.] On Saturday, July 18th, the SCRC ethernet will change from 192.10.41.0 to 128.81.41.0. The appropriate changes were put into the NIC Host table on Wednesday July 15th. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707161448.AA20895@gateway.mitre.org] <1987071606485200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: charny@GATEWAY.MITRE.ORG (M. Charny) Newsgroups: comp.protocols.tcp-ip Subject: Re: PD TCP/IP requests Message-ID: <8707161448.AA20895@gateway.mitre.org> Date: Thu, 16-Jul-87 10:48:52 EDT Article-I.D.: gateway.8707161448.AA20895 Posted: Thu Jul 16 10:48:52 1987 Date-Received: Sat, 18-Jul-87 07:45:40 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 106 Pat, I have sent the following information to several people who have asked about this. I hope it is helpful to you. Manette Charny -+-+-+-+-+-+-+-+-+-+-+- The MITRE Corporation has produced several prototype implementations of devices using the Department of Defense (DoD) communication protocols TCP, IP, ARP, ICMP, and TELNET. Most of the implementations use the CMOS/DMOS operating systems also produced by MITRE. The programs are written in "C" language and Motorola 68000 assembler. The programs are maintained on a SUN3 workstation running Berkely 4.2 UNIX. MITRE is not in the business of distributing or maintaining software. Devices and software created by MITRE are prototypes created for particular sponsors. The programs are available to the outside world according to the conditions and procedures listed below. **Please note that distribution is done on a time available basis and therefore delivery turn-around time cannot be guaranteed.** The software is distributed free of charge. In order to obtain a copy of this software, the requester should send to one of the below listed people: 1. 2400 foot reel of 1/2 inch magnetic tape capable of handling 1600 bpi. 2. Letter, on your company letterhead, indicating the following: -- who they are -- short synopsis (2-3 sentences) about what our software is to be used for -- equipment and operating system being used by them. -- tape format desired: only format possible is Berkely 4.2 UNIX tar, 1600 bpi, and any blocking factor 1 through 20. (20 by default) -- they agree to the four conditions listed below (please explicitly list the conditions in the letter). i. The MITRE TCP/IP source files will not be passed on to any third party. ii. MITRE will be credited should the software be used in a product or written about in any publication. However, MITRE will not be referenced as the source in advertisements. iii. MITRE assumes no legal responsibility for source code and its subsequent use. No warranty is expressed or implied. iv. If any bugs or problems are found they will be reported back to MITRE. NOTE: These programs are not commercial quality, but do work. A good 'hacker' can learn to build 'boxes' by studying the 'config', 'table', and 'Makefiles' in the directories 'box/diag/testV', 'box/testV/1822', 'box/hfe', and 'box/gate_egp'. The current contact(s) for the TCP/IP distribution tape are: Manette Charny Mailstop: W425 1820 Dolley Madison Blvd. McLean, VA 22102 (703) 883-6728 ARPANET: charny@mitre-gateway Daryl Crandall Mailstop: W429 1820 Dolley Madison Blvd. McLean, VA 22102 (703) 883-7278 ARPANET: daryl@mitre-gateway Documents describing the OS and the TCP/IP implementation can be obtained from MITRE document control. "CMOS, A Portable Operating System in C" Gilbert R. Berglass MITRE Technical Report: MTR-84W00071 "DMOS, A Portable Distributed Operating System in C" Shiraz G. Bhanji MITRE Technical Report: MTR-85W00206 "Implementation of the BBN 1822 Host-to-IMP Protocol in a CMOS Environment" Manette Charny MITRE Working Paper: WP-84W00223 "The MITRE Implementation of MIL-STD 1777: The Internet Protocol" William S. Morgart MITRE Working Paper: WP-86W??? (not released yet!) "TCP/IP" Interface Specifications for CMOS Systems" Daryl O. Crandall MITRE Working Paper: WP-86W00180 "TCP/IP" Diagnostic Package for CMOS Systems" Daryl O. Crandall MITRE Working Paper: WP-86W??? (not released yet!) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707161604.AA01826@confusion.Princeton.EDU] <1987071608040000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: barry@confusion.UUCP (Barry Lustig) Newsgroups: comp.protocols.tcp-ip Subject: PD TCP/IP requests Message-ID: <8707161604.AA01826@confusion.Princeton.EDU> Date: Thu, 16-Jul-87 12:04:00 EDT Article-I.D.: confusio.8707161604.AA01826 Posted: Thu Jul 16 12:04:00 1987 Date-Received: Sat, 18-Jul-87 07:45:26 EDT References: <122@casetek.casetek.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 A "mini" TCP/IP was once posted to comp.sources.unix. You may want to look at the archives on uunet.uu.net. Barry Lustig Cognitive Science Lab Princeton University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707162244.AA01413@nic.nyser.net] <1987071614443600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: weltyc@NIC.NYSER.NET (Christopher A. Welty) Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP for VMS Message-ID: <8707162244.AA01413@nic.nyser.net> Date: Thu, 16-Jul-87 18:44:36 EDT Article-I.D.: nic.8707162244.AA01413 Posted: Thu Jul 16 18:44:36 1987 Date-Received: Sat, 18-Jul-87 09:04:10 EDT References: <4491@videovax.Tek.COM> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 15 The Tek TCP/IP for VMS was sort of taken over by cmu, I believe, it still legally belongs to Tektronics, but CMU has spiced it up a lot. There is a special mailing list for the tektronic tcp/ip called tektcp, ummm let's see, send a msg to: tektcp-request%kla.weslyn%wesleyan.bitnet@wiscvm.wisc.edu to get added. There's probably a shorter way to write it, but that's all I have.... --- Christopher Welty - Asst. Director, RPI CS Labs weltyc@cs.rpi.edu ...!seismo!rpics!weltyc ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707170353.AA13278@ucbvax.Berkeley.EDU] <1987071619411400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CDRNI@CUNYVM.BITNET ("George N. Reeke Jr.") Newsgroups: comp.protocols.tcp-ip Subject: NETWATCH Message-ID: <8707170353.AA13278@ucbvax.Berkeley.EDU> Date: Thu, 16-Jul-87 23:41:14 EDT Article-I.D.: ucbvax.8707170353.AA13278 Posted: Thu Jul 16 23:41:14 1987 Date-Received: Sat, 18-Jul-87 11:22:05 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 3 Can someone out there tell me how to get a copy of NETWATCH for IBM PC (or some similar program to analyze ETHERNET traffic)? Thanks, GNR ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987071619411401> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Thu 16 Jul 87 20:43:47-PDT Received: from CUNYVM.BITNET by wiscvm.wisc.edu ; Thu, 16 Jul 87 22:41:52 CDT Received: by CUNYVM (Mailer X1.23b) id 7700; Thu, 16 Jul 87 23:43:31 EDT Date: Thu, 16 Jul 87 23:41:14 EDT From: "George N. Reeke Jr." Subject: NETWATCH To: tcp-ip@sri-nic.arpa Can someone out there tell me how to get a copy of NETWATCH for IBM PC (or some similar program to analyze ETHERNET traffic)? Thanks, GNR ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707170455.aa00520@VGR.BRL.ARPA] <1987071700554900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dpk@BRL.ARPA (Doug Kingston) Newsgroups: comp.protocols.tcp-ip Subject: Something has changed dramatically Message-ID: <8707170455.aa00520@VGR.BRL.ARPA> Date: Fri, 17-Jul-87 04:55:49 EDT Article-I.D.: VGR.8707170455.aa00520 Posted: Fri Jul 17 04:55:49 1987 Date-Received: Sat, 18-Jul-87 13:06:55 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Internet performance has soared to some of the best I have see all year. I have been able to successfully access Berkeley and UCL is finally available again. I would like to thank whoever is responsible for the recent change of events and to suggest that perhaps a status update is in order. Putting away my UUCP, -Doug- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987071700581300> Received: from ALEXANDER.BBN.COM by SRI-NIC.ARPA with TCP; Fri 17 Jul 87 06:21:04-PDT To: Doug Kingston cc: tcp-ip@SRI-NIC.ARPA cc: scohn@ALEXANDER.BBN.COM Subject: Re: Something has changed dramatically In-reply-to: Your message of Fri, 17 Jul 87 4:55:49 EDT. <8707170455.aa00520@VGR.BRL.ARPA> Date: Fri, 17 Jul 87 09:18:13 -0500 From: Steve Cohn Here's something that changed. BBN modified the metric used for calculating SPF routes in the Arpanet on Sunday, 12 July. A detailed description and analysis of how it works and a report on measured changes in performance in the Arpanet will be forthcoming eventually. In brief, this change in the metric leads to more stable routing behavior when the network is overloaded, thereby reducing the tendency for congestion to spread from overloaded paths to the rest of the network. This modification also tends to make satellite trunking more attractive. Other potential sources for improvement include recent topology changes including the addition of transcontinental VSAT trunks between MIT-77 and SRI-51. These trunks became operational about 1 July. The routing effort is still in the experimental/tuning stage. We expect that performance on many PSN-to-PSN flows will be improved by this modification. It is also possible that some PSN-to-PSN flows will receive degraded performance. We at BBN would like to hear both the good news and the bad news. Please send your observations about recent changes in internet/Arpanet performance to Fred Serr (fserr@bbn.com), Bob Pyle (rpyle@bbn.com) and myself (scohn@bbn.com) and I suppose to the list if your observation is of general interest. Stephen Cohn Director of Network Analysis BBN Communications ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987071702512800> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Fri 17 Jul 87 06:42:50-PDT To: CERF@A.ISI.EDU cc: dpk@BRL.ARPA, tcp-ip@SRI-NIC.ARPA, hinden@CCV.BBN.COM Subject: Re: Something has changed dramatically In-reply-to: Your message of 17 Jul 87 06:59:00 -0400. <[A.ISI.EDU]17-Jul-87 06:59:34.CERF> Date: Fri, 17 Jul 87 09:31:28 -0400 From: Robert Hinden Vint, Doug, Its not voodoo networking, but lots of hard work. There have been several changes on the Arpanet (new line and a software patch) which make things better. These changes are very recent. A more detailed report will be seen soon. Regards, Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]17-Jul-87.06:59:34.CERF] <1987071702590000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Something has changed dramatically Message-ID: <[A.ISI.EDU]17-Jul-87.06:59:34.CERF> Date: Fri, 17-Jul-87 06:59:00 EDT Article-I.D.: <[A.ISI.EDU]17-Jul-87.06:59:34.CERF> Posted: Fri Jul 17 06:59:00 1987 Date-Received: Sat, 18-Jul-87 13:32:51 EDT References: <8707170455.aa00520@VGR.BRL.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 16 Doug, Voodoo networking! (George Bush theme for the 88 campaign?) Maybe someone sacrificed a chicken over RFC 1009? Added some links? Your puzzlement points out that we lack any global view of the Internet and don't even have a good way to figure out when we should report changes we've made in some part of the system or to whom such changes should be reported. Sounds like a good INENG topic, to me. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987071703303600> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Fri 17 Jul 87 07:15:19-PDT To: "George N. Reeke Jr." cc: tcp-ip@SRI-NIC.ARPA, brescia@CCV.BBN.COM Subject: Re: NETWATCH In-reply-to: Your message of Thu, 16 Jul 87 23:41:14 -0400. Date: Fri, 17 Jul 87 10:10:36 -0400 From: Mike Brescia NETWATCH for IBM PC (or some similar program ... TCPDUMP for Suns is also useful for checking traffic patterns. It does lack the real-time interface that NETWATCH has. Van Jacobson (van@lbl-csam.arpa) made this available from one of his hosts. mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707171340.AA21710@ucbvax.Berkeley.EDU] <1987071705425900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: scohn@ALEXANDER.BBN.COM (Steve Cohn) Newsgroups: comp.protocols.tcp-ip Subject: Re: Something has changed dramatically Message-ID: <8707171340.AA21710@ucbvax.Berkeley.EDU> Date: Fri, 17-Jul-87 09:42:59 EDT Article-I.D.: ucbvax.8707171340.AA21710 Posted: Fri Jul 17 09:42:59 1987 Date-Received: Sat, 18-Jul-87 13:48:32 EDT References: <8707170455.aa00520@VGR.BRL.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 25 Here's something that changed. BBN modified the metric used for calculating SPF routes in the Arpanet on Sunday, 12 July. A detailed description and analysis of how it works and a report on measured changes in performance in the Arpanet will be forthcoming eventually. In brief, this change in the metric leads to more stable routing behavior when the network is overloaded, thereby reducing the tendency for congestion to spread from overloaded paths to the rest of the network. This modification also tends to make satellite trunking more attractive. Other potential sources for improvement include recent topology changes including the addition of transcontinental VSAT trunks between MIT-77 and SRI-51. These trunks became operational about 1 July. The routing effort is still in the experimental/tuning stage. We expect that performance on many PSN-to-PSN flows will be improved by this modification. It is also possible that some PSN-to-PSN flows will receive degraded performance. We at BBN would like to hear both the good news and the bad news. Please send your observations about recent changes in internet/Arpanet performance to Fred Serr (fserr@bbn.com), Bob Pyle (rpyle@bbn.com) and myself (scohn@bbn.com) and I suppose to the list if your observation is of general interest. Stephen Cohn Director of Network Analysis BBN Communications ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707171353.AA21839@ucbvax.Berkeley.EDU] <1987071705560400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hinden@CCV.BBN.COM (Robert Hinden) Newsgroups: comp.protocols.tcp-ip Subject: Re: Something has changed dramatically Message-ID: <8707171353.AA21839@ucbvax.Berkeley.EDU> Date: Fri, 17-Jul-87 09:56:04 EDT Article-I.D.: ucbvax.8707171353.AA21839 Posted: Fri Jul 17 09:56:04 1987 Date-Received: Sat, 18-Jul-87 14:02:31 EDT References: <[A.ISI.EDU]17-Jul-87.06:59:34.CERF> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Vint, Doug, Its not voodoo networking, but lots of hard work. There have been several changes on the Arpanet (new line and a software patch) which make things better. These changes are very recent. A more detailed report will be seen soon. Regards, Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707171423.AA22088@ucbvax.Berkeley.EDU] <1987071706264700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@CCV.BBN.COM (Mike Brescia) Newsgroups: comp.protocols.tcp-ip Subject: Re: NETWATCH Message-ID: <8707171423.AA22088@ucbvax.Berkeley.EDU> Date: Fri, 17-Jul-87 10:26:47 EDT Article-I.D.: ucbvax.8707171423.AA22088 Posted: Fri Jul 17 10:26:47 1987 Date-Received: Sat, 18-Jul-87 14:02:45 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 NETWATCH for IBM PC (or some similar program ... TCPDUMP for Suns is also useful for checking traffic patterns. It does lack the real-time interface that NETWATCH has. Van Jacobson (van@lbl-csam.arpa) made this available from one of his hosts. mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [SRA.12319113498.BABYL@XX.LCS.MIT.EDU] <1987071708310000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: SRA@XX.LCS.MIT.EDU (Rob Austein) Newsgroups: comp.protocols.tcp-ip Subject: Something has changed dramatically Message-ID: Date: Fri, 17-Jul-87 12:31:00 EDT Article-I.D.: XX.SRA.12319113498.BABYL Posted: Fri Jul 17 12:31:00 1987 Date-Received: Sat, 18-Jul-87 14:54:54 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 13 The third transcontinental link (MIT77 <=> SRI51) came online about two weeks ago. I noticed a serious DECREASE in performance just after the link came up, but now I too am seeing a major performance improvement (it's been a long time since I could FTP from MIT to Stanford at noon on a Friday!). My guess is that there were some initial tuning problems after the new link came up; not too surprising given that this is a satellite bounce instead of a land line. Presumably somebody at BBN can give a more detailed report. --Rob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [210@casemo.UUCP] <1987071710160200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brian@casemo.UUCP (Brian Cuthie ) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong TCP/IP for VAX/VMS Message-ID: <210@casemo.UUCP> Date: Fri, 17-Jul-87 14:16:02 EDT Article-I.D.: casemo.210 Posted: Fri Jul 17 14:16:02 1987 Date-Received: Sat, 18-Jul-87 17:02:48 EDT References: <12316245218.8.MRC@PANDA> <432@umbc3.UMD.EDU> Organization: CASE Communications, Columbia, MD Lines: 29 In article <432@umbc3.UMD.EDU>, jeff@umbc3.UMD.EDU (Jeffrey Burgan) writes: > In article <12316245218.8.MRC@PANDA> MRC@PANDA.COM (Mark Crispin) writes: > > > > I received my nth bug report from a Wollongong site today complaining > >that mail didn't work between them and a DEC-20. > > > > The problem is, of course, that the Wollongong software simply does > >not work ... and that Wollongong simply does not care. > > We have been running Wollongong's software for 2 years and have > never experienced any problems sending to a TOPS-20 machine. ... > What would you have VMS user's use? > UNIX of course !! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Brian Cuthie CASE (Rixon) Communications Columbia Md. 21046 (301) 290 - 7443 ARPA: Brian@umbc3.umd.edu UUCP: ...seismo!mimsy!aplcen!casemo!brian ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707171821.AA04846@nic.nyser.net] <1987071710214300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: schoff@NIC.NYSER.NET (Martin Lee Schoffstall) Newsgroups: comp.protocols.tcp-ip Subject: TWG questions Message-ID: <8707171821.AA04846@nic.nyser.net> Date: Fri, 17-Jul-87 14:21:43 EDT Article-I.D.: nic.8707171821.AA04846 Posted: Fri Jul 17 14:21:43 1987 Date-Received: Sat, 18-Jul-87 16:46:09 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 I have two questions concerning the current (3.X) implementation: 1) does it still support the async tcp/ip code (ttylink in WIN/VX 2.2) 2) Does anyone have a DECNET async connection where they use DBRIDGE, and what is the performance like? Marty ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707171853.AA26632@ucbvax.Berkeley.EDU] <1987071710440300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet Uselessness Message-ID: <8707171853.AA26632@ucbvax.Berkeley.EDU> Date: Fri, 17-Jul-87 14:44:03 EDT Article-I.D.: ucbvax.8707171853.AA26632 Posted: Fri Jul 17 14:44:03 1987 Date-Received: Sat, 18-Jul-87 16:45:40 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 48 [The following got to John, but not to the List, thanks to the vagaries of trying to Answer on his foreign To and CC fields:] John-- As I understand your msg, "the PTT way" amounts to Overcharge So That You Can Overengineer. The Internet way, however, doesn't have to be Undercharge And You Must Underengineer. How about, instead, Undercharge And You'd Better Engineer A Lot More Cleverly? For example, I recall that in the Multics NCP [sic] I had a privileged primitive that let me ignore packets from a Host on a blacklist at interrupt time (which was actually used once, during the infamous Network Horror Story Number 5): Why not use a similar trick in Gateways? Say, on a 30-second cycle (or whatever time value seems appropriate) check the per-Host packet counters (added for the purpose) and put any Host that's exceeded a threshold count on the List for the next cycle. A tad arbitrary, perhaps, but much easier to implement than trying to spot and throttle sf-lovers file transfers/SMTPs. (The threshold should probably be a fraction of total packets for the period rather than a set number, so that periods of relative inactivity for other Hosts behind the Gateway can be catered to--but this is just a "frinstance," not a spec, so no matter.) The example isn't necessarily to be taken literally, of course; it's just meant to suggest a principle to the effect that you can combat resource hogging creatively without violating protocol (since Gateways are explicitly allowed to drop packets on the floor) on the one hand yet without having to "go commercial" on the other hand. Actually, I've long suspected that the real problem with the Internet Way is that we draw so heavily on Academe that clever engineering is somehow suspect because it's not Computer Sciencey enough somehow. I mean, granted we couldn't have afforded to throw as much hardware as we might have liked at Gateways from the outset, but it still seems to me that all the pious queuing-theoretic stuff about one buffer is enough and even infinite buffers aren't enough and the like has clouded the issue so much that we still (unless the relevant Task Force is about to step in) haven't come up with a rough and ready congestion control approach because we "know" it wouldn't be "optimal". Well, as I've said before Optimality Differs According To Context. cheers, map P.S. As I recall, the X.25 spec certainly _implies_ that there won't be any dynamic routing, both in one of the error returns and, for that matter, in the whole "virtual circuit" premise (since destination addrs aren't carried in ordinary packets), but, yes, They could do it right despite all that if They had/wanted to. Does anybody know of an implementations that do do it right, though? (And even if there are some, so what? We could have some segments of the Internet which used Multics Gateways if we wanted/had to. Some old saw about weakest links still seems to apply....) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [25@abvax.icd.ab.com] <1987071712243100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: wrk@abvax.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Wollongong telnet and new line processing Message-ID: <25@abvax.icd.ab.com> Date: Fri, 17-Jul-87 16:24:31 EDT Article-I.D.: abvax.25 Posted: Fri Jul 17 16:24:31 1987 Date-Received: Tue, 21-Jul-87 02:40:55 EDT Organization: Allen-Bradley Company, Inc; Industrial Computer Division, Highland Heights, OH Lines: 30 Keywords: Wollongong telnet BSD4.3 I've been tyring to get our BSD 4.3 VAX to talk to a VAX/VMS system using Wollongong telnet and have discovered an interesting problem. Unix uses \n as the line terminator, but VMS interpetes that as 'delete the word to the left of the cursor'. So imagine this: % telnet vms_node Username: GUEST ^ and here you type a return. Unix translate the \r into a \n and sends it across the net to the VMS machine which promptly deletes the word GUEST. This makes logging in a little difficult. I've modified telnet to send a \r instead of a \n for the line terminator. Although I think this is only a work around. I say this because if you are connect to the Unix machine via a direct line everything works fine. This problem only occurs when you are connected via a pty. We use Bridge cs/1 terminal servers almost exclusivly, hence you are always connected to a pty and never to a direct line. This leads me to think that the problem lies somewhere in the pty driver. Anyone have any ideas? Thanks Bill King ...!{pyramid,decvax}!abic!wrk ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707172027.AA06335@braden.isi.edu] <1987071712273600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@BRADEN.ISI.EDU (Bob Braden) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet meltdowns Message-ID: <8707172027.AA06335@braden.isi.edu> Date: Fri, 17-Jul-87 16:27:36 EDT Article-I.D.: braden.8707172027.AA06335 Posted: Fri Jul 17 16:27:36 1987 Date-Received: Sat, 18-Jul-87 17:12:00 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 22 Phil, Your interpretation of the IP broadcast address situation is at variance from the "official" interpretation in RFC-1009. The issue is one on which reasonable and informed Internetters can and have disagreed, on this mailing list and elsewhere, and there probably is not a "right" answer. However, we did make a decision, and gave the Internet community plenty of chance to read and comment on RFC-1009 before it was published. As a matter of fact, the IP broadcast address was not an issue on which anybody made a comment (and there WERE plenty of comments and commenters on the RFC-985+ draft!). I suspect that you will now go read RFC-1009, and be suitably outraged. All outraged messages to Jon Postel or myself on the contents of RFC-1009 will be read, considered carefully, and if the arguments are irrefutable, will influence a future revision to the RFC. Bob Braden PS I think you make a mistake by dismissing the IP multicasting mechanism. A 4.3BSD implementation is available today for anyone who wants it. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707171704.a004101@Huey.UDEL.EDU] <1987071713043300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet meltdowns Message-ID: <8707171704.a004101@Huey.UDEL.EDU> Date: Fri, 17-Jul-87 17:04:33 EDT Article-I.D.: Huey.8707171704.a004101 Posted: Fri Jul 17 17:04:33 1987 Date-Received: Sun, 19-Jul-87 07:06:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Phil, Read RFC-985 and its recent successor. The IP address space is not flat. There are architected IP broadcast (and other) addresses, whether bogus or not. The intent of the martian filter is to kill "local" broadcasts before they escape the local net. This is a pragmatic consideration based on some years of horror living without it. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707180308.AA04241@ucbvax.Berkeley.EDU] <1987071719025100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jch@OMNIGATE.CLARKSON.EDU (Jeffrey C Honig) Newsgroups: comp.protocols.tcp-ip Subject: Re: twg, and nic not knowing its domain name.... Message-ID: <8707180308.AA04241@ucbvax.Berkeley.EDU> Date: Fri, 17-Jul-87 23:02:51 EDT Article-I.D.: ucbvax.8707180308.AA04241 Posted: Fri Jul 17 23:02:51 1987 Date-Received: Sat, 18-Jul-87 19:07:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 16 > >I tried to send an article into the tcp-ip mailing list (twice) and >I keep getting the mail back....(with some headers removed) here is >the letter and returned mail: > > ... > >nic.sri.com is in the host tables, it nic just not answering right??? No, nic.sri.com is not in the host tables that I have, #648. The authoritive servers for sri.com, kl.sri.com and stripe.sri.com, both claim that it does not exist. It looks like that alias was removed, the question is, was it intentional? Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987071719025101> Received: from omnigate.clarkson.edu by SRI-NIC.ARPA with TCP; Fri 17 Jul 87 20:04:47-PDT Received: by omnigate.clarkson.edu id aa01203; 17 Jul 87 23:03 EDT Date: Fri, 17 Jul 87 23:02:51 EDT From: Jeffrey C Honig To: Ed Cetron cc: tcp-ip@sri-nic.arpa Subject: Re: twg, and nic not knowing its domain name.... > >I tried to send an article into the tcp-ip mailing list (twice) and >I keep getting the mail back....(with some headers removed) here is >the letter and returned mail: > > ... > >nic.sri.com is in the host tables, it nic just not answering right??? No, nic.sri.com is not in the host tables that I have, #648. The authoritive servers for sri.com, kl.sri.com and stripe.sri.com, both claim that it does not exist. It looks like that alias was removed, the question is, was it intentional? Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1987.7.18.7.14.3.Eugene.Hastings@morgul] <1987071723185500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Eugene.Hastings@MORGUL.PSC.EDU Newsgroups: comp.protocols.tcp-ip Subject: X.25 on vax (was: Vaxes and the System 38)~r Message-ID: <1987.7.18.7.14.3.Eugene.Hastings@morgul> Date: Sat, 18-Jul-87 03:18:55 EDT Article-I.D.: morgul.1987.7.18.7.14.3.Eugene.Hastings Posted: Sat Jul 18 03:18:55 1987 Date-Received: Sat, 18-Jul-87 20:51:41 EDT References: <1604@phred.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 There exists a DEC package called PSI that provides X.25 communications. We have a pair of VMS 8650s connected to GTE TELENET in this manner. It required a special (fairly smart) interface, also DEC. Gene Hastings Pittburgh Supercomputing Center ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707181004.AA09360@ucbvax.Berkeley.EDU] <1987071802415100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@CCV.BBN.COM (Mike Brescia) Newsgroups: comp.protocols.tcp-ip Subject: Name of NIC (was: twg, and nic not knowing its domain name..) Message-ID: <8707181004.AA09360@ucbvax.Berkeley.EDU> Date: Sat, 18-Jul-87 06:41:51 EDT Article-I.D.: ucbvax.8707181004.AA09360 Posted: Sat Jul 18 06:41:51 1987 Date-Received: Sat, 18-Jul-87 21:04:56 EDT References: <12318755656.17.MKL@SRI-NIC.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 11 NIC.SRI.COM is not and was never the official name of any host. SRI-NIC.ARPA is equally hard to remember. I suggest that NIC be a name at the top level of the domain tree, and be the obvious place. The reason is that the Net.Info.Ctr is a top level resource, not actually some branch of SRI.COM. Suppose SRI changes its corporate name? Suppose ARPA removes its support of the internet, and the ARPA domain goes away? The (THE) NIC service should still be available by name. Mike. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [553606399.0.PERRY@VAX.DARPA.MIL] <1987071803331900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL (Dennis G. Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: Name of NIC (was: twg, and nic not knowing its domain name..) Message-ID: <553606399.0.PERRY@VAX.DARPA.MIL> Date: Sat, 18-Jul-87 07:33:19 EDT Article-I.D.: VAX.553606399.0.PERRY Posted: Sat Jul 18 07:33:19 1987 Date-Received: Sun, 19-Jul-87 00:35:35 EDT References: <8707181112.AA29845@vax.darpa.mil> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Mike, I agree with you. The NIC should be availabe by name, regardless of where it is located. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [M.JSOL.12319353801.BABYL@MIT-EECS] <1987071806310000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: M.JSOL@DEEP-THOUGHT.MIT.EDU (Jon Solomon) Newsgroups: comp.protocols.tcp-ip Subject: Name of NIC (was: twg, and nic not knowing its domain name..) Message-ID: Date: Sat, 18-Jul-87 10:31:00 EDT Article-I.D.: MIT-EECS.M.JSOL.12319353801.BABYL Posted: Sat Jul 18 10:31:00 1987 Date-Received: Sun, 19-Jul-87 00:49:10 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 It's a neat idea, but the main problem with that is that there is already another NIC (I'm speaking of nic.nyser.net). --jsol p.s. also there is a BITNIC in the BITNET namespace. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12319418972.8.M.JSOL@DEEP-THOUGHT.MIT.EDU] <1987071812293400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: M.JSOL@DEEP-THOUGHT.MIT.EDU (Jon Solomon) Newsgroups: comp.protocols.tcp-ip Subject: another joke. Message-ID: <12319418972.8.M.JSOL@DEEP-THOUGHT.MIT.EDU> Date: Sat, 18-Jul-87 16:29:34 EDT Article-I.D.: DEEP-THO.12319418972.8.M.JSOL Posted: Sat Jul 18 16:29:34 1987 Date-Received: Sun, 19-Jul-87 01:40:57 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 2 "don't talk about networking in front of the kids". ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12319419581.8.M.JSOL@DEEP-THOUGHT.MIT.EDU] <1987071812325500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: M.JSOL@DEEP-THOUGHT.MIT.EDU (Jon Solomon) Newsgroups: comp.protocols.tcp-ip Subject: my last message Message-ID: <12319419581.8.M.JSOL@DEEP-THOUGHT.MIT.EDU> Date: Sat, 18-Jul-87 16:32:55 EDT Article-I.D.: DEEP-THO.12319419581.8.M.JSOL Posted: Sat Jul 18 16:32:55 1987 Date-Received: Sun, 19-Jul-87 01:42:14 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 14 If you don't get it, don't worry. I sent it to the wrong list. o o p s sorry folks, --jsol ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [593@ms3.UUCP] <1987071816142600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: isns01@ms3.UUCP (Jim Chappell) Newsgroups: comp.protocols.tcp-ip Subject: Gateway problem Message-ID: <593@ms3.UUCP> Date: Sat, 18-Jul-87 20:14:26 EDT Article-I.D.: ms3.593 Posted: Sat Jul 18 20:14:26 1987 Date-Received: Sun, 19-Jul-87 06:48:55 EDT Distribution: na Organization: ISN HIOS Project, Arlington, VA Lines: 83 Keywords: 4.2 BSD, VAX, whois from an interior node We are running vanilla 4.2BSD on Vaxen 11/780s. We use DEC DR-11 Direct Memory Access hardware connected to an Ungermann-Bass NIU-150 to implement TCP/IP over a broadband LAN. One of our Vaxen (hostname 'tlog') has a ACC DH/LH + modem connected to PSN 76 to implement milnet access. A representative interior VAX is 'ms3'. Visually, we have: --------- --------- | ms3 | | tlog | | | | |---\/\/---PSN 76--------| milnet | ---|----- ---|---- | | ------ ------- |NIU | | NIU | --|---- ---|--- --|--------------------------------|--------------------- --------------------------------------------------------- My problem exists on hosts interior to 'tlog' I have been unable to access the milnet directly from such hosts. Can anyone help me out? Also, what's the best documentation to use to get a handle on this beast? The ifconfig we use on ms3 is: /etc/ifconfig ub0 -trailers arp 92.0.0.6 Here's a script(1) output of what I've tried: Script started on Sat Jul 18 19:39:08 1987 ROOT(ms3) 1: netstat -r Routing tables Destination Gateway Flags Refcnt Use Interface loopback 127.0.0.1 U 0 0 lo0 92.0.0 ms3 U 0 7269 ub0 ROOT(ms3) 2: route add default tlog 0 add 0.0.0: gateway tlog, flags 1 ROOT(ms3) 3: netstat -r Routing tables Destination Gateway Flags Refcnt Use Interface default tlog U 0 0 ub0 loopback 127.0.0.1 U 0 0 lo0 92.0.0 ms3 U 0 7270 ub0 ROOT(ms3) 4: whosis Chappell whois: connect: Connection timed out ROOT(ms3) 5: netstat -r Routing tables Destination Gateway Flags Refcnt Use Interface default tlog U 0 11 ub0 loopback 127.0.0.1 U 0 0 lo0 92.0.0 ms3 U 0 7273 ub0 ROOT(ms3) 6: ^D script done on Sat Jul 18 19:41:08 1987 Script started on Sat Jul 18 20:07:29 1987 ROOT(ms3) 1: route add sri-nic tlog 1 add sri-nic: gateway tlog, flags 7 ROOT(ms3) 2: netstat -r Routing tables Destination Gateway Flags Refcnt Use Interface sri-nic tlog UGH 0 0 ub0 default tlog U 0 11 ub0 loopback 127.0.0.1 U 0 0 lo0 92.0.0 ms3 U 0 7387 ub0 ROOT(ms3) 3: whois Chappell whois: connect: Connection timed out ROOT(ms3) 4: netstat -r Routing tables Destination Gateway Flags Refcnt Use Interface sri-nic tlog UGH 0 11 ub0 default tlog U 0 11 ub0 loopback 127.0.0.1 U 0 0 lo0 92.0.0 ms3 U 0 7390 ub0 ROOT(ms3) 5: ^D script done on Sat Jul 18 20:09:00 1987 -- Jim Chappell ...!seismo!vrdxhq!ms3!jrc ISN Corp. (703) 979-8900 1235A Jeff Davis Hwy, Suite 220 Arlington, Va 22202 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707190252.AA06909@nic.nyser.net] <1987071818524200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: weltyc@NIC.NYSER.NET (Christopher A. Welty) Newsgroups: comp.protocols.tcp-ip Subject: Something has changed dramatically Message-ID: <8707190252.AA06909@nic.nyser.net> Date: Sat, 18-Jul-87 22:52:42 EDT Article-I.D.: nic.8707190252.AA06909 Posted: Sat Jul 18 22:52:42 1987 Date-Received: Sun, 19-Jul-87 07:08:26 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 Hard work indeed. I too have noticed significant improvement in ARPAnet performance. THose resposible should be congratulated! --- Christopher Welty - Asst. Director, RPI CS Labs weltyc@cs.rpi.edu ...!seismo!rpics!weltyc ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707190438.AA20723@ucbvax.Berkeley.EDU] <1987071820133700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: Re: Name of NIC (was: twg, and nic not knowing its domain name..) Message-ID: <8707190438.AA20723@ucbvax.Berkeley.EDU> Date: Sun, 19-Jul-87 00:13:37 EDT Article-I.D.: ucbvax.8707190438.AA20723 Posted: Sun Jul 19 00:13:37 1987 Date-Received: Sun, 19-Jul-87 08:36:02 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 4 Jon, I think that Mike and Dennis were thinking of the name of the entity to be NIC (or .NIC to be syntatically incorrect). Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987071820133701> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sat 18 Jul 87 21:18:29-PDT Date: 19 Jul 1987 00:13:37 EDT Subject: Re: Name of NIC (was: twg, and nic not knowing its domain name..) From: Dan Lynch To: Jon Solomon <@EDDIE.MIT.EDU:M.JSOL@DEEP-THOUGHT.MIT.EDU> cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: Jon, I think that Mike and Dennis were thinking of the name of the entity to be NIC (or .NIC to be syntatically incorrect). Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12319695446.19.ROODE@BIONET-20.ARPA] <1987071913481700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROODE@BIONET-20.ARPA (David Roode) Newsgroups: comp.protocols.tcp-ip Subject: Re: Name of NIC (was: twg, and nic not knowing its domain name..) Message-ID: <12319695446.19.ROODE@BIONET-20.ARPA> Date: Sun, 19-Jul-87 17:48:17 EDT Article-I.D.: BIONET-2.12319695446.19.ROODE Posted: Sun Jul 19 17:48:17 1987 Date-Received: Sun, 19-Jul-87 22:38:25 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 WaWhat about creating a domain under the top level NET domain, NIC.NET in there could be the name DDN.NIC.NET for the DDN NIC...... NYSER.NIC.NET for their NIC.... This also works for the NOC.... ARPANET.NOC.NET MILNET.NOC.NET etc. The NIC/NOC for the NSFNET is called NNSC for some reason, so NSFNET.NNSC.NET is also possible. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12319729249.11.ROMKEY@XX.LCS.MIT.EDU] <1987071916535800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROMKEY@XX.LCS.MIT.EDU (John Romkey) Newsgroups: comp.protocols.tcp-ip Subject: Re: NETWATCH Message-ID: <12319729249.11.ROMKEY@XX.LCS.MIT.EDU> Date: Sun, 19-Jul-87 20:53:58 EDT Article-I.D.: XX.12319729249.11.ROMKEY Posted: Sun Jul 19 20:53:58 1987 Date-Received: Mon, 20-Jul-87 03:45:29 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 NETWATCH is part of the PC/IP package from MIT. You can get a copy of it by contacting: MIT Microcomputer Center Room 11-209 77 Massachusetts Avenue Cambridge, MA 02139 (617) 253-6325 It has drivers for the 3COM 3C500/3C501 ethernet interface, the Micom-Interlan NI5010 ethernet interface and the Proteon p1300 ProNET-10 interface. - john romkey ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707200250.AA12477@nic.nyser.net] <1987071918503700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: schoff@NIC.NYSER.NET (Martin Lee Schoffstall) Newsgroups: comp.protocols.tcp-ip Subject: Re: Name of NIC (was: twg, and nic not knowing its domain name..) Message-ID: <8707200250.AA12477@nic.nyser.net> Date: Sun, 19-Jul-87 22:50:37 EDT Article-I.D.: nic.8707200250.AA12477 Posted: Sun Jul 19 22:50:37 1987 Date-Received: Mon, 20-Jul-87 03:54:13 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Actually there is a "nic.isi.edu" also. Reading between the lines is sri-nic.arpa suppose to become: nic.ddn.net Or some such thing? Marty ----MESSAGE-END---- ----MESSAGE-BEGIN---- [276@wapsyvax.OZ] <1987071919590100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: doug@wapsyvax.OZ (Doug Robb) Newsgroups: comp.protocols.tcp-ip,comp.sources.wanted Subject: NFS for 4.{2,3} Message-ID: <276@wapsyvax.OZ> Date: Sun, 19-Jul-87 23:59:01 EDT Article-I.D.: wapsyvax.276 Posted: Sun Jul 19 23:59:01 1987 Date-Received: Wed, 22-Jul-87 06:36:47 EDT Organization: Psychology, University of Western Australia Lines: 7 Can anyone tell me if they are aware of or have public domain or cheapish NFS software (al la SUN's) that will run on a 4.{2,3} BSD system. Thanks ARPA net : doug%wapsyvax.oz@seismo.css.gov UUCP : ....!{seismo,mcvax,ucb-vision,uks}!munnari!wacsvax.oz!doug ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707200400.AA24674@PARIS.MIT.EDU] <1987071920001300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: martillo@ATHENA.MIT.EDU Newsgroups: comp.protocols.tcp-ip Subject: Clearpoint Message-ID: <8707200400.AA24674@PARIS.MIT.EDU> Date: Mon, 20-Jul-87 00:00:13 EDT Article-I.D.: PARIS.8707200400.AA24674 Posted: Mon Jul 20 00:00:13 1987 Date-Received: Tue, 21-Jul-87 00:40:25 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 I noticed that some assistance was being to get Wollongong on the net. I was talking to Vinnie Bono who is the President of Clearpoint which makes lots of useful boards for VAXes and other machines. Apparently a lot of Clearpoint clients have net access and he would like to get some access so that he can be more responsive to his clientel. If anyone can give some advice or give some assistance, it would be much appreciated. Yakim Martillo ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987071922530000> Mail-From: STJOHNS created at 20-Jul-87 05:54:35 Date: 20 Jul 1987 05:53-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: Name of NIC (was: twg, and nic not knowing its domain na... From: STJOHNS@SRI-NIC.ARPA To: brescia@CCV.BBN.COM Cc: MKL@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]20-Jul-87 05:53:42.STJOHNS> In-Reply-To: The message of Thu, 16 Jul 87 10:22:20 -0400 from Mike Brescia Guys, to forestall further discussions on this. The name "SRI-NIC.ARPA" is the official name for the NIC now and this is due mostly to historical concerns. At some time in the future (i.e. when I can spare the time to argue the case at the PMO), the NIC will change to something like NIC.DDN.MIL. (No, I don't want naming suggestions just yet thanks!) Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707201046.AA17140@nic.nyser.net] <1987072002464900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: schoff@NIC.NYSER.NET (Martin Lee Schoffstall) Newsgroups: comp.protocols.tcp-ip Subject: Re: Name of NIC (was: twg, and nic not knowing its domain name..) Message-ID: <8707201046.AA17140@nic.nyser.net> Date: Mon, 20-Jul-87 06:46:49 EDT Article-I.D.: nic.8707201046.AA17140 Posted: Mon Jul 20 06:46:49 1987 Date-Received: Tue, 21-Jul-87 04:19:17 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 3 Actually the NOC for the NSFNet is called devvax.tn.cornell.edu. marty ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072003044900> Received: from CC5.BBN.COM by SRI-NIC.ARPA with TCP; Mon 20 Jul 87 06:53:52-PDT To: PADLIPSKY@A.ISI.EDU cc: tcp-ip@SRI-NIC.ARPA, malis@CC5.BBN.COM Subject: Re: Internet Uselessness In-reply-to: Your message of 17 Jul 87 14:44:03 -0400. Date: Mon, 20 Jul 87 09:44:49 -0400 From: Andy Malis Mike, As a whole, I think the internet community has been doing "clever engineering" for quite a number of years now. However, there comes a time when offered load just overwhelms the resources devoted to the task. We are very close to that point on the ARPANET, even though we just made the routing algorithm more "clever" and added another transcontinental trunk. We are currently in the process of implementing congestion control in the PSNs. This should optimize the total available throughput of the network (at the expense of backing flows into source hosts if necessary). Finally, the X.25 spec really says nothing about what goes on in the subnet, it is just an interface spec between a DTE and its DCE. Internally, the PSNs use virtual circuits to support both AHIP (1822) and X.25 traffic while using good old dynamic adaptive routing to get the packets between the endpoint PSNs. Internally, neither AHIP nor X.25 data packets contain full addressing information, just the destination PSN number and a connection identifier at that PSN. So I guess you might say that we "do it right". Cheers, Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707201229.AA06551@saturn.mitre.org] <1987072004290200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lazear@GATEWAY.MITRE.ORG Newsgroups: comp.protocols.tcp-ip Subject: TWG on MILNET? Message-ID: <8707201229.AA06551@saturn.mitre.org> Date: Mon, 20-Jul-87 08:29:02 EDT Article-I.D.: saturn.8707201229.AA06551 Posted: Mon Jul 20 08:29:02 1987 Date-Received: Tue, 21-Jul-87 04:34:41 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 3 Can someone please explain why TWG will be homed on the MILNET instead of the ARPANET? Somewhere the MIL in MILNET must have gotten redefined! Walt Lazear ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[SRI-NIC.ARPA]20-Jul-87.05:53:42.STJOHNS] <1987072004530000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: STJOHNS@SRI-NIC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: Name of NIC (was: twg, and nic not knowing its domain na... Message-ID: <[SRI-NIC.ARPA]20-Jul-87.05:53:42.STJOHNS> Date: Mon, 20-Jul-87 08:53:00 EDT Article-I.D.: <[SRI-NIC.ARPA]20-Jul-87.05:53:42.STJOHNS> Posted: Mon Jul 20 08:53:00 1987 Date-Received: Tue, 21-Jul-87 04:54:17 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 Guys, to forestall further discussions on this. The name "SRI-NIC.ARPA" is the official name for the NIC now and this is due mostly to historical concerns. At some time in the future (i.e. when I can spare the time to argue the case at the PMO), the NIC will change to something like NIC.DDN.MIL. (No, I don't want naming suggestions just yet thanks!) Mhing ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072005055100> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Mon 20 Jul 87 09:28:30-PDT To: Jim Chappell cc: tcp-ip@SRI-NIC.ARPA, brescia@CCV.BBN.COM Subject: Re: Gateway problem In-reply-to: Your message of 19 Jul 87 00:14:26 +0000. <593@ms3.UUCP> Date: Mon, 20 Jul 87 11:45:51 -0400 From: Mike Brescia I have been unable to access the milnet directly from such hosts. /etc/ifconfig ub0 -trailers arp 92.0.0.6 Jim, Ask yourself the following question: How will other hosts on the MILNET, and other gateways farther away, know how to reach net 92? You should go to your provider of operating system software, which you said is 4.2BSD unix, and ask them about configuring the gateway software for this setup. The key to answering the question I posed above is the program which handles the "Exterior Gateway Protocol" (EGP), which should be provided as part of your network software. Also, you need to address the NIC to get a registered network number for your Ungermann-Bass net, as well as an Autonomous System number (related to the EGP). Send your inquiry to 'hostmaster@sri-nic.arpa'. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707201407.AA12061@ucbvax.Berkeley.EDU] <1987072006093200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: malis@CC5.BBN.COM (Andy Malis) Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet Uselessness Message-ID: <8707201407.AA12061@ucbvax.Berkeley.EDU> Date: Mon, 20-Jul-87 10:09:32 EDT Article-I.D.: ucbvax.8707201407.AA12061 Posted: Mon Jul 20 10:09:32 1987 Date-Received: Tue, 21-Jul-87 04:48:48 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 26 Mike, As a whole, I think the internet community has been doing "clever engineering" for quite a number of years now. However, there comes a time when offered load just overwhelms the resources devoted to the task. We are very close to that point on the ARPANET, even though we just made the routing algorithm more "clever" and added another transcontinental trunk. We are currently in the process of implementing congestion control in the PSNs. This should optimize the total available throughput of the network (at the expense of backing flows into source hosts if necessary). Finally, the X.25 spec really says nothing about what goes on in the subnet, it is just an interface spec between a DTE and its DCE. Internally, the PSNs use virtual circuits to support both AHIP (1822) and X.25 traffic while using good old dynamic adaptive routing to get the packets between the endpoint PSNs. Internally, neither AHIP nor X.25 data packets contain full addressing information, just the destination PSN number and a connection identifier at that PSN. So I guess you might say that we "do it right". Cheers, Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [725@hjuxa.UUCP] <1987072007473600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kp@hjuxa.UUCP (Karen Paszamant) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Streams TCP/IP Message-ID: <725@hjuxa.UUCP> Date: Mon, 20-Jul-87 11:47:36 EDT Article-I.D.: hjuxa.725 Posted: Mon Jul 20 11:47:36 1987 Date-Received: Wed, 22-Jul-87 07:24:33 EDT Organization: Digital Equipment Corp. Holmdel, NJ Lines: 6 Keywords: TCP/IP, Streams Does anyone know what vendors have a System V Release 3.0 streams based tcp/ip product? The only vendors I have found so far are Lachman Assoc. & Wollongong. There must be others. Thanks, in advance ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707201633.AA02544@mitre-bedford.ARPA] <1987072008334000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bjp@MITRE-BEDFORD.ARPA Newsgroups: comp.protocols.tcp-ip Subject: SMTP for any UNIX on any kind of AT Message-ID: <8707201633.AA02544@mitre-bedford.ARPA> Date: Mon, 20-Jul-87 12:33:40 EDT Article-I.D.: mitre-be.8707201633.AA02544 Posted: Mon Jul 20 12:33:40 1987 Date-Received: Tue, 21-Jul-87 05:53:27 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 Folks I need some help. Is there anyone out there that has mil stnd simple mail runing on any version of an AT under any version of UNIX? If so, please let me know what versions and the vendors where you bought it, there names addresses and phone numbers. I need the answer by tomorrow afternoon. bj Pease ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707201638.AA14267@ucbvax.Berkeley.EDU] <1987072008410500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@CCV.BBN.COM (Mike Brescia) Newsgroups: comp.protocols.tcp-ip Subject: Re: Gateway problem Message-ID: <8707201638.AA14267@ucbvax.Berkeley.EDU> Date: Mon, 20-Jul-87 12:41:05 EDT Article-I.D.: ucbvax.8707201638.AA14267 Posted: Mon Jul 20 12:41:05 1987 Date-Received: Tue, 21-Jul-87 05:21:21 EDT References: <593@ms3.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 22 I have been unable to access the milnet directly from such hosts. /etc/ifconfig ub0 -trailers arp 92.0.0.6 Jim, Ask yourself the following question: How will other hosts on the MILNET, and other gateways farther away, know how to reach net 92? You should go to your provider of operating system software, which you said is 4.2BSD unix, and ask them about configuring the gateway software for this setup. The key to answering the question I posed above is the program which handles the "Exterior Gateway Protocol" (EGP), which should be provided as part of your network software. Also, you need to address the NIC to get a registered network number for your Ungermann-Bass net, as well as an Autonomous System number (related to the EGP). Send your inquiry to 'hostmaster@sri-nic.arpa'. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707201644.AA02805@mitre-bedford.ARPA] <1987072008444700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bjp@MITRE-BEDFORD.ARPA Newsgroups: comp.protocols.tcp-ip Subject: SMTP for any UNIX on any kind of AT Message-ID: <8707201644.AA02805@mitre-bedford.ARPA> Date: Mon, 20-Jul-87 12:44:47 EDT Article-I.D.: mitre-be.8707201644.AA02805 Posted: Mon Jul 20 12:44:47 1987 Date-Received: Tue, 21-Jul-87 05:58:25 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 11 Folks I need some help. Is there anyone out there that has mil stnd simple mail runing on any version of an AT under any version of UNIX? If so, please let me know what versions and the vendors where you bought it, there names addresses and phone numbers. I need the answer by tomorrow afternoon. bj Pease PS Sorry for the double message but I forgot to give you my email address. Here it is: bjp@mitre-bedford.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707201734.AA07007@saturn.mitre.org] <1987072009345300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lazear@GATEWAY.MITRE.ORG Newsgroups: comp.protocols.tcp-ip Subject: Vendors on MILNET Message-ID: <8707201734.AA07007@saturn.mitre.org> Date: Mon, 20-Jul-87 13:34:53 EDT Article-I.D.: saturn.8707201734.AA07007 Posted: Mon Jul 20 13:34:53 1987 Date-Received: Tue, 21-Jul-87 06:17:22 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 4 I may have missed something somewhere, but I thought MIL-NET had something to do with MIL-itary, production systems, national defense. I must have been reading the glossy brochures again! Oh, I know ... Military-Industrial-Liaison-NET ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707201740.AA07042@saturn.mitre.org] <1987072009400700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lazear@GATEWAY.MITRE.ORG Newsgroups: comp.protocols.tcp-ip Subject: Vendors on MILNET Message-ID: <8707201740.AA07042@saturn.mitre.org> Date: Mon, 20-Jul-87 13:40:07 EDT Article-I.D.: saturn.8707201740.AA07042 Posted: Mon Jul 20 13:40:07 1987 Date-Received: Tue, 21-Jul-87 06:23:35 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 I may have missed something somewhere, but I thought MIL-NET had something to do with MIL-itary, production systems, national defense. I must have been reading the glossy brochures again! Oh, I know ... Military-Industrial-Liaison-NET ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707201852.AA07169@saturn.mitre.org] <1987072010521100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lazear@GATEWAY.MITRE.ORG Newsgroups: comp.protocols.tcp-ip Subject: Re: Vendors on MILNET Message-ID: <8707201852.AA07169@saturn.mitre.org> Date: Mon, 20-Jul-87 14:52:11 EDT Article-I.D.: saturn.8707201852.AA07169 Posted: Mon Jul 20 14:52:11 1987 Date-Received: Wed, 22-Jul-87 00:37:43 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 14 Alan, I would indeed be interested in the details, since there are still parts of DCA touting the eventual closing of the mail bridges and the rehoming of hosts to their proper side. Then there's the issue of dual-homed hosts.... If DCA isn't serious about the architecture they have advertised as the target, then we should eliminate the mail bridges altogether, connect MILNET and ARPANET as one, and improve performance for everyone! Perhaps a changing of the guard at DCA has made past work obsolete, but they need to tell both themselves and the outside world that that is so (if indeed it is so). Walt ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707201919.AA04726@oliver.cray.uucp] <1987072011192600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dab@oliver.cray.COM (Dave Borman) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong telnet and new line processing Message-ID: <8707201919.AA04726@oliver.cray.uucp> Date: Mon, 20-Jul-87 15:19:26 EDT Article-I.D.: oliver.8707201919.AA04726 Posted: Mon Jul 20 15:19:26 1987 Date-Received: Wed, 22-Jul-87 00:44:15 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 47 In reply to William R. King's message, where he is trying to connect to a VAX/VMS system running Wollongong. He claims that when using telnet from a directly connected terminal on his 4.3BSD VAX things would work, but when he was logged into the VAX via a Bridge cs/1 terminal, all of his \r's were turned into \n, which on VMS thought that meant 'delete a word to the left of the cursor'. Bill changed telnet, and belives that it is a pty problem on the VAX. My guess is that it is either a Bridge or a 4.3 telnetd problem, or mayby even a combination of them. When you run telnet, it defaults to single character input, with remote echo. In this mode, every character that comes in from the terminal/pty is passed straight through. Telnet puts the the terminal/pty into CBREAK mode, with ECHO & CRMOD turned OFF. This means that the terminal driver will do no translation between \r and \n. Hence, if a \n is showing up at the VMS node, it must be coming from before the pty, i.e. either from telnetd or dirctly from the Bridge box. Be aware that between 4.2 and 4.3, changes were made to both telnet and telnetd to deal with the \r/\n issue. 4.2 did not conform to the TELNET spec in this area. A simple test that could be done would be to write a short program that puts the terminal into CBREAK mode, and turns off ECHO and CRMOD, and then just dumps it's input in octal. Run that on the 4.3 VAX when logged in from the Bridge box, and see what it sees when you type \r. Then write a dummy server that does the same thing, run it on some other TCP port, and telnet to that alternate port from the Bridge box (assuming it will let you do that...), and see what it says a \r is. If you get "\n" in the first case, and "\r" or "\r\n" in the second case, the problem is in telnetd. If you get "\n" in both cases, then the problem is in the Bridge box. If the 4.3 telnetd is not in binary mode, then "\r\n" will be translated to "\n". If the bridge box is sending "\r\n" when you type "\r", then the 4.3 telnetd is where the translation is taking place. What should be sent is "\r\0", which is the correct sequence to send according to the TELNET spec. (If the 4.3 telnetd is in BINARY mode, then this translation will not take place.) "\r/\n" means "move the cursor to the begining of the next line", usually tranlated to '\n' on UNIX machines, "\r\0" means do a "carriage return", (octal 015) and a '\n' (not preceeded by '\r') means do a "line feed" (octal 012). I hope I've helped to clarify things, not confuse them even more. -Dave Borman, Cray Research, Inc. dab@umn-rei-uc.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [553809435.0.CASNER@VENERA.ISI.EDU] <1987072011571500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CASNER@VENERA.ISI.EDU (Stephen Casner) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong telnet and new line processing Message-ID: <553809435.0.CASNER@VENERA.ISI.EDU> Date: Mon, 20-Jul-87 15:57:15 EDT Article-I.D.: VENERA.553809435.0.CASNER Posted: Mon Jul 20 15:57:15 1987 Date-Received: Wed, 22-Jul-87 01:03:50 EDT References: <25@abvax.icd.ab.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 The TELNET spec (RFC 854, pp. 11-12) says that the line terminator is to be the pair of characters CR-LF (\r\n if you prefer). I have seen problems in both UNIX user telnet (sending just \n) and server telnet (not interpreting \r\n properly). This particular bit of UNIX chauvinism seems to be rather difficult to stamp out. The problem has been discussed on this list more than once in the past. It often comes up when one tries to communicate between a UNIX machine and something else. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707202011.AA03207@phun.riacs.edu] <1987072012272400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: leiner@riacs.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Name of NIC (was: twg, and nic not knowing its domain name..) Message-ID: <8707202011.AA03207@phun.riacs.edu> Date: Mon, 20-Jul-87 16:27:24 EDT Article-I.D.: phun.8707202011.AA03207 Posted: Mon Jul 20 16:27:24 1987 Date-Received: Wed, 22-Jul-87 01:04:36 EDT References: <8707181044.AA15368@icarus.riacs.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Mike, That was the reason for having ORG or NET as a top level domain. Barry ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072012550000> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Tue 21 Jul 87 13:50:02-PDT Received: from YMIR.BITNET by wiscvm.wisc.edu ; Tue, 21 Jul 87 15:47:53 CDT Received: from ENGVAX.SCG.HAC.COM by YMIR.BITNET; Mon, 20 Jul 87 19:58 PDT Date: Mon, 20 Jul 87 19:55 PDT From: Kevin Carosso <@YMIR.BITNET:KVC@ENGVAX.SCG.HAC.COM> Subject: Re: wollongong telnet and new line processing To: tcp-ip@sri-nic.ARPA X-VMS-To: IN%"tcp-ip@sri-nic.arpa" > Unix translate the \r into a \n and sends it across the net > to the VMS machine which promptly deletes the word GUEST. This > makes logging in a little difficult. > I say this because if you are connect to the Unix machine > via a direct line everything works fine. This problem only > occurs when you are connected via a pty. We use Bridge > cs/1 terminal servers almost exclusivly, hence you are always > connected to a pty and never to a direct line. > This leads me to think that the problem lies somewhere in the > pty driver. Anyone have any ideas? > Bill King We had the same problem here, but a different manifestation (couldn't run a local editor or TELNET to a VMS system running CMU IP/TCP). The problem occurs when you connect via TELNET to a 4.3 system and then run any program which reads in raw mode and expects to see EXACTLY the key the user typed. I traced the problem to the fact that "telnetd.c" has the following in it: /* * We map \r\n ==> \n, since \r\n says * that we want to be in column 1 of the next * printable line, and \n is the standard * unix way of saying that (\r is only good * if CRMOD is set, which it normally is). */ if ((myopts[TELOPT_BINARY] == OPT_NO) && c == '\r') { if ((ncc > 0) && ('\n' == *netip)) { netip++; ncc--; c = '\n'; } else { state = TS_CR; } } I don't think it's right to map to . I changed it to map to instead, and everything works just fine. The terminal driver will map the to when necessary and programs that think that are supposed to get a now work fine. My rationale was that the UNIX tty driver is set up to work with terminals that usually send when the user hits "carriage return". A pty works just like a tty, so we should be sending into it. I suppose another approach might be to say that the Bridge TELNET code is broken and that it shouldn't be sending when you type "carriage return" but should send . I can't fix the Bridge code, though. /Kevin Carosso kvc@engvax.scg.hac.com Hughes Aircraft Co. kvc%engvax@oberon.usc.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707202321.AA19800@monk.proteon.com] <1987072015215100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jas@MONK.PROTEON.COM (John A. Shriver) Newsgroups: comp.protocols.tcp-ip Subject: Berkeley (not Wollongong) telnet and new line processing Message-ID: <8707202321.AA19800@monk.proteon.com> Date: Mon, 20-Jul-87 19:21:51 EDT Article-I.D.: monk.8707202321.AA19800 Posted: Mon Jul 20 19:21:51 1987 Date-Received: Wed, 22-Jul-87 02:13:09 EDT References: <25@abvax.icd.ab.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 73 That one is completely Berkeley's fault! The explanation of new line processing is presented with excruciating clarity on pages 11-12 of RFC 854, "Telnet". For reasons unknown to god or man, instead of fixing new line processing between 4.2BSD and 4.3BSD, it got broken worse. (I hope the reason was ignorance, not independence!) There are three "characters" which the Telnet Network Virtual Terminal can encode: netascii function what it means chracters newline go to first column of next line carriage- go to first column of this line return line-feed go to same column in next line Note that most systems only conceive of two of these, since there are only two keys on the keyboard. In user Telnet, you should send when the user types whatever the "doit!" key is on that system. On a VMS system, that would be when the user types . On a UNIX system with "stty -nl", that would be when the user types , although the input stream may have returned ('\n'), depending on how raw the terminal is. On a UNIX system in "stty nl" state (native Teletype model 37), the gets sent when is typed. For the VMS and UNIX "stty -nl" cases, when the user types , you send . Note that there is no simple way for that user to send . In the UNIX "stty nl" case, when the user typed , then you would send . Now for server Telnet. On the VMS system, the server should type when it sees from Telnet. It should also do so when it sees . (To be gracious of goofs like 4.2BSD, it should also accept naked .) Presuming that a UNIX server Telnet would probably always have the psuedo-tty in "stty -nl" mode, it would behave the same. Both of these systems would type when they saw on the Telnet stream. Similar conventions apply to output operations. On UNIX, printf("\n") should send , and printf("\r") should send . On VMS, you just take the VT100 terminal stream, and stuff a after any naked . (VMS allows naked or from an application program.) The user telnet has to sort out the incoming netascii and do the right thing to the terminal. (If the terminal doesn't mind a few s, you can probably send straight netascii.) As always, follow the robustness principle (p.13 RFC 793, "TCP"): be conservative in what you do, be liberal in what you accept from others In Telnet, this poses several corollaries: 1. Generate only legal netascii on a Telnet stream 2. The noraml netascii sequence should be 3. Accept all three netascii sequences on input from Telnet streams 4. Accept degenerate netascii ( not folloed by or ) to cope with broken software ----MESSAGE-END---- ----MESSAGE-BEGIN---- [6482@hc.DSPO.GOV] <1987072016235000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tomlin@hc.DSPO.GOV (Bob Tomlinson) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong TCP/IP for VAX/VMS (Really NRC's Fusion TCP/IP) Message-ID: <6482@hc.DSPO.GOV> Date: Mon, 20-Jul-87 20:23:50 EDT Article-I.D.: hc.6482 Posted: Mon Jul 20 20:23:50 1987 Date-Received: Wed, 22-Jul-87 01:57:09 EDT References: <670@julian.UWO.CDN> Distribution: world Organization: Los Alamos National Laboratory Lines: 20 in article <670@julian.UWO.CDN>, peter@julian.UUCP says: > >> You might also tell DEC about it, since they sell TWG software >>for VMS as the official VAX?VMS TCP/IP product. > > In my last conversation with Digital about this, they said that Digital > had had so much support trouble with The Wollongong Group that they were now > recommending the Fusion product for TCP/IP under VMS. > I suppose that this might be just a Canadian phenomenon. I don't think it's just a Canadian phenomenon. I've heard similar things here. We're using Fusion TCP/IP for VMS here. We mainly use it to communicate with 4.3bsd VAXs and Suns. My main complaint with them now is they don't have a domain name system resolver. Does anybody else out there use Fusion TCP/IP on VMS? bob -- Bob Tomlinson -- tomlin@hc.dspo.gov -- (505) 667-8495 Los Alamos National Laboratory -- MEE-10/Data Systems ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707212110.AA13986@ucbvax.Berkeley.EDU] <1987072018550000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: KVC@ENGVAX.SCG.HAC.COM (Kevin Carosso) Newsgroups: comp.protocols.tcp-ip Subject: Re: wollongong telnet and new line processing Message-ID: <8707212110.AA13986@ucbvax.Berkeley.EDU> Date: Mon, 20-Jul-87 22:55:00 EDT Article-I.D.: ucbvax.8707212110.AA13986 Posted: Mon Jul 20 22:55:00 1987 Date-Received: Thu, 23-Jul-87 04:47:41 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 54 > Unix translate the \r into a \n and sends it across the net > to the VMS machine which promptly deletes the word GUEST. This > makes logging in a little difficult. > I say this because if you are connect to the Unix machine > via a direct line everything works fine. This problem only > occurs when you are connected via a pty. We use Bridge > cs/1 terminal servers almost exclusivly, hence you are always > connected to a pty and never to a direct line. > This leads me to think that the problem lies somewhere in the > pty driver. Anyone have any ideas? > Bill King We had the same problem here, but a different manifestation (couldn't run a local editor or TELNET to a VMS system running CMU IP/TCP). The problem occurs when you connect via TELNET to a 4.3 system and then run any program which reads in raw mode and expects to see EXACTLY the key the user typed. I traced the problem to the fact that "telnetd.c" has the following in it: /* * We map \r\n ==> \n, since \r\n says * that we want to be in column 1 of the next * printable line, and \n is the standard * unix way of saying that (\r is only good * if CRMOD is set, which it normally is). */ if ((myopts[TELOPT_BINARY] == OPT_NO) && c == '\r') { if ((ncc > 0) && ('\n' == *netip)) { netip++; ncc--; c = '\n'; } else { state = TS_CR; } } I don't think it's right to map to . I changed it to map to instead, and everything works just fine. The terminal driver will map the to when necessary and programs that think that are supposed to get a now work fine. My rationale was that the UNIX tty driver is set up to work with terminals that usually send when the user hits "carriage return". A pty works just like a tty, so we should be sending into it. I suppose another approach might be to say that the Bridge TELNET code is broken and that it shouldn't be sending when you type "carriage return" but should send . I can't fix the Bridge code, though. /Kevin Carosso kvc@engvax.scg.hac.com Hughes Aircraft Co. kvc%engvax@oberon.usc.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2482@hoptoad.uucp] <1987072019375200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gnu@hoptoad.uucp (John Gilmore) Newsgroups: comp.protocols.tcp-ip Subject: Re: PD TCP/IP requests Message-ID: <2482@hoptoad.uucp> Date: Mon, 20-Jul-87 23:37:52 EDT Article-I.D.: hoptoad.2482 Posted: Mon Jul 20 23:37:52 1987 Date-Received: Wed, 22-Jul-87 04:31:51 EDT References: <8707161448.AA20895@gateway.mitre.org> Organization: Nebula Consultants in San Francisco Lines: 27 charny@GATEWAY.MITRE.ORG (M. Charny) wrote: > Subject: Re: PD TCP/IP requests > > MITRE is not in the business of distributing or maintaining software. Devices > and software created by MITRE are prototypes created for particular sponsors. > The programs are available to the outside world according to the conditions > and procedures listed below. > -- they agree to the four conditions listed below > (please explicitly list the conditions in the letter). > i. The MITRE TCP/IP source files will not be passed on to > any third party. How can this software be called "public domain" if it can't be passed on? Also, I am interested in who actually owns this software. If it was written on contract for the government, it is owned by the government, as a work for hire. Since the government cannot copyright things it owns, (this is explicit in the Copyright Act), this would mean that the code is in the public domain, and MITRE has no right to put these kind of restrictions on it. I presume that whoever contracted to have MITRE do this work is on the net. Or their DARPA sponsor is on the net. Can you clarify the ownership of the code and the origin of these restrictions? -- {dasys1,ncoast,well,sun,ihnp4}!hoptoad!gnu gnu@postgres.berkeley.edu Alt.all: the alternative radio of the Usenet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707210531.AA06574@aramis.rutgers.edu] <1987072021314800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lear@ARAMIS.RUTGERS.EDU (eliot lear) Newsgroups: comp.protocols.tcp-ip Subject: CRLF stuff Message-ID: <8707210531.AA06574@aramis.rutgers.edu> Date: Tue, 21-Jul-87 01:31:48 EDT Article-I.D.: aramis.8707210531.AA06574 Posted: Tue Jul 21 01:31:48 1987 Date-Received: Wed, 22-Jul-87 05:45:54 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 There is (was?) a definite bug Sun 3.2 in.telnetd where it would send LF when one pressed CR. The bug involved going into state TS_CR (just seen a CR) and then dropping the CR on the floor if the next character was LF. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [553860812.0.PERRY@VAX.DARPA.MIL] <1987072102133200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL (Dennis G. Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: TWG on MILNET? Message-ID: <553860812.0.PERRY@VAX.DARPA.MIL> Date: Tue, 21-Jul-87 06:13:32 EDT Article-I.D.: VAX.553860812.0.PERRY Posted: Tue Jul 21 06:13:32 1987 Date-Received: Wed, 22-Jul-87 06:41:54 EDT References: <8707201229.AA06551@saturn.mitre.org> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 16 I suppose the reason the TWG will be homed on the Milnet instead of the Arpanet is that the sponsor suggested the Milnet. Remember that someone in the government pay for every connection to the Milnet or the Arpanet. The Arpanet cost me about $3500 per port connection per month. I am not sure what the Milnet connections cost. Yes, there is a fuzzing of the lines between Milnet and Arpanet. As turnover at the DDN PMO more and more of the history of the Arpanet and the reason for the split into the Milnet and Arpanet is lost, and therefore the definition of why each exists is lost. A strong tendency exists already to consider them as equal nets, with little distinction between them or little appreciation of what the experimental Arpanet can do for the operational Milnet. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [553862036.0.PERRY@VAX.DARPA.MIL] <1987072102335600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL (Dennis G. Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: Name of NIC (was: twg, and nic not knowing its domain na... Message-ID: <553862036.0.PERRY@VAX.DARPA.MIL> Date: Tue, 21-Jul-87 06:33:56 EDT Article-I.D.: VAX.553862036.0.PERRY Posted: Tue Jul 21 06:33:56 1987 Date-Received: Wed, 22-Jul-87 06:42:28 EDT References: <[SRI-NIC.ARPA]20-Jul-87.05:53:42.STJOHNS> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 Mike, who you gonna argue with? It seems to me that you should just write the memo to the Col and say here we what we are going to do and when and why. No one else cares about what the NIC is called. I will help you with the Col if you want it. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [649@houxa.UUCP] <1987072105082000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mel1@houxa.UUCP (M.HAAS) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <649@houxa.UUCP> Date: Tue, 21-Jul-87 09:08:20 EDT Article-I.D.: houxa.649 Posted: Tue Jul 21 09:08:20 1987 Date-Received: Thu, 23-Jul-87 03:19:39 EDT References: <725@hjuxa.UUCP> Organization: AT&T Bell Laboratories, Holmdel Lines: 8 Keywords: TCP/IP, Streams Summary: Why STREAMS ? Would someone please post a summary of reasons why use of Streams is an advantage. Is this just another sales-hype buzzword? or is there a reason Streams is better? than sockets? than psudo-sockets? or select? Does the end user see any advantage? faster response? less CPU waste? what? Does anyone have some before & after figures on drivers that were converted to Streams? Please share them with us. Thanks, Mel Haas , odyssey!mel ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072105314200> Received: from CC5.BBN.COM by SRI-NIC.ARPA with TCP; Tue 21 Jul 87 09:13:46-PDT To: Michael Padlipsky cc: Andy Malis , tcp-ip@SRI-NIC.ARPA, malis@CC5.BBN.COM Subject: Re: Internet Uselessness In-reply-to: Your message of 21 Jul 87 10:03:10 -0400. Date: Tue, 21 Jul 87 12:11:42 -0400 From: Andy Malis Mike, Your impression is correct: many X.25 networks (e.g. TELENET) set up a path at call setup time and then force all packets along that fixed path, just using the VC number for identification. Your inference is also correct: in BBNCC networks, the same underlying packet format (and dynamic adaptive routing) is used for both AHIP and X.25 traffic. If you are interested in the workings of the backbone subnet, you might like to read my RFC 979. It is the functional specification for the PSN's new End-to-End protocol, which is being implemented in PSN 7.0 (PSN 6.0 is now running in the subnet). My statement above concerning packet formats and routing is true for both the existing and the new EEs. Cheers, Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707211353.AA05661@ucbvax.Berkeley.EDU] <1987072105373200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dpowles@CCD.BBN.COM ("Drew M. Powles") Newsgroups: comp.protocols.tcp-ip Subject: RLP Message-ID: <8707211353.AA05661@ucbvax.Berkeley.EDU> Date: Tue, 21-Jul-87 09:37:32 EDT Article-I.D.: ucbvax.8707211353.AA05661 Posted: Tue Jul 21 09:37:32 1987 Date-Received: Wed, 22-Jul-87 07:31:15 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Does anyone out there have an implementation of, or at least any experience with, the Resource Location Protocol, as described in RFC 887, dated December 1983? thanks for the help. Drew M. Powles BBN Communication dpowles@ccd.bbn.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072105373201> Received: from ccd.bbn.com by SRI-NIC.ARPA with TCP; Tue 21 Jul 87 06:39:37-PDT Date: Tue, 21 Jul 87 09:37:32 EDT From: "Drew M. Powles" Subject: RLP To: tcp-ip@sri-nic.arpa Cc: dpowles@ccd.bbn.com Does anyone out there have an implementation of, or at least any experience with, the Resource Location Protocol, as described in RFC 887, dated December 1983? thanks for the help. Drew M. Powles BBN Communication dpowles@ccd.bbn.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072105374100> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Tue 21 Jul 87 03:05:53-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA02577; Tue, 21 Jul 87 02:42:28 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Jul 87 05:37:41 GMT From: ejnorman@unix.macc.wisc.edu (Eric Norman) Organization: UW-Madison Academic Computer Center Subject: Re: Berkeley (not Wollongong) telnet and new line processing Message-Id: <1747@uwmacc.UUCP> References: <25@abvax.icd.ab.com>, <8707202321.AA19800@monk.proteon.com> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa John A. Shriver explains: > In user Telnet, you should send when the user types whatever > the "doit!" key is on that system. On a VMS system, that would be What has always bothered me about RFC 854, et al. is that there is a clear statement of the physical effect that CR's and LF's have on the printer of a NVT. However, I can see no clear statement that the sequence CR-LF means "it's your turn now". This is muddied by the fact that there is a "go ahead" signal, but it's not necessary. I look at it this way, which seems to agree with what John suggests. I have a keyboard here that I push keys on. When I push a key, one or more characters are sent off to some computer over some wires. When I push the key labelled "return", something happens so that I get a response from the computer on the other end. If back-to-back NVT's are spliced into the wire between my keyboard and that computer, I would hope that that behavior doesn't change. Eric Norman Internet: ejnorman@unix2.macc.wisc.edu UUCP: ...{allegra,ihnp4,seismo}!uwvax!ejnorman Life: Detroit!Alexandria!Omaha!Indianapolis!Madison!Hyde "Forest fires prevent bears." -- bumper sticker -- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707211409.AA05844@ucbvax.Berkeley.EDU] <1987072105562800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dpowles@CCD.BBN.COM ("Drew M. Powles") Newsgroups: comp.protocols.tcp-ip Subject: SMTP question Message-ID: <8707211409.AA05844@ucbvax.Berkeley.EDU> Date: Tue, 21-Jul-87 09:56:28 EDT Article-I.D.: ucbvax.8707211409.AA05844 Posted: Tue Jul 21 09:56:28 1987 Date-Received: Wed, 22-Jul-87 07:32:49 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 14 This may sound like a silly question, but believe me, I have a need. In going through the SMTP spec, there doesn't seem to be any provision for embedding full octets in the body of the message, only seven bit ascii. Is this an artificial limitation? What if I want to use special characters embedded in my text? TCP does provide an eight-bit byte interface. Does anyone have any thoughts or experiences along these lines they could share with me? thanks. Drew M. Powles BBN Communications dpowles@ccd.bbn.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072105562801> Received: from ccd.bbn.com by SRI-NIC.ARPA with TCP; Tue 21 Jul 87 06:59:27-PDT Date: Tue, 21 Jul 87 09:56:28 EDT From: "Drew M. Powles" Subject: SMTP question To: tcp-ip@sri-nic.arpa Cc: dpowles@ccd.bbn.com This may sound like a silly question, but believe me, I have a need. In going through the SMTP spec, there doesn't seem to be any provision for embedding full octets in the body of the message, only seven bit ascii. Is this an artificial limitation? What if I want to use special characters embedded in my text? TCP does provide an eight-bit byte interface. Does anyone have any thoughts or experiences along these lines they could share with me? thanks. Drew M. Powles BBN Communications dpowles@ccd.bbn.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707211421.AA06017@ucbvax.Berkeley.EDU] <1987072106031000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet Uselessness Message-ID: <8707211421.AA06017@ucbvax.Berkeley.EDU> Date: Tue, 21-Jul-87 10:03:10 EDT Article-I.D.: ucbvax.8707211421.AA06017 Posted: Tue Jul 21 10:03:10 1987 Date-Received: Thu, 23-Jul-87 01:47:29 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 21 Andy-- I certainly did NOT mean to imply that we aren't doing good engineering, merely that a bit more ruthlessness in extreme situations (which I attempted to euphemize as "clever engineering") might be in order. No intention whatsoever to minimize the efforts of the BBN troops who keep the subnet going, whom I don't recall picking on since '71, when the IMP's support for halfduplex interfaces wasn't as advertized. (Horror Story Number Five involved TENEX, of course, but that's not the subnet.) Will be looking forward to the forthcoming congestion control stuff. A quibble over "addressing information": any packet that contains the destination PSN number is addressed enough for me. My impression was (indeed, still is), though, that many/most X.25 subnets use the interface format with just the VC number for packets in flight. I'd be relieved to learn I'm wrong in general, and am delighted to infer from your msg that that isn't how it's done on our backbone. cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072106031001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 21 Jul 87 07:04:48-PDT Date: 21 Jul 1987 10:03:10 EDT Subject: Re: Internet Uselessness From: Michael Padlipsky To: Andy Malis cc: PADLIPSKY@A.ISI.EDU, tcp-ip@SRI-NIC.ARPA In-Reply-To: (Message from "Andy Malis " of Mon, 20 Jul 87 09:44:49 -0400) Andy-- I certainly did NOT mean to imply that we aren't doing good engineering, merely that a bit more ruthlessness in extreme situations (which I attempted to euphemize as "clever engineering") might be in order. No intention whatsoever to minimize the efforts of the BBN troops who keep the subnet going, whom I don't recall picking on since '71, when the IMP's support for halfduplex interfaces wasn't as advertized. (Horror Story Number Five involved TENEX, of course, but that's not the subnet.) Will be looking forward to the forthcoming congestion control stuff. A quibble over "addressing information": any packet that contains the destination PSN number is addressed enough for me. My impression was (indeed, still is), though, that many/most X.25 subnets use the interface format with just the VC number for packets in flight. I'd be relieved to learn I'm wrong in general, and am delighted to infer from your msg that that isn't how it's done on our backbone. cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707211635.AA08210@ucbvax.Berkeley.EDU] <1987072108382400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: malis@CC5.BBN.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet Uselessness Message-ID: <8707211635.AA08210@ucbvax.Berkeley.EDU> Date: Tue, 21-Jul-87 12:38:24 EDT Article-I.D.: ucbvax.8707211635.AA08210 Posted: Tue Jul 21 12:38:24 1987 Date-Received: Thu, 23-Jul-87 01:34:08 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 Mike, Your impression is correct: many X.25 networks (e.g. TELENET) set up a path at call setup time and then force all packets along that fixed path, just using the VC number for identification. Your inference is also correct: in BBNCC networks, the same underlying packet format (and dynamic adaptive routing) is used for both AHIP and X.25 traffic. If you are interested in the workings of the backbone subnet, you might like to read my RFC 979. It is the functional specification for the PSN's new End-to-End protocol, which is being implemented in PSN 7.0 (PSN 6.0 is now running in the subnet). My statement above concerning packet formats and routing is true for both the existing and the new EEs. Cheers, Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707211638.AA24272@topaz.rutgers.edu] <1987072108384700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: SMTP for any UNIX on any kind of AT Message-ID: <8707211638.AA24272@topaz.rutgers.edu> Date: Tue, 21-Jul-87 12:38:47 EDT Article-I.D.: topaz.8707211638.AA24272 Posted: Tue Jul 21 12:38:47 1987 Date-Received: Thu, 23-Jul-87 01:30:30 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 3 IBM has an implementation of POP 2 for the IBM PC. It's part of their TCP/IP support for the PC. This is probably as close as you will come to SMTP for a PC. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [553884192.0.PERRY@VAX.DARPA.MIL] <1987072108431200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL (Dennis G. Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: Vendors on MILNET Message-ID: <553884192.0.PERRY@VAX.DARPA.MIL> Date: Tue, 21-Jul-87 12:43:12 EDT Article-I.D.: VAX.553884192.0.PERRY Posted: Tue Jul 21 12:43:12 1987 Date-Received: Thu, 23-Jul-87 03:52:24 EDT References: <8707201734.AA07007@saturn.mitre.org> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Actually, the Milnet and Arpanet used to be the same net. They were split some time ago into the Arpanet, mostly university researchers, and the Milnet, mostly government agencies, not all of which were military. E.g., the DOE national labs are on the milnet. Not all those on the Milnet are operational folks, although most are. There are still a lot of research related folks on the Milnet. As I said earlier, it it no longer clear, except for sponsorship, who get put where. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707211726.AA02071@braden.isi.edu] <1987072109263600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@BRADEN.ISI.EDU (Bob Braden) Newsgroups: comp.protocols.tcp-ip Subject: Re: 4.3 IP multicast Message-ID: <8707211726.AA02071@braden.isi.edu> Date: Tue, 21-Jul-87 13:26:36 EDT Article-I.D.: braden.8707211726.AA02071 Posted: Tue Jul 21 13:26:36 1987 Date-Received: Thu, 23-Jul-87 03:56:13 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 44 From YAKOV@IBM.COM Mon Jul 20 22:32:50 1987 Posted-Date: 20 July 1987, 09:53:11 EDT Received-Date: Mon, 20 Jul 87 22:32:38 PDT Received: from ibm.com by braden.isi.edu (5.54/5.51) id AA01617; Mon, 20 Jul 87 22:32:38 PDT Date: 20 July 1987, 09:53:11 EDT From: Jacob Rekhter To: braden@braden.isi.edu Message-Id: <072087.095311.yakov@ibm.com> Subject: 4.3 IP multicast Status: R Recently you mentioned, that 4.3 BSD IP multicast is available. How can I get it ? Jacob Rekhter (YAKOV @ IBM.COM) The IP Multicasting extensions described in RFC988 have been implemented for 4.3bsd Unix by Karen Lam of BBN Labs. This software is available for experimental purposes to sites that have 4.3bsd source code. In addition to full support for the RFC988 extensions, the software includes a prototype "multicast agent" demon which enables a Unix host to act as an inter-network relay for IP multicast packets, and a version of Berkeley's "rwhod" that uses multicast instead of broadcast datagrams. To obtain the software, a site will have to sign a licence with BBN certifying that they possess a 4.3bsd source license. The software is distributed on a 1600bpi tar tape and comes with printed installation and usage notes. Interested parties should contact Craig Partridge (craig@bbn.com or craig@nnsc.nsf.net). It is important to note that the internetwork multicasting protocols are still under development and subject to change. Sites that obtain the software are urged to contact Steve Deering at Stanford University (deering@pescadero.stanford.edu) who maintains a mailing list for bug reports, updates, and discussion of changes to the multicast software and protocols. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707211807.AA09192@mitre.arpa] <1987072110072300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA (H. Craig McKee) Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet Uselessness Message-ID: <8707211807.AA09192@mitre.arpa> Date: Tue, 21-Jul-87 14:07:23 EDT Article-I.D.: mitre.8707211807.AA09192 Posted: Tue Jul 21 14:07:23 1987 Date-Received: Thu, 23-Jul-87 04:22:06 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The MITRE Corp., Washington, D.C. Lines: 41 >As a whole, I think the internet community has been doing "clever >engineering" for quite a number of years now. However, there >comes a time when offered load just overwhelms the resources >devoted to the task. We are very close to that point on the >ARPANET, even though we just made the routing algorithm more >"clever" and added another transcontinental trunk. COMMENT: "Clever Engineering" - The ARPANET has been around for 17 Years and there is still a need for clever engineering; that's discouraging. >We are currently in the process of implementing congestion >control in the PSNs. This should optimize the total available >throughput of the network (at the expense of backing flows into >source hosts if necessary). COMMENT: With about a hundred different flavors of TCP/IP, some (many?) of which are network-hostile, the subscriber community is forcing the ARPANET designers to defend themselves. >Finally, the X.25 spec really says nothing about what goes on in >the subnet, it is just an interface spec between a DTE and its >DCE. Internally, the PSNs use virtual circuits to support both >AHIP (1822) and X.25 traffic while using good old dynamic >adaptive routing to get the packets between the endpoint PSNs. >Internally, neither AHIP nor X.25 data packets contain full >addressing information, just the destination PSN number and a >connection identifier at that PSN. So I guess you might say that >we "do it right". COMMENT: I didn't say it, Andy Malis said it: "...PSNs use virtual circuits ... packets [DO NOT] contain full addressing information." Then why are we flogging the network 40 octets of header per packet? Isn't it time to swallow our embarrassment and admit that while TCP/IP looks good on paper, in the reality of limited bandwidth and unstable network delays, TCP/IP is, in fact, a Bad Idea? The subscriber and network communities need to work together and come up with a scheme that doesn't hammer the network to its knees when something goes wrong. The Commercial/PTT networks can do it, why can't we? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072110111200> Received: from CC5.BBN.COM by SRI-NIC.ARPA with TCP; Tue 21 Jul 87 14:00:39-PDT To: "H. Craig McKee" cc: Andy Malis , PADLIPSKY@A.ISI.EDU, tcp-ip@SRI-NIC.ARPA Subject: Re: Internet Uselessness In-reply-to: Your message of Tue, 21 Jul 87 14:07:23 -0400. <8707211807.AA09192@mitre.arpa> Date: Tue, 21 Jul 87 16:51:12 -0400 From: Andy Malis Craig, I would like to respond to a couple of points in your message. On the need for "clever engineering", and defending the ARPANET: for all of its sophistication, the PSN's dynamic routing algorithm was originally designed for, and worked very well in, an environment where the offered load did not come close to congesting the network's resources. This is no longer the case, with network subnet congestion as the predictable result. The recent changes in routing are actually slight modifications to one part of the algorithm, to try to prevent routing oscillations as a result of congested paths and to make the cross-country satellite link more attractive when the land lines start congesting. As Steve Cohn said in a previous message, a more detailed description of the change, and its effects, will be forthcoming. Congestion control will further help the network in these days of plentiful load and scarce resources. I really don't see what we are doing as defending ourselves from network-hostile hosts; rather, we are trying to allocate scarce resources as fairly and evenly as possible, and trying to keep the network from going past the point where additional load would cause the network's total throughput to start degrading. Of course, that doesn't mean that there aren't "hostile" hosts out there. On 40 octets of header per packets: I was referring to the internals of the ARPANET and MILNET subnets when I was discussing packet headers and such. However, they are only two networks on an internet of over 100 networks now. I am not a TCP/IP implementer so I won't get into whether any of the 40 octets can be squeezed out; you just have to realize that the environment TCP/IP runs in is nothing like that of commercial and PTT networks. X.25 does internetting (X.75) using fixed routes though transit networks and X.75 gateways without an end-to-end transport layer like TCP, and is nowhere as reliable and survivable as the TCP/IP internet. But you have to pay for this by using large datagram headers and end-to-end retransmissions. I do agree that some of the assumptions that were made during the TCP/IP design days (such as a richly configured backbone network) may no longer be valid. It may be time to revisit TCP/IP's design, especially in light of the OSI protocol suite, just as long as we keep in mind the overall requirements of the internet. Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707212125.AA14211@ucbvax.Berkeley.EDU] <1987072113285300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: malis@CC5.BBN.COM (Andy Malis) Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet Uselessness Message-ID: <8707212125.AA14211@ucbvax.Berkeley.EDU> Date: Tue, 21-Jul-87 17:28:53 EDT Article-I.D.: ucbvax.8707212125.AA14211 Posted: Tue Jul 21 17:28:53 1987 Date-Received: Thu, 23-Jul-87 04:47:53 EDT References: <8707211807.AA09192@mitre.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 50 Craig, I would like to respond to a couple of points in your message. On the need for "clever engineering", and defending the ARPANET: for all of its sophistication, the PSN's dynamic routing algorithm was originally designed for, and worked very well in, an environment where the offered load did not come close to congesting the network's resources. This is no longer the case, with network subnet congestion as the predictable result. The recent changes in routing are actually slight modifications to one part of the algorithm, to try to prevent routing oscillations as a result of congested paths and to make the cross-country satellite link more attractive when the land lines start congesting. As Steve Cohn said in a previous message, a more detailed description of the change, and its effects, will be forthcoming. Congestion control will further help the network in these days of plentiful load and scarce resources. I really don't see what we are doing as defending ourselves from network-hostile hosts; rather, we are trying to allocate scarce resources as fairly and evenly as possible, and trying to keep the network from going past the point where additional load would cause the network's total throughput to start degrading. Of course, that doesn't mean that there aren't "hostile" hosts out there. On 40 octets of header per packets: I was referring to the internals of the ARPANET and MILNET subnets when I was discussing packet headers and such. However, they are only two networks on an internet of over 100 networks now. I am not a TCP/IP implementer so I won't get into whether any of the 40 octets can be squeezed out; you just have to realize that the environment TCP/IP runs in is nothing like that of commercial and PTT networks. X.25 does internetting (X.75) using fixed routes though transit networks and X.75 gateways without an end-to-end transport layer like TCP, and is nowhere as reliable and survivable as the TCP/IP internet. But you have to pay for this by using large datagram headers and end-to-end retransmissions. I do agree that some of the assumptions that were made during the TCP/IP design days (such as a richly configured backbone network) may no longer be valid. It may be time to revisit TCP/IP's design, especially in light of the OSI protocol suite, just as long as we keep in mind the overall requirements of the internet. Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707212203.a004399@Huey.UDEL.EDU] <1987072118034400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong telnet and new line processing Message-ID: <8707212203.a004399@Huey.UDEL.EDU> Date: Tue, 21-Jul-87 22:03:44 EDT Article-I.D.: Huey.8707212203.a004399 Posted: Tue Jul 21 22:03:44 1987 Date-Received: Thu, 23-Jul-87 07:11:30 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 11 Steve, Well, the annual raucus caucus over the TELNET new-line convention has come around again, exactly a year after the previous one, which itself was the latest in the annual series. last year it was Ford Research squawking that Wollongongware did not love fuzzballs. Subsequently, the Wollongongbunch responded to the complaint and fixed the problem. The present instance suggests the gongfermers should be called. You may look up that interesting word in a dictionary. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [230570.870721.JBVB@AI.AI.MIT.EDU] <1987072119165600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: SMTP for any UNIX on any kind of AT Message-ID: <230570.870721.JBVB@AI.AI.MIT.EDU> Date: Tue, 21-Jul-87 23:16:56 EDT Article-I.D.: AI.230570.870721.JBVB Posted: Tue Jul 21 23:16:56 1987 Date-Received: Thu, 23-Jul-87 07:13:18 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 IBM has an implementation of POP 2 for the IBM PC. It's part of their TCP/IP support for the PC. This is probably as close as you will come to SMTP for a PC. FTP Software has SMTP client and server in the PC/TCP (DOS) package. I don't know a great deal about the various Xenix offerings, but I don't think any of those currently available has SMTP. jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [230575.870721.JBVB@AI.AI.MIT.EDU] <1987072119343400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Streams TCP/IP Message-ID: <230575.870721.JBVB@AI.AI.MIT.EDU> Date: Tue, 21-Jul-87 23:34:34 EDT Article-I.D.: AI.230575.870721.JBVB Posted: Tue Jul 21 23:34:34 1987 Date-Received: Thu, 23-Jul-87 07:13:29 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Spider Systems, Edinburgh, U.K. lists one in the current printing of the Vandors Guide, and I believe it is available in source form. Beyond that, I know nothing about it. jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [517@bpa.BELL-ATL.COM] <1987072203182100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: espo@bpa.BELL-ATL.COM (Bob Esposito) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <517@bpa.BELL-ATL.COM> Date: Wed, 22-Jul-87 07:18:21 EDT Article-I.D.: bpa.517 Posted: Wed Jul 22 07:18:21 1987 Date-Received: Fri, 24-Jul-87 02:52:39 EDT References: <725@hjuxa.UUCP> Reply-To: espo@bpa.UUCP (Bob Esposito) Organization: Bell of Penna., Phila. Lines: 19 Keywords: TCP/IP, Streams In article <725@hjuxa.UUCP> kp@hjuxa.UUCP (Karen Paszamant) writes: > >Does anyone know what vendors have a System V Release 3.0 >streams based tcp/ip product? The only vendors I have found >so far are Lachman Assoc. & Wollongong. There must be others. > >Thanks, in advance Uniq Digital Technologies in Batavia, IL. does have a Streams based TCP/IP product for System V Release 3.0 They advertise being the leading supplier for AT&T System V.3 with RFS for Digital Equipment Corp. processors. -- ===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-=== Bob Esposito, Bell of Pennsylvania - espo@bpa.bell-atl.com - (215) 466-6831 ===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-=== ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707221308.AA29050@ucbvax.Berkeley.EDU] <1987072204270100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: pogran@CCQ.BBN.COM (Ken Pogran) Newsgroups: comp.protocols.tcp-ip Subject: Re: Berkeley (not Wollongong) telnet and new line processing Message-ID: <8707221308.AA29050@ucbvax.Berkeley.EDU> Date: Wed, 22-Jul-87 08:27:01 EDT Article-I.D.: ucbvax.8707221308.AA29050 Posted: Wed Jul 22 08:27:01 1987 Date-Received: Fri, 24-Jul-87 04:18:56 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 27 John, Your elucidation of the handling of line-termination characters in TELNET is the best I've seen in a long time; congratulations! On the other hand, it's unfortunate that after so many years it still needs to be explained! TELNET's careful handling of the various line-termination possibilities is one of the "great compromises" of the relatively early days of the ARPANET (the bit-serial 1822 interface, accomodating computers with the bewildering array of word sizes found in late '60s - early '70s machines, being another). It arose through the efforts of the IBM EBCDIC-newline-physical- half-duplex, Multics LF-is-newline (from which UNIX got its idea of newline) and various DEC (and other) you-CR-and-I'll-echo-the-LF camps to develop something that would work for everyone and that was easily converted at each end of the connection. That different systems STILL have different conventions (UNIX vs VMS, for example) after all this time underscores the importance of the TELNET ASCII compromise -- as well as the importance of implementing it correctly. Thanks, John, for your explanation. Regards, Ken Pogran ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072204270101> Received: from ccq.bbn.com by SRI-NIC.ARPA with TCP; Wed 22 Jul 87 06:04:27-PDT Date: Wed, 22 Jul 87 8:27:01 EDT From: Ken Pogran Subject: Re: Berkeley (not Wollongong) telnet and new line processing In-Reply-To: Your message of Mon, 20 Jul 87 19:21:51 EDT To: jas@monk.proteon.com Cc: tcp-ip@sri-nic.arpa John, Your elucidation of the handling of line-termination characters in TELNET is the best I've seen in a long time; congratulations! On the other hand, it's unfortunate that after so many years it still needs to be explained! TELNET's careful handling of the various line-termination possibilities is one of the "great compromises" of the relatively early days of the ARPANET (the bit-serial 1822 interface, accomodating computers with the bewildering array of word sizes found in late '60s - early '70s machines, being another). It arose through the efforts of the IBM EBCDIC-newline-physical- half-duplex, Multics LF-is-newline (from which UNIX got its idea of newline) and various DEC (and other) you-CR-and-I'll-echo-the-LF camps to develop something that would work for everyone and that was easily converted at each end of the connection. That different systems STILL have different conventions (UNIX vs VMS, for example) after all this time underscores the importance of the TELNET ASCII compromise -- as well as the importance of implementing it correctly. Thanks, John, for your explanation. Regards, Ken Pogran ----MESSAGE-END---- ----MESSAGE-BEGIN---- [499@atlas.UUCP] <1987072204313500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jjensen@atlas.UUCP (Jim Jensen) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong telnet and new line processing Message-ID: <499@atlas.UUCP> Date: Wed, 22-Jul-87 08:31:35 EDT Article-I.D.: atlas.499 Posted: Wed Jul 22 08:31:35 1987 Date-Received: Fri, 24-Jul-87 06:43:12 EDT References: <25@abvax.icd.ab.com> Organization: Gould CSD, Fort Lauderdale, FL Lines: 50 in article <25@abvax.icd.ab.com>, wrk@abvax.icd.ab.com (William R. King) says: > > I've been tyring to get our BSD 4.3 VAX to talk to a VAX/VMS > system using Wollongong telnet and have discovered an interesting > problem. Unix uses \n as the line terminator, >[deleted about sending a \r to VMS] > Unix translate the \r into a \n and sends it across the net > [problems this causes on VMS deleted] > I've modified telnet to send a \r instead of a \n for the line > terminator. Although I think this is only a work around. > > I say this because if you are connect to the Unix machine > via a direct line everything works fine. This problem only > occurs when you are connected via a pty. We use Bridge > cs/1 terminal servers almost exclusivly, hence you are always > connected to a pty and never to a direct line. > (this is my first posting so I dont know if I am doing this right) I just finished writing telnet for MPX (Gould's real time OS), and ran into the same problem. The bridge box sends a \r\n which is the specifed in the telnet rfc as the end of line character. which the unix telnet server turns into a \n. on telnet 4.2 the telnet task, converts this back to \r\n which the VMS(or MPX)server converts back to a \r and everything works. 4.3 leaves it as a \n, which seems to me to be a clear violation of the protocol. The rfc SAYS that \r\n is the end of line character, not \n. Thats what protocols are for; To take care of differences between machines. When a protocol is not followed problems like this happen. I asked one of our unix people about it, and he said that BSD did it on purpose, and it is in telnet. I was unable to convince him it was a mistake, so he would not change it. that is until some people in our unix group tried to use a bridge box. Thus: the latest patch to Gould Unix has a telnetd which has a variable that can be set called Telnet_with_a_bridge_box(if I remember correctly) that if set fixes the problem. I am not a unix person, so I may have gotten something wrong about unix, but I don't think so. Jim Jensen Gould inc. CSD 6901 West Sunrise Boulevard Ft. Lauderdale Fl 33313-4499 (305) 587-2900 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [501@atlas.UUCP] <1987072204391800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jjensen@atlas.UUCP (Jim Jensen) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong telnet and new line processing Message-ID: <501@atlas.UUCP> Date: Wed, 22-Jul-87 08:39:18 EDT Article-I.D.: atlas.501 Posted: Wed Jul 22 08:39:18 1987 Date-Received: Fri, 24-Jul-87 06:43:24 EDT References: <25@abvax.icd.ab.com> Organization: Gould CSD, Fort Lauderdale, FL Lines: 49 in article <25@abvax.icd.ab.com>, wrk@abvax.icd.ab.com (William R. King) says: > > I've been tyring to get our BSD 4.3 VAX to talk to a VAX/VMS > system using Wollongong telnet and have discovered an interesting > problem. Unix uses \n as the line terminator, >[deleted about sending a \r to VMS] > Unix translate the \r into a \n and sends it across the net > [problems this causes on VMS deleted] > I've modified telnet to send a \r instead of a \n for the line > terminator. Although I think this is only a work around. > > I say this because if you are connect to the Unix machine > via a direct line everything works fine. This problem only > occurs when you are connected via a pty. We use Bridge > cs/1 terminal servers almost exclusivly, hence you are always > connected to a pty and never to a direct line. > (this is my first posting so I dont know if I am doing this right) I just finished writing telnet for MPX (Gould's real time OS), and ran into the same problem. The bridge box sends a \r\n which is the specifed in the telnet rfc as the end of line character. which the unix telnet server turns into a \n. on telnet 4.2 the telnet task, converts this back to \r\n which the VMS(or MPX)server converts back to a \r and everything works. 4.3 leaves it as a \n, which seems to me to be a clear violation of the protocol. The rfc SAYS that \r\n is the end of line character, not \n. Thats what protocols are for; To take care of differences between machines. When a protocol is not followed problems like this happen. I asked one of our unix people about it, and he said that BSD did it on purpose, and it is in telnet. I was unable to convince him it was a mistake, so he would not change it. that is until some people in our unix group tried to use a bridge box. Thus: the latest patch to Gould Unix has a telnetd which has a variable that can be set called Telnet_with_a_bridge_box(if I remember correctly) that if set fixes the problem. I am not a unix person, so I may have gotten something wrong about unix, but I don't think so. Jim Jensen Gould inc. CSD 6901 West Sunrise Boulevard Ft. Lauderdale Fl 33313-4499 (305) 587-2900 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [504@atlas.UUCP] <1987072204563700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jjensen@atlas.UUCP (Jim Jensen) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong telnet and new line processing Message-ID: <504@atlas.UUCP> Date: Wed, 22-Jul-87 08:56:37 EDT Article-I.D.: atlas.504 Posted: Wed Jul 22 08:56:37 1987 Date-Received: Fri, 24-Jul-87 06:43:59 EDT References: <25@abvax.icd.ab.com> Organization: Gould CSD, Fort Lauderdale, FL Lines: 49 Keywords: Wollongong telnet BSD4.3 Summary: BSD 4.3 new line processing and VMS in article <25@abvax.icd.ab.com>, wrk@abvax.icd.ab.com (William R. King) says: > > I've been tyring to get our BSD 4.3 VAX to talk to a VAX/VMS > system using Wollongong telnet and have discovered an interesting > problem. Unix uses \n as the line terminator, >[deleted about sending a \r to VMS] > Unix translate the \r into a \n and sends it across the net > [problems this causes on VMS deleted] > I've modified telnet to send a \r instead of a \n for the line > terminator. Although I think this is only a work around. > > I say this because if you are connect to the Unix machine > via a direct line everything works fine. This problem only > occurs when you are connected via a pty. We use Bridge > cs/1 terminal servers almost exclusivly, hence you are always > connected to a pty and never to a direct line. > (this is my first posting so I dont know if I am doing this right) I just finished writing telnet for MPX (Gould's real time OS), and ran into the same problem. The bridge box sends a \r\n which is the specifed in the telnet rfc as the end of line character. which the unix telnet server turns into a \n. on telnet 4.2 the telnet task, converts this back to \r\n which the VMS(or MPX)server converts back to a \r and everything works. 4.3 leaves it as a \n, which seems to me to be a clear violation of the protocol. The rfc SAYS that \r\n is the end of line character, not \n. Thats what protocols are for; To take care of differences between machines. When a protocol is not followed problems like this happen. I asked one of our unix people about it, and he said that BSD did it on purpose, and it is in telnet. I was unable to convince him it was a mistake, so he would not change it. that is until some people in our unix group tried to use a bridge box. Thus: the latest patch to Gould Unix has a telnetd which has a variable that can be set called Telnet_with_a_bridge_box(if I remember correctly) that if set fixes the problem. I am not a unix person, so I may have gotten something wrong about unix, but I don't think so. Jim Jensen Gould inc. CSD 6901 West Sunrise Boulevard ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707221453.AA00603@ucbvax.Berkeley.EDU] <1987072206284500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet Uselessness Message-ID: <8707221453.AA00603@ucbvax.Berkeley.EDU> Date: Wed, 22-Jul-87 10:28:45 EDT Article-I.D.: ucbvax.8707221453.AA00603 Posted: Wed Jul 22 10:28:45 1987 Date-Received: Fri, 24-Jul-87 04:46:43 EDT References: <8707211807.AA09192@mitre.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 51 H. Craig-- Just to show the unbelievers that there are some windmills even I won't bother to lance, I'll merely answer your final rhetorical question ("The Commercial/PTT networks can do it, why can't we?"): As I understand the "it" John and Andy and I were talking about, it's dealing with presented loads greater than a system was designed to deal with; if you really think the PTTs know how to get five pounds of bits in a two-pound sack, I hope you'll share your knowledge with us all. In other words, if it's physically impossible, even we can't do it--but neither can They.... It would be too Zen to get into the subtleties of the flavor of pie in the sky vs. the taste of bread in the mouth, but I would feel myself remiss if I didn't mention that I've been aware of pricing as a resource-demand regulator since my CTSS days, where Corby told me it was already known for years to the phone company; so I'd suggest that if the PTTs aren't groaning under their presented loads (and for all I know they are but just don't talk about it in public) it's because they have extra-protocol ways of limiting the loads. And, for that matter, if 40-byte headers bother you, how about you be the one who finally does the exercise of totalling up the sizes of the Network (actual), Network ("connectionless" [a/k/a IP], Transport, Session, Presentation, Application, and Management (times 5 or 6) "PDUs": after all, another good way of keeping the loads down is to make things so barococo that nobody can fabricate a load to present, right? pro forma cheers, map P.S. Andy's reply to me, my reply to it, and his reply to my reply should cast some light on the flavor of virtual circuits we were talking about at the subnet processor to subnet processor level; sorry, I don't think you can rightly infer that IMPs/PSNs "are" X.25 node to node. Indeed, the fundamental problem of the Internet in one sense is that there is not and cannot be A node to node protocol at the subnet level, since the subnet level is by definition hetereogenous. Andy is adressing the/a backbone subnet, which contrary to its original design parameters is now dealing with a multiplicity of (to it) ancillary subnets; X.25 on the other limb is offering some (by spec) no more than 56.2 kb/s "trunks", take 'em or leave 'em. It's like comparing apples to orange pits (or pips, if John Laws is still tuned in) to imagine that Arpanet and "the PTTs" are interchangeable. Try hooking say a 10-meg Ethernet up to an X.25 PSN: you've either got a 56.2 bottleneck or you're building some sort of milking machine and paying for multiple X.25 ports even if your Hosts are "doing" X.25 as their end-to-end/"Transport" protocol, but if the Hosts are doing the ISO Stack, you've the same Gateway bashing problems as in the Internet--with, almost certainly, a far less flexible/responsive "backbone".... ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072206284501> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 22 Jul 87 07:35:35-PDT Date: 22 Jul 1987 10:28:45 EDT Subject: Re: Internet Uselessness From: Michael Padlipsky To: H. Craig McKee cc: Andy Malis , PADLIPSKY@A.ISI.EDU, tcp-ip@SRI-NIC.ARPA In-Reply-To: <8707211807.AA09192@mitre.arpa> H. Craig-- Just to show the unbelievers that there are some windmills even I won't bother to lance, I'll merely answer your final rhetorical question ("The Commercial/PTT networks can do it, why can't we?"): As I understand the "it" John and Andy and I were talking about, it's dealing with presented loads greater than a system was designed to deal with; if you really think the PTTs know how to get five pounds of bits in a two-pound sack, I hope you'll share your knowledge with us all. In other words, if it's physically impossible, even we can't do it--but neither can They.... It would be too Zen to get into the subtleties of the flavor of pie in the sky vs. the taste of bread in the mouth, but I would feel myself remiss if I didn't mention that I've been aware of pricing as a resource-demand regulator since my CTSS days, where Corby told me it was already known for years to the phone company; so I'd suggest that if the PTTs aren't groaning under their presented loads (and for all I know they are but just don't talk about it in public) it's because they have extra-protocol ways of limiting the loads. And, for that matter, if 40-byte headers bother you, how about you be the one who finally does the exercise of totalling up the sizes of the Network (actual), Network ("connectionless" [a/k/a IP], Transport, Session, Presentation, Application, and Management (times 5 or 6) "PDUs": after all, another good way of keeping the loads down is to make things so barococo that nobody can fabricate a load to present, right? pro forma cheers, map P.S. Andy's reply to me, my reply to it, and his reply to my reply should cast some light on the flavor of virtual circuits we were talking about at the subnet processor to subnet processor level; sorry, I don't think you can rightly infer that IMPs/PSNs "are" X.25 node to node. Indeed, the fundamental problem of the Internet in one sense is that there is not and cannot be A node to node protocol at the subnet level, since the subnet level is by definition hetereogenous. Andy is adressing the/a backbone subnet, which contrary to its original design parameters is now dealing with a multiplicity of (to it) ancillary subnets; X.25 on the other limb is offering some (by spec) no more than 56.2 kb/s "trunks", take 'em or leave 'em. It's like comparing apples to orange pits (or pips, if John Laws is still tuned in) to imagine that Arpanet and "the PTTs" are interchangeable. Try hooking say a 10-meg Ethernet up to an X.25 PSN: you've either got a 56.2 bottleneck or you're building some sort of milking machine and paying for multiple X.25 ports even if your Hosts are "doing" X.25 as their end-to-end/"Transport" protocol, but if the Hosts are doing the ISO Stack, you've the same Gateway bashing problems as in the Internet--with, almost certainly, a far less flexible/responsive "backbone".... ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707221535.AA23560@topaz.rutgers.edu] <1987072207351000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Name of NIC (was: twg, and nic not knowing its domain name..) Message-ID: <8707221535.AA23560@topaz.rutgers.edu> Date: Wed, 22-Jul-87 11:35:10 EDT Article-I.D.: topaz.8707221535.AA23560 Posted: Wed Jul 22 11:35:10 1987 Date-Received: Fri, 24-Jul-87 04:59:40 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 1 Watch out or they'll make the name of the hosts NET.INFO.CTR as you suggested. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [314@uniq.UUCP] <1987072207494100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: news@uniq.UUCP (Usenet Administration) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <314@uniq.UUCP> Date: Wed, 22-Jul-87 11:49:41 EDT Article-I.D.: uniq.314 Posted: Wed Jul 22 11:49:41 1987 Date-Received: Fri, 24-Jul-87 06:51:32 EDT References: <725@hjuxa.UUCP> Organization: Uniq Digital Technologies, Batavia, IL Lines: 15 Keywords: TCP/IP, Streams In article <725@hjuxa.UUCP>, kp@hjuxa.UUCP (Karen Paszamant) writes: > Does anyone know what vendors have a System V Release 3.0 > streams based tcp/ip product? Uniq Digital Technologies supports UNIX System V Release 3 TCP/IP for VAX processors. The product, called Passage, is available in binary or source form. The next release of Passage will be Streams based. That release is expected within approximately 30 days. Contact Trish Halleen on 1-800-DEC-UNIX for more information about Passage or Uniq's port of System V Release 3 to VAX processors. -- Uniq Digital Technologies 28 South Water Street Batavia, Illinois 60510 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707221554.AA24150@topaz.rutgers.edu] <1987072207542700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: RE: Wollongong TCP/IP for VAX/VMS Message-ID: <8707221554.AA24150@topaz.rutgers.edu> Date: Wed, 22-Jul-87 11:54:27 EDT Article-I.D.: topaz.8707221554.AA24150 Posted: Wed Jul 22 11:54:27 1987 Date-Received: Sat, 25-Jul-87 17:11:53 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 I hope that Dave's arrival at Wollongong will certainly help the situation there. It seems to have gotten much better already. However several assertions he made are false. 2.3 will make VAX's unusable under certain instances (they don't crash, they just don't do anything until you correct the network problem). As for the support statement, in the past I have directly called Woolongong with support problems and gotten the eternal run-around. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707221558.AA24214@topaz.rutgers.edu] <1987072207582000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: TWG questions Message-ID: <8707221558.AA24214@topaz.rutgers.edu> Date: Wed, 22-Jul-87 11:58:20 EDT Article-I.D.: topaz.8707221558.AA24214 Posted: Wed Jul 22 11:58:20 1987 Date-Received: Fri, 24-Jul-87 05:00:48 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Dbridge in Version 2 of the code is abysmal. I don't know if it is fixed in 3.0 since I now have a real IP path between the two sites. It would be nice if Woolongong would take the effort of reversing this product (allowing DECNET to flow through their IP paths) but it probalby isn't an easy modification. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707221755.AA27315@topaz.rutgers.edu] <1987072209551900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: PD TCP/IP requests Message-ID: <8707221755.AA27315@topaz.rutgers.edu> Date: Wed, 22-Jul-87 13:55:19 EDT Article-I.D.: topaz.8707221755.AA27315 Posted: Wed Jul 22 13:55:19 1987 Date-Received: Sat, 25-Jul-87 17:58:18 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 20 With Universities at least, ownership of code funded by the government depends upon the provisions of the grant. If the grant was a contract that specified production of software as a deliverable, then it is work for hire, and the code is owned by the government, or required to be PD, or something like that. However if the grant called for research, and the code was in effect a sideeffect of the research, then all agencies that I know interpret that the code was not the thing that they were contracting for, and the University owns it. Few universities these days are willing to admit that any code the produce was the intended product of their work, so although the government pays for much of the code produced by our universities, the tendency is for very little of it to be regarded as covered by the provisions requiring government-funded code to be public. Some agencies consider this a good thing, because they'd rather see the universities have enough ownership of the code to be able to sell it to a software house for futher development and eventual marketing. This is viewed as "technology transfer", and gets them brownie points. Agencies apparently do not view PD software as accomplishing much. I disapprove of this trend, and view all of my work as PD, but I seem to be fighting a losing battle. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [64200002@uiucuxe] <1987072212370000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: alexandr@uiucuxe.cso.uiuc.edu Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong telnet and new line proc Message-ID: <64200002@uiucuxe> Date: Wed, 22-Jul-87 16:37:00 EDT Article-I.D.: uiucuxe.64200002 Posted: Wed Jul 22 16:37:00 1987 Date-Received: Sat, 25-Jul-87 11:06:28 EDT References: <25@abvax.icd.ab.com> Lines: 40 Nf-ID: #R:abvax.icd.ab.com:25:uiucuxe:64200002:000:1301 Nf-From: uiucuxe.cso.uiuc.edu!alexandr Jul 22 15:37:00 1987 The bug is in telnetd for the incoming session, not telnet for the outgoing session. There is nothing wrong with the pty driver at all. Here is a diff. Your line numbers may vary. The problem is that someone misread the telnet spec and interpreted "NEWLINE" to mean UNIX newline character ('\n') not a conceptual end of line. The result: If you telnet into a 4.3 machine (or SUN running 3.2), you can't telnet out to any non-unix machine. You can't tip anywhere. It's a dumb bug, but easy to fix. -- Steve Alexander Workstation Development, National Center for Supercomputing Applications stevea%newton@uxc.cso.uiuc.edu stevea%newton@uiuc.arpa stevea%newton@uiuc.csnet stevea@uiucvmd.bitnet ...!{pur-ee, convex, ihnp4}!uiucdcs!uiucuxc!newton!stevea ----- cut here for diffs ------ *** /tmp/geta2947 Wed Jul 22 15:30:13 1987 --- /tmp/getb2947 Wed Jul 22 15:30:14 1987 *************** *** 637,643 **** if ((myopts[TELOPT_BINARY] == OPT_NO) && c == '\r') { if ((ncc > 0) && ('\n' == *netip)) { netip++; ncc--; ! c = '\n'; } else { state = TS_CR; } --- 652,658 ---- if ((myopts[TELOPT_BINARY] == OPT_NO) && c == '\r') { if ((ncc > 0) && ('\n' == *netip)) { netip++; ncc--; ! c = '\r'; } else { state = TS_CR; } ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072212413100> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Wed 22 Jul 87 19:11:30-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA12207; Wed, 22 Jul 87 17:53:36 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Jul 87 12:41:31 GMT From: mtune!codas!novavax!atlas!jjensen@RUTGERS.EDU (Jim Jensen) Organization: Gould CSD, Fort Lauderdale, FL Subject: Re: Wollongong telnet and new line processing Message-Id: <502@atlas.UUCP> References: <25@abvax.icd.ab.com> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa in article <25@abvax.icd.ab.com>, wrk@abvax.icd.ab.com (William R. King) says: > > I've been tyring to get our BSD 4.3 VAX to talk to a VAX/VMS > system using Wollongong telnet and have discovered an interesting > problem. Unix uses \n as the line terminator, >[deleted about sending a \r to VMS] > Unix translate the \r into a \n and sends it across the net > [problems this causes on VMS deleted] > I've modified telnet to send a \r instead of a \n for the line > terminator. Although I think this is only a work around. > > I say this because if you are connect to the Unix machine > via a direct line everything works fine. This problem only > occurs when you are connected via a pty. We use Bridge > cs/1 terminal servers almost exclusivly, hence you are always > connected to a pty and never to a direct line. > (this is my first posting so I dont know if I am doing this right) I just finished writing telnet for MPX (Gould's real time OS), and ran into the same problem. The bridge box sends a \r\n which is the specifed in the telnet rfc as the end of line character. which the unix telnet server turns into a \n. on telnet 4.2 the telnet task, converts this back to \r\n which the VMS(or MPX)server converts back to a \r and everything works. 4.3 leaves it as a \n, which seems to me to be a clear violation of the protocol. The rfc SAYS that \r\n is the end of line character, not \n. Thats what protocols are for; To take care of differences between machines. When a protocol is not followed problems like this happen. I asked one of our unix people about it, and he said that BSD did it on purpose, and it is in telnet. I was unable to convince him it was a mistake, so he would not change it. that is until some people in our unix group tried to use a bridge box. Thus: the latest patch to Gould Unix has a telnetd which has a variable that can be set called Telnet_with_a_bridge_box(if I remember correctly) that if set fixes the problem. I am not a unix person, so I may have gotten something wrong about unix, but I don't think so. Jim Jensen Gould inc. CSD 6901 West Sunrise Boulevard Ft. Lauderdale Fl 33313-4499 (305) 587-2900 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072213020400> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Wed 22 Jul 87 19:12:00-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA12262; Wed, 22 Jul 87 17:55:32 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Jul 87 13:02:04 GMT From: mtune!codas!novavax!atlas!jjensen@RUTGERS.EDU (Jim Jensen) Organization: Gould CSD, Fort Lauderdale, FL Subject: Re: Wollongong telnet and new line processing Message-Id: <505@atlas.UUCP> References: <25@abvax.icd.ab.com> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa in article <25@abvax.icd.ab.com>, wrk@abvax.icd.ab.com (William R. King) says: > > I've been tyring to get our BSD 4.3 VAX to talk to a VAX/VMS > system using Wollongong telnet and have discovered an interesting > problem. Unix uses \n as the line terminator, >[deleted about sending a \r to VMS] > Unix translate the \r into a \n and sends it across the net > [problems this causes on VMS deleted] > I've modified telnet to send a \r instead of a \n for the line > terminator. Although I think this is only a work around. > > I say this because if you are connect to the Unix machine > via a direct line everything works fine. This problem only > occurs when you are connected via a pty. We use Bridge > cs/1 terminal servers almost exclusivly, hence you are always > connected to a pty and never to a direct line. > (this is my first posting so I dont know if I am doing this right) I just finished writing telnet for MPX (Gould's real time OS), and ran into the same problem. The bridge box sends a \r\n which is the specifed in the telnet rfc as the end of line character. which the unix telnet server turns into a \n. on telnet 4.2 the telnet task, converts this back to \r\n which the VMS(or MPX)server converts back to a \r and everything works. 4.3 leaves it as a \n, which seems to me to be a clear violation of the protocol. The rfc SAYS that \r\n is the end of line character, not \n. Thats what protocols are for; To take care of differences between machines. When a protocol is not followed problems like this happen. I asked one of our unix people about it, and he said that BSD did it on purpose, and it is in telnet. I was unable to convince him it was a mistake, so he would not change it. that is until some people in our unix group tried to use a bridge box. Thus: the latest patch to Gould Unix has a telnetd which has a variable that can be set called Telnet_with_a_bridge_box(if I remember correctly) that if set fixes the problem. I am not a unix person, so I may have gotten something wrong about unix, but I don't think so. Jim Jensen Gould inc. CSD 6901 West Sunrise Boulevard ----MESSAGE-END---- ----MESSAGE-BEGIN---- [684@julian.UWO.CDN] <1987072214162700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: peter@julian.UUCP Newsgroups: comp.os.vms,comp.protocols.tcp-ip Subject: Async DECnet and MNP modems help Message-ID: <684@julian.UWO.CDN> Date: Wed, 22-Jul-87 18:16:27 EDT Article-I.D.: julian.684 Posted: Wed Jul 22 18:16:27 1987 Date-Received: Sat, 25-Jul-87 01:32:10 EDT Organization: Univ. Western Ontario, London Ont. CA Lines: 27 Keywords: DECnet VMS MNP Microcom I'm trying to get a dynamic asynchronous DECnet link established between two VMS machines. The method of connection is a telephone line and a pair of Microcom AX/9624c MNP-6 modems running at either 9600bps or 19200bps. When I follow the instructions, I get the circuit set up, but after a flurry of activity lasting perhaps 30 or 40 seconds (data transmitted in both directions) the remote end stops talking and I see periodic polls coming from the local system. A SET HOST command to the remote system dies with a message about a DECnet channel error. Eventually I hang up the telephone manually and try to get my async line back. Does anyone have any experience with this kind of set up? Has anyone tried something similar using Serial Line IP (SLIP)? I'm willing to abandon DECnet and consontrate on something that will fit in better. Am I silly to expect it ever to work? Are there any parameters (delays, retransmission...) that I can set to make this work better? The modems will be introducing a significant delay as they try to buffer up and compress and packetize. Any help would be appreciated. -- Peter Marshall, Data Comm. Manager CCS, U. of Western Ontario, London, Canada N6A 5B7 (519)661-2151x6032 pm@uwovax.BITNET; pm@uwovax.uwo.cdn; peter@julian.uucp; ...!watmath!julian!peter ----MESSAGE-END---- ----MESSAGE-BEGIN---- [11636@hi.UUCP] <1987072214474800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kurt@hi.UUCP (Kurt Zeilenga) Newsgroups: comp.unix.wizards,comp.dcom.lans,comp.protocols.tcp-ip Subject: How do you break up a B class number? Message-ID: <11636@hi.UUCP> Date: Wed, 22-Jul-87 18:47:48 EDT Article-I.D.: hi.11636 Posted: Wed Jul 22 18:47:48 1987 Date-Received: Fri, 24-Jul-87 06:45:29 EDT Reply-To: kurt@hc.dspo.gov (Kurt Zeilenga) Followup-To: comp.protocols.tcp-ip Organization: U. of New Mexico, Albuquerque Lines: 22 Does anyone know of any good references for netmasking (subnets) schemes to split a B class number into various sized networks? Here's the problem: We have out grown our present configuration for IP networking. We have a half dozen or so C class networks (not registered), one of which is filling rapidly. We will soon be attaching to Internet and will be using one B class number (registered) for the whole campus. We would like to split the B into different sized subnets say of sizes to support 2 (host-host), 14, 62, 254, 2046 hosts. On NIC's suggestion, we will use all 1s on a given net for broadcast and reserve all 0s on a given net. There will be at least one gateway to the outside Internet. What did you do? If you send your comments to me, I will post a summary. If not .... -- Kurt Zeilenga (zeilenga@hc.dspo.gov) I want my talk.flame! "Remember, Mommie, I'm off to get a commie..." ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072217122100> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Fri 24 Jul 87 13:08:18-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA25025; Fri, 24 Jul 87 13:06:54 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Jul 87 17:12:21 GMT From: ur-tut!ur-cvsvax!srs!dan@cs.rochester.edu (Dan Kegel) Organization: S.R.Systems Subject: Re: Streams TCP/IP Message-Id: <255@srs.UUCP> References: <725@hjuxa.UUCP>, <649@houxa.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa > Would someone please summarize why Streams is better... While we're at it, could anybody summarize the differences between RFS and NFS? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707230250.AA00546@gateway.mitre.org] <1987072218504300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gross@GATEWAY.MITRE.ORG (Phill Gross) Newsgroups: comp.protocols.tcp-ip Subject: Re: TWG on MILNET? Message-ID: <8707230250.AA00546@gateway.mitre.org> Date: Wed, 22-Jul-87 22:50:43 EDT Article-I.D.: gateway.8707230250.AA00546 Posted: Wed Jul 22 22:50:43 1987 Date-Received: Sat, 25-Jul-87 03:17:24 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 13 Dennis, I was told by one of our DDN planners just a few days ago that Arpanet was most definitely not considered to be part of the DDN. I pointed that most of the DDN transition charts I've seen show many nets, including Arpanet, merging into an internet called DDN. He assured me, however, that when all is done, Arpanet will not be part of DDN. I remain puzzled. Now I guess the next question is- is Arpanet really an experimental network for network research or an operational network for use by researchers? Phill ----MESSAGE-END---- ----MESSAGE-BEGIN---- [278@unixprt.UUCP] <1987072221575400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: monkey@unixprt.UUCP (Monkey Face@unixprt) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <278@unixprt.UUCP> Date: Thu, 23-Jul-87 01:57:54 EDT Article-I.D.: unixprt.278 Posted: Thu Jul 23 01:57:54 1987 Date-Received: Sat, 25-Jul-87 06:41:13 EDT References: <725@hjuxa.UUCP> <649@houxa.UUCP> Organization: uni-xperts - Unix System and Networking Consultants Lines: 23 Keywords: TCP/IP, Streams Summary: Streams advantages/disadvantages In article <649@houxa.UUCP>, mel1@houxa.UUCP (M.HAAS) writes: > Would someone please post a summary of reasons why use of Streams is > an advantage... is there a reason Streams is better? than sockets?... > Does the end user see any advantage?... > Thanks, > Mel Haas , odyssey!mel First it is STREAMS, as apposed to Streams, streams, this differenciates it from a stream based environment. The primary advantage, for those using ATT based UNIX, is that this is the only 'real' facility provided in UNIX System V to support networking. It basically provides the 'structure' that allows layered protocols a consistent interface to other layers in a somewhat independent manner. It is not necessarily 'better', but it is a more appropriately structure for the varying protocols than other implementations (such as the 4.x BSD architecture). Hopefully the 'end-user' doesn't get involved at this level. ATT's Transport Interface is mostly base on the ISO transport interface, therefore should map to the emerging interface standards. I have found that performance is not considerably different in s STREAMS based vs. 4.x BSD based implemetnation of TCP/IP. Monkey Face - uni-xperts ----MESSAGE-END---- ----MESSAGE-BEGIN---- [940@gvax.cs.cornell.edu] <1987072303054400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jqj@gvax.cs.cornell.edu (J Q Johnson) Newsgroups: comp.protocols.tcp-ip Subject: Re: How do you break up a B class number? Message-ID: <940@gvax.cs.cornell.edu> Date: Thu, 23-Jul-87 07:05:44 EDT Article-I.D.: gvax.940 Posted: Thu Jul 23 07:05:44 1987 Date-Received: Sat, 25-Jul-87 05:36:44 EDT References: <11636@hi.UUCP> Reply-To: jqj@gvax.cs.cornell.edu (J Q Johnson) Organization: Cornell Univ. CS Dept, Ithaca NY Lines: 24 In article <11636@hi.UUCP> kurt@hc.dspo.gov (Kurt Zeilenga) writes: >Does anyone know of any good references for netmasking (subnets) >schemes to split a B class number into various sized networks? Although variable-sized subnets may work for some network topologies, they are almost guaranteed to get you into trouble, and I strongly recommend that you avoid them. Consider a subnet (perhaps the backbone) with two or more gateways. Host A on this subnet wants to send a packet to host B on a different subnet. In order to look up the route to B, A needs to decompose B's address into net-subnet-host, so he needs to know B's subnet mask. All current software that I know of will use A's mask, and ASSUME that it is the same size as B's. Granted you can fool the routing tables in some topologies, e.g. a network with subnet mask of 255.255.255.0 containing several subsubnets (who think the subnet mask is 255.255.255.188 or something) all connected to only a single (hacked) gateway, where that gateway advertises a subnet that is the union of the subsubnets. It will break as soon as you make the topology more complex! Given that we can't do what Zeilenga asks, is it perhaps time to rethink the whole subnet scheme? 16 bits of hostnumber is not much at all for a typical large organization (say a university), especially if we have to waste most of it because of subnet constraints. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707231238.AA22963@ucbvax.Berkeley.EDU] <1987072304202300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HANK@BARILVM.BITNET (Henry Nussbacher) Newsgroups: comp.protocols.tcp-ip Subject: Looking for someone from ACC Message-ID: <8707231238.AA22963@ucbvax.Berkeley.EDU> Date: Thu, 23-Jul-87 08:20:23 EDT Article-I.D.: ucbvax.8707231238.AA22963 Posted: Thu Jul 23 08:20:23 1987 Date-Received: Sat, 25-Jul-87 06:44:41 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 If someone reading this is from ACC (Advanced Computer Communications - makers of ACCES/MVS and ACC 9310) could you please drop me a note via the network. Thanks, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2501@ncrcae.Columbia.NCR.COM] <1987072305272500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: heath@ncrcae.Columbia.NCR.COM (Robert Heath) Newsgroups: comp.protocols.tcp-ip Subject: Wanted: Network Independent File Transfer Protocol (NIFTP) Message-ID: <2501@ncrcae.Columbia.NCR.COM> Date: Thu, 23-Jul-87 09:27:25 EDT Article-I.D.: ncrcae.2501 Posted: Thu Jul 23 09:27:25 1987 Date-Received: Sat, 25-Jul-87 06:37:19 EDT Reply-To: heath@ncrcae.UUCP (Robert Heath) Organization: NCR Corp., Engineering & Manufacturing - Columbia, SC Lines: 22 I am looking for the source to a UNIX-based implementation of Network Independent File Transfer Protocol (NIFTP). NIFTP is used mainly in the UK (& New Zealand) to move files around X.25 networks. I am informed that Internet Protocol versions of NIFTP exist, but I am interested only in using the OSI Transport layer over X.25 version. My goal is to port NIFTP to an NCR TOWER running UNIX 5.2. I'd like to hear the opinion of any NIFTP users on how well it works and to discuss possible interconnection. I have the names of two other interested parties which I picked up from an earlier, unsuccessful posting to comp.sources.wanted. Thanks in advance. Robert A. Heath ncrcae!heath or heath@Columbia.NCR.COM NCR Dept 783 3325 W. Platt Springs Rd. W. Columbia, SC 29169 (803)-791-6492 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [730@hjuxa.UUCP] <1987072306264800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kp@hjuxa.UUCP (Karen Paszamant) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans Subject: RE: Streams TCP/IP Vendors Message-ID: <730@hjuxa.UUCP> Date: Thu, 23-Jul-87 10:26:48 EDT Article-I.D.: hjuxa.730 Posted: Thu Jul 23 10:26:48 1987 Date-Received: Sat, 25-Jul-87 11:01:31 EDT Organization: Digital Equipment Corp. Holmdel, NJ Lines: 14 Keywords: Streams, TCP/IP Thanks for the info on vendors. I ordered the book from SRI but have still not received it. In case anyone else is interested, here is a summary of Streams based TCP/IP vendors for Sys V Release 3.0: 1. Spider Systems, Edinburgh, U.K. 2. Counterpoint Computers 3. Micom Interlan - they used Lachmans TCP/IP 4. Uniq Digital Technologies, Batavia, ILL. 1-800-DEC-UNIX 5. The Wollongong Group, Palo Alto, CA 6. Lachman Associates, Naperville, ILL. - they worked with Convergent Technologies to develop product. Karen hjuxa!kp ----MESSAGE-END---- ----MESSAGE-BEGIN---- [731@hjuxa.UUCP] <1987072306282300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ajr@hjuxa.UUCP (Karen Paszamant) Newsgroups: comp.protocols.tcp-ip Subject: NFS on system V Message-ID: <731@hjuxa.UUCP> Date: Thu, 23-Jul-87 10:28:23 EDT Article-I.D.: hjuxa.731 Posted: Thu Jul 23 10:28:23 1987 Date-Received: Sat, 25-Jul-87 11:01:46 EDT Organization: Digital Equipment Corp. Holmdel, NJ Lines: 7 Keywords: nfs,tcp/ip,system v I am looking for a port of NFS for System V release 2 or 3. Does any one know if it exists. What kind of environment is it running in? How is the performance and bugs? Does it come with Yellow pages and XDR? Thanks hjuxa!ajr ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3857@osu-eddie.UUCP] <1987072307510800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bob%tut.cis.ohio-state.edu@osu-eddie.UUCP (Bob Sutterfield) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <3857@osu-eddie.UUCP> Date: Thu, 23-Jul-87 11:51:08 EDT Article-I.D.: osu-eddi.3857 Posted: Thu Jul 23 11:51:08 1987 Date-Received: Sat, 25-Jul-87 10:43:56 EDT References: <725@hjuxa.UUCP> <314@uniq.UUCP> Sender: news@osu-eddie.UUCP Reply-To: bob@ohio-state.ARPA (Bob Sutterfield) Organization: The Ohio State University Dept of Computer & Information Science Lines: 15 Keywords: TCP/IP, Streams Summary: only for VAXen In article <314@uniq.UUCP> news@uniq.UUCP (Usenet Administration) writes: >In article <725@hjuxa.UUCP>, kp@hjuxa.UUCP (Karen Paszamant) writes: >> Does anyone know what vendors have a System V Release 3.0 >> streams based tcp/ip product? >Uniq Digital Technologies supports UNIX System V Release 3 TCP/IP for >VAX processors. ... Contact Trish Halleen on 1-800-DEC-UNIX ... I just did. I was about the dozenth person who had inquired whether they do IP on 3B2s under SVr3 too (which they don't), and whether they planned to (ditto). *Disappointment*. I guess I'm stuck with TWG. -=- Bob Sutterfield, Department of Computer and Information Science The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277 bob@ohio-state.{arpa,csnet} or ...!cbosgd!osu-eddie!bob soon: bob@aargh.cis.ohio-state.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12639.554047863@gremlin.nrtc.northrop.com] <1987072308414600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mrose@GREMLIN.NRTC.NORTHROP.COM (Marshall Rose) Newsgroups: comp.protocols.tcp-ip Subject: Re: SMTP question Message-ID: <12639.554047863@gremlin.nrtc.northrop.com> Date: Thu, 23-Jul-87 12:41:46 EDT Article-I.D.: gremlin.12639.554047863 Posted: Thu Jul 23 12:41:46 1987 Date-Received: Sat, 25-Jul-87 07:36:31 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 I don't know what the "official" word is, but SMTP is designed for moving ascii messages. Although the gurus will probably tell you otherwise, SMTP is very dependent on rfc822, which defines the format of text messages. This probably isn't the fault of SMTP, since all of the mailers which use SMTP also depend on rfc822 or rfc822-like formats being used. If you want to use SMTP to move arbitrary octets in messages, then on UNIX, using something like atob and btoa. btoa takes a "binary" stream (8-bit bytes) and explodes it into a 7-bit data path with line breaks at column 78 (or something like that); atob performs the inverse operation. I'm sure other systems have similar programs. Alternately, find someone running X.400 in the Internet and just use X.400. Of course, it's probably going to be another three years before X.400 mailers will have the reach of SMTP mailers. /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707231737.AA24337@topaz.rutgers.edu] <1987072309372400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: SMTP question Message-ID: <8707231737.AA24337@topaz.rutgers.edu> Date: Thu, 23-Jul-87 13:37:24 EDT Article-I.D.: topaz.8707231737.AA24337 Posted: Thu Jul 23 13:37:24 1987 Date-Received: Sat, 25-Jul-87 07:59:42 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 I strongly object to modifying SMTP and RFC822 to allow for this. Lets keep plaintext plain. If you wish to enhance mail, try the multimedia mail project. The main problem with the existing Multimedia project is that NOBODY OBEYS THE SPECIFICATION. Hence messages from DIAMOND are unreadable on other systems. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [686@julian.UWO.CDN] <1987072310290300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: peter@julian.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong TCP/IP for VAX/VMS Message-ID: <686@julian.UWO.CDN> Date: Thu, 23-Jul-87 14:29:03 EDT Article-I.D.: julian.686 Posted: Thu Jul 23 14:29:03 1987 Date-Received: Sat, 25-Jul-87 05:20:58 EDT References: <12316245218.8.MRC@PANDA> <8707071930.AA08177@nic.nyser.net> <670@julian.UWO.CDN> Reply-To: peter@julian.UUCP (Peter Marshall) Distribution: world Organization: University of Western Ontario, London Lines: 12 Summary: TWG seems to be trying I recently posted a message saying that Digital was now not recommending TWG software for VMS machines. I got a call last night from TWG following up on my message. They wanted to find out what specific problems that we have been having with their software. (We don't have a copy, unfortunately.) It looks to me as if their new Vice-president is having some effect. They are making an effort to improve their image. It could be more than skin deep. -- Peter Marshall, Data Comm. Manager CCS, U. of Western Ontario, London, Canada N6A 5B7 (519)661-2151x6032 pm@uwovax.BITNET; pm@uwovax.uwo.cdn; peter@julian.uucp; ...!watmath!julian!peter ----MESSAGE-END---- ----MESSAGE-BEGIN---- [24072@sun.uucp] <1987072310394100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <24072@sun.uucp> Date: Thu, 23-Jul-87 14:39:41 EDT Article-I.D.: sun.24072 Posted: Thu Jul 23 14:39:41 1987 Date-Received: Sat, 25-Jul-87 08:42:07 EDT References: <725@hjuxa.UUCP> <649@houxa.UUCP> <278@unixprt.UUCP> Sender: news@sun.uucp Lines: 21 Keywords: TCP/IP, Streams > The primary advantage, for those using ATT based UNIX, is that this is the > only 'real' facility provided in UNIX System V to support networking. Gee, for some time now the people at Berkeley have been using an "AT&T-based UNIX" (the only non-"AT&T-based" UNIXes I know of are things like Mark Williams' "Coherent", which was written from scratch) that supports networking without STREAMS. Plenty of other people have dropped the socket code into System V kernels, just as Berkeley dropped it into a 32V-derived kernel, so STREAMS are not "the only game in town". > ATT's Transport Interface is mostly base on the ISO transport interface, > therefore should map to the emerging interface standards. Unfortunately, the TLI also has a number of warts, such as the fact that it keeps some state both in userland and in the kernel, so that after a "fork"/"exec" you have to issue a "t_sync" call to pull the kernel's notion of the state into userland. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12320712107.11.OKUNO@SUMEX-AIM.STANFORD.EDU] <1987072310525800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Okuno@SUMEX-AIM.STANFORD.EDU (Hiroshi "Gitchang" Okuno) Newsgroups: comp.protocols.tcp-ip Subject: Help: TCP/IP for business application Message-ID: <12320712107.11.OKUNO@SUMEX-AIM.STANFORD.EDU> Date: Thu, 23-Jul-87 14:52:58 EDT Article-I.D.: SUMEX-AI.12320712107.11.OKUNO Posted: Thu Jul 23 14:52:58 1987 Date-Received: Sat, 25-Jul-87 13:03:01 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: Knowledge Systems Laboratory Lines: 9 I'd like to know whether TCP/IP is really used for business applications or distributed processings. Or is it used only for computational environments (Telnet, FTP, SMTP, NSF, windows)? Any information or pointer is welcome. Thanks in advance, - Gitchang - ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5680@ut-ngp.UUCP] <1987072312033200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rick@ut-ngp.UUCP (Rick Watson) Newsgroups: comp.protocols.tcp-ip Subject: Re: TWG questions Message-ID: <5680@ut-ngp.UUCP> Date: Thu, 23-Jul-87 16:03:32 EDT Article-I.D.: ut-ngp.5680 Posted: Thu Jul 23 16:03:32 1987 Date-Received: Sat, 25-Jul-87 08:43:44 EDT References: <8707221558.AA24214@topaz.rutgers.edu> Distribution: world Organization: UTexas Computation Center, Austin, Texas Lines: 44 > Dbridge in Version 2 of the code is abysmal. I don't know if it is > fixed in 3.0 since I now have a real IP path between the two sites. > It would be nice if Woolongong would take the effort of reversing this > product (allowing DECNET to flow through their IP paths) but it probalby > isn't an easy modification. > > -Ron *Flame on* Saying that "Dbridge [...] is abysmal" is not really very informative. What specifically did you have problems with? *Flame off* We have been using DBRIDGE under v2.x (and now 3.0) with good performance under light to moderate usage (say 1-4 "active [currently transferring data]" circuits in/out of each node). Performance will (of course) be dependent on DECnet circuit speed and loading. Our topology looks like: 192.16.73---ether --+--128.83-----ether-+--------- | |... | | |... +---+ +---+ +---+ | | | | UTADNX | |--- 10 (arpanet) +---+ +---+ +---+ | | ---DECnet 192.16.72----- | | | | +---+ +---+ +---+ +---+ | | | | | | | | +---+ +---+ +---+ +---+ with DBRIDGE/DECnet making the connections for the network 192.16.72 over serveral leased phone lines that run at 56KB, 230.4KB and ~760KB. The CPU overhead for the DBRIDGE process on UTADNX can get to be high if it is having to route too many packets on to 128.83 and beyond. It really needs to be a dedicated uVax. It would be nice if the DBRIDGE interface could live in the WIN/TCP kernel (like ELINK does now), instead of a user-mode process, but I have no idea if that is possible. Rick Watson University of Texas Computation Center arpa: ccaw001@utadnx.cc.utexas.edu rick@ngp.utexas.edu uucp: ...seismo!ut-sally!ut-ngp!rick bitnet: ccaw001@utadnx phone: 512/471-3241 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707232004.AA05747@lear.ultra.com] <1987072312043900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: wayne@ultra.UUCP (Wayne Hathaway) Newsgroups: comp.protocols.tcp-ip Subject: Re: Berkeley (not wollongong!) telnet and new line processing Message-ID: <8707232004.AA05747@lear.ultra.com> Date: Thu, 23-Jul-87 16:04:39 EDT Article-I.D.: lear.8707232004.AA05747 Posted: Thu Jul 23 16:04:39 1987 Date-Received: Sat, 25-Jul-87 13:49:34 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 38 Apropos of not much more than "Nothing new under the sun," a small war story about TELNET end-of-lines. Back about 15ish years ago I had the dubious pleasure of trying to shoehorn an IBM system into the ARPANET world. In particular, we used the IBM 2741, a half-duplex Selectric typewriter ("Mother of the TELNET go-ahead"*). Among the 2741's endearing qualities was that it had no key. It had "INDEX," which did a , and it had "RETURN," which did a combined (actually the EBCDIC "newline" character); the only way to output a naked was to backspace all the way to the beginning of the line! In actual operation, this caused no real problem, because of course my user TELNET was smart enough to translate TELNET end-of-line () into EBCDIC "newline," and naked s were pretty rare. Except in one case: good old Multics (or at least one generation of Multics TELNET), which for some unknown reason insisted on ending every line with . Decidedly nonconforming for sure, but completely transparent to almost every other ARPANET host, so why change? Anyway, whenever I logged into Multics from a 2741 I got the following behavior: typey-typey-typey-typey-backspace-backspace-backspace-backspace-index typey-typey-typey-typey-backspace-backspace-backspace-backspace-index typey-typey-typey-typey-backspace-backspace-backspace-backspace-index typey-typey-typey-typey-backspace-backspace-backspace-backspace-index Ad nauseum. But the most interesting thing was that in spite of everything taking more than twice as long (plus shaking everything off the typing table), the output ended up being exactly correct! Amazing what can pass for "interoperability" ... Wayne Hathaway ultra!wayne@Ames.ARPA Ultra Corporation 2140 Bering drive with a domain server: San Jose, CA 95131 wayne@Ultra.COM 408-922-0100 * There was at least one other name for the 2741 that also started with "Mother." Fun gadget ... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12320729020.11.BILLW@MATHOM.CISCO.COM] <1987072312255300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BILLW@MATHOM.CISCO.COM (William Westfield) Newsgroups: comp.protocols.tcp-ip Subject: IBM TCP. Message-ID: <12320729020.11.BILLW@MATHOM.CISCO.COM> Date: Thu, 23-Jul-87 16:25:53 EDT Article-I.D.: MATHOM.12320729020.11.BILLW Posted: Thu Jul 23 16:25:53 1987 Date-Received: Sat, 25-Jul-87 13:02:34 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 I heard an interesting rumor that the IBM distributed TCP/IP source routes all its packets. Is this possibly true???? BillW ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [561@applix.UUCP] <1987072313250500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mark@applix.UUCP (Mark Fox) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <561@applix.UUCP> Date: Thu, 23-Jul-87 17:25:05 EDT Article-I.D.: applix.561 Posted: Thu Jul 23 17:25:05 1987 Date-Received: Sat, 25-Jul-87 08:57:11 EDT References: <725@hjuxa.UUCP> <649@houxa.UUCP> <278@unixprt.UUCP> Reply-To: mark@applix.UUCP (Mark Fox) Organization: APPLiX Inc., Westboro MA Lines: 49 Keywords: TCP/IP, Streams Summary: how so? In article <278@unixprt.UUCP> monkey@unixprt.UUCP (Monkey Face@unixprt) writes: >In article <649@houxa.UUCP>, mel1@houxa.UUCP (M.HAAS) writes: >> Would someone please post a summary of reasons why use of Streams is >> an advantage... is there a reason Streams is better? than sockets?... >> Does the end user see any advantage?... > >The primary advantage, for those using ATT based UNIX, is that this is the >only 'real' facility provided in UNIX System V to support networking. Possible, but have you seen HP's or CPC's implementation of sockets in their System V ports? Looks plenty "real" to me and cleanly done as well. >It is not necessarily 'better', but it is a more appropriately structure >for the varying protocols than other implementations (such as the >4.x BSD architecture). What do you mean by "a more appropriate[ly] structure"? Could you back this up or is this only an opinion? >Hopefully the 'end-user' doesn't get involved >at this level. But with 4.x all the end-user needs to know is a host name in order to use the Berkeley "r" utilities assuming NFS across remote mount points is not being used instead. >ATT's Transport Interface is mostly base on the ISO >transport interface, therefore should map to the emerging interface >standards. But its easy enough to add new socket types as Sun has for its OSI protocol implementation. >I have found that performance is not considerably >different in s STREAMS based vs. 4.x BSD based implemetnation of TCP/IP. So? >Monkey Face - uni-xperts What're those? Don't get me wrong - I'm not a socket bigot - but I have never seen an implementation of streams and I am still curious why some people prefer them. -- Mark Fox Applix Inc., 112 Turnpike Road, Westboro, MA 01581, (617) 870-0300 uucp: seismo!harvard!m2c!applix!mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072318502300> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Thu 23 Jul 87 05:23:51-PDT Received: from VM1.BIU.AC.IL by wiscvm.wisc.edu ; Thu, 23 Jul 87 07:21:49 CDT Received: by BARILVM (Mailer X1.24) id 4534; Thu, 23 Jul 87 15:22:22 P Date: Thu, 23 Jul 1987 15:20:23 P From: Henry Nussbacher Subject: Looking for someone from ACC To: tcp-ip@sri-nic.ARPA If someone reading this is from ACC (Advanced Computer Communications - makers of ACCES/MVS and ACC 9310) could you please drop me a note via the network. Thanks, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707240018.a023436@Huey.UDEL.EDU] <1987072320183900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet Uselessness Message-ID: <8707240018.a023436@Huey.UDEL.EDU> Date: Fri, 24-Jul-87 00:18:39 EDT Article-I.D.: Huey.8707240018.a023436 Posted: Fri Jul 24 00:18:39 1987 Date-Received: Sat, 25-Jul-87 13:46:56 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Craig, Without addressing your comment that "TCP/IP is in fact a Bad Idea," I might conclude from your remarks that public X.25 networks may have to either surcharge or prohibit use of connectionless protocols over virtual circuits. This is an interesting issue which should be raised within the ANSI X3S3.3 committee. I also conclude from your remarks that the public X.25 community has come up with "a scheme that doesn't hammer the network to its knees when something goes wrong." Please, I desperately need to know what scheme you have in mind. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072403320000> Received: from umn-rei-uc.ARPA by SRI-NIC.ARPA with TCP; Fri 24 Jul 87 10:35:01-PDT Received: by umn-rei-uc.ARPA (5.51/4.40.2) id AA29388; Fri, 24 Jul 87 12:34:18 CDT Date: 24 Jul 1987 10:32-PDT Sender: STJOHNS@sri-nic.arpa Subject: Re: IP Security option From: STJOHNS@sri-nic.arpa To: dab%oliver.cray.com@umn-rei-uc.arpa Cc: tcp-ip%sri-nic.arpa@umn-rei-uc.arpa Message-Id: <[SRI-NIC.ARPA]24-Jul-87 10:32:55.STJOHNS> In-Reply-To: <8707241651.AA01975@oliver.cray.uucp> IA copy of the IP security option as (supposedly) approved by the protocol standards steering group resides in [sri-nic]PS:ipso.txt. LoginVia anonymous ftp to retrieve it. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [965@geac.UUCP] <1987072405270800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: daveb@geac.UUCP (Dave Brown) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <965@geac.UUCP> Date: Fri, 24-Jul-87 09:27:08 EDT Article-I.D.: geac.965 Posted: Fri Jul 24 09:27:08 1987 Date-Received: Sat, 25-Jul-87 12:16:02 EDT References: <725@hjuxa.UUCP> <649@houxa.UUCP> <278@unixprt.UUCP> <561@applix.UUCP> Reply-To: daveb@geac.UUCP (Dave Brown) Organization: The little blue rock next to that twinkly star Lines: 36 Summary: why? because it looks elegant and interesting In article <561@applix.UUCP> mark@applix.UUCP (Mark Fox) writes: >>In article <649@houxa.UUCP>, mel1@houxa.UUCP (M.HAAS) writes: >>> Would someone please post a summary of reasons why use of Streams is >>> an advantage... is there a reason Streams is better? than sockets?... >>> Does the end user see any advantage?... >... >Don't get me wrong - I'm not a socket bigot - but I have never seen an >implementation of streams and I am still curious why some people prefer them. There is interest in streams for several reasons. 1) It looks elegant. 2) It comes from an acknowleged Unix expert. 3) It *looks* (emphais added) more general than sockets. 4) It allows a structured decomposition of some of the hot-spots in Unix (terminal handling, protocols) into subparts which can be placed on a front-end processor. There is use of streams for other reasons. 1) Bell provides it instead of sockets. 2) Some customers will buy anthing that Berkley *doesn't* make. 3) Some system/hardware designers want (4) above. 4) Some system/hardware designers have fallen in love with any of the above. Personally, I like (4), having worked on a machine which used FEPs effectively (as well as two which didn't, all from the same manufacturer!). --dave (unix hack on a 'bun) collier-brown -- David (Collier-) Brown. | Computer Science Geac Computers International Inc., | loses its memory 350 Steelcase Road,Markham, Ontario, | (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072405371800> Received: from cu-arpa.cs.cornell.edu by SRI-NIC.ARPA with TCP; Fri 24 Jul 87 07:57:52-PDT Received: from gvax.cs.cornell.edu by cu-arpa.cs.cornell.edu (5.54/4.30) id AA03641; Fri, 24 Jul 87 09:37:29 EDT Date: Fri, 24 Jul 87 09:37:18 EDT From: jqj@gvax.cs.cornell.edu (J Q Johnson) Message-Id: <8707241337.AA18897@gvax.cs.cornell.edu> Received: by gvax.cs.cornell.edu (5.54/4.30) id AA18897; Fri, 24 Jul 87 09:37:18 EDT Newsgroups: arpa.tcp-ip Subject: variable sized subnets Reply-To: jqj@gvax.cs.cornell.edu (J Q Johnson) Organization: Cornell Univ. CS Dept, Ithaca NY Apparently-To: tcp-ip@sri-nic.arpa In article <11636@hi.UUCP> on comp.protocols.tcp-ip, kurt@hc.dspo.gov (Kurt Zeilenga) writes: >Does anyone know of any good references for netmasking (subnets) >schemes to split a B class number into various sized networks? Although variable-sized subnets may work for some network topologies, they are almost guaranteed to get you into trouble, and I strongly recommend that one avoid them. Given that we can't do what Zeilenga asks, is it perhaps time to rethink the whole subnet scheme? 16 bits of hostnumber is not much at all for a typical large organization (say a university), especially if we have to waste most of it because of subnet constraints. Why don't variable sized subnets work? Routing and broadcast. Broadcast isn't too bad as long as all hosts have the "correct" subnet mask set for their size of subnet and gateways don't leak broadcasts off the local subnet, but routing is a problem. Consider a subnet (perhaps the backbone) with two or more gateways. Host A on this subnet wants to send a packet to host B on a different subnet. In order to look up the route to B, A needs to decompose B's address into net-subnet-host, so he needs to know B's subnet mask. All current software that I know of will use A's mask (for 4.3BSD, the mask for the first interface on that network!), and ASSUME that it is the same size as B's. Granted you can fool the routing tables in some topologies, e.g. a network with subnet mask of 255.255.255.0 containing several subsubnets (who think the subnet mask is 255.255.255.188 or something) all connected to only a single (hacked) gateway, where that gateway advertises a subnet that is the union of the subsubnets. It will break as soon as you make the topology more complex! Am I missing something? Has anyone successfully made variable-sized subnets work in a real (multivendor, multisubnet) environment? Does anyone have suggestions for a clean way to make them work? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707241359.AA03994@etn-wlv.eaton.com] <1987072405593900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mcc@ETN-WLV.EATON.COM (Crockett) Newsgroups: comp.protocols.tcp-ip Subject: Processing Message-ID: <8707241359.AA03994@etn-wlv.eaton.com> Date: Fri, 24-Jul-87 09:59:39 EDT Article-I.D.: etn-wlv.8707241359.AA03994 Posted: Fri Jul 24 09:59:39 1987 Date-Received: Sat, 25-Jul-87 13:51:33 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 58 I don't have a copy of RFC 854; however, I do have MIL-STD-1782 which defines the implementation requirements for the TELNET Protocol for DDN MILNET and other DDN subnetworks. The end of line character is a which moves the cursor or print head to the beginning of the current line. The standard became confusing when it attempted to accomodate physical terminals that generate a sequence when the ENTER or RETURN key is struck. To permit the use of these terminals a two octet end of line function (ELF) was defined. For terminals that could generate a and a independently, the ELF was defined to be a . For those that couldn't, the ELF was defined to be . Regardless of any echo options that may be in effect, the user (local) host is responsible for transmitting only the keyboard input from the terminal to the server (remote) host. If the RETURN key generates a , it is to be mapped to a prior to transmission over the network. If the NVT is being operated in its default line buffered full duplex mode with local echo, the user host echoes both ELF variations as a to the terminal display. At the server host , , and are to be treated identically and mapped to the host's local interpretation of the character or character sequence that is passed to the application software when the RETURN key is struck. When the virtual circuit is being operated in half duplex mode with the server echoing data back to the user, it transmits either a or with the ELF form being dependent upon the server's local convention. The original problem that raised the question of the NVT ELF was a difference in operation when a terminal (workstation) was connected on a local LAN segment or on a remote LAN segment requiring the use of a gateway to make the transition between the LAN segments. The answer is that both Woologong and the Bridge CS/1 have errors or have been configured incorrectly. Any host in the network that functions as a gateway is responsible for ensuring that the data transmitted is the same as what was received. The sequences and are not necessarily equivalent. The gateway can not compress the sequence to . The problem I have seen with a number of hardware and/or software products that implement TCP/IP, TELNET, FTP, SMTP, and UDP is that the vendor has based his product on the 4.x bsd implementation. The problem with the vendors that have done that is that they have failed to go back through the software and remove all the tacit assumptions that the host system will be running a UNIX or UNIX derivative operating system. Some vendors have even removed code to support the options that are to be negotiated always responding with a DO or WILL when they should be responding with a DON'T or WON'T because they know that 4.x bsd always attempts to negotiate to the same mode of operation. Invariably these products have problems when one attempts to use them on a PDP11 or VAX based AN/GYQ-21(V) systems which use the IAS and VMS operating systems, respectively. Merton Campbell Crockett mcc@etn-wlv.eaton.com AN/GYQ-21(V) Program ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072406384200> Received: from NNSC.NSF.NET by SRI-NIC.ARPA with TCP; Fri 24 Jul 87 10:23:29-PDT To: tcp-ip@sri-nic.ARPA Subject: Naming the NIC Date: Fri, 24 Jul 87 13:18:42 -0400 From: Craig Partridge Hey guys, There is a forum for these sorts of naming issues -- the namedroppers list. I recommend that any continued debate migrate to that list and will even be so good as to resist the instinct to point out that the issue of how to name NICs and NOCs was settled (I thought) over a year ago. Craig Partridge ----MESSAGE-END---- ----MESSAGE-BEGIN---- [M.JSOL.12320929803.BABYL@MIT-EECS] <1987072406480000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: M.JSOL@DEEP-THOUGHT.MIT.EDU (Jon Solomon) Newsgroups: comp.protocols.tcp-ip Subject: Name of NIC (was: twg, and nic not knowing its domain name..) Message-ID: Date: Fri, 24-Jul-87 10:48:00 EDT Article-I.D.: MIT-EECS.M.JSOL.12320929803.BABYL Posted: Fri Jul 24 10:48:00 1987 Date-Received: Sat, 25-Jul-87 14:04:41 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 4 Oh, so there would be MILNET.NIC and ARPANET.NIC and NYSERNET.NIC and BITNET.NIC? Good idea! --jsol ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707241651.AA01975@oliver.cray.uucp] <1987072408515600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dab@oliver.cray.COM (Dave Borman) Newsgroups: comp.protocols.tcp-ip Subject: IP Security option Message-ID: <8707241651.AA01975@oliver.cray.uucp> Date: Fri, 24-Jul-87 12:51:56 EDT Article-I.D.: oliver.8707241651.AA01975 Posted: Fri Jul 24 12:51:56 1987 Date-Received: Sat, 25-Jul-87 14:39:49 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 I seem to recall that at the Monteray TCP/IP conference last fall, there was some discussion that the IP Security option was being re-written, and that there would be an RFC out that described the new scheme. Has anything progressed in this area? Is there a new RFC that talks about the IP Security option? Any pointers to what the current status is would be appreciated. -Dave Borman Cray Research, Inc. dab@umn-rei-uc.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3260@ptsfa.UUCP] <1987072409040700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jmc@ptsfa.UUCP (Jerry Carlin) Newsgroups: comp.protocols.tcp-ip Subject: Re: NFS on system V Message-ID: <3260@ptsfa.UUCP> Date: Fri, 24-Jul-87 13:04:07 EDT Article-I.D.: ptsfa.3260 Posted: Fri Jul 24 13:04:07 1987 Date-Received: Sat, 25-Jul-87 14:44:41 EDT References: <731@hjuxa.UUCP> Reply-To: jmc@ptsfa.UUCP (Jerry Carlin) Organization: Pacific * Bell, San Ramon, CA Lines: 10 Keywords: nfs,tcp/ip,system v In article <731@hjuxa.UUCP> ajr@hjuxa.UUCP (Karen Paszamant) writes: >I am looking for a port of NFS for System V release 2 or 3.... >Does it come with Yellow pages and XDR? Arete release 3.8 (V.2) supports NFS including YP and XDR. They are using an Excelan Ethernet board with EXOS software. -- voice: (415) 823-2441 uucp: {ihnp4,lll-crg,ames,qantel,pyramid}!ptsfa!jmc Where am I? In the village. Whose side are you on? That would be telling. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[SRI-NIC.ARPA]24-Jul-87.10:32:55.STJOHNS] <1987072409320000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: STJOHNS@SRI-NIC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: IP Security option Message-ID: <[SRI-NIC.ARPA]24-Jul-87.10:32:55.STJOHNS> Date: Fri, 24-Jul-87 13:32:00 EDT Article-I.D.: <[SRI-NIC.ARPA]24-Jul-87.10:32:55.STJOHNS> Posted: Fri Jul 24 13:32:00 1987 Date-Received: Sat, 25-Jul-87 15:04:20 EDT References: <8707241651.AA01975@oliver.cray.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 4 IA copy of the IP security option as (supposedly) approved by the protocol standards steering group resides in [sri-nic]PS:ipso.txt. LoginVia anonymous ftp to retrieve it. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [554146774.hoey@nrl-aic] <1987072409393400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hoey@NRL-AIC.ARPA (Dan Hoey) Newsgroups: comp.protocols.tcp-ip Subject: Re: new lines Message-ID: <554146774.hoey@nrl-aic> Date: Fri, 24-Jul-87 13:39:34 EDT Article-I.D.: nrl-aic.554146774.hoey Posted: Fri Jul 24 13:39:34 1987 Date-Received: Sat, 25-Jul-87 15:09:34 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 32 Date: Mon, 20 Jul 87 19:55 PDT From: Kevin Carosso <@YMIR.BITNET:KVC@ENGVAX.SCG.HAC.COM> Subject: Re: wollongong telnet and new line processing To: tcp-ip@sri-nic.ARPA X-Vms-To: IN%"tcp-ip@sri-nic.arpa" I traced the problem to the fact that "telnetd.c" has the following in it: ... What's really laughable about the 4.3 code is that if the is split across whatever buffer boundary telnetd is using, the code turns it into instead of . I don't think it's right to map to . I changed it to map to instead, and everything works just fine. ...I suppose another approach might be to say that the Bridge TELNET code is broken and that it shouldn't be sending when you type "carriage return" but should send .... Well, given that is supposed to be the ``normal'' line terminator, it should probably correspond to the big button on your keyboard. The real bug in the Bridge TELNET is that it apparently gives the user no way of sending a . Telnet user programs should provide some way of sending all three of , , and . On two-button keyboards (RETURN/LF or RETURN/INDEX) this probably means you need to be able to tell telnet what mapping you want. Dan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072409393401> Received: from nrl-aic.ARPA by SRI-NIC.ARPA with TCP; Fri 24 Jul 87 11:37:25-PDT Return-Path: Received: Fri, 24 Jul 87 14:37:10 edt by nrl-aic.ARPA id AA07224 Date: 24 Jul 1987 13:39:34 EDT (Fri) From: Dan Hoey Subject: Re: new lines To: tcp-ip@sri-nic.arpa Cc: Kevin Carosso , uxc.cso.uiuc.edu!uiucuxe!alexandr@a.cs.uiuc.edu Message-Id: <554146774/hoey@nrl-aic> Date: Mon, 20 Jul 87 19:55 PDT From: Kevin Carosso <@YMIR.BITNET:KVC@ENGVAX.SCG.HAC.COM> Subject: Re: wollongong telnet and new line processing To: tcp-ip@sri-nic.ARPA X-Vms-To: IN%"tcp-ip@sri-nic.arpa" I traced the problem to the fact that "telnetd.c" has the following in it: ... What's really laughable about the 4.3 code is that if the is split across whatever buffer boundary telnetd is using, the code turns it into instead of . I don't think it's right to map to . I changed it to map to instead, and everything works just fine. ...I suppose another approach might be to say that the Bridge TELNET code is broken and that it shouldn't be sending when you type "carriage return" but should send .... Well, given that is supposed to be the ``normal'' line terminator, it should probably correspond to the big button on your keyboard. The real bug in the Bridge TELNET is that it apparently gives the user no way of sending a . Telnet user programs should provide some way of sending all three of , , and . On two-button keyboards (RETURN/LF or RETURN/INDEX) this probably means you need to be able to tell telnet what mapping you want. Dan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707241739.AA22286@ucbvax.Berkeley.EDU] <1987072409434100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: Naming the NIC Message-ID: <8707241739.AA22286@ucbvax.Berkeley.EDU> Date: Fri, 24-Jul-87 13:43:41 EDT Article-I.D.: ucbvax.8707241739.AA22286 Posted: Fri Jul 24 13:43:41 1987 Date-Received: Sat, 25-Jul-87 14:40:59 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Hey guys, There is a forum for these sorts of naming issues -- the namedroppers list. I recommend that any continued debate migrate to that list and will even be so good as to resist the instinct to point out that the issue of how to name NICs and NOCs was settled (I thought) over a year ago. Craig Partridge ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4742@sdcrdcf.UUCP] <1987072411553500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: unni@sdcrdcf.UUCP (Unni Warrier) Newsgroups: comp.protocols.tcp-ip Subject: Mailing list on modeling/simulation of networks Message-ID: <4742@sdcrdcf.UUCP> Date: Fri, 24-Jul-87 15:55:35 EDT Article-I.D.: sdcrdcf.4742 Posted: Fri Jul 24 15:55:35 1987 Date-Received: Sat, 25-Jul-87 21:41:34 EDT Reply-To: unni@sdcrdcf.UUCP (Unni Warrier) Distribution: world Organization: Unisys - System Development Group, Santa Monica Lines: 62 This is to announce the start of a new mailing-list devoted to network modeling and simulation. Sorry for the cross-postings to many groups, but we aim to reach as wide an audience as possible. We expect to cover the following broad areas: Networks modeling, Queueing theory as applied to networks Simulation, Distributed simulation These topics are furthur described at the end of this article. Please send in your requests to be included in this list, because if I get a large enough number, we can get our own newsgroup. All requests for inclusion in the mailing list should be sent to ..!sdcrdcf!sdcjove!modsim-request OR "modsim-request@cam.unisys.com" All articles for inclusion should be sent to ..!isdcrdcf!sdcjove!modsim OR "modsim@cam.unisys.com" Any private correspondence regarding the list should be sent to me at ..!sdcrdcf!sdcjove!unni OR "unni@cam.unisys.com" TOPICS FOR DISCUSSION: a. Networks modeling There is a lot of work in the literature on modeling networks, typically as a network of queues. However, for large networks, the computations become intractable and we are forced to move to even more approximte models. * An example is the ARPANET, where the congestion problem has not been satisfactorily analyzed. * Some groups are working on providing network management mechanisms. Will these include performance "hooks"? * A new generation of high-speed fibre-optic based networks is coming into being. What are the models available for these networks? * What do we know about interconnection structures like the hypercube? What is the experience of people in the field? * A lot of work has been done on applying queueing theory to networks. What is the practical experience of net-people in applying these results to real-life network problems? b. Simulation of networks * What is the experience of net-people on simulation of networks? * What are your opinions on simulation vs closed-form solutions? * How well does simulation agree with real measurements? * What are the tools people are using for simulation? Do object-oriented languages provide any better simulation environments than "ordinary" simulation tools like Simscript, GPSS, PAWS? * What are the experiences of net.people with specific tools? * Does distributed simulation offer improved performance over uni-processor simulation? Does anyone have any experiences they wish to communicate? I fully realize that the areas outlined above are very large in scope, but the idea is to get a discussion going. As the group expands, we can spin off more selective areas into new newsgroups. I will "moderate" this list until someone more qualified volunteers, or we get a real newsgroup going. If I get enough responses, I will try to push the net.gods into giving us our own newsgroup. unni UUCP: ..!sdcrdcf!sdcjove!unni ARPA: unni@cam.unisys.com Ma Bell (may she rest in peace!): (213) 829-7511 X 5694 US mail: Unni Warrier, Unisys, MS 41-02, 2400 Colorado Ave, Santa Monica CA 90406 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072413220000> Received: from wharton-10.arpa by SRI-NIC.ARPA with TCP; Fri 24 Jul 87 15:27:37-PDT Date: Fri, 24 Jul 87 18:22 EST From: "Salomon Bros. Inc - Maarten Nederlof" Subject: Info Request - 802 Spec Group Addressing / TCP File Server To: TCP-IP@SRI-NIC.ARPA X-VMS-To: IN%"TCP-IP@SRI-NIC.ARPA" We would like to investigate in pilot form the use of 802 spec "Group Addressing." I would be very interested if anyone on this list has had any experience with using ethernet interfaces for UNIX workstations (SUN, APOLLO, IBM-RT, IBM/AT) that support group addressing (hardware) and provide ON-BOARD processing of the TCP/IP protocols. We are also interested in disk servers that support not only firm-ware TCP/IP, but also allow for SNA and X.25 gateways in the same box. Is there such an animal? Anyone that has such interfaces or equipment, or if anyone has done a review of such vendors, please drop me a note. I will gladly summarize to the net. Maarten Nederlof Salomon Brothers Inc One New York Plaza New York, NY 10004 (212) 747-4238 SALOMON@WHARTON.UPENN.EDU SALOMON@WHARTON-10.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1529@tekgen.TEK.COM] <1987072415005900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dennist@tekgen.TEK.COM (Dennis Thomas) Newsgroups: comp.os.vms,comp.protocols.tcp-ip Subject: CMU-TEK TCP/IP Message-ID: <1529@tekgen.TEK.COM> Date: Fri, 24-Jul-87 19:00:59 EDT Article-I.D.: tekgen.1529 Posted: Fri Jul 24 19:00:59 1987 Date-Received: Sat, 25-Jul-87 18:25:47 EDT Expires: Sun, 23-Aug-87 19:00:58 EDT Reply-To: dennist@tektronix.TEK.COM (Dennis Thomas) Distribution: world Organization: Tektronix, Inc., Beaverton, OR. Lines: 39 Keywords: TCP-IP, VMS, The distribution of the Tektronix VMS TCP/IP software to non-profit organizations has been changed, effective immediately. Carnegie Mellon University (CMU) and Tektronix (TEK) have agreed to a change in the method of distribution of the CMU-TEK VMS TCP/IP software. The major aspects of this distribution are: 1. The new distribution software will be called CMU-TEK IP package, and will be distributed by CMU. 2. CMU-TEK IP software will not require a separate license from TEK; only the CMU license will be required. 3. CMU-TEK IP will be licensed to be used on all DEC Computers including workstations, such as the Micro-vax II. 4. CMU-TEK IP will be distributed in object and source formats. 5. All unfilled and future requests to Tektronix will be forwarded to CMU for actual distribution. 6. CMU-TEK IP software will be available to non-profit and commercial organizations. 7. All requests and enquires for CMU-TEK IP should be sent to: CMU-TEK IP Software Request Computing Services Carnegie Mellon University 4910 Forbes Avenue Pittsburgh, PA 15213-3890 Dennis Thomas John Leong Mgr. Engineering Network Services Director of Networking Tektronix, Inc. Carnegie Mellon University P.O. Box 500 DS 50-454 Pittsburgh, Pennsylvania Beaverton, OR 97077 15213-3890 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707242239.AA28560@ucbvax.Berkeley.EDU] <1987072415220000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: SALOMON@WHARTON.UPENN.EDU ("Salomon Bros. Inc - Maarten Nederlof") Newsgroups: comp.protocols.tcp-ip Subject: Info Request - 802 Spec Group Addressing / TCP File Server Message-ID: <8707242239.AA28560@ucbvax.Berkeley.EDU> Date: Fri, 24-Jul-87 19:22:00 EDT Article-I.D.: ucbvax.8707242239.AA28560 Posted: Fri Jul 24 19:22:00 1987 Date-Received: Sat, 25-Jul-87 15:49:25 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 22 We would like to investigate in pilot form the use of 802 spec "Group Addressing." I would be very interested if anyone on this list has had any experience with using ethernet interfaces for UNIX workstations (SUN, APOLLO, IBM-RT, IBM/AT) that support group addressing (hardware) and provide ON-BOARD processing of the TCP/IP protocols. We are also interested in disk servers that support not only firm-ware TCP/IP, but also allow for SNA and X.25 gateways in the same box. Is there such an animal? Anyone that has such interfaces or equipment, or if anyone has done a review of such vendors, please drop me a note. I will gladly summarize to the net. Maarten Nederlof Salomon Brothers Inc One New York Plaza New York, NY 10004 (212) 747-4238 SALOMON@WHARTON.UPENN.EDU SALOMON@WHARTON-10.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1124@nu3b2.UUCP] <1987072416484700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rwhite@nu3b2.UUCP (Robert C. White Jr.) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <1124@nu3b2.UUCP> Date: Fri, 24-Jul-87 20:48:47 EDT Article-I.D.: nu3b2.1124 Posted: Fri Jul 24 20:48:47 1987 Date-Received: Sun, 26-Jul-87 00:53:45 EDT References: <725@hjuxa.UUCP> <649@houxa.UUCP> <278@unixprt.UUCP> Organization: National University, San Diego Lines: 35 Keywords: TCP/IP, Streams Summary: Just a quickey... This is a semi-informed retelling... As I understand it, STREAMS is/are intelegent filter devices. As such some of the filters can be "multiplexing". You can "open" a "stream head" to a multiplexing STREAMS module and then connect a potentally infinite number of other STREAMS and still only have one "open" counting against your allowed maximum. Since all files are STREAMS you can pass whole file descriptors between processes through an IOCTL call [FD_GIVE and FD_RCV or somesuch]. The flexability is very interesting, and seems to allow recursive nesting of STREAMS modules such that you decide which "layer" you wish to work with depending what stream head you open. i.e. Starlan support for the 3B2 [from program level] requires you use a strange set of primitives to establish the link [they are all in a library] but after you have the link you ay "push" a module on the stream which makes read, write, putsg, and getmsg the [only] valid primitives against the stream. [you can't use read etc. while you are useing the deeper t_primitive calls] What this means is, you can open a connection accross a/the network then "push" the module and pipe the connection through any normal means. when the subtask/pipe exits you pop the module off the stream and terminate the connection. It all looks very interesting, I am watching this stuff carefully, but I havn't been able to upgrade my OS yet so I don't know how well it works first hand. Robert. Disclaimer: My mind is so fragmented by random excursions into a wilderness of abstractions and incipient ideas that the practical purposes of the moment are often submerged in my consciousness and I don't know what I'm doing. [my employers certainly have no idea] ----MESSAGE-END---- ----MESSAGE-BEGIN---- [232386.870724.JBVB@AI.AI.MIT.EDU] <1987072419322000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: IBM TCP. Message-ID: <232386.870724.JBVB@AI.AI.MIT.EDU> Date: Fri, 24-Jul-87 23:32:20 EDT Article-I.D.: AI.232386.870724.JBVB Posted: Fri Jul 24 23:32:20 1987 Date-Received: Sat, 25-Jul-87 17:19:14 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 35 I heard an interesting rumor that the IBM distributed TCP/IP source routes all its packets. Is this possibly true???? BillW ------- What I have been told is this: 1. IBM's TCP/IP for the PC, as released for use on their Token Ring Adapter, does not ARP in the conventional sense: Instead, it sends the ARP as an "all rings" broadcast, with an empty Routing Information Field. When the reply comes back, it looks for the filled-in RIF field, and uses it. No RIF field, no function. 2. IBM's TCP/IP for AIX can behave as above, but only if you enable it with some magic switch. 3. Other IBM TCP/IP products will try the "all rings" approach, but only if they get no reply to a conventional ARP. 4. IBM bridges don't pass conventional (not "all rings") broadcasts. So, yes, folks, source routing is alive & well at Yorktown, whether or not ISO has accepted it. No official position is being stated here, but comments I've heard range from "That's WRONG! Let's try to talk them into conforming." to "Oh, hell, they won't listen, and they're going to sell piles of that junk - It's gonna be a dirty job, but we'd better change the code..." I've heard nothing about aberrant behavior on Ether, so apparently they're only punishing their own pioneering customers at the moment.... jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2403@ames.UUCP] <1987072510330400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: schoch@ames.UUCP (Steve Schoch) Newsgroups: comp.protocols.tcp-ip Subject: Why are these hosts trying to connect? Message-ID: <2403@ames.UUCP> Date: Sat, 25-Jul-87 14:33:04 EDT Article-I.D.: ames.2403 Posted: Sat Jul 25 14:33:04 1987 Date-Received: Sun, 26-Jul-87 01:54:30 EDT Organization: NASA Ames Research Center, Moffett Field, CA Lines: 63 Keywords: refused A while back, out of curiosity, I added a line to our kernel on ames.arpa that logs a message when a host tries to connect to a TCP port on ames on which no process is listening (i.e. when ames sends back a packet with the reset bit set in response to a SYN). Since we run most of the common servers on ames, I expected to get a few messages if someone played around trying random ports on our machine. I log the foreign address and the destination port i.e. the port on ames to which a connection is attempted. What surprised me is how many messages I got. Here are a couple pages of log messages: ---- Jul 24 00:06:26 ames vmunix: conn refused ucbarpa.berkeley.edu port 3944 Jul 24 00:09:11 ames vmunix: conn refused rutgers.edu port 3836 Jul 24 00:09:17 ames vmunix: conn refused rutgers.edu port 3836 Jul 24 00:17:55 ames vmunix: conn refused hao.ucar.edu port 3958 Jul 24 00:20:48 ames vmunix: conn refused hao.ucar.edu port 3968 Jul 24 00:21:05 ames vmunix: conn refused ucbarpa.berkeley.edu port 3965 Jul 24 00:24:11 ames vmunix: conn refused ucbarpa.berkeley.edu port 3972 Jul 24 00:49:35 ames vmunix: conn refused xn.ll.mit.edu port 3990 Jul 24 00:49:37 ames vmunix: conn refused xn.ll.mit.edu port 3990 Jul 24 00:49:38 ames vmunix: conn refused xn.ll.mit.edu port 3990 Jul 24 00:49:38 ames vmunix: conn refused xn.ll.mit.edu port 3990 Jul 24 01:03:20 ames vmunix: conn refused hao.ucar.edu port 4001 Jul 24 01:06:06 ames vmunix: conn refused cad.berkeley.edu port 4005 Jul 24 01:06:10 ames vmunix: conn refused cad.berkeley.edu port 4005 Jul 24 01:15:45 ames vmunix: conn refused seismo.css.gov port 4026 Jul 24 01:15:50 ames vmunix: conn refused seismo.css.gov port 4026 Jul 24 01:16:23 ames vmunix: conn refused im4u.utexas.edu port 4014 Jul 24 01:24:39 ames vmunix: conn refused think.com port 4034 Jul 24 01:34:13 ames vmunix: conn refused cs.ucla.edu port 4040 Jul 24 01:34:14 ames last message repeated 5 times Jul 24 01:38:04 ames vmunix: conn refused hao.ucar.edu port 4047 Jul 24 01:46:36 ames vmunix: conn refused cad.berkeley.edu port 4051 Jul 24 02:06:10 ames vmunix: conn refused hao.ucar.edu port 4069 Jul 24 02:09:58 ames vmunix: conn refused scubed.arpa port 3797 Jul 24 02:19:11 ames vmunix: conn refused think.com port 4083 Jul 24 03:00:57 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105 Jul 24 03:02:27 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105 Jul 24 03:05:27 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105 Jul 24 03:07:42 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105 Jul 24 03:08:27 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105 Jul 24 03:12:12 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105 Jul 24 03:12:57 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105 Jul 24 03:14:27 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105 Jul 24 03:15:12 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105 Jul 24 03:18:15 ames vmunix: conn refused think.com port 4119 Jul 24 03:19:42 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105 Jul 24 03:21:12 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105 Jul 24 03:22:28 ames vmunix: conn refused hao.ucar.edu port 4125 Jul 24 03:22:40 ames vmunix: conn refused hao.ucar.edu port 4127 Jul 24 03:22:42 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105 Jul 24 03:24:12 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105 Jul 24 03:24:57 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105 Jul 24 03:27:12 ames vmunix: conn refused ucbarpa.berkeley.edu port 4105 ---- My question is: "Why are all these host trying to connect to these ports on ames?" Note that the port numbers are the ports to which they are trying to connect, i.e. someone on ucbarpa could have typed "telnet ames.arpa 4105" to generate that last message, but I kind of doubt someone did this that may times at 3 in the morning. I think all the hosts in this log file run 4BSD UNIX. Does BSD send random SYN packets to sites? Steve ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707251854.AA03963@etn-wlv.eaton.com] <1987072510544500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mcc@ETN-WLV.EATON.COM (Crockett) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong telnet and new line processing Message-ID: <8707251854.AA03963@etn-wlv.eaton.com> Date: Sat, 25-Jul-87 14:54:45 EDT Article-I.D.: etn-wlv.8707251854.AA03963 Posted: Sat Jul 25 14:54:45 1987 Date-Received: Sun, 26-Jul-87 02:11:54 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 64 I submitted this previously but probably performed the submission incorrectly. ************* I don't have a copy of RFC 854; however, I do have MIL-STD-1782 which defines the implementation requirements for the TELNET Protocol for DDN MILNET and other DDN subnetworks. The end of line character is a which moves the cursor or print head to the beginning of the current line. The standard became confusing when it attempted to accomodate physical terminals that generate a sequence when the ENTER or RETURN key is struck. To permit the use of these terminals a two octet end of line function (ELF) was defined. For terminals that could generate a and a independently, the ELF was defined to be a . For those that couldn't, the ELF was defined to be . Regardless of any echo options that may be in effect, the user (local) host is responsible for transmitting only the keyboard input from the terminal to the server (remote) host. If the RETURN key generates a , it is to be mapped to a prior to transmission over the network. If the NVT is being operated in its default line buffered full duplex mode with local echo, the user host echoes both ELF variations as a to the terminal display. At the server host , , and are to be treated identically and mapped to the host's local interpretation of the character or character sequence that is passed to the application software when the RETURN key is struck. When the virtual circuit is being operated in half duplex mode with the server echoing data back to the user, it transmits either a or with the ELF form being dependent upon the server's local convention. The original problem that raised the question of the NVT ELF was a difference in operation when a terminal (workstation) was connected on a local LAN segment or on a remote LAN segment requiring the use of a gateway to make the transition between the LAN segments. The answer is that both Woologong and the Bridge CS/1 have errors or have been configured incorrectly. Any host in the network that functions as a gateway is responsible for ensuring that the data transmitted is the same as what was received. The sequences and are not necessarily equivalent. The gateway can not compress the sequence to . The problem I have seen with a number of hardware and/or software products that implement TCP/IP, TELNET, FTP, SMTP, and UDP is that the vendor has based his product on the 4.x bsd implementation. The problem with the vendors that have done that is that they have failed to go back through the software and remove all the tacit assumptions that the host system will be running a UNIX or UNIX derivative operating system. Some vendors have even removed code to support the options that are to be negotiated always responding with a DO or WILL when they should be responding with a DON'T or WON'T because they know that 4.x bsd always attempts to negotiate to the same mode of operation. Invariably these products have problems when one attempts to use them on a PDP11 or VAX based AN/GYQ-21(V) systems which use the IAS and VMS operating systems, respectively. Merton Campbell Crockett AN/GYQ-21(V) Program EATON Corporation Information Management Systems Division ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707260257.AA26037@umix.cc.umich.edu] <1987072518573600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hyc@UMIX.CC.UMICH.EDU (Howard Chu) Newsgroups: comp.protocols.tcp-ip Subject: Re: SMTP for any UNIX on any kind of AT Message-ID: <8707260257.AA26037@umix.cc.umich.edu> Date: Sat, 25-Jul-87 22:57:36 EDT Article-I.D.: umix.8707260257.AA26037 Posted: Sat Jul 25 22:57:36 1987 Date-Received: Sun, 26-Jul-87 04:54:14 EDT References: <8707211638.AA24272@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 17 >Date: Tue, 21 Jul 87 12:38:47 EDT >From: hedrick@topaz.rutgers.edu >Subject: Re: SMTP for any UNIX on any kind of AT >IBM has an implementation of POP 2 for the IBM PC. It's part of their >TCP/IP support for the PC. This is probably as close as you will >come to SMTP for a PC. Au contraire... Phil Karn has a TCP/IP package which includes SMTP service that works with MSDOS, and is being ported to Minix. From there, any other Unix is just a tiny stretch. Send a message to tcp-group-request@louie.udel.edu for more info... -- Howard Chu hyc@umix.cc.umich.edu seismo!umix!hyc ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072604100000> Received: from eglin-vax.arpa by SRI-NIC.ARPA with TCP; Sun 26 Jul 87 07:16:12-PDT Date: 26 Jul 87 09:10:00 CDT From: "CALVIN R. GEORGE" Subject: SEVERAL copies of message received To: "tcp-ip" Reply-To: "CALVIN R. GEORGE" Delivery Receipt: NO E G L I N A F B I N T E R O F F I C E M E M O R A N D U M Date: 26-Jul-1987 08:52am CDT From: CALVIN R. GEORGE GEORGE Dept: Tel No: 882-5498 TO: _MAILER! ( _DDN[TCP-IP@SRI-NIC.ARPA] ) Subject: SEVERAL copies of message received It is not uncommon to receive 2 copies of a message on occasion but I know I have read 6 copies of the one from Jim Jensen ( GOULD ) about the BSD 4.3 problem. I have checked our system and am 99% sure it is not replicating the messages. Have others seen many copies of this message? Calvin George Eglin AFB, FL ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707261432.AA26072@ucbvax.Berkeley.EDU] <1987072606100000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: george@EGLIN-VAX.ARPA ("CALVIN R. GEORGE") Newsgroups: comp.protocols.tcp-ip Subject: SEVERAL copies of message received Message-ID: <8707261432.AA26072@ucbvax.Berkeley.EDU> Date: Sun, 26-Jul-87 10:10:00 EDT Article-I.D.: ucbvax.8707261432.AA26072 Posted: Sun Jul 26 10:10:00 1987 Date-Received: Sun, 26-Jul-87 21:07:05 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "CALVIN R. GEORGE" Distribution: world Organization: The ARPA Internet Lines: 26 Delivery Receipt: NO E G L I N A F B I N T E R O F F I C E M E M O R A N D U M Date: 26-Jul-1987 08:52am CDT From: CALVIN R. GEORGE GEORGE Dept: Tel No: 882-5498 TO: _MAILER! ( _DDN[TCP-IP@SRI-NIC.ARPA] ) Subject: SEVERAL copies of message received It is not uncommon to receive 2 copies of a message on occasion but I know I have read 6 copies of the one from Jim Jensen ( GOULD ) about the BSD 4.3 problem. I have checked our system and am 99% sure it is not replicating the messages. Have others seen many copies of this message? Calvin George Eglin AFB, FL ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707261457.aa11734@SMOKE.BRL.ARPA] <1987072610574400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: steve@BRL.ARPA (Stephen Wolff) Newsgroups: comp.protocols.tcp-ip Subject: Re: Name of NIC (was: twg, and nic not knowing its domain name..) Message-ID: <8707261457.aa11734@SMOKE.BRL.ARPA> Date: Sun, 26-Jul-87 14:57:44 EDT Article-I.D.: SMOKE.8707261457.aa11734 Posted: Sun Jul 26 14:57:44 1987 Date-Received: Sun, 26-Jul-87 21:38:53 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 3 Indeed. One would hope that the name of the address of "the NIC" would contain no clue concerning which of the multiple, partially-redundant, National Research Internet databases (the InterNic) would answer any query. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [19872@ucbvax.BERKELEY.EDU] <1987072615430700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: leres@ucbarpa.Berkeley.EDU (Craig Leres) Newsgroups: comp.protocols.tcp-ip Subject: Re: TWG questions Message-ID: <19872@ucbvax.BERKELEY.EDU> Date: Sun, 26-Jul-87 19:43:07 EDT Article-I.D.: ucbvax.19872 Posted: Sun Jul 26 19:43:07 1987 Date-Received: Mon, 27-Jul-87 00:36:18 EDT References: <8707221558.AA24214@topaz.rutgers.edu> <5680@ut-ngp.UUCP> Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: leres@lbl-rtsg.arpa (Craig Leres) Lines: 12 Dbridge exists because we wanted internet access from VMS system that only had a point to point interface which DECnet already had its claws in. But there were other VMS machines on our DECnet that did have internet access so we devised a way to take advantage of them. We knew from the start that dbridge would never be a speed demon; not only is the overhead for DECnet too great, but it generates lots of system calls and process context switches. Of course, the minute we got money to buy a DEUNA, we started running elink. But dbridge served us well until that happened. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707270125.AA16263@topaz.rutgers.edu] <1987072617254600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Vendors on MILNET Message-ID: <8707270125.AA16263@topaz.rutgers.edu> Date: Sun, 26-Jul-87 21:25:46 EDT Article-I.D.: topaz.8707270125.AA16263 Posted: Sun Jul 26 21:25:46 1987 Date-Received: Mon, 27-Jul-87 03:42:31 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 The MIL in MILNET means the Military's operational network. Hence, if they want to reliably talk to someone for whatever reason, they put the on the MILNET rather than risk having to deal with the potentially broken experimental ARPANET. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707262327.aa01093@Huey.UDEL.EDU] <1987072619271300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Studies in congestion control and preemption Message-ID: <8707262327.aa01093@Huey.UDEL.EDU> Date: Sun, 26-Jul-87 23:27:13 EDT Article-I.D.: Huey.8707262327.aa01093 Posted: Sun Jul 26 23:27:13 1987 Date-Received: Mon, 27-Jul-87 03:57:32 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 397 Folks, As you may know, the NSFNET Backbone network has recently been upgraded to a fuzzware version that supports selective buffer preemption. In this version an input buffer is almost always available for an arriving packet. Upon arrival and inspection for correct format and IP checksum, the (sometimes considerable) unused space at the end of the buffer is returned to the buffer pool and the packet inserted on the correct output queue, as determined by the routing algorithm. A preemption is necessary when an input buffer must be allocated for the next following packet. When preemption is necessary, each output queue is scanned separately to find the customer with the largest number of 512-octet blocks. Then the queue with the largest number of such blocks is determined and the last buffer for the associated customer is preempted, even if the buffer preempted was the one just filled. In case of ties, the queue with the most packets transmitted since the last preemption is chosen. The entire process is repeated until sufficient buffer space is available for the input buffer request. It turns out rusty old soldier linkabit-gw is carrying much more traffic than it should, for reasonse that are temporary and irrelevant to the discussion anyway. There is a bottleneck between the inbound 56-Kbps line from ARPANET and an outbound 7.2-Kbps serial line to U Maryland. There is only about 8K octets of buffering in this machine, so one would expect preemption to occur fairly often. One would then be keenly interested in how the selection strategy operates. Following is an edited extract from the log file for linkabit-gw covering an interval of about eight hours on a weekend morning (UT). Each line reveals a single buffer preemption, the interface it occured on and the interface the packet came in on. For the purposes here, only the time and IP source address shown are relevant. The data are arranged chronologically and grouped according to "events," which evidently consist of traffic surges separated by at least five seconds. I have reduced the bulk of the data considerably and deleted, with note, duplicate traps for the same hosts. The fun thing here is to look at the patterns, trends and so forth in order to gain some insight on the behavior of various IP/TCP implementations. The data show 321 packets preempted in 64 surge events during an interval of about 504 minutes. Each surge event consists of from one to 17 preemptions (mean five) and lasts from one to several seconds (typically two). Thus, about two minutes of the 504-minute interval represents congestion severe enough to result in preemption and when this occurs about five packets will be preempted. There are 18 surge events with two or more traps involving a single host, 13 involving two hosts and eight involving three. There were eight more events involving from four to six hosts, most of which occur toward the end of the period when overall network traffic is increasing. Of these 47 events, over a third apparently involve a single host, which suggests further examination of its packetization and queueing mechanisms. Host [10.3.0.11] (SCORE.STANFORD.EDU) seems to be well represented in the data; however, it is also possible that this host may simply have more traffic than the others represented here. I think the data confirms earlier suspicions of many of us that only a few hosts are causing most of the surge events, whether due to defective implementations, antisocial queueing policies or simply too much traffic. Also, note the surges are quite short, in many cases about the same duration as the round-trip interval between the source and its destination. Clearly, ICMP Source Quench messages will have little effect in such cases, especially if the throttling mechanism they operate upon is simply to squeeze the TCP window. On the other hand, note that the intervals between successive surges sometimes is not very large, especially near the end of the period shown, where it ranges from a few seconds to about thirty seconds. This suggests TCP window-throttling might have some beneficial effect if its time constant were comparatively long, like in the order of a minute or more. Since many mail transfers complete in less time, this means that flow information of this type must span more than just a single connection and suggests it be recorded as a state variable in the IP layer and made available on a continuous basis to the TCP layer. I'm inserting the actual data last in this message if you want to skip it. Dave 06:38:07 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1] *** 3 deleted 06:38:07 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1] 06:38:07 010 ?TRAP-I-Buffer preemption 002 [192.5.53.170] 06:38:08 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1] *** 5 deleted 06:38:09 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1] 06:38:09 010 ?TRAP-I-Buffer preemption 002 [192.5.53.170] 06:38:09 010 ?TRAP-I-Buffer preemption 002 [192.5.53.170] 06:38:09 010 ?TRAP-I-Buffer preemption 002 [192.5.53.170] 06:51:50 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] 06:51:50 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] 06:51:50 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] 06:51:50 010 ?TRAP-I-Buffer preemption 002 [26.0.0.74] 06:51:51 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1] 06:51:51 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] *** 3 deleted 06:51:51 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] 06:51:51 010 ?TRAP-I-Buffer preemption 002 [26.0.0.74] 06:51:52 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] 06:58:39 010 ?TRAP-I-Buffer preemption 002 [128.210.1.4] *** 4 deleted 06:58:40 010 ?TRAP-I-Buffer preemption 002 [128.210.1.4] 07:12:59 010 ?TRAP-I-Buffer preemption 002 [192.5.53.170] *** 3 deleted 07:13:00 010 ?TRAP-I-Buffer preemption 002 [192.5.53.170] 07:19:51 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5] 07:19:53 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5] 07:21:57 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1] 07:21:57 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1] 07:21:58 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5] 07:24:52 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:24:52 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:24:52 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5] 07:24:52 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5] 07:24:53 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:24:53 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5] 07:24:53 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5] 07:25:38 014 ?TRAP-I-Buffer preemption 002 [192.5.45.21] 07:25:38 014 ?TRAP-I-Buffer preemption 002 [192.5.45.21] 07:25:45 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:27:03 004 ?TRAP-I-Buffer preemption 012 [128.5.32.1] 07:27:05 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:27:06 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:27:06 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:27:24 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:27:25 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5] *** 2 deleted 07:27:25 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5] 07:27:25 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1] 07:27:47 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5] 07:27:48 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:27:48 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:27:49 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1] 07:33:16 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:33:16 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:33:16 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:33:32 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:33:32 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:33:32 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:33:57 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:34:14 010 ?TRAP-I-Buffer preemption 002 [10.1.0.2] 07:34:35 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:35:09 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:35:09 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:35:27 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:35:27 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:35:28 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:35:58 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:35:59 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:35:59 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:36:32 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:36:32 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:37:00 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:37:00 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:37:00 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:37:29 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:37:30 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:37:30 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:37:30 010 ?TRAP-I-Buffer preemption 002 [10.4.0.5] 07:37:30 010 ?TRAP-I-Buffer preemption 002 [128.36.0.1] 07:37:30 010 ?TRAP-I-Buffer preemption 002 [128.95.1.4] 07:37:31 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:38:04 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:38:04 010 ?TRAP-I-Buffer preemption 002 [128.95.1.4] 07:39:13 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:39:13 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:40:48 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] *** 2 deleted 07:40:49 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:41:16 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:41:16 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:41:54 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] *** 3 deleted 07:42:58 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 07:55:11 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] *** 2 deleted 07:55:11 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] 07:55:12 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1] 07:55:12 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] *** 4 deleted 07:55:12 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] 08:30:00 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] *** 2 deleted 08:30:01 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] 08:30:01 010 ?TRAP-I-Buffer preemption 002 [26.0.0.21] 08:30:01 010 ?TRAP-I-Buffer preemption 002 [26.0.0.21] 08:34:16 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 08:46:40 010 ?TRAP-I-Buffer preemption 002 [10.0.0.52] 08:54:03 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] *** 3 deleted 08:54:04 010 ?TRAP-I-Buffer preemption 002 [10.3.0.11] 09:20:12 010 ?TRAP-I-Buffer preemption 002 [192.5.23.8] 09:24:43 014 ?TRAP-I-Buffer preemption 002 [192.5.8.1] 09:30:52 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] 09:30:52 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] 09:30:53 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1] 09:30:53 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] *** 7 deleted 09:30:54 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] 09:44:38 010 ?TRAP-I-Buffer preemption 002 [10.0.0.52] 09:44:38 010 ?TRAP-I-Buffer preemption 002 [10.0.0.52] 09:44:38 010 ?TRAP-I-Buffer preemption 002 [10.0.0.52] 09:44:38 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1] 09:44:38 010 ?TRAP-I-Buffer preemption 002 [128.105.2.1] 09:44:38 010 ?TRAP-I-Buffer preemption 002 [128.89.0.208] 10:00:14 010 ?TRAP-I-Buffer preemption 002 [10.0.0.52] 10:00:16 010 ?TRAP-I-Buffer preemption 002 [10.0.0.52] 10:00:16 010 ?TRAP-I-Buffer preemption 002 [128.102.2.3] 10:33:12 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] *** 3 deleted 10:33:12 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] 10:33:13 010 ?TRAP-I-Buffer preemption 002 [128.101.1.1] 10:33:13 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] *** 3 deleted 10:33:13 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] 11:03:39 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] *** 7 deleted 11:03:40 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] 11:03:41 010 ?TRAP-I-Buffer preemption 002 [26.2.0.104] 11:19:41 010 ?TRAP-I-Buffer preemption 002 [128.2.249.105] *** 4 deleted 11:19:42 010 ?TRAP-I-Buffer preemption 002 [128.2.249.105] 11:43:20 010 ?TRAP-I-Buffer preemption 002 [192.5.23.8] 12:06:11 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] *** 11 deleted 12:06:13 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] 12:06:13 010 ?TRAP-I-Buffer preemption 002 [128.46.131.21] 12:06:13 010 ?TRAP-I-Buffer preemption 002 [128.46.131.21] 12:06:14 010 ?TRAP-I-Buffer preemption 002 [128.46.131.21] 12:06:14 010 ?TRAP-I-Buffer preemption 002 [192.12.8.9] 12:38:01 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] 12:38:02 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] 13:32:08 010 ?TRAP-I-Buffer preemption 002 [10.1.0.2] *** 6 deleted 13:32:09 010 ?TRAP-I-Buffer preemption 002 [10.1.0.2] 13:32:09 010 ?TRAP-I-Buffer preemption 002 [192.12.141.25] 13:33:38 014 ?TRAP-I-Buffer preemption 002 [192.5.8.1] 13:34:44 010 ?TRAP-I-Buffer preemption 002 [192.12.141.25] 13:34:45 010 ?TRAP-I-Buffer preemption 002 [128.20.1.1] 13:34:45 010 ?TRAP-I-Buffer preemption 002 [192.12.141.25] 13:34:45 010 ?TRAP-I-Buffer preemption 002 [192.5.48.3] 13:47:54 010 ?TRAP-I-Buffer preemption 002 [10.7.0.82] 13:47:54 010 ?TRAP-I-Buffer preemption 002 [192.12.141.25] 13:47:55 010 ?TRAP-I-Buffer preemption 002 [128.110.4.22] 13:47:55 010 ?TRAP-I-Buffer preemption 002 [128.165.4.4] 13:47:55 010 ?TRAP-I-Buffer preemption 002 [192.12.141.25] 13:47:55 014 ?TRAP-I-Buffer preemption 002 [192.5.8.5] 13:47:55 014 ?TRAP-I-Buffer preemption 002 [192.5.8.5] 14:41:41 010 ?TRAP-I-Buffer preemption 002 [128.89.0.92] 14:43:09 004 ?TRAP-I-Buffer preemption 012 [128.5.34.1] 14:43:09 014 ?TRAP-I-Buffer preemption 002 [192.12.33.99] 14:43:11 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1] 14:43:11 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1] 14:43:11 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1] 14:43:12 010 ?TRAP-I-Buffer preemption 002 [128.89.0.92] 14:43:33 010 ?TRAP-I-Buffer preemption 002 [128.89.0.92] 14:46:31 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1] 14:48:09 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1] 14:48:27 010 ?TRAP-I-Buffer preemption 002 [128.97.2.16] *** 3 deleted 14:48:28 010 ?TRAP-I-Buffer preemption 002 [128.97.2.16] 14:48:28 010 ?TRAP-I-Buffer preemption 002 [128.97.2.16] 14:48:46 010 ?TRAP-I-Buffer preemption 002 [10.3.0.44] 14:48:46 010 ?TRAP-I-Buffer preemption 002 [10.3.0.44] 14:51:08 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1] 14:51:09 010 ?TRAP-I-Buffer preemption 002 [10.3.0.44] *** 2 deleted 14:51:09 010 ?TRAP-I-Buffer preemption 002 [10.3.0.44] 14:51:09 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1] 14:51:09 010 ?TRAP-I-Buffer preemption 002 [192.26.86.5] 14:51:10 010 ?TRAP-I-Buffer preemption 002 [10.3.0.44] 14:51:10 010 ?TRAP-I-Buffer preemption 002 [10.3.0.44] 14:51:10 010 ?TRAP-I-Buffer preemption 002 [192.26.86.5] 14:51:10 010 ?TRAP-I-Buffer preemption 002 [192.26.86.5] 14:51:10 010 ?TRAP-I-Buffer preemption 002 [192.26.86.5] 14:55:31 010 ?TRAP-I-Buffer preemption 002 [128.105.2.13] 14:55:31 010 ?TRAP-I-Buffer preemption 002 [128.105.2.13] 14:55:31 010 ?TRAP-I-Buffer preemption 002 [128.165.4.4] 14:55:32 010 ?TRAP-I-Buffer preemption 002 [128.105.2.13] 14:55:32 010 ?TRAP-I-Buffer preemption 002 [128.165.4.4] 14:55:32 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1] 14:55:32 010 ?TRAP-I-Buffer preemption 002 [18.72.0.205] 14:55:32 010 ?TRAP-I-Buffer preemption 002 [192.12.141.129] 14:56:04 010 ?TRAP-I-Buffer preemption 002 [128.105.2.13] 14:56:04 010 ?TRAP-I-Buffer preemption 002 [128.105.2.13] 14:56:04 010 ?TRAP-I-Buffer preemption 002 [128.105.2.13] 14:56:04 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1] 14:56:04 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1] 14:56:05 010 ?TRAP-I-Buffer preemption 002 [10.1.0.96] 14:56:05 010 ?TRAP-I-Buffer preemption 002 [10.1.0.96] 14:56:05 010 ?TRAP-I-Buffer preemption 002 [10.1.0.96] 14:56:05 010 ?TRAP-I-Buffer preemption 002 [128.110.4.22] 14:56:05 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1] 14:56:05 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1] 14:56:05 010 ?TRAP-I-Buffer preemption 002 [192.26.86.5] 14:56:06 010 ?TRAP-I-Buffer preemption 002 [128.2.30.1] 14:56:30 010 ?TRAP-I-Buffer preemption 002 [128.105.2.13] 14:56:31 010 ?TRAP-I-Buffer preemption 002 [128.105.2.13] 14:56:31 010 ?TRAP-I-Buffer preemption 002 [128.165.4.4] 14:56:31 010 ?TRAP-I-Buffer preemption 002 [128.41.9.3] 14:56:31 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1] 14:56:31 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1] 14:56:31 010 ?TRAP-I-Buffer preemption 002 [18.72.0.205] 14:56:32 010 ?TRAP-I-Buffer preemption 002 [192.26.86.5] 14:56:32 010 ?TRAP-I-Buffer preemption 002 [192.26.86.5] 14:56:52 010 ?TRAP-I-Buffer preemption 002 [128.105.2.13] 14:56:53 010 ?TRAP-I-Buffer preemption 002 [128.110.4.22] 14:56:53 010 ?TRAP-I-Buffer preemption 002 [128.110.4.22] 14:56:53 010 ?TRAP-I-Buffer preemption 002 [128.165.4.4] 14:56:53 010 ?TRAP-I-Buffer preemption 002 [128.165.4.4] 14:57:18 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1] 14:57:18 010 ?TRAP-I-Buffer preemption 002 [18.63.0.3] 14:57:19 010 ?TRAP-I-Buffer preemption 002 [128.105.2.13] 14:57:19 010 ?TRAP-I-Buffer preemption 002 [128.110.4.22] 14:57:19 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1] 14:57:19 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1] 14:57:19 010 ?TRAP-I-Buffer preemption 002 [192.26.86.5] 14:58:13 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1] 14:58:13 010 ?TRAP-I-Buffer preemption 002 [128.83.144.1] 14:58:13 010 ?TRAP-I-Buffer preemption 002 [26.2.0.4] 14:58:13 010 ?TRAP-I-Buffer preemption 002 [26.2.0.4] 14:58:13 010 ?TRAP-I-Buffer preemption 002 [26.2.0.4] 14:58:14 010 ?TRAP-I-Buffer preemption 002 [10.0.0.51] 14:58:14 010 ?TRAP-I-Buffer preemption 002 [26.2.0.4] 14:58:14 010 ?TRAP-I-Buffer preemption 002 [26.2.0.4] 14:58:14 010 ?TRAP-I-Buffer preemption 002 [26.2.0.4] 14:58:15 010 ?TRAP-I-Buffer preemption 002 [192.26.86.5] 14:58:15 010 ?TRAP-I-Buffer preemption 002 [192.26.86.5] 14:58:15 010 ?TRAP-I-Buffer preemption 002 [26.2.0.4] 15:02:06 010 ?TRAP-I-Buffer preemption 002 [10.1.0.2] *** 10 deleted 15:02:08 010 ?TRAP-I-Buffer preemption 002 [10.1.0.2] 15:06:46 010 ?TRAP-I-Buffer preemption 002 [128.110.192.2] la di da di da ----MESSAGE-END---- ----MESSAGE-BEGIN---- [233180.870727.PAP4@AI.AI.MIT.EDU] <1987072622541800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") Newsgroups: comp.protocols.tcp-ip Subject: Re: RLP Message-ID: <233180.870727.PAP4@AI.AI.MIT.EDU> Date: Mon, 27-Jul-87 02:54:18 EDT Article-I.D.: AI.233180.870727.PAP4 Posted: Mon Jul 27 02:54:18 1987 Date-Received: Tue, 28-Jul-87 01:03:59 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 23 Yes, I wrote an RLP server for the FTP Software, Inc. `PC/TCP' package. I spoke to Mike Acceta when I wrote it, and apparently, we are the only implementors of it. It hasn't proved very popular. One extension we discussed was to add unsolicited packets for (non-RLP) servers wishing to advertise their services. For instance, a domain name server might send out a periodic broadcast " RLP" query, then send to the servers from that answer a message " DOMAIN" reply. The servers that strictly follow the spec will discard this as being a bogus packet (and hopefully not crash); a smart server might save this info and use it later. I like the protocol. I'm suprised it hasn't been accepted. It's not Clearinghouse, but then it didn't try to be. When I have some time, I will do an implementation for 4.3BSD... It would be really neat if (on UNIX) you didn't need /etc/printcap to list all the various local printers, but could use RLP to locate a printer with suitable qualities... Real Soon Now. -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072703455000> Received: from ford-cos1.arpa.ARPA (FORD-COS1.ARPA) by SRI-NIC.ARPA with TCP; Mon 27 Jul 87 09:07:06-PDT Received: by ford-cos1.arpa.ARPA (5.15/4.7) id AA08806; Mon, 27 Jul 87 09:45:50 MDT Date: Mon, 27 Jul 87 09:45:50 MDT From: paclark%ford-cos1.arpa@ford-cos1.arpa (Patricia A. Clark) Message-Id: <8707271545.AA08806@ford-cos1.arpa.ARPA> To: ihnp4!homxb!houxm!hjuxa!kp%ucbvax.Berkeley.EDU@ford-cos1.arpa, tcp-ip@sri-nic.ARPA Subject: RE: Streams TCP/IP Vendors t q ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072703485500> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Mon 27 Jul 87 07:04:18-PDT Received: from TCSVM.TULANE.EDU by wiscvm.wisc.edu ; Mon, 27 Jul 87 09:00:40 CDT Received: by TCSVM (Mailer X1.24) id 2620; Mon, 27 Jul 87 08:54:05 CDT Date: Mon, 27 Jul 87 08:48:55 CDT From: Manole Calamari To: TCP-IP@SRI-NIC.ARPA In-Reply-To: Message of Mon, 27 Jul 87 11:57:45 +0200 from The latest RFC's can be gotten from LISTSERV@TCSVM.BITNET, note that this is not an all inclusive collection. If others are not present on the server Let me know and I will obtain them for the server. To get the List of files the LISTSERV command TELL LISTSERV AT TCSVM GET TCSSERVE FILELIST. ---------- Manole Calamari (alias Xenon) BITNET: OPRBMVC@TCSVM ARPA: OPRBMVC%TCSVM.BITNET@WISCVM.WISC.EDU Ma Bell: (504) 865-5631 Real Paper: Tulane University Tulane Computer Services Attn: Manuel V. Calamari Jr. 6823 St. Charles Ave. New Orleans, LA 70118-5698 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707271416.AA10134@ucbvax.Berkeley.EDU] <1987072705485500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: OPRBMVC@TCSVM.BITNET (Manole Calamari) Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8707271416.AA10134@ucbvax.Berkeley.EDU> Date: Mon, 27-Jul-87 09:48:55 EDT Article-I.D.: ucbvax.8707271416.AA10134 Posted: Mon Jul 27 09:48:55 1987 Date-Received: Tue, 28-Jul-87 02:19:35 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 15 The latest RFC's can be gotten from LISTSERV@TCSVM.BITNET, note that this is not an all inclusive collection. If others are not present on the server Let me know and I will obtain them for the server. To get the List of files the LISTSERV command TELL LISTSERV AT TCSVM GET TCSSERVE FILELIST. ---------- Manole Calamari (alias Xenon) BITNET: OPRBMVC@TCSVM ARPA: OPRBMVC%TCSVM.BITNET@WISCVM.WISC.EDU Ma Bell: (504) 865-5631 Real Paper: Tulane University Tulane Computer Services Attn: Manuel V. Calamari Jr. 6823 St. Charles Ave. New Orleans, LA 70118-5698 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [443@pluto.UUCP] <1987072705582700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: warren@pluto.UUCP (Warren Burstein) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong TCP/IP for Sys V Message-ID: <443@pluto.UUCP> Date: Mon, 27-Jul-87 09:58:27 EDT Article-I.D.: pluto.443 Posted: Mon Jul 27 09:58:27 1987 Date-Received: Wed, 29-Jul-87 05:00:09 EDT Reply-To: warren@pluto.UUCP (Warren Burstein) Distribution: world Organization: Industrial Automation Systems, New York, NY Lines: 16 Summary: They won't sell it! I asked my boss to order TCP/IP from Wollongong for a 3B2 and he came back and told me they stopped selling it because too many people were ripping it off and they won't sell it until they come up with a way to keep it from being stolen. If anyone out there is from Wollongong - I do not use copy protected software, so I'm not going to buy it when you do figure out what to do. Even if you do something harmless, I still will have found another vendor by the time you get your act together. -- /|/~\~~\ The entire world Warren Burstein |__/__/_/ is a very strange carrot. | But the farmer philabs!tg!pluto!warren / is not afraid at all. Why doesn't life come with subtitles? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707271452.AA02186@seismo.CSS.GOV] <1987072706503200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mo@maximo.UUCP (Mike O'Dell) Newsgroups: comp.protocols.tcp-ip Subject: TCP in business Message-ID: <8707271452.AA02186@seismo.CSS.GOV> Date: Mon, 27-Jul-87 10:50:32 EDT Article-I.D.: seismo.8707271452.AA02186 Posted: Mon Jul 27 10:50:32 1987 Date-Received: Tue, 28-Jul-87 02:49:33 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 17 Gee, I can think of lots of them, starting with where I work, where I used to work and where I worked before that. The best example I know of, however, is at the Bank of Milan in Italy (Europe - home of ISO, right?) and in all the systems built by DATAMAT of Rome. DATAMAT is a systems engineering house who builds systems for business and the financial community, as well as governmental systems. Come to think about it, SUN now has a Wall Street sales office since they are selling SUNs, which use TCP-IP, to investment firms. I guess these qualify. -Mike O'Dell ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707271621.AA06031@phun.riacs.edu] <1987072708345000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: leiner@riacs.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Help: TCP/IP for business application Message-ID: <8707271621.AA06031@phun.riacs.edu> Date: Mon, 27-Jul-87 12:34:50 EDT Article-I.D.: phun.8707271621.AA06031 Posted: Mon Jul 27 12:34:50 1987 Date-Received: Tue, 28-Jul-87 04:27:32 EDT References: <12320712107.11.OKUNO@SUMEX-AIM.STANFORD.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 14 A bit of a strange question, in my opinion. Fact 1. Much of what scientists do on a daily basis is use business functions (e.g. word processing, etc.) and often access remote machines to do this. Fact 2. TCP/IP is the underpinning of much of the scientific networking environment. Did you mean, perhaps, "Do people in a business environment (rather than a scientific or engineering environment) use TCP/IP?" Barry ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707271643.AA23231@monk.proteon.com] <1987072708432400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jas@MONK.PROTEON.COM (John A. Shriver) Newsgroups: comp.protocols.tcp-ip Subject: Streams TCP/IP Message-ID: <8707271643.AA23231@monk.proteon.com> Date: Mon, 27-Jul-87 12:43:24 EDT Article-I.D.: monk.8707271643.AA23231 Posted: Mon Jul 27 12:43:24 1987 Date-Received: Tue, 28-Jul-87 04:52:42 EDT References: <24072@sun.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Read the AT&T SVR3 license agreement about SVID (System V Interface Dovcument) compliance. That's why STREAMS is the only game in town. If you sell a UNIX System under the binary licensing provisions of SVR3, and it has networking, that networking MUST conforn to the SVID networking extnesions, which include STREAMS as the TLI. While you could provide the socket() interface as well, you must provide STREAMS. The SVID requirements have caused a lot of UNIX vendors to not upgrade from SVR2 to SVR3, despite the more attractive binary license pricing. It makes it very difficult to provide 4.3BSD functionality, since you've also got to provide SVR3/SVID/SVVS compatability. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707271647.AA00575@braden.isi.edu] <1987072708475900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: How do you break up a B class number? Message-ID: <8707271647.AA00575@braden.isi.edu> Date: Mon, 27-Jul-87 12:47:59 EDT Article-I.D.: braden.8707271647.AA00575 Posted: Mon Jul 27 12:47:59 1987 Date-Received: Tue, 28-Jul-87 04:49:02 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 18 I'd like to understand the reason that you feel the need to split a class B network into different-sized subnets. What happens if you stick to a single subnet size? Although some of the comments in reply to your message have been somewhat overblown, the fact is that the technical mechanism to handle different-sized subnets of the same network is not generally available today. It may require carrying a 32-bit subnet mask along with each IP (sub-)network address in whatever IGP is used within the subnetted network. The only current IGP which does carry such a mask is Dave Mills' Hello protocol used in the Fuzzballs; however, you could probably hack the BSD routing table and daemon to do so. If you are not in a position to roll your own IGP in this fashion, you had better stick to a single subnet mask. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12321742542.23.OKUNO@SUMEX-AIM.STANFORD.EDU] <1987072709131900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Okuno@SUMEX-AIM.STANFORD.EDU (Hiroshi "Gitchang" Okuno) Newsgroups: comp.protocols.tcp-ip Subject: Re: Help: TCP/IP for business application Message-ID: <12321742542.23.OKUNO@SUMEX-AIM.STANFORD.EDU> Date: Mon, 27-Jul-87 13:13:19 EDT Article-I.D.: SUMEX-AI.12321742542.23.OKUNO Posted: Mon Jul 27 13:13:19 1987 Date-Received: Tue, 28-Jul-87 04:58:13 EDT References: <8707271621.AA06031@phun.riacs.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: Knowledge Systems Laboratory Lines: 23 Barry, > Did you mean, perhaps, "Do people in a business environment (rather than > a scientific or engineering environment) use TCP/IP?" I want to know whether TCP/IP is used in applications such as banking system, car registration system, information retrieval system or other database management system (centralized or distributed). The ARPA Internet, X25Net of CSNET, and NSFNet use TCP/IP but support only Telnet, FTP, SMTP or Finger. Some campus networks support network window or network file systems. Whois may be a kind of network database retrieval system. However, I don't know other higher level or large-scale applications. Mike O'dell, maximo!mo@seismo.CSS.GOV, told me that the system for the Bank of Milan in Italy was the best example. Is there any example in this country? Regards, - Gitchang - ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707271701.AA19176@sri-gemini] <1987072709370200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ejc@TSCA.ISTC.SRI.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: SMTP question Message-ID: <8707271701.AA19176@sri-gemini> Date: Mon, 27-Jul-87 13:37:02 EDT Article-I.D.: sri-gemi.8707271701.AA19176 Posted: Mon Jul 27 13:37:02 1987 Date-Received: Tue, 28-Jul-87 04:55:22 EDT References: <8707231737.AA24337@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 33 This will likely lead to yet another tangent and should be continued on the MM Mail list, but it isn't true that NOBIDY FOLLOWS THE SPECIFICATION for MM Mail. There was a report written by SRI in 1983 defining the consensus (among DoD researchers) specification for standardized MM Mail exchange at that time. The BBN Diamond, ISI MMM, and SRI MMM systems all conformed to that spec (and also, I believe, Dave Mills' Fuzzballs could read MM msgs). A RFP was to be generated, and more development was to be undertaken, especially in the area of graphics exchange. BBN decided to change the DIAMOND exchange formats to support new capabilities they were developing, and as a result, they were no longer compatible with the other (still operational) systems. SRI, in turn, has been funded to develop systems that handle digitized images (maps) with dynamically changing graphic overlays. One might argue that these enhancements should have been discussed and a common exchange protocol agreed to by the "whole community", but the truth is, minimal funding is being provided for that. One observation that is given to support the cutback in funds is that there aren't any remaining research issues. But, one only has to look at the subject headers on this mailing list (the details quickly become boggling) to see that there are many unresolved issues in information exchange in our current systems (not even addressing enhanced system capabilities) and that a much better framework is needed. So, in summary, there still are "compatible" MM Mail systems, they clearly need upgrading to support new capabilities, DIAMOND is developing such capabilites but common exchange protocols need to be re-established in order to leverage all the on-going research in these areas. Earl ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707271742.AA26964@hi] <1987072709424900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kurt@hi.UUCP (Kurt Zeilenga) Newsgroups: comp.protocols.tcp-ip Subject: Re: How do you break up a B class number? Message-ID: <8707271742.AA26964@hi> Date: Mon, 27-Jul-87 13:42:49 EDT Article-I.D.: hi.8707271742.AA26964 Posted: Mon Jul 27 13:42:49 1987 Date-Received: Tue, 28-Jul-87 05:32:03 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 39 Brandon@isi.edu writes: > I'd like to understand the reason that you feel the need to split > a class B network into different-sized subnets. What happens if > you stick to a single subnet size? The reasons why we would like to split the B into different-sized subnets is simple. Address space. Right now we are projecting to have over 1k hosts on our main ethernet (actually a combination of thin and fat wires connected together using repeaters and smart bridges, like DEC's LAN 100 bridge). We also have many subnet that are being installed. Some of which are very small. To accomadate the main cable we would have to use a mask like 0xfffff800. This means we have split our B into 32 subnets each of 2k hosts (minus all ones and all zeros, of course). Anyway, 32 subnets will probably not be enough. Most (if not all) of our subnets will be gatewayed directly to the main ethernet (so subnetting the subnet won't really come into the problem) > Although some of the comments in reply to your message have been somewhat > overblown, the fact is that the technical mechanism to handle > different-sized subnets of the same network is not generally available > today. It may require carrying a 32-bit subnet mask along with each IP > (sub-)network address in whatever IGP is used within the subnetted > network. The only current IGP which does carry such a mask is Dave > Mills' Hello protocol used in the Fuzzballs; however, you could probably > hack the BSD routing table and daemon to do so. If you are not in a > position to roll your own IGP in this fashion, you had better stick to a > single subnet mask. We are not planning to do any hacking. Since there is no real software solution at this time (unless you hack), maybe a hardware solution is in order. Anyone know of where we could pick up a few "smart bridges" real cheap? > Bob Braden - Kurt (zeilenga@hc.dspo.gov) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707272049.AA00306@KAUAI.MCL.UNISYS.COM] <1987072712490300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bobj@KAUAI.MCL.UNISYS.COM (Bobj Jones) Newsgroups: comp.protocols.tcp-ip Subject: DoD Certification of TCP and IP Message-ID: <8707272049.AA00306@KAUAI.MCL.UNISYS.COM> Date: Mon, 27-Jul-87 16:49:03 EDT Article-I.D.: KAUAI.8707272049.AA00306 Posted: Mon Jul 27 16:49:03 1987 Date-Received: Tue, 28-Jul-87 07:11:09 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 For those who are interested, the DCA is setting up an administrative agreement with the National Bureau of Standards to provide for the certification of the TCP/IP suite of protocols. NBS is expected to announce for vendors to participate under the National Voluntary Laboratory Accreditation Program (NVLAP). This program is expected to be in place sometime in early 1988. Any questions please call DCEC, Jim Tontonoz, 703-437-2038. Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707272125.aa04106@Huey.UDEL.EDU] <1987072717250000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: [Lawrence J. Kaufman: Re: Wollongong telnet and new line processing] Message-ID: <8707272125.aa04106@Huey.UDEL.EDU> Date: Mon, 27-Jul-87 21:25:00 EDT Article-I.D.: Huey.8707272125.aa04106 Posted: Mon Jul 27 21:25:00 1987 Date-Received: Wed, 29-Jul-87 01:16:05 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 36 Larry, See the delightful little book "Cotswold Privies" by Mollie Harris and Sue Chapman (Hogarth Press, London 1984) for a full, complete and satisfying definition of the word. In sweet, a gongfermer is the poor (but well-paid) lad who cleaned out the privies in yesteryesteryear. Any similarity, functional or otherwise, to departmental of industrial institutions is stoutly denied. Why did I use this wonderful 15th-century word? Because I hoped to get a message like yours. Dave ----- Forwarded message # 1: Received: from Louie.UDEL.EDU by Huey.UDEL.EDU id aa05649; 27 Jul 87 14:25 EDT Received: from bbncc-eur.arpa by Louie.UDEL.EDU id a010057; 27 Jul 87 11:23 EDT Date: Mon, 27 Jul 87 17:02:50 GMT+0100 From: "Lawrence J. Kaufman" Subject: Re: Wollongong telnet and new line processing In-Reply-To: Your message of Tue, 21 Jul 87 22:03:44 EDT To: Mills@louie.udel.edu Cc: lkaufman@bbncc-eur.arpa Message-ID: <8707271123.a010057@Louie.UDEL.EDU> Dave, Would you please explain gongfermer to a poor city boy? What does a privy farmer do and why are you using a 15th century word? --- Larry Kaufman lkaufman@bbn.com now in Germany, moving to Maryland in the next week or so. ----- End of forwarded messages ----MESSAGE-END---- ----MESSAGE-BEGIN---- [233720.870727.JBVB@AI.AI.MIT.EDU] <1987072718221200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Follow-on to my "Re: IBM TCP/IP" msg. Message-ID: <233720.870727.JBVB@AI.AI.MIT.EDU> Date: Mon, 27-Jul-87 22:22:12 EDT Article-I.D.: AI.233720.870727.JBVB Posted: Mon Jul 27 22:22:12 1987 Date-Received: Wed, 29-Jul-87 01:50:54 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 In further discussion of IBM's non-standard approach to ARP and routing on 802.5, someone else pointed out that there is little chance that their source-routing and RIF fields will ever work through a MAC-level bridge between Ether and Token-Ring. Hi ho. I wonder if they care? jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [281@unixprt.UUCP] <1987072720150900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: monkey@unixprt.UUCP (Monkey Face@unixprt) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <281@unixprt.UUCP> Date: Tue, 28-Jul-87 00:15:09 EDT Article-I.D.: unixprt.281 Posted: Tue Jul 28 00:15:09 1987 Date-Received: Wed, 29-Jul-87 04:13:59 EDT Organization: uni-xperts - Unix System and Networking Consultants Lines: 29 Keywords: TCP/IP, Streams Summary: STREAMS vs. Sockets I'm not sure that this is worth it, but what the heck... In article <24072@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: > > The primary advantage, for those using ATT based UNIX, is that this is the > > only 'real' facility provided in UNIX System V to support networking. > Gee...people at Berkeley have been using an "AT&T-based UNIX"... > that supports networking without STREAMS. Plenty of other > people have dropped the socket code into System V kernels... > Berkeley dropped it into a 32V-derived kernel, so STREAMS are not > "the only game in town". I only meant that STREAMS is what you get with the current versions from ATT, without the cost of re-porting to each new AT&T release, you don't get sockets or anything else. A vendor that must rely on ATT to provide a base, a strategy based on sockets does not seem appropriate in the long term. > > ATT's Transport Interface is mostly base on the ISO transport interface, > > therefore should map to the emerging interface standards. > Unfortunately, the TLI also has a number of warts...it keeps some state > both in userland and in the kernel...after a "fork"/"exec" you > have to issue a "t_sync" call to...(get)... kernel's...state into userland. > Guy Harris So what? Warts can be removed, if deemed necessary. My response to a question someone asked was not meant to support or criticize STREAMS or the Socket implementation in 4.x based systems. I was only offering my opinion based on experience with STREAMS. I have also ported the socket code the System V version of UNIX and think that sockets are a very good base for network implementation. How tall is Guy Harris anyway? Monkey Face - uni-xperts ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707281815.AA00206@ucbvax.Berkeley.EDU] <1987072803090000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU ("I am only an egg.") Newsgroups: comp.protocols.tcp-ip Subject: adversity or perversity Message-ID: <8707281815.AA00206@ucbvax.Berkeley.EDU> Date: Tue, 28-Jul-87 07:09:00 EDT Article-I.D.: ucbvax.8707281815.AA00206 Posted: Tue Jul 28 07:09:00 1987 Date-Received: Thu, 30-Jul-87 00:39:42 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 30 Hi! I have a problem and I'm not sure I believe what I see. I have an ethernet with disparate tcp's around on it. We have bsd 4.3, Symbolics, Sun release 3.2, Micom np100 board running tcp among others. I'm in the middle of changing network numbers. Now, networks on the same ethernet won't talk to each other. It seems as if IP wants to have one network number per ethernet. I really don't see why this should be so. Is this the way of IP? Does it really want one network number per ethernet? Is there an RFC that says this should be so? If so then which one so I can go look? If it isn't IP is it the the perversity of ethernet interface manufacturers? USnail: Chris Johnson Academic Computer Services Northeastern University 39RI 360 Huntington Ave. Boston, MA. U.S.A. 02115 AT&T: (617) 437-2335 CSNET: johnson@nuhub.acs.northeastern.edu ARPANET: johnson%nuhub.acs.northeastern.edu@relay.cs.net BITNET: johnson%nuhub.acs.northeastern.edu@csnet-relay (Always vote. There may not be anything you want to vote for, but there might be something you want to vote against.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072803090001> Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Tue 28 Jul 87 10:56:01-PDT Received: from relay2.cs.net by RELAY.CS.NET id ad15315; 28 Jul 87 13:25 EDT Received: from northeastern.edu by RELAY.CS.NET id ac02039; 28 Jul 87 13:21 EDT Date: Tue, 28 Jul 87 07:09 EDT From: "I am only an egg." Subject: adversity or perversity To: tcp-ip@SRI-NIC.ARPA X-VMS-To: NET%"tcp-ip@sri-nic.arpa" Hi! I have a problem and I'm not sure I believe what I see. I have an ethernet with disparate tcp's around on it. We have bsd 4.3, Symbolics, Sun release 3.2, Micom np100 board running tcp among others. I'm in the middle of changing network numbers. Now, networks on the same ethernet won't talk to each other. It seems as if IP wants to have one network number per ethernet. I really don't see why this should be so. Is this the way of IP? Does it really want one network number per ethernet? Is there an RFC that says this should be so? If so then which one so I can go look? If it isn't IP is it the the perversity of ethernet interface manufacturers? USnail: Chris Johnson Academic Computer Services Northeastern University 39RI 360 Huntington Ave. Boston, MA. U.S.A. 02115 AT&T: (617) 437-2335 CSNET: johnson@nuhub.acs.northeastern.edu ARPANET: johnson%nuhub.acs.northeastern.edu@relay.cs.net BITNET: johnson%nuhub.acs.northeastern.edu@csnet-relay (Always vote. There may not be anything you want to vote for, but there might be something you want to vote against.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [513@atlas.UUCP] <1987072804145400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jjensen@atlas.UUCP (Jim Jensen) Newsgroups: comp.protocols.tcp-ip Subject: Re: SEVERAL copies of message received Message-ID: <513@atlas.UUCP> Date: Tue, 28-Jul-87 08:14:54 EDT Article-I.D.: atlas.513 Posted: Tue Jul 28 08:14:54 1987 Date-Received: Thu, 30-Jul-87 01:19:24 EDT References: <8707261432.AA26072@ucbvax.Berkeley.EDU> Distribution: world Organization: Gould CSD, Fort Lauderdale, FL Lines: 19 in article <8707261432.AA26072@ucbvax.Berkeley.EDU>, george@EGLIN-VAX.ARPA ("CALVIN R. GEORGE") says: > I know I have read 6 copies of the one from Jim Jensen ( GOULD ) about > the BSD 4.3 problem. > > Calvin George > Eglin AFB, FL Sorry about that. I posted the article, and got an error message. I then had show this to someone who knew about news. Then someone else. then with a different news program, and so on. The next time I read news there were all the articles. I was kind of hoping that only the last one with no error messege got out. Oh well. Jim Jensen Gould inc. CSD 6901 West Sunrise Boulevard Ft. Lauderdale Fl 33313-4499 (305) 587-2900 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707281943.AA02198@ucbvax.Berkeley.EDU] <1987072805322800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: A024012@RUTVM1.BITNET (Ross Patterson) Newsgroups: comp.protocols.tcp-ip Subject: Re: Does IBM TCP/IP Source Route? Message-ID: <8707281943.AA02198@ucbvax.Berkeley.EDU> Date: Tue, 28-Jul-87 09:32:28 EDT Article-I.D.: ucbvax.8707281943.AA02198 Posted: Tue Jul 28 09:32:28 1987 Date-Received: Thu, 30-Jul-87 01:34:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 95 I posted a copy of Bill Westfield's question to IBMTCP-L@CUNYVM.BITNET, which discusses IBM's new TCP/IP for VM/SP program (IBM program #5798-FAL, not to be confused with WiscNet (5798-DRG)). It elicited two reponses, one from Jay Elinsky at IBM's Watson Research Center, and one from John Shriver at Proteon. Both are enclosed below. Ross Patterson Rutgers University ------------------ Start of included file TCPIP REPLIES ----------------- Received: from CUNYVM(MAILER) by RUTVM1 (Mailer X1.24) id 1161; Mon, 27 Jul 87 17:47:57 EDT Received: by CUNYVM (Mailer X1.23b) id 8954; Mon, 27 Jul 87 17:47:06 EDT Date: Monday, 27 Jul 1987 17:39:33 EDT Reply-To: IBM TCP/IP For VM List Sender: IBM TCP/IP For VM List From: Jay Elinsky Subject: Does IBM TCP/IP source route all its packets? To: Ross Patterson If he's referring to the IP source routing options e.g. strict source routing, the answer is No. On Token Ring, we use Token Ring source routing for packets that must pass through bridges. Jay Elinsky IBM T.J. Watson Research Center Yorktown Heights, NY --------------------------- Received: from CUNYVM(MAILER) by RUTVM1 (Mailer X1.24) id 1245; Mon, 27 Jul 87 19:10:26 EDT Received: by CUNYVM (Mailer X1.23b) id 3703; Mon, 27 Jul 87 19:08:54 EDT Date: Mon, 27 Jul 87 18:58:50 EDT Reply-To: IBM TCP/IP For VM List Sender: IBM TCP/IP For VM List X-To: IBMTCP-L%CUNYVM.BITNET@WISCVM.WISC.EDU From: "John A. Shriver" Subject: Re: Does IBM TCP/IP source route all its packets? To: Ross Patterson In-Reply-To: Jay Elinsky's message of Monday, 27 Jul 1987 17:39:33 EDT <8707272226.AA25652@monk.proteon.com> Yes, it indeed source routes. A bit of background on how the 802.2 class 2 does it's source routing. When opening a connection, the first thing done in 802.2 is to swap XID (exchange ID) packets, to see that you both speak class 2. The calling interface sends the XID to the called address as a normal packet. If it does not get "address recognized" in the frame status byte after some number of tries, it decides the called host is off-ring. It then modifies the XID packet to set the U bit of the source address (I call this "bridge-me"), and to include an empty routing information field (RIF) with the broadcast (all rings) bit set. Each bridge will add it's entry to the RIF. The called party will receive the XID, and will (1) store the source route in the connection block, (2) clear the broadcast bit in the RIF, (3) flip the direction bit in the RIF, and (4) update the XID information and send the packet back. The caller will receive the reply XID, and store that source route in the connection block. The IBM and TI 802.2 software does not offer this convenience for class 1 operations. Probably the main reason is that there is no connection block to store the data in. This does not bother the architects of source routing, since all IBM applications (except TCP/IP) use class 2. The network layer is repsonsible for developing and providing RIF fields. However, since TCP/IP uses ARP to find addresses, there is a convenient broadcast packet to use to thread bridges. You just send the ARP as a "all rings" broadcast, setting the "bridge-me" bit and the broadcast bit in the RIF. This does not make for a standard ARP implementation. You've got to add an entry to the data blocks for the RIF, as well as the hadrware address, for each protocol (IP) address. You've also got to extend the calling interface into the datalink, but only for 802.5. This is not clean when you are trying to use the same code to support multiple datalinks or network protocols at the same time. The details of what IBM did for ARP/source routing in each TCP/IP vary. In the PC version, they do not try and do a "this ring only" broadcast before doing an "all rings" braodcast. (This is due to the way PC/IP does ARP without a seperate ARP task). Thus it cannot make a connection with an implementation that does not source route. Other versions have a switch to turn on source routing (eg AIX?). It would be nice if all versions tried without RIF first, looking for addresses recognized, to talk to other versions that don't do RIFs. Only if they don't get address recognized would they start trying to source-route via ARP. Another thought: one way to make this clean would be to switch to a special ARP hardware type just for 802.5, and put the RIF in as part the hardware address. This would make code a lot cleaner, since 802.2 also has to support non-source-route LANs, like 802.3 and 802.4. ------------------ End of included file TCPIP REPLIES ----------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072805322801> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Tue 28 Jul 87 12:16:24-PDT Received: from RUTVM1.BITNET by wiscvm.wisc.edu ; Tue, 28 Jul 87 11:09:08 CDT Received: by RUTVM1 (Mailer X1.24) id 1719; Tue, 28 Jul 87 09:39:27 EDT Date: Tue, 28 Jul 87 09:32:28 EDT From: Ross Patterson Subject: Re: Does IBM TCP/IP Source Route? To: TCP-IP@SRI-NIC.ARPA I posted a copy of Bill Westfield's question to IBMTCP-L@CUNYVM.BITNET, which discusses IBM's new TCP/IP for VM/SP program (IBM program #5798-FAL, not to be confused with WiscNet (5798-DRG)). It elicited two reponses, one from Jay Elinsky at IBM's Watson Research Center, and one from John Shriver at Proteon. Both are enclosed below. Ross Patterson Rutgers University ------------------ Start of included file TCPIP REPLIES ----------------- Received: from CUNYVM(MAILER) by RUTVM1 (Mailer X1.24) id 1161; Mon, 27 Jul 87 17:47:57 EDT Received: by CUNYVM (Mailer X1.23b) id 8954; Mon, 27 Jul 87 17:47:06 EDT Date: Monday, 27 Jul 1987 17:39:33 EDT Reply-To: IBM TCP/IP For VM List Sender: IBM TCP/IP For VM List From: Jay Elinsky Subject: Does IBM TCP/IP source route all its packets? To: Ross Patterson If he's referring to the IP source routing options e.g. strict source routing, the answer is No. On Token Ring, we use Token Ring source routing for packets that must pass through bridges. Jay Elinsky IBM T.J. Watson Research Center Yorktown Heights, NY --------------------------- Received: from CUNYVM(MAILER) by RUTVM1 (Mailer X1.24) id 1245; Mon, 27 Jul 87 19:10:26 EDT Received: by CUNYVM (Mailer X1.23b) id 3703; Mon, 27 Jul 87 19:08:54 EDT Date: Mon, 27 Jul 87 18:58:50 EDT Reply-To: IBM TCP/IP For VM List Sender: IBM TCP/IP For VM List X-To: IBMTCP-L%CUNYVM.BITNET@WISCVM.WISC.EDU From: "John A. Shriver" Subject: Re: Does IBM TCP/IP source route all its packets? To: Ross Patterson In-Reply-To: Jay Elinsky's message of Monday, 27 Jul 1987 17:39:33 EDT <8707272226.AA25652@monk.proteon.com> Yes, it indeed source routes. A bit of background on how the 802.2 class 2 does it's source routing. When opening a connection, the first thing done in 802.2 is to swap XID (exchange ID) packets, to see that you both speak class 2. The calling interface sends the XID to the called address as a normal packet. If it does not get "address recognized" in the frame status byte after some number of tries, it decides the called host is off-ring. It then modifies the XID packet to set the U bit of the source address (I call this "bridge-me"), and to include an empty routing information field (RIF) with the broadcast (all rings) bit set. Each bridge will add it's entry to the RIF. The called party will receive the XID, and will (1) store the source route in the connection block, (2) clear the broadcast bit in the RIF, (3) flip the direction bit in the RIF, and (4) update the XID information and send the packet back. The caller will receive the reply XID, and store that source route in the connection block. The IBM and TI 802.2 software does not offer this convenience for class 1 operations. Probably the main reason is that there is no connection block to store the data in. This does not bother the architects of source routing, since all IBM applications (except TCP/IP) use class 2. The network layer is repsonsible for developing and providing RIF fields. However, since TCP/IP uses ARP to find addresses, there is a convenient broadcast packet to use to thread bridges. You just send the ARP as a "all rings" broadcast, setting the "bridge-me" bit and the broadcast bit in the RIF. This does not make for a standard ARP implementation. You've got to add an entry to the data blocks for the RIF, as well as the hadrware address, for each protocol (IP) address. You've also got to extend the calling interface into the datalink, but only for 802.5. This is not clean when you are trying to use the same code to support multiple datalinks or network protocols at the same time. The details of what IBM did for ARP/source routing in each TCP/IP vary. In the PC version, they do not try and do a "this ring only" broadcast before doing an "all rings" braodcast. (This is due to the way PC/IP does ARP without a seperate ARP task). Thus it cannot make a connection with an implementation that does not source route. Other versions have a switch to turn on source routing (eg AIX?). It would be nice if all versions tried without RIF first, looking for addresses recognized, to talk to other versions that don't do RIFs. Only if they don't get address recognized would they start trying to source-route via ARP. Another thought: one way to make this clean would be to switch to a special ARP hardware type just for 802.5, and put the RIF in as part the hardware address. This would make code a lot cleaner, since 802.2 also has to support non-source-route LANs, like 802.3 and 802.4. ------------------ End of included file TCPIP REPLIES ----------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072806110800> Received: from PS1.CS.CMU.EDU by SRI-NIC.ARPA with TCP; Tue 28 Jul 87 08:06:23-PDT Date: 28 Jul 1987 11:11:08 EST From: Dale.Moore@PS1.CS.CMU.EDU To: Info-vax@KL.SRI.COM, Tektcp@HAMLET.CALTECH.EDU, tcp-ip@SRI-NIC.ARPA Subject: CMU-TEK Announcement A few simple questions.... Are you looking for a well integrated IP/TCP on VMS? Are you tired of paying your annual salary per machine for networking software you use one hour a day? Are you despondent over not having the sources to make the simple changes necessary to fix relatively minor problems? If you answered yes to all the above, then have we got something for you. It's not swamp land in Florida, nor is it prime gold fields in Alaska. It's CMU-TEK IP/TCP for VMS. For only $0 (thats Z-E-R-O dollars) you get - Common network utilities such as Telnet, FTP and Finger. - Domain network name resolver. - A mail generation and sending program. - Network servers for Telnet, FTP, SMTP and Finger. - An ACP process and device driver that implements IP, ICMP, TCP and as an extra special bonus UDP. - Subnets and packet reassembly. - Sources to utilities. Sources to documentation. Sources to everything above that we can write on a tape. What you don't get - Large monthly installment payment plan - Heavy Liscensing restrictions. This is available to anyone, profit or nonprofit on any VAX processor. Soon we will be able to send this to all 'reasonable' countries. - A big corporation with a three character name abbreviation. - 24 Hour telephone hotline support. As a matter of fact, you get very little support. - User training seminars. You'll have to find some other reason to get a free Road-Trip out of your employer. - Warranties. No warranties expressed or implied. - VMS, BLISS or SCRIBE. To recompile the sources and documentation, these necessary tools are not provided. All of this, and VMSINSTAL compatible. Some of you maybe skeptical. Perhaps you think that this is only a minor change over what is available from Tektronix. Things do change, and now they've changed for the better. Some of you have refered to this as the CMU `enhanced' Tektronix code. When you put flowers in the flower box outside your window, you enhance the building. When rip out and replace the plumbing, heating, electric and replaster and repaint all the walls, and put on new siding, insulation and roofing you've rebuilt. It is no longer necessary to obtain a liscense from Tektronix to run the CMU software. To get a copy, send a US Postal Snail Mail letter to CMU-TEK IP/TCP Software Request Computation Center Carnegie Mellon University 4910 Forbes Av. Pittsburgh, PA 15213 No warranties expressed or implied. Postage and Handling may be extra. Lifetime of offer limited. All rights reserved. Hey, I mean it! We don't mind giving the stuff away, but we don't want it stolen! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [AV3=-0y00WE14X40=U@andrew.cmu.edu] <1987072806173600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mw3s+@ANDREW.CMU.EDU (Martin Weiss) Newsgroups: comp.protocols.tcp-ip Subject: Streams Message-ID: Date: Tue, 28-Jul-87 10:17:36 EDT Article-I.D.: andrew.AV3=-0y00WE14X40=U Posted: Tue Jul 28 10:17:36 1987 Date-Received: Wed, 29-Jul-87 06:42:31 EDT References: <649@houxa.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 3 A recent article in either Business Communications Review or Data Communications discusses STREAMS and Streams. It compares the communications facilities for both Unix System V and BSD. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [142@hippo.UUCP] <1987072807213800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: eric@hippo.UUCP (Eric Bergan) Newsgroups: comp.protocols.tcp-ip Subject: Re: Help: TCP/IP for business application Message-ID: <142@hippo.UUCP> Date: Tue, 28-Jul-87 11:21:38 EDT Article-I.D.: hippo.142 Posted: Tue Jul 28 11:21:38 1987 Date-Received: Wed, 29-Jul-87 07:06:35 EDT References: <8707271621.AA06031@phun.riacs.edu> <12321742542.23.OKUNO@SUMEX-AIM.STANFORD.EDU> Organization: HEALTHCARE 2000 Lines: 15 In article <12321742542.23.OKUNO@SUMEX-AIM.STANFORD.EDU>, Okuno@SUMEX-AIM.STANFORD.EDU (Hiroshi "Gitchang" Okuno) writes: > I want to know whether TCP/IP is used in applications such as banking > system, car registration system, information retrieval system or other > database management system (centralized or distributed). At Johns Hopkins Hospital, we used TCP/IP to implement a wide range of distributed database applications, including patient identification, scheduling, radiology film tracking, radiology report transcription and retrieval, etc. For all of the distributed pieces, we used Sun's RPC protocol. -- eric ...!ptsfa!hippo!eric ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707281511.AA04543@ucbvax.Berkeley.EDU] <1987072808110800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Dale.Moore@PS1.CS.CMU.EDU Newsgroups: comp.protocols.tcp-ip Subject: CMU-TEK Announcement Message-ID: <8707281511.AA04543@ucbvax.Berkeley.EDU> Date: Tue, 28-Jul-87 12:11:08 EDT Article-I.D.: ucbvax.8707281511.AA04543 Posted: Tue Jul 28 12:11:08 1987 Date-Received: Wed, 29-Jul-87 06:46:03 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 67 A few simple questions.... Are you looking for a well integrated IP/TCP on VMS? Are you tired of paying your annual salary per machine for networking software you use one hour a day? Are you despondent over not having the sources to make the simple changes necessary to fix relatively minor problems? If you answered yes to all the above, then have we got something for you. It's not swamp land in Florida, nor is it prime gold fields in Alaska. It's CMU-TEK IP/TCP for VMS. For only $0 (thats Z-E-R-O dollars) you get - Common network utilities such as Telnet, FTP and Finger. - Domain network name resolver. - A mail generation and sending program. - Network servers for Telnet, FTP, SMTP and Finger. - An ACP process and device driver that implements IP, ICMP, TCP and as an extra special bonus UDP. - Subnets and packet reassembly. - Sources to utilities. Sources to documentation. Sources to everything above that we can write on a tape. What you don't get - Large monthly installment payment plan - Heavy Liscensing restrictions. This is available to anyone, profit or nonprofit on any VAX processor. Soon we will be able to send this to all 'reasonable' countries. - A big corporation with a three character name abbreviation. - 24 Hour telephone hotline support. As a matter of fact, you get very little support. - User training seminars. You'll have to find some other reason to get a free Road-Trip out of your employer. - Warranties. No warranties expressed or implied. - VMS, BLISS or SCRIBE. To recompile the sources and documentation, these necessary tools are not provided. All of this, and VMSINSTAL compatible. Some of you maybe skeptical. Perhaps you think that this is only a minor change over what is available from Tektronix. Things do change, and now they've changed for the better. Some of you have refered to this as the CMU `enhanced' Tektronix code. When you put flowers in the flower box outside your window, you enhance the building. When rip out and replace the plumbing, heating, electric and replaster and repaint all the walls, and put on new siding, insulation and roofing you've rebuilt. It is no longer necessary to obtain a liscense from Tektronix to run the CMU software. To get a copy, send a US Postal Snail Mail letter to CMU-TEK IP/TCP Software Request Computation Center Carnegie Mellon University 4910 Forbes Av. Pittsburgh, PA 15213 No warranties expressed or implied. Postage and Handling may be extra. Lifetime of offer limited. All rights reserved. Hey, I mean it! We don't mind giving the stuff away, but we don't want it stolen! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12107@hi.UUCP] <1987072808365400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kurt@hi.UUCP (Kurt Zeilenga) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Multiple netmasks Message-ID: <12107@hi.UUCP> Date: Tue, 28-Jul-87 12:36:54 EDT Article-I.D.: hi.12107 Posted: Tue Jul 28 12:36:54 1987 Date-Received: Wed, 29-Jul-87 07:25:24 EDT Reply-To: kurt@hi.UUCP (Kurt Zeilenga) Organization: U. of New Mexico, Albuquerque Lines: 45 Keywords: At present, if you want to break up a network into different size subnets there is really no way of doing it. Hence, I would like to (re)start a discussion on ways of implementing multiple masks for said purpose. How does the system know wether a given address is an A, B, or C Class address? It looks at magic bits that are hardcoded! It would be really nice to be able to softcode some bits. Hence, every network could have a subnetmask. The subnetmask is used to mask out n bits of the IP address. Those n bits are then used to lookup what netmask to use. Consider Host A: /etc/ifconfig ie0 0xXXXXf001 subnetmask 0x0000c000 up /etc/ifconfig ie1 0xXXXX0081 subnetmask 0x0000c000 up and Host B: /etc/ifconfig ie0 0xXXXXf002 subnetmask 0x0000c000 up /etc/ifconfig ie1 0xXXXX8101 subnetmask 0x0000c000 up and in /etc/subnets (or wherever) there are three fields. Network, Subnet, Mask. This so that if you have a gateway between to different networks each doing subnetmasking. 0xXXXX0000 0x0000c000 0xfffff000 0xXXXX0000 0x00008000 0xffffff00 0xXXXX0000 0x00004000 0xffffff80 0xXXXX0000 0x00000000 0xffffffc0 Okay, say host A gets a packet off of ie1. The packet is for IP address 0xXXXX8102. We mask the address with the subnetmask and get 0x00008000, lookup the netmask and get 0xffffff00. Using it we figure out that we need to send this to host 2 on network 0xXXXX8100. We look in the routing table and see that we ahve a rout to 0xXXXX8100 via 0xXXXXf002, we send the packet off..... Of course there are problems with this idea, but it's a start. Any comments? -- Kurt Zeilenga (zeilenga@hc.dspo.gov) I want my talk.flame! "Remember, Mommie, I'm off to get a commie..." ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072810220000> Received: from acc.arpa by SRI-NIC.ARPA with TCP; Tue 28 Jul 87 18:42:17-PDT Date: 28 Jul 87 18:22:00 PST From: Subject: Re: Streams TCP/IP To: "tcp-ip" Reply-To: >Would someone please post a summary of reasons why use of Streams is >an advantage. Is this just another sales-hype buzzword? or is there >a reason Streams is better? than sockets? than psudo-sockets? or >select? Does the end user see any advantage? faster response? less >CPU waste? what? Does anyone have some before & after figures on >drivers that were converted to Streams? Please share them with us. Lets not compare apples and oranges here. STREAMs is an architectural feature of the System V Rel 3 UNIX kernel. STREAMs are to the kernel what pipes are to users, allowing various kernel components to connected in useful configurations. This is the base used for kernel resident communications support in Sys V Rel 3. Sockets in the Berkeley UNIX world can mean a couple of things, the socket systems calls or the architecture of the kernel resident protocol implementations. In my opinion, the STREAMs mechanism is a much cleaner way to implement things like communications protocols in the kernel (but there are some limitations). The user interface to streams can be nearly anything you could want, but normally is via the Transport Level Interface (TLI) which is a stream module which is intended to present a standard transport service interface to users. Most of the TCP/IP implementations that I have seen for STREAMs provide the socket interface, either via new systems calls or via an interface emulation library. As far as performance, I would suspect that a STREAMs implementation would be at least as fast as functionally equivalent code in the Berkeley kernel. Art Berggreen art@acc.arpa ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707281841.AA26723@ACC-SB-UNIX.ARPA] <1987072810415800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lars@ACC-SB-UNIX.ARPA (Lars Poulsen) Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8707281841.AA26723@ACC-SB-UNIX.ARPA> Date: Tue, 28-Jul-87 14:41:58 EDT Article-I.D.: ACC-SB-U.8707281841.AA26723 Posted: Tue Jul 28 14:41:58 1987 Date-Received: Thu, 30-Jul-87 01:21:27 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 17 Date: Tue, 28 Jul 87 11:12:16 PDT From: lars (Lars Poulsen) To: hank%barilvm.BITNET@WISCVM.ARPA Subject: ACC Customer Service Network Address Cc: tcp-ip@sri-nic.arpa ACC's Customer Service is reachable as follows: (1) By email: service@acc-sb-unix.arpa (2) By phone: (800) 222-7308 (Not from CA, AK, HI and foreign countries) (805) 963-9431 (From anywhere) (3) By FAX: (805) 966-9725 (4) By TWX: 910 334-4907 This in response to Hank Nussbacher's message of July 23, 1987. Sorry, we are sometimes behind on reading "news". / Lars Poulsen, ACC Customer Service - Support ----MESSAGE-END---- ----MESSAGE-BEGIN---- [24335@sun.uucp] <1987072810591100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <24335@sun.uucp> Date: Tue, 28-Jul-87 14:59:11 EDT Article-I.D.: sun.24335 Posted: Tue Jul 28 14:59:11 1987 Date-Received: Thu, 30-Jul-87 02:36:47 EDT References: <281@unixprt.UUCP> Sender: news@sun.uucp Lines: 38 Keywords: TCP/IP, Streams I won't bother replying to the whiny little question at the end, but I will point out a couple of things: > I only meant that STREAMS is what you get with the current versions from > ATT, without the cost of re-porting to each new AT&T release, you > don't get sockets or anything else. A vendor that must rely on ATT > to provide a base, a strategy based on sockets does not seem appropriate > in the long term. That depends on several things. First, it depends on whether the vendor wants to continue to depend on AT&T to provide a base, especially given the S5R3 licensing agreement. Second, it depends on whether they want to re-port the rest of what they've done to S5R3. Yes, STREAMS comes "for free" with S5R3. This is not necessarily sufficient to make it the best way to go. Unisoft, I believe, offers a socket implementation as part of their S5 ports. > So what? Warts can be removed, if deemed necessary. It is not necessarily that easy. The TLI uses the state information that is kept in userland; it might have to be redesigned to remove this particular wart. It is not a given that the TLI will be the interface used for future protocol implementations; a socket-based ISO implementation (which may require changes to the socket interface) or some completely different C-language binding of network operations may end up being dominant. > My response to a question someone asked was not meant to support or > criticize STREAMS or the Socket implementation in 4.x based systems. My response wasn't meant to do that either; it was meant to point out the other side of various issues. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy *! AFN"("(". ----MESSAGE-END---- ----MESSAGE-BEGIN---- [24336@sun.uucp] <1987072811184200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <24336@sun.uucp> Date: Tue, 28-Jul-87 15:18:42 EDT Article-I.D.: sun.24336 Posted: Tue Jul 28 15:18:42 1987 Date-Received: Thu, 30-Jul-87 02:45:19 EDT References: <725@hjuxa.UUCP> <649@houxa.UUCP> <278@unixprt.UUCP> <561@applix.UUCP> <965@geac.UUCP> Sender: news@sun.uucp Lines: 61 > There is interest in streams for several reasons. > 1) It looks elegant. However, in practice there are some rather inelegant parts. Doing an "ioctl" on a stream, for example, is a pain in the neck, as a streams module or driver is notified of the "ioctl" by receiving a message, and it must construct a reply message in order to respond to the "ioctl". Since streams modules and drivers do not necessarily run in the context of a process, even when servicing a request made in a process (e.g., a "write" or an "ioctl"), they cannot block; thus, if a memory allocation fails, you have to go through some amount of contortions to retry the allocation if it's important to do so. Were STREAMS to be implemented on top of a kernel that supported "lightweight processes", one could guarantee that streams modules and drivers ran in the context of a thread of control that could safely block, which would considerably simplify this. The read side of a stream is driven by pressure from the bottom; there is little a streams module or driver can do in response to a "read". This may be a problem for some uses of STREAMS. If you want a STREAMS-based terminal driver, there will be some problems with sharing a single pool of buffer resources between the networking code and the terminal driver; it makes it more likely that networking operations will exhaust these resources. (RSX-11 users may remember that - at least in some versions, they may have fixed this later - a process that consumed all of pool space, or just sufficient pool space as to prevent the tty driver from doing a read, could hang the system fairly thoroughly.) This is not an insuperable problem, but it means you have to be careful. When writing a streams module or driver, there is often a lot of "bureaucratic" code that has to be added to handle various message types, to construct messages, etc.; don't assume things are going to get smaller if you go to STREAMS. > 2) It comes from an acknowleged Unix expert. The concept is the same in Dennis Ritchie's version and in the S5R3 version, but some of the details are different. I believe the S5R3 version is bigger and more complicated. > 3) It *looks* (emphais added) more general than sockets. Since it imposes less structure, it is. Sockets correspond roughly to streams+TLI. > 4) It allows a structured decomposition of some of the > hot-spots in Unix (terminal handling, protocols) > into subparts which can be placed on a front-end > processor. Probably true, although this depends on what the streams modules that implement a given function are. It may be that the decomposition that makes the most architectural sense isn't the decomposition that makes sense for a particular front-end processor. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [450@pluto.UUCP] <1987072811484600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: warren@pluto.UUCP (Warren Burstein) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong TCP/IP for Sys V Message-ID: <450@pluto.UUCP> Date: Tue, 28-Jul-87 15:48:46 EDT Article-I.D.: pluto.450 Posted: Tue Jul 28 15:48:46 1987 Date-Received: Sat, 1-Aug-87 04:51:19 EDT References: <443@pluto.UUCP> Reply-To: warren@pluto.UUCP (Warren Burstein) Distribution: world Organization: Industrial Automation Systems, New York, NY Lines: 17 Summary: Sorry, my last posting on this subject was very wrong In article <443@pluto.UUCP> warren@pluto.UUCP (Warren Burstein) writes: : :I asked my boss to order TCP/IP from Wollongong for a 3B2 and he came :back and told me they stopped selling it because too many people were :ripping it off and they won't sell it until they come up with a way to :keep it from being stolen. I posted this yesterday and today I got a phone call from Wollongong. It seems that ATT has the exclusive to sell this product, and I got a contact to find out what the problem is with the ATT side. Sorry for the misinformation. -- /|/~\~~\ The entire world Warren Burstein |__/__/_/ is a very strange carrot. | But the farmer philabs!tg!pluto!warren / is not afraid at all. Why doesn't life come with subtitles? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2121@sphinx.uchicago.edu] <1987072812524600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kdw1@sphinx.uchicago.edu (Keith Waclena) Newsgroups: comp.protocols.tcp-ip Subject: E-mail address for Wollongong Group wanted Message-ID: <2121@sphinx.uchicago.edu> Date: Tue, 28-Jul-87 16:52:46 EDT Article-I.D.: sphinx.2121 Posted: Tue Jul 28 16:52:46 1987 Date-Received: Thu, 30-Jul-87 01:30:40 EDT Reply-To: kdw1@sphinx.uchicago.edu (Keith Waclena) Distribution: na Organization: University of Chicago, Graduate Library School Lines: 54 We just installed Enhanced TCP/IP WIN/3B from the Wollongong Group on our AT&T 3B15 running System V r2.1. I am new at administering TCP/IP and am having some trouble with the library routines. Ftp, rlogin and the like are working just fine. Does anyone have an E-mail address for someone at the Wollongong Group that can give me some advice? Do they maintain some sort of mailing list or whatever? Please respond by mail as I don't normally read this newsgroup. Just in case anyone else out there can help, here's a brief description of my problems. I let Wollongong's install script do the work of installation. It gives me a /usr/netinclude directory for things like socket.h. Why are they not in /usr/include? Is there any reason why I shouldn't just cp them in there? I have to conditionalize source code in order for the .h's to be found. The man pages for the socket compatibility library refer to the .h's as if they live in /usr/include. I also find /usr/lib/libnet.a. Am I supposed to use this via -lnet? I get similar (non)results whether I do or don't. Typical problems have shown up in two short programs I tried to compile as tests. One is Rob Jacobs wm (window manager) which has compiled and run just fine on about four machines that *I've* tried it on. But when I try it on the 3B15, I get the following error from select(): Bad address. (aka EFAULT) The exact lines of code are: int readmask; readmask = 01; while (select(8*sizeof(readmask), &readmask, 0, 0, 0) <= 0) perror("select"); What's wrong with this? It loops forever with ``Bad address''. In another program that compiles just fine, the loader barfs and complains that it can't find socketpair(), which is in my set of man pages. This happens with or without -lnet. Any help is much appreciated. My apologies if this is the wrong newsgroup. Keith -- Keith Waclena University of Chicago Graduate Library School 1100 E. 57th Street, Chicago, Illinois 60637 ...ihnp4!gargoyle!sphinx!kdw1 #include kdw1@sphinx.UChicago.{EDU,BITNET,MAILNET,CSNET} ----MESSAGE-END---- ----MESSAGE-BEGIN---- [271@nrc-ut.UUCP] <1987072813370000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mcc@nrc-ut.UUCP (Mecham Computer Associates) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Wanted: Honeywell 6000 TCP/IP Message-ID: <271@nrc-ut.UUCP> Date: Tue, 28-Jul-87 17:37:00 EDT Article-I.D.: nrc-ut.271 Posted: Tue Jul 28 17:37:00 1987 Date-Received: Sat, 1-Aug-87 00:42:55 EDT Reply-To: mcc@nrc-ut.UUCP (Bob McKenzie, Mecham Computer Consultants) Organization: Mecham Computer Consultants, Salt Lake City, UT Lines: 12 I am interested in obtaining any information whatsoever about existing implementations of TCP/IP on the Honeywell 6000. Please respond by mail as I have less-than-regular access to USENET news. Thanks in advance for your help, ===================================================================== Bob McKenzie -- Mecham Computer Consultants ihnp4!nrcvax!nrc-ut!mecham!bob -- USENET utah-cs!utah-gr!uplherc!nrc-ut!mecham!bob@SEISMO.CSS.GOV -- ARPANET ===================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707290156.AA09655@ucbvax.Berkeley.EDU] <1987072818220000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: art@ACC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <8707290156.AA09655@ucbvax.Berkeley.EDU> Date: Tue, 28-Jul-87 22:22:00 EDT Article-I.D.: ucbvax.8707290156.AA09655 Posted: Tue Jul 28 22:22:00 1987 Date-Received: Thu, 30-Jul-87 04:31:35 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Distribution: world Organization: The ARPA Internet Lines: 33 >Would someone please post a summary of reasons why use of Streams is >an advantage. Is this just another sales-hype buzzword? or is there >a reason Streams is better? than sockets? than psudo-sockets? or >select? Does the end user see any advantage? faster response? less >CPU waste? what? Does anyone have some before & after figures on >drivers that were converted to Streams? Please share them with us. Lets not compare apples and oranges here. STREAMs is an architectural feature of the System V Rel 3 UNIX kernel. STREAMs are to the kernel what pipes are to users, allowing various kernel components to connected in useful configurations. This is the base used for kernel resident communications support in Sys V Rel 3. Sockets in the Berkeley UNIX world can mean a couple of things, the socket systems calls or the architecture of the kernel resident protocol implementations. In my opinion, the STREAMs mechanism is a much cleaner way to implement things like communications protocols in the kernel (but there are some limitations). The user interface to streams can be nearly anything you could want, but normally is via the Transport Level Interface (TLI) which is a stream module which is intended to present a standard transport service interface to users. Most of the TCP/IP implementations that I have seen for STREAMs provide the socket interface, either via new systems calls or via an interface emulation library. As far as performance, I would suspect that a STREAMs implementation would be at least as fast as functionally equivalent code in the Berkeley kernel. Art Berggreen art@acc.arpa ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [27@abvax.icd.ab.com] <1987072818560500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: wrk@abvax.icd.ab.com (William R. King) Newsgroups: comp.protocols.tcp-ip Subject: telnet CR processing, bridge comm servers and TWG telnet Message-ID: <27@abvax.icd.ab.com> Date: Tue, 28-Jul-87 22:56:05 EDT Article-I.D.: abvax.27 Posted: Tue Jul 28 22:56:05 1987 Date-Received: Sat, 1-Aug-87 16:08:52 EDT Organization: Allen-Bradley Company, Inc; Industrial Computer Division, Highland Heights, OH Lines: 22 Keywords: telnet TWG Bridge BSD4.3 Last week I posted a query about CR processing. I was able to telnet to TWG telnet from a 4.3 BSD system only if I was connected on a direct line. I was not able to connect when I was logged into the BSD system via a Bridge CS/1. The problem stemed from the connection between the Bridge CS/1 and the BSD 4.3 telnetd. The CS/1 was incorrectly sending \r\n as the line terminator instead of the correct \r\0 sequence. The BSD telnetd converted the \r\n sequence into \n and sent that into the pty. The \n was passed on to TWG telnet which interpeted \n as "delete the word to the left of the cursor". So much for logging in. I have since obtained a new release of Bridge CS/1 software (version 13000) which fixes the problem. They now offer the option (per port) of sending \r\n or \r\0 as the line terminator. I thank the many people who took time to respond. It made life much simpler. Bill King Allen-Bradley Company, Inc. ...!{decvax,pyramid}!abic!wrk ----MESSAGE-END---- ----MESSAGE-BEGIN---- [312@sering.cwi.nl] <1987072901592700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: piet@cwi.nl (Piet Beertema) Newsgroups: comp.protocols.tcp-ip Subject: Re: (none) Message-ID: <312@sering.cwi.nl> Date: Wed, 29-Jul-87 05:59:27 EDT Article-I.D.: sering.312 Posted: Wed Jul 29 05:59:27 1987 Date-Received: Fri, 31-Jul-87 01:36:20 EDT References: <8707271416.AA10134@ucbvax.Berkeley.EDU> Distribution: world Organization: CWI, Amsterdam Lines: 12 >The latest RFC's can be gotten from LISTSERV@TCSVM.BITNET I sure hope that this LISTSERV is more intelligent than other LISTSERV's on BITNET: those aren't at all interested in [the From: lines in] mail headers, only in the envelope information. Unfortunately, when mails pass through gateways to BITNET, the "user" in the envelope tends to be a pseudo user (e.g. MAILER@FOO). -- Piet Beertema, CWI, Amsterdam (piet@cwi.nl) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [334@xios.XIOS.UUCP] <1987072906090700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: peter@xios.XIOS.UUCP (Peter Manson) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <334@xios.XIOS.UUCP> Date: Wed, 29-Jul-87 10:09:07 EDT Article-I.D.: xios.334 Posted: Wed Jul 29 10:09:07 1987 Date-Received: Sat, 1-Aug-87 11:47:59 EDT References: <725@hjuxa.UUCP> Reply-To: peter@xios.UUCP (Peter Manson) Organization: XIOS Systems Corporation, Ottawa, Ontario, Canada Lines: 18 In article <725@hjuxa.UUCP> kp@hjuxa.UUCP (Karen Paszamant) writes: > >what vendors have a System V Release 3.0 streams based tcp/ip product? > At a special session on STREAMS TCP/IP at the March TCP/IP Interoperability Conference, the following vendors were on the panel (so they're at least working on it): Convergent Technologies / Lachmann Associates Excelan The Wollongong Group Counterpoint Interactive Systems Sorry, I don't have addresses, etc. for them. -- Hope this helps. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12322251827.33.VAF@C.CS.CMU.EDU] <1987072907505400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Vince.Fuller@C.CS.CMU.EDU Newsgroups: comp.protocols.tcp-ip Subject: CMU-TEK Announcement Message-ID: <12322251827.33.VAF@C.CS.CMU.EDU> Date: Wed, 29-Jul-87 11:50:54 EDT Article-I.D.: C.12322251827.33.VAF Posted: Wed Jul 29 11:50:54 1987 Date-Received: Fri, 31-Jul-87 04:47:51 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 111 For some reason, this doesn't seem to have made it out. Apologies to any sites that may receive duplicates. Also, to answer a couple of common questions: "I already have a license and distribution. Do I need another?" If you already have a CMU license on file, you don't need another. You do need to send us another tape if you want a more recent version. "The Tektronix license I have says I can't run it on some CPUs (i.e. the Microvax-I or II)" This restriction no longer applies. "The version of the software that I have doesn't have as advertised" You probably have an old version of the software. The base version of the software (the ACP version) that we are currently distributing is 6.2. Older versions will not have all of the advertised features. As stated above, if you want the latest release, send us another tape. At some point, we hope to setup some system for sending updates over the network (but don't hold your breath). "Is the software still restricted to educational institutions only?" In general, no. Our license does restrict use of the software explicitly to the organization obtaining it from us (i.e. no redistribution or selling of it). "Is the software still restricted to use within the United States?" Most of this restriction has been lifted, meaning that most countries not on any technology export-control list may receive this software. If you don't know if you are allowed to receive the software, send a letter to the distribution address listed below - they will find out for you if there are problems. Vince Fuller, Dale Moore CMU-CSD Facilities ------------------------------------------------------------ Date: 28 Jul 1987 11:11:08 EST From: Dale.Moore@PS1.CS.CMU.EDU Subject: CMU-TEK Announcement A few simple questions.... Are you looking for a well integrated IP/TCP on VMS? Are you tired of paying your annual salary per machine for networking software you use one hour a day? Are you despondent over not having the sources to make the simple changes necessary to fix relatively minor problems? If you answered yes to all the above, then have we got something for you. It's not swamp land in Florida, nor is it prime gold fields in Alaska. It's CMU-TEK IP/TCP for VMS. For only $0 (thats Z-E-R-O dollars) you get - Common network utilities such as Telnet, FTP and Finger. - Domain network name resolver. - A mail generation and sending program. - Network servers for Telnet, FTP, SMTP and Finger. - An ACP process and device driver that implements IP, ICMP, TCP and as an extra special bonus UDP. - Subnets and packet reassembly. - Sources to utilities. Sources to documentation. Sources to everything above that we can write on a tape. What you don't get - Large monthly installment payment plan - Heavy Liscensing restrictions. This is available to anyone, profit or nonprofit on any VAX processor. Soon we will be able to send this to all 'reasonable' countries. - A big corporation with a three character name abbreviation. - 24 Hour telephone hotline support. As a matter of fact, you get very little support. - User training seminars. You'll have to find some other reason to get a free Road-Trip out of your employer. - Warranties. No warranties expressed or implied. - VMS, BLISS or SCRIBE. To recompile the sources and documentation, these necessary tools are not provided. All of this, and VMSINSTAL compatible. Some of you maybe skeptical. Perhaps you think that this is only a minor change over what is available from Tektronix. Things do change, and now they've changed for the better. Some of you have refered to this as the CMU `enhanced' Tektronix code. When you put flowers in the flower box outside your window, you enhance the building. When rip out and replace the plumbing, heating, electric and replaster and repaint all the walls, and put on new siding, insulation and roofing you've rebuilt. It is no longer necessary to obtain a liscense from Tektronix to run the CMU software. To get a copy, send a US Postal Snail Mail letter to CMU-TEK IP/TCP Software Request Computation Center Carnegie Mellon University 4910 Forbes Av. Pittsburgh, PA 15213 No warranties expressed or implied. Postage and Handling may be extra. Lifetime of offer limited. All rights reserved. Hey, I mean it! We don't mind giving the stuff away, but we don't want it stolen! ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870729093220.01d@Lbl-Csa1.Arpa] <1987072908322000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: adelman@LBL-CSA1.ARPA (Kenneth Adelman) Newsgroups: comp.protocols.tcp-ip Subject: Re: SMTP for any UNIX on any kind of AT Message-ID: <870729093220.01d@Lbl-Csa1.Arpa> Date: Wed, 29-Jul-87 12:32:20 EDT Article-I.D.: Lbl-Csa1.870729093220.01d Posted: Wed Jul 29 12:32:20 1987 Date-Received: Fri, 31-Jul-87 04:48:16 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Adelman@Lbl-Csa1.Arpa (Kenneth Adelman) Distribution: world Organization: The ARPA Internet Lines: 13 > Folks I need some help. Is there anyone out there that has mil stnd > simple mail runing on any version of an AT under any version of UNIX? The C version of the Software Tools Mail System runs under VMS as well as System III, V, and BSD Unix and many derivatives including Xenix. The current distribution runs on PC/ATs with Xenix and either Excelan or NRC/Fusion TCP/IP and should be readily adaptable to other variants of TCP. Kenneth Adelman LBL ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707291332.aa29108@Huey.UDEL.EDU] <1987072909324200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Wanted: Network Independent File Transfer Protocol (NIFTP) Message-ID: <8707291332.aa29108@Huey.UDEL.EDU> Date: Wed, 29-Jul-87 13:32:42 EDT Article-I.D.: Huey.8707291332.aa29108 Posted: Wed Jul 29 13:32:42 1987 Date-Received: Fri, 31-Jul-87 04:56:26 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 11 Robert, So far as I know, Blue-Book NIFTP was implemented for TOPS-20 and LSI-11 Fuzzballs quite a while ago (circa 1980). When I did the Fuzzball one I started from a C-language program written at University College London. Since the guys that wrote that program have since left UCL, I suggest you contact Prof. Peter Kirstein, whose latest address can be found via WHOIS. With his approval, I can forward the source code, which I still have somewhere on an oxide plow. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707291348.aa29364@Huey.UDEL.EDU] <1987072909483800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Why are these hosts trying to connect? Message-ID: <8707291348.aa29364@Huey.UDEL.EDU> Date: Wed, 29-Jul-87 13:48:38 EDT Article-I.D.: Huey.8707291348.aa29364 Posted: Wed Jul 29 13:48:38 1987 Date-Received: Fri, 31-Jul-87 05:07:07 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 Steve, Your observations are consistent with the scenario that you try to initiate a TCP connection, give up after too short a time, then receive a SYN/ACK from your destination, who might not have given up yet. The clue is the port number, which is outside the range assigned most defined services. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707291353.aa29415@Huey.UDEL.EDU] <1987072909532000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP in business Message-ID: <8707291353.aa29415@Huey.UDEL.EDU> Date: Wed, 29-Jul-87 13:53:20 EDT Article-I.D.: Huey.8707291353.aa29415 Posted: Wed Jul 29 13:53:20 1987 Date-Received: Fri, 31-Jul-87 05:22:57 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Folks, As far as I know, the INTELPOST electronic mail system was the first to adopt TCP/IP circa 1982. This is a facsimile-mail system first built by BBN and then rebuilt by COMSAT Laboratories. It was operated by the US Post Office and overseas affiliates. It use PDP11/40s and the fuzzball network code. I know not if it is still in business. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [948@gvax.cs.cornell.edu] <1987072910123100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jqj@gvax.cs.cornell.edu (J Q Johnson) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Multiple netmasks Message-ID: <948@gvax.cs.cornell.edu> Date: Wed, 29-Jul-87 14:12:31 EDT Article-I.D.: gvax.948 Posted: Wed Jul 29 14:12:31 1987 Date-Received: Fri, 31-Jul-87 05:03:33 EDT References: <12107@hi.UUCP> Reply-To: jqj@gvax.cs.cornell.edu (J Q Johnson) Organization: Cornell Univ. CS Dept, Ithaca NY Lines: 41 In article <12107@hi.UUCP> kurt@hi.UUCP (Kurt Zeilenga) proposes that subnet routing be modified. His proposal, slightly cleaned up, is that: When sending or forwarding to an IP address on a "local" subnetted network (i.e. one for which the system has a directly connected interface), the subnet mask should NOT be used directly to determine routing. Instead, it should be used to mask off a field of the destination IP address, then that field should be used in a table lookup to determine the netmask to use in examining the routing tables. Thus, if net 128.84.0.0 is subnetted into 1 subnet with 16K hosts, 8 subnets with 4K hosts each, plus 1023 subnets with 255 hosts each, the administrators of 128.84.0.0 could legislate that addresses with the 2 highest bits of the third octet set to 0 would be interpreted as 16 bits of net, 8 bits of subnet, and 8 bits of host, while having both of those bits set would be interpreted as 2 bits of subnet and 14 bits of host, and the rest would be interpreted as 4 bits of subnet and 12 bits of host. The table he proposes might have: # subnet index mask is 0x0000c000 # network index value subnet mask 128.84.0.0 0x0000c000 0xffffc000 128.84.0.0 0x00008000 0xfffff000 128.84.0.0 0x00004000 0xfffff000 128.84.0.0 0x00000000 0xffffff00 It seems to me that this scheme would work, although at this point it is unlikely ever to be adopted by the community as a standard. The major problems with it are (1) it is quite complex to administer [I spent 15 minutes constructing the above example, and am not confident I got it right], and (2) it requires that every host that does routing know how the network is broken into subnets (such hosts currently need to know this information, but it consists of only a single number, the subnetmask). Problem (2) is the serious one: almost all host implementations would have to be changed. Given the problems we've had in getting vendors to support the current subnetting scheme, it seems very unlikely that they would change to support such a new scheme. This raises the question of whether there is any less radical way to support variable sized subnets, perhaps a solution that involves changing the code only in gateways. Anyone have any ideas? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870729143044.6.DCP@KOYAANISQATSI.S4CC.Symbolics.COM] <1987072910300000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) Newsgroups: comp.protocols.tcp-ip Subject: Re: IBM TCP. Message-ID: <870729143044.6.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Wed, 29-Jul-87 14:30:00 EDT Article-I.D.: KOYAANIS.870729143044.6.DCP Posted: Wed Jul 29 14:30:00 1987 Date-Received: Fri, 31-Jul-87 05:26:31 EDT References: <232386.870724.JBVB@AI.AI.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Date: Fri, 24 Jul 87 23:32:20 EDT From: "James B. VanBokkelen" I've heard nothing about aberrant behavior on Ether, so apparently they're only punishing their own pioneering customers at the moment.... Maybe they're just trying to go one up on DEC? Remember that DEC violates the spirit of the Ethernet hardware address by forcing the Ethernet address to be algorithmically determined by the DECnet address, resulting in Ethernet addresses which do not indicate the vendor of hardware interface, as well as not ensuring globally unique addresses. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707291901.AA06038@EDDIE.MIT.EDU] <1987072911015200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jsol@EDDIE.MIT.EDU (Jon Solomon) Newsgroups: comp.protocols.tcp-ip Subject: How do you break up a B class number? Message-ID: <8707291901.AA06038@EDDIE.MIT.EDU> Date: Wed, 29-Jul-87 15:01:52 EDT Article-I.D.: EDDIE.8707291901.AA06038 Posted: Wed Jul 29 15:01:52 1987 Date-Received: Fri, 31-Jul-87 05:29:33 EDT References: <8707271647.AA00575@braden.isi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 17 I can think of a situation where different sized subnets would be useful. At BU we have some networks (1 -3 ) which have alot of hosts on them (> 10), one of our networks is growing rapidly (our backbone) and we have other networks which will be in the future growth of our class B network. We also have networks with less than 10 hosts, some haveo only 1 (one) host and need a network because of technical limitations, such as Macintoshes which need to talk to an appletalk gateway, or a Sun Server with only 2 clients and little or no growth predicted. In the latter case, using a common subnetting scheme will be alright in the near future because we have a total of 254 subnets. But what happens when we run out? I know, I know, maybe by then we will be switching to ISO protocols or someone will come up with a subnetting scheme that works better than the one we have. See? I can answer my own questions :-). Anyway, there is a need and it should be recognized. --jsol ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2514@whuts.UUCP] <1987072911191000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: paul@whuts.UUCP (HO) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <2514@whuts.UUCP> Date: Wed, 29-Jul-87 15:19:10 EDT Article-I.D.: whuts.2514 Posted: Wed Jul 29 15:19:10 1987 Date-Received: Sat, 1-Aug-87 01:44:08 EDT References: <725@hjuxa.UUCP> <649@houxa.UUCP> Organization: AT&T Bell Laboratories Lines: 15 Keywords: TCP/IP, Streams In article <649@houxa.UUCP>, mel1@houxa.UUCP (M.HAAS) writes: > Would someone please post a summary of reasons why use of Streams is > an advantage. Is this just another sales-hype buzzword? or is there > a reason Streams is better? than sockets? than psudo-sockets? or > select? Does the end user see any advantage? faster response? less > CPU waste? what? Does anyone have some before & after figures on > drivers that were converted to Streams? Please share them with us. Chapter 10 of the Bach book (The Design of the UNIX Operating System) has a pretty good discussion and description on STREAMS. Also, Bach and others have also written some papers on the SVR3 STREAMS implementation, which differs slightly from the Research STREAMS. Paul Ho ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072911421600> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 29 Jul 87 18:46:58-PDT Date: 29 Jul 1987 18:42:16 PDT Subject: Re: How do you break up a B class number? From: Dan Lynch To: hi!kurt@HC.DSPO.GOV (Kurt Zeilenga) cc: braden@VENERA.ISI.EDU, tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU In-Reply-To: <8707271742.AA26964@hi> This subnetting stuff can lead to bizzare situations that may sound ok, but give some of the "semi-invisible glue" parts (like gateways, routers, bridges) horrendous headaches. Example: you want a lot of subnets, but you also want One Big One because you have a ton of hosts on "one cable". There is nothing that says you cannot have more than one entwork number on the same "cable"! So break the 16 bits up into 256 nets of 256 hosts and assign 4 of the to the main cable. It's legal , but wil it work!? Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707292006.AA17307@umix.cc.umich.edu] <1987072912063300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hyc@UMIX.CC.UMICH.EDU (Howard Chu) Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP w/SMTP for MSDOS, Minix, etc. Message-ID: <8707292006.AA17307@umix.cc.umich.edu> Date: Wed, 29-Jul-87 16:06:33 EDT Article-I.D.: umix.8707292006.AA17307 Posted: Wed Jul 29 16:06:33 1987 Date-Received: Fri, 31-Jul-87 05:44:10 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 175 Here's the latest status report on Phil Karn's TCP/IP package, stolen from the Usenet newsgroup comp.os.minix. (If you read the News, you know... }-) -- Howard Chu University of Michigan Computing Center, Unix Project -=-=-=-=-=-=-=-=-=- In article <389@louie.udel.EDU> galvin@UDEL.EDU (James M Galvin) writes: >From: Paul Congdon >> Why doesn't someone just post the source.... It can't be all that big. No No No No No! The package *IS* big, though much, much smaller than the PC/IP source distribution. Much easier for those who care to get it from louie, via uucp, or from my bbs. Why make the whole world pay distribution charges for something so few have an immediate need for? The code on louie was just updated by Phil to rev 870526.5, which contains quite a few internal changes from the .0 release. I'm working on integrating his changes with stuff from a *lot* of other folks to issue another major release. I'd really hate to waste net bandwidth with code that's about to be obsolete, since I assume most folks have 870526.0... If we ever get a release that we're happy with, maybe a post to one of the sources groups would be appropriate. With the rate things are changing right now, I don't think so. The big news for this group is that the new release in a week or two will have support for running as a single process under bsd or sysV. Assume that with a serial port driver for Minix (I don't have one? Did the post not get here?), that it will be trivial to bring it up there too as a single process. Not wonderful, but a start! >The compressed tar file on our machine is 1/2 meg. The uncompressed tar >file is almost 1 meg. That is a LOT of stuff to be mailing around. Do >we really want that? Thanks for asking and not posting! -- Bdale Garbee, N3EUA phone: 303/593-9828 h, 303/590-2868 w uucp: {bellcore,crash,hp-lsd,hpcsma,ncc,pitt,usafa,vixie}!winfree!bdale fido: sysop of 128/19 packet: n3eua @ k0hoa, Colorado Springs -=-=-=-=-=-=-=-=-=-=-=- [Here are some older messages describing other means of getting the sources. As far as I know, the most up to date version will always be on Bdale's BBS, with louie getting updated soon after. -- Howard] -=-=-=-=-=-=-=-=-=-=-=- In article <1049@bucsb.bu.edu.UUCP>, madd@bucsb.bu.edu.UUCP (Jim "Jack" Frost) writes: > I have a copy of Phil Karn's TCP/IP for the PC, which has a README > file saying that you can do anything you want with it so long as its > noncommercial. I can shar it and send it to any interested parties. > Note: It's *quite* large. This is now available from minix-server@bugs.nosc.mil under the pseudo Message-Ids karn0@bugs.nosc.mil thru karn7@bugs.nosc.mil . Also the 1.2 diffs and sources are here on bugs. The compatibility list has not much new in it. To review: ----------------------------------------------------------------------------- Subject: archive service on bugs.nosc.mil Keywords: automatic mail archive server Message-ID: <690@cod.UUCP> Date: 20 May 87 19:22:17 GMT An archive retrieval service for old comp.os.minix articles is set up on bugs.nosc.mil using E-mail. Everything available to anonymous FTP in directory pub/Minix can be obtained by sending a mailed request to minix-server@bugs.nosc.mil or nosc!minix-server . Include in the message, either among the header fields or the body, a line like: Reply-To: and following that a line or lines naming desired files e.g.: send compatibility send SUBJECTS send 1180@botter.cs.vu.nl to get an automatic mailed reply. Your mail address should look something like one of these examples: you@stolaf.uucp cs.vu.nl!giant@seismo.css.gov person%utoronto.bitnet@wiscvm.wisc.edu user%ulowell.csnet@relay.cs.net honcho%durham.mailnet@mit-multics.arpa . FTP should happen during off-hours only. E-mail is not free, either; abuse of the system will cause bad karma. Contents may have settled during shipment. Vincent Broman, code 632, Naval Ocean Systems Center, San Diego, CA 92152, USA Phone: +1 619 225 2365 Internet: broman@nosc.mil Uucp: sdcsvax!nosc!broman -=-=-=-=-=-=-=-=-=-=- My mailbox overrunneth!!! I'm averaging one request per hour for Phil's code. Here's how to obtain the distribution via anonymous UUCP from 'ncc'. First, add the following line to your L.sys file: ncc Any ACU 2400 14034250342 "" \r ogin:--ogin: nuucp or for 1200 baud access ncc Any ACU 1200 14034250342 "" BREAK\r ogin:-BREAK\r-ogin: nuucp The distribution is split into four files as follows: -rw-rw-r-- 1 lyndon 0 Jul 22 11:24 FILES -r--r--r-- 1 lyndon 61089 Jul 21 11:53 exe.tar.Z -r--r--r-- 1 lyndon 42474 Jul 21 11:54 misc.tar.Z -r--r--r-- 1 lyndon 142666 Jul 21 11:52 src.tar.Z -r--r--r-- 1 lyndon 96487 Jul 21 11:54 tnc.tar.Z exe.tar.Z contains the MS-DOS binaries misc.tar.Z is the documentation and bm (Bdales Mailer) src.tar.Z is the source code for everything except bm tnc.tar.Z contains the Terminal Node Controller stuff (not needed for Minix) FILES is a list of the current directory contents All files are in 16 bit compressed format. Once you've decided which files you require, queue up a SEPERATE request for each file as follows: uucp ncc!~/pub/ka9q/src.tar.Z /usr/spool/uucppublic/ka9q/ ^^^^^^^^^ Replace with appropriate filename You should take a copy of the FILES file first, just incase the distribution breakdown is changed. Please note that this is NOT the most current release of the software. I have been waiting for the new versions to stabalise a bit before bringing an updated copy in. Given the amount of interest I will be obtaining the most current release in the next couple of days. You might want to wait for it (I will post an announcement as soon as it's online). If you have any problems with UUCP, send mail to me and I'll check into it. Lyndon Nerenberg VE6BBM alberta!ncc!lyndon pyramid!ncc!lyndon -- Ollie for president: the tradition continues. -=-=-=-=-=-=-=-=-=-=-=- > Here's how to obtain the distribution via anonymous > UUCP from 'ncc'. For those of you with anonymous ftp access, it is also available from louie.udel.edu, "10.0.0.96", in the "pub" directory, file name "ka9q_all.tar.Z". Jim -=-=-=-=-=-=-=-=-=-=-=- Bdale's BBS can be reached at (303) 593-0766, up to 2400bps, almost 24 hours a day. He claims the access restrictions for first time users are long enough to allow downloading the entire package at 1200 baud. -- Howard ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072912270900> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 29 Jul 87 19:29:14-PDT Date: 29 Jul 1987 19:27:09 PDT Subject: Re: Wollongong TCP/IP for Sys V From: Dan Lynch To: phri!bc-cis!pluto!warren@NYU.ARPA (Warren Burstein) cc: tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU In-Reply-To: <443@pluto.UUCP> Bashing Wollongong is probably more fun now that they are on the Internet now and we know they see these flames. But, Burstein's message really puzzles me. If Wollongong's stuff is so bad, why is everyone stealing it? Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072913051600> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 29 Jul 87 20:09:17-PDT Date: 29 Jul 1987 20:05:16 PDT Subject: Re: Streams TCP/IP From: Dan Lynch To: gorodish!guy@SUN.COM (Guy Harris) cc: tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU In-Reply-To: <24335@sun.uucp> Guy Harris said something that made me see red: the TLI uses state information that is kept in userland. Does that mean that it takes parameters from userland and then operates on them in kernelland or doe sit mean that it uses userland dataspace to keep some state variables that the user can change between system calls to get data to or form the stream? If so, it is a potential source of random havoc or invidious hackery to accomplish amazing ends. In short, I am asking: is this a security or integrity breach ot not? Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707301712.AA18994@ucbvax.Berkeley.EDU] <1987072913542700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ELINSKY@YKTVMX.BITNET (Jay Elinsky) Newsgroups: comp.protocols.tcp-ip Subject: Source routing Message-ID: <8707301712.AA18994@ucbvax.Berkeley.EDU> Date: Wed, 29-Jul-87 17:54:27 EDT Article-I.D.: ucbvax.8707301712.AA18994 Posted: Wed Jul 29 17:54:27 1987 Date-Received: Sat, 1-Aug-87 09:58:35 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: IBM TCP/IP For VM List Distribution: world Organization: The ARPA Internet Lines: 33 This is from Jay Elinsky at IBM Yorktown, originally sent on the Bitnet- based IBM TCP/IP For VM Mailing list. He asked that it be forwarded to the TCP/IP mailing list. - Mark Bodenstein, Cornell University ----------------------------Original message---------------------------- I'm one of the developers of the VM code at Yorktown, and I want to clarify some possible misconceptions on this subject: 1) We use source routing only on Token Ring. Even on Token Ring, we can certainly also route through a router, if the destination host is on a different net or subnet. If the destination host is on a different ring with the same net or subnet number, we do indeed use source routing. I believe that this is consistent with the architecture of the Token Ring. Is it inconsistent with any existing implementation of TCP/IP over Token Ring? If so, I'd certainly like to know about it. 2) Re "No RIF field, no function": If a host is on the same ring, the ARP code will recognize it, and subsequent packets between the hosts have no routing field at all. 3) Our TCP/IP certainly is inter-operable with other TCP/IP implement- ations. That is our reason for supporting TCP/IP. To repeat what I said in (1), the source routing issue is only on Token Ring, and to the best of my knowledge our implementation is consistent with other TCP/IP Token Ring implementations, and with Token Ring architecture. 4) In the VM code, the Token Ring routing information is kept as part of the address translation cache. I think that's logical. Jay Elinsky IBM T.J. Watson Research Center Yorktown Heights, NY ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987072913542701> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Thu 30 Jul 87 10:05:07-PDT Received: from CORNELLC.BITNET by wiscvm.wisc.edu ; Thu, 30 Jul 87 12:05:48 CDT Received: by CORNELLC (Mailer X1.23b) id 9260; Thu, 30 Jul 87 12:57:51 EDT Resent-Date: Thu, 30 Jul 87 12:51:52 EDT Resent-From: Mark Bodenstein Resent-To: TCP-IP@sri-nic.arpa Received: from CUNYVM(MAILER) by CORNELLC (Mailer X1.23b) id 7296; Wed, 29 Jul 87 20:45:04 EDT Received: by CUNYVM (Mailer X1.23b) id 0224; Wed, 29 Jul 87 18:37:05 EDT Date: Wednesday, 29 Jul 1987 17:54:27 EDT Reply-To: IBM TCP/IP For VM List Sender: IBM TCP/IP For VM List Comments: Warning -- RSCS tag indicates an origin of ELINSKY@YKTVMT From: Jay Elinsky Subject: Source routing To: Mark Bodenstein , Michael Hojnowski This is from Jay Elinsky at IBM Yorktown, originally sent on the Bitnet- based IBM TCP/IP For VM Mailing list. He asked that it be forwarded to the TCP/IP mailing list. - Mark Bodenstein, Cornell University ----------------------------Original message---------------------------- I'm one of the developers of the VM code at Yorktown, and I want to clarify some possible misconceptions on this subject: 1) We use source routing only on Token Ring. Even on Token Ring, we can certainly also route through a router, if the destination host is on a different net or subnet. If the destination host is on a different ring with the same net or subnet number, we do indeed use source routing. I believe that this is consistent with the architecture of the Token Ring. Is it inconsistent with any existing implementation of TCP/IP over Token Ring? If so, I'd certainly like to know about it. 2) Re "No RIF field, no function": If a host is on the same ring, the ARP code will recognize it, and subsequent packets between the hosts have no routing field at all. 3) Our TCP/IP certainly is inter-operable with other TCP/IP implement- ations. That is our reason for supporting TCP/IP. To repeat what I said in (1), the source routing issue is only on Token Ring, and to the best of my knowledge our implementation is consistent with other TCP/IP Token Ring implementations, and with Token Ring architecture. 4) In the VM code, the Token Ring routing information is kept as part of the address translation cache. I think that's logical. Jay Elinsky IBM T.J. Watson Research Center Yorktown Heights, NY ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707300156.AA05328@ucbvax.Berkeley.EDU] <1987072917421600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: Re: How do you break up a B class number? Message-ID: <8707300156.AA05328@ucbvax.Berkeley.EDU> Date: Wed, 29-Jul-87 21:42:16 EDT Article-I.D.: ucbvax.8707300156.AA05328 Posted: Wed Jul 29 21:42:16 1987 Date-Received: Sat, 1-Aug-87 01:06:53 EDT References: <8707271742.AA26964@hi> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 11 This subnetting stuff can lead to bizzare situations that may sound ok, but give some of the "semi-invisible glue" parts (like gateways, routers, bridges) horrendous headaches. Example: you want a lot of subnets, but you also want One Big One because you have a ton of hosts on "one cable". There is nothing that says you cannot have more than one entwork number on the same "cable"! So break the 16 bits up into 256 nets of 256 hosts and assign 4 of the to the main cable. It's legal , but wil it work!? Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707300241.AA06088@ucbvax.Berkeley.EDU] <1987072918270900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong TCP/IP for Sys V Message-ID: <8707300241.AA06088@ucbvax.Berkeley.EDU> Date: Wed, 29-Jul-87 22:27:09 EDT Article-I.D.: ucbvax.8707300241.AA06088 Posted: Wed Jul 29 22:27:09 1987 Date-Received: Sat, 1-Aug-87 02:31:03 EDT References: <443@pluto.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Bashing Wollongong is probably more fun now that they are on the Internet now and we know they see these flames. But, Burstein's message really puzzles me. If Wollongong's stuff is so bad, why is everyone stealing it? Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707300326.AA06674@ucbvax.Berkeley.EDU] <1987072919051600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <8707300326.AA06674@ucbvax.Berkeley.EDU> Date: Wed, 29-Jul-87 23:05:16 EDT Article-I.D.: ucbvax.8707300326.AA06674 Posted: Wed Jul 29 23:05:16 1987 Date-Received: Sat, 1-Aug-87 02:33:13 EDT References: <24335@sun.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 11 Guy Harris said something that made me see red: the TLI uses state information that is kept in userland. Does that mean that it takes parameters from userland and then operates on them in kernelland or doe sit mean that it uses userland dataspace to keep some state variables that the user can change between system calls to get data to or form the stream? If so, it is a potential source of random havoc or invidious hackery to accomplish amazing ends. In short, I am asking: is this a security or integrity breach ot not? Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707300535.AA01586@bu-cs.BU.EDU] <1987072921352100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bzs@BU-CS.BU.EDU (Barry Shein) Newsgroups: comp.protocols.tcp-ip Subject: Help: TCP/IP for business application Message-ID: <8707300535.AA01586@bu-cs.BU.EDU> Date: Thu, 30-Jul-87 01:35:21 EDT Article-I.D.: bu-cs.8707300535.AA01586 Posted: Thu Jul 30 01:35:21 1987 Date-Received: Sat, 1-Aug-87 04:43:12 EDT References: <142@hippo.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 25 We are currently installing an ACC TCP/IP interface on the (purely) Administrative IBM3090 here at BU, they have also installed a Sun system. The CLA Dean's office is currently using a SUN3/180 and several diskless clients (that's TCP packets like all getout) and are moving their databases (which have been Unix based for many years) to that system. Several other departments are doing compatible things like that. The goal is to distribute the management of registration, grant and other information campus-wide via TCP/IP in the near future. I doubt they would at this time even consider anything other than TCP for their applications which (using typically the Ingres and Adabas(e?) data base systems) relies upon the heterogenous network to make accessible IBM/MVS, IBM/VM, Suns, Vax/VMS and other systems (Macintoshes via Kinetics boxes if I can ever finish reading my mail.) Boston University is generally considered to be within the United States of America and although you might write us off as academia you might want to consider the business involved in running a private university of over 25,000 students. We're probably a bigger business than you are (probably approaching Fortune 500, I dunno, never thought of it that way.) So there. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [52500001@ztivax.UUCP] <1987073002240000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: meth@ztivax.UUCP Newsgroups: comp.protocols.tcp-ip Subject: ISO - TCP/IP gateway? - (nf) Message-ID: <52500001@ztivax.UUCP> Date: Thu, 30-Jul-87 06:24:00 EDT Article-I.D.: ztivax.52500001 Posted: Thu Jul 30 06:24:00 1987 Date-Received: Sun, 2-Aug-87 19:46:58 EDT Lines: 15 Nf-ID: #N:ztivax:52500001:000:425 Nf-From: ztivax!meth Jul 30 11:24:00 1987 Here in Munich,W.-Germany, we have installed an Ethernet with a lot of different systems on it, speaking TCP/IP. Now two more systems could be connected to the net, but these only speak ISO (not yet in the market). Is there any hardware or software which could work as a gateway between these two protocol families? Any advice would be regret! Wilhelm Methfessel Siemens AG Munich W.-Germany seismo!unido!ztivax!meth ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987073003524100> Received: from yuma.arpa by SRI-NIC.ARPA with TCP; Thu 30 Jul 87 10:11:24-PDT Date: Thu, 30 Jul 87 9:52:41 MDT From: Robert Butler Subject: Re: SEVERAL copies of message received In-Reply-To: Your message of 26 Jul 87 09:10:00 CDT To: "CALVIN R. GEORGE" Cc: tcp-ip@sri-nic.arpa, rbutler@yuma.arpa I have received many copies also (8). Some of them have a different closing address in the signature block. I also receive dual and triple copies of other msgs addressed to tcp-ip and there is no specific delimiter to single them out as to why. We are a MIL site running a BBN C70,(BBN OS V) behind an LSI/11-23 gateway attached to Milnet Node 75. The gateway makes our system a subnet 6.1.0.1 under the 26.3.0.75 DDN address. This has been sparodically going on for several months. I have read all the net-problems reported on the tcp-ip news group and thought the problem had been defined and (will be?) corrected. Regards Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707301516.AA11279@trantor.UMD.EDU] <1987073007160700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: louie@TRANTOR.UMD.EDU (Louis A. Mamakos) Newsgroups: comp.protocols.tcp-ip Subject: Re: Why are these hosts trying to connect? Message-ID: <8707301516.AA11279@trantor.UMD.EDU> Date: Thu, 30-Jul-87 11:16:07 EDT Article-I.D.: trantor.8707301516.AA11279 Posted: Thu Jul 30 11:16:07 1987 Date-Received: Sat, 1-Aug-87 09:34:44 EDT References: <2403@ames.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 4 You might also want to log both port numbers; it may be possible that you are seeing broken FTP data connections. louie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707301726.AA19235@ucbvax.Berkeley.EDU] <1987073007524100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rbutler@YUMA.ARPA (Robert Butler) Newsgroups: comp.protocols.tcp-ip Subject: Re: SEVERAL copies of message received Message-ID: <8707301726.AA19235@ucbvax.Berkeley.EDU> Date: Thu, 30-Jul-87 11:52:41 EDT Article-I.D.: ucbvax.8707301726.AA19235 Posted: Thu Jul 30 11:52:41 1987 Date-Received: Sat, 1-Aug-87 09:59:00 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 16 I have received many copies also (8). Some of them have a different closing address in the signature block. I also receive dual and triple copies of other msgs addressed to tcp-ip and there is no specific delimiter to single them out as to why. We are a MIL site running a BBN C70,(BBN OS V) behind an LSI/11-23 gateway attached to Milnet Node 75. The gateway makes our system a subnet 6.1.0.1 under the 26.3.0.75 DDN address. This has been sparodically going on for several months. I have read all the net-problems reported on the tcp-ip news group and thought the problem had been defined and (will be?) corrected. Regards Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707301841.AA20785@ucbvax.Berkeley.EDU] <1987073010190000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CDC-DDN@DDN3.ARPA Newsgroups: comp.protocols.tcp-ip Subject: SMTP host number notation Message-ID: <8707301841.AA20785@ucbvax.Berkeley.EDU> Date: Thu, 30-Jul-87 14:19:00 EDT Article-I.D.: ucbvax.8707301841.AA20785 Posted: Thu Jul 30 14:19:00 1987 Date-Received: Sat, 1-Aug-87 10:09:30 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 15 SMTP RFC-821 defines a 'host number' that supplements the regular domain name and internet address notation. For example, PERSON @ #354. (refer to page 30 in the syntax for , and to page 31 in the last paragraph.) Does anyone know what this #host number is and where it comes from? Is this a feature that is normally expected to be implemented in SMTP, or is it a left-over from years past (NCP?). Any pointers will be appreciated. Mike Sanders CDC-DDN @ DDN3.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987073010190001> Received: from ddn3.arpa by SRI-NIC.ARPA with TCP; Thu 30 Jul 87 11:38:07-PDT Date: 30 Jul 87 14:19 EDT From: CDC-DDN @ DDN3.arpa Subject: SMTP host number notation To: tcp-ip @ sri-nic.arpa CC: CDC-DDN @ DDN3.arpa SMTP RFC-821 defines a 'host number' that supplements the regular domain name and internet address notation. For example, PERSON @ #354. (refer to page 30 in the syntax for , and to page 31 in the last paragraph.) Does anyone know what this #host number is and where it comes from? Is this a feature that is normally expected to be implemented in SMTP, or is it a left-over from years past (NCP?). Any pointers will be appreciated. Mike Sanders CDC-DDN @ DDN3.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987073011072000> Received: from F4.CSL.SRI.COM by SRI-NIC.ARPA with TCP; Thu 30 Jul 87 18:07:26-PDT Date: Thu 30 Jul 87 18:07:20-PDT From: Karl Auerbach Subject: STREAM, TLI, and (of all things) MAP 3.0 To: tcp-ip@SRI-NIC.ARPA I was wondering whether TLI (Transport Level Interface) is an intrinsic part of STREAMS? If severable, is TLI required by AT&T? Can TLI support fully asynchronous operations. In other words can I initiate a bunch of connects, sends, listens, receives.., continue running and get some sort of call-back, up-call, AST (pick your favorite name) when something completes? If TLI is an ISO transport interface, who provides graceful close? (ISO transport does not have graceful close, that's part of session.) I have on my desk a copy of a working document from the GM MAP 3.x folks. It defines a programmatic interface for applications. If anyone is familiar with that and TLI, I'd like to hear your comments. --karl-- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MV3uMGy00ja9QJE04p@andrew.cmu.edu] <1987073012012200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: leong+@ANDREW.CMU.EDU (John Leong) Newsgroups: comp.protocols.tcp-ip Subject: CMU-TEK IP code for VMS : qualification Message-ID: Date: Thu, 30-Jul-87 16:01:22 EDT Article-I.D.: andrew.MV3uMGy00ja9QJE04p Posted: Thu Jul 30 16:01:22 1987 Date-Received: Sat, 1-Aug-87 10:48:42 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 36 Further to a recent posting concerning the CMU-TEK IP software for VMS, I have the following qualifications : [1] The software is not really free. In the past, when we were receiving requests at a rate of 5 or so a month, programmers will just bang out the tape and levy a charge of something like $25 just to cover postage. In view of the recent increase requests for the software, we are having administration and operation to handle the mechanic of request processing. We will be levying a charge of $100 per request to cover media, postage, handling, and. hopefully, keep out potential nusiance requests. [2] While the software has been substantially re-written and significantly improved by the staff of our CS department, I would like to fully acknowledge the contribution by Tektronix. Not only have they the foresight and committement to carry out the original development, they have also done the academic and research community a great big favour by letting CMU distribute the software at virtually no cost - even if it is not supported. I can name a few university developments that got complete tangled up by licensing by corporations that has only money in their brain. [3] Finally, the software is ** NOT SUPPORTED and has absolutely NO WARRANTIES **. Unsupported software may be fine for organisations that have significant local expertise or want to take advantage of the available source (in Bliss) to make local enhancements. It should not be used simply on account of its low cost. This can be dangerously deceptive since you can end up paying bundles more if the package starts causing all sorts of instablity with your system and you have no idea what it is doing [and no one to get help from!] . For quite a number of organisations, you may well be advised to get fully supported and warrantied software from commercial vendors instead. John Leong CMU ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987073016070600> Received: from ADA20.ISI.EDU by SRI-NIC.ARPA with TCP; Thu 30 Jul 87 23:08:03-PDT Date: 30 Jul 1987 23:07:06 PDT Subject: data representation in FTP From: Douglas M. Olson To: tcp-ip@SRI-NIC.ARPA Tedious but trivial for people who use these documents, I hope: I'm reading a draft test plan in order to spot whoppers and fix it up. In some areas I'm not extremely qualified...oh well. Problem: the draft for testing FTP calls for transmission of data in "text, ASCII, EBCDIC, and binary" to and from the test host, which will be a VAX/VMS system. Seems inspecific to me... I'm referencing what looks like MIL-STD 1780 page 9 (which is on page I-341 of the white books which I DON'T really know how to use). "5.2.1 ASCII format: ...is intended primarily for transfer of text files, except when both hosts would find the EBCDIC type more convenient. The sender converts the data from his internal format to the standard 8-bit NVT ASCII representation..." I'm still in trouble, but now I know its because I don't know FTP well enough. Question 1) When would a VAX/VMS FTP decide that EBCDIC is convenient? That is, is this likely/mandatory to be a user-selectable option in a reasonable FTP implementation on VMS? Seems like the default in this case is that if a VAX/VMS user gets a file from a machine which uses EBCDIC, it is the remote (EBCDIC) host's job to translate it before transmission, unless the user wants EBCDIC. If the VMS FTP user CANNOT specify EBCDIC, then I have to tell the test plan writers to fix this... comments from you folks anxiously solicited! Doug (dolson @ Ada20) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707310111.AA28460@ucbvax.Berkeley.EDU] <1987073017072000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: AUERBACH@CSL.SRI.COM (Karl Auerbach) Newsgroups: comp.protocols.tcp-ip Subject: STREAM, TLI, and (of all things) MAP 3.0 Message-ID: <8707310111.AA28460@ucbvax.Berkeley.EDU> Date: Thu, 30-Jul-87 21:07:20 EDT Article-I.D.: ucbvax.8707310111.AA28460 Posted: Thu Jul 30 21:07:20 1987 Date-Received: Sat, 1-Aug-87 11:54:51 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 17 I was wondering whether TLI (Transport Level Interface) is an intrinsic part of STREAMS? If severable, is TLI required by AT&T? Can TLI support fully asynchronous operations. In other words can I initiate a bunch of connects, sends, listens, receives.., continue running and get some sort of call-back, up-call, AST (pick your favorite name) when something completes? If TLI is an ISO transport interface, who provides graceful close? (ISO transport does not have graceful close, that's part of session.) I have on my desk a copy of a working document from the GM MAP 3.x folks. It defines a programmatic interface for applications. If anyone is familiar with that and TLI, I'd like to hear your comments. --karl-- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707310016.aa04873@Huey.UDEL.EDU] <1987073020165000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: adversity or perversity Message-ID: <8707310016.aa04873@Huey.UDEL.EDU> Date: Fri, 31-Jul-87 00:16:50 EDT Article-I.D.: Huey.8707310016.aa04873 Posted: Fri Jul 31 00:16:50 1987 Date-Received: Sat, 1-Aug-87 21:30:57 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 11 Chris, You are asking for a lot. In conventional wisdom multi-network Ethernets are considered somewhat unstable and, so far as I know, are unsupported by current host and gateway vendors. Some experimentation has been done in the NSFNET community with these things, but the gadgets with which this has been done (fuzzballs) are probably best left in their original cages. See RFC1009 for further discussion on this point. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [284@unixprt.UUCP] <1987073021253300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: monkey@unixprt.UUCP (Monkey Face@unixprt) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <284@unixprt.UUCP> Date: Fri, 31-Jul-87 01:25:33 EDT Article-I.D.: unixprt.284 Posted: Fri Jul 31 01:25:33 1987 Date-Received: Sat, 1-Aug-87 21:37:02 EDT References: <281@unixprt.UUCP> <24335@sun.uucp> Organization: uni-xperts - Unix System and Networking Consultants Lines: 16 Keywords: TCP/IP, Streams Summary: STREAMS vs. Sockets In article <24335@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: > I won't bother replying to the whiny little question at the end,... Two n's in 'whinny', besides I was laughing at the time. Several people at Sun have mailed me the answer anyway. Anyone who wants to know can ask me via mail. > > ...A vendor that must rely on ATT > > to provide a base, a strategy based on sockets does not seem appropriate > > in the long term. > That depends on several things. First, it depends on whether the > vendor wants to continue to depend on AT&T to provide a base, especially > given the S5R3 licensing agreement. Second, it depends on whether > they want to re-port the rest of what they've done to S5R3. Most current and near future UNIX vendors do and will use S5Rn based ports. I beleive that vendor management can see the costs associated with not following this path. Their customer will demand upward compatible functionality. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707310611.AA03275@ucbvax.Berkeley.EDU] <1987073022070600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dolson@ADA20.ISI.EDU (Douglas M. Olson) Newsgroups: comp.protocols.tcp-ip Subject: data representation in FTP Message-ID: <8707310611.AA03275@ucbvax.Berkeley.EDU> Date: Fri, 31-Jul-87 02:07:06 EDT Article-I.D.: ucbvax.8707310611.AA03275 Posted: Fri Jul 31 02:07:06 1987 Date-Received: Sat, 1-Aug-87 15:46:23 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 30 Tedious but trivial for people who use these documents, I hope: I'm reading a draft test plan in order to spot whoppers and fix it up. In some areas I'm not extremely qualified...oh well. Problem: the draft for testing FTP calls for transmission of data in "text, ASCII, EBCDIC, and binary" to and from the test host, which will be a VAX/VMS system. Seems inspecific to me... I'm referencing what looks like MIL-STD 1780 page 9 (which is on page I-341 of the white books which I DON'T really know how to use). "5.2.1 ASCII format: ...is intended primarily for transfer of text files, except when both hosts would find the EBCDIC type more convenient. The sender converts the data from his internal format to the standard 8-bit NVT ASCII representation..." I'm still in trouble, but now I know its because I don't know FTP well enough. Question 1) When would a VAX/VMS FTP decide that EBCDIC is convenient? That is, is this likely/mandatory to be a user-selectable option in a reasonable FTP implementation on VMS? Seems like the default in this case is that if a VAX/VMS user gets a file from a machine which uses EBCDIC, it is the remote (EBCDIC) host's job to translate it before transmission, unless the user wants EBCDIC. If the VMS FTP user CANNOT specify EBCDIC, then I have to tell the test plan writers to fix this... comments from you folks anxiously solicited! Doug (dolson @ Ada20) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707311241.AA20146@nic.nyser.net] <1987073104570100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: schoff@NIC.NYSER.NET (Marty Schoffstall) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong TCP/IP for Sys V Message-ID: <8707311241.AA20146@nic.nyser.net> Date: Fri, 31-Jul-87 08:57:01 EDT Article-I.D.: nic.8707311241.AA20146 Posted: Fri Jul 31 08:57:01 1987 Date-Received: Sat, 1-Aug-87 21:52:31 EDT References: <8707311042.AA02721@csv.rpi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 22 Dan, I personally haven't heard of anyone stealing it, (that message really took me by surprise), but I'd propose that the reason why people might "steal" tcp/ip it is that it is CURRENTLY the only game in town. AT&T donated thousands of 3b machines to the universities, (RPI has almost 30 of them), stealing the networking software puts it in the "matching" price range of the hardware itself. What may happen as soon as the "public domain" implementations are available is what has happened with VMS tcpip networking in the past (and accelerating right now), either you don't buy a TWG product at all or you buy one for "stability" sake and run TEK/CMU/TCP everywhere else. Marty PS: RPI told AT&T that we HAD to have tcp/ip and ethernet on ours or we simply wouldn't use them, AT&T delivered tcp/ip. From my discussions with others who took donated equipment, stances like that were rare. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [566@applix.UUCP] <1987073106212200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mark@applix.UUCP (Mark Fox) Newsgroups: comp.protocols.tcp-ip Subject: Re: STREAM, TLI, and (of all things) MAP 3.0 Message-ID: <566@applix.UUCP> Date: Fri, 31-Jul-87 10:21:22 EDT Article-I.D.: applix.566 Posted: Fri Jul 31 10:21:22 1987 Date-Received: Sun, 2-Aug-87 00:45:06 EDT References: <8707310111.AA28460@ucbvax.Berkeley.EDU> Reply-To: mark@applix.UUCP (Mark Fox) Organization: APPLiX Inc., Westboro MA Lines: 66 In article <8707310111.AA28460@ucbvax.Berkeley.EDU> AUERBACH@CSL.SRI.COM (Karl Auerbach) writes: >... several questions follow... I just put down the UNIX System V manuals from AT&T and Prentice-Hall. I also have been looking at our Bell Technologies 386 running S5V3. Here is what I have observed: >I was wondering whether TLI (Transport Level Interface) is an intrinsic >part of STREAMS? If severable, is TLI required by AT&T? TLI is implemented by a library called libnsl_s.a in /usr/lib. It contains all of the t_ calls. TLI is implemented on top of STREAMS. Is it severable or required? Check the licensing agreements... >Can TLI support fully asynchronous operations. In other words can >I initiate a bunch of connects, sends, listens, receives.., continue >running and get some sort of call-back, up-call, AST (pick your favorite >name) when something completes? Both synchronous multiplexing using the poll (== select) call and asynchronous multiplexing with the I_SETSIG ioctl (== SIGIO) are supported in addition to a non-blocking option (by setting O_NDELAY) on most of the calls >If TLI is an ISO transport interface, who provides graceful close? (ISO >transport does not have graceful close, that's part of session.) The UNIX System V Network Programmer's Guide says that graceful close is an optional procedure. Does this mean that t_sndrel defaults to a t_snddis for ISO? >I have on my desk a copy of a working document from the GM MAP 3.x folks. >It defines a programmatic interface for applications. If anyone is familiar >with that and TLI, I'd like to hear your comments. MAP's programmatic interface, from my hazy recollection, is primarily at the CASE and directory service interfaces in the application layer. TLI is a transport layer interface. Now I have a question based on an observation: It seems that AT&T's TLI primitives are not very different from the Berkeley socket calls. For example: poll == select; t_open == socket; t_bind, t_accept, t_connect, t_listen == bind, accept, connect, listen; t_rcv, t_snd == recv/recvfrom, send/sendto; t_snddis == shutdown... Did NIH have something to do with the design of TLI? Actually the real question is: If I have an application that communicates with other processes using fairly vanilla socket calls, couldn't I just implement the socket calls for the System V port using TLI calls or at least encapsulate the Unix calls within my own primitives? Or am I missing some basic incompatibility? By vanilla I mean that I am not particularly interested in exploiting protocol options such as call user data or graceful close. Oh yes, another question: Are there any System V equivalents for the Berkeley Network library functions, such as gethostent and inet_addr, and files such as /etc/hosts and /etc/services? I found no mention in the Network Programmer's Guide or Release Notes. Do I have to pay extra for them? -- Mark Fox Applix Inc., 112 Turnpike Road, Westboro, MA 01581, (617) 870-0300 uucp: seismo!harvard!m2c!applix!mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987073107584100> Received: from PS1.CS.CMU.EDU by SRI-NIC.ARPA with TCP; Fri 31 Jul 87 09:53:06-PDT Date: 31 Jul 1987 12:58:41 EST From: Dale.Moore@PS1.CS.CMU.EDU To: info-vax@kl.ri.com, tcp-ip@SRI-NIC.ARPA, tektcp%kla.weslyn%wesleyan.bitnet@VMA.CC.CMU.EDU Subject: CMU-TEK questions Ever read Mad Magazine? How about that section "Snappy Answers to Stupid Questions"? Well this is just like that, only the questions are about CMU-TEK VMS IP/TCP software, and some of the questions aren't so stupid. Q: How do I get the software? A: Like my post said, send mail to CMU-TEK IP/TCP Software Request Computation Center Carnegie Mellon University 4910 Forbes Av. Pittsburgh, PA 15213 They'll answer your questions and give you a copy of a license to sign. Once we receive the signed license, we'll mail you the software. The license says that the software is owned by CMU-TEK and that CMU isn't responsible for problems caused by this software etc. It will take a couple of weeks to process this stuff. Please, no rush exceptions. Q: We have an old license from Tektronix. Do we need to re-license? A: CMU would like everyone to have the same type of license to this software. Our current license is probably the least restrictive of any of the past. You might want to contact the above address and see what current license restrictions are. Q: Please explain "Postage and Handling may be extra"? A: We are currently charging $20 for the tape, postage, handling and the cost of reproducing one hardcopy of the documentation. This may increase to $50 sometime in the future. We use to ask that the user send us the tape and a prepaid mailer. But that was a hassle because some wouldn't send enough postage and others wouldn't send the tape. Q: Sounds like you don't like Tektronix? A: Tektronix did good by us. Their pioneering work with this stuff was a great help. Some of their original framework and design flavor remains. In retrospect we might have been better starting from scratch. We are very grateful to the technical and administrative folks at Tektronix. Q: Are you trying to put TWG and other VMS IP/TCP vendors out of business? A: No. They do hand-holding. And some of them do it quite well. We do not hand-hold. Some of those vendors are offering innovative and custom solutions to some of the IP/TCP problems. Most are willing to stand behind their work and see that it is working almost perfectly. We might occasionally take the approach of "Since you found the bug, you can help us find the fix". ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987073108290000> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Fri 31 Jul 87 16:21:06-PDT Received: from UCIVMSA.BITNET by wiscvm.wisc.edu ; Fri, 31 Jul 87 18:21:54 CDT Date: 31 JUL 87 15:29-PDT From: DHWalker%UCIVMSA.BITNET@wiscvm.wisc.edu To: TCP-IP@SRI-NIC.ARPA Subject: Telnet spooling for Unix X-Original_To: tcp-ip%SRI-NIC.ARPA@orion X-Routing: SMTPUSER @ WISCVM Received: from ORION by UCICP6 with PMDFs; 31 Jul 1987 15:04:01 Received: from localhost by orion.cf.uci.edu id a009621; 31 Jul 87 14:59 PDT Date: Fri, 31 Jul 87 14:59:55 -0700 From: David Walker Does anyone know of a filter program for Unix's spooling system which can make a telnet request for its printer? We would like to attach (cheap) serial printers to terminal servers and have them accessible from our Sequent system (among others). David Walker Network Services Manager UC Irvine ----MESSAGE-END---- ----MESSAGE-BEGIN---- [171500006@uxc.cso.uiuc.edu] <1987073108300000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sandrock@uxc.cso.uiuc.edu Newsgroups: comp.protocols.tcp-ip Subject: Re: IBM TCP. Message-ID: <171500006@uxc.cso.uiuc.edu> Date: Fri, 31-Jul-87 12:30:00 EDT Article-I.D.: uxc.171500006 Posted: Fri Jul 31 12:30:00 1987 Date-Received: Sun, 2-Aug-87 19:48:06 EDT References: <11@<12320729020> Lines: 24 Nf-ID: #R:<12320729020:11:uxc.cso.uiuc.edu:171500006:000:1260 Nf-From: uxc.cso.uiuc.edu!sandrock Jul 31 11:30:00 1987 >/* Written 1:30 pm Jul 29, 1987 by DCP@QUABBIN.SCRC.SYMBOLICS.COM in uxc.cso.uiuc.edu:comp.protocols.tcp-ip */ > > Date: Fri, 24 Jul 87 23:32:20 EDT > From: "James B. VanBokkelen" > > I've heard nothing about aberrant behavior on Ether, so apparently they're > only punishing their own pioneering customers at the moment.... > > Maybe they're just trying to go one up on DEC? Remember that DEC > violates the spirit of the Ethernet hardware address by forcing the > Ethernet address to be algorithmically determined by the DECnet address, > resulting in Ethernet addresses which do not indicate the vendor of > hardware interface, as well as not ensuring globally unique addresses. > DECnet uses the node address to set the least significant 16 bits of the 48-bit Ethernet hardware address while setting the most significant 32 bits to a "known" constant value. Specifically, the Ethernet address will be AA-00-04-00-xx-xx, where the xx-xx fields are the DECnet node address (area-number * 1024) + node-number. There may be both certain advantages and also disadvantages to this approach, but is it true that these addresses are not globally unique? Mark Sandrock, (sandrock@uxc.cso.uiuc.edu) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707311655.AA20489@topaz.rutgers.edu] <1987073108555500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <8707311655.AA20489@topaz.rutgers.edu> Date: Fri, 31-Jul-87 12:55:55 EDT Article-I.D.: topaz.8707311655.AA20489 Posted: Fri Jul 31 12:55:55 1987 Date-Received: Sun, 2-Aug-87 01:14:46 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 2 Is streams in the SVID? Really? Well DAMN ship back this AT&T SVR3 release because streams ain't in it. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707311702.AA20541@topaz.rutgers.edu] <1987073109020600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong TCP/IP for Sys V Message-ID: <8707311702.AA20541@topaz.rutgers.edu> Date: Fri, 31-Jul-87 13:02:06 EDT Article-I.D.: topaz.8707311702.AA20541 Posted: Fri Jul 31 13:02:06 1987 Date-Received: Sun, 2-Aug-87 01:16:29 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 The TWG code for the 3B2 comes from AT&T. I wasn't aware you could buy it at all from TWG (I wish I were wrong, I'd expect that the product would be better direct). Anyhow, TWG could avoid pirating by using the same method as the SUN PCNFS code. The software shuts down if it notices datagrams from another of the same licensed code on the net. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707311744.AA02059@violet.ISC.COM] <1987073109443500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dougm@violet.isc.COM ("Doug McCallum") Newsgroups: comp.protocols.tcp-ip Subject: Re: STREAM, TLI, and (of all things) MAP 3.0 Message-ID: <8707311744.AA02059@violet.ISC.COM> Date: Fri, 31-Jul-87 13:44:35 EDT Article-I.D.: violet.8707311744.AA02059 Posted: Fri Jul 31 13:44:35 1987 Date-Received: Sun, 2-Aug-87 03:08:32 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 45 In reply to your message of Thu 30 Jul 87 18:07:20-PDT ------- > I was wondering whether TLI (Transport Level Interface) is an intrinsic > part of STREAMS? If severable, is TLI required by AT&T? It is possible to have streams without TLI. TLI is implemented as a STREAMS module and library code. TLI is the programmer interface to the Transport Provider Interface which is the format of messages used to communicate with a transport protocol module. STREAMS by itself doesn't define message format, just message type. TLI is required to be implemented if the Network Extensions are supported. It is possible to leave that out of the system. You aren't required to use TLI as a user, but if you don't have an alternate interface, its easier to use TLI than to process all of the message formats yourself. > Can TLI support fully asynchronous operations. In other words can > I initiate a bunch of connects, sends, listens, receives.., continue > running and get some sort of call-back, up-call, AST (pick your favorite > name) when something completes? Yes. When a t_bind is done, it includes a count of maximum pending connect requests, similar to what listen does in the socket world. The difference being that with TLI, you can accept, connect or both on the stream. Accepting a connection requires first listening for a connection request. You can read in multiple connection requests and then decide which ones to accept or reject. Accepts can either be done on a new stream or on the same stream you received the request on. You can also elect to receive a signal when a stream has data at the stream head. To determine which stream has the data, the poll system call is used in much the same way as select on a BSD system. TLI (actually STREAMS) is flexible enough that you can initiate several connections and not wait for the results and then go back later to determine if they are done. One thing to note, the poll call only works on STREAMS descriptors and not on things like ttys. > If TLI is an ISO transport interface, who provides graceful close? (ISO > transport does not have graceful close, that's part of session.) TLI only provides a graceful close if the underlying transport provides it. TLI is ISO in flavor, it is supposed to be general enough for other protocols. The calls are similar to the ISO service primitives. Unfortunately, this has some problems for TCP, primarily in how to deal with urgent data. Urgent data is not the same thing as expedited data. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707311711.AA13254@ucbvax.Berkeley.EDU] <1987073109584100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Dale.Moore@PS1.CS.CMU.EDU Newsgroups: comp.protocols.tcp-ip Subject: CMU-TEK questions Message-ID: <8707311711.AA13254@ucbvax.Berkeley.EDU> Date: Fri, 31-Jul-87 13:58:41 EDT Article-I.D.: ucbvax.8707311711.AA13254 Posted: Fri Jul 31 13:58:41 1987 Date-Received: Sun, 2-Aug-87 01:13:52 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 48 Ever read Mad Magazine? How about that section "Snappy Answers to Stupid Questions"? Well this is just like that, only the questions are about CMU-TEK VMS IP/TCP software, and some of the questions aren't so stupid. Q: How do I get the software? A: Like my post said, send mail to CMU-TEK IP/TCP Software Request Computation Center Carnegie Mellon University 4910 Forbes Av. Pittsburgh, PA 15213 They'll answer your questions and give you a copy of a license to sign. Once we receive the signed license, we'll mail you the software. The license says that the software is owned by CMU-TEK and that CMU isn't responsible for problems caused by this software etc. It will take a couple of weeks to process this stuff. Please, no rush exceptions. Q: We have an old license from Tektronix. Do we need to re-license? A: CMU would like everyone to have the same type of license to this software. Our current license is probably the least restrictive of any of the past. You might want to contact the above address and see what current license restrictions are. Q: Please explain "Postage and Handling may be extra"? A: We are currently charging $20 for the tape, postage, handling and the cost of reproducing one hardcopy of the documentation. This may increase to $50 sometime in the future. We use to ask that the user send us the tape and a prepaid mailer. But that was a hassle because some wouldn't send enough postage and others wouldn't send the tape. Q: Sounds like you don't like Tektronix? A: Tektronix did good by us. Their pioneering work with this stuff was a great help. Some of their original framework and design flavor remains. In retrospect we might have been better starting from scratch. We are very grateful to the technical and administrative folks at Tektronix. Q: Are you trying to put TWG and other VMS IP/TCP vendors out of business? A: No. They do hand-holding. And some of them do it quite well. We do not hand-hold. Some of those vendors are offering innovative and custom solutions to some of the IP/TCP problems. Most are willing to stand behind their work and see that it is working almost perfectly. We might occasionally take the approach of "Since you found the bug, you can help us find the fix". ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987073110300600> Received: from cu-arpa.cs.cornell.edu by SRI-NIC.ARPA with TCP; Fri 31 Jul 87 11:29:44-PDT Received: from gvax.cs.cornell.edu by cu-arpa.cs.cornell.edu (5.54/4.30) id AA12690; Fri, 31 Jul 87 14:30:11 EDT Date: Fri, 31 Jul 87 14:30:06 EDT From: jqj@gvax.cs.cornell.edu (J Q Johnson) Message-Id: <8707311830.AA27720@gvax.cs.cornell.edu> Received: by gvax.cs.cornell.edu (5.54/4.30) id AA27720; Fri, 31 Jul 87 14:30:06 EDT Newsgroups: arpa.tcp-ip Subject: Re: How do you break up a B class number? Summary: Expires: References: <8346@cornell.UUCP> Sender: Reply-To: jqj@gvax.cs.cornell.edu (J Q Johnson) Followup-To: Distribution: Organization: Cornell Univ. CS Dept, Ithaca NY Keywords: Apparently-To: tcp-ip@sri-nic.arpa Dan Lynch suggests (in jest, I think) a solution to the heterogenous subnet problem: > . . . have more than one entwork number on the same "cable"! So break >the 16 bits up into 256 nets of 256 hosts and assign 4 of the to the >main cable. It's legal , but wil it work!? No, it probably won't work. One big problem is that you are likely to have broadcasts with all sorts of broadcast addresses. Suppose that we have 128.84.253.0 and 128.84.33.0 (netmask 0xffffff00) on the same cable. Then the host with interface address 128.84.253.3 will occasionally receive Ethernet broadcasts that contain IP broadcasts with destination 128.84.33.255. If this is a typical 4.3BSD implementation, it will say "that's not a broadcast address, so I gotta forward or send an ICMP unreachable or something". Result: every host on 128.84.253.0 replies at the same time, and you get a big Ethernet collision. We tried something like this, and sure enough our SUNs were reporting 70% collision rates! Another version of the Ethernet meltdown Charles Hedrick so aptly described in these pages a few weeks ago. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707311950.AA12026@opal.berkeley.edu] <1987073111495800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: minshall@OPAL.BERKELEY.EDU Newsgroups: comp.protocols.tcp-ip Subject: Telnet, , etc. Message-ID: <8707311950.AA12026@opal.berkeley.edu> Date: Fri, 31-Jul-87 15:49:58 EDT Article-I.D.: opal.8707311950.AA12026 Posted: Fri Jul 31 15:49:58 1987 Date-Received: Sun, 2-Aug-87 04:28:29 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 129 (LONG MESSAGE - print and read at your leisure.) I have the pleasure of being the gongfermer (aka nightman) for 4.3 telnet and telnetd. One of my joys is replying to the recent discussion of same. Another of my joys is admitting that everything wrong with 4.3 telnet and telnetd is my fault. William R. King started out the discussion asserting that 4.3 telnet was sending \n when the user typed carriage return. Dave Borman, from Cray, (who, by the way, spent a LOT of time helping to improve 4.3 telnet/d over the 4.2 versions) suggested that this was unlikely to be the case. This is, indeed, unlikely to be the case. The "problem", as Steve Alexander (and various others in both the public discussion, and in private comments) has mentioned, is that the 4.3 telnetd (the server telnet), on receiving a TELNET , sends in a \n towards the application program. Now, Mr. John Shriver (jas) has a bit of a flame. I, personally, don't agree with the emotion of his flame, but I'm willing to talk about the philosophy. If I seem to be a bit derisive, please bear with me (this is a very sore subject). Jas states "In user Telnet, you should send when the user types the 'doit!' key." Now, I would very much like to see a reference in the RFC (854) to that effect; I won't, though. I've looked many times. Jas, of course, is not the only person who believes this to be the case. I don't know jas, but I know and trust Bob Braden at ISI, and he is as emphatic as jas is about this. Ken Pogran also agrees. So does Stephen Casner (and he quotes chapter and verse! Alas.). But, honest to god, it isn't in the spec. The spec talks a lot about what , , will do to the printer head. The spec does say: "Even though it may be known in some situations (e.g., with remote echo and suppress go ahead options in effect) that characters are not being sent to an actual printer, nonetheless, for the sake of consistency, the protocol requires that a be inserted following a not followed by a in the data stream." (And, yes, the 4.3 implementations do that.) So, I do not believe that is NECESSARILY what should be sent when the user hits the "Enter", "Return", whatever, key. What I DO believe is that the group of people who believe is the way to go are relying on, in many cases, their participation in "let's define and bring up TELNET" meetings, projects, etc., back when "everything" was starting. I really wish these people, all of whom have much more experience than I in this business, would realize this point. So, how does 4.3 telnet (the client side) work? If remote echoing is going on, and the user types '\r', we send . If local echoing is going on, and the user types '\r', we ECHO '\r\n', and send . NOTE: I think that 4.3 telnet (and I know that 4.3 telnetd) is broken in binary mode, sending when it should send just . Null stuffing isn't valid in binary mode. That is how 4.3 telnet works. Now, we slip over to 4.3 telnetd (the server). Again, the 4.3 server conforms to the protocol (not out of ignorance, not out of independence, but out of thought and some consultation). When we receive , we send '\r' towards the application program. When we receive , we send '\n' towards the application program. What do we do when we receive ? Well, what should we do? Clearly the user has typed something. What they are sending is an "end of line function" sequence (cf the note from Merton Campbell Crockett to this list); they are signalling "newline" if you will (and we would). The Unix "newline" character is '\n' (NOT '\r'). If the 4.3 server receives a , we send a '\n' (newline) towards the application program. This is a problem if the user on the client side has no way of sending . If the client side has no way of sending , then the application program is not going to see what it would have seen had a '\r' been sent its way (if it could have noticed a difference; most Unix applications would not notice the difference [but some do]). We could, it is true, have mapped the to '\r'. That would also have been within the spec. It would violate, somewhat, the philosophy of Unix (that '\n', not '\r', is the newline character). If would also mean that anyone unfortunate enough to be connecting from a client unwilling to send a alone would face a problem getting a '\n' send towards their program. I hope I haven't offended anyone overly. I AM pissed off (and what's wrong with being pissed off?). I hope that we can move from "Berkeley is violating the protocol" (which, except in the case of binary mode mentioned above, we aren't), to a Unix discussion of "how best could it work interface to Unix" (since I believe that the discussion of -> '\n' or '\r' is a Unix discussion). Or, to a general discussion of "when should a client send , when should it send , when should it send ?" (recently there was some talk about defining line and character mode; there may be some interaction here). In summary: In client mode, we sometimes send , we sometimes send , and we sometimes send by itself. In server mode, we always pad a standalone with a ; in server mode, we map incoming to '\r', incoming to '\n', and to '\n'. None of these actions violate the letter (or, to my mind, the spirit) of the RFC (or the Boland amendment, for that matter). Greg Minshall ps - Dan Hoey feels it is laughable that "if the is split across whatever buffer boundary telnetd is using, the code turns it into instead of ". This is not laughable, but IS embarassing. The intent of this was to continue to support brain-damaged 4.2 implementations, which (as has been noted time-after-time) send when the user types carriage return. pps - Those of you who are accepting of this missive may believe I come from any part of Berkeley you want; however, for the benefit of those who would use this letter to criticize the "Berkeley clique", I feel you should know that I have nothing whatsoever to do with the Computer Systems Research Group [home of Berkeley Unix]. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987073111584100> Received: from SUMEX-AIM.STANFORD.EDU by SRI-NIC.ARPA with TCP; Fri 31 Jul 87 19:18:52-PDT Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Fri, 31 Jul 87 19:19:12 PDT Date: Fri, 31 Jul 87 18:58:41 PDT From: Mark Crispin Subject: Re: SMTP host number notation To: cdc-ddn@DDN3.ARPA cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "CDC-DDN @ DDN3.arpa" of Thu, 30 Jul 87 14:19:00 PDT Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12322886758.8.MRC@PANDA> The "host number" is simply the IP address expressed as a large decimal integer. In general, there is no reason to use it since the domain literal form is preferable when "going by the numbers". However, any SMTP server implementor who fails to implement it should be shot. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [073087.233339.elinsky@ibm.com] <1987073113432100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ELINSKY@IBM.COM (Jay Elinsky) Newsgroups: comp.protocols.tcp-ip Subject: Source routing Message-ID: <073087.233339.elinsky@ibm.com> Date: Fri, 31-Jul-87 17:43:21 EDT Article-I.D.: ibm.073087.233339.elinsky Posted: Fri Jul 31 17:43:21 1987 Date-Received: Sun, 2-Aug-87 03:14:46 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 38 Here's a copy of a note I sent to IBMTCP-L, on the subject of source routing in the IBM TCP/IP code. My apologies in advance if it shows up twice -- someone else may have also sent it, but it hasn't shown up on our database at Yorktown. I want to make sure it shows up on this mailing list, since the note that started it all appeared here. Date: Wednesday, 29 Jul 1987 17:54:27 EDT From: Jay Elinsky To: Subject: Source routing I'm one of the developers of the VM code at Yorktown, and I want to clarify some possible misconceptions on this subject: 1) We use source routing only on Token Ring. Even on Token Ring, we can certainly also route through a router, if the destination host is on a different net or subnet. If the destination host is on a different ring with the same net or subnet number, we do indeed use source routing. I believe that this is consistent with the architecture of the Token Ring. Is it inconsistent with any existing implementation of TCP/IP over Token Ring? If so, I'd certainly like to know about it. 2) Re "No RIF field, no function": If a host is on the same ring, the ARP code will recognize it, and subsequent packets between the hosts have no routing field at all. 3) Our TCP/IP certainly is inter-operable with other TCP/IP implement- ations. That is our reason for supporting TCP/IP. To repeat what I said in (1), the source routing issue is only on Token Ring, and to the best of my knowledge our implementation is consistent with other TCP/IP Token Ring implementations, and with Token Ring architecture. 4) In the VM code, the Token Ring routing information is kept as part of the address translation cache. I think that's logical. Jay Elinsky IBM T.J. Watson Research Center Yorktown Heights, NY ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707312233.AA03919@violet.ISC.COM] <1987073114335700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dougm@violet.isc.COM ("Doug McCallum") Newsgroups: comp.protocols.tcp-ip Subject: Re(2): STREAM, TLI, and (of all things) MAP 3.0 Message-ID: <8707312233.AA03919@violet.ISC.COM> Date: Fri, 31-Jul-87 18:33:57 EDT Article-I.D.: violet.8707312233.AA03919 Posted: Fri Jul 31 18:33:57 1987 Date-Received: Sun, 2-Aug-87 08:25:29 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 52 In reply to your message of 31 Jul 87 14:21:22 GMT ------- >It seems that AT&T's TLI primitives are not very different from the >Berkeley socket calls. For example: poll == select; t_open == socket; >t_bind, t_accept, t_connect, t_listen == bind, accept, connect, listen; >t_rcv, t_snd == recv/recvfrom, send/sendto; t_snddis == shutdown... Actually, t_bind == (bind+listen) (t_listen+t_accept) == accept t_connect == connect t_rcv/t_snd == read/write (or send/recv) t_rcvudata/t_sndudata == recvfrom/sendto The mappings aren't quite exact, but close enough. With the names being so similar, expecially t_listen and t_accept, it is easy to assume they work the same way. >Did NIH have something to do with the design of TLI? Probably a little NIH and a little of trying to generalize a little further. There are some good ideas, too bad there are some bad ones as well. >Actually the real question is: >If I have an application that communicates with other processes using >fairly vanilla socket calls, couldn't I just implement the socket calls >for the System V port using TLI calls or at least encapsulate the Unix >calls within my own primitives? Or am I missing some basic incompatibility? Almost. Without doing some work with which modules are present in the stream you might have some minor problems. If you stay with SOCK_STREAM type usage, you can do pretty well by having the socket emulation library set the STREAM up to have the read/write interface once the connection is established. The SOCK_DGRAM type sockets would be more work since address information won't be available if you do a read. In fact the read will fail if there is address information (in a control portion of a message) and you haven't setup the read/write interface. The recv*/send* emulation could deal with it though. The main problem is that while sockets preserve file descriptor semantics, TLI doesn't. You have to use TLI calls unless you make provisions to use the read/write interface. You can't have both at the same time. >Oh yes, another question: >Are there any System V equivalents for the Berkeley Network library functions, >such as gethostent and inet_addr, and files such as /etc/hosts and >/etc/services? I found no mention in the Network Programmer's Guide or >Release Notes. Do I have to pay extra for them? Nope. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8707312326.AA20283@ucbvax.Berkeley.EDU] <1987073115283400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DHWalker@UCIVMSA.BITNET Newsgroups: comp.protocols.tcp-ip Subject: Telnet spooling for Unix Message-ID: <8707312326.AA20283@ucbvax.Berkeley.EDU> Date: Fri, 31-Jul-87 19:28:34 EDT Article-I.D.: ucbvax.8707312326.AA20283 Posted: Fri Jul 31 19:28:34 1987 Date-Received: Sun, 2-Aug-87 04:32:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 13 Received: from ORION by UCICP6 with PMDFs; 31 Jul 1987 15:04:01 Received: from localhost by orion.cf.uci.edu id a009621; 31 Jul 87 14:59 PDT Date: Fri, 31 Jul 87 14:59:55 -0700 From: David Walker Does anyone know of a filter program for Unix's spooling system which can make a telnet request for its printer? We would like to attach (cheap) serial printers to terminal servers and have them accessible from our Sequent system (among others). David Walker Network Services Manager UC Irvine ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987073116364200> Received: from rice.edu by SRI-NIC.ARPA with TCP; Fri 31 Jul 87 19:55:54-PDT Received: from titan.rice.edu by rice.edu (AA08215); Fri, 31 Jul 87 21:55:49 CDT Received: by titan.rice.edu (AA16107); Fri, 31 Jul 87 21:46:07 CDT Date: Fri, 31 Jul 87 21:36:42 CDT From: David Chase Subject: Warrantied software? To: leong+@andrew.cmu.edu (John Leong) Cc: info-vax@kl.sri.com, tcp-ip@sri-nic.arpa Message-Id: <252.rbbb.titan@Rice> > For quite a number of organisations, you may well be advised to get > fully supported and warrantied software from commercial vendors instead. "_______ is sold as is without warranty as to performance, merchantability, or fitness for any particular purpose. The entire risk as to the results and performance of _______ is assumed by the Licensee." (etc) Yes sir, you get your money's worth out of those software warranties. Try substituting "bridge", "car", or "airplane" for "_______". David ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987073120144100> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Mon 3 Aug 87 04:43:59-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA28627; Mon, 3 Aug 87 04:31:53 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 31 Jul 87 20:14:41 GMT From: osupyr!hsu_f@ohio-state.arpa (Frank Hsu) Organization: Mathematical Sciences Computer Lab, The Ohio State University Subject: Wollongon TCP/IP for AT&T 3B2 Message-Id: <47@osupyr.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa I have an AT&T 3B2/300 computer running UNIX System V R3.0, and I installed the Wollongon TCP/IP software then make it running. I can do remote login (rlogin), e-mail (mailx), file transfer (ftp) with IBM 3081 (MVS), 4341 (VM/CMS), Sun Workstation, Pyramid, DEC VAX 11/780 and many other machine. This TCP/IP is running fine. The only two problems are 1) It is trying to communicating to port #513 all the time. 2) It done not accept host names contain a dot (.) when doing e-mail (mailx). And one more thing that I know is that AT&T is supporting this software, and I have reported these problems to AT&T. Frank C. Hsu IRCC Ohio State Univ. Columbus, Ohio ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987073123272200> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Tue 4 Aug 87 03:41:03-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA21083; Tue, 4 Aug 87 03:37:44 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 31 Jul 87 23:27:22 GMT From: trwrb!ucla-an!medivax!chinson@ucbvax.Berkeley.EDU (Chinson Yi) Organization: Dept. of Medicine, Sch. of Med., UCLA, Los Angeles Subject: CMU TCP/IP for VMS Message-Id: <156@medivax.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa We are trying to bring up TCP/IP on our uVAX running VMS 4.4 and heard about CMU TCP/IP. Can someone send me how to get this program. Also, if someone is running this, I would appreciate any comment or evaluation on this CMU TCP/IP. Thank you Chinson Yi UCLA, Dept. of Medicine (medivax) __ || ==== | |__ | |-.\ |__| \\ || || ======__| ________||__ /____________\ (c) ----MESSAGE-END----