[final message on linux-net] > Oh, I didn't mean it look into higher level headers. It's simply > unacceptable currently that the "other" interface is completely > invisible since packets to it are not forwarded, and they are not > recognized as "local" on the closer interface. Hmmm... I suppose that would be reasonable. Just to say "looking at my bridging table, this packet belongs locally, not on any other interfaces. That shouldn't take a rewrite or anything even close though should it? Of course, I don't know if this violates whatever the bridging standard is that it tries to adhere to. > like now. [I.e. packets either are forwarded between the interfaces, > or passed upwards. Currently the last operation is not correctly > aligned with the rest of the internal networking architecture.] Your idea of the bridging interface does sound appealing, particularly in its ability to create multiple logical bridges. > Of course. Bridging can also easily bring a server down to its knees, > since all related interfaces must be in promiscuous mode, which is > really not acceptable, except maybe the case when there is *very* light > peer to peer traffic, even between nodes on the same physical network. Right, I would feel that putting the interface into promiscuous mode would be enough of an overhead by itself. However, it is still a possibility which I'd like to leave open, even if it isn't the primary focus. > I just tried to make sure you don't want to hack around the current > misbehavior of the bridging code. And of course, in a few, a bit even > more special cases NADS aims to be much more efficient. But this > brought up something in my mind which is really NADS related, will send > in a separate message. Great. I'm leaving out linux-kernel on this reply, and from now on hope that discussions like this can take place on the NADS list only. > I'll be curious what this should take from the current code; I just > started looking again at the bridging code, maybe I can help with this > part. Any help would be appreciated, but the first hurdle is to design the discovery mechanism. That is, we need a way to know which interface is closest to which host. In the case where you don't have a separate switch/hub, this is easy. And in the case where the client makes the first ARP request, I imagine it would be easy (whichever interface the ARP request comes in on first, that's the one to use to talk to them). The toughie seems to be what if the server has to talk first. How do we know *then* which interface it is? If we make an ARP request using any particular interface, it'll always come back on that interface right? Is it possible to make an ARP request of the form "arp who-has 192.168.0.1 tell 255.255.255.255"? Maybe use FF:FF:FF:FF:FF:FF as the hardware address of the frame, just for good measure? > Umm, it seems I misunderstood something; by looking again, it seems to > really do what I claimed it can't, namely it tries to decide quickly > where to forward the packet and start the transmit while still > receiving. However to me it looks a bit kludgy; very brilliant, but I > can't believe it works.. :) It only works with certain ethernet cards and does seem to have problems working with the firewall code, but if performance is the most important thing, hey, i guess that solves it. > But it's time to move to the NADS list, I hope every interested party > will find it too. Right, and for anyone else who wants to participate, please visit the NADS web site at http://www.marko.net/nads Mark - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to [EMAIL PROTECTED]
