freghar

No money, no gain. You can't expect an enterprise-level support in most opensource "free" communities. I'd start with mysql connection testing, like verifying you don't have localhost restrictions in my.cnf.

Disable anti-idiotic protection in your windows (ie. "show file extensions") and rename realmd.conf.dist to realmd.conf ... and use search next time.

Sure, my patch doesn't conflict with yours.

There is a way how to do this on a Linux/Unix box - make a cronjob (or dhclient hook script) that will check for current IP address and if it's different than the last one, it updates realmd.realmlist and re-starts mangos-realmd. The other part is to set-up a dyndns service that will periodically check for your IP address and if it differs from the last one, it automatically updates your DNS entry. It's not mandatory, but - unless you want your users to change realmlist.wtf several times a day - it's worth it.

* What bug does the patch fix? What features does the patch add? It moves 'received not allowed opcode' and 'received wrong-status-req opcode' to DEBUG_LOG, where "unhandled opcode" already is. * For which repository revision was the patch created? 10523 (5c04687d47) * Who has been writing this patch? Please include either forum user names or email addresses. freghar As said in the header, it makes more sense to move those two to debug log level, since they aren't really errors. If I remember correctly, "not allowed opcode" means the client sent a packet that is recognized by the server, but it's * not implemented (but it has an opcode entry in some struct, so it's not "unhandled") * not correctly implemented (the client sends this opcode more often than server would expect / on special situations) * client bug / spoof attack / cheat attempt / ... Which makes it not really more "critical" than unhandled opcodes. I've never seen 'wrong-status-req' message, but since those other two should be in DEBUG log level and since this error message is most likely not user-correctable, I'd put it into debug as well. http://paste2.org/p/1000242

As said, read the documentation, -m64 is the default on a 64bit system. I'd like to add that And I'm closing this thread, your ability to ignore advices and inability to read documentation made it waay off topic.

There's one problem with that; buffer size. Since you're doing one read(), you have to store the result somewhere. That "somewhere" must already be allocated, so you would have to seek to EOF, measure the file size, allocate buffer for it, seek back and read it. Doing it line-by-line with, say, 255 chars per line (max) is somewhat easier.

Lynx3d already gave you a GCC documentation link, you can also use gcc manpage - http://linux.die.net/man/1/gcc . There are not really major speed improvement flags besides -O2 / -O3 (which just enables a bunch of -fxx flags), you can use -fomit-frame-pointer, but that'd make crashdumps pretty much worthless.

Wrong, -g tells what debug data should be put in the binary, -O flag just mangles the code to be more optimized. Because it does things like loop unroll and it thus uses A LOT more memory as well, -O3 is recommended for smaller binaries / projects (like simple password cracker), advanced servers like mangos should use -O2, unless run on a server with tons of spare RAM.

The certificate is for *.gridserver.com , which is somewhat confusing. The best and zero-money-cost way would be to generate your own certificate (assuming you have complete control over http server) and self-sign it. Such certificate will still show as "invalid" in most browsers, but you can distribute it's fingerprint via another channel (like git repository), so users can check it's identity and install it to their browsers.

No, it wouldn't. At least not any sane way. Multithreaded config parsing (ie. reading from the same file) makes no sense to me at all. If you do it performance-wise, it can take as much as 5ms with one thread. "The .reload problem" is more in re-reading data from a database, which can take several seconds, not about config parsing. One of the fastest ways would be to use ie. scanf()/sscanf() or related function. It's very fast (from my experience), much faster than using regular expressions. One could make the config file format somewhat more strict and use sscanf() to read it, skipping comment lines with another if() condition. I was able to parse about 16000 "name=value" pairs in 146ms on my desktop computer, single thread. When you chose to use regexps, you need to at least understand how are they handled. Each regexp must be parsed, pre-processed, compiled and then it can be executed. Doing this for each line is a ****load waste of resources. There are (at least in C) POSIX regexp functions regcomp() for regexp compilation, regexec() for regexp execution and regfree() for you - to free the compiled regexp. So you can compile a text representation of a regexp into it's binary form and then execute it as many times as you want, ie. for each line. From the looks of your code, you're compiling the regexp for each line, which is where the slowdown (most likely) comes from. edit: It seems that "searchPattern" is indeed a compiled regexp.

As said in that thread - oracle DB is way off performance limits of mangos. As long as there's one thread for world processing, there's almost no point in making mangos work with oracle DB. Even after it gets multiple threads, it'll still be way off. The only case you should be interested in oracleDB for mangos is when you have more than ~30000 users on your realm. Which is probably not going to happen. I said it's a completely different category. In my opinion - the future is most likely in PostgreSQL, with mysql uncertain future and other things. Furthermore, it's a web application backend, not a "real" database server with all the features one would welcome (like per-user logging, network data types, ...). So I'm glad for pgsql support, though projects like UDB make one's life a lot harder anyway (ie. by using mysql-specific INSERT IGNORE INTO).

You can use "git fetch" directly on the repo URL (+ revspec) if you don't want to add a remote with all the branches it has.

I guess he meant some kind of a forum plug-in, like other vBulletin forums have. There can be all the fields you define as mandatory, like revision, category, ... I'm for it. It won't be like a "real" bugtracker, but it'll be accessible to a lot more people. edit: oh, this wasn't the original idea, but it looks like a suitable compromise to me

And make sure your ports (for both realmd and mangosd) are forwarded, if you're behind NAT.

Wouldn't strtok() be easier? Or just strchr() if you can't modify the original string.

Hey, I thought CMake works with VC. At least through some plug-ins or so. As far as I know, cmake is just a set of generic rules to build final Makefiles, vcproj files and others *files.

The IP address binding was introduced a looong time ago. It allows you to run multiple independent processes on different IP addresses. Imagine a machine A having two IP addresses - IP1, IP2. You can "bind", say, an Apache (http) server to IP1, TCP port 80 and - at the same time - "bind" a VNC server to IP2, TCP port 80. This scenario is only possible without using INADDR_ANY (0.0.0.0). As for the second part; Historically, a machine accepts all traffic with destination IP address assigned to one if it's interfaces as it's own. There's no such thing as "interface IF1 with IP1" , "interface IF2 with IP2". Whenever a network packet comes to IF2 with destination address IP1, the machine accepts it. Therefore you need _something_ to prevent the machine from accepting (spoofed) packets with destination IP 127.0.0.1 sent by other computers on your network. That "something" is a network filter, usually called a "firewall".

That's exactly my point - you have no idea what it really does, right? Because you can't "bind" to an address you don't explicitly own. Not without using kernel and userspace hooks (see TPROXY iptables target for example). Therefore you can't "bind" to a subnet like 87.93.0.0/16. Actually, 0.0.0.0 is a special case, the socket struct gets filled with INADDR_ANY and sent to kernelspace. Any other value needs to be a real address assigned to one of machine's interfaces, adding something like "192.168.x.y" to the help text would only cause more confusion. There's nothing wrong using so-called "public" IP addresses, if you want to keep your server private, simply use firewall. Also the "advanced network experience" is called "routing" and there's (IMHO) nothing advanced about it, though it's not something a common Joe can do without google. You can of course use loopback, but it has the same effect (for most users) as using 0.0.0.0. Again - to block people from the outside world, you need to use a firewall. The shortened version makes it clear - this option is only useful when running two or more worldd or realmd instances. If an admin finds himself in such a situation, he should start googling on "bind IP".

I personally think the original warning is quite enough - people, who know what this option does, can change it to their needs. Others should really stay away from it. Anyway - a short description has been added.

> What bug does the patch fix? What features does the patch add? It tries to make poor souls stay away from a config option they have no idea about. > For which repository revision was the patch created? 36249a0372 - [10410] > Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread. > > Who has been writing this patch? Please include either forum user names or email addresses. The patch was created by git from changes written by vim. I just made up the words. There are quite a lot of threads / confusion about this option. Most people simply don't realize it's ONLY for local-address binding - some try to put their external (router-assigned) addresses, some try 127.0.0.1 and then wonder why noone else can connect, some others do even more crazy things. The only real purpose of this option is to allow multiple realm/world processes to be run and bound to different addresses on one machine. It can't even be used instead of a proper firewall - you can still send packets to a server bound to localhost address. Oh, and, I'm not sure if mangos uses SO_REUSEADDR, if not, I'd strongly recommend using it, it will prevent "address/port already in use" when no realmd/worldd instance is running. diff --git a/src/mangosd/mangosd.conf.dist.in b/src/mangosd/mangosd.conf.dist.in index cfd767a..e07e778 100644 --- a/src/mangosd/mangosd.conf.dist.in +++ b/src/mangosd/mangosd.conf.dist.in @@ -45,6 +45,7 @@ ConfVersion=2010062001 # # BindIP # Bind World Server to IP/hostname +# DO NOT CHANGE THIS UNLESS YOU _REALLY_ KNOW WHAT YOU'RE DOING # ###################################################################################################################

There's not really a problem with classic Makefiles (not even with GNU versions), it's just the autohell. Aside from being non-portable to windows, of course.

Intel's TBB is used on mangos only for allocation caching and memory pools to reduce the amount of mmap() calls. There's AFAIK no useful multithreading involved.

The priority is decided by the CPU scheduler in the kernel. Pretty much all today's CPU schedulers do some sort of fair task/thread switching, so there's a VERY low chance your input thread gets completely stuck because some other thread/process is "using the CPU on 100%".

To explain a bit more - a multitasking / multithread OS can handle several processes / threads, but the CPU itself cannot. The OS has to not only divide the time between threads/processes, but it also needs to backup&restore register sets for those threads. Ie. if thread 1 is currently active and it's time to run thread 2, the OS (well, kernel) needs to save registers of thread 1 somewhere, restore second thread's registers (from already saved state) and continue execution of thread 2. Some CPUs (I believe it's called HyperThreading) can store (mostly) 2 registers sets, so - for two simultaneous threads - you don't need to do this save&restore things. But since no major kernel / OS uses 2-8 threads only, there still has to be done some of the work. So in general - if you have, say, 2000 threads, you need about 2000 CPU cores to run those threads efficiently. Context switches do really cost some CPU time, therefore 20 threads is still okay, but 200 is not. To original question - go for a separate thread with input handling. Many events can be taken care of without interfering with other threads - like when a user presses an Alt key, you don't need to store that state in some "main thread", you can simply poll for the next key input. Things like menus could have it's own thread as well (or perhaps be in the input thread), so if the rendering core locks up for some reason, the user can still interact with the application. And - of course - you need to take care of mutex locks, spinlocks, semaphores, atomic operations and all the stuff that comes with multithreading.