On Tuesday 15 July 2008 15:00, Michael Rogers wrote: > Theodore Hong wrote: > > I think that there are actually two distinct though related issues > > going on here, which are downtime and polling. > > > > Downtime means that the data you want is in the network, but you can't > > get to it right now because one of the nodes that the request needs to > > go through isn't up right now (e.g. a gateway out of a darknet). > > > > Polling means that the data you want isn't in the network yet, but > > you'd like to get it sometime in the future when it is inserted. > > This seems like a useful distinction. > > > DOWNTIME > > > > The downtime problem is related to delay-tolerant networking - > > http://en.wikipedia.org/wiki/Delay_Tolerant_Networking > > http://www.dtnrg.org/wiki > > In my opinion we shouldn't over-complicate the design for the sake of > nodes that are only online once a week - maybe we should avoid sending > them inserts, but a DTN layer would be overkill.
IMHO nodes that are not online all the time - as opposed to nodes whose downtime is so low that it's hardly feasible to route, I was taking an extreme example to try to make things clearer - are likely to be the majority of nodes either on an opennet or on a darknet. Most Freenet users are likely to be non-geeks who won't run their computers 24x7 for various good reasons: - Noise. - Pollution. - Energy bills. - Other people. - Security. (The paranoid will encrypt their disk and therefore only run it when they are there). On an opennet we can deal with them by reconnecting if our old peers have slots and are port forwarded, otherwise reannouncing. On a darknet, it's a lot more difficult. IMHO Freenet will not be widely deployable or usable, in the long term, unless it can be reasonably happy with say 10x7. > > Routing, caching and swapping are all based on the assumption of a > single well-connected network. If people can't remain connected to the > network then maybe they should use a DTN instead of Freenet, but Freenet > shouldn't try to be a DTN *and* a scalable anonymous DHT. There's no > such thing as an egg-laying woolmilkpig. :-) I'm not convinced. Freenet is not defined by its real-time behaviour, so much as by its goals (censorship resistant datastore), and its need to build a global f2f darknet to support those goals. > > > POLLING > > > > Polling, on the other hand, is related to publish-subscribe: > > http://en.wikipedia.org/wiki/Publish/subscribe > > > > You set up a subscription that registers your interest in some key(s), > > together with a route showing where to find you later on. When the > > data is later inserted, it gets pushed to you. > > > > Here, the trigger event is data arriving, rather than a node coming > > up. There is no further forward routing, only sending data back along > > an already-existing route. If the route to the subscriber no longer > > exists, that's another problem, but in this case I think we should > > just drop it rather than try to find the subscriber. If s/he really > > wants it, s/he can just request it again. > > Again, I would argue against adding complexity unless we definitely need > it. Is FMS currently the only use case for pub-sub? Is there any other > way to decrease the cost of outbox polling? We already have ULPRs, which do decrease the cost somewhat, and have other beneficial effects. > > Here's a suggestion: each FMS identity already publishes a list of > trusted identities and polls their outboxes. When you discover that a > trusted identity has updated its outbox, add the key to your own outbox > (unless you've already seen the key). This doesn't harm your privacy > because you've already revealed that you trust that identity. After > polling each outbox, wait for a random period before polling again. The > combination of reposting and random polling creates a gossip protocol, > which should allow nodes to discover new messages relatively quickly > with a limited amount of polling per node. This can all be done at the > application layer without pub-sub. This has been proposed more than once, I don't know if it has been implemented yet. Nonetheless there is going to be a hell of a lot of polling going on from FMS. Other apps may use batosai's web of trust plugin. There is a real time chat client which some people are using, which no doubt does evil levels of polling. And longer term it'd be great if we could have e.g. audio streams. Apart from that, a lot of traffic is nodes rerequesting stuff that has fallen out of the network, or has moved to places where it shouldn't be, I'm not sure how that relates to this though, what I do know is that some mechanism to limit it will work much better if it has some form of subscription associated with it (that being more or less the principle behind ULPRs). > > Cheers, > Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20080716/76bbd87e/attachment.pgp>
