Здравствуйте.
Имеется программа-клиент. Написана на Qt-сокетах. Её задача - подключиться к программе-серверу и слать ему сообщения по событию и по таймеру. Попытки подключения производятся всё время, пока оно не будет установлено. Также при запросе от сервера она должна ему ответить. Всё отлично работает, если программа-сервер запущена. Если же программа-сервер не запущена - начинаются чудеса: нерегулярно (иногда через час работы программы, иногда - через 10..15 минут) мне приходит сообщение, что есть подключение к серверу. А затем ко мне приходят те же пакеты, которые я на этот сервер отсылал. Т.е. получается некий loopback. Когда это возникает, я смотрел программой tcpview на предмет кто же это мог быть. tcpview показывает, что таки действительно есть некий процесс system, который является сервером, который "слушает" порт, на который стучалась моя программа.
Теперь, собственно вопрос (он, похоже из области фантастики, но всё же...): может ли система создать сервер для "бедолаги", которой никто не отвечает, и зациклить на неё её же сообщения?
Щаз перечитал - бред полный, но я уже готов поверить всему )))

Environment: Windows XP Prof (впрочем, такое наблюдалось и на других Windows - Win7, WinServer 2003), Qt 4.8.4, MinGW 4.8.0.

Спасибо.

Первая мысль: вирус. Но, скорее всего, нет...
Вторая мысль: фаервол или антивирус, которые так специфически определяют угрозу компьютеру. Возможно...
Третья мысль: нужно точно установить, что это за процесс такой, который висит на серверном порту... (Номер порта не какой-нибудь особенный?) То есть с помощью разных утилит докопаться до имени и пути этого процесса.

borisbn, это происходит при разных номерах портов? SP все установлены?

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

Спасибо всем откликнувшимся. Прошу прощения, что задержался - работы много...


Исключено. Чистая виртуалка

Исключено. Фаервол я абсолютно точно отключил, а антивирус и не ставил


Номер порта 3333. Может, конечно, и особенный... Я хз.


Хмммм... Сменил на 13335 - вроде не происходило такого. Буду ещё экспериментировать. SP стоит 2-й (т.е. не все).

До того, как я сменил номер порта, в то время, как я получал эти фантомные ответы, tcpview показывал для моего процесса в колонке Remote Address - localhost:3333, а в колонке Local Address - linesm-cuprl:3333. Что, в общем-то, тоже непонятно. Когда я сменил номер порта на 13335, картина стала такой


Это сообщение отредактировал(а) borisbn - 16.12.2013, 19:41

Ситуация, конечно, несколько идиотская)))) Я тут ниже побурчу немножко, тоже по-идиотски)))



По картинке: пока соединения не видно, только запросы на соединение. И запросы идут на локальный хост - это правильно? Или запросы уходят на другой узел, а на картинке как раз странно написано "localhost"?



Насколько Вы доверяете этим самым Qt-сокетам? Быть может, в их реализации присутствует какая-то ошибка. Если схему подключения тупо переписать на обычных сокетах (не думаю, что это сложная задача для тестовых целей), то возникнет ли подобная ситуация? Недоверие возникло потому что:



Понаблюдайте за номерами исходящих портов, когда возникает незапланированное подключение. Возможно, какой-нибудь сетевой сервис в Windows так странно реагирует на ICMP-сообщение "Port Unreachable", если исходящий порт из какого-то "интересного" диапазона. Это бы объяснило:так как значение исходящего порта меняется при каждой попытке подключения. Хотя, конечно, об этом уже было бы известно)))


Последняя зелёная строка совсем не понятна, fmt_ukv - это тоже Ваш процесс? Почему порт 20005? Почему несколько одновременных запросов на cоnnect от одной и той же программы? 


Проверьте конфигурацию сети, мало ли что. Проверьте сетевой трафик, что уходит, что приходит. Есть ли ICMP-ответ?

Это я протупил.. Сделал скриншот после изменения порта (читай после разрыва соединения. Кстати, "останки" этого соединения остались - первая строка на скрине).


Да. Я пытаюсь соединиться с 127.0.0.1:3333


Самое интересное, что сначала я делал на обычных сокетах, а потом, когда начался этот идиотизм - переделал на Qt... Последнему, в общем-то, полного доверия нет, но как-то не верится, что там такая ошибка - зацикливание сообщений...

fmt_ukv - да. мой.

Не знаю. Первое, что в голову пришло.

Ну... такая логика программы. В общем, так нужно. А почему бы и нет ?

Ок... Беру таймаут и сделаю то, с чего нужно было начинать - напишу простенький тест и погоняю его. Хотя, всё равно не понятно... Боевая программа достаточно маленькая и простая...

borisbn, судя по скриншоту, все работает нормально: видны нормальные запросы на соединение, на которые пока никто не ответил.
System Process:0 это IdleProcess, в данном случае просто остатки соединения: соединение еще не закрыто (не было fin, таймаут еще не подошел), но процессов, его обслуживающих, уже нет.
Это не то что бы нормальная, но вполне объяснимая ситуация.

Добавлено через 21 секунду
вот кстати

Добавлено через 1 минуту и 19 секунд

как-то слабо в это верится

До разрыва соединения первая строчка была посередине, состояние было ESTABLISHED и процесс был не System, а мой.

Про "останки" соединения понял. Спасибо. Но это не объясняет, откуда оно вообще взялось...

а ваш процесс точно только запрашивает соединение?

Вообще-то - нет. Он ещё создаёт 2 сервера, но на портах 10009 и 20003. И уж точно эти серверы не разворачивают сообщения назад.
Я прошу прощения - у меня сейчас цейтнот на работе. Как будет поспокойнее - сделаю простенький тест и попробую повторить.

Периодически создаёт (то есть может ли иногда закрывать сокеты по каким-то своим причинам, а потом переоткрывать сокеты) или один раз вначале создаёт, и на этом всё?

Добавлено через 58 секунд

Ну да)))

> один раз вначале создаёт, и на этом всё
Ну... Как и положено серверу, при подключении клиента сокет создаётся автоматически и удаляется при разрыве соединения. В моём случае клиенты подключались один раз и больше не отключались. По каким-либо другим причинам/событиям сервер не пересоздаётся. 

Я имел в виду прослушивающий сокет   

Тут меня немного осенило. Не может ли возникать такая ситуация, когда номер исходящего порта клиентского сокета совпадает с номером серверного порта, на который устанавливается соединение? То есть порт 3333 на локальной машине свободен (сервер не запущен), в результате последовательной смены номера клиентского порта этот номер становится 3333; идёт запрос на соединение с этим же портом, у Виндовуса едет крыша, и он устанавливает соединение клиентского сокета с ним самим же под видом серверного сокета. В результате все данные, которые клиент посылает на сервер, принимаются этим же сокетом (как серверной стороной), но под видом ответа от сервера (так как сокет воспринимается клиентом как клиентский, а отнюдь не серверный)   

гы. возможно. у windows динамические порты 1025-5000.

Да. Я тоже об этом думал. И это, кстати, подтверждается тем, что когда это фантомное соединение устанавливается, исходящий порт становится равным 3333. А то, что на 13335 я этого не видел, возможно, говорит о том, что я просто не дождался этой ситуации. Щаз попробую на каком-нибудь 1400, чтобы быстрее воспроизвести.


Не очень понял, что это.... Если Вы предполагаете, что я вызывал подобный скрипт, то это не так. Если предлагаете это сделать, то объясните, пожалуйста, что это и зачем. Спасибо.

Так на 13335 можно и не увидеть, так как

По умолчанию. Если установлены какие-то дополнительные компоненты, то диапазон может быть и другой.



Что-то из этой области...

это способ установить диапазон исходящих портов в win

Это я понял )) Кстати, я уже нарыл, что в XP это делается только через реестр. В netsh таких команд нет.
Ещё я вычитал, что в XP диапазон этих "эфемерных" портов - 1025...5000. Так что я могу спокойно уйти за этот диапазон и надеяться, что больше мне Windows """"помогать""" не будет ))

Порты то у Винды с 1025 динамические, да не очень.
Всего в 10 циферках от 3333 порта сидит 3343, который приписан к службе каталогов.
Кроме этого, по всему диапазону динамических портов распределяются под RPC (мне малоизвестным динамическим образом, в руководствах написано, что сначала идут запросы на три порта 12х, где постоянные службы перенаправляют уже на указанные порты). Можете уточнить у админа, диапазон портов "от 1045 до упора" админы могут ещё урезать c целью ограничить именно диапазон портов, разрешённых именно для RPC. Но, думаю, что здесь дело вообще в другом.
Порт 3333 стандартный динамический порт под Windows, который встречается во многих примерах "возьмём, например, 3333 порт, и ..". Вероятнее всего, что где-то на серваке стоит дыра в чьей-то программе или, ещё проще, чья-то программа раз в полчаса-час пробует юзать этот порт и тут вы встречаетесь.

Для большей точности надо отьюзать порт 3332 или 3331. Если картина не повторится, значит, надо ставить в известность админа, пусть сам разбирается, какая прога у него проявляет активность по порту 3333.


Это сообщение отредактировал(а) akizelokro - 6.1.2014, 16:20

Притом, совершенно непонятно, почему в XP динамические порты только до 5000.
может, эта йцифра как "историческое наследие" ("шоб було" и "этапы большого пути"), а дальше лень всем стало кучу руководств переписывать?

Меня всегда мущали рассуждения, то в Винде XP порты от 1025, хотя я млин всегда считал что то ли от 1045, то ли от 1048