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

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

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

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

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

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

C++ (Qt)
data_handler
 

в методе run:

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

В ТЗ сказано:

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

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

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

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

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

Я пока предполагаю, что это просто 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
 

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