| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Асинхронные сокеты [D7, 2003]
prodex © (2008-04-15 22:19:00)При перекрытом вводе/выводе используя события как будет себя вести WSARecv если приемный буфер меньше, чем принимаемые данные? Еще раз взведется событие FD_READ?
Сергей М. (2008-04-17 08:27:00) [1]
> Palladin © (16.04.08 20:51) [15]
> пусть тот убивает кто породил
А вот ребята из Борланда думали иначе, когда сочиняли метод TCustomWinSocket.SendStream.
И в принципе в реализованной ими там логике нет ничего несуразного.
Одна только беда - мало кто читает справку к методу, где эта логика пусть и кратко, но вполне доходчиво изложена.
Slym (2008-04-17 05:37:00) [2]Мне интересно, Ктонибудь осилит написать сервер на IOCP? Обернутую в компоненту :)... или это фантастика?
IOCP лучше чем этот CompletionRoutine, в силу частичной поточной распараллелизации...
Сергей М, (2008-04-16 21:48:00) [3]Ничего не будет.
Прикладные буферы, указанные при вызове ф-ции, будут заполнены "на полную катушку", внутренняя очередь уменьшится на размер cbTransferred.
Никаких новых FD_READ не возникнет.
prodex (2008-04-16 21:19:00) [4]Так все таки, что будет с данными, с буфером или с ошибками при вызове WSARecv и нехватке места в буфере для данных из гнезда?
Сергей М, (2008-04-16 21:08:00) [5]Не вижу вообще никакой проблемы.
Суть WSAEWOULDBLOCK та же, что и WSA_IO_PENDING - запрошенная операция не может быть выполнена немедленно.
prodex (2008-04-16 21:02:00) [6]Меня не устраивает WSAEWOULDBLOCK, а именно то, что если буфер не передан, потом его куда хочешь, туда и девай. При оконной модели вроде все здорово, не считая этой заковыки (WSAEWOULDBLOCK). При перекрытом вводе-выводе это проблема отпадает.
prodex (2008-04-16 20:55:00) [7]Palladin, так и есть. Я уже наступал на эти грабли, давно. Я же описал абстрактную модель, ну, в общем смысле.
Сергей М. (2008-04-16 20:53:00) [8]
> Оконные сообщения неудобны тем, что растет очередь сообщений,
> если замешкаешь
Разве кто-то настаивает именно на оконной нотификации ?
Palladin (2008-04-16 20:51:00) [9]
>при ококнчании передачи класс "TBuffer" сам "знает", когда он становится ненужен и уничтожает сам себя из очереди на передачу некоего класса TClient...,
ай ай ай. какая нехорошая схема. по рукам бить. TBuffer не должен сам себя уничтожать. он должен уведомлять об этом своего владельца. TClient в данном случае. бо пусть тот убивает кто породил. иначе набор несуразиц в динамической модели приложения я тебе гарантирую.
prodex (2008-04-16 20:47:00) [10]Оконные сообщения неудобны тем, что растет очередь сообщений, если замешкаешь
prodex (2008-04-16 20:42:00) [11]Прцедуры завершения - удобно. Коротко - есть некий класс "TBuffer", который содержит сам буфер и процедуру завершения. Отправка: при ококнчании передачи класс "TBuffer" сам "знает", когда он становится ненужен и уничтожает сам себя из очереди на передачу некоего класса TClient..., и если размер данных большой, то он моментально не отправится, а перекрытый ввод-вывод, позволяет передавать несколько блоков "одновременно" в фоновом режиме. С приемом примерно так же, только при окончании приема генерируется некое событие, которое видит TClient..., и при чтении буфера класса "TBuffer", "TBuffer" сам уничтожается. в общих чертах примерно так.
Сергей М, (2008-04-16 20:27:00) [12]Обоснуй выбор тобой именно WSARecv, а не просто Recv ..
Что толкнуло на использование механизма процедур завершения ?
Чем не угождают традиционные механизмы - ивенты или оконные сообщения ?
Чем, собссно, не угождает обычный неблокирующий режим без нотификаций ?
Это нужно четко понимать ..
prodex (2008-04-16 20:17:00) [13]Так вот, сколько бы не было буферов, общий их размер конечен, данные из гнезда будут заполнять их по очереди, и резервировать память для них надо, т.е. я резервирую, допустим 1 мб, а данные, например всреднем будут посылаться по 100-1000 байт, а клиентов, к примеру 400, а потом в один прекрасный момент придет 15 мб, как тогда?
prodex (2008-04-16 20:03:00) [14]Понимаешь, Сергей, Размер пересылаемых данных заранее неизвестен, может и 10 байт, может и 1 мб, может посоветуешь, как быть? И обязательно не блокирующие сокеты. Клиентов от 20 до 400, а может и больше. Начальство не говорит, говорит оттестируем, укажем на недостатки, доработаешь.
Сергей М, (2008-04-16 19:50:00) [15]
> в буфере, указаном в WSARecv
Там, вообще-то, можно указать списокбуферов...
Ты о каком из этого списка ?
prodex (2008-04-16 19:49:00) [16]Хорошо, я еще не сильно в этом разбираюсь, поэтому скорее всего ошибаюсь. Так вот, если принимаю с WSARecv и CompletionRoutine, в буфере, указаном в WSARecv места не хватает, что при этом будет? В CompletionRoutine предастся ошибка или как?
Сергей М, (2008-04-16 19:39:00) [17]CompletionRoutine = процедура завершения
К "перекрытию" чего-то там это отношения не имеет
prodex (2008-04-16 19:36:00) [18]Когда принимаешь данные через WSARecv, и при окончании чтения всего блока данных вызываеттся проседура, указанная в параметре lpCompletionRoutime (или что-то вроде того, нет статьи под руками).
Сергей М. (2008-04-16 08:44:00) [19]
> При перекрытом вводе/выводе
Для начала поясни, что подразумевается под "перекрытый ввод/вывод"..
prodex (2008-04-15 23:09:00) [20]Сергей, уважаю, всегда откликнешься. Буду ждать...
| |
Страницы: 