Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!asylum.sf.ca.us!romkey
From: romkey@asylum.sf.ca.us (John Romkey)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: re: FTP Packet driver vs. Microsoft Lan Manager driver spec
Message-ID: <8812131711.AA11349@asylum.sf.ca.us>
Date: 14 Dec 88 01:11:13 GMT
References: <8812132127.AA01951@frodo.physicsa.mcgill.ca>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: romkey@asylum.sf.ca.us
Organization: The Internet
Lines: 29

>I like the packet driver spec way of demultiplexing
>much more (and there really is no excuse for not doing it that
>way, either).

That's not true. I've never been completely happy with the way
demultiplexing works in the packet driver. It doesn't work well in
cases where you have IEEE packets with SNAP headers and Xerox blue
book packets with type fields on the same ethernet. Generally, it
doesn't work well in any environment where type information does not
always start at the same place in a packet.

I'd be much happier with a more flexible mechanism, but every
mechanism I've tried is still too inflexible in one are or another.
The MAC spec's approach is the single most general one I've seen, and
it's flexible enough to suit me.

The MAC approach opens you up to whole new methods of selecting
packets - for instance, a network monitor could decide whether it
wanted the packet before allocating buffer space to it - it could
inspect every field in the packet that it cared about. Even using a
packet driver with a general bit mask that each client would register
wouldn't allow this flexibility.

It's real problem is not that you'll lose on performance when you have
too many clients - how many clients do you expect to have on a 1MB
address space machine (I am intentionally leaving OS/2 out here)? You
can't fit in enough to make the performance an issue here. The real
problem is that if a client exits without telling the driver, the
system will crash the next time a packet is received.
				- john