Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Сэмулируй многозадачность! :-)) 06.11.05 12:08 Число просмотров: 1847
Автор: 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, сколько тебе надо. Чисто китайский подход всех удивить :-)))
|
|
|
подробно о проекте
Анализ криптографических сетевых...
