NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/protocol/tcpip/ibmpc/7380

Internet Message Format | 1993-01-12 | 3.7 KB

Xref: sparky comp.protocols.tcp-ip.ibmpc:7380 comp.sys.novell:11377
Newsgroups: comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Path: sparky!uunet!europa.asd.contel.com!howland.reston.ans.net!usc!cs.utexas.edu!torn!watserv2.uwaterloo.ca!watserv1!demorgan.uwaterloo.ca!erick
From: [e-mail] (Erick Engelke)
Subject: Re: ODI information requested.
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: University of Waterloo
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 12 Jan 1993 16:43:28 GMT
Lines: 65

> [e-mail] (Alasdair Grant) writes:
> [e-mail] (Joe Doupnik) writes:
>
>>from multiple (same type) stacks. The difficulty is, however, receiving packets
>>when there are contending receipients. A packet will be delivered just once,
>>but to whom? Well, you can't tell from the outside so one stack gets the
>>packet, whether it belongs there or not, and the others starve. Misdelivery

>There are two solutions I can think of:
>
>a) give each IP stack a different IP address, and let ODI demultiplex
>   on this

I did this with packet drivers for a while - it was a kludge but worked
ok.  Like PKTMUX, this is best done as a shim.  I wouldn't recommend it
now that PKTMUX exists, but here is the basic strategy for academic
understanding:

   - on received packets, select destination from destination IP field
     and upcall only to that one application
   - on received broadcasts, send upcall to every application
   - on xmits check destination for a local IP address and perform
     local upcall if necessary
   - on xmit broadcasts, upcall each application except originator
     and then place on the net

Though it seems simple enough, this is not sufficient to work with
every application.  For example, bootp is no longer an option.  And
many of the commercial TCPs chain to the hardware interrupt, so it
become necessary to simulate a hardware IRQ or tie them to the timer
tick if you expect to be able to talk between two TCPs on the same PC.

Finally, this is expensive in IP addresses.  It works fine for one
machine, but you wouldn't want this solution for all your PCs.

>b) get ODI to demultiplex on TCP/UDP port numbers, which would require it
>   to manage (or have knowledge of) transport endpoint bindings.
>
>Clearly (b) is the best solution.  A second-best would be to put a shim
>over ODI to do the demultiplexing function, but you still have to provide
>a way for each stack to tell it about bindings.  Is there an API for this?
>How does PKTMUX work?

Sheer magic!  Actually, PKTMUX essentially contains about 50% of a
complete TCP/UDP stack.  Other tcp stacks demultiplex tcp packets
to a TCB (TCP Control Block - a generic name mentioned in the TCP RFC
which gives us word to describe a structure which varies widely between
different implementations, but which gives us some simple lingo all
developers can understand.)

The TCB is some form of memory stucture which contains connection
information, retransmit information, etc.  PKTMUX basicallY demultiplexes
tcp and udp packets to a TCB, but its TCBs list which application to upcall.

And when applications transmit packets for new TCP or UDP connections,
PKTMUX grabs the packets before they go on the wire and learns which
application sent them.  Graham had to do a good bit of thinking to
design this package and it is a bit of a marvel that it works as
well as it does.

Erick
--
----------------------------------------------------------------------------
Erick Engelke                                 WATTCP Architect
[e-mail]     TCP/IP was easy but i still can't work VI