Migrate to Open.NAT and replace Mono.Nat #7140
Comments
rapgro
changed the title
|
The issue here is that Open.NAT requires .NET 4.5, which isn't supported under Windows XP. According to our website statistics* the number of XP-using visitors is about 25% of the combined Linux-using vistors, but we know from our package downloads that the vast majority of these are from people running a Debian-based distro. This means that we likely have more players running XP than Fedora. This is a poor trade-off from a pragmatic perspective: Improving OpenRA from "playable" to "fully distro-supported" for one group of players requires completely breaking it for an even larger group of players. * This is making the assumption that the website statistics reflect our player base, which probably isn't true. |
|
I am really tired of this Linux user market share discussion here especially since this is an Open Source project. @lontivero told us that a .NET 4.0 version is in the makings #5466 (comment) so I propose we just wait for that to happen. |
|
I'm equally tired of arguments driven by philosophy without consideration of the real world data. When a proposed change hurts users on one platform in order to improve things on another it would be irresponsible not to consider the relative number of users and hurt/win on each side. In either case it probably doesn't matter all that much what we do here, as it shouldn't affect the vast majority of our players who are running on modern OSes. It is vaguely tempting to drop the baggage of the legacy and unsupported Windows XP OS, even though it may drive off some players. |
|
@Mailaender, Open.NAT still requires 4.5. I didn't find the time to do it even when others have suggested the same that you because it clear that 4.5 is not the best for a real world project. Currently I am maintaining the project but I cannot do a major surgery. |
|
I don't know if it is possible, but maybe we could conditionally load .NET 4.5 code/assemblies as UPnP itself is pretty much optional. http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.runtimeenvironment.aspx has |
|
https://code.google.com/p/lidgren-network-gen3/ I discovered this a while ago, it's a popular networking middleware library that includes nat and connection management. Latency simulation and all sorts of other goodies. If you're looking to replace that nat stuff I think this would be a better longterm solution to networking in general. And it supports 4.0. |
|
Er that is it's easy to port to 4.0 just resyntax like two lines of code |
|
Looks like the project is still maintained at https://github.com/nterry/Mono.Nat (found via nuget.org) |
|
The nterry fork has a build problem cause of automake failure. Can you please provide a patch to disable / remove the anyhow b0rken mono-nat feature? As it turns out, this dependency is mostly needed to support XP users. Fedora should find another way to handle NAT issues, IMHO. |
|
You can still use older Mono.Nat versions with OpenRA. |
|
We discussed this again in IRC, and I suggested that we could modify OpenRA to (gracefully) disable the UPNP feature at runtime (or perhaps via a Fedora-specific compile-time patch) if the mono.nat dll isn't found. This would be a straightforward way to work around Fedora's strict restrictions that are blocking us from being packaged upstream. |
|
Sure, but Mono.Nat is very easy to package: https://build.opensuse.org/package/show/Mono:Factory/mono-nat |
|
Yep, but according to the earlier discussions the whole problem here is that Fedora won't accept dead/unmaintained libraries into their repositories, and also won't allow other packages to ship them directly. It looks like the only route to being accepted is to remove Mono.Nat by one means or another, which is pretty lame IMO. |
|
FuzzyLogicLibrary is also "unmaintained". Eluant and SDL2-CS are both forked and the latter one is rolling release. Mono.Nat is the least problem with the actively developed https://github.com/nterry/Mono.Nat fork. |
|
No. This bug is about Mono.NAT / Open.NAT only. From downstream (Fedora): https://bugzilla.redhat.com/show_bug.cgi?id=1166897#c7 As it turns out, the github tarball luckily includes LICENSE and AUTHORS. Unfortunately, this tarball does not provide any Makefile nor Makefile.in files, but Makefile.am only. I tried to tweak that somehow with autoreconf or automake, but without any success so far. Please help to use automake properly. Otherwise, I would suggest to leave mono-nat as dead as it is ("to not wake up any bad zombie"). For reference, I'll upload the spec file without any claim to fix FTBFS. https://raphgro.fedorapeople.org/review/mono/mono-nat/mono-nat.spec Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.JMcPjo
|
|
http://www.nuget.org/packages/Mono.Nat/1.1.3 states
as a feature. I think you should not complain here, but instead send a pull request towards https://github.com/nterry/Mono.Nat to get autotools support back or compile with xbuild. |
|
The BoltEngine fork builds fine with xbuild. This issue can be considered as fixed. |
I just tried. Open.NAT seems to heavily rely on the Task-based Asynchronous Pattern which is .NET 4.5 exclusive so this isn't easily done. At least for me. |
|
We will also loose Fedora support (which is still on ancient Mono 2.10) by the way if we migrate to Open.NAT as the .NET 4.5 async support was added in http://www.mono-project.com/docs/about-mono/releases/3.0.0/#profile, but I think it is about time for Fedora to wake up and not our fault that Mono is unmaintained there. |
|
That kind of defeats the purpose though, considering that the primary motivation for this change was as a prerequisite for an official Fedora package. I hadn't considered the effect of the .net version bump on older mono versions - so this is a bigger issue than just Windows XP, and this strengthens my argument above. |
|
Yeah, pretty ironic. I took a look at Open.NAT again, because for some reason Mono.NAT simply does not work for me anymore and I have no idea why. Even the detailed NAT logging isn't working so I have no means to debug it. However porting to .NET 4.5 and loosing support for older platforms is out of the question as UPnP is an optional convenience function although it significantly reduced support request https://github.com/OpenRA/OpenRA/wiki/FAQ#nobody-can-join-my-online-game. |
|
Mono 3.x is delayed for F22 → https://fedoraproject.org/wiki/Changes/Mono_3 So please make NAT feature as optional. Either by patch or GUI. Request to reopen this issue. |
|
It is already optional and disabled by default. Go to Settings - Advanced to enable it. |
|
The package for Mono.NAT builds just fine. Still waiting for a reviewer to approve it. So I should suggest to use Open.NAT since the futuristic F22 release and keep going with Mono.NAT for the moment. Does that sound reasonable for you? |
|
You are missing the point. We can't go with Open.NAT although it is superior in architecture, because we can't raise the .NET framework version to 4.5 without dropping support for legacy OS like Windows XP, Debian or latest Fedora. |
|
So this is CANTFIX and UPnP seems to be never supported properly in official Fedora package. |
|
I am astonished by the bureaucracy of the Fedora project. Looking at https://bugzilla.redhat.com/show_bug.cgi?id=1166897#c2 it seems to be worse than Debian. In contrast this is how it is done in openSUSE by the way: https://build.opensuse.org/request/show/133378 |
|
Gave it a try at #7692. |
|
Not technically possible and WONTFIX from Open.NAT, sorry. |
This issue has nothing to do with bureaucracy. Mono's just horribly slow and lazily maintained in Fedora, unfortunately. |
|
There are semi-official builds at Copr for both Mono 3 and 4. Maybe use those repos to provide official Fedora assemblies from OBS? |
|
OBS is not connected to COPR. Feel free to send a submit request to https://build.opensuse.org/project/show/games:openra though. |
|
IMHO using COPR in OBS is wrong. We should move the whole stuff to COPR then, at least for concerns about clean Fedora packaging. |
|
Ported to .Net 3.5 |
|
I made a new attempt: #10281 |
|
and another one: #11286. |
The project Mono.Nat is nearly dead.
Since mono-nat (respectively as the old name) is retired in Fedora and can not be wake up easily, I would like to know how far the plan is to migrate to Open.NAT as promised already in some other issue (number unkonwn?).
The text was updated successfully, but these errors were encountered: