Major preformance improvement in core networking

[Imperil]

Major preformance improvement in core networking

I recently made some changes to the RunUO core with some of the newest .Net socket patterns and tested under load I see a very significant performance increase, hence the reason I am posting.

Currently the RunUO core uses the .Net asynchronous networking that has always been present since .Net 1.1, which has always been great but with one major drawback, being that AsyncEvents and buffers are recreated fragmenting the heap, causing garbage collection, etc. The heap actually gets very fragmented eventually due to the fact during network operations the memory is pinned for sending/receiving.

Microsoft remedied this problem in .Net 3.0 by including the SocketAsyncEventArgs interface which lets you create a set amount of EventArgs for concurrent processing and reuse them in a pool. This was included strictly for high performance and high volume servers. The performance improvement are quite amazing, as I tested with my robot client and hammered the server and saw a nearly 50% performance increase and I think I could get more out of it with a few smaller optimizations.

The main Microsoft article can be found here: SocketAsyncEventArgs Class (System.Net.Sockets) and if anyone is interested or has any questions feel free to ask.

Sorry if this is the wrong forum, I'm more of an occasional lurker

 

[Lord_Greywolf]

sounds interesting
of course need to recompile the core in .net 3.0

but if you get this working good might want to post what changes you actualy made to the core files, and how to set it up, etc to use .net 3.0, etc for C#express, etc
so other people on here can try it out

 

[Imperil]

sounds interesting
of course need to recompile the core in .net 3.0

Very true, and so I am not sure how this would impact building on mono as I am not up to speed on what they have implemented yet and if they have build in these interfaces.

but if you get this working good might want to post what changes you actualy made to the core files, and how to set it up, etc to use .net 3.0, etc for C#express, etc
so other people on here can try it out

I did in fact get this building and it is a fairly significant change to some of the core, mainly the listener and netstate classes with small changes in a few other places. I don't have a lot of time to put together a good write up right now as I am very busy, but possibly next weekend I will get a chance to document all changes that I made and how to build, etc. (Although note I use Visual Studio and not express edition so people would have to extrapolate from that)

I just wanted to start a discussion on this as I wasn't sure if this was ever looked at (I am guessing that nobody looked at this as RunUO runs great even without these changes, this just allows better performance with large amounts of clients and data being sent).

 

[Lord_Greywolf]

i also think it has not beeen looked at because they have it set to use .net 2.0 and not .net 3.0

but anything that can improve performance on packets sent/recieved to help with lag when many people are on, especialy at champ spawns, many people may want to do

as for mono, i am not sure how many actualy run it on mono, but they can always use the version they have all ready

and reason why i said the C# exprees is because it is the free one that anyone can get from MS

 

[Imperil]

Sorry I did make a mistake previously, SocketAsyncEventArgs using IOCP was added in .Net 3.5, not earlier as suggested.

 

[Acronis]

Interesting, I'll have to play around with that.

 

[Rawolf]

Hi.

I also recently spotted the new SocketAsyncEventArgs introduced in .NET 3.5.
It seems highly promzing. It would be neat if the RunUO developers would inform us whether it's ideal for the next version or not. I see no reason why they wouldn't want to upgrade their code up to .NET 3.5.

I'm also really interested in memory management (Buffer pool), on performance. It would be cool to have some core dev talk.

Thanks.

 

[Mideon]

Very interesting. I look forward to seeing the guide. Would love to see what this does on my system. Great innovative idea though, props to you for it!

 

[arul]

SocketAsyncEventArgs + the specific Socket functions are available in .NET 2.0 SP1, so the updated netcode should work for everybody unless they ignore service packs :>

 

[Lord_Greywolf]

now all we need to do is see the code that works
and if for .net 2.0 would be even better, because most of us only use it because of the rest of runuo

(plus 3.5 does not like my system, i install it and everything goes goofy)

 

[Rawolf]

I would like to inform people that use Mono that SocketAsyncEventArgs is coded in such way that it simply uses threadpool behind the curtain. So I bet there won't be any optimization for Mono users.

And yes, what about some code for us to test?

best regards.

 

[Mideon]

Did anyone ever get this working? Or know what has to be changed? I'm terrible at the networking stuff and am not really sure where to start.

 

[old_school]

Well if you really want to know where to start I have about 6 books about the size of a diconary lol From my MCSE classes. You need a copy? JK yeah this was a great post with interesting concept. Problem seems that recompling the entire UO core etc would take a long time. I think focussing on KR is best.

 

[Mideon]

KR Support? Kingdom reborn? I'm not terribly interested in that as they've abandoned that client.

I am however interested in a 50% performance increase lol. As for the networking books, I can only imagine how much that weighs ;P

I am going to attempt to reconstruct this modification......so I'm just going to pose questions as I go. If anyone is interested in helping, by all means please do. This modification could be a huge boon to the community.

I'm using this code as an example: SocketAsyncEventArgs Class (System.Net.Sockets)

Firstly.....this code seems to rely upon a maximum number of connections....do we have to set this? Should it be dynamically set for the # of clients online? Do we just set it to some arbitrary high number? (likely not).

They also define a "receive buffer size". What should we seek to set this as for RunUO purposes? Should this be dynamic or static?

I see this code in NetState.cs:

private static BufferPool m_ReceiveBufferPool = new BufferPool( 1024, 2048 );

And this code in BufferPool.cs:

public BufferPool( int initialCapacity, int bufferSize )

Should this remain the same? Or change...?

Anyways...it's 1am. I better sleep before my brain implodes (more than it has). Will post back when I have more questions or some solutions. Cheers

 

[Kons.snoK]

so there should be no improv for mono users?