romkey@ASYLUM.SF.CA.US (John Romkey) (09/18/90)
Yes, the packet driver doesn't know anything at all about protocol addresses. All it knows about is protocol types, and then, all it knows about that is what the protocols that call into it tell it. You can't effectively run two separate IP stacks on one system with the packet driver. If you want two IP stacks, you need two packet drivers and two ----net boards. The right way to deal with multiple windows or Desqview applications calling into TCP is to have a TSR TCP kernel with an interface that supports windows or Desqview, and have the applications call into that. I believe all the popular commercial TCP/IP implementations for DOS (and none of the free ones) provide a TSR interface these days, and some even have mechanisms for letting Windows/Desqview applications call into them. The packet driver is only intended to provide an interface between the protocol stack and the network device driver. Issues involving application programming interfaces are better dealt with elsewhere (like at the application programming interface!). - john romkey USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@ftp.com
RAF@CU.NIH.GOV (Roger Fajman) (09/19/90)
> The packet driver is only intended to provide an interface between the > protocol stack and the network device driver. Issues involving > application programming interfaces are better dealt with elsewhere > (like at the application programming interface!). You are certainly correct from the viewpoint of good design of an overall system for supporting multiple TCP/IP applications under a multitasking system. However, as a practical matter, the different implementations of TCP/IP on the PC have their various strong and weak points. There may be reasons to want to run two of them, in much the same way that people want to run two different protocol stacks. Can native NDIS do this? I seem to recall hearing that under NDIS each received packet is passed to all the protocol stacks to process or not process, as desired. If that's true, each TCP/IP stack could look at only the packets with its IP address. A kludge, but a possibly useful kludge.
jbvb@FTP.COM ("James B. Van Bokkelen") (09/19/90)
Can native NDIS do this? I seem to recall hearing that under NDIS each
received packet is passed to all the protocol stacks to process or not
process, as desired. If that's true, each TCP/IP stack could look at
only the packets with its IP address. A kludge...
Yes. It only works as long as there are no packets which want to go
to both protocol stacks (e.g. ARP replies, RIP broadcasts, etc.).
NDIS doesn't guarantee that a packet can be received by more than one
protocol. You also would either parse all the layer's headers twice,
or wind up spending a *lot* more time in the receive_lookahead or
receive_chain upcall than the MAC driver's designer assumed you would
while you check the IP and TCP checksums.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901