2) 한 명의 Expert Advisor가 주문 삭제 요청을 보냅니다(OrderSend()).
3) 두 번째 EA는 동일한 주문을 삭제하라는 요청을 보냅니다(OrderSend()).
4) 첫 번째 EA에서 연결 + 약간의 지연이 발생하자마자 OrderSend()가 성공하고 주문이 실제로 삭제됩니다.
5) 두 번째 고문이 "중단"됩니다. OrderSend() 호출이 완료된 후 정확히 3분 후 결과: retcode=10012 comment="Request timeout"
주문이 실제로 삭제되고 첫 번째 어드바이저가 그것을 본 것을 감안할 때 교환은 그것과 아무 관련이 없으며 이것은 터미널과 어드바이저 사이의 일종의 상호 작용입니다. 서버와의 거래 작업 이 완료되면 이 작업의 실행을 기다리고 있는 첫 번째 Expert Advisor에게만 응답이 주어질 것으로 보입니다. 동일한 작업을 기다리는 다른 Expert Advisor가 있는 경우 응답을 받지 못하고 작업 실행이 시간 초과로 종료됩니다.
예, 교환에 따라 다릅니다. 나는 우리를 볼 수 없습니다.
나는 다른 사람들에 대해 모른다. 그러나 원칙은 동일합니다. 클라이언트로부터 애플리케이션을 수신하고, 프레임을 브로드캐스트하고, 다시 수신 및 브로드캐스트하는 것입니다. 전체 문제는 이러한 프레임의 빈도와 애플리케이션의 빈도입니다.
거래소도 방송합니다. 아니면 DOM 프레임이 손실되었다고 생각하십니까?
이러한 점은 별도로 인식해야 합니다. 어떤 샘플링 레이트로 사진을 촬영합니까?
이러한 점은 별도로 인식해야 합니다. 사진을 찍는 샘플링 속도는 얼마입니까?
아마도 그들의 웹사이트에 있는 문서에 있을 것입니다.
나는 다른 사람들에 대해 모른다. 그러나 원칙은 동일합니다. 클라이언트로부터 애플리케이션을 수신하고, 프레임을 브로드캐스트하고, 다시 수신 및 브로드캐스트하는 것입니다. 전체 문제는 이러한 프레임의 빈도와 애플리케이션의 빈도입니다.
대답은 이미 밝혀졌습니다.
중소기업에 대해 이야기하고 있습니다. 문서를 읽어야 합니다.
그것은 또한 FORTS, 오직 Amerovsky입니다. 선물.
서버가 다시 충돌합니다
3분간 멈춘 후 [요청 시간 초과]
디스커버리 서버, 터미널 빌드 1947.
무엇을 할까요?
정확히 3분 동안 매달린 나는 다음과 같은 경우에 여러 번 나타났습니다.
1) 짧은 시간(예: 100ms) 동안 서버와의 연결이 끊어졌습니다.
2) 한 명의 Expert Advisor가 주문 삭제 요청을 보냅니다(OrderSend()).
3) 두 번째 EA는 동일한 주문을 삭제하라는 요청을 보냅니다(OrderSend()).
4) 첫 번째 EA에서 연결 + 약간의 지연이 발생하자마자 OrderSend()가 성공하고 주문이 실제로 삭제됩니다.
5) 두 번째 고문이 "중단"됩니다. OrderSend() 호출이 완료된 후 정확히 3분 후 결과: retcode=10012 comment="Request timeout"
주문이 실제로 삭제되고 첫 번째 어드바이저가 그것을 본 것을 감안할 때 교환은 그것과 아무 관련이 없으며 이것은 터미널과 어드바이저 사이의 일종의 상호 작용입니다. 서버와의 거래 작업 이 완료되면 이 작업의 실행을 기다리고 있는 첫 번째 Expert Advisor에게만 응답이 주어질 것으로 보입니다. 동일한 작업을 기다리는 다른 Expert Advisor가 있는 경우 응답을 받지 못하고 작업 실행이 시간 초과로 종료됩니다.
내가 아는 한, 오더 북의 사본은 특정 주파수, 즉 거래소에서 방송됩니다. 모든 변화는 쉽게 얻을 수 없습니다.
그리고, 나는 아직도 이해하지 못한다. 그러나 그것으로 무엇을 해야 하는가? 특히 움직임이 심할 때 데이터가 딜레이 된다면...모스크바 교환 웹 사이트에서 "전체 주문 로그"라는 단어를 찾으십시오.
여기에서 정보 를 찾았습니다
테스트에는 Plaza II / CGate 서비스와 유사하게 일괄 처리가 비활성화된 전체 주문 로그의 스트림을 발행하는 전투 서버와 10ms 퀀트로 데이터 그룹화로 집계된 주문서를 배포하는 전투 서버가 포함되었습니다.
따라서 양자화는 10ms입니다. 아니면 다른 유용한 정보를 찾아야 했습니까?