The Free On-Line Dictionary of Computing (FOLDOC) defines tunneling as "Encapsulation of protocol A within protocol B, such that A treats B as though it were a data link layer. Tunnelling is used to get data between administrative domains which use a protocol that is not supported by the internet connecting those domains."

SST Method Invocation supports similar tunneling to allow requests to be sent across transports not normally associated with method invocation; for example, HTTP. The key to this is using two marshalers. First, requests are marshaled as normal (using, for example, an SstSwapperMarshaler). The output of the first marshaler is then embedded into a communications message specific to the transport being used for tunneling (such as HTTP). The first marshaler is referred to as the nested marshaler, or sub-marshaler.

SST supports tunneling across HTTP and RFC822 e-mail using either SMTP or IMAP transports. In both cases, the resultant message is specially tagged as a message passed via tunneling so that it is properly unmarshaled by the receiving side. For RFC822 tunneling, the marshaled form of the request must be specially encoded to protect the 8-th bit of each byte.

Enabling tunneling is easy: it is only necessary to install the correct nesting marshaler for the particular transport. Consider the following method which creates an invocation configuration for a by-value Swapper-based marshaler.

To set this up the configuration for tunneling through HTTP, you need carry out only two steps:

Note that tunneling is not restricted to just the SstSwapperMarshaler, or by-value marshaling, it can be used for any marshaler which produces a set of bytes as its output. A working example can be found in SstPingPongLPHttpTunneling class in the SstLPExamples application. See the class comment on SstPingPong for more information.