Date: Fri, 23 Aug 1996 10:12:41 -0500 From: rkw@dataplex.net (Richard Wackerbarth) To: current@freebsd.org Cc: sos@freebsd.org, pst@jnx.com Subject: Thoughts on implementation of communications protocols Message-ID: <v02140b03ae43480e0b3b@[199.183.109.242]>
next in thread | raw e-mail | index | archive | help
PST and SOS, and perhaps others, have been discussing ideas to improve the structure of IP packet handling. I like the direction that they are headed. Let me add a few ideas of by own. 1) If I interpret Paul correctly, he advocates a unified interface for modules which do firewalling, accounting, etc. I agree. The fundamental concept here is that of a "message". It may be broken into several buffers. By using the same interface for each processing element, we can insert or remove elements at will. 2) These processing elements should be in the format that allows them to be lkm's. 3) A "glue" module could be used to pass the packets to user space. The user space module could use the same protocol. This would greatly simplify the transition between kernel module and user module. 4) The same mechanism that works for IP should also apply to IPX, Appletalk, PPP, etc. Here is a model that I propose for consideration. The kernel has a built-in registration mechanism for handlers. Packet switchers handle the routing. There is a special "bit bucket" protocol that takes care of message buffer management. If no router is loaded for a particular protocol, the default sends things to the "bit bucket". Each interface "registers" for the protocols that it can accept. Interface routines are "(de)encapsulators" which translate from one protocol to another. Real interfaces have the side effect of transferring the data to some hardware while they route the buffers back to the "bit bucket". I also add "queueing" encapsulators which can hold messages until they are passed down the chain. These need to communicate with the storage management portion of the scheme to avoid consuming too many buffers. Firewalls and accounting modules simply "hook in" the chain at the appropriate place. They act with just the same interface as any other handler. - - - - I like the suggestion of passing along a "dead/alive" tag with each message. That way accounting routines can still get a chance at things which a filter has blocked. Everyone else would just pass it along until it gets to a protocol switching node which shunts it to the "bit bucket". - - - - - Now, here's a scary thought... Would the same kind of mechanism also work for file systems? It would certainly make it easy to handle encrypted file systems and foreign FS structures.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v02140b03ae43480e0b3b>