bip_utracker dependency on bip_handshake

[astro]

Because the calling code needs to setup and invoke both anyway, it could also:

• Configure port and peer_id for bip_utracker requests
• Pass results to bip_handshake in its own controlled fashion

That way a utracker client wouldn't depend on the handshaker.

Do you intend to start a project that combines the various crates into a functioning application?

[GGist]

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.

[GGist]

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.

[GGist]

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.

[astro]

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?