동일한 응용 프로그램 팩인 IMHO는 데모용으로만 필요하며 다른 기호에 대한 응용 프로그램은 볼륨이 다르며 물론 작업에 다른 방향이 사용됩니다. 따라서 각 게스트를 개별적으로 확인해야 하므로 팩으로 보낼 필요가 없습니다 .
음, 여기에서 선택해야 합니다. OrderSendPacketAsync 함수를 한 번 실행하거나( MqTradeRequest& request [] , MqlPacketTradeResult& packet_result) 반환 코드 10008에 대한 단일 검사로 한 번 에 500개 요소 의 미리 채워진 request[] 배열을 보냅니다. 또는 OrderSendAsync() 함수 를 500번 실행 하고 반환 코드 10008을 500번 확인 합니다.
... MqlPacketTradeRequest 구조가 MqlTradeRequest 구조의 동적 배열 구조인 경우 간단한 요청 구조용으로 설계된 서버의 전체 논리가 손상될 수 있습니다.
동적 배열을 사용하는 거래 요청이 어떻게 "서버 로직을 깨뜨릴 수 있습니까?" 특정 구조 유형의 변수를 처리하는 블록이 있는 경우 필요한 경우 이 블록을 동일한 유형의 배열의 각 요소에 적용하지 못하게 하는 것은 무엇입니까? 유사하게, 오늘날 "서버가 단순한 요청 구조를 위해 날카롭게 되었다"면, 서버가 OrderSendPacketAsync() 함수에 의해 전송된 동적 배열을 수락할 때 "단순한 요청에 맞게 조정된" 블록을 적용할 수 있도록 하는 주기를 추가하는 것을 막는 것은 무엇입니까? 구조"를 그러한 배열의 각 요소에 차례로?
비동기식 거래 작업을 수행할 때 이 요청 또는 그 요청이 어떻게 작동했는지 정확히 모릅니다. 특히, 비동기 요청 중 하나가 부분적으로 실행되었을 때 처리되지 않은 것이 얼마나 남았는지 모릅니다.
Forex에서 거래할 때와 거래소에서 거래할 때 모두 역사에서 주문의 속성이
ORDER_VOLUME_CURRENT
백로그
비동기식 요청이 얼마나 완전히 완료되었는지 명확하게 결정할 수 있습니까? 즉, Forex에서 시장가 주문을 비동기식으로 보낼 때 히스토리에 나타날 때 ORDER_VOLUME_CURRENT==0.0이면 주문이 완전히 실행되고 ORDER_VOLUME_CURRENT에 값이 0이면 이 값은 이러한 외환 시장 주문에 대해 채워지지 않은 거래량으로 간주되어야 합니까?
OrderSendAsync() 함수 가 true를 반환하고 result.retcode 필드에 코드 10008이 포함된 경우 핸드북에 따르면 이는 "전송 사실을 의미할 뿐 요청이 거래 서버에 도달했다는 보장은 없습니다. ".
질문: 비동기 요청이 터미널에서 성공적으로 전송되었지만 서버에 도달하지 못한 경우 이러한 요청에 대한 정보가 항상 기록에 포함됩니까? 즉, 비동기식 요청이 성공적으로(모든 조치에 의해) 서버로 전송되었지만 이에 대한 정보가 히스토리에 나타나지 않을 수 있습니까? 그러한 시나리오가 가능하다면 어떤 조건에서?
질문: 비동기 요청이 터미널에서 성공적으로 전송되었지만 서버에 도달하지 못한 경우 이러한 요청에 대한 정보가 항상 기록에 포함됩니까? 즉, 비동기식 요청이 성공적으로(모든 조치에 의해) 서버로 전송되었지만 이에 대한 정보가 히스토리에 나타나지 않을 수 있습니까? 그러한 시나리오가 가능하다면 어떤 조건에서?
귀하의 제안이 기존 기능을 보완하기만 하면 아무 것도 하지 않습니다. 그렇지 않으면 간단한 MqlPacketTradeRequest 구조가 어떻게 ...
... 다른 주문에 대한 요청을 보낼 수 있지만 MqlPacketTradeRequest 구조가 MqlTradeRequest 구조의 동적 배열 구조인 경우 간단한 요청 구조용으로 설계된 서버의 전체 논리가 손상될 수 있습니다.
다시 말해, 터미널 수준에서 이 패킷은 별도의 요청으로 분할되어야 하며, 이는 이 과부하를 도입하는 전체 포인트를 무효화합니다.
비동기로 인해 이 옵션에 "동의"한 것 같습니다.
어디,
packet_request는 무엇보다도 MqlTradeRequest 구조의 배열을 포함합니다 ...
그렇다면 이 모든 생각은 토론의 원료가 됩니다 :-)
동일한 응용 프로그램 팩인 IMHO는 데모용으로만 필요하며 다른 기호에 대한 응용 프로그램은 볼륨이 다르며 물론 작업에 다른 방향이 사용됩니다. 따라서 각 게스트를 개별적으로 확인해야 하므로 팩으로 보낼 필요가 없습니다 .
... MqlPacketTradeRequest 구조가 MqlTradeRequest 구조의 동적 배열 구조인 경우 간단한 요청 구조용으로 설계된 서버의 전체 논리가 손상될 수 있습니다.
내 생각에 OrderSendAsync() 함수는 주문을 보내기 위한 루프를 구성하는 대신 매개변수로 만들어야 합니다. 예를 들어 OrderSendAsync(Symbol(), 숫자, 방향). 매개변수로: - 기호, - 주문 수 , - 주문 방향(구매, 판매).
비동기식 거래 작업을 수행할 때 이 요청 또는 그 요청이 어떻게 작동했는지 정확히 모릅니다. 특히, 비동기 요청 중 하나가 부분적으로 실행되었을 때 처리되지 않은 것이 얼마나 남았는지 모릅니다.
Forex에서 거래할 때와 거래소에서 거래할 때 모두 역사에서 주문의 속성이
ORDER_VOLUME_CURRENT
비동기식 요청이 얼마나 완전히 완료되었는지 명확하게 결정할 수 있습니까? 즉, Forex에서 시장가 주문을 비동기식으로 보낼 때 히스토리에 나타날 때 ORDER_VOLUME_CURRENT==0.0이면 주문이 완전히 실행되고 ORDER_VOLUME_CURRENT에 값이 0이면 이 값은 이러한 외환 시장 주문에 대해 채워지지 않은 거래량으로 간주되어야 합니까?
질문은 https://www.mql5.com/ru/forum/3775/page28#comment_84851 에서 ORDER_VOLUME_CURRENT 속성이 주식 시장에서 사용되는 주문을 참조한다는 사실에 중점을 둡니다.
비동기 요청에 대한 정보 기록의 출현에 관한 질문입니다.
OrderSendAsync() 함수 가 true를 반환하고 result.retcode 필드에 코드 10008이 포함된 경우 핸드북에 따르면 이는 "전송 사실을 의미할 뿐 요청이 거래 서버에 도달했다는 보장은 없습니다. ".
질문: 비동기 요청이 터미널에서 성공적으로 전송되었지만 서버에 도달하지 못한 경우 이러한 요청에 대한 정보가 항상 기록에 포함됩니까? 즉, 비동기식 요청이 성공적으로(모든 조치에 의해) 서버로 전송되었지만 이에 대한 정보가 히스토리에 나타나지 않을 수 있습니까? 그러한 시나리오가 가능하다면 어떤 조건에서?
질문: 비동기 요청이 터미널에서 성공적으로 전송되었지만 서버에 도달하지 못한 경우 이러한 요청에 대한 정보가 항상 기록에 포함됩니까? 즉, 비동기식 요청이 성공적으로(모든 조치에 의해) 서버로 전송되었지만 이에 대한 정보가 히스토리에 나타나지 않을 수 있습니까? 그러한 시나리오가 가능하다면 어떤 조건에서?
요청이 서버에 도달하지 않은 경우 클라이언트 터미널에 나타날 가능성이 없습니다.
고마워! 성공적으로 전송된 비동기 요청 은 쉽게 손실되고 기록에 들어갈 수 없습니다.
성공적으로 전송 된 비동기 요청 은 쉽게 손실되고 기록에 들어갈 수 없습니다.
이는 비동기 요청이 실제로 "성공적으로 전송됨" 상태를 제공하지 않는다는 점입니다.
기능이 성공적으로 완료되었다는 것은 "클라이언트의 관점에서 볼 때 주문이 정확하고 네트워크 파이프에 던져졌고 OnTrade에서 답변을 기다립니다"라는 의미일 뿐입니다.