1 : When I send RT packet in a real-time session , I want to set the player peerID as the sender of the packet ,I know I can send an int with the data,but that would increase the packet size ,so how to change the sender value ?
2 : currently I''m sending 3 ints with a packet,so the size should be 12 bytes , and maybe a little more because of the keys and such,but the packet size ranges between 15-21 , what's increasing it ?
3 : As for the speed of sending packets ,what determines it ? Aside from network speed , does the size of packet matter that much ?
And Thanks.
Best Answer
C
Customer Support
said
about 6 years ago
Hey Yaser,
[1] - The peerID is already available from any packet that comes in (RTPacket.Sender). [2] - The peerID present in the the packet already will add to the packet size (4bytes), there is also another int present in the packet representing the op-code. [3] - Size of the packet does affect the speed. The main issue with packet size is that larger packets take longer to transmit across the network, but they carry more information so they can be more efficient if used correctly. There is a little processing overhead needed in order to send each packet, but this is really minuscule. You will only see that overhead affect speed if you are sending many small packets very frequently, so a happy-medium is to send larger packets less frequently, ideally at a set-rate so all clients are in sync. For GameSparks RT the delivery intent also affects the speed. UDP (unreliable) will send immediately where TCP (reliable) will buffer data until there is enough to send. So TCP is typically slower though more reliable. Lost packets with TCP also get retrieved from the sender. So any lost packet (typically <1% packets are lost for all networks) get requested again, and the client/server has to wait for the packet to be resent, which also slows things down.
We have a document we are preparing for best-practices that goes through this in a bit more detail. Let us know if you would like to see an early version.
1. We don't have a recommended way of sending a player ID as the sender of the packet other than your current solution to set it as an int within the packet data.
2. There may be a slight discrepancy in the packet size from time to time, this is probably due to other parts of the packet being formed in the background. Our system limit for packet size is 1400 bytes you can read up on our limits here (https://docs.gamesparks.com/documentation/key-concepts/system-limits.html)
3. Mainly the speed of the network is the determining factor along with the size of the packet. Heavy server side processing of a packet will also add to the lag time.
Hope this helps,
- Steve
1 person likes this
Customer Support
said
about 6 years ago
Answer
Hey Yaser,
[1] - The peerID is already available from any packet that comes in (RTPacket.Sender). [2] - The peerID present in the the packet already will add to the packet size (4bytes), there is also another int present in the packet representing the op-code. [3] - Size of the packet does affect the speed. The main issue with packet size is that larger packets take longer to transmit across the network, but they carry more information so they can be more efficient if used correctly. There is a little processing overhead needed in order to send each packet, but this is really minuscule. You will only see that overhead affect speed if you are sending many small packets very frequently, so a happy-medium is to send larger packets less frequently, ideally at a set-rate so all clients are in sync. For GameSparks RT the delivery intent also affects the speed. UDP (unreliable) will send immediately where TCP (reliable) will buffer data until there is enough to send. So TCP is typically slower though more reliable. Lost packets with TCP also get retrieved from the sender. So any lost packet (typically <1% packets are lost for all networks) get requested again, and the client/server has to wait for the packet to be resent, which also slows things down.
We have a document we are preparing for best-practices that goes through this in a bit more detail. Let us know if you would like to see an early version.
Hey, This discussion has been very helpful in determining the data size. My packet includes: 2 vector2: 8bytes x 2 = 16 bytes key with vectors = 8 bytes peer id = 4 bytes
op-code = 4 bytes So my size should be 32bytes. Am i missing something else because the size is bigger than this. Thanks in advance!
Yaser Prog
Hello
I have a few questions regarding RT packets .
1 : When I send RT packet in a real-time session , I want to set the player peerID as the sender of the packet ,I know I can send an int with the data,but that would increase the packet size ,so how to change the sender value ?
2 : currently I''m sending 3 ints with a packet,so the size should be 12 bytes , and maybe a little more because of the keys and such,but the packet size ranges between 15-21 , what's increasing it ?
3 : As for the speed of sending packets ,what determines it ? Aside from network speed , does the size of packet matter that much ?
And Thanks.
[1] - The peerID is already available from any packet that comes in (RTPacket.Sender).
[2] - The peerID present in the the packet already will add to the packet size (4bytes), there is also another int present in the packet representing the op-code.
[3] - Size of the packet does affect the speed. The main issue with packet size is that larger packets take longer to transmit across the network, but they carry more information so they can be more efficient if used correctly. There is a little processing overhead needed in order to send each packet, but this is really minuscule. You will only see that overhead affect speed if you are sending many small packets very frequently, so a happy-medium is to send larger packets less frequently, ideally at a set-rate so all clients are in sync. For GameSparks RT the delivery intent also affects the speed. UDP (unreliable) will send immediately where TCP (reliable) will buffer data until there is enough to send. So TCP is typically slower though more reliable. Lost packets with TCP also get retrieved from the sender. So any lost packet (typically <1% packets are lost for all networks) get requested again, and the client/server has to wait for the packet to be resent, which also slows things down.
We have a document we are preparing for best-practices that goes through this in a bit more detail. Let us know if you would like to see an early version.
Thanks,
Sean
- Oldest First
- Popular
- Newest First
Sorted by Oldest FirstCustomer Support
Hi Yaser,
I'll do my best to answer your questions for you.
1. We don't have a recommended way of sending a player ID as the sender of the packet other than your current solution to set it as an int within the packet data.
2. There may be a slight discrepancy in the packet size from time to time, this is probably due to other parts of the packet being formed in the background. Our system limit for packet size is 1400 bytes you can read up on our limits here (https://docs.gamesparks.com/documentation/key-concepts/system-limits.html)
3. Mainly the speed of the network is the determining factor along with the size of the packet. Heavy server side processing of a packet will also add to the lag time.
Hope this helps,
- Steve
1 person likes this
Customer Support
[1] - The peerID is already available from any packet that comes in (RTPacket.Sender).
[2] - The peerID present in the the packet already will add to the packet size (4bytes), there is also another int present in the packet representing the op-code.
[3] - Size of the packet does affect the speed. The main issue with packet size is that larger packets take longer to transmit across the network, but they carry more information so they can be more efficient if used correctly. There is a little processing overhead needed in order to send each packet, but this is really minuscule. You will only see that overhead affect speed if you are sending many small packets very frequently, so a happy-medium is to send larger packets less frequently, ideally at a set-rate so all clients are in sync. For GameSparks RT the delivery intent also affects the speed. UDP (unreliable) will send immediately where TCP (reliable) will buffer data until there is enough to send. So TCP is typically slower though more reliable. Lost packets with TCP also get retrieved from the sender. So any lost packet (typically <1% packets are lost for all networks) get requested again, and the client/server has to wait for the packet to be resent, which also slows things down.
We have a document we are preparing for best-practices that goes through this in a bit more detail. Let us know if you would like to see an early version.
Thanks,
Sean
2 people like this
Yaser Prog
Hi, thanks for your answer.
I found that page in the API Documentation: https://docs.gamesparks.com/api-documentation/realtime-api/rtpacketbuilder.html
Can I use this class with unity API? or is it for Cloud Code?
Because it looks like it has a setSender Function
Yaser Prog
Thank you Guys for answering.
Well it would be good if I can see an early version
Alexey Pozdnyakov
Hi Sean!
Could you please give me a link to the document you have mentioned?
Thank you!
Customer Support
Hi Alexey,
That piece of documentation has been forwarded on to you.
Regards,
Liam
Alexey Pozdnyakov
Thank you Liam.
Yaser Prog
Hi.
I would like to get that Document also, if possible.![]()
Thanks
Customer Support
Martin Horn
Hi, I've just started looking into using GameSparks RT for our next project, could I get a copy of that document also.
Many thanks.
Customer Support
Hey Martin, i've just sent that one.
We should a version of this up on the site soon; just getting some guidelines for bandwidth together.
Sean
Martin Horn
That's great thanks very much :)
Customer Support
waleed bin khalid
Hey,
This discussion has been very helpful in determining the data size.
My packet includes:
2 vector2: 8bytes x 2 = 16 bytes
key with vectors = 8 bytes
peer id = 4 bytes
op-code = 4 bytes
So my size should be 32bytes. Am i missing something else because the size is bigger than this.
Thanks in advance!
-
Documentation Notes
-
Design issues with user events
-
Using NoSQL
-
Runtime Collections vs Metadata Collections
-
Anonymous authentication from browser app
-
Modules
-
Movement With Unity
-
Problem with url parameters for downloadables
-
Querying NoSql GameSparks database
-
Challenge accesType
See all 2487 topics