Archived

This forum has been archived. Please start a new discussion on GitHub.

Help To Integrate Ice Into A Complicated Architecture

Hello Experts,
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:
JavaScript -> Back End Server -> Game Instance

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.

I need the JavaScript client to be able to make an RPC call to the backend server, and then again to game instance for initialisation. This will include a large blob of save data (a few mbs) which is sent to game instance for loading.

Secondly the server must be able to callback to the JavaScript, via the backend server. This is because after the game instance has conducted a save operation it must pass the data back to client for storage. If possible I need a return value back from the JavaScript, just a simple true or false, because if the client failed to save, for example if it ran out of storage, the game instances needs to know so as to not commit the save data to it's own cache.

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.

Comments

  • benoit
    benoit Rennes, France

    Hi,

    You could check our Chat demo as well, check-out https://doc.zeroc.com/technical-articles

    If your JavaScript client needs to call on both the back end server and the game instance directly, using Glacier2 is probably best. You won't have to worry about the setup of the bi-directional connection on the server-side.

    If all the communication has to go though the back end server first with this back end server relaying the invocations to the game server, you could eventually not use Glacier2 and use a bi-directional connection between this backend server and the JavaScript client. This implies that all the communication will have to go through the backend server and you'll need to take care of relaying the invocations in the backend server. It's definitely not as simple.

    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.

    Cheers,
    Benoit

  • Thank you for your help.

    My architecture is the latter, the backend server relays data between the JavaScript and the game instance.

    I am bound to do this, otherwise I would have to a million ports open to the internet if I wanted the JavaScript to talk to the game instance directly, as there is one per running game.

    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.

  • benoit
    benoit Rennes, France

    With Glacier2, you don't necessarily need to go through the backend server for Ice invocations. Your JavaScript client could directly invoke the Game instance server by going through Glacier2 without having to go through the backend server. Glacier2 will only listen on a single port so this means you would have to expose only two ports to clients: the Glacier2 port and the backend server port.

    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.

  • Thanks for your advice