Hash table inside of a dictionary?

void.pointer
edited July 2010 in Photon Server
I can't remember if it was for operations or events (or even both), but I recall seeing the server-side MMO classes requring a "properties" hash table be nested in the dictionary of params. I also noticed that the dictionary had a requirement on the ID and number of params that you send. What I'd like to know is why a hash table is being nested in the dictionary instead of simply adding to the params dictionary directly. Any comments/explanations? Thanks in advance.

Comments

  • Using a hash table allows greater flexibility for client developers. You can definitely change this to multiple operation params, but you would have define a parameter key for each value.
  • Boris wrote:
    Using a hash table allows greater flexibility for client developers. You can definitely change this to multiple operation params, but you would have define a parameter key for each value.
    How does this add flexibility?
  • key based datacontainer that supports any of the supported datatypes.

    has the benefit that you can send on the whole datacontainer on receive to process it where its meant to be used, you don't have to create one on the fly from a freeform amount of parameters and you don't have to send on the whole event data either.

    in the end though it depends on what to achieve to see how much sense it makes. there are definitely cases where the key based nature is very powerfull and important
  • ...I recall seeing the server-side MMO classes requring a "properties" hash table be nested in the dictionary of params. I also noticed that the dictionary had a requirement on the ID and number of params that you send. What I'd like to know is why a hash table is being nested in the dictionary instead of simply adding to the params dictionary directly...

    You almost answered this yourself.
    Any rpc operation has a set of parameters - equivalent to the signature of a function. Each parameter has an id key (byte). If you want to send a string as parameter value, it gets stuffed into a hash/dictionary with the byte-key of the parameter it should populate. Example: you want to send an event and make it key 11.
    So, the nested properties hashtable is a value for some parameter of some rpc operation.
    The good thing about nesting the event content as hashtable is that it's self-contained: the event keys and values don't mingle with other parameters (of the operation) you might be sending. In the nested hashtable you could re-use key 11 without problems.

    This nesting makes sense if you want to send arbitrary data but don't want it to interfere with your operation parameters.

    Hope that helps.
  • Slightly unrelated question:

    I noticed that Mmo.Item has a hashtable stored inside of it and also requires one as a construction parameter. This seems to be stored in the Properties property. First, why does Item keep track of this hash table itself? Does it do anything special with it?

    Secondly, and this partly answers my first question, why is Item.SetProperties() so complex? It does versioning, but the most confusing thing is the "properties to unset" ArrayList that it takes as a second parameter. Why is versioning necessary and why is it "unsetting" keys in the hash table? Is this so you can only change/remove the properties you're interested in without affecting the whole hashtable at once?
  • when a client interest area subscribes to an item it sends the ItemSubscribed event to the client.
    This event contains the properties revision number.
    If the client hasn't seen the item before it has to ask for the properties with the GetProperties operation.
    If the client has seen the item before it calls GetProperties only if the properties revision number is greater than the known properties revision.
    When you change properties with SetProperties the subscribed clients just get the changes, not the full properties set.
    Does this answer your question?
  • Thanks for your answer. One minor follow up question...

    In MmoActor.ItemOperationGetProperties(), you seem to be sending the entire properties hash table back with your response and not just the parts that changed. Is this the case? If not, can you explain how it is determining which parts of the hash table to send?
  • GetProperties sends the whole hashtable, because we don't keep track of every single change and we wouldn't know what changed since the last known revision. The event ItemPropertiesSet contains just the changes, and this is sent to subscribers with operation SetProperties. Subscribers already know the complete properties set (they called GetProperties before) so they only need the changes.