First, a client would not be able to receive a subscription token just by connecting to the "sending-server" port. That is a destination connector, and without a message processing through the channel to trigger it, a connecting client would not receive anything at all. The whole point of the registration port is to provide a way for the client to push initial data to the server and/or receive initial data.
Second, a pool of connected clients would be associated with a single destination connector. As such, when a message processes through, it would be dispatched to all connected clients for that destination. If you like you can create separate destinations for separate clients, but obviously those server sockets would be bound to different ports.
For a single destination connector, the filter/transformer would not be run for each socket that happens to be currently connected. The job of the dispatcher (TCP Sender) is to take the output of the transformer (encoded data) and send it out to a downstream system. The transformer has no knowledge whatsoever of the dispatcher, what kind it is, how many sockets are connected if it happens to be a TCP Sender, etc
You can already do round-robin message dispatching with the TCP Sender by using a Velocity template variable in the address/port fields. If and when we add the new "server mode" feature, then you automatically have the broadcast-style alerting. If we added the "allowed addresses" field for server mode, then you can do the filter-by-message style for pub/sub.
We are considering adding a new "re-run the filter/transformer on each queue attempt" feature. If you leverage that, the variable address/port replacement, and the response transformer, then you could technically run the transformer for each specific socket and dispatch a message only to that socket using the "allowed addresses" field.