Advertisement

A better way to communicate with relay server?

Started by January 07, 2016 11:51 AM
15 comments, last by Acar 8 years, 10 months ago

Is there a better way to communicate with a relay server than using sockets on windows?

There's two tasks you want simplified - structs serializing and network communication.

For serialization you might want to check google's Protocol Buffers.

For network stuff there's various solutions, covering different use cases. One of very simple libs is ZeroMQ.

Advertisement

Thanks for the reply. Although I would prefer a solution which doesn't require any dependencies other than windows API if possible.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa385096%28v=vs.85%29.aspx

InternetOpen followed by Connect / HttpOpenRequest / HttpSendRequest if you use HTTP(S). Can automatically use system proxy settings where required.

I'd like to understand more what the requirements of your "relay server" are, because I've seen that term used for different things.

What is it relaying from, and to?
What is the rate of communication?
Do you use any kind of authentication?
What kind of session management do you need?
Are there hard latency requirements?
enum Bool { True, False, FileNotFound };

Thanks for the reply.

It's basically a bridge between game server and oracle database.

Very often. Possibly more than 50 request per second.

I'm using blowfish encryption with hardcoded session keys.

Session management?

I would very much prefer the fastest communication possible.

Advertisement
That sounds more like an application server to me. Where do the requests to the database come from? Are there game clients that connect to this application server, and the server then issues database requests? Or are requests "stateless" in the sense of a web server -- new requests come in, and should be processed, without persistent connections?

When you say 50 requests per second, is that per user, or overall across all users? How many users at the same time?

Encryption with keys doesn't add security, because someone who has the client software will be able to extract the keys, and if that's all the security you have, they could then spoof any user they wanted.

Session management has to do with how users/clients authorize to the system, and how that authorization stays alive.

"The fastest communication possible" doesn't make much sense. Of course you shouldn't needlessly slow things down. The question here is more "is it more important that communication is reliable, or is it more important that, even if there is a hiccup on request X, request X+1 is hopefully not delayed."
enum Bool { True, False, FileNotFound };

Alright so let's say client wants to use an item. The packet goes to game server and gets unpacked. Then game server creates a statement like "opcode, user_id, item_id" and sends it to relay server. Then relay server updates sql procedure with those values and runs the query. Sends a result to game server depending on the query result. Then game server sends its response to client. I'm not very conserned with security between game server and relay server as relay server port will be closed to remote connections.

Who hosts the game servers? Do they run on machines that you control? If so, you don't need the relay server; you could just talk directly to the database from the game server machine. (Although a database proxy of some sort might still be useful for other reasons, such as failover or query introspection or connection pooling or whatnot.)

If users control the game servers (there is a "host game" option in the UI) then there really is no difference between a game "client" and a game "server" from the point of view of the database -- either is equally un-trust-worthy, and you need to somehow validate that the request is legitimate, before you turn it into SQL and talk to the database.
enum Bool { True, False, FileNotFound };

I'll be hosting the game servers. The reason I'd like to use a relay server is because game server already has heavy work so I'd like to keep database related and maybe some of the sessional client data on relay server and separate them into different machines in future if client amount demands it.

This topic is closed to new replies.

Advertisement