Sequência em que as ordens são processadas - página 3
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
@Rodrigo Malacarne e colegas,
No fórum russo também me responderam que a ordem não será garantida. Veja uma das respostas (traduzida pelo tradutor automático, pois não sei falar russo - acredito que "autorização" seja a ordem limitada pendente a ser cancelada e "entrar no mercado" seja a segunda ordem, enviada a mercado):
Essa é uma boa pergunta.
Não há garantias.
Pelo menos porque o primeiro OrderSendAsync pode se perder no caminho para o servidor, e o segundo virá mais cedo.
Se você precisar excluir a autorização e, em seguida, entrar no mercado, use OrderSend ou OrderSendAsync com a análise de resultado em OnTradeTransaction .
Pensando aqui com meus botões ...
1) De fato, redes TCP/IP (internet em geral) usam roteamento dinâmico e por isso NÃO garantem que os pacotes de dados cheguem no destino na mesma ordem em que foram enviados na origem. Isso é fato.
2) Com base no item (1) podemos afirmar que, com OrderSendAsync(), os comandos poderão chegar fora de ordem nos servidor MT5 e a execução da ordem a mercado poderá ocorrer antes do cancelamento da ordem anterior, podendo gerar o "zé-com-zé", como eu mesmo tive a infeliz oportunidade de verificar na prática.
3) Entretanto, se for usada a versão síncrona, OrderSend(), os comandos certamente chegarão no servidor MT5 na ordem correta, pois o OrderSend() aguarda a confirmação de que o servidor MT5 recebeu o comando (não necessariamente já o processou, mas já o recebeu, e isso é o que importa para garantir que o segundo comando será recebido após o primeiro).
4) Com base no item (3), podemos afirmar que, com OrderSend(), os comandos chegarão sempre nas ordem correta no servidor MT5.
5) Entretanto, mesmo que os comandos cheguem na ordem certa no servidor MT5, ainda existem pelo menos duas brechas adicionais que poderiam permitir a execução dos comandos fora de ordem (e o eventual "zé-com-zé", no meu caso) mesmo com OrderSend():
5.1) se o servidor MT5 não enviar à B3 os comandos na mesma ordem em que os recebeu;
5.2) se os comandos forem enviados na ordem correta do servidor MT5 para a B3, mas chegarem na B3 na ordem errada.
obs: uma terceira possibilidade seria a B3 processar os comandos em ordem diferente da ordem em que foram recebidos, mas isto eu acredito que não aconteça, pelo menos não para comandos que venham de uma mesma corretora.
6) Não sei se a brecha (5.1) existe, mas acredito que a brecha (5.2) dependerá do tipo de conexão entre o servidor MT5 da corretora e a B3. Se for uma conexão de internet normal (TCP/IP), a ordem de execução dos comandos não será garantida. Somente um link direto, com rota única, entre a corretora e a B3 poderia garantir que os comandos cheguem na B3 na ordem correta.
Com base no raciocínio acima, as perguntas-chave seriam:
1) O servidor MT5 processa os comandos OrderSend() sempre na mesma ordem em que os recebe?
2) Como são os links entre o servidor MT5 das corretoras brasileiras e a B3? Há alguma corretora que tenha link direto com a B3, garantindo que os comandos são recebidos pela B3 na mesma ordem em que são enviados pelo servidor MT5?
Alguém sabe?
Abraços
Boa tarde!
Sobre as questões 5.x e 6:
Como a função OrderSend() bloqueia o processo até o recebimento do resultado, você garante que as suas ordens cheguem na mesma ordem que você enviou, já que o resultado é a execução/cancelamento/colocação da ordem.
No caso da OrderSendAsync(), como ela não bloqueia o processo, você não tem nenhuma garantia e o maior problema não está entre o OMS e a B3, mas sim entre você e o OMS, seu SO e HW. Mesmo tendo um link direto com rota única, você não terá tal garantia.
Quanto as perguntas chave:
Como o OMS precisa ser escalável e ter uma alta vazão de entrada e saída, as requisições devem ser processadas de forma concorrente, somente, já na B3 o pré-processamento das requisições é de forma concorrente e colocado em forma de fila para processamento no match engine da bolsa. (Somente minha opinião)
Até onde eu sei temos o OMS em modo DMA-2 e DMA-4. Mas até ai não há nenhuma garantia ao usar OrderSendAsync()
Abs.
Boa tarde!
Sobre as questões 5.x e 6:
Como a função OrderSend() bloqueia o processo até o recebimento do resultado, você garante que as suas ordens cheguem na mesma ordem que você enviou, já que o resultado é a execução/cancelamento/colocação da ordem.
No caso da OrderSendAsync(), como ela não bloqueia o processo, você não tem nenhuma garantia e o maior problema não está entre o OMS e a B3, mas sim entre você e o OMS, seu SO e HW. Mesmo tendo um link direto com rota única, você não terá tal garantia.
Quanto as perguntas chave:
Como o OMS precisa ser escalável e ter uma alta vazão de entrada e saída, as requisições devem ser processadas de forma concorrente, somente, já na B3 o pré-processamento das requisições é de forma concorrente e colocado em forma de fila para processamento no match engine da bolsa. (Somente minha opinião)
Até onde eu sei temos o OMS em modo DMA-2 e DMA-4. Mas até ai não há nenhuma garantia ao usar OrderSendAsync()
Abs.
Você precisa considerar que um boa oportunidade não vai aparecer simultaneamente na compra e na venda e por isso agurdar a confirmação de cancelamento não deve ser um problema. E uma vez que a oportunidade passou e ordem não foi executada deve ser cancelada imediatamente e não apenas quando enviar uma ordem oposta, caso contrário corre o risco de executar operações indesejadas se ficar ordem passiva no book.
Oi Samuel.
No caso eram operações de arbitragem, explorando ineficiências de mercado, ou seja, distorções transitórias na proporção entre preços de diferentes ativos que deveriam estar sempre correlacionados. Estas distorções normalmente se desfazem rapidamente, pois logo algum robô percebe e explora a distorção, restabelecendo o equilíbrio do mercado. Se o seu robô for o primeiro a perceber e conseguir agir antes dos outros, vc ganha dinheiro sem risco.
Exemplos de arbitragem: units x ações preferenciais e ordinárias, ações x opções, opções do mesmo ativo com diferentes strikes e/ou vencimentos, box de 4 pontas, lote cheio da ação x mesma ação no mercado fracionário, ADR's de empresa brasileira x ações da mesma empresa na B3, contratos futuros com diferentes vencimentos x taxa de juros, triangulações entre 3 moedas, triangulação entre commodities no Brasil e no exterior e câmbio USD/BRL, etc.
Essas oportunidades surgem a qualquer momento, em qualquer direção, geralmente causadas por algum comprador ou vendedor que faz um movimento grande e repentino, e geralmente só podem ser capturadas com lucro se você comprar/vender pelo menos uma das pontas de forma passiva, com ordem pendente em preço um pouco afastado do bid/ask, para capturar uma variação súbita e inesperada de um ativo antes que o(s) preço(s) do(s) ativo(s) correlacionado(s) se mexa(m).
Claro que dá pra evitar o problema do "zé-com-zé" que eu relatei colocando a "isca" (a ordem pendente) somente em uma das pontas de cada vez, mas nesse caso perdem-se metade das oportunidades.
A corretora bloqueou minhas ordens no MT5.
O que faço?
Tem operações positivas para fechar, mas não consigo
A corretora bloqueou minhas ordens no MT5.
O que faço?
Tem operações positivas para fechar, mas não consigo