есть стандартный код обработки событий сервером для асинхронных сокетов в очень упрощенной форме

вся схема отрабатывает как надо , но есть такие моменты в ходе программы когда нужно самому рвать соединение - т.е. иницицаторы разрыва мы а не клиент , и соответственно, мы не получаем события FD_CLOSE - на котором завязан весь контроль изменившегося числа клиентов (RemoveClientInformation(Event - WSA_WAIT_EVENT_0);  и апдейт числа евентов и массива евентов в WSAWaitForMultipleEvents(....)). С одной стороны самому при closesocket ничего не мешает сделать RemoveClientInformation... , но как пробудить тогда   ? для того чтобы оно взяло мониторить новое кол-во хэндлов - что в этой ситуации можно сообразить то ?  есть ли возможность самому вручную "инициировать" network event FD_CLOSE для определенного хэндла - чтобы разбудить WSAWaitForMultipleEvents ?


Это сообщение отредактировал(а) 12usver12 - 9.1.2012, 10:20

Microsoft често говорит:



Заводите специальное событие wakeEvent, вставляете его в массив arrEvents (увы, максимальное число клиентов при этом уменьшается на 1), затем проверяете, не оно ли сработало. Установка wakeEvent так же полезна при корректном завершеннии программы.

Самому делать SetEvent на одном из сокетных событий (например, на том, который ловит FD_ACCEPT) я несоветую, возможны очень неприятные ситуации, лучше пожертвовать одним клиентом (их и так 63 штуки остаётся ;))

вначале так и делал через WSASetEvent, угу так и есть FD_ACCEPT потом не приходит 


это мелочи действительно 

я так понимаю что для одной группы из 64 клиентов , этого wakeclient лучше добавлять в самое начало массива хэндлов. 
на этом wakeEvent что лучше делать SetEvent или WSASetEvent или без разницы т.е создавать через WSACreateEvent или CreateEvent ?

Это сообщение отредактировал(а) 12usver12 - 9.1.2012, 13:53

Это без разницы (хотя, может, и есть малюсенькая разница, пока не могу сказать), главное - корректно обработать. Если вставлять в начало, потом единицу из индекса вычитать надо ;)

Кстати, закрывать сокет можно и в другом потоке, а вот высвобождать соответствующее ему событие - только в ожидающем WSAWaitForMultipleEvents потоке. Честно, не помню, почему после closesocket не стоит устанавливать отвечающее ему событие (чтобы пробудить wait-функцию, там тоже какой-то неприятный эффект был). Лучше пользовать добавочное событие с дальнейшим перебором клиентов (жив - не жив))))

То есть:

•  в одном потоке - closesocket( arrSocketInfo[index]->Socket ); arrSocketInfo[index]->Socket = INVALID_SOCKET; SetEvent( wakeEvent );
•  в другом потоке - WSAWait...(...); if( Event == 0 ) for( index... ) if( arrSocketInfo[index]->Socket == INVALID_SOCKET ){ CloseHandle( arrSocketInfo[index]->Event ); RemoveClient( index ); }

Вот это однозначно без разницы. Можно и Wait... вместо WSAWait...)))

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


ну я собсно connect,accept и close обрабатываю в одном потоке , а отправку и принятие данных в других, перед каким-то телодвижением например закрытие сокета пробуждаю wait , а то вроде глюки были когда сначала закрывал сокет.

как показала практика - без разницы
ну и конечно там где уже несколько потоков пошло - не забывать про синхронизацию 

p.s. спс за wakeclient , а то чувствуется делал бы через ж*