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