Привет всем! В сетевом оборудовании не силен, поэтому прошу совета у знающих людей.Может ли какой-нибудь "умный" роутер блокировать установление tcp-соединения?
Ситуация - имеются клиент и сервер, работающие по собственному протоколу поверх tcp. Довольно часто случается, что клиент ловит разрыв соединения по таймауту. Клиент очень простой, т.е. если он не успел отправить все данные до разрыва tcp-соединения, то он просто завершает свою работу с соответствующим кодом возврата. Далее скрипт по этому коду возврата может снова поднять клиента для доотправки данных.
Так вот бывает так, что клиент при своем повторном поднятии не может подключиться к серверу. connect() _постоянно_ возвращает TIMEOUT, такое может продолжаться по нескольку часов. При этом если руками запустить новую копию клиента (можно даже несколько копий) - все подключаются с первого раза.
Какое конкретно оборудование стоит между клиентом и сервером - не знаю. traceroute показывает 8 хопов.
wireshark'ом на стороне клиента ничего необычного не увидел (исходящий syn и ... тишина, снова исходящий syn и тишина - это для копии запущенной скриптом, для остальных копий - все в порядке - syn, syn-ack, ack и далее...). Единственное отличие между копиями - различный исходящий tcp-порт.Не могу понять почему первая копия клиента не может установить соединение? Мое предположение - какие-то проблемы с маршрутизацией. Да, и как такое можно диагностировать?
Спасибо.
а Вы попробуйте биндить клиент на рандомный порт.
вполне возможно, что на трассе есть файервол с разбором tcp сессий, он то и может вносить смуту.>[оверквотинг удален]
>тишина, снова исходящий syn и тишина - это для копии запущенной
>скриптом, для остальных копий - все в порядке - syn, syn-ack,
>ack и далее...). Единственное отличие между копиями - различный исходящий tcp-порт.
>
>
>Не могу понять почему первая копия клиента не может установить соединение? Мое
>предположение - какие-то проблемы с маршрутизацией. Да, и как такое можно
>диагностировать?
>
>Спасибо.
>а Вы попробуйте биндить клиент на рандомный порт.
>вполне возможно, что на трассе есть файервол с разбором tcp сессий, он
>то и может вносить смуту.Исходящий порт выбирается автоматически во время первого вызова connect(), он-то и используется при дальнейших коннектах данного экземпляра клиента. Естественно в каждой копии клиента будет свой уникальный исходящий порт.
Могу добавить еще, что такое наблюдается когда клиент (точнее tcp-стек на стороне клиента) ловит разрыв по таймауту, т.е. клиент данные отправляет-отправляет, но не получает tcp-ack от сервера. Если поймать момент, когда соединение стабильно и перезагрузить приложение-сервер, клиенту будет отправлен rst, и тогда клиент при перезапуске _устанавливает_ соединение (не сразу конечно, первые несколько попыток коннекта завершаются с CONNREFUSED, это понятно, сервер только стартует).
Получается, если "проблемный" фаервол/роутер не видит обратный rst-пакет, то непосредственно последующее соединение не устанавливается. Хотя там будет уже другой исходящий клиентский порт, и эти две сессии не должны пересекаться.
У меня есть доступ только к машинам с клиентом и сервером. Подскажите, что спросить у тех, кто занимается этим каналом связи? Они говорят, что у них все нормально с оборудованием. А я даже не знаю куда их носом ткнуть, чтобы они посмотрели...
>[оверквотинг удален]
>CONNREFUSED, это понятно, сервер только стартует).
>
>Получается, если "проблемный" фаервол/роутер не видит обратный rst-пакет, то непосредственно последующее соединение
>не устанавливается. Хотя там будет уже другой исходящий клиентский порт, и
>эти две сессии не должны пересекаться.
>
>У меня есть доступ только к машинам с клиентом и сервером. Подскажите,
>что спросить у тех, кто занимается этим каналом связи? Они говорят,
>что у них все нормально с оборудованием. А я даже не
>знаю куда их носом ткнуть, чтобы они посмотрели...Я думаю ваши проблемы с клиентами никакого отношения к роутингу не имеют,
советую зря не беспокоить тех кто занимается этим каналом.
>[оверквотинг удален]
>>эти две сессии не должны пересекаться.
>>
>>У меня есть доступ только к машинам с клиентом и сервером. Подскажите,
>>что спросить у тех, кто занимается этим каналом связи? Они говорят,
>>что у них все нормально с оборудованием. А я даже не
>>знаю куда их носом ткнуть, чтобы они посмотрели...
>
> Я думаю ваши проблемы с клиентами никакого отношения к роутингу
>не имеют,
> советую зря не беспокоить тех кто занимается этим каналом.Так как проблема лежит гораздо выше 3-его уровня модели OSI
>> Я думаю ваши проблемы с клиентами никакого отношения к роутингу
>>не имеют,
>> советую зря не беспокоить тех кто занимается этим каналом.
>
>Так как проблема лежит гораздо выше 3-его уровня модели OSIНамекаете на 8-й уровень? :-)
Теперь у меня подозрение, что клиент за NAT'ом находится, буду копать в этом направлении :-)
Всем спасибо за ответы.
чтож вы про нат молчали.
если нат организован патом, то используется параметр таймаут сессии.
если вы в него попадаете, то подобное может происходить из-за смещения реальный и подставных портов источника.>[оверквотинг удален]
>>> советую зря не беспокоить тех кто занимается этим каналом.
>>
>>Так как проблема лежит гораздо выше 3-его уровня модели OSI
>
>Намекаете на 8-й уровень? :-)
>
>Теперь у меня подозрение, что клиент за NAT'ом находится, буду копать в
>этом направлении :-)
>
>Всем спасибо за ответы.
You can use setsockopt() to set the SO_REUSEADDR socket option