Differences between revisions 5 and 6
Revision 5 as of 2015-03-17 02:21:11
Size: 3267
Editor: AndrewStone
Comment:
Revision 6 as of 2015-03-17 03:47:22
Size: 4370
Editor: HungTa
Comment:
Deletions are marked like this. Additions are marked like this.
Line 22: Line 22:

==== SCTP transport plugin ====

SCTP stands for Stream Control Transmission Protocol. SCTP is the extension of TCP, therefore, there are some typical features:
 *Data transfer is reliable
 *Multi-stream support
 *Multi-homing support
 *Does not enforce strictly ordered delivery

Because of the data transport in stream, so there is 2 separate methods to open socket at server and client:
 *Server:
   *open a socket
   *set sctp socket options
   *bind the opened socket with address and port
   *listen connections
   *accept connections
   *receive/send from/to clients
 *Client:
   *open a socket
   *set sctp socket options
   *connect to the listening server socket
   *send/receive to/from server socket

To implement the peer-to-peer model using SCTP, the model has to be refined: each client would need to support its own listen socket, so that another client (once aware of another client), can connect directly to its peer. In such a model, the server mainly serves as the broker that notifies other clients when a new client is aboard and ready for connections.

SAFplus 7 Feature Discussion

SAFplus Messaging

Advanced Socket Layer

The socket abstraction (MsgSocket class) presents a simple read/write API for multiple scatter gather messages, consisting of receive, send, and flush APIs. At the message transport layer, an instance of the socket object directly communicates with the Linux level socket via system calls. However additional socket objects can be created that implement additional functionality, such as traffic shaping, message segmentation and reassembly and reliable messaging. These message sockets can modify the messages sent and received and then call a lower level MsgSocket instance.

Functionality can therefore be selected at socket construction time by instantiation of a stack or tree of MsgSocket-derived classes, and a single implementation of an abstract concept (such as traffic shaping) can be applied to any message transport type.

After socket construction, application code is unaware that it is accessing layered sockets rather than a direct socket implementation, making it easy to change add or remove functionality as application requirements change.

MsgSocketLayering.svg MsgSocketLayering.svg

The diagram above shows 3 applications with different socket stacks. Application 1 is using UDP transport, traffic shaping and allows large messages (segmentation and reassembly). Application 2 does not need large messages; it is just using traffic shaping. Application 3 shows a complex configuration. Its node supports both UDP and TIPC transports, so the first layer above the transport ("splitter") uses the destination nodeId to determine which transport to route the message to. Large messages are supported so the "Segmentation And Reassembly" object is next. After that, the application may need both reliable and unreliable messages, so a "Joiner" object is added that is capable of providing 2 independent MsgSocket interfaces and combining them into one (by prefixing a "message type" character to the front of every message, for example). Finally, a "reliable message" MsgSocket object provides reliable messaging. The application code sees 2 MsgSocket interfaces; one for unreliable and one for reliable messages.

Note that is is expected that the receiving application will have the same socket stack, in cases where the MsgSocket objects modify message content.

SCTP transport plugin

SCTP stands for Stream Control Transmission Protocol. SCTP is the extension of TCP, therefore, there are some typical features:

  • Data transfer is reliable
  • Multi-stream support
  • Multi-homing support
  • Does not enforce strictly ordered delivery

Because of the data transport in stream, so there is 2 separate methods to open socket at server and client:

  • Server:
    • open a socket
    • set sctp socket options
    • bind the opened socket with address and port
    • listen connections
    • accept connections
    • receive/send from/to clients
  • Client:
    • open a socket
    • set sctp socket options
    • connect to the listening server socket
    • send/receive to/from server socket

To implement the peer-to-peer model using SCTP, the model has to be refined: each client would need to support its own listen socket, so that another client (once aware of another client), can connect directly to its peer. In such a model, the server mainly serves as the broker that notifies other clients when a new client is aboard and ready for connections.

SAFplus Management

Management Access APIs

We need a c++ API to issue management object set and gets from any application. This will allow the management data to be generically manipulated and so we will not need to support a lot of application specific APIs like log stream creation or Dynamic HA operations.

Applications can also use these APIs to implement a new northbound protocol (like SNMP and NETCONF) if they need to.

Proposal:

mgtSet(const string& pathSpec, const string& value, Transaction& t);

string mgtGet(const string& pathSpec);

void mgtCreate(const string& pathSpec);
void mgtDelete(const string& pathSpec);

All APIs raise an exception if they cannot complete.

For example:

mgtSet("/Log/stream["mystream"]/filename", "/var/log/myapplog")

SAFplus: Feature Discussion (last edited 2015-07-24 14:01:34 by AndrewStone)