[Cc set truncated..]
On Sun, Jun 11, 2000 at 06:07:09PM +0200, Jes Sorensen wrote:
> >>>>> "Ben" == Ben Greear <greearb@xxxxxxxxxxxxxxx> writes:
> Ben> So just because you don't see a use for it means everyone else
> Ben> should be denied the use of it??? Gleb's argument is valid
> Ben> whether or not IPX exists, because other, so-far-unthought-of,
> Ben> protocols may be created, and they would have the same problem
> Ben> that IPX would now.
> Try to take a look at how IPX behaves on the wire before commenting -
> the people who designed it need serious larting.
IPX is/was protocol used in XNS networking, which had its
origins in early Ethernets -- I mean BEFORE the Ethernet
was standardized to be 10 Mbit/sec.
As such it worked reasonably well with 2-10 stations in
the network. Growing beyond that has proven to be non-trivial..
> Ben> TCP/IP is not the end of the line in network protocols! At the
> Ben> very least IPv6 will be extremely important in the near future.
> Some people still believe that, I used to think that but I don't see
> the push for it anymore.
One could say same of IP(v4) multicast.
Only now the userspace has gotten *some* support for it,
and all manner of multimedia things are still burning
network bandwidth for kwazillion point-to-point unicast
copies of datastreams.
Of course networks don't very widely support multicast, as
nobody has called for it because there are no applications
which would use it, and application writers don't use MC
because networks don't support it ubiquitously...
One of the major things which IPv6 has over IPv4 is its seriously
expanded address space. However...
Emergence of NAT/PAT for IPv4 has somewhat reduced the network
address space explosion with the unpleasant feature of it not
being completely transparent for all applications.
New "Realm Specific IP" (RSIP) mechanism requires that hosts
interact with external RSIP gateway (which NAT doesn't need),
so in my thinking it is similar magnitude thing to IPv4 for
the kernel stack. It isn't quite the same task for e.g. user-
space, which gets most of RSIP handling "free" from kernel.
Deployment requires a new kernel, of course.
> Ben> Broad support for almost every protocol known is one of the very
> Ben> best features of Linux. Doing anything to make that less true
> Ben> would make Linux less useful to the rest of us.
> Broad support for as much as possible is good, but limiting support
> for the mainstream in order to improve support for something broken is
Hmm.. I think I have already scrubbed the thread start
so I am not sure what thing you are talking about.
But on broad terms, in Linux having two competeting
implementations which have performance differences
affecting commonly used protocols, performance winner
gets picked -- usually.