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.
PacketID: 27715
05/14/2014 23:10
Spirited#16
05/14/2014 23:48
SteveRambo#17
Wow, you really Fang'd that one.Quote:
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.
05/15/2014 00:57
Korvacs#18
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.Quote:
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).
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.
05/15/2014 01:21
SteveRambo#19
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.Quote:
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.
05/15/2014 01:27
Spirited#20
And so your solution is a blocked socket model? That's how you chose to handle the possibility of that error occurring?Quote:
05/15/2014 01:33
InfamousNoone#21
shots fired
05/15/2014 01:34
SteveRambo#22
When did I ever say or even HINT that I thought using blocking sockets would be a good idea? LOOOOOOOOOOL. Come on.Quote:
05/15/2014 01:37
InsomniacPro#23
Bet you won't hit em.
05/15/2014 01:41
Spirited#24
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.Quote:
05/15/2014 01:45
CptSky#25
TCP have packet-ordering. It doesn't mean that 100% of the trafic must be processed in order...Quote:
And the only solution is to have a single-thread system ?Quote:
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).
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.
05/15/2014 01:47
Spirited#26
Amen. I was about to throw in the towel.Quote:
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.
05/15/2014 02:04
SteveRambo#27
You really shouldn't be doing a lot of heavy processing in your packet processor anyways, you know ...Quote:
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.Quote:
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.Quote:
Oh I'm sorry, I completely forgot that most of the CO private servers have to handle thooooousands of concurrent players.Quote:
05/15/2014 02:04
InfamousNoone#28
im amazed how complicated u guys can make a viable solution sound
05/15/2014 02:12
Spirited#29
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.
05/15/2014 02:13
SteveRambo#30
KISS.Quote: