Quem já experimentou a subscrição de Sinais para se colocar na cauda dos participantes do ATC 2012? - página 5
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Pense também nas ordenhadoras.
Alugar um Sinal é deflacionado...
Alguma ideia porquê?
Além disso, há várias outras questões a serem resolvidas:
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.
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.
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.
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".
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.
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:
Tudo isto é muito difícil de arranjar na prática, e além disso exigiria uma modificação séria da arquitectura existente.
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.
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.
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.