How to cancel previous send messages from the queue?

nanda

i am sending a lot of data with in a second(for eg 50msg/sec) through photon cloud support in ios. Photon put all messages in a queue and sending the message. How can i cancel the messages in the queue?.
[Note: It takes lot of time to leave the room ,if they are lot of messages in queue?]

[Deleted User]

Hey Nanda,

unfortunately, there is no way to 'cancel' the messages currently queued.
The only way you could achieve this, would be to disconnect and reconnect.
This would clear the queues.
As a different approach I would suggest to find a way to reduce the number of messages you are sending per second.

Hope that helps.


Tim

Kaiserludi

Removing messages from the send queue is not currently supported (and it is not planned, to change this).

If there are still a lot of messages in the queue for the same channel, when the leave-message is added, then of course they will all be sent out before it.

You should also check your outgoing message queue.
If a lot of messages are waiting there and it takes a lot of time to send all those messages out, then this will produce a big lag and the messages will be quite old, when they finally go out.
You can approach this by calling service() or sendOutgoingCommands() more often.
You should also think about sending less messages, as 50 per second per client is a real lot. You probably won't recognize any negative influence onthe playability, if you just send less often. Afaik you game is mainly based on user input and I can't imagine any user triggering 50 actions per second, which would be 3.000 APM (even pro players at championchips have apms in the low hundreds).
With 50 operations per second per client and 10 clients per room you would also generate 500 events, received per client per second and 5.000 events going out from the server per second.
Eventually this could trigger your connectivity losses ingame, which you have from time to time.
Also the cloud indie license is restricted to 300 msg persecond per room, the pro one to 500 per second and room. this is not currently enforced, but as soon as it will be, your game could get into serious trouble with exceeding these limits by times of 10.


PS:
The approach of just sending all stuff in channel 1 and above to give leave (which will always be sent in channel 0) priority will work in that the client will indeed immediately leave the room, but it will produce a serious side effect:
If the player is joining the next room quick enough after leaving and the queue is full enough to not get compeletely sent until then, then the old stuff will still be sent after joining the next room. When using the LoadBalancing app (which is always the case when using the cloud), then it will still work due to sentQueue-clearing on server switches, when switching rooms, but your app should not count on this implementation detail. So please solve the source of the problem: just don't let your queue grow to more then a handfull of operations under normal circumstances, not only because of the delays on leaving, but also because of the big lag, that a too full sentQueue will produce.
So this approach is discouraged.

nanda

@Tim and @Kaiserludi : Thanks for your kind reply.

Kaiserludi

Hi nanda.
Please also pay attention to my just made edit, thanks.

nanda

@kaiserludi: As per guidance i implement my code, and so Now i can able to leave the room quickly . You have mentioned about calling the service() or sendOutgoingCommands() more often. Can you elaborate it where we need to implement it and what is the functionality of those methods?.

Kaiserludi

Please have a look at the .pdf in the docs folder of the client SDK therefor.

gnoblin

Kaiserludi wrote:

Also the cloud indie license is restricted to 300 msg persecond per room, the pro one to 500 per second and room. this is not currently enforced, but as soon as it will be, your game could get into serious trouble with exceeding these limits by times of 10.

Could you please show how to calculate the amount of msg per second in a game?
I don't really get it right now :?.

thanks,
Slav

gnoblin

For example let's say I have 12 players per room state syncing 10 times per second and sending 10 rpcs per second while shooting.
12*12 * (10+10) = 2880 messages per second

Do I miss something?

thanks,
Slav

Kaiserludi

One RPC will trigger one operationRequest from the calling client to the server (but no operationResponse back from the server) and for very other client in the room one event from the server to the client. opRequests, opResponses and events all count as messages.
In your example, you would have (1+11)*12*10 + (1+11)*12*10, which one can simplify to your formula from above -> 2880 msg/second is correct.

gnoblin

So what kind of games does the cloud target with 300 and 500 msg per second limit? :?

Kaiserludi

gnoblin wrote:

So what kind of games does the cloud target with 300 and 500 msg per second limit? :?

We are aware of the fact, that these are quite low limits for games with more than 4 players per room and that you practically can't call anything realtime, which is within these limits with lets say 16 players per room.
The reason for these limits is, that we have to draw a border somewhere, so that no one can come by and create a game with real huge amounts of messages per room and producing so much load, that we need thousands of servers just for him and accordingly have huge costs and then state, that he has a valid subscription for this kind of usage.
We are currently not enforcing these limits, but we monitor the situation. We currently won't kick you, if some of of your rooms exceed these limits, but if your avarage msg/s per room ratio is getting to much beyond these limtis, we will talk to you.
However we won't disallow anyone, to use the cloud, just because he needs higher limits, we just can't guarantee you, that you can get them for these low prices.
In fact we plan to make the option available of buying higher limits, when we are actually enforcing these limits. I can't give you any date therefor, nor can I already give you any numbers about the prices for higher limits. The only thing, I can say, is, that our price politics therefor will be similar agressive like it is now. It will NOT be like for example for 100CCU 9$ per month for 300, 19$ for 500 and then 190$ for 1.000.

Tobias

The 300 messages are per second and room.
In a 4 player room, this makes 75 messages per player.
If you attach a PhotonView to 8 objects, this might hit the cap but you could as well control 8 objects with one view and more clever usage of OnSerializePhotonView.