mot
Destination for messages.
Destination for messages.
Host to connect to. Can be an IP address or a domain name. In the latter case, all records are tried sequentially in case of error.
TCP port to connect to.
Exception used as a cause when a connection was normally terminated by the counter party.
Mot client.
Mot client. Instantiate this class to create a client-side Mot protocol engine.
A "client flow" is an abstraction created to enable selective flow control, which is a way to ask the server in the other side to stop sending responses of a certain kind.
A "client flow" is an abstraction created to enable selective flow control, which is a way to ask the server in the other side to stop sending responses of a certain kind. The need for selective flow control comes when the client can receive back-pressure using some subset of the responses. Proxy servers are a prototypical case: when sending the responses to the front-end, some clients can slow down (the slowness can come from the themselves or from the network) and the proxy must either buffer the data, discard it, or tell the back-end to stop sending it.
If there is no need to be selective, there is no need of explicit flow control, as it is simpler to rely on TCP for that (not reading, and causing "zero window" notifications). This is the most common case.
Instances of this class are created by the Mot client, and are used opaquely: each request is associated with a flow (which defaults to the main flow). The client can then use the flows (of which it must keep references) to stop responses selectively: "closing" a flow instructs the server to do not send the responses of the messages that were associated with that particular flow. If flow control is not used, there is only one instance of this class, which is always created (the "main flow" with id 0).
This mechanism only applies to responses. Requests do not need it, as it is always possible to respond them with an application-level indication to stop. This is not the case with responses, which could only be discarded. (In the proxy case, additionally, it would be impossible for the front-end to know in advance which is the final target of a request).
It is also worth mentioning that no response is stopped half-sent: Mot is a small-message protocol and each message (that cannot use more than one frame) is always sent entirely o not at all.
Mot context.
Mot context. Instances of mot.Client and mot.Server need to be associated with a context.
Exception that mix this trait are used as a cause when a connection was terminated (somehow) by the counter party.
Exception thrown when the client could not establish a connection and the tolerance period is exceeded.
Represent an incoming message to a Mot server.
Represent an incoming response to a Mot client.
Represent an incoming response to a Mot client. It can also represent a failure sending a message.
Exception thrown by the server when trying to responde a message over an already closed connection.
Exception use as a cause to signal the cases when the client or server was locally closed.
A Mot message.
A Mot message. This class represents Mot messages, either outgoing or incoming. In order to construct an instance, one of the factory methods of the companion object must be used.
Exception thrown when trying to send a message bigger than the counter party would accept.
Trait that represents Mot parties, either Client or Servers.
Exception thrown when trying to response an unrespondable message.
Exception used as a cause when a connection was abnormally terminated by the counter party.
Instances of this class are created by server-side parties as handlers for responding messages.
Instances of this class are created by server-side parties as handlers for responding messages. Each respondible request has one distinct instance.
Exception thrown when trying to response the same message twice.
Exception use as a cause to signal the cases when the response of a message timed out.
Mot server.
Mot server. Instantiate this class to create a server-side Mot protocol engine.
Instances of this class represent a server-side flow.
Instances of this class represent a server-side flow.
A trait containing a method to be called in the case of a fatal error in the Mot implementation.
A trait containing a method to be called in the case of a fatal error in the Mot implementation. This errors would be in fact bugs and will not happen, in theory. In case they happen in practice, this trait is used to define what to do. Reasonable behaviors are logging with an error level or (if appropiate) crashing the process.
Package that contains the classes that represent Mot frames.
Main package for Mot implementation. User-facing classes reside directly in the top-level package, with utility classes residing in the mot.util sub-package. The rest of the sub-packages contain implementation classes.