20 Кб, 1200x800Аноны, а на Python можно написать программу типа Goodbye DPI?
Там реально сделать подобное? Возможно ли манипулировать передающимися данными на таком уровне в реальном времени на Python?
Там реально сделать подобное? Возможно ли манипулировать передающимися данными на таком уровне в реальном времени на Python?
>>39844 (OP)
Можно. Goodbye DPI это обычная дрочилка строковых байтов на С поверх сетевого драйвера, который написан был написан другим программистом.
Можно. Goodbye DPI это обычная дрочилка строковых байтов на С поверх сетевого драйвера, который написан был написан другим программистом.
>>39844 (OP)
В догонку, на питоне эта прога будет строк 200 максимум, ибо работа со строками уже в стандартной либе зашита.
В догонку, на питоне эта прога будет строк 200 максимум, ибо работа со строками уже в стандартной либе зашита.
>>39844 (OP)
Если кто-то за тебя уже написал все нужные функции на сишке и заботливо их обернул в готовое API, то конечно можно, хоть на 1С или VBA. Пишешь десяток строк и можешь гордиться, как охуенно решил проблему полностью сам.
Если кто-то за тебя уже написал все нужные функции на сишке и заботливо их обернул в готовое API, то конечно можно, хоть на 1С или VBA. Пишешь десяток строк и можешь гордиться, как охуенно решил проблему полностью сам.
>>39844 (OP)
В чём суть твоего вопроса? По твоему на питоне можно написать нейронку, но нельзя написать дрочилку пакетов сетевого трафика?
В чём суть твоего вопроса? По твоему на питоне можно написать нейронку, но нельзя написать дрочилку пакетов сетевого трафика?
>>39844 (OP)
Пока не написана программа - нельзя.
Когда будет написана - можно.
В вопросе ложная дихотомия. Помимо языка, для написания программы нужен человек с человеческим фактором, без которого ничего написано не будет - нельзя.
Пока не написана программа - нельзя.
Когда будет написана - можно.
В вопросе ложная дихотомия. Помимо языка, для написания программы нужен человек с человеческим фактором, без которого ничего написано не будет - нельзя.
>>39844 (OP)
Если там нужна многопоточность - то нет.
Если там нужна многопоточность - то нет.
>>39844 (OP)
Да, можно написать программу из одной функции на питоне, который вызывает модуль на Си, который всё делает. Потом заявить что ты написал питон программу, которая манипулирует пакетами.
Да, можно написать программу из одной функции на питоне, который вызывает модуль на Си, который всё делает. Потом заявить что ты написал питон программу, которая манипулирует пакетами.
>>39844 (OP)
Мне кажется, такое УЖЕ написано на Питоне во множестве вариантов. Но это надо искать по Гитхабу.
Мне кажется, такое УЖЕ написано на Питоне во множестве вариантов. Но это надо искать по Гитхабу.
>>39844 (OP)
Конечно можно, питон из коробки поддерживает низкоуровневые сокеты. Другое дело что в питоне не очень удобно с байтами работать, ну по крайней мере мне как С++ прогеру.
Но вообще, если выбирать из таких высокоуровневых языков, то я бы может на TypeScript под ноду написал бы, нода все намного быстрее питона и поддерживает многопоточность, к тому же тайпскрипт строготипизированный язык в отличии от питона. Питон вряд ли сможет обеспечить более 1-2 одновременных коннекшена, конечно можно делать форк на каждый коннекшн, но если их будет тысячи то тоже будет хуйня.
А вообще не еби мозги, если ты задаешь такие вопросы, то писать что-то типа anti-dpi системы тебе точно рановато.
Конечно можно, питон из коробки поддерживает низкоуровневые сокеты. Другое дело что в питоне не очень удобно с байтами работать, ну по крайней мере мне как С++ прогеру.
Но вообще, если выбирать из таких высокоуровневых языков, то я бы может на TypeScript под ноду написал бы, нода все намного быстрее питона и поддерживает многопоточность, к тому же тайпскрипт строготипизированный язык в отличии от питона. Питон вряд ли сможет обеспечить более 1-2 одновременных коннекшена, конечно можно делать форк на каждый коннекшн, но если их будет тысячи то тоже будет хуйня.
А вообще не еби мозги, если ты задаешь такие вопросы, то писать что-то типа anti-dpi системы тебе точно рановато.
>>78590
Многими. GIL не перманентный. Он включается когда выполяется питонячий байткод. Когда делается ввод вывод и сишная либа что-то считает гил разблокирует другие потоки, пока какой нибудь питонячий код снова не запустится. Если не делать тяжелые вычисления на самом питоновском коде, то вполне можно распаралеливать запросы и вычислять хеши с тензорами в потоках. Запросы сейчас распаралеливаются с asyncio, но если хочешь старый добрый requests то делаешь в многопотоке.
Многими. GIL не перманентный. Он включается когда выполяется питонячий байткод. Когда делается ввод вывод и сишная либа что-то считает гил разблокирует другие потоки, пока какой нибудь питонячий код снова не запустится. Если не делать тяжелые вычисления на самом питоновском коде, то вполне можно распаралеливать запросы и вычислять хеши с тензорами в потоках. Запросы сейчас распаралеливаются с asyncio, но если хочешь старый добрый requests то делаешь в многопотоке.
>>78618
Я не про питон, я про ноду. Там нет нормальной многопоточности с расшаренным стейтом, семафорами и всем, зачем может быть нужна многопоточность - вместо этого там какое-то говно типа эмуляции fork. Зачем оно, если можно спавнить воркеры сразу через форк? Чтобы у спермоблядей работало?
Я не про питон, я про ноду. Там нет нормальной многопоточности с расшаренным стейтом, семафорами и всем, зачем может быть нужна многопоточность - вместо этого там какое-то говно типа эмуляции fork. Зачем оно, если можно спавнить воркеры сразу через форк? Чтобы у спермоблядей работало?
>>78626
Ладно. Я пост не полностью прочитал и сразу пошел защищать питон )
Чтобы были общие данные у потоков, а иначе в ноде тебе придется плеваться сообщениями между родительским процессом и дочерними. А еще репу чесать как обменяться данными между дочерними процессами.
Я как-то делал такую схему.
1) В родительском процессе создаю задачу и присваиваю ей ID
2) Запускаю дочерний процесс с задачей.
3) Ожидаю сообщения от дочернего процесса с ID задачи
Выглядит как полная шняга..
Ладно. Я пост не полностью прочитал и сразу пошел защищать питон )
Чтобы были общие данные у потоков, а иначе в ноде тебе придется плеваться сообщениями между родительским процессом и дочерними. А еще репу чесать как обменяться данными между дочерними процессами.
Я как-то делал такую схему.
1) В родительском процессе создаю задачу и присваиваю ей ID
2) Запускаю дочерний процесс с задачей.
3) Ожидаю сообщения от дочернего процесса с ID задачи
Выглядит как полная шняга..
>>78629
Так в том и прикол, что их там вроде как и нет. Зато есть мессадж порты.
Хотя я сейчас посмотрел npm и пожалуй смысл этим всем пользоваться и правда есть - как минимум, не костылять самому обёртку над форками, которую за годы существования ноды никто почему-то так и не сделал.
>Чтобы были общие данные у потоков
Так в том и прикол, что их там вроде как и нет. Зато есть мессадж порты.
>https://nodejs.org/api/worker_threads.html#workerparentport
>Unlike traditional thread models, Node.js worker threads communicate via message passing rather than shared memory
Хотя я сейчас посмотрел npm и пожалуй смысл этим всем пользоваться и правда есть - как минимум, не костылять самому обёртку над форками, которую за годы существования ноды никто почему-то так и не сделал.
>>78590
Так в ноде встроенный тред пул. Хз конечно может в питоне какие-нибудь asyncio тоже используют тредпул внутри.
>>78626
Это вам батенька на С++ тогда надо.
"Это и есть самый настоящий форк. В ноде создать отдельный потом это форк. Хз я не спец по ноде, но читал как-то про это. Ну а как еще сделать поток в интерпретаторе. Я тебе больше скажу, даже сишная программа делает потом форком, просто отличаются параметры которые позволяют шарить виртуальное пространство между процессами.
Если мы говорим о контексте сервера, где может быть сотни тысяч конекшенов, то такой подход быстро умрет от OOM киллера.
В ноде есть тредпул внутри, и можно без задней мысли принимать конекшены и т.д. они будут распараллелены внутри тред пула. В питоне такого вроде как нет, если только либы какие. Вот и вся разница. Нода удобнее из коробки для этого. + Тайпскрипт лучше питона.
Так в ноде встроенный тред пул. Хз конечно может в питоне какие-нибудь asyncio тоже используют тредпул внутри.
>>78626
>с расшаренным стейтом, семафорами и всем, зачем может быть нужна многопоточность
Это вам батенька на С++ тогда надо.
> вместо этого там какое-то говно типа эмуляции fork
"Это и есть самый настоящий форк. В ноде создать отдельный потом это форк. Хз я не спец по ноде, но читал как-то про это. Ну а как еще сделать поток в интерпретаторе. Я тебе больше скажу, даже сишная программа делает потом форком, просто отличаются параметры которые позволяют шарить виртуальное пространство между процессами.
>Зачем оно, если можно спавнить воркеры сразу через форк?
Если мы говорим о контексте сервера, где может быть сотни тысяч конекшенов, то такой подход быстро умрет от OOM киллера.
В ноде есть тредпул внутри, и можно без задней мысли принимать конекшены и т.д. они будут распараллелены внутри тред пула. В питоне такого вроде как нет, если только либы какие. Вот и вся разница. Нода удобнее из коробки для этого. + Тайпскрипт лучше питона.
>>79275
1) У ноды для сети не тредпул, а ивентлуп ожидающий epoll (у винды оно хз что опрашивает, но похожее апи), asyncio в питухоне точно так же работает. Тредпул у ноды для файловых операций
2) Это бессмысленно противопоставлять мультитредингу, так как это внутренний механизм ноды и недоступен в жс коде, который выполняется в одном потоке.
3) Несколько потоков в ноде делается с помощью воркеров
1) У ноды для сети не тредпул, а ивентлуп ожидающий epoll (у винды оно хз что опрашивает, но похожее апи), asyncio в питухоне точно так же работает. Тредпул у ноды для файловых операций
2) Это бессмысленно противопоставлять мультитредингу, так как это внутренний механизм ноды и недоступен в жс коде, который выполняется в одном потоке.
3) Несколько потоков в ноде делается с помощью воркеров
>>79293
Алло, нода построена вокруг либы libav которая в свою очередь эвентпул на тредпуле или ты думал там эвентпул в одном главном потоке хуярит?
Так никто и не противопоставляет ничего. Просто для разныхх задач свои инструменты. Нода хорошо расчитана на серверные задачи благодаря тредпулу. Тебе и не нужно знать ничего о потоках. Ты оперируешь с другими материями при работе с ней, ты оперируешь асинхронностью. Как там внутри что, тебя вообще не должно интересовать. И она не работает в одном потоке.
Воркеры там для cpu-intensive задач. Всё io работает и так в несколько потоков.
Короче чел, ты зеленоватый еще иди матчасть подучи)
>1) У ноды для сети не тредпул, а ивентлуп ожидающий epoll (у винды оно хз что опрашивает, но похожее апи), asyncio в питухоне точно так же работает. Тредпул у ноды для файловых операций
Алло, нода построена вокруг либы libav которая в свою очередь эвентпул на тредпуле или ты думал там эвентпул в одном главном потоке хуярит?
>2) Это бессмысленно противопоставлять мультитредингу, так как это внутренний механизм ноды и недоступен в жс коде, который выполняется в одном потоке.
Так никто и не противопоставляет ничего. Просто для разныхх задач свои инструменты. Нода хорошо расчитана на серверные задачи благодаря тредпулу. Тебе и не нужно знать ничего о потоках. Ты оперируешь с другими материями при работе с ней, ты оперируешь асинхронностью. Как там внутри что, тебя вообще не должно интересовать. И она не работает в одном потоке.
>3) Несколько потоков в ноде делается с помощью воркеров
Воркеры там для cpu-intensive задач. Всё io работает и так в несколько потоков.
Короче чел, ты зеленоватый еще иди матчасть подучи)
>>79303
чел libuv
Для асинхронной обработки io тредпул не нужен. Зачем ты это приплел как доказательство многопточности ноды?
Но колбаки то один поток и один стек дрочат
Кто-то с этим спорил?
Чел иди учи матчасть..
>libav
>матчасть подучи
чел libuv
>нода построена вокруг либы libav которая в свою очередь эвентпул на тредпуле
Для асинхронной обработки io тредпул не нужен. Зачем ты это приплел как доказательство многопточности ноды?
>Всё io работает и так в несколько потоков.
Но колбаки то один поток и один стек дрочат
>Воркеры там
Кто-то с этим спорил?
Чел иди учи матчасть..
>>79316
Ой бля ну либ uv похуй, хоть libhuivrot, смысл не меняется.
Ты не шутишь? Я думал нужен....
Короче ты меня заебал, ты зелень которая нахваталась каких-то случайных знаний и пытается быть гуру.
Бля я на С++ все эти эвентпулы и epoll'ы сотни раз делал на лоу левеле по работе, ты мне рассказывать будешь про это? Можешь как долбоеб коненчо в одном потоке все делать, не это не обязывает продакт либы делать таким же долбоебским способом. Просто ты судя по всему из разряда тех, кто только что урвал какой-то кусок знаний и сразу неразобравшись побежал со всеми спорить и доказывать какой ты ахуенный низкоуровневый профи которому семафоры подавай, а все остальное не тру. Ну ты просто долбоеб.
>чел libuv
Ой бля ну либ uv похуй, хоть libhuivrot, смысл не меняется.
>Для асинхронной обработки io тредпул не нужен. Зачем ты это приплел как доказательство многопточности ноды?
Ты не шутишь? Я думал нужен....
Короче ты меня заебал, ты зелень которая нахваталась каких-то случайных знаний и пытается быть гуру.
Бля я на С++ все эти эвентпулы и epoll'ы сотни раз делал на лоу левеле по работе, ты мне рассказывать будешь про это? Можешь как долбоеб коненчо в одном потоке все делать, не это не обязывает продакт либы делать таким же долбоебским способом. Просто ты судя по всему из разряда тех, кто только что урвал какой-то кусок знаний и сразу неразобравшись побежал со всеми спорить и доказывать какой ты ахуенный низкоуровневый профи которому семафоры подавай, а все остальное не тру. Ну ты просто долбоеб.
>>79348
Но к сожалению нода такая...
https://stackoverflow.com/questions/50718543/node-js-how-libuv-thread-pool-works
There are ONLY FOUR things that use the thread pool - DNS lookup, fs, crypto and zlib. Everything else execute in the main thread irrespective or blocking or not.
>Можешь как долбоеб коненчо в одном потоке все делать
Но к сожалению нода такая...
https://stackoverflow.com/questions/50718543/node-js-how-libuv-thread-pool-works
There are ONLY FOUR things that use the thread pool - DNS lookup, fs, crypto and zlib. Everything else execute in the main thread irrespective or blocking or not.
>>79371
Ну как я понял это относистся к тому что в ноде изначально блокирующее, и то что это вынесли одельной либой аля в асинхронность через тред пул.
Я читал сейчас документацию ноды, там сказано
Просто даже в теории это особо возможно, если у тебя сервак на котором висит стотыщ, а то и милион конекшенов как это в одном потоке обработать? Типа у тебя 64 ядерный серверный проц и ты будешь всего один поток использовать для обработки всех этих событий? Ну это очевидно не будет работать. Может быть все таки в ноде еще есть тредпулы для network io и event handler'a? Хз я не спец по ноде, писал на ней только экстеншены для вскода и мини приложения какие-то. Но делать один поток для обработки всех эвентов анрил, тупость же.
Ну если так, нахуй тогда все это только хардкор только С++, смысл тогда писать на нодах всех этих, если они не работают на многопроцессорных системах.
Ну как я понял это относистся к тому что в ноде изначально блокирующее, и то что это вынесли одельной либой аля в асинхронность через тред пул.
Я читал сейчас документацию ноды, там сказано
>Node.js scales well, sometimes better than more heavyweight approaches like Apache. The secret to the scalability of Node.js is that it uses a small number of threads to handle many clients.
Просто даже в теории это особо возможно, если у тебя сервак на котором висит стотыщ, а то и милион конекшенов как это в одном потоке обработать? Типа у тебя 64 ядерный серверный проц и ты будешь всего один поток использовать для обработки всех этих событий? Ну это очевидно не будет работать. Может быть все таки в ноде еще есть тредпулы для network io и event handler'a? Хз я не спец по ноде, писал на ней только экстеншены для вскода и мини приложения какие-то. Но делать один поток для обработки всех эвентов анрил, тупость же.
Ну если так, нахуй тогда все это только хардкор только С++, смысл тогда писать на нодах всех этих, если они не работают на многопроцессорных системах.
>>79401
Конекшенов то у тебя мильен, но по сети байты приходят милииздрическими порциями в пакете по проволоке последовательно. За конекшенами следит ОС. Тебе из кода приложух же не надо за всеми ними следить, ты только следишь за тем что тебе вернет epoll wait, и он вернет дескрипторы сокетов в которых пришла очередная порция данных. Нода способна мильен конкшенов обрабатывать но не значит что она способна обрабатывать магистральный трафик. Если много данных прет, то обычно несколько инстансов ноды работает через балансер.
Разве не так?
Конекшенов то у тебя мильен, но по сети байты приходят милииздрическими порциями в пакете по проволоке последовательно. За конекшенами следит ОС. Тебе из кода приложух же не надо за всеми ними следить, ты только следишь за тем что тебе вернет epoll wait, и он вернет дескрипторы сокетов в которых пришла очередная порция данных. Нода способна мильен конкшенов обрабатывать но не значит что она способна обрабатывать магистральный трафик. Если много данных прет, то обычно несколько инстансов ноды работает через балансер.
Разве не так?
>>79421
Так, но тебе из этого мильона конекшенов может вернуться еполом пол мильона готовых одновременно, и вот ты в цикле на одном ядре будешь пол мульта обходить? А ведь там надо у каждого распарсить данные, подготовить ответ, и т.д. даже учитывая что все эти вещи будут делать в воркерах ноды, все равно это очень сомнительно выглядит и внесет нехилую задержку. Вряд ли конечно пол пульта сразу будут готовы, но проектируя систему надо учитывать худший сценарий, когда epoll тебе вернет 1 миллион готовых конекшенов и что ты с этим будешь делать.
Хз конечно как там нодисты и другие делают, но я всегда на С++ писал серверные вещи и у нас там всегда все параллелилось и было бы немыслимо делать эвентлуп в одном потоке.
Так, но тебе из этого мильона конекшенов может вернуться еполом пол мильона готовых одновременно, и вот ты в цикле на одном ядре будешь пол мульта обходить? А ведь там надо у каждого распарсить данные, подготовить ответ, и т.д. даже учитывая что все эти вещи будут делать в воркерах ноды, все равно это очень сомнительно выглядит и внесет нехилую задержку. Вряд ли конечно пол пульта сразу будут готовы, но проектируя систему надо учитывать худший сценарий, когда epoll тебе вернет 1 миллион готовых конекшенов и что ты с этим будешь делать.
Хз конечно как там нодисты и другие делают, но я всегда на С++ писал серверные вещи и у нас там всегда все параллелилось и было бы немыслимо делать эвентлуп в одном потоке.