Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!ucbvax!H.CS.CMU.EDU!Rudy.Nedved
From: Rudy.Nedved@H.CS.CMU.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Protcol Development on SUN 2 and 3 computers.
Message-ID: <1986.12.19.15.19.44.Rudy.Nedved@h.cs.cmu.edu>
Date: Fri, 19-Dec-86 10:27:45 EST
Article-I.D.: h.1986.12.19.15.19.44.Rudy.Nedved
Posted: Fri Dec 19 10:27:45 1986
Date-Received: Fri, 19-Dec-86 23:57:08 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 23
Approved: tcp-ip@sri-nic.arpa

The ENET filter mechanism is nice but CMU is using the 
BSD sockets mechanism. We still have a few applications
using the old mechanism but under a compatibility flag
and plan to flush the stuff.

>From the perspective of a network application hacker, the
only major thing that is missing from the BSD mechanism
is the ability to filter certain types of raw packets. It
should not be neccessary for one to modify the operating
system in order to see all packets of a certain type, or
length or from a certain host or going to a certain host.

The minor problems we have been ignoring. I don't like the
fact that the operating system code design seems to believe
it knows when data should be flushed for an SMTP connection
since it knows how to do it for a telnet and ftp data
connection. Heck, I like to get my performance anywhere I
can and dang...computers should be smart for the novice but
should not take control away from the expert...I hate waiting
for kernel bug fixes when a little more application level
control could create a work-around for the application.

-Rudy