Photon Realtime and Application-Level Retries: Preventing Duplicate Event Execution

To prevent duplicate event execution in Photon Realtime during manual retries, the recommended pattern is to integrate a unique sequence number or transaction ID into the event data payload. Since RaiseEvent does not provide native application-layer deduplication at the OnEvent level, the receiver must track processed IDs manually.

The Sequence Number Pattern

p>While Photon's reliable UDP ensures delivery and order, it cannot account for application-level retries triggered when a network timeout occurs after the receiver processes an event but before the sender receives the acknowledgment. By adding a unique identifier to your event structure, you can implement idempotency.

1. Define a Schema: Wrap your event data in a class that includes a `long eventId or sequence number.
2. Maintain a Cache: The receiver should maintain a dictionary or hash set of recently processed event IDs per sender ID.
3. Validate in OnEvent: Inside the OnEvent handler, check if the incoming `eventId exists in the cache.
4. Execute and Store: If the ID is new, execute the logic and add the ID to the cache. If it exists, discard the event immediately.
5. Prune Memory: Periodically remove old IDs from the cache to prevent memory leaks, ensuring the history covers the maximum possible retry window.

Example Implementation

// Sender-side structure
public class GameEvent {
    public long SequenceId;
    public string Payload;
}

// Receiver-side OnEvent
void OnEvent(Event code, object[] message) {
    var ev = (GameEvent)message[0];
    
    if (processedIds.Contains(ev.SequenceId)) {
        return; // Duplicate detected, ignore
    }

    // 1. Execute critical game logic
    ProcessLogic(ev.Payload);

    // 2. Track the ID
    processedIds.Add(ev.SequenceId);
}

Assumptions and Uncertainty

This solution assumes your manual retry logic is triggered by an application-side timeout. If you are strictly using Photon's built-in reliable delivery without manual retry loops, the engine handles re-transmissions internally, and deduplication is only necessary if you are manually re-sending RaiseEvent calls due to perceived failures. I have assumed the frequency of events is low enough that a memory-based cache is feasible.