그러나 각 이벤트를 동기적으로 처리하는 것은 매우 어렵기 때문에 사용 방법, 즉, 사건의 발생에 대해 알게 되면 행동하기에는 너무 늦을 수 있습니다. 주식 거래나 느린 선물에 대해서만 이야기한다면. 내 말은, 거래소에서 발자취의 미끄러짐은 경이적입니다. 마지막으로 61포인트가 개장에 있었습니다... 그리고 틱으로 판단하면 24ms 동안 1000개 이상의 랏이 거래되었습니다.
터미널은 아무 것도 동기화할 필요가 없습니다... 업데이트가 도착할 때(또는 약간의 고정 지연으로) 다시 제공하면 됩니다. 또는 두 개의 시냇물에 줄 수도 있습니다. 진드기용 시냇물과 너도밤나무용 시냇물. 그러나 두 사람의 정확한 도착 시간을 표시하여 함께 가져올 수 있습니다.
그러나 이제 모든 이벤트가 유리에 표시된다는 것이 확실합니까? 그리고 일반적으로 일종의 필터가 있을 수 있기 때문에 처리됩니다. 초당 100개 이하의 이벤트가 발생한다고 가정해 보겠습니다. 그리고 아마도 어쨌든 때가 왔지만 단순히 사용자가 사용할 수 없었습니다. 그렇지 않으면 유리에서 움직임을 그리는 다른 방법은 무엇입니까? 그러나 움직임이 많고 이미 구식이라면 필터에 의해 단순히 폐기될 수 있습니다.
이것을 어떻게 확인할 수 있습니까? 무엇을 확인할 것인가? 방법이 없거나 아이디어가 있습니까?
그러나 이제 모든 이벤트가 유리에 표시된다는 것이 확실합니까? 그리고 일반적으로 일종의 필터가 있을 수 있기 때문에 처리됩니다. 초당 100개 이하의 이벤트가 발생한다고 가정해 보겠습니다. 그리고 아마도 어쨌든 때가 왔지만 단순히 사용자가 사용할 수 없었습니다. 그렇지 않으면 유리에서 움직임을 그리는 다른 방법은 무엇입니까? 그러나 움직임이 많고 이미 구식이라면 필터에 의해 단순히 폐기될 수 있습니다.
이것을 어떻게 확인할 수 있습니까? 무엇을 확인할 것인가? 방법이 없거나 아이디어가 있습니까?
Plaza 2의 사양을 알려주시겠습니까?
읽어보세요. 관심이 있다면 어떻게 작동하는지 이해할 수 있을 것입니다.
추가됨
하지만, 완전히 은밀한 경우라면
거래소는 데이터 STREAMS를 발행하지만 실시간으로 받을 수는 없지만 이러한 흐름의 "컷"을 얻습니다.
그러나 이제 모든 이벤트가 유리에 표시된다는 것이 확실합니까? 그리고 일반적으로 일종의 필터가 있을 수 있기 때문에 처리됩니다. 초당 100개 이하의 이벤트가 발생한다고 가정해 보겠습니다. 그리고 아마도 어쨌든 때가 왔지만 단순히 사용자가 사용할 수 없었습니다. 그렇지 않으면 유리에서 움직임을 그리는 다른 방법은 무엇입니까? 그러나 움직임이 많고 이미 구식이라면 필터에 의해 단순히 폐기될 수 있습니다.
이것을 어떻게 확인할 수 있습니까? 무엇을 확인할 것인가? 방법이 없거나 아이디어가 있습니까?
최소한 모든 거래를 확인하게 하십시오. 저것들. 유리가 과거 거래를 확인할 수 있도록. 이것은 밀리초 정밀도를 의미합니다. 그게 다야, 더도 말고 덜도 말고 - 그것들을 집계/합산/필터링/차단하게 놔두지만 나는 상관하지 않습니다. 동일한 정확도로 주문서의 현재 틱 정확도에서 시간이 필요합니다.
실용성의 관점에서 볼 때 - 예, 유용하지만 모든 것을 동기화하려는 시도에서 터미널이 어떻게 느려질지 상상하기 어렵습니다 ... 그러나이 데이터의 비동기식 도착에 의미가 있습니까? 잘 모르겠어.
속도가 전혀 느려지지 않으며 어쨌든 테이블이 처리됩니다. :)
새로운 필드의 도입에는 전혀 시간이 걸리지 않습니다(여전히 테이블 처리에 소요됨)
MT5 서버는 22개의 테이블 팩을 수신하고 MqlBookInfo 구조 의 필드를 채우기 위해
전체 22개 테이블(방향 - 마지막 필드)을 "걷기"해야 합니다!
속도가 전혀 느려지지 않으며 어쨌든 테이블이 처리됩니다. :)
새로운 필드의 도입에는 전혀 시간이 걸리지 않습니다(여전히 테이블 처리에 소요됨)
MT5 서버는 22개의 테이블 팩을 수신하고 MqlBookInfo 구조 의 필드를 채우기 위해
전체 테이블 22(방향 - 마지막 필드)를 통해 "걷기"해야 합니다!
성능에 영향을 미치지 않는다면 그렇게 하십시오.
그러나 각 이벤트를 동기적으로 처리하는 것은 매우 어렵기 때문에 사용 방법, 즉, 사건의 발생에 대해 알게 되면 행동하기에는 너무 늦을 수 있습니다. 주식 거래나 느린 선물에 대해서만 이야기한다면. 내 말은, 거래소에서 발자취의 미끄러짐은 경이적입니다. 마지막으로 61포인트가 개장에 있었습니다... 그리고 틱으로 판단하면 24ms 동안 1000개 이상의 랏이 거래되었습니다.
그러나 터미널이 모든 것을 동기화하려는 시도에서 어떻게 느려질지 상상하기 어렵습니다...
터미널은 아무 것도 동기화할 필요가 없습니다... 업데이트가 도착할 때(또는 약간의 고정 지연으로) 다시 제공하면 됩니다. 또는 두 개의 시냇물에 줄 수도 있습니다. 진드기용 시냇물과 너도밤나무용 시냇물. 그러나 두 사람의 정확한 도착 시간을 표시하여 함께 가져올 수 있습니다.
값은 어떤 경우에도 됩니다!
얘들아!
MqlBookInfo 구조는 표 22(또는 FORTS_FUTORDERBOOK_REPL - Futures: Glass Break)에서 채워집니다!
MOMENT 필드를 추가하고 THE SAME 테이블에서 채우기만 하면 됩니다!
시간 손실이 없고 동기화할 필요가 없으며 모든 것이 작동한 대로 작동합니다.
수정 사항이 나타납니다! 모두!
그러나 이제 모든 이벤트가 유리에 표시된다는 것이 확실합니까? 그리고 일반적으로 일종의 필터가 있을 수 있기 때문에 처리됩니다. 초당 100개 이하의 이벤트가 발생한다고 가정해 보겠습니다. 그리고 아마도 어쨌든 때가 왔지만 단순히 사용자가 사용할 수 없었습니다. 그렇지 않으면 유리에서 움직임을 그리는 다른 방법은 무엇입니까? 그러나 움직임이 많고 이미 구식이라면 필터에 의해 단순히 폐기될 수 있습니다.
이것을 어떻게 확인할 수 있습니까? 무엇을 확인할 것인가? 방법이 없거나 아이디어가 있습니까?
그러나 이제 모든 이벤트가 유리에 표시된다는 것이 확실합니까? 그리고 일반적으로 일종의 필터가 있을 수 있기 때문에 처리됩니다. 초당 100개 이하의 이벤트가 발생한다고 가정해 보겠습니다. 그리고 아마도 어쨌든 때가 왔지만 단순히 사용자가 사용할 수 없었습니다. 그렇지 않으면 유리에서 움직임을 그리는 다른 방법은 무엇입니까? 그러나 움직임이 많고 이미 구식이라면 필터에 의해 단순히 폐기될 수 있습니다.
이것을 어떻게 확인할 수 있습니까? 무엇을 확인할 것인가? 방법이 없거나 아이디어가 있습니까?
Plaza 2의 사양을 알려주시겠습니까?
읽어보세요. 관심이 있다면 어떻게 작동하는지 이해할 수 있을 것입니다.
추가됨
하지만, 완전히 은밀한 경우라면
거래소는 데이터 STREAMS를 발행하지만 실시간으로 받을 수는 없지만 이러한 흐름의 "컷"을 얻습니다.
상당히 낮은 지연으로.
MQ가 수정 및 혁신을 원하지 않는 또 다른 옵션이 가능합니다.
그들은 고용할 수 있도록 CGate에서 MT5 서버를 빠르게 다시 작성해야 했습니다.
CGate의 제3자 구현을 위해.
그리고 이것은 2줄의 코드가 아니며 매우 심각하게 이해해야 합니다.
추가됨
내 자신의 Plaza2 커넥터를 여러 번 작성하려고 했지만 작동하지 않았습니다(뇌가 충분하지 않음)
그러나 이제 모든 이벤트가 유리에 표시된다는 것이 확실합니까? 그리고 일반적으로 일종의 필터가 있을 수 있기 때문에 처리됩니다. 초당 100개 이하의 이벤트가 발생한다고 가정해 보겠습니다. 그리고 아마도 어쨌든 때가 왔지만 단순히 사용자가 사용할 수 없었습니다. 그렇지 않으면 유리에서 움직임을 그리는 다른 방법은 무엇입니까? 그러나 움직임이 많고 이미 구식이라면 필터에 의해 단순히 폐기될 수 있습니다.
이것을 어떻게 확인할 수 있습니까? 무엇을 확인할 것인가? 방법이 없거나 아이디어가 있습니까?
최소한 모든 거래를 확인하게 하십시오. 저것들. 유리가 과거 거래를 확인할 수 있도록. 이것은 밀리초 정밀도를 의미합니다. 그게 다야, 더도 말고 덜도 말고 - 그것들을 집계/합산/필터링/차단하게 놔두지만 나는 상관하지 않습니다. 동일한 정확도로 주문서의 현재 틱 정확도에서 시간이 필요합니다.
얘들 아, 요새에 제한 설정을 실행하는 방법에 대한 조언이 필요합니다. 코드가 있습니다. 위치가 나타나면 로봇이 가격 위와 아래에 들여 쓰기로 지정가 주문을합니다.
나는 실제로 리미터에 대한 들여쓰기 자체의 가격이 올바르게 정규화되었는지, 내장 라이브러리를 사용할 가치가 있는지, 아니면 개별적으로 가격을 정규화하는 것이 더 나은지 여부에 관심이 있습니다.
고맙습니다.
별도의 주제를 만듭니다.