TCP Layer

The communication server is implemented using Boost Asio and Beast. It is separated into three parts:

• Server communication/v2/server.hpp
• Listener communication/v2/listener.hpp
• Session communication/v2/session.hpp

There is also an “old” implementation of the same Bolt server using POSIX API in directory communication/ and it can be removed, but note that the POSIX version is still faster than Asio one.

Server

When the server is instantiated it starts listening for connections on a background thread, and the server also instantiates a listener and passes any new connection to the listener.

Listener

The thread model used in our listener is a thread per core architecture, meaning the listener has multiple worker threads, and after receiving a connection from the server, it creates a single session in one of the worker threads.

Possible Modes

1. IO context per thread
2. Thread per core
   1. One IO context → each connection is attached to the thread pool

Session

<aside> ⁉️ The Session class should probably be renamed to the TCPSession. The TCP Session is not aware of the application protocol. The details of the protocol (encoding and decoding are done under the application specific session, e.g. communication::bolt::Session.

</aside>

A session is an object that handles a single connection throughout its lifetime until the session is terminated either by the user or by the server.

The session uses input and output buffers to receive data from the client and send back responses.

It is also possible to upgrade the session from a standard TCP connection to a WebSocket connection by sending an HTTP upgrade request. And then, the communication still uses Bolt protocol to communicate over WebSocket.

The session in communication/v2/session.hpp is a session in the communication stack, there is also a Bolt session defined in communication/bolt/v1/session.hpp and there we define Bolt specifics. Both of these sessions are used in memgraph.cpp.