lkml.org 
[lkml]   [1998]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: NADS for Linux
[off-topic about off-topicness]

Would it be a rude thing to wish that people, if at least can't be
taught to NOT send occasional off-topic (political, etc) posts here,
at least strongly resist continue discussing them?

[end off-topic]

On 1998-10-21 at 14:17:13, Mark Spencer wrote:
> It's fun to hear people having so much fun with our acronym (yes, i
> suppose there *is* a little double entendre there), but does anyone
> have any technical comments with regards to our project? I'm a bit
> surprised that I've gotten no comments of the sort "You can already do
> this with IP routing and you shouldn't play with arp" or of the sort
> of "That's just what I've been trying to do" or anything in between.

It's moderately interesting, since it could be part of a larger picture
in a world, whose buzzworlds are high-availability, failover, load
distribution, clustering. But I needed to look at thoroughly the
problem statement twice to discover what it's all about.

In short, for people with less intention to visit graphical web places,
NADS is aiming to reduce network load, (and increase server bandwith
available to clients) in a few very specific cases. These are:

1. when there is already a switched network architecture in place, by
making the server appear in multiple (possibly all) branches of the
switch-separated network.
2. ultimately, to use the linux server itself as a switch (via the
bridging code) to provide occasional communications between the
separated clients, but still provide better connectivity to each
of the local network branches.

It's all good, but I can't decide what's really so hot about it. Even
placing interfaces on subnetted interfaces, and registering multiple A
records in the name server provides similar result (the name server is
able to sort the returned records in a way that the ones "closer" to the
clients are used first). Probably not everything would work with this,
but fixing server code is not that hard to support this better, and with
most clients, it's simply works. Ok, so this requires subnetting, which
NADS does not (plan to) need, but it might be more common than switched
networks.

The second case is by default "done", since a linux bridge ("switch")
would be doing exactly what you are planning.. Even the first case
might be done with it, since if you are a bridge, you are local to all
connected clients, and you could even work as a hot backup switch.

The only difficulty is that firstly, the current bridge code is a bit
"hard coded", it could be shaped up quite a bit to multiple bridge
groups, then maybe even VLAN support, etc.. Second, the current network
architecture will be always behind "real" switches, since the network
drivers do not provide (and it's probably very hard to do) a way to look
at packet headers which are currently being received. In a real switch,
even the send is being done concurrently while the rest of the packet is
still coming in, and that sounds a nightmare to implement in a generic
network server OS like Linux. Although a few years back, mingo thought
about this, and he still might have code that could be used.

--
Janos - Don't worry, my address is real. I'm just bored of spam.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.428 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site