spermik

Yesterday we had 2700+ player online 6H uptime (yes soo bad... but good with 3.2.2a and these population) and no lag... with ACE MTMaps + gcc 4.4.2 + ACE 5.7.2, rates 60% sometimes in some core. In me experience with mangos, the secret of performance (if you have enouth CPU and RAM) are 2 important factor:

- 1) MySQL with INNODB Tunning Configuration: Without very very good config and tunnig... mangos =lag. 950+ needed

- 2) HDD IO: Without good rate IO in HDD of MySQL witn 1800+... mangos=lag

Yes.. if you have a good server and good configuration for DB. Lag is gone

Best Regards

Could you please add some hints about tweaking DB performance?

I've been playing around a bit, but I have the feeling, that there is still some tweak possible ; )

thanks,

Termitt

hmm seems another dead project ( , pastebin on first post are death, anyone still have latest version? i will give it to our devs, meybe we can make it at least stable.

Good to hear Higi, im realy looking forward to hear from you about progress.

Wish you good luck,

Termitt

Im realy looking forward to deploy this mod on server with 1200+ players, but im waiting to get compatible with mangos rev. 8870 and to avoid random crashes...

I haven'd found any recent news... Opterman, how are doing last days? ; )

...any recent progress on crashes issue?

Termitt

Im realy looking forward to test this project. Is it possible to get it from some git repo?

I've found only pastebin diff.. = /

Second question: I havent found with which mangos revision is the lastest version compatible, are you guys maintaining the compatibility with every commit?

Thanks,

Termitt (Admin@Spermik)

Hi, I will add my little opinion here. I generally agree with Alex`s idea. So the really quick description of multimangos architecture:

1) realmd remains unchanged

2) all clients connects to the supervisior server (which would be the hardest part), announced as realm in realmlist

3) "behind" the supervisior there are several game(or map) servers (simillar to curent worldd)

4) supervisior handles the easy and fast packets (like chat)

5) more complicated opcodes are routed to game servers, where they are executed

6) the game server manages most of the game logic (ie AIs, spells, colision calculations)

7) 1 game server can run more maps (ie all instances, battleground server,...) 1 map = 1 thread

8) access to the world database perform all game server on their own

9) access to the character database is made via the supervisior, which solves the race conditions in creating new items (mails, characters...)

10) communication between supervisior and the map servers is made by TCP/IP sockets, probably 1 connection per map.

I hope this will help you deciding how to write it

Cheers Tabak

unistd.h

But I have some things to add:

* Why the hell removed author the CR (\\r) from windows help print? I really don't know if that is going to work well on win.

* About the --quiet parameter - perhaps I'm too old, but I'd still do it by closing all FDs (with a loop) or directly calling close on stdin and stderr (1,2) and then opening both on /dev/null. You don't need "nul" stream pointer this way (not to mention that I have NO idea why you're opening a FILE stream and converting it to file descriptor instead opening the file descriptor directly).

* I'm curious about the daemon(3) call. Even if the support for it is in GNU/Linux, *BSD and Mac, probably excluding Solaris, I'd still use fork + setsid + close 0,1,2 and open them on /dev/null (with check if such device exists!) + chdir ..., we could tune it to use for example vfork instead of fork when available, but whatever, daemon(3) will work too.

edit: Well .. to fetch something on point and get the "critic jerk" label off me, here's my old C daemonizer - http://paste2.org/p/157871 , I wrote it a while ago so no idea if it's left it in a functional state, but it should work. Maybe you can get some ideas from it.

the unistd.h is included in Common.h so no need to include it again.

1. the CR is added automaticky, because stdout is text (not binary) stream. Btw the correct order is \\r\\n, not \\n\\r so even if you will keep that in source it will be in bad order.

2. the dup2 function does what we need. It closes the second parameter and copyes the first to that. But you are right, i should use directly open, not fopen and convert (I will correct it when I came home).

3. the daemon is not supported on all unix like systems (it is not standert possix function), but is supported on most newer BSDs and all Linux systems.

I will read your source and maybe correct and/or make it more multiplatform.

Hi I have added the --daemonize option for mangos (under unix) - someone has asked for that on the forums. I have also added the -h and --help options which will print usage and exit. And at the and I have added --quiet option (for unix) which will redirect stdout and stderr to /dev/null to suppress all output from mangos (which can be useful when debugging it under gdb - it will not spam your gdb console, which you are probably sending to some file to see backtraces and etc.).

http://tabak.spermik.info/dev/mangos/daemon.patch

Best regards

Tabak

Vladimir, you obviously dont belive me. So lets make a little proof. (Im still talking about mangos under linux, I dont understand win stuff). So lets open some SD2 cpp file (for example ScriptMgr.cpp) and add this:

class Test
{
public:
 Test()
 {
   printf("TEST CREATED\\n");
 }

 ~Test()
 {
   printf("TEST DESTROYED\\n");
 }
};

Test t;

So when out library is initialized the Test t shoud be created and message should appead in stdout. So lets recompile and run mangos.

1st strange thing: the message "TEST CREATED" appear in output immidiatly after starting the binary and NOT when the dlopen is called later in boot process (thats right because it is HARD linked to mangos and that dlopen practicaly does nothing).

2nd stragne thing: use loadscripts to reload that library. Both messages should appear (DESTROYED and CREATED) but neither does. (again the same reason, the library is NOT freed and loaded again, dlclose practicaly does nothing in this case).

3rd strange thing: the DESTROYED message is printed when the server is shutting down when all linked libraries are freed.(the same reason)

So if you will use loadscripts to load another library the first will remain loaded, because it was linked to the core just all other libraries (ZThread, ACE). And that is what Im trying to explain here

Best regards

Tabak

I have already investigated scripts reloading in the past, so despawning all scripted objects in game is a solution for safe library unload.

You are right that the SD2 patch does not modify the mangos sources, but it is linked to mangos binary by ld, so without modifying this build process the library will not be freed and reloaded - dlopen and dlclose will not work as it should (im still talning about *nix system, dunno how it works under win).

So if you wanna reloadable scripts, you will have to :

1) change the linking so mangos will not be linked to any scripting lib

2) make the load and unload safe

3) and also excluding that lib from mangos build process whould be great

Btw creating some mangos module/plugin interface whould be great to, because many ppl develop and distribute their modules as source patches, and thats not the right way.

Tabak

Btw we use a scripted NPC to teleport players out of closed areas, you can write a simple AI which will teleport anyone (except GMs for example) on sight. It has disadvantage in large areas (you will have to spawn many of those teleporters to cover it). But is has one big advantage - any GM with spawning rights can close/open any location, zone, instance, so no need to touch the sources, recompile and restart.

Tabak

We discussed it long long time ago, the scripting library is HARCODED and HARDLINKED (dynamically but is) to the core. The problem is that mangos does not have any plugin interface, so all "plugins" (like various chatlogs, bots, scripting libraries, etc,...) are hadroced to the core by patching the sources. So if you call UnloadScriptingModule() nothing will happen (im 100% sure on unix systems) because mangos-worldd is linked to that during linking process (g++ -l...). Try to delere that lib and ld will not allow mangos to start. Btw even if you will remove that link and open that library runtime you will have problems with all AIs spawned in game, those objects are allocated in the library and they will be freed during unloading, so all scripted creatures will have i_AI pointer to hell But everything is possible to rewrite

Best regards

Tabak

If you want mangos as a _real_ daemon, nothing stands between you and such goal.

Use a simple C program for example - close all I/O FDs, reopen 0,1,2 (stdin,out,err) on /dev/null, fork() under init, change process group ID, load mangos-worldd into own memory space and execute it (using exec() / execv() / execve() / ...). It's that simple.

Python has that on ~6 lines.

Or if you wanna mangos as a real daemon really really fast you can add one simple line to mangos:

daemon(0,0);

See man 3 daemon for any other info

Btw you can always run mangos as "daemon" using the screen. I start mangos with

$ screen -dmS mangos /path/to/mangos/bin/mangos-worldd

With this command mangos will start in named screen (wchich can be any time re-attached using screen -r mangos and deattached again) and it will behave as daemon. You can let mangos to create pid file and check it in restarter, or you can grep ps or use telnet to verify if its running.