Discussion regarding handling packets on a synchronized thread

[bowser123467]

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?

[MentaL]

[Snopboy]

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 shit.

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:)
Bad Request

[bowser123467]

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 shit.

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:)
Bad Request

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?

Sent from my SM-G903W using Tapatalk