Hi...

I newbie to forum and game programming but I have a question( probably dummy question...)

I am working on a multiplayer game like a Checkers.

My architecture goes like this:

After both client sign in to game, and ready to go,

each client, in his turn makes a 'move', and send it to server to authorize it.

After server authorize movement, it then send 2 message:

1) first one for the player which make the 'move', telling him its move is granted and it now should 'wait' for the other opponent to play.

2) second message, goes to opponent, telling him what soldier move, and that now it his 'turn' to play.... bla bla bla

my silly question is: When a each client sign-in to game, a new socket created for him for communicating with server

How can I use the socket for BOTH, sending messages to server(like movement), and also for listening to responses from server(like 'your turn', 'wait'...)

is it possible or I should create another socket for 'listening' ?

Thanks for the help

Hi...

I newbie to forum and game programming but I have a question( probably dummy question...)

I am working on a multiplayer game like a Checkers.

My architecture goes like this:

After both client sign in to game, and ready to go,

each client, in his turn makes a 'move', and send it to server to authorize it.

After server authorize movement, it then send 2 message:

1) first one for the player which make the 'move', telling him its move is granted and it now should 'wait' for the other opponent to play.

2) second message, goes to opponent, telling him what soldier move, and that now it his 'turn' to play.... bla bla bla

my silly question is: When a each client sign-in to game, a new socket created for him for communicating with server

How can I use the socket for BOTH, sending messages to server(like movement), and also for listening to responses from server(like 'your turn', 'wait'...)

is it possible or I should create another socket for 'listening' ?

Thanks for the help

simply call recv on the created socket. once a socket is created, it's available for both sending and receiving data(unless you specifically disable 1 or the other). note that recv is a blocking method, so you have to use something like select to check if data is waiting on a connection.

I'd recommend reading over beej's guide: http://beej.us/guide/bgnet/ if your not very familiar with networking.

I'd recommend reading over beej's guide: http://beej.us/guide/bgnet/ if your not very familiar with networking.

Don't be mislead by the 90s webpage. This is the place to start.

If you are using TCP, then you first create a "listening" socket. This socket is "ready" when some connection is available, and you retrieve a second socket, representing that connection, with accept(). Each time the "listening" socket is ready, you call accept() to generate another socket that represents a new connection. For two players, you need to accept() at least twice.

If you have more than one socket that may become "ready" (have input data or connections available) then you need to use select() to check all the sockets at once. Once select() says that a socket is readable, then one call to recv(), or one call to accept() for listening sockets, is guaranteed not to block.

Ok, I will use the connection socket for both send and recv with the server.

.

imply call recv on the created socket. once a socket is created, it's available for both sending and receiving data(unless you specifically disable 1 or the other). note that recv is a blocking method, so you have to use something like select to check if data is waiting on a connection

My game is a turn base game, between 2 players, means that only one player has the privlege to play.

Ok, I will use the connection socket for both send and recv with the server.

.

imply call recv on the created socket. once a socket is created, it's available for both sending and receiving data(unless you specifically disable 1 or the other). note that recv is a blocking method, so you have to use something like select to check if data is waiting on a connection

My game is a turn base game, between 2 players, means that only one player has the privlege to play.

why is it bad for the client to block after 'recv()' method?

When a player is in 'TURN' state, he plays its move, and send it to server, and then goes to 'WAIT' state(by calling recv()) and block until the server 'ACK' to him.

Is it bad decision? or should I do something else?

I am sorry for the newbie question but its realy my first game

Thx

that might be acceptable if your networking is on it's own thread, however if they aren't, blocking means your application can't do anything until it returns, not even quit. your users can't look around the map, if it is a window application, it can't handle window messages, it just sits and waits forever until you receive some data on that socket. if you are using tcp you'll at least get a connection closed if the other sides stops talking, but if you are using udp you'll sit forever.

in short, don't do it.

OK, now i understand.

My game also has a Chat option, so BLOCKING until recv() is not an option.

I am writing the game with Java, and look for equivalent for select() method with no luck.

Is there anything close to select() method in java? or should I try to implement something using a thread

Thx

If you're using UDP, why not use a non-blocking socket?

I am using TCP, but even if i use UDP with non-blocking socket, how can you implement a state where the client need to wait until a response from server without blocking?

You will implement a loop(true) until some text can be recv() ?

I am using TCP, but even if i use UDP with non-blocking socket, how can you implement a state where the client need to wait until a response from server without blocking?

You will implement a loop(true) until some text can be recv() ?

If performing async IO, you can simply use a Queue or callbacks when the operation succeeds. So, when messages are received, put them in a message queue, and the chat application can poll that to see if it has any unhandled messages. If so, it can simply take them and display them.

Alternatively, define a callback to be executed when a message is received, (which could write to the display, or whatever you like).