[Lineage2] rGuard Interlude

supernewbie · 02.04.2017, 11:42

Цитата:

Сообщение от ScythLab

ты хочешь сказать, что если у меня одноядерный проц, то я не смогу запустить на нем, скажем, 100 потоков?

сможешь, но зачем?) если внутри потока не используется блокирующих функций кроме ожидания когда все возможные на данный момент действия завершены, то поток будет максимально эффективно использовать ядро, конечно если так сделать не получится то можно и 100 и 1000 потоков сделать, но если прикинуть то на 10000 ботов вряд ли понадобится даже 1000 потоков, потому что это получается по 10 ботов на поток, что за неоптимальное использование там будет происходить?) вообще даже при неоптимальном коде можно использовать формулу типа {количество_ядер * коэффициент_неоптимальности} и запускать скажем по 10 потоков на ядро, чтобы система разобралась кто простаивает, а кто нет. в итоге 40 потоков и в них можно впихнуть теже 10000 ботов по 250 ботов на поток, а дальше уже дело оптимизации, сможешь ли ты написать тело обработки одного бота чтобы 250 ботов успевали обработаться за уделенное им время. но и да, если код оптимален то производить потоки более чем на 90% загружающих ядро в количестве большем, чем имеется ядер, нет смысла, потому как это только ухудшит производительность, плюс кстати у потоков же ещё стек выделяется + куча внутренних поточных штук, так что каждый поток это ещё блок памяти. в общем лучше писать оптимальный код, создавать минимум потоков, создавать один общий буфер для одного потока и отдавать одному потоку как можно больше ботов на обработку. но в реальности как получится так и будет

Цитата:

Сообщение от alexov

Но как только мы заведем общий буфер для группы клиентов, сразу появляются ограничения на то как мы должны писать код, чтобы этот буфер не запороть

идея в следующем (далее псевдокод):

Код:

переменные на каждый поток:
  общий_сетевой_буфер = массив байт равный максимальному размеру пакета (65535 в нашем случае)
  боты = список ботов для обработки

тело_потока:

для каждого бота в ботах потока делаем:
{
  бот.установить_буфер(общий_сетевой_буфер);
  // в этом моменте бот использует общий буфер потока
  // для приема и отправки данных
  бот.получить_сетевые_данные_используя_буфер();
  бот.послать_данные_используя_буфер();
  бот.аннулировать_буфер();
  // в этом моменте у бота больше нет буфера
  // в следующей итерации общий буфер перейдет к следующему боту
}

при такой архитектуре единственное что нужно держать в памяти экземпляра бота это переменные необходимые для воссоздания пакетов при записи их в буфер для отправки и буферизацию фрагментированных пакетов при приеме фрагметированных данных, но буфер для фрагментов можно сделать равным максимально возможной длине элемента пакета (скажем максимальная длина строки - 64 символа) в итоге буфер для фрагментов пакета - (64 * 2 + 2) байт

в общем что-то такое можно придумать)

ScythLab · 02.04.2017, 19:54

Цитата:

Сообщение от supernewbie

сможешь, но зачем?)

ты путаешь программирование для каких-нибудь расчетов, там где тебе нужно максимально эффективно использовать ресурсы компа и обычные программы, которые, как правило, проектируются с точки зрения удобства разработки, поддержки, и чтобы у пользователя интерфейс по минимуму тормозил, тогда как в фоне идет работа с сетью, диском и прочими данными. Как раз ла2 является представителем второй категории, да и боту никогда не нужно столько расчетов, чтобы задумываться об эффективности использования каждого ядра и ручного распределения своих потоков между ядрами (у меня бот использует менее 1% от моего проца, и может его подгружать только при прорисовке карты, т.к. этот участок крайне не оптимален и медленный)

alexov · 03.04.2017, 06:09

Цитата:

Сообщение от supernewbie

идея в следующем (далее псевдокод):

Код:

переменные на каждый поток:
  общий_сетевой_буфер = массив байт равный максимальному размеру пакета (65535 в нашем случае)
  боты = список ботов для обработки

тело_потока:

для каждого бота в ботах потока делаем:
{
  бот.установить_буфер(общий_сетевой_буфер);
  // в этом моменте бот использует общий буфер потока
  // для приема и отправки данных
  бот.получить_сетевые_данные_используя_буфер();
  бот.послать_данные_используя_буфер();
  бот.аннулировать_буфер();
  // в этом моменте у бота больше нет буфера
  // в следующей итерации общий буфер перейдет к следующему боту
}

Повторюсь, экономить потоки это хорошая идея. Но делать это надо не так. В том что ты предлагаешь следующие проблемы:
1) ручная балансировка ботов между потоками
2) прием данных бывает либо блокирующий, что в твоем случае не подходит. либо асинхронный. что в твоем случае не подходит. либо активное ожидание - привет дополнительные задержки и излишний расход процессорного времени.

И снова мы приходим к тому что код должен быть полностью асинхронный. А в асинхронном коде ограничение на неразрывность обработки одного пакета является злом. Вот захочу я посреди обработки пакета отправить пакет другому клиенту, в этот момент я должен отпустить поток исполняющий мой код, и прощайте буфера.

Yegor · 04.04.2017, 01:45

Цитата:

Сообщение от alexov

код должен быть полностью асинхронный.

Тоесть получить доп задержки ожидания месаджей от винды?

supernewbie · 04.04.2017, 02:57

Yegor, если не вызывать WaitMessage то мессаджей ждать не придется, если ты об этом

Оффтоп

Yegor · 05.04.2017, 01:27

Цитата:

Сообщение от supernewbie

Yegor, если не вызывать WaitMessage то мессаджей ждать не придется, если ты об этом

Каким образом в асинхронном режиме ваш процесс узнает что пришла очередная порция данных в буфер, новое подключение и т.п.?
Вашему коду ждать не прийдется но месаг будет пойман и обработан в главном потоке ожидания месаджей, а это все задержки.

supernewbie · 05.04.2017, 01:52

Yegor, хехе, я об этом подозревал, но не хотел вслух говорить.

но насколько долгие эти задержки? по хорошему надо затестить этот момент и сравнить с WSAPoll и с реализацией на блокирующих функциях (1 сокет = 2 потока). может быть это уже кем-нибудь было сделано?

alexov · 05.04.2017, 07:55

Цитата:

Сообщение от Yegor

Каким образом в асинхронном режиме ваш процесс узнает что пришла очередная порция данных в буфер, новое подключение и т.п.?
Вашему коду ждать не прийдется но месаг будет пойман и обработан в главном потоке ожидания месаджей, а это все задержки.

Скажу честно я не вникал как это работает в ядре Windows, я пишу на C#, внимательно изучил документацию и провел свои тесты.

Пусть это немного наивно, но вот что я сделал:
1) взял в аренду VDS, пропинговал его, получил пинг 59мс (да я знаю что пинг идет по ICMP)
2) написал свой сервер и свой клиент, подключился и дал 50mbps нагрузку по траффику через много копий клиента, сделал замеры времени ответа средствами языка, у меня снова получилось 59мс. 0% загрузка процессора, и ровно 4 потока в серверном приложении.

может быть задержки о которых вы говорите измеряются в наносекундах?) какая тогда разница

alexov · 04.04.2017, 06:41

Цитата:

Сообщение от Yegor

Тоесть получить доп задержки ожидания месаджей от винды?

О каких задержках идет речь? можно пруф?
лично у меня никаких задержек нет