accept возвращает -1 в никсах, а в винде она возращает INVALID_SOCKET
INVALID_SOCKET в винде равен -1.
Хотя согласен, можно добавить этот макрос для линукса. Про WSAEWOULDBLOCK — не вижу смысла его проверять для сервера: ну ошибка и ошибка, все равно будем в цикле слушать.
И немного не понял смысл замены блокирующего вызова на зацикленный неблокирующий.
Вы же сами ответили:
Неблокирующий сокет нужен для обработки циклом клиентов и приёма новых конектов в одной ните, вместо разнесения этих операций по разным нитям.
Для «рабочих» клиентских сокетов смысл есть, согласен. Только в приведенном примере этого смысла нет, потому как тут обрабатывается одно единственное подключение.
Сколько соединений сможет одновременно «держать» ваш сервер?
Хоть сколько.
Сервер в моей статье не использует ни select ни epoll ничего!
Да, это не правильно, но так тоже можно.
В принципе, если меня не закидают минусами, я могу показать, как пишется кроссплатформенный сервер с select и epoll. Он будет поддерживать тоже любое количество соединений в Linux, а в Windows — сколько позволит select.
Ничего там сверхъестественного нет.
В чем смысл делать сокеты неблокирующими — а потом вызывать методы в цикле?
Это простой пример, демонстрирующий принцип работы.
В реальных задачах, в каждом цикле вызывается callback функция в которой процессу можно заниматься какимито другими задачами.
В случае блокирующих сокетов процесс тупо виснет на каждой блокирующей функции и ничего с ним сделать невозможно.
Согласен, что пример написан в сишном стиле, а не c++.
Но это не мой пример, а расширение у файла «cpp», что какбы намекает…
Кстати, я собираюсь дополнять этот пример в следующих статьях, думаю в конце концов сишный стиль из него уйдет окончательно.
Но даже если в ваш сервер добавить многопоточность — то он все равно будет хуже, чем такой же сервер на блокирующих сокетах.
Ну вам то оно конечно виднее, но по моему вы меня тролите.
Дочитайте статью до конца — может найдете ответ на свой вопрос.
Если перестанете кидать минусы — напишу, как из этого примера сделать реально работающий сервер для любого количества подключений ))
INVALID_SOCKET в винде равен -1.
Хотя согласен, можно добавить этот макрос для линукса. Про WSAEWOULDBLOCK — не вижу смысла его проверять для сервера: ну ошибка и ошибка, все равно будем в цикле слушать.
Вы же сами ответили:
Приведите аргумент в пользу select и для слушающего сокета?
Для «рабочих» клиентских сокетов смысл есть, согласен. Только в приведенном примере этого смысла нет, потому как тут обрабатывается одно единственное подключение.
Хоть сколько.
Сервер в моей статье не использует ни select ни epoll ничего!
Да, это не правильно, но так тоже можно.
В принципе, если меня не закидают минусами, я могу показать, как пишется кроссплатформенный сервер с select и epoll. Он будет поддерживать тоже любое количество соединений в Linux, а в Windows — сколько позволит select.
Ничего там сверхъестественного нет.
Из вашего поста следует, что мой код подвержен и является «неправильным способом», я правильно понимаю?
Было бы любопытно почитать ваши доводы на эту тему.
Это простой пример, демонстрирующий принцип работы.
В реальных задачах, в каждом цикле вызывается callback функция в которой процессу можно заниматься какимито другими задачами.
В случае блокирующих сокетов процесс тупо виснет на каждой блокирующей функции и ничего с ним сделать невозможно.
Возможно, для набирающихся опыта разработчиков. Таких как я например.
Просто, чтобы не вставали на грабли и возможно почерпнули пару полезных советов.
Согласен, что пример написан в сишном стиле, а не c++.
Но это не мой пример, а расширение у файла «cpp», что какбы намекает…
Кстати, я собираюсь дополнять этот пример в следующих статьях, думаю в конце концов сишный стиль из него уйдет окончательно.