• Ajuda: RENPAC X.25

----- Original Message -----
From: J. R. Smolka
To: Celld-group@yahoogrupos.com.br
Sent: Monday, April 14, 2008 9:27 AM
Subject: RE: [Celld-group] Ajuda: RENPAC X.25

At 11:25 11/4/2008, you wrote:
Smolka,
Por favor me corrija se estiver errado, mas seja lá qual for a solução que seja adotada do lado da rede do Tadashi, terá que também ser adotada do lado do cliente dele, não é?
Por exemplo, se encapsulamos IP em X.25 de um lado, o outro lado terá desencapsular (e vice-versa).
Se no PVC de um lado colocamos um GW, do outro deve haver um GW similar para poder ler o payload do quadro X.25 e jogar para a LAN.
Portanto talvez a grande pergunta é: o que o cliente do Tadashi já tem/usa do lado de lá?
Pelo que ele diz o cliente dele opera já com X.25, portanto ele já tem um GW ou um Roteador...
Não seria o caso do Tadashi seguir a mesma solução que o cliente já usa?
O que vc acha?
Abs,
Rodrigo.

Rodrigo,
Em um ponto básico vc está certo: as duas partes tem que usar o mesmo modo de comunicação entre suas aplicações para que tudo funcione a contento. Só que vc parte da suposição que existe uma LAN e TCP/IP do outro lado. O que não parece ser o caso.

O problema do Tadashi, se é que entendi direito, é estabelecer comunicação entre uma aplicação dele e outra aplicação, que roda em uma máquina de uma instituição financeira (banco, cartão de crédito, seguradora, whatever...). Só que a tal IF - o que não é incomum - estruturou a aplicação dela em cima de X.25 nativo, com primitivas proprietárias no protocolo de camada 7 (aplicação), e diz a quam quiser comunicar-se com ela que existem dois jeitos de fazer isto: o jeito dela e o jeito errado. Tenho a forte suspeita que seja assim, porque já passei por problema parecido alguns anos atrás. Minha única surpresa, neste caso, é que nada tenha mudado de lá para cá.

Isto faz sentido hoje em dia? Acho que não. Conexões IP sobre frame-relay dão o mesmo efeito, são mais fáceis de programar - tanto para a IF quanto para seus parceiros, são tão seguras quanto o X.25, e são suportadas nos ambientes mainframe IBM que a maioria das IF ainda usa. Mas uma boa parte das IFs ainda age desta maneira. Sei lá... Talvez eles não tenham ainda dominado as APIs entre NCP, CICS, VTAM e TCP/IP no z/OS, ou quem sabia fazer isso já se aposentou e não treinaram mão-de-obra substituta. :-D Seja lá qual for o motivo, o problema existe de fato.

É por isso que eu disse no meu post sobre as duas formas de solução: programação nativa X.25 (horrível) ou colocar um gateway X.25/IP entre a aplicação do Tadashi e a aplicação da IF. Neste segundo caso, a aplicação dele precisa emular as primitivas do protocolo de aplicação da IF usando a API de sockets (piece of cake), e o gateway tem de ser programado para "trasladar" o payload dos pacotes TCP/IP ou UDP/IP vindos da aplicação dele para os pacotes X.25 (no formato esperado pela IF), e vice-versa.

[ ]'s
J. R. Smolka

Nota da Coordenação:
Este "post" no BLOCO - Blog ComUnitário, pode conter material que complementa o assunto:

------------------------------------------------------

----- Original Message -----
From: J. R. Smolka
To: Celld-group@yahoogrupos.com.br
Sent: Thursday, April 10, 2008 5:00 PM
Subject: Re: [Celld-group] Ajuda: RENPAC X.25

At 08:55 10/4/2008, you wrote:

Eu sei que o Frame Relay é melhor que o X.25, acontece que o nosso cliente opera com esse tipo de rede. Muitas entidades financeiras, infelizmente, ainda continuam a usar a rede X.25. E por ser uma tecnologia antiga, não encontro muitas informações a respeito de sua implantação, o que torna meu trabalho um poucocomplicado.
Quanto à aplicação, temos feito grandes esforços para que ela seja a mais enxuta possível.
O problema se encontra a partir da criação dos sockets do nosso aplicativo em diante... pelo pouco que estudei sobre X.25, parece que existem 2 maneiras de se implementar, mas ainda não sei qual a melhor solução:

- se já realizo uma comunicação X.25 saindo direto do aplicativo (o que torna complicado, pois terei de descer muito baixo nível e programar em SO para configurar essa conexão com a rede X.25)

- ou se faço uma comunicação convencional Ethernet TCP/IP (a mais fácil de implementar) e utilizo um roteador CISCO 2501 que tratará a conexão X.25 (segundo a dica de Rodrigo Garcia Corbera encaminhada a mim).

Tadashi,

Já tive de conviver com um problema semelhante ao seu no passado. Infelizmente, se entendi direito a sua explicação, a solução não é tão fácil.

O problema é comunicação aplicação a aplicação em X.25 nativo, certo? Então não se trata de encapsular tráfego IP em um canal X.25 (o que, como foi dito, tem uma performance sofrível). Vejo 2 hipóteses: uma ruim e outra melhor. Comecemos pela ruim.

Vc pode usar um roteador com suporte full a X.25 (no mesmo pé de igualdade do TCP/IP, OSI, etc.) e programar a comunicação da sua aplicação diretamente em X.25. Provavelmente vc vai ter algumas dores de cabeça, tipo: detalhes de configuração do roteador e encontrar uma API decente (que não é socket) para programar o acesso. Além disso, provavelmente a conexão do servidor de aplicação com o roteador não poderá ser LAN (estas coisas são tão velhas que talvez só exista suporte a conexões seriais). Eu só entraria neste caminho em último caso.

Agora a melhor: encontrar uma aplicação que funcione como gateway IP/X.25 (deve ser disso que o Wallace estava falando no e-mail dele). Neste caso:

a) A máquina onde roda o gateway é a "dona" da conexão X.25 (link e modem conectam-se nela, quase certamente em uma porta serial);

b) A sua aplicação pode ser programada normalmente com a API de sockets, estabelecendo uma conexão UDP ou TCP com o gateway, que converte o tráfego de pacotes IP para pacotes X.25 e vice-versa.

Para a solução 2 conheço um caso onde o gateway foi "enxertado" no próprio roteador (que era da Cyclades - o fornecedor não tinha conseguido fazer isto com equipamentos da Cisco). Se estiver interessado, me avise e vou garimpar no arquivo morto qual o nome da empresa que fez isto naquela época (sem garantias que ela ainda exista, ou ainda dê suporte a este tipo de solução).

[ ]'s
J. R. Smolka