Опитвам се да внедря сървър, който използва IOCompletionPort за четене от своите клиенти. Имам нещо много подобно на този пример.
Ако разбирам правилно, това трябва да е моят дизайн:
- [Основна тема] Създайте гнездо за слушане, свържете и слушайте
- [Основна тема] Създайте събитие и го прикачете към сигнала за приемане на сокет с помощта на WSAEventSelect
- [Приемане на нишка] Изчакайте събитието и приемете клиент
- [Приемане на нишка] Когато клиент се свърже, използвайте CreateIOCompletionPort, за да използвате опашката за IOCompletion с него
- [Приемане на нишка] Приемащата нишка извиква първия WSARecv с параметри на припокриване
- [Работни нишки] Използвайте опашката, за да внедрите модел лидер-последовател на WSARecv
След известно четене на WSARecv (Тук )Открих, че WSARecv може да се върне веднага с данните, ако данните са готови. Това изглежда доста странно, защото това означава, че работник може да се завърти на WSARecv, без да се връща към IO опашката, ако клиентът изпрати достатъчно бързо - И това може да причини глад на клиента...
Тук въпросите ми са:
- Има ли начин да "принудите" WSARecv да не се връща веднага? Искам да кажа, да върна IO_PENDING 100% от времето?
- Ако не - Какъв би бил правилният дизайн, оптимизиран за мащабируемост?
Ето как използвам WSARecv:
flags = 0;
receiveResult = WSARecv(clientSocket, &(olStruct->Buffer), 1, &bytesReceived, &flags, (OVERLAPPED*)olStruct, NULL);
olStruct е разширение за структурата OVERLAPPED.
РЕДАКТИРАНЕ: В крайна сметка публикувах повторно това, което получих от WSARecv, използвайки PostQueuedCompletionStatus. Все пак бих искал да чуя други решения Вижте отговора