*plea* for Photon server on Linux / Mono .NET

mindlube

I have read the past threads about this, and I understand that you have a lot of native Windows x86 code in Photon, and there is no abstraction layer, and you started building an "express" version for Mono .NET and it was slow and sucky.

Among my Windows server gripes are
- bucketload of security holes out of the box
- OS uses nearly 1GB of RAM, when doing nothing
- OS license activation issues. dealing with cloud computing and instancing a Windows 2008 server from disk images is a freaking nightmare because of how windows activation works (in my experience)

The only reason I am here now is because I can discern that Photon has superior kit, better API, just a better product than anyone else. I looked at Electroserver, Unity3d multiplayer server, Foxserver, a few others. Photon came out on top in my evaluation, but I resisted it until the very end because I am forced to run it on Windows. I suspect you are losing customers and marketshare for the simple reason you don't offer a Linux server. Many users probably wouldn't even start to evaluate Photon.

But I bought my Photon license and am suffering through the Windows system administration and not liking it one bit.

Mono has come a long way in the past few years since your last experiment with it. There is an ahead-of-time (AOT) compilation mode; it's how Unity3d gets their kit to run so fast on iOS. It all gets compiled to native ARM code. So the excuse that was too slow on Mono .NET is really suspect anymore. Regardless, I would gladly sacrifice a little bit of speed for not having to touch a Windows server ever a gain.

Please consider this a plea to do the engineering work and make either a pure .NET version, or Linux port of Photon including your native code, or maybe with the --aot feature of Mono. Just anything so we don't have to run on Windows. Thanks for your consideration. I definitely hope to use Photon on future games.

dreamora

It was last evaluated last winter when Mono 2.10 already existed and the recent updates didn't change its performance that drastically.
its still a lot slower and it does not change the fact that OSX and Linux can not execute Windows native code applications at all (photon is no .NET technology, its a native code technology using .NET for scripting)

mindlube

*shrug* it's possible to write cross platform C/C++ code and or abstraction layers. The plea was directed to Exit Games, not to dreamora. Think big: Photon4 running on Linux. 8-)

dreamora

Right but the concept was dropped last year due to mono 2.10 still being significantly too slow to work in production usage.
if you want something as crap slow and scaleable as unity, why don't you use unitys networking itself? :P

duke

dreamora wrote:

Right but the concept was dropped last year due to mono 2.10 still being significantly too slow to work in production usage.
if you want something as crap slow and scaleable as unity, why don't you use unitys networking itself? :P

Now lets not go nuts. Unity's networking problems are due to a generalized, "cover-all" approach, combined with a concrete implementation that meant linking it to a particular version of Raknet, not Raknet itself, nor, I think, the mono wrapper.

Tobias

Please, guys. Calm down.
Mindlube: Thanks for the head up. It's good you tell us your wishes (and thanks for the kinds words about Photon in general).
I understand your points about activation and administration in Windows. I'm sorry you don't get along with it.

Still, Linux is currently no topic for us. We simply can't really support it. We want to get the Windows version right and best-performing and have clean client SDKs. This is never simply "done", so time is limited for Linux and others.

We don't rule it out by definition but it's simply a matter of priorities for us, sorry.

dreamora

duke wrote:

dreamora wrote:

Right but the concept was dropped last year due to mono 2.10 still being significantly too slow to work in production usage.
if you want something as crap slow and scaleable as unity, why don't you use unitys networking itself? :P

Now lets not go nuts. Unity's networking problems are due to a generalized, "cover-all" approach, combined with a concrete implementation that meant linking it to a particular version of Raknet, not Raknet itself, nor, I think, the mono wrapper.

The problem is not the used Raknet Version (unity is on 3.7 which is more than enough technically) nor the cover all approach at least not out of my view as its flexible enough thanks to set scope etc.
Its that Unity simply does not expose any control, especially not 'number of receiver threads' and 'number of sender threads', which is the prime reason why it does not scale. It simply can not do all sending and receiving on the same thread that handles the whole world simulation and physics without having to cut down one end massively and thats due to the lack of control ALWAYS the networking.

I personally would still be happy to get my hands on the 'not performant' mono build to do development on my MBP without firing up VMWare Fusion every time (though since I got 16gb ram in my 2011 mbp, I no longer have issues doing that either) but from what I recall it was mentioned to not even have been completed cause the performance profiling has shown significant performance deltas in the pure .net version between MS.net and mono and I guess it had to be cancelled at that point as it would have become a support nightmare if you get users switching between the OS and then realizing that their previously performant server environment from their windows dev machine basically dies on Linux with equal hardware thanks to Mono.

mindlube

Tobias wrote:

We don't rule it out by definition but it's simply a matter of priorities for us, sorry.

Thanks Tobias, I understand

mindlube

update: It doesn't work with LoadBalancing, but I put my Photon server on a private VLAN behind a linux firewall (as a bonus I run Redis on the linux box) 8-)
Works great and I dont have to worry about maintaining a Windows box with public IP.

Tobias

Hehe. Good work.
LoadBalancing uses some more ports, so that's most likely the part where that fails. Forward UDP 5055, 5056 and 5057 (those are Master, GameServer 1 and 2).