This might have to wait until the devs work on the internal logic for multiplayer as per fff-145.
I got my group to go back to playing the game to try and get all the achievements but for some reason we can only play somewhat smoothly on /c game.speed = 0.1.
Bug report is below but quick question: Do commands like /c game.speed = 0.1 disable achievements (i think they should because it made it a lot easier to clear biter bases)?
I narrowed the issue down to 1 person. I then hosted a server with just he and I. Latency was set to 600ms (ping said to set it to 350ms during a different playthrough about an hour before).
Even with this insanely high latency setting, we still had terrible stuttering. Ping showed that the actual latency was about 500ms but that's still below the server latency.
His connection is 1Mb down and 0.5Mb up (which is a lot better than the bandwidth requirements given by Korvax in my previous thread -- viewtopic.php?f=49&t=23353#p153650).
After some digging, we figured out that his router was dropping packets (about 15% packet loss). After a lot more digging, we figured out that factorio was trying to send about 290 KB/s (which is more than double his limit).
TL;DR
Guy has 15% packet loss at his router so less than 1ms of added latency 15% of the time.
Game should be sending 5KB/s + (5*0.15) = 6 ish KB/s but it is actually trying to send 290KB/s as diagnosed by successfully sending 29KB/s at /c game.speed = 0.1.
Stats gathered on unmodded fresh game of 0.13.3 and verified again today with 0.13.4.
[0.13.3] Unreasonable bandwidth expectations (Packet Loss)
Re: [0.13.3] Unreasonable bandwidth expectations (Packet Loss)
If the person really has 15% packet loss then he's completely out of luck.
No coding we do can handle that amount of packet loss at any reasonable speed.
It's not just "On I have 5 MB of download speed but - 15% because of packet loss" it's *far* worse than that and typically drops to the KB/s range or less.
No coding we do can handle that amount of packet loss at any reasonable speed.
It's not just "On I have 5 MB of download speed but - 15% because of packet loss" it's *far* worse than that and typically drops to the KB/s range or less.
If you want to get ahold of me I'm almost always on Discord.
Re: [0.13.3] Unreasonable bandwidth expectations (Packet Loss)
It's normal behavior for UPD to drop packet when there is congestion on the wire, unlike TCP who have control congestion feature.
This mean you are sending faster than the other side reading the data stream. UDP didn't have control congestion feature by default but can be implemented on software level. Maybe that reveal an abscence or a bug into the throttle transfer system.
This mean you are sending faster than the other side reading the data stream. UDP didn't have control congestion feature by default but can be implemented on software level. Maybe that reveal an abscence or a bug into the throttle transfer system.
Re: [0.13.3] Unreasonable bandwidth expectations (Packet Loss)
Thanks for the info all.
For some reason Overwatch and WoW work fine for him but they both use TCP. We can see his router sending responses that the packet was dropped with wireshark and then his computer resends the packet. Even if this happens 3 or 4 times that's only an extra couple of ms since his router is trash. This kind of recovery isn't possible with UDP (even with Reliable UDP).
I still don't see why the game uses UDP. Even Windows supports the TCP_NODELAY flag which basically translates a TCP connection (with all it's glorified automatic reliability) into a UDP pipe. The largest downside is the time the handshake takes to complete which is pretty much negligible over a few seconds of gameplay. Since you're already using NAT punchthrough it might be time time to try out TCP if your backend is easy to change (I have no idea how encapsulated your networking is).
In the first example, the packet might have been dropped only 3~5 ms away from the previous device thus adding less than 20ms (all handled with 0 application code).
In the second example, neither the client nor the server are aware of a dropped packet until the full round trip time (1000ms in this case). The server then has to tell the client that it has dropped a packet (application code) and the client has to send the packet again (application code and another 500ms). Lets not get into if it's dropped again because this gets messy in application code.
TL;DR
You're right that there's no level of application code that could fix this problem but it's only a problem because of the choice if UDP over TCP (with TCP_NODELAY). Since a lot of work has been going into the multiplayer codebase recently, please (please please please) have a go with TCP (with TCP_NODELAY).
Also 15% packet loss brings total throughput down to 35% which is still 28KB/s (but shoots latency through the roof for UDP).
For some reason Overwatch and WoW work fine for him but they both use TCP. We can see his router sending responses that the packet was dropped with wireshark and then his computer resends the packet. Even if this happens 3 or 4 times that's only an extra couple of ms since his router is trash. This kind of recovery isn't possible with UDP (even with Reliable UDP).
I still don't see why the game uses UDP. Even Windows supports the TCP_NODELAY flag which basically translates a TCP connection (with all it's glorified automatic reliability) into a UDP pipe. The largest downside is the time the handshake takes to complete which is pretty much negligible over a few seconds of gameplay. Since you're already using NAT punchthrough it might be time time to try out TCP if your backend is easy to change (I have no idea how encapsulated your networking is).
Normally yes but it depends where the packet is lost and where it is known to be lost. With TCP the previous device is made aware when a packet is dropped at the intermediate device where as with UDP the application (client or server) has to verify both packet order and content.Rseding91 wrote:It's not just "On I have 5 MB of download speed but - 15% because of packet loss" it's *far* worse than that and typically drops to the KB/s range or less.
In the first example, the packet might have been dropped only 3~5 ms away from the previous device thus adding less than 20ms (all handled with 0 application code).
In the second example, neither the client nor the server are aware of a dropped packet until the full round trip time (1000ms in this case). The server then has to tell the client that it has dropped a packet (application code) and the client has to send the packet again (application code and another 500ms). Lets not get into if it's dropped again because this gets messy in application code.
TL;DR
You're right that there's no level of application code that could fix this problem but it's only a problem because of the choice if UDP over TCP (with TCP_NODELAY). Since a lot of work has been going into the multiplayer codebase recently, please (please please please) have a go with TCP (with TCP_NODELAY).
Also 15% packet loss brings total throughput down to 35% which is still 28KB/s (but shoots latency through the roof for UDP).
Re: [0.13.3] Unreasonable bandwidth expectations (Packet Loss)
Actually blizzard use mixed transportation TCP and UDP for their game.
It's true TCP is more reliable but are not designed for game. Simply because every packet must be acknoladge by the reciever and resend if not. In game the state change quicly (not like browser where page allways the same and load once).
Also the server will open a connection that will stay open for each client and data will need to be send to each client and every data must pass by the server.
Client 1 send data to server <> server send data to client 2 / client 3 / client 4 etc.
UDP allow broadcast no connection need to stay alive and the server will only send once the data.
Client 1 send data into broadcast <> client 2 / client 3 / client 4 etc receive information.
Normally in FPS game the client extrapolate movement of other and at X interval they receive the real position of other player, that's why you see some player "jump" from one place to another that mean they have a very low latency.
It's true TCP is more reliable but are not designed for game. Simply because every packet must be acknoladge by the reciever and resend if not. In game the state change quicly (not like browser where page allways the same and load once).
Also the server will open a connection that will stay open for each client and data will need to be send to each client and every data must pass by the server.
Client 1 send data to server <> server send data to client 2 / client 3 / client 4 etc.
UDP allow broadcast no connection need to stay alive and the server will only send once the data.
Client 1 send data into broadcast <> client 2 / client 3 / client 4 etc receive information.
Normally in FPS game the client extrapolate movement of other and at X interval they receive the real position of other player, that's why you see some player "jump" from one place to another that mean they have a very low latency.
Re: [0.13.3] Unreasonable bandwidth expectations (Packet Loss)
I hear you vtx and thanks for the info on how blizzard uses different transport systems at the same time.
I just read over this before posing and it sounds kind of like a rant so I want to apologize before you read it. It was not meant as a rant.
UDP is usually used where client and server are not so tightly synced i.e where out-of-order packets don't need to be buffered (and reordered) and a few lost packets are meaningless (don't need recovery).
Also, the jumping is a result of clients with low latency interpolating the velocity of clients with high latency and when the server receives updated velocity (and velocity history) from the laggy user then the fast users have to re-sync with the server. Factorio doesn't do this type of interpolation and it doesn't make sense for it to since it is not a twitch-shooter (for an image of what this does to games where it doesn't need to be implemented think Minecraft Alpha 7 upgrading to Minecraft Alpha 8 where the networking overhead rose from <1 kB/s to 30 kB/s with zero noticeable changes besides increased CPU from processing these packets with unnecessary data).
I just read over this before posing and it sounds kind of like a rant so I want to apologize before you read it. It was not meant as a rant.
In this game, client and server run in what's called lock-sync. Currently client and server have to both run the same in-game events (and maybe in the same order). Try playing a game on a network with high-ish latency (>200ms) and you will see that the entire server will pause for you to receive the packet. If the server latency setting is low enough, this will happen several times per frame. Using TCP wouldn't solve this issue but it would cut the round-trip-time for dropped packets by at most 40% (considering 20% of time is client sending packet to server, 20% is server sending response to client, 20% is server sending response to client, 20% is client saying he didn't receive the previous packet, and 20% is server re-sending the previous packet) depending on where the packet is being dropped.vtx wrote: It's true TCP is more reliable but are not designed for game. Simply because every packet must be acknoladge by the reciever and resend if not. In game the state change quicly (not like browser where page allways the same and load once).
UDP is usually used where client and server are not so tightly synced i.e where out-of-order packets don't need to be buffered (and reordered) and a few lost packets are meaningless (don't need recovery).
This is how the current NAT-punching is working with UDP (aside for the persistent connection) and how the server relays UDP traffic to each client. While this is normally a downside of TCP, the application has already implemented control-flow logic to reimplement this under UDP. If anything, the devs could reduce the networking codebase by quite a bit by switching to TCP. Also I don't see any downside of a persistent connection; actually a more consistent latency is a plus of a consistent connection since the initial connection will only function along 1 route (not follow several different multi-hop paths which leads to jitter).vtx wrote: Also the server will open a connection that will stay open for each client and data will need to be send to each client and every data must pass by the server.
This is how the client-server architecture currently works with Peer-To-Peer mode turned off (I don't think it's even an option anymore for public games).vtx wrote: Client 1 send data to server <> server send data to client 2 / client 3 / client 4 etc.
I'm afraid I might not be understanding you correctly. Under the current UDP system, if a packet is dropped then it is the responsibility of the application to detect the drop and resend the packet if the game wishes to run in lock-sync (sometimes called lock-step). In other words if a packet is dropped, the server will resend the data. If the game were using TCP, the server would never know that a packet was dropped because the networking drivers of all the intermediate devices will automatically resend the dropped packet.vtx wrote: UDP allow broadcast no connection need to stay alive and the server will only send once the data.
This is how the game currently works with Peer-To-Peer mode turned off. Switching from UDP to TCP won't change this. Think of how PASV on FTP works at establishing a connection.vtx wrote: Client 1 send data into broadcast <> client 2 / client 3 / client 4 etc receive information.
Factorio doesn't do interpolation like this. Without actually looking at the code, all I can say is that the game sends every event processed to the server packaged nicely in a single UDP datagram (once per tick or 60/s).vtx wrote: Normally in FPS game the client extrapolate movement of other and at X interval they receive the real position of other player, that's why you see some player "jump" from one place to another that mean they have a very low latency.
Also, the jumping is a result of clients with low latency interpolating the velocity of clients with high latency and when the server receives updated velocity (and velocity history) from the laggy user then the fast users have to re-sync with the server. Factorio doesn't do this type of interpolation and it doesn't make sense for it to since it is not a twitch-shooter (for an image of what this does to games where it doesn't need to be implemented think Minecraft Alpha 7 upgrading to Minecraft Alpha 8 where the networking overhead rose from <1 kB/s to 30 kB/s with zero noticeable changes besides increased CPU from processing these packets with unnecessary data).
Re: [0.13.3] Unreasonable bandwidth expectations (Packet Loss)
I'm going to try tunneling the UDP through a VPN that encapsulates all packets via TCP and will report back.
If I'm right then it game will run great even with 15% packet loss.
If I'm right then it game will run great even with 15% packet loss.
Re: [0.13.3] Unreasonable bandwidth expectations (Packet Loss)
I do not think TCP will help that much. I'm curious of the result you'll get.
TCP will only put packet loss behind the scene but your friend will have the same amount of packet loss. When TCP detect packet lost it halt the the flow of data and ask the sender the missing packet then wait untill he receive it to restart the flow. Will be translate in an increase of delay.
So in the end you should see the same result if not worst.
-- edit --
As I reread your post you said server send once per tick ( 60 / s ). Just with that info TCP is a no go, it's not designed for sub-second transmission.
Also to gain full potential of UDP it should be use as "send and forget" that mean you send once and didn't care if the packet is lost. So instead of trying to "copy the feature of TCP into UDP" by resending EVERY packet lost.
They should add a backlog of event per client on the server. The client will ack the last event receive then the server will remove from backlog all event older. Then the server will send the rest of the backlog.
That will be remove the hicup when someone have a high packet lost and latency. But require a perfect deterministic lock-step game ( for a specific input the result is allways the same ).
TCP will only put packet loss behind the scene but your friend will have the same amount of packet loss. When TCP detect packet lost it halt the the flow of data and ask the sender the missing packet then wait untill he receive it to restart the flow. Will be translate in an increase of delay.
So in the end you should see the same result if not worst.
-- edit --
As I reread your post you said server send once per tick ( 60 / s ). Just with that info TCP is a no go, it's not designed for sub-second transmission.
Also to gain full potential of UDP it should be use as "send and forget" that mean you send once and didn't care if the packet is lost. So instead of trying to "copy the feature of TCP into UDP" by resending EVERY packet lost.
They should add a backlog of event per client on the server. The client will ack the last event receive then the server will remove from backlog all event older. Then the server will send the rest of the backlog.
That will be remove the hicup when someone have a high packet lost and latency. But require a perfect deterministic lock-step game ( for a specific input the result is allways the same ).
Re: [0.13.3] Unreasonable bandwidth expectations (Packet Loss)
Actually TCP can handle re-transmission by intermediate devices i.e. a packet on a 23 hop journey is lost from hop 12 to 13 then hop 12 re-transmits the packet which loses only the RTT from 12 to 13 (2 times) instead of the entire 23 hop journey (2 times). This is where it should help the most because the problem device has a latency of 1ms from him and 300ms from me which saves on average ((1+300)*2 * (0.15 packet loss)) = 90ms. This translates to saving at most 602ms and at least 200ms if we dropped every packet at the problem device.vtx wrote:I do not think TCP will help that much. I'm curious of the result you'll get.
TCP will only put packet loss behind the scene but your friend will have the same amount of packet loss. When TCP detect packet lost it halt the the flow of data and ask the sender the missing packet then wait untill he receive it to restart the flow. Will be translate in an increase of delay.
So in the end you should see the same result if not worst.
Also, TCP doesn't halt the flow but it does half the transmission rate and then proceeds with what's called "slow start" where it attempts to send packets progressively faster until 1 of them fails which triggers "slow start" again.
This is fine when using the TCP_NODELAY flag (see https://en.wikipedia.org/wiki/Nagle%27s_algorithm). There is no delay and the sliding window size is plenty large enough for 60/s.vtx wrote: As I reread your post you said server send once per tick ( 60 / s ). Just with that info TCP is a no go, it's not designed for sub-second transmission.
Yes but the game isn't setup to continue from lost packets so the devs have already added functionality to mimic TCP by using re-transmission. My point is that it would be both simpler application code and more effective for latency to just use TCP instead of fake the part the game needs.vtx wrote: Also to gain full potential of UDP it should be use as "send and forget" that mean you send once and didn't care if the packet is lost. So instead of trying to "copy the feature of TCP into UDP" by resending EVERY packet lost.
This isn't compatible with the idea lock-sync. They have added something like this with the server latency slider (which is probably keeping most of the "backlog" in transmission instead of in a buffer) and it's good at reducing little hick-ups but the reliance on UDP with 0% packet loss means that minimum latency for a single lost packet is many many times greater than optimal.vtx wrote: They should add a backlog of event per client on the server. The client will ack the last event receive then the server will remove from backlog all event older. Then the server will send the rest of the backlog.
The comment that 15% packet loss means a completely hosed network connection is also garbage (from Rseding91).
Let's assume a nice short 20 hop jump from my PC to google.com (where we ignore all the caching content servers since a game can't use them). An ISP's network happens to be under extremely high load for the time of day. Because of the high load, 6 of these devices have 3% packet loss which means that the route has a total of 18% packet loss. I'll still get to google.com just fine and the RTT for my request will only be a few ms longer than expected. This is because the internet uses TCP. If the internet used UDP (ignoring all firewalls and NAT), I would have to wait for a timeout to expire to find out I didn't get my response and re-transmit my request; this wastes a lot more time.
The above scenario is very common under heavy load because UDP applications are not meant to be reliant on every packet so the routers purposefully drop UDP over dropping TCP.
Re: [0.13.3] Unreasonable bandwidth expectations (Packet Loss)
Here some information about TCP vs UDP.
http://gafferongames.com/networking-for ... dp-vs-tcp/
Sure a game like World of Warcraft can use TCP because they used some trick to hide latency. No player to player collision. Attack are made to object not is relative position in the world. When a player cast it send the command to server then start animation and during this time it should receive confirmation from the server.
Here some information about Deterministic Lockstep and why UDP is better for those kind of game.
http://gafferongames.com/networked-phys ... -lockstep/
Fortunately, factorio use this system. If you start a new game in the exact same world and do the exact same thing you'll get same result ( replay ingame is exactly that ).
---
Both UDP and TCP is viable for game but you must choose the right one for the type of game you are doing. Using TCP if you are able to live with 1 or 2 seconds latency like a game card. UDP is better suit for real-time game.
If they mimmic TCP over UDP is true they choose the wrong approach.
For sanity let's assume every message use 1 packet and a message can have more than one event in it.
With the backlog :
Server send backlog to client 1 having message #45 to #60
Client 1 ack last message receive #50.
Server delete from backlog for client 1 messsage #45 to 50.
Server send the backlog to client 1 having now message #50 to 60
So wathever the last message receive is due to packet lost didn't matter. Mimmic TCP that mean :
TCP
Server send message #45 to client.
Server didn't receive ack for message #45 then resend it.
Client ack #45
Server receive ack for #45 then send #46.
TCP per packet RTT.
UDP should be per message RTT. See in the example above those lost packet stay lost we just didn't care as the backlog serve the reliability of TCP.
http://gafferongames.com/networking-for ... dp-vs-tcp/
Sure a game like World of Warcraft can use TCP because they used some trick to hide latency. No player to player collision. Attack are made to object not is relative position in the world. When a player cast it send the command to server then start animation and during this time it should receive confirmation from the server.
Here some information about Deterministic Lockstep and why UDP is better for those kind of game.
http://gafferongames.com/networked-phys ... -lockstep/
Fortunately, factorio use this system. If you start a new game in the exact same world and do the exact same thing you'll get same result ( replay ingame is exactly that ).
---
Both UDP and TCP is viable for game but you must choose the right one for the type of game you are doing. Using TCP if you are able to live with 1 or 2 seconds latency like a game card. UDP is better suit for real-time game.
If they mimmic TCP over UDP is true they choose the wrong approach.
For sanity let's assume every message use 1 packet and a message can have more than one event in it.
With the backlog :
Server send backlog to client 1 having message #45 to #60
Client 1 ack last message receive #50.
Server delete from backlog for client 1 messsage #45 to 50.
Server send the backlog to client 1 having now message #50 to 60
So wathever the last message receive is due to packet lost didn't matter. Mimmic TCP that mean :
TCP
Server send message #45 to client.
Server didn't receive ack for message #45 then resend it.
Client ack #45
Server receive ack for #45 then send #46.
TCP per packet RTT.
UDP should be per message RTT. See in the example above those lost packet stay lost we just didn't care as the backlog serve the reliability of TCP.
Re: [0.13.3] Unreasonable bandwidth expectations (Packet Loss)
http://gafferongames.com/networking-for ... dp-vs-tcp/vtx wrote:http://gafferongames.com/networked-phys ... -lockstep/
This is beautiful. The devs should definitely use the solution at the bottom of this page if they wish to still use UDP.
It would be a lot more info to send in Factorio because I imagine the game syncs event-ids on object-ids but UDP datagrams can be huge and still function just fine.
This link made my day. Thank you.
Also while the TCP simulation shows a lot of jumping for the laggy guy, it's important to note that the left simulation isn't waiting on the right simulation to catch-up (which Factorio currently does). This would already be an improvement.
Anyway encapsulating UDP in TCP added about 30ms of latency via processing (from my pc to my server down the hall) but brought down the latency from slow guy to me by about 200ms (down to 300-ish). It didn't solve the stuttering (like your link shows it shouldn't). We can play fine (no stuttering) at 1S of server latency when encapsulating UDP via TCP. Occasionally we get a short hiccup which I imagine is where a packet is dropped more than once on it's trip.
You may want to show the devs that link somehow. I imagine I've already annoyed them a bit.
-
TruePikachu
- Filter Inserter
- Posts: 978
- Joined: Sat Apr 09, 2016 8:39 pm
- Contact:
Re: [0.13.3] Unreasonable bandwidth expectations (Packet Loss)
To get back to the original issue, the person with all the packet loss, how are they connecting to the Internet? If it is through any sort of wireless connection, try a wired one.
Re: [0.13.3] Unreasonable bandwidth expectations (Packet Loss)
It's wired on a gigabit connection to the modem. It's just a really bad modem that can only handle about a thousand packets/s.TruePikachu wrote:To get back to the original issue, the person with all the packet loss, how are they connecting to the Internet? If it is through any sort of wireless connection, try a wired one.
Thanks for the help though.
Re: [0.13.3] Unreasonable bandwidth expectations (Packet Loss)
To help reduce the bandwidth usage I hope they use BINARY data instead of sending data as TEXT.
I'm a little bit confuse about if this game use a P2P system or Server/client. There is a headless server provided but is it truly a server/client or just a third-party P2P system.
By P2P I mean :
- Everyone is connected to everyone. So if you play with 10 others players, everyone is connected to everyone and everyone is sending at least 10 messages per game-tick ( one for every players ) .
For 1 message per tick : 10 players sending to everyone else in the game ( 9 ).
10 players receiving from everyone else ( 9 ) .
Total : 18 messages per player and 180 messages on the global network.
1 080 messages per seconds / 10 800 messages per seconds
- Everyone is authorative of it's own game. ( validation of the game event )
- Everyone must wait to have receive state of everyone to process the game tick. As you have to make sure everyone is on the same step-lock.
- The speed of the game will be the speed of the slowest ( internet connection and/or PC ).
By server I mean :
- Everyone send only 1 messages to the server. Only the server will relay the data between players in one message combining data of everyone into one message send back to every players ).
For 1 message : 10 players sending to the server ( 1 )
Server sending back to players ( 10 )
Total : 2 messages per player and 20 messages total on the global network.
120 mesage per seconds / 1 200 messages per seconds.
- server is the authorative of the game ( only the server validate game event )
- The speed of the game depend on the speed of the server ( internet connection and PC ).
-----
If they applied what we have talked before that mean everyone will only have to be sure to be sync with the server that mean everyone will be in a kinda bubble time. Having someone in the game with 5 seconds latency in an extreme example will be possible he will lag behind of everyone else by 5 seconds but everyone will have a smooth gameplay.
One of great advantage of UPD is that sending 1 message = 1 messages receive ( packet wise that mean 1 message = 1 packat ). Not allways the case in TCP in BLOCKING mode 1 on 1 is respected but the packet combination was made behind the scene ( meaning longer latency ) in NON-BLOCKING mode you have to do it yourself.
Only one message have to be send and receive per game-tick on server system. By adding an buffer on the server for every players and having a counter message system. With that you can easily deal of ( packet loss / disorder of message / desync ).
Datagram
[#id_last_message_ receive]{[#id_current_message][bulk of every event command]...}
Client receiving an #id lower of #id of last message receive mean disorder of message and drop it.
If someone trigger a desync with the server. either the game stop for everyone to let the one receive all game-event on the buffer, no need to reload the map. Or simply stop is display and focus on receiving all game-event on the buffer.
Packet loss will be deal silently as you allways send everything you have in the buffer per tick. Not receiving data on a specific tick could be packet loss.
I'm a little bit confuse about if this game use a P2P system or Server/client. There is a headless server provided but is it truly a server/client or just a third-party P2P system.
By P2P I mean :
- Everyone is connected to everyone. So if you play with 10 others players, everyone is connected to everyone and everyone is sending at least 10 messages per game-tick ( one for every players ) .
For 1 message per tick : 10 players sending to everyone else in the game ( 9 ).
10 players receiving from everyone else ( 9 ) .
Total : 18 messages per player and 180 messages on the global network.
1 080 messages per seconds / 10 800 messages per seconds
- Everyone is authorative of it's own game. ( validation of the game event )
- Everyone must wait to have receive state of everyone to process the game tick. As you have to make sure everyone is on the same step-lock.
- The speed of the game will be the speed of the slowest ( internet connection and/or PC ).
By server I mean :
- Everyone send only 1 messages to the server. Only the server will relay the data between players in one message combining data of everyone into one message send back to every players ).
For 1 message : 10 players sending to the server ( 1 )
Server sending back to players ( 10 )
Total : 2 messages per player and 20 messages total on the global network.
120 mesage per seconds / 1 200 messages per seconds.
- server is the authorative of the game ( only the server validate game event )
- The speed of the game depend on the speed of the server ( internet connection and PC ).
-----
If they applied what we have talked before that mean everyone will only have to be sure to be sync with the server that mean everyone will be in a kinda bubble time. Having someone in the game with 5 seconds latency in an extreme example will be possible he will lag behind of everyone else by 5 seconds but everyone will have a smooth gameplay.
One of great advantage of UPD is that sending 1 message = 1 messages receive ( packet wise that mean 1 message = 1 packat ). Not allways the case in TCP in BLOCKING mode 1 on 1 is respected but the packet combination was made behind the scene ( meaning longer latency ) in NON-BLOCKING mode you have to do it yourself.
Only one message have to be send and receive per game-tick on server system. By adding an buffer on the server for every players and having a counter message system. With that you can easily deal of ( packet loss / disorder of message / desync ).
Datagram
[#id_last_message_ receive]{[#id_current_message][bulk of every event command]...}
Client receiving an #id lower of #id of last message receive mean disorder of message and drop it.
If someone trigger a desync with the server. either the game stop for everyone to let the one receive all game-event on the buffer, no need to reload the map. Or simply stop is display and focus on receiving all game-event on the buffer.
Packet loss will be deal silently as you allways send everything you have in the buffer per tick. Not receiving data on a specific tick could be packet loss.
Re: [0.13.3] Unreasonable bandwidth expectations (Packet Loss)
https://www.factorio.com/blog/post/fff-145vtx wrote:[...]
Multiplayer problems
Now, when we can connect to public games on the internet, we found out, there are lot of issues with the multiplayer server that weren't apparent when we were lan-testing it. One of the issues is, that even when we use the one center player (the server) to resend the packages of individual players, the server still sends one packet per player to everyone. This means, that with 10 players, the server sends 10 packets to every player every tick, which results in 6000 packets per second to be processed by every player. The obvious solution will be, that the server will merge the messages from individual players into one package. We also plan to reduce the network transfer by sending only 30 updates per second (once per two ticks) over the multiplayer. This will reduce the network problems related to packet throughput a lot. Apart from this, we found out, there are few bugs in the internal multiplayer state logic. We will look at these problems once the main bug report wave is tamed, so consider the current multiplayer very experimental.
Re: [0.13.3] Unreasonable bandwidth expectations (Packet Loss)
Thanks daniel34 for the link.
That paragraph is actually why I posted this bug report initially (so that the devs would be aware of it's existence while they fixed bugs in the surrounding code during the multiplayer-backend overhaul).
The devs at least acknowledged this bug and I have confidence that it will eventually be fixed if they want multiplayer to ever be stable. vtx posted an excellent link with a way to fix it (without too much work). I just hope a dev sees it.
That paragraph is actually why I posted this bug report initially (so that the devs would be aware of it's existence while they fixed bugs in the surrounding code during the multiplayer-backend overhaul).
The devs at least acknowledged this bug and I have confidence that it will eventually be fixed if they want multiplayer to ever be stable. vtx posted an excellent link with a way to fix it (without too much work). I just hope a dev sees it.
Re: [0.13.3] Unreasonable bandwidth expectations (Packet Loss)
It's seem as the Friday Facts #147 said they have allready that in mind or they are inspired by this discussion either way it's good news for the future of game network.
Good job dev!!
Good job dev!!