Discussão do artigo "Comunicando-se com o MetaTrader 5 utilizando pipes nomeados sem DLLs"
Os tubos funcionam no testador?
Por que a comunicação entre diferentes terminais deve funcionar no testador?
Faça isso por meio de eventos, eles funcionam no testador.
Por que a comunicação entre terminais diferentes deve funcionar no testador?
faça isso por meio de eventos, eles funcionam no testador.
O que é por meio de eventos? Comunicação entre terminais?
;)
Os pipelines nomeados funcionam em agentes locais, mas são desativados em clades.
Ou seja, tanto os testes individuais quanto os agentes locais em massa podem se conectar a um servidor pip de terceiros (não apenas local).
Por que não? Vale a pena tentar, não sei por quê. :)
O que, por meio de eventos? comunicação entre terminais?
;)
Se uma pessoa precisa de comunicação entre programas no testador, então a tarefa de transferência de dados entre programas em um terminal é óbvia, e isso pode ser feito por meio de eventos, omitindo todo esse absurdo, minha resposta é bastante lógica.
Em uma rápida olhada, há duas maneiras de usá-lo:
- copiar operações de uma conta para outra (bem como do MetaTrader 5 para o MetaTrader 4 ou vice-versa)
- obter resultados de otimização em tempo real com processamento dinâmico em outro aplicativo
E artigos sobre esse tópico serão interessantes.
Em uma rápida olhada, há duas maneiras de usá-lo:
- copiar operações de uma conta para outra (bem como do MetaTrader 5 para o MetaTrader 4 ou vice-versa)
- obter resultados de otimização em tempo real com processamento dinâmico em outro aplicativo
E artigos sobre esse tópico serão interessantes.
Infelizmente, isso só é possível para aqueles que sabem programar em C para Windows, porque:
Observe que esse é o suporte ao cliente, e os conectores do servidor não podem ser criados no terminal.
Ou seja, em tecnologias cliente-servidor, dois clientes não poderão se ver sem a mediação do servidor. Analisei a questão da criação de canais nomeados em outras linguagens de programação, mas, infelizmente, na maioria delas é possível criar um cliente para Windows por meios padrão, embora os canais para Unix sejam criados em quase todos os lugares sem nenhum problema.
Precisamos de gateways na forma de shells EXE, que possam conectar dois canais nomeados full-duplex de acordo com o algoritmo:
- Criar dois canais nomeados A e B
- Criar o primeiro subprocesso que escuta o canal A para uma conexão.
- Depois que um cliente que estiver aguardando uma mensagem se conectar ao canal A, crie um segundo subprocesso que escute o canal B para uma conexão.
- O primeiro subprocesso é ativado para transferir um fluxo de bytes em um loop do canal A para o canal B
- Assim que um cliente se conecta ao canal B, o segundo subprocesso é iniciado para ler o fluxo de bytes em um loop do canal B para o canal A.
- O segundo cliente começa a transmitir a primeira mensagem do canal B para o canal A.
- e assim por diante, até que algum cliente se desconecte, após o que os dois canais são destruídos e voltamos ao ponto 1. 1
É claro que, nos scripts MQL de tarefa única, o full duplex não é necessário, porque os clientes não podem receber e transmitir informações de forma assíncrona. Mas o half-duplex é adequado apenas para os casos em que o servidor conhece o protocolo de troca e pode calcular facilmente onde termina a recepção-transmissão de um cliente para outro, a fim de mudar para o modo oposto. Se ele não souber disso, porque não tem habilidades telepáticas, e isso for conhecido apenas pelos clientes que estão trocando entre si usando o protocolo conhecido apenas por eles, será necessário um full duplex com dois subprocessos. Esse gateway é conveniente porque cada cliente tem apenas um canal de comunicação com outro cliente e a sequência de conexão do lado do cliente não desempenha nenhum papel, se ele certamente verificará a possibilidade de conexão no ciclo inicial. O algoritmo de gateway exclui a possibilidade de conexão do cliente, que é o primeiro, de acordo com o protocolo, a transmitir uma mensagem antes que o segundo cliente se conecte, e a transmissão para o vazio não ocorrerá.
Teoricamente, como o número de canais nomeados é ilimitado, seria possível criar um gateway simplex de tarefa única de acordo com o algoritmo:
- Um primeiro canal nomeado é criado para transmissão do gateway para o cliente
- Após o primeiro cliente ter feito uma conexão, um segundo canal é criado para receber mensagens do cliente
- Depois que o cliente transmissor se conecta ao segundo canal, o processo faz um loop do fluxo de bytes do canal receptor para o canal transmissor.
- Assim que um cliente se desconecta, removemos os dois canais e voltamos à etapa 1.
Nesse caso, você precisará de dois gateways desse tipo para conectar dois clientes em half-duplex ou um se apenas o simplex for usado. A desvantagem em relação a um gateway full-duplex é que, nos scripts MQL, você terá de escrever dois canais (para recepção e transmissão) e neles também observar rigorosamente a sequência de conexão: primeiro para recepção e depois para transmissão (caso contrário, o segundo canal nunca será criado). O algoritmo desse gateway também exclui a possibilidade de conexão de um cliente, que é o primeiro, de acordo com o protocolo, a transmitir uma mensagem antes que o segundo cliente se conecte, e a transmissão para o vazio não ocorrerá.
Naturalmente, os gateways devem oferecer a possibilidade de configurar os nomes dos canais dependendo da sequência de recebimento-transmissão e conexão dos clientes, por exemplo, por meio da linha de comando na inicialização.
Se alguém que programasse em C criasse esses gateways e os compilasse em EXEs e os publicasse aqui, seria fácil criar conexões entre scripts, Expert Advisors e indicadores usando ferramentas MQL5 padrão sem a necessidade de usar outras linguagens de programação.
Teoricamente, você também pode escrever um artigo sobre como conectar corretamente os clientes com esses gateways, para não criar servidores em outras linguagens além da MQL (provavelmente não sou o único que não consegue programar em C, certo?) com exemplos específicos em coautoria com um programador C. Ou seja, de mim o texto do artigo e exemplos em MQL, e do programador C-sh fontes de gateways em C e EXE-shniki. A taxa é compartilhada.
O servidor é simples, todo em código-fonte, incluindo o arquivo exe compilado no diretório /release. Os testes podem ser repetidos facilmente.
A propósito, os exemplos mostram uma troca full-duplex, em que você não precisa esperar por ninguém.
O servidor é simples, todo em fontes, incluindo o arquivo exe compilado no diretório /release. Os testes podem ser repetidos facilmente.
Essa não é a questão. Tentei executar seu exemplo. Ele funciona. Mas ele não tem utilidade, ou seja, eu o testei e é tudo, ele pode ser excluído porque não é mais necessário.
Por um lado, você se livrou da dll, mas, por outro lado, novamente, para o uso do aplicativo, você precisa de muletas em outras linguagens de programação.
A desvantagem do método proposto é que ele é adequado apenas para programadores que desenvolvem aplicativos em linguagens que não sejam MQL e que ofereçam suporte à API do Windows. Ou seja, o exemplo proposto não é universal e não pode ser adaptado a outras tarefas sem modificações. E todos têm tarefas diferentes. E isso significa que os usuários terão que criar até mesmo uma troca elementar de informações entre dois scripts para estudar, além do MQL, outra linguagem, de modo que, nela, criem um servidor no qual seja necessário escrever parte da lógica relacionada ao protocolo de troca.
Proponho criar gateways uma vez, compilar e disponibilizar para todos, de modo que qualquer usuário possa criar conexões, usando apenas as ferramentas MQL padrão.
Por exemplo, para mim, não faz diferença se os arquivos brutos abertos ou fechados estão em C. Porque eu não escrevo nada em C, e levará tempo para resolver os voos. Não consigo nem mesmo compilar esses mesmos arquivos brutos. E no Java puro, assim como em muitas outras linguagens de programação, você só pode criar uma conexão de cliente por meio de fluxos de arquivos usando ferramentas padrão. Se houvesse um gateway que conectasse dois canais nomeados, pelo menos por simplex, não haveria problemas. Eu escreveria o protocolo de troca nos clientes, me conectaria por meio de alguns gateways, depuraria e tudo funcionaria. Ou seja, não há necessidade de projetar e criar um servidor separado para cada tarefa.
E no momento, ou seja, sem gateways, muitas pessoas terão que instalar um ambiente de desenvolvimento para C, aprender uma nova linguagem de programação, etc., etc.
O gateway não dá a mínima: o que ele recebe de um cliente, ele envia para outro. A lógica é burra, mas permite unir dois clientes sem nenhuma muleta adicional e dança com pandeiro, ou seja, é universal e independente do protocolo de troca de informações e do conhecimento da linguagem C.
Aqui, como se diz, quem tem comida não entende quem tem fome. Aqueles que desenvolvem algo em C provavelmente não verão nenhum problema. E para o restante de nós, podemos lidar com esse sistema como quisermos.
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso
Novo artigo Comunicando-se com o MetaTrader 5 utilizando pipes nomeados sem DLLs foi publicado:
Muitos desenvolvedores encontram o mesmo problema - como chegar ao sandbox do terminal sem utilizar DLLs arriscados.
Um dos métodos mais fáceis e seguros é utilizar pipes nomeados padrão que funcionam como operações de arquivo normais. Eles permitem que você organize a comunicação cliente-servidor interprocessadores entre programas. Embora já exista um artigo publicado sobre este assunto - Uma solução livre de DLL para comunicação entre os terminais MetaTrader 5 utilizando pipes nomeados - que demonstra a habilitação de acesso para DLLs, utilizaremos os recursos seguros padrão do terminal do cliente.
Você pode encontrar mais informações sobre pipes nomeados na biblioteca MSDN, mas iremos direto a exemplos práticos em C++ e MQL5. Implementaremos o servidor, cliente, troca de dados entre eles e, em seguida, faremos uma comparação de desempenho.
Autor: MetaQuotes Software Corp.