OrderSend() 질문 - 페이지 5

[Yedelkin]

분명히 이전 문제를 명확하게 설명하지 못했습니다. 다시 한번 시도해 보겠습니다.

ENUM_ORDER_TYPE_FILLING 열거형의 값 목록에 대한 설명은 지난 1년 동안 3번 이상 변경되었습니다. 이전 설명은 다음과 같았습니다.

ENUM_ORDER_TYPE_FILLING

식별자	설명
ORDER_FILLING_FOK	거래는 지정된 수량만큼만 주문에 명시된 가격과 같거나 그 이상의 가격으로 이루어질 수 있습니다. 현재 시장에 주문 기호에 대한 제안이 충분하지 않으면 주문이 실행되지 않습니다. 이 유형의 채우기는 실행 모드 SYMBOL_TRADE_EXECUTION_INSTANT 에서 사용됩니다. 또는 SYMBOL_TRADE_EXECUTION_REQUEST .
ORDER_FILLING_IOC	주문에 지정된 한도 내에서 시장에서 사용할 수 있는 최대 수량과 지정된 가격과 같거나 더 나은 가격으로 거래를 하기로 하는 계약. 동시에 누락된 수량에 대한 추가 주문은 하지 않습니다. 이 유형의 채우기는 실행 모드 SYMBOL_TRADE_EXECUTION_MARKET 에서만 사용할 수 있습니다. 및 SYMBOL_TRADE_EXECUTION_EXCHANGE 거래 서버의 기호 설정에 따라 다릅니다.
ORDER_FILLING_RETURN	주문에 지정된 한도 내에서 시장에서 사용할 수 있는 최대 수량과 지정된 가격과 같거나 더 나은 가격으로 거래를 하기로 하는 계약. 이 경우 이 주문에 지정된 가격으로 누락된 수량에 대해 추가 주문이 이루어집니다. 이 채우기 유형은 보류 주문( TRADE_ACTION_PENDING )에만 사용됩니다.

쉽게 볼 수 있듯이 ORDER_FILLING_RETURN과 대기 중인 주문 간에 일대일 대응이 있었습니다. 즉: ORDER_FILLING_RETURN은 대기 중인 주문에만 적용될 수 있고 모든 대기 중인 주문의 type_filling 필드는 ORDER_FILLING_RETURN 값으로만 채워질 수 있습니다.

시장가 주문( action== TRADE_ACTION_DEAL )의 경우 type_filling 필드는 서버 측에서 설정한 실행 모드에 따라 채워져야 했습니다.

따라서 특정 패러다임이 형성되었습니다. 주문이 보류 중인 경우 ORDER_FILLING_RETURN; 시장 주문인 경우 ORDER_FILLING_FOK 또는 ORDER_FILLING_IOC(모드에 따라 다름).

이제 모든 것이 거꾸로 뒤집혔습니다.

ENUM_ORDER_TYPE_FILLING

식별자	설명
ORDER_FILLING_FOK	이 실행 정책은 지정된 볼륨에서만 주문을 실행할 수 있음을 의미합니다. 현재 시장에 금융 상품의 양이 충분하지 않으면 주문이 실행되지 않습니다. 필요한 볼륨은 현재 시장에서 사용할 수 있는 여러 제안으로 구성될 수 있습니다.
ORDER_FILLING_IOC	주문에 지정된 한도 내에서 시장에서 사용할 수 있는 최대 수량에 대해 거래를 하기로 합의하는 것을 의미합니다. 전체 실행이 불가능한 경우, 가용 수량만큼 주문이 실행되며, 채워지지 않은 주문 수량은 취소됩니다.
ORDER_FILLING_RETURN	이 모드는 ORDER_TYPE_BUY_LIMIT 및 ORDER_TYPE_SELL_LIMIT 주문에만 사용됩니다. 부분실행의 경우 남은 수량의 지정가 주문은 취소되지 않고 계속 운영됩니다. ORDER_TYPE_BUY_STOP_LIMIT 및 ORDER_TYPE_SELL_STOP_LIMIT 주문의 경우 활성화 시 실행 유형이 ORDER_FILLING_RETURN인 해당 지정가 주문 ORDER_TYPE_BUY_LIMIT/ORDER_TYPE_SELL_LIMIT이 생성됩니다.

시장가 주문에만 ORDER_FILLING_FOK 및 ORDER_FILLING_IOC를 사용하는 제한이 사라졌습니다. 서버에 설정된 실행 모드에 따라 시장가 주문과 함께 ORDER_FILLING_FOK 및 ORDER_FILLING_IOC 사용에 대한 제한도 사라졌습니다. limit- 및 stop_limit-orders에서만 ORDER_FILLING_RETURN 사용에 제한이 있었습니다.

따라서 질문은 다음 과 같습니다. ORDER_FILLING_FOK 및 ORDER_FILLING_IOC 모드를 limit 및 stop_limit 주문을 포함한 모든 주문(시장 및 보류 모두)에 적용할 수 있습니까? 변경 사항을 알아낸 사람이 있습니까?

[Yedelkin]

표준 라이브러리 에는 다음과 같은 방법이 있습니다(도식적으로).

 bool CTrade::PositionClose( const string symbol, ulong deviation)
  {
   do
     {
       //--- checking
       if ( PositionSelect (symbol))
        {
         if (( ENUM_POSITION_TYPE ) PositionGetInteger ( POSITION_TYPE )== POSITION_TYPE_BUY )
           {
             //--- prepare request for close BUY position
            m_request.type = ORDER_TYPE_SELL ;
            m_request.price= SymbolInfoDouble (symbol, SYMBOL_BID );
           }
         else
           {
             //--- prepare request for close SELL position
            m_request.type = ORDER_TYPE_BUY ;
            m_request.price= SymbolInfoDouble (symbol, SYMBOL_ASK );
           }
        }
       else
        {
         //--- position not found
         m_result.retcode=retcode;
         return ( false );
        }
      m_request.action      =TRADE_ACTION_DEAL;
      m_request.volume      = PositionGetDouble ( POSITION_VOLUME );
       //--- check volume
       double max_volume= SymbolInfoDouble (symbol, SYMBOL_VOLUME_MAX );
       if (m_request.volume>max_volume)
        {
         m_request.volume=max_volume;
         partial_close= true ;
        }
       else
         partial_close= false ;
       //--- order send
       if (! OrderSend (m_request,m_result))
        {
         if (--retry_count!= 0 ) continue ;
         if (retcode== TRADE_RETCODE_DONE_PARTIAL )
            m_result.retcode=retcode;
         return ( false );
        }
      retcode= TRADE_RETCODE_DONE_PARTIAL ;
       if (partial_close) Sleep ( 1000 );
     }
   while (partial_close);
   return ( true );
  }

여기서, 포지션 볼륨이 거래를 체결하기 위한 최대 볼륨보다 큰 경우, 부분적으로 포지션을 청산하기 위한 연속적인 시도가 이루어집니다.

이 경우 OrderSend() 함수를 성공적으로 호출한 후 두 번째 지연이 설정되고 Do-while 루프의 본문에서 PositionSelect() 함수가 호출됩니다. 저것들. 서버가 시장 주문을 성공적으로 수락하면 터미널 데이터베이스의 열린 위치에 대한 정보를 업데이트하는 데 1초면 충분하고 다음 반복에서 위치에 대한 업데이트된 데이터를 수신할 수 있다고 가정합니다(여기에서 예를 들어 위치 볼륨에 대해). 하지만 2년 전 같은 메서드에서 PositionSelect() 함수를 호출하기 전 지연 시간은 3초였습니다. 따라서 질문은 다음과 같습니다.

OrderSend() 함수를 성공적으로 호출한 후 터미널 데이터베이스가 업데이트된 위치 데이터를 수신하도록 보장하려면 모든 경우에 1 초면 충분합니까 (따라서 터미널 측의 나머지 위치 볼륨을 올바르게 처리하려면)? 설명된 경우에 터미널 데이터베이스가 업데이트된 위치 데이터를 수신하도록 보장해야 하는 최대 시간은 얼마입니까?

[Olegs Kucerenko]

챔피언십에는 다음과 같은 규칙이 있습니다.

거래 조건은 가능한 한 실제에 가깝습니다.

• 거래 요청 처리 시간 2~7초

실생활에서 한 브로커(입출금 후)가 약 3초(개폐-수정)를 처리했는데 바로 NDD로 갈아타서 지금까지는 만족합니다.

[Yedelkin]

Karlson :

챔피언십에는 다음과 같은 규칙이 있습니다.

거래 조건은 가능한 한 실제에 가깝습니다.

• 거래 요청 처리 시간 2~7초

알겠습니다. 팁 감사합니다! OrderSend() 함수를 성공적으로 호출한 후 터미널 데이터베이스가 업데이트된 위치 데이터를 수신하도록 보장 하는 데 1초로 는 충분하지 않다는 것이 밝혀졌습니다.

이 결론에서 내가 제시한 표준 라이브러리의 방법은 포지션을 청산하는 대신 반전이 있을 것이라고 전혀 보장하지 않습니다. 저것들. PositionClose() 메서드가 다음 반복을 1초 동안 지연하고 거래 요청을 2 - 7배 더 오래 처리할 수 있는 경우 새로운 반복에서 PositionSelect() 함수가 위치 상태에 대한 동일한 정보를 수신할 수 있습니다. 터미널 기반 및 서버에 주문 -중복을 폭격합니다. 이 경우 전체 볼륨은 마감되는 위치의 초기 볼륨 보다 큽니다.

그렇다면 위치를 닫는 대신 역전되도록 허용하는 경우 PositionClose() 메서드에 1초 지연이 설정되는 이유는 무엇입니까? 그리고 " 가능한 한 실물에 가까운 거래 조건 "과 일치하지 않습니까?

일반적으로 OrderSend() 함수를 성공적으로 호출한 후 터미널 데이터베이스가 업데이트된 위치 데이터를 수신하도록 보장하는 기간과 표준 PositionClose() 메서드에서 1 초 지연의 이유에 대한 자세한 정보가 필요합니다.

[---]

시작하자

 if ( PositionSelect (symbol))

아무것도 보장하지 않습니다. 적용할 수 없습니다.

둘째, 터미널 데이터 업데이트에 대한 보장도 없습니다. 인위적인 TradeContextBusy를 직접 구성하고 모든 주문이 처리될 때까지 기다려야 합니다.
MQL5에서 바로 할 수는 없습니다. 일시적인 보장은 없습니다.

[Yedelkin]

sergeev :

начнем с того, что

if ( PositionSelect (symbol))

아무것도 보장하지 않습니다. 적용할 수 없습니다.

둘째, 터미널 데이터 업데이트에 대한 보장도 없습니다. 인위적인 TradeContextBusy를 직접 구성하고 모든 주문이 처리될 때까지 기다려야 합니다.
MQL5에서 바로 할 수는 없습니다. 일시적인 보장은 없습니다.

네, 계속 생각해봐야겠습니다. 헛되이 처리를 위한 예로 라이브러리에서 표준 방법을 취한 것으로 나타났습니다.

말해봐, 하지만 재산과의 거래가 역사에 나온다면

DEAL_ENTRY_OUT

시장 출구

이것은 터미널 데이터베이스의 모든 정보가 자동으로 변경되었음을 의미합니까(현재 상태로 업데이트됨)? 아니면 거래가 이미 기록에 표시되고 위치 세부 정보가 여전히 업데이트되지 않을 수 있습니까? 즉, 우리는 히스토리에 있는 거래에 대한 정보와 해당 포지션에 대한 정보가 동시에 변경되는가?라는 질문에 관심이 있습니다. 아니면 이 경우에도 터미널에서 거래와 위치가 비동기식으로 업데이트됩니까? 나는 Roche의 기사에서 이것을 포착할 수 없었습니다. 내가 이해하는 한, 그것은 터미널 기반 업데이트와 거래 요청 결과 반환 사이의 비동기를 설명합니다.

[---]

터미널의 데이터 교환 모델은 아시다시피 비동기식입니다.

따라서 거래(주문/거래/포지션의 속성 가져오기) 시 데이터 획득의 성공 여부를 분석해야 합니다. 그리고 오류(false/0)가 발생하면 거래 로직 분석을 종료합니다.

실행되고 확인되지 않은 모든 OrderSend는 기억되고 주문이 나타날 때까지 기다리며, 아직 마지막 전송에서 응답이 없는 경우 새 주문 전송을 독립적으로 차단합니다.

예를 들어 PositionSelect를 구성으로 바꾸는 것이 좋습니다.

 for ( int i= PositionsTotal ()- 1 ;i>= 0 ;i--) 
{
   if ( PositionGetSymbol (i)== Symbol ())
  {
    ....
  }

일반적으로 거래 작업 의 논리는 비동기식이어야 합니다. 터미널이 비동기식이므로 MT 서버와 유동성 공급자의 서버도 비동기식입니다.

동기화 확인 작업은 전적으로 MQL 프로그래머에게 있습니다.

[Olegs Kucerenko]

지난 챔피언십에서 이 답변을 사용하는 데 문제가 없었습니다.

https://www.mql5.com/ru/forum/4342#comment_88688

[Yedelkin]

sergeev :

예를 들어 PositionSelect를 구성으로 바꾸는 것이 좋습니다.

 for ( int i= PositionsTotal ()- 1 ;i>= 0 ;i--) 
{
   if ( PositionGetSymbol (i)== Symbol ())
  {
    ....
  }

어렵지 않다면 PositionSelect()를 사용하는 것보다 PositionsTotal() + PositionGetSymbol() 을 사용 하는 것이 어떤 이점이 있는지 설명해주세요. 세 가지 함수는 모두 동일한 터미널 기반을 참조하지만 PositionGetSymbol() 및 PositionSelect() 함수는 실패할 수 있습니다. 즉, 단말의 베이스에 위치가 존재한다면 PositionSelect() 함수와 제안된 구성 모두 실패할 수 있다. 여전히 오류 코드를 확인해야 합니다.

디자인의 특성/신뢰성은 무엇입니까? 그래서 나는 그것을 알아낼 수 없었다.

[Mario]

그의 머리 전체를 부러뜨렸다 .. 멈추지 않고 그것이 .. 그리고 많은 실수. 이것은 전문가에게 남은 것이며 작동하지 않습니다.

 void OnTick (){ if ( PositionsTotal ()< 1 ){OPEN();}}

bool OPEN(){
             MqlTradeRequest request;
             MqlTradeResult result;
             

             request.symbol       = _Symbol ;
             request.action       = TRADE_ACTION_DEAL ;
             request.type_filling = ORDER_FILLING_FOK ;
             request.deviation    = 100 ;
             request.volume       = NormalizeDouble ( 2 , 2 );
             request.type         = ORDER_TYPE_BUY ;
             request.price        = NormalizeDouble ( SymbolInfoDouble ( _Symbol , SYMBOL_ASK ), _Digits );
             request.tp           = NormalizeDouble ( SymbolInfoDouble ( _Symbol , SYMBOL_ASK ) + 500 * _Point , _Digits );
             request.sl           = NormalizeDouble ( SymbolInfoDouble ( _Symbol , SYMBOL_ASK ) - 500 * _Point , _Digits );

             OrderSend (request,result);     
                        
             if (result.retcode== 10009 || result.retcode== 10008 )   Print ( "Succsesful open" );
             else                                                Print ( "Error open: " , DoubleToString ( GetLastError (), 0 ), "  response code: " ,result.retcode);
    
   return ( true );}

이렇게하면 오류가 없지만 정지 손실이 아직 설정되지 않았습니다.

 MqlTradeRequest request={ 0 }; MqlTradeResult result={ 0 };