MQL4 대 MQL5 - 페이지 7

 
Andrei01 :
그러나 무슨 일이 일어나는지 흥미롭습니다. DC에 MT4 및 MT5 서버가 모두 있다고 가정해 보겠습니다. 이 서버는 유동성 공급자에 연결하기 전에 서로 단락되어야 합니다. 그런 다음 모든 것이 최악의 서버 매개 변수에 의해 결정되기 때문에 그러한 쌍이 있는 경우 DC에 이점이 없다는 것이 밝혀졌습니다.
:)
 
HideYourRichess :

주문이 MT5에 오는 순간부터 "유동성 공급자"에게로 가는 순간까지. 네트워크 지연은 관심 대상이 아니라 서버 지연, 처리 속도에 관심이 있습니다.

마이크로초(밀리초 미만). 데이터베이스에 개체를 추가하고 dip을 위해 애플리케이션을 버리면 됩니다.

그것은 완곡어법 "유동성 공급자" 아래에 무엇이 숨겨져 있습니까? 그리고 그 질문은 일반적으로나 Wikipedia의 인용문이 아니라 우리의 현실에 관한 것이었습니다.
간단히 말해서 유동성 공급자는 은행이고, 거래소, 즉 자산의 매매에 대한 유동성 소비자의 적용을 만족시키는 실체입니다.

응용 프로그램을 시장에 출시하지 않는 DC 작업 모델을 이 개념에 연결하려는 경우 이것이 플랫폼 자체의 운영과 관련이 없음을 이해하십시오. 이것은 비즈니스 모델과 동일한 DC의 양심에 있습니다.
플랫폼 자체는 거래자의 작업에 대해 절대적으로 정직하고 투명합니다.

그리고 당신은 누구입니까? 저자는 누구입니까?

고급 터미널 사용자.

----------------------
한 브로커의 견적

중개 회사가 운영하는 두 가지 일반적인 비즈니스 모델이 있습니다.

- 직접 처리(STP)
이 모델에서 중개 회사는 고객과 유동성 공급자 사이의 중개자입니다. STP 모델의 고객 주문은 자동으로 유동성 공급자에게 전달되며 브로커는 수수료와 스프레드의 일부를 받습니다. 여기에서 브로커는 이익이 고객의 거래 수와 직접 관련이 있기 때문에 거래량의 증가에 관심이 있습니다. STP 브로커와 클라이언트 사이에는 이해 상충이 없습니다.

- 폐쇄형 딜링센터(DC)
이 모델에서 클라이언트는 브로커를 통해 구매 및 판매합니다. 여기에서 브로커는 실제로 거래를 체결할 때 클라이언트의 상대방(두 번째 참가자) 역할을 하는 외환 딜러입니다. 클라이언트가 이기면 브로커는 이익을 잃으며 그 반대의 경우도 마찬가지입니다. Forex 시장에서 거래를 시작하는 대부분의 초보자는 경험이 없으며 자금을 잃을 확률이 95%입니다. 이 모델은 카지노와 유사하며 대부분의 고객이 예금을 잃을 수 있도록 설계되었습니다. 이 모델에는 브로커와 클라이언트의 다방향적인 이해관계가 있습니다.

----------------------

따라서 공급자에 대해 이야기할 때 첫 번째 모델을 의미합니다.
클라이언트와 플레이하는 것에 대해 이야기할 때 두 번째 모델은

거의 모든 브로커(위에 인용된 브로커 포함)는 결합된 방식에 따라 작동합니다.
소액 주문(최대 0.1랏) 또는 지속적으로 클라이언트를 병합하는 경우 두 번째 모델에 따라 작동합니다.
첫 번째에 따르면 0.1 이상 또는 수익성이 있습니다.
아무도 그의 주머니와 당신의 주머니에 들어가지 않습니다. 각 당사자는 자체 위험을 감수합니다.

그러나 이것은 플랫폼에 독립적 입니다. 교환, dukascopy, esignal 등은 이러한 모델에 따라 작동합니다. MT를 사용하지 않는 기타.
다큐멘터리 "Wallstreet Wars"를 기억한다면 첫 번째 에피소드는 뉴욕 증권 거래소의 작업을 성공적으로 보여줍니다. 실제로는 시장에 유동성이 없을 때 두 번째 계획에 따라 작업을 수행합니다. 즉, 고객 주문에 대한 상대방 역할을 합니다.

 
sergeev :

마이크로초(밀리초 미만). 데이터베이스에 개체를 추가하고 dip을 위해 애플리케이션을 버리면 됩니다.

그것이 당신이 생각하는 것입니까 아니면 실제 측정이 있었습니까? 그건 그렇고, 실제로 거기에는 또 다른 문제가 있습니다. 대량 적용의 순간, 그것이 어떻게 작동하는지입니다. 이전에는 확장성 등에 관한 것이었습니다. - 이 경우는 어떻게 되는지 궁금합니다.

세르게예프 :
간단히 말해서 유동성 공급자는 은행이고, 거래소, 즉 자산의 매매에 대한 유동성 소비자의 적용을 만족시키는 실체입니다.

응용 프로그램을 시장에 출시하지 않는 DC 작업 모델을 이 개념에 연결하려는 경우 이것이 플랫폼 자체의 운영과 관련이 없음을 이해하십시오. 이것은 비즈니스 모델과 동일한 DC의 양심에 있습니다.
플랫폼 자체는 거래자의 작업에 대해 절대적으로 정직하고 투명합니다.

은행이 하는 일과 거래소가 하는 일은 서로 다릅니다. 당신은 어떻게든 그것들을 하나의 범주로 매우 유명하게 만들었지만 한편으로는 다릅니다. 개인적으로 은행에 가지 않고 증권 거래소에 갈 것입니다.

나는 나 자신을 반복해야합니다 - 나는 DC의 양심에 무엇이 있는지 상관하지 않습니다. 질문은 다르며 응용 프로그램이 실행되는 위치와 방법이 다릅니다. 그리고 나는 Wikipedia의 인용문이 필요하지 않습니다.

세르게예프 :

고급 터미널 사용자.

그렇다면 당신의 의견은 중요하지 않습니다.

세르게예프 :

따라서 공급자에 대해 이야기할 때 첫 번째 모델을 의미합니다.
클라이언트와 플레이하는 것에 대해 이야기할 때 두 번째 모델은

거의 모든 브로커(위에 인용된 브로커 포함)는 결합된 방식에 따라 작동합니다.
소액 주문(최대 0.1랏) 또는 지속적으로 클라이언트를 병합하는 경우 두 번째 모델에 따라 작동합니다.
첫 번째에 따르면 0.1 이상 또는 수익성이 있습니다.
아무도 그의 주머니와 당신의 주머니에 들어가지 않습니다. 각 당사자는 자체 위험을 감수합니다.

그러나 이것은 플랫폼에 독립적 입니다. 교환, dukascopy, esignal 등은 이러한 모델에 따라 작동합니다. MT를 사용하지 않는 기타.

강의 감사합니다만 저는 필요없습니다.
세르게예프 :
다큐멘터리 "Wallstreet Wars"를 기억한다면 첫 번째 에피소드는 뉴욕 증권 거래소의 작업을 성공적으로 보여줍니다. 실제로는 시장에 유동성이 없을 때 두 번째 계획에 따라 작업을 수행합니다. 즉, 고객 주문에 대한 상대방 역할을 합니다.

우리는 NYSE에서 소위 전문가의 작업에 대해 이야기하고 있습니다. 그의 작업을 "두 번째 계획"(DC와 비교)으로 압축하는 것은 큰 왜곡이며 모든 것이 그렇게 배열되지 않습니다.

 
HideYourRichess :

그렇다면 당신의 의견은 중요하지 않습니다.

강의 감사합니다만 저는 필요없습니다.


글쎄, 내 임무는 플랫폼이 상인과 관련하여 수중 산호초와 함께 악이 아니며 깨끗하게 작동한다는 것을 보여주는 것이 었습니다.

임무를 완수했으면 좋겠습니다.

 
Hide # :

Mushchshchina, 수정 구슬이 파손되어 인터넷을 통해 잘못된 진단을 제공합니다.


응용 프로그램의 저장 및 전송에 대해 설명하는 이유는 이미 알려져 있습니다. 이 단계에서 지연이 발생하는 것이 흥미로웠습니다.


둘째, 누가 "유동성 제공자"의 역할을 할 수 있습니까?

"유동성 공급자"가 MT5 서버 자체의 별도 블록인 경우 - 의심의 여지가 없습니다. 하지만 플랫폼에 대한 관심 정도를 계획하기 위해 개인적으로 이것을 알아야 합니다.

"유동성 공급자"가 MT4의 오래된 10진수 서버인 경우 상황을 이해할 수 있습니다.

"유동성 제공자"가 외환 거래에 종사하는 XYZ24 은행의 서버라면 같은 것은 이해할 수 있습니다.

"유동성 공급자"가 교환 서버라면 흥미롭습니다. 그러나 증권 거래소 외부의 사람들로부터 "예, 증권 거래소에서 작동할 수 있습니다"라는 보증은 흥미롭지 않습니다. 그것이 실제로 작동하는지 확인하는 것이 흥미 롭습니다. 추신. 제공하지 않는 zhybot.

그리고 결과는 무엇입니까? 어떤 옵션이 있습니까?
 
Hide # :

그리고 저는 신중한 사람으로서 증거를 원합니다. 또는 최소한 모니터 반대편에서 누가 나를 반대하는지 이해하는 것입니다. 이것이 다른 거래자의 실제 주문이라면 좋습니다. 이들이 시장 조성자라면 이해할 수 있습니다. 그리고 이것이 다시 어딘가에 집합적으로 무언가를 출력하는 DC 서버라면 - 죄송합니다. 이해 상충이 있습니다. 개인적으로 관심이 없습니다.

간단한 것을 이해하십시오. 유리 형태의 인용문도 거의 모든 곳에서 강제 없이 쉽게 구동할 수 있으며 거래소 자체의 데이터에서 자랑스럽게 이름을 붙입니다. 문제는 애플리케이션을 통합하는 대상과 위치입니다.

글쎄, 이것도, 그리고 실제로 스레드에서 제기된 모든 질문.