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. 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. :-) > 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? 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. Cheers, Michael
