the trite "not reinventing the wheel" is countered with
the equally trite "use the right tool for the job". both
avoid the point of carefully evaluating the engineering
problem.
Deprecating IL must have had engineering reasons. Among them, I guess, that
in the course of time and as applications accumulated and became more
complex it dawned on the developers that TCP had always had good reason to
be as complex as it were.
tcp is the perl of networking.
I happen to like Perl but they say liking Perl here is like being a leper.
i think it is a bit easier. the plan 9 kernel is simplier.
but that's beside the point. plan 9 network does more
with less than bsd. /net is more expressive than sockets.
the dial interface is quite elegant. plan 9 telnet works
just fine with il and most other connection-based protocols.
You seem to forget--or am I gravely mistaken?--that the network layer
occurs below /net not above it--which is why Plan 9 connections can remain
network agnostic--so the expressiveness of /net abstraction (if it exists
outside of subjective judgment) won't ease the pain of implementing a
network layer protocol.
Actually, the marginal (contrast with: the ubiquity of sockets) nature of
the interface you need to present to layers atop the layer you are
implementing will trouble you all along the way because few people know how
to present that sort of interface, there has been little experimentation in
that direction outside of the small community of Plan 9 researchers, and
the people who designed the network layer protocol you are implementing
were more or less enamored of another abstraction (again, sockets).
For the specific case of dial, dial(3) says that transport may be
explicitly specified (TCP, UDP, UNIX domain sockets, and "net") which means
dial sees things from above transport layer, i.e. from the application
layer. In other words if you were to implement IPv6 for Plan 9 you would
have to implement either TCP6 or another IPv6 transport protocol as well.
The diversity of transports available in Plan 9 should not leave the
impression that one can get away with _no_ transports.
So, it becomes unclear again where the advantage of Plan 9 for implementing
a new network protocol is. Plan 9 may have many advantages, this isn't one
of them. My impression is that its edges are mostly in newer areas of
computing (this "cloud" computing thingy) and _almost certainly_ not in
areas already explored and exhausted to the extreme.
--On Sunday, November 16, 2008 12:17 PM -0500 erik quanstrom
<[EMAIL PROTECTED]> wrote:
And what is the "IP world?" Aren't you part of it? Does your network use
a different transport/network layer protocol than TCP/IP? IL is
dead--just in case you were thinking of it--because to re-invent the
wheel was eventually perceived redundant.
yes. several. il/ip being one of them.
the trite "not reinventing the wheel" is countered with
the equally trite "use the right tool for the job". both
avoid the point of carefully evaluating the engineering
problem.
tcp is the perl of networking.
I see no reason why implementing IPv6 for Plan 9 has to be easier than
the same task on *BSD. What does Plan 9's dubious claim to superior
design as an OS have to do with implementing a network layer protocol?
i think it is a bit easier. the plan 9 kernel is simplier.
but that's beside the point. plan 9 network does more
with less than bsd. /net is more expressive than sockets.
the dial interface is quite elegant. plan 9 telnet works
just fine with il and most other connection-based protocols.
- erik
