(M)  s i s t e m a   o p e r a c i o n a l   m a g n u x   l i n u x ~/ · documentação · suporte · sobre

  Página seguinte Página anterior Índice

118. Entendendo o problema

Entender o problema é a metade do caminho para resolvê-lo.

118.1 Dando nomes às coisas

Para que este programa funcione para você, há que se ter uma idéia de como ele funciona, pois se alguma coisa falhar, se terá uma idéia de onde procurar as causas.

O primeiro passo em direção ao entendimento do problema é dar um nome aos conceitos relevantes.

Por isso nós chamaremos aqui de "local" a máquina que inicia a conexão, bem como os programas e arquivos daquela máquina. Por outro lado chamaremos de "remoto" o que estiver do outro lado da conexão.

118.2 O Problema

O objetivo é conectar a entrada e saída de um emulador IP local para a saída e entrada de um emulador IP remoto respectivamente.

Os emuladores IP interagem somente com canais de comunicação como dispositivos diretos (como o caso comum do pppd) ou o "terminal atual". O caso anterior obviamente não acontece com as sessões telnet. O último é complicado, porque quando se lança o emulador local a partir da linha de comando, o terminal atual é ligado à linha de comando do usuário e não à uma sessão remota. Devemos abrir uma nova sessão (local ou remota) num novo terminal, sincronizar o lançamento e a conexão dos emuladores IP nos dois lados, pois a menor parcela de saída de lixo de uma sessão poderá ser entendida como comandos na outra sessão, o que recursivamente produziria mais lixo.

118.3 Dificuldade adicional

Para facilitar o uso, o emulador IP local tem que prover um IP para o kernel de rede, ou seja habilitar o pppd. Porém o pppd é limitado para só aceitar dados através de arquivos /dev ou através do terminal em uso. Ou seja, deve ser um tty e não um par de conectores. Isto é ótimo para o pppd remoto se houver, pois ele pode usar o tty das sessões telnet, mas o pppd local não pode lançar a sessão telnet para conectar-se, conseqüentemente deve haver algum tipo de invólucro ao redor dele.

O telnet se comporta quase corretamente com um par de conectores, exceto que ainda insistirá em executar controles de entrada e saída no terminal atual, com o qual interferirá. Usar telnet sem um tty também causa condições de uso intenso de recurso, de maneira que toda a conexão falhará nos computadores "lentos". (fwprc 0.1 funcionou perfeitamente num Pentium MMX 233, uma vez em 6 num 6x86-P200+ e nunca funcionará em um 486dx2/66).

[Nota: se eu encontrar o autor (provavelmente uma cara da MULTICS , embora tenha havido pessoas de UNIX tolas o suficiente para copiar a idéia) que inventou o princípio dos dispositivos "tty" pelos quais se pode ler e escrever um "mesmo" pseudo arquivo, ao invés de ter pares de conectores, eu o estrangulo!]


Página seguinte Página anterior Índice