From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 20 Nov 2008 00:00:12 +0000 From: Eris Discordia To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: In-Reply-To: References: <2AB9AFC10DDFC15A2A6D27BA@[192.168.1.2]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [9fans] Do we have a catalog of 9P servers? Topicbox-Message-UUID: 4a2813c0-ead4-11e9-9d60-3106f5b1d025 > I wouldn't go so far as to say Plan 9 "disallows" certain functions that > are implicit in NAT. As someone mentioned in the thread before, it is > certainly possible and rather easy to write something similar to > trampoline(8) to perform load balancing. Add in packet analysis to the > mix and you have rate control, intrusion detection etc. Perhaps my choice of wording wasn't exactly correct. Make it "does not function in this capacity unless modified." But there's a missed point: add in packet analysis and you're doing NAT. The boasted transparency of Plan 9 is a product of bringing most (or really all?) functions, including networking, into a single framework. That single framework exists as an application of networking, i.e. 9P, hence living in the application layer. Descending to network layer is expulsion from the Plan 9 Eden. I have come to believe it was in the wisdom of Plan 9's creators that sooner or later the meaningless variations of network stacks up until application layer will vanish and the entire standardized stack will probably be implemented as fast and reliable hardware. In such a world--which isn't very far actually--the programmer will have to do everything they want done at the application layer so Plan 9's approach to adding additional networking capability becomes natural and obvious; it will become much harder to introduce ad hoc modifications of something as essential as the network stack and call them features. You want an _application_, you create an application, you don't mess with basics of networking. --On Wednesday, November 19, 2008 9:08 PM +0100 Anant Narayanan wrote: > >> Nevertheless, the same machinations that allow for transparency in >> Plan 9 disallow certain functions that can be naturally provided by >> a NAT implementation, or any of a number of software categories that >> involve packet filtering/rewriting/inspection. For example, the one >> I referred to in the posting you have quoted in your response: load >> balancing. Add to the list: rate control, intrusion detection, QoS >> earmarking, honeynetting, et cetera ad [put you favorite -um, -am >> here]. > > I wouldn't go so far as to say Plan 9 "disallows" certain functions that > are implicit in NAT. As someone mentioned in the thread before, it is > certainly possible and rather easy to write something similar to > trampoline(8) to perform load balancing. Add in packet analysis to the > mix and you have rate control, intrusion detection etc. > > Plan 9, in the end, is infinitely more malleable than most other OSes :-) > > -- > Anant > >