Ambal

Already in repo.

In [11144]. Thank you

In [11143]. Thank you, Feanordev

In [11142]. Thank you

In [11141]. Thanks

In [11140]. Thank you

Yes, SilverIce already put his changes regarding dynamic LOS in his git repo - you are free to check it.

faramir118, your code changes are great and I don't see any potential drawbacks currently. Looking forward to see multi-threaded proactor code. Yes, TProactor looks very nice but incorporating it into mangos might be a tough job. Also in case if someone will get poor performance or issues with TProactor they will not be able to fall back to old code - mangos will become unusable =/ Anyway, cheers to you for your awesome work

Error clearly says that your "character" DB is missing "character_pet" table. So you need to drop and recreate your DB.

All Armory issues should be reported in Armory topic - this is 3rd party project.

Please, post this bug report in Armory topic

I've found some docs regarding ACE_Proactor and ACE_Reactor pattern use on *nix and Windows systems: http://stevehuston.wordpress.com/tag/ace-proactor-overlapped-asynchronous/: So, the Proactor situation on UNIX platforms is generally not too good for demanding applications. Again, Proactor on Windows is very good, and recommended for high-performance, highly scalable networked applications. On Linux, stick to ACE_Reactor using the ACE_Dev_Poll_Reactor implementation; on other systems, stick with ACE_Reactor and ACE_Select_Reactor or ACE_TP_Reactor depending on your need for multithreaded dispatching. Information might be outdated since there were new versions of OSes as well as ACE which might have fixed those issues. If not then there is a solution called TProactor http://www.terabit.com.au/solutions.php with detailes about its internals: http://www.terabit.com.au/docs/Comparison.htm. Also their license allows us to use it w/o any issues if we will carry on their license file Looks like not all *nix OSes are good for true async IO P.S. Yes, faramir118, we should ask for kernel CPU utilization params too since async IO will push more resources to kernel level. P.P.S. We can rename your "Network.Async" config option into "Network.OldEngine", set default to "0". Create a factory method which will create a proper networking engine based on either Reactor or Proactor patterns, so users will be able to fall back to current networking code in case any issues will be spotted. The reason to try this way and not stop developing patch is: in many cases add-on Proactor improves performance up to 2 times (compared with Reactor);

Thank you, faramir118 . Yes, you can set starting buffer size to 64 KB - this is our default value in config. I'll test your changes tomorrow since currently my brain hurts so bad I can't think at all Once you'll done that, is there any possibility we can make use of "Network.Threads" config value to spawn several worker thread for processing async completion notifications? P.S. As a small advice: in AsyncSocketHandler::handle_write_stream() you should place check to see if ALL the data from m_busyBuffer was written by last write() call. If not - you should keep sending pending data until finished. Otherwise we might loose data =/ Cheers

Undergarun, there is currently no issues in code which can cause such problems you have. Maybe patch was applied with errors? Please, check if part of code which initializes visibility/AI periods from config is not damaged. Gotisch, statistics provided by Undergarun has enough precision to judge patch effect. You cannot control amount of players on you machine as well as sorts of activity they do. So there is no possibility to sit for hours and measure mid CPU usage values. Cheers.

faramir118, I'll check your code tomorrow for memory leaks so community can be able to start testing your patch Thank you very much and keep up the awesome work P.S. No memory leaks detected so far - very nice Everyone are welcome to test this patch - we want to know whether or not ping/CPU usage went down and any issues you possibly might experience. P.P.S. I'd edited topic to reflect what this patch actually does.

faramir118, please, remember that scatter/gather API is supported only on Vista/Windows 7 operating systems - no need to bother for these specific cases at all. It is better to use old fashioned way of dealing with data buffer merging and mining. P.S. I've checked you last commit with scatter/gather functionality discussed above - no sights of issue with packet drop by client. Very promising

Undergarun, what is the following values in your config for variables: 1) Visibility.AIRelocationNotifyDelay 2) Visibility.RelocationLowerLimit ?

Ouch, that sounds very weird =/ We'll take a look what might cause such issue, Undergarun.

you can use union to hold multiple data in same list

faramir118, I'll definitely check today if issue is resolved. Also, don't think that IOCP is slow - it is highly sensitive in case of async op notification receive delays. The less data you send - the more your performance might suffer because notification should be queued by OS and read by your thread (e.g using GetQueuedCompletionStatus() function call in Windows). You have to do 2 things to improve your code and lower the impact of described flaws: 1) Read maximum amount of information from OS' TCP buffer and not just header-by-body style you use. It is harder since you need to crunch received data for packets, but you will always keep your TCP stack happy and avoid packet drop by client because of possible overflows. 2) Send maximum amount of data with one async write request. To achive this keep merging your outgoing packets into one single data buffer until you receive next async write op complete notification. This way OS will send as much data as possible + you will minimize the impact of thread scheduling while it is waiting for your async op to complete. These simple ( atleast to say ) things will maximize server's throughput as well as minimize amount of async read/write requests Otherwise you might end up sending/receiving each packet once in 10-15 ms time which is a killer... Cheers

I've experienced the same issues as you had, faramir118. It seemed like client was refusing or server not sending packets back to client. Also, your current scheme of crunching networking buffer for packets looks not very efficient. But this can be easily improved once issue with packet send will get fixed.

faramir118, you might have a bug in your code:you do not initialize bool AsyncSocketHandler::m_open variable in AsyncSocketHandler(AsyncAcceptor *acceptor) constructor code. Also you do not initialize m_OverSpeedPings and m_LastPingTime variables too.

fallenangelX, can you check if turning VMAPs on will solve your issue? Since some zone_id information is present in .vmap files

Any news about this patch development?

This might be a problem with wrong extracted .map, or DBC files. Anyway, this issue does not depend on specific character class and can be easily reproduced by everyone. fallenangelX, can you check if your .map files are properly extracted? Do you use VMAPS on your server? They can cause problems too...