Comments 26
реализации конструктора, который служил бы каркасом основного приложения и всю работу с сетью брал на себя, чтобы оставалось реализовать только сам протокол
Мне кажется заголовок "Конструктор клиент-серверных протоколов" вводит в заблуждение. Протокол это что-то формальное и отделенное от реализации. Задизнайнить протокол задачка сама по себе не тривиальная.
В целом выглядит как интересная библиотека модулей для интернет приложений с поддержкой разных протоколов. Было бы здорово увидеть пример конкурентных запросов, и работы с потоками в частности. Является-ли код потокобезопасным и какие могут быть подводные камни?
Библиотека разрабатывалась как потокобезопасная, насчёт подводных камней сложный вопрос. Архитектура уже несколько раз полностью перерабатывалась как раз из-за выявления этих подводных камней, не исключено, что глобальные доработки будут ещё. Про конкурентные запросы не понял, вы имеете в виду HTTP запросы?
Это определенно не конструктор протоколов.
Слово конструктор (по крайней мере, в моем понимании) подразумевает, что с помощью вашей библиотеки я могу реализовать клиент и сервер для своего протокола.
Поправьте, пожалуйста, но (по-моему) вы не даёте конструировать протокол.
Вы НАВЯЗЫВАЕТЕ протокол. Один из протоколов. Т.е., например, если у меня есть протокол посылки пакетов с определённым заголовком (об 7 байтах, из них 4 байта длина пакета), то не понятно, как эту логику разделения на пакеты/сообщения внедрить в работу с awh библиотекой.
Ещё не понятен вопрос многопоточности: как запустить сервер на 2 (или 20) потоках?
А что поправить, то что вы описали так это и работает, вы сами решаете как передавать данные, протокола тут нет, я не навязываю протокол, я на оборот показал реализацию нескольких различных протоколов на основе AWH, как это работает, а не предоставил пакет нескольких сервисов в одной библиотеке.
Да, похоже это действительно конструктор.
Тогда более общий вопрос:
А в чём сама библиотека-то? То, что увидел по примерам кода на github: пишется своя обёртка (для своего протокола). И пишется с применением libevent и других библиотек. Т.е. awh не скрывает использование нижележащих библиотек - а этого хотелось бы.
Возможно, что-то неправильно понял.
Предложение: написать статью, в котором СОЗДАЁТСЯ новый протокол (не rest, не https), что-то отвлечённое. Желательно с работай на нескольких потоках (см. выше). Желательно с использованием корутин для обработки логики протокола.
Как такая идея?
AWH это готовый клиент/сервер (не важно какой протокол) которые можно объединять, комбинировать, при этом легко например переходить от TCP к UDP или SCTP. При этом сжатие и шифрование данных уже реализовано, все это львиная доля работы в любом проекте клиент/серверной разработки, а реализация самого протокола дело тривиальное. LibEvent используется только как событийный фреймворк и не более. Библиотеки используются только стандартные, такие, какие нет смысла писать самому, например: OpenSSL, Zlib и прочее, эти же библиотеки используют все проекты, такие как Nginx или Curl, последний так и вообще использует столько зависимостей, что только их собрать уже подвиг. В отличии от остальных проектов, я реализовал статическую сборку, т.е. конечный проект будет без зависимостей вообще, как раз факт использования сторонних библиотек будет скрыт.
Про реализацию своего стороннего протокола идея интересная
Так потому вас и спрашивали почему это конструктор протоколов, когда этим и не пахнет. API это конечно тоже протокол, но обычно не тот что имеют ввиду по-умолчанию
Потому, что это и есть конструктор протоколов, что есть вся базовая составляющая, а реализация протокола лежит на плечах разработчика. Как вы по другому представляете конструктор протоколов? На каком-то языке разметки описать сколько байт отправляется в какой момент и куда? Так, это все тоже самое, протоколы могут быть очень сложные и реализация даже того же "ping" в каждом протоколе будет своя, и за вас ни один генератор этот код не напишет. Здесь все как я вижу придрались к заголовку поста, что это мол не конструктор, а что тогда конструктор? Хоть бы кто пояснил. Я скорее прихожу к выводу, что либо не поняли суть проекта, либо не понимают понятия конструктора или вообще не знают что хотят.
На каком-то языке разметки описать сколько байт отправляется в какой момент и куда?
Ага.
Я скорее прихожу к выводу, что либо не поняли суть проекта, либо не понимают понятия конструктора или вообще не знают что хотят.
Народец не тот попался, да.
Вашу разработку было бы правильнее назвать "конструктор сетевых сервисов". Хотя и здесь от слова "конструктор" могут быть неправильные ожидания.
Судя по заголовку ожидал увидеть свежий взгляд на тему https://thrift.apache.org/ Ожидания не оправдались.
Простите, а где, собственно, описание конструктора?
Есть примеры того, как использовать имеющийся в AWH код, написанный вами (полагаю) вручную. Если мне хочется сделать собственную реализацию какого-то протокола, который не поддерживается в AWH "искаропки", то мне придется вручную выписывать простыни кода вроде вот этой?
Или же у вас есть возможность декларативно описать a) формат PDU протокола и b) поток PDU протокола, а затем AWH для меня сгенерирует код по работе с сетью, по парсингу и проверке корректности PDU и пр.?
Для этого есть пример который разбит на разные виды сокетов (sample) UDP/TCP/UnixSocket ...
TCP клиент
#include <client/sample.hpp>
using namespace std;
using namespace awh;
class Client {
private:
log_t * _log;
public:
void active(const client::sample_t::mode_t mode, client::sample_t * sample){
this->_log->print("%s client", log_t::flag_t::INFO, (mode == client::sample_t::mode_t::CONNECT ? "Connect" : "Disconnect"));
if(mode == client::sample_t::mode_t::CONNECT){
const string message = "Hello World!!!";
sample->send(message.data(), message.size());
}
}
void message(const vector <char> & buffer, client::sample_t * sample){
const string message(buffer.begin(), buffer.end());
this->_log->print("%s", log_t::flag_t::INFO, message.c_str());
sample->stop();
}
public:
Client(log_t * log) : _log(log) {}
};
int main(int argc, char * argv[]){
fmk_t fmk;
log_t log(&fmk);
Client executor(&log);
client::core_t core(&fmk, &log);
client::sample_t sample(&core, &fmk, &log);
log.setLogName("SAMPLE Client");
log.setLogFormat("%H:%M:%S %d.%m.%Y");
sample.mode(
// (uint8_t) client::sample_t::flag_t::NOINFO |
(uint8_t) client::sample_t::flag_t::WAITMESS |
(uint8_t) client::sample_t::flag_t::VERIFYSSL
);
core.sonet(awh::scheme_t::sonet_t::TCP);
core.affiliation(awh::core_t::affiliation_t::PRIMARY);
sample.init(2222, "127.0.0.1");
sample.on(bind(&Client::active, &executor, _1, _2));
sample.on(bind(&Client::message, &executor, _1, _2));
sample.start();
return 0;
}Т.е. пример без реализации какого-либо протокола вообще, я специально его расписал на множество видов подключения, там есть прием данных и отправка, дальше идет своя реализация. Да документация нужна по самой библиотеки и до неё руки ещё не дошли, но обязательно сделаю. В принципе на данный момент примеры довольно простые и с комментариями и человек работающий с C++, должен быстро разобраться.
Из этого примера мало что понятно. Вы бы вместо того, чтобы накидывать в статью 100500 разных примеров, привели бы 1-2, но с разбором того, что делается, почему делается именно так, что происходит "за кулисами".
Например, что это за методы active и message, почему у них именно такой формат, почему их нужно вручную привязывать к экземпляру sample.
Насчет простыни кода вроде этой, никто же вас не заставляет писать также, напишите по своему, это просто пример работы. Протоколов передачи данных огромное количество, они отличаются по сложности и размерам, посмотрите только на HTTP2, сколько кода придется написать для его реализации ... Самое сложное это именно клиент-серверное взаимодействие, шифрование и сжатие данных, реализация самих протоколов уже дело рук разработчика.
Насчет простыни кода вроде этой, никто же вас не заставляет писать также, напишите по своему, это просто пример работы.
Если вы в заголовок статьи выносите слово "конструктор", то у читателей возникают некоторые ожидания о того, какую функциональность предоставит этот самый "конструктор". И тут выясняется, что "конструктор" -- это разве что event-loop + еще несколько плюшек сверху. А всю основную работу по парсингу и валидации содержимого PDU нужно делать врукопашную.
Самое сложное это именно клиент-серверное взаимодействие, шифрование и сжатие данных
Боюсь, "у меня для вас плохие новости" (с)
А не хотите нормальную сборку сделать - зависимости из системы, сборку динамической библиотеки, установку без ограничений?
Если мы говорим о Linux и FreeBSD, то нужна версия OpenSSL с поддержкой SCTP, по умолчанию в системе он собран без этой поддержки. Понятно, что не всем она нужна, но моей задачей была показать работу всех возможностей библиотеки на данном этапе. После реализации HTTP/2, сделаю сборку с поддержкой динамических библиотек из системы, для тех кому не нужны SCTP, может и репозитории сделаю, как я понял проект никому не понравился.
как я понял проект никому не понравился.
не стоит делать такие выводы, это особенность русскоязычного сообщества (не только ИТ), если выходить с какимито предложениями — всегда только критикуют и заваливают грязью.
Я в свое время так свой pet-проект забросил, просто потому что на профильном форуме закидали омном… при том что на штатовских форумах даже какаято дикая дичь в этой сфере на ура заходит… и эту дичь наши (с того форума) на ура юзают и ни слова в критику сказать нельзя (тышто!!! это общепризнанный софт из штатов в этой сфере! а ты бред какойто предлагаешь)
imho стоит на забугорных ресурсах попробовать попиарить
Если мы говорим о Linux и FreeBSD, то нужна версия OpenSSL с поддержкой
SCTP, по умолчанию в системе он собран без этой поддержки
Во-первых, такого требования вообще не должно быть, во-вторых не обязательно без:
% make -C /usr/ports/security/openssl -V OPTIONS_DEFAULT:MSCTP
SCTPкак я понял проект никому не понравился
Во-первых, вы ввели публику в заблуждение заголовком. Никто не увидел тут заявленного конструктора протоколов, потому что его тут нет. "Конструктор сервисов" не вводит в заблуждение, но ничего и не описывает. На самом деле это называется асинхронный сетевой фреймворк - написали бы так сразу и было бы понятно на что вообще смотреть.
Во-вторых, для предметного обсуждения мало просто вывалить примеров. Неплохо было бы разобрать один и описать используемые сущности и их взаимодействие. Сравнить с аналогами. Кому-то наверняка были бы интересны бенчи. Рассказать где и как используется в проде.
Лично для меня комментарии и описания к коммитам на русском и неопциональный бандлинг зависимостей - это шоу стопперы при которых дальше можно не смотреть. Если бы посмотрел дальше, бросил бы на отсутствии тестов и CI. Примеры, честно, не впечатляют - многословно, запутанно и несовременно. Но вообще начинание замечательное и таких штук в C++ мире сильно не хватает.
Конструктор сетевых сервисов