[jcxz 214]

11 минут назад, aaarrr сказал:

Потому что состояние TIME_WAIT может быть только у открытого когда-то соединения. По очевидным причинам, на старте таковых нет.

А теперь подумайте немножко дальше.  

Устройство стартует. После чего - ему неизвестно. А значит: предыдущее состояние сетевого взаимодействия - неизвестно. А значит - этот момент старта может прийтись как раз на тот момент, когда начиналось фаза TIME_WAIT (до сброса). А значит - корректно написанное ПО должно безусловно вставить задержку не менее чем 2MSL при старте ПО.

PS: Или Вы думаете что в момент локального сброса устройства, этот же сброс автоматически распространится и на всех его удалённых партнёров кто с ним работал по сети и почистит все линки от задержанных кадров?  

[aaarrr 69]

Вы можете ставить хоть 5 минут задержки при старте. Но прежде чем советовать кому-либо следовать вашему примеру, вооружитесь соответствующими ссылками на RFC.

 

18 minutes ago, jcxz said:

PS: Или Вы думаете что в момент локального сброса устройства, этот же сброс автоматически распространится и на всех его удалённых партнёров кто с ним работал по сети и почистит все линки от задержанных кадров?  

Нет, я думаю, что вполне достаточно того, что "удаленные партнеры" получат RST на свои пакеты.

[jcxz 214]

47 минут назад, aaarrr сказал:

Нет, я думаю, что вполне достаточно того, что "удаленные партнеры" получат RST на свои пакеты.

А с чего они их получат?

47 минут назад, aaarrr сказал:

Вы можете ставить хоть 5 минут задержки при старте. Но прежде чем советовать кому-либо следовать вашему примеру, вооружитесь соответствующими ссылками на RFC.

Где я советовал кому-то следовать моему совету??? Приведите цитату пожалуйста.

Я всего лишь высказал гипотезу почему может быть задержка.

[aaarrr 69]

9 minutes ago, jcxz said:

А с чего они их получат?

Вы действительно настолько незнакомы с предметом?

 

9 minutes ago, jcxz said:

Я всего лишь высказал гипотезу почему может быть задержка.

По вашей гипотезе она не может быть, а "должна быть безусловно" (почти цитирую).

[jcxz 214]

10 минут назад, aaarrr сказал:

Вы действительно настолько незнакомы с предметом?

Пока что видно, что Вы с ним незнакомы.... Так как ничего по делу сказать не можете, а сразу переходите на личности.

PS: Если есть, что сказать по делу - говорите. Если нет - то ваше мнение насчёт моей компетенции мне не интересно.

PPS: И ещё раз советую изучить приведённую ссылку. И подумать - зачем нужно TIME_WAIT....

[aaarrr 69]

19 minutes ago, jcxz said:

Так как ничего по делу сказать не можете, а сразу переходите на личности.

Вас никто не заставлял высказываться по вопросу, в котором некомпетентны.

 

20 minutes ago, jcxz said:

PS: Если есть, что сказать по делу - говорите.

Заниматься ликбезом в данном случае не вижу смысла.

[mantech 40]

1 час назад, jcxz сказал:

PPS: И ещё раз советую изучить приведённую ссылку. И подумать - зачем нужно TIME_WAIT....

Соглашусь с aaarrr. Этот флаг выставляется, если устройство - сервер, и соединение было разорвано. Причем на задержки старта это никак не влияет, т.к. подсчитывается таймером стека. Что и может повлиять на стартовую задержку, так если устройство инитит клиентский сокет и потом тупо ожидает коннекта с сервером, но учитывая, что запросы SYN_SENT идут 3-6 раз и с интервалом в пол-секунды - это тоже не катит, тут что-то совсем мутное походу...

[jcxz 214]

7 минут назад, mantech сказал:

Соглашусь с aaarrr. Этот флаг выставляется, если устройство - сервер, и соединение было разорвано.

Какой "флаг"? Вы о чём?  

Если Вы про TIME_WAIT, то это не флаг, а одно из состояний машины состояний TCP.

Цитата

Причем на задержки старта это никак не влияет, т.к. подсчитывается таймером стека. Что и может повлиять на стартовую задержку, так если устройство инитит клиентский сокет и потом тупо ожидает коннекта с сервером, но учитывая, что запросы SYN_SENT идут 3-6 раз и с интервалом в пол-секунды - это тоже не катит, тут что-то совсем мутное походу...

Прочитайте приведённую мной ссылку выше. Особенно обратите внимание на следующее:

Каждый задержанный сегмент, прибывающий по соединению, которое находится в состоянии ожидания 2MSL, отбрасывается. Так как соединение определяется парой сокет в состоянии 2MSL, это соединение не может быть повторно использовано до того момента, пока мы не сможем установить новое соединение. Это делается для того, чтобы опоздавшие пакеты не были восприняты как часть нового соединения. (Соединение определяется парой сокет. Новое соединение называется восстановлением или оживлением данного соединения.)

Как мы уже показали на рисунке 18.13, обычно клиент осуществляет активное закрытие и входит в режим TIME_WAIT. Сервер обычно осуществляет пассивное закрытие и не проходит через режим TIME_WAIT. Можно сделать вывод, что если мы выключим клиента и немедленно его перестартуем, этот новый клиент не сможет использовать тот же самый локальный номер порта. В этом нет никакой проблемы, так как клиенты обычно используют динамически назначаемые порты и не заботятся, какой динамически назначаемый порт используется в настоящее время.

Однако, с точки зрения сервера все иначе, так как сервера используют заранее известные порты. Если мы выключим сервер, который имеет установленное соединение, и постараемся немедленно перестартовать его, сервер не может использовать свой заранее известный номер порта в качестве конечной точки соединения, так как этот номер порта является частью соединения, находящегося в состоянии ожидания 2MSL. Поэтому может потребоваться от 1 до 4 минут, перед тем как сервер будет перестартован.

 

Если стартовать стек без задержки, то условие "Это делается для того, чтобы опоздавшие пакеты не были восприняты как часть нового соединения" не может быть выполнено в общем случае.

[aaarrr 69]

19 minutes ago, jcxz said:

Если стартовать стек без задержки, то условие "Это делается для того, чтобы опоздавшие пакеты не были восприняты как часть нового соединения" не может быть выполнено в общем случае.

Покажите мне хоть один TCP-стек, который на старте просто отрабатывает тайм-аут. Или официальную рекомендацию из RFC так поступать.

На опоздавшие пакеты перезапущенное устройство просто ответит RST - у него нет соединений.

[jcxz 214]

10 минут назад, aaarrr сказал:

На опоздавшие пакеты перезапущенное устройство просто ответит RST - у него нет соединений.

Тогда зачем ввели это состояние TIME_WAIT? Если соединение было одно и оно закрыто - тоже устройство ответит RST. Зачем тогда TIME_WAIT?

[DASM 0]

1 hour ago, aaarrr said:

Вас никто не заставлял высказываться по вопросу, в котором некомпетентны.

 

Заниматься ликбезом в данном случае не вижу смысла.

[off] а эт по жизни, бегает по всем веткам, блеснет "знанийом", сообщит вопрошающему что тот лопух и свалит. Толку с "советов" как с козла молока [/off]

К сожалению в движке форума не наблюдается "черного списка"

[murmur 0]

Эх! Вот если бы с таким же рвением, какое вы проявляете сейчас, когда причина названа, если бы вы так же старались помочь, когда вопрос был только задан)))

Не в упрек, если что)

[mantech 40]

21 минуту назад, murmur сказал:

Не в упрек, если что)

Дык ясно дело, просто интересно стало, откуда эта задержка в стеке, да и при старте МК, когда все соединения закрыты по умолчанию... Кстати, там сервером или клиентом МК выступает? 

1 час назад, jcxz сказал:

Как мы уже показали на рисунке 18.13, обычно клиент осуществляет активное закрытие и входит в режим TIME_WAIT.

Дак чтоб попасть в этот режим, соединение должно быть открыто, а в данном случае, оно закрыто, т.к. программа только что запущена, да, клиент может попросить сервер открыть соединение, и если пред-е было прервано, то откроется новое и никаких задержек быть не должно.  Подобные задержки были разве, что в древних протоколах, аля NetBIOS и подобных.

[aaarrr 69]

1 hour ago, aaarrr said:

Покажите мне хоть один TCP-стек, который на старте просто отрабатывает тайм-аут. Или официальную рекомендацию из RFC так поступать.

Вообще, есть такая, причем прямо в RFC 793 (посыпаю голову пеплом):

Quote

  To be sure that a TCP does not create a segment that carries a
  sequence number which may be duplicated by an old segment remaining in
  the network, the TCP must keep quiet for a maximum segment lifetime
  (MSL) before assigning any sequence numbers upon starting up or
  recovering from a crash in which memory of sequence numbers in use was
  lost.

Правда

Quote

  TCP implementors may violate the "quiet time" restriction, but only
  at the risk of causing some old data to be accepted as new or new
  data rejected as old duplicated by some receivers in the internet
  system.

что они и делают.

 

И, разумеется, выполнение этого условия никоем образом не вынуждает стек завешивать остальную систему при старте.

[jcxz 214]

1 час назад, mantech сказал:

Дак чтоб попасть в этот режим, соединение должно быть открыто, а в данном случае, оно закрыто, т.к. программа только что запущена, да, клиент может попросить сервер открыть соединение, и если пред-е было прервано, то откроется новое и никаких задержек быть не должно.

Вы нарисуйте себе диаграмму состояния сокета. Вот например:

FIN_WAIT_2 -> TIME_WAIT -> CLOSED.

Про TIME_WAIT сказано, что оно должно быть не менее чем 2MSL.

Теперь предположим, что в самом начале TIME_WAIT процессор перезапускается и сразу запускает сетевой стек, который сразу переводит сокет в состояние CLOSED. Получается картина:

FIN_WAIT_2 -> CLOSED. что является нарушением работы автомата состояний TCP.

По всем внутренним переменным сокета состояние TIME_WAIT ничем не отличается от CLOSED.

А то что "программа только что запущена" - так удалённая сторона ведь не знает, что ваше устройство только что запущено. Если бы сигнал RESET распространялся с этого устройства по всей сети и все участники обмена могли сбросить свои машины состояний и кадры связанные со сброшенным устройством, тогда да - можно было бы сразу после старта ПО переходить в состояние CLOSED. Но, так как такой инфы нет, то сразу после старта сетевой стек должен переходить в начало состояния TIME_WAIT. Для всех TCP-сокетов. Ну или можно просто тупо сделать задержку старта TCP-стека после чего все сокеты перевести в CLOSED.

49 минут назад, aaarrr сказал:

Вообще, есть такая, причем прямо в RFC 793 (посыпаю голову пеплом):

Ну наконец-то...  Я это RFC не помню, но (имхо) из самой диаграммы автомата состояний TCP следует, что задержка работы TCP-сокетов при старте необходима. Ну разве только если заранее известно что раньше (до рестарта) эти сокеты не работали - тогда задержку можно опустить.

Цитата

И, разумеется, выполнение этого условия никоем образом не вынуждает стек завешивать остальную систему при старте.

Я вроде такого и не говорил. Я ещё в самом начале написал: "тормозиться может сетевая задача". Но если всё свалено в одну кучу задачу, то тогда эта задача будет тормозиться.

Можно конечно в составе сетевого API для всех функций запросов открытия сокетов с прикладного уровня внести проверку на истечение времени таймаута с момента старта стека, и сразу запускать сетевой сервис. Но проще просто сделать задержку - чтобы упростить API. Всё равно открыть сокеты в это время нельзя в общем случае.