On Monday 12 May 2008 23:28, Michael Rogers wrote: > Matthew Toseland wrote: > > Hence request priorities, so that the requests for the top blocks go over the > > UDP connections. > > Are you assuming that every sneakernet connection will be backed up by > an internet connection?
No, it's merely an interesting case that will be common in a lot of less hostile, richer places (which being outside of the megacities don't have stellar bandwidth). > > > So the routing code > > could be very similar to the current code, but we would presumably have to > > store the stats in a database of some kind. > > So in other words the code would be similar, but separate? Perhaps. Some of it we'd just tune with subclasses e.g. the failure table code. > > > Again, request priorities. Maybe two completely different kinds of requests, > > fast (darknet only, no priority) and slow (can go over sneakernet or > > real-time darknet links, different sub-priorities, high latency). > > Yes, I think the code would have to be separate because the requirements > are completely different: batch operation, latency on the order of days > rather than seconds, round-trips must be minimised at all costs. A lot of our current usage is for batch operation. But you have a fair point about round-trips. > (For > example the current accept/reject negotiation would add two days per hop > in a sneakernet; token passing doesn't solve the problem because you > still need to handle loops.) True. > > So the implementations will be separate, and as Ian pointed out, so will > the applications: people won't use a system with ten-day latency for the > same purposes as a system with ten-second latency. If the > implementations and applications will both be separate, there's no > advantage that I can see to gluing the two systems together. Then why do people use Freenet for multi-day bulk downloads today? Clearly there is an overlap. Also we could handle publish/subscribe systems fairly efficiently. > > 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/devl/attachments/20080513/3fb2624e/attachment.pgp>
