[Babel-users] babel and zeroconf
Brad Neuberg
bradneuberg at gmail.com
Wed Jun 4 23:00:40 UTC 2008
Hi Luke and Juliusz! Good to hear from you. Ah, P2P DNS... thats near and
dear to my heart...
What's the context of the giant email thread below? I can glean bits and
pieces but am not sure of what the overall discussion is about.
On Wed, May 14, 2008 at 11:23 AM, Luke Kenneth Casson Leighton <
luke.leighton at googlemail.com> wrote:
> On Wed, May 14, 2008 at 12:15 AM, Juliusz Chroboczek
> <Juliusz.Chroboczek at pps.jussieu.fr> wrote:
> > > getting proper WAN-wide name registration and defending is _hard_.
> >
> > Yes, if you want to be distributed. You can always fake it with
> > a centralised server.
>
> yuk :) yes. e.g. WINS servers. WINS servers - a centralised
> "collection" point, aka NBNS servers in rfc1001/1002. the "recursion
> desired" flag is set to indicate the distinction between "actually
> this packet should go to the WINS server" and "actually this packet
> should go to the local-broadcast-network-service that is defending
> this particular LAN segment". because, obviously, a WINS server has
> to be _on_ a NetBIOS network! the "recursion desired" flag is exactly
> the same bit as the DNS "recursion desired" flag (same packet format,
> different meaning. botched by microsoft's implementation! grr)
>
>
> ... or you could have a p2p-based DNS service such as that offered by
> the lightweight p2p-dns replacement of
> https://p2psockets.dev.java.net/ (hi brad! :) )
>
> freedce / dce/rpc contains a "naming service" with the ability to do
> "global" naming. i.e. you can register as being one of many of the
> providers of a particular service. the opengroup's reference
> implementation (dce 1.1 aka freedce) and the subsequent release of dce
> 1.2.2 under the LGPL - all these codebases contain a "naming service"
> which is, unfortunately, "centralised".
>
> however, i'm mentioning the concept because i believe that a p2p
> "naming service" should deeffinitely have "group registration"
> support.
>
> thus, you can have a p2p dns cache where it would be easy to find
> yourself a local cache of the more "global" dns, and you would simply
> begin by broadcasting out to find the nearest cache, then, on finding
> one, you'd be able to query _that_ to find out further-afield
> resources...
>
> > > it takes about _three years_ to get it right - as no less than three
> > > of us found out for samba.
> >
> > Yeah, but you needed to be bug-compatible with another system. Doing
> > it from scratch would have been easier.
>
> ... you'd think so... :) but we learned that it took microsoft three
> years to get their _own_ implementation correct ha ha.
>
> > >> In a mesh network, the notion of link doesn't really
> > >> exist, so zeroconf will give mixed results.
> >
> > > ... this i don't follow. you're using terms that have specific
> > > meanings with which i'm not yet familiar, and, as it's an area i
> > > really do need to understand, i'd very much appreciate some pointers /
> > > elaboration.
> >
> > Sure. In traditional (wired) networking, a link is a set of
> > interfaces that can communicate without going through a router.
>
> oh ok.
>
> > It
> > used to be just a cable, nowadays it's usually a set of cables bridged
> > together.
>
> oh, as simple as that? ok he he.
>
> ok - so... going back to the original thing you said - that "in a
> mesh network, zeroconf can't really cope because 'link' doesn't really
> exist", a mesh network is where you have limited (unreliable)
> connectivity between nodes.
>
> soo... http://wiki.laptop.org/go/Mesh_Network_Details#Experimenting -
> they've ... oh. they cheated. they got marvell to do some of the
> low-level mesh networking. y'know... i get deeply unimpressed, more
> and more, with the OLPC's management, the more i hear about it.
>
> so anyway, that explains why zeroconf can do what it does on OLPC,
> because the mesh networking side is "taken care of" in hardware.
>
>
> > In both IPv4 and IPv6, you usually assume that if a node belongs to
> > the same subnet prefix as you do then it is on the same link, and you
> > may speak to it directly (ignoring unnumbered links and multiple
> > prefixes per link for now). In other words, you encode topology
> > information within the bits of the address.
>
> ack.
>
> > Obviously, this is not the case for mesh networks, where the topology
> > varies over time and does not correspond in any way to the address
> > allocation.
>
> ack.
>
> > > in particular, what does - or doesn't - babel provide for "mesh
> networks" ?
> >
> > Babel is a routing protocol that, in its basic form, does not make any
> > assumptions about how prefixes map to links. Hence, it will work on
> > any network topology -- wireless mesh, classical wired network --, but
> > might not be optimally efficient.
>
> doesn't matter :)
>
> > Babel can be made to be efficient on wired networks, but this requires
> > a little bit of per-node configuration. Since most of our nodes are
> > wireless, and at any rate the inefficiency incurred by using
> > out-of-the-box Babel on wired networks is slight, that's satisfactory.
>
> ack.
>
> > The only assumption that Babel makes about the underlying network is
> > that link-local multicast is able to reach all neighbours.
>
> ahh :) that would be where a "group-based" p2p "name registration"
> concept would come in handy: you could use it to maintain an
> approximation of link-local, based on aggregation of successful links
> and partially-successful links (which would sometimes require one hop
> and would sometimes drift in-and-out of direct contact).
>
> and use this aggregated list to pseudo-define a slightly more stable
> multicasting group, comprising immediate neighbours plus
> one-hop-neighbours.
>
> ... what you think? does this sound even remotely practical - or useful?
>
> > Hence, in
> > its current form, it will not work on non-broadcast (NBMA) networks,
> > such as ATM.
>
> ack.
>
> >
> > > mm? *quizzical*. i thought ipv6 didn't do multicasting?
> >
> > IPv6 multicasts just fine.
>
> oh. huh. i must have something misunderstood (from my friend who
> maintains his own node and gets a BGP feed etc. etc. - i'll have to
> ask him what that's about).
>
> > However, non-local multicast requires
> > multicast routers, and Babel doesn't route multicast right now.
> >
> >
> > > the lowest speed network is a digital radio modem, with something
> > > like a 10 mile range (with TCP/IP on it).
> >
> > How does that Simpsons line go again? Mmmh... 800MHz.
>
> he he
>
> >
> > > the other ones we have yet to specify but candidates include
> > > GPRS/EDGE or maybe 3G, and WIMAX or some other adhoc high speed
> > > networking.
> >
> > What do you mean by ``ad-hoc''? If you're using the term to mean that
> > stations can communicate between themselves, then WiMAX certainly
> > isn't, it's strictly a point-to-multipoint technology. (Which is
> > something that Babel will handle beautifully, by the way.)
>
> ooo, cooool :)
>
> > > please don't ask why all that's needed :)
> >
> > Please do tell!
>
> ha ha.
>
> well, the voice data goes over the radio-modem, but the baud rate is
> nowhere near enough to do video, which is one of the requirements.
> and the radio-modem "black box" has mesh networking built-in and it's
> all "taken care of" as far as i can tell...
>
> ... which leaves us completely buggered for transferring video content
> between devices. and pretty much everything else.
>
> so, not only am i going to need to merge all the different types of
> communications technology together but also i'm going to need to send
> certain types of traffic (voice, video, jpeg images) over the
> different communications networks, selecting the "best available" one
> for the job. (!)
>
> > > so i am suddenly extreemely interested in decent and versatile routing
> > > software that can help here!
> >
> > Babel is certainly versatile, and I like to think it's decent. It can
> > deal with multiple interfaces, which appears to be what you are mainly
> > concerned with.
>
> yes. ppp over GSM/GPRS; WIMAX; 802.11; radio-modem; all of it has to
> be sort-of... merged amorphously.
>
> what i am hoping is that the use of (at least two) extra
> communications channels will be very helpful in ensuring that the
> other channels are made best use of.
>
> e.g. if you can transfer _some_ routing information - however slowly -
> about the 2-mile-range WIMAX nodes over the 10-mile-range radio-modem,
> then you would, i assume, be able to make better routing decisions
> than you would if you didn't have the long-range radio connection?
>
>
> > But you'll really need to tell us more about the network architecture
> > you're envisioning. Whether Babel or some other technology is best
> > depends on a lot of factors,
>
> ok.
>
> > notably what kind of hand-off times are tolerable,
>
> walking around inside and outside office buildings, which might cut
> things off randomly, but assume decent antenna (4 or 8-way phased
> ceramic antenna).
>
> > whether you're interested in multi-hop routing,
>
> like http://wiki.laptop.org/go/Mesh_Network_Details#Experimenting ? yes.
>
> so - like the OLPC thing [except better :) ] assume that it's got to
> work without centralised infrastructure, but if centralised
> infrastructure is available (e.g. GPRS / 3G or a high-power
> fixed-position WIMAX unit that has better range and coverage than the
> mobile units) then it should be seamlessly taken advantage of.
>
> > how large is your power budget,
>
> luggable rather than portable. i.e. "big enough" to not have to worry
> about :)
>
> > and whether you can count on link-layer notifications.
>
> does this mean "inter-layer" notifications? i.e. like i hinted at
> above, about being able to send notifications over the radio-modem
> about the e.g. WIMAX layer?
>
> if so, yes.
>
> l.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/babel-users/attachments/20080604/3bf79fbc/attachment.htm
More information about the Babel-users
mailing list