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 < [EMAIL PROTECTED]> wrote: > On Wed, May 14, 2008 at 12:15 AM, Juliusz Chroboczek > <[EMAIL PROTECTED]> 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. >
_______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/babel-users
