Kvikovites는 "아무것도 숨기지 않는다"고 주장하며 광장에서 터미널까지 모든 것을 방송합니다. 동시에 퀵은 교환 정보의 각 부분에 대한 이벤트를 생성합니다. 따라서 이러한 이벤트 처리기의 파일에 해당 데이터를 쓰는 것이 논리적입니다. 그런 다음 "모든 거래" 파일을 "주문서의 이미지" 파일과 비교합니다.
그리고 여기에 하나의 미묘함이 있습니다. 잔 자체는 컵 도착 이벤트 핸들러에 도착하지 않습니다. 그리고 핸들러에서 요청해야 합니다. 그리고 당신은 주저하고 사건을 일으킨 유리의 절단이 아니라 예를 들어 다음 유리를 얻을 수 있습니다. 저것들. 컷을 건너뛰고 "유리한 거래"를 받으세요.
MT5에서도 거의 동일합니다. 그리고 metaquote는 이에 대해 정직하게 경고합니다.
이벤트 핸들러에 관한 것이 아닙니다.
최적가 데이터가 전송되는 두 가지 방법이 있습니다.
1. 유리 컷
2. 공통 테이블은 최적의 가격과 함께 악기에 대한 정보를 방송합니다.
이벤트가 오더북에 의해 생성되는지 또는 기기에 대한 정보에 의해 생성되는지 여부는 전혀 중요하지 않습니다.
정보가 모든 터미널에 동일하게 제공되는 것이 중요하며 다른 브로커의 역사에서
그것은 다르고 거래는 모든 곳에서 동일하지만 요청과 입찰은 종종 다릅니다.
두 MT5 터미널에서 매도호가와 매수호가를 얻는 알고리즘은 다른 브로커에 대해 동일하므로 다음과 같이 결론을 내립니다.
이벤트가 오더북에 의해 생성되는지 또는 기기에 대한 정보에 의해 생성되는지 여부는 전혀 중요하지 않습니다.
정보가 모든 터미널에 동일하게 제공되는 것이 중요하며 다른 브로커의 역사에서
그것은 다르고 거래는 모든 곳에서 동일하지만 요청과 입찰은 종종 다릅니다.
두 MT5 터미널에서 매도호가와 매수호가를 얻는 알고리즘은 다른 브로커에 대해 동일하므로 다음과 같이 결론을 내립니다.
이 알고리즘은 제대로 작동하지 않습니다. 견적 공백이 있습니다.
이벤트가 생성되는 방식과 생성 여부가 중요합니다. 그리고 이벤트를 일으킨 값도 핸들러에 오면 일반적으로 괜찮습니다. 왜냐하면. 가치를 놓치지 않는다는 더 큰 자신감.
Plaza는 입찰/매도를 포함하는 FORTS_COMMON_REPL 스트림을 브로드캐스트합니다. 이 정보의 일부가 QUIK에 도착하면 OnParam 이벤트가 생성됩니다. 그리고 여기에서 모호성이 시작됩니다. Quick에서 상자를 선택하고 "현재 상태로 데이터 업데이트 간격"을 초 단위로 선택할 수 있습니다. 그리고 이 간격으로 OnParam 이벤트가 생성됩니다. 물론 입찰/매도 변경 사항은 건너뜁니다. 그리고 체크박스를 체크하지 않으면 OnParam이 꽤 자주 생성됩니다. 그러나 유리 절단보다 약간 적습니다. 이는 원칙적으로 오더북이 변경되면 가능하나 최적가/매도호가는 변경되지 않습니다.
MT5에서는 Quick에서 OnParam과 유사한 이벤트를 찾지 못했습니다. 이러한 이벤트가 없는 경우 가능한 한 건너뛰기로부터 자신을 보호하기 위해 논리적으로 OnBookEvent 핸들러에서 입찰/요청 을 수집(및 처리, 예를 들어 반복 제거)해야 합니다. 어떻게든 다르게, 심지어 다르게 하면 다른 입찰/매도 사례를 얻을 수 있습니다.
Kvikovites는 "아무것도 숨기지 않는다"고 주장하며 광장에서 터미널까지 모든 것을 방송합니다. 동시에 퀵은 교환 정보의 각 부분에 대한 이벤트를 생성합니다. 따라서 이러한 이벤트 처리기의 파일에 해당 데이터를 쓰는 것이 논리적입니다. 그런 다음 "모든 거래" 파일을 "주문서의 이미지" 파일과 비교합니다.
그리고 여기에 하나의 미묘함이 있습니다. 잔 자체는 컵 도착 이벤트 핸들러에 도착하지 않습니다. 그리고 핸들러에서 요청해야 합니다. 그리고 당신은 주저하고 사건을 일으킨 유리의 절단이 아니라 예를 들어 다음 유리를 얻을 수 있습니다. 저것들. 컷을 건너 뛰고 "유리에서 거래"를 얻으십시오.
MT5에서도 거의 동일합니다. 그리고 메타 인용문은 이에 대해 정직하게 경고합니다.
"최대한 빨리"은(는) 무슨 뜻인가요?
우리가 이것을 돌볼 필요가 있습니까?
;)
---
여기 있는 사람이 유리 절단면의 적합성을 확인하는 방법에 대해 이야기할 수 있습니까?
원칙적으로 어느 시점에서 차단되는지는 중요하지 않습니다.
본질이 중요하다. 그는 본질적으로 자신의 그것을 보여야합니까?
글쎄요, 혼합물은 혼합물입니다 ....
나는 Forex에 대해 전혀 이야기하지 않습니다.
다른 날 나는 그 PPC를 깨달았습니다.
그건 그렇고, 어떤 교환에서도 동일한 .ren, 가격이 동일하기 때문에 글쎄요, 크게 다르지 않습니다 - +/-, 요점이 아닙니다.
그들이 말하는 가장 중요한 것은 표시 따옴표입니다! 그리고 그들 중 어느 것이 쓰레기입니다 - 당신에게 발생하지 않았습니까 ??? ;)))
일반적으로 나는 곧 메이슨을 존경할 것이다.
돈주고 사먹지 않는게 너무 쉬워서 PPC ...........
---
여기서 뭐가 문제야????????????
당신은 항상 진실에서 실수를 찾습니다 ;)
빌어먹을 프리메이슨 피라미드, 궁극의 진실이 어디 있는지 이해할 때까지 두개골이 깨질 것입니다.
지금까지는 다음과 같습니다. 거래소는 3개의 엔티티를 발생시킵니다. 유리 흐름, 공통 흐름(입찰/매도 포함), 모든 거래의 흐름. 또한 이들 개체는 서로 동기화되지 않고 자율적인 삶을 살고 있습니다. 브로커는 스트림 내에서 데이터 일관성만 관리하면서 서로 독립적으로 스트림을 처리합니다(자체 독점 프로토콜로 재패키지하고 터미널로 변환). 터미널은 또한 이러한 스트림을 서로 독립적으로 처리(렌더링/풀 이벤트)합니다. 10-20ms의 스레드 간의 비동기화는 훌륭한 결과일 뿐입니다.
Kvikovites는 "아무것도 숨기지 않는다"고 주장하며 광장에서 터미널까지 모든 것을 방송합니다. 동시에 퀵은 교환 정보의 각 부분에 대한 이벤트를 생성합니다. 따라서 이러한 이벤트 처리기의 파일에 해당 데이터를 쓰는 것이 논리적입니다. 그런 다음 "모든 거래" 파일을 "주문서의 이미지" 파일과 비교합니다.
그리고 여기에 하나의 미묘함이 있습니다. 잔 자체는 컵 도착 이벤트 핸들러에 도착하지 않습니다. 그리고 핸들러에서 요청해야 합니다. 그리고 당신은 주저하고 사건을 일으킨 유리의 절단이 아니라 예를 들어 다음 유리를 얻을 수 있습니다. 저것들. 컷을 건너뛰고 "유리한 거래"를 받으세요.
MT5에서도 거의 동일합니다. 그리고 metaquote는 이에 대해 정직하게 경고합니다.
이벤트 핸들러에 관한 것이 아닙니다.
최적가 데이터가 전송되는 두 가지 방법이 있습니다.
1. 유리 컷
2. 공통 테이블은 최적의 가격과 함께 악기에 대한 정보를 방송합니다.
이벤트가 오더북에 의해 생성되는지 또는 기기에 대한 정보에 의해 생성되는지 여부는 전혀 중요하지 않습니다.
정보가 모든 터미널에 동일하게 제공되는 것이 중요하며 다른 브로커의 역사에서
그것은 다르고 거래는 모든 곳에서 동일하지만 요청과 입찰은 종종 다릅니다.
두 MT5 터미널에서 매도호가와 매수호가를 얻는 알고리즘은 다른 브로커에 대해 동일하므로 다음과 같이 결론을 내립니다.
이 알고리즘은 제대로 작동하지 않습니다. 견적 공백이 있습니다.
prostotrader # :
이벤트가 오더북에 의해 생성되는지 또는 기기에 대한 정보에 의해 생성되는지 여부는 전혀 중요하지 않습니다.
정보가 모든 터미널에 동일하게 제공되는 것이 중요하며 다른 브로커의 역사에서
그것은 다르고 거래는 모든 곳에서 동일하지만 요청과 입찰은 종종 다릅니다.
두 MT5 터미널에서 매도호가와 매수호가를 얻는 알고리즘은 다른 브로커에 대해 동일하므로 다음과 같이 결론을 내립니다.
이 알고리즘은 제대로 작동하지 않습니다. 견적 공백이 있습니다.
이벤트가 생성되는 방식과 생성 여부가 중요합니다. 그리고 이벤트를 일으킨 값도 핸들러에 오면 일반적으로 괜찮습니다. 왜냐하면. 가치를 놓치지 않는다는 더 큰 자신감.
Plaza는 입찰/매도를 포함하는 FORTS_COMMON_REPL 스트림을 브로드캐스트합니다. 이 정보의 일부가 QUIK에 도착하면 OnParam 이벤트가 생성됩니다. 그리고 여기에서 모호성이 시작됩니다. Quick에서 상자를 선택하고 "현재 상태로 데이터 업데이트 간격"을 초 단위로 선택할 수 있습니다. 그리고 이 간격으로 OnParam 이벤트가 생성됩니다. 물론 입찰/매도 변경 사항은 건너뜁니다. 그리고 체크박스를 체크하지 않으면 OnParam이 꽤 자주 생성됩니다. 그러나 유리 절단보다 약간 적습니다. 이는 원칙적으로 오더북이 변경되면 가능하나 최적가/매도호가는 변경되지 않습니다.
MT5에서는 Quick에서 OnParam과 유사한 이벤트를 찾지 못했습니다. 이러한 이벤트가 없는 경우 가능한 한 건너뛰기로부터 자신을 보호하기 위해 논리적으로 OnBookEvent 핸들러에서 입찰/요청 을 수집(및 처리, 예를 들어 반복 제거)해야 합니다. 어떻게든 다르게, 심지어 다르게 하면 다른 입찰/매도 사례를 얻을 수 있습니다.
OnBook 및 OnTick 주제에 대한 이벤트 처리가 병렬이 아닌 순차적으로 수행되기 때문에 실망할 수 있습니다.
Kvikovites는 "아무것도 숨기지 않는다"고 주장하며 광장에서 터미널까지 모든 것을 방송합니다. 동시에 퀵은 교환 정보의 각 부분에 대한 이벤트를 생성합니다. 따라서 이러한 이벤트 처리기의 파일에 해당 데이터를 쓰는 것이 논리적입니다. 그런 다음 "모든 거래" 파일을 "주문서의 이미지" 파일과 비교합니다.
그리고 여기에 하나의 미묘함이 있습니다. 잔 자체는 컵 도착 이벤트 핸들러에 도착하지 않습니다. 그리고 핸들러에서 요청해야 합니다. 그리고 당신은 주저하고 사건을 일으킨 유리의 절단이 아니라 예를 들어 다음 유리를 얻을 수 있습니다. 저것들. 컷을 건너 뛰고 "유리에서 거래"를 얻으십시오.
MT5에서도 거의 동일합니다. 그리고 메타 인용문은 이에 대해 정직하게 경고합니다.
"최대한 빨리"은(는) 무슨 뜻인가요?
우리가 이것을 돌볼 필요가 있습니까?
;)
---
여기 있는 사람이 유리 절단면의 적합성을 확인하는 방법에 대해 이야기할 수 있습니까?
원칙적으로 어느 시점에서 차단되는지는 중요하지 않습니다.
본질이 중요하다. 그는 본질적으로 자신의 그것을 보여야합니까?
글쎄요, 혼합물은 혼합물입니다 ....
나는 Forex에 대해 전혀 이야기하지 않습니다.
다른 날 나는 그 PPC를 깨달았습니다.
그건 그렇고, 어떤 교환에서도 동일한 .ren, 가격이 동일하기 때문에 글쎄요, 크게 다르지 않습니다 - +/-, 요점이 아닙니다.
그들이 말하는 가장 중요한 것은 표시 따옴표입니다! 그리고 그들 중 어느 것이 쓰레기입니다 - 당신에게 발생하지 않았습니까 ??? ;)))
일반적으로 나는 곧 메이슨을 존경할 것이다.
돈주고 사먹지 않는게 너무 쉬워서 PPC ...........
---
여기서 뭐가 문제야????????????
당신은 항상 진실에서 실수를 찾습니다 ;)
빌어먹을 프리메이슨 피라미드, 궁극의 진실이 어디 있는지 이해할 때까지 두개골이 깨질 것입니다.
둘 중 하나 ;)
물론 초등이지만 어디에도 알려주지 않아서 어렵다;;)
OnBook 및 OnTick 주제에 대한 테스트 고문 이 있었습니다.
지금까지는 다음과 같습니다. 거래소는 3개의 엔티티를 발생시킵니다. 유리 흐름, 공통 흐름(입찰/매도 포함), 모든 거래의 흐름. 또한 이들 개체는 서로 동기화되지 않고 자율적인 삶을 살고 있습니다. 브로커는 스트림 내에서 데이터 일관성만 관리하면서 서로 독립적으로 스트림을 처리합니다(자체 독점 프로토콜로 재패키지하고 터미널로 변환). 터미널은 또한 이러한 스트림을 서로 독립적으로 처리(렌더링/풀 이벤트)합니다. 10-20ms의 스레드 간의 비동기화는 훌륭한 결과일 뿐입니다.
브로커는 스트림 내에서 데이터 일관성만 관리하면서 서로 독립적으로 스트림을 처리합니다(자체 독점 프로토콜로 재패키지하고 터미널로 변환).
다시 당신은 "물고기 돈을 위해"?
브로커는 아무것도 하지 않습니다.
브로커 네트워크 에 있는 터미널의 서버 부분은 들어오는 정보를 처리하여 터미널로 보냅니다.
prostotrader # :
브로커 네트워크에 있는 터미널의 서버 부분은 들어오는 정보를 처리하여 터미널로 보냅니다.
의사 # :
브로커는 스트림을 처리합니다 (독점 프로토콜로 다시 패키징하고 터미널로 변환 ) .
이 댓글의 의미 차이가 보이시나요?
이 댓글의 의미 차이가 보이시나요?
:)
교육 프로그램을 시작합시다 ...
QUICK 및 MT-5는 모두 클라이언트 <--> 서버 애플리케이션입니다.
클라이언트(터미널)는 최종 사용자에게 있습니다.
서버가 브로커의 네트워크에 있습니다.
서버(MT-5, QUIK)는 네트워크와 Promserver Broker를 통해 모든 정보를 받아 처리하여 단말로 보낸다.
브로커는 이 과정을 어떤 식으로든 방해하지 않습니다.
서버 설정만 입력할 수 있습니다(예: 주문서의 깊이).
그렇다면 따옴표의 단일 기록은 신화입니까?
그렇다면 따옴표의 단일 기록은 신화입니까?
신화가 아니라 소프트웨어가 장난이 아닙니다 ...