Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
[C++] ребята, подкиньте исходники, использующие Асинхронные операторы winnsocket 14.03.08 04:03
Автор: saynsk2 Статус: Незарегистрированный пользователь
|
|
ребята, подкиньте исходники, использующие Асинхронные операторы winnsocket
|
|
наверно асинхронные функции всё таки... 14.05.08 13:20
Автор: Tamas Статус: Member
|
> ребята, подкиньте исходники, использующие Асинхронные
> операторы winnsocket
наверно асинхронные функции всё таки....
вот а вобще бред это проше пользоватся CreateThread и синхронными сокетами и всё будет намногоь проще...
|
| |
CreateThread это хорошо 15.05.08 11:59
Автор: amirul <Serge> Статус: The Elderman
|
> > ребята, подкиньте исходники, использующие Асинхронные
> > операторы winnsocket
>
> наверно асинхронные функции всё таки....
> вот а вобще бред это проше пользоватся CreateThread и
> синхронными сокетами и всё будет намногоь проще...
Но лучше после этого делать не синхронные операции, а IOCP.
|
| | |
Not always. If initializing of the CRT is important, _beginthreadex is better 16.05.08 20:20
Автор: void <Grebnev Valery> Статус: Elderman
|
> > > ребята, подкиньте исходники, использующие
> Асинхронные
> > > операторы winnsocket
> >
> > наверно асинхронные функции всё таки....
> > вот а вобще бред это проше пользоватся CreateThread и
> > синхронными сокетами и всё будет намногоь проще...
>
> Но лучше после этого делать не синхронные операции, а IOCP.
Not always. Sometimes, use of only one work thread which simply queues the client request might be better; … for small number of clients, the model “a thread per a client” may work well. So it depends … Even using of internal Windows thread pooling features does not necessarily means using of IOCP – in some simplest cases you just can use QueueUserWorkItem in order to periodically perform asynchronous IO. It depends on particularity of the task …, on what he needs.
|
| | | |
Always, always ;) 19.05.08 11:32
Автор: IgorR <Igor Razin> Статус: Member
|
> Not always.
Always, always ;)
Только IOCP. Всё остальное - от незнания этого механизма. Но начинать надо с потока на клиента, проще для понимания :)
|
| | | | |
Нужно ли использовать IOCP в случае, если если очередь... 20.05.08 01:55
Автор: void <Grebnev Valery> Статус: Elderman
|
> > Not always.
> Always, always ;)
> Только IOCP. Всё остальное - от незнания этого механизма.
> Но начинать надо с потока на клиента, проще для понимания
> :)
Нужно ли использовать IOCP в случае, если если очередь порта (IOCP completion queue) пополняется гораздо медленнее, чем рабочий поток его обрабатывает ( кроме того, предполагается, что нет блокирующих операций, так что поток никогда не будет помещён в IOCP paused thread list)? Т.е мы быстро обрабатывает относительно редкие запросы. IOCP очередь waiting threads - LIFO, так что в упомянутом выше случае IOCP будет "поднимать"тот_же_самый поток. Легко проверить - получается одно и тоже id = GetCurrentThreadId():
BOOL fOk = GetQueuedCompletionStatus(...);
DWORD id = GetCurrentThreadId();
|
| | | | | |
А почему не нужно? Какая разница сколько запросов и какой... 20.05.08 09:48
Автор: IgorR <Igor Razin> Статус: Member
|
> Нужно ли использовать IOCP в случае...
А почему не нужно? Какая разница сколько запросов и какой поток обрабатывать будет? Оно работает? Работает. Лучше всего остального? Лучше.
К тому же, при неожиданном :) возрастании нагрузки, ничего не придется переделывать.
Полагаю, есть некий психологический барьер, мол зачем огород городить из-за пары клиентов с двумя запросами в секунду. Надо его беспощадно ломать :)
Все написанное справедливо для товарищей, хочущих заниматься серверостроением. Если надо одноразово написать простенький сервачок на пару клиентов - thread per client - наш выбор.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
