[Freedombox-discuss] Freedom Box UUCP?
On 03/02/2011 04:57 AM, stillyet at googlemail.com wrote:
> On 2 March 2011 06:37, William Astle <lost at l-w.ca <mailto:lost at l-w.ca>>
> On 11-03-01 10:16 PM, Anthony Papillion wrote:
> Like most people. I haven't used UUCP for years. But I've been
> about ways it might be used within the Freedom Box project and, to a
> large degree, it makes sense. Specifically, UUCP works very well in
> place where there isn't an Internet connection and can be
> configured for
> email and file exchange.
> What are your thoughts on using UUCP within Freedom Box?
> UUCP might be a reasonable choice for communication between two
> nodes that both happen to support it. However, as anything else, it
> would be a huge step backward.
> Using UUCP as anything other than a single hop protocol would cause
> all sorts of confusion, not least because of bang paths. The fact
> that UUCP requires specifying every hop from source to destination
> would be unpleasant in the face of rapidly (for some value of
> rapidly) changing topology.
> Of course, figuring a way to route messages through the mesh without
> user knowledge of the path is a problem that needs to be solved and
> that is not an easy problem.
> Bang paths is precisely the point. In the days when we all ran UUCP
> (a) there was nothing better
> (b) servers were large machines in well known fixed locations with well
> known phone numbers
> (c) even so you often 'booked your slot' on the modem - dialled in at a
> particular time to avoid contention
> I strongly believe that the small distributed severlets which will allow
> users to reclaim the information network need to be able to operate
> without persistent connection to the global network, and need to be able
> to propagate messages opportunistically towards the global network.
> Natural disaster, civil disruption and just geography can all produce
> disconnected islands of network. But also because these serverlets will
> now include mobile devices, some devices will inevitably move between
> the island and the global network continent, while others will have
> intermittent connections onwards.
> So I believe that we (where 'we' is the community of interest looking at
> serverlets and the user-controlled information network generally, rather
> than the Debian[r][tm] FreedomBox[r][tm] list specifically) need a store
> and forward protocol, but we need a store and forward network which can
> discover willing relays opportunistically in real time, and which
> critically does not trust those relays (since they may be enemy
> honeytraps, or may simply never be able to pass the message onwards) but
> sends only digitally signed, tamperproof packets.
> Clearly, S+FNGP is not a project for the Debian[r][tm] FreedomBox[r][tm]
> list, but nevertheless there are some people on this list who will be
> interested. And, for the avoidance of doubt, I'm not proposing a new
> project, although I do hope to ensure that things like Tahrir and
> Serval, if they develop store and forward technology, do so interoperably
> Simon Brooke :: http://www.journeyman.cc/~simon/
> ;; Stultus in monte
Apologies, I meant to respond to Tracy Reed's earlier post
"Store-and-forward is a necessity". This very much reminds me of the
work Vint Cerf has been doing on Delay-Tolerant Networks (DTN) as
prototyped by the Bytewalla folks. See below for more information
including Bytewalla's implementation of the RFC's.
There has been an effort to integrate this into a mesh software (HSLS
and NetBSD) over at the CUWiN (http://www.cuwin.org) for some time.
There have been conversations to do the same with the commotion mesh
project (http://tech.chambana.net/projects/commotion) which is using
OLSR and OpenWRT. I'd love to hear of folks thoughts or experiences
diving into DTN.