Copiadora de transações/sinais altamente confiável (discussão ideológica e desenvolvimento) - página 2

Novo comentário
 
Integer:
Tudo já foi pensado, mas desculpe-me, não é desagradável.

Dima, eu sei, é claro, que também tenho tudo inventado e feito, tanto local como remotamente, em diferentes disfarces.

Mas eu só quero discutir este tema bastante hackney, que, em minha opinião, não foi levantado aqui neste contexto.


Se você tem algo a dizer sobre o assunto, então fale mais alto.

 

O cliente copia seus parâmetros e cria um pedido com um magik igual ao bilhete original. desta forma, contornamos a dupla configuração.

Depois disso, o cliente deve verificar o estado do pedido e relatar a execução (se houver algo a ser executado), ou sua vivacidade, se o pedido for um controle.

 
sergeev:

No início, tudo se resume ao próprio sistema de correio. Um servidor, muitos clientes. Se o sistema funcionar, você pode carregar o resto sobre este esqueleto.

Quando o cliente se conecta, ele envia um pedido de conexão, o servidor retorna uma assinatura em uma mensagem especial, pela qual ele controlará as respostas. A assinatura não é válida até que o cliente não a devolva com mensagem especial. Quando tudo está em ordem, é possível começar a se comunicar.

Portanto, tem assinaturas de cada cliente emitidas pelo servidor (portanto, não repetidas). O servidor envia mensagens com números de contador (deve armazenar logs de mensagens com alguma profundidade caso tenha que ser repetido), os clientes recebem mensagens numeradas e enviam cópias assinadas para o servidor. Desta forma, o servidor sabe qual cliente perdeu a mensagem e pode reenviá-la novamente. Após x repetição o servidor deixa de enviar esta mensagem, fecha a sessão com este cliente, e começa a esperar que o cliente solicite uma nova sessão.

 
Por que ter todo esse trabalho, a chave variável pode ser colocada na própria mensagem.
 
FAQ:

O cliente copia seus parâmetros e cria um pedido com um magik igual ao bilhete original. desta forma, contornamos a dupla configuração.

ok. esquema clássico.

Depois disso, o cliente deve verificar o estado do pedido e informar seu cumprimento (se houver algo a ser cumprido), ou sua vivacidade, se o pedido for um controle.

E para que serve fazer isso? O servidor ainda não pode afetar o cliente de forma alguma.
 
FAQ:
Por que tais complicações, a chave variável pode ser colocada na própria mensagem.
Então o servidor tem que enviar as chaves o tempo todo? isto aumentará o tráfego, mas e o tráfego, onde está a garantia de que a mensagem será recebida? e isto significa que o lado do servidor precisará do log de chaves variáveis para cada mensagem, o programador pode ficar confuso com tudo isto.
 
Urain:

No início, tudo se resume ao próprio sistema de correio.
É aqui que a criptografia é essencial; quando o cliente se conecta, ele envia um pedido de conexão

Mas diga-nos que tecnologia é utilizada para enviar e receber. Onde o servidor armazena os dados?

Acho que é um pouco difícil usar as assinaturas. É suficiente ter um login/password do cliente, emitido uma vez e verificado durante os pedidos.
 
sergeev:

OK. Esquema clássico.

Por que fazer isto? O servidor não pode afetar o cliente de qualquer maneira.

Por que não? Pode. Reinicie a exp, o terminal. Sem problemas.
 
sergeev:
Por favor, diga-me qual tecnologia é utilizada para enviar e receber os dados e onde o servidor os armazena.

Não acho que seja fácil com assinaturas. Basta ter apenas um login/password
O servidor envia os dados para o servidor ftp e os clientes os buscam de lá.
 
Urain:
onde está a garantia de que a mensagem será recebida?
Uma pergunta importante que decorre da resposta é qual método é usado para o intercâmbio de dados?
123456789
Novo comentário