Здравствуйте Gosha, Вы писали:
NR>>Неправильно. Сокет закрыт <=> recv возвращает 0.
G>Кто бы спорил! 
Только вот, в таком случае по сокету гоняются левые, никому не нужные (в данной постановке), данные. Потому как если recv не вернул 0 и не вернул SOCKET_ERROR, то он должен вернуть количество принятых байт, а их для этого надо послать. Делать это только для проверки "живости" сокета, я считаю, лишне.
Не понял
Какие еще "левые данные"? Если данные идут, то они информативны, а если данных нет, то вызов recv() на блокирующем сокете остановит задачу либо до получения данных (recv() > 0) либо до закрытия сокета (recv() == 0), а на неблокирующем — либо скажет, что данных еще нет (recv() == -1 && WSAGetLastError() == WSAEWOULDBLOCK) либо что сокет закрыт (recv() == 0)
И, кстати, если ты не споришь с утверждением "сокет закрыт <=> recv возвращает 0", то почему ты считаешь лишним "Делать это только для проверки "живости" сокета"? Или может быть было не совсем понятно, что знак "<=>" означает "необходимо и достаточно"?
NR>>Не пойдет. select через readfds скажет, что из сокета можно прочитать либо что сокет закрыт. При этом для проверки "закрыт ли сокет?" по любому придется вызывать recv.
G>При чем тут readfds? Я говорил про writefds...
Я знаю, что ты говорил про writefds. Но если сервер закроет соединение, то на клиенте этот факт отразится на значении readfds, а не writefds.
G>...В клиент-серверных отношениях рулит клиент, а сервер выполняет пассивную роль. С этой точки зрения "живость" сокета должна проверяться клиентом, и именно на возможность записи в него (в сокет), т.е. проверка способности клиента рулить.
Не совсем понимаю, что здесь есть "живость" сокета, подозреваю что "сервер доступен и готов обрабатывать запросы". Только такая проверка называется ping'ом (не путать с одноименной программой и не ограничиваться ICMP) и делается все равно иначе.
Если же ты имеешь ввиду состояние сокета "соединение закрыто", то смотри выше.
G>А вообще, это дело вкуса 
Что дело вкуса? Правильно или неправильно решать задачи?
