---
tags: tarantool, h2o, network
---

# Tarantool Network Framework API

Сетевой фреймворк — это набор интерфейсов для создания сетевых модулей в рамках платформы. Основное назначение фреймворка — дать возможность внешнему разработчику создать модуль, который сможет утилизировать отдельные потоки для обработки сетевых запросов и иметь коммуникационный канал для асинхронного обмена данными с транзакционным потоком.

Для чего это предполагается использовать?
- Интеграция HTTP-фреймворка H2O, когда воркеры H2O работают в отдельных тредах, крутят свой событийный цикл, терминируют TLS, обрабатывают HTTP-запросы, а в TX передаётся уже полностью разобранный запрос, на который он должен ответить.
- Реализация протокола Redis для прозрачной замены Redis
- Перенос сетевой части реализации memcached из tx в отдельный тред

Цель этого — максимально разгрузить транзакционный тред от обработки сетевых запросов, шифрования и прочей нецелевой нагрузки.

Разработчик создаёт модуль, который реализует необходимые ему функции. В функциях, работающих в tx-треде можно пользоваться методами работы с базой и файберами (в т.ч. yield'ить). Нельзя блокироваться. Нельзя запускать "свой" событийный цикл. В функциях, работающих в тредах, нельзя работать с базой, файберами, основным событийным циклом.

* Загрузка (`mod = require 'h2o'`)
- Должна быть выполнима до вызова `box.cfg()`
- Выполянется из TX треда.
- dlopen + проверка наличия нужных символов
- Создаёт lua-модуль и возвращает его
* Конфигурация и запуск. (`mod.cfg{ ... }`)
- Желательна возможность вызова до `box.cfg()`
- Вызывается из lua
- Принимает lua-таблицу с параметрами и передаёт на уровень C
- Проверяет все параметры и выбрасывает исключение в случае некорректности
- Инициализирует слушающие сокеты.
- Инициализирует и запускает необходимое количество рабочих тредов
- В рабочем треде запускается полезная нагрузка, реализующая listen/accept цикл
* Переконфигурация (`mod.cfg{ ... }` повторно)
- Вызывается из lua
- Принимает lua-таблицу с параметрами и передаёт на уровень C
- Проверяет все параметры и выбрасывает исключение в случае некорректности
- Инициализирует новые параметры. Должны поддерживаться:
+ Смена сокета
+ Изменение кол-ва рабочих тредов
- Cтарые треды и их соединения должны завершаются gracefully, т.е. по завершению запроса. (На совести разрабочика модуля)
+ Необходимо API для выставления треду признака работать/завершать-работу и сигнальный интерфейс
* Общение между тредами
- При обработке соединений и запросов может быть необходимо отправить сообщение и данные из рабочего треда в tx тред. Для этого нужен API вызов, который позволит передать данные, обратный контекст и вызовет функцию модуля в tx треде.
- Вызванная в tx треде функция может взаимодействовать с box api, вызывать fiber_yield и т.п. и в конце концов должна иметь возможность передавать данные и контекст обратно.
- Нужно учесть, что в рамках одной пользовательской сессии возможен многократный обмен сообщениями (напр. в сценариях WebSocket, HTTP/2, HTTP/3), т.е. простая пара call/return не подойдёт
- Т.о. необходим механизм двунаправленной асинхронной передачи сообщения вместе с вызовом функции.
* Насколько мне удалось разобраться в iproto.cc, всё уже есть и это называется `cbus`, `cpipe` и `cmsg`
- Нужно вытащить в виде публичного интерфейса для модулей cbus, cpipe и, возможно, rlist