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.