|
|
ARCHIVE: TCP-IP Distribution List - Archives (1991)
DOCUMENT: TCP-IP Distribution List for April 1991 (422 messages, 243620 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1991/04.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 91 08:42:30 GMT From: tom@wcc.oz.au (Tom Evans) To: comp.protocols.appletalk,comp.protocols.tcp-ip Subject: Re: Subnetted TCP addresses and Webster MultiGates
In article <1991Mar26.192901.1670@cns.umist.ac.uk>, jf@ap.co.umist.ac.uk (John Forrest) writes: > We have ordered a Webster Multiport Gateway and are about to > put in a Localtalk network for our Macs. In preperation we have > put up CAP (to ensure it compiled on our Apollo's) and a few > other things. We've got hold of atalkad, and have compiled that > too. I am a bit concerned, though, about the issue of TCP > subnets in the configuration. The program obviously supports > them, but only refers to the use of whole number subnets. CAP maps "whole number" Class C subnets to IPTalk (AppleTalk) networks. Thus all CAP hosts that are on a Class C Subnet are deemed to be on the same AppleTalk network. Whether or not you are subnetted as you describe (subnetmask ffffffe0). It should work OK, as long as the routers handle the "full subnet" broadcast IP address properly (192.84.82.255). If this doesn't work properly you may need to run atalkrd. Possibly not though. If the MultiGate and the CAP host are on the same subnet it should be simple. > Essentially we plan to use two of the Multigates four Localtalk > ports for standard use (one is to be dedicated to a laser, and > the other kept spare for the moment). I was hoping to use two > of the subnets for these Completely separate subject. Setting up MacIP (protocol that supports MacTCP and NCSA Telnet etc.) is a completely separate issue to CAP. They aren't really related. I'll send you mail on this. > As far > as I can tell, MacTCP is happy with subnets - it definitely > allows you to set them up. But what it actually does with subnets is a mystery. It probably only uses this information when it is directly on Ethernet. Going through MacIP is another matter - the "routing decisions" are different. ======================== Tom Evans tom@wcc.oz.au ** ADD ".au" MANUALLY (don't trust "reply") ** Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179 Victoria, Australia 61-3-764-1100 FAX ...764-1179 A.C.N. 004 818 455 wcc@cup.portal.com 2109 O'Toole Avenue, Suite J SAN JOSE CA 95131 - 1303 CALIFORNIA 1-408-954-8054 FAX 1-408-954-1832 wcc-uk@cup.portal.com Unit 7, Weltech Centre Ridgeway, Welwyn Garden City Hertfordshire AL7 2AA LONDON UK. Ph 44-707-336969 Mobile 44-836-725849 FAX 44-707-373378
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 91 16:13:27 GMT From: malis@BBN.COM (Andy Malis) To: comp.protocols.tcp-ip Subject: Re: IP over Frame Relay Network
> I am not really sure where to ask this question but here goes... > Is anyone working on or has thoughts concerning running IP over a > Frame Relay network? What I had hoped to see (but didn't) was an RFC > to the tune of "Standard for the transmission of IP datagrams over > Frame Relay networks". Carl, This is actively in progress in the "IP over Large Public Data Networks" working group of the IETF. A new (hopefully close to final) draft of the specification will soon be released, based upon discussion at the St. Louis working group meeting. To join the discussion, send a subscription request to iplpdn-request@nri.reston.va.us . Regards, Andy
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 91 18:38:54 GMT From: bill@polygen.uucp (Bill Poitras) To: news.software.nntp,comp.binaries.ibm.pc.d,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: NNTP news readers for MS-DOS (QUERY)
I have seen a lot of talk about news readers for MS-DOS. Could someone
send me what they know about the various news readers. Things I want to
know are:
- What communications does it need? (pc-nfs,packet tcpip,none)
- How good is it? How much like RN does it work like?
- How configurable is it?
If I get enough responce, I will post a summary to
comp.protocols.tcp-ip.ibmpc. Mail is preferable. Thanks in advance.
+-----------------+---------------------------+-----------------------------+
| Bill Poitras | Polygen Corporation | {princeton mit-eddie |
| (bill) | Waltham, MA USA | bu sunne}!polygen!bill |
| | FAX (617)890-8694 | bill@polygen.com |
+-----------------+---------------------------+-----------------------------+
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 91 19:07:14 GMT From: carlson@mrx.webo.dg.com (James Carlson) To: comp.protocols.tcp-ip Subject: Re: UDP Reliability between processes on same host
Sure ... they can end up out of order -- UDP doesn't guarantee delivery, and packets may arrive out of order or duplicated. (Of course, this shouldn't happen on the *same* host, but .... !) May I ask why you're not just using IPCs, since that's what it sounds like you need? UDP is usually used for self-contained data (like in XDMCP) and as the basis for a more complex protocol (like TFTP). -- Disclaimer: My company neither knows nor cares what I say. .//.
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 91 19:15:39 GMT From: rick@wucs1.wustl.edu (Rick Bubenik) To: comp.protocols.tcp-ip Subject: Public domain, user level TCP/IP
Does anyone know of a public domain implementation of TCP/IP that runs as user level code under Unix (ideally implemented in C or C++)? I'm going to be porting TCP/IP to run over a new network and want to do some experimentation outside of the kernel. rick ++++++ Rick Bubenik rick@cs.wustl.edu Research Associate Department of Computer Science Washington University Campus Box 1045 One Brookings Drive St. Louis, Missouri 63130-4899 (314) 726-7530
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 91 20:30:07 GMT From: enag@ifi.uio.no (Erik Naggum) To: comp.protocols.tcp-ip Subject: Re: UDP Reliability between processes on same host
In article <1991Mar28.220615.5501@newbridge.com> todds@newbridge.com (Todd Sandor) writes:
Please don't flame me, I know UDP is unreliable, but I have a
question concerning using UDP between processes on the same host.
My experience is that UDP is reliable on the same host, and especially
so if you use the loopback (127.0.0.1 on some systems).
The problem with assuming that you talk to the same host is that one
day, you don't. The extra cost of sequence numbers, timeouts and
retransmits (which need only be trivial -- otherwise I would suggest
TCP), won't be incurred as long as you talk to your own host. Sure,
it's more code, and you need to check that you got the right packet
and so on. As message sequence integrity is one of your concerns, I
suggest that you use sequence numbers "just in case". It _could_ be
that the network code implementation on your system uses a LIFO type
buffer for outstanding packets, and that you will find out only under
heavy load, as you allude to.
- socket overflows or
- bad data length fields or
- bad checksums
I have a hard time thinking up conditions under which you'd get more
than the first problem on a local host, but as I said, you could
suddenly find yourself having two hosts communicating. Your code
should work, regardless.
but could we experience out of order packets or duplicate packets.
You should make sufficient safety nets to allow for these conditions.
Sequence numbers will do. For instance, you could provide a minimal
layer which, when expecting n packets, read packets and requested
retransmits until it got all of them, then delivered them back to the
caller in sequence. Or you could make this layer buffer up packets
arriving out of sequence and deliver the "next" (expected) packet when
called. (This will require negotiation of initial packet numbers
between the communicating processes, and dynamic memory handling, both
of which may become costly.)
I can't speak on the relative speed of using (one of) the address(es)
of the host or using the loopback. Intuitively, one would expect a
slightly higher throughput with the loopback, using your reasoning.
All I can say is I'm pretty certain that no implementation is slower
for the loopback than one of its other addresses.
Hope this helps.
--
[Erik Naggum] <enag@ifi.uio.no>
Naggum Software, Oslo, Norway <erik@naggum.uu.no>
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 91 20:30:24 GMT From: enag@IFI.UIO.NO (Erik Naggum, the Internet Purist) To: comp.protocols.tcp-ip Subject: Re: UDP Reliability between processes on same host
In message <1991Mar28.220615.5501@newbridge.com>, Todd Sandor writes:
... I have a question concerning using UDP between processes on the
same host.
My experience is that UDP is reliable on the same host, and especially
so if you use the loopback (127.0.0.1 on some systems).
The problem with assuming that you talk to the same host is that one
day, you don't. The extra cost of sequence numbers, timeouts and
retransmits (which need only be trivial -- otherwise I would suggest
TCP), won't be incurred as long as you talk to your own host. Sure,
it's more code, and you need to check that you got the right packet
and so on. As message sequence integrity is one of your concerns, I
suggest that you use sequence numbers "just in case". It _could_ be
that the network code implementation on your system uses a LIFO type
buffer for outstanding packets, and that you will find out only under
heavy load, as you allude to.
- socket overflows or
- bad data length fields or
- bad checksums
I have a hard time thinking up conditions under which you'd get more
than the first problem on a local host, but as I said, you could
suddenly find yourself having two hosts communicating. Your code
should work, regardless.
but could we experience out of order packets or duplicate packets.
You should make sufficient safety nets to allow for these conditions.
Sequence numbers will do. For instance, you could provide a minimal
layer which, when expecting n packets, read packets and requested
retransmits until it got all of them, then delivered them back to the
caller in sequence. Or you could make this layer buffer up packets
arriving out of sequence and deliver the "next" (expected) packet when
called. (This will require negotiation of initial packet numbers
between the communicating processes, and dynamic memory handling, both
of which may become costly.)
I can't speak on the relative speed of using (one of) the address(es)
of the host or using the loopback. Intuitively, one would expect a
slightly higher throughput with the loopback, using your reasoning.
All I can say is I'm pretty certain that no implementation is slower
for the loopback than one of its other addresses.
Hope this helps.
--
[Erik Naggum] <enag@ifi.uio.no>
Naggum Software, Oslo, Norway <erik@naggum.uu.no>
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 91 22:55:11 GMT From: jbvb@FTP.COM (James B. Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: UDP Reliability between processes on same host
...but could we experience out of order packets or duplicate packets?
Taking an unsophisticated view, one wouldn't expect out of order or duplicate
packets unless IP routers and long-haul paths were involved. However,
consider what happens if a packet is lost due to hardware error on your
local cable (this WILL happen - believe me): You have to have some sort of
mechanism for detecting that it was lost and retransmitting it. If the
product of the probability of packet loss times the number of packets
outstanding (unacknowleged) at any given time gets high enough, your receiver
will see both out of order and duplication. Better to use TCP, IMHO.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 2 Apr 91 16:28:22 GMT From: frankh@durin.laguna.sparta.com (Frank Halsema) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: 10BaseT installation
I have read a lot about 10BaseT and I am considering using it in a new facility. Everything I see has the twisted pair connector as a RJ45 but inplications are that twited pair uses two pair or four wires. My question is how many pair do I need and if it is two pair why does 10BaseT use an RJ45 connector. Frank Halsema UUCP: durin!frankh SPARTA, Inc. Internet: frankh@laguna.sparta.com 23041 de la Carlota, Suite 400 Laguna Hills Ca, 92653 (714) 768-8161 EXT 339 (714)583-9114 FAX
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Tue, 2 Apr 91 17:22:23 GMT From: yjy@stlucia.uucp (Joe Yung) To: comp.sys.att,comp.protocols.tcp-ip Subject: Datakit Interface Through TCP/IP
NOTE: Followup to comp.sys.att I have a SPARC station 2 and a Datakit with a bunch of TTY modules. I am trying to have the SPARC connected to the Datakit so I can use my SPARC to access various TTY line off the Datakit. Does anybody know how ? I heard that AT&T Datakit has a connection to TCP/IP directly. We have a bunch of SPARCs on the Ethernet. It will be a a versatile way to open up the Datakit available to all the SPARCs. Does anybody know anything about this connectivity. Joe Yung yjy@stlucia.bellcore.com (908)699-5344
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 2 Apr 91 19:07:49 GMT From: ramsey@NPIRS.Purdue.EDU (Ed Ramsey) To: comp.protocols.tcp-ip,comp.protocols.nfs Subject: Has anyone updated pcnfsd to use passwd.adjunct?
Has anyone upgraded the pcnfsd program to work with sunos 4.1.1 C2 passwd.adjunct files? If so, could I have a copy? Thanks! -Ed -- Ed Ramsey ramsey@npirs.purdue.edu 317/494-6616 FAX/494-0535 currently: "User Services Manager" soon to be: "Network Services Manager"
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Tue, 2 Apr 91 19:10:23 GMT From: hughes@bronze.ucs.indiana.edu (larry hughes) To: comp.protocols.tcp-ip,vmsnet.mail Subject: VMS POP3 server
IUPOP3, a VMS POP3 (Post Office Protocol Version 3) server, is now available via anonymous ftp from mythos.ucs.indiana.edu (129.79.16.210) in the /pub/iupop3 directory. It was developed here at Indiana University in recent months. IUPOP3 is a static, multithreaded server that can process up to 31 simulataneous POP3 client connections. This does not mean that it can serve only 31 clients; here at IU it serves dozens. It was developed on VMS 5.3 and 5.4 systems, and currently requires the Wollongong WIN/TCP for VMS product. (It uses their $QIO interface extensively). We have not yet attempted to port the code to other TCP/IP products for VMS, although we will likely do so for UCX in the future. We've tested IUPOP3 thoroughly with two POP3 clients: Eudora for the Macintosh, and FTP Software's POP3 for DOS. It will probably work well with others. //=========================================================================\\ || Larry J. Hughes, Jr. || hughes@indiana.edu || || Indiana University || || || University Computing Services || "The person who knows everything || || 750 N. State Road 46 Bypass || has a lot to learn." || || Bloomington, IN 47405 || || || (812) 855-9255 || Disclaimer: Same as my quote... || \\==========================================================================//
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 2 Apr 91 20:45:26 GMT From: van@EE.LBL.GOV (Van Jacobson) To: comp.protocols.tcp-ip Subject: Re: TELNET slow through bridge.
> One difficult tradeoff when deciding which packet to drop is > which end of the TCP window to start from. Most VJ TCPs seem to > react badly when you drop the more recent packets first, so > since v2.04 we drop the older ones. James, Could you elaborate on this a bit? If something's broken, I'd like to fix it. - Van
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 2 Apr 91 21:19:31 GMT From: vances@xenitec.on.ca (Vance Shipley) To: comp.protocols.tcp-ip Subject: Re: Digital phones for SLIP circuits
In article <8204@suned1.Nswses.Navy.MIL> efb@suned1.Nswses.Navy.MIL (Everett F Batey II) writes: >Confronted with an urgent need to run SLIP between two Sun3s (OS 4.1 and >4.1.1) and some easy to comeby telephone assets AND NO money for modems, >we are trying to pick the most trustworthy and easy to accomplish SLIP >link. Sites are within 3 miles, wire, 1/2 mile crow flight. > >- We have Meridian phones for which we can get 9600 baud RS-232 interfaces. >DOES ANYBODY know if with handshaking and async over digitized phone line, >these data phone options WORK SUCCESSFULLY for this purpose ? I have Northern Telecom Meridian 1 telephones also. I also have the data units equipped in EVERY telephone! They work quite well. We use them for modem pooling, we have two T1000's and a pair of UDS 9600 baud modems that every one in house has access to. I plan to use these for slip soon when I get TCP/IP for DOS that supports slip. I do use them for UUCP through the modem pools. These beasts actually run up to 19.2K asynch. Units that run up to 64K sysnchronous are available. If you have digital TIE lines between your sites you should have no problem doing this up to 56K. Vance Shipley vances@ltg ..uunet!watmath!xenitec!ltg!vances
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: 2 Apr 91 22:12:25 GMT From: rwolski@lll-crg.llnl.gov (Richard Wolski) To: comp.protocols.tcp-ip Subject: Bootp questions (a possible reposting)
Profuse apologies to those of you who have seen this before. I am posting this request for a friend with a somewhat unreliable news feed. Thanks for your patience, Rich =============================================== Sorry if you have seen this before, but my news feed has been flakey lately and I haven't seen it posted. Hi. I have some questions about bootp that someone out there might be able to answer. Is the bootp 2.1 (cmu) the must current version? What other versions are there out there (and where can I get them)? Is bootp the most widely used protocol to boot up network devices? Are there others? Has anyone run up against the 64 byte limitation of vendor specific data? If so, what did you do you about it? What is the method for specifying a vendor magic cookie (do you have to modify the boop server source?). Thanks any information will be appreciated! If I get responses, I will post the replies. Emily Hipp ehipp@wrs.com
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 2 Apr 91 22:27:23 GMT From: CCMARKM@UMCVMB.MISSOURI.EDU (Mark Moody) To: comp.protocols.tcp-ip Subject: Weird Iron
Greetings, I work in the NOC for MOREnet a new network and some of our members are bringing up TCP/IP implementations on ... some less common systems. I am looking for people who have worked with TCP/IP on systems like these and who would be willing to anwser some questions as they (will) arise down the road here. The systems in question are: an IBM AS/400 Model B55, a HP 3000 Series 58 running MPE-V operating system, and a Unisys mainframe (once a Burroughs) 'A' series A6KX. I personnaly don't have any experience with these but I would like to find *some* help for them. If you can offer any assistance, please let me know. Many thanks, Mark Moody MOREnet - MissOuri Research and Educational network University of Missouri - Columbia CCMARKM@umcvmb.missouri.edu (preffered) mark@noc.missouri.edu (alternate)
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 91 01:13:01 GMT From: rc@mit-caf.MIT.EDU (Ran-Chi Huang) To: comp.protocols.tcp-ip Subject: Determination of Statistics on a Subnet
I have an application that needs to determine the following : Average Utilization Average Packet Rates Peak Packet Rates Can any netters give me some ideas as to how I can approach the problem. I already have an application that processes packets on a per-packet basis. The aim is to put all this in a C program which will generate the results I need. Please mail responses to me at "rc@caf.mit.edu" because I do not read this list often. Thanks for any pointers. rc@caf.mit.edu
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 91 02:43:42 GMT From: tridge@anu.oz.au (Andrew Tridgell) To: comp.windows.ms,comp.protocols.tcp-ip Subject: Re: WinQVT/Net and 3C503 DMA support
If the reason you want non-shared memory support is to run in conjunction with SUN's PC-NFS then I suggest you use the pktd.sys driver to make PC-NFS work in shared memory mode. I have done this and have successfull combined PC-NFS, windows and NCSA Telnet, all using packet drivers and shared memory. You can get the "compatibility kit" from falstaff.cwru.edu in /pub/compat.kit it is called compat.zip and includes source. If you have troubles setting it up you can send me mail --- Andrew Tridgell tridge@aerodec.anu.edu.au
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 91 04:05:00 GMT From: HARISH@ITIVAX.BITNET To: comp.protocols.tcp-ip Subject: Question on FTP's MAC/NDIS driver + WinQVTNet
Folks, I have machines that run 3Com's 3+Open (LAN Manager) and have been trying without too much success to use FTP Software's MAC/NDIS to Packet Driver translator to provide a PktDrvr interface to the MS Windows app WinQVT/Net. WinQVT/Net works just fine when I load up the normal packet drivers and the PKTINT (provided by WinQVT/Net). However, I am then not able to get to my servers. Any suggestions? Please respond by e-mail. I'll summarize. Thanks. -- Harish Pillay harish@itivax.bitnet Senior Software Engineer harish@ece.orst.edu CSA Research Pte Ltd harish%temasek.uucp@cs.orst.edu 12 Science Park Dr #03-01 Singapore 0511 +65-772-0393 (w), +65-278-4191 (h)
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 91 12:15:21 MST From: haas%basset.utah.edu@cs.utah.edu (Walt Haas) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: 10BaseT installation
In article <1991Apr3.153750.19033@jhereg.osa.com> andrew@jhereg.osa.com (Andrew C. Esh) writes: > >If anyone is interested, I can write a longer posting on the ins and outs >of 10baseT, and the experiences I and my co-workers have had with it. I'd be interested. We have started to do 10BASE-T for offices where there is little chance that a second computer will be added. Thinnet still wins for student bullpens and labs with lots of machines in one room. The cost to us is about $300 + wiring per computer for 10BASE-T. Thinnet cost is a little more than half that. The big win with 10BASE-T is the situation where a computer locked in somebody's office goes nuts and starts to hose the network, or where somebody unplugs their cable. With 10BASE-T we don't have to check every office, we just check the hub, and wiring faults are dealt with automatically. In engineering offices where there are likely to be additional computers we still like the hub idea, but set up a multiport thinnet repeater and assign a port to an office. This gives us the same automatic recovery from wiring faults, at a slightly greater cost per office than 10BASE-T, with the chance to inexpensively add up to 14 more computers per office. -- Walt Haas haas@ski.utah.edu
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 91 08:11:08 GMT From: woody@ucscb.UCSC.EDU (Bill Woodcock) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: 10BaseT installation
> I have read a lot about 10BaseT and I am
> considering using it in a new facility.
> Everything I see has the twisted pair connector
> as a RJ45 but inplications are that twisted pair
> uses two pair or four wires. My question is how
> many pair do I need and if it is two pair why
> does 10BaseT use an RJ45 connector.
10BASE-T does indeed use four conductors. On an RJ-45 modular jack,
pin 1 is Rx+, pin 2 is Rx-, pin 3 is Tx+, and pin 6 is Tx-. When you
go to your wiring closet, they are normally punched down in that order
as well, pin 1 to row 1, pin 2 to row 2, pin 3 to row 3, and pin 6 to
row 4.
As to why 10BASE-T uses an RJ-45, I know of a couple of reasons, but I
don't know that any of them are "official." First and most important,
it's to keep people from plugging their phones into data jacks, and
vice versa. Secondly, it's to allow for people in the future plugging
their phones into data jacks, but making it work. You'll find that
ISDN normally uses pins 4, 5, 7, and 8.
-Bill Woodcock
BMUG NetAdmin
_______________________________________________________________________________
0000 : 0600 0800 7700 FE00 FF 0 FF8 7F 0 3 00 48 bill.woodcock.iv
0010 : CC00 7C00 0C00 1000 2800 440 8200 40
0020 : C000 4000 8000 C000 C 00 800 80 48 0 9 woody@ucscb.ucsc.edu
0030 : FF00 F000 7F80 CC00 CC 0 7 80 7 80 CC 6
0040 : CC00 7F80 9800 7800 CC00 CC0 CC 0 C 00 2355.virginia.st
0050 : CC00 CC00 FC00 CC00 CC 0 2000 10 0 7 00 C 0
0060 : CC00 CC00 CCC0 4800 2 00 1 00 2 00 48 0 9 berkeley.california
0070 : 4800 2400 1200 1000 2800 4 00 8 00 E0
0080 : 3000 6000 F000 6000 000 60 0 600 C0 0 01C 94709.1315
_______________________________________________________________________________
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 91 12:29:16 GMT From: kevin@exocet.mentec.ie To: comp.protocols.tcp-ip Subject: Honeywell Bull DPS700 ---> Ethernet (TCP/IP) ???
Hi Netlanders, A sister company has a Honeywell BULL DPS7000 system which needs a connection to an Ethernet lan. Does anyone know if there is a TCP/IP package available for a such a beast. As far as I can gather the system is running an operating system known as GCOS7. Also, any pointers on ethernet cards for the same would be very helpful. I realise that being an old system such hardware/software may not be available. Any help/comments greatly appreciated. thanks, Kevin. ------------------------------------------------------------------------------- Kevin O'Farrell | Internet/EUnet: Kevin@mentec.ie Technical Services Group.| Kevin@mentec.uucp Mentec Computer Systems. | PSI-Mail: PSI%272436059082::Kevin Pottery Road,Dun Laoire, | MCI-Mail: KOFARRELL / 390-4994 Co Dublin. Ireland | Voice: +353-1-858444 -------------------------------------------------------------------------------
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 91 14:37:37 GMT From: teb@SATURN.ACC.COM (Tom Benkart) To: comp.protocols.tcp-ip Subject: Message compression
In applications involving file transfers (FTP) over low speed lines, has anyone investigated any type of data compression on a message by message basis? I'm familiar with the header compression algorithms, but don't know of any data compression algorithms. The pay-off might not be very high, but any compression could be useful. Tom Benkart ACC
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 91 15:37:50 GMT From: andrew@jhereg.osa.com (Andrew C. Esh) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: 10BaseT installation
In article <5438@durin.sparta.COM> frankh@durin.laguna.sparta.com (Frank Halsema) writes: >I have read a lot about 10BaseT and I am considering using it in a new >facility. Everything I see has the twisted pair connector as a RJ45 but >inplications are that twited pair uses two pair or four wires. My >question is how many pair do I need and if it is two pair why does >10BaseT use an RJ45 connector. > > >Frank Halsema UUCP: durin!frankh >SPARTA, Inc. Internet: frankh@laguna.sparta.com >23041 de la Carlota, Suite 400 >Laguna Hills Ca, 92653 (714) 768-8161 EXT 339 (714)583-9114 FAX 10baseT tends to be used in the same "wiring closets" (IDF's) as telephone equipment, as well as the same wall plates, so I would guess the use of RJ45 is an attempt to make use of existing telephone wiring, without getting it confused with RJ11. RJ11 won't work with 10baseT jacks or transceivers, since the pairs are 1-2, and 3-6, with the lines as T+, T-, R+, and R-, respectively. Six wire RJ45 doesn't work, since you need pin 1 on the 8 wire RJ45. Pin 1 on the six conductor version connects to pin 2 of the 8 wire outlet. You have to use an 8 conductor RJ45 to plug into the 10baseT outlets and transceivers. Which plugs, punchdowns, wires, and connections you use in between the ends is your business, as long as the connections are fairly secure from EMI ingress, and the wire has at least 3 twists per foot, preferably more. You must maintain the pairs, and the polarity, obviously. Some transceivers will detect backward polarity, and reverse themselves to compensate. Regular "silver ribbon" telephone wire that they use to make desk-to-wall cords will cause collisions on a 10baseT connection. If anyone is interested, I can write a longer posting on the ins and outs of 10baseT, and the experiences I and my co-workers have had with it. -- Andrew C. Esh andrew@osa.com Open Systems Architects, Inc. Minneapolis, MN 55416-1528 So much System, (612) 525-0000 so little CPU time...
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 91 15:37:55 GMT From: lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) To: comp.protocols.tcp-ip,news.admin,comp.mail.misc Subject: Re: What Is Difference Between Internet And X.400 Style Names?
In article <1991Feb25.185436.11447@watserv1.waterloo.edu> broehl@watserv1.waterloo.edu (Bernie Roehl) writes: >In article <39557@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: >>Can someone please explain the difference between X.400 and Internet-style >>names of the form: USER@SITE.DOMAIN? I had thought that X.400 names >>were of the form /THIS=,/THAT=,/ANDWHATEVER=. > >They are. The standard syntax "user@site.domain" is used throughout the >Internet (and beyond!). The "/this=,that=" is unique to X.400, which is >part of the OSI spec. In any case, part of the confusion is the assumption that a standard's address format must be what is presented to the user. This isn't true. It's quite legal for a single system to have, say, an X.400 mailer, an SMTP (internet) mailer, and a UUCP mailer installed. The usual result would be that the poor users have to figure out for themselves which of the mailers talks to a given machine, and use the correct syntax for that mailer. Sendmail typically comes configured to require this. But this is extremely user-hostile, and there is no real excuse for it. It is quite legal, and not hard to program, to have the user interface accept addresses in multiple formats, parse them, figure out which of the mailers can handle a job, and convert the address to that mailer's format. This is, for example, what the smail package does. Sendmail also has the capability (if you can figure out how to change sendmail.cf to do it right ;-), and some vendors even supply sendmail configured to do this. Forcing the user to figure out bizarre mail syntaxes is inexcusable in these days of mass email confusion. That's what we have computers for. If your mail interface can't do the translation, you should harass your vendor until they get it right.
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 91 20:15:25 GMT From: albers@ka3ovk (Jon Albers) To: comp.dcom.modems,comp.protocols.tcp-ip Subject: Anyone gotta netblazer
We just got 2 Netblazers (2 serial, 2 ethernet cards, 1 T2500) to evaluate here. We have 2 networks to link via the T2500 and phone line: The ssi network consists of: 100.30.0.1 ssi <-- The netblazer at ssi. 100.30.0.5 irs5 <-- Unix mini 100.30.0.6 irs6 <-- Unix mini 100.30.0.8 irs8 <-- Unix mini 100.30.0.10 ka3ovk <-- SCO Unix micro 100.30.0.11 w3wox <-- SCO Unix micro The bxr network consists of: 89.0.0.1 sys95 <-- Unix mini 89.0.0.2 sys85 <-- Unix mini 89.0.0.3 bxr <-- The netblazer at bxr. Now, the netblazers at both networks are set up and working as terminal servers. I can log in and telnet from the netblazer to any other host on the LOCAL network, and any other host on the LOCAL network can telnet to the LOCAL netblazer. Convincing the netblazer to connect the 2 networks together has been difficlut. I think we have followed the directions in the manual OK, but any attempt to cannect to a host on the 89.x.x.x net from the ssi netblazer still causes it to look out the LOCAL ethernet and vice versa. When I log into the netblazer, and do a 'session dial bxr', it complains that 'no dialout lines are available', although the dialup is defined properly as far as Ican tell. Has anyone set up a netblazer yet!?! I have several calls into our local Telebit office, but I have not gotten a call back in 2 days of trying.. Jon -- | Jon Albers, IRS, Information Systems Management, Support and Installation. | | Office Symbols: ISM:S:S:SI voice: (202/FTS)535-3729 Packet: KA3OVK@N4QQ | | UUCP:(media|teemc|tcsc3b2|ki4pv)!ka3ovk!albers ARPA: JALBERS@SIMTEL20 |
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Wed, 3 Apr 91 21:34:18 GMT From: chlebosc@nadia.stgt.sub.org (Claudius Chlebosch) To: comp.os.os2.programmer,comp.protocols.tcp-ip Subject: Problems with IBMs TCP/IP V1.1 for OS/2
I got some problems with IBMs TCP/IP V1.1 for OS/2 using stream sockets an i hope to get some help on this way. I have to write a program, which transfers data using stream sockets in portions of 32 kByte. The sender should send this portions with one call to the send() function and the receiver should get this portions with one call to the recv() function. This works very well, if the size of the transmitted segments does not exceed about 6000 bytes and only one segment is transferred using the same socket. In the other case the receiving program has to call the function recv() several times to get the complete segment. Normally the recv() function should block the process, until the whole segment is reveived. For example: the client calls send() with the msgLen set to 20000. The server calls the recv() function, which blocks the process, until the whole 20000 bytes are received. The client calls send() once again with the msgLen set to 20000. The server calls the recv() function, which returns with 4360 bytes received. The client has to call the recv() function once again to get the remaining 15640 bytes of the segment. In my opinion this behaviour is not correct. second problem: If the server an the client reside in the same machine, no fragmentation is detected, if the size of the transmitted segments is less than the receivebuffersize (which is 23360 bytes as reported by the function getsockopt() ). This beviaour does not change, even if the receivebuffersize of the receiving socket and the sendbuffersize of the sending socket are increased via the setsockopt() call. The border at which fragmentation begins remains at 23360 bytes. My configuration is: two IBM PS/2 (mod 80 and mod 50Z) both with an Token-Ring adaptercard 16/4 A and OS/2 1.2 EE CSD:4098 and TCP/IP V1.1 for OS/2 (Program number: 5798-RXW Part Number : 66F5612). The mtu parameter of the TCP/IP is set to 4400 as it is recommended in the documentation. I hope somebody can give me a hint how i can solve this problem. Thanx for reading this message. Klaudius Chlebosch -- Klaudius Chlebosch | usenet: ..chlebosc@nadia.stgt.sub.org Eschenweg 1 | Mailbox: *49 711 484464 24 h 1200/2400 Baud D-7045 Nufringen | *49 711 461592 24 h 1200/2400 Baud Tel.: *49 7032 82023 |
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 00:26:58 GMT From: ted@blia.sharebase.com (Ted Marshall) To: comp.protocols.tcp-ip Subject: Re: Problems with TCP, read(), and write()
The problem is that TCP is a pure stream protocol that does not preserve
record boundries. Thus, if something delays the processing on some of the
bytes from one of your write()s, your read can easily complete with only the
beginning of what we written.
Since you know that all "records" are 32 bytes, there is a real easy solution:
if your read() completes with less than 32 bytes, add that count to your
buffer pointer, subtract the count from your buffer size, and repeat the read.
Continue this loop until your buffer is full. For example:
ptr = &buffer[0];
cnt = sizeof buffer;
do
{
i = read(d, ptr, cnt);
if (i <= 0)
<error-processing>
ptr += i;
cnt -= i;
} while (cnt > 0);
--
Ted Marshall ted@airplane.sharebase.com
ShareBase Corp., 14600 Winchester Blvd, Los Gatos, Ca 95030 (408)378-7000
The opinions expressed above are those of the poster and not his employer.
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 01:42:30 GMT From: lee@locus.com (Lee Slaughter) To: comp.protocols.tcp-ip Subject: tn connect closed
On a foreign site, over which we have no control, people need to telnet in from here. An irritating problem that sometimes occurs is "Connection closed by foreign host" right after the login screen (on foreign site) appears. Frequent retries then usually succeed. (debug output shows nothing except some terminal negotiation) I know there are many things (on the foreign site) that can cause this but what can we suggest to the administrator of that foreign site in the way of configuration things to check there. I don't know of any way we can tell from here. Please e-mail me as I can't usually keep up with this group. thanks............. lee@locus.com
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 03:15:06 GMT From: caserta@athena.mit.edu (Francesco Caserta) To: comp.protocols.tcp-ip Subject: finger weather
The Department of Atmospheric Sciences, University of Washington
provides the following service, and also unusual application of finger.
Do you know of any other unusual application of finger?
(RFC742, RFC1194 and RFC1196)
finger [...]@stormy.atmos.washington.edu
[stormy.atmos.washington.edu]
Format: finger weather[-station[-type[-day]]e.g.: finger weather-SEA-zone
where: station = station for required area or hiway (default=SEA)
type = disc, zone, warn, extend (default=zone)
day = day of month forecast was issued (default=today)
Washington SEA Seattle
Oregon PDX Portland
Northern and central California SFO San Francisco
Southern California LAX Los Angeles
Hawaii HNL Honolulu
Nevada RNO Reno
Idaho BOI Boise
Montana GTF Great Falls
Wyoming CYS Cheyenne
Utah SLC Salt Lake City
Arizona PHX Phoenix
Colorado DEN Denver
New Mexico ABQ Albuquerque
North Dakota BIS Bismark
South Dakota FSD Sioux Falls
Nebraska OMA Omaha
Kansas TOP Topeka
Oklahoma OKC Oklahoma City
Western Texas LBB Lubbock
Northern Texas FTW Fort Worth
Southern Texas SAT San Antonio
Minnesota MSP Minneapolis
Iowa DSM Des Moines
Missouri STL St. Louis
Arkansas LIT Little Rock
Louisiana NEW New Orleans
Mississippi JAN Jackson
Wisconsin MKE Milwaukee
Michigan ARB Ann Arbor
Illinois CHI Chicago
Indiana IND Indianapolis
Ohio CLE Cleveland
Kentucky SDF Louisville
Tennessee MEM Memphis
Alabama and northwest Florida BHM Birmingham
Georgia ATL Atlanta
Florida (except northwest) MIA Miami
South Carolina CAE Columbia
North Carolina RDU Raleigh
Virginia RIC (issued by WBC)
West Virginia CRW Charleston
DC and vicinity WBC Washington
Western Pennsyvania PIT Pittsburgh
Eastern Pennsyvania PHL Philadelphia
Western New York BUF Buffalo
Interior eastern New York ALB Albany
S.E. New York and N. New Jersey NYC New York City
Southern New England states BOS Boston
Vermont BTV (issued by ALB)
New Hampshire CON (issued by PWM)
Maine PWM Portland
Francesco Caserta
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 05:23:06 GMT From: faunt@CISCO.COM (Doug Faunt N6TQS 415-688-8269) To: comp.protocols.tcp-ip Subject: 10BaseT installation
We use 10BaseT here, on RJ-11's. We use mass termination on the 10BaseT hubs, to 66 blocks, and cross connect to the 2nd and third pairs of the RJ-11's. We use a custom cable to connect the RJ11 to the MAU, which we have made up for, I think, $8.00. We don't do it, but you could run a telephone connection on the first pair, and 10BaseT on the other two pairs simultaneously. I have a couple of adapters somewhere around that will do that out of one RJ11.
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 11:41:20 GMT From: solensky@animal.clearpoint.com (Frank T. Solensky) To: comp.protocols.tcp-ip Subject: Re: Message compression
In article <9104031437.AA14650@saturn.acc.com> teb@SATURN.ACC.COM (Tom Benkart) writes: In applications involving file transfers (FTP) over low speed lines, has anyone investigated any type of data compression on a message by message basis? I'm familiar with the header compression algorithms, but don't know of any data compression algorithms. The pay-off might not be very high, but any compression could be useful. One of the problems with a number of data compression algorithms (eg: Lempel-Ziv encoding, the one used by the Unix 'compress' command) is that they need to be able to look at the entire data stream before being able to compress any part of it. In this case, it would be about the same as running compress yourself and then FTPing the resulting file. Another approach would be to use something like an adaptive Huffman code (the details of which I know nothing about). The '/usr/old/compact' command on Sun's Release 4.1 takes this approach by encoding the data as it is being read in and sending it out immediately. The man page lists the following reference (and also indicates that the command will NOT be distributed or supported in future releases): Gallager, Robert G., Variations on a Theme of Huffman, IEEE Transactions on Information Theory, vol.IT-24, no. 6, Novermber 1978, pp. 668-674. I believe that the Applications Area of the Internet Engineering Task Force is planning to look into improvements to FTP such as this at some point in the near future, but I'm afraid I don't know what the time frames or immediate plans are. -- -- Frank Solensky / Clearpoint Research Corp. Red Sox magic number: 163
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 14:37:00 GMT From: 0004219666@MCIMAIL.COM (Bob Stine) To: comp.protocols.tcp-ip Subject: Re: Problems with TCP, read(), and write()
>I am having problems with TCP, write(), and read(). I want to send and
>receive 32 byte structures....
>My problem is that if I do no put a sizeable delay in the
>send or receive loop, I end up receiving only part of a 32 byte chunk
>after a number of chunks have been received.
Shawn,
As you have discovered, TCP does not preserve record boundaries. One
work-around makes use the value returned by read(), which is the number of the
bytes read. Keep reading until you get your entire 32 bytes. I.e.,
int bf_ln, /* number of bytes requested */
bc, /* byte count returned by read() */
s; /* socket */
struct shawns_struct { /* whatever, 32 bytes worth */} in_rec;
char *bptr;
/* get the connection. Then, to load a structure... */
bf_ln = sizeof(struct shawns_struct);
bptr = (char *) in_rec;
while (bf_ln)
{
bc = read(s,bptr,bf_ln);
if (bc < 1)
exit(-1);
bf_ln -= bc;
bptr += bc;
}
Note that I exit if read() returns a value of zero. In BSD, select() will
indicate that a closed socket is ready to read, but read() will return zero
bytes. Hence, if the above loop didn't exit when read() returned a zero, then
a closed socket would keep it busy for quite some time... :-)
Regards,
Bob Stine
bstine@MCIMail.com
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 15:23:45 GMT From: andrew@jhereg.osa.com (Andrew C. Esh) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: 10BaseT installation
From the response, both here and in EMail, this sounds like a really hot subject. I will put together as much as I can, and post it soon. -- Andrew C. Esh andrew@osa.com Open Systems Architects, Inc. Minneapolis, MN 55416-1528 So much System, (612) 525-0000 so little CPU time...
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 16:10:19 GMT From: oleg@watson.ibm.com To: comp.os.os2.programmer,comp.protocols.tcp-ip Subject: Re: Problems with IBMs TCP/IP V1.1 for OS/2
In <ZSNPX4T@nadia.stgt.sub.org> chlebosc@nadia.stgt.sub.org (Claudius Chlebosch) writes: > I got some problems with IBMs TCP/IP V1.1 for OS/2 using stream sockets an i > hope to get some help on this way. > > I have to write a program, which transfers data using stream sockets in portions > of 32 kByte. The sender should send this portions with one call to the send() > function and the receiver should get this portions with one call to the recv() > function. > This works very well, if the size of the transmitted segments does not exceed ab > 6000 bytes and only one segment is transferred using the same socket. In the > other case the receiving program has to call the function recv() several times > to get the complete segment. Normally the recv() function should block the proce > until the whole segment is reveived. No, it is not how recv()/send() work. You can't make any assumptions on size of segments that you get with recv(). Also, there is 8K per call limit on send/recv in OS/2 TCP/IP implementation. [TEXT DELETED] > second problem: > If the server an the client reside in the same machine, no fragmentation is > detected, if the size of the transmitted segments is less than the > receivebuffersize (which is 23360 bytes as reported by the function getsockopt() > ). This beviaour does not change, even if the receivebuffersize of the > receiving socket and the sendbuffersize of the sending socket are increased via > the setsockopt() call. The border at which fragmentation begins remains at > 23360 bytes. What do you mean by fragmentation, and what is the problem here ? [TEXT DELETED] > Klaudius Chlebosch | usenet: ..chlebosc@nadia.stgt.sub.org Oleg Vishnepolsky
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Thu, 4 Apr 1991 18:02:39 GMT From: henry@zoo.toronto.edu (Henry Spencer) To: comp.protocols.tcp-ip Subject: Re: Message compression
In article <SOLENSKY.91Apr4114120@animal.clearpoint.com> solensky@animal.clearpoint.com (Frank T. Solensky) writes: >One of the problems with a number of data compression algorithms >(eg: Lempel-Ziv encoding, the one used by the Unix 'compress' command) >is that they need to be able to look at the entire data stream before >being able to compress any part of it... Telebit would be very surprised to hear this; all their modems do Lempel-Ziv compression on the fly. No, LZ does *not* need to look at the entire data stream before being able to compress any part of it. -- "The stories one hears about putting up | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 are all true." -D. Harrison| henry@zoo.toronto.edu utzoo!henry
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 18:05:41 GMT From: solensky@animal.clearpoint.com (Frank T. Solensky) To: comp.protocols.tcp-ip Subject: Re: Message compression
In article <1991Apr4.180239.12442@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: Telebit would be very surprised to hear this; all their modems do Lempel-Ziv compression on the fly. No, LZ does *not* need to look at the entire data stream before being able to compress any part of it. Faux pas, mea culpa, *sigh*! Looking at the man page again, I see that the "compress" command does indeed use an _adaptive_ LZ coding.. The main point I wanted to make was that the IETF is, at least, aware of the desire for compression within FTP. -- -- Frank Solensky / Clearpoint Research Corp. Red Sox magic number: 163
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 18:21:15 GMT From: metzger@watson.ibm.com (Perry E. Metzger) To: comp.protocols.tcp-ip Subject: Re: finger weather
In article <1991Apr4.031506.6778@athena.mit.edu> caserta@athena.mit.edu (Francesco Caserta) writes: >The Department of Atmospheric Sciences, University of Washington >provides the following service, and also unusual application of finger. >Do you know of any other unusual application of finger? The RFC for finger specifies fingers behavior when applied to coke machines. It is my understanding that CMU used to have a coke machine on the internet that followed the stated behavior, although this may be an urban legend. Perry Metzger
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 20:35:15 GMT From: dshardin@zoot.avgrp.cr.rok.com (David Hardin) To: comp.protocols.tcp-ip Subject: XTIS info?
I am looking for information on XTIS, the X/Open Transport Interface
Specification (at least, I think that's what it stands for). Is there
any info available via anonymous ftp, or do I have to contact X/Open?
Thanks in advance,
David Hardin
--
David S. Hardin Collins Commercial Avionics
Rockwell International
M/S 124-211, 400 Collins Rd. NE
INTERNET: dshardin@zoot.avgrp.cr.rok.com Cedar Rapids, IA 52498
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 20:46:14 GMT From: ww0n+@ANDREW.CMU.EDU (Walter Lloyd Wimer III) To: comp.protocols.tcp-ip Subject: Re: Bootp questions (a possible reposting)
Emily,
> Hi.
> I have some questions about bootp that someone out
> there might be able to answer.
> Is the bootp 2.1 (cmu) the must current version?
> What other versions are there out there
> (and where can I get them)?
Bootpd 2.1 is the most recent release of bootpd from CMU. I have not
had time to work on it in quite a while, but I will again eventually.
The IETF Dynamic Host Configuration Working Group is working on a new
Dynamic Host Configuration Protocol (DHCP) based on BOOTP. I will
eventually be writing and releasing a DHCP server which will work with
DHCP clients and old BOOTP clients.
A number of people have suggested improvements to CMU's bootpd. Several
have added their own local extensions or ported it to other operating
systems (Unix System V, MS-DOS, VMS). Unfortunately, there hasn't been
much effort to coordinate these versions or gather them together in a
single place (largely my fault for being unable to devote the time). As
such, I don't really know where to find these other versions.
I know of no independently-developed BOOTP servers; all seem to be
derivations of the Stanford/CMU bootpd for BSD Unix. (Someone please
correct me if I am wrong!)
The CMU distribution of bootpd is available via anonymous FTP from
LANCASTER.ANDREW.CMU.EDU (128.2.13.21) in the file pub/bootp.2.1.tar.
This is actually a slightly newer version which calls itself 2.1a. It
includes just a few minor bug fixes which were often reported to me.
> Is bootp the most widely used protocol
> to boot up network devices? Are there others?
RARP provides another alternative for assigning IP addresses to booting
hosts. It only deals with the IP address assignment issue (unlike BOOTP
which can also pass information such as the subnet mask, default
router(s), etc.). RARP is a link-layer protocol, so it cannot work
across routers like BOOTP can.
There are other protocols which deal with various aspects of the network
boot problem. The DHC "Problem Statement" Internet Draft touches on
some of them. This was available via anonymous FTP from NNSC.NSF.NET in
the internet-drafts/ directory, but seems to have disappeared (it
probably expired).
> Has anyone run up against the 64 byte limitation
> of vendor specific data? If so, what did you
> do you about it?
Yes, CMU certainly has and I know others have. The DHCWG is trying to
address this problem as well. One suggestion has been to modify both
BOOTP clients and servers to simply send larger packets. In many
instances, the network manager knows the minimum MTU (Maximum
Transmission Unit) between the BOOTP server and a given client. The
BOOTP server could be configured with this information and could then
send a packet up to that size.
I must stress that, so far, this is only a suggestion and is not
guaranteed to work in all environments, etc., etc.
Another suggestion is to use the vendor field to communicate a file name
containing configuration information and then use TFTP or something to
transfer that file.
> What is the method for specifying a vendor
> magic cookie (do you have to modify
> the boop server source?).
Yes; this is really the only way if you don't want to use the CMU or
RFC1084/RFC1048 formats. Bootpd does contain some code to let you
specify an arbitrary vendor magic cookie, but there is no way to then
specify what actual information should go in the remaining 60 octets.
This is one of those features that was sort-of half-implemented and then
forgotten/abandoned.
Note that you can stick with RFC1084/RFC1048 format and define your own
custom tags with the generic tag ":Tn=xxxx:" bootptab construct. From
RFC1084:
Reserved Fields (Tag: 128-254, Data: N bytes of undefined
content)
Specifies additional site-specific information, to be
interpreted on an implementation-specific basis. This
should follow all data with the preceding generic tags 0-
127).
> Thanks any information will be appreciated!
> If I get responses, I will post the replies.
There is also a mailing list devoted to open discussion about BOOTP and
questions such as yours. The submission address is:
bootp@andrew.cmu.edu
In the Internet tradition, please send requests to be added to or
removed from the mailing list to:
bootp-request@andrew.cmu.edu
> Emily Hipp
> ehipp@wrs.com
Walt Wimer
Network Development
Carnegie Mellon University
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 23:34:08 GMT From: parr@wglen.ab.ca (Bob Parr) To: comp.protocols.tcp-ip Subject: (none)
To Whom It May Concern ... This is probably a question that has been asked and answered many times in the last six months but we've been unplugged from the USENET for the past year so I'm operating out of a news blackout. In the INTEROP 1991 brochure that advertises Doug Comer's TCP/IP Internals and Implementation tutorial mention is made of his book "Internetworking with TCP/IP: Design, Implementation, and Internals, Vol 2". On a recent business trip to the Bay Area I stopped in at the Stanford Bookstore to see if this book was available and found that it had ( as of the end of January at least ) not yet been published. If you could respond with any information as to the current or future availability of this book I would be greatly appreciative. Thanks in advance, Bob Parr SCADACOM Product Manager Willowglen Systems Ltd. Calgary, Alberta, Canada Tel: (403)-272-1800 Fax: (403)-272-2114 parr@wglen.ab.ca
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 91 23:50:41 GMT From: rsk@hazel.circ.upenn.edu (Rick Kulawiec) To: comp.protocols.tcp-ip Subject: Re: finger weather
In article <1991Apr4.182115.3531@watson.ibm.com> metzger@watson.ibm.com (Perry E. Metzger) writes: >The RFC for finger specifies fingers behavior when applied to coke >machines. It is my understanding that CMU used to have a coke machine >on the internet that followed the stated behavior, although this may >be an urban legend. I think it was for real...the three notes below cover the story, and are probably worth reposting here since it's been a while since they first appeared. ---Rsk Originally-From: tgl@zog.cs.cmu.edu (Tom Lane) Original-Newsgroups: alt.folklore.computers Original-Subject: The only Coke machine on the Internet Original-Date: 11 Dec 89 15:45:34 GMT This story is old news to ex-CMU folk, but may be amusing to others. Since time immemorial (well, maybe 1970) the Carnegie-Mellon CS department has maintained a departmental Coke machine, which sells bottles of Coke for a dime or so less than other vending machines around campus. As no Real Programmer can function without caffeine, the machine is very popular. (I recall hearing that it had the highest sales volume of any Coke machine in the Pittsburgh area.) The machine is loaded on a rather erratic schedule by grad student volunteers. In the mid-seventies expansion of the department caused people's offices to be located ever further away from the main terminal room where the Coke machine stood. It got rather annoying to traipse down to the third floor only to find the machine empty; or worse, to shell out hard-earned cash to receive a recently loaded, still warm Coke. One day a couple of people got together to devise a solution. They installed microswitches in the Coke machine to sense how many bottles were present in each of its six columns of bottles. The switches were hooked up to CMUA, the PDP-10 that was then the main departmental computer. A server program was written to keep tabs on the Coke machine's state, including how long each bottle had been in the machine. When you ran the companion status inquiry program, you'd get a display that might look like this: EMPTY EMPTY 1h 3m COLD COLD 1h 4m This let you know that cold Coke could be had by pressing the lower-left or lower-center button, while the bottom bottles in the two right-hand columns had been loaded an hour or so beforehand, so were still warm. (I think the display changed to just "COLD" after the bottle had been there 3 hours.) The final piece of the puzzle was needed to let people check Coke status when they were logged in on some other machine than CMUA. CMUA's Finger server was modified to run the Coke status program whenever someone fingered the nonexistent user "coke". (For the uninitiated, Finger normally reports whether a specified user is logged in, and if so where.) Since Finger requests are part of standard ARPANET (now Internet) protocols, people could check the Coke machine from any CMU computer by saying "finger coke@cmua". In fact, you could discover the Coke machine's status from any machine anywhere on the Internet! Not that it would do you much good if you were a few thousand miles away... As far as I know nothing similar has been done elsewhere, so CMU can legitimately boast of having the only Coke machine on the Internet. The Coke machine programs were used for over a decade, and were even rewritten for Unix Vaxen when CMUA was retired in the early eighties. The end came just a couple years ago, when the local Coke bottler discontinued the returnable, coke-bottle-shaped bottles. The old machine couldn't handle the nonreturnable, totally-uninspired-shape bottles, so it was replaced by a new vending machine. This was not long after the New Coke fiasco (undoubtedly the century's greatest example of fixing what wasn't broken). The combination of these events left CMU Coke lovers sufficiently disgruntled that no one has bothered to wire up the new machine. I'm a little fuzzy about the dates, but I believe all the other details are accurate. The man page for the second-generation (Unix) Coke programs credits the hardware work to John Zsarnay, the software to David Nichols and Ivor Durham. I don't recall who did the original PDP-10 programs. tom lane ========== Orginally-From: sgw@cad.cs.cmu.edu (Stephen Wadlow) Orginal-Newsgroups: alt.folklore.computers Orginal-Subject: Re: The only Coke machine on the Internet Orginal-Date: 11 Dec 89 20:26:30 GMT In article <7295@pt.cs.cmu.edu> tgl@zog.cs.cmu.edu (Tom Lane) writes: >This story is old news to ex-CMU folk, but may be amusing to others. [story of the CMU coke machine] At the annual Jimmy Tsang's dinner expedition last saturday, I was talking with a member of the CS Facilities staff [Hi Steve :-)] who is currently working on the new hardware for the coke server. In addition to monitoring the status of the coke machine, the new server will re-implement the JF (junk food) protocol, telling you the status of the CS M&M dispenser and other CS-affiliated junk food dispensers. It's hoped that this will all be finished and installed by early next year, such that any internet site will be able to finger coke@cs.cmu.edu once again. An addendum to the coke story is that for quite sometime there was a Perq sitting behind a large glass window in front of the elevators on the third floor of science hall that frequently ran a variation of the coke program that would display bar graphs indicating the amount of time since the machine had been filled. You now didn't even have to be logged in to find out if the coke was cold, rather you could just be riding by on the elevator and decide on the fly if you wanted to grab a cold coke. You used to (and still may) be able to finger weather@hermes.ai.mit.edu to find out what the weather was like on the 9th floor of tech square (the ai labs). steve ========== Originally-From: colbath@cs.rochester.edu (Sean Colbath) Original-Newsgroups: alt.folklore.computers Original-Subject: Re: The only Coke machine on the Internet Original-Date: 11 Dec 89 19:01:21 GMT I don't think the students at RIT (Rochester Institute of Technology) get this newsgroup, so I'll relate this (true) story. At UR, there is an organization known as the Computer Interest Floor, an area of campus housing where computer oriented people can get together. RIT has a similar organization, known as CSH (Computer Science House, or...). Many of their members are quite hardware oriented. Well, apparently they found an old slightly malfunctioning coke machine that was being thrown out (can-style). They decided to install this on their hall, but were informed by the powers that be that the university had granted a monopoly on vending machines to a city vending machine service, and they couldn't set it up. So, they decided to come up with a way to get around this rule: they changed the coke machine from a vending machine to a peripheral! The vending machine has a serial line running from it to one of the unix systems. It looks much like a regular machine, except it has a red calculator-like display that says "Coke" on it. If you press a button, it'll tell you how many sodas are in that particular bin, or "Empty". Next to it is a terminal with the time of day displayed, and a coke logo. To buy a coke, all you have to do is to "log on" to your coke machine account at the terminal, look at the status report, and "buy" your coke by selecting from a menu. Each user had a bank account that was added to by giving the machine maintainers more money. Now, this isn't all -- you could buy your coke from any terminal in their housing section (every room had one, and they had two semi-public terminal areas. If you wanted to, you could program in a delay before the machine dropped your coke, so you wouldn't get down the hall to find someone had snarfed your coke. Apparently they wanted coke to come do a commercial showing someone hacking on a terminal, pausing with a thirsty look on their face, type "coke", race down the hallway, and arrive just in time to have the machine plop a soda in their hand...! Sean Colbath colbath@cs.rochester.edu ...uunet!rochester!colbath
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 01:27:07 GMT From: mikem@ibmpa.awdpa.ibm.com To: comp.os.os2.programmer,comp.protocols.tcp-ip Subject: Re: Problems with IBMs TCP/IP V1.1 for OS/2
In article <ZSNPX4T@nadia.stgt.sub.org> chlebosc@nadia.stgt.sub.org (Claudius Chlebosch) writes: >I got some problems with IBMs TCP/IP V1.1 for OS/2 using stream sockets an i >hope to get some help on this way. > >I have to write a program, which transfers data using stream sockets in portions >of 32 kByte. The sender should send this portions with one call to the send() >function and the receiver should get this portions with one call to the recv() >function. No. You can *not* code your client program to expect that a block of bytes sent by your server will arrive in a single receive. It doesn't matter what TCP/IP implementation you use. To do so is to cripple your client. What you need to do is place some sort of signature byte so that your client knows when the data block is complete and can process that block at that time. Michael R. MacFaden IBM Palo Alto Marketing Systems mikem@ibmpa.awdpa.ibm.com, macfaden@paloic1.vnet.ibm.com disclaimer: what I write above is not necessarily my employer's opinion
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 04:50:55 GMT From: ww0n+@ANDREW.CMU.EDU (Walter Lloyd Wimer III) To: comp.protocols.tcp-ip Subject: Re: Message compression
> Excerpts from internet.tcp-ip: 4-Apr-91 Re: Message compression Frank T. > Solensky@ucsd.e (1666) > One of the problems with a number of data compression algorithms > (eg: Lempel-Ziv encoding, the one used by the Unix 'compress' command) > is that they need to be able to look at the entire data stream before > being able to compress any part of it. In this case, it would be about > the same as running compress yourself and then FTPing the resulting file. From empirical evidence, I don't believe this is true. The 'compress' program can read from a pipe. I've used this feature to create a compressed tar file of a directory tree in a single step: tar -cf - somedirectory | compress -c > somedirectory.tar.Z Granted, it could be buffering quite a bit of data in virtual memory, but I doubt it was buffering the 90 megabytes worth of data from one particular tar I remember. (My system only has 64 megs of swap space. . . .) Recently, there was also an excellent posting to the comp.sources.unix newsgroup concerning compression techniques. It included a draft of a paper on the workings of various compression algorithms, including a newly-invented variant of Lempel-Ziv which the author seems to claim is free of patent (he calls it "Y-coding"). While I know and understand very little about compression techniques, a brief reading of the paper seems to suggest that these compression techniques work quite well even applied to (relatively small) finite-sized chunks of data. An implementation of the new algorithm is included in the posting. Walt Wimer Network Development Carnegie Mellon University
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 07:55:01 GMT From: romkey@ASYLUM.SF.CA.US (John Romkey) To: comp.protocols.tcp-ip Subject: finger weather
Date: 4 Apr 91 18:21:15 GMT From: decwrl!uunet.uu.net!bywater!arnor!halley!metzger (Perry E. Metzger) The RFC for finger specifies fingers behavior when applied to coke machines. It is my understanding that CMU used to have a coke machine on the internet that followed the stated behavior, although this may be an urban legend. No, it's true. CMU did have a coke machine on the Internet. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us voice/fax: 415 594-1141
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 08:03:32 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: Bootp questions (a possible reposting)
In article <Ibyt2Ki00WCp44dZAH@andrew.cmu.edu> ww0n+@ANDREW.CMU.EDU (Walter Lloyd Wimer III) writes:
>RARP provides another alternative for assigning IP addresses to booting
>hosts. It only deals with the IP address assignment issue (unlike BOOTP
>which can also pass information such as the subnet mask, default
>router(s), etc.). RARP is a link-layer protocol, so it cannot work
>across routers like BOOTP can.
Why couldn't an RARP server rebroadcast the RARP request on another subnet,
and then forward the response back to the original host? BOOTP's "routing"
is done at the application layer, because IP-layer routing requires the
client to know most of the information it is trying to find out from the
BOOTP server. Since BOOTP does its routing at the application layer, so
could RARP.
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmar
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 08:12:03 GMT From: francis@zaphod.uchicago.edu To: comp.protocols.tcp-ip Subject: FTP site for RFCs?
Is there an FTP site with RFCs? I'm kinda interested in seeing the protocol specs for the stuff I'm using, but I'm just a student (not even a CS student at that :-), so I don't have any clue about who handles this stuff. -- /============================================================================\ | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | Earth: Love it or leave it. | | francis@zaphod.uchicago.edu | | \============================================================================/
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 11:59:00 GMT From: CSP1DWD@MVS.OAC.UCLA.EDU (Denis DeLaRoca 825-4580, 213) To: comp.protocols.tcp-ip Subject: Re: Re: finger weather
Alas, the weather finger service at <stormy.atmos.washington.edu> is not more, it's been replaced by an equivalent RPC-based service. The RPC-client source code can be obtained by fingering "weather" at the above host. -- Denis
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Fri, 5 Apr 1991 14:20:41 GMT From: dcarr@hobbit.gandalf.ca (Dave Carr) To: comp.protocols.tcp-ip Subject: Re: Message compression
In <1991Apr4.180239.12442@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <SOLENSKY.91Apr4114120@animal.clearpoint.com> solensky@animal.clearpoint.com (Frank T. Solensky) writes: >>One of the problems with a number of data compression algorithms >>(eg: Lempel-Ziv encoding, the one used by the Unix 'compress' command) >>is that they need to be able to look at the entire data stream before >>being able to compress any part of it... >Telebit would be very surprised to hear this; all their modems do >Lempel-Ziv compression on the fly. No, LZ does *not* need to look at >the entire data stream before being able to compress any part of it. >-- I agree with Henry. LZW type algorithms can me made to adapt very quickly by adjusting the number of characters learned after each match. For example, V.42 bis data compression has the number of characters learned as a settable parameter (N8 I believe). As for speed, LZW can be made very fast. After all, it was designed with disk controller applications. The main problem with LZW is expanding uncompressable (or precompressed) data. Again, this is addressed with V.42 bis (but not with standard LZW). If the compressor can handle the uncompressable cases without expansion (or minimize the expansion), then TCPIP compression is a winning solution. Couple this with Van Jacobson's header compression, (or better the one which we will soon debut) and you can get substantial compression. I won't quote compression rates and spoil the marketting peoples fun. BTW Henry, does Telebit use LZW, LZSS, or LZH ?
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 15:06:54 GMT From: smith@newsserver.sfu.ca (Richard Smith) To: comp.protocols.tcp-ip Subject: Re: finger weather
Here is what fingering "coke" will get you now: [cs.cmu.edu] [ Forwarding coke as "gripe@vega.fac.cs.cmu.edu" ] [VEGA.FAC.CS.CMU.EDU] Login name: gripe In real life: Gripe Directory: /usr1/gripe Shell: /usr/cs/bin/csh Last login Tue Mar 5 10:22 on ttyP7 from GLN.FAC.CS.CMU.EDU Mail came on Fri Apr 5 09:57, last read on Fri Apr 5 09:01 Plan: CS/RI User Services Software and hardware requests, bug reports and fixes, general questions about the facility -- all of these can be sent to "gripe". Gripe mail is *NOT* constantly monitored. If you have a problem which requires immediate attention, please call the CS Operator (x2607).
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 15:53:17 GMT From: ypinn@gpu.utcs.utoronto.ca To: comp.protocols.tcp-ip,comp.protocols.ibm Subject: TCP/IP tunnelled in IBM/SNA
As hideous as this may sound, is there a UNIX TCP/IP implementation that has this capability? In order for this to work, the UNIX box would need to support SDLC based links, SNA services, and TCP/IP tunnelled through SNA using an APPC. Your probably asking yourself, why does this madman want to do this? I work for a large multi-national accounting firm. Our firm uses a public mail system in Canada as the basis of their enterprise-wide mail system. My group is trying to develop a proposal to bring our mail system in house. The system would use a combination of Macintosh computers - 3000 dispersed over 60 offices - and UNIX servers. The UNIX boxes would provide the message routing between offices. Our network design for this system is based on a hub and spoke topology. The remote offices would use dial-up connections running UUCP to communicate with one of eight hubs. Now for the SNA component... We currently have SNA lines running to the eight hub locations. This newtork is well entrenched. We have suggested replacing it with multi-protocol routers which would forward SNA as well as TCP. However, the idea was flatly rejected for two reasons: its cost and the predominance of the technology blind IBM group. Hence the idea of tunnelling TCP/IP in SNA. Of course, the fallback plan would be to exchange mail between the hubs using UUCP, but, I would prefer to have a connected network in place. Does anyone have any suggestions, or comments on this issue? Your assistance would be greatly appreciated. Thanks bruce pinn Manager, NITG Peat Marwick Thorne
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 15:58:36 GMT From: mqh@theory.tn.cornell.edu (Mike Hojnowski) To: comp.protocols.tcp-ip Subject: Old TCP announces MSS of 65496. Fix available?
I'm running AIX/370 with it's built-in ancient BSD 4.3 networking code. Occasionally, it will announce an MSS of around 65496 to sites it connects to on non-local networks. Some of those sites are also running ancient networking code (Ultrix and VaxStations, notably). Those sites tend to panic when we connect to them. We'd like to be better neighbors than that, though I realize that this bug is due to problems on both ends. Is there a reasonably short source patch I can put in our networking code to keep it from announcing an MSS > 32K? I imagine the remote sites are having a problem 'cause they think the MSS is signed and are indexing into hyperspace or something. Just to add to the confusion, we run "gated" on our site. I don't know if this makes a difference or not. Please respond via Email here (this is not an AIX site, so it won't crash you :-)). I don't read this newsgroup regularly. Mike Hojnowski AIX Grunt Cornell University
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 16:01:05 GMT From: ypinn@gpu.utcs.utoronto.ca To: comp.protocols.ibm,comp.protocols.tcp-ip Subject: TCP tunnelled in IBM/SNA (more)
Apologies, but there appears to be a bug in our Pnews command so that
the From: address for my previous message - and probably this one - is
marked as ypinn@gpu.utcs.utoronto.ca. It should read either
craystn@gpu.utcs.utoronto.ca {which is the machine the note was sent from},
or you can reach me at ypinn@gauss.clsc.utoronto.ca
Thanks
bruce pinn
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 16:38:51 GMT From: hathawa@rdsunx.crd.ge.com (Barry Hathaway) To: comp.protocols.tcp-ip,comp.protocols.ibm Subject: Re: TCP/IP tunnelled in IBM/SNA
IBM's TCP/IP software supports TCP/IP tunnelled through SNA. In order to do this in your situation you would have to attach each IBM system to you TCP/IP network. This could be expensive, but it would offer additional capabilities.
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 16:43:46 GMT From: yjy@stlucia.uucp (Joe Yung) To: comp.sys.att,comp.sys.tcp-ip Subject: Re: Datakit Interface Through TCP/IP
>from: yjy@stlucia.bellcore.com (Joe Young)
Previously, I posted the following questions:
>I have a SPARC station 2 and a Datakit with a bunch of TTY modules.
>I am trying to have the SPARC connected to the Datakit so I can use
>my SPARC to access various TTY line off the Datakit.
>Does anybody know how ?
>
>I heard that AT&T Datakit has a connection to TCP/IP directly.
>We have a bunch of SPARCs on the Ethernet. It will be a
>a versatile way to open up the Datakit available to all the SPARCs.
>Does anybody know anything about this connectivity.
I have got many helps from the net.
The following is my conclusion.
There are two possible configurations.
The first configuration is the following:
-------------- Fiber Link ---------
|Sparc server| -----------------|Datakit|-------async terminals
-------------- ---------
A CPM/HS module is required on the Datakit end and a fiber interface
plus some software (DKHOST ?) is requried on the Sparc server.
Based on my experience on the 3B2-to-Datakit fiber link,
I believe this configuration will allow me to use all the fiber link features
including the datakit library.
However this configuration does not apply to the Sparcstations
because the fiber interface requires VME bus architecture which is
on the Sparcserver only.
The Sparcstations use SBUS architecture !
Another configuration is the following:
--------------
|Sparcstation|
--------------
|
| TCP/IP TCP/IP
========================== ================
| | | |
------------------------
|Datakit Interface(NIK)|
------------------------
| Fiber
| Link
Async --------- Async
Serial Printer----------|Datakit|--------async terminals
---------
The Datakit Interface(NIK) is a "telnet" service box which convert the TCP/IP
to URP protocol.
The user login from the async terminals as shown has to select
the "telnet" service on the datakit destination prompt.
This will take the connection to the NIK.
From there, a host address will be entered to connect to the sparcstation.
This configuration is only limited to telnet service.
From the Sparcstation end, type in telnet and open the NIK host connection.
The NIK host can connect to the async lines via the fiber link.
I think the sparcstation is not awared of the NIK as a gateway to the Datakit.
Here are some features provided by NIK(Thanks to Bill Hill):
*Local Routing on NIK
*Routing between LAN and remote LAN through Datakit (DK)
*Up to 4 LANs/NIK
*NIK fiber connected to DK
*Local Mngt of NIK or through StarKeeper NMS
*Capability to act as Terminal Server; a terminal or host directly
connected to DK can log onto any Ethernet LAN host connected to DK
via NIK
*Reverse terminal service; PC on LAN to Access DK hosts or Terms
Joe Yung
-----------------------------------------------------------------
Joe Yung
yjy@stlucia.bellcore.com
(908)699-5344
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 17:02:34 GMT From: smith@newsserver.sfu.ca (Richard Smith) To: comp.protocols.tcp-ip Subject: Re: finger weather
"weather" is now a RPC which will produce similar results (i.e. the weather for your locality - if you live in the U.S :->). I downloaded it and tried it - it works. ...r
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 18:12:11 GMT From: amallic@swtec1.intel.com (Asit Mallick ~) To: comp.protocols.tcp-ip Subject: MIT/CMU implementatin of SNMP
I am looking for source of a public domain implementation of SNMP. I was told that a CMU and MIT version exist. Can anyone send me information about these. Thanks in advance. email addr: amallic@swtec1.intel.com
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 18:35:03 GMT From: SSJACK@ECUVM1.BITNET To: comp.protocols.tcp-ip Subject: Two machine ethernet?
Out of curiosity, I have a question regarding 10BASET wiring: Can two PC's with 10BASET cards be wired back to back using a single twisted pair wire (RJ45s) with the transmit and receive pairs swapped via a crossover block -- effectively producing a two machine ethernet? ====================================================================== Jack E. McCoy SSJACK@ECUVM1.BITNET Systems Programmer (919) 757 - 6401 East Carolina University Greenville, NC 27858 ======================================================================
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 19:28:23 GMT From: hollings@poona.cs.wisc.edu (Jeff Hollingsworth) To: comp.protocols.tcp-ip Subject: Re: finger weather (really Coke machines)
|> |> As far as I know nothing similar has been done elsewhere, so CMU can |> legitimately boast of having the only Coke machine on the Internet. |> Here at the University of Wisconsin we were *FORCED* to computerize our Coke machine a year ago (or they would take it away). The University had given an exclusive vending contract to a local vending company. That company didn't like the fact we were under cutting their prices. But they did permit "coffee clubs" to continue. The idea was people would pay into a club and then only people who payed in could take coffee from the pot. We decided to do the same thing with our Coke machine. A small bit of hardware was built to activiate the Coke machine via a computer, and a program was written to track coke accounts and keep their balances. The coke machine was also modified so that it would NOT take money and could only be activated from the computer. So I guess Wisconsin can claim the only Coke machine that can be controlled via the Internet. ------------------------------------------------------------------------------- Jeff Hollingsworth Work: (608) 262-6617 Internet: hollings@cs.wisc.edu Home: (608) 256-4839 X.400: <pn=Jeff.Hollingsworth;ou=cs;o=uw-madison;prmd=xnren;c=US>
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 20:02:46 GMT From: hollings@poona.cs.wisc.edu (Jeff Hollingsworth) To: comp.protocols.tcp-ip Subject: Re: finger weather (really Coke machines)
!> !> As far as I know nothing similar has been done elsewhere, so CMU can !> legitimately boast of having the only Coke machine on the Internet. Here at the University of Wisconsin we were *FORCED* to computerize our Coke machine a year ago (or they would take it away). The universion had given an exclusive vending contract to a local vending company. But they did prmit "coffee clubs" to continue. The idea is that people pay into a club and then only people in the club get to drink from the coffee. We decided to do the same thing with our Coke machine. A small bit of hardware was built to activate the Coke machine via a computer, and a program was written to track coke accounts and keep their balances. The coke machine was also modified so that it would NOT take money and could only be activated from the computer. So I guess Wisconsin can claim the only Coke machine that can be controlled via the Internet. -- ------------------------------------------------------------------------------- Jeff Hollingsworth Work: (608) 262-6617 Internet: hollings@cs.wisc.edu Home: (608) 256-4839 X.400: <pn=Jeff.Hollingsworth;ou=cs;o=uw-madison;prmd=xnren;c=US>
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 23:31:40 GMT From: art@opal.acc.com (Art Berggreen) To: comp.protocols.tcp-ip Subject: Token Ring ARPs
The research community has been pushing for all MAC addresses carried as data in communication protocols to always be in cannonical format. This is at odds with older implementations for the Token Ring which were based on RFC1042 (use of SNAP). I'm curious as to if and when this might have an effect on products in the marketplace. I believe there is a large installed base that uses the RFC1042 style ARPs where the MAC addresses are in wire order. Are there any products out there that use cannonical order? Are there any coming? Does anyone have any other information? Art
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 91 23:50:16 GMT From: yates@UNIX1.CS.UMASS.EDU (David Yates) To: comp.protocols.tcp-ip Subject: TCP/IP mailing list
I am interested in adding my name to the TCP/IP mailing list. Is this the right e-mail stop? Thanks in advance, David
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 91 00:21:06 GMT From: Rudy.Nedved@RUDY.FAC.CS.CMU.EDU To: comp.protocols.tcp-ip Subject: Re: finger weather
John, You know your stuff. CMU still has a coke machine on the network. Alas because of software upgrades being constant that little trick has been divorced from the finger software. Under finger we had coke machine status and "tingle" status... At the current time we have network service for the coke machine and for our M&M machine. We have this under the "junk food" service. -Rudy
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 91 01:11:39 GMT From: cmilono@netcom.COM (Carlo Milono) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: 10BaseT installation
First, as was stated in an earlier post or RE:, it is *not* true that AT&T uses more than the 4 wires for 10BASE-T - four is IT for the standard and their product is standard. Secondly, it is a misnomer to use the RJ45 name for an 8-pin jack - the correct terminology is the ISO 8877 jack. The RJ stands for Registered Jack and refers to those blocks that terminate a TelCo circuit as a demarcation point to a public service. You may note that if you have a DSU or Modem with a private line, that the connector looks a bit different, possibly with a switch-selectable resistor and it will have a notch on the jack as a key for the data-set plug. Lastly, you can run your 10BASE-T on household 'quad' wire and get an appropriate cord (twisted preferably) to splay the four wires into the 10BASE-T standard spacing within the ISO jack. I have several locations where the only wire available was a six-conductor wire split between two four-wire jacks - the first being a true RJ11. Works fine. I agree with a previous poster in that: 1) the physical arrangement allows for near foolproof use of a phone on the SAME jack (with a splitter) 2) the ISO jack has proven to be sufficient to support 3270, LAN, ISDN, Async, Sync, twin-axial (5251 - yuck!), as well as other less-used transmission schemes (Oh, LADC-II as well!) 8 pins will do most everything in a neat and clean manner, a la AT&T's PDS (as opposed to IBM's multi-gauge, shielded poop). -- +--------------------------------------------------------------------------+ | Carlo Milono: cmilono@netcom.apple.com or apple!netcom!cmilono | |"When a true genius appears in the world, you may know him by this sign, | |that the dunces are all in confederacy against him." - Jonathan Swift | +--------------------------------------------------------------------------+
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 91 02:15:56 GMT From: pchin@midautumn.wpd.sgi.com (Phil Chin) To: comp.protocols.tcp-ip Subject: How to put tcp/ip over LocalTalk?
Any information or pointers to that information will be very much appreciated. Thanks. Philip
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 91 03:44:40 GMT From: bruce@camb.com (Barton F. Bruce) To: comp.protocols.tcp-ip,comp.sys.dec Subject: Re: LANTRONIX terminal server comments?
In article <1991Mar26.181532.27542@banana.fedex.com>, bill@banana.fedex.com (bill daniels) writes: > I am interested in comments about Lantronix tcp/ip-LAT terminal servers. We > a looking for some small (physically & # ports) terminal servers and the > good price of lantronix is attractive. I would especially like to hear about Never tried them, but the features you seek are available in DEC's new DS90 that might have been announced by now. I have NOT seen one, but apparently many customers have seen at least non-disclosure units. They target BEATING everyone's price! DEC listening to customers?
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 91 06:49:46 GMT From: faunt@CISCO.COM (Doug Faunt N6TQS 415-688-8269) To: comp.protocols.tcp-ip Subject: Two machine ethernet?
Yes. It's speced that way. It works. Date: Fri, 05 Apr 91 13:35:03 EST From: SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu Out of curiosity, I have a question regarding 10BASET wiring: Can two PC's with 10BASET cards be wired back to back using a single twisted pair wire (RJ45s) with the transmit and receive pairs swapped via a crossover block -- effectively producing a two machine ethernet? ====================================================================== Jack E. McCoy SSJACK@ECUVM1.BITNET Systems Programmer (919) 757 - 6401 East Carolina University Greenville, NC 27858 ======================================================================
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 91 09:19:26 GMT From: colin@la.excelan.com (Colin Goldstein) To: comp.os.os2.programmer,comp.protocols.tcp-ip Subject: Re: Problems with IBMs TCP/IP V1.1 for OS/2
The News Manager) Nntp-Posting-Host: la Reply-To: colin@la.novell.com (Colin Goldstein) Organization: Novell, Inc., San Jose, Ca References: <ZSNPX4T@nadia.stgt.sub.org> Date: Thu, 4 Apr 1991 16:17:06 GMT In article <ZSNPX4T@nadia.stgt.sub.org> chlebosc@nadia.stgt.sub.org (Claudius Chlebosch) writes: >The server calls the recv() function, which returns with 4360 bytes >received. The client has to call the recv() function once again to >get the remaining 15640 >bytes of the segment. In my opinion this >behaviour is not correct. > I don't have the IBM TCP/IP package, but the TCP/IP toolkit from Novell works the same way. Although stream sockets give reliable delivery, there is no way to be sure that all the data will arrive at the same time. It is therefore the applications responsibility to recv() until all the data is read. Keep a count of bytes read or use select() to determine if more data is available. Colin -- /-------------------------------------------------------------------\ | The views expressed here are my own. | Norm, what are you | | They do not necessarily represent | up too??? | | the views expressed by my employer. | | | ---------------| My ideal weight if I | | colin@novell.com | Novell Inc., | were 11 feet tall. | | uunet!novell!colin | San Jose | - Cheers | \-------------------------------------------------------------------/
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 91 12:37:30 GMT From: scoggin@delmarva.delmarva.COM (John Scoggin) To: comp.protocols.tcp-ip Subject: Multi-protocol Routers with Compression
We are currently operating a multi-protocol (IP, XNS, IPX, SNA...) internet
using Wellfleet bridge/routers with 672 kbps links. While this configuration
works quite nicely, it is a bit expensive to implement in smaller offices.
Is anyone aware of a multi-protocol bridge/router which incorporates data
compression techniques for operation on low-speed (56-384 kbps) lines?
It is difficult to justify T-1 circuits to an office with 10-15 office
workers, but a DDS or fractional T-1 circuit might be feasible. A straight-
forward bridge/router without compression would give unacceptable performance
(IMHO) when retrieving mapping data from our NFS servers.
Many thanks for any ideas!
----------------------------------------------------------------------
John K. Scoggin, Jr.
Supervisor, Network Operations Phone: (302) 451-5200
Delmarva Power & Light Company Fax: (302) 451-5321
500 N. Wakefield Drive Email: scoggin@delmarva.com
Newark, DE 19714-6066
-------------------------------
"Never underestimate the bandwidth of a station wagon load of magnetic
tapes screaming down the interstate!"
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 91 16:12:24 GMT From: smithfd@weiss.cs.unc.edu (Don Smith) To: comp.protocols.tcp-ip,comp.protocols.iso Subject: TriComm'91 Final Call for Registration
FINAL CALL FOR REGISTRATION
[Note: If you plan to attend TriComm'91, please send the registration
information (below) immediately by express mail, FAX or email. Payment
can be made when you pick up your registration material at the conference.
Registrations made after Monday, April 15, 1991, cannot be guaranteed lunch
and dinner tickets.]
TriComm'91
IEEE CONFERENCE ON COMMUNICATIONS SOFTWARE:
COMMUNICATIONS FOR DISTRIBUTED APPLICATIONS AND SYSTEMS
Chapel Hill, NC April 18-19, 1991 (Registration & Reception April 17, 6 pm)
An International Conference Sponsored by the IEEE Communication Society,
the University of North Carolina at Chapel Hill, and MCNC
The decade of the 1980s was a period of rapid advances in communications
technology (both hardware and software) and of pioneering deployment of
distributed systems and applications. At the beginning of the 1990's,
new communications technologies and new distributed applications are
emerging that will have far-reaching impact on communications software.
Very high-speed networks (e.g., from FDDI to Gigabit technologies), multi-
and continuous-media communications, interconnection of workstations and
supercomputers, visualization and image applications, and computer-supported
cooperative work (CSCW) are just a few examples. Participation in the
conference by both developers of advanced distributed applications or
systems and researchers interested in communications software will
provide a mutually beneficial dialogue.
FEATURED SPEAKERS
Ken Birman, Cornell University, "Group Communication in Operating System
Microkernals"
Roger Bushnell, Bell Northern Research, "Subscriber Service Evolution"
J. L. Felton, IBM, "Directions in Information Systems in the 1990s"
John Morris, Open Software Foundation, "Distributed Systems: Meeting the
Needs of the 90s"
Dave Sincoskie, Bellcore, "Gigabit Testbed Activities at Bellcore"
SESSIONS
COMMUNICATIONS FOR MULTIMEDIA
"Multimedia TeleConferencing over International Packet Switched Networks,"
J. Crowcroft, University College-London
"On the Synchronization and Display of Multiple Full-Motion Video Streams,"
Howard Katseff, AT & T Bell Laboratories
"Delay Jitter Control for Real-Time Communication in a Packet Switching
Network,"
Dinesh C. Verma, University of CA-Berkeley & International Computer Science
Institute
"New Virtual Time CSMA/CD Protocols for Real-Time Communication,"
Jaideep Srivastava, University of Minnesota
APPLICATIONS AND ARCHITECTURES
"The Design and Implementation of the MONTAGE Multimedia Mail System,"
Keith Edwards, Georgia Institute of Technology
"A Proposed Extension of the ODA Document Model for the Processing of
Multimedia Documents,"
Hannes P. Lubich, ETH-Zurich
"The Andrew File System on OS/2 and SNA,"
Neil Sullivan, IBM-RTP
"Vector Processor Services for Local Area Networks,"
Scott Midkiff, Virginia Polytechnic Institute and State University
COMPUTER CONFERENCING
"Evaluating Alternative Display Sharing System Architectures,"
Nina Rosson, Southwest Research Institute
"XTV: A Framework for Sharing X Window Clients in Remote Synchronous
Collaboration,"
Hussein Abdel-Wahab, Old Dominion University
"Control Issues in Multimedia Conferencing,"
S. R. Ahuja, AT & T Bell Laboratories
"System Design for Workstation-Based Conferencing with Digital Audio
and Video."
Kevin Jeffay, University of North Carolina-Chapel Hill
NETWORK PROTOCOLS AND IMPLEMENTATIONS
"A Communication Protocol for a Multi-level Secure Network,"
Andrew Mazeikis, Queen's University-Ontario
"Heirarchial Network Routing,"
Alan Fekete, University of Sydney
"A Parallel Implementation of the ISO 8802-2.2 Protocol,"
Matthias Kaiserswerth, IBM Research-Zurich
"A Layered Communication System Generator,"
Gen-Huey Chen, National Taiwan University
PERFORMANCE AND MEASUREMENT
"The Effects of Long Delay and Transmission Errors on the Performance of TP-4
Implementation,"
Randy C. Mitchell, The MITRE Corp.
"HiPPI Link Data Analysis System,"
Dan Winkelstein, MCNC
"Tingle: Suite for Monitoring Networks,"
J. Dean Brock, University of North Carolina-Asheville
"Capability Analysis of Distributed Switching Systems in Interprocessor
Communications,"
Serap Savari, MIT
CONFERENCE COMMITTEE
Alan Blatecky, General Chairman Jurg Nievergelt, International Chairman
MCNC, USA ETH, Switzerland
Peter Calingaert Andre Fournier
UNC-Chapel Hill, USA BNR, USA
David May Joe Rusnak
BNR, USA IBM, USA
Dan Stevenson
MCNC, USA
PROGRAM COMMITTEE
F. Donelson Smith Chairman Yutaka Matsushita
IBM & UNC-Chapel Hill, USA Keio University, Japan
Steven Bellovin Najah Naffah
AT & T Bell Laboratories, USA Bull, France
Rich Chilausky Erich Neuhold
BNR, USA GMD-IPSI, Germany
Brian Coan Bernhard Plattner
Bellcore, USA ETH, Switzerland
Flaviu Cristian Tom Rodeheffer
IBM Research-Almaden, USA DEC System Research Center, USA
Carla Ellis Beverly Sanders
Duke University ETH, Switzerland
Rong-Chin Fang M. Satyanarayanan
Northern Telecom, USA Carnegie Mellon U., USA
Domenico Ferrari H.T. Smith
U. of CA-Berkeley, USA Nottingham University, UK
James P. Gray Jorgen Stanstrup
IBM-RTP, USA Technical University, Denmark
Fukuya Ishino Liba Svobodova
NTT, Japan IBM Res.-Zurich, Switzerland
Kevin Jeffay Mladen Vouk
UNC-Chapel Hill, USA NC State U., USA
Rivka Laden Hussein Abdel-Wahab
DEC CRL. USA Old Dominion University, USA
Simon Lam William Weihl
U. of Texas-Austin, USA MIT, USA
Geovane Magalhaes Jennifer Welch
CPqD/TELEBRAS, Brazil UNC-Chapel Hill, USA
LOCATION
TriComm '91 will take place in Chapel Hill, North Carolina, at the University
of North Carolina. The University of North Carolina is located at one corner
of North Carolina's Research Triangle (Raleigh, Durham, Chapel Hill) in the
center of which is the Research Triangle Park and the Raleigh-Durham Airport.
MCNC, a national resource in microelectronics, is located in the Research
Triangle Park. MCNC is a non-profit corporation established to support and
develop the education and research technology infrastructure in North
Carolina. It has three divisions: microelectronics, supercomputing, and
communications.
All conference sessions and meals will be held at the Carolina Inn, a
charming Chapel Hill landmark, located on the campus of the University of
North Carolina just across the street from Sitterson Hall, the
state-of-the-art building which houses UNC's Computer Science Department.
On Wednesday night, April 17, pre-registration and the conference reception
will take place in Sitterson Hall.
Chapel Hill is a small community of about 40,000. In April the weather will
generally be very pleasant with daytime temperatures in the upper 60's and
nighttime temperatures in the 50's; however, you should be prepared for a
shower. Many spring-flowering plants and shrubs should be in bloom at this
time.
TRANSPORTATION
The local airport is Raleigh-Durham International. American Airlines is
the official carrier of TriComm '91, offering special fares to North
American conferees: 5% saving off published excursion fare within the
US, or 40% (Canada 35%) off the full coach fare with a 7-day advance purchase
valid from April 15-April 21, 1991. Call 1-800-433-1790 and refer to STAR
FILE S0241GC to obtain the discount.
Taxis, which you can take to the Carolina Inn or any other location in
Chapel Hill for about $25.00, are generally waiting outside the airport
terminals. Or you can arrange to be picked up by LTD Services. LTD operates
by reservation. In order to be picked up, call LTD (1-800-787-4474 or
919-840-1829) at least one day in advance and give the time, flight number
and airline you will arrive on. You may call after you arrive but you may
have a substantial wait. The cost is $15.00 per person. Because all
conference events will take place either at the Carolina Inn or Sitterson
Hall just across the street, there is no need to rent a car.
For those commuting, we have arranged for a shuttle bus to run from the
southwest corner of the University Mall parking lot (near First Union Bank)
beginning at 7:00 am on April 18 and 19. The Mall is located at the
intersection of Estes Drive and US 15-501. Parking is not available on the
UNC campus between 8:00 am and 5:00 pm. The Carolina Inn provides free
parking for registered guests only.
-------------------------------------cut here---------------------------------
ADVANCE REGISTRATION FORM (Clip and mail to address below)
Please make checks or money orders payable (in U.S. currency) to TriComm '91.
We cannot accept credit cards. Mail with
completed registration form to: Mary Ducker
TriComm '91
CB #3175, Sitterson Hall
University of North Carolina
Chapel Hill, NC 27599-3175 USA
919-962-1869 FAX 919-962-1799
ducker@cs.unc.edu
Conference registration includes a copy of the proceedings, coffee breaks,
Wednesday evening reception, lunches Thursday and Friday, and the Thursday
evening conference dinner. The basic student fee includes the technical
sessions, proceedings, and coffee breaks. Students who register in
advance may also purchase lunches. No refunds can be given after April 10.
Please indicate the appropriate fee.
IEEE member $225.00
Non-member $275.00
Full time student (basic) $35.00
Full-time student
(including lunches) $55.00
Please print the following information.
Name (for name badge) __________________________________________________
Affiliation (for name badge) ___________________________________________
Address ________________________________________________________________
________________________________________________________________
Phone ______________________________Email_______________________________
IEEE membership number __________________________________
I will attend the reception on Wed., April 17____yes ____no
NOTE: Individuals whose registrations are received after Monday, April 15,
cannot be guaranteed lunch and dinner tickets. If you have any special
dietary needs, please let us know. We will make every effort to work with
our caterers to honor those needs.
------------------------------------cut here-------------------------------
HOTEL RESERVATIONS (Clip and mail to address below or phone for reservation)
CAROLINA INN
PO Box 1110
Chapel Hill, NC 27514
919-933-2001 1-800-962-8519
Please make reservations directly with the Carolina Inn and refer to
TriComm '91 (Group #1960*1). Please complete all information and circle
desired accommodation.
TriComm '91 rates (not including tax): single $42-65 double $52-80
Guest name___________________________________________________________
Phone_______________
Address______________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
Arrival date _________________________Departure date_________________
Number in party__________ Share with ________________________________
_________________________________________________
Reservations w