МО>потом — нормальный обмен. меня настораживают эти ZeroWindow, которые от Висты приходили. у нее не хватало буфферов для приема?

Обычно пакет с window = ZeroWindow и флагом ACK действительно посылается при переполнении входного буфера для приостановки передачи. Но. Судя по значениям Seq и Ack = 1, данный пакет был послан сразу после установки соединения. Есть подозрение, что данное соединение установлено, но еще не принято сетевым приложением ( т.е не было вызова accept ), возможно приложение зависло. Также возможно, действуют какие то ограничения на кол-во устанавливаемых соединений в единицу времени. У вас виста не Home Edition? Третье предположение ( маловероятное ) — на висте работают кривые драйвера, которые расходуют NonPaged pool ( можно посмотреть соответствующее значение в диспетчере задач ).

Привет!
начала проявляться проблема, не могу пока понять в чем дело, в инете описания похожих вещей тоже не встречал. при коннекте TCP сокета с проги, выполняющейся на XP к прослушивающему сокету в той же проге, выполняющейся на Vista иногда возникает задержка до 40 минут. После этого ожидания, сеанс связи происходит успешно, данные передаются.
Насколько я выяснил (я и сейчас с этим занимаюсь, поэтому возможны апдейты), установление связи на стороне, которая пытается подключиться, подвисает на connect, и возвращает успех, когда срабатывает listen на передающей. может я протупил, но в течение этих 40 минут, на обоих компах netstat показывал это соединение как ESTABLISHED. сейчас пытаюсь это проверить, но не могу воспроизвести.
если кто располагает какой инфой по теме, поделитесь, плиз.
спасибо!

Несколько фактов:
1. На висте есть фаервол и он работает в так называемом режиме "невидимости". Это значит, когда приходит SYN пакет ( это реакция на вызов connect ) на закрытый порт, в ответ ничего не уходит ( никого нет дома ). Если фаервол отключить, при попытке соединиться с закрытым портом сразу последует ответ RST и вызов connect окончится с соответствующим кодом ошибки. Вот почему клиент может висеть на connect e.
2. соединения устанавливает tcp/ip cтек, для установления соединения не нужен вызов accept. Поэтому в Вашем случае сразу после вызова listen в списке может появится estblished соединение — ведь с другой cтороны хост долбят SYN ом ( см ф.1 — SYN ом будут долбить долго : )
3. данные не будут передаваться, пока не будет вызова accept

Здравствуйте, TarasCo, спасибо за эти факты!

Вы писали:

TC>1. На висте есть фаервол и он работает в так называемом режиме "невидимости". Это значит, когда приходит SYN пакет ( это реакция на вызов connect ) на закрытый порт, в ответ ничего не уходит ( никого нет дома ). Если фаервол отключить, при попытке соединиться с закрытым портом сразу последует ответ RST и вызов connect окончится с соответствующим кодом ошибки. Вот почему клиент может висеть на connect e.

т.е. вы предполагаете, что сокет был закрыт ранее? или именно порт?

TC>2. соединения устанавливает tcp/ip cтек, для установления соединения не нужен вызов accept. Поэтому в Вашем случае сразу после вызова listen в списке может появится estblished соединение — ведь с другой cтороны хост долбят SYN ом ( см ф.1 — SYN ом будут долбить долго : )
TC>3. данные не будут передаваться, пока не будет вызова accept

так получилось, что в процессе работы соединение с компами устанавливается и закрывается несколько раз. но я не замечал ошибок в реализации этого механизма. приложение работает уже очень долгий срок, и эти странности возникают именно на Vista.
з.ы. с утра не могу добиться воспроизведения ошибки...

МО>т.е. вы предполагаете, что сокет был закрыт ранее? или именно порт?

Я комментировал Вашу фразу:

"Насколько я выяснил (я и сейчас с этим занимаюсь, поэтому возможны апдейты), установление связи на стороне, которая пытается подключиться, подвисает на connect, и возвращает успех, когда срабатывает listen на передающей."

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

МО>так получилось, что в процессе работы соединение с компами устанавливается и закрывается несколько раз. но я не замечал ошибок в реализации этого механизма. приложение работает уже очень долгий срок, и эти странности возникают именно на Vista.

Возможно, у Вас не хватает каких нибудь флажков вроде SO_REUSEADDR ( рекомендуется установить его, если сокет будет слушающим ). А вообще, первым делом, отключите фаервол, если баг не перестанет проявляться — тогда уже ищете ошибки.

Здравствуйте, TarasCo, Вы писали:

да нет, там отдельный поток, который обслуживает listen, пускается сразу по старту приложения. если управление выходит из listen, то тут же создается новый поток, ему передаются параметры сокета, и новый поток вызывает accept. у меня получается, что управление не возвращается из вызова listen длительное время...

TC>А вообще, первым делом, отключите фаервол, если баг не перестанет проявляться — тогда уже ищете ошибки.

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

TC>Возможно, у Вас не хватает каких нибудь флажков вроде SO_REUSEADDR
насколько я понял, я не должен его устанавливать. у меня есть порт П0. этот порт я передаю в listen. другой комп коннектится к этому порту, только один раз(в этом я уверен на 100%; все сокеты создаются из фабрики. если придет запрос на создание(и соответственно, коннект) к сокету, который еще не возвращен фабрике другим потоком-пользователем, фабрика заставит запрашивающий поток ждать завершения предыдущего). разве я должен был юзать SO_REUSEADDR, при условии, что имею лишь один входящий коннект с одного IP адреса? подключаться друг к другу одновременно они могут; т.е. комп А может подключиться к Б на порт П0, потом Б подключается к А на П0...

МО>у меня получается, что управление не возвращается из вызова listen длительное время...
Это довольно странно. Системе не нужно асинхронных операция для прослушивания порта. Еще один довод, что это фаервол. Причем, возможно, даже не родной.

МО>разве я должен был юзать SO_REUSEADDR, при условии, что имею лишь один входящий коннект с одного IP адреса? подключаться друг к другу одновременно они могут; т.е. комп А может подключиться к Б на порт П0, потом Б подключается к А на П0...
Не должен. Этот флаг ставят для серверов в рекомендательном порядке, на случай такой ерунды: если служба вдруг упадет, возможно ее захотят поднять. А после активной работы сервера могут быть соединения в состоянии TIME_WAIT ( это нормально и правильно ), которые могут висеть до 2х минут. В течении этого времени службу не удасться поднять — порт будет считаться занятым, если не установить флажок SO_REUSEADDR. Я написал про флажок предположив, что во время отладки вы иногда перезапускаете службу и такие вещи могут проявляться.

Здравствуйте, TarasCo, Вы писали:

TC>предположив, что во время отладки вы иногда перезапускаете службу и такие вещи могут проявляться.

спасибо! действительно, иногда ее даже убивают через Task Manager. в этих случаях netstat показывает, что некоторые сокеты висят в состоянии CLOSE_WAIT. так вот, пока в системе есть такие сокеты (с портом, на который я коннекчусь), коннект задерживается, и некоторое время просто висит. вчера у меня получилось один раз этого добиться, но сегодня я не могу добиться воспроизведения таким образом. да, файрволы отключены.

к сожалению, проблема снова проявляется.
удается проследить, что это проявляется когда в сети появляется некоторое количество (3-5) компов, с активными VPN соединениями. этот сервис периодически рассылает UDP сообщения (широковещательные), оповещая о том, что на компе запущен мой сервис. в случае, когда активно VPN соединение, UDP пакет посылается через каждый IP-канал, который нахожу на компе. не понимаю почему, но иногда бывает, что пакет, который отрпавился через VPN возвращается, и сервисы пытаются подключиться по TCP к адресу пакета и обламываются. мне кажется, что в случае, когда много этих обломов, Виста подтормаживает входящие коннекты...
ребят, если кто-то находит что-то, что не правильно, или есть идеи, как понять, где есть что-то неправильное, озвучьте пожалуйста

МО> но иногда бывает, что пакет, который отрпавился через VPN возвращается, и сервисы пытаются подключиться по TCP к адресу пакета и обламываются.

что значит "пакет возвращается" ??? Просто так он не может возвратиться. Либо где то есть loopback ( у сетевой карты может быть такой режим — копия отсылаемых пакетов отправляется наверх, обычно снифферы переводят сетевые карты в такой режим, чтобы увидеть отправляемый трафик ), либо с другой стороны отвечают согласно протокола. Может также быть возвращен ICMP пакет c кодом ошибки — недостижимый адрес или закрытый порт ( windows системы никогда не отвечают на броадкасты, но другие оси — могут ). Так что уточните, что именно "возращается" ?

Еще интересный вопрос, какой именно броадкаcт отсылаете вы c VPN интерфейса. Для броадкаста 255.255.255.255 должен стоять TTL=1 и он не должен по идее выйти дальше VPN сервера, соответственно, на него не должны отвечать ( если последний не производит манипуляций с TTL — некоторый маршрутизаторы работают "нечестно" пытаясь скрыть свое существование и не изменяют TTL ). Лучше в качестве броадкаст адреса использовать броадкаст адрес подсети ( например 192.168.255.255 ).

Проделайте следующий эксперимент: в момент "зависания" процедуры установки соединения, попробуйте сделать ping ( или tracert ) на тот адрес, с который сервис пытается соединиться. Еще можно попробовать включить на машине с вистой фаервол и запретить входящие ICMP.

Здравствуйте, TarasCo, Вы писали:

МО>> но иногда бывает, что пакет, который отрпавился через VPN возвращается, и сервисы пытаются подключиться по TCP к адресу пакета и обламываются.


TC>Еще интересный вопрос, какой именно броадкаcт отсылаете вы c VPN интерфейса. Для броадкаста 255.255.255.255 должен стоять TTL=1 и он не должен по идее выйти дальше VPN сервера, соответственно, на него не должны отвечать ( если последний не производит манипуляций с TTL — некоторый маршрутизаторы работают "нечестно" пытаясь скрыть свое существование и не изменяют TTL ). Лучше в качестве броадкаст адреса использовать броадкаст адрес подсети ( например 192.168.255.255 ).

бродкаст на 255.255.255.255 с временем жизни 1. пытаюсь разобраться, что это такое приходит.
переделываю

TC>Проделайте следующий эксперимент: в момент "зависания" процедуры установки соединения, попробуйте сделать ping ( или tracert ) на тот адрес, с который сервис пытается соединиться. Еще можно попробовать включить на машине с вистой фаервол и запретить входящие ICMP.

пингуется, трассируется.

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

217 8.677350 10.11.13.242 10.11.13.177 TCP mediaspace > 5950 [ACK] Seq=1 Ack=1 Win=65535 Len=1
218 8.677573 10.11.13.177 10.11.13.242 TCP [TCP ZeroWindow] 5950 > mediaspace [ACK] Seq=1 Ack=1 Win=0 Len=0
5290 128.652055 10.11.13.242 10.11.13.177 TCP [TCP Keep-Alive] mediaspace > 5950 [ACK] Seq=1 Ack=1 Win=65535 Len=1
5291 128.652247 10.11.13.177 10.11.13.242 TCP [TCP ZeroWindow] 5950 > mediaspace [ACK] Seq=1 Ack=1 Win=0 Len=0
6578 147.569449 10.11.13.177 10.11.13.242 TCP [TCP Window Update] 5950 > mediaspace [ACK] Seq=1 Ack=1 Win=65520 Len=0
6579 147.569489 10.11.13.242 10.11.13.177 TCP [TCP Retransmission] mediaspace > 5950 [ACK] Seq=1 Ack=1 Win=65535 Len=1260

потом — нормальный обмен. меня настораживают эти ZeroWindow, которые от Висты приходили. у нее не хватало буфферов для приема? пытаюсь в этом разобраться в слепую, т.к., признаться, не понимаю, как добиться устойчивого воспроизведения.

Здравствуйте, TarasCo, Вы писали:

TC>Обычно пакет с window = ZeroWindow и флагом ACK действительно посылается при переполнении входного буфера для приостановки передачи. Но. Судя по значениям Seq и Ack = 1, данный пакет был послан сразу после установки соединения. Есть подозрение, что данное соединение установлено, но еще не принято сетевым приложением ( т.е не было вызова accept ), возможно приложение зависло. Также возможно, действуют какие то ограничения на кол-во устанавливаемых соединений в единицу времени. У вас виста не Home Edition? Третье предположение ( маловероятное ) — на висте работают кривые драйвера, которые расходуют NonPaged pool ( можно посмотреть соответствующее значение в диспетчере задач ).

Vista Enterprise.
невыгружаемая память не расходуется.

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

while(inst.m_Listening)
        {
            try
            {
                m_Socket->Listen();
                SOCKET incomming = m_Socket->Accept();
                if(incomming == INVALID_SOCKET)
                    continue;

                CSocketPtr sp(new CSocket(incomming));

                CMessageThread * thr = new CMessageThread(sp);
                thr->DeleteWhenFinish(true);
                thr->BeginThread();
            
            }
            catch(...)
            {
            }
        }
        return 0;

thr выполняет getpeername и потом overlapped прием 4 байт (WSARecv) кода операции, хотя шлются они большими пачками.
2 раза мне удалось поймать ее в дебаггере — оба раза приложение висело в аccept.

Я правильно понимаю мысль: открывается на прослушку порт, принимается ОДНО соединение, которое обрабатывается в отдельном потоке, порт закрывается, с соединением работаем....

Если это так, то возможно следует рассмотреть пристальней следующие ситуации ( попытаться форсировать их возникновение ):
1. после того как слушающий порт закрыли, может ли через достаточно короткое время ( ~1-2 минут или меньше ) открыться новый? Может ли быть ситуация когда номер вновь открытого порта совпадает со старым?
2. возможно ли ситуация, когда на один порт пытаются приконнектиться несколько клиентов?

Здравствуйте, TarasCo, Вы писали:

TC>Я правильно понимаю мысль: открывается на прослушку порт, принимается ОДНО соединение, которое обрабатывается в отдельном потоке, порт закрывается, с соединением работаем....

совершенно верно, только прослушивающий порт не закрывается. он продолжает работать и ловить входящие соединения. закрывается он при завершении сервиса.

TC>2. возможно ли ситуация, когда на один порт пытаются приконнектиться несколько клиентов?

да, на один порт коннектятся несколько клиентов. притом один клиент может приконнектиться, отвять, потом коннектитться опять.

МО>совершенно верно, только прослушивающий порт не закрывается. он продолжает работать и ловить входящие соединения. закрывается он при завершении сервиса.

меня форматирование вашего кода сбило с толку. Тогда получается, что Listen зовется несколько раз на один и тот же сокет? Не знаю, хорошо ли это?

МО>да, на один порт коннектятся несколько клиентов. притом один клиент может приконнектиться, отвять, потом коннектитться опять.

при этом у него должен быть другой номер порта, ведь вы для клиентов порты не фиксируете?

Здравствуйте, TarasCo, Вы писали:

TC>Listen зовется несколько раз на один и тот же сокет? Не знаю, хорошо ли это?

где-то пробегало, что безразлично... я разницы не заметил.

МО>>да, на один порт коннектятся несколько клиентов. притом один клиент может приконнектиться, отвять, потом коннектитться опять.
TC>при этом у него должен быть другой номер порта, ведь вы для клиентов порты не фиксируете?

мое клиентсерверное приложение ожидает коннекта на порт 5950, все компьютеры в локалке на один и тот же порт. они коннектятся каждый раз с разных портов, это хорошо прослеживается по логам.

сейчас удалось поймать начало подвисона, конца так и не дождался. похоже, что TCP модуль успешно принимает данные, но, по какой-то причине не передает их приложению.
6854 32.776088 10.11.13.242 10.11.13.177 TCP spectardb > 5950 [ACK] Seq=71829 Ack=1 Win=65535 Len=1260
... успели 72 кила передать
6872 32.778134 10.11.13.177 10.11.13.242 TCP 5950 > spectardb [ACK] Seq=1 Ack=71829 Win=2464 Len=0
... подтверждено
... пропущено много пакетов, не имеющих отношение к моим адресам, и TCP
10492 37.957391 10.11.13.177 10.11.13.242 TCP [TCP ZeroWindow] 5950 > spectardb [ACK] Seq=1 Ack=74293 Win=0 Len=0
... все, больше не принимаю

действительно, выглядит как подвисон на принимающей стороне.

Здравствуйте, TarasCo.

большое спасибо, без Вашего участия мне было бы труднее найти эту проблему. скорее всего, в Висте по-другому реализовано планирование потоков, и, поток, который обрабатывал входящие сообщения (т.е. уже после accept, перед тем, как нужно было понять, что нам пытаются сообщить), конкурировал с другим потоком на общем ресурсе. после небольшого изменения правил обладания ресурсом, все заработало, как на ХР. еще раз, спасибо!