Event cache slicing

colm

Hello, i am interested in learning more about how the event cache slicing works. I am working on a project that will require data being passed back and forth as people leave and exit the room. I do not want to be dependent on Master client for this and would like to use event caching.

I have set it up using hashtables and it works great, I was wondering if there was some documentation or code snippets regarding slicing and grouping the cached events. Many Thank PS. I LOVE PHOTON!

Kaiserludi

Hi @colm.

Unfortunately the topic of cache slices is not currently covered by our docs.

So let me explain it to you below:

Slices are a grouping mechanism for cached events.

If you cache a lot of events, these will accumulate to quite a big amount over time and at a certain point their amount might just be so huge that the amount of data to process would simply overload any rejoining client. Hence you can use cache slices to split the event cache up into chunks.

All events that you sent with the cache option turned on will be stored in the current cache slice.
From time to time just increase the cache slice by 1, so that further events get stored in the next slice.

Once all your clients have acknowledged that they have received the information that the cache slice has increased, you know that they all have received all events from the previous slice and can delete it, as soon as the events inside that slice are no longer needed. This way you can just purge the events in that slice from the cache all at once.

On rejoining a room the joining client can then specify from which (not yet deleted) slice onward it needs the events to be repeated.

For example when a game uses some type of levels and a player that joins the room, while the players inside have already pushed the game to level 25, then the cached events from level 1-24 may not be relevant at all anymore for the new player, that joins the game in level 25, so there is no need to let the server send all those outdated events to him.

Slicing can be critical for long running games that cache lots of events.

Depending on the amount and average size of cached events the initial load of data that gets sent to late joiners may become that huge, that those new clients connections get struck dead by the pure massive amount of data that comes in all at once, although by far the majority of that data might not be relevant at all anymore.

Being able to group event in slices give you a tool to prevent this scenario by limiting the amount of data that clients receive when they join the room to only the data that is still relevant.



Finally, please note that after rejoining a room a client can just access the latest state of all room properties. So for any kind of information for which each client only needs the latest state and is not interested in any previous state anymore once it has the latest one, just store this information in room properties instead of sending it around as events.

colm

A very detailed and informative response, thank you very much

With regard to the 'cache slice', I assume this is a value that we create and use ourselves, sending it to the server in the hashtable, rather that it being apart of the Photon API. (I'm assuming this as I have never seen it in the docs), can you confirm? many thanks

Kaiserludi

Hi @colm.

With regard to the 'cache slice', I assume this is a value that we create and use ourselves, sending it to the server in the hashtable, rather that it being apart of the Photon API. (I'm assuming this as I have never seen it in the docs), can you confirm?

No. That is incorrect.

You would set the cache slice for each event that you send and that should be cached, via RaiseEventOptions.setCacheSliceIndex().
See https://doc-api.photonengine.com/en/cpp/current/a05602.html#a66bc119e647ab32005014bca617f765f.

opJoinRoom() and opJoinOrCreateRoom() both a have a parameter 'cacheSliceIndex', to specify the lowest cache slice index, you want to receive cached events for.
See https://doc-api.photonengine.com/en/cpp/current/a05522.html#a0989c3b651e46f90873c05e46a86fdea and https://doc-api.photonengine.com/en/cpp/current/a05522.html#af643e24fb61a69db1d57a7d94c229031.

colm

Thats amazing @Kaiserludi, Thank you very much.