Derex
Members-
Posts
76 -
Joined
-
Last visited
Never -
Donations
0.00 GBP
Derex's Achievements
Advanced Member (3/3)
0
Reputation
-
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
-
[GIT] CentOS Problem
Derex replied to Auntie Mangos's topic in OldInstallation, configuration & upgrades
Try in EPEL repository it contains some of the good stuff thats not in RHEL -> https://fedoraproject.org/wiki/EPEL -
High Performance Tips
Derex replied to Auntie Mangos's topic in OldInstallation, configuration & upgrades
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.
Contact Us
To contact us
click here
You can also email us at [email protected]
Privacy Policy | Terms & Conditions
You can also email us at [email protected]
Privacy Policy | Terms & Conditions
Copyright © getMaNGOS. All rights Reserved.
This website is in no way associated with or endorsed by Blizzard Entertainment®
This website is in no way associated with or endorsed by Blizzard Entertainment®