Help To Integrate Ice Into A Complicated Architecture
Can you please point me in the right direction for integrating ice into my complicated architecture please. I will describe it first and then state what I need.
I am writing a front end for a game engine to run in the browser. The back end sends pictures and sound to the front end browser, and then user sends key strokes and mouse movements through the browser to the backend, which are then processed.
Here is the basic architecture:
There is one game instance per running game, but only one back end server instance. Each game has an id which is known to the client, and is passed to the server to identify the game instance, for sending key and mouse commands.
It works the other way as well, the game instance knows it's ID which is back passed alongside picture frames and sound samples to ensure that they end up at the right front end client.
I am unfortunately bound to use the two tiered system, for reasons unrelated to Ice and I won't discuss them here.
Currently the transmission technology is SignalR, which works great for real time stuff like pictures and sound but I am sure you guys will agree is a horrible RPC framework.
This is where Ice comes in. I want to continue to use SignalR for realtime stuff like pictures, sound and keyboard but Ice for some of my RPC requirements.
Here are my requirements.
This is a .NET project written in C# and I followed your very good tutorial on getting started. The thing which is really tripping me up is the bidirectionality.
There are several choices I noticed such as Glacier2 router or manual configuration, can you please point me to one I should use?
I have the Ice-Demos from GitHub (https://github.com/zeroc-ice/ice-demos/tree/3.7/csharp/Glacier2/callback). Is that the best one to follow our should I consider another.
Please give me advice, as well, as to the best way to handle to the two hops. I was considering making a second Ice RPC call from the BackEndServer, is that wise?
Thank you for you help. This is a really complicated project and I left a lot out. If I am missing any vital information let me known.
You could check our Chat demo as well, check-out https://doc.zeroc.com/technical-articles
If using Glacier2, you should consider implementing a session manager in the backend server to be able to to track when the client is connected or not.
Thank you for your help.
One port per running game is not avoidable, for technical reasons outside the scope of the forum.
Knowing this, based on what you said, it sounds like bi-directional is the way right?
It is great that good libraries like yours are available for free online! Thanks for your hard work.0
It's hard to provide specific advice without knowing more about your architecture. In general, using Glacier2 will be simpler when a client has to communicate with multiple servers: it creates a session with Glacier2 and invocations from the clients will be routed to the different servers deployed behind Glacier2 by the Glacier2 router.
Using bi-dir directly is fine as well for simple client-server communications. It gets more complicated if the client has to talk to multiple servers as you will need to implement some kind of routing for requests if you want the client to only connect to a single server instance.1
Thanks for your advice0