<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 26, 2015 at 9:41 PM, Edward Ned Harvey (mono) <span dir="ltr"><<a href="mailto:edward.harvey.mono@clevertrove.com" target="_blank">edward.harvey.mono@clevertrove.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> From: <a href="mailto:mono-devel-list-bounces@lists.ximian.com">mono-devel-list-bounces@lists.ximian.com</a> [mailto:<a href="mailto:mono-devel-list-">mono-devel-list-</a><br>
> <a href="mailto:bounces@lists.ximian.com">bounces@lists.ximian.com</a>] On Behalf Of Gelin Yan<br>
<span class="">><br>
>    A few years ago, I tried to port one of our server from .net to mono. At the<br>
> time. Mono 2.8 was just out. My server use socket (tcp almost) & thread<br>
> pools heavily.<br>
<br>
</span>You're making a blanket statement, "ready."   My blanket response is:  Yes.  Mono is ready.*<br>
<br>
* 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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 -<br>
<br>
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.  ;-)<br></blockquote><div><br></div><div>Hi Edward</div><div><br></div><div>    Thanks for sharing your experience. I am not saying .net is better. It can't be due to .net and mono are different things. A possible reason that people comparing these two frameworks is .net was there first.</div><div><br></div><div>   About bugs related to tcp&socket, I remembered there were two types of async styles: </div><div><br></div><div>1. use IAsyncResult </div><div>&</div><div>2.  SocketAsyncEventArgs (MS favors this style & claims it outperforms the first one).</div><div><br></div><div>Unfortunately, at the time, mono crashed each time after a few seconds of pressing tests. (IAsyncResult was slightly better, </div><div>it lasted a bit longer).</div><div><br></div><div>   I had no idea what happened and I ever posted a mail in the mail list, sure without any response.</div><div><br></div><div>   I guessed mono users might be more interested in use it for other purposes instead of backend.</div><div><br></div><div>Another problem is related to the gc. I have some codes crashed on mono due to OOM and I found out mono couldn't handle </div><div>that until I call System.GC.Collect() manually. The same, sgen was just out and failed on the tests.</div><div><br></div><div>   Due to I haven't seen any problem on .Net (It doesn't mean .net is bug free), so I considered mono runtime was not that stable for a heavy load environment. That's why I finally decided not to use it in production. I still keep an eye on mono due to I like C# and Linux too. I don't use BSD Like system, so thank for sharing about how mono works and what's problem on BSD Like OS.</div><div><br></div><div>   By the way, Do you have any info about tuning GC on mono?  When I searched "mono, gc tuning" on google,  only a few results came out and a little bit outdated.</div><div><br></div><div>Regards</div><div><br></div><div>gelin yan</div><div><br></div><div>    <br></div></div><br></div></div>