[Mono-dev] Is mono ready for backend deployment?

[Edward Ned Harvey (mono)]

> From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-
> bounces at lists.ximian.com] On Behalf Of Gelin Yan
> 
>    A few years ago, I tried to port one of our server from .net to mono. At the
> time. Mono 2.8 was just out. My server use socket (tcp almost) & thread
> pools heavily.

You're making a blanket statement, "ready."   My blanket response is:  Yes.  Mono is ready.*

* Going into a little more detail, no matter what, you must acknowledge that there are major architectural differences between Windows, BSD, Linux, etc.  Mono and .Net are enormous, and there *are* differences, and there always will be.  So you can never say "It's ready" meaning 100% compatible and bug-free.  (Guess what, in my experience, I've found about equal numbers of MS bugs and Mono bugs.)  What you can do instead, is to develop and test on multiple platforms, and anyplace where something is different, solve the problem.

I personally develop a commercial product, that has windows/mac/linux client and server components, doing a lot of SSL communications over unreliable network connections.  We develop code on .Net, test on mono, and for the non-GUI server backend stuff, around 99% of the code simply works without any modifications.  We run into occasional snags, like, managing the SSL certs differently on each platform, and privilege escalation to bind port 443, and stuff like that, which are intrinsically different on different platforms.  FileSystemWatcher works perfectly on windows & linux, but the BSD implementation of kevent/kqueue is fundamentally flawed and will never work, so FSWatcher simply doesn't work (reliably) on macs.  We had to get Xam.Mac and use FSEvents.  Also, mutexes and inter-process signalling, and file locking - we've had to do work in order to support multi-platforms, due to fundamental differences in the different platforms.  It's impossible for mono (or anything not running on windows) to implement file locking as designed in the MS API.  Differences of filesystem charset, path separator character, etc.  Dramatic difference in RSA key generation, and absent support for EC keys...  To name a few of the areas that are different between .Net and mono.

You might be like I was originally - assuming .Net was better - but I have found in many regards, neither .Net nor Mono is better.  They each are better in specific ways, and the number and severity of differences doesn't add up to a clear "one is better."  For example, I found that .Net's implementation of RSA key generation greatly outperforms mono's implementation, but mono does a lazy key generation which means 99% of the time you can completely skip key generation (depending on your usage model).  And there's a huge list like that.  Dramatic performance differences in SHA and stuff.

We make heavy use of tcp sockets and threadpool, as well as manually managed threads.  Threadpool:  No issues whatsoever.  Tcp:  the timeout setting doesn't work unless you set it at the right time ... I forget ... after the connection is established?  I forget, but I could look it up.  We decided to manually manage the tcp timeouts.  (Not difficult; every time we create a TcpClient, create a timer, and when we receive bytes, consider resetting the timer).  Whatever you do, frigging *don't* call Dispose on a SslStream.  On heavily used linux servers, we had to increase the number of tcp sockets in kernel - I could look up details if needed - 

So I would say ultimately, Tcp:  Barely any issues, which were easily managed.  Unfortunately, SslStream was (and still is) not easily managed, if you happen to want a mono SslStream server.  But you didn't say SSL; you said TCP sockets.  ;-)