[GTER] RES: Solução para acesso discado

[Rafael Cresci]

OK, se é pra radicalizar:

http://www.synchro.net/
http://www.bbbs.net/
http://www.elebbs.com/

Estes aí ao menos já dispensam o uso de driver FOSSIL (ou são compatíveis com OSes mais modernos com o http://www.netfoss.com/ ) e já se integram por telnet também, que é um passo intermediário ;-)

(Aliás o NetFOSS dispensa a plataforma de BBS se for só para rodar o programa remotamente como terminal burro; e ainda faz virtual modem via TCP/IP/telnet)

Em termos de drivers multisseriais:
http://pcmicro.com/modempooling/

Em termos de equipamento, isso varia conforme a sua central telefônica aí; se for tudo analógico é usar as velhas multisseriais (que tenham driver para OS/2, ô louco!) e desenterrar os US Robotics véios de guerra; se for central digital, e vc recebe as linhas em múltiplos E1s, tem aqueles console servers da Cyclades e etc que aí já não era mais do meu expertise (v.90 digital era muito pra mim na época, eu era aborrescente e tinha mais o que estudar :-)

[]s
Rafael Cresci

PS: Você consegue a sinalização via telnet, usando estes dispositivos de virtual com ports, netFOSSIL e/ou software de BBS (com doorway, etc). Não precisa necessariamente da infra ser serial puro.

On Apr 20, 2012, at 2:07 PM, Lucas Willian Bocchi wrote:

> Pois é Galera... Isso é coisa batida já aqui pra mim.
> 
> Vejam bem
> 1) O Software ainda roda em DBF (existe um "importador" para um banco Firebird)
> 2) O Software roda em uma plataforma OS/2
> 3) O Software é um lixo e PRECISA da sinalização, não tem jeito.
> 
> Mas eu agradeço meu povo todas as idéias de vocês. O negócio é
> procurar uns equipamentos multiseriais conforme indicados por vcs e
> pau na viola. Quem sabe um dia o cara acorda animado e arruma essa
> bagunça.
> 
> Valeu povão
> 
> Em 20 de abril de 2012 14:05, Toledo, Luis Carlos
> <lscrlstld at gmail.com> escreveu:
>> 
>>> Oi Bruno, bom dia?
>>> 
>>> O problema é que eu preciso das sinalizações de controle (DTR,
>>> CTS/RTS), paridade, etc.
>> ...
>>> 
>>> O problema disso é você ter que manter toda uma estrutura telefônica
>>> para atender essas chamadas, ter espaço físico pra manter isso... Sei
>>> lá se o cara faz a conta desse gasto. E também agora o cara vai ter o
>>> custo do legado desse negócio... É pura BUCHA.
>>> 
>> 
>> Nesse cenário, duas sugestões que na verdade é o que todo mundo faz com
>> "maquininhas tipo de cartão de crédito"
>> - Usar rede de pacotes, (aka RENPAC) onde terminal disca para a rede X.28 e
>> os pacotes virão ao ponto concentrador por uma X.25. As redes de pagamento
>> fazem isso hj em dia.
>> - Usar rede de comutação de circuitos, onde vc pode alugar a rede dial-up de
>> a operadora entrega em IP para você. Os provedores faziam isso antigamente.
>> 
>> Em ambos os casos os sinais de controle de hardware irão ficar na rede da
>> operadora, chegando até vc somente os pacotes de dados ou datagramas.
>> 
>> Mas esse mesmo problema de não enxergar diretamente os sinais de controle
>> você terá em qualquer concentrador de acesso.
>> 
>> O único jeito da sua aplicação saber dos sinais de controle é ter um modem
>> conectado na serial do servidor, que no caso agirá como concentrador de
>> acesso.
>> 
>> O único diferencial que vejo na solução é que seu cliente quer usar uma
>> tecnologia que foi utilizada na década de 90.
>> 
>> Abs Toledo
>> 
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter