PDA

View Full Version : DOS TCP/IP Networking page updated



mbbrutman
December 26th, 2013, 09:03 PM
Please enjoy a little link spam ...

http://www.brutman.com/Dos_Networking/

I have rewritten my introduction to DOS TCP/IP Networking and I think it will be helpful for anybody looking for a primer on DOS networking. Topics include:

A general introduction to DOS networking.
A quick overview of TCP/IP written in layman's terms.
Rewritten sections on packet drivers, choosing networking hardware, and some notes on specific networking software.
A set of reasonably good links that I have collected over the years.


The introductory material applies to DOS networking in general. I go deeper into packet drivers in the rest of the document because I have more experience with those. In the future I hope to make it more comprehensive and include discussions on MS LANMAN, Novell NetWare, etc.

Enjoy, and yell if you spot a problem!

-Mike

MikeS
December 27th, 2013, 11:15 AM
Nicely done and very informative, but I think any discussion of "DOS networking in general" should really include at least a brief mention of RS-232 networks. One gets the impression that Network=Ethernet and TCP/IP, and serial ports were only used for one-to-one computer to computer/peripheral connection/transfers, whereas full RS-232 networks, both server/client and peer-to-peer, with full file and peripheral sharing, email, etc. were the usual method of networking computers both locally and remotely before the availability and higher speed of Token Ring, Ethernet etc. made them obsolete.

mbbrutman
December 27th, 2013, 11:28 AM
I struggle with the concept of "networking" and RS-232. For most purposes, RS-232 was limited to peer to peer unless you had slightly more unusual multi-drop connections.

Is there a particular product that was more than Xmodem/Ymodem or a terminal emulator that you were thinking of? (Interlnk/Intersrv worked. And I remember seeing DOS shareware that allowed for sharing a drive letter using the DOS network file redirector API. But not much more comes to mind.

paul
December 27th, 2013, 11:28 AM
Thank you for your effort!

"TCP also ports to target specific applications, but unlike UDP..."
________^ also addresses ports, or something like that?

MikeS
December 27th, 2013, 02:14 PM
I struggle with the concept of "networking" and RS-232. For most purposes, RS-232 was limited to peer to peer unless you had slightly more unusual multi-drop connections.Well, yes, since RS-232 was also used for connecting to BBSs, serial printers (which were much more common then) etc. that usage was certainly more common than networking just as TCP/IP is used much more today for connecting to the web (the modern equivalent of the BBSs) than other (local) computers.


Is there a particular product that was more than Xmodem/Ymodem or a terminal emulator that you were thinking of? (Interlnk/Intersrv worked. And I remember seeing DOS shareware that allowed for sharing a drive letter using the DOS network file redirector API. But not much more comes to mind.The only name that comes to mind at the moment is Also-LAN, but there were a number of others, as well as hardware RS-232 switches/terminal servers. Other than speed and the hardware I can't think of any significant difference from a modern LAN; the usual configuration was daisy-chained with two-port serial cards and usually using cheap modular phone cable and adapters (sort of like a 10Base2 configuration), or a star configuration with all systems connected to a central hub/switch/router (like 10baseT) that handled the name assignments and routing. Just like the client side of Interlink, you got additional disk drives (which could usually be named), printers, plotters, modems, etc. representing drives, printers etc. on other computers across the room or across the country.

With the proper software what could you do locally (in the context of the DOS pre-MP3/video etc. days) with Ethernet and TCP/IP that you couldn't do (albeit more slowly) with RS-232?

The largest daisy-chain LAN I set up had (I think) 7 nodes and I also had a terminal server setup handling a 10-node system; a colleague installed and supported a network of close to 100 nodes, many of which were remote and connected through a modem, although it was a relatively low volume application.

I've probably got a dozen or so 16-port RS-232 terminal servers/routers somewhere and should also still have software for at least two different implementations somewhere; might have to set up a serial LAN for fun one day and of course bridge it to the internet...

Admittedly not much info out there on serial networks, which is the reason I mention them whenever an opportunity arises...

MikeS
December 27th, 2013, 04:48 PM
Just remembered another one that I used, LBL, for which there is some documentation out there:
http://bitsavers.trailing-edge.com/pdf/informationModes/Little_Big_LAN_V1.0q_Jan94.pdf

From the manual:


Little Big LAN is very FLEXIBLE. ... What follow are some options.

The Physical layer
- or-
"How are these computers going to talk to one another, anyway?"

One of the most powerful features of Little Big LAN is the freedom you have
to choose the method by which you will connect your computers. In network
jargon a computer on the network is called a node. There are presently
five different methods of interconnecting nodes.

o Serial ports
o Parallel ports
o ARCnet cards
o Ethernet cards
o Modems

Not only can you choose any of these methods to link all of your computers, you
can mix any method on the same network. Several computers could be linked via
Ethernet cards, and any of these nodes could also be linked to other computers
via Arcnet or serial or parallel ports or modems. Why would you want to do
that? Because all of these methods have both advantages and disadvantages.
Little Big LAN allows you to tailor your network to fit your present needs.
Later you can change interconnection methods as your needs change.
Still "struggling with the concept of 'networking' and RS-232"? ;-)

mbbrutman
December 28th, 2013, 03:52 PM
I should probably amend the serial software section to point out that INTERLNK and INTERSVR can do file sharing over serial. DOSRIFS (DOS Remote Installable Filesystem") did something similar, and even included the source code.

The "Little Big LAN" PDF was a good read. They appear to have done file and printer sharing over pretty much any link you could provide; serial, parallel, ARCNET, Ethernet, etc. One problem with RS232 is that it is point-to-point, which kind of limits the scale of the network to the number of serial ports you can install. It sounds like Little Big LAN got around that problem by letting each node relay data for the other nodes.

Mau1wurf1977
December 28th, 2013, 03:56 PM
Fantastic document! A pleasure to read and very informative. Learnt quite a bit :)

Caluser2000
December 28th, 2013, 04:35 PM
Nice work alright. While researching things Zenith/Heath related stuff I stumbled across this thanks to a pointer from Chuckster_in_Jax http://www.pestingers.net/HC1032.htm For serial networking 8 devices by the looks.

MikeS
December 28th, 2013, 04:53 PM
I should probably amend the serial software section to point out that INTERLNK and INTERSVR can do file sharing over serial.Yeah, I occsionally try to point out that Interlink is conceptually a little different from, say, LapLink in that it doesn't specifically transfer files (although of course you could do that with various two-pane compare/copy programs) but adds resources so that you can, for instance, run a program located on the server without first transferring it and its files to the client. Of course unlike a terminal remote session like Carbon Copy/ PCAnywhere etc. the program will actually run on the client with whatever memory/speed/display issues etc. that involves, but on the other hand you don't need any local disk space to store the program, i.e. once you're booted you can run diskless.

BTW, did I mention RS-232 remote access programs? ;-)


The "Little Big LAN" PDF was a good read. They appear to have done file and printer sharing over pretty much any link you could provide; serial, parallel, ARCNET, Ethernet, etc. One problem with RS232 is that it is point-to-point, which kind of limits the scale of the network to the number of serial ports you can install. It sounds like Little Big LAN got around that problem by letting each node relay data for the other nodes.I still don't get the distinction; how is it conceptually different from ARCnet or Token ring or even using 10baseT cabling? Isn't a 10baseT Ethernet network essentially also point-to-point unless you add either a second NIC or a router/switch, exactly as you would add a second serial port (or save a slot by using a dual-port card) or an RS-232 terminal server?

Basically you preface your data with a destination name header and it either gets passed to its destination through any intervening nodes or is directly directed by a terminal server.

What really is the functional difference between a 10baseT NIC and an RS-232 port? They both transmit and receive serialized data. Different speed limit, protocol, connectors, voltage levels, differential vs. single-ended, yes, but allowing for that presumably with the right firmware and software almost anything you can do with one you could also do with the other.

Sorry for taking this a little OT, but I think RS-232 is often sold a little short in terms of what you can do (and what was actually done) with it, not to mention with today's free or inexpensive bridges to/through the 'net, Bluetooth, IR and WiFi adapters, etc.

mbbrutman
December 28th, 2013, 05:22 PM
A better way to make the distinction is that Ethernet (all forms) is frame based: whether you use a cross over cable, ThickNet, ThinkNet, twisted pair or wireless all of the data is encapsulated in frames and each frame has a source and destination hardware address.

Serial port networks are strictly point to point - at the media level there is just the concept of a transition of individual bytes. The hardware level does a minimal amount of "framing" - just enough to let you know the next byte is coming.

Since there is no to or from address in that frame, there is no way to address nodes in the network. Even the most primitive Ethernets listening on the wire (the Ether, which behaves like a shared bus) know how to read the frame and figure out if the frame is for them or not. So Ethernet works whether you have something like ThickNet, or real switches which can do store and forward.

Serial on the other hand you can't do much with. You can't store and forward in the same way that you can with Ethernet frames. It's just point to point and nothing more because you don't have a way to address the other nodes of the network.

Your terminal server example is slightly flawed - when you connect to a terminal server you tell it what you want to connect to. It behaves like a cross bar switch there - you get a virtual connection to a specific endpoint.

MikeS
December 28th, 2013, 05:54 PM
A better way to make the distinction is that Ethernet (all forms) is frame based: whether you use a cross over cable, ThickNet, ThinkNet, twisted pair or wireless all of the data is encapsulated in frames and each frame has a source and destination hardware address.I have to ask again: why specifically couldn't you do this just as well through a serial (or even a parallel) port, moving some of the involved logic from the NIC to the CPU?


Serial port networks are strictly point to point - at the media level there is just the concept of a transition of individual bytes. The hardware level does a minimal amount of "framing" - just enough to let you know the next byte is coming.Again, sure, the logic is distributed differently between hardware and software, but so what?


Since there is no to or from address in that frame, there is no way to address nodes in the network. Even the most primitive Ethernets listening on the wire (the Ether, which behaves like a shared bus) know how to read the frame and figure out if the frame is for them or not.How could a serial network possibly work if the data did not contain a destination address?


Serial on the other hand you can't do much with. You can't store and forward in the same way that you can with Ethernet frames. It's just point to point and nothing more because you don't have a way to address the other nodes of the network.Sorry, I don't get it; each node could potentially store and forward and of course so can the terminal server.


Your terminal server example is slightly flawed - when you connect to a terminal server you tell it what you want to connect to. It behaves like a cross bar switch there - you get a virtual connection to a specific endpoint.How is this in any way different from an Ethernet switch?

So you're saying that LBL (for example) uses totally different software and protocols with totally different capabilities when you select Ethernet instead of RS-232 for the connection?

MikeS
December 28th, 2013, 06:16 PM
Maybe this will help me grasp the esssential difference and save further discussion:

Of course there are many hardware, protocol, etc. differences but we're talking (I think) about functional differences, so can you give, oh, three examples of something (again, in the DOS pre-WWW/MP3/video/etc. context) that you can do on an Ethernet LAN that you can specifically not do on an RS-232 LAN?

mbbrutman
December 28th, 2013, 07:06 PM
It is really a simple distinction - network cards frame payloads and serial ports do not.

Your point is taken - a serial network can do everything that the higher level networks do. The key thing is that there is communication between nodes.

But I still think the framing distinction is important. Hardware that embeds hardware level addressing information is fundamentally different than a serial port that basically just frames the payload (a single byte) with a start and stop bit.

Here is a concrete example: An Ethernet frame can be broadcast on the Ether (ThinNet or ThickNet) or sent to a switch for store and forward. In the case of broadcast each node can look at the frame and determine if it is directed at them or not. In the case of the switch the switch can route based on the information in the frame.

You can do that with a serial port; the frame doesn't contain enough information. The host CPU must read the payload and be involved in storing and forwarding if necessary. And that payload would have to include some basic information that the other technologies include in their hardware generated frame.

That's a big performance difference. Which is why I distinguish between serial ports and real network technologies. One can emulate a network with a serial port. But you are doing in software (at a protocol level) what the network does in hardware. And involving the host more to do it.

The terminal server is a poor example. When you connect to a terminal server you establish a virtual connection and from that point forward all bytes on that connection flow through one path. You can't change the path for each individual path; the path is set, just like a virtual circuit through the phone system. An Ethernet switch routes each packet independently; there are no virtual circuits that packets are predetermined to follow.

mbbrutman
December 28th, 2013, 07:12 PM
Thank you for your effort!

"TCP also ports to target specific applications, but unlike UDP..."
________^ also addresses ports, or something like that?


Paul - thanks for the editing work - it will be fixed shortly!


-Mike

mbbrutman
December 28th, 2013, 07:23 PM
Nice work alright. While researching things Zenith/Heath related stuff I stumbled across this thanks to a pointer from Chuckster_in_Jax http://www.pestingers.net/HC1032.htm For serial networking 8 devices by the looks.

I had never heard of the Octoport before; it is an interesting device. But it really is an intelligent switchbox - trying to force it to do networking would be unnatural.

If your networking software knew to setup the Octoport to change the connections each time two nodes wanted to communicate then you could use it for networking. To make it fair and deterministic you would want to implement time slicing or token passing so that no one port gets monopolized by another.

MikeS
December 29th, 2013, 06:05 AM
Your point is taken - a serial network can do everything that the higher level networks do. The key thing is that there is communication between nodes.That was my only point (and sorry to keep harping on it ;-) ), that your otherwise excellent write-up suggests that serial (and parallel) ports are only useful for limited one-to-one communication between a computer and another computer/terminal/peripheral, whereas they can in fact be used to create or participate in networks that are functionally virtually indistinguishable from a network using token ring, Arcnet or Ethernet interfaces, and in some cases have advantages over TCP/IP for example. We're talking about DOS networking, so we should probably compare something like LBL on serial ports to the MS DOS Network client or even NETBIOS.


...That's a big performance difference. Which is why I distinguish between serial ports and real network technologies. One can emulate a network with a serial port. But you are doing in software (at a protocol level) what the network does in hardware. And involving the host more to do it.A pretty arbitrary distinction and narrow definition of "a real network" IMO; surely you're not suggesting that LBL nodes communicating via ARCnet or Ethernet are 'real' networking whereas those using com ports are not?

I'd certainly call a bunch of nodes connected through Little Big LAN a real network, with some additional features not even found in the usual networks such as running sector-level diagnostics remotely, for example.


The terminal server is a poor example. When you connect to a terminal server you establish a virtual connection and from that point forward all bytes on that connection flow through one path. You can't change the path for each individual path; the path is set, just like a virtual circuit through the phone system. An Ethernet switch routes each packet independently; there are no virtual circuits that packets are predetermined to follow.... which actually makes the TS more efficient ;-) It remembers where the packets from a specific node are supposed to go, so it's not necessary to include it in each packet; remember that we're talking about networking DOS, so it's pretty unlikely that a given node will be dealing with more than one data stream simultaneously.

Guess as usual we'll have to agree to disagree; you call anything using serial or parallel ports an 'emulated' network, whereas I say if it looks and functions exactly like a 'real' network and it is in fact called a LAN then it is in fact a network.

Multiport cards are really intended more for connecting a single computer to multiple terminals/computers/peripherals although I suppose with the proper software they could be configured as a network switch.

mbbrutman
December 29th, 2013, 08:48 AM
But the primary use for serial and parallel ports *was* for point-to-point communications. And not for network communications, but for controlling relatively dumb devices. Contrast that with devices designed for networking: they all do framing in hardware and are inherently packet based, not connection based. This is a big distinction.

You can emulate a network with serial ports. But the lack of hardware support requires that pretty much every node on the network has to participate in store and forward routing. Unless you add a link to each node that you want that node to be able to reach. Real networking hardware does not impose the requirement that every node must store and forward for other nodes.

The other big difference is speed. The fastest commonly available serial ports run at 115200 bps. And you lose 20% of that for some combination of start, stop or parity bits. Contrast that Ethernet, which runs at 10,000,000bps. Your minimum frame size is 64 bytes, of which 42 is payload. That is terribly inefficient but when you look at the maximum frame size of 1500 bytes that 22 bytes of framing overhead makes it really efficient. That difference makes it obvious; networking cards are meant to move large amounts of data more efficiently as opposed to single bytes. (Pro-tip: Telnet over Ethernet is a terribly inefficient use of a network.)

I think a 100 to 1 speed different is fairly significant. And the requirement that the hosts must do store and forward routing when the network size is greater than two or the number of links per node can not grow with the number of network nodes is also significant, and has a very negative impact on performance. So, functionally yet, you can use serial ports for a network. If you ignore the vast speed difference.

I have made a small edit to note that low end networking was possible using serial ports. And now that we have hashed out the finer points on the differences, this might be a good FAQ .. the differences between serial/parallel ports and dedicated networking hardware. (And their relative cost would be an important factor in that discussion.)

Chuck(G)
December 29th, 2013, 11:49 AM
It depends on the application. I could see telnet over serial or parallel and even ftp; I could even see SCSI. There are all sorts of industrial low-speed buses interfaced to IEEE 802.3 through bridge adapters, such as CAN, ControlNet, HART, DeviceNet and Modbus. Many of these run at 1200 bps. Browsing the web? Probably not--most DOS boxes don't have the horsepower to do modern web browsing.

MikeS
December 29th, 2013, 12:59 PM
But the primary use for serial and parallel ports *was* for point-to-point communications. And not for network communications, but for controlling relatively dumb devices.Perhaps not "network", but I'd say that serial ports were indeed primarily used for "communications"!

Most traditional applications of serial ports were to connect to a remote computer via a modem and/or for multiple terminals connecting to a central server which in fact offered many of the capabilities of a network such as sharing peripherals, inter-'node' communication, email, etc.


Contrast that with devices designed for networking: they all do framing in hardware and are inherently packet based, not connection based. This is a big distinction.
...
You can emulate a network with serial ports. If serial ports' point-to-point characteristics are your crucial distinction you might as well use the same qualification for 10baseT which is also point-to-point at the hardware interface... ;-)

I guess it comes down to semantics; most people including me would define a computer network as Wikipedia does:

A computer network or data network is a telecommunications network that allows computers to exchange data. In computer networks, networked computing devices pass data to each other along data connections. The connections (network links) between nodes are established using either cable media or wireless media. The best-known computer network is the Internet.
...
Computer networks differ in the physical media used to transmit their signals, the communications protocols to organize network traffic, the network's size, topology and organizational intent.

But apparently by your defininition only certain media, protocols, size, speed, topology and organizational intent qualify as a 'network' and anything else is an 'emulation' even when they are in fact called 'LANs' or 'Networks".

As I said, let's agree to disagree and get back to your latest TCP/IP document.

mbbrutman
December 29th, 2013, 01:52 PM
I believe that in the original version of the document I included networking over serial ports using TCP/IP. The only quibble seems to be that I did not include other examples of network software, and that I characterize serial ports as mostly for point to point communications.

If I did not agree that serial ports could be used for networking I would not have included the tcp/ip example. But I choose to make a distinction between low speed point to point connections and hardware designed for packet switched networking. We will continue to disagree on whether that is important or not.

MikeS
December 29th, 2013, 04:16 PM
I believe that in the original version of the document I included networking over serial ports using TCP/IP. The only quibble seems to be that I did not include other examples of network software, and that I characterize serial ports as mostly for point to point communications.Yes, the quibble was with your "struggle with the concept of "networking" and RS-232" and that under the heading of "DOS Networking Techniques" you really only discussed TCP/IP over Ethernet and didn't actually discuss serial or parallel networking; only one-to-one transfers and sharing (with the implication that Interlink is more or less equivalent to LapLink) and connecting to a TCP/IP network through a serial or parallel port. Point-to-point does not necessarily mean one-to-one if one of those points connects to other 'points'.


If I did not agree that serial ports could be used for networking I would not have included the tcp/ip example.It's still a TCP/IP network that you happen to be accessing through a bridge of some kind.

But I choose to make a distinction between low speed point to point connections and hardware designed for packet switched networking. We will continue to disagree on whether that is important or not.Sure it's an important distinction from the technical perspective and the speed/cost/compatibility etc. differences can certainly be an issue for the user, but so is the distinction between a 5150 PC and a current multi-core speed demon; huge speed difference, incompatible in many ways, but still both computers...

I wonder just how great the speed difference would actually be between a Xircom-equipped 5150 running FTP vs. a connection using the parallel port natively, or even a real NIC; any stats?

But quibbles over incomplete or misleading (IMO) bits here and there, a bitchin' document. Thanks.

mbbrutman
December 29th, 2013, 04:48 PM
The title of the document is "DOS TCP/IP Networking with Packet Drivers", not a treatise on every possible combination of hardware and networking software. I presented serial ports, parallel ports, ARCNet and Token Ring without getting into incredible detail to show that there were alternatives.

You can build a network using serial ports and I have added that to the document. But I have also explained why I struggle with that - the serial port was not designed as a networking technology. It was designed for connecting telco equipment to computers. Most personal computers used it for connecting modems, mice and printers.

People have used it to build larger networks, relying on the nodes to be able to store and forward or adding additional point to point links. (I had acknowledged that in the original version of the document and used TCP/IP as an example of that.) But that does not change the fact that it was not designed for networking as we understand it today (packet switching). Which explains why there is usually several orders of magnitude in performance between hardware that was designed for networking and hardware that was not.

I'm sorry you don't like my opinion on serial and parallel ports and their uses in networking. You may call my work incomplete, but I don't think it is misleading in any way. The false praise is not necessary.

MikeS
December 30th, 2013, 06:22 AM
The title of the document is "DOS TCP/IP Networking with Packet Drivers", not a treatise on every possible combination of hardware and networking software. I only thought that a section called "A Survey of DOS Networking Techniques" should include mention of RS-232 Networks; your adding the paragraph
"Examples include: Low-end networking solutions that allowed for file and printer sharing. These allowed for simple networks but were limited by the speed of the serial port and the point-to-point nature of the serial port." took care of that omission as far as I'm concerned.

I'm sorry you don't like my opinion on serial and parallel ports and their uses in networking. I don't have any problem with your opinions and agree with most of them; the only quibble was whether a network linked via serial ports is indeed a 'real' network or whether in order to be considered a network it must use NICs.

You may call my work incomplete, but I don't think it is misleading in any way. The false praise is not necessary.Too bad that you often have this problem when folks (especially me?) try to contribute something, and you perceive it as personal criticism and have to get unpleasant about it with remarks like calling "Nicely done and informative" and "Bitchin' document; thanks!" false praise.

Oh well...

mbbrutman
December 30th, 2013, 07:16 AM
Too bad that you often have this problem when folks (especially me?) try to contribute something, and you perceive it as personal criticism and have to get unpleasant about it with remarks like calling "Nicely done and informative" and "Bitchin' document; thanks!" false praise.

Oh well...

No, I think that for the last 2 pages of replies you've been subtly trolling or needling, trying to make it sound like reasonable criticism. And even after explaining my opinion and addressing most of your criticism you usually roll back around to my 'I struggle with the concept of "networking" and RS-232' quote and start another round. Shall we count the number of times I've conceded your point and you've managed to restart the cycle again?

This is my favorite contortion so far (from your last reply):


"But quibbles over incomplete or misleading (IMO) bits here and there, a bitchin' document. Thanks."

You go through great pains to call it incomplete and misleading, and a "bitchin" document. All in the same sentence.

Enough already. I amended the document immediately after you pointed out that people were doing larger scale networks over serial, which was not anything I ever contested. I gave you a very good technical argument as to why people generally don't use serial cables for large networks, to back up why I generally don't consider RS232 to be an appropriate medium for networking. I'm not sure what the problem is, but after two or three rounds a normal person would have stopped, satisfied that they made their point known. You've "contributed" the same thing a few times now and I'm waiting for the record player to stop skipping.

You think I have a problem with criticism. I think you are trolling. Given your personal history on the forum with other people I'm not too concerned.

MikeS
December 30th, 2013, 12:41 PM
Whatever; I can't help how you interpret my posts so we'll let the readers form their own opinions (probably that there's not much to choose between a pair of stubborn and pedantic nitpickers ;-) ), but I did ask you twice to agree to disagree and let it drop...

Since you love to twist words and misquote, I did not "go through great pains" to call "it" (your document) incomplete and misleading, I referred to incomplete and misleading bits and emphasized that that was only my opinion; it should however have read "Incomplete and misleading bits aside, it's a bitchin' document."

Despite your attitude I still thank you for it; as I said in my first reply, "Nicely done and very informative!" (Just more false praise and trolling in your eyes I suppose...)

mbbrutman
December 30th, 2013, 01:29 PM
Another excellent trolling technique - accusing the other person of twisting words and misquoting. Please show something that I twisted or misquoted?

Caluser2000
December 30th, 2013, 01:43 PM
Can you move this to rants or maybe software? Although it is amusing seeing alpha geeks quibble it does look quite childish.

mbbrutman
December 30th, 2013, 01:51 PM
Better yet, I'm just closing this for now and Erik can sort it out.

It's a shame it got ruined though.