Здравствуйте.
Имеется программа-клиент. Написана на 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; идёт запрос на соединение с этим же портом, у Виндовуса едет крыша, и он устанавливает соединение клиентского сокета с ним самим же под видом серверного сокета. В результате все данные, которые клиент посылает на сервер, принимаются этим же сокетом (как серверной стороной), но под видом ответа от сервера (так как сокет воспринимается клиентом как клиентский, а отнюдь не серверный)