Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!bionet!agate!ucbvax!asylum.sf.ca.us!romkey
From: romkey@asylum.sf.ca.us (John Romkey)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: re: packet driver benefits?
Message-ID: <8908291812.AA17413@asylum.sf.ca.us>
Date: 30 Aug 89 01:12:30 GMT
References: <16400002@uxh.cso.uiuc.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: romkey@asylum.sf.ca.us
Organization: The Internet
Lines: 42

>It seems to me that the packet driver should (i.e. it would be nice) 
>be able to do de-multiplexing, based on ports or sockets.
>Does anyone have a socket-based driver for MS-DOS?

I've heard this before and want to make my thoughts on it clear: No.
That's not what the packet driver's supposed to do at all.

The packet driver is intended to be a programmatic interface to allow
multiple different protocol stacks to share a network interface.
Usually a protocol stack will have a hardware driver for a specific
card in it.  Running two stacks at once (say, TCP and NetWare or
DECnet) will have conflicts because of two different drivers trying to
use the same piece of hardware at once and not knowing it. The packet
driver eliminates this problem by letting one driver be shared.

It is also intended to allow protocol stack authors to decouple their
stack from the specific network device they're using, so they only
have to have an ethernet version rather than 20 different versions for
different network interfaces, or one humonguous version with support
built in for 20 different network interfaces. Hardware vendors could
write packet drivers for their cards and bundle this software with
them, but few have seen fit to do so thus far.

The packet driver is intended to be used only for multiplexing
access to a network interface. Its semantics are modelled around those
of network interfaces, not TCP connections. It's the wrong place from
which to try to access a TCP connection. It's not meant to look like
sockets, and it doesn't.

FTP Software has defined a binary interface that is used with PC/TCP
2.x to allow applications to access TCP, UDP and other protocols. It's
similar to sockets but more flexible, especially in the area of
asynchronous notification. The interface is documented in the 2.x
Development Kit. If you want a binary interface for talking to
sockets, this is probably a good place to start. But please leave the
packet driver out of it.

If you mean allowing multiple TCP stacks to run in the same machine at
the same time, I think that's probably a bad idea and is becoming less
and less useful as time goes on. Running two separate TCP stacks leads
to all sort of problems in the ICMP and routing area.
			- john