Register for your free account! | Forgot your password?

You last visited: Today at 00:27

  • Please register to post and access all features, it's quick, easy and FREE!

Advertisement



PacketID: 27715

Discussion on PacketID: 27715 within the CO2 Private Server forum part of the Conquer Online 2 category.

Closed Thread
 
Old 05/15/2014, 02:14   #31


 
CptSky's Avatar
 
elite*gold: 0
Join Date: Jan 2008
Posts: 1,434
Received Thanks: 1,146
Quote:
Originally Posted by SteveRambo View Post
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.
Only for few packets.

Quote:
Originally Posted by SteveRambo View Post
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.
Never realized that as soon the server get a lot of players, TQ must split it ? Else you start lagging ? I wouldn't always say that TQ's system is the way to go.

Also, a little thing to know. It was designed in early 2000's ! We are in 2014, don't you think better solutions exist now ? Would you use a cipher like TQ did back in the days, for a new project ? No. It's not good enough for today's standard.

Quote:
Originally Posted by SteveRambo View Post
Oh I'm sorry, I completely forgot that most of the CO private servers have to handle thooooousands of concurrent players.
That's right. Because you'll never handle a lot of concurrent players. You can do whatever design you want. LOTF was shitty ? Meh. Not a problem, it can handle enough concurrent players
CptSky is offline  
Thanks
1 User
Old 05/15/2014, 02:16   #32
 
Spirited's Avatar
 
elite*gold: 12
Join Date: Jul 2011
Posts: 8,205
Received Thanks: 4,107
TQ uses IOCP, and has since pre-Conquer Online.
I'm wrong - they do not use IOCP.
Spirited is offline  
Old 05/15/2014, 02:28   #33
 
elite*gold: 0
Join Date: Sep 2013
Posts: 197
Received Thanks: 140
Quote:
Originally Posted by CptSky View Post
Only for few packets.
Never realized that as soon the server get a lot of players, TQ must split it ? Else you start lagging ? I wouldn't always say that TQ's system is the way to go.
No, I haven't actually experienced that. I've noticed that during events, the servers often seem to lag though, I'm pretty sure that has something to do with the way their "arena system" is implemented though. Actually, I remember when the Classic servers, the servers were PACKED with thousands of players, and no lag at all.
Quote:
Originally Posted by CptSky View Post
Also, a little thing to know. It was designed in early 2000's ! We are in 2014, don't you think better solutions exist now ? Would you use a cipher like TQ did back in the days, for a new project ? No. It's not good enough for today's standard.
Not really. And I don't care about some shitty cipher.
Quote:
Originally Posted by CptSky View Post
That's right. Because you'll never handle a lot of concurrent players. You can do whatever design you want. LOTF was shitty ? Meh. Not a problem, it can handle enough concurrent players
I'm pretty sure LOTF had other bugs that made it shit. I don't know, I never looked into it. I don't care much for the private server community, and never have, to be honest.
Quote:
Originally Posted by Spirited View Post
TQ uses IOCP, and has since pre-Conquer Online.
That has nothing to do with any of this . Why are you even mentioning that? Seriously? IOCP != Asynchronous packet processing.

Edit:
TQ does not use IOCP. At least not for Conquer Online or Eudemons Online.
SteveRambo is offline  
Old 05/15/2014, 02:37   #34
 
Spirited's Avatar
 
elite*gold: 12
Join Date: Jul 2011
Posts: 8,205
Received Thanks: 4,107
IOCP is a type of threading model for asynchronous processing. What do you mean that it's not asynchronous packet processing. It's specifically used to solve the problem you are currently trying to solve with single threading. ****** hell man.

Edit: Woah, you are absolutely correct. I could have sworn that they used IOCP. I wonder why I thought that. Oh well, IOCP is still the way to go.
Spirited is offline  
Old 05/15/2014, 02:47   #35
 
elite*gold: 0
Join Date: Sep 2013
Posts: 197
Received Thanks: 140
Quote:
Originally Posted by Spirited View Post
IOCP is a type of threading model for asynchronous processing. What do you mean that it's not asynchronous packet processing. It's specifically used to solve the problem you are currently trying to solve with single threading. ****** hell man.
IOCP is, as the name suggests, related to input/output, specifically asynchronous I/O. It has nothing to do with packet processing. Why are you confusing these two very different things?
SteveRambo is offline  
Old 05/15/2014, 03:06   #36
 
Spirited's Avatar
 
elite*gold: 12
Join Date: Jul 2011
Posts: 8,205
Received Thanks: 4,107
Quote:
Originally Posted by SteveRambo View Post
IOCP is, as the name suggests, related to input/output, specifically asynchronous I/O. It has nothing to do with packet processing. Why are you confusing these two very different things?
Processing packets is processing IO. Packets are a form of input and output. Oh well, I throw in the towel. Keep your head up your *** and continue using your terrible practices. Have fun.
Spirited is offline  
Old 05/15/2014, 04:05   #37
 
elite*gold: 0
Join Date: May 2011
Posts: 648
Received Thanks: 413
Now I know how hybrid felt on my previous thread. Im just enjoying the comments here.
Y u k i is offline  
Old 05/15/2014, 09:05   #38


 
Korvacs's Avatar
 
elite*gold: 20
Join Date: Mar 2006
Posts: 6,125
Received Thanks: 2,518
Quote:
Originally Posted by SteveRambo View Post
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.
True, but its also not unheard of there being issues with a single threaded approach, so actually there's no real difference except that one scales significantly better than the other.
Korvacs is offline  
Old 05/15/2014, 10:56   #39
 
elite*gold: 0
Join Date: Sep 2013
Posts: 197
Received Thanks: 140
Quote:
Originally Posted by Spirited View Post
Keep your head up your *** and continue using your terrible practices. Have fun.
Hahahaha, you're so cute when you think you're a computer scientist. And hey, if I wanted to use terrible practices, I could've just let myself be inspired by Project Phoenix ... not that I care for private server development at all though.
Quote:
Originally Posted by Korvacs View Post
True, but its also not unheard of there being issues with a single threaded approach, so actually there's no real difference except that one scales significantly better than the other.
That's a pretty bad argument, I think. Multi-threading is always more error prone. If you're just carelessly processing all your packets asynchronously, you might as well just make your entire project non thread-safe (no locks, no concurrent collections, etc.) and cross your fingers and hope nothing ***** up, really.
SteveRambo is offline  
Old 05/15/2014, 11:07   #40


 
Korvacs's Avatar
 
elite*gold: 20
Join Date: Mar 2006
Posts: 6,125
Received Thanks: 2,518
If your careful enough to avoid the multi-threading issues then your careful enough to design a socket system where its a practical impossibility for 2 packets be processed out of order using a multi-threaded packet handler.

Sorry, I don't see your argument. There's little evidence to support the claim unless you include people who don't know how to design a decent socket and packet handler. In which case the single threaded approach would likely fair no better.
Korvacs is offline  
Old 05/15/2014, 12:10   #41
 
elite*gold: 0
Join Date: Sep 2013
Posts: 197
Received Thanks: 140
Quote:
Originally Posted by Korvacs View Post
If your careful enough to avoid the multi-threading issues then your careful enough to design a socket system where its a practical impossibility for 2 packets be processed out of order using a multi-threaded packet handler.

Sorry, I don't see your argument. There's little evidence to support the claim unless you include people who don't know how to design a decent socket and packet handler. In which case the single threaded approach would likely fair no better.
Quote:
Originally Posted by SteveRambo View Post
If you're just carelessly processing all your packets asynchronously, you might as well just make your entire project non thread-safe (no locks, no concurrent collections, etc.) and cross your fingers and hope nothing fucks up, really.
^

Honestly, packet processing should not be doing that much work. A Conquer server doesn't have to do any kind of advanced physics calculations or anything "heavy", really. It should really just be: "Input" verification, a few commands (like changing player position, status, money, attack, whatever), and generating some form of response. It should not be anything heavy at all.

What I would do, if I were to ever write a server, which I'm not, I'd obviously async I/O and submit packets to a queue that is processed from a SINGLE, different thread. If I actually did some profiling and could prove that using a single thread for packet processing is not sufficient, then yes, I would probably start delegating the packet processing out to more threads and have different threads for different "categories" of packets, like packets that were accessing a player's position in one thread, maybe chat packets in another thread, etc., who knows. But I would never design my server like that from the start. That's really unnecessary and, in my opinion, a huge overkill. Sure, you could and should probably design your server so you can actually make this change without too much effort, but that should come naturally as long as you follow basic OOP guidelines.
SteveRambo is offline  
Old 05/15/2014, 12:57   #42


 
Korvacs's Avatar
 
elite*gold: 20
Join Date: Mar 2006
Posts: 6,125
Received Thanks: 2,518
That's your choice I suppose, but given the gains in performance you can get from using a multi-threaded application and in turn a multi-threaded packet handler I see no argument against it as long as you know what your doing. And frankly if there was ever a place for multi-threading its in a server.

To say "But I would never design my server like that from the start. That's really unnecessary and, in my opinion, a huge overkill" when discussing multi-thread packet handling for a server is frankly nonsense. There is no advantage for a single thread packet handler when compared to multi-threaded, there is only disadvantage. It can't scale effectively, you have to rewrite your source code to accommodate more clients. It can adversely effect performance if a packet ends up generating alot of processing, be that by design or a bug.

In this day and age you are frankly a fool for stubbornly refusing to design around multi-threading. It is the way forward in all aspects of programming, get with the times.
Korvacs is offline  
Old 05/15/2014, 13:15   #43
 
elite*gold: 0
Join Date: Sep 2013
Posts: 197
Received Thanks: 140
Quote:
Originally Posted by Korvacs View Post
There is no advantage for a single thread packet handler when compared to multi-threaded, there is only disadvantage.
Single-threaded advantages: Less error-prone (smaller chance of race condition/concurrency related bugs) and of course less complexity which also includes easier debugging and reasoning about the code.
The only advantage of multi-threaded packet processing is possibly a slight performance gain, which should really NOT be noticable at all anyways, unless you're doing some really heavy processing in your packet processor. Which you really shouldn't do anyways.
Quote:
Originally Posted by Korvacs View Post
It can't scale effectively, you have to rewrite your source code to accommodate more clients. It can adversely effect performance if a packet ends up generating alot of processing, be that by design or a bug.
Rewrite your source? Over-exaggerate more, please. Did you not read what I said? You adapt and refactor your source, you don't re-write it. Unless of course you're a terrible coder and didn't follow any of the basic OOP principles, then yes, you might have to re-write some decent amount of code.
Quote:
Originally Posted by Korvacs View Post
In this day and age you are frankly a fool for stubbornly refusing to design around multi-threading. It is the way forward in all aspects of programming, get with the times.
And what part of my solution is "refusing to design around multi-threading"? Really? Did you actually read what I wrote, or are you just making random stuff up for fun?
SteveRambo is offline  
Old 05/15/2014, 13:30   #44


 
Korvacs's Avatar
 
elite*gold: 20
Join Date: Mar 2006
Posts: 6,125
Received Thanks: 2,518
So no advantage to using single threaded, is what your saying. Since "Less error-prone" has nothing to do with the threading design, just the programmers ability. Multi-threading scales appropriately where as single-threaded does not.

If you have written your source to be single threaded, then you need to rewrite alot of it to accommodate thread-safe design such as collections, locks, etc for multi-threading. Its not a simple case of refactoring, provided you designed your source correctly in the first place.

I could quote where you stated explicitly that you would not design your server to be multi-threaded packet handling by design, but I suspect you would just double back on yourself, so really what's the point.

At the end of the day you have, as you stated not written a server for Conquer, so with respect be quiet. Your adding nothing to an already pointless discussion.
Korvacs is offline  
Old 05/15/2014, 13:52   #45
 
elite*gold: 0
Join Date: Sep 2013
Posts: 197
Received Thanks: 140
Quote:
Originally Posted by Korvacs View Post
If you have written your source to be single threaded, then you need to rewrite alot of it to accommodate thread-safe design such as collections, locks, etc for multi-threading. Its not a simple case of refactoring, provided you designed your source correctly in the first place.
No, because you SHOULD have written your code in such a way that it doesn't care whether or not you're using a thread-safe collection or not.
Code:
IDictionary<TValue, TKey> CreateDictionary<TValue, TKey>(...)
{

    // old code: return new Dictionary<TKey, TValue>();
    return new ConcurrentDictionary<TKey, TValue>();

}
Big deal.
That is, if you're actually following basic OOP principles, of course ...
Quote:
Originally Posted by Korvacs View Post
I could quote where you stated explicitly that you would not design your server to be multi-threaded packet handling by design, but I suspect you would just double back on yourself, so really what's the point.
I'm pretty sure I already explained my reasons for this. I don't understand why you're saying it like it's something I'm trying to hide? Lol.
Quote:
Originally Posted by Korvacs View Post
At the end of the day you have, as you stated not written a server for Conquer, so with respect be quiet. Your adding nothing to an already pointless discussion.
So you think it's fine if people just use code like this in their sources?:
Code:
                            ThreadPool.QueueUserWorkItem(O =>
                            {
                                PacketHandler.HandlePacket(Client, Type, Chunk);
                            });
Okay ... good talk though.
SteveRambo is offline  
Closed Thread


Similar Threads 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 +1. The time now is 00:27.


Powered by vBulletin®
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Support | Contact Us | FAQ | Advertising | Privacy Policy | Terms of Service | Abuse
Copyright ©2024 elitepvpers All Rights Reserved.