OrderSendAsync() 함수 - 페이지 3

[Yedelkin]

기술 메시지. 우리는 하나의 주제에서 흥미로운 진술을 수집합니다.

sergeev :

예델킨 :
실행 대기열의 동시 요청 제한을 담당하는 계정 속성은 무엇입니까? 이 표시기를 프로그래밍 방식으로 찾을 수 있습니까?

OrderSendAsync = false 함수 의 결과일 뿐입니다.

그것을 따라 탐색

[Mykola Demko]

Rosh :

스레드를 흥미롭게 다시 읽어보고 실제로 확인도 해보니 이제 자동매매에 대한 어처구니 없는 차별을 발견하게 되었습니다.

다음은 수동으로 포지션 을 청산한 기록입니다. (연대기는 아래에서 위로 명확합니다)

2012.04.26 22:32:05     Trades  '686934': deal #9256820 sell 0.02 EURUSD at 1.32391 done (based on order #10091825)
2012.04.26 22:32:05     Trades  '686934': order #10091825 sell 0.02 / 0.02 EURUSD at 1.32391 done
2012.04.26 22:32:05     Trades  '686934': accepted instant sell 0.02 EURUSD at 1.32391
2012.04.26 22:32:04     Trades  '686934': instant sell 0.02 EURUSD at 1.32391

여기에서 볼 수 있는 것: 주문이 전송되고, 주문이 수락되고, 티켓이 주문에 할당되고, 마지막으로 주문이 실행됩니다(해석에 약간의 변화가 있을 수 있지만 이와 유사한 것). 모든 것이 고전적입니다.

유일한 혼란스러운 점은 Trades 이벤트가 트리거된 범주와 순서(마지막 두 범주에 대해)를 (터미널 내부에서) 절대적으로 알고 있다는 것입니다. 그렇지 않으면 그러한 주석을 표시하는 것이 불가능하지만 프로그래머는 이 정보를 얻으려면 바퀴를 재발명해야 합니다. 그리고 OrderSendAsync 함수 의 상황은 단순성을 전혀 추가하지 않았습니다.

주문 실행 속도가 빨라졌다는 점에 유의해야 합니다. 이제 대기열에 있는 주문을 확인할 시간이 없으며 이미 실행되었습니다.

---

추신: 이론적으로 4개의 거래가 올 것이며 각 거래에서 각 주문을 제어해야 하는 주문을 많이 보냈습니다.

우리는 파란색 4*Number_of_orders*Number_of_orders 의 제어 포인트를 가지고 있습니다. 10개 주문의 경우 400개, 100개의 경우 40000개입니다. 그리고 신은 금지합니다. 일부 주문에는 4개보다 적은 거래가 있으며, 그러면 전체 제어 논리가 무너지고 있습니다. 숫자 4에 있기 때문에 두 번째 주문을 보내기 전에 계속 기다리십시오(첫 번째 요청이 실행되지 않은 경우).

[Andrey Dik]

여기에서 우리 는 거래 주문 팩을 서버로 보냈습니다.

각 주문을 별도로 모니터링해야 합니까? 그리고 응답을 받는 데 얼마나 걸립니까?

[---]

joo :

각 주문을 별도로 모니터링해야 합니까?

예

그리고 응답을 받는 데 얼마나 걸립니까?

브로커마다 다릅니다. STP인 경우 유동성 공급자에게 더 많은 질문입니다.

[Mykola Demko]

sergeev :

예

브로커마다 다릅니다. STP인 경우 유동성 공급자에게 더 많은 질문입니다.

아니오, 아니오, 이것은 모두 커피 찌꺼기에 대한 운세입니다. 수동으로 창이 열리면 구매를 누르고 재견적 이벤트를 기다리거나 실행되고 확인을 누르기만 하면 됩니다.

자동 모드에서는 반복 요청 또는 모든 유형 상단을 보내기 위해 춤을 출 필요가 있는 기준점이 있어야 합니다.

위의 게시물에 추가된 위협을 다시 읽었습니다.

[---]

Urain :

아니요, 아니요, 이것은 모두 커피 찌꺼기에 대한 추측입니다. 수동으로 창이 열리면 구매를 누르고 재인용 이벤트를 기다리거나 실행되고 확인을 누르면 끝입니다.

아니요. 반환 코드 DONE(10009)에서 사례를 설명합니다. 동기식이라고 합시다.

그러나 귀하의 거래를 공급자에게 전달하는 중개인이 있습니다. 이 경우 즉시 PLACED(10008)로 반환됩니다. 그건 그렇고, 시장 주문이라면 이 답변에는 거래 티켓이 없습니다. 티켓만 주문 하세요.

그리고 OrderSendAsync의 경우 주문 티켓도 없습니다.

자동 모드에서는 반복 요청 또는 모든 유형 상단을 보내기 위해 춤을 출 필요가 있는 기준점이 있어야 합니다.

예를 들어, MT4에서도 재인용의 기준점은 무엇입니까? 무한 루프를 수행하지 않고 주문의 제거 또는 열기를 기다리지 않습니다.

모든 것이 체크된 상태 등으로 틱별로 진행됩니다.

[Yedelkin]

OrderSendAsync() 함수를 실행해 보았습니다.

 //+------------------------------------------------------------------+
//|                                               OrderSendAsync.mq5 |
//+------------------------------------------------------------------+
MqlTradeResult   res={ 0 };
MqlTradeRequest req={ 0 };
//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
void OnStart ()
  {
   req.action= TRADE_ACTION_PENDING ;
   req.symbol= _Symbol ;
   req.volume= 1.0 ;
   req.price= 3.0 ;
   req.type= ORDER_TYPE_BUY_STOP ;
   req.type_filling= ORDER_FILLING_RETURN ;
   switch (OrderSendAsync(req,res))
     {
       case    true :
         Print ( "retcode=" ,res.retcode, ", order=" ,res.order, ", deal=" ,res.deal);
         break ;
       default : Print ( "Неудача при отправке запроса функцией OrderSendAsync()" );
     }
  }

응답으로 받았습니다

2012.05.02 21:12:33 OrderSendAsync (USDCHF,M1) retcode=10008, order=0, deal=0

즉시 의문이 생겼습니다. 주문 티켓을 알 수 없는 경우에도 OrderSendAsync() 함수에 의해 전송된 거래 요청의 추가 운명을 누가 추적할 수 있습니까? 코멘트 - 그리고 그 브로커가 채워져야 합니다.

[Renat Fatkhullin]

비동기식 모드는 대량 일괄 주문 전송을 위한 것이지만 단일 트랜잭션을 위한 것은 아닙니다. 싱글의 경우 동기 모드를 사용하는 것이 좋습니다. 모든 것이 동일한 속도로 풀 서비스로 실행됩니다.

OnTrade에서 비동기 작업의 실행을 추적해야 합니다. 예, 더 복잡하지만 비동기식의 대가입니다.

[Yedelkin]

Renat :
비동기식 모드는 주문을 대량 일괄 발송하기 위한 것이지만 단일 트랜잭션을 위한 것은 아닙니다. 싱글의 경우 동기 모드를 사용하는 것이 좋습니다. 모든 것이 동일한 속도로 풀 서비스로 실행됩니다.

OnTrade에서 비동기 작업의 실행을 추적해야 합니다. 예, 더 복잡하지만 비동기식의 대가입니다.

글쎄요, 질문을 명확히 하겠습니다. 대량 주문 발송의 경우 500개 거래 요청 의 추가 운명을 누가 추적할 것입니까? 대량 주문 발송은 많은 단일 거래로 구성되어 있기 때문에 모두가 과거와 현재를 비교하는 원칙을 실제로 사용할까요? 다른 접근 방법은 없나요?

[Renat Fatkhullin]

이해의 근본은 프로세스의 동시성이
1) 적시성 및 응답의 가용성을 보장하지 않습니다.
2) 개발자 측의 계정 작업에 대해 별도의 대기열이 명시적으로 필요합니다.

즉, 작성자 자신이 OnTrade 항목을 다시 확인하고 채우면서 신청서 목록의 구성을 처리해야 합니다. 물론 고통스럽습니다.

우리는 비동기 작업의 대기열을 투명하게 유지하고 응답으로 채우고 거래자에게 대기열에서 처리된 레코드를 확인하고 추출하는 편리한 기능을 제공할 수 있습니다. 대기열은 OnTrade에서 비동기식으로 확인하거나 주문 일괄 전송 직후 주기에서 폴링하여 동기식으로 확인할 수 있습니다.

우리는 그러한 메커니즘에 대해 생각할 것입니다. 전문 개발자의 삶을 훨씬 더 쉽게 만들어 루틴을 제거합니다.