sequence number?

orangeted
edited August 2011 in Photon Server
I couldn't find mention in the docs... is there a sequence number built into a Photon UDP packet? If so how do I access it (and where can i find the documentation)?

thanks

Comments

  • Copy and paste from the Photon Native Clients documentation pdf:
    1.5.1 Invocation IDs
    Invocation IDs
    Every event and operation that is transmitted through Photon will be assigned an id that is unique for the current game
    session. This way, the Photon Library is able to detect if operations have been lost or have been received multiple times
    because of network problems. This id is called the invocation Id (invocId). It is set to a random number during Photon
    initialization and will afterwards be incremented with each new operation.
    In most cases, the invocId is of no importance for the game developer. Anyway, there may be cases where a developer
    wants to make sure that a PeerReturn callback is triggered in reaction to a certain operation call (opJoin() , opLeave() or
    opRaiseEvent()) at a certain point of time. To do this, a developer can compare the invocId of an operation with the invocId
    of the operation that triggered the call of PeerReturn. For this reason, the invocId is the return value of all operation calls,
    and is also passed as a parameter in the PeerReturn callback.

    Is that the kind of feature, what you have been looking for?
  • yes, thanks.

    I'm intrigued by this comment though:
    In most cases, the invocId is of no importance for the game developer

    Isn't a sequence number essential for most action games? So a recipient peer can a) discard OOO packets if necessary and b) detect lost packets if necessary?
  • orangeted wrote:
    yes, thanks.

    I'm intrigued by this comment though:
    In most cases, the invocId is of no importance for the game developer

    Isn't a sequence number essential for most action games? So a recipient peer can a) discard OOO packets if necessary and b) detect lost packets if necessary?
    Well, as a Photon-user you will not have to touch the raw packets yourself. That low-level stuff is abstracted and not available in the API. There are just operations and events. These will internally be split up into multiple packets, if their size is so big, that this is needed, but this is completely handled by Photon and you do not have to care about it.

    Photon client APIs provide a servertime-property, so you can just add the servertime, when an operation has been sent, to that operation, and compare it to the servertime at the receiving client to decide, if the operation is outdated or up to date.

    Moreover, Photon guarantees, that all operations, which are sent in the same channel, will be received in the order, in which they have been added to the queue of operations, which you want to send (as long as they will be received at all), so if you are for example sending position updates every few milliseconds, there is no risk of getting older position updates from the same sending clients later than newer ones - if they are received in another order internally, than the order they have been sent, than the order will be corrected by Photon, before passing them to the callback-API, so you have not to care about this issue.

    Last, but not least, Photon provides not only unreliable udp, but also our own reliable udp implementation and tcp. Both, reliable udp and tcp, guarantee automatic internal resending of the packet, until either sending is successful or a connection timeout triggers, if a packet gets lost. So, use unreliable udp for data, for which you do not want resending and reliable udp for data, for which you want/need resending or use tcp, if udp isn't supported on that client-platform.

    However, it makes sense to read the chapters about fragmentation and about channels in the docs, to understand the behavior for operations consisting of multiple packets (this makes even unreliable operations reliable!) and to understand, how to use channels, to for example keep movement data uninfluenced from if a chat message has to be resent.