Both a Wishlist/RFE and also a question.
What is limiting the Touch In/Out operators from being able to be either a Client or a Server in TCP/IP mode?
Similar to how SRT has a Caller vs Sender mode.
I find myself needing to have 2 directional communication between networked instances, and having the server and all the clients aware of each others IP addresses seems… redundant?
It would be great to have the Server TD Instance have all In/Out operators in a Server Mode, and the Client TD Instances have Client mode In/Out operators.
So, the only IP address that really matters is that of the Server Instance.
I can see the Touch In operators having collisions when in Server Mode (ie, multiple clients connecting and sending data to it).
So I suggest having a “Client Identifier” that can be set on the Client Mode operators.
The Client ID would have to be an Integer to work correctly with my following recommendations for the various types of Touch In/Out operators.
Another option would be to allow for string based Client Identifiers, and have the Info DAT (or a linked table) on the Server Mode Touch In operator that produces a lookup style table for Integer based connection ID against string based Client IDs.
Touch In TOPs can produce some sort of cache/buffer output, and the Cache Select TOP could be used to select the correct client.
This is the main requirement for an Integer base Client ID (or Client ID lookup).
The Client Identifier could be prepended to the channel names by the Touch Out CHOPs.
(e.g. 2 Client Mode Touch Out Chops each with a channel named “chan1”, and identifiers of “1” and “2”. The Touch In Server would then receive “1_chan1” and “2_chan1”).
Alternatively, a new operator similar to the Cache Select TOP that would allow for the selection of the correct stream of channels.
I don’t have much for the DATs…
Perhaps they could “Append Identifier Column”, but that doesn’t work well for Text DATs.
Or a similar operator to the Cache Select TOP.
I think this would massively simplify “Server with Multiple Clients” style setups, both for config and for actually building the networks.
Having typed this out, I feel that using a linked table based lookup with a new Cache Select style operator would be the best method.
It would be consistent across different types of operators, it wouldn’t modify the actual data sent/received, and the Lookup Table would work well with a replicator.
Additional information could be provided in the attached Lookup Table, such as “Time since last message”, “Remote IP” and so on, which would greatly improve monitoring client connection status.