Actor Framework Discussions
Multiple Connections using Network Endpoint Actors
I am currently using Network Endpoint Actors to communicate between Host and RT. One of the recent problems I have run into is that occasionally multiple Hosts will try to connect (the most common instance is one user leaves the UI open but logs off and another starts the UI under a different profile). This will give a disconnected message to the second user. The UI can't really tell if the whole RT/system is down or if they are just locked out. How does everyone else handle this issue?
The best solution I can think of is to have two (or more) different ports that can be connected to. Once a new connection is made on any of the ports I check to see if we are already connected and if so I send back a message saying that. The UI side then has to know to rotate through trying to connect on the different ports until it finds one that works. Thoughts on this idea? Does this seem like the best approach?
A slight variation on what you're describing as a solution could be to have two types of connection. Initially, have the Host connect with a Reader endpoint to a waiting Writer on the RT system.
Once the RT system receives a connection, it can send a message like "\\%ip address\{Reader,Writer} %03d" or similar, providing the name of a new connection that it has just triggered the creation of. Your first connection can be \\<ip>\Reader 001, your second \\<ip>\Reader 002, and so on... (substitute for Writer or whatever name you have/want as needed - you can spin up both if you want bidirectional communication).
Edit: To clarify - the initial connection should be immediately dropped, to allow a future connection to be made with the same static name (e.g. \\<ip>\StreamAllocator or similar)
@drjdpowell wrote:
Does the AF not have an existing implementation of a multi-client TCP server? If not, write one; don't reinvent the TCP Listener on top of a 1:1 design.
That was my main question. I was hoping I wouldn't have to do this but I can't really find anything.
I really don't need multi simultaneous client support (though I would take it and that would solve my problem) as I will maintain that only 1 UI controls the system.
I have decided to push forward with my solution. I like it better as the user would like the ability to override (kick off) the other user. Similar to how remote desktop works when two people try to remote into the same machine.
