Ir para conteúdo
  • Cadastre-se

leo.mck2

Membros
  • Total de ítens

    3
  • Registro em

  • Última visita

Tudo que leo.mck2 postou

  1. 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
  2. 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
  3. leo.mck2

    Múltiplas Conexões Tcp/ip

    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
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...
The popup will be closed in 10 segundos...