Derex

This is the process 1) Enter nick/pass 2) Realmd authentificates username/pass, a session key is associated for the account using SRP6 protocol 3) Get realm list 4) Connect to mangosd and authenticate with username and sessionkey 4) Select character and press the enter world, a loading screen starts 5) Drop connection to realmd 6) World loaded and you play s and v are used for SRP6 authentication session_key is the key produced from SRP6 autentication, and you use it to login to mangosd (you use it also to reconnect to realmd, when you want to change realm) SRP protocol is explained in http://srp.standford.edu

Try in EPEL repository it contains some of the good stuff thats not in RHEL -> https://fedoraproject.org/wiki/EPEL

Here is performance tip for windows 2008 -> Install Linux.

Ok, so I guess this is the final patch http://paste2.org/p/858326 [EDIT] Fixed in [10009]

You got me I didn't even compile or run the patch, because I don't have windows around.

It is disabled by default. If you havent enabled it, it wont enable itself. I think you get "unable to register client handler: Too many open files" error is because ACE on Windows uses by default WaitForMultipleObjects() type of reactor which supports MAXIMUM_WAIT_OBJECTS sockets as far as I know. MAXIMUM_WAIT_OBJECTS is 64 on XP as far as I remember, on server versions it may be bigger [EDIT] Solution1: try this patch: http://paste2.org/p/856430 Solution2: define ACE_USE_SELECT_REACTOR_FOR_REACTOR_IMPL when compiling ACE

You put the patches that realm should send in patches folder, relative to the directory from which you start realmd. The patches should have filename like this: 65535enGB.mpq where 65535 is the client build that the client has when he is connecting. Note that there is bug since the system don't have option to send different patches to different operating systems. The above scheme for sending patches is now not appropriate because realmd supports several valid client versions. I don't recommend sending patches over realmd, its there for compatibility, because I was thinking that somebody actually uses it.

I beleive patch system exists from 3-4 years ago. With new ACE realmd, the patch support is the same like before. In development versions of ace realmd, patch support has been temporary disabled, because I had to reimplement it ontop of ace networking.

It works the same way as before

Yes, but at the time we were doing mmaps, recast didn't exist. I think its around 1-2 years since ralf started it.

ACE version 5.7.7 is not officially supported by MaNGOS

Anybody tested it on freebsd and windows ?

Woweur mutex patch is perfectly fine, its a common technique to use global mutexes for protecting non-reentrant code. A better solution would be to use #pragma omp critical section than ACE mutexes, cause #pragma omp critical will work better with rest of omp. As long for openmp, the problem with it is that on some systems the gcc implementation of openmp specification ( libgomp ) is configured to use linux specific optimizations, that cause high cpu ussage ( busy waiting ) and better performance ofc. But having all CPU on 100% is not good if you use the server for other things except mangos. I think the linux specific optimizations appeared in latest gcc releases, so older systems like the stable debian are still using the posix variant which is a bit slower, but doesnt waste that much cpu.

One developer is enough

The whole picture is vmaps + maps , so not everything is in vmaps.

Nobody wanted to manually create navmeshes out of all maps (or at least ralf didn't want), thats why we try to generate them. In the article you posted the navmesh is made by the designer that made the map. If anybody would volunteer to make navmeshes manually for the whole world (maybe with some 3d software like 3dsmax, or with application that we can code especially for this task) and export it, and keep it up to date, it would be nice and will allow very optimized navigating around the world. I tried to make a navmesh from the mmaps that ralf made and then apply some mesh optimization algorithm on it (the white lines are from this mesh), so that the end result looks like the navmesh in the blog post, but generated by a program, I tried several well known algorithms for mesh optimizations, but they didn't work very well, I needed to make some super custom algorithm. So main answer: Because we are programmers, we like computers to do what we feel is too much of a repeating task for us to do manually and not go crazy.

I amended the commit at http://github.com/derex/mangos/tree/realmd with _build = ch->build; hack and also with diagnostics output of ulimit -n on server startup and enchantment that will ease debugging of the server. [EDIT] I tested opening 10 000 connections to realmd, and then login, and there was no problem. [EDIT 2] 20 000 connections were also no problem.

Hello, Thanks for reply here is answer for the reports: 1) Are you sure you have ulimit -n properly set ? If ulimit -n is set to 2048 or something near, then the behavior is expected, try to increase it. 2) I believe the bug exists both in current mangos implementation in realmd and in the new realmd, here is quick fix for the new realmd (its a hack fix that works only on little endian machines, like yours), for old realmd fix is similar. diff --git a/src/realmd/AuthSession.cpp b/src/realmd/AuthSession.cpp index 965c528..c7f1fa5 100644 --- a/src/realmd/AuthSession.cpp +++ b/src/realmd/AuthSession.cpp @@ -749,6 +749,8 @@ bool AuthSession::_HandleReconnectChallenge() _safelogin = _login; loginDatabase.escape_string(_safelogin); + _build = ch->build; + QueryResult *result = loginDatabase.PQuery ("SELECT sessionkey FROM account WHERE username = '%s'", _safelogin.c_str ()); // Stop if the account is not found

Hello, I would like to present for preview a patch for making realmd use ACE framework instead of the old sockets library for networking. [EDIT] The patch is already commited in mangos

Yea, we want the old design

For a third party developer, calculating s and v would be overkill. Authenticating in a web page using s and v will also be overkill. It could be solved easily using stored procedures inside the db, but I don't see 'normal' way to do this in mysql, for postgre using some of the pl/pgXX bindings it will be easy task.

Its a nice idea, but it would be nicer if you implement the connector to mangos as ejb module Do you find the RA stable for operation ?

Interesting approach, I really want to see some results on heavy load.

Look at following manuals man limits.conf man ulimit You would like to change the core limit to 0, so the kernel will not generate core dumps for crashed processes.

The generation of path can me implemented asynchronous. So that more than one bacground threads can generate paths (using the same mmaps data), and return the results to mangos thread. If you have problems with memory, or crashes, I can also take a look, when I have free time.