방금 해명했습니다. SL 레벨은 어떤 식으로든 보장되지 않고 마켓에서 요청이 있을 때만 마켓에서 실행되기 때문에 오더북에서 TP 레벨에 도달하지 않아도 됩니다. 단지. SL을 시장에서 실행하기 전에 TP 수준의 실행 서버(Dukascopy)에 의해 삭제됩니다(주문서에 있더라도). 불행히도 거래자는 거래 서버에 이상적인 연결이 있더라도 MT5에서 이 순간을 안정적으로 구현할 수 없습니다. 그리고 MT5에서는 정말 신뢰할 수 없습니다.
이 문제에 대한 솔루션은 다음과 같습니다.
관계(FILL->KILL)는 지정가 주문과 중지 주문 사이의 MT5 거래 서버 수준에서 도입되어 다음을 제공합니다.
- 중지 주문의 시장 실행 전에 이와 관련된 지정가 주문은 실행 서버에 의해 삭제됩니다.
- 지정가 주문이 실행된 후 해당 주문과 관련된 중지 주문은 실행 서버에 의해 삭제됩니다.
논의된 모든 문제는 서버에서 조건부 주문 배치를 도입하여 아주 간단하게 해결됩니다. 그건 그렇고 고전적인 교환 계획에 따라 일하는 많은 중개인이 수행합니다. 이를 위해서는 주문 시 취소 및 입력 관련 주문을 설정하는 기능을 추가해야 합니다. 논리는 기본입니다: 주문 A가 실행되면 주문 B와 C가 배치됩니다. 취소의 경우도 동일합니다: 주문 A가 실행되면 주문 B와 C가 취소됩니다. 반대의 경우도 가능합니다: 다음과 같은 경우 주문 B가 배치됩니다 주문 A가 실행됩니다.사실, 같은 것입니다. 그러면 전체 포즈를 고려하는 문제가 기본적으로 해결되고 TP와 SL을 설정하고 취소하는 것까지도 해결됩니다. 이 외에도 많은 추가 기능을 제공합니다.
Z.Y. 내가 쓴 후에, 나는 그 getch가 이미 이전 포스트에서 이것을 언급한 것을 보았다. 그러나 제한과 정지 주문 만 연결할 필요는 없습니다. 아무거나 연결할 수 있다면 훨씬 더 많은 가능성이 있습니다.
Решение данной проблемы видится так: вводится связь (FILL->KILL) на уровне торгового сервера MT5 между Limit-ордерами и Stop-ордерами, которая дает следующее: - перед тем, как сделать маркет-сиполнение Stop-ордера, удаляется Execution-сервером связанный с ним Limit-ордер. - после срабатывания Limit-ордера, удаляется Execution-сервером связанный с ним Stop-ордер.
논의된 모든 문제는 서버에서 조건부 주문 배치를 도입하여 아주 간단하게 해결됩니다. 그건 그렇고 고전적인 교환 계획에 따라 일하는 많은 중개인이 수행합니다. 이를 위해서는 주문 시 취소 및 입력 관련 주문을 설정하는 기능을 추가해야 합니다. 논리는 기본입니다: 주문 A가 실행되면 주문 B와 C가 배치됩니다. 취소의 경우도 동일합니다: 주문 A가 실행되면 주문 B와 C가 취소됩니다. 반대의 경우도 가능합니다: 다음과 같은 경우 주문 B가 배치됩니다 주문 A가 실행됩니다.사실, 같은 것입니다. 그러면 전체 포즈를 고려하는 문제가 기본적으로 해결되고 TP와 SL을 설정하고 취소하는 것까지도 해결됩니다. 이 외에도 많은 추가 기능을 제공합니다.
Z.Y. 내가 쓴 후에, 나는 그 getch가 이미 이전 포스트에서 이것을 언급한 것을 보았다. 그러나 제한과 정지 주문만 연결할 필요는 없습니다. 아무거나 연결할 수 있다면 훨씬 더 많은 가능성이 있습니다.
죄송합니다, 이해하지 못했습니다. 좋은 생각. 일종의 미니 스크립트.
그러나 문제는 이것이 집계되지 않은 위치를 저장하는 것보다 서버에 더 큰 부하가 걸린다는 것입니다.
나는 getch))))와 동일하게 작성했으며 이것은 대부분의 중개 소프트웨어에서 구현되는 100% 신뢰할 수 있고 표준적인 단계입니다.
일반적인 OCO 주문(거래 서버에서 가장 원시적인 미니 스크립트)에 의해 광범위한 기회가 제공됩니다. MT5의 FILL->KILL 플래그로 충분해 보입니다. 일부 회사(StrategyRunner라고도 함)는 스크립트와 심지어 Expert Advisor를 서버에 저장하는 경로를 택했습니다. 이 경로에는 장점(논쟁적)과 단점(논쟁적)이 있습니다. MetaQuotes는 다른 방향으로 갔다.
일반적인 OCO 주문(거래 서버에서 가장 원시적인 미니 스크립트)에 의해 광범위한 기회가 제공됩니다. MT5의 FILL->KILL 플래그로 충분해 보입니다. 일부 회사(StrategyRunner라고도 함)는 스크립트와 심지어 Expert Advisor를 서버에 저장하는 경로를 택했습니다. 이 경로에는 장점(논쟁적)과 단점(논쟁적)이 있습니다. MetaQuotes는 다른 방향으로 갔다.
솔직히. 예를 들어, 나는 한 가지에만 관심이 있습니다. 전체 위치를 구성 요소로 나누는 방법. 더 이상은 없어. 프로그래밍 방식으로 (연결 해제 및 기타 사항을 고려 하여) 위치를 하나씩 유능하게 닫는 것이 가능합니다. 지금까지 해결책이 보이지 않습니다. EA를 다시 시작하면 모든 것이 망가집니다. 그리고 그는 항상 그럴 수 있습니다.
다양한 경우에 당신의 과감한 발언(내 자격, MC의 상황 등)은 당신의 의견에 대한 관심을 다소 감소시키는 것 같아요, 그렇지 않나요?))))) 어떻게 당신에게 대답하는 것이 말이되지 않습니다 - 왜 당신의 진술에 반응합니까? 분명히 부족한 사람? )))
우선 현실과 환상을 혼동하지 마십시오. 이야기합시다.
모든 것이 진정되었습니다.
어떤 이야기를 할까요?
나는 이미 펜과 공책을 준비했습니다.
잘 듣고 있습니다.
방금 해명했습니다. SL 레벨은 어떤 식으로든 보장되지 않고 마켓에서 요청이 있을 때만 마켓에서 실행되기 때문에 오더북에서 TP 레벨에 도달하지 않아도 됩니다. 단지. SL을 시장에서 실행하기 전에 TP 수준의 실행 서버(Dukascopy)에 의해 삭제됩니다(주문서에 있더라도). 불행히도 거래자는 거래 서버에 이상적인 연결이 있더라도 MT5에서 이 순간을 안정적으로 구현할 수 없습니다. 그리고 MT5에서는 정말 신뢰할 수 없습니다.
이 문제에 대한 솔루션은 다음과 같습니다.
관계(FILL->KILL)는 지정가 주문과 중지 주문 사이의 MT5 거래 서버 수준에서 도입되어 다음을 제공합니다.
- 중지 주문의 시장 실행 전에 이와 관련된 지정가 주문은 실행 서버에 의해 삭제됩니다.
- 지정가 주문이 실행된 후 해당 주문과 관련된 중지 주문은 실행 서버에 의해 삭제됩니다.
논의된 모든 문제는 서버에서 조건부 주문 배치를 도입하여 아주 간단하게 해결됩니다. 그건 그렇고 고전적인 교환 계획에 따라 일하는 많은 중개인이 수행합니다. 이를 위해서는 주문 시 취소 및 입력 관련 주문을 설정하는 기능을 추가해야 합니다. 논리는 기본입니다: 주문 A가 실행되면 주문 B와 C가 배치됩니다. 취소의 경우도 동일합니다: 주문 A가 실행되면 주문 B와 C가 취소됩니다. 반대의 경우도 가능합니다: 다음과 같은 경우 주문 B가 배치됩니다 주문 A가 실행됩니다.사실, 같은 것입니다. 그러면 전체 포즈를 고려하는 문제가 기본적으로 해결되고 TP와 SL을 설정하고 취소하는 것까지도 해결됩니다. 이 외에도 많은 추가 기능을 제공합니다.
Z.Y. 내가 쓴 후에, 나는 그 getch가 이미 이전 포스트에서 이것을 언급한 것을 보았다. 그러나 제한과 정지 주문 만 연결할 필요는 없습니다. 아무거나 연결할 수 있다면 훨씬 더 많은 가능성이 있습니다.
를 위해: getch
Решение данной проблемы видится так:
вводится связь (FILL->KILL) на уровне торгового сервера MT5 между Limit-ордерами и Stop-ордерами, которая дает следующее:
- перед тем, как сделать маркет-сиполнение Stop-ордера, удаляется Execution-сервером связанный с ним Limit-ордер.
- после срабатывания Limit-ордера, удаляется Execution-сервером связанный с ним Stop-ордер.
이것은 하기 어렵기 때문입니다. 주문에는 다른 티켓이 있습니다.
서버와 터미널에서 필드를 하나 더 입력해야 합니다.
MQ는 이러한 비표준 단계로 이동하지 않습니다.
TP와 SL이 존재합니다. 그래서, 그것은 집계 위치에 대한 것입니다.
정수가 말했듯이 정류장은 최후의 수단입니다 :-)
아발의 경우:
이 주제는 방법에 관한 것이 아니라 전혀 수행할 수 있습니다.
그것은 할 수 있습니다.
이 주제는 여러 전문가와 하나의 총체적 입장에서 주문 실행의 신뢰성에 관한 것입니다.
귀하의 버전이 가장 신뢰할 수 없습니다.
를 위해: getch
이것은 하기 어렵기 때문입니다. 주문에 다른 티켓이 있습니다.
서버와 터미널에서 필드를 하나 더 입력해야 합니다.
MQ는 이러한 비표준 단계로 이동하지 않습니다.
TP와 SL이 존재합니다. 그래서 무엇, 그것은 집계 위치에 대한 것입니다.
정수가 말했듯이 정류장은 최후의 수단입니다 :-)
나는 getch))))와 동일하게 작성했으며 이것은 대부분의 중개 소프트웨어에서 구현되는 100% 신뢰할 수 있고 표준적인 단계입니다.
논의된 모든 문제는 서버에서 조건부 주문 배치를 도입하여 아주 간단하게 해결됩니다. 그건 그렇고 고전적인 교환 계획에 따라 일하는 많은 중개인이 수행합니다. 이를 위해서는 주문 시 취소 및 입력 관련 주문을 설정하는 기능을 추가해야 합니다. 논리는 기본입니다: 주문 A가 실행되면 주문 B와 C가 배치됩니다. 취소의 경우도 동일합니다: 주문 A가 실행되면 주문 B와 C가 취소됩니다. 반대의 경우도 가능합니다: 다음과 같은 경우 주문 B가 배치됩니다 주문 A가 실행됩니다.사실, 같은 것입니다. 그러면 전체 포즈를 고려하는 문제가 기본적으로 해결되고 TP와 SL을 설정하고 취소하는 것까지도 해결됩니다. 이 외에도 많은 추가 기능을 제공합니다.
Z.Y. 내가 쓴 후에, 나는 그 getch가 이미 이전 포스트에서 이것을 언급한 것을 보았다. 그러나 제한과 정지 주문만 연결할 필요는 없습니다. 아무거나 연결할 수 있다면 훨씬 더 많은 가능성이 있습니다.
죄송합니다, 이해하지 못했습니다. 좋은 생각. 일종의 미니 스크립트.
그러나 문제는 이것이 집계되지 않은 위치를 저장하는 것보다 서버에 더 큰 부하가 걸린다는 것입니다.
죄송합니다, 이해하지 못했습니다. 좋은 생각. 그런 미니 스크립트.
그러나 문제는 이것이 집계되지 않은 위치를 저장하는 것보다 서버에 더 큰 부하가 걸린다는 것입니다.
따라서 사용자는 여전히 이러한 응용 프로그램을 입력합니다. 사실, 모든 것이 기초적이고 어떤 자원도 먹지 않습니다. 모든 플랫폼에서 필요한 부분입니다. 예를 들어, QUIKa http://www.quik.ru/about/features/conditional-orders/
Alfa Direct http://www.alfadirect.ru/help3_3/index.htm 도 있으며 부르주아 거래 플랫폼에도 있습니다. 나는 그것이 없었을 터미널을 기억하지 못한다.
나는 getch))))와 동일하게 작성했으며 이것은 대부분의 중개 소프트웨어에서 구현되는 100% 신뢰할 수 있고 표준적인 단계입니다.
일반적인 OCO 주문(거래 서버에서 가장 원시적인 미니 스크립트)에 의해 광범위한 기회가 제공됩니다. MT5의 FILL->KILL 플래그로 충분해 보입니다. 일부 회사(StrategyRunner라고도 함)는 스크립트와 심지어 Expert Advisor를 서버에 저장하는 경로를 택했습니다. 이 경로에는 장점(논쟁적)과 단점(논쟁적)이 있습니다. MetaQuotes는 다른 방향으로 갔다.
일반적인 OCO 주문(거래 서버에서 가장 원시적인 미니 스크립트)에 의해 광범위한 기회가 제공됩니다. MT5의 FILL->KILL 플래그로 충분해 보입니다. 일부 회사(StrategyRunner라고도 함)는 스크립트와 심지어 Expert Advisor를 서버에 저장하는 경로를 택했습니다. 이 경로에는 장점(논쟁적)과 단점(논쟁적)이 있습니다. MetaQuotes는 다른 방향으로 갔다.
그들이 어디로 갔는지 아직 완전히 명확하지 않습니다.