Hi all,
I'm not sure whether this is a bug, an architectural issue, or that maybe i'm just doing something wrong, but here is what I have discovered:
- when sending a hashtable TO the network (in an operation request for example), it must be the ExitGames implementation of a hashtable, because the System implementation is not serializable (by default).
- when sending a hashtable FROM the network (in an operation response or event), it again be the ExitGames implementation of a hashtable, for the exact same reason as above.
Now, the above would be okay if it were okay to use the ExitGames hashtable throughout your application (and try to avoid using the System implementation wherever possible, or at the very least where sending data is concerned). However there are two fundamental problems with this:
- the ExitGames hashtable exists as part of the client libraries... for example the Photon3DotNet.dll and Photon3Unity3D.dll libraries. This means that in order to use this hashtable within your server code you have to include these libraries within your application. This seems like an odd architecture to have to implement...?
- by default (and it doesn't look like you can change this...), the lower-level part of photon will convert your ExitGames hashtable to the System hashtable when it reaches the server end!!
It would be great to get some further clarification on this.
EDIT
After further investigation, namespacing was causing confusion in my code, causing it to use the wrong hashtable in certain scenarios. Fixing this has made the issue a little less obscure. To point out my further discoveries:
- the ExitGames hashtable can be serialized on the client, and deserialized on the server, but not the other way around!
- the System hashtable can be serizlized and deserialized on the server, but not at all on the client
So the ultimate way to make use of this is to:
- only use the system hashtable on server > client communications, and server > server communications
- only use the exitgames hashtable on client > server communications
Now that I know the above, I can tweak the architecture of my application accordingly. However, I am keen to know why things work this way, since it does make things seemingly more difficult than they need to be? For example, in my last project (build using v3 of the photon server sdks) this wasn't an issue, and we were able to use the system hashtable across the client/server, and build some nice functionality around that. Now though, we cannot build functionality that is shared between both the client and the server (when it comes to dealing with hashtables, which we plan to do alot)
I'm not sure whether this is a bug, an architectural issue, or that maybe i'm just doing something wrong, but here is what I have discovered:
- when sending a hashtable TO the network (in an operation request for example), it must be the ExitGames implementation of a hashtable, because the System implementation is not serializable (by default).
- when sending a hashtable FROM the network (in an operation response or event), it again be the ExitGames implementation of a hashtable, for the exact same reason as above.
Now, the above would be okay if it were okay to use the ExitGames hashtable throughout your application (and try to avoid using the System implementation wherever possible, or at the very least where sending data is concerned). However there are two fundamental problems with this:
- the ExitGames hashtable exists as part of the client libraries... for example the Photon3DotNet.dll and Photon3Unity3D.dll libraries. This means that in order to use this hashtable within your server code you have to include these libraries within your application. This seems like an odd architecture to have to implement...?
- by default (and it doesn't look like you can change this...), the lower-level part of photon will convert your ExitGames hashtable to the System hashtable when it reaches the server end!!
It would be great to get some further clarification on this.
EDIT
After further investigation, namespacing was causing confusion in my code, causing it to use the wrong hashtable in certain scenarios. Fixing this has made the issue a little less obscure. To point out my further discoveries:
- the ExitGames hashtable can be serialized on the client, and deserialized on the server, but not the other way around!
- the System hashtable can be serizlized and deserialized on the server, but not at all on the client
So the ultimate way to make use of this is to:
- only use the system hashtable on server > client communications, and server > server communications
- only use the exitgames hashtable on client > server communications
Now that I know the above, I can tweak the architecture of my application accordingly. However, I am keen to know why things work this way, since it does make things seemingly more difficult than they need to be? For example, in my last project (build using v3 of the photon server sdks) this wasn't an issue, and we were able to use the system hashtable across the client/server, and build some nice functionality around that. Now though, we cannot build functionality that is shared between both the client and the server (when it comes to dealing with hashtables, which we plan to do alot)