Нужна помощь с разделением отправления / получения сообщений сокета на потоки

По совету от kolobok0 попробовал разделить прием и передачу данных от сокета на различные потоки, чтобы достичь асинхронности.
Но столкнулся с проблемами, которые не совсем понимаю как решить.

Скажем я создал три объекта SOCK, RD, WR.
SOCK создает сокет, инициализирует его и запускает поток, который отслеживает сообщения.
в нем я создаю событие m_ConnectionEvent, отвечающее за FD_READ, FD_WRITE, FD_CLOSE. Кроме того я создаю событие m_ExitEvent для остановки потока.

затем с помощью WSAWaitForMultipleEvents я слежу за этими двумя событиями.

Объект RD должен отслеживать события FD_READ, но на прямую он не может этого делать, так как FD_READ привязан к сокету в SOCK. Т.е. я должен, например через SetEvent(hReadEvailable) просигналить потоку в RD, что надо прочитать буфер. Так ли это или есть другой способ ?

Что касается WR (write), то тут я совсем не понимаю - в каком именно случае срабатывает событие FD_WRITE ?
В данный момент я через вызов функции класса WR::Send копирую данные в буфер этого объекта и с помощью SetEvent(hWriteBuffEvailable) сообщаю потоку класса WR, что можно отсылать информацию.
Но каким именно образом это связано с FD_WRITE так как после вызова send FD_WRITE не вызывается (в прочем как и до этого) ?

Может мне кто-либо помочь осмыслить эту проблему ?
(кстати kolobok0, ты обещал подбросить хорошую литерату на эту тему!)

0

По поводу литературы - я помню. Как только буду рядом с книгами - запишу. Щаз в процессе перезда. Уж сорьки.

По коду..
Честно говоря немного не вьехал...
---------
Постараюсь обрисовать суть...(это из одной реализации, нечто типа своего аля TCP на уровне UDP. Сокеты кажеться разные были - не буду врать щаз не помню)
Поток приёма. Задача - слушать сокет. Как можно быстрее выбирать данные из сокета, минимум обработки, передача дальнейшей логике обработки пакетов(потока), анализ на шутдаун, захват памяти (может и не быть), снова на сокет.

Поток передатчика (если такой имееться). Ожидаем данные из очереди. Подготовка транспортной инфы. Отослать. Освободить память (может и не быть). Ожидать далее из очереди. (вообщето в данной реализации в этой же нитке была вся логика гарантированного уровня доставки - аля TCP)
---------
Возможны и другие реализации. Например (это другой случай. TCP уровень). Один и тот же вспомогательный поток отрабатывает как сенд так и ресив. Обычно применяеться при соединении точка-точка. Малти ожидание необходимо делать на хэндлере сокета и на синхро обьекте очереди передачи. Тогда из основного потока Вы добавляете в очередь передатчика, сигнализируете ему и бежите дальше (если работаете асинхронно).
---------

вроде так.
у Вас насколько я понял уровень TCP ?

(круглый)

0

У меня действительно уровень TCP, при чем данная модель описывает поведение клиента подключенного к серверу.
Зачем тогда разделять на потоки ? Просто передача данных идет от одного потока определенного объекта в сторону сервиса, данные передаются переодически и главное момент передачи данных не должен задерживать отвравляющий поток.
А прием данных предназначен для другого потока, которому после приема я делаю Notify (вызываю callback функцию, которая поднимает флаг события в том объекте).
То есть фактически на данный момент у меня есть три потока (для сокета) которые обслуживают еще два потока. Может быть выглядит и громоздко, но я пока не понимаю, как можно упростить с одной стороны и добиться асинхронности с другой.

А на счет FD_WRITE я так и не понял, как же он работает?

0