Serialization, a Request and Questions

OmegaGames

Hello, I have one question and one request this time

Firstly, I'm interested in the way you guys serialize Dictionary<byte, object>. The most efficient method I could determine was to add the byte keys to a stream, with the first byte being the amount of keys present in the dictionary, and then using BinaryFormatter to serialize the objects. Serializing the objects with BinaryFormatter was the only method I could find, I did not attempt xml serialization, and even protobuf-net by google couldn't serialize objects. However, this means that for each object the bandwidth cost is very high. BinaryFormatter, which is what I remember settling on the other day but cannot fully recall, produces large byte arrays when serializing objects.

My question is if the above estimation on how you guys handle serialization is true or if you serialize it in some custom way I've not determined. The reason I ask is because I want to know the cost of sending a package from the client to the server and if I should put my emphasis on reducing package size; if the dictionary is serialized like I could figure out then it won't have too great of a reduction by me reducing ints to bytes and such. Anyway, interested in your response.

Secondly I have a request. I'd like to have some documentation on the application and use of the different SendParameter members.

I guess I have more questions too.

• In my logfiles I see this thing like
  

  2014-01-16 23:54:53,359 [16] DEBUG ExitGames.Diagnostics.Counter.CounterBase [(null)] - Creating AverageCounter: Name=''

  
  Is it suppose to be empty? I don't really know what it is and there is a lot of them.
  
• Also, can I adjust this value in some way?
  

  6520: 23:54:53.018 - Adding TCP listener on :127.0.0.1: 5057 with a listen backlog of: 150

  
  If I understand this right it can only have 150 packets unserviced? Is that really enough? Can I adjust this?
  
• Also, clientside, there is an interface member of IPhotonPeerListener called DebugReturn. I've never seen this called. How, why and when is this called?
• Serverside there is a method in the PeerBase class called SetDebugString. It doesn't have a summary. What is this used for?
• Peerbase also has a method named Flush(). Should I ever call this manually; is this something that is called under the hood or can I use it to expedite a packet I've just queue up as an event or response?

Thank you in advance for enduring my lightning round of questions.

[Deleted User]

Hey,

that's a lot of questions Let me try to answer..

1. We are using a custom binary serialization, details are described here: http://doc.exitgames.com/en/photon-serv ... ryProtocol
Reducing the size of your data is ALWAYS a good idea, including the use of the smallest possible data types etc.

2. Documentation of the different Photon applications can also be found here: http://doc.exitgames.com/en/photon-server/ (Lite, LoadBalancing, MMO etc.) - are you looking for that?

3. SendParameter members are the following:
- reliable / unreliable: only used for UDP (we've built a "reliable" layer on top of the per se unreliable UDP - and you can turn it on or off per operation, as you should only use it when needed. For example, an authenticate request should be reliable, while frequent position updates may be unreliable).
- channel ID: also used for UDP. It makes sense to use different channels for reliable and unreliable data.
- encryption: can be turned on or off per operation as well. See details here: http://doc.exitgames.com/en/photon-server/Encryption

4. The "Creating AverageCounter" Name = " seems to be a misconfigured log message - I'll have a look and improve that in the next version.

5. The listen backlog of 150 is configurable in PhotonServer.config. Please check out /doc/Photon-configuration.pdf in your Photon SocketServer SDK package, where all settings are briefly explained.

For the backlog:

"The size of the listen backlog queue. This affects the number of connections that can be
established simultaneously; so, for example, if 151 clients attempt to connect at exactly the same
time then the last one could be rejected. Note that each connection establishment attempt takes
very little time and once the connection IS established the connection is not affected by the limit.
So you can set the value to 10 and still have 10,000 concurrent active connections as long as no
more than 10 attempt to connect at exactly the same time"

In general, we advise that you are going with the default settings, unless you have a very specific problem - and even than, it's often a better idea to work on the issue instead of using a workaround with some tweaked settings (because every "optimization" comes at a cost - memory / bandwidth vs. cpu load etc.).

6. The DebugReturn is called internally, whenever some debug output should be written - try to increase the log level for your clients and you should see something. Or head over to the .NET / PUN subforum, where our client developers will answer all your questions about client SDKs.

7. SetDebugString: Thanks's for the hint - we'll set a description. You can set a debug string for each peer that will be logged into the log file for Photon's native core (like Photon-Default-.. or Photon-Loadbalancing-... log) in case of exceptions. Just a method to pass information from the "higher" levels (managed applications) to the "lower" level when we needed to track some failures.

8. The Flush method is a way to override the default "DataSendingDelay", for UDP again. Explanation from the photon-configuration.pdf again:

The data sending delay is how long the server will wait to accumulate more data to send to the
client in the same datagram. A larger value can lead to fewer datagrams being sent as more data
can be put into a single datagram, however this also increases latency as the server waits longer
before sending responses. If using the 'standard' ENet code then data is accumulated until a call
to enet_host_flush() or enet_host_service()

However, the data sending delay is 5ms per default, so there is not much to gain from manual calls to the "flush" operation - it might be useful if you use longer send delays, however.

Hope this answers your questions - feel free to ask again if something is not clear.