주문에 지정된 한도 내에서 시장에서 사용할 수 있는 최대 수량과 지정된 가격과 같거나 더 나은 가격으로 거래를 하기로 하는 계약. 이 경우 이 주문에 지정된 가격으로 누락된 수량에 대해 추가 주문이 이루어집니다. 이 채우기 유형은 보류 주문(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 주문을 포함한 모든 주문(시장 및 보류 모두)에 적용할 수 있습니까? 변경 사항을 알아낸 사람이 있습니까?
예, 이 질문은 혼란스럽습니다.
ENUM_SYMBOL_TRADE_EXECUTION 과 ENUM_ORDER_TYPE_FILLING 사이에 완전한 일치가 있는 경우 두 번째 것은 분명히 불필요합니다. 터미널에서 기호 유형으로 필요한 정보를 간단히 대체하는 것이 가능합니다.
따라서 일치의 도덕성은 없으며 ENUM_SYMBOL_TRADE_EXECUTION 의 동일한 값으로ENUM_ORDER_TYPE_FILLING의 다른 값 이 허용될 가능성이 큽니다. 여기서 MQ는 가능한 옵션 테이블을 설명하지만 이 데이터는 처리 서버의 설정에 따라 달라질 가능성이 큽니다.
따라서 두 번째 도덕, 여전히 필요한 것:
그러나 요청된 주문 유형(즉시 또는 보류 중)에 대해 유효한 옵션 목록( ENUM_ORDER_TYPE_FILLING )을 반환하는 함수가 필요합니다 .
예외는 가능하지만 첫째 예외는 규칙을 확인할 뿐이고 둘째, 예외가 있으면 예외를 작성해야 합니다. 여기에 그러한 동어반복이 있습니다.
여기서 무슨 일이 일어나고 있는지 이해하십시오.
메타쿼타는 실행 유형과 실행 시간을 엉망으로 만들었습니다. 실생활에서 IOC 및 FOK 명령이 실행 시간을 참조한다는 점에서 비표준입니다.
적절한 이름으로 사용되는 주문 실행 유형 - AON. 그러나 나중에 제거되었습니다.
DC가 작동하고 주문을 채우는 FIX 사양을 살펴보십시오.
FIX 4.4 : TimeInForce < 59 > field
Type: char
Used In
Description
Specifies how long the order remains in effect. Absence of this field is interpreted as DAY. NOTE not applicable to CIV Orders.
Valid values:
0 = Day (or session)
1 = Good Till Cancel ( GTC )
2 = At the Opening (OPG)
3 = Immediate or Cancel ( IOC )
4 = Fill or Kill ( FOK )
5 = Good Till Crossing (GTX)
6 = Good Till Date7 = At the Close
메타 할당량을 사용하는 유형을 강조 표시했습니다. 그러나 여기에서 볼 수 있듯이 모두 TimeInForce <59> 태그의 동일한 그룹으로 이동합니다.
그리고 알려주세요 - 시장에 주문을 보내는 브로커가 MT 주문에서 제공된 IOC 유형과 GTD 시간을 어떻게 처리할 수 있습니까? 결국 그는 두 개의 다른 분야가 아니라 하나 의 분야를 가지고 있습니다.
따라서 각 중개인은 채우기로 수행 할 작업과 사용할 유형을 스스로 생각할 것입니다. 그리고 주문을 철회하는 방법.
여기서 구출되는 유일한 것은 시장과 보류 중인 주문 사이에 차이가 있다는 것입니다. 즉, 일부 유형의 실행은 지연만을 위한 것이고 다른 유형은 시장용입니다. 일반적으로 여기에서보고 의사 소통해야합니다.
그리고 All-Or-Nothing이라고 하는 것은 완전히 다른 ExecInst <18> 태그에 있습니다. 태그는 MT 순서로 어떤 식으로든 전송되지 않는 태그입니다. FOK 유형에 대해 간접적으로 가정됩니다(아마도).
Alex가 이 주제를 관리하도록 하십시오. 불행히도, 나는 이러한 문제에서 수영합니다. SD로 제안하고 그들과 채팅하십시오. 당신은 주제에 몇 가지 순서를 가져와야합니다. 그리고 결국 지금은 전문 프로그래밍에 완전히 사용할 수 없습니다.
하아. 내가 바보이거나 스키가 가지 않습니다.
매월 메타쿼터가 새로운 거래소나 시장에 연결된다는 것을 직접 확인할 수 있습니다. 따라서 그들은 이러한 목적을 위해 다리를 만듭니다. 나는 이 상황에서 그들의 프로그래머가 문제 없이 MT와 FIX에 합류한다고 결론지었습니다. 즉, FOK 및 GTC 시간 유형을 결합하는 데 성공합니다. 이는 작업이 진행 중이기 때문에 가까운 장래에 아무 것도 변경하지 않을 것임을 의미합니다. 동시에 (내가 이해한대로) 교환을 위해 MT의 브리지는 AON 또는 부분의 두 가지 유형만 설정할 수 있습니다. 그리고 MT Return에서 발명 - 아마도 부분적으로 갈 것입니다.
일반적으로 FIX 브로커와 MT 서버 간의 상호 작용 문제는 MT에서 공급자로 다리를 만드는 브로커의 프로거(progers)의 기술 및 이해 수준에 있습니다. 그리고 메타쿼터 자체가 오랫동안 적극적으로 플랫폼을 시장에 홍보해 왔으며, 이는 MT 서버의 내부 구조가 현실과 매우 일치한다는 것을 의미하기 때문에 메타쿼터가 아무것도 바꿀 것이라고 생각하지 않습니다.
그의 머리 전체를 부러뜨렸다 .. 멈추지 않고 그것이 .. 그리고 많은 실수. 이것은 전문가에게 남은 것이며 작동하지 않습니다.
이렇게하면 오류가 없지만 정지 손실이 아직 설정되지 않았습니다.
분명히 이전 문제를 명확하게 설명하지 못했습니다. 다시 한번 시도해 보겠습니다.
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 주문을 포함한 모든 주문(시장 및 보류 모두)에 적용할 수 있습니까? 변경 사항을 알아낸 사람이 있습니까?
예, 이 질문은 혼란스럽습니다.
ENUM_SYMBOL_TRADE_EXECUTION 과 ENUM_ORDER_TYPE_FILLING 사이에 완전한 일치가 있는 경우 두 번째 것은 분명히 불필요합니다. 터미널에서 기호 유형으로 필요한 정보를 간단히 대체하는 것이 가능합니다.
따라서 일치의 도덕성은 없으며 ENUM_SYMBOL_TRADE_EXECUTION 의 동일한 값으로 ENUM_ORDER_TYPE_FILLING 의 다른 값 이 허용될 가능성이 큽니다 . 여기서 MQ는 가능한 옵션 테이블을 설명하지만 이 데이터는 처리 서버의 설정에 따라 달라질 가능성이 큽니다.
따라서 두 번째 도덕, 여전히 필요한 것:
그러나 요청된 주문 유형(즉시 또는 보류 중)에 대해 유효한 옵션 목록( ENUM_ORDER_TYPE_FILLING )을 반환하는 함수가 필요합니다 .
옵션이 많지 않으므로 "|"를 통해 int로 밀어넣을 수 있습니다.
내가 틀렸다면, 이 질문을 맛보기 위해 담배를 피울 수 있는 마법의 펜델을 주세요.
이 문제를 해결하기 위해 나는 표준 라이브러리 에 들어갔다.
일반적으로이 질문은 전혀 처리되지 않고 편안한 상속을위한 기능을 제공했으며 CTrade 클래스 자체에서 SetTypeFilling()이 사용되지 않고 type_filling 필드가 기본 0으로 초기화되며 이는 ORDER_FILLING_FOK에 따라 열거.
그게 다야, 더 이상 움직임이 없습니다. 그리고 이 필드가 인터페이스에 없기 때문에 클래스의 채우기가 자동화된다고 생각했습니다.
일반적으로 위협, 우리는 답변을 기다리고 있습니다. 긁어 모으는 방법 :)지금까지는 원하는 답을 얻을 때까지 서버를 망치는 한 가지 방법이 있습니다.
밤에보고 기뻐서 배에 배앓이 웃었습니다.
중국인들이 펜타곤의 중앙 서버를 해킹했다.
각 중국인은 암호를 한 번 시도했습니다.
매초마다 "마오쩌둥"을 입력했습니다.
5*10^7 시도에서 서버는 비밀번호가 "Mao Tse Tung"이라는 데 동의했습니다.
지금까지는 원하는 답을 얻을 때까지 서버를 망치는 한 가지 방법이 있습니다.
멍청한 출구.
DT와 함께 시작하기 위해 이야기할 것입니다. 그들이 지원하는 실행 유형 과 실행 유형에 해당하는 메타 인용 목록 유형을 찾으십시오.
메타 따옴표가 발명되었다는 사실(3가지 채우기 유형과 3가지 시간 유형)이 실제 중개인에서 주문을 작성할 때 현실을 반영한다는 의미는 아닙니다.
멍청한 출구.
DT와 함께 시작하기 위해 이야기할 것입니다. 그들이 지원하는 실행 유형 과 실행 유형에 해당하는 메타 인용 목록 유형을 찾으십시오.
3가지 충전 유형과 3가지 시간 유형의 메타쿼타가 발명되었다는 사실이 실제 브로커에서 주문을 작성할 때 현실을 반영한다는 의미는 아닙니다.
여기 나는 거의 동일합니다. 모두 서버 설정에 따라 다릅니다.
하지만 각 DC를 노크하는 것도 문제가 됩니다.
글쎄, 한 프로그래머는 노크할 것이다. 글쎄, 다른 프로그래머는
그러나 모든 것을 우회하고 코드에 스위치 거래를 작성하는 것은 과도합니다.
PS는 모든 거래에 대해 일반 코드가 통일된 방식으로 작성된다는 데 동의합니다.
예외는 가능하지만 첫째 예외는 규칙을 확인할 뿐이고 둘째, 예외가 있으면 예외를 작성해야 합니다.
여기에 그러한 동어반복이 있습니다.
여기에 나는 거의 동일합니다. 모두 서버 설정에 따라 다릅니다.
하지만 각 DC를 노크하는 것도 문제가 됩니다.
글쎄, 프로그래머는 하나, 다른 하나,
그러나 모든 것을 우회하고 코드에 스위치 거래를 작성하는 것은 과도합니다.
PS는 모든 거래에 대해 일반 코드가 통일된 방식으로 작성된다는 데 동의합니다.
예외는 가능하지만 첫째 예외는 규칙을 확인할 뿐이고 둘째, 예외가 있으면 예외를 작성해야 합니다. 여기에 그러한 동어반복이 있습니다.
여기서 무슨 일이 일어나고 있는지 이해하십시오.
메타쿼타는 실행 유형과 실행 시간을 엉망으로 만들었습니다. 실생활에서 IOC 및 FOK 명령이 실행 시간을 참조한다는 점에서 비표준입니다.
적절한 이름으로 사용되는 주문 실행 유형 - AON. 그러나 나중에 제거되었습니다.
DC가 작동하고 주문을 채우는 FIX 사양을 살펴보십시오.
메타 할당량을 사용하는 유형을 강조 표시했습니다. 그러나 여기에서 볼 수 있듯이 모두 TimeInForce <59> 태그의 동일한 그룹으로 이동합니다.
그리고 알려주세요 - 시장에 주문을 보내는 브로커가 MT 주문에서 제공된 IOC 유형과 GTD 시간을 어떻게 처리할 수 있습니까? 결국 그는 두 개의 다른 분야가 아니라 하나 의 분야를 가지고 있습니다.
따라서 각 중개인은 채우기로 수행 할 작업과 사용할 유형을 스스로 생각할 것입니다. 그리고 주문을 철회하는 방법.
여기서 구출되는 유일한 것은 시장과 보류 중인 주문 사이에 차이가 있다는 것입니다. 즉, 일부 유형의 실행은 지연만을 위한 것이고 다른 유형은 시장용입니다. 일반적으로 여기에서보고 의사 소통해야합니다.
그리고 All-Or-Nothing이라고 하는 것은 완전히 다른 ExecInst <18> 태그에 있습니다. 태그는 MT 순서로 어떤 식으로든 전송되지 않는 태그입니다. FOK 유형에 대해 간접적으로 가정됩니다(아마도).
...
Alex가 이 주제를 관리하도록 하십시오. 불행히도, 나는 이러한 문제에서 수영합니다.
SD로 제안하고 그들과 채팅하십시오.
당신은 주제에 몇 가지 순서를 가져와야합니다.
그리고 결국 지금은 전문 프로그래밍에 완전히 사용할 수 없습니다.
Alex가 이 주제를 관리하도록 하십시오. 불행히도, 나는 이러한 문제에서 수영합니다.
SD로 제안하고 그들과 채팅하십시오.
당신은 주제에 몇 가지 순서를 가져와야합니다.
그리고 결국 지금은 전문 프로그래밍에 완전히 사용할 수 없습니다.
하아. 내가 바보이거나 스키가 가지 않습니다.
매월 메타쿼터가 새로운 거래소나 시장에 연결된다는 것을 직접 확인할 수 있습니다. 따라서 그들은 이러한 목적을 위해 다리를 만듭니다.
나는 이 상황에서 그들의 프로그래머가 문제 없이 MT와 FIX에 합류한다고 결론지었습니다.
즉, FOK 및 GTC 시간 유형을 결합하는 데 성공합니다. 이는 작업이 진행 중이기 때문에 가까운 장래에 아무 것도 변경하지 않을 것임을 의미합니다.
동시에 (내가 이해한대로) 교환을 위해 MT의 브리지는 AON 또는 부분의 두 가지 유형만 설정할 수 있습니다. 그리고 MT Return에서 발명 - 아마도 부분적으로 갈 것입니다.
일반적으로 FIX 브로커와 MT 서버 간의 상호 작용 문제는 MT에서 공급자로 다리를 만드는 브로커의 프로거(progers)의 기술 및 이해 수준에 있습니다. 그리고 메타쿼터 자체가 오랫동안 적극적으로 플랫폼을 시장에 홍보해 왔으며, 이는 MT 서버의 내부 구조가 현실과 매우 일치한다는 것을 의미하기 때문에 메타쿼터가 아무것도 바꿀 것이라고 생각하지 않습니다.