bip_utracker dependency on bip_handshake about bip-rs HOT 4 OPEN

I was intending bip_handshake to be a central crate for all peer discovery services (trackers, dht, pex, etc) to be able to forward contact information to in an asynchronous fashion (synchronous is possible, but our BTHandshaker just sends the connect over to the mio event loop asynchronously). Because of this, I wouldn't have to export an asynchronous interface (token or callback based) for every peer discovery service, they would just asynchronously forward the contact information over to the Handshaker which would act on that information. This is because in most cases, this is what the client wants anyway, for other cases, see my last block of text.

However as you can see, some services also have metadata associated with requests such as trackers which, in addition to contact information, also return swarm statistics, and announce intervals and for these, I have no choice but to offer a crate specific asynchronous interface, but the contact information is still passed through the Handshaker asynchronously and so is not exposed with the metadata. Services like the DHT don't have metadata associated with requests so it was not necessary to have anything other than the Handshaker (not sure about PEX).

To address your second point, the Handshaker was intended to be composable so that if you wanted to, you could provide a sort of MockHandshaker which could pool or forward the connection requests to a client wanting to have more control over things.

from bip-rs.

Yes, I do intend to start a project that combines the various crates. Such a project would be external to bip-rs and would be sort of a reference torrent client similar to what libtorrent offers.

However, currently I am working on the bip_peer module so such an application wouldn't start development anytime soon. That being said, I appreciate the use cases you are bringing up as it is helpful in rethinking how each of the bip_* modules fit together.

from bip-rs.

Just to add on to my first comment, coupling the peer discovery services and the Handshaker was intended. However, approaching this issue from the perspective of a client that needs loose coupling (at least loose coupling from BTHandshaker) they can provide their own Handshaker and do whatever they want with the information provided to it.

from bip-rs.

Ok.

To me the moniker Handshaker indicated that this was all about initiating wire connections. For the other purpose, how about calling that something like SwarmInfo?

from bip-rs.