Closed joseph-wakeling-sociomantic closed 5 years ago
gavin-norman-sociomantic
commented
6 years ago One relevant point is that having multiple instances of the same type of client (e.g. multiple DHT clients) in an application is regarded as unusual usage, though is theoretically possible (the clients are not singleton classes).
gavin-norman-sociomantic
commented
6 years ago A nice way to do this would be to add a string field with a default value (e.g. "DHT client") to the client config or settings struct.
joseph-wakeling-sociomantic
commented
6 years ago Yes, this sounds reasonable.
Note that there are some obvious use cases for multiple clients: for example, in some applications it might make sense to have separate reader and writer clients, so that the latter could be cleanly disabled or throttled. Overkill for most apps, but a reasonable approach nevertheless.
Another use-case could be the transition between legacy and neo protocols: while both are supported in the same client instance, there might be a reasonable case for some apps keeping a hard separation between legacy-only and neo-only client instances.
gavin-norman-sociomantic
commented
5 years ago Closing. The uses of this are very obscure.
A recent dhtproto PR raised the question of how to accurately distinguish different instances of helper classes (https://github.com/sociomantic-tsunami/dhtproto/pull/136).
One thing to observe here is that in the use-case in question (a helper class to manage initial client handshake with DHT nodes), the uniqueness that matters is not of the helper class instance, but of the client. In this case it might be useful for the client to support a means to associate it with a user-supplied identifier, which can be used by helper classes to describe which client they are working with.