Crate reactive_messaging

reactive-messaging

Provides Stream-based reactive client/server communications focused on high performance – through sockets, shared mem IPCs and other goodies – async-powered by Tokio.

The distinct features of this library are:

• a thorough protocol modeling, with the help of Rust’s powerful enums;
• ease of logic decoupling by using reactive Streams for the client / server logic;
• the main network loop for both client & server is fully optimized;
• const-time (yet powerful) configurations, to achieve the most performance possible;
• zero-cost retrying strategies & dropping the connection vs ignoring on errors through const time configs & the keen-retry lib
• for version 1: only textual socket protocols are supported by now – binary & shared mem IPCs to be added later;

Taste it

Take a look at the ping-pong game in example/, which shows some nice patterns on how to use this library:

• How the ping-pong game logic is shared among the client and server;
• How the protocol is modeled;
• How to work with server-side sessions;
• How decoupled and testable those pieces are;
• How straight-forward it is to create flexible server & client applications once the processors are complete.

beta status

The API has been stabilized – new features yet to be added for v1.0:

• allow reactive processors to produce all combinations of fallible/non-fallible & futures/non-futures for responsive & unresponsive logic processors (currently, only Streams of non-fallible & non-future items are allowed)
• better docs
• clean the code for the ping-pong example and the recommended patterns for using this lib

Modules

• prelude
  Re-exports of types – out of the internal directory and module structure – useful for users of this crate

Macros

• _define_processor_uni_and_sender_channel_types
  For internal use: defines ProcessorUniType & SenderChannel based on the given [Channels] parameter (for use when spawning processors with [MessagingService::spawn_unresponsive_processor()] & [MessagingService::spawn_responsive_processor()].)
• new_composite_socket_client
  Instantiates & allocates resources for a stateful CompositeSocketClient (suitable for the “Composite Protocol Stacking” pattern), ready to have processors added by spawn_client_processor!().
• new_composite_socket_server
  Instantiates & allocates resources for a stateful CompositeSocketServer (suitable for the “Composite Protocol Stacking” pattern), ready to have processors added by [spawn_unresponsive_server_processor!()] or [spawn_responsive_server_processor!()] and to be later started by CompositeSocketServer::start_multi_protocol() – using the default “Atomic” channels (see [new_composite_fullsync_server!()] & [new_composite_crossbeam_server!()] for alternatives).
  Params:
• new_socket_client
  Instantiates & allocates resources for a stateless CompositeSocketClient (suitable for single protocol communications), ready to be later started by start_client_processor!().
• new_socket_server
  Instantiates & allocates resources for a stateless CompositeSocketServer (suitable for single protocol communications), ready to be later started by [start_unresponsive_server_processor!()] or [start_responsive_server_processor!()].
• spawn_client_processor
  Spawns a processor for a client (previously instantiated by new_composite_socket_client!()) that may communicate with the server using multiple protocols / multiple calls to this macro with different parameters – and finally calling CompositeSocketClient::start_multi_protocol() when the “Composite Protocol Stacking” is complete.
• spawn_server_processor
  See CompositeSocketServer::spawn_processor().
• start_client_processor
  Starts a client (previously instantiated by new_socket_client!()) that will communicate with the server using a single protocol – as defined by the given dialog_processor_builder_fn, a builder of Streams as specified in CompositeSocketClient::spawn_processor().
• start_server_processor
  Starts a server (previously instantiated by new_socket_server!()) that will communicate with clients using a single protocol – as defined by the given dialog_processor_builder_fn, a builder of “unresponsive” Streams as specified in CompositeSocketServer::spawn_processor().
  If you want to follow the “Composite Protocol Stacking” pattern, see the [spawn_composite_server_processor!()] macro instead.