Welcome!

Join our community of MMO enthusiasts and game developers! By registering, you'll gain access to discussions on the latest developments in MMO server files and collaborate with like-minded individuals. Join us today and unlock the potential of MMO server development!

Join Today!

Private Discussion regarding handling packets on a synchronized thread

Junior Spellweaver
Joined
Jun 29, 2009
Messages
139
Reaction score
12
Has anyone considered handling the 'game' related packets on one thread?

Right now, all sources that I know of handle each packet on whichever thread it is currently running on. This also includes all the TimerManager threads. Because of all these threads accessing and writing to different variables, we are constantly dealing with multi-threading issues. While some things are being handled correctly, there are lots of locks and synchronize key words being used, and in many cases we have sources that only last about 24 hours before they run out of memory.

If we were to queue all these packets and onto a separate, single thread then wouldn't we be able to avoid many of these problems?
 
Joined
Sep 8, 2011
Messages
822
Reaction score
129
Has anyone considered handling the 'game' related packets on one thread?

Right now, all sources that I know of handle each packet on whichever thread it is currently running on. This also includes all the TimerManager threads. Because of all these threads accessing and writing to different variables, we are constantly dealing with multi-threading issues. While some things are being handled correctly, there are lots of locks and synchronize key words being used, and in many cases we have sources that only last about 24 hours before they run out of memory.

If we were to queue all these packets and onto a separate, single thread then wouldn't we be able to avoid many of these problems?

I don't get why would you possibly want to use a single thread, when you queue all the packets into one thread, do expect a significant performance loss when there's major stress on it, it will also cause delays in sending and processing received packets. What would you do if the thread is getting deadlocked?
Literally, by placing the packet routing and handling in a single thread, the packets can't be processed all at once, they will be chained one after another, and won't be processed in a parallel manner, in other words - a HUGE delay when there's stress on the server.

The only reason why multithreaded sources here aren't stable is because they are literally spaghetti, they are full of deadlocks because they weren't implemented properly, thus being a complete poop.

Just because the implementation is bad, doesn't mean the concept/solution is, it shouldn't reflect on it.

Multi threading will always be better than single threading, especially for this use case, have fun reading:)
 
Junior Spellweaver
Joined
Jun 29, 2009
Messages
139
Reaction score
12
I don't get why would you possibly want to use a single thread, when you queue all the packets into one thread, do expect a significant performance loss when there's major stress on it, it will also cause delays in sending and processing received packets. What would you do if the thread is getting deadlocked?
Literally, by placing the packet routing and handling in a single thread, the packets can't be processed all at once, they will be chained one after another, and won't be processed in a parallel manner, in other words - a HUGE delay when there's stress on the server.

The only reason why multithreaded sources here aren't stable is because they are literally spaghetti, they are full of deadlocks because they weren't implemented properly, thus being a complete poop.

Just because the implementation is bad, doesn't mean the concept/solution is, it shouldn't reflect on it.

Multi threading will always be better than single threading, especially for this use case, have fun reading:)
I see your point. What if we were to have each channel have its own thread. That way we coukd reduce packet queue times. As well, not all packets would be queued. Only ones that access MapleStory related things like MapleMap.

Logging in for example could still be asynchronous.

Another solution would be to process the packet data asynchronous and then apply the data on a synchronous thread.

Thoughts?

 
Back
Top