Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!PHYSICSA.MCGILL.CA!philipp
From: philipp@PHYSICSA.MCGILL.CA (Philip Prindeville Comp Ctr)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: re: FTP Packet driver vs. Microsoft Lan Manager driver spec
Message-ID: <8812141913.AA12054@frodo.physicsa.mcgill.ca>
Date: 14 Dec 88 19:13:50 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 31

>>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.

This doesn't pose a problem -- one can have a driver program that
provides two different (pseudo) devices, an Ethernet II and an
802.3 interface.  An application (or at least the person configuring
it) should be smart enough to figure out which one to use when
speaking a certain protocol on a particular wire...

>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.

I think if there was a more generalized approach, such as mapping
a packet into `system' space passing pointers (via indications?) to
the various client processes, then this would be winning.

Still, there is the overhead of having each process inspect the
packet, when it should only be checked once.  What would VJ say?

-Philip