[Feature request] PUN RPC message aggregation

Since OnPhotonSerializeView messages are already batched together, the framework must already exist.
Can you please add this feature to RPC calls as well? Specifically, multiple RPC calls sent in the same frame to the same target should be able to batch. This would reduce Msg/s counts drastically, at least for us, but I'm sure others would benefit from it as well.

Best Answer

Answers

  • Awesome! :)
    Please keep me updated!
  • Any news on this?
  • From which PUN version you stopped merge together OnPhotonSerializeView messages?
  • We didn't.
    But we introduced a limit how many views go into one message. The limit is admittedly arbitrary, as in: it's not based on actual data that's being sent but the idea is to avoid huge messages, which then have to be sent as fragments (which are reliable).

    How do you measure and what's the problem?
    Also: Which version do you use??
  • OneManArmy
    OneManArmy ✭✭✭
    edited March 2019
    Let's say i want to sync NPC's. Will be huge difference with/without batching messages together.
    Of course we can use RPC's for that, but why? It is more complicated for us.

    I did tests long time ago (on v1.76 (21. September 2016)), with RPC's (by manually batching together all data) and with OnPhotonSerializeView and result was similar. With OnPhotonSerializeView traffic was a bit higher. Now i tested on v1.90 (10. April 2018) and latest version. Also on latest PUN 2 version.

    To minimize impact on message count, you are forcing us to use RPC's.
    So my question - is there any difference for you?
    Traffic? Same/similar. Only difference is higher message count.

    Here is what i see:
    v1.76:
    5 clients and 50 NPC = 50 messages
    v1.90:
    5 clients and 50 NPC = 250 messages
  • To minimize impact on message count, you are forcing us to use RPC's.

    RPCs never aggregate, so this is misleading. If you aggregate all info into one RPC, that may work but obviously, you can do the same with a single PhotonView to send the complete update in intervals.

    If you really want to aggregate everything into one message, is another question. As said: Earlier PUN versions could create messages that were too big to send in one datagram (due to somewhat arbitrary MTU size). This meant that you intended to send something unreliable but it got turned into reliable fragments instead.

    While we are for aggregating data into less messages, I think that it's bad when we have to change the delivery mode for that.

    The PUN source is provided, so you can modify it. You could lift the "10 PhotonViers per update" rule and aggregate everything in one message. It's just not currently built-in.
  • OneManArmy
    OneManArmy ✭✭✭
    edited March 2019
    If previously with OnPhotonSerializeView there was some "automagic", then now it's simply more complicated. Don't take me wrong, I am not complaining. I simply wasn't aware about this change and I thought that it may be mistake.


    RPCs never aggregate, so this is misleading. If you aggregate all info into one RPC
    "with RPC's (by manually batching together all data)"
  • The change isn't very obvious and easily becomes buried in all the versions there are. I found it in the changelog, so at least I can say when it's been introduced:

    v1.79 (18. November 2016)
    Changed: PUN will no longer aggregate the data from ALL objects in a group into ONE message. Instead, a maximum of 10 objects will be sent together. The idea is to avoid huge messages, which need fragmentation. Fragmentation needs to be avoided, cause fragments are always reliable (and you basically lose "unreliable" updates when you send too much). There is a new variable for this: NetworkingPeer.ObjectsInOneUpdate.

    Let us know how you solve this situation and please ask whenever you need any input. It's good to have these conversations.