[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tcp/ip rewrite for summer of code

From: Joshua Stratton
Subject: Re: tcp/ip rewrite for summer of code
Date: Thu, 27 Mar 2008 17:50:37 -0600

I'd still like some feedback from the Hurd developers about what they would like to see in the TCP/IP rewrite.  From what I envision, it would be modular design of two or more translators (perhaps one for each protocol).  Although it's quite a different approach, I really like the idea of client-based responsibility for the memory buffers and other data structures.  I would personally like to know who works most with the networking stack now and what they would like to see in a TCP/IP rewrite.  If you haven't read the paper Pierre posted, it's a very interesting model and I would like to know what those developers involved in the network stack like and don't like about it (http://www.cs.jhu.edu/~sarat/usenix-net-2004.ps).  It provides an architecture that is very secure and stable.  I also think the modularity of the individual protocols would be a great fit for Hurd. 


On Thu, Mar 27, 2008 at 5:23 AM, Joshua Stratton <strattonbrazil@gmail.com> wrote:
I've rewritten my proposal based on some feedback from the mailing list.  Once again, more about the proposal and myself can be found off Google's website at:I really liked the paper Pierre referenced and think a modular approach with client-based memory management would provide a great network stack for Hurd being fault-tolerant, secure, and modular with negligible performance penalty.  If those interested in the network stack could read my new proposal, I'd like to get some additional feedback as to how I could refine this idea. 


On Wed, Mar 26, 2008 at 9:05 PM, Joshua Stratton <strattonbrazil@gmail.com> wrote:

As far as security and efficiency is concerned, I highly recommend
reading 'Network Subsystems Reloaded: A High-Performance, Defensible
Network Subsystem'[1].

 1. http://www.cs.jhu.edu/~sarat/usenix-net-2004.ps

Having a capability-oriented network stack would be great, BTW.

Thanks, Pierre.  That was an interesting paper.  I would love to implement this kind of implementation for Google SoC, even though it's a bit more complicated than I imagined.  They seemed to get some great benefits for only minor drops in peak bandwidth.  Their actual implementation doesn't seem unfeasible.  The idea of having clients handle resources seems very different to me, but provide some incredible advantages.  I think it would need some additional helper library could encapsulate a bit of this on the client side if the developer chose to.  Would this type of implementation be something you guys would want to see as a Google Summer of Code? 


OpenPGP 0xD9D50D8A

Version: GnuPG v1.4.6 (GNU/Linux)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]