Crate reactive_messaging
source ·Expand description
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-retrylib - 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
- Re-exports of types useful for users of this crate
Macros
- Instantiates & allocates resources for a GenericSocketClient, ready to be later started by spawn_unresponsive_client_processor!() or spawn_responsive_client_processor!().
Params: - Instantiates & allocates resources for a GenericSocketServer, ready to be later started by spawn_unresponsive_server_processor!() or spawn_responsive_server_processor!().
Params:
Structs
- Real definition & implementation for our Socket Client, full of generic parameters.
Probably you want to instantiate this structure through the sugared macro new_socket_client!() instead. Generic Parameters: - Real definition & implementation for our Socket Server, full of generic parameters.
Probably you want to instantiate this structure through the sugared macro new_socket_server!() instead. Generic Parameters:
Enums
- Represents a client built out of
CONFIG(au64version of [ConstConfig], from which the other const generic parameters derive).
Don’t instantiate this struct directly – use new_socket_client!() instead. - Represents a server built out of
CONFIG(au64version of [ConstConfig], from which the other const generic parameters derive).
Don’t instantiate this struct directly – use new_socket_server!() instead.
Traits
- Trait that should be implemented by enums that model the “remote messages” to be consumed by a “Responsive Processor” – “remote messages” may either be messages produced by the remote server or by the remote client (when we are implementing the opposite peer).
This trait, therefore, specifies how todeserialize()enum variants received by the remote peer (like RON, for textual protocols) - Trait that should be implemented by enums that model the “local messages” to be sent to the remote peer – “local messages” may either be messages generated by the server or by the client, depending on if you’re building a server or client.
This trait, therefore, specifies how to:
Functions
- RON deserializer
- RON serializer