core.utilities.ANSIProgressRenderer |
Knows how to render a ProgressTracker to the terminal using coloured, emoji-fied output. Useful when writing small command line tools, demos, tests etc. Just set the progressTracker field and it will go ahead and start drawing if the terminal supports it. Otherwise it just prints out the name of the step whenever it changes. |
core.node.AbstractNode |
A base node implementation that can be customised either for production (with real implementations that do real I/O), or a mock implementation suitable for unit test environments. |
core.messaging.AllPossibleRecipients |
A special base class for the set of all possible recipients, without having to identify who they all are. |
core.node.services.ArtemisMessagingService |
This class implements the MessagingService API using Apache Artemis, the successor to their ActiveMQ product. Artemis is a message queue broker and here, we embed the entire server inside our own process. Nodes communicate with each other using (by default) an Artemis specific protocol, but it supports other protocols like AQMP/1.0 as well. |
core.node.servlets.AttachmentDownloadServlet |
Allows the node administrator to either download full attachment zips, or individual files within those zips. |
core.node.services.AttachmentStorage |
An attachment store records potentially large binary objects, identified by their hash. Note that attachments are immutable and can never be erased once inserted |
core.node.servlets.AttachmentUploadServlet | |
core.utilities.BriefLogFormatter |
A Java logging formatter that writes more compact output than the default. |
core.node.ConfigurationException | |
core.node.services.DataVendingService |
This class sets up network message handlers for requests from peers for data keyed by hash. It is a piece of simple glue that sits between the network layer and the database layer. |
core.node.services.E2ETestKeyManagementService |
A simple in-memory KMS that doesnt bother saving keys to disk. A real implementation would: |
protocols.FetchAttachmentsProtocol |
Given a set of hashes either loads from from local storage or requests them from the other peer. Downloaded attachments are saved to local storage automatically. |
protocols.FetchDataProtocol |
An abstract protocol for fetching typed data from a remote peer. |
protocols.FetchTransactionsProtocol |
Given a set of tx hashes (IDs), either loads them from local disk or asks the remote peer to provide them. |
core.node.services.FixedIdentityService |
Scaffolding: a dummy identity service that just expects to have identities loaded off disk or found elsewhere. |
core.node.services.KeyManagementService |
The KMS is responsible for storing and using private keys to sign things. An implementation of this may, for example, call out to a hardware security module that enforces various auditing and frequency-of-use requirements. |
core.messaging.LegallyIdentifiableNode |
Info about a network node that has is operated by some sort of verified identity. |
org.slf4j.Logger (extensions in package core.utilities) | |
core.messaging.Message |
A message is defined, at this level, to be a (topic, timestamp, byte arrays) triple, where the topic is a string in Java-style reverse dns form, with "platform." being a prefix reserved by the platform for its own use. Vendor specific messages can be defined, but use your domain name as the prefix e.g. "uk.co.bigbank.messages.SomeMessage". |
core.messaging.MessageHandlerRegistration | |
core.messaging.MessageRecipientGroup |
A base class for a set of recipients specifically identified by the sender. |
core.messaging.MessageRecipients |
The interface for a group of message recipients (which may contain only one recipient) |
core.messaging.MessagingService |
A MessagingService sits at the boundary between a message routing / networking layer and the core platform code. |
core.messaging.MessagingServiceBuilder |
This class lets you start up a MessagingService. Its purpose is to stop you from getting access to the methods on the messaging service interface until you have successfully started up the system. One of these objects should be the only way to obtain a reference to a MessagingService. Startup may be a slow process: some implementations may let you cast the returned future to an object that lets you get status info. |
core.messaging.MockNetworkMap | |
core.messaging.NetworkMap |
A network map contains lists of nodes on the network along with information about their identity keys, services they provide and host names or IP addresses where they can be connected to. A reasonable architecture for the network map service might be one like the Tor directory authorities, where several nodes linked by RAFT or Paxos elect a leader and that leader distributes signed documents describing the network layout. Those documents can then be cached by every node and thus a network map can be retrieved given only a single successful peer connection. |
core.node.Node |
A Node manages a standalone server that takes part in the P2P network. It creates the services found in ServiceHub, loads important data off disk and starts listening for connections. |
core.node.services.NodeAttachmentService |
Stores attachments in the specified local directory, which must exist. Doesnt allow new attachments to be uploaded. |
core.node.NodeConfiguration | |
core.node.NodeConfigurationFromProperties |
A simple wrapper around a plain old Java .properties file. The keys have the same name as in the source code. |
core.node.services.NodeTimestamperService |
This class implements the server side of the timestamping protocol, using the local clock. A future version might add features like checking against other NTP servers to make sure the clock hasnt drifted by too much. |
core.node.services.NodeWalletService |
This class implements a simple, in memory wallet that tracks states that are owned by us, and also has a convenience method to auto-generate some self-issued cash states that can be used for test trading. A real wallet would persist states relevant to us into a database and once such a wallet is implemented, this scaffolding can be removed. |
core.protocols.ProtocolLogic |
A sub-class of ProtocolLogic implements a protocol flow using direct, straight line blocking code. Thus you can write complex protocol logic in an ordinary fashion, without having to think about callbacks, restarting after a node crash, how many instances of your protocol there are running and so on. |
core.protocols.ProtocolStateMachine |
A ProtocolStateMachine instance is a suspendable fiber that delegates all actual logic to a ProtocolLogic instance. For any given flow there is only one PSM, even if that protocol invokes subprotocols. |
protocols.ResolveTransactionsProtocol |
This protocol fetches each transaction identified by the given hashes from either disk or network, along with all their dependencies, and verifies them together using a single TransactionGroup. If no exception is thrown, then all the transactions have been successfully verified and inserted into the local database. |
core.node.services.ServiceHub |
A service hub simply vends references to the other services a node has. Some of those services may be missing or mocked out. This class is useful to pass to chunks of pluggable code that might have need of many different kinds of functionality and you dont want to hard-code which types in the interface. |
core.messaging.SingleMessageRecipient |
A base class for the case of point-to-point messages |
core.messaging.StateMachineManager |
A StateMachineManager is responsible for coordination and persistence of multiple ProtocolStateMachine objects. Each such object represents an instantiation of a (two-party) protocol that has reached a particular point. |
core.node.services.StorageService |
A sketch of an interface to a simple key/value storage system. Intended for persistence of simple blobs like transactions, serialised protocol state machines and so on. Again, this isnt intended to imply lack of SQL or anything like that, this interface is only big enough to support the prototyping work. |
protocols.TimestampingProtocol |
The TimestampingProtocol class is the client code that talks to a NodeTimestamperService on some remote node. It is a ProtocolLogic, meaning it can either be a sub-protocol of some other protocol, or be driven independently. |
core.messaging.TopicStringValidator |
A singleton thats useful for validating topic strings |
demos.TraderDemoProtocolBuyer | |
demos.TraderDemoProtocolSeller | |
protocols.TwoPartyTradeProtocol |
This asset trading protocol implements a "delivery vs payment" type swap. It has two parties (B and S for buyer and seller) and the following steps: |
core.utilities.UntrustworthyData |
A small utility to approximate taint tracking: if a method gives you back one of these, it means the data came from a remote source that may be incentivised to pass us junk that violates basic assumptions and thus must be checked first. The wrapper helps you to avoid forgetting this vital step. Things you might want to check are: |
core.node.services.Wallet |
A wallet (name may be temporary) wraps a set of states that are useful for us to keep track of, for instance, because we own them. This class represents an immutable, stable state of a wallet: it is guaranteed not to change out from underneath you, even though the canonical currently-best-known wallet may change as we learn about new transactions from our peers and generate new transactions that consume states ourselves. |
core.node.services.WalletService |
A WalletService is responsible for securely and safely persisting the current state of a wallet to storage. The wallet service vends immutable snapshots of the current wallet for working with: if you build a transaction based on a wallet that isnt current, be aware that it may end up being invalid if the states that were used have been consumed by someone else first |