Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Receive packets in the thread or in game render.


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 cookery   Members   -  Reputation: 101

Like
0Likes
Like

Posted 18 May 2013 - 04:35 AM

Server sends many packets to one client example 100 packets/one second when client can receive only 40 packets/one second because client is handling packets in render function which reaches 40fps. In some minutes it makes big lag and client can't apply these packets to the game (can not keep up). I can't at the same time receive packets in thread and apply these informations to the game because it makes some problems in client's program and does crashes. I would receive packets in thread (it's much faster than game render function) and apply informations from packets received in thread to the game, but it's some strange method and makes a lot of not needed redirects thread->gameRenderFunction. What can I do with this? How work other multiplayer games, these receive packets in thread and apply them to the game render function? How it looks like?



Sponsor:

#2 C0lumbo   Crossbones+   -  Reputation: 2345

Like
2Likes
Like

Posted 18 May 2013 - 05:19 AM

There should be nothing stopping you from receiving more than one packet per frame. So a 40fps game should not be limiting you to 40 packets per second.

 

The server sending 100 packets per frame sounds wrong though. It could consolidate multiple game messages into a single packet and save a lot of bandwidth and CPU. Although if you're targeting desktop hardware then this is probably not a significant issue.

 

To receive messages on a thread, you probably just want to have the thread receive the message and just add it into some sort of thread safe queue, so that the main thread can consume the messages at an appropriate time.



#3 cookery   Members   -  Reputation: 101

Like
0Likes
Like

Posted 18 May 2013 - 07:27 AM

To receive messages on a thread, you probably just want to have the thread receive the message and just add it into some sort of thread safe queue, so that the main thread can consume the messages at an appropriate time.

 

Exactly. I have done some tests. In 10 seconds I can:

 

- receive 390 packets in the game render function

- receive 4000 packets in the thread

 

It's very big difference. 390 packets in 10 seconds its very little and it can make some lags example for 20 players. Server sends to one client 100 packets per second, not per frame, so client can receive only 390 packets in 10 seconds (should receive 1000 packets) which I could process them. My only option is just receive in the thread and make safe queue?



#4 C0lumbo   Crossbones+   -  Reputation: 2345

Like
0Likes
Like

Posted 18 May 2013 - 07:57 AM

I meant to say that the server sending 100 packets to a single client in a second is excessive (100 packets per frame would be crazily high). Ideally you should consolidate your messages into fewer packets. e.g. If you're sending positions for 10 entities 10 times per second, then you can package that information up into 10 packets instead of 100.

 

However, I'm still not sure why there would be a limit of one packet receive per frame on the client when you're handling the messages in the render thread. I suspect there's something wrong with your code if you find that's the case.

 

Receiving messages on a worker thread and sticking them into a thread safe queue would be a good approach, but I suspect there's no good reason that receiving messages on the main thread couldn't also be made to work.



#5 cookery   Members   -  Reputation: 101

Like
0Likes
Like

Posted 18 May 2013 - 08:14 AM

Hm.. I had call to Receiver function 10-50 times per frame in Game Render function and there aren't any lags. Thank you very much for help :)



#6 frob   Moderators   -  Reputation: 22226

Like
0Likes
Like

Posted 18 May 2013 - 08:30 AM

C0lumbo is pretty much on track.  Process all messages that have arrived rather than just one, and look at your frequency of messages.

 

I have moved this question to the Networking forum where it belongs.  Check the Forum FAQ and the links it contains, especially Q12 and Q14.


Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#7 hplus0603   Moderators   -  Reputation: 5519

Like
1Likes
Like

Posted 18 May 2013 - 09:57 AM

The packets are already received by the computer and buffered in the kernel. All that your "receive" function does is copy the received data out of the kernel to your application. If you write the code correctly, you should be able to receive hundreds of thousands of packets a second from a single thread (be it main thread or other thread.)


enum Bool { True, False, FileNotFound };




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS