Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > C/C++: Сети > Не блокирующие сокеты и потоки


Автор: TiKKi 13.5.2006, 14:58
1. К серваку коннектится клиент, его принимаем функций accept(...).

2. Затем, WSAAsynSelect(..., WM_CLIENTEVENT,  FD_READ | FD_CLOSE), этой функцией определяем за какими
событиями на сокете клиента будет наблюдать.

3. Затем, чтобы обработать сообщение WM_CLIENTEVENT получаем что-то вроде такого
    
         ...
         SOCKET  СSock = Message.WParam;
         WORD    WSAEvent = WSAGETSELECTEVENT(Message.LParam);
         switch (WSAEvent)
         {
             ...
                  case FD_READ:
                  {
                           //читаем данные из CSock
                           return;
                  }    
                  ...
         }
         ...

Вопрос в следующем, правильно же будет,если процесс обработки события FD_READ кинуть в поток ? Ведь, если чтение данных от одного клиента затянется, а в это время пришли данные от другого клиента, который ждет ответа.
И тогда, если надо использовать потоки, что делать если опять же чтение данных затянулось и клиент закрыл соединение со своей стороны ? Получается, что FD_READ еще обрабатывается, а уже прилетело FD_CLOSE. 

Автор: blur 13.5.2006, 22:05
Цитата(TiKKi @  13.5.2006,  14:58 Найти цитируемый пост)
И тогда, если надо использовать потоки, что делать если опять же чтение данных затянулось и клиент закрыл соединение со своей стороны ? Получается, что FD_READ еще обрабатывается, а уже прилетело FD_CLOSE.

А как это клиент сможет закрыть соединение, если он не передал еще все данные(буфер)?
 

Автор: TiKKi 14.5.2006, 02:13
Если работа с сокетом у клиента вынесена в поток и он просто закрывает прогу. Это как вариант, но точно незнаю прилетит ли в этот случае FD_CLOSE. Мне больше интересно, логично ли будет обработку на серваке события FD_READ выносить в поток, вот  smile  

Автор: MoZy 5.6.2006, 18:30
TiKKi, логичнее не придумаешь. smile  

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)