tksjmi@cs.Buffalo.EDU (JoAnn Illuzzi) (08/27/89)
I don't understand why this happens- I am running packet driver pcip binaries (like lpr). I am also running packet drover ncsa telnet for the ibm pc. I run them both thru desqview on my XT, I thought I would be able to background pcip, call up ncsa telnet and use it? I thought I could flip between programs and run pcip stuff and ncsa telnet without exiting either program? It doesn't work even if I stop the background programs in Desqview. So, should this work? If not, why not? Where is the problem? thanks JoAnn
nelson@sun.soe.clarkson.edu (Russ Nelson) (08/27/89)
In article <9197@eerie.acsu.Buffalo.EDU> tksjmi@cs.Buffalo.EDU (JoAnn Illuzzi) writes:
I don't understand why this happens- I am running packet driver pcip
binaries (like lpr). I am also running packet drover ncsa telnet for
the ibm pc.
So, should this work?
No.
If not, why not?
Because you have two protocols that are asking the packet driver for the
same packet types. Even if you convince the packet driver to forward the
packets to both TCP/IPs, they are both going to try to acknowledge packets,
generate replies, etc. Bad news.
Where is the problem?
What you need (what we *all* need) is a kernel[1]-based TCP/IP for MS-LOSS.
[1] I call MSDOS.SYS a kernel for identification purposes only. Please
do not infer anything about my knowledge of computer science from this.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])|(70441.205@compuserve.com)|
(Russ.Nelson@f360.n260.z1.fidonet.org)|(BH01@GEnie.com :-)carlson@uxh.cso.uiuc.edu (08/29/89)
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? -------------------- Brad Carlson <carlson@mrcnext.cso.uiuc.edu> or <brad-carlson@uiuc.edu> University of Illinois -- Consultant -- NeXT guru -- Windows Programmer
romkey@asylum.sf.ca.us (John Romkey) (08/30/89)
>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