информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Атака на InternetВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Блокировка российских аккаунтов... 
 Отзыв сертификатов ЦБ РФ, ПСБ,... 
 Памятка мирным людям во время информационной... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Сэмулируй многозадачность! :-)) 06.11.05 12:08  Число просмотров: 1690
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 06.11.05 12:56  Количество правок: 2
<"чистая" ссылка> <обсуждение закрыто>
> Транспорт - TCP. Мне сказали, что архитектура, когда сервер
> делается в первичном потоке на блокирующем прослушивающем
> сокете (Беркли интерфейс), и когда каждый клиент
> обслуживается в отдельном потоке - сакс. Было сказано, что
> такой софт никто не будет покупать... Было заявлено, что
> всё на самом деле можно сделать в одном потоке.
Сделать-то можно... Но зачем? -))
Ну да ладно. IMHO самое разумное, что можно предложить, дык это слушать всё-таки во столько потоков, сколько есть реальных исполнительных устройств для потоков, т.е. если сервер -- 2-х процовый Xeon with HT, юзать четыре потока, ну и так далее...

Вновь подключающемуся клиенту создавать контекст (сеанс), давать ему идентификатор сеанса, и вперёд — старыми добрыми средствами.

> Было сказано также, что Winsock Microsoft вообще тянет как
> устарелую технологию только ради поддержки старых
> приложений. Типа сейчас так уже не пишут. :cry:
Интересно, а как СЕЙЧАС пишут? Напрямую работают со стеком (TDI), что ли? -))

> Вот я и думаю... Как я отстал от жизни. Как же сделать так,
> чтобы всё работало без отдельных потоков для клиентов.
Ну... Тут бы я вообще не стал ни с кем спорить. Сделай два варианта сервера — один многопоточный, другой не очень -) Потести на производительность. Кто победит — тот и Д'Артаньян.

Мне самому больше нравится многозадачная модель. Если обслуживание клиента на блокирующем сокете затянется, то остальные со своими запросами будут становится в очередь сетевого стека, когда она заполнится, могут получить отлуп. Таймауты или ещё какая-нить хрень, завязанная на реализацию TCP/IP именно под виндами. При многопоточной модели реализация более "резиновая", но и более ресурcоёмкая. IMHO.

P.S.: Кстати, M$ SQL Server, яркий пример многопоточной службы, имеет два режима работы: на обычных потоках, и на т.н. "fibers", менее ресурсоёмких, чем "threads". Прикол в том, что приложение само заботится о переключении из нити в нить, виндовозный шедулер отдыхает. Можешь написать сервис с одним потоком - шедулером, но с такми кол-вом fibers, сколько тебе надо. Чисто китайский подход всех удивить :-)))
<programming> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach