[drats_users] Picture crash

[Dan Smith]

> OK, here's the logs.  I don't really have a clue what happened, it
> just seemed to be unhappy and stop.  I didn't change any
> configuration during the transfer, but I did go between the Chat and
> Event Log windows.

Okay, I think this clears things up a bit.  If you'll humor me, I'd
like to explain a few things from your receiving debug log as they
pertain to what's going on here.

> Acking block 13
> Acking block 14
> Acking block 15
> Acking block 16

This bit shows us that you're definitely on the fringe and you're not
getting all your blocks through cleanly the first time.  There's no
problem with that of course, just a data point.

> [SESSION 4]: Receiving [42%] 73.34 B/s (Total 2 B)
> Acking blocks [13, 14, 15, 16] ({'': '\r\x0e\x0f\x10'})
> [SESSION 4]: Receiving [45%] 78.58 B/s (Total 2 B)

This should have an "X retries" message in it but it doesn't, so I need
to fix that so that you can see it from the UI.

> Session timed out!
> SESSION IS CLOSED

Here, I believe, lies the problem you're seeing.

Unrelated (directly) to retries, there is a timer that causes it to
give up if a particular block takes too long to get through.  This is
fragile, because it can depend heavily on how much delay there is on
the line (lots, with a repeater) and the number of blocks that came
before it that had to be resent.

So, I think what's happening is that you're sending a pretty
good-sized file through a high-latency link and missing a fair number
of blocks along the way, which causes it to take a long time (which
should be fine).  Thus, towards the end, the block timers are getting
impatient and it fails too early.

I need to make some tweaks to this logic, obviously, which I'll do for
the next version.  If you can repeat this test a couple of times after
that, we can re-examine where we are.  Sound good?

Thanks for your patience!

-- 
Dan Smith
dsmith#danplanet.com, s/#/@/
www.danplanet.com
KK7DS