Questions about the Photon Cloud script "PhotonStatsGui".

Kurtav

http://imgur.com/pqMSESa
After the script collects data during one second, I display the data in GUI and reset the traffic - PhotonNetwork.networkingPeer.TrafficStatsReset ();
In the room there are two players and 20 bots.

1) I send Vector3 movement of 20 bots - script CubeLerp,OnPhotonSerializeView. Why it takes 6000 bytes? Veсtor3 -16 * 200 bytes (10 positions per second * 20 bots) = 3200 bytes!
2) What are the: In * 18, TotalPacketCount = 10, TotalCommnadsInPackets = 20? It is not clear, how does this relate to the number of packages. Logically, there should be 200 messages in a second from bot's positions (the Photon Cloud documentation says that movement packages combine in a unique way). How do the combine? What is the formula for calculating? What is the difference between the "package command" and "package"?

JohnTube

Hi @Kurtav,

You can take a look at "Photon Stats GUI", "Binary Protocol" and "Serialization in Photon" to know more.

I guess you took a look at the "PhotonStatsGUI" script code already.

@Kaiserludi already gave an answer for a similar question here.

Kurtav

my one package = 28 (UDP header) + 12(eNet package header) + 16 (send unreliable (eNet command header)) + 8 (operation-header eNet command) + 16 (data eNet command(Vector3)) + ACK(20+20) = 120 byte.
Сorrectly ?

JohnTube

Hi @Kurtav,

Yes that should be it.
@Kaiserludi can confirm.

Kaiserludi

Hi @Kurtav.

Note that the ack will be a separate package that goes in the other direction from the receiver to the sender, to acknowledge that it has received your reliable package. When you are sending an unreliable message, not ack will be sent from the server to you to acknowledge its receival.
So you have one 80 bytes package from client to server and that's it. If your message would be reliable, then you would instead have a 76 bytes packet going from client to server + a 40 bytes packet coming back from server to client.

Note that Photon will combine multiple messages into a single packet if they are added to the sending queue between 2 send intervals and if they are small enough to result in a package that is below the maximum transfer unit (MTU) of a single packet. The 40 bytes for UDP header and init package header are only added once per packet, while the enet command header needs to be added once per command. Each message is always at least one command and a packet may contain multiple commands, but a command gets split up into multiple fragments if its size exceeds the MTU. Keep this in mind when you want to optimize the traffic that is created by your client.

Kurtav

https://www.photonengine.com/en-US/PUN/Pricing#plan-20

"500 Msg/s per Room"

how many there are in the mind, in bytes, size of the message? How was the formula of this limit calculated? She as I understood is connected with MTU

The 40 bytes for UDP header and init package header are only added once per packet, while the enet command header needs to be added once per command.

If I transfer vector3 to the OnPhotonSerializeView unreliable.
The first iteration OnPhotonSerializeView is 80 bytes
2 - n iteration OnPhotonSerializeView = 40 bytes?
If these commands do not have a large size, then if I combine them into one command, then I will save traffic?

void OnPhotonSerializeView(PhotonStream stream, PhotonMessageInfo info)
{
	if (stream.isWriting) //first option
	{
		stream.SendNext(command1);
		stream.SendNext(command2);
		stream.SendNext(command3);
		stream.SendNext(command4);
	}
	//second option - less traffic
	if (stream.isWriting)
	{
		stream.SendNext(command1+command2+command3+command4);
	}
}

Note that Photon will combine multiple messages into a single packet if they are added to the sending queue between 2 send intervals and if they are small enough to result in a package that is below the maximum transfer unit (MTU) of a single packet.

I understood correctly?

If I send large commands in a small amount -
The quickly comes later and the queue will be released for a long time
If I send small commands in large quantities -
The quickly comes faster and the queue will be released more quickly

but a command gets split up into multiple fragments if its size exceeds the MTU

What are fragments? Or it can be represented as - a huge command splits into several commands .The number of command headers is increasing and the queue is rapidly increasing when there are many commands that have more MTU