Socket.*Async on Linux vs Windows


#1

I’m developing a multiplayer game in .Net and since I’m considering using Linux for the server I’ve been looking at Mono and .Net Core. Several benchmarks I’ve seen seem to suggest that .Net Core performs a lot better than Mono.

Up until now I’ve been using the BeginSend() and BeginReceive() methods that are leveraging IOCP on Windows, but they seem to not be available for .Net Core.

*Async methods are though - and since they’re also using IOCP on Windows I was wondering how they work on Linux? Do they use epoll() or similar? Has anyone tried using them in a multi-client setting?


#2

FYI, [those methods are coming back in .Net Core 2.0](https://apisof.net/catalog/System.Net.Sockets.Socket.BeginSend(Byte(),Int32,Int32,SocketFlags,AsyncCallback,Object)).

Yes, asynchronous socket methods use epoll on Linux and kqueue on macOS.


#3

When I say this, I say it with the greatest respect, so please do not assume I am trying to dissaude you in any way.

.Net is a technology that is best left on Windows. If you are dealing with cross-platform game development, you are far better off working with a different framework/language, and a game engine such as Unity or Unreal.

The problem comes from the fact that Microsoft never standardized the complete .Net framework for other operating systems. Things like Winforms will simply not work at all, and there is no DirectX support off of Windows whatsoever. Everyone else outside of Microsoft uses Vulkan or OpenGL. While that situation might change with .Net Core at some time later, we have to work with what we have now.

I recommend that you consider C/C++ as you will be rewriting less code (the language is far more supported), and one of the two game engines I mentioned, which depends on your project. Both have been ported to multiple operating systems and should ease the work of graphics.


#4

Thanks - I’m actually using Unity on the client side, but have decided to write the server in C#. C++ would probably allow me to write better performing code, but it would take a lot longer to get anything done - especially since I’m an experienced C# programmer and only have limited experience with C++.
I don’t have a lot of dependencies - pretty much only file and networking IO in addition to a DB I haven’t decided on yet (Using SQLite at the moment because of the ease - will probably move to MySQL/MariaDB or Postgres).


#5

Since you are using C# for the server, I am assuming Windows as the server. No offense intended, but Windows servers are a pain in the butt. You end up resetting them at least every two weeks - but that is just my personal opinion.

I’ve written code in all three languages. =)

If this is a FOSS/non-profit venture, I might be persuaded to lend a hand, if you were willing to let outsiders take a look, of course. I prefer to stay out of for-profit ventures when chatting on programming boards. Too many legal complications regarding remuneration and so on.

At the very least, I might be able to help you get rid of some bottlenecks in your C#, or help with interfacing to third parties, as you can use C/C++ libraries inside of C# with a little tinkering. Anything I’d offer you would be a suggestion only. It’s your project.


#6

Thanks for the offer:) But it’s not open source, and hopefully not non-profit either, although the game is still a long way from being something I can charge for:)
Currently I’m using .Net 4.6 on Windows Server 2012 (cheap VPS hosting) and I haven’t really had any problems with the OS, but I’ve been considering Linux when I have to move to dedicated hosting because of the cost and licensing issues - Windows Server is only an extra $25 per month on typical hosts but I might have to buy or lease an external connector license (I’m not sure if it’s needed). That’s $2000 or $60/month if leased. A saving of $85/month could buy me some better hardware if .Net core on Linux turns out to be worse in terms of performance than .Net on Windows.


#7

That’s cool. If the situation changes or you are willing to post a code bit here for help, let me know.

I’m not “dissing” Microsoft when I say that the reason I commented about Windows server is a bit of bias on my part. I make no bones about that. I have had very few positive things to say about Windows Server, as the cost per seat quickly becomes prohibitive and they need frequent resets compared to Unix. It’s easy to drop $10k per server for commercial licensing. I’m not saying that Linux is not a perfect solution either, just a cheaper one. The fact that many server versions of Linux have adopted Systemd with its unstable API ends up being a maintenance problem.

Frankly, given the installer problems I have had with .Net Core Preview on Windows, I do not expect that Linux will be any better, although I admit I have not tried it on Linux. If Microsoft can’t even get it to uninstall cleanly, then I do not expect Linux to have decent support as Microsoft is the reference implementation.

To be honest, while I like to chat about it, I’ve actually started moving away from .Net as deployed apps in MSIL are easily decompiled and reverse engineered. I ran tests for work reasons. Like Java, it’s fine on the server side, but not really ideal when trying to protect trade secrets in client side code. .Net obfuscators only go so far, can cause runtime issues, and are costly. I much prefer native code. I’m not saying you can’t reverse engineer that either, but it is a magnitude of order harder. With .Net MSIL, you just run it through something like ILSpy, and you have almost the original code in less than 5 minutes. Even if it has been obfuscated, it would take longer - but still not that hard.


#8

Yeah CALs really become pricey - especially if you’re also running SQL Server and other Microsoft products. And if you take the bait and use volume licensing you also have license audits to deal with. Luckily I won’t be needing many “seats”. Worst case scenario is that I would have to purchase External Connector licenses.
I can’t recognize the problems with stability though - in the places where I’ve been working lately and their clients we’ve have had a pretty good experience with Windows Server.
If I were to go with MS then I would just use the .Net framework and not bother with Core.
And yeah decompilers are a bit problematic… I’m not too worried about piracy since the game is SAAS but it would be really easy to make a bot for a Unity client - at least until they enable IL2CPP for Windows Standalone builds.


#9

I’m confused, you say people shouldn’t use .Net and instead should use an engine that uses .Net or an engine that supports .Net (in both cases in the form of Mono)?

That’s why it’s called a preview: because it’s not done yet and likely still has significant known issues. Maybe you should try it again now?

If this is your main issue with .Net, then you might want to watch CoreRT, which compiles IL into native code “ahead of time”. Though I believe it’s not production ready yet. And I wouldn’t expect desktop applications to run on it anytime soon.


#10

No need for confusion. =) It is simply an opinion.

It’s based on the fact that .Net is not standardized for cross-platform development. Sadly, Microsoft never standardized the language beyond version 2, and even then, Microsoft only offered an incomplete standard for ECMA/ISO to consider.

When you are working across platforms, C or C++ happens to be a better choice, because it is standardized, and no one can assert patent complaints against either. The same cannot be said for C#, Java, or any other defacto language. Just ask Google about Java and Oracle’s lawsuit - previous agreements notwithstanding. Microsoft has promised not to assert patents on Mono, but Sun had agreements with Google before Oracle bought them out - so patent promises do not mean much, in my opinion, without an irrevocable RAND grant.

As for .Net Core preview, it was not the preview, it was the installer for it that had problems. If you don’t uninstall it before VS 2015, it won’t uninstall. That has nothing to do with the fact it is a preview, but everything to do with dependency checking. Other versions of VS had similar problems in the past.

CoreRT is a new project in the early stages of development. It could literally be years (or never) before it is production ready. Other projects like Microsoft’s .Net Native have severe limitations, especially since it is Windows 10 only.

The other reason for moving away - again - is standardization and portability. No matter how you slice it, C# is not portable. Even with Xamarin, it is missing several parts of Microsoft’s reference version. Microsoft does not protect or license reimplimentations of Forms or WPF. Now that APIs are protected under US law, implementing them without a RAND grant from Microsoft could end up in a lawsuit.

It’s far easier to port code that is not written in a proprietary language. C/C++ are available for virtually every processor and OS.


#11

My confusion was caused by the fact that you recommended Unity, which is based on mono and Unreal, which supports mono, while saying everything related to .Net should be avoided.

Yes, but work is being done on creating an ECMA standard for C# 5.0 (and more current versions will follow).

I’m not a lawyer, is this promise not enough?

And about Java: what agreements are you talking about? The Wikipedia article about it does not mention any, but it does say:

Google negotiated with Sun about possible partnership and licensing deals for Java, but no agreement was reached.

The installer is part of the preview, so I think it should be considered a preview version too.

That’s wrong. From a certain point of view, sure, C# is not fully portable, because some parts of .Net Framework are not portable. But from another point of view, C# on .Net Core is a portable open source language. It doesn’t have everything, like a GUI library, but C or C++ don’t have one either (certainly not as part of the standards).


To sum up: if you consider only ISO or ECMA standards, then yes, C# is less standardized than C or C++, because the .Net base class library was never standardized and because the ECMA C# standard is outdated.

But when it comes to portability, C# is pretty much on the same boat as C and C++. All of them have open source implementations available for common architectures and OSes. And all of them have a “standard” library that’s available on all supported platforms. (And the .Net Standard contains more functionality than the standard libraries of C or C++.)


#12

Unity is actually written in C and C++ as far as I am aware. Whether that is still true, I have no idea.

I never said .Net should be avoided.

I said I avoid it for reasons of cross-platform compatibility and legal considerations. In the end, what you or anyone else decides to use is entirely your concern. It’s a judgment call.

I freely admit that I am not overly fond of it, but I have my reasons. I have spent considerable time with it, and have even found some bugs in Microsoft’s version. You also have the fact that since the reference version is Windows only - it takes time for Mac and Linux to “catch up”.
That might change, but at the moment, the reality is that a large portion of C# is simply not portable from Windows to other systems. C# was never designed or intended to be cross-platform. I do not recommend it for cross-platform work because of code maintenance.

Defacto languages make cross platform work harder. They often make syntax changes between major releases, and then depreciate support for the existing runtime - necessitating large and often unnecessary rewrites. Java is an example, and so is C# to a lesser degree. It makes the job of maintaining codebases that much more time-consuming and expensive. Standardized language compilers can generally support multiple standards. GCC for example can compile C90 code if you want it to.

That’s good news, but given Microsoft’s lack of enthusiasm for standards, I’ll adopt a wait and see attitude. I do not expect much.

Yes and no. Now that APIs are considered intellectual property, the answer is probably not. I do not doubt Microsoft’s good intentions, but I also do not doubt that they would use any means they can to absorb or remove a competitor -as Oracle tried to do when it tried to force Google to abandon its Java clone.

Sun had an informal arrangement, agreeing not to assert patents against Google because Google actually increased the use of Java - and thus its overall value. Sun seldom asserted patents because doing so is bad for business in the long run.

I disagree. Microsoft’s installer architecture is independent of what is being installed. If they can’t simply delete files and registry keys in the proper order, then that is a serious problem. One of Windows’ long term problems that does not go away is the potential registry corruption. The Windows registry suffers from a design flaw known as “bit rot.” Microsoft knows this - but has never taken decisive steps to alleviate the problem.

How many times have you had to manually delete keys or reinstall Windows because of it? I have lost count. Much of that and installer problems could be avoided if Microsoft redesigned the registry to be local to each user instead of system-wide.

Here is the way I see it. If you have a language like C#, where the reference standard does not separate what is core to the Framework and what is not, then how do you write portable code? You can’t. It has gotten better , but it still stands to reason that C++ and C are clearly defined as to what is part of the language and what is not. They are designed to write portable code. C# is still trying to find its legs.

It is true that C and C++ do not define a GUI. Why should anyone - C# or C++? It’s an unrealistic expectation. GUIs are not portable by nature because vendors cannot standardize on a single one. The closest anyone has ever come to a portable GUI would be window managers (usually written in C) on top of X11. The next closest effort are frameworks like Qt.

I strongly disagree with that statement. If you want to discuss it further on another thread, we can go over some examples. It is really off topic here. We have already wandered too far as is.

That again is a matter of design necessity. How much crap do you really need to cram into a “standard library” before it becomes redundant to the purpose of the language? C and C++ (debatable IMHO) were designed specifically so that the standards were minimum and that external libraries were easily linked for reusable code. It leads to fewer bugs in the language core.

Like it or not, in the real world, C and C++ libraries significantly outnumber and outclass (no pun intended) C# codebases. Linking C to C++ is a snap. Linking C# to anything other than .Net is a massive PITA - even if it is Microsoft’s own COM based libraries in the Windows OS.

It is the number of contortions that you have to go through - plus the inherent insecurity of MSIL that have made some, including myself reject .Net for long term projects.


#13

That used to be true with mono. Now it’s the other way around: .Net Core (on all three OSes) gets new features first, and they are later ported to the (Windows-only) .Net Framework.

MS takes backwards compatibility very seriously. I’m not aware of any syntax changes in C# that ever required a rewrite.

Library changes in when switching to new frameworks are a different matter, but hopefully that will be better going forward, with the introduction of .Net Standard.

New versions of the C# compiler should be able to compile old code too. And you can also switch them to compile using an old version of the language.

By targeting the .Net Standard. It’s a clearly defined API set that every implementation has to support. That separates what is portable and what is isn’t.


#14

Yes, Microsoft does take it seriously. What I said was:

Java is known for this - rendering entire codebases obsolete without a rewrite, even if the official version is cross-platform.

C# is not quite as bad, but it does require minor changes in older code. All in all, I give credit for Microsoft keeping it to a minimum on Windows, but it is still there. Setting that aside, when you look at the whole C# ecosystem: Windows, Linux, Mac and mobile - there is considerably more variance. That wide variance becomes the problem that I was referring to.

That was only introduced in September of 2016, and needs work, so you are making my point for me.

You are right. C# is getting better - but developers have to work with what is here now, not what might come out later. As a rule of thumb, anything that has not been released might as well not exist. What something is claimed it will be is not the same as the release version.


#15

Hey Jesper! I’ve been playing with .NET Core for a while (on both Mac and Windows), and my experience has been that it is quite good already. I’d recommend trying some code and comparing it against Mono. The async performance I’ve seen so far has been great.

Cheers!


.NET Foundation Website | Blog | Projects | Code of Conduct