Jump to content
  • Advertisement
Sign in to follow this  
Synex

Network Code Design

This topic is 4817 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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?!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!