Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Мысли по поводу 15.12.03 12:10 Число просмотров: 1498
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
> 1.1 Потоки клиентов.
> Зная свою слабость к большому числу ошибок в коде, решил не
> оставлять потоки клиентов «безнадзорными». Кое-что здесь
> уже сделано. Кое-что не стал делать (для «спортивного
> интереса» было б слишком). Есть пул потоков, который можно
> контролировать из специального потока-свиппера «менеджера
> клиентских потоков».
Хм, насколько я знаю, для надежной работы пула потоков (в том числе в системах реального времени) нонче модно использовать так называемый watchdog, который регулярно извещается самим потоками о том, что эти потоки живы. И я, чесговоря, не вижу, почему это может быть плохо. Порядок действий в этом случае такой: рабочий поток произвольным образом (например, через UDP) извещает следящий процесс о том, что этот рабочий поток жив. Если следящий процесс в течение определенного времени не получает сигнала от рабочего потока, он прибивает рабочий поток (скажем, через kill(SIGKILL)), и перезапускает новый поток - преемника убитого. Такой способ быстрее, чем предложенный, и не требует взаимной синхронизации за исключением механизма посылания сообщения.
> Здесь было сказано о буфере ввода/вывода клиентского
> потока, см. stream_buf в структуре CLIENTINFO выше. Вообще,
> на мой взгляд, это вопрос – как выделять память потоку для
> буфера ввода/вывода? В той реализации, которая сделана из
> «спортивного интереса» – сделано дубово. Память выделяется
> в одной, общей куче процесса. Какие идеи в части памяти,
> господа?
Ну а какие тут могут быть идеи... Не использовать же thread local storage. А раз не использовать, то из многочисленных соображений (фрагментация памяти, производительность выдачи и освобождения памяти и проч.) лучше написать свой менеджер памяти, который и будет заниматься организацией всего этого безобразия. Алгоритм работы менеджера целиком и полностью зависит от конкретного приложения и даже от конкретных условий работы этого приложения.
> тем, как выделяется? Проще и быстрее всего, с точки зрения
> доступа – realloc (поэтому-то и realloc).
Не могу сказать, что realloc - это самое быстрое, что можно использовать в нашем случае. См. выше.
> 1.3 Клиент.
> В работе клиента есть одна особенность – возможно большие
> таймауты, когда пользователь пошёл покурить...
> ...
> Таким образом, мне кажется, что в любом мало-мальски
> нормальном прикладном протоколе, рассчитанном на длительные
> соединения (имеется ввиду только TCP, а не соединения с
> DBMS) обрабатывать длительные таймауты следует
> самостоятельно. Не проблема это включить в обсуждаемый
> протокол. Не очень ясно другое, как это сделать в
> реализации сервера и клиента. Например, на клиенте
> придётся или делать это в отдельном потоке (все данные и
> получаем и отсылаем в отдельном потоке) – изврат, или
> использовать асинхронные сокеты Windows в сочетании с
> таймерами (для организации обычных таймаутов чтения/записи
> в сокет).
> Какие идеи, господа?
В отдельном-то потоке зачем? Ставим select, а для keep-alive-сигналов либо создаем специальный формат сообщения, который будет отлавливаться еще до передачи в рабочие потоки, либо открываем дополнительное соединение, по которому только кипалайвы и шлются.
> 2.1 Сетевой порядок байт.
> ООО!!! Неоднократно встречал на форумах, в том числе и в
> faq-ах от гуру, что, дескать, не забывайте, ламеры, про
> сетевой порядок байт. Зачем?!!! Наивные. Да у них (у гуру)
> крыша поехала. Это ж прикладной протокол. Какая здесь
> разница. Всё равно клиентов под разные платформы придётся
> компилировать отдельно. Там (на платформах отличных от
> Intel) и учесть можно – делать htons, или нет. Другие
> мнения есть?
Есть. Зачем выбирать, делать или не делать htons, если можно всегда его делать?
> 2.2 Выравнивание заголовка по границе слова.
> ...
> Заголовок вычитывается из сокета «первым». Здесь не так
> важно сколько читать – 11 байт, или 12. Другое дело,
> насколько эффективным будет следующий шаг – вычитывание
> «невыровненных» данных (что за заголовком) из буфера
> сокета.
> Какие будут мнения, товарищи?
По-моему, это не имеет большого значения. А поле reserved лучше иметь всегда.
> 2.3 Выравнивание полей в заголовке.
> Похоже на предыдущий пункт. И здесь логики больше. Хотя,
> тоже с учётом возможностей современных компиллеров,
> сомнительно. Речь идёт о том, что слово выравниваем по
> границе слова, а двойное слово – по границе двойного слова.
> Придерживаюсь пока правил. А по правде – насколько это
> актуально сейчас (чай не 80-е годы на дворе)?
Актуально, но не в нашем случае. Это интересно для выжимания производительности на локальной машине, а когда появляется сеть и/или доступ к БД... Характерные времена уже не те, чтобы это было заметно. ИМХО.
> 2.4 Контрольная сумма.
> ...
> Вставляется эта проверка движением руки. Потери
> производительности – никакой. А сомнения здесь такого рода
> – хорошо «вылизанный» код не требует проверки checksum.
Требует. "Нам не дано предугадать", в каком месте наш софт слетит. И не стоит уповать на вылизанность кода, тем более что потери производительности действительно никакой.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
