Проблема заключается в следующем...у меня на сервере на одном потрту висят 10 клиентов..и по 4 события от каждого(Accept Read Write Close)...происходит ситуация когда приходят 3 события чтения у меня теряется событие записи.....существует ли очередь сообщений у WSAWaitForMultipleEvents?....или как с этим лучше бороться...

Здравствуйте, Аноним, Вы писали:

А>Проблема заключается в следующем...у меня на сервере на одном потрту висят 10 клиентов..и по 4 события от каждого(Accept Read Write Close)...происходит ситуация когда приходят 3 события чтения у меня теряется событие записи.....существует ли очередь сообщений у WSAWaitForMultipleEvents?....или как с этим лучше бороться...

Как таковой именно очереди нет. А бороться с Вашей ситуацией можно с помощью третьего параметра ф. WSAWaitForMultipleEvents, установите его в FALSE, будете знать, какое событие вызвало окончание ожидания. Остальные события массива остануться в неизменном состоянии ( если события с автосбросом ).

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

TC>Здравствуйте, Аноним, Вы писали:

А>>Проблема заключается в следующем...у меня на сервере на одном потрту висят 10 клиентов..и по 4 события от каждого(Accept Read Write Close)...происходит ситуация когда приходят 3 события чтения у меня теряется событие записи.....существует ли очередь сообщений у WSAWaitForMultipleEvents?....или как с этим лучше бороться...

TC>Как таковой именно очереди нет. А бороться с Вашей ситуацией можно с помощью третьего параметра ф. WSAWaitForMultipleEvents, установите его в FALSE, будете знать, какое событие вызвало окончание ожидания. Остальные события массива остануться в неизменном состоянии ( если события с автосбросом ).


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

У WSAWaitForMultipleEvents есть ограничение на количество евентов — до 64. Может ето влияет?

Здравствуйте, Аноним, Вы писали:

А>дело в том что параметр уже установлен в FALSE....я ставлю точку прерывания на обработку события Read...вызываю его двумя клиентами т.е посылаю серверу одновременно два события Read....первое ловится второе всегда куда то исчезает....

Допустим у меня два сокета. Я на каждом из них задал ( WSAEventSelect ) ожидание события FD_READ. Теперь у меня есть два дескриптора событий ( Event ) для каждого сокета. Я использую для ожидания WSAWaitForMultipleObject. Допустим, приходят данные — одно ( или оба события взводяться ). WSAWaitForMultipleObject возвращает WAIT_OBJECT_0 или WAIT_OBJECT_1. По этому значению я узнаю, на каком сокете случилось событие. Для него вызываю WSARecv, далее снова вызываю WSAWaitForMultipleObject. Вот такой примерно должен быть алгоритм. Из Ваших слов я понял, что WAIT_OBJECT_1 никогда не возвращается?

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

TC>Здравствуйте, Аноним, Вы писали:

А>>дело в том что параметр уже установлен в FALSE....я ставлю точку прерывания на обработку события Read...вызываю его двумя клиентами т.е посылаю серверу одновременно два события Read....первое ловится второе всегда куда то исчезает....

TC>Допустим у меня два сокета. Я на каждом из них задал ( WSAEventSelect ) ожидание события FD_READ. Теперь у меня есть два дескриптора событий ( Event ) для каждого сокета. Я использую для ожидания WSAWaitForMultipleObject. Допустим, приходят данные — одно ( или оба события взводяться ). WSAWaitForMultipleObject возвращает WAIT_OBJECT_0 или WAIT_OBJECT_1. По этому значению я узнаю, на каком сокете случилось событие. Для него вызываю WSARecv, далее снова вызываю WSAWaitForMultipleObject. Вот такой примерно должен быть алгоритм. Из Ваших слов я понял, что WAIT_OBJECT_1 никогда не возвращается?

Спасибо всем!!!...Все сам решил....у меня приходило два события Read я смотрел на каком сокете у меня происходило событие далее я сбрасывал событие ResetEvent- ом....переходил снова в цикле на WSAWaitForMultipleObject что бы обработать второй прешедший мне Read...но оказалось что функция ResetEvent сбрасывает второе событие....

Здравствуйте, Аноним, Вы писали:

А>...у меня на сервере на одном потрту висят 10 клиентов..и по 4 события от каждого(Accept Read Write Close)...происходит ситуация когда приходят 3 события чтения у меня теряется событие записи.....существует ли очередь сообщений у WSAWaitForMultipleEvents?....или как с этим лучше бороться...

Ну в общем бардак!!!

Для начала внимательно читаем доку по WSAEventSelect! Одному сокету можно назначить только одно событие (системный объект), которое будет установлено (в сигнальное состояние) при наступлении любой из перечисленных ситуаций (FD_ACCEPT|FD_READ|FD_WRITE|FD_CLOSE) в третьем параметре WSAEventSelect. При этом сокет автоматом становится неблокирующим. Попытка назначить два события приведет к тому, что первое "отвяжется". В то же время одно и то же событие можно назначить нескольким разным сокетам, причем с разными масками. Кстати, назначать маску FD_ACCEPT|FD_READ бессмысленно!

Событие сбрасывается (в несигнальное состояние) в зависимости от того, auto-reset оно или manual-reset (смотри CreateEvent/WSACreateEvent). Для сбрасывания manual-reset события можно использовать либо ResetEvent, либо с помощью побочного эффекта WSAEnumNetworkEvents. И вообще, имхо без WSAEnumNetworkEvents вообще нельзя обойтись! С auto-reset событием не связывался вообще — невкусно пахнет

Теперь о баранах.
Hint #1: RTFM, Menu->Edit->Select All, Del, а теперь напиши правильно.
Hint #2: Маска FD_READ (FD_WRITE, кстати, тоже!) срабатывает один раз! И пока вызов recv не завершится ошибкой с кодом WSAEWOULDBLOCK, событие по этой маске установлено не будет! Почему это происходит и как с этим бороться смотрим в этом треде

ЗЫ Я вот обратил внимание — все гении такие скромные и всегда скрывают свои настоящие никнэймы! А зря — страна должна знать своих героев!

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

NR>Hint #1: RTFM, Menu->Edit->Select All, Del, а теперь напиши правильно.

Начинаем с себя, посколько за знание документации низачот, почему, смотрим далее....

NR>Hint #2: Маска FD_READ (FD_WRITE, кстати, тоже!) срабатывает один раз! И пока вызов recv не завершится ошибкой с кодом WSAEWOULDBLOCK, событие по этой маске установлено не будет! Почему это происходит и как с этим бороться смотрим в этом треде

Событие по маске FD_READ устанавливается:
1. Когда приходят данные в пустой буфер
2. Если после вызова recv/WSARecv в буфере остались данные.

Чтоб не было пустого флейма, сошлюсь на MSDN:

For FD_READ, FD_OOB, and FD_ACCEPT network events, network event recording and event object signaling are level-triggered. This means that if the re-enabling routine is called and the relevant network condition is still valid after the call, the network event is recorded and the associated event object is set. This allows an application to be event-driven and not be concerned with the amount of data that arrives at any one time. Consider the following sequence:

1. A transport provider receives 100 bytes of data on socket s and causes ws2.dll to record the FD_READ network event and set the associated event object.
2. The application issues recv(s, buffptr, 50, 0) to read 50 bytes.
3. The transport provider causes ws2.dll to record the FD_READ network event and sets the associated event object again because there is still data to be read.

Здравствуйте, Аноним, Вы писали:

А>далее я сбрасывал событие ResetEvent

Классика мирового синематографа. Пора вносить в FAQ

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

NR>>Hint #1: RTFM, Menu->Edit->Select All, Del, а теперь напиши правильно.

TC>Начинаем с себя, посколько за знание документации низачот, почему, смотрим далее....

Выполнил 3 первых пункта, 4 — в процессе. "Ку" много раз.

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

NR>Выполнил 3 первых пункта, 4 — в процессе. "Ку" много раз.

Не расстраивайся, ты не одинок. Я тоже постоянно путаю, что когда устанавливается и кого куда посылают в какой модели ввода-вывода. Намутили они так что уже 20 лет люди мучаются, а конца мучениям не видать