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<http://www.cs.jhu.edu/%7Esarat/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.
Josh http://www.cs.utah.edu/~jstratto/soc_hurd/<http://www.cs.utah.edu/%7Ejstratto/soc_hurd/> On Thu, Mar 27, 2008 at 5:23 AM, Joshua Stratton <[EMAIL PROTECTED]> 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: > > http://www.cs.utah.edu/~jstratto/soc_hurd/<http://www.cs.utah.edu/%7Ejstratto/soc_hurd/> > > 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. > > Josh > > > On Wed, Mar 26, 2008 at 9:05 PM, Joshua Stratton <[EMAIL PROTECTED]> > 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<http://www.cs.jhu.edu/%7Esarat/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? > > > > Thanks, > > Josh > > > > > > > > > > Quickly, > > > Pierre > > > -- > > > [EMAIL PROTECTED] > > > OpenPGP 0xD9D50D8A > > > > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v1.4.6 (GNU/Linux) > > > > > > iD8DBQFH6q7Pxe13INnVDYoRAjAXAKDnHiuXTlAIguilg7fs/b6Os0BokQCfTcTQ > > > xOQ4ujb355LholWcOvBBw4Q= > > > =5MAz > > > -----END PGP SIGNATURE----- > > > > > > > > >
