Hi Peter,

You could probably move the “// Response body handling” part inside the first if, then you don’t need the return in the else and the flow will be clearer.

Yes, I did - makes sense!

Try elaborating on the closing scenarios: http session closed while waiting for the responseBody; after close()-ing the http session, waiting for httpSessionClosed() befor signaling trackerRequestSessionClosed(); etc.

I think you might add abort() too - if will send the closed() notification immediately.

You could also have a look at RFC 2616 Section 10.4 Client Error 4xx about the different HTTP 400 error codes. We should think what we should do in case of an HTTP server error response - maybe think of a way to report HTTP errors and tracker errors (ones reported in the bencoded dictionary) in an uniform way to the user code. Maybe plain strings (”HTTP server responded: 404 Not Found”, or “Tracker responded: Unknown info_hash”) and a single status notification, or plain strings with two status notifications (e.g. trackerRequestFailedOnHttpError (”404 NotFound”) and trackerRequestFaildOnTrackerError (”Unknown info_hash”)?

Ok, I’ll add these later after I finish the TrackerResponse[Parser] implementation - I’ll then have every session part working and I’ll be able to focuse on the TrackerRequestSession. I’ll also think of the error handling possibilities and write some ideas then!

Regards,

Petr