CAF: C++ Actor Framework

Version 0.13 of CAF has just been released. This release contains mostly improvements to core components, but also deprecates some parts of the API and removes previously deprecated parts. No cppa Headers The cppa headers were deprecated with 0.9 ... [More] and are now finally removed. In case you were using the old cppa::options_description API, you can migrate to the new API based on message::extract (see Section 18.4 of the Manual). IPv6 Support You can now use IPv6 addresses for remote_actor. Deprecate last_dequeued and last_sender Version 0.13 slightly changes the semantics of last_dequeued and last_sender. Both functions will now cause undefined behavior (dereferencing a nullptr) instead of returning dummy values when accessed from outside a callback or after forwarding the current message. Besides, the function names were not a good choice in the first place, since “last” implies accessing data received in the past. As a result, both functions are now deprecated. Their replacements are named current_message and current_sender. Pattern Matching Revised The pattern matching engine no longer accesses the RTTI system of CAF. This means that you no longer have to announce your messages as long as you use only the core component of CAF for in-process messaging and not use to_string. The main reason for this change was to reduce the amount of template instantiations and to make CAF more debugger-friendly. For example, consider the following simple CAF program: Prior to 0.13, this produces the following three stack traces (using c++filt and removing unwanted parts such as binary name): If you ever ran into a message handler with your debugger of choice, you had to filter through a lot of templates and CAF internals. Starting with 0.13 (and applying the same transformations), you will get these stack traces instead: There are still a few templates left, but overall it is much easier to understand what is going on. Whenever you pass a lambda without any prefix, you will get a trivial_match_case. Using the “on(...) >> ...” notation results in an advanced_match_case. Lastly, “others() >> ...” will produce a catch_all_match_case. The function apply_args takes a function or function object, a (compile-time) list of indexes, and a tuple. It then simply gets all values using the given indexes from the tuple and calls the function object. The lfinvoker is a simple helper that returns unit whenever your message handler would return void. Of course you will see a bit more CAF internals when using event-based actors, but the old match_case madness is gone for good. [Less]

Version 0.13 of CAF has just been released. This release contains mostly improvements to core components, but also deprecates some parts of the API and removes previously deprecated parts. No cppa Headers The cppa headers were deprecated with 0.9 ... [More] and are now finally removed. In case you were using the old cppa::options_description API, you can migrate to the new API based on message::extract (see Section 18.4 of the Manual). IPv6 Support You can now use IPv6 addresses for remote_actor. Deprecate last_dequeued and last_sender Version 0.13 slightly changes the semantics of last_dequeued and last_sender. Both functions will now cause undefined behavior (dereferencing a nullptr) instead of returning dummy values when accessed from outside a callback or after forwarding the current message. Besides, the function names were not a good choice in the first place, since "last" implies accessing data received in the past. As a result, both functions are now deprecated. Their replacements are named current_message and current_sender. Pattern Matching Revised The pattern matching engine no longer accesses the RTTI system of CAF. This means that you no longer have to announce your messages as long as you use only the core component of CAF for in-process messaging and not use to_string. The main reason for this change was to reduce the amount of template instantiations and to make CAF more debugger-friendly. For example, consider the following simple CAF program: Prior to 0.13, this produces the following three stack traces (using c++filt and removing unwanted parts such as binary name): If you ever ran into a message handler with your debugger of choice, you had to filter through a lot of templates and CAF internals. Starting with 0.13 (and applying the same transformations), you will get these stack traces instead: There are still a few templates left, but overall it is much easier to understand what is going on. Whenever you pass a lambda without any prefix, you will get a trivial_match_case. Using the "on(...) >> ..." notation results in an advanced_match_case. Lastly, "others() >> ..." will produce a catch_all_match_case. The function apply_args takes a function or function object, a (compile-time) list of indexes, and a tuple. It then simply gets all values using the given indexes from the tuple and calls the function object. The lfinvoker is a simple helper that returns unit whenever your message handler would return void. Of course you will see a bit more CAF internals when using event-based actors, but the old match_case madness is gone for good. [Less]

Version 0.12 of CAF has just been released. This release adds FreeBSD 10 to the list of supported OSes but removes two features from CAF: (1) type names are no longer demangled automatically, and (2) .continue_with is no longer supported. The former ... [More] change is due to the fact that there is no standard-compliant way to retrieve the original, i.e., "unmangled", type name from std::type_info. Some compilers allow you to restore type names at runtime. For example, GCC and Clang support a C ABI to invert the mangling operation. However, this function is broken on FreeBSD and is not offered on all platforms. After much consideration, we have thus decided to remove the automated demangling completely. As a consequence, announce() now takes the type name as first argument, i.e., announce<my_class>(...) becomes announce<my_class>("my_class", ...). The .continue_with feature has been removed mainly due to its runtime overhead. Since this overhead was added to each sync_send operation, we have decided to drop this feature in favor of a better overall system performance. For a list of bugfixes and improvements, please read the release notes on GitHub. [Less]

Version 0.12 of CAF has just been released. This release adds FreeBSD 10 to the list of supported OSes but removes two features from CAF: (1) type names are no longer demangled automatically, and (2) .continue_with is no longer supported. The former ... [More] change is due to the fact that there is no standard-compliant way to retrieve the original, i.e., "unmangled", type name from std::type_info. Some compilers allow you to restore type names at runtime. For example, GCC and Clang support a C ABI to invert the mangling operation. However, this function is broken on FreeBSD and is not offered on all platforms. After much consideration, we have thus decided to remove the automated demangling completely. As a consequence, announce() now takes the type name as first argument, i.e., announce(...) becomes announce("my_class", ...). The .continue_with feature has been removed mainly due to its runtime overhead. Since this overhead was added to each sync_send operation, we have decided to drop this feature in favor of a better overall system performance. For a list of bugfixes and improvements, please read the release notes on GitHub. [Less]

Version 0.12 of CAF has just been released. This release adds FreeBSD 10 to the list of supported OSes but removes two features from CAF: (1) type names are no longer demangled automatically, and (2) .continue_with is no longer supported. The former ... [More] change is due to the fact that there is no standard-compliant way to retrieve the original, i.e., "unmangled", type name from std::type_info. Some compilers allow you to restore type names at runtime. For example, GCC and Clang support a C ABI to invert the mangling operation. However, this function is broken on FreeBSD and is not offered on all platforms. After much consideration, we have thus decided to remove the automated demangling completely. As a consequence, announce() now takes the type name as first argument, i.e., announce<my_class>(...) becomes announce<my_class>("my_class", ...). The .continue_with feature has been removed mainly due to its runtime overhead. Since this overhead was added to each sync_send operation, we have decided to drop this feature in favor of a better overall system performance. For a list of bugfixes and improvements, please read the release notes on GitHub. [Less]

In our new spotlight series, we present software projects that are based on CAF. The first project we want to highlight is the Massive Multiplayer Online (MMO) game Dual Universe. We talked to Jean-Christophe Baillie, founder and president of ... [More] Novaquark, the company behind the game. Background: Dual Universe Dual Universe is a science fiction, multi-planet world where "players are free to invent their collective destiny: civilizations will rise and fall, player-driven events will shape the course of history". The ambitious goal is to implement a persistent single-shard universe consisting of thousands of procedurally generated planets. Based on the Unreal Engine 4, Dual Universe strives to deliver beautiful and immersive environments. It will also be compatible with Oculus Rift. To see some of the impressive artwork and read more about the game, visit the official homepage. The first alpha release will hopefully be available in mid 2015. Scaling up a software infrastructure to simultaneously deal with millions of active players is a real challenge. To build this scalable infrastructure, the development team behind Dual Universe has selected CAF. The Interview CAF Team: Dear Jean-Christophe, thank you for giving us the opportunity for this interview. You are the founder and president of Novaquark, but given the relatively small team size of indie studios, we can imagine you are also deeply involved in the development process. Jean-Christophe: The team is currently 18 people, with 7 developers. I wrote a first prototype of the game two years ago, as well as the server architecture and scalability algorithms. Because our ambition has grown a lot since the beginning of the project, most of the original prototype has been rewritten, with the exception of the server architecture, which is still in operation. I currently supervise the technical developments, as well as the game design in general. CAF Team: Building an MMO is a very ambitious goal for an indie studio. What is the history behind and what are your plans for the future? Jean-Christophe: Yes, developing a MMO as an indie studio can sound a bit crazy! The important thing to see is that the design of the game is based on what is called "emergent gameplay": the players are going to create their world, their stories, and their destiny. Unlike other MMOs, we don't create tons of content like cities or quests, but we give the players a sandbox to create their own. This is making the project more feasible as we are more a tech company than a content company. As for the origin of the project: it's a very old gamer dream, something I've been thinking about for at least 6 or 7 years now. Dual Universe is a single-shard sandbox MMO taking place on hundreds of planets, where players are free to create their own economic or political systems, gathered in organizations and explore the procedurally generated world for resources and opportunities. Quite uniquely, they also are able to modify the voxel-based world: create cities, various scriptable constructs like vehicles, space ships or gigantic orbital stations. All players share the same "single shard" universe : there is only one persistent reality, giving birth to emergent organizations and player specialization around activities like building, politics, security, piracy, space colonization and exploration, logistics, harvesting, manufacturing or industry production. We hope that we will see civilizations rise and fall, empires and alliances unite or compete, in a totally open world where everything will be possible. CAF Team: How did you learn about CAF and what convinced you that it is the right tool for building your infrastructure? After all, this is a most critical business component. Did you try other frameworks before? Jean-Christophe: Originally, I was interested in scalable design patterns to create a robust and distributed server architecture. I knew about Erlang and got interested in the actor programming model. Erlang sounded great, but we finally decided to use Scala and Akka to build a first prototype of the architecture (the Java proximity sounded like a good way to stay connected to a rich ecosystem). It was very hard however to find good Scala developers and we quickly realized that finding a way to get the job done in C++ would make things much easier in terms of recruiting. But C++ is a very dangerous language to use for a server: it's not as safe, and does not provide native scalability and actor-based features like Scala/Akka does. We decided to take advantage of modern C++11 features and design patterns to try to avoid the typical memory management problems of C++ (plus tons of other issues), and I started to look for a good implementation of the actor model in C++. That's when I found libcppa, the old name of CAF, and started to test it. CAF is very close in philosophy to Erlang/Scala/Akka, and is based on sound C++11 programming, so we fell in love with it pretty quickly! CAF Team: What did you experience with CAF? How fast could you get productive? Did you have a long evaluation phase? Jean-Christophe: CAF was very easy to use, with well documented examples. I think my familiarity with the actor model was probably helping, I suppose the particular way of doing things might be more difficult to grasp if you are totally new to this approach. CAF Team: What technologies do you use beside CAF and what are your experiences in integrating CAF with other tools and frameworks? Jean-Christophe: We use an external middleware to handle network communications with processes not running CAF (mainly, the game client); we also deal with a few standard databases and external data stores. All of them behave with their own logic: synchronous vs. asynchronous, single or multi-threaded. We developed wrappers for those to keep the functional logic as much as possible in CAF actors. Each tool is specific, but we mainly use caf::brokers, and anonymous sends (anon_send) from the threads not managed by CAF to exchange data with the actors. CAF Team: Can you tell us about your scaling requirements? What is your experience (and expectation) regarding performance? Jean-Christophe: As I said, the novelty we try to bring to the market is the idea of a continuous single-shard universe. This means that we must be able to balance the computing load dynamically, whereas current MMO games balance it statically, depending on the player position in the game. CAF allows us to avoid dealing with low-level synchronization issues (data races, deadlocks, costly synchronization primitives) while enabling the logical architecture of our code. Furthermore, we leverage CAF network transparency to let actors communicate directly, whether in the same process or across our datacenter. This is a huge step towards fluid scalability, since it eases considerably the possibility to throw more hardware and increase the processing power linearly. So far, we are satisfied with the performance, and we plan to build large-scale stress tests to put even more pressure to our architecture. CAF Team: You have been using CAF for quite a while and started using it when it was still named libcppa. What was the first version you have used and what was your experience with the progress of CAF during that time? Jean-Christophe: I think the first version was libcppa 0.8. It was already fairly mature and reliable. We discovered small issues that were quickly solved in the next iterations and globally, I would say that the reactivity of the team has been very good. CAF Team: Final question: if you were to decide what the next feature of CAF would be, what would you have in mind? Jean-Christophe: I can think of a few, some of which are probably a bit below the scope of CAF! atom()s with more than 10 characters! when announce()ing a custom type, std::container should be announced too; or at least it would be nice to detect at compile-time that it cannot be sent as a message the ability to migrate actors between processes - though we are not sure if it would make sense - to further enhance dynamic scalability an easy way to view internal metrics, such as: number of messages handled per second, hotspots in the application, number of message waiting in a queue, etc. CAF Team: Thank you very much for this interview and we wish you and your team all the great success! Links Twitter: /dualthegame Facebook: /dualuniverse Linkedin: /company/novaquark [Less]

In our new spotlight series, we present software projects that are based on CAF. The first project we want to highlight is the Massive Multiplayer Online (MMO) game Dual Universe. We talked to Jean-Christophe Baillie, founder and president of ... [More] Novaquark, the company behind the game. Background: Dual Universe Dual Universe is a science fiction, multi-planet world where "players are free to invent their collective destiny: civilizations will rise and fall, player-driven events will shape the course of history". The ambitious goal is to implement a persistent single-shard universe consisting of thousands of procedurally generated planets. Based on the Unreal Engine 4, Dual Universe strives to deliver beautiful and immersive environments. It will also be compatible with Oculus Rift. To see some of the impressive artwork and read more about the game, visit the official homepage. The first alpha release will hopefully be available in mid 2015. Scaling up a software infrastructure to simultaneously deal with millions of active players is a real challenge. To build this scalable infrastructure, the development team behind Dual Universe has selected CAF. The Interview CAF Team: Dear Jean-Christophe, thank you for giving us the opportunity for this interview. You are the founder and president of Novaquark, but given the relatively small team size of indie studios, we can imagine you are also deeply involved in the development process. Jean-Christophe: The team is currently 18 people, with 7 developers. I wrote a first prototype of the game two years ago, as well as the server architecture and scalability algorithms. Because our ambition has grown a lot since the beginning of the project, most of the original prototype has been rewritten, with the exception of the server architecture, which is still in operation. I currently supervise the technical developments, as well as the game design in general. CAF Team: Building an MMO is a very ambitious goal for an indie studio. What is the history behind and what are your plans for the future? Jean-Christophe: Yes, developing a MMO as an indie studio can sound a bit crazy! The important thing to see is that the design of the game is based on what is called "emergent gameplay": the players are going to create their world, their stories, and their destiny. Unlike other MMOs, we don't create tons of content like cities or quests, but we give the players a sandbox to create their own. This is making the project more feasible as we are more a tech company than a content company. As for the origin of the project: it's a very old gamer dream, something I've been thinking about for at least 6 or 7 years now. Dual Universe is a single-shard sandbox MMO taking place on hundreds of planets, where players are free to create their own economic or political systems, gathered in organizations and explore the procedurally generated world for resources and opportunities. Quite uniquely, they also are able to modify the voxel-based world: create cities, various scriptable constructs like vehicles, space ships or gigantic orbital stations. All players share the same "single shard" universe : there is only one persistent reality, giving birth to emergent organizations and player specialization around activities like building, politics, security, piracy, space colonization and exploration, logistics, harvesting, manufacturing or industry production. We hope that we will see civilizations rise and fall, empires and alliances unite or compete, in a totally open world where everything will be possible. CAF Team: How did you learn about CAF and what convinced you that it is the right tool for building your infrastructure? After all, this is a most critical business component. Did you try other frameworks before? Jean-Christophe: Originally, I was interested in scalable design patterns to create a robust and distributed server architecture. I knew about Erlang and got interested in the actor programming model. Erlang sounded great, but we finally decided to use Scala and Akka to build a first prototype of the architecture (the Java proximity sounded like a good way to stay connected to a rich ecosystem). It was very hard however to find good Scala developers and we quickly realized that finding a way to get the job done in C++ would make things much easier in terms of recruiting. But C++ is a very dangerous language to use for a server: it's not as safe, and does not provide native scalability and actor-based features like Scala/Akka does. We decided to take advantage of modern C++11 features and design patterns to try to avoid the typical memory management problems of C++ (plus tons of other issues), and I started to look for a good implementation of the actor model in C++. That's when I found libcppa, the old name of CAF, and started to test it. CAF is very close in philosophy to Erlang/Scala/Akka, and is based on sound C++11 programming, so we fell in love with it pretty quickly! CAF Team: What did you experience with CAF? How fast could you get productive? Did you have a long evaluation phase? Jean-Christophe: CAF was very easy to use, with well documented examples. I think my familiarity with the actor model was probably helping, I suppose the particular way of doing things might be more difficult to grasp if you are totally new to this approach. CAF Team: What technologies do you use beside CAF and what are your experiences in integrating CAF with other tools and frameworks? Jean-Christophe: We use an external middleware to handle network communications with processes not running CAF (mainly, the game client); we also deal with a few standard databases and external data stores. All of them behave with their own logic: synchronous vs. asynchronous, single or multi-threaded. We developed wrappers for those to keep the functional logic as much as possible in CAF actors. Each tool is specific, but we mainly use caf::brokers, and anonymous sends (anon_send) from the threads not managed by CAF to exchange data with the actors. CAF Team: Can you tell us about your scaling requirements? What is your experience (and expectation) regarding performance? Jean-Christophe: As I said, the novelty we try to bring to the market is the idea of a continuous single-shard universe. This means that we must be able to balance the computing load dynamically, whereas current MMO games balance it statically, depending on the player position in the game. CAF allows us to avoid dealing with low-level synchronization issues (data races, deadlocks, costly synchronization primitives) while enabling the logical architecture of our code. Furthermore, we leverage CAF network transparency to let actors communicate directly, whether in the same process or across our datacenter. This is a huge step towards fluid scalability, since it eases considerably the possibility to throw more hardware and increase the processing power linearly. So far, we are satisfied with the performance, and we plan to build large-scale stress tests to put even more pressure to our architecture. CAF Team: You have been using CAF for quite a while and started using it when it was still named libcppa. What was the first version you have used and what was your experience with the progress of CAF during that time? Jean-Christophe: I think the first version was libcppa 0.8. It was already fairly mature and reliable. We discovered small issues that were quickly solved in the next iterations and globally, I would say that the reactivity of the team has been very good. CAF Team: Final question: if you were to decide what the next feature of CAF would be, what would you have in mind? Jean-Christophe: I can think of a few, some of which are probably a bit below the scope of CAF! atom()s with more than 10 characters! when announce()ing a custom type, std::container<type> should be announced too; or at least it would be nice to detect at compile-time that it cannot be sent as a message the ability to migrate actors between processes - though we are not sure if it would make sense - to further enhance dynamic scalability an easy way to view internal metrics, such as: number of messages handled per second, hotspots in the application, number of message waiting in a queue, etc. CAF Team: Thank you very much for this interview and we wish you and your team all the great success! Links Twitter: /dualthegame Facebook: /dualuniverse Linkedin: /company/novaquark [Less]

Version 0.11.2 of CAF has just been released. This release primarily resolves some issues with reference count management and adds an unpublish function. Read more on GitHub.

Version 0.11.2 of CAF has just been released. This release primarily resolves some issues with reference count management and adds an unpublish function. Read more on GitHub.

Version 0.11.2 of CAF has just been released. This release primarily resolves some issues with reference count management and adds an unpublish function. Read more on GitHub.