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