Função OrderSendAsync() - página 8
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
Porque os pacotes quebrados, as ligações largadas, etc., são uma treta. Não confiável. Não fiável -- tem de se desligar.
Só por precaução, manteremos a fila de transacções comerciais para a emissão de EAs e distribuí-las-emos.
As lacunas de comunicação na execução são um problema, ainda não é clara a melhor forma de lidar com elas. Em qualquer caso, seremos capazes de verificar todas as posições em aberto após a reconexão.
Porque os pacotes quebrados, as ligações largadas, etc., são uma treta. Não confiável. Não fiável -- tem de se recuperar.
Vamos manter as moscas separadas e as costeletas separadas.
Os pacotes quebrados são uma situação anormal para o terminal e devem ser tratados por excepções, incluindo através da análise do histórico.
Mas é demasiado caro para analisar a história de cada comércio. A chegada do comércio é uma situação normal e deve ser tratada de forma pouco dispendiosa.
Hi. Sabe sequer o que é a assíncronia?
Tanto quanto sei, a introdução desta função para EAs de moeda múltipla (para EAs de moeda única a iniciativa não faz sentido), o único objectivo é poupar tempo, evitando o atraso na execução da ordem do lado do servidor. Corrija-me se estiver errado.
Além disso, resta apenas uma parte crítica do tempo - a transmissão de pacotes de dados através dos canais de comunicação. Ao tentar empurrar a "fronteira do desconhecido" para o nível de "cair (pacote) e continuar", tem mais problemas do que benefícios. É importante avaliar o problema de forma holística. Um possível timeout, se houvesse um, é susceptível de afectar não só a capacidade de negociar num determinado instrumento, mas também, em princípio, a falta de comunicação com o servidor.
Além disso, não é claro como fazer uma estimativa por parte do consultor especializado: a ordem comercial foi perdida na transmissão de dados, ou está à espera da sua vez no servidor há tanto tempo? E isso significa que haverá erros com a duplicação de ordens comerciais, o que conduzirá a violações do MM e, consequentemente, a riscos acrescidos. Na minha opinião, qualquer comerciante profissional (Expert Advisor) deve certificar-se de que a sua ordem comercial é aceite pelo servidor. Além disso, a fim de identificar claramente o estado de uma determinada ordem de negociação (na função OnTrade()), é necessário um valor único recebido do servidor para o aplicar no processamento posterior (até que a negociação seja executada (abertura/fecho de uma posição).
É semelhante ao modelo de rede da OSI. Não precisamos de entrar no canal ou na camada física de execução de ordens comerciais. Deixar o cliente (MT5) desempenhar esta função de transporte. Operar na camada de aplicação.
Poupança de tempo devido a nenhum atraso do lado do servidor na execução da ordem. Corrija-me se estiver errado.
Ao custo de não esperar pelos resultados do pedido. Em termos gerais, sim. Isto é, para ordens e execução de mercado pode ser muito útil.
Além disso, resta apenas uma secção de tempo crítico - a transmissão do pacote de dados através dos canais de comunicação. Ao tentar empurrar a "fronteira do desconhecido" para o nível de "cair (pacote) e continuar", tem mais problemas do que benefícios.
Bem... não. Só tem de ser utilizado quando os benefícios superam os problemas.
Na minha opinião, qualquer comerciante profissional (conselheiro) precisa de se certificar de que a sua ordem comercial é aceite para execução pelo servidor.
Então a opção assíncrona não é adequada para si. Tudo é solvível.
TheXpert
Vamos repetir, com os dedos. Estruturando de forma grosseira os atrasos:
1. Tempo para o terminal verificar previamente a ordem de comércio, "embalá-la" no lote de saída e colocá-la na "fila da rede".
2. Tempo de transmissão de um pacote de dados contendo uma ordem de troca do cliente para o servidor.
3. Hora de receber uma ordem comercial pelo servidor e de a colocar no pool de processamento e de enviar ao cliente um identificador único deste bilhete.
4. O tempo de pré-processamento da correcção da ordem comercial e a sua colocação na plataforma de negociação.
Se indiquei algo errado, por favor corrija. Compreendo que não queira esperar depois do primeiro ponto? Eu, por outro lado, defendo a disponibilidade obrigatória dos três primeiros.
Duas perguntas precisam de ser respondidas para uma discussão mais aprofundada:
1. A relação proporcional de atrasos. Isto é, em média, quanto tempo em termos percentuais cada um dos quatro itens acima referidos leva. Se a distribuição for, por exemplo, "0,5%-1,0%-1,0%-1,0%-97,5%", então não vale a pena.
2) O tempo limite e o seu impacto na estratégia comercial. Francamente falando, não posso nomear um único TS que não requeira um entendimento claro se uma encomenda foi ou não enviada para o servidor. Isto é relevante tanto para arbitragens a longo prazo como para arbitragens multimoedas. Ou seja, a garantia de execução de uma ordem de comércio não pode ser questionada. Por favor, forneça um contra-exemplo se não concordar.
Na minha opinião, a maneira mais fácil de resolver o problema de execução numa pausa é não criar uma fila de execução (cancelar a execução) e notificar o utilizador do cancelamento ao restabelecer a ligação. Desta forma, haverá menos ambiguidade.
Um bilhete de servidor deve ser devolvido. Isto assegurará que a encomenda chega ao servidor e é aceite para processamento.
Construir piscinas de espera astuciosas do lado do cliente não é apenas uma solução impraticável, chamar-lhe-ia uma falha grosseira de design na arquitectura cliente-servidor do MT5.
As pesadas piscinas de espera do lado do cliente não é uma solução elegante.
Foi isto que foi pedido. Ninguém o está a forçar a usá-lo se não for necessário.
TheXpert
Vamos fazê-lo novamente, com os dedos. Estruturando de forma grosseira os atrasos:
1. tempo para o terminal verificar previamente a ordem comercial, "embalá-la" numa embalagem expedível e colocá-la numa "fila de rede".
2. Hora do envio de um pacote de dados contendo uma ordem de troca do cliente para o servidor.
Hora de receber uma ordem comercial pelo servidor e de a colocar no pool de processamento e de enviar ao cliente um identificador único deste bilhete.
4. Tempo de pré-processamento da correcção da ordem comercial e da sua colocação na plataforma comercial.
3 está melhor dividido.
3.1 colocação
3.2 envio de uid.
Se eu indicar algo errado, por favor, corrija. Compreendo que não queira esperar depois do primeiro artigo?
Sim.
Eu, por outro lado, sou a favor de tornar os três primeiros obrigatórios.
E se o ping for meio segundo? É assíncrono. De que serve usar este modo?
É isto que tem sido pedido. Ninguém o está a forçar a usá-lo se não for necessário.
Ainda não respondeu à minha pergunta. Dê-me um exemplo concreto em que casos pode ignorar a garantia de execução de ordens comerciais por causa da rapidez do seu envio para caracteres diferentes?
Ainda não respondeu à minha pergunta. Por favor, dê-me um exemplo concreto de quando pode ignorar as garantias de execução de ordens comerciais por causa da rapidez do seu envio para símbolos diferentes?
Sem problemas - negociação de carteiras + execução no mercado.