Вернуться   CoderX :: Forums > Основные форумы > Курилка
Войти через OpenID

Курилка Флудим и шутим тут!

Чат (Новых сообщений с момента вашего последнего визита нет)
Загрузка...
Задавайте ваши вопросы на форуме. Чат предназначен для небольших разговоров.
 
Ответ
 
Опции темы Опции просмотра
Старый 31.03.2017, 22:00   #11
Пользователь
 
Регистрация: 14.07.2016
Сообщений: 59
Сказал Спасибо: 6
Имеет 10 спасибок в 9 сообщенях
Smwr на пути к лучшему
По умолчанию

Цитата:
Сообщение от ScythLab Посмотреть сообщение
кстати, здесь все же крайне желательно использовать локальные переменные и так сказать "локальную" память, т.е. либо стек буферов свой делать и бегать по ним, либо постоянно выделять память (эта операция очень быстрая благодаря менеджеру памяти компилятора)
буффер будет отправлен немедленно в том же потоке, зачем постоянно перевыделять, если можно выделить один раз?
Smwr вне форума   Ответить с цитированием
Старый 31.03.2017, 23:34   #12
Местный
 
Регистрация: 22.10.2014
Сообщений: 122
Сказал Спасибо: 1
Имеет 8 спасибок в 7 сообщенях
alexov пока неопределено
По умолчанию

Цитата:
Сообщение от Smwr Посмотреть сообщение
но зачем такое? под size выделено 4 байта -> максимум 2^16, столько можно выделить один раз и не задумываться.


куда по сети если не секрет?
1) Мы в таком случае выделяем больше памяти чем нужно. Как-то это не оптимально. А однажды окажется что мы выделяем меньше памяти чем нужно, и мы упадем. Плохо. Алгоритмы должны быть адаптивными.

2) У меня бот на C#, работает через перехват траффика. на некоторых серверах траффик зашифрован., а значит его нужно хватать через сплайсинг., но делается это на Delphi или C++, поэтому я хочу сделать коннектор и отправлять "чистый" траффик в бота.
alexov вне форума   Ответить с цитированием
Старый 01.04.2017, 09:02   #13
Пользователь
 
Регистрация: 14.07.2016
Сообщений: 59
Сказал Спасибо: 6
Имеет 10 спасибок в 9 сообщенях
Smwr на пути к лучшему
По умолчанию

Цитата:
Сообщение от alexov Посмотреть сообщение
1) Мы в таком случае выделяем больше памяти чем нужно. Как-то это не оптимально. А однажды окажется что мы выделяем меньше памяти чем нужно, и мы упадем. Плохо. Алгоритмы должны быть адаптивными.
спорить о выделении лишних 20-30 килобайт для запаса это даже не смешно
Кстати говоря, выделение динамической памяти не самая быстрая операция, её рекомендуют сторониться.
Smwr вне форума   Ответить с цитированием
Старый 01.04.2017, 10:37   #14
Местный
 
Регистрация: 22.10.2014
Сообщений: 122
Сказал Спасибо: 1
Имеет 8 спасибок в 7 сообщенях
alexov пока неопределено
По умолчанию

Цитата:
Сообщение от Smwr Посмотреть сообщение
спорить о выделении лишних 20-30 килобайт для запаса это даже не смешно
Кстати говоря, выделение динамической памяти не самая быстрая операция, её рекомендуют сторониться.
сегодня я пишу софтину для 10 клиентов, а завтра для 10000. я хочу чтобы мой код нормально масштабировался. И я не хочу вылететь когда пакеты внезапно станут больше. И выделение памяти происходит буквально пару раз лишних, это не критично
alexov вне форума   Ответить с цитированием
Старый 01.04.2017, 10:57   #15
Местный
 
Аватар для supernewbie
 
Регистрация: 23.09.2009
Сообщений: 1,232
Сказал Спасибо: 119
Имеет 172 спасибок в 134 сообщенях
supernewbie пока неопределено
По умолчанию

alexov, можно изловчиться и сделать один буфер на один поток, передавая этот буфер текущему боту с которым поток работает.
в итоге если ядер скажем 4, то это всего-лишь 4 * 64K байт на буферы
__________________
Начало.
supernewbie вне форума   Ответить с цитированием
Старый 01.04.2017, 18:10   #16
Местный
 
Аватар для ScythLab
 
Регистрация: 24.10.2014
Сообщений: 190
Сказал Спасибо: 4
Имеет 42 спасибок в 40 сообщенях
ScythLab пока неопределено
По умолчанию

Цитата:
Сообщение от Smwr Посмотреть сообщение
буффер будет отправлен немедленно в том же потоке, зачем постоянно перевыделять, если можно выделить один раз?
ты перехватил функцию Send, тебе нужно в ней до 64к памяти, когда ты собираешься выделить эту память? внутри функции и сохранить ссылку на память в глобальной переменной? если так, то следующей вызов функции может идти из другого потока и причем параллельно с предыдущим, в итоге крах ла2, либо дисконнект

Цитата:
Сообщение от supernewbie Посмотреть сообщение
alexov, можно изловчиться и сделать один буфер на один поток, передавая этот буфер текущему боту с которым поток работает.
в итоге если ядер скажем 4, то это всего-лишь 4 * 64K байт на буферы
ты хочешь сказать, что если у меня одноядерный проц, то я не смогу запустить на нем, скажем, 100 потоков?

здесь 2 простых решения:
1) глобальный массив массивов (можно его динамическим сделать, тогда все будет кошерно) и использовать его по кругу (даже паттерн программирования такой есть)
2) выделять память каждый раз внутри функции Send; если память гарантированно освобождать после этого и посмотреть на работу менеджера памяти, то можно увидеть, что операция очень и очень быстрая (на 100 циклов выделений/освобождения потребуется пару микросекунд, а ла2 очень редко когда пропускается хотя бы 100 пакетов/секунду)

PS. второй вариант проще, т.к. в (1) все равно придется делать некоторую синхронизацию по работе с общим буфером
__________________
Хобби: разработка бота для Lineage.

Последний раз редактировалось ScythLab, 01.04.2017 в 18:14.
ScythLab вне форума   Ответить с цитированием
За это сообщение ScythLab нажился спасибкой от:
Старый 01.04.2017, 18:23   #17
Пользователь
 
Регистрация: 14.07.2016
Сообщений: 59
Сказал Спасибо: 6
Имеет 10 спасибок в 9 сообщенях
Smwr на пути к лучшему
По умолчанию

Цитата:
Сообщение от ScythLab Посмотреть сообщение
следующей вызов функции может идти из другого потока и причем параллельно с предыдущим
не может. клиент дергает этот метод только из главного потока.
а дергать его ботом не из главного даже самая стремная защита не позволит.



и вообще, как то вы все усложняете простые вещи

Последний раз редактировалось Smwr, 01.04.2017 в 18:28.
Smwr вне форума   Ответить с цитированием
Старый 01.04.2017, 22:52   #18
Местный
 
Аватар для ScythLab
 
Регистрация: 24.10.2014
Сообщений: 190
Сказал Спасибо: 4
Имеет 42 спасибок в 40 сообщенях
ScythLab пока неопределено
По умолчанию

Цитата:
Сообщение от Smwr Посмотреть сообщение
не может. клиент дергает этот метод только из главного потока.
я бы сказал, что "в основном" дергает из главного потока, не зря же у них внутри идет работа с критическими секциями, значит они что-то знают
PS. а если ты пишешь код для одного потока, то тупо делаешь глобальный статический массив и не паришься

Цитата:
а дергать его ботом не из главного даже самая стремная защита не позволит.
а я дергал и мне защиты позволяли, только я их хорошо просил

Цитата:
и вообще, как то вы все усложняете простые вещи
иногда такие усложнения так много волос на жопе берегут, что лучше лишний раз перебздеть
__________________
Хобби: разработка бота для Lineage.
ScythLab вне форума   Ответить с цитированием
Старый 02.04.2017, 03:39   #19
Местный
 
Регистрация: 22.10.2014
Сообщений: 122
Сказал Спасибо: 1
Имеет 8 спасибок в 7 сообщенях
alexov пока неопределено
По умолчанию

Цитата:
Сообщение от supernewbie Посмотреть сообщение
alexov, можно изловчиться и сделать один буфер на один поток, передавая этот буфер текущему боту с которым поток работает.
в итоге если ядер скажем 4, то это всего-лишь 4 * 64K байт на буферы
можно изловчиться и сделать 10-20 переменных во всей программе и переиспользовать их по мере освобождения) но это потребует такой нетривиальной логики которую ни один человек не осилит)

Ну а если серьезно - использовать на 4х ядерном процессоре только 4 потока, это хорошая идея, для этого и придумали асинхронное программирование. Я так и делаю. Но вот в чем загвоздка, при асинхронном программировании код превращается в последовательность из коллбэков, а порядком их исполнения рулит тредпул.

Так вот к чему это я. Если для каждого клиента создать полный контекст из данных которые ему нужны, включая буфер для сетевых данных, код получается простой и красивый, потому что нам не важно в каком порядке на самом деле исполняется код. Но как только мы заведем общий буфер для группы клиентов, сразу появляются ограничения на то как мы должны писать код, чтобы этот буфер не запороть. Не знаю как это понятнее объяснить, но я думаю что те кто уже пишет асинхронный код, должны понять.
alexov вне форума   Ответить с цитированием
Старый 02.04.2017, 11:42   #20
Местный
 
Аватар для supernewbie
 
Регистрация: 23.09.2009
Сообщений: 1,232
Сказал Спасибо: 119
Имеет 172 спасибок в 134 сообщенях
supernewbie пока неопределено
По умолчанию

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

Цитата:
Сообщение от alexov Посмотреть сообщение
Но как только мы заведем общий буфер для группы клиентов, сразу появляются ограничения на то как мы должны писать код, чтобы этот буфер не запороть
идея в следующем (далее псевдокод):
Код:
переменные на каждый поток:
  общий_сетевой_буфер = массив байт равный максимальному размеру пакета (65535 в нашем случае)
  боты = список ботов для обработки

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

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

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

Последний раз редактировалось supernewbie, 02.04.2017 в 12:18.
supernewbie вне форума   Ответить с цитированием
Ответ

  CoderX :: Forums > Основные форумы > Курилка



Ваши права в разделе
Вы не можете создавать темы
Вы не можете отвечать на сообщения
Вы не можете прикреплять файлы
Вы не можете редактировать сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


Часовой пояс GMT +4, время: 03:01.

vBulletin style designed by MSC Team.
Powered by vBulletin® Version 3.6.11
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Locations of visitors to this page
Rambler's Top100

Вы хотите чувствовать себя в безопасности? чоп Белган обеспечит её!