I am designing a UDP protocol which only requires there to be a single client and a single server, however I would like the ability to support multiple clients, or even better, multiple clients on the same machine.
When a client connects to the server, the server receives the client's IP and outgoing UDP port along with the message. However, I have not had any success in responding to the client via that outgoing port.
I guess my question is about what the right way of implementing something like this is, if data is to be sent both ways (client to server, and server back to client). It appears to me now that a single socket will not be sufficient, and that both the client and the server must maintain both a "listening" socket, and a separate "sending" socket. The sending socket must also be repeatedly opened and closed if the recipient changes. Perhaps the server would have one sending socket per connected client.
Since it seems like the outgoing UDP port isn't an actual useful value, I have to keep track of the ports from within my protocol, so that two clients on a particular machine can work out their individual listen ports, relay that to the server, and the server will simply send the data to the appropriate ports after explicitly being informed of what they are.
Edit: Okay, I don't want the "Use TCP" answer, even though it may be a valid answer. I'll describe the application a little bit: I am controlling hardware remotely in real-time through the internet. I want there to be as little latency as possible, and TCP's data integrity and in-order guarantees are simply not going to help. I just need somebody who is familiar with datagram based netcode to help me make sure that my approach is sane.