A nice little
TCP/IP stack for IBM PCs, XTs PCjrs, and newer machines
Current version: (September 6th
2008)
Quick Links:
Introduction
A stand-alone machine might be useful, but a networked one opens a lot
of doors. I have always wanted to write my own TCP/IP for old DOS
machines and in late 2005 I finally started working on it.
mTCP is a TCP/IP stack for old machines written using Turbo C++ 3.0 for
DOS and a sprinkling of x86 assembler. It is designed to work with an
Ethernet card and packet driver. Basic features include:
- ARP support for finding the IP addresses of other machines
on the network
- A simple UDP implementation
- A high performance TCP implementation
Other TCP/IP stacks for DOS already exist and I experimented
with them
before deciding to write my own. I wrote my own because I wanted the
source code to be available in case I needed to add features or fix
bugs, I wanted to make my own space and performance tradeoffs, I did
not
want to deal with bad or incomplete documentation and I wanted the
bragging rights of doing something nutty like this.
Some of the more advanced features are:
- Configuration: A lot of the features are enabled and
disabled at compile time using #defines so you can tailor the
features and behavior of the TCP/IP
code to each application.
- High performance: Great care was taken to minimize memory
copies, speed up checksum calculations and avoiding needless polling
and
locking of data structures. The end result is code that can move around
40KB per second through a TCP/IP socket on a 4.77Mhz PC XT with an 8
bit ethernet card. On faster DOS machines (386-40) the rate is well
over 500KB per second.
- Small space requirements: There are TCP/IP implementations
which use less space, but not with the same performance. I made my
target a 256KB machine, which gives me plenty of room for buffers and
code. Basic applications such as the IRC client can run in under 160KB
of space. Buffer space and features are configurable to suit your needs.
- Extensive tracing: Nobody likes a bug. I built a very
comprehensive trace mechanism into the code so that in the event of a
bug I can set two environment variables, get a detailed trace, and
figure out what happened. This has come in handy a few times when other
people have had problems. The trace feature can be compiled
out to save space if you think your application is truly perfect. (Ha!)
- Robustness: Test code that I have written has handled
several simultaneous connections for days. The IRC client has been run
against a busy IRC channel for over a week at a time.
I have tried to adhere to the TCP/IP specifications as closely as
possible, but not everything is possible in such a small machine. There
are a few features missing. Some I will be adding as options as time
goes on. IP packet fragmentation and reassembl is a good example - you
can do a lot without having this feature implemented, and it can be
quite a resource hog. For now, we are doing without it.
Structure/Packaging
mTCP is a library that is statically linked with the application code.
Put another way, any application that you write will include a copy of
the mTCP code in it. This is very similar to the way WATTCP and the
TCP/IP code in NCSA Telnet is packaged. The other common way to package
TCP/IP is as a memory resident DOS TSR. Here are the pros and cons:
- Pro: The TCP/IP code can be tailored to match the needs of
the application
- Pro: One less piece of software to install and configure.
- Pro: Better performance due to less call overhead.
- Con: Applications will be larger on disk because they
include the TCP/IP code in them.
- Con: To write an application you need to be able to link
your code against the TCP/IP code. This means you probably need a copy
of Borland Turbo C++ to do any applications yourself.
Applications
- A DHCP
client that can automatically get an IP address from
a DHCP server, such as a cable modem, Linux machine, etc. and create a
configuration file for you.
- A DNS resolver that can convert named machines (ie:
www.brutman.com) to IP addresses. (Not included yet .. need to clean it
up.)
- 'Netcat' (nc):
send and receive bytes across the network
- IRCjr: a simple DOS IRC
client
And I'm constantly working on more features and applications.
Requirements
The applications should work on any DOS PC with an Ethernet adapter and
a packet driver. My personal testing includes:
- Generic AMD 386-40 with an NE2000 card and DOS 5
- IBM PC XT at 4.77Mhz with a 3Com 3C503 and DOS 3.3
- IBM PCjr at 4.77Mhz with a NEC V20 and a Xircom PE3-10BT
parallel-port to Ethernet adatper and DOS 5
As long as you have an Ethernet adapter (card or parallel port device)
with a packet driver, it should work.
Token Ring, SLIP, CSLIP and other network types are not supported but
could be if there was a reason. SLIP and CLIP via a packet driver than
can emulate Ethernet (eg: SLIPPR or CSLIPPR) will be supported shortly.
(My code is dependent upon ARP replies being received. I will be adding
some code to get around this limitation.)
Configuring
mTCP
Applications
Configuring applications based on mTCP is fairly easy - there is an
environment variable and a text file. If you choose to use DHCP most of
the configuration is done automatically.
See the page "mTCP
Configuration" for a detailed description.
Downloads and Support
Get the current set of mTCP applications (IRCjr, DHCP client and
Netcat) here!
I am interested in hearing about your experiences with the mTCP based
applications and any
comments you have. Please email me at mbbrutman@yahoo.com. You can also
start a thread on http://www.brutman.com/forums
(Mike's PCjr Page) in the 'Programming' area.
Recent changes
- April 2008: DNS resolver added (UDP only)
- June 2008: new IRCjr application
- July 2008: new DHCP Client
- July 2008: TCP/IP parameters moved from environment
variables to a configuration file
- August 2008: Add hostname support to DHCP client, IRC
nickname enhancements to IRCjr
- Sept 2008: Zero window support for TCP, check for presence of packet driver, performance improvements
Created July 29th, 2008, Last updated September 6th,
2008
(C)opyright Michael B. Brutman, mbbrutman@yahoo.com
