Complications with sending hashtables over the network
Options
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)
0
Comments
-
Which client SDK are you referring to? Please let us know the name and version of the SDK / Package you're using.
In general, the client-side Hashtable is needed for WSA clients. Some API versions for Windows Store did not have the Hashtable but we need it, so it's re-implemented based on a Dictionary.
As we have to use our own on some platforms, we decided to use ours always in Unity. So you code once and export to all platforms.
The server always gets a regular System.Hashtable. Always. It can also always send one and the client should get it (be able to read it).
0 -
As always, thanks for the response Tobias. that definitely clears up the reasoning behind the custom hashtable implementation.
I'm using the photon server sdk bare-bones (custom application) with the unity3d client library. I've tweaked everything to work as you guys have it set up (client will always use your hashtable, while the server will use the system hashtable) and it all works fine now.
It might be worth sticking up a section about this in the documentation page.0 -
> and it all works fine now.
That's good to read. Glad my info helped. I know it's not self explaining and potentially confusing.
It's mentioned somewhere in the readme.txt but not obvious enough. We will try to find a better place.
Hope you're now making good progress with the bare bones server
0
