Expose torrent Peer status updates #987
Conversation
* basic observer framework * connects to a valid tracker * added observer channel for announce status * set up Peer Connection status Observers * add PeerConn test: connection established * added Observers factory method * Added Event to AnnounceStatus, with embedded TrackerStatus * state updates must be non-blocking * add unit tests on PeerConn Observer status reading * add test and debug log on dropped connection * add PeerID check to test --------- Co-authored-by: Parker Whittle <[email protected]>
|
I'm not sure about this one. I don't think channels are a good way to handle events unless there's explicit concurrency cooperation required. In the case here where we are updating status information, there's no cooperation, we're just telling users of events. I think I started setting up https://pkg.go.dev/github.com/anacrolix/torrent#Callbacks as a way to handle various events that occur in the client. In particular if you wanted to have a subset of this exposed to various subpackages, like trackers, webtorrent etc. you would create a callback struct for each of those and embed it in the larger one in the client. Having synchronous events lets the user act on or even alter behaviour as appropriate. As for the various status objects, what do you think of just exposing those internal types where possible instead? I believe I started this process for Peer, PeerConn, Torrent and a few others, and their public API is mixed but could be extended. In general I think introducing observers, and meta types to track their state creates new API contracts that are particularly hard to navigate around. I could be completely wrong but it just doesn't feel right. There have been plenty of bad API choices in anacrolix/torrent to date that I'm stuck with. |
|
Thanks for getting back to me on this. I generally like channels as I feel I can give real-time updates as things happen, but I see your point and I'll look into changing this into callbacks (when I get some time). |
Provide updates on peer status which include peer ID, ok status, and an error message. This can be useful for the client to be notified of errors when running a connection after handshake.
Updates are sent via channels to Observers, which are set up by the client in config.