MQL: segurança vs oportunidades

 

Analisando os meus anos de experiência com MQL e tentando adequá-la às minhas necessidades, percebi
O obstáculo mais frequente, que apareceu de tarefa em tarefa, foi uma troca de informação nos dois sentidos.

É simples: o antigo machado de MQL - só há uma forma de obter informações do Expert Advisor, ou seja, ficheiros sobre o hardware. Que, pelos padrões actuais, são as ferramentas primitivas do trabalho árduo do programador.
A realização deste facto não é demasiado pequena para compreender a direcção do desenvolvimento necessário.

E quanto código foi empurrado em busca de outras variantes de transmissão de informação!
Mas todas elas se resumem ao uso de ferramentas não-MQL. Infelizmente.

Troca de informações entre terminais e entre terminais e outras aplicações, envio de dados para um site, envio de informações para agentes ou de agentes para a EA - todos nós, caros utilizadores e programadores, podemos continuar esta lista.
Ao longo dos anos da nossa prática activa em MQL, quase todas as ferramentas de sistema possíveis foram adaptadas e testadas de novo:
- envio legal de correio, FTP, Mensagens Push
- ficheiros fora da pasta do terminal
- cartografia
- tubos
- tomadas

Os tubos são dados pelos criadores como uma tecnologia de troca de informação, mas por alguma razão são utilizados de forma truncada. As tubagens em MQL podem ser apenas do lado do cliente.

Estou surpreendido e tenho uma pergunta: porque é que só está do lado do cliente? É uma coisa de "uma perna negra"...
Tentando analisar esta limitação em termos de segurança, cheguei à conclusão de que não, o MQL server-pipe não tem qualquer efeito sobre a segurança. Uma vez que na minha versão actual o ficheiro exe do servidor auto-escrito é uma obrigação, não é seguro da mesma forma.
Talvez os criadores sejam demasiado preguiçosos? Na verdade não, eles apoiam-nos e desenvolvem-nos activamente...

-----

Há mais de um ano, Renat recomendou-me a port system winsock2 à MQL sem qualquer dll autoescrita (descrevi parcialmente como foi feito no artigo).
O código do MQL foi utilizado para fazer o upend do servidor + convertê-lo para o modo non-blocking + sondá-lo com temporizador de milissegundos (ainda assim na altura) de aceitar clientes + servi-los com o mesmo temporizador...

Renat disse na altura que, por "algumas" razões técnicas, isto era impossível. Mas acabou mesmo pelo oposto - tudo é possível e até mesmo o máximo possível!

Fez o servidor especializado directamente no gráfico, e ligou-se a ele a partir de qualquer computador na Internet - foi um avanço na técnica de funcionamento. Apontamento directo para ligação p2p, copiadores, sincronizadores, optimizadores, tarefas distribuídas, etc.

-----

Assim, voltando à minha pergunta sobre o desenvolvimento futuro do MQL, gostaria de a resumir desta forma:
Caros programadores, quando é que eu e o senhor daremos o passo do ficheiro antigo para uma ferramenta muito mais acolhedora, rápida e melhor - como uma tecnologia cliente/servidor?
Afinal de contas, o facto de ter dado pips aos clientes - isso significa automaticamente uma saída irrevogável da caixa de areia. Para tubagem de clientes em MQL implica tubagem auto-escrita do servidor, e está simplesmente fora dele.

PS.
Recentemente, como exemplo, foi levantado um tópico importante sobre a transferência de informação para agentes locais. Esta é outra chamada de despertar para si. Existem muitos desses tópicos e cada utilizador de MQL tenta resolvê-los de acordo com os seus conhecimentos.

Até agora não tinha compreendido a importância das ferramentas incorporadas na MQL para a troca de informação. Ainda não considerei o nível de requisitos.
Mas a análise de tais tópicos leva-me a uma conclusão clara - a troca de informações nos dois sentidos tem de ser feita!
Chegou o momento de recolher as pedras.

 
Subscrevo cada palavra.
 

Bom posto.

Renat vem normalmente a estes e diz que não consegue ver merda alguma e não entende da sua caixa de areia.

 
TheXpert:

Bom posto.

A estes vêm normalmente Renat e dizem que não vêem merda alguma e não compreendem da vossa caixa de areia.

Vamos esperar para ver.

ZS. Seria uma boa ideia fazer uma votação, não é uma pergunta ociosa.

ZS.ZS. Isto também se aplica ao Quarteto.

 
Já não era sem tempo...
 

A necessidade existe. E tal necessidade surge nas tarefas mais interessantes.

Fora de tópico, mas aproveitando a oportunidade, lembro-vos queResourceRead() foi em tempos prometido.Permitiria pelo menos aos peritos no interior do terminal trocar grandes quantidades de informação.

 
Como habitualmente, só se fala dos benefícios, ignorando completamente a segurança e as consequências. Além disso, a avaliação é feita apenas por um comerciante.

Qualquer revelador pode fazer qualquer solução por si próprio e transmitir de/para os seus terminais o que quiser. Mas não vamos fazer um buraco padrão, e não vamos fazer um buraco padrão global para 100% de todos os terminais. Além disso, não faremos ligações http de rede.

Nas próximas construções, haverá um novo método de interacção de rede personalizado com servidores comerciais, que permitirá aos corretores e desenvolvedores no MQL4/5 alargar a funcionalidade do terminal com suporte em servidores onde os manipuladores estão escritos em plugins.
 
Renat:
Nas próximas construções, haverá um novo método de interacção de rede personalizado com servidores comerciais que permitirá aos corretores e desenvolvedores em MQL4/5 estender a funcionalidade do terminal com suporte em servidores onde os manipuladores são escritos em plugins.
Mais detalhes sobre este ponto?
 
Atrevo-me a dizer que a organização do peyem bidireccional fará essencialmente do MT5 apenas uma ligação de transferência entre aplicações de terceiros e a troca. Neste caso, o aparecimento dos chamados novos programas independentes, add-ons sobre o terminal - de facto, os concorrentes directos da MQ parasitando as suas tecnologias e prometendo tornar o trabalho nos mercados financeiros "mais conveniente e produtivo" por apenas 29,95 dólares por mês são inevitáveis.
 
C-4:
Atrevo-me a dizer que a organização do peiime bidireccional fará essencialmente do MT5 apenas uma ligação de transmissão entre aplicações de terceiros e a troca. Neste caso, o aparecimento dos chamados novos programas independentes - adaptações ao terminal - de facto, os concorrentes directos da MQ parasitando as suas tecnologias e prometendo tornar o trabalho nos mercados financeiros "ainda mais conveniente e produtivo" por apenas 29,95 dólares por mês é inevitável.

Exactamente.

Mais importante ainda, cada primeiro programa será essencialmente spyware e recolherá muita informação crítica sobre contas, história e definições de contas. Desenvolvedores terceiros não têm travões nesta questão - eles não se importam com a segurança e a destruição da privacidade. Eles "não compreendem" genuinamente qual é o problema. Quando os apanhamos, eles rejeitam até ao último minuto, e depois resume-se a "estás a tirar-nos o nosso dinheiro, que nos custou muito dinheiro, enquanto nós te temos ajudado durante tantos anos". Isto para não mencionar as violações dos nossos direitos, licenças e pirataria informática.

Já vimos o suficiente deste tipo de "ajuda" e por isso estamos a apertar as regras.

 
FAQ:
Pode desenvolver este ponto?

Um corretor (ou um terceiro desenvolvedor) pode escrever um programa em MQL4/MQL5 puro e incluí-lo legalmente no seu pacote de distribuição (inclui-lo-emos no seu pacote de distribuição) e criar gráficos predefinidos com indicadores e EAs predefinidos. Não somos contra a inclusão de programas personalizados (baseados apenas em código MQL4/MQL5 puro, sem DLL e sem fanatismo) na sua própria distribuição de corretores.

Este programa pode implementar a sua própria funcionalidade, suportada pelo servidor de negociação. Para este fim, é escrito um plugin para MetaTrader 4/5 Server API para o servidor, que pode receber e responder a pacotes de comandos personalizados enviados de programas MQL4/MQL5 no terminal.

Assim, um corretor pode expandir as capacidades do terminal sem sacrificar a segurança dos seus clientes e sem violar as licenças do sistema. Os promotores terceiros têm uma nova oportunidade de vender as suas soluções legalmente e internamente.

Razão: