Quem já experimentou a subscrição de Sinais para se colocar na cauda dos participantes do ATC 2012? - página 5

[Andrey Khatimlianskii]

St.Vitaliy:

Pense também nas ordenhadoras.

Não se pode evitar reclamações das ordenhadoras, escrevi imediatamente sobre isso.

[Mikhail Antropov]

Alugar um Sinal é deflacionado...
Alguma ideia porquê?

[Vasiliy Sokolov]

Renat:

Além disso, há várias outras questões a serem resolvidas:

1. o que fazer com a travessia iminente por símbolos?
2. o que fazer com uma inevitável sobrecarga de depósitos e paragens garantidas?
3. Como se restabelece o esquema quando se perde comunicação durante algum tempo? É um verdadeiro pesadelo da fotocopiadora, e depois há uma confusão de múltiplos sinais
   
4. como explicar ao comerciante a confusão final com as posições quando ninguém terá a oportunidade de provar a correcção de todos os rolos?

Simplificámos propositadamente o sistema até um único sinal, livrando-nos das piores consequências. Especialmente tendo em conta o facto de que a maioria das transacções passarão muito provavelmente pelo mecanismo do Trusted Execution Token dos servidores em nuvem, o que reduzirá o atraso na cópia do sinal para alguns milissegundos.

Espere um minuto, não desenvolveu a arquitectura? Agora é você que escreve sobre mexer nas posições e intersecção por símbolos.

Renat:

Existe um mecanismo não comercial para replicar o comércio, não tem perda de conectividade, não tem problema de sincronização após uma reconexão (imagine 15 minutos ou 2 horas sem conectividade) e pode ser controlado rigorosamente 100% do tempo. Há também o MetaTrader 4 sem rede.

E a rede como tal não tem nada a ver com isso. Em tempos, algumas pessoas precisaram de desenvolver uma arquitectura apropriada para fazer com que as múltiplas moedas funcionassem de forma transparente em modo de rede. De facto, tudo foi limitado por ideias rudes de alguns entusiastas, descritas em artigos, dedicadas à criação de múltiplas moedas, que, devido à sua complexidade e falta de fiabilidade, está disponível apenas para um círculo restrito de "iniciados". Como resultado, "milhares de donas de casa" continuam a escolher o MT4 apenas porque tem um controlo simples sobre cada negócio e não há necessidade de se preocupar com que negócio deve ser fechado e que stop-loss deve ser reordenado.

[Vasiliy Sokolov]

Renat:

Simplificámos propositadamente o sistema até um único sinal, livrando-nos das piores consequências. Especialmente porque é provável que a maioria das transacções passe pelo mecanismo do Trusted Execution Token dos servidores de nuvem, o que reduzirá a latência da cópia do sinal para alguns milissegundos.

Homem, o objectivo do comércio de sinais é criar uma carteira de investimentos. Vejam os produtos , A**ri - a própria procura de um pool de gestores/robots criou estes serviços.

[Vasiliy Sokolov]

Renat:

Até agora não apresentou quaisquer soluções para os problemas, mas apenas afirmou que "tem pouco a fazer, e em geral a tarefa é um bolo".

Considerem que temos andado a pensar no problema há muito mais tempo. E não parámos no primeiro passo "bem, sim, em teoria, pode ser feito".

Na verdade, a essência de todos os vossos comentários foi reduzida a "dar e basta, é teoricamente possível, por isso não neguem, e eu sou demasiado preguiçoso para ir além do primeiro passo da elaboração".

E o que pensa que os criadores independentes podem fazer? O MT5 é rigidamente monolítico. O melhor que podem fazer é criar outra muleta e descrevê-la no artigo correspondente. Não se pode escrever um sistema de qualidade sem o integrar num produto. Conhecendo o problema em primeira mão, posso dizer que não se pode passar sem guardar registos de estados no lado do servidor. E como pensa que os programadores terceiros devem resolver este problema? No final, fazem-no o melhor que podem. Criam muletas e combinações como MQL5 <-> DLL <--> SQL, que são difíceis de manter e inaplicáveis ao mercado de massas que se está a promover.

[Renat Fatkhullin]

komposter:

Caracteristicamente, todas as coisas construtivas do meu posto anterior foram ignoradas )

Infelizmente, não houve qualquer contributo construtivo da sua parte. Havia apenas "dar e receber" + declarações unidireccionais.

Ou seja, não descreveu como resolver o conflito de sinais múltiplos e não deu resposta à questão de como recuperar de uma perda de ligação.

Além disso, não aborda a responsabilidade por conflitos iminentes tendentes a uma probabilidade de 100%. Não assinalei por nada a impossibilidade da solução "Posso fazê-lo por mim, vou arranjá-lo, está tudo bem" para um serviço de massas.

[Vasiliy Sokolov]

No que diz respeito ao tema, posso dizer, por experiência própria, que o problema é muito complexo e não pode ser resolvido por simples réplica. Convencionalmente, pode ser dividido em três componentes:

• Sistema de replicação de sinal. Reduz-se à recepção de sinais do pool de robôs comerciais, com controlo obrigatório da posição agregada.
• O sistema de gestão de carteiras. Um conjunto de regras, segundo as quais os fundos da conta conjunta são redistribuídos pelas sub-contas dos robots de negociação.
• O sistema de gestão de dinheiro/gestão de risco. Um conjunto de regras e fórmulas matemáticas que controlam o risco e determinam a forma como a carteira é capitalizada.

Tudo isto é muito difícil de arranjar na prática, e além disso exigiria uma modificação séria da arquitectura existente.

[Renat Fatkhullin]

C-4:

Espere um minuto, não desenhou a arquitectura? Agora você mesmo está a escrever sobre posição e sobreposição de caracteres.

Vejo que poucas pessoas pensaram realmente sobre a implementação do processamento.

Embora se possa compreender a linha de pensamento da afirmação "Dê-me uma solução, o comerciante precisa dela, armazene os estados no servidor". É compreensível: transferir o máximo de problemas para outros, não incomodar, e se algo correr mal - criticá-los por má implementação.

Mas se avaliar o problema do lado do corretor, do fornecedor do sistema, da infra-estrutura de rede, e só então do comerciante, verá que a solução proposta de mistura de sinais não tem uma solução razoável e segura.

[Andrey Khatimlianskii]

Renat:

Infelizmente, não tem havido qualquer atitude construtiva. Havia apenas "dar e receber" + declarações unidireccionais.

Por outras palavras, não descreveu como resolver conflitos de sinais múltiplos nem respondeu à questão de como recuperar da perda de comunicação.

Além disso, não aborda a responsabilidade por conflitos iminentes tendentes a uma probabilidade de 100%. Não assinalei por nada a impossibilidade da solução "Posso fazê-lo por mim, vou arranjá-lo, está tudo bem" para o serviço de massas.

Proibir-me por fazer declarações não substanciadas. Promete-me apenas que vais descansar.

[Renat Fatkhullin]

C-4:
E o que pensa que os criadores independentes podem fazer? O MT5 é rigidamente monolítico. O melhor que podem fazer é criar outra muleta e descrevê-la no artigo correspondente. Não se pode escrever um sistema de qualidade sem o integrar num produto. Conhecendo o problema em primeira mão, posso dizer que não se pode passar sem guardar os registos dos estados no lado do servidor. E como pensa que os programadores terceiros devem resolver este problema? No final, fazem-no o melhor que podem. Criam muletas tipo muleta e combinações de MQL5 <-> DLL <--> SQL, que são difíceis de manter e inaplicáveis ao mercado de massas, que tanto se elogia.

Está enganado.

A MQL5 é tão aberta e funcional que se pode fazer quase tudo. Não há necessidade de fazer muletas com DLL e SQL, basta utilizar operações de arquivo e armazenar tudo o que precisa em disco. A base de dados de variáveis globais é muito estável e não se perde durante as reinicializações ou colisões.

E o armazenamento do estado no servidor é medgies e comentários. Aprenda a utilizá-los com parcimónia.