MSDN говорит следующее: «Вызывающая отправка с параметром len с нулем допустима и будет обработана реализациями как успешная. В таких случаях send будет возвращать ноль в качестве допустимого значения. Для ориентированных на сообщения сокетов, отправленная длинная транспортная датаграмма ».При каких условиях блокировка winsock send() возвращает 0?
Мой вопрос в том, что если параметр len не равен нулю, произойдет ли блокировка send() return 0 (если не установлен тайм-аут)?
Я также искал в Интернете, и нашел следующее:
http://tangentsoft.net/wskfaq/articles/bsd-compatibility.html
«Под Winsock, то SIGPIPE/функциональность EPIPE не существует вообще: отправить() либо возвращает 0, для нормального отключения или -1 для аномального отключения ».
Однако, как бы я ни старался, я не мог не имитировать «нормальное разъединение», и поэтому я не мог отправить() возвращает 0.
Спасибо заранее.
send() все равно будет успешным, даже если FIN был получен. FIN может быть вызван закрытием, выключением (SD_SEND), отключением (SD_BOTH). Для случая завершения работы (SD_SEND) последующая функция send() s всегда будет успешной, так как другая сторона (которая вызывается shutdown (SD_SEND)) должна получать любые дополнительные данные. Однако вызов recv() будет возвращать 0. Для закрытия и завершения работы (SD_BOTH) (а также отключения (SD_RECEIVE)) первая функция send() будет по-прежнему успешной; однако RST будет возвращен. В следующий раз, когда вызывается send() или recv(), возвращается SOCKET_ERROR (-1). – JohnTang
Подводя итог, независимо от того, что вызывает FIN, send() будет либо успешным (первый раз после получения FIN), либо будет возвращаться -1 из-за RST (второй и будущий вызовы). То есть блокировка send() никогда не вернет 0? правильно? (если не установлен тайм-аут) – JohnTang