Look, when I made some tests I figure out that, when I send one empty RPC (without arguments), Statistic window show that I send 60 byte and receive 38 byte at first time, and 40 send / 15 recieve each further RPC’s.
This is huge amount of data!
Yep, when I try to send RPC with some data, for example RPC with two Int variable. We know that Int is 4 byte. And Statistic window show the correct result: 48 byte send, 15 receive. Ok.
But what the 40 byte overhead of empty RPC?!
I start to thinking about develop some global RPC manager that will collect data and send it in one package. One empty RPC cost like 10 Int values, or 40 bool! If I should send only one Int, or even bool value, RPC looks totaly waste.
But before, maybe I don’t understand something?
Also I test default networkView sync, but empty package have a size of 25 byte (instead of 40 RPC’s), not very good improvement.
Do you know something about this? What about this situation on photon server, for example?
Try uLink and compare. I still believe it’s not as optimized as it should be (no string dictionary compression - for really common RPCs you might want one letter names hence) but AFAIK uLink’s protocol is a lot more efficient than Unity’s overall. I’ll try to publish a comparison some time.
overhead of RPCs is pretty much irrelevant as they should only be used for really infrequent actions which do not require a real-time response on the receiving end.
As compared to statesync, I presume you hint? As in particular, there are reasons for sometimes choosing unreliable RPCs over statesyncs since you have more control of when the former are sent.
Well, the breakdown between “RPC” and “State Sync” in Unity is really awkward, but more to the point:
There are no unreliable RPCs in the unity networking implementation.
You do not have more “control” over when they are sent, you might “call” them at a specific time, but they are buffered locally and then sent with everything else, X times per second. The same as OnSerializeNetworkView.
Ah that explains it. There are unreliable RPCs in uLink in addition to reliable ones, sorry for my unfamiliarity. Wonder how people can manage to develop a fast paced game without this feature… Guess they try to cram everything unreliable into statesync?
It’s a shame uLink advertising sucks so nobody is aware of its existence ^^