Как реализовать бекконект?

[Quake3]

Интересует такой вопрос. Судя по объявлениям, всем нужен сокс бот с бекконектом. Но как сделать этот бекконект, я не понимаю и не нашел никаких статей на эту тему. Насколько удалось выяснить, это серверный скрипт, который выступает "переходником" между пользователем сокс-бота и зараженным сокс-ботом компьютером.

Нет ли где-нибудь в паблике статей/примеров (желательно, на php) этого самого бекконекта? Чтоб хотя бы разобраться в общих чертах, как такое делается.

 

[at0m]

также интересует вопрос
Первое что пришло в голову, припустим есть сеть ботов каждый делает коннект на основной сервак и поддерживает подключение ( знаю будет нагрузка ) с другой стороны у этого сервака есть IP x.x.x.x и открытые порты начиная с 1000 по 10000. На портах будет соединения клиентов. То есть каждый порт соответствует соединенному боту (делать просто пересылку данных с текущего соединения бота на текущий порт соединения клиента ). Но если чесно на эту идею нужен хз какой мощности сервак да и подключения постоянно бота к серваку не гуд палево.На реализацию сначала думал порт маппинг но говорят что не всегда работает ...

 

[higaru]

Quake3
Привет будущим конкурентам :P
Во-первых забудьте о скриптах, тк нужно будет поддерживать постоянные соединение и передавать кучу трафика, что не выдержит не один скрипт + куча ботов онлайн (1 бот - 1 инстанс пхп интерпретатора 0___o). Поэтому только нативный код. Желательно ещё кросплатформенность, чтобы поддерживать любые дедики для развертывания бэкконект сервера и как следствия использования чего-то типо boost::asio или poco framework.
Во-вторых модель с одним двумя потоками на бота не выдерживает совсем никакой критики (вспомнить хотя бы тогоже IceSocksBot - у него были проблемы со стабильностью бэкконекта по этой причине, больше 1000 ботов не держал, насколько помню) поэтому только асинхронная модель + пул потоков для обработки по числу ядер.
В третьих в принципе есть готовые решения по бэкконекту - реализация TURN сервера или STUN-сервера (на википедии довольно неплохо расписано + довольно объемные рфц существуют). Первый это тупо пересылка через сервер трафика, второй хитрый обход ната, сервер используется только для хэндшейка и определения куда слать, трафик клиенты шлют уже самостоятельно, но подходит не для всех натов. Обычно для уменьшения нагрузки эти два сервера используются в связке. Реализация их с нуля довольно объёмная задача сама по себе и немного выходит за рамки среднестатистических проектов, поэтому большинство используют собственные протоколы. к примеру у Зевса реализован довольно примитивный протокол с парой команд типа бинд и тд, что хорошо, тк уменьшает затраты на разработку.
Upnp маппинг в качестве обхода ната уже издох, на сколько знаю, да и никогда он не являлся стопроцентным решением проблемы.

Далее общая схема работы
На сервере изначально 1 порт слушается, на него конектятся боты.
1 управляющий канал от бота к серверу для посылки команд. Чтобы открыть бэкконект сессию бот направляет бинд команду серверу и тот соответственно начинает слушать какой-то порт для приема соединений от клиентов. При коннекте клиента на этот порт по управляющему соединение посылается уведомление о приеме клиента и бот открывает ещё одно соединение к серверу для пересылки данных. Сервер пересылает данные из сокета клиента в соединение бота (новое которое). Ну и так пока управляющее соединение от бота ещё живо.
Подобная схема реализована например в пассивном режиме ftp, почитайте рфц там наверное понятней описывается, чем я тут написал.

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

 

[Barack]

Товарищ Quake судя по вашим предыдущим вопросам, и исходя из вашего нынешнего уровня при всем уважении - браться за это дело еще рано, в сетевом программировании подводных камней несколько больше, а в официальной документации ты не найдешь ответы на многие свои вопросы и часто приходиться просто ставить эксперименты. Кроме того, надо позаботиться о быстром и эффективном хранении данных/буферов, реализации для более "нагруженного" использования предполагают наличие своей очереди куда складываются принимаемые пакеты и пакеты для отправки, но не нужно забывать что очередь может очень сильно разрастись и не хватит системных ресурсов/памяти , например ситуация когда у отдающего канал больше чем у принимаемого - поэтому при этом взаимодействии важно, чтобы следующие данные не отправлялись пока не получим подтверждение от принимающей стороны ну и т.д. и т.п.
За реализацию бэкконект сервера на bsd-сокетах тебя посадят на кресло почета :o :
Кресло почета

 

[Quake3]

Спасибо всем за ответы. В общем, буду изучать матчасть, а то наверное в самом деле, рано мне еще такое кодить :swoon2:

 

[TrueUser]

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