내가 이해하는 한, 다중 통화 Expert Advisors에 대해 이러한 기능을 도입함으로써(단일 통화 Expert Advisors의 경우 이니셔티브는 의미를 잃음), 유일한 목표는 주문 실행 지연 이 없기 때문에 시간을 절약하는 것입니다. 서버 측 . 옳지 않다면 저를 수정하십시오.
또한 통신 채널을 통한 데이터 패킷 전송이라는 시간에 중요한 시간 간격이 하나만 남아 있습니다. '불확실성의 경계'를 '던지고 달려갔다' 수준으로 옮기려고 하면 이득보다 문제가 더 많다. 문제를 전체적으로 평가하는 것이 중요합니다. 타임아웃 가능성이 있는 경우 특정 상품을 거래할 수 있는 능력뿐만 아니라 원칙적으로 서버와의 통신 부족에도 영향을 미칠 가능성이 큽니다.
또한 EA에서 평가하는 방법이 명확하지 않습니다. 데이터 전송 중에 거래 주문이 손실되었거나 서버에서 오랜 시간 동안 차례를 기다리고 있습니까? 즉, 거래 주문 중복에 오류가 발생하여 MM을 위반하고 결과적으로 위험이 증가합니다. 제 생각에는 모든 전문 거래자(고문)는 자신의 거래 주문이 서버에서 실행되도록 수락되었는지 확인해야 합니다. 또한 특정 거래 요청의 상태를 이후에 명확하게 식별하기 위해( OnTrade() 함수 에서) 추가 처리가 이를 기반으로 하기 위해 서버에서 수신한 일부 고유 값이 필요합니다(거래가 완료될 때까지 만들었습니다(포지션 열기/닫기)).
OSI 네트워크 모델과 유사합니다. 거래 주문 실행의 채널이나 물리적 수준에 들어갈 필요가 없습니다. 클라이언트(MT5)가 이 전송 기능을 수행하도록 합니다. 응용 프로그램 계층에서 작업하십시오.
1. 단말기가 거래 요청을 사전 확인하여 보낼 패킷에 "포장"하고 "네트워크 대기열"에 배치하는 시간.
2. 거래 요청이 포함된 데이터 패킷이 클라이언트에서 서버로 전송된 시간.
3. 거래 요청이 서버에서 수신되고 이 티켓의 고유 식별자가 처리 풀에 추가되어 클라이언트로 전송된 시간.
4. 매매주문의 정확성 및 매매시장 배치의 전처리 시간.
잘못된 것이 있으면 저를 수정하십시오. 첫 번째 단계가 완료된 후 기다리고 싶지 않다는 것을 이해합니까? 나는 처음 세 사람의 필수 참석을 옹호합니다.
추가 토론을 위해서는 두 가지 질문에 답해야 합니다.
1. 지연의 비례 비율. 저것들. 평균적으로 위의 4개 항목 각각에 소요되는 시간을 백분율로 나타냅니다. 예를 들어 분포가 "0.5% -1.0% -1.0% -97.5%"이면 게임은 양초의 가치가 없습니다.
2. 타임아웃과 그것이 거래 전략에 미치는 영향. 솔직히 말하면 명확한 이해가 필요하지 않은 단일 TS의 이름을 지정할 수 없습니다. 주문이 서버로 전송되었는지 여부입니다. 이는 장기 및 다중 통화 차익 거래 모두에 해당됩니다. 저것들. 거래 주문의 실행에 대한 보장은 의심의 여지가 없습니다. 동의하지 않는 경우 반례를 제공하십시오.
패킷 파손, 통신 단절 등이 발생하기 때문입니다. 쓰레기. 신뢰할 수 없는. 신뢰할 수 없음 - 제거해야 합니다.
만일의 경우를 대비하여 Expert Advisors에게 발행할 거래 거래 대기열을 보관하고 배포함을 알려드립니다.
실행 시 통신 단절이 문제이며, 이를 해결하는 최선의 방법은 아직 명확하지 않습니다. 어쨌든 재접속 후에는 모든 열린 포지션 을 정기적으로 확인할 수 있습니다.
패킷 파손, 통신 단절 등이 발생하기 때문입니다. 쓰레기. 신뢰할 수 없는. 신뢰할 수 없음 - 제거해야 합니다.
따로 날아가자, 커틀릿은 따로따로.
연결 끊김은 터미널에 대한 비정상적인 상황이며 이력 분석을 포함하여 예외적으로 처리되어야 합니다.
그러나 각 거래에 대한 기록을 구문 분석하는 데 너무 많은 비용이 듭니다. Trade의 도착은 일반적인 상황이며 저렴한 비용으로 처리되어야 합니다.
안녕하세요. Vkurse는 일반적으로 비동기식이란 무엇입니까?
내가 이해하는 한, 다중 통화 Expert Advisors에 대해 이러한 기능을 도입함으로써(단일 통화 Expert Advisors의 경우 이니셔티브는 의미를 잃음), 유일한 목표는 주문 실행 지연 이 없기 때문에 시간을 절약하는 것입니다. 서버 측 . 옳지 않다면 저를 수정하십시오.
또한 통신 채널을 통한 데이터 패킷 전송이라는 시간에 중요한 시간 간격이 하나만 남아 있습니다. '불확실성의 경계'를 '던지고 달려갔다' 수준으로 옮기려고 하면 이득보다 문제가 더 많다. 문제를 전체적으로 평가하는 것이 중요합니다. 타임아웃 가능성이 있는 경우 특정 상품을 거래할 수 있는 능력뿐만 아니라 원칙적으로 서버와의 통신 부족에도 영향을 미칠 가능성이 큽니다.
또한 EA에서 평가하는 방법이 명확하지 않습니다. 데이터 전송 중에 거래 주문이 손실되었거나 서버에서 오랜 시간 동안 차례를 기다리고 있습니까? 즉, 거래 주문 중복에 오류가 발생하여 MM을 위반하고 결과적으로 위험이 증가합니다. 제 생각에는 모든 전문 거래자(고문)는 자신의 거래 주문이 서버에서 실행되도록 수락되었는지 확인해야 합니다. 또한 특정 거래 요청의 상태를 이후에 명확하게 식별하기 위해( OnTrade() 함수 에서) 추가 처리가 이를 기반으로 하기 위해 서버에서 수신한 일부 고유 값이 필요합니다(거래가 완료될 때까지 만들었습니다(포지션 열기/닫기)).
OSI 네트워크 모델과 유사합니다. 거래 주문 실행의 채널이나 물리적 수준에 들어갈 필요가 없습니다. 클라이언트(MT5)가 이 전송 기능을 수행하도록 합니다. 응용 프로그램 계층에서 작업하십시오.
서버 측 에서 주문 실행 의 지연 이 없기 때문에 시간을 절약할 수 있습니다. 옳지 않다면 저를 수정하십시오.
쿼리 결과를 기다리지 않았기 때문입니다. 일반적으로 그렇습니다. 저것들. 예금 및 시장 성과에 대해 매우 유용할 수 있습니다.
또한 통신 채널을 통한 데이터 패킷 전송이라는 시간에 중요한 시간 간격이 하나만 남아 있습니다. '불확실성의 경계'를 '던지고 달려갔다' 수준으로 옮기려고 하면 이득보다 문제가 더 많다.
음 ... 아니. 이점이 문제를 능가할 때만 사용하십시오.
제 생각에는 모든 전문 거래자(고문)는 자신의 거래 주문이 서버에서 실행되도록 수락되었는지 확인해야 합니다.
그러면 비동기 옵션이 적합하지 않습니다. 모든 것이 해결되었습니다.
더엑스퍼트
손가락으로 다시 해보자. 대략적인 구조 지연:
1. 단말기가 거래 요청을 사전 확인하여 보낼 패킷에 "포장"하고 "네트워크 대기열"에 배치하는 시간.
2. 거래 요청이 포함된 데이터 패킷이 클라이언트에서 서버로 전송된 시간.
3. 거래 요청이 서버에서 수신되고 이 티켓의 고유 식별자가 처리 풀에 추가되어 클라이언트로 전송된 시간.
4. 매매주문의 정확성 및 매매시장 배치의 전처리 시간.
잘못된 것이 있으면 저를 수정하십시오. 첫 번째 단계가 완료된 후 기다리고 싶지 않다는 것을 이해합니까? 나는 처음 세 사람의 필수 참석을 옹호합니다.
추가 토론을 위해서는 두 가지 질문에 답해야 합니다.
1. 지연의 비례 비율. 저것들. 평균적으로 위의 4개 항목 각각에 소요되는 시간을 백분율로 나타냅니다. 예를 들어 분포가 "0.5% -1.0% -1.0% -97.5%"이면 게임은 양초의 가치가 없습니다.
2. 타임아웃과 그것이 거래 전략에 미치는 영향. 솔직히 말하면 명확한 이해가 필요하지 않은 단일 TS의 이름을 지정할 수 없습니다. 주문이 서버로 전송되었는지 여부입니다. 이는 장기 및 다중 통화 차익 거래 모두에 해당됩니다. 저것들. 거래 주문의 실행에 대한 보장은 의심의 여지가 없습니다. 동의하지 않는 경우 반례를 제공하십시오.
내 생각에는 실행 중단 문제를 해결하는 가장 쉬운 방법은 실행 큐를 생성(실행 취소)하지 않고 사용자에게 재접속 시 취소를 알리는 것입니다. 이 경우 이중 상황이 더 적습니다.
서버 티켓을 반환해야 합니다. 이렇게 하면 주문이 서버에 도달하고 처리가 승인됩니다.
까다로운 클라이언트 측 대기 풀을 쌓는 것은 완전히 세련된 솔루션이 아니며 MT5 클라이언트-서버 아키텍처 설계 의 실수라고 부를 수 있습니다.
까다로운 클라이언트 측 대기 풀을 쌓는 것은 그렇게 우아하지 않습니다.
이것이 요청된 것입니다. 당신이 필요하지 않다면 아무도 당신에게 그것을 사용하도록 강요하지 않습니다.
더엑스퍼트
손가락으로 다시 해보자. 대략적인 구조 지연:
1. 단말기가 거래 요청을 사전 확인하여 보낼 패킷에 "포장"하고 "네트워크 대기열"에 배치하는 시간.
2. 거래 요청이 포함된 데이터 패킷이 클라이언트에서 서버로 전송된 시간.
3. 거래 요청이 서버에서 수신되고 이 티켓의 고유 식별자가 처리 풀에 추가되어 클라이언트로 전송된 시간.
4. 매매주문의 정확성 및 매매시장 배치의 전처리 시간.
3 더 나은 분할
3.1 스테이징
3.2 UID 전송
잘못된 것이 있으면 저를 수정하십시오. 첫 번째 단계가 완료된 후 기다리고 싶지 않다는 것을 이해합니까?
네.
나는 처음 세 사람의 필수 참석을 옹호합니다.
그리고 핑이 0.5초라면? 킥 비동기. 이 모드를 사용하는 이유는 무엇입니까?
이것이 요청된 것입니다. 당신이 필요하지 않다면 아무도 당신에게 그것을 사용하도록 강요하지 않습니다.
당신은 아직 내 질문에 대답하지 않았습니다. 다른 기호에 대한 전송 속도를 위해 거래 주문 의 실행 보장을 무시할 수 있는 경우의 구체적인 예를 들어 주시겠습니까?
당신은 아직 내 질문에 대답하지 않았습니다. 다른 기호에 대한 전송 속도를 위해 거래 주문 의 실행 보장을 무시할 수 있는 경우의 구체적인 예를 들어 주시겠습니까?
질문이 아닙니다 - 포트폴리오 거래 + 시장 실행.