информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Сетевые кракеры и правда о деле ЛевинаГде водятся OGRыВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Tailscale окончательно забанила... 
 Прекращение работы антивируса Касперского... 
 Microsoft Authenticator теряет... 
главная обзор 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 19:49  Число просмотров: 1858
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
Спасибо за ответ.
> Мне самому больше нравится многозадачная модель. Если
> обслуживание клиента на блокирующем сокете затянется, то
> остальные со своими запросами будут становится в очередь
> сетевого стека, когда она заполнится, могут получить отлуп.
> Таймауты или ещё какая-нить хрень, завязанная на реализацию
> TCP/IP именно под виндами. При многопоточной модели
> реализация более "резиновая", но и более ресурcоёмкая.
> IMHO.
В том, что сделано - в каждом клиентском треде сервера данные вычитываются на блокирующих сокетах. Вернее "вычитывание" написано стандартно на select, так что если не вычитаны все данные команды клиента, то выходим по таймауту. Если же данных в сокете клиента нет (опятьтаки проверяется select-ом в клиентском треде), то посылаем клиенту кипэлайв пакет, на который онmustответить с минимальной задежкой (я условно вводил некий тайм вэйт по смыслу близкий к rtt). Если ответа нет - клиент умер каким-то образом, подвис и т.д (даже не знаю что), не закрыв сокет. Теперь всёже думаю попробовать что-нибудь совсем другое на неблокирующих сокетах, как парни говорят, ибо чувствую огромный пробел в знаниях ... Ну и потом, я сам видел, что при числе потоков (клиентов) ~ 1000 - всё тихо замирает.

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

Это точно. В настройках MS SQL 2000 есть соответствующая галочка, использовать файбер, или нет.
Обязательно попробую простенькие модели на тредах переделать в тестовых примерах на файберы. Подозреваю, что будет гораздо эффективнее, чем треды.

Спасибо.
<programming> Поиск 






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


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