In
An in-memory network allows you to manufacture MockNodeMessagingServices for a set of participants. Each MockNodeMessagingService maintains a queue of messages it has received, and a background thread that dispatches messages one by one to registered handlers. Alternatively, a messaging system may be manually pumped, in which case no thread is created and a caller is expected to force delivery one at a time (this is useful for unit testing).
Parameters
defines the strategy to be used when determining which peer to send to in case a service is addressed.
Types
A class which represents information about nodes offering the same distributed service on the InMemoryMessagingNetwork.
Implement this interface in order to inject artificial latency between sender/recipient pairs.
A class which represents a message being transferred from sender to recipients, within the InMemoryMessageNetwork.
A class that provides an abstraction over the nodes' messaging service that also contains the ability to receive messages from the queue for testing purposes.
A class which represents information about an entity on the InMemoryMessagingNetwork.
How traffic is allocated in the case where multiple nodes share a single identity, which happens for notaries in a cluster. You don't normally ever need to change this: it is mostly useful for testing notary implementations.
Properties
Get a List of all the MockMessagingService endpoints
A stream of (sender, message, recipients) triples containing messages once they have been received.
A stream of (sender, message, recipients) triples containing messages once they have been sent by pumpSend.