PacketID: 27715

[Spirited]

Which is why I mentioned queues and worker threads. Each client in my server can only access one worker thread at a time (since the completion port is only released after packet processing has occurred). Their backlog queue is linked to their completion port, so packets are processed in order. Therefore, I never have to worry about any of what you just mentioned. I also don't have a bottleneck as a result. Don't dumb down your code.

[SteveRambo]

Originally Posted by Spirited

Which is why I mentioned queues and worker threads. Each client in my server can only access one worker thread at a time (since the completion port is only released after packet processing has occurred). Their backlog queue is linked to their completion port, so packets are processed in order. Therefore, I never have to worry about any of what you just mentioned. I also don't have a bottleneck as a result. Don't dumb down your code.

Wow, you really Fang'd that one.

[Korvacs]

Originally Posted by SteveRambo

Player jumps from position 300, 300 to 300, 310 and sends packet A to the server with this information.
Player jumps from position 300, 310 to 300, 320 and sends packet B to the server with this information.

The server receives packet A and B in the correct order, because the server uses TCP.

The server uses a thread pool to process packets, so both packet A and B are submitted to the thread pool for processing.

The server uses thread A for processing packet A and thread B for processing packet B.

While processing packet A in thread A, the operating system suddenly decides to stop thread A before it's done processing and gives thread B time to run.

Thread B happens to complete the processing of packet B and now the operating system gives time for thread A to continue again.

What happens then? The client is going to get disconnected because the server processed the packets in the wrong order: it thinks that the player jumped from 300, 300 to 300, 320 (distance = 20 ==> disconnect).

While true it doesn't typically work that way, for one your assuming that both packets are received and added to the threadpool at the same time. That's simply not the case. There are a number of factors that make this extremely unlikely from the chances of both packets being received at the same time to the way you split your packets for handling.

In all the time I've been using a threadpool, be that my own or the Task Factory, I have never experienced this scenario, and I doubt very much that I ever will experience it.

[SteveRambo]

Originally Posted by Korvacs

While true it doesn't typically work that way, for one your assuming that both packets are received and added to the threadpool at the same time. That's simply not the case. There are a number of factors that make this extremely unlikely from the chances of both packets being received at the same time to the way you split your packets for handling.

In all the time I've been using a threadpool, be that my own or the Task Factory, I have never experienced this scenario, and I doubt very much that I ever will experience it.

It's not unheard of, though, that there has been software running for months/years just fine before discovering some critical bug related to multi-threading issues.

[Spirited]

Originally Posted by SteveRambo

It's not unheard of, though, that there has been software running for months/years just fine before discovering some critical bug related to multi-threading issues.

And so your solution is a blocked socket model? That's how you chose to handle the possibility of that error occurring?

[InfamousNoone]

shots fired

[SteveRambo]

Originally Posted by Spirited

And so your solution is a blocked socket model? That's how you chose to handle the possibility of that error occurring?

When did I ever say or even HINT that I thought using blocking sockets would be a good idea? LOOOOOOOOOOL. Come on.

[InsomniacPro]

Bet you won't hit em.

[Spirited]

Originally Posted by SteveRambo

When did I ever say or even HINT that I thought using blocking sockets would be a good idea? LOOOOOOOOOOL. Come on.

I meant a blocked packet processor, sorry. You might as well have a blocked socket system though since you're not planning on having any more players on your server. Do you honestly think a blocked packet processor is going to scale? How did you think that was a good idea? Good enough to actually recommend to people? Come on. As I said, don't dumb down your code. Design a multithreaded server that won't have that problem.

[CptSky]

Originally Posted by SteveRambo

... you might as well just use UDP then, if you don't care in what order your packets are processed

TCP have packet-ordering. It doesn't mean that 100% of the trafic must be processed in order...

Originally Posted by SteveRambo

Player jumps from position 300, 300 to 300, 310 and sends packet A to the server with this information.
Player jumps from position 300, 310 to 300, 320 and sends packet B to the server with this information.

The server receives packet A and B in the correct order, because the server uses TCP.

The server uses a thread pool to process packets, so both packet A and B are submitted to the thread pool for processing.

The server uses thread A for processing packet A and thread B for processing packet B.

While processing packet A in thread A, the operating system suddenly decides to stop thread A before it's done processing and gives thread B time to run.

Thread B happens to complete the processing of packet B and now the operating system gives time for thread A to continue again.

What happens then? The client is going to get disconnected because the server processed the packets in the wrong order: it thinks that the player jumped from 300, 300 to 300, 320 (distance = 20 ==> disconnect).

And the only solution is to have a single-thread system ?

Single-threaded design for a MMO is a really, really bad design. You could at least have worker threads and a player on one worker. Meaning, your issue is no longer an issue. You could also have worker threads with queued mouvement packets, and other worker threads for packets who can be handled out-of-order ? You could do whatever design you want to achieve the synchronisation you want. If you're good enough, you could also design a distributed architecture.

====

Honestly, anyone thinking having a single-threaded design is the way to do for a MMO should stop making one, or expect a very small player-base.

[Spirited]

Originally Posted by CptSky

TCP have packet-ordering. It doesn't mean that 100% of the trafic must be processed in order...



And the only solution is to have a single-thread system ?

Single-threaded design for a MMO is a really, really bad design. You could at least have worker threads and a player on one worker. Meaning, your issue is no longer an issue. You could also have worker threads with queued mouvement packets, and other worker threads for packets who can be handled out-of-order ? You could do whatever design you want to achieve the synchronisation you want. If you're good enough, you could also design a distributed architecture.

====

Honestly, anyone thinking having a single-threaded design is the way to do for a MMO should stop making one, or expect a very small player-base.

Amen. I was about to throw in the towel.

[SteveRambo]

Originally Posted by Spirited

I meant a blocked packet processor, sorry. You might as well have a blocked socket system though since you're not planning on having any more players on your server. Do you honestly think a blocked packet processor is going to scale? How did you think that was a good idea? Good enough to actually recommend to people? Come on. As I said, don't dumb down your code. Design a multithreaded server that won't have that problem.

You really shouldn't be doing a lot of heavy processing in your packet processor anyways, you know ...

Originally Posted by CptSky

TCP have packet-ordering. It doesn't mean that 100% of the trafic must be processed in order...

It has to at least be processed in the correct order for the individual player ... if we're talking about a CO server, of course.

Originally Posted by CptSky

And the only solution is to have a single-thread system ?

It should be more than fine for a CO server. It seems to have worked alright for TQ. They do have professional, paid programmers after all.

Originally Posted by CptSky

Honestly, anyone thinking having a single-threaded design is the way to do for a MMO should stop making one, or expect a very small player-base.

Oh I'm sorry, I completely forgot that most of the CO private servers have to handle thooooousands of concurrent players.

[InfamousNoone]

im amazed how complicated u guys can make a viable solution sound

[Spirited]

Because the phrase "good enough for a Conquer Online private server" has done so well for this community... but sure. Let's continue promoting bad programming practices.

[SteveRambo]

Originally Posted by Spirited

Because the phrase "good enough for a Conquer Online private server" has done so well for this community... but sure. Let's continue promoting bad programming practices.

KISS.