вызов CancelIO не помогает.

проблема в том что накапливается очень быстро большое число объектов для которых HasOverlappedIoCompleted всегда возвращает FALSE

А если через GetQueuedCompletionStatus попробовать?

CancelIO надо вызывать из того же потока, который эту IO инициировал.

И да, если закрыть сокет, то все pending IO обязательно отменятся с соответствующим кодом ошибки.

не уверен что приемлемо ее вызывать из потока в котором объекты киляются для определения статуса.

в частности оъект на удаление может и дважды и трижды попасть в список.

Вот с этого и надо начать все разгребать. Простой атомарный флаг "объект в расстрельном списке" решает проблему. Удалось атомарно поменять 0 на 1 - значить можно спокойно вызвать closesocket прямо там же и поместить объект в список.

Это рождает каскад других побочных проблем - в частности оъект на удаление может и дважды и трижды попасть в список.

А пометить его никак нельзя?

факт помещения объекта в очередь на удаление разве не метка?

Ну раз у тебя один и тот же объект 2 раза в очередь попадает, то значит нет.

А, теперь понятно. В моем типовом коде IOCP сервере есть счетчик pending IO операций. Когда вызываю WSASend/WSARecv/AcceptEx/DisconnectEx, счетчик увеличивается, когда получаю результат через GetQueuedCompletionStatus, счетчик уменьшается. Если счетчик стал равен 0 и объект помечен на удаление, то он удаляется (на самом деле не удаляется, а зачищается от старых данных и помещается в пул свободных объектов).

Добавлено 24.03.16, 15:14
Так что просто помечай на удаление, вызывай closesocket + считай, сколько там осталось pending IO.

Any pending overlapped send and receive operations ( WSASend/ WSASendTo/ WSARecv/ WSARecvFrom with an overlapped socket) issued by any thread in this process are also canceled. Any event, completion routine, or completion port action specified for these overlapped operations is performed. The pending overlapped operations fail with the error status WSA_OPERATION_ABORTED.

Более того мы можем 10 раз вызвать WSARecv и получить все данные за дин вызов. Как корректно счетчик тогда вести?

чем это будет отличаться от проверки HasOverlappedIoCompleted которая у меня есть и которая не надежно работает ?

Do not call this macro unless the call to GetLastError returns ERROR_IO_PENDING, indicating that the overlapped I/O has started.

- внутренняя серверная логика приняла решение что клиент должен быть дисконнектнут

progman
HasOverlappedIoCompleted вообще не необходимости использовать. GetQueuedCompletionStatus в любом случае вернет результат операции, либо когда она сама завершится, либо будет отменена из-за closesocket. Кстати, у тебя на один объект только один OVERLAPPED буфер ("объект унаследованный от OVERLAPPED")? Тогда тебе категорически нельзя вызывать любые overlapped операции с объектом, если текущая не завершилась. Может в этом проблема?

Возможно HasOverlappedIoCompleted ненадежно работает поэтому:

Вот у меня есть поток в который приходит команда - объект номер 1234 нужно убить.

Do not call this macro unless the call to GetLastError returns ERROR_IO_PENDING, indicating that the overlapped I/O has started.

Вот у меня есть поток в который приходит команда - объект номер 1234 нужно убить.

Как мне дальше правильно поступить?

Как мне дальше правильно поступить?

т.к. он может вернуть управление через произвольное время.

Ну если хотя бы 1 одна операция с этой структурой overlapped была инициализирована до этого, то этот макрос должен работать нормально. Но я вообще никогда не видел в коде IOCP ее использования.

Synchronization Macros

The following macros are used with synchronization:
HasOverlappedIoCompleted
MemoryBarrier
PreFetchCacheLine
YieldProcessor

И согласен с Pacific, что можно достаточно следить только за GetQueuedCompletionStatus.

Что за объект - поточнее:
1. Это одиночная оверлапнутая структура?
2. Это буфер нескольких таких структур?
3. ???варианты...
Определив что за объект, однозначно четко распознать статус самого объекта или что с ним еще может быть связано.
После этого что приемлемо по статусу - убивать...
Где-то так...мож что не въехал...

под каждого законенктившегося клиента создается объект

я закономерность не понимаю Она по разному себя ведет.
GetQueuedCompletionStatus выдаст в поле *lpOverlapped только что удаленный объект. "только что" понятие тут растяжимое может вызваться через миллисекунду а может через 3 секунды ( у меня рекорд 5 секунд был )

Проблема
После асинхронного ввода-вывода на жесткий диск, HasOverlappedIoCompleted возвращает TRUE, а также GetOverlappedResult() возвращает 0 байт, переданных проблемы приложения (например, Microsoft SQL Server).

Примечание: После нескольких микросекунды, GetOverlappedResult() возвращает правильное значение.
Причина
В первую очередь эта проблема наблюдалась на компьютерах, симметричная многопроцессорная обработка (SMP), где завершения ввода/вывода обновляет поля в структуре OVERLAPPED в неверном порядке.

Падений нет но куча объектов никогда не удаляются и очередь растет.

в рабочем потоке может произойти вызов GetQueuedCompletionStatus а может и не произойти - я закономерность не понимаю Она по разному себя ведет.

А есть гарантия, что на момент закрвтия сокета есть активные операции ввода-вывода?
Тут мне видится 2 ситуации:
1. Операций нет и все можно сделать прямо на месте.
2. Есть операции, объект надо пометить, сокет закрыть и ждать когда завершится последняя операция.
Тут только с синхронизацией надо аккуратно.

все замечательно - но как я узнаю что операция есть?

и как я узнаю что она закончена?

Ты можешь для отладки сделать счетчики, как Pacific советует?

Если пришло по ней событие - значит закончена, счетчик уменьшился на 1.

При этом после закрытия сокета и удаления объекта 1234 в рабочем потоке может произойти вызов GetQueuedCompletionStatus а может и не произойти - я закономерность не понимаю Она по разному себя ведет.

Вот обратил внимание на эту фишку - как это понять - может произойти, а может и нет?
Есть код, где прописан вызов GetQueuedCompletionStatus - и в этом месте он должен произойти...как иначе то???
Или есть условие - в одном случае - вызываем, в другом - нет. но ведь и это детерминировано...
Или поток сконструирован так - что гуляет по коду как хочет?
Чето я архитектуру приложения недопонимаю...
PS
А можно кусочек кода с этими объектами
class ovpConnection: public OVERLAPPED
- где хранятся, как место хранения описано, как доступ к этому месту и откуда он возможен и прочее...чуть чуть...
А вообще у меня большое недоверие - можно ли эту уникальную структуру объявлять в виде класса, да еще и паблик. Пару полей в ней уникальны и используются только ядром...потому и проблемы бывают, как я выше писал.

Ты можешь для отладки сделать счетчики, как Pacific советует?

Если пришло по ней событие - значит закончена, счетчик уменьшился на 1.

А я не знаю.
на стороне сервера закрытие клиентского сокета может привести к срабатыванию вызова GetQueuedCompletionStatus в рабочем потоке а может нет

Каждая завершившаяся тем или иным образом операция ввода/вывода, назначенная на данный порт завершения, сообщает о своем возврате с помощью специального системного пакета, который поступает в очередь завершенных запросов порта. Для обработки этой очереди и предназначены наши рабочие потоки. Достигается это с использованием функции GetQueuedCompletionStatus(), которая пытается извлечь из очереди пакет завершения соответствующей операции

если вызов произошел то GetQueuedCompletionStatus может вернуть FALSE и как валидный ( еще не удаленный ) указатель на OVERLAPPED так и вернуть удаленный пару секунд назад объект OVERLAPPED
А может вернуть TRUE но кол-во байт 0 прочитанных в lpNumberOfBytes и аналогично или валидный указатель на OVERLAPPED или указатель на только что удаленный объект.
вот такая херь у меня. и как разгребать я хз.

При корректном завершении работы порта завершения главное - не освобождать память со структурой OVERLAPPED, пока выполняется какая-нибудь операция на сокете. Так же надо знать, что закрытие сокета с помощью closesocket() прерывает любые продолжающиеся операции на данном порту завершения.

Пусть в нашу систему прибыло 100 байтов, в результате возникло событие FD_READ. За этими данными пришел сегмент с уведомлением о закрытии соединения на той стороне. В стек сетевых событий этого сокета добавился FD_CLOSE. Мы считываем 30 байтов – остается непрочитанными 70 байтов, потому снова возникает событие FD_READ. В стеке теперь расположены FD_CLOSE, за которым следует FD_READ. Если мы теперь обработаем FD_CLOSE и закроем сокет, мы потеряем оставшиеся в буфере приема данные. О чем это говорит? Полагаться на сетевое событие здесь не совсем логично – надо полагаться только на возврат функцией recv() значения 0.

Вот этого я никак не могу понять.
Что вы понимаете под НЕсрабатыванием вызова GetQueuedCompletionStatus?

Мне на ум пришел только один вариант - когда клиент отваливается так, что даже RST пакет не доходит до сервера, и сервер думает, что клиент все еще подключен. Но таких клиентов сервер сам должен отбрасывать по таймауту - либо getsockopt(socket, SOL_SOCKET, SO_CONNECT_TIME, ...), если соединение в стиле либо "вкл-запрос-ответ-выкл", либо вручную отслеживать, когда пришел последний пакет.

объекты уходят на удаление в двух случаях:
- GetQueuedCompletionStatus вернул FALSE или *lpNumberOfBytes вернулось ноль
- внутренняя серверная логика приняла решение что клиент должен быть дисконнектнут

Что вы понимаете под НЕсрабатыванием вызова GetQueuedCompletionStatus?

Я закрываю в потоке 17 сокет и удаляю OVERLAPPED структуру а она херакс и через некоторое время высплывает в обработчике в GetQueuedCompletionStatus

Нельзя просто взять и удалить OVERLAPPED структуру, пока она используется системой. Надо ждать возврата ее из GetQueuedCompletionStatus, потом только удалять.

GetQueuedCompletionStatus выдаст в поле *lpOverlapped только что удаленный объект. "только что" понятие тут растяжимое может вызваться через миллисекунду а может через 3 секунды ( у меня рекорд 5 секунд был )

Так мы про что талдычим уже 3 страницы? Нельзя просто взять и удалить OVERLAPPED структуру, пока она используется системой. Надо ждать возврата ее из GetQueuedCompletionStatus, потом только удалять.

Именно поэтому надо дожидаться реального возврата GetQueuedCompletionStatus и только после этого удалять все что ассоциировано программой с закрытым сокетом.

да. но как мне гарантированно знать что закрывать сокет можно и объект можно убивать?
чтобы не произошел при этом вызов GetQueuedCompletionStatus

Добавь CRITICAL_SECTION

Обычно рекомендуется, чтобы функция CreateIoCompletionPort() задавала один поток для каждого отдельного процессора во избежание переключения контекста потока.

После завершения асинхронной операции ввода/вывода для ассоциированного файла диспетчер ввода/вывода создает пакет запроса из структуры OVERLAPPED и ключа завершения и помещает его в очередь с помощью вызова KeInsertQueue(). Когда поток вызывает функцию GetQueuedCompletionStatus(), на самом деле вызывается функция NtRemoveIoCompletion(). NtRemoveIoCompletion() проверяет параметры и вызывает функцию KeRemoveQueue(), которая блокирует поток, если в очереди отсутствуют запросы, или поле CurrentCount структуры KQUEUE больше или равно MaximumCount. Если запросы есть, и число активных потоков меньше максимального, KeRemoveQueue() удаляет вызвавший ее поток из очереди ожидающих потоков и увеличивает число активных потоков на 1. При занесении потока в очередь ожидающих потоков поле Queue структуры KTHREAD устанавливается равным адресу порта завершения. Когда запрос помещается в порт завершения функцией PostQueuedCompletionStatus(), на самом деле вызывается функция NtSetIoCompletion(), которая после проверки параметров и преобразования хендла порта в указатель вызывает KeInsertQueue().

Ну и конечно же не соответствие вашей архитектуры рекомендациям:

но shutdown()вроде помог.

Я в другой литературе встречал рекомендацию 2 рабочих потока на ядро.

2. уничтожаем всё, кроме OVERLAPPED-структуры, которую
засылаем в отстойный список.

Ссылочку не дадите?

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

Или поднять еще один сервер и балансировать нагрузку.

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

у меня их уже 5 штук. по 7 тысяч онлайн на каждом.

Вероятно, речь идёт о:
"Программирование серверных приложений для Windows 2000".

progman, а почему ты сделал все на голом API? Чем варинат с boost.asion не устроил?

Объект подлежащий удалению сливается в список на удаление который обрабатывается в потоке 17
Так вот, если в потоке 17 вызвать closesocket то в одном из потоков 1-16 GetQueuedCompletionStatus срабатывает и возвращает значение TRUE или FALSE а также lpNumberOfBytes вернет ноль но самое страшное что в поле lpOverlapped будет указание на структуру сокета, который был закрыт и объект удален и самое нехорошее что это происходит не всегда. Иногда вызывается обработчик в GetQueuedCompletionStatus а иногда нет.

The IOCP documentation says that application needs to call CloseHandle() to unregister the socket from the IOCP, and PJLIB does this in ioqueue_winnt.c.
We assumed that a call to CloseHandle() should close the socket (just like closesocket()), since a socket should just be another handle in Windows NT.
But turns out this is not the case. A call to CloseHandle() doesn't seem to close the socket, as the socket still appears in "netstat" output. Also further down it will cause "Invalid handle" exception to be raised in debug mode when WSACleanup() is called.
Checking at MSDN documentation about CloseHandle() (see ​http://msdn.microsoft.com/en-us/library/ms...11(VS.85).aspx), actually it does suggest application to call both for socket, i.e. always follow closesocket() call with CloseHandle(). This is what it says:
After closing a socket using the closesocket function, ensure that you release the socket by calling CloseHandle. For more information, see ​Socket Closure.

...
4. Нашел в сети такую последовательность закрытия сокета:
shutdown(sock->socket,SD_BOTH);
closesocket(sock->socket);
sock->socket = INVALID_SOCKET;
Может именнно ее надо применять?

если в потоке 17 вызвать closesocket то в одном из потоков 1-16 GetQueuedCompletionStatus срабатывает

Ну блин и где разгадка этого пазла???

progman ничего не сообщил о том, в результате каких условий поток №17 принимает решение о закрытии клиентского сокета. Предположим, что это решение принимается по таймауту, когда клиентский сокет вообще заснул (или отвалился вообще).
Что это означает в отношении IOCP?

boost.asion

с переходом на boost.asion проблема рассосалась.

В этом случае оба клиента активны и "гонят" трафик.
По логике системы оба должны быть дисконнектнуты.

Скорее всего это баг архитектуры приложения, не учитывающий взаимоотношения пакетов завершения рабочих потоков с проблемами закрытия (принудительного по сути) сокетов с активным трафиком. Ясен день, что в HTTP такой ситуации не может возникнуть по определению. Все решает пользовательский протокол.

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

собственно ее и сейчас нет.
в потоке 17 просто закрываю порт. Буст видимо внутри сам все разруливает как то ...

Посредством размещения запроса на уничтожение сокета в очереди запросов порта завершения.

в потоке 17 просто закрываю порт.

значит всё придётся мастерить как-то иначе

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

В данный момент этот 1234 может из порта что то читать или что то писать или вообще заниматься обработкой своих внутренних данных

При этом после закрытия сокета и удаления объекта 1234 в рабочем потоке может произойти вызов GetQueuedCompletionStatus а может и не произойти - я закономерность не понимаю. Она по разному себя ведет.

GetQueuedCompletionStatus выдаст в поле *lpOverlapped только что удаленный объект. "только что" понятие тут растяжимое может вызваться через миллисекунду а может через 3 секунды ( у меня рекорд 5 секунд был ).

В потоке который обрабатывает очередь объектов на удаление я у каждого объекта уточняю статус с помощью макроса HasOverlappedIoCompleted и удаляю только те у кого нет в обработке операций

А он (Буст) точно использует порт завершения ?
Насколько я понимаю, это кросс-платформенная библиотека.

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

Это каким таким образом вы закрываете порт? Чей порт?
Порт приложения?

Хотя мне в общем то проблема понятна - убивать живого клиента можно лишь убедившись что это возможно.

168 часов без сбоев сейчас сервак висит.

Во блин...невезуха.

сейчас сервак висит.

Завис, повис - т.е. не пашет

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

и вот после шотдауна 5 минут раз в день не хватало.....

Ничего себе...это сколько же надо пакетов иметь в очереди порта, чтобы 16 рабочих потоков не могли разрулить пару пакетов за 5 минут
Не могу себе представить...где-то еще какая-то клизма...

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

Это разработчикам Буста придётся решать вопрос иначе, те фактически
на сокетах беркли. А раз такое возможно, зачем нужен порт завершения ?

Делаем приблизительно так:

В среднем 7-8 тысяч входящих в минуту.

В среднем 7-8 тысяч входящих в минуту.

Велосипед с квадратными колесами.

Ясно что система работает практически на грани возможностей IOCP.

Ясно что система работает практически на грани возможностей IOCP.

Давайте считать: 10 мс время обработки одного пакета - значит один поток обработает за секунду 100 пакетов или 6000 за минуту.

Когда я тестировал грани возможностей IOCP, у меня 6-ядерный сервер держал 30000 запросов

И выдержал бы больше, если бы это был простой echo-сервер.

Ну и кстати такой вопрос - а что такое "запрос"???

Все это конечно тестировалось в гигабитной локалке, в реальной работе таких нагрузок не было.

Этот расчет слишком на мой взгляд слишком арифметически прямолинеен.
В любой сложной системе крутятся сотни процессов и может быть тысячи потоков. Время переключения контекста потока с одного на другой в разных процессорных системах может колебаться от 20 до 300 циклов - смотрел только что в гуглях. Кроме того, надо учитывать и приоритетность и прочая. Так что процентов на 10-15 я бы ваши цифры уменьшил бы...

Почему я не имею право экстраполировать? ))))