Fragmentation and Channels

Fragmentation

Bigger chunks of data (more than about 1kB) are not fitting into a single packet, so they are fragmented and reassembled automatically. Depending on the data size, this takes up multiple packages.

Be aware that this might stall other commands. Call service() or sendOutgoingCommands() more often than absolutely necessary. You can also check the debug output for "WARNING! There are x outgoing messages waiting in the local sendQueue !", which is triggered, if a sendqueue contains an unusual big amount of elements and means, that you probably do not call service() or sendOutgoingCommands() often enough to let Photon send all the packets out, which you are creating by triggering operations.

Sequencing

The sequencing of the protocol makes sure that any receiving client will dispatch your actions in the order, in which you have sent them. Unreliable data is considered replaceable and can be lost. Reliable events and operations will be repeated several times if needed, but they will all be dispatched in order without gaps. Unreliable actions are also related to the last reliable action in the same channel and do not get dispatched before that reliable data has been dispatched first. This can be useful, if the actions are related to each other.

Example: Your FPS sends out unreliable movement updates and reliable chat messages. A lost package with movement updates would be left out as the next movement update is coming fast. On the receiving end, this would maybe show as a small jump. If a package with a chat message is lost, it would be resent and would introduce lag, even to all movement updates, created after that chat-message. In this case, the data is unrelated and should be put into different channels, to avoid that a needed resent of a chat message introduces lag into the movement updates.

Channels

Photon is supporting "channels". This allows you to separate information into multiple channels, each being sequenced independently. This means, that operations and events of one channel will not be stalled because events of another channel are not available yet.

By default a PhotonPeer has an amount of getChannelCountUserChannels() user channels and channel zero is the default channel, which will be used, when not explicitly specifying a channel. Operations join and leave are always sent in channel zero. There is a "system" channel 255 used internally for connect and disconnect messages. This channel is ignored for the user channel count.

Channels are prioritized: Data, to be send on the lowest channel number is put into an UDP package first. Data, which will be sent through a channel with a higher number might be sent later when an UDP package is already full.

Example: The chat messages could be sent in channel one, while movement is sent in channel zero. They are not related to the movement and if a chat message is delayed, it will no longer affect movement in channel zero. Also, channel zero has higher priority and is more likely to be sent immediately (in case packages get filled up).