Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Да ладно. 16.12.03 03:54 Число просмотров: 1183
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
> Признаюсь, я просто не смотрел сабдж. И раз ты говоришь,
> что это хорошо, то я соглашусь, ибо прислушиваюсь к
> "старшим" ;)) (без иронии. я серьёзно)
Да ладно, какой из меня "старший"... Просто так получилось, что те несколько production-систем, которые я видел и на которых вставала подобная задача, использовали именно такую систему контроля пула потоков. Видимо, чем-то она действительно хороша, раз ею пользуются. Ее минус состоит в том, что она интрузивна по отношению к рабочим потокам, но в нашем случае это неважно.
> Не могу согласится (сразу) только с тем, что в описанном
> алгоритме будет долго. Там ж не мьютексов, не хрютексов.
> Критическая секция очень быстрая (по сравнению с
> остальным). В ней пара операций. Дёрнули и отпустили. Хотя
> ... может я и не прав.
В твоей схеме есть еще дополнительные издержки на копирование моментального снимка состояния потоков.
> > лучше написать свой менеджер
> > памяти, который и будет заниматься организацией всего этого
> > безобразия. Алгоритм работы менеджера целиком и полностью
> > зависит от конкретного приложения и даже от конкретных
> > условий работы этого приложения.
>
> Это было б сложно для того контекста ("из спортивного
> интереса"), который здесь. А если честно - мне и
> недоступно. Программист я - сам знаешь какой. Но всё равно
> интересно;)).
Да там в общем-то ничего сложного нет. Простейший менеджер памяти под сообщения может, например, выделять память фиксированными кусками, и возвращать ее ими же. Впрочем, согласен, это тема уже довольно могучая, для спортивного проекта, пожалуй, даже слишком. Ну, тогда можно обойтись и realloc'ами.
> > В отдельном-то потоке зачем? Ставим
> > select, а для keep-alive-сигналов
> > либо создаем специальный формат сообщения, который будет
> > отлавливаться еще до передачи в рабочие потоки, либо
> > открываем дополнительное соединение, по которому только
> > кипалайвы и шлются.
> Дык, и мне не хочется в отдельном потоке;)) Я ж пишу -
> изврат. Да, может и на selecte. Всё равно, там надо думать.
> А про формат keepalive сообщения - дык это уже сделано в
> том протоколе "для затравки";))) Всё пока правда криво, ибо
> делалось в несколько дней "на скоряк".
А, я, честно говоря, не обратил внимания. Ну и хорошо. А над select'ом особо думать не надо, с ним только работать муторно, зато код пишется ровно один раз.
> > > компилировать отдельно. Там (на платформах отличных
> > > от Intel) и учесть можно – делать htons, или нет. Другие
> > > мнения есть?
> > Есть. Зачем выбирать, делать или не делать htons, если
> > можно всегда его делать?
>
> Обоснуй. Это ж не смтп и фтп, т.е. то, что оговорено RFC.
> Какой смысл соблюдать сетевой порядок байт только в
> заголовке прикладного протокола. Тогда и все числовые
> значения, что длиной более одного байта, и которые следуют
> за заголовком прикладного протокола - придётся в сетевом
> порядке представлять.
Да, придется, и это правильно. Ибо это переносимо, не нужно заморачиваться с платформами, отличающимися порядком байтов. Каков будет порядок байт при пересылке, действительно не имеет значения. Но зато можно быть твердо уверенным, что каждая машина может использовать свой порядок байт, и никаких проблем с перестраиванием порядка байт при передаче данных не возникнет.
Другим вариантом является жесткое прошивание во всем тракте порядка байтов, не только в самих клиенте и сервере, но еще и в агентах, с которыми они взаимодействуют. То есть если ты работаешь с базой данных - в ней должен быть фиксированный порядок байтов, не плавающий от платформы к платформе. То же самое и на клиенте - ты должен быть уверен, что не только сам клиент, но и все приложения, которые им пользуются, имеют фиксированный порядок байтов, неизменный от платформы к платформе. Если ты можешь гарантировать подобную определенность (то есть фактически независимость порядка байтов на любом из узлов от платформы), то ты можешь и не пользоваться промежуточным преобразованием в сетевой порядок байт, а передавать байты как тебе удобно. Этот же вариант ты можешь смело использовать, если все поддерживаемые тобой платформы имеют одинаковый порядок байт, и ты не боишься, что этот статус-кво в ближайшем будущем изменится.
Надеюсь, я не слишком запутал ситуацию? :)
> > По-моему, это не имеет большого значения. А поле
> > reserved лучше иметь всегда.
>
> Зачем тогда гуру обманывают начинающих, как я? ;)))
Ну так им же обидно, что их тоже когда-то обманули :) А если серьезно, то чаще выравнивание все-таки полезно. Другой вопрос, что в случае сетевых приложений однозначного ответа нет: в зависимости от характера данных это может быть желательно, не важно или даже вредно (например, когда размер передаваемых данных находится где-то в районе размера пакета).
> Про производительность согласен. Но! Если компиллер не
> вставит дополнительный код (за спиной программера) при
> доступе к невыровненным данным, то на некоторых процеках
> это приводит к ошибкам, как говорят гуру. Сам не встречал.
> Как думаешь?
Хм, ну да, чтобы, скажем, обратиться ко второму байту в слове, нужен дополнительный код %-) Ну так блин, если компилятор его когда надо не вставляет - на свалку такой компилятор, он же неработающий код генерит. Что же касается производительности, то да, этот дополнительный код ее снизит, поэтому, если нет насущной необходимости все уложить максимально компактно, то лучше данные выравнивать. См. выше мои слова про размер данных и размер пакета.
> > "Нам не дано предугадать", в каком месте наш софт
> > слетит. И не стоит уповать на вылизанность кода, тем более
> > что потери производительности действительно никакой.
>
> Вот блин! Хоть это я сделал правильно;))
Ну почему "хоть это" - основная идея была заложена вполне прогрессивная, имхо :)
Да, кстати. Весьма серьезным моментом при выходе на уровень Интернет, будет параноидальность при обработке полученных пакетов. В LAN обычно еще можно (хотя уже нехорошо) заложиться на то, что к серверу всегда будет присоединяться "хороший" клиент, а не хакер с неткатом. А в Интернет надо проверять все по полной. Поэтому вопросы производительности по сравнению с вопросами безопасности нередко отходят (должны отходить) на второй план.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
