tcp proxy server. Только на berkley sockets (select/poll/epoll)

[m_ax]

Доброго времени суток, коллеги!)

На собеседовании дали тестовое задание разработать Tcp proxy server для Postgresql с возможностью логирования
всех SQL запросов, проходящих через него.
При этом нужно использовать Berkley sockets (select/poll/epoll). Прочих зависимостей быть не должно.
Прокси должен уметь обрабатывать большое количество соединений без создания потока
(thread) на каждое соединение. Необходимо распарсить сетевые пакеты, проходящие через
прокси, в которых содержатся SQL запросы, извлечь эти запросы из пакетов и записать их
в файл в виде текста (по одному запросу в строке, структура неважна). И т.д..

Тема для меня совсем новая, раньше сетевым программированием не занимался.
Поэтому пришлось убить все выходные на расскуривание данного вопроса.

Своял код (проект прилагаю). При реализации из select/poll/epoll   выбор пал на poll.
Если кому не сложно и кто в теме, покритикуйте пожалуйста.
Может как то по элегантнее можно реализовать. Боюсь, у меня уже взгляд замыленный.. 

Заранее спасибо)

[ssoft]

С сетью работал оочень давно). Похоже, что должно работать.

Необходимо распарсить сетевые пакеты, проходящие через
прокси, в которых содержатся SQL запросы, извлечь эти запросы из пакетов и записать их
в файл в виде текста (по одному запросу в строке, структура неважна)

Вот этой части не нашел. В обработчике только вывод в cout.

По идее SQL запросы необходимо собирать из сетевых пакетов.
При этом пакеты могут неожиданно разрываться и слипаться между собой.
Должен быть какой-то признак окончания запроса (м.б. символ";").

[m_ax]

Вот этой части не нашел. В обработчике только вывод в cout.

Да, спасибо за замечание) Парсинг запросов я пока не делал. Этим будет заниматься

Код

C++ (Qt)
data_handler
 

в методе run:

Код

C++ (Qt)
void run(std::ostream & logger, const received_data_handler_t & data_handler);
 

В ТЗ сказано:

Необходимо распарсить сетевые пакеты, проходящие через
прокси, в которых содержатся SQL запросы, извлечь эти запросы из пакетов и записать их
в файл в виде текста (по одному запросу в строке, структура неважна).

По идее SQL запросы необходимо собирать из сетевых пакетов.
При этом пакеты могут неожиданно разрываться и слипаться между собой.
Должен быть какой-то признак окончания запроса (м.б. символ";").

Вот. Займусь как раз этим вопросом) Эта тема для меня тоже пока новая 

[Old]

Так а проксик то работает?

[m_ax]

Так а проксик то работает?

Ну я у себя запускал, работает) Но на большом числе клиентов не тестировал)

[qate]

а почему m_remote_sd один ? если я правильно понял задачу - будет, например 10 клиентов к прокси, которая сделает 10 коннектов к БД

[m_ax]

а почему m_remote_sd один ? если я правильно понял задачу - будет, например 10 клиентов к прокси, которая сделает 10 коннектов к БД

А одного m_remote_sd для этого достаточно. Прокси последовательно перебирает всех активных клиентов (событие POLLIN), читает данные от каждого, обрабатывает и пробрасывает  их на remote_server (через сокет m_remote_sd)

[qate]

а как сервер через прокси ответит нужному клиенту (о выполнении запроса) если он не знает кому ?

[m_ax]

а как сервер через прокси ответит нужному клиенту (о выполнении запроса) если он не знает кому ?

Ну по логике, сервер и не должен ничего знать о том, какой клиент отправил запрос. Его задача получить запрос, обработать и отправить ответ.
Всю консолидацию данных между сервером и клиентами берёт на себя прокси.
Сейчас сделано (возможно топорно) так:
У прокси есть список активных клиентов. Он последовательно перебирает их, читает у каждого запрос, обрабатывает его и шлёт дальше на удалённый сервер. Дожидается ответа и шлёт ответ клиенту. Затем переходит к следующему в списке клиенту и т.д..
Здесь (в моей реализации), я подозреваю, есть слабое место: прокси должен дождаться ответа от сервера, прежде чем перекинуть серверу следующего клиента..
Здесь меня это смущает, конечно    

[Old]

Как я понимаю, сейчас прокси может обрабатывать один запрос от одного клиента. Только после завершения обмена с одним клиентом, происходит переход к следующему.
Но это не очень эффективно, если мы отправили серверу запрос, который он будет обрабатывать 5 секунд, а от других клиентов есть запросы, которые сервер сможет выполнить параллельно за 1 сек, то из-за прокси клиенты будут ждать, пока выполниться долгий запрос.
Т.е. все запросы выполняются последовательно, а тот же postgres может их обрабатывать параллельно.

Логика должна быть другой, на старте поднимается только сокет, который принимает подключения от клиентов.
При подключении нового клиента, выполняем подключение к серверу и после этого имеем пару сокетов client-proxy и proxy-server, вот все что приходит по первому сокету, нужно отправить во второй и наоборот. Если один из сокетов закрывается, то нужно закрыть и второй.
Как правило эти два сокета храняться в объектах, которые называют session.

[m_ax]

Логика должна быть другой, на старте поднимается только сокет, который принимает подключения от клиентов.
При подключении нового клиента, выполняем подключение к серверу и после этого имеем пару сокетов client-proxy и proxy-server, вот все что приходит по первому сокету, нужно отправить во второй и наоборот. Если один из сокетов закрывается, то нужно закрыть и второй.
Как правило эти два сокета храняться в объектах, которые называют session.

Согласен) 
По сути, m_remote_sd должен быть слушающим. Запускать poll и ждать событий POLLOUT от удалённого сервера..
Переделаю сегодня. Спасибо)

[qate]

Дожидается ответа и шлёт ответ клиенту

теперь ясно )

а как решается проблема, что трафик между клиентом, например psql, и сервером - это не plain text и вычленить sql запросы не очевидно как ?

[m_ax]

Дожидается ответа и шлёт ответ клиенту

теперь ясно )

а как решается проблема, что трафик между клиентом, например psql, и сервером - это не plain text и вычленить sql запросы не очевидно как ?

Я пока предполагаю, что это просто plain text в котором могут быть sql запросы.
Сейчас реализовано так:

Код

C++ (Qt)
proxy.run(std::cout, [&](const std::string & data)
        {
            auto query_list = sandbox::get_sql_query(data);
            for (const auto & query : query_list)
                out << query << std::endl;
        });
 

где парсер просто извлекает из текста запросы:

Код

C++ (Qt)
#ifndef SQL_PARSER_H
#define SQL_PARSER_H
 
#include <regex>
#include <string>
#include <list>
 
namespace sandbox {
 
inline std::list<std::string> get_sql_query(const std::string & src)
{
    std::regex query_regex("(SELECT[^;]+;)");
 
    auto query_begin = std::sregex_iterator(src.begin(), src.end(), query_regex);
    auto query_end = std::sregex_iterator();
 
    std::regex r("\\n");
 
    std::list<std::string> result;
 
    for (std::sregex_iterator i = query_begin; i != query_end; ++i)
    {
        std::smatch match = *i;
 
        result.push_back(std::regex_replace(match.str(), r, " "));
    }
 
    return result;
}
 
} /* namespace sandbox */
 
#endif // SQL_PARSER_H
 

[Old]

А если запрос получен не полностью?
Например, получили только
"SELECT * FRO"
а остаток прилетит позже?

[qate]

Я пока предполагаю, что это просто plain text в котором могут быть sql запросы.

не похоже https://www.manniwood.com/2016_12_29/tcpdump_pg.html