networking design idea
can i have two clients connected to the same ip & port on the server @ the same time? will their be confilcts & stuff?
Yes, you can. =)
As for conflicts, it''ll depend on your code. If you don''t multithread or fork to handle each client, you could be very inefficient in talking to both clients (server will only process one at a time, which might not be good depending on what you''re doing).
Once you accept, you have your descriptor to use for sending and receiving. You can also get the socket address from the accept call, at least in Unix environments you can I assume it''s the same for WinSock.
For example, once you accept and get the address, you can store them all in an array, then start UDP connections to the clients. Since you have a list of each client that connected and their IP address, you can just start sending them UDP data to their open port(s), which you should have set up in the client code. So you could use TCP to "log in" or initialize the connection, then use the client address list to STREAM game data to the clients.
There are some advantages to using the same port, namely getting through firewall policies. Most firewall admins blanche at the thought of opening a range of ports, but opening just one port usually just makes them gulp and nod.
Now, I haven''t had to do any performance tuning like a game would need, but can anyone provide some facts if there is any speed difference using a single socket vs multiple? I''m assuming not, since the idea of a socket is just a conceptual tool and the reality is that the network code is just the rules to construct the packet on the network card. Whether you put 1.1.1.1:3500 or 2.2.2.2:3501 into the TCP header, seems to be the only difference between a single socket vs multiple. Seems like the real performance concerns are in how you handle your SELECT and your filedescriptors for your clients...and of course how well you design your network protocol for the game. =)
Rube
As for conflicts, it''ll depend on your code. If you don''t multithread or fork to handle each client, you could be very inefficient in talking to both clients (server will only process one at a time, which might not be good depending on what you''re doing).
Once you accept, you have your descriptor to use for sending and receiving. You can also get the socket address from the accept call, at least in Unix environments you can I assume it''s the same for WinSock.
For example, once you accept and get the address, you can store them all in an array, then start UDP connections to the clients. Since you have a list of each client that connected and their IP address, you can just start sending them UDP data to their open port(s), which you should have set up in the client code. So you could use TCP to "log in" or initialize the connection, then use the client address list to STREAM game data to the clients.
There are some advantages to using the same port, namely getting through firewall policies. Most firewall admins blanche at the thought of opening a range of ports, but opening just one port usually just makes them gulp and nod.
Now, I haven''t had to do any performance tuning like a game would need, but can anyone provide some facts if there is any speed difference using a single socket vs multiple? I''m assuming not, since the idea of a socket is just a conceptual tool and the reality is that the network code is just the rules to construct the packet on the network card. Whether you put 1.1.1.1:3500 or 2.2.2.2:3501 into the TCP header, seems to be the only difference between a single socket vs multiple. Seems like the real performance concerns are in how you handle your SELECT and your filedescriptors for your clients...and of course how well you design your network protocol for the game. =)
Rube
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement