Jump to content

Derex

Members
  • Posts

    76
  • Joined

  • Last visited

    Never
  • Donations

    0.00 GBP 

Derex's Achievements

Advanced Member

Advanced Member (3/3)

0

Reputation

  1. 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
  2. Try in EPEL repository it contains some of the good stuff thats not in RHEL -> https://fedoraproject.org/wiki/EPEL
  3. Here is performance tip for windows 2008 -> Install Linux.
  4. Ok, so I guess this is the final patch http://paste2.org/p/858326 [EDIT] Fixed in [10009]
  5. You got me I didn't even compile or run the patch, because I don't have windows around.
  6. 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
  7. 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.
  8. 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.
  9. It works the same way as before
  10. Yes, but at the time we were doing mmaps, recast didn't exist. I think its around 1-2 years since ralf started it.
  11. ACE version 5.7.7 is not officially supported by MaNGOS
  12. Anybody tested it on freebsd and windows ?
  13. 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.
  14. The whole picture is vmaps + maps , so not everything is in vmaps.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use