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