Ok, i'm pretty up to with Winsock now, i can send packets like a pro, TCP, UDP its all good. BUT! What way all a y'all integrate it into your games? The networking code throws a byte-stream into and out of your program, so do you tend to encase your individual data structures such as: byte stream into program : "<msg>FDSA£"$£"FA432432FfsaFDS<msg>FDSAFdsafds£"43243<msg>fdsafsa3432" And then split off each <msg> and handle it? Or is there a better way of doing it? Also, seeing as you want most of your network stuff running Async with your program WOULD it be a good idea to design a program like this?: MessageStruct newMessage = new MessageStruct(); newMessage.messageType = 432 <- 432 is a request for userName newMessage.callback = someFunction <- callback for when response is received QueueMessage (newMessage) <- Add message to queue in the mean time, a loop is running through the message queue sending them all off to the server... in the server: newMessage is received in the byteStream, data is retreived and added to the send message queue (server) when reply message (containing the requested data) is received by the client, the appropriate callback is called and handed the data. Is this a good way to go about these things? Or is there a much easier, less complicated or better way of doing it? Obviously, the server will hand out regular game-state updates, but often a client will request specific information from the server and will need to handle it. Any ideas?

I don't keep your mean. In server side, one socket with one client.

Quote:

Original post by sodme I don't keep your mean. In server side, one socket with one client.

That's ok, i dont keep your mean either.

eh?!

I think "sodme" is not a native English speaker, and was translating a phrase from some other language. My guess is that that phrase meant something like "I don't understand what you mean," and I guess the recommendation was to use one socket per client. I don't quite understand how the socket-per-client recommendation addresses the original question, but the original question was vague, so that's OK.

One socket per client is the blessing and curse of using TCP for communication, and comes with the benefits and limitations we've discussed elsewhere in this forum many times.

Sounds like you are on the right track. Both the client and the server should have a similar queue for handling messages. You don't want to send messages back and forth notifying whether a message was received or not; that just generates unneeded traffic. 98% of the time there won't be a need for the client to know if the message was received or not. For example, in an FPS game you would be sending messages to the server with location updates. By the time the client has received the 'Ok' message, the player would have moved anyways. For the other two percent, the server just creates a new message and sends it back to the client to be processed like any other message related event.

Quote:

Original post by BobV Sounds like you are on the right track. Both the client and the server should have a similar queue for handling messages. You don't want to send messages back and forth notifying whether a message was received or not; that just generates unneeded traffic. 98% of the time there won't be a need for the client to know if the message was received or not. For example, in an FPS game you would be sending messages to the server with location updates. By the time the client has received the 'Ok' message, the player would have moved anyways. For the other two percent, the server just creates a new message and sends it back to the client to be processed like any other message related event.

Ok, so most people use message queues? I'll see if i can throw together something in code / a layout design or something this evening for you all to look at and pull to pieces.