Author Topic: client and server in the same application (Read 4419 times)

CJ_COIMBRA · « **on:** January 15, 2011, 08:00:38 pm »

Greetings,

I am currently working on a turn based strategy game with a multiplayer mode (8 players maximum).

I am studying possible aproaches for the network architecture of the game. I was thinking of a server that would iterate over the active TCP client sockets (non-blocking) and see if there is any input, then calc the result and send an answer.

However I am not sure if using selector would be better.

Also I am confused about where to place the socket reading code. It would be in the main game loop, right? Probably between input code and drawing code?

tntexplosivesltd · « **Reply #1 on:** January 17, 2011, 09:05:34 am »

A selector would definitely make this easy. TCP socket functions Accept() and Recieve() ARE blocking, and a selector gets around this problem. Definitely the way to go for multiple connections.

Also for where to have the network stuff, probably best to have it after the input, yes, and before the graphics stuff. Even better, it you can, is to have it in a seperate thread

CJ_COIMBRA · « **Reply #2 on:** January 17, 2011, 10:14:44 am »

Thanks for the reply! By the way do you by any chance understand this "dirty bit" idea? Some one mentioned it to me but I couldn´t understand his explanation... something about tagging clients on the server side when they need update...

edit: this guy I talked seemed to know a lot on networking but I could barely understand his english. He said that if I go along with a selector and timeout aproach, with game logic being calculated only on server side and then broadcasting update info for the existing clients would increase my latency even with as low as 8 players...

tntexplosivesltd · « **Reply #3 on:** January 17, 2011, 10:28:30 am »

Sorry, no. Never heard of this "dirty bit" idea. A definition for it, however, can be found here.

If latency isn't a problem, then a selector isn't such a bad idea. If it is, consider using UDP. You only need a selector for TCP connections. A comparison can be found here to help you make your decision. If you really need effof correction, you need TCP (or you could write a more error-free wrapper for UDP sockets).

CJ_COIMBRA · « **Reply #4 on:** January 17, 2011, 10:48:22 am »

This will be my first serious socket work so I guess I´ll stick around with TCP because I don´t wan´t to handle packet corruption and that stuff that might happen with UDP sockets...

Thanks!

tntexplosivesltd · « **Reply #5 on:** January 17, 2011, 10:57:41 am »

Groovy. All the best!

CJ_COIMBRA · « **Reply #6 on:** January 18, 2011, 01:25:54 am »

Another question about this.

When a client connects to the server and server accepts via selector, then only client can send data to server right? In order to send data to the client, the server also need to connect to a socket in which that client is listening, right?

What I mean is, each side needs two sockets one for sending and one for receiving? Or TCP is two way?

tntexplosivesltd · « **Reply #7 on:** January 18, 2011, 03:04:06 am »

I'm pretty sure you can send and recieve on the same TCP socket. If there are sockets waiting with the selector, either they are waiting to be accepted (in which case you add them to a client array), or they are waiting to communicate something. You can send something to any of the client arrays at any time, as long as you aren't receiving.