Имеется своё сетевое приложения на клиенте и сервере. Подключаюсь с клиента к серверу по tcp. Соединение есть, идёт обмен данными, но спустя 5-10 сек. соединение обрывается. Приложение клиента никаких ошибок не выдаёт, лишь сервер говорит что удалённый хост разорвал соединение. 
Поставил сетевой анализатор и увидел что во время обмена вдруг ни с того ни с сего клиент отправляет пакет с установленным флагом RST(на этом соединение и завершается). 
По каким причинам  может отправляться такой пакет во время обмена? Неисправная сетевая карта или драйвер? Т.е. из-за чего?

Как ведут себя другие приложения?

Lexicss, посмотрите на своего клиента, код имеется ввиду. в нем гвоздь, скорее всего.

Ксожалению, такая ситуация происходит на компьютере пользователя, который за 300 км от меня. Как себя ведут другие приложения, сложно сказать, вроде он там работает по сети. Или может именно этот порт глючный с которым моё приложение работает, может быть такое?  Но могу сказать что на других компьютерах это приложение работает. Когда я через модем(пользователь живёт в другом городе) подключаюсь своим приложением к его серверу - ничего не обрывается при обычной работе с нагрузкой. И даже если пользователь подключается с другого компьютера(т.е. другого клиента) ЭТИМ ЖЕ ПРИЛОЖЕНИЕМ, то тоже утверждает что всё работает. В своём приложении я сделал вывод ошибок по любой неадекватной ситцации сокетов, но ошибок нету на клиенте. 
Т.е. подозрения что это что-то системное, но даже если и так то хочется досконально разобраться почему такое поведение.

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

Код приложения сетевой подсистемы выложить не смогу, очень большой.

Добавлено через 11 минут и 24 секунды
Могу выложить протокол сетевого обмена во время разрыва(*.pcap) если это поможет. :/

Это сообщение отредактировал(а) Lexicss - 3.9.2010, 13:55

давайте попробуем посмотреть.

Файл сделан в wireshark 1.1.2
Немного прокомментирую: Анализатор засёк два подключения к серверу с обрывами, сегмент 12 и сегмент 36 - посылка клиентом пакета с флагом RST.

Присоединённый файл ( Кол-во скачиваний: 7 )
 281.pcap 9,46 Kb

В описании пакета есть текст ошибки:
Acknowledgement number: Broken TCP. The acknowledge field is nonzero while the ACK flag is not set

Хотя этого пакета я не вижу, из-за которого рвётся tcp.

Судя по номерам поcледовательностей в пакетах у вас вырезан из pcap файла весь пользовательский трафик, а это сделано зря, покажите пакеты между последним ACK и RST.

P.S. Похоже на той стороне кто-то путается с полями tcp заголовка в пользовательском трафике...

Это сообщение отредактировал(а) Secandr - 6.9.2010, 15:06

Secandr, Да ничего и не вырезал. Wireshark установлен на компе клиента(10.252.17.38) и ведётся весь траффик связанный с портом 5958. Может тока что wireshark не обнаруживает какие-то пакеты.
И судя по последовательностям, вроде как всё верно, 
если я , конечно правильно понимаю.  К Номер след. последовательности добавляется длина данных. например, если рассмотреть пакеты клиента начиная с 32-го.
32.Seq=83, Len = 47
34.Seq=130=83+47, Len = 47
36.Seq=177=130+47, Len = 0.

Единственное что, в пакете с ошибкой содержится неверной значение абсолютного подверждения(ACK), т.е. кал-будто клиент предыдущий пакет принял с нулевыми данными.


Это сообщение отредактировал(а) Lexicss - 7.9.2010, 10:52

попробуйте поставить фильтр не на порт, а на хост:
host 10.252.17.31

seq изменяется на 1 при пересылке каждого кадра, у вас судя по всему поймалась только сигнализация самого tcp без данных из-за фильтра, а ошибка в пакете с данными ИМХО.

Как окзалось такую ситуация вызывала на клиенте функция shutdown - закрывающая сокет на приём, именно это и приводило к посылке флага RST.
Спасибо всем кто откликнулся и помогал.

что за функция shutdown?

Secandr, Remarks

shutdown is used on all types of sockets to disable reception, transmission, or both.
If how is SD_RECEIVE, subsequent receives on the socket will be disallowed. This has no effect on the lower protocol layers. For TCP sockets, if there is still data queued on the socket waiting to be received, or data arrives subsequently, the connection is reset, since the data cannot be delivered to the user. For UDP sockets, incoming datagrams are accepted and queued. In no case will an ICMP error packet be generated.

If how is SD_SEND, subsequent sends are disallowed. For TCP sockets, a FIN will be sent.
Setting how to SD_BOTH disables both sends and receives as described above.
Note that shutdown does not close the socket, and resources attached to the socket will not be freed until closesocket is invoked.

И обратил внимание что wireshark выдавало пакет с флагом RST именн по выполнению у меня на клиенте функции (shutdown(Sock, SD_BOTH) или если второй параметр поставить SD_RECEIVE

Добавлено через 6 минут и 56 секунд
Теперь у меня уже другая проблема. На клиенте при приёме данных выдаётся ошибка, что не хватает буфферов.
Если кто желает помочь/подсказать буду признателен, подробнее здесь. http://forum.vingrad.ru/forum/topic-309944...wsaenobufs.html