PacketID: 27715

Page 3 of 5 12 3 45
05/15/2014 02:14 CptSky#31
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 :rolleyes:
05/15/2014 02:16 Spirited#32
TQ uses IOCP, and has since pre-Conquer Online.
I'm wrong - they do not use IOCP.
05/15/2014 02:28 SteveRambo#33
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 :rolleyes:
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 :confused:. 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.
05/15/2014 02:37 Spirited#34
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. Bloody 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.
05/15/2014 02:47 SteveRambo#35
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. Bloody 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?
05/15/2014 03:06 Spirited#36
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 ass and continue using your terrible practices. Have fun.
05/15/2014 04:05 Y u k i#37
Now I know how hybrid felt on my previous thread. Im just enjoying the comments here.
05/15/2014 09:05 Korvacs#38
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.
05/15/2014 10:56 SteveRambo#39
Quote:
Originally Posted by Spirited View Post
Keep your head up your ass 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 fucks up, really.
05/15/2014 11:07 Korvacs#40
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.
05/15/2014 12:10 SteveRambo#41
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.
05/15/2014 12:57 Korvacs#42
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.
05/15/2014 13:15 SteveRambo#43
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?
05/15/2014 13:30 Korvacs#44
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.
05/15/2014 13:52 SteveRambo#45
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.
Page 3 of 5 12 3 45