Friends living abroad have really laggy connection to me, why?(using raknet, udp)

Rusev · 2016-08-22T16:24:03

Guys, as I told you probably 100 times by now. I'm making a multiplayer paintball game. I've just finished with setting up the sending of my position and rotation to all other connected clients and I tested it on my PC( I've loaded both a server and a client on my PC ) and when I move forward in the server app, the same forward movement is made on the client app, cool. Everything works perfectly fine. But when I send the client version of my game to a friend of mine who is in another country, he says that my movement is very laggy, and the game is not playable. I'm wondering why the packets are sent so slowly. I'm using RakNet and RakPeerInterface class which is based on UDP, so it's not a TCP problem and I don't know what to do. 2nd bonus question: Ok, TCP guarantees the arrival of every packet and while this is good for some applications, it causes slowdown in games, because if one packet is dropped, the router waits for the same packet to be resent and this messes things up, OK. But then in this link here:http://www.raknet.net/raknet/manual/introduction.html There is this sentence: "At the lowest level, RakNet's peer to peer class, RakPeerInterface provides a layer over UDP packets that handle these problems transparently, allowing the programmer to focus on the game rather than worrying about the engine." So actually RakNet provides a layer over UDP packets that provides the functions a normal TCP would have. Everything is messed up in my head because of this. Why would someone use UDP and write code to add TCP functionality ( right order, reliable packets ) instead of just using TCP. Of course there should be a very logical reason, and I know I'm missing something. Do you have any suggestions why this may be?

Networking and Multiplayer Programming

Started by Heelp August 20, 2016 03:37 PM

11 comments, last by Heelp 7 years, 8 months ago

hplus0603

11,916

August 21, 2016 04:28 PM

dropped TCP packets are just waited for at the router to be resent again

Routers, in general, do not wait for re-transmission before they forward, because they work at the IP layer, not the TCP layer.
For "reverse NAT servers" this changes, as they play the role of end-points, but when you talk about "router" in general internet parlance, you typically mean the boxes that sit in the middle of the network.

The re-transmission in TCP is entirely handled by the endpoints -- the machine doing the sending, and the machine doing the receiving on the other end.
And if one packet is dropped or delayed, ALL THE PACKETS AFTER THAT PACKET ARE HELD when they are received, waiting for the dropped/delayed packet to be re-sent.
By the time the dropped packet is detected, re-transmitted, and received on the other end, anything that was sent after that is also late, because it's been sitting in the kernel, received by the host, but not delivered to the application, because of the in-order guarantee.

Regarding spraying 100 packets at the same time, that doesn't really help, because the main reason a packet is dropped, is that there is congestion at some node on the network.
Once there is congestion, if the node receives 1 packet from you, or 100 packets from you, they will all be dropped at that time until the congestion recovers.
If you want to try duplication, consuming bandwidth in an attempt at higher robustness, it's much more robust to perhaps include the last 2-3 packets as copies in the next packets you send, so there is some time between each. This will add a bit of overhead, but if you structure your data right, it will RLE compress really well, and thus won't actually consume 200-300% of the bandwidth.
If the network drops three successive packets with a packet-send delay between each, the congestion is likely so bad that you're going to have a bad playing experience no matter what.

enum Bool { True, False, FileNotFound };

frob

46,221

August 21, 2016 10:26 PM

A bit more on that...

You seem to already know some of this, but the nature of the questions means it bears repeating:

TCP is stream based. The protocol makes sure that you get what was sent, in the exact order it was sent. This is wonderful if you prefer a guarantee that everything arrive in the order it was sent. If something was dropped on the network the underlying protocol will tell you it isn't ready yet, and it will do its job behind the scenes to request the missing data and ensure that your stream is given to you in the order it was sent. This isn't necessarily wrong or bad, and if you need a stream based system it can be exactly what you need.

UDP is packet based. The protocol gives you items as fast as they are received, and does not take steps to deal with network hiccups. This is wonderful if you prefer data is available as soon as it arrives. However, if something was dropped on the network the protocol won't automatically request it for you; if a network hiccup gives you a packet multiple times, twice or three times or twenty times, you'll get copy after copy as they arrive. This isn't necessarily wrong or bad, and if you want data as soon as it arrives it can be exactly what you need.

Raknet, like many game networking libraries use UDP for their communication and then implement an optional stream-based protocol on top of it. This way you can specify how you want the data. If you want the data as fast as it arrives then you can flag it to use that version of their protocol, but in exchange you need your code to deal with missing packets, duplicate packets, and the rest. If you want your data stream based you can flag it to use that variation of their protocol, but in exchange you need your code to deal with the fact that sometimes the stream will stop after network hiccups and it may cause a delay.

Whichever version you end up taking you will need to design in ways to deal with latency and with network hiccups. There are many tips and tricks out there for dealing with them. Some of them can be masked with simple tricks: an audio cue ("Yes, sir!") or an animation (slight gun lift and trigger pull) can buy you 100-200 milliseconds. For bullets, introducing flight time on the shot can gain you another few hundred milliseconds. A bullet may travel about 4000 feet per second, so there's another 10 milliseconds of network time. Dead reckoning and predictions with rewinding and injecting events are more difficult to implement, but they can further reduce the perceived network performance. You can implement any or all of those things using either stream-based or packet-based networking protocols.