[Mono-list] high performance Unix-based TCP socket server
Edward Ned Harvey (mono)
edward.harvey.mono at clevertrove.com
Mon Oct 5 11:03:26 UTC 2015
> From: mono-list-bounces at lists.ximian.com [mailto:mono-list-
> bounces at lists.ximian.com] On Behalf Of hlavko
>
> do you recommend the Mono for high performance Unix-based TCP socket
> server
> with thousands of concurrent connections?
Let us know what you find.
> I already found and tried high performance implementation using
> SocketAsyncEventArgs
The official documentation is here:
https://msdn.microsoft.com/en-us/library/system.net.sockets.socketasynceventargs(v=vs.110).aspx
> However, I am little bit sceptical about other possible drawbacks:
> 1. Not sure if the Mono implementation of the SocketAsyncEventArgs is fully
> replacable to .NET implementation on Windows. Is it ready for production in
> the current state?
Judging by the existence of SocketAsyncEventArgs in MSDN, apparently Microsoft considers it production ready. To see if there are any known differences between the mono and ms implementations, you check the class compatibility pages:
http://mono-project.com
Documentation > About Mono > Class Status (http://www.mono-project.com/docs/about-mono/class-status/)
It's a little annoying the way the class assemblies are broken up, you don't really know if you should start by digging into System.Net, or something else. Today, the correct answer is go into System, and then System.Net.Sockets, and you find SocketAsyncEventArgs. It looks like mono's implementation does have a few known issues, so you'll want to pay attention to those. I'm not sure how to tell you to find more info about the known issues - Look in the mono source for comments on the failing items (sometimes it's just a particular argument of the method is unsupported, because there's no such thing in Linux, or something like that). Maybe search bugzilla https://bugzilla.xamarin.com
> 2. Not sure if this is still issue with last versions but I found many hate
> comments targeting Mono performance. Is Mono comparable to other high-
> level
> languages like Java/C++/.NET in the question of performance?
Ignorance is rampant on the Internet. All of the above perform excellent - but there are differences. I have benchmarked many different operations in mono, .Net, java, and python. I have found that each one outperforms the others in particular ways. The only way to know is to pick a specific operation you care about, and then benchmark it. All the results vary from platform to platform, version to version. Don't forget to build "Release" mode, to enable compiler optimizations. And if you want to squeeze more performance out of it, you might do an AOT fully optimized build for the platform that you care about.
The conclusion I've reached is that there is no general winner or loser. There are only specific winners and losers on specific things.
> 3. You know it looks like there is not many people which are going this
> server way with Mono. Also we want to focus primarily on business logic
> rather then polish and hack core server functionality. So, is it possible to
> rapidly prototype relatively stable framework around Mono or we will need
> to
> solve many hidden secrets and issues?
This is what we do at my work. We use SslStream to make mono a server, listener. We're using TcpListener. I'm not sure what/if there are advantages to SocketAsyncEventArgs, but it sounds like your requirements might be higher than ours. Yes, there are some issues, but we got over them, and I suspect you probably can too.
The other alternatives you mentioned were Java and C++. I would anticipate java is probably less ready than mono for this purpose, because a java server is usually wrapped up in something else like apache or whatever, which handles the lower level socket stuff, while C# is often used for server stuff - at least on Windows Server. So mono's readiness really comes down to the question of how complete mono has implemented the .Net API. And I would anticipate this is probably already done excellently well in C, but a lot more effort for you to use. So it's really up to you to choose.
> 4. Looks like the future of Mono is in crossplatform mobile market not
> servers. (we are looking forward to next few years)
Most focus is definitely on mobile. But everything else is getting attention too.
More information about the Mono-list
mailing list