[Poll] What emulater do you like best?

[XDoombladeX]

I have used all types of emu (arcemu, aspire, mangos , ascent, antrix) but i think arcemu is da best

[Vindicated]

If you are going to announce your favorite, at least give good reasons why you use the one you do and why you DON'T use the other ones.

[Clain]

I don't use any :O

MaNGOS - Too lazy to get used to GIT.
Aspire - Mem leakz.
Arc - leaks/not latest patch.
WCell - Moar resources.

[Vindicated]

I don't use any :O

MaNGOS - Too lazy to get used to GIT.
Aspire - Mem leakz.
Arc - leaks/not latest patch.
WCell - Moar resources.

Quoted for truth. You almost forgot that all the ascent-branched emulators lack the features of other emulators and that there hasn't been a reliable database for an ascent-branched emulator since last May (before ArcEmu came out)

[Obsideon]

I have always used ArcEmu, love it, and will never go back! =)

[archonmagnus]

I'm a MaNGOS fan. I like that it's open source and could be adapted to other games should there be future interest in doing so. I tried Ascent on my first emulated server but, at the time, it was really buggy. I've yet to try ArcEmu, but for my 2kb, so far I've had little reason to switch from MaNGOS.

[SliderX]

Which of cores can hold 2000 players better?
I tried Arcemu , Ascent , Aspire and Mangos early and I surprised that it less buggy and has more working spells, BG , world events and gossip npc ... but it has more deatils which may make lag so any one could give me answer?

[mgX]

Which of cores can hold 2000 players better?
I tried Arcemu , Ascent , Aspire and Mangos early and I surprised that it less buggy and has more working spells, BG , world events and gossip npc ... but it has more deatils which may make lag so any one could give me answer?

its singlethreaded, try trinitycore

[Wamer]

I think MaNGOS or TrinityCore, both are good.

[Apoc]

its singlethreaded, try trinitycore

Everything Blizzard writes is single threaded. (Well, as close to it as they can get)

Even WoW is mostly single threaded. The other 14-15 threads are mainly render helpers, and IO threads. (Plus some network stuff) Everything as far as logic is done on the main thread. (That includes Lua) I don't see why they'd stray from a singe threaded app for their servers, especially when going multi-threaded just uses more resources in the end without much gain. Never did understand why you guys think multi-threading is 'the way to go' when you don't really understand when you should ACTUALLY use multiple threads.

[mgX]

Everything Blizzard writes is single threaded. (Well, as close to it as they can get)

Even WoW is mostly single threaded. The other 14-15 threads are mainly render helpers, and IO threads. (Plus some network stuff) Everything as far as logic is done on the main thread. (That includes Lua) I don't see why they'd stray from a singe threaded app for their servers, especially when going multi-threaded just uses more resources in the end without much gain. Never did understand why you guys think multi-threading is 'the way to go' when you don't really understand when you should ACTUALLY use multiple threads.

mmm because games usually run in 1 thread in a tight loop to prevent excess overhead, and tbh syncing threads in games is a pain... For servers, its a completely diffrent matter... You need to process massive amounts of data, and with the multicore cpus available today, it would be a waste not to utilize the extra power you have. The next generation of nehalam cpus come with 8 cores and HT (16 logical), and restricting your server to only use 1 thread for everything (yes i am well aware of the fact that blizzard use the standard cluster setup) would limit you to the amount of data that particular core can process. You are partly correct that there is overhead involved in locking crap all the time for accessing, but the gain is so much bigger in the end. Tbh, it seems like you are stuck in the early 90s where the debate with threads vs processes raged on the nix platforms

Oh yea a piece of advice.. We have been looking at alternative ways of storing dynamic data, and tbh, SQL has its uses, but oh my god gameservers is NOT one of them. Seems for our purpose that using an ODB (object database), things are 1: much easier to deal with, 2: much faster since you dont need some ****ed up ORM and crazy table lookups, 3: alot easier for the end user to deal with. Check out db4o :: Native Java & .NET Open Source Object Database even LINQ is supported! (linq2sql blows imo...)


And oh yeah, go grab a book about modern server architechture and join the new millenium

[svedin]

ArcEmu! because they have good Lua support

[Apoc]

mmm because games usually run in 1 thread in a tight loop to prevent excess overhead, and tbh syncing threads in games is a pain... For servers, its a completely diffrent matter... You need to process massive amounts of data, and with the multicore cpus available today, it would be a waste not to utilize the extra power you have. The next generation of nehalam cpus come with 8 cores and HT (16 logical), and restricting your server to only use 1 thread for everything (yes i am well aware of the fact that blizzard use the standard cluster setup) would limit you to the amount of data that particular core can process. You are partly correct that there is overhead involved in locking crap all the time for accessing, but the gain is so much bigger in the end. Tbh, it seems like you are stuck in the early 90s where the debate with threads vs processes raged on the nix platforms

Oh yea a piece of advice.. We have been looking at alternative ways of storing dynamic data, and tbh, SQL has its uses, but oh my god gameservers is NOT one of them. Seems for our purpose that using an ODB (object database), things are 1: much easier to deal with, 2: much faster since you dont need some ****ed up ORM and crazy table lookups, 3: alot easier for the end user to deal with. Check out db4o :: Native Java & .NET Open Source Object Database even LINQ is supported! (linq2sql blows imo...)


And oh yeah, go grab a book about modern server architechture and join the new millenium

Lol I think you misunderstood what I was saying.

You inherently multi-thread when you open multiple connections to the server. (Unless you're an idiot, and try to handle hundreds of concurrent connections on a single thread...)

A single thread is all that's needed to 'sync' the connections together (thinking of a logic sync here, not a real thread sync). Sure, you could multi-thread it, and spend a few hundred hours trying to work out silly bugs that are hard to catch. Or you could do it properly from the start, and only put important things on the main thread.

A server requires 2 *actual* threads running.

1) An 'initial receive' thread. Just listen for requests to connect, then fire a new thread for that connection.
2) A generalized sync thread, to make sure nothing gets screwy.

Everything else is in it's own thread, based entirely on the connection.

So in the end, it technically is a multi-threaded app. I just view it differently, as those 'multiple threads' are required to make it functional.

@ODB, try SQLite. The speed is incredibly faster, and the only real limitations are your hardware. (Since it's basically all I/O) I've been able to test up to 1k concurrent connections without it failing. Couldn't go any higher as my test machine refused to let me. (It pretty much crawled at that point.)

LINQ to SQL FTW! Are you nuts?!? Would you rather have to write all that shit out in normal SQL queries? I DIDN'T THINK SO!!

Edit; Don't diss the 90s! They were awesome. Though, the 80s were better.

[mgX]

Lol I think you misunderstood what I was saying.

You inherently multi-thread when you open multiple connections to the server. (Unless you're an idiot, and try to handle hundreds of concurrent connections on a single thread...)

A single thread is all that's needed to 'sync' the connections together (thinking of a logic sync here, not a real thread sync). Sure, you could multi-thread it, and spend a few hundred hours trying to work out silly bugs that are hard to catch. Or you could do it properly from the start, and only put important things on the main thread.

A server requires 2 *actual* threads running.

1) An 'initial receive' thread. Just listen for requests to connect, then fire a new thread for that connection.
2) A generalized sync thread, to make sure nothing gets screwy.

Everything else is in it's own thread, based entirely on the connection.

So in the end, it technically is a multi-threaded app. I just view it differently, as those 'multiple threads' are required to make it functional.

@ODB, try SQLite. The speed is incredibly faster, and the only real limitations are your hardware. (Since it's basically all I/O) I've been able to test up to 1k concurrent connections without it failing. Couldn't go any higher as my test machine refused to let me. (It pretty much crawled at that point.)

LINQ to SQL FTW! Are you nuts?!? Would you rather have to write all that shit out in normal SQL queries? I DIDN'T THINK SO!!

Edit; Don't diss the 90s! They were awesome. Though, the 80s were better.

Erm yea, we use nHibernate so bleh :/

In any case, ODB is actually faster if you combine the OR mapping needed, and the IO besides, its alot easier to work with hehe. You wont believe how much trouble nH/AR is giving us atm. LINQ works with ODB too btw :P

[Powerking89670]

Lol I think you misunderstood what I was saying.

You inherently multi-thread when you open multiple connections to the server. (Unless you're an idiot, and try to handle hundreds of concurrent connections on a single thread...)

A single thread is all that's needed to 'sync' the connections together (thinking of a logic sync here, not a real thread sync). Sure, you could multi-thread it, and spend a few hundred hours trying to work out silly bugs that are hard to catch. Or you could do it properly from the start, and only put important things on the main thread.

A server requires 2 *actual* threads running.

1) An 'initial receive' thread. Just listen for requests to connect, then fire a new thread for that connection.
2) A generalized sync thread, to make sure nothing gets screwy.

Everything else is in it's own thread, based entirely on the connection.

So in the end, it technically is a multi-threaded app. I just view it differently, as those 'multiple threads' are required to make it functional.

@ODB, try SQLite. The speed is incredibly faster, and the only real limitations are your hardware. (Since it's basically all I/O) I've been able to test up to 1k concurrent connections without it failing. Couldn't go any higher as my test machine refused to let me. (It pretty much crawled at that point.)

LINQ to SQL FTW! Are you nuts?!? Would you rather have to write all that shit out in normal SQL queries? I DIDN'T THINK SO!!

Edit; Don't diss the 90s! They were awesome. Though, the 80s were better.

I've seen many applications that use TCP do this method, but for UDP?

For applications that use UDP thread pooling is better because the amount of overhead you create when you create/destroy a thread counter acts the niceness of having it in it's own thread. The only viable method for a server that will scale beyond a couple hundred users requires a pool of worker threads that grab the packets from a Queue and then fire it back into another Queue for the network thread to send out. They start when the server starts, and the amount of them you run depends on the the number of packets currently waiting to be processed at a specific interval. (Main is nice for this)

Using this method you not only gain a speed boost by removing the overhead created in the creation/destruction of a thread, but you also save overhead from the massive number of threads that are in existence when there are many users online at one time.

Threading is nice so your service/application quality degrades more slowly until you over do it, and creating a new thread for each connection is server suicide if you need to have connections on the scale of WoW retail servers.

Here is a nice article summing it up (excuse the fact that it's Wikipedia ) : Thread pool pattern - Wikipedia, the free encyclopedia