For Week W33-2016 C++ project, Fumanchu (Rui Figueira) is working on czrpc : Open Source C++ RPC framework.
He has been working as a fulltime game developer since 2007. Before moving to the UK to work in the games industry, he was working as a software developer in other areas.
He is a self-taught programmer and started coding at the early age of 13 or 14 on a ZX Spectrum 128k.
In 2016, he thought it was about time to start sharing the experience accumulated over the years, and thus started creating high-quality technical articles (some of which are featured on Gamasutra). Those articles can be found at his personal website(http://www.crazygaze.com).
- Bitbucket: https://bitbucket.org/ruifig
- GitHub URL: https://github.com/ruifig
Let’s learn more about the project from Fumanchu himself!
What is czrpc all about? Give us a brief.
czrpc is a C++ RPC framework that requires no code generation step, while still keeping a relatively small API.
A full feature list can be found at https://bitbucket.org/ruifig/czrpc, and a detailed implementation analysis here. (http://www.crazygaze.com/blog/2016/06/06/modern-c-lightweight-binary-rpc-framework-without-code-generation.)
Although that covers the first implementation, most of the key principles are the same.
What is the motivation behind the project?
czrpc started off as an experiment to see how a C++ RPC framework would look if using modern C++ features, and required no code generation step through the typical IDL (Interface Definition Language).
Also, the game I’ve been working on for the last few years (https://bitbucket.org/ruifig/g4devkit) gives players fully-simulated, little in-game computers, then can code for whatever they want. As such, there are a multitude of servers running, such as:
- Gameplay server(s)
- VM Server(s) – Simulates the in-game computers
- VM Disk Server(s) – Deals with the in-game computers storage, like floppies or hard drives
- Database server(s)
- Login server(s)
All these servers need to exchange data, and therefore the need for a flexible RPC framework.
Initially, I had a custom solution where I would tag method of a class with certain attributes. A Clang based tool would then run in a pre-build step, analyze the tags, and generate any clue code for the RPCs.
Although it worked for the most part, it was another tool to maintain, and it was a bit intrusive, since any code to be used by RPC needed to be aware of that.
So, czrpc evolved to replace the existing solution. With czrpc, I don’t need any tools running in a pre-build step.
Which language/framework/API did you use in your project? What are the reasons for choosing them? Any specific reason?
czrpc is purely built with C++, since it’s the language of choice for game development. Also, it doesn’t care for the possibility to communicate with other languages, or using different transports. The RPCs are sent purely as binary data, for performance and simplicity reasons.
What challenges did you encounter while doing the project?
The biggest challenge was to simplify the API, particularly the RPC table definition, so the API would be relatively simple, considering it doesn’t require code generation.
Also, making sure the API enforces correct RPC calls was challenging.
RPC calls are type-safe. If you try to pass the wrong parameters to a RPC, it will not compile.
Which feature of the project stands out?
Well, personally I would pick a few features, such as the no-need-for-code generation, type safe RPC calls, and the fact it is non-intrusive.
I know it’s not to everyone’s tastes. Some people prefer RPC frameworks with well-defined IDL files, support for multiple languages, and flexible encodings, such as Thrift.
But I focused on creating something purely for my needs.
The advantage is that czrpc is relatively lean with a small header file library (needs no separate compilation).
Did you start the project as a side project or a serious commercial project?
It started off as a side project. At work we use Thrift, so I wanted to see if I could create something leaner purely focused on my personal needs.
What is the current state of the project?
czrpc is already usable as is. I’m now in the process of writing documentation and creating more samples. Although I’m happy with current API, it might still change.
Also, the framework itself doesn’t enforce a way to send RPCs. If allows the users to specify their own transport class. At the moment, it provides a transport using Boost Asio (or standalone Asio). I might create a transport using BSD sockets, which probably will not be as good as Asio, but will be small and won’t have any dependencies.
As soon as I get the documentation and samples up, I’ll start replacing the RPC framework in my game with czrpc. That will serve as a proof of concept. I’m sure I’ll find some areas of improvement as I go.
If not complete, how much time do you think before the first version hits the market?
Documentation and samples should be up in a couple of weeks. Not much free time, unfortunately.
What’s your future plan? Or where do you see yourself in the next 5 years?
My plan is to keep working on the game and make it commercial. Hopefully, in 5 years it will be up and running, and with constant updates.
Lastly, what do you think about Livecoding.tv and its future?
I love the concept. I started streaming my coding sessions on Twitch, but Livecoding is so much better for this. I love the direction Livecoding is taking, building a community, making experts available in given areas, and creating a marketplace for those skills, all in one single website focused on coding.
Follow his channel and stream schedule to watch him next time he streams.