|
You last visited: Today at 16:08
Advertisement
PacketID: 27715
Discussion on PacketID: 27715 within the CO2 Private Server forum part of the Conquer Online 2 category.
05/14/2014, 23:10
|
#16
|
elite*gold: 12
Join Date: Jul 2011
Posts: 8,212
Received Thanks: 4,115
|
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/14/2014, 23:48
|
#17
|
elite*gold: 0
Join Date: Sep 2013
Posts: 197
Received Thanks: 140
|
Quote:
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.
|
|
|
05/15/2014, 00:57
|
#18
|
elite*gold: 20
Join Date: Mar 2006
Posts: 6,125
Received Thanks: 2,518
|
Quote:
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.
|
|
|
05/15/2014, 01:21
|
#19
|
elite*gold: 0
Join Date: Sep 2013
Posts: 197
Received Thanks: 140
|
Quote:
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.
|
|
|
05/15/2014, 01:27
|
#20
|
elite*gold: 12
Join Date: Jul 2011
Posts: 8,212
Received Thanks: 4,115
|
Quote:
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?
|
|
|
05/15/2014, 01:33
|
#21
|
elite*gold: 20
Join Date: Jan 2008
Posts: 2,012
Received Thanks: 2,882
|
shots fired
|
|
|
05/15/2014, 01:34
|
#22
|
elite*gold: 0
Join Date: Sep 2013
Posts: 197
Received Thanks: 140
|
Quote:
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.
|
|
|
05/15/2014, 01:37
|
#23
|
elite*gold: 0
Join Date: Feb 2014
Posts: 397
Received Thanks: 205
|
Bet you won't hit em.
|
|
|
05/15/2014, 01:41
|
#24
|
elite*gold: 12
Join Date: Jul 2011
Posts: 8,212
Received Thanks: 4,115
|
Quote:
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.
|
|
|
05/15/2014, 01:45
|
#25
|
elite*gold: 0
Join Date: Jan 2008
Posts: 1,434
Received Thanks: 1,147
|
Quote:
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...
Quote:
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.
|
|
|
05/15/2014, 01:47
|
#26
|
elite*gold: 12
Join Date: Jul 2011
Posts: 8,212
Received Thanks: 4,115
|
Quote:
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.
|
|
|
05/15/2014, 02:04
|
#27
|
elite*gold: 0
Join Date: Sep 2013
Posts: 197
Received Thanks: 140
|
Quote:
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 ...
Quote:
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.
Quote:
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.
Quote:
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.
|
|
|
05/15/2014, 02:04
|
#28
|
elite*gold: 20
Join Date: Jan 2008
Posts: 2,012
Received Thanks: 2,882
|
im amazed how complicated u guys can make a viable solution sound
|
|
|
05/15/2014, 02:12
|
#29
|
elite*gold: 12
Join Date: Jul 2011
Posts: 8,212
Received Thanks: 4,115
|
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
|
#30
|
elite*gold: 0
Join Date: Sep 2013
Posts: 197
Received Thanks: 140
|
Quote:
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.
|
|
|
Similar Threads
|
[Request]Buy from shop packetID
11/06/2009 - CO2 Private Server - 4 Replies
using ConquerPatch._5017;
I`d need the packetID of the packet that allows you to buy stuff from shops, or if it`s a subtype of a packet, then the ID and the subtype. Btw, if anyone has a list of the PacketIDs (just the IDs, not the codes) for 5017, I`d be really grateful.
|
MessageBoard PacketID?
07/26/2009 - CO2 Private Server - 5 Replies
Heya.
Was just wondering if anyone has the messageboard packetid to make a text be written in the messageboard. I got so far that I can get what message the user inputs in the window, but not sure how to get it to write a text in the board.
Thanks.
|
All times are GMT +2. The time now is 16:08.
|
|