Port Forwarding
-
Agree 142%
Glad that the issue was picked up to the devs.
-
Allow from-client to-server remapped, but check whether forwarded port is accessible.
Traffic of each client arrives at the server with a possibly remapped source port. But the client informs the server (as part of the payload) of the source port it actually uses locally (typically 2935). If the server would reply not to the remapped source port, but the actual one, a client without proper port forwarding would be unable to join the server.
Personally, I see more in reporting the connection status of clients in the UI. If the names of the clients in the COMM window were colored, e.g. green for all p2p connections established, orange for at least one peer-to-peer connection routing through host, and red for failed connection with another client (if that is still possible), at least the users would know what’s wrong. All green would be perfect, some orange would be functionally okay although perhaps laggy, and one or more reds would be a no-go. Red users might even be refused to join a mission. Being unable to connect might be a mystery to most users.
Could you do me a favor and summarize the desired behavior in a bullet-point list? However, both from a client to server and a server to client point of view. And - if needed - as well from a client to client point of view. All of these in combination with and without the “allow dubious” and “server hosts all” options set/not set.
I would forward the info to Mike, and then will try to work with him on the implementation.
Thanks a bunch!
-
Can try…
always:
ignore source ports when connection initiated by clientdubious:
ensure port forwarding presentnon-dubious:
enough for client to communicate with server and server only, though allow mesh participation
server hosts all:
disable c2c mesh (?) -
@sthalik: I expect you need to spend a few more words to convey your thoughts fully to a programmer.
I’d like to discuss things a bit more first.
The concept of the client initiating communications with the server using source port 2935, then that source port being remapped by NAT, say to 1234, then the server responding not to 1234, but to 2935, feels funny. Aren’t we violating some rules when we do this?
Also, it’s still no guarantee that things will be 100%. At least, I believe some NATs are so restricted, that when 2935 is used in conjunction with the server’s ip-address, it can’t be used by other ip-addresses (i.e. the other clients). However, this class of NATs will be a lot smaller than the “I have port forwarding for 2935, but will still remap outbound packets” class.
I’m not sure what the relevance is of Server Hosts All. I believe that has nothing to do with connectivity, just with who controls units in 3D?
Last but not least I wonder whether AllowDubiousConnections should be an issue. If we design a superior mechanism, can’t we forget about this option?
-
source port being remapped by NAT, say to 1234, then the server responding not to 1234, but to 2935, feels funny. Aren’t we violating some rules when we do this?
No. With dubious=0, it checks the port for equal to 2935, and disconnects otherwise. Of course, it -still- has nothing to do with TCP/IP by doing so.
Last but not least I wonder whether AllowDubiousConnections should be an issue. If we design a superior mechanism, can’t we forget about this option?
This requires BMS to be robust enough not to cause instability with severe network issues, such as hosting 50+ people on flaky connections, all flying one campaign and shooting at each other.
-
source port being remapped by NAT, say to 1234, then the server responding not to 1234, but to 2935, feels funny. Aren’t we violating some rules when we do this?
No. With dubious=0, it checks the port for equal to 2935, and disconnects otherwise. Of course, it -still- has nothing to do with TCP/IP by doing so.
I assume you mean the disconnecting based on source port (AllowDubious=0), when you state it has nothing to do with tcp/ip? Please keep in mind that this option wasn’t meant for public use IIRC. It was just implemented to ensure proper conditions for MP beta-testing.
The idea of having the server respond to 2935 instead of the possibly remapped source port ensures that 2935 is accessible to the server. However, it might still be inaccessible to other clients (i.e. symmetric NAT). The “ultimate” test would be to have all the clients report what the status of their part of the mesh network is, and display messages and/or kick users based on that information. The server could maintain an array of connection statuses of clients to other clients. It’s not trivial what to do with that information. E.g. when client A connects that can only connect to the server, and not to any of the existing clients, not only will this client A list all his statuses as “not connected”, or “routing through host”, all other clients will have one connection status read “not connected”, or “routing through host”, namely the connection to client A. Kick A because overall status was OK before he connected? What if A connected as the first client? No other clients could join then.
I think a system where everybody is able to log on to the server, but only well-connected clients are able to join a mission, is ideal. Of course, the UI should indicate in some way what the interconnection status of each client is.
-
when you state it has nothing to do with tcp/ip? Please keep in mind that this option wasn’t meant for public use IIRC. It was just implemented to ensure proper conditions for MP beta-testing.
1. Yes.
2. Too bad Archer and friends are using it then…I think a system where everybody is able to log on to the server, but only well-connected clients are able to join a mission, is ideal.
Ideal is a system that is robust enough to deal with flaky client connections, IMO.
Of course, the UI should indicate in some way what the interconnection status of each client is.
1+
-
I think a system where everybody is able to log on to the server, but only well-connected clients are able to join a mission, is ideal.
Ideal is a system that is robust enough to deal with flaky client connections, IMO.
Yes, agreed, but if flaky connections were good enough for a perfect MP experience, we wouldn’t need good connections… So I think that’s unrealistic.
On the other hand, BMS now supports “routing through host” reliably. That creates the opportunity to define the “minimum network quality” of client connections. I.e. set this option (in BMS.cfg) to “high”, and only well-connected clients were allowed to join a mission, set it to “medium”, and clients that are routing through host could join, set it to “low”, and everybody could join. “High” would then be similar to disallowing dubious connections, but with the added flexibility that clients are allowed to use remapped source ports.
-
Flaky connections shouldn’t destabilize the host… That’s ideal. At least not cause dedicated server crashes.
-
Could you do me a favor and summarize the desired behavior in a bullet-point list? However, both from a client to server and a server to client point of view. And - if needed - as well from a client to client point of view. All of these in combination with and without the “allow dubious” and “server hosts all” options set/not set.
I would forward the info to Mike, and then will try to work with him on the implementation.
Thanks a bunch!
About the “Host all Units” option :
–----------------------------------------------------------------------------------------------------
First and foremost, a few definitions about AI management after Deagg :When a battalion/flight is deagg by a player, it’s controlled according to 2 different statuses “Owner” and “SimOwner” for himself and for all MP players (Camp Label must be activated to see these statuses).
-Owner => control of a unit (complete battalion/flight => controlled as unique objects (2D combat control : not much impact on CPU usage and even less impact on bandwidth usage)
-SimOwner => control of all vehicles (tank SAM launcher, infantry, truck, F16, MiG-29, etc.) part of a unit “battalion/flight” => tens of vehicles controlled (3D combat management, for each individual vehicle : large impact on CPU usage and direct impact on bandwidth usage)
-Local => controlled
-Remote => not controlledExamples :
“Owner:local SimOwner:local” => seen from an individual player, it means that this battalion/flight is controlled as a unique object, BUT ALSO that each vehicle in this battalion/flight is controlled by the same individual player
“Owner:remote SimOwner:remote” => seen from an individual player, it means that this battalion/flight isn’t controlled as a unique object AND that each vehicle of this battalion/flight isn’t controlled by the same individual player
“Owner:local SimOwner:remote” => seen from an individual player, it means that this battalion/flight is controlled as a unique object, BUT each vehicle in this battalion/flight is not controlled by the same individual player
“Owner:remote SimOwner:local” => seen from an individual player, it means that this battalion/flight isn’t controlled as a unique object BUT each vehicle of this battalion/flight IS controlled by the same individual player
“Host all Units” disabled :
- if the host deaggs a battalion/flight : from his point of view, he will see it as “Owner:local SimOwner:local” and the other connected players (clients) will see it as “Owner:remote SimOwner:remote”
- if a client deaggs a battalion/flight : he will see it as “Owner:remote SimOwner:local”, all the other clients will see it as “Owner:remote SimOwner:remote” and the host will see it as “Owner:local SimOwner:remote”
This means :
- the host always controls the battalions/flights as unique objects (“owner” will always be “local” for the host) -> very little impact on the CPU and bandwidth usage.
- therefore, the clients never control the battalions/flights as unique objects (“owner” is always “remote” for the clients)
- On the contrary, if a player (host or client) deaggs one or several battalions/flights, he will have to control each vehicle in this battalion/flight (=> SimOwner:local) for all other connected players, which has a direct impact on this player’s CPU and bandwidth usage, whether he is host or client. It depends on the number of battalions/flights he has deagged and on the number of vehicles in these battalions/flight. This means he might have to control tens of objects, all tracers shot, all missiles trajectories => try to imagine a client with a small CPU and bandwidth who has to host all this for all other players … some data will certainly be lost in MP
“Host all Units” enabled :
- the battalions/flights deagged by any client will always be “Owner:remote SimOwner:remote” for the clients
- therefore, these battalions deagged by these clients will always be “Owner:local SimOwner:local” for the host
this means:
- it’s always the host who’ll control all battalions/flights deagged by the clients : therefore, he will always be “Owner:local SimOwner:local” => huge impact on the CPU and bandwidth usage, especially upload.
- the clients don’t control anything, even if they are the ones who deagg the battalions/flights => very low CPU and upload bandwidth usage. But, they must have a stable and large download bandwidth to receive all data sent by the host
Check all the subject i wrote here : https://www.benchmarksims.org/forum/showthread.php?5271-quot-Host-all-units-OFF-quot-vs-quot-Host-all-units-ON-quot-gt-CONCLUSION&highlight=host%27s+units
BB
-
As my original post got jumped on ill try again.
“Unless your hosting you should not need to forward any ports.” OK forget about hosting for now.
A: Statment expressing a desirable outcome or status.
B: Also my current router state/setup.
With my current ISP provided “2WIRE” router (previous DLink I cant get working with this ISP) If I set up port forward
on 2934-2935 then FoL see me as a dubious connection. So can’t connect.If I then set up a DMZ I connect, but my local area network is screwed as my PC now has an external IP.
My solution was/is no port forwarding & no DMZ, apparently thanks to update 4,5 or 6.
Im shore this situation would horrify Arty and any other purist and may not be Ideal but it works with our daily group of 4-8
& weekends of over 20 in the air.So any efforts to drag this old girl (Falcon) into the twenty first century is appreciated.
Regards
-
You can always use a PC router with Linux/FreeBSD and set up static port forwarding for the few select ports… Raspberry Pi as a router is very cheap.
FOL guys are stubborn and their networking knowledge is lacking. ‘Just set up DMZ’, as if that’s what DMZ meant wrt network topology…
-
With my current ISP provided “2WIRE” router (previous DLink I cant get working with this ISP) If I set up port forward
on 2934-2935 then FoL see me as a dubious connection. So can’t connect.That’s probably due to the fact that your router changes the source port (2935) of your outbound packets, even though you got port forwarding setup. Most consumer routers will conserve the source port if there exists a corresponding rule for inbound packets.
If I then set up a DMZ I connect, but my local area network is screwed as my PC now has an external IP.
I’m sure you know, but DMZ is a really bad idea. It exposes your PC to the internet, and makes you vulnerable for all kinds of attacks.
My solution was/is no port forwarding & no DMZ, apparently thanks to update 4,5 or 6.
You probably got the “routing through host” to thank for that. It didn’t function as it should at first, but that was fixed in update 4 or 5. If you start BMS with the “-mono” command switch, it creates a log file in ./user/logs. Not fun reading, but if you search for “routing through host”, you might confirm my suspicion.
-
Another benfit is a friend staying here can also fly online.
So far 4-8 clients with no show stoppers, will be watching closely this weekend when our numbers should be in the 20+
We have a server with gigabit connectivity but the box does need more horsepower.
-
shadow probably u r talking about local lan?
-
shadow probably u r talking about local lan?
No
-
Let’s try it once more as suggested by Ripley, to make more clearer the port mappings:
Dubious on/off, tautologically speaking
- Client X:Y connects to S:T
[dubious=1]
- S:T queries X:2934[4-7] for redirect status
- ACK if redirected, NAK otherwise
[dubious=0]
- ACK
This is disrespective from the current wrong behavior where Y must equal 2935 or the connection won’t be accepted.
Is that explanation good enough?
-
I thought of an issue with this approach. Ideally, clients should be able to connect without port forwarding setup at their side. Sort of the Holy Grail. This requires NAT traversal to establish the peer-to-peer connections between clients, but that’s already in place (in RAKNET). However, by having the server query port 2935 on the client side, you basically require port forwarding on the client side. Of course, if things depend on the parameter AllowDubiousConnections, this could be acceptable.
-
I’m sure you know, but DMZ is a really bad idea. It exposes your PC to the internet, and makes you vulnerable for all kinds of attacks.
Not correct, you always be protected by the default Windows (software) Firewall
BB
-
@Bad:
Not correct, you always be protected by the default Windows (software) Firewall
BB
makes you more vulnerable than you would normally be, considering its basically telling the router to stop all the various filtering it normally does.