From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] Van Jacobsen's network stack restructure From: Charles Forsyth Date: Thu, 2 Feb 2006 20:46:24 +0000 In-Reply-To: <3e1162e60602021114mcb820feue424478b30f77d89@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: efd29d58-ead0-11e9-9d60-3106f5b1d025 > I've really not dug in deep into 9P2000 to really appreciate why this is > better yet I guess. this is hardly exhaustive, but amongst other things, import $cpu /net is rather more tedious in socket land. another variant: import -a $cpu /net to extend my machine's protocol set by those of $cpu, so that i use my protocols when i can, but fall back to $cpu's when needed. also, each type of socket has its own equivalent to sockaddr_in, so that socket programs are often confined to a particular type of network. by contrast, plan 9's telnet can be used (and has been used) across many network types, because dial is just an encapsulation of a little dance that culminates in opening a file with a conventional name (clone) writing a string with a conventional form into that file "connect address" where the key thing is that "address" is a string, thus easily handled within a program and conveyed between programs without knowledge of its meaning, but the string's final recipient interprets it. thus, in plan 9, ndb/cs translates human-readable strings into little recipes of the form ``open this file, and write this string into it''; the essential level of indirection is trivial to add (but not trivial to invent--it took some time). the low-level addresses thus pass transparently through the application. by contrast, i know one project that needed to switch networks transparently, and with sockets, it was hard. even replacing the library was not enough, because the new addresses were bigger than could fit in the sockaddr_in of the time, and so some amazing hacks were employed to work round that.