форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Маршрутизаторы CISCO и др. оборудование. (Public)
Изначальное сообщение		[ Отслеживать ]

"tcp таймаут"

Сообщение от nicolayp on 31-Мрт-09, 08:45

Привет всем! В сетевом оборудовании не силен, поэтому прошу совета у знающих людей. Может ли какой-нибудь "умный" роутер блокировать установление tcp-соединения? Ситуация - имеются клиент и сервер, работающие по собственному протоколу поверх tcp. Довольно часто случается, что клиент ловит разрыв соединения по таймауту. Клиент очень простой, т.е. если он не успел отправить все данные до разрыва tcp-соединения, то он просто завершает свою работу с соответствующим кодом возврата. Далее скрипт по этому коду возврата может снова поднять клиента для доотправки данных. Так вот бывает так, что клиент при своем повторном поднятии не может подключиться к серверу. connect() _постоянно_ возвращает TIMEOUT, такое может продолжаться по нескольку часов. При этом если руками запустить новую копию клиента (можно даже несколько копий) - все подключаются с первого раза. Какое конкретно оборудование стоит между клиентом и сервером - не знаю. traceroute показывает 8 хопов. wireshark'ом на стороне клиента ничего необычного не увидел (исходящий syn и ... тишина, снова исходящий syn и тишина - это для копии запущенной скриптом, для остальных копий - все в порядке - syn, syn-ack, ack и далее...). Единственное отличие между копиями - различный исходящий tcp-порт. Не могу понять почему первая копия клиента не может установить соединение? Мое предположение - какие-то проблемы с маршрутизацией. Да, и как такое можно диагностировать? Спасибо.

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "tcp таймаут"

Сообщение от chocholl (??) on 31-Мрт-09, 09:59

а Вы попробуйте биндить клиент на рандомный порт. вполне возможно, что на трассе есть файервол с разбором tcp сессий, он то и может вносить смуту. >[оверквотинг удален] >тишина, снова исходящий syn и тишина - это для копии запущенной >скриптом, для остальных копий - все в порядке - syn, syn-ack, >ack и далее...). Единственное отличие между копиями - различный исходящий tcp-порт. > > >Не могу понять почему первая копия клиента не может установить соединение? Мое >предположение - какие-то проблемы с маршрутизацией. Да, и как такое можно >диагностировать? > >Спасибо.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "tcp таймаут"
	Сообщение от nicolayp on 31-Мрт-09, 10:48
	>а Вы попробуйте биндить клиент на рандомный порт. >вполне возможно, что на трассе есть файервол с разбором tcp сессий, он >то и может вносить смуту. Исходящий порт выбирается автоматически во время первого вызова connect(), он-то и используется при дальнейших коннектах данного экземпляра клиента. Естественно в каждой копии клиента будет свой уникальный исходящий порт. Могу добавить еще, что такое наблюдается когда клиент (точнее tcp-стек на стороне клиента) ловит разрыв по таймауту, т.е. клиент данные отправляет-отправляет, но не получает tcp-ack от сервера. Если поймать момент, когда соединение стабильно и перезагрузить приложение-сервер, клиенту будет отправлен rst, и тогда клиент при перезапуске _устанавливает_ соединение (не сразу конечно, первые несколько попыток коннекта завершаются с CONNREFUSED, это понятно, сервер только стартует). Получается, если "проблемный" фаервол/роутер не видит обратный rst-пакет, то непосредственно последующее соединение не устанавливается. Хотя там будет уже другой исходящий клиентский порт, и эти две сессии не должны пересекаться. У меня есть доступ только к машинам с клиентом и сервером. Подскажите, что спросить у тех, кто занимается этим каналом связи? Они говорят, что у них все нормально с оборудованием. А я даже не знаю куда их носом ткнуть, чтобы они посмотрели...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "tcp таймаут"
	Сообщение от GolDi (??) on 31-Мрт-09, 11:45
	>[оверквотинг удален] >CONNREFUSED, это понятно, сервер только стартует). > >Получается, если "проблемный" фаервол/роутер не видит обратный rst-пакет, то непосредственно последующее соединение >не устанавливается. Хотя там будет уже другой исходящий клиентский порт, и >эти две сессии не должны пересекаться. > >У меня есть доступ только к машинам с клиентом и сервером. Подскажите, >что спросить у тех, кто занимается этим каналом связи? Они говорят, >что у них все нормально с оборудованием. А я даже не >знаю куда их носом ткнуть, чтобы они посмотрели...   Я думаю ваши проблемы с клиентами никакого отношения к роутингу не имеют, советую зря не беспокоить тех кто занимается этим каналом.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "tcp таймаут"
	Сообщение от GolDi (??) on 31-Мрт-09, 11:48
	>[оверквотинг удален] >>эти две сессии не должны пересекаться. >> >>У меня есть доступ только к машинам с клиентом и сервером. Подскажите, >>что спросить у тех, кто занимается этим каналом связи? Они говорят, >>что у них все нормально с оборудованием. А я даже не >>знаю куда их носом ткнуть, чтобы они посмотрели... > >  Я думаю ваши проблемы с клиентами никакого отношения к роутингу >не имеют, > советую зря не беспокоить тех кто занимается этим каналом. Так как проблема лежит гораздо выше 3-его уровня модели OSI
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "tcp таймаут"
	Сообщение от nicolayp on 31-Мрт-09, 12:29
	>>  Я думаю ваши проблемы с клиентами никакого отношения к роутингу >>не имеют, >> советую зря не беспокоить тех кто занимается этим каналом. > >Так как проблема лежит гораздо выше 3-его уровня модели OSI Намекаете на 8-й уровень? :-) Теперь у меня подозрение, что клиент за NAT'ом находится, буду копать в этом направлении :-) Всем спасибо за ответы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "tcp таймаут"
	Сообщение от chocholl (??) on 31-Мрт-09, 12:58
	чтож вы про нат молчали. если нат организован патом, то используется параметр таймаут сессии. если вы в него попадаете, то подобное может происходить из-за смещения реальный и подставных портов источника. >[оверквотинг удален] >>> советую зря не беспокоить тех кто занимается этим каналом. >> >>Так как проблема лежит гораздо выше 3-его уровня модели OSI > >Намекаете на 8-й уровень? :-) > >Теперь у меня подозрение, что клиент за NAT'ом находится, буду копать в >этом направлении :-) > >Всем спасибо за ответы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "tcp таймаут"

Сообщение от Vladin (ok) on 31-Мрт-09, 10:29

You can use setsockopt() to set the SO_REUSEADDR socket option http://hea-www.harvard.edu/~fine/Tech/addrinuse.html

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]