3 replies to this topic

[plopo]

Hello all for my first post after a long time lurking,


I am currently writing up a small game "engine", as a hobby really. Nothing that will make me rich or anything. Consider it a way to mix personal passion with a positive impact on my professional life. Personal research

So this "engine" is being written for browser-based gaming:

* client-side: websockets, webGL, and lots of Javascript (as you may have probably guessed).
* server-side: stackless python, the stackless implementation of sockets, and a bit of memcache(d). The engine is action-driven, i.e., actions between entities define the way the game can behave. I've tried to make the thing flexible and easy to update/change by having those dynamically loaded upon server startup.

Client and server are talking over websockets, using an obfuscated protocol. The defined language is still very .. err ... primitive right now, but grammar is being worked on.

What I am looking for is ideas, suggestions on how to implement the following:

* server-side only protocol: given the nature of stackless python, ingame "objects" talk to each other by sending stuff over channels. This happens "in-process" only.
* client-server protocol: this is what gets sent over the wire.

Now, I _would like_ the two protocols to be similar in nature, i.e., to share the same syntax/grammar. For ease of maintenance, enhancements, and the overall maintainability and beauty of the whole.

Would that be a good idea? Efficient or horribly not so? For which reasons?

Many thanks for your input!

Plopo

[TheNut]

This is a huge and domain specific problem. I can't give you any direct solutions, but I can recommend you look-up using JSON as a potential data transmission format and avoid deliberately "obfuscating" your protocol. Throughout development, use a readable protocol to make tracing and debug issues easier. You can write code or tools to optimize and minimize transmission data for your release builds.

[alphadog]

What are you doing to secure the client, and communications between the client and server?

And, as for TheNut's suggestion, JSON is still verbose, but less so than the atrocious idea of XML. Also, one thing people don't see at first is the tree-based structure of JSON and XML. This can be a problem at times if your data is highly inter-related. The good thing is the wealth of tools and libraries for it. I'd consider YAML along with JSON.

Or, look at something more efficient, like protobuf or Thrift.

[plopo]

Hello and thanks for your answers.

To secure the client:

. php login, nothing fancy, with PDOs and sanitization.
. php writes to memcache, that info has a temporary lifetime there.
. now the issue was to bridge the PHP world with the python world. So upon Websocket fire-up, the client sends information, whose validity is checked by the python server, via accessing the stuff in memcache. If ok, allow client to request for more things (world loading, engine init, etc.) over that websocket.

Dunno if it's perfect. It's not my speciality. Then again if it was, I wouldn't be around here asking advice/ideas.

About the protocol: it is fully hexadecimal (+ascii control characters). I'm using this as it lends itself nicely to:

. One-time passwords
. XORing, on a client basis, anything that gets sent on the wire. That _may_ also have a lifetime shorter than socket life (a few client-sent commands, maybe). But then is raised the option of history logging server-side versus freshness of the client elements that it uses to "asks" things from the server (hope that makes sense).

I _believe_ (or would like to believe, heh ) that this wil make the protocol reasonably secure.

I wanted to do something else than:
. XML: heavy, verbose. Big no-no since the very start indeed.
. JSON: more light-weight, faster to parse via .parse() - but I've seen too much of it after 11+ years of working in the web industry.

If the hex seems like a good direction, I will actually revert to a "clear" protocol, one that will indeed be easier to read (and debug ). And then go back the hex way to makes things lighter.

The one thing I like a lot about hex is its weight. 60-80 bytes for a full message sounds very nice to me.

Cheers.