<commit_before>---
title: Thali Multiplex layer for non-TCP/IP Transports
layout: default
---
# Muxing TCP/IP connections over non-TCP/IP transports

## The problem

When we use a transport that doesn’t natively support TCP/IP we will create a TCP/IP connection over the transport. But in each case we support exactly one TCP/IP connection at a time over the non-TCP/IP transport. In practice this is a problem because we use HTTP and HTTP really wants to open multiple simultaneous TCP/IP connections at a time. This is necessary due to the fact that most HTTP clients and servers don’t properly implement pipelining and even if they did non-idempotent requests can’t be pipelined. Also without multiple simultaneous TCP/IP connections it is possible to end up with ‘head of line’ blocker situations where a bunch of requests that could have been run in parallel can’t because some expensive request is being processed and HTTP doesn’t support out of order responses.

## Client Solution overview

In an ideal world we would run something like HTTP/2.0 over the Singleton TCP/IP connection. Unlike HTTP/1.1, HTTP/2.0 natively supports parallel requests and responses over a single TCP/IP connection. But the HTTP/2.0 server and client code bases are still a bit early and we don’t feel comfortable adopting them yet.

So instead we use a multiplex layer where we take multiple TCP/IP connections and multiplex them onto a single TCP/IP connection which we then send over the non-TCP/IP transport.

```
                                           -----------------
    TCP/IP Client 1 ---(Connection 1.1)--->|               |
                    ---(Connection 1.2)--->|               |
                         ...               |  Client       |
                    ---(Connection 1.N)--->|  Multiplexer  |
       ...                                 |               |----->Singleton TCP/IP 
    TCP/IP Client N ---(Connection N.1)--->|               |
                         ...               |               |
                    ---(Connection N.N)--->|               |
                                           -----------------
```

In other words any number of TCP/IP clients can form as many TCP/IP connections as they want all of which go to the Multiplexer layer who multiplexes all of those connections into a single TCP/IP connection that is then sent over the Singleton TCP/IP connection that relays to the non-TCP/IP transport. This way we can still have just one TCP/IP connection talking to the non-TCP/IP transport but send over it as many individual TCP/IP connections as we require.

## The Client Multiplexer

To understand the Multiplexer one has to understand the Mobile API layer. This layer emits events that include something called the `peerID` which tells the higher level code that a Thali peer has been found and if one wants to connect to them the one has to instruct the Multiplexer to create a connection.
<commit_msg>Stupid change<commit_after># Muxing TCP/IP connections over non-TCP/IP transports

## The problem

When we use a transport that doesn’t natively support TCP/IP we will create a TCP/IP connection over the transport. But in each case we support exactly one TCP/IP connection at a time over the non-TCP/IP transport. In practice this is a problem because we use HTTP and HTTP really wants to open multiple simultaneous TCP/IP connections at a time. This is necessary due to the fact that most HTTP clients and servers don’t properly implement pipelining and even if they did non-idempotent requests can’t be pipelined. Also without multiple simultaneous TCP/IP connections it is possible to end up with ‘head of line’ blocker situations where a bunch of requests that could have been run in parallel can’t because some expensive request is being processed and HTTP doesn’t support out of order responses.

## Client Solution overview

In an ideal world we would run something like HTTP/2.0 over the Singleton TCP/IP connection. Unlike HTTP/1.1, HTTP/2.0 natively supports parallel requests and responses over a single TCP/IP connection. But the HTTP/2.0 server and client code bases are still a bit early and we don’t feel comfortable adopting them yet.

So instead we use a multiplex layer where we take multiple TCP/IP connections and multiplex them onto a single TCP/IP connection which we then send over the non-TCP/IP transport.

```
                                           -----------------
    TCP/IP Client 1 ---(Connection 1.1)--->|               |
                    ---(Connection 1.2)--->|               |
                         ...               |  Client       |
                    ---(Connection 1.N)--->|  Multiplexer  |
       ...                                 |               |----->Singleton TCP/IP 
    TCP/IP Client N ---(Connection N.1)--->|               |
                         ...               |               |
                    ---(Connection N.N)--->|               |
                                           -----------------
```

In other words any number of TCP/IP clients can form as many TCP/IP connections as they want all of which go to the Multiplexer layer who multiplexes all of those connections into a single TCP/IP connection that is then sent over the Singleton TCP/IP connection that relays to the non-TCP/IP transport. This way we can still have just one TCP/IP connection talking to the non-TCP/IP transport but send over it as many individual TCP/IP connections as we require.

## The Client Multiplexer

To understand the Multiplexer one has to understand the Mobile API layer. This layer emits events that include something called the `peerID` which tells the higher level code that a Thali peer has been found and if one wants to connect to them the one has to instruct the Multiplexer to create a connection.

{'fraction_non_alphanumeric': 0.06798283261802575, 'fraction_numerical': 0.005150214592274678, 'mean_word_length': 2.1783960720130935, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 15, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 20, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5733003', 'n_tokens_mistral': 1342, 'n_tokens_neox': 1286, 'n_words': 766}