Ага, когда ретрансмиссия используется в обычном режиме, то клиент прекрасно разбирает все. Но при этом количество ретрансмиссий несравнимо меньше с количеством обычных сообщений, поэтому уж их то можно не напрягаясь отследить.
Более того, в вашем случае необходим запущенный клиент. А для фарма в промышленных масштабах нужно много одновременно бегающих ботов. Не всякий компутер потянет столько открытых окон.
Ну про ядро вы помоему загнули. Сервер и клиент общаются только через сеть. Следовательно, если бот будет слать пакеты идиентичные настоящему клиенту игры, то сервер в жизни ничего не заметит.
Но согласен, реверсить придется в любом случае.
У меня такая же мышь, проблемы со скролом не наблюдал.
Зато через 3 года работы сломалась левая кнопка мыши, пришлось разобрать и вытащить из под кнопки тройного нажатия работающую деталь. И да, покрытие пооблезло.
>у ядра есть свои буфферы для сокетов
Да, приложение работает не с этими буферами. Zero-copy это вообще отдельная тема.
>Но это же во много хуже по сравнению с неблокирующим вариантом, где мне достаточно одного буффера на тред
На тред? У вас client-per-thread? Тогда стоит считать не буферы, а треды. При описанной выше схеме у вас всего лишь несколько потоков.
И я не совсем понял насчет
>что мы ко всему этому на каждый запрос чтения выделяем буффер
Со стороны вызовы recv на неблокирующем сокете и WSASend с OVERLAPPED выглядят одинаково. Разница в том, как мы получаем и обрабатываем результат выполнения.
То, что вы описали kills the purpose. Я еще в прошлом посте хотел отметить что неблокирующие сокеты (или вообще чтение/запись) это еще не асинхронность.
Суть как раз в том, что после
>делаем асинхронный запрос на чтение и передаём буффер
мы ничего не ждем. Каждый цикл мы смотрим на ситуацию — есть ли чего на отправку или на прием. Если что-то есть, то мы инициируем новую операцию или обрабатываем завершившуюся. Если нет вообще ничего, то поток спит не потребляя CPU.
Вообще касательно линукса: там есть aio. Вот хорошая, на мой взгляд иллюстрация: www.ibm.com/developerworks/linux/library/l-async/figure1.gif
Aio — это фактически оверлаппед вызовы виндовс. Порта завершения в линуксе нет, т.к. это относительно высокоуровневый объект. Я сейчас разбираюсь с механизмом kqueue+aio в FreeBSD, чтобы реализовать аналог iocp.
Вообще статья о потоках, а не буферах, так что я не мудрувствовал особо. Впрочем, у меня вообще нету отдельных буферов для каждого клиента — все клиенту пишут в одно большое кольцо памяти, которое кстати статично и мне не приходится каждый раз искать место под нового юзера или новое сообщение.
Хорошо, если клиент ВоВ работает как антивирус в режиме проактивной защиты, я его вообще удалю перед запуском бота. Так сойдет?
Но согласен, реверсить придется в любом случае.
Зато через 3 года работы сломалась левая кнопка мыши, пришлось разобрать и вытащить из под кнопки тройного нажатия работающую деталь. И да, покрытие пооблезло.
Да, приложение работает не с этими буферами. Zero-copy это вообще отдельная тема.
>Но это же во много хуже по сравнению с неблокирующим вариантом, где мне достаточно одного буффера на тред
На тред? У вас client-per-thread? Тогда стоит считать не буферы, а треды. При описанной выше схеме у вас всего лишь несколько потоков.
И я не совсем понял насчет
>что мы ко всему этому на каждый запрос чтения выделяем буффер
Со стороны вызовы recv на неблокирующем сокете и WSASend с OVERLAPPED выглядят одинаково. Разница в том, как мы получаем и обрабатываем результат выполнения.
Суть как раз в том, что после
>делаем асинхронный запрос на чтение и передаём буффер
мы ничего не ждем. Каждый цикл мы смотрим на ситуацию — есть ли чего на отправку или на прием. Если что-то есть, то мы инициируем новую операцию или обрабатываем завершившуюся. Если нет вообще ничего, то поток спит не потребляя CPU.
Вообще касательно линукса: там есть aio. Вот хорошая, на мой взгляд иллюстрация: www.ibm.com/developerworks/linux/library/l-async/figure1.gif
Aio — это фактически оверлаппед вызовы виндовс. Порта завершения в линуксе нет, т.к. это относительно высокоуровневый объект. Я сейчас разбираюсь с механизмом kqueue+aio в FreeBSD, чтобы реализовать аналог iocp.