OnTradeTransaction

 
Interessado na resposta dos desenvolvedores - por que o evento daOnTradeTransaction não é garantido?
 
Alexey Oreshkin:
Estou interessado na resposta dos desenvolvedores - por que o evento daOnTradeTransaction não é garantido?

Os desenvolvedores provavelmente estão cansados de responder. Vou tentar responder por eles: A OnTradeTransaction não pode ser garantida por definição porque é um evento. Mesmo que seja garantido o envio do evento, não se pode garantir que ele seja aceito. Imagine que quando um evento ocorre, o terminal do usuário é desligado ou a conexão com a Internet é interrompida e este evento não pode ser tratado. A probabilidade é baixa, mas não impossível.

Em vez de analisar os eventos, é necessário analisar o ambiente comercial e somente se o ambiente comercial tiver mudado, tomar as decisões necessárias. A OnTransaction só pode ser usada em casos muito limitados, e geralmente é melhor trabalhar sem ela. Veja o MetaTrader 4, ele não tem a OnTransaction e gerencia perfeitamente bem sem ele.

 
Vasiliy Sokolov:

Os desenvolvedores provavelmente estão cansados de responder. Vou tentar responder por eles: A OnTradeTransaction não pode ser garantida por definição porque é um evento. Mesmo que seja garantido o envio do evento, não se pode garantir que ele seja aceito. Imagine que quando um evento ocorre, o terminal do usuário é desligado ou a conexão com a Internet é interrompida e este evento não pode ser tratado. A probabilidade é baixa, mas não impossível.

Em vez de analisar os eventos, é necessário analisar o ambiente comercial e somente se o ambiente comercial tiver mudado, tomar as decisões necessárias. A OnTransaction só pode ser usada em casos muito limitados, e geralmente é melhor trabalhar sem ela. Veja o MetaTrader 4, ele não tem a OnTransaction e todos estão indo bem sem ele.

Ao contrário do mt5, é muito mais fácil administrar posições no mt4 devido à ausência de rede, portanto a OnTransaction é boa ou má lá.
Isto é, o evento não é garantido apenas por razões técnicas? Se tudo funcionar, então o terminal deve garantir 100% deste evento?

 
Alexey Oreshkin:

No MT4 é muito mais fácil administrar posições ao contrário do MT5 devido à ausência de rede. É por isso que a OnTransaction é quente ou fria no MetaTrader.
Então o evento não é garantido apenas por razões técnicas? Se tudo funcionar, então o terminal deve garantir 100% deste evento?

A compensação não tem efeito sobre a necessidade da OnTradeTransaction.

A segunda pergunta só pode ser respondida pelos próprios desenvolvedores. Tudo o que tenho notado é que a OnTradeTransaction é extremamente estável. Não foram detectadas perdas no recebimento de eventos.

 
Vasiliy Sokolov:

A compensação não tem efeito sobre a necessidade da OnTradeTransaction.

A rede afeta a contabilidade de posição e é a razão de tantos problemas com uma questão tão simples, enquanto a OnTradeTransaction também é necessária para a contabilidade de posição.

 
Alexey Oreshkin:

No MT4, devido à ausência de redes em geral, é muito mais fácil administrar posições ao contrário do MT5, portanto a OnTransaction não é nem fria nem quente lá.
Isto é, o evento não é garantido apenas por razões técnicas? Se tudo funcionar, então o terminal deve garantir 100% deste evento?

Os desenvolvedores escolhem propriedades prioritárias do produto. A propriedade prioritária do MT4 era a facilidade de uso com a MQL4.

Com o MT5, a prioridade óbvia de primeiro nível é a velocidade (e a flexibilidade). É impossível obter todas as características de um produto no máximo. Isto contradiz a teoria.

O produto mais rápido exigirá inevitavelmente muito mais (conhecimento, experiência e esforço) do programador do cliente.


Que se lixe estes problemas técnicos. Pensemos nisso sobriamente.

Suponha que você esteja desenvolvendo um MT5 e tenha uma tarefa: escrever um bloco HFT para ações comerciais.

Por um lado, os registros de transações são enfileirados do servidor, por outro lado, esses registros devem ser passados ao XXX-expert.

No XXX expert, dentro do manipulador da OnTradeTransaction(), o usuário pode ter qualquer "pornografia"!

Não está absolutamente claro por quanto tempo esta função será executada.

A fila pode conter centenas de registros vindos do servidor, mas ainda não transferidos para o XXX-expert.

O que você pode garantir nesta situação? Velocidade ou integralidade dos dados?

E há algum sentido em "armazenar" informações profundamente obsoletas para uma função que, em sua essência, contribui apenas para o HFT?

 

Gente!

Eu o li e me pergunto...

A OnTradeTransaction permite obter as informações mais atualizadas sem "cavar" em qualquer lugar

em encomendas e negócios!

Você simplesmente não sabe como usar esta função.

 
Михаил:

Gente!

Eu o li e me pergunto...

A OnTradeTransaction permite obter as informações mais atualizadas sem "cavar" em qualquer lugar

em encomendas e negócios!

Você simplesmente não sabe como usar esta função.

Você também não sabe como utilizá-lo. Você já escreveu dezenas de páginas sobre a OnTradeTransaction, mas não entendeu uma coisa: a OnTradeTransaction é uma função de serviço para resolver tarefas específicas estreitas, você não pode usá-la na negociação como você faz. E então os caras espertos lêem seus artigos e criam tópicos similares: "Por que a OnTradeTransaction não é garantida" - porque um Expert Advisor não deve criar seu ambiente comercial através da OnTradeTransaction, como você faz, mas confiar apenas no que está disponível no sistema, em particular no histórico de ordens e negócios.
 
Vasiliy Sokolov:
Você também não sabe como fazer isso. Você já escreveu dezenas de páginas sobre o assunto OnTradeTransaction, mas não tem uma coisa clara: a OnTradeTransaction é uma função de serviço destinada a resolver tarefas específicas estreitas, você não pode usá-la na negociação como você faz. E então os caras espertos lêem seus artigos e criam tópicos similares: "Por que a OnTradeTransaction não é garantida" - porque um Expert Advisor não deve criar seu ambiente comercial através da OnTradeTransaction, como você faz, mas confiar apenas no que está disponível no sistema, em particular no histórico de ordens e negócios.

Por um lado, sim. Por outro lado: e nos casos em que um pedido foi enviado ao servidor, mas a operação ainda não foi executada? Como podemos dizer em que estado estamos se temos apenas uma lista de pedidos e posições (e histórico da conta)?

Não existe tal problema no MT4, porque todas as operações comerciais lá são síncronas. Mas como resultado, obtemos um desempenho mais lento.

 
Игорь Герасько:

Por um lado, sim. Por outro lado: e nos casos em que um pedido foi enviado ao servidor, mas a operação ainda não foi executada? Como podemos dizer em que estado estamos se temos apenas uma lista de pedidos e posições (e histórico da conta)?

Não existe tal problema no MT4, porque todas as operações comerciais lá são síncronas. Mas como resultado, o nosso desempenho é mais lento.

Se o tempo entre o envio de uma ordem e o próximo sinal de entrada no mercado exceder o tempo de execução da ordem, não precisaremos fazer nada. A lógica é simples: enviamos uma ordem assíncrona, deixamos o fio e o esquecemos. Esperamos pelo próximo momento para verificar o sinal. Se naquele momento o ambiente comercial não mudou - o Expert Advisor procura um sinal para entrar novamente no mercado e repete a ordem para entrar no mercado. Se, pelo contrário, tudo correu bem e a ordem foi executada, o consultor especializado perceberá que tem uma posição após analisar o ambiente e não abrirá uma nova posição novamente. Ou seja, nesta abordagem, a condição do Expert Advisor é garantida de ser consistente com o ambiente do mercado.

A situação é mais complicada no comércio de alta freqüência, onde um novo sinal pode ocorrer após um tempo comparável à execução de uma ordem (6-100 msec). Neste caso, você não pode passar sem travamento. O Consultor Especialista deve se lembrar da hora do último envio do pedido. Se ocorrer um erro na OnTransaction, o bloqueio é reiniciado e o Expert Advisor pode realizar operações novamente.

Deve-se notar que a OnTradeTransacton, pela qual tantas pessoas gostam de rezar, não ajuda na HFT. Um novo sinal de entrada pode chegar mais rápido do que a resposta sobre a execução bem sucedida de uma transação na OnTradeTransaction. O bloqueio é necessário quer você use ou não a OnTradeTransacton.

Como, você pode perguntar, podemos controlar os erros que surgem na OnTradeTransaction? Você pode responder com uma contra-question: Como você mudará a lógica comercial do Expert Advisor on the fly quando ocorrer um erro? - Você não pode. Os erros ocorrem se você não fizer verificações apropriadas antes (presença de dinheiro, volume, etc., etc.). Mas uma vez ocorrido, você não será capaz de corrigi-lo. Portanto, a melhor coisa que você pode fazer na OnTradeTransaction, é imprimir este erro no log (para corrigir a lógica do Expert Advisor mais tarde), e remover a fechadura, se ela for usada. Para isso e nada mais, a OnTradeTransaction deve ser utilizada.

Agora vários adeptos de Mikalas virão correndo e começarão a jogar tomates contra mim - deixe-os. Mas eu sempre repeti que uma lógica comercial confiável só pode ser organizada se for baseada no ambiente comercial do terminal. Qualquer outra coisa não vai funcionar.

 
Alexey Oreshkin:
Estou interessado na resposta dos desenvolvedores - por que o evento daOnTradeTransaction não é garantido?

A OnTradeTransaction é o resultado da resposta do servidor ao pedido da OrderSendAsinc.

A própria função OrderSendAsinc é assíncrona, que é declarada mesmo em seu nome. Isto significa que esta função lançou uma solicitação ao servidor e retornou a resposta ao programa sobre os resultados do envio (se a solicitação foi enviada com sucesso ou não).

Isso é de acordo com o princípio que o galo cantou e não vai amanhecer. É por isso que a resposta do servidor naOnTradeTransaction não é garantida. Você nunca sabe o que pode acontecer lá.

Há duas funções similares OrderSend e OrderSendAsinc.

O primeiro é síncrono e espera silenciosamente pela resposta do servidor, não importa quanto tempo demore (retorna o resultado do processamento da solicitação pelo servidor).

O segundo é assíncrono, não espera pela resposta do servidor, mas retorna imediatamente o resultado da operação (mas retorna o resultado do envio ou não da solicitação ao servidor com sucesso).

O OrderSendAsinc é necessário quando as decisões precisam ser tomadas rapidamente. Testes mostraram que a OrderSendAsinc pode lidar com o envio de centenas de pedidos por segundo (mas esta velocidade se deve ao fato de não estar esperando por uma resposta do servidor).

Exatamente para o recebimento de resposta "atrasada" o terminal gera o evento OnTradeTransaction (atrasado condicionalmente devido ao fato de que o programa continuou recebendo resposta, na verdade, o atraso é contado em segundos ou milissegundos).

A diferença da OrderSend é que a OnTradeTransaction pode ser gerada para um pedido várias vezes notificando o terminal sobre as informações recém recebidas sobre como o pedido foi processado pelo servidor. Isso significa que podemos ver as etapas de processamento de pedidos na OnTradeTransaction.

Ordem aceita pelo servidor OnTradeTransaction

O pedido foi colocado na fila da OnTradeTransaction

Encomendar ... OnTradeTransaction

Encomendar ... OnTradeTransaction etc.

Todos os eventos, exceto o primeiro evento no pedido, são assinados com um ingresso para identificar exatamente qual ordem a resposta ao evento OnTradeTransaction foi recebida.

O primeiro evento é assinado pelo bilhete e pelo request_id. O request_id é obtido pelo usuário logo após o pedido ser submetido pela função OrderSendAsinc. Assim, uma certa iteração OrderSendAsinc está ligada aos resultados obtidos na OnTradeTransaction.