SlideShow

Creating protocols

One of the building blocks of scalable applications

• Context; Protocols;

• Case studies: AMQP; SPDY; SST;

• Related work: UBF;

• Proposed solution:

  • Features; Responsibilities; Design;

  • Example; Implementation;

  (31 slides! have patience...)

Context

• networked entities ubiquity;

• Internet of Things;

• mOSAIC;

• web-services are not a panacea;

Protocols

• what:

  • semantic (rules -> verification);

  • syntax (format -> serialization);

  • means (transport);
• how to implement?

Case studies

• AMQP -- Advanced Message Queueing Protocol;

• SPDY;

• SST -- Structured Stream Protocol;

• SCP -- Session Control Protocol;

• BEEP;

• MUX;

AMQP -- Advanced Message Queueing Protocol

• AMQP:

  • fully functional interoperability between conforming clients and middleware servers;

  • defines a messaging model (i.e. entities, capabilities, etc.);
  • defines a network level protocol;
  • provides a protocol specification in XML (for code generation);
• references:

  • What is wrong with AMQP (and how to fix it);

  • AMQP 0-9-1 Specification;

AMQP -- Advanced Message Queueing Protocol (2)

• features:
  • virtual hosts;

  • independent, multiplexed channels;

  • command based approach;
  • data serialization format;
  • authentication and versioning;
  • layered architecture (transport, framing, brokering);

AMQP -- Advanced Message Queueing Protocol (3)

•     +------------------------+
      |      Application       |
      +-----------+------------+
                  |
      +------------------------+
  +---|      API Layer         |----Client API Layer-----+
  |   +-----------+------------+                         |
  |               |                                      |
  |   +------------------------+    +---------------+    |
  |   |   Connection Manager   +----+ Framing Layer |    |
  |   +-----------+------------+    +---------------+    |
  |             |                                        |
  |   +------------------------+                         |
  +---| Asynchronous I/O Layer |-------------------------+
      +-----------+------------+
                  |
               -------
       - - - - Network - - - -
               -------

SPDY

• SPDY:

  • a protocol designed for low-latency transport of content over the World Wide Web;

  • HTTP-like semantics for compatibility with existing HTTP application servers;

• references:

  • SPDY Protocol;

SPDY (2)

• features:
  • independent, multiplexed streams (uni- or bi-directional);
  • stream meta-data (i.e. headers);
  • session configuration (e.g. concurrency, bandwidth, etc.);
  • frame priorities;
  • stream flow-control;
  • authentication;
  • compression;
  • server-to-client streams;

SPDY (3)

SST -- Structured Stream Protocol

• SST;

• features:
  • independent, multiplexed streams;
  • hierarchical streams;
  • request / response pattern;
  • stream prioritization;
  • transport implementation over UDP;
• references:

  • Structured Streams: a New Transport Abstraction;

SST -- Structured Stream Protocol (2)

SST -- Structured Stream Protocol (3)

Related work

• UBF -- Universal Binary Format;

• generic protocol modeling:

  • SPIN / Promela;

• generic protocol parsers:

  • NetBee;

  • Ragel;

UBF

• UBF -- Universal Binary Format;

  • UBF(B) -- A protocol description language;

• features:
  • data transport format;
  • protocol type system;
  • protocol description language;
• references:

  • Getting Erlang to talk to the outside world (by Joe Armstrong);

UBF (2)

UBF (3)

• +NAME("file_server").
  +VSN("ubf1.0").
  
  +TYPES
  ...
  files()        = {files, [file()]};
  getFile()      = {get, file()};
  ...
  
  +STATE start 
         ls()      => files()     & start;
         getFile() => binary()    & start
                   | noSuchFile() & stop.
  
  +ANYSTATE
          info()        => string();
          description() => string();
          contract()    => term();

Proposed solution -- Features

• no special client / server roles (i.e. equal peers);
• multiple identities and protocols on the same endpoint;
• multiplexed, independent sessions;
• hierarchical, interdependent sessions;
• only message oriented sessions;
• arbitrary message exchange patterns;

Proposed solution -- Features (2)

• logical addressing;
• multi-part messages;
• eliminate handshake overhead;
• state-machine verification;
• code generators;

Proposed solution -- Responsibilities

• transport	-- no (1)
  framing	-- no (1)
  addressing	-- yes
  multiplexing	-- yes
  verification	-- yes (2)
  sequencing	-- yes
  flow control	-- maybe

• (1) these is provided by the transport layer;
• (2) can be disabled at run-time;

Proposed solution -- Responsibilities (2)

• prioritization	-- maybe
  segmentation / reassembly	-- no (3)
  error control	-- no (4)
  encryption	-- no (4)
  compression	-- no (4)
  encoding / serialization	-- no (5)
  authentication	-- no (5)

• (3) a whole message should fit into the transport layer limits (practically it should fit into memory);
• (4) this is the responsibility of the underlaying transport layer;
• (5) this is the responsibility of the application;

Proposed solution -- Design

Proposed solution -- Design (2)

Proposed solution -- Design (3)

• message ::= {
      type :: enumeration,
      case type of
          master-session-initiation-request ->
              initiator :: end-point,
              target :: end-point;
          nested-session-initiation-request ->
              nesting-session;
          {master,nested}-session-initiation-request ->
              protocol;
          {master,nested}-session-{initiation,termination}-{request,acknowledgment}, exchange ->
              session;
          exchange ->
              % void
      end,
      payload-count :: count,
      payload *
  }

• (see mOSAIC interoperability);

Proposed solution -- Design (4)

• end-point, session, nesting-session, protocol, method ::= universally-unique-identifier
  
  payload ::= {
      semantic :: universally-unique-identifier,
      role :: universally-unique-identifier,
      mandatory :: boolean,
      encoding :: universally-unique-identifier,
      schema :: scoped-unique-identifier(method),
      data :: length-prefixed-binary-string
  }

• (see mOSAIC interoperability);

Proposed solution -- Example

• (protocol
          (name connection) (identifier "e7b45267-da3c-4954-b83e-c0630ae4bdef")
          (roles ((name client) (identifier "d6954b86-a74e-4e72-b026-366c13878125")) ...)
          (sessions (
                          (name connection) (identifier "f9a936a5-f09e-4b32-b713-1c54c31422d9")
                          (type master) (roles client server)
                          (messages
                                  ((name access-request) (type initiation))
                                  ((name access-accept) (type exchange))
                                  ((name access-reject) (type termination))
                                  ((name select-request) (type initiation) (payload select-request)) ...)

• (see mOSAIC interoperability);

Proposed solution -- Example (2)

•         (exchanges
                  (
                         (role client)
                         (states
                                 (initial created)
                                 (intermediary access-pending ready)
                                 (terminal closed aborted))
                         (transitions
                                 ((name access-requesting) (when created) (next access-pending)
                                         (send access-request))
                                 ((name access-accepted) (when access-pending) (next ready)
                                         (receive access-accept))
                                 ((name access-rejected) (when access-pending) (next closed)
                                         (receive access-reject))
                                 ((name disconnected) (when ready) (next closed)
                                         (send close))
                                 ((name select-requesting) (when ready)
                                         (send select-request)
                                         (spawn select-operation (role client) (state pending))))
                                 ((name self-aborted) (when access-pending ready) (next aborted)
                                         (send abort))
                                 ((name peer-aborted) (when access-pending ready) (next aborted)
                                         (receive abort)))) ...)) ...)

• (see mOSAIC interoperability);

Proposed solution -- Example (3)

•         (payloads
                  (
                          (name select-request)
                          (identifier "0a320756-b799-47dd-9455-685ca610ae62")
                          (encoding protocol-buffers)
                          (specification
                                  (message "SelectRequest")
                                  (proto-file "key-value-store-select.proto"))) ...))

• (see mOSAIC interoperability);

Proposed solution -- Implementation

• technologies:

  • ZeroMQ (for transport);

  • JSON (for lightweight payloads);

  • Protocol Buffers (for binary, heavy payloads);

• code (version 0)

  • Java: interoperability-core; interoperability-zeromq;

  • Erlang: erlang-drivers;

• (see mOSAIC interoperability);

Future work

• implement version 1;
• benchmark it;
• publish it;

Questions?

• (phew! done...)

  Any questions???