This is the core abstraction used across the Interledger.rs implementation.
Inspired by tower, all of the components of this implementation are "services" that take a request type and asynchronously return a result. Every component uses the same interface so that services can be reused and combined into different bundles of functionality.
The Interledger service traits use requests that contain ILP Prepare packets and the related
and asynchronously return either an ILP Fullfill or Reject packet. Implementations of Stores (wrappers around
databases) can attach additional information to the Account records, which are then passed through the service chain.
The following examples illustrate how different Services can be chained together to create different bundles of functionality.
SPSP Client --> ValidatorService --> RouterService --> HttpOutgoingService
HttpServerService --> ValidatorService --> RouterService --> BalanceAndExchangeRateService --> ValidatorService --> HttpOutgoingService
HttpServerService --> ValidatorService --> StreamReceiverService
A struct representing an incoming ILP Prepare packet or an outgoing one before the next hop is set.
A struct representing an ILP Prepare packet with the incoming and outgoing accounts set.
A service created by
Usernames can be unicode and must be between 2 and 32 characters.
The base trait that Account types from other Services extend. This trait only assumes that the account has an ID that can be compared with others.
The base Store trait that can load a given account based on the ID.
Core service trait for handling IncomingRequests that asynchronously returns an ILP Fulfill or Reject packet.
Core service trait for sending OutgoingRequests that asynchronously returns an ILP Fulfill or Reject packet.
Create an IncomingService that calls the given handler for each request.
Create an OutgoingService that calls the given handler for each request.
A future that returns an ILP Fulfill or Reject packet.