Architecture

There will be a self contained stack that makes transparent to every other module about the details of SLP and SLP messages. The proposed architecture exposes a single SLP API on top of the stack and pass it to the lower layers as needed: SLP API → SlpCall → SlpLink → Network. Where SlpLink is an abstraction of the possible transaction methods, each defined in the DirectConn and SBConn modules.

           +------------+
           |  SLP API   |
           +------------+
                 |       SlpMessage
           +------------+
           |  SlpCall   |
           +------------+
                 |
           +------------+
           |  SlpLink   |
           +------------+
              /       \   SlpMessagePart
+-----------------------------------+
|           /   Conn    \           |
|  +------------+   +------------+  |
|  |  SBConn    |   | DirectConn |  |
|  +------------+   +------------+  |
+-----------------------------------+
  MsnMsg |                |
   +------------+   +------------+
   |Switchboard |   |  Network   |
   +------------+   +------------+
       Figure 1. SLP Stack

SLP API (WIP)

This API must abstract everything others modules will need from SLP transactions. This will be the one that creates the SlpCall for any new transaction as needed.

Here is where the SlpMessage is created and passed down to lower modules.

SlpCall

Represent an SLP transaction creating the messages as needed and managing most of the msg specific management (what to do on each response).

SlpLink

Abstract a Connection. Try DirectConn and fallback to SBConn if the former fails. This module is also responsible to get the data that must be sent from files or write down the received data.

If the data that will be sent is big, here it is split in a serie of SlpMsgPart to be sent down to a Conn.

Conn

This modules must expose a common interface so they can be easily attached to SlpCall and Network interfaces.

SBConn

Each SlpMsgPart? must be packaged in a MsnMessage? and then be sent through the !Switchboard.

Packagement

SBConn

Since the SlpMessage is placed on the body of a MsnMsg, it must be embedded in there. When the SlpMessage? is too big it can be split in small SlpMsgParts?.

+-----------------------------------------------------------+
| SlpMessage                                                |
| +---------------+ +---------------+     +---------------+ |
| | MsnMessage    | | MsnMessage    |     | MsnMessage    | |
| | +-----------+ | | +-----------+ |     | +-----------+ | |
| | |SlpMsgPart | | | |SlpMsgPart | | ... | |SlpMsgPart | | |
| | +-----------+ | | +-----------+ |     | +-----------+ | |
| +---------------+ +---------------+     +---------------+ |
+-----------------------------------------------------------+
             Figure 2. SlpMessage Packaging
                    using switchboard

Implementation

• SBConn and DirectConn can have a conn_ops structure which will be called by the SlpLink module.
• SBConn must be extracted from the actual Switchboard module.
• Use an MsnTable in SlpCall to manage the SLP protocol callbacks.