Múltiplas Conexões Tcp/ip

[leo.mck2]

Olá, implementei uma solução de emissão de NFe utilizando o ACBrNFeMonitor. O monitor fica no servidor e um aplicativo meu envia os comandos, via TCP/IP. Nas estações, uso C# para conectar no monitor e tudo funciona muito bem até que 2 estações tentem enviar comandos ao mesmo tempo.

O que acontece normalmente é isso:

 

Requisição 1 -> Conexão Socket 1 -> Escreve Comando 1 -> Lê retorno 1 -> OK!

 

Quando 2 estações enviam comandos simultaneamente, ao ler o conteúdo do socket, uma conexão "vê" os dados da outra. Exemplo:

 

Requisição 1 -> Conexão Socket 1 -> Escreve Comando 1 -> Requisição 2 -> Conexão Socket 2 -> Escreve Comando 2 -> Lê retorno 1 -> Resultado do Comando 2 -> Lê retorno 2 -> Não tem mais nada para ler.

 

A ordem dos acontecimentos pode variar, claro, mas o resultado é basicamente sempre o mesmo. Já vi outras pessoas () tendo dúvidas semelhantes, mas sem solução.

Alguém já desenvolveu alguma solução semelhante e tem alguma sugestão do que pode estar ocorrendo? Este tipo de cenário é suportado pelo monitor?

 

 

 

 

leo

[jorge andrade]

Eu ainda não implementei o tráfego de informações através do tcp/ip, porém achei que o fato do próprio escapsulamento do protocolo permitsse  identificarmos o retorno pela origem de envio, ou seja, se a estação 1 enviou um comando, esta deveria receber a pela encapsulamento da origem, ou seja no endereço de retorno de quem enviou?

Será que pensei bobagem?

 

[]s,

[leo.mck2]

Jorge, obrigado pelo comentário, seu raciocínio está perfeito, é exatamente isso o que eu também esperava que aconteceria. Como não obtive resposta aqui, resolvi montar uma VM de compilação do ACBr, com delphi e tudo mais para dar uma olhada em como o programa funciona. De fato, não funciona do modo que pensamos, o programa tem uma variável global para a conexão e a cada novo "connect", ele substitui esta variável.

Não trabalho (mais) com o delphi e não conheço bem o Indy (que tive que atualizar para a versão 10) então não sei se há uma solução mais elegante nele mesmo (e suponho que haja, já que o componente TIdTCPServer deles me pareceu ser um componente bem completo) mas criar uma solução em que haja uma lista de conexões não me parece muito complexo. O problema é saber se o resto do código é thread-safe, podem haver outras armadilhas ali e por isso o programador do monitor decidiu manter apenas 1 conexão.

 

 

leo

[adilsonpazzini]

Pode ser por utilizar o mesmo componente pra gerar e enviar a NFe , pois imagina se dois usuarios que estao tentando criar e enviar suas notas ao mesmo tempo , talvez um comando como por exemplo acbrnfe.notasfiscais.clear; , mata-se o carregamento do outro usuario , talvez se fosse criado a a classe da nfe em tempo de execução , mais tambem vejo que o TCP processa em fila , igual o arquivo , o que nunca testei foi ver se na hora da resposta cai pro IP que solicitou , mais tambem ja tive problemas de pegar resposta de outro IP ,,, vou tambem aqui fazer mais testes pra ver se consigo produzir esse mesmo problema  .

[leo.mck2]

Muito bem lembrado Adilson, mesmo se mantivesse múltiplas conexões, possivelmente um comando poderia influenciar no outro, como no caso do NotasFiscais.Clear(). Isso dá a imaginar que seria mesmo necessário criar um TACBrNFe para cada requisição mas imagino que as alterações necessárias para isso descaracterizariam o programa no que concerne o processamento via arquivos. Em último caso então, penso que fazer o controle do lado do meu aplicativo para enfileirar as requisições e mandar uma por vez ao ACBr seja o melhor, ao menos por ora.

 

Obrigado pela contribuição;

 

leo

[jorge andrade]

Bom pessoAL, como nenhum dos desenvolvedores se manisfestou em relação ao assunto, é pq ele deve ser complicado, embora eu ainda utilizo o modo texto e uso mascara no arquivo de comando de entrada e saída no formato ????????.TXT, onde somente ler a resposta a estação que enviou o conteúdo próprio ou seja, quem enviou 99999999.TXT, irá ler a resposta de 99999999.TXT.

 

[]S,