RPC — повод попробовать новое в C++ 14 / 1724.08.2018 13:04

Конструктор класса server

template 
server(std::pair const & ... handlers)
{
    auto make_executor = [&packer = packer_] (auto const &handler)
    {
        auto executor = [&packer, function = std::function{handler}] (type::buffer buffer)
        {
            using meta = detail::function_meta>;
            typename meta::request_type request;
            packer.load(buffer, request);
            auto response = std::apply([&function] (std::string const &, auto && ... args)
                    { return function(std::forward(args) ... ); },
                    std::move(request)
                );
            return packer.save(std::make_tuple(std::move(response)));
        };
        return executor;
    };
    (handlers_.emplace(handlers.first, make_executor(handlers.second)), ... );
}

Конструктор класса является шаблонным. На вход принимает список пар. Каждая пара — имя метода и обработчик. А так как конструктор является шаблоном с переменным количеством параметров, то при создании объекта server сразу регистрируются все доступные на сервере обработчики. Что даст возможность не делать дополнительных методов регистрации вызываемых на сервере обработчиков. И в свою очередь освобождает от размышлений о том, будет ли объект класса server использоваться в многопоточной среде и нужна ли синхронизация.

Фрагмент конструктора класса server

template 
server(std::pair const & ... handlers)
{

    // …

    (handlers_.emplace(handlers.first, make_executor(handlers.second)), ... );
}

Помещает множество переданных разнотипных обработчиков в карту однотипно вызываемых функций. Для этого так же используется свертка, позволяющая легко поместить в std: map все множество переданных обработчиков одной строкой без циклов и алгоритмов

(handlers_.emplace(handlers.first, make_executor(handlers.second)), ... );

Лямбда-функции, позволяющие использовать auto в качестве параметров дали возможность легко реализовать однотипные обертки над обработчиками. Однотипные обертки регистрируются в карте доступных на сервере методов (std: map). При обработке запросов производится поиск по такой карте, и однотипный вызов найденного обработчика вне зависимости от принимаемых параметров и возвращаемого результата. Появившаяся в стандартной библиотеке функция std: apply вызывает переданную ей функцию с параметрами, переданными в виде кортежа. Функцию std: apply можно реализовать и на C++11. Теперь же она доступна «из коробки» и не надо ее переносить из проекта в проект.

Метод execute

type::buffer execute(type::buffer buffer)
{
    std::tuple pack;
    packer_.load(buffer, pack);
    auto func_name = std::move(std::get<0>(pack));
    auto const iter = handlers_.find(func_name);
    if (iter == end(handlers_))
        throw std::runtime_error{"Function \"" + func_name + "\" not found."};
    return iter->second(std::move(buffer));
}

Извлекает имя вызываемой функции, производит поиск метода в карте зарегистрированных обработчиков, вызывает обработчик и возвращает результат. Все интересное в обертках подготовленных в конструкторе класса server. Кто-то возможно заметил исключение, и, возможно, возник вопрос: «А исключения как-то обрабатываются?». Да, в полной реализации, которая будет дана ссылкой в конце, маршалинг исключений предусмотрен. Тут же для упрощения материала исключения не передаются между клиентом и сервером.

Взгляните еще раз на функцию

int main()
{
    try
    {
        using packer_type = rpc::packer::string_serializer;

        rpc::server server{
            std::pair{"hello",
                [] (std::string const &s)
                {
                    std::cout << "Func: \"hello\". Inpur string: " << s << std::endl;
                    return "Hello " + s + "!";
                }},
            std::pair{"to_int",
                [] (std::string const &s)
                {
                    std::cout << "Func: \"to_int\". Inpur string: " << s << std::endl;
                    return std::stoi(s);
                }}
        };

        auto executor = [&server] (rpc::type::buffer buffer)
        {
            return server.execute(std::move(buffer));
        };

        rpc::client client{std::move(executor)};
        std::cout << client.call("hello", std::string{"world"}).as() << std::endl;
        std::cout << "Convert to int: " << client.call("to_int", std::string{"100500"}).as() << std::endl;
    }
    catch (std::exception const &e)
    {
        std::cerr << "Error: " << e.what() << std::endl;
        return EXIT_FAILURE;
    }
    return EXIT_SUCCESS;
}

В ней реализовано полноценное клиент-серверное взаимодействия. Чтобы не усложнять материал клиент и сервер работают в один процесс. Заменив реализацию executor, можно использовать нужный транспорт.

В стандарте C++ 17 появилась возможность иногда не указывать параметры шаблонов при инстанцировании. В приведенной выше функции main это используется при регистрации обработчиков сервера (std: pair без параметров шаблона) и делает код проще.

Базовая реализация RPC готова. Осталось добавить обещанную возможность передавать пользовательские структуры данных в качестве параметров и возвращаемых результатов.

Пользовательские структуры данных

Чтобы передать данные через границу процесса их нужно во что-нибудь сериализовать. Например, можно все выводить в стандартный поток. Многое будет поддерживаться «из коробки». Для пользовательских структур данных придется реализовать самостоятельно операторы вывода. Каждой структуре нужен свой оператор вывода. Иногда хочется этого не делать. Чтобы перебрать все поля структуры и вывести каждое поле в поток, нужен какой-то обобщенный метод. В этом могла бы хорошо помочь рефлексия. Ее пока нет в C++. Можно прибегнуть к кодогенерации и использованию смеси из макросов и шаблонов. Но идея была в том, чтобы сделать интерфейс библиотеки на чистом C++.

Полноценной рефлексии в C++ пока нет. Поэтому приведенное ниже решение может использоваться с некоторыми ограничениями.

Решение построено на использовании новой возможности C++ 17 «structured bindings». Часто в диалогах можно встретить много жаргонизмов, поэтому я отказался от каких-либо вариантов названия этой возможности на русском.

Ниже приведено решение, позволяющее перенести в кортеж поля переданной структуры данных.

template 
auto to_tuple(T &&value)
{
    using type = std::decay_t;

    if constexpr (is_braces_constructible_v)
    {
        auto &&[f1, f2, f3] = value;
        return std::make_tuple(f1, f2, f3);
    }
    else if constexpr (is_braces_constructible_v)
    {
        auto &&[f1, f2] = value;
        return std::make_tuple(f1, f2);
    }
    else if constexpr (is_braces_constructible_v)
    {
        auto &&[f1] = value;
        return std::make_tuple(f1);
    }
    else
    {
        return std::make_tuple();
    }
}

В Интернете можно найти немало аналогичных решений.

О многом, что здесь использовано было сказано выше, кроме structured bindings. Функция to_tuple принимает пользовательский тип, определяет количество полей, и с помощью structured bindings «перекладывает» поля структуры в кортеж. А «if constexpr» позволяет выбрать нужную ветвь реализации. Так как в C++ рефлексии нет, то полноценное, учитывающее все аспекты типа, решение построить нельзя. Есть ограничения на используемые типы. Одно из них — тип должен быть без пользовательских конструкторов.

В to_tuple используется is_braces_constructible_v. Этот тип позволяет определить возможность инициализировать переданную структуру с помощью фигурных скобок и определить количество полей.

struct dummy_type final
{
    template 
    constexpr operator T () noexcept
    {
        return *static_cast(nullptr);
    }
};

template 
constexpr decltype(void(T{std::declval() ... }), std::declval())
is_braces_constructible(std::size_t) noexcept;

template 
constexpr std::false_type is_braces_constructible(...) noexcept;

template 
constexpr bool is_braces_constructible_v = std::decay_t(0))>::value;

Приведенная выше функция to_tuple может преобразовывать в кортежи пользовательские структуры данных, содержащие не более трех полей. Чтобы увеличить возможное количество «перекладываемых» полей структуры можно или копировать ветки «if constexpr» с небольшим включением разума, или прибегнуть к использованию не самой простой библиотеки boost.preprocessor. В случае выбора второго варианта код станет трудночитаемым и даст возможность использовать структуры с большим количеством полей.

template 
auto to_tuple(T &&value)
{
    using type = std::decay_t;

#define NANORPC_TO_TUPLE_LIMIT_FIELDS 64 // you can try to use BOOST_PP_LIMIT_REPEAT

#define NANORPC_TO_TUPLE_DUMMY_TYPE_N(_, n, data) \
    BOOST_PP_COMMA_IF(n) data

#define NANORPC_TO_TUPLE_PARAM_N(_, n, data) \
    BOOST_PP_COMMA_IF(n) data ## n

#define NANORPC_TO_TUPLE_ITEM_N(_, n, __) \
    if constexpr (is_braces_constructible_v) { auto &&[ \
    BOOST_PP_REPEAT_FROM_TO(0, BOOST_PP_SUB(NANORPC_TO_TUPLE_LIMIT_FIELDS, n), NANORPC_TO_TUPLE_PARAM_N, f) \
    ] = value; return std::make_tuple( \
    BOOST_PP_REPEAT_FROM_TO(0, BOOST_PP_SUB(NANORPC_TO_TUPLE_LIMIT_FIELDS, n), NANORPC_TO_TUPLE_PARAM_N, f) \
    ); } else

#define NANORPC_TO_TUPLE_ITEMS(n) \
    BOOST_PP_REPEAT_FROM_TO(0, n, NANORPC_TO_TUPLE_ITEM_N, nil)

    NANORPC_TO_TUPLE_ITEMS(NANORPC_TO_TUPLE_LIMIT_FIELDS)
    {
        return std::make_tuple();
    }

#undef NANORPC_TO_TUPLE_ITEMS
#undef NANORPC_TO_TUPLE_ITEM_N
#undef NANORPC_TO_TUPLE_PARAM_N
#undef NANORPC_TO_TUPLE_DUMMY_TYPE_N
#undef NANORPC_TO_TUPLE_LIMIT_FIELDS
}

Если Вы когда-либо пробовали сделать что-то подобное boost.bind для C++ 03, где нужно было сделать множество реализаций с разным количеством параметров, то реализация to_tuple с использованием boost.preprocessor не покажется странной или сложной.

А если добавить в сериализатор поддержку кортежей, то функция to_tuple даст возможность сериализовать пользовательские структуры данных. И появляется возможность предавать их в качестве параметров и возвращаемых результатов в своем RPC.

Кроме пользовательских структур данных в C++ есть другие встроенные типы, для которых вывод в стандартный поток не реализован. Желание уменьшить количество перегруженных операторов вывода в поток приводит к обобщенному коду, позволяющему одним методом обрабатывать большую часть контейнеров C++ таких, как std: list, std: vector, std: map. Не забыв про SFINAE и std: enable_if_t можно продолжить расширять сериализатор. При этом нужно будет как-то косвенно определять свойства типов, подобно тому, как сделано в реализации is_braces_constructible_v.

За рамками поста остался маршалинг исключение, транспорт, сериализация stl-контейнеров и многое другое. Дабы сильно не усложнять пост были приведены только общие принципы, на которых мне удалось построить свою RPC библиотеку и решить изначально поставленную для себя же задачу — попробовать новые возможности C++ 14 / 17. А полученная реализация позволяет вызывать удаленные методы по широкораспространенным протоколам HTTP / HTTPS и содержит достаточно подробные примеры использования.

Код библиотеки NanoRPC на GitHub .

Спасибо за внимание!

© Habrahabr.ru