mot

Type Members

1. case class Address(host: String, port: Int) extends Product with Serializable

   

   Destination for messages.

   Destination for messages.

   host

   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.

   port

   TCP port to connect to.

2. class ByeException extends CounterpartyClosedException

   

3. class Client extends MotParty with StrictLogging

   

   Mot client.

4. class ClientFlow extends StrictLogging

   

   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.

   See also

   mot.protocol.FlowControlFrame

5. class Context extends AnyRef

   

   Mot context.

   Mot context. Instances of mot.Client and mot.Server need to be associated with a context.

6. class CounterpartyClosedException extends Exception

   

7. class ErrorStateException extends Exception

   

8. class GreetingAbortedException extends Exception

   

9. case class IncomingMessage extends Product with Serializable

   

10. case class IncomingResponse extends Product with Serializable

    

11. class InvalidConnectionException extends Exception

    

12. class LocalClosedException extends Exception

    

13. case class Message extends Product with Serializable

    

14. class MessageTooLargeException extends Exception

    

15. trait MotParty extends AnyRef

    

16. trait NoStackTraceException extends Exception

    

17. class NotRespondableException extends Exception

    

18. class ResetException extends CounterpartyClosedException

    

19. class Responder extends AnyRef

    

20. class ResponseAlreadySendException extends Exception

    

21. class ResponseTimeoutException extends Exception with NoStackTraceException

    

22. class Server extends MotParty with StrictLogging

    

    Mot server.

23. class ServerConnectionHandler extends AnyRef

    

24. trait UncaughtErrorHandler extends AnyRef