bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: n-hurd networking


From: Thomas Bushnell, BSG
Subject: Re: n-hurd networking
Date: 07 Aug 2002 13:39:08 -0700
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Simon Law <sfllaw@uwaterloo.ca> writes:

> On Wed, Aug 07, 2002 at 01:14:57PM -0700, Thomas Bushnell, BSG wrote:
> > Ok, so the subhurd question (different from collectives).
> > 
> > It seems clear to me that each subhurd should have a separate IP
> > address, and that they should use net filters so that they keep out of
> > each other's way.  They should ignore incoming IP or ARP packets not
> > concerned with their own IP address.  This is almost adequate.  It
> > doesn't deal with packets from one subhurd to another on the same
> > machine.  I think the best thing to deal with that is to have the
> > kernel device automatically loop back such packets.
> 
>       Ooh.  That seems like a potentially bad solution.  You're going
> to have trouble with non TCP/IP protocols if you do it this way.  Please
> don't mix datalink and network protocols, that will just get ugly.

Huh?  It's a solution for IP and ARP.  It doesn't pretend to be a
solution for other cases.

Any protocol which addresses itself separates from ethernet should be
amenable to such a solution, but again, it would have to be a
per-protocol thing.

Think about disk devices.  Two subhurds cannot share a disk partition
unless the filesystem format in use enables cooperation.  There is no
*general* scheme for having two subhurds share one partition; but if
they are careful and storing things in certain ways, they could
cooperate.

Similarly, if you want two subhurds to share a network device, it can
work, but only depending on what you are using the network device
for.  If you are using it for IP and ARP, then there's no difficulty.

You say "don't mix datalink and network protocols", but I'm not sure
what you mean by "mix" here.  If you mean that net filters are the
wrong way to filter, then fine--just continue to receive all packets,
and ignore in pfinet the ones that aren't destined for the "local" IP
address.  Then you have multiple listeners on the device, and
everything still just works.

Now if you are worried that some net peers might assume that there is
a one-to-one mapping of IP address to ethernet MAC address, then,
well, *those* systems have a serious bug.  Nothing in the protocols
requires that each IP address have a separate MAC address.

Thomas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]