gpg: Signature made Tue May 13 18:03:09 2008 UTC using DSA key ID E43DA450
gpg: Good signature from "Matthew John Toseland <toad@amphibian.dyndns.org>"
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
