Здравствуйте, появились вопросы.
Скажите пожалуйста, когда нужен timeout на send ? опцией SO_SNDTIMEO.
И скажите почему нужно закрывать сокет когда одна из функций (send, recv), ранние выставлена функцией setsockopt(); вылетела по таймауту, чем это грозит? И вообще стоит юзать такой метод или лучше обойтись select();
Спасибо!

С одного из форумов:

SO_{SND,RCV}TIMEO are probably the most widely
unimplemented, or strangely/incompatibly implemented, of all
common sockopts in existence... Basically, in short, NEVER try to use them for anything... ;-)

If you want I/O timeouts, your only real option in most cases is
to roll your own, using either blocking/alarm()-based timeouts, or
non-blocking/select()-based timeouts... The latter probably being
the best choice, and least likely to cause pain (especially if you
ever need to write multi-threaded code)... 

MSDN
SO_RCVTIMEO and SO_SNDTIMEO

    When using the recv function, if no data arrives during the period specified in SO_RCVTIMEO, the recv function completes. In Windows versions prior to Windows 2000, any data received subsequently fails with WSAETIMEDOUT. In Windows 2000 and later, if no data arrives within the period specified in SO_RCVTIMEO, the recv function returns WSAETIMEDOUT, and if data is received, recv returns SUCCESS.

    If a send or receive operation times out on a socket, the socket state is indeterminate, and should not be used; TCP sockets in this state have a potential for data loss, since the operation could be canceled at the same moment the operation was to be completed.

Короче все говорят - что не надо использовать - ни в никсах,ни в винде.....

Не сходится.



Тоже не сходится.


То есть, вместо уже написанного кода человек предлагает городить свой велосипед? Нет уж, спасибо. Использовать select() на каждый чих - тоже, не очень-то разумно.

Ну и, возвращаясь к исходному вопросу:

Когда нужен timeout на send. Не нужен - не используй.

Все три источника - и можно привести еще больше - сходятся на одном и том же.
Не желательно...
Не рекомендуется...и тд....
А вот что пишет Стивенс (насчет никсов):
1. Поддержка этих двух параметров  не требуется Posix. т.е. не очень приветствуется...
2. В реализациях типа Беркли эти два значения определяют таймер отсутствия сетевой активности....
(Стр. 236)

Надёжность источника "на форуме пишут" без ссылок на нормативные документы и/или собственное тестирование стремится к нулю.

Источник "MSDN" принимается, но только для Windows.

Источник "Стивенсон":


Принято.

Не принято. Из чего это следует?


Принято. С оговоркой, что единственная вменяемая альтернатива в виде select() ничем не лучше по функциональности, но заставит писать значительно больше кода.

А теперь мой контраргумент (статья 2009 года): http://portabilityblog.com/blog/archives/1...O_RCVTIMEO.html
Выдержка:


Подводя итоги, я соглашусь, что эти параметры работают не на всех системах. Однако здравый смысл говорит мне, что процент POSIX-совместимых систем, не принимающих SND/RCV TIMEO, меньше, чем вероятность ошибиться в своей реализации I/O-таймаутов у даже опытного программиста. Следовательно, я бы рекомендовал использовать эти параметры вместо всех предложенных альтернативных решений.

Скажем так.
Сойдемся на том, что рекомендовать что-то однозначно - для всех абсолютно ОС - просто неприемлемо.
В мире наверно уже более 30? разных реализация модуля TCP - и у каждой ОС будут свои предпочтения - или заморочки.
Потому Стивенс и пишет - уклончиво......
И в вашей ссылке есть завершающее резюме:
"In summary, you can actually expect these timeouts to either work or cause an error when you try to set them on most UNIX and Unix-like operating systems, and also on Windows, but if you are really concerned about portability, you need a backup plan, and either a whitelist of platforms where the backup plan is not necessary, or a very short blacklist that mostly consists of HP-UX."

Да, согласен.