On Monday 12 May 2008 23:56, Ian Clarke wrote: > On Mon, May 12, 2008 at 9:52 AM, Matthew Toseland > <[EMAIL PROTECTED]> wrote: > > On Saturday 10 May 2008 17:33, Ian Clarke wrote: > >> I see a simple scenario where a "sneakernet" would be useful is in a > >> situation like Burma or Tibet where stuff is happening, possibly a > >> political crack-down, and the authorities are actively trying to > >> prevent information from getting out. > > > > You are assuming a short term emergency, right? > > In this scenario, yes - although I think similar issues arise in > aggressively repressive regimes such as Burma and North Korea.
Exactly: such a system would be useful long-term anywhere where you can get a computer but not a (safe) internet connection. > > > This is what happens now, except that the determination of what is most > > important is made individually. If there is no filtering, it will of course > > be flooded with garbage. > > Well, its kinda what happens now, except this proposal would be > faster, lower risk, and much more convenient. Flooding is a danger, > but I'm sure it could be mitigated. Ok. > > > Manual filtering will work better, if stuff is of universal relevance. Any > > broadcast system will be flooded. > > Manual filtering would require transmission in the clear, and would > require far more human intervention. Some kind of web-of-trust for > authors may be more appropriate. Passive requests? Publish/subscribe? Both features for Freenet 0.8. :) > > >> 1. The platform for this type of thing is a small mobile device, > >> getting Freenet to work well on an iPhone would be a world of pain - > >> and doesn't buy anything for us > > > > No, to do that requires a massive amount of short range bandwidth. Phones do > > not have this. What you want is to swap actual memory sticks, at least until > > PDAs with UWB (maybe wireless USB) are available. > > iPhones support 802.11n, which apparently operates at up to 70Mbps at > ranges up to 300m. That seems plenty fast enough to me. That's nice yeah, but how long are you going to be in close contact? An hour? And how much congestion can you expect - how many other people will be using this at once? How much general noise will there be from commercial networks, public wifi, etc etc? I'm not sure you could reliably exchange more than a gig... That's not to say I'm not a fan of this kind of stuff: IMHO it's better than sneakernet in a lot of ways, and it's a very viable alternate transport, which a sneakernet system should take advantage of if possible. But I do believe it should use whatever is available, high or low latency, i.e. have pluggable transports. > > > Furthermore, with the currently planned changes IMHO Freenet 0.7.1 will be > > able to run in a 64MB memory limit. Running it on a low end device is not so > > far away, and would have some massive advantages (e.g. being able to ship it > > on one of the fanless boxes they currently ship for overnight bittorrent > > downloads). > > It would be nice if Freenet could run on an iPhone, but I'm not > holding my breath. :) > > >> 2. Most or all Freenet apps assume a few seconds latency on requests > >> (Frost, Fproxy, etc), yet the latency with the sneakernet would be > >> measured in days. Freenet's existing apps would be useless here. > > > > Not true IMHO. A lot of existing Freenet apps deal with long term requests, > > which would work very nicely with sneakernet. > > Such as? FMS is pretty slow even with multi-second requests, do you > really think it would be useful with multi-day requests? I can't > think of a single Freenet app that would be useful over a transport > with multi-day latencies, it would be insane. Downloads of all kinds. These can take a long time. Uploads of all kinds, likewise. These already take ages. Freenet has minimal "offline browsing" support already, in that if a page DNFs, it offers a "keep trying and tell me when done" option. Once mister_wavey's bandwidth scheduler goes in, this may be used more widely, as many nodes will be not connected at all during peak hours, but the user can still browse what is available there. I don't see a fundamental problem with FMS over sneakernet. Practically speaking, of course it would be slow: it can't be faster than the underlying network. However, with subscriptions (over passive requests), there is no reason for it to require many many round trips. In terms of API, FMS wouldn't notice the difference at all, because FMS simply subscribes to a key (ClientGet MaxRetries=-1). At the moment, we poll for the key, 3x every half hour. In 0.8 we might simply issue a single passive request and renew it when challenged (hopefully less than that). On sneakernet it would be exactly the same. > > > I see it more as a long term, attack resistant, scalable solution for general > > communication in places where Freenet-over-UDP doesn't work. > > Agreed. Scalability IMHO requires *some* form of routing. Yes, a lot of it would be broadcast/multicast, but not all of it. There is a difference between broadcast radio and the internet! > > > What is wrong with this vision? Technically speaking, this might be best > > post-0.8, but I do think that there is a certain synergy here. > > Two things having "a certain synergy" is way way way below the bar > needed to justify incorporating the functionality into the same app. Maybe we should call a ceasefire for the time being, and I'll bug you all again about it in 0.8 when we have passive requests, transport plugins, and maybe new load management? > > Ian.
pgpelNzNOI8CU.pgp
Description: PGP signature
_______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
