OperationResult's Hastable is a <byte, obj> or <short,obj>?

lazalong

Hey

I am trying to send an operation and get the result. The doc & api says that you can use an Hastable<short, object> to send parameters.
public OperationResponse(OperationRequest request, int errorCode, string debugMessage, Dictionary<short, object> retVals);


So I tried to respond to an operation with:

OperationResponse IOperationHandler.OnOperationRequest(
  Peer peer, OperationRequest operationRequest)
  {
    _logger.Debug("Operation...");
    var param;

    param =  new Dictionary<short, object> 
             {{ (byte)100, "Some text" } };
    // param =  new Dictionary<short, object> 
    //         {{ (short)100, "Some text" } };
    // param =  new Dictionary<short, object> 
    //         {{ (short)555, "Some text" } };

    return new OperationResponse((operationRequest, 0, "Ok", param);
}

All three don't throw an error when sending but it's on the receiving part I got stuck.
To receive the result the doc only state that we receive an Hastable:

void OperationResult(byte opCode, int returnCode, Hashtable returnValues, short invocID);

void IPhotonPeerListener.OperationResult(byte opCode, 
        int returnCode, Hashtable returnValues, short invocID)
    {
        var debug = (string)returnValues[(byte)100];        OK 
        // var debug = (string)returnValues[(short)100];  KO
        // var debug = (string)returnValues[(byte)555];   KO can't convert short to byte

        Debug.Log(debug);
    }

Only the (byte) 100 will work !!!

- Can we use only (byte) hence limited to 127 values? If yes, it's probably enough values but the api is misleading IMO.
- Or is it a shortcoming of me using Microsoft Visual C# 2008 Express edition?

Thanks.

Tobias

You are right, this is a misleading part of the server API. As of today, only bytes are supported as operation parameters and return-value keys.
The server should inform you about unsupported keys (when you send a key 555, e.g.) in the log. On the client side, return-value keys are byte, so a comparison to short will fail.
Background: We wanted to be open for short-typed keys but in the end decided against it. This part is (still) in the API.

You can use (nearly) all 255 values per Operation - they don't have to mean the same for all operations. If you re-use certain codes, it makes stuff easier.

Three keys are used by the framework and can't be re-assigned:
0 = error code
1 = debug message
60 = code (operation or event codes are stored in this key)

Sorry for the confusion.

lazalong

Small follow-up as I got a doubt.

Does this limit apply only to this case?
Or do all serialised hashmap need to be of the type <byte, objects>?

What would happen if I put a nested Dictionary<int, objects> or Hashmap with keys higher than 255 in a response?

Would this work?

    public class GetCharactersOperation : Operation
    {
        public GetCharactersOperation(OperationRequest request)
            : base(request) { }

        [ResponseParameter(Code = (short)ParameterCode.Characters,
            IsOptional = false)]
        public Dictionary<int,object> Characters { get; set; }
    }

and then add a character with an id of 343522 like this:

    GetCharactersOperation op = new GetCharactersOperation(request);
    op.Characters.Add(character.Id, character.GetHashtable());
    return op.GetOperationResponse(0, "Ok");

Also must the character.GetHashtable() also be limited to a <byte, object>?


Btw you know that Hashtables are deprecated.
Perhaps changing the api to Dictionary<byte, object> would make our code more solid as we would benefit from type safety at compile time

Tobias

Nested Hashtables can use any (serializable) type as key.
The limitation to byte keys exists only on the parameter-level. This way, the binary protocol saves the type-identifier per parameter code (and event and some other codes), making it more compact.

So, in an event's data hashtable, you can use integers or strings as keys. The drawback is that both require more bytes to send.

Yes, Hashtable is deprecated. Maybe we replace it with Dictionaries when we switch to Photon 3.0.