Асинхронные сокеты

← →
prodex (2008-04-15 22:19) [0]

При перекрытом вводе/выводе используя события как будет себя вести WSARecv если приемный буфер меньше, чем принимаемые данные? Еще раз взведется событие FD_READ?

← →
prodex (2008-04-15 22:24) [1]

А при использовании процедуры завершения?

← →
prodex (2008-04-15 22:45) [2]

Неужели никто не поможет?!

← →
Palladin © (2008-04-15 23:07) [3]

Сергей М., может и поможет, но видимо тока завтра. советую набраться терпения.

← →
prodex (2008-04-15 23:09) [4]

Сергей, уважаю, всегда откликнешься. Буду ждать...

← →
Сергей М. © (2008-04-16 08:44) [5]

> При перекрытом вводе/выводе

Для начала поясни, что подразумевается под "перекрытый ввод/вывод"..

← →
prodex (2008-04-16 19:36) [6]

Когда принимаешь данные через WSARecv, и при окончании чтения всего блока данных вызываеттся проседура, указанная в параметре lpCompletionRoutime (или что-то вроде того, нет статьи под руками).

← →
Сергей М, (2008-04-16 19:39) [7]

CompletionRoutine = процедура завершения

К "перекрытию" чего-то там это отношения не имеет

← →
prodex (2008-04-16 19:49) [8]

Хорошо, я еще не сильно в этом разбираюсь, поэтому скорее всего ошибаюсь. Так вот, если принимаю с WSARecv и CompletionRoutine, в буфере, указаном в WSARecv места не хватает, что при этом будет? В CompletionRoutine предастся ошибка или как?

← →
Сергей М, (2008-04-16 19:50) [9]

> в буфере, указаном в WSARecv

Там, вообще-то, можно указать список буферов...

Ты о каком из этого списка ?

← →
prodex (2008-04-16 20:03) [10]

Понимаешь, Сергей, Размер пересылаемых данных заранее неизвестен, может и 10 байт, может и 1 мб, может посоветуешь, как быть? И обязательно не блокирующие сокеты. Клиентов от 20 до 400, а может и больше. Начальство не говорит, говорит оттестируем, укажем на недостатки, доработаешь.

← →
prodex (2008-04-16 20:17) [11]

Так вот, сколько бы не было буферов, общий их размер конечен, данные из гнезда будут заполнять их по очереди, и резервировать память для них надо, т.е. я резервирую, допустим 1 мб, а данные, например всреднем будут посылаться по 100-1000 байт, а клиентов, к примеру 400, а потом в один прекрасный момент придет 15 мб, как тогда?

← →
Сергей М, (2008-04-16 20:27) [12]

Обоснуй выбор тобой именно WSARecv, а не просто Recv ..

Что толкнуло на использование механизма процедур завершения ?
Чем не угождают традиционные механизмы - ивенты или оконные сообщения ?
Чем, собссно, не угождает обычный неблокирующий режим без нотификаций ?

Это нужно четко понимать ..

← →
prodex (2008-04-16 20:42) [13]

Прцедуры завершения - удобно. Коротко - есть некий класс "TBuffer", который содержит сам буфер и процедуру завершения. Отправка: при ококнчании передачи класс "TBuffer" сам "знает", когда он становится ненужен и уничтожает сам себя из очереди на передачу некоего класса TClient..., и если размер данных большой, то он моментально не отправится, а перекрытый ввод-вывод, позволяет передавать несколько блоков "одновременно" в фоновом режиме. С приемом примерно так же, только при окончании приема генерируется некое событие, которое видит TClient..., и при чтении буфера класса "TBuffer", "TBuffer" сам уничтожается. в общих чертах примерно так.

← →
prodex (2008-04-16 20:47) [14]

Оконные сообщения неудобны тем, что растет очередь сообщений, если замешкаешь

← →
Palladin © (2008-04-16 20:51) [15]

>при ококнчании передачи класс "TBuffer" сам "знает", когда он становится ненужен и уничтожает сам себя из очереди на передачу некоего класса TClient...,

ай ай ай. какая нехорошая схема. по рукам бить. TBuffer не должен сам себя уничтожать. он должен уведомлять об этом своего владельца. TClient в данном случае. бо пусть тот убивает кто породил. иначе набор несуразиц в динамической модели приложения я тебе гарантирую.

← →
Сергей М. © (2008-04-16 20:53) [16]

> Оконные сообщения неудобны тем, что растет очередь сообщений,
> если замешкаешь

Разве кто-то настаивает именно на оконной нотификации ?

← →
prodex (2008-04-16 20:55) [17]

Palladin, так и есть. Я уже наступал на эти грабли, давно. Я же описал абстрактную модель, ну, в общем смысле.

← →
prodex (2008-04-16 21:02) [18]

Меня не устраивает WSAEWOULDBLOCK, а именно то, что если буфер не передан, потом его куда хочешь, туда и девай. При оконной модели вроде все здорово, не считая этой заковыки (WSAEWOULDBLOCK). При перекрытом вводе-выводе это проблема отпадает.

← →
Сергей М, (2008-04-16 21:08) [19]

Не вижу вообще никакой проблемы.

Суть WSAEWOULDBLOCK та же, что и WSA_IO_PENDING - запрошенная операция не может быть выполнена немедленно.

← →
prodex (2008-04-16 21:19) [20]

Так все таки, что будет с данными, с буфером или с ошибками при вызове WSARecv и нехватке места в буфере для данных из гнезда?

← →
Сергей М, (2008-04-16 21:48) [21]

Ничего не будет.

Прикладные буферы, указанные при вызове ф-ции, будут заполнены "на полную катушку", внутренняя очередь уменьшится на размер cbTransferred.

Никаких новых FD_READ не возникнет.

Мне интересно, Ктонибудь осилит написать сервер на IOCP? Обернутую в компоненту :)... или это фантастика?

IOCP лучше чем этот CompletionRoutine, в силу частичной поточной распараллелизации...

> Palladin © (16.04.08 20:51) [15]

> пусть тот убивает кто породил

А вот ребята из Борланда думали иначе, когда сочиняли метод TCustomWinSocket.SendStream.

И в принципе в реализованной ими там логике нет ничего несуразного.
Одна только беда - мало кто читает справку к методу, где эта логика пусть и кратко, но вполне доходчиво изложена.

Асинхронные сокеты Найти похожие ветки