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

 
Sobre o assunto, estou interessado em opções para sincronizar (transmitir ordens) os terminais
- localmente
- remotamente

Estamos planejando fazer tudo de uma vez em um servidor - muitos clientes.

Teremos de prestar atenção a aspectos como
- a opção de link (arquivos, memória para um local; soquetes, http, servidor intermediário, etc., para um remoto)
- sem carga no canal de comunicação (especialmente para sincronização remota)
- segurança em caso de falha (restauração do canal em caso de sua perda)
- Reinicialização do próprio Expert Advisor em caso de falha de um terminal/CA
- Nenhuma duplicação/ nenhuma eliminação de negócios se a conexão for perdida/restaurada
etc.

Você também precisa considerar duas ideologias
- sincronização no nível de disponibilidade do pedido
- sincronização no nível de envio de sinais para abrir/fechar ordens

descrever as vantagens e desvantagens desta variante para cada uma de nossas propostas.

Eu gostaria que a discussão nos ajudasse a encontrar a melhor solução para a confiabilidade/simplicidade do sistema.

Eu farei a codificação e os testes.

Os resultados podem ser postados em base de código por acordo.
 

Ok. Para começar, precisamos dividir as tarefas(tipo de especialista) em um comercial (via rede), e uma variante nocional não comercial (dentro do mesmo sistema OP).

Variante de rede - sem ambigüidade através de servidor adicional, para segurança e gerenciamento de clientes.

Intra-sistema - comunicação: mapeamento, por causa da velocidade e confiabilidade.

Como o terminal vai segurar a libc até que ela caia ou feche, ele será uma indicação do estado do próprio MT (escravo).

E o protocolo será algo parecido com isto :

O mestre cria um mappu nomeado (cujo nome é conhecido por todos os escravos), e espera que eles sinalizem para iniciar o caminho, este será o cabo da janela do conselheiro (escravo).

Após a troca dos sinais, outro é criado onde os sinais comerciais são passados e ao mesmo tempo há um comando para cada escravo para atualizar a janela.

Após o sinal ser executado, o escravo deve informar sobre sua execução ou será considerado como congelado e medidas são tomadas para trazê-lo à tona.

Se o escravo descarregou (corretamente), ele deve informar de volta.

Qualquer um dos escravos pode, por sua vez, monitorar o status do mestre e tomar as medidas necessárias para levantá-lo ou emitir um alarme.

Geralmente mais ou menos o mesmo.

Para a comunicação em rede, ver mais adiante.

 
Faça uma versão comercial e empurre-a.
 
TheXpert:
Faça uma versão comercial e empurre-a.

Você está falando comigo?
 
FAQ:
Você está falando comigo?
Se você é o iniciador do tópico, sim :)
 
FAQ:

Uma vez executado o sinal, o escravo deve comunicar a execução, ou é considerado congelado e são tomadas medidas para levantá-lo.

Se for descarregado (corretamente), o escravo deve relatar o fato.

Estas linhas me lembram da necessidade de discutir dois modos de operação

sincronização de pedidos no nível de ordem mestre->cliente. E sincronização de sinais no nível mestre->cliente (precisamos de um banco de dados de sinais, reconhecimento de recebimento do cliente, etc.)

Penso que também deveríamos decidir o que seria mais confiável e menos complicado em termos de sincronização e perda de sinais.

 
TheXpert:
Faça uma versão comercial e empurre-a.

Eu não quero empurrar nada e não o farei. Eu estou fazendo um meio, não um fim. Eu faço isso para todos.
 
sergeev:

estas linhas me lembraram da necessidade de discutir dois modos de operação

sincronização de pedidos no nível de ordem mestre->cliente. E sincronização do sinal do mestre de nível - sinal do cliente (há necessidade em um banco de dados de sinais, confirmação de recebimento do cliente, etc.)

Penso que também deveríamos decidir o que seria mais confiável e menos complicado em termos de sincronização e perda de sinais.


Não é necessário complicar as coisas, basta enviar um sinal de controle ao cliente em um determinado intervalo (digamos, uma vez por segundo), e se ele não respondeu, então aja.
 
sergeev:

Eu não quero empurrar nada e não o farei. Eu faço os meios, não o fim. Eu faço isso para todos.

Eu respeito pessoas assim, continuem assim!!!
 
Não há necessidade de complicar as coisas, basta enviar um sinal de controle para o cliente em um determinado intervalo (digamos, uma vez por segundo) e se o cliente não responder, então aja. <br / translate="no">
é só isso que você está falando de um sinal de servidor para cliente? você precisa de um mecanismo detalhado de como o sinal vive e é transmitido para o receptor. Nunca tinha encontrado um sistema desse tipo antes. Somente cópia de pedido.
 
Está tudo resolvido, mas desculpe não de graça.
Razão: