Opened 5 years ago

Last modified 4 years ago

#1372 new defect

Large HTTP downloads fail when their tunnel expires?

Reported by: somewon Owned by:
Priority: minor Milestone:
Component: streaming Version: 0.9.14.1
Keywords: performance Cc:
Parent Tickets:

Description

Having some fun with eepget getting some wonderful books from the libgen eepsite ( http://u76v7ha6j4jmtz3k2lseaso5qy36lxs77klhovmptufwcodovatq.b32.i2p ). I'm noticing that larger files seem to fail pretty regularly with appx. 10-11 minute intervals, so I'm assuming that it's tunnel expiration causing the issue. Could we implement having interrupted single files automatically resume through another tunnel, or perhaps keep a tunnel open for the duration of a single file transfer? Obviously there's some security and other issues with keeping a tunnel open, and I dunno the specifics of that. Since the clients on both ends would have to control the participants to preserve the tunnel, it could lead to some interesting DoS or other attacks on participants, etc., so I suspect that a graceful resume with another tunnel (like eepget does by default) probably makes more sense.

Since eepget does it and a browser does not (which has frustrated me in the past when trying to download cool files, especially since in the browser there's no indication that a file is incomplete, it just says "download finished"), I assume that it might be tricky to implement, at least until we have a dedicated I2P-Browser or something. Or maybe there's some settings I could tweak in about:config to make it retry a bit more aggressively?

Anyway, I'm not sure if there's anything that can be done on the I2P side about it, but it's worth noting. Also I don't seem to notice this problem when downloading large files via HTTP from Tor .onion sites, so there's obviously something going on at the network level (maybe just faster speeds and longer-lived circuits).

I do think that this is a real problem, though - if people try I2P and find that it's just corrupting their downloads, they'll be pretty turned off.

Subtickets (add)

Change History (3)

comment:1 Changed 5 years ago by somewon

Another potential "solution" might be that if a tunnel is about to close, the server's router, or possible the outbound endpoint router injects some traffic that informs the downloading program (browser, probably) that the file is incomplete instead of "finished", if such a kind of traffic exists - I'm thinking something like TCP RST packet or similar, or some HTTP equivalent.

I'm also not sure how feasible that is, especially with lower-level encryption that may be in use like HTTPS/garlic wrapping, etc. Of course eepsites don't usually have (or need) HTTPS...

Anyway, something to think about.

Version 0, edited 5 years ago by somewon (next)

comment:2 Changed 5 years ago by zzz

  • Component changed from unspecified to streaming

comment:3 Changed 4 years ago by str4d

  • Keywords performance added
  • Milestone 0.9.16 deleted
Note: See TracTickets for help on using tickets.