SAM connection shall stay open even if some peer failed to resolve

[mlt]

Currently if INVALID_KEY is returned, the connection is getting closed by handle_error. Thus other peer addresses aren't even attempted to resolve... actually they fail with 10009 (The file handle supplied is not valid.)

[arvidn]

do you intend to issue a pull request for this patch? it looks reasonable as far as I can tell

[mlt]

I was planning to test this and that before submitting a pull request. Hence I called the branch work in progress to solicit comments. I'm not sure if the patch is enough. Eventually, I'd clean it up for a pull request. If you'd rather prefer a few shorter pull request, I'll do that.
There are quite a few (~3) assertions that still fail, e.g.

1. deletion of a peer that failed to handshake on time (on second_tick) fails TORRENT_ASSERT(p->in_use); @ peer_list::connection_closed
2. http_connection::on_connect often fails with m_connecting being false. Missing assignment at the end of http_connection::on_i2p_resolve ?
3. TORRENT_ASSERT(pp->prev_amount_upload == 0); in torrent::remove_peer.I'm not sure yet when this happens.

Also I'm somewhat puzzled as how to reestablish connection, e.g. when i2p router died. It doesn't look like there is a provision to reestablish SAM connection.

[arvidn]

one pull requests is fine. either way

[arvidn]

as for number 3, when a peer connects, it takes the upload/download stats from the torrent_peer object and stores it in the peer_connection. It's supposed to set the fields in torrent_peer to 0 when it does this. Then as it uploads and downloads more bytes it increments those counters in peer_connection. When it disconnects, it puts back the stats. If the counters in torrent_peer are non-zero, that implies that either some other peer_connection was connected as the same peer, or it got disconnected so quickly after connecting that it never had time to zero those counters out (and perhaps not pick up the stats either)