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. 

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

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

TiKKi, логичнее не придумаешь.