Cees de Groot wrote:
Don't past walkbacks, fix them ;).
Mea culpa - you did say "But send me fixes, not whines that it doesn't work", after all :) (My excuse is that doesn't seem to be a codefix kind of thing)
Actually, I'm just mimicking MC's regular behavior here by throwing walkbacks instead of nice error dialogs. Bugger Avi about this, please ;) (or not, it's a developer tool, after all)
I don't mind that too much.
A problem right now is that the network is too unreliable because of its size. That makes me a bit wary of suggesting alternative ways to tackle this at this point in time.
Okay. I'll have to do a bit of digging to find out how messages are routed to the two hits - 30 seconds seems like a loooooong time, so I guess I need to learn more about how the p2p network works to understand why 30 seconds isn't practically infinity.
In fact I'll, just as an experiment, try setting it to 300 seconds and see what happens.
- So maybe a two-stage protocol? Ask for a file handle, retrieve from
the first host that responds?
I think that sounds like a good idea. Perhaps have a small number, say 5, of first-stage-handle-requests going simultaneously; as they time out, replace them with more from the pool of untried hits; and if one responds positively, cancel the other 4 and take the file from the offer.
Of course, the reason that I'm putting out this stuff is that I'd like to have some input on options like these - there are a lot of time/space/bandwidth tradeoffs to be made in p2p land...
Agreed :) How does bittorrent do its thing, I wonder? I did read the protocol description once many moons ago but it didn't stick, clearly...
Tony