Network agnostic: You provide it with input and receive output using whatever transport mechanism you prefer.  Typically this will be a TCP/IP connection.

Simple protocol: Though it has been developed for Ruby, the network protocol is extremely simple and should work well with any language that supports JSON encoded strings.

Easily modifiable: It was designed from the ground up to be modified both in code and in terms of protocol.  Prefer Message Pack over JSON?  Want to add compression?  All of these and more are easy to accomplish.

Messages and Requests:  Both messages (fire-and-forget) and requests (receive return values) are supported.  This covers the most common forms of communication over a TCP/IP socket.

Bi-directional: Both ends of a network connection are on equal footing once a connection is established.  This gives you great flexibility in designing your application.

Thread safe: Ruby threading has improved greatly over the last few years and is especially useful with JRuby.

It is very common in Ruby to use blocks and functional style programming to manipulate data.  The below example squares each element in an array and then removes the odd values:

[1,2,3,4,5].map { |i| i**2 }.reject { |i| i.odd? }

Such one-liners are an amazing feature of Ruby and very useful on the console.  Unfortunately, they can really start to break down in more complex situations.  This is where Filter Chain can be really useful.

Unlike in the above example, filters in Filter Chain are dedicated classes with a simple API.  This means each filter can easily have it’s own state, private helper methods, independent tests, and be reusable.  This is especially true for filters that include buffering, multithreading, and asynchronous IO.

CrossBridge is an amazing piece of technology that unfortunately receives little press.  In summary, it combines GCC with FreeBSD’s libc and allows you to compile C/C++ code to ABC bytecode.  Since ABC is the native bytecode for Adobe Flash and AIR, you end up with a version of Lua that can fully integrate with all of Adobe’s runtimes (mobile, desktop, and web).

The main use case for Easy Lua is to add Lua scripts to ActionScript based games.  I plan on using it to implement card game engines in Lua so that the engine can be used both on the client (single-player mode) and on the server (mutli-player mode).  This will mean less development time, more code reuse, and hopefully fewer bugs.

• Interactive console
• Logging
• Standard folder structure (very Rails like)
• Environments (development, production, etc)
• Generators
• Easy database access (via an add-on)

Totem and Totem – Activerecord seek to bring these and many other features to your non-Rails application.  Give it a try and feel free to contact me with your feedback.

Timers provide a way to tell an actor to do something in the future.  Tribe supports both one-shot and periodic timers so I believe all the major usage patterns are covered.  Adding this feature was fairly easy since all of the low level details are hidden in my Workers gem.

Futures make it easy for an actor to ask another actor to perform an operation and return the result.  Previously you would have to use custom events and a lot of boilerplate code to accomplish this.  Both synchronous (blocking) and asynchronous (non-blocking) futures are supported.  More information on both types can be found in the readme file.

The Task and TaskGroup classes make it even easier to parallelize expensive computations (and blocking IO operations) using background threads.  They build on top of worker pools and standardize on various features such as success/failure handling, delayed execution, and arguments.

Parallel Map is syntactic sugar built on top of tasks and task groups.  It works very similar to Ruby’s standard Array#map method except each element is mapped in parallel.

Pools are now dynamically resizable.  The long term vision for this feature is to experiment with auto-resizing algorithms that adapt to an applications load.  In the short term it is mostly useful for quickly changing the size of the default pool (currently set to 20 workers) without having to create a new one.

Tribe EM bridges the gap between Tribe and EventMachine.  Currently it provides basic TCP server functionality for Tribe actors.  My intent is to use this as a base for implementing higher-level protocols such as HTTP.

Tribe EM AMF Socket is a wrapper around my existing AMF Socket – Ruby gem.  Currently it only supports messages and not requests (RPC).  I believe this to be a reasonable limitation for now since AMF Socket messages fit in very well with Tribe’s asynchronous messaging system.

One key difference between the two gems is what I refer to as native vs wrapper implementations:

Native: The Tribe::EM::Connection class is considered native since it pushes the higher level protocol implementation onto the actor threads.  This results in greater scalability since actors take advantage of multi-core systems (especially on JRuby).

Wrapper: The Tribe::EM::AmfSocket::Connection class is considered a wrapper since it wraps the AMF Socket gem for use with Tribe.  This means that a lot of work (serialization, deserialization, framing, keep alives, etc) are all performed on the EventMachine thread.  The result is lower performance than a native implementation, but less coding since I can reuse the existing Ruby implementation of AMF Socket.

Both gem are designed to be easily customized.  Feel free to contact me with your custom protocol implementations so that I can add them to the Tribe EM homepage.

The Workers gem turns low-level operating system threads into simple to use event-driven workers and worker pools.  This allows you to focus on message passing instead of complex thread management.  As an added bonus, it includes a timer system that can tell your workers to execute work in the future.

The Tribe gem builds on top of Workers in order to implement the actor model. It specifically focuses on event-driven actors such that each thread manages one or more actors.  This way the system can support many more actors than is possible with implementations that force a 1:1 thread to actor relationship.  A simple benchmark demonstrating one million actors using 20 threads can be found on the performance wiki page.

Both gems have been tested with MRI Ruby 1.9.3 and JRuby 1.7.  Due to MRI’s thread limitations, it is highly recommended that you use JRuby if you are concerned about multi-core CPU performance.