Смотрите, название статьи говорит о расширении стандарта (а стоит ли?). Вам пояснили что того же эффекта с делегатами можно добиться используя существующий функционал. Возможно в вашем опыте было то, что не покрывалось этим функционалом. И если бы вы им поделились было бы куда конструктивнее нежели говорить что все сообщество далеко от ваших ожиданий.
Возможно не найдя ответа почему для реализации делегатов вы не использовали std::function, лямбды с захватом this. Может есть то, что не позволяет использовать стандартный функционал?
Как-то для себя открыл утилиту RegexBuddy, в ней есть чуть больше чем надо, от обработки данных, до тестирования регулярок и готового сниппета в любой доступный ЯП.
epoll мощный механизм, но не совсем полноценный из-за отсутствия механизма получения ассоциированого с fd — epoll_event. Приходится использовать костыли в виде деревьев и т.п., что влечёт дополнительные расходы на поддержание и очистку ресурсов
Довольно поверхностный и типичный подход. Уж извините.
1. Добавьте для сокетов SOCK_CLOEXEC опцию
2. Хендлите ситуацию закрытия\подвисания сокета (EPOLLRDHUP | EPOLLHUP)
3. Почитайте про edge\level triggered, дайте другим сокетам право на жизнь избавясь от лишнего вызова while(read(...)) => EAGAIN || EWOULDBLOCK
4. ну и надеется на то что в вашем http сервере, все запросы\ответы будут ограниченной длины в 1024 байт — наивно. Тут у вас и появятся вопросы с аллоцированием\реалоцированием памяти, просадки
5. http сервер, не ограничивается только приемом данных, данные нужно как-то обработать, выше писали, про тот же парсинг и т.д.
…
N. А есть медленные клиенты, почитайте про TCP_KEEPALIVE
N+1. позже вы дойдете, до того, что не все клиенты честные, они откроют десятки тысяч соединений и на вашем сервере закончатся сокеты. Подумайте над этим когда будете развивать ваш проект
Все хорошо пока разрешены в сети мультикасты. А так приходится надеятся на старый добрый dhcp и хардварную кнопку сброса до заводских настроек.
За труд спасибо, было полезно.
Делаю MVP похожего проекта на arm, прямо чувствую вашу боль ?. Но вы круты. Спасибо за статью, хотя и хотелось бы чуть больше техники.
Смотрите, название статьи говорит о расширении стандарта (а стоит ли?). Вам пояснили что того же эффекта с делегатами можно добиться используя существующий функционал. Возможно в вашем опыте было то, что не покрывалось этим функционалом. И если бы вы им поделились было бы куда конструктивнее нежели говорить что все сообщество далеко от ваших ожиданий.
Возможно не найдя ответа почему для реализации делегатов вы не использовали std::function, лямбды с захватом this. Может есть то, что не позволяет использовать стандартный функционал?
Как-то для себя открыл утилиту RegexBuddy, в ней есть чуть больше чем надо, от обработки данных, до тестирования регулярок и готового сниппета в любой доступный ЯП.
Если сообщения короткие, то udp предпочтительнее tcp.
1. Добавьте для сокетов SOCK_CLOEXEC опцию
2. Хендлите ситуацию закрытия\подвисания сокета (EPOLLRDHUP | EPOLLHUP)
3. Почитайте про edge\level triggered, дайте другим сокетам право на жизнь избавясь от лишнего вызова while(read(...)) => EAGAIN || EWOULDBLOCK
4. ну и надеется на то что в вашем http сервере, все запросы\ответы будут ограниченной длины в 1024 байт — наивно. Тут у вас и появятся вопросы с аллоцированием\реалоцированием памяти, просадки
5. http сервер, не ограничивается только приемом данных, данные нужно как-то обработать, выше писали, про тот же парсинг и т.д.
…
N. А есть медленные клиенты, почитайте про TCP_KEEPALIVE
N+1. позже вы дойдете, до того, что не все клиенты честные, они откроют десятки тысяч соединений и на вашем сервере закончатся сокеты. Подумайте над этим когда будете развивать ваш проект