Понимание сути проблемы
Четкое понимание сути проблемы - большая половина ее решения.
Называем все своими именами
Если вы хотите, чтобы этот обходной путь работал для вас, вам придется
понять, КАК он работает, чтобы, если что-то сломается, вы знали где искать
неисправность.
Первый шаг на пути к пониманию проблемы - присвоить всему соответствующие
названия.
Итак "локальная" - это машина, которая устанавливает соединение, файлы на
ней тоже называются "локальными"; и наоборот - "удаленная" - это машина с
другой стороны соединения.
Проблема
Наша цель - соединить между собой ввод и вывод локального IP-эмулятора,
соответственно, с выводом и вводом удаленного IP-эмулятора
Каналами связи между двумя эмуляторами могут быть либо устройства (обычно
pppd), либо "текущий терминал (tty)". Первый вариант, практически, невозможен
в telnet-соединениях. Второй должен быть достаточно хитрым, потому что,
когда вы запускаете локальный эмулятор из командной строки, он подключен к
текущему tty пользователя, а не к telnet-сессии; если мы захотим открыть
новую сессию (локальную или удаленную) на новом терминале, нам придется
синхронизировать запуск и соединение IP-эмуляторов, иначе мусор одного из
эмуляторов будет восприниматься как команды на другой стороне - это
приведет еще к большему мусору и т.п..
Дополнительные трудности
Чтобы все было хорошо, локальный эмулятор должен позволять создавать
IP-соединения на уровне ядра, то есть, быть pppd. Однако pppd достаточно
глуп - он позволяет создавать соединения только через /dev-устройства или
через текущий tty; это должно быть tty, а не парой потоков (pipe) (как все
было бы просто!). Он подходит для удаленной стороны - он может использовать
tty telnet-сессии; но вот для локальной машины он никак не подходит - он не
может запустить telnet-соединения; должен существовать какой-то обходной
путь.
Telnet работает почти правильно с парой потоков, хотя он
все-таки настаивает на выполнении ioctl с tty, с которым он
взаимодействует; использование telnet без tty тоже не совсем правильно,
потому что на медленных компьютерах соединение будет прерываться (fwprc 0.1
работал правильно на P/MMX 233, один из 6 раз на 6x86-P200+, и вообще не
работал на 486dx2/66).
[Примечание: Если я найду того негодяя (возможно он из фанатов MULTICS, да
и в UNIX должны были найтись пара недоумков, скопировавших глупую идею),
который изобрел принцип "tty"-устройств - запись и чтение производятся с
одним "псевдо"-файлом, вместо того, чтобы иметь одну чистую пару потоков -
Я его задушу!]
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
Виртуальные VPS серверы в РФ и ЕС
