Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Sockets VS TCP packets network latency

Author
Message
Cybermind
Valued Member
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 17th Jan 2017 15:12
Hello I am converting an old project that uses UDP packets for positioning players over the internet, this has a very low latency. I noticed a little more latency when using AGK2. I have set SetNetworkLatency to 1 on both server and clients, I have set clients sync rate to 60 and server sync rate to 0. I think this is the best I can do with TCP packets to eliminate lag, but what about sockets, would that be faster? I've never used sockets before.
13/0
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 17th Jan 2017 16:42
TCP is slower than UDP but better. Packets without loss and in the right order + Connection State.
If you sending Data be careful , send only changes not 60x each second the same position.

AGK (Steam) V2017.01.09 : Windows 10 Pro 64 Bit : AMD (16.12.1) Radeon R7 265 : Mac mini OS Sierra (10.12.2)
Cybermind
Valued Member
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 17th Jan 2017 17:52
Yes, no loss and in the right order, and I only send a TCP packet when the player has moved or turned. But now I see a small lag issue with TCP packets, a lag issue that was not there with UDP packets. The UDP packets were just fired away all the time, it didn't matter if some got lost, and it worked really well. Is sockets faster, slower or about equal to TCP packets?
13/0
Ortu
DBPro Master
17
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 17th Jan 2017 18:57 Edited at: 17th Jan 2017 18:59
Your question is a bit confusing. In general, a socket can be either a udp socket, or a tcp socket. Any built in implementation of tcp packet networking is still using a socket, it's just abstracting some of the management away from you.

At the end of the day, your basic choices are still udp or tcp.

Udp will be faster, but it is less stable, this is usually fine for position data, but can have problems with data and input that is not repeatedly sent in a constant stream.

Tcp is slower, but more reliable, you won't have to deal with missing or corrupt data, but you will have to handle higher latency.
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
Cybermind
Valued Member
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 17th Jan 2017 19:45
I am using Tier 1, I don't think that I get the option to choose between UDP or TCP sockets.
13/0
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 17th Jan 2017 23:03
about how much ms time your are speaking if you say "noticed a little more latency" ?

Quote: "and I only send a TCP packet when the player has moved or turned. "

if you push data into outgoing buffer and you have any delay or jam you will see at the receiving end, looks jiggle / stutter if
you process it.
then you can try using Tweening for a move from a to b.
your network can send new data but it will still moving smooth to next new/last send position.



AGK (Steam) V2017.01.09 : Windows 10 Pro 64 Bit : AMD (16.12.1) Radeon R7 265 : Mac mini OS Sierra (10.12.2)
Cybermind
Valued Member
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 18th Jan 2017 09:57 Edited at: 18th Jan 2017 09:58
If I open two clients on my computer and align the windows, I can "race" with a sprite (one client sends position data, the other recieves them), I move a sprite from one side of the window to the other. With the UDP packets the sprites would arrive at "finish line" almost at the same, no noticeable delay on the recieving end, but with TCP packets, sometimes the recieving end shows a delay, the sprite arrives at the "finish line" a little after the sending client.
13/0
Mobiius
Valued Member
21
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 18th Jan 2017 10:12
That sounds like correct behavior.
Cybermind
Valued Member
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 18th Jan 2017 10:39
Quote: "That sounds like correct behavior."


Yes, but it is an action game and I want positions to be updated as fast as possible, and it seems that with AGK2 Tier 1, TCP packets is the only option I get.
13/0
Mobiius
Valued Member
21
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 18th Jan 2017 11:16 Edited at: 18th Jan 2017 11:16
Are you using the ConnectSocket or HostNetwork command?

I get the feeling that whilst ConnectSocket uses TCP, HostNetwork will use UDP. (As it's designed for games and you should use UDP for gaming.)
Cybermind
Valued Member
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 18th Jan 2017 11:16
Nevermind, it is close enough now. I send 3x4 bytes now, one 4 byte integer for X, one 4 byte integer for Y, one 4 byte integer for direction. I can, however, shave that down to 2 bytes for X, 2 bytes for Y and 1 byte for direction with sockets as I can send a byte with a socket instead of a 4 byte integer (the smallest amount of data I can send with the network commands that are not sockets).
13/0
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 19th Jan 2017 00:56
i believe the multiplayer commands using also tcp except broadcast commands.

how about this solution,
server sending the position to both clients.
at one pc i think both race cars will get the pos at the same time.
else u need a time & pos. data for synchronize.
if you made a server system it get the input from clients, the server have the game data (& logic) and distributed it.
AGK (Steam) V2017.01.09 : Windows 10 Pro 64 Bit : AMD (16.12.1) Radeon R7 265 : Mac mini OS Sierra (10.12.2)
Seditious
11
Years of Service
User Offline
Joined: 2nd Aug 2013
Location: France
Posted: 19th Jan 2017 02:18
If you're regularly re-sending updates (such as with a real-time game) you absolutely do *not* want to use TCP, since it will continually try to retransmit old data until it is sent, and will not send any newer data (due to ordering) until it has done so.
imagine going to a wedding and farting on the corpse lol - Seditious, 2016
(Formerly known as Benjamin until he lost access to his account)
Cybermind
Valued Member
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 20th Jan 2017 16:15 Edited at: 20th Jan 2017 18:53
Is there any way to use UDP packets in Tier 1?

EDIT: Silly question, it should be a feature request, I guess :-P
13/0
Cybermind
Valued Member
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 26th Jan 2017 13:38 Edited at: 26th Jan 2017 13:42
Short update, I am now using a socket connection for updating player positions. I can then send only 6 bytes for positions instead of 16. X posititons are always < 1280 and Y positions are always < 720. In theory I could have X and Y positions up to 256 * 256 without combining X and Y byte 1.

TCP packets:
Packet operation, 4 bytes
Player X integer, 4 bytes
Player Y integer, 4 bytes
Player direction, 4 bytes
= 16 bytes

Socket connection:
No packet operation ID, socket is only used for positions
Player number byte (4 players)
Player X byte 1 (player X in range 0 to 255 = 0, player X in range 256 to 511 = 1, player X in range 512 to 767 = 2, and so on)
Player X byte 2(player X in range 0 to 255 = player X byte 1 = player X - 128, player X in range 256 to 511 = player X byte 2 = player X - 256 - 128 and so on), this will send a byte in the range -128 to 127.
The same with Y as with X positions.
Player Y byte 1
Player Y byte 2
Player direction byte (8 directions, angle 0 = 0, angle 45 = 1, angle 90 = 2, and so on)
= 6 bytes

I can further compress it by combining player number and player direction into 1 byte and player X byte 1 and player Y byte 1 into 1 byte.

The send code:


Recieve code:


EDIT: Lag is noticeable less now. The smallest data type I can send with the multiplayer messages is a 4 byte integer, and with sockets I can send 1 byte.
13/0

Login to post a reply

Server time is: 2024-11-24 20:42:28
Your offset time is: 2024-11-24 20:42:28