기고글 토론 "DLLs을 사용하지 않고 명명된 파이프를 사용하여 MetaTrader 5와 통신하기"

새 코멘트
 

새로운 기고글 DLLs을 사용하지 않고 명명된 파이프를 사용하여 MetaTrader 5와 통신하기 가 게재되었습니다:

많은 개발자가 동일한 문제에 직면하고 있습니다 - 안전하지 않은 DLL을 사용하지 않고 거래 터미널 샌드박스로 이동하는 방법. 가장 쉽고 안전한 방법 중 하나는 정상적인 파일 작업으로 작동하는 표준 명명된 파이프를 사용하는 것입니다. 프로그램 간의 프로세서 간 클라이언트-서버 통신을 구성할 수 있습니다. C++ 및 MQL5에서 서버, 클라이언트, 두 서버 간의 데이터 교환 및 성능 벤치마크를 포함하는 실용적인 예를 살펴 보십시오.

가장 쉽고 안전한 방법 중 하나는 정상적인 파일 작업으로 작동하는 표준 명명된 파이프를 사용하는 것입니다. 프로그램 간의 프로세서 간 클라이언트-서버 통신을 구성할 수 있습니다. DLL에 대한 액세스를 사용하는 방법을 설명하는 이 항목에 대해 MetaTrader 5 터미널 간에 통신할 수 있는 DLL 없는 문서 명명된 파이프를 사용하여 MetaTrader 5 터미널 간에 통신할 수 있는 DLL 없는 솔루션에 이미 게시되어 있지만, 클라이언트 터미널의 표준적이고 안전한 기능을 사용합니다.

명명된 파이프에 대한 자세한 내용은 MSDN 라이브러리에서 확인할 수 있지만, C++ 및 MQL5의 실제 예제에 대해 알아보겠습니다. 우리는 서버, 클라이언트, 데이터 교환을 구현한 후 성능을 벤치마킹할 것입니다.

작성자: MetaQuotes

 
테스터에서 핍이 작동하나요?
 
Graff:
테스터에서 파이프가 작동하나요?

왜 서로 다른 터미널 간의 통신이 테스터에서 작동해야 하나요?

이벤트를 통해 수행하면 테스터에서 작동합니다.

 
Urain:

왜 다른 단말기 간의 통신이 테스터에서 작동해야 하나요?

왜 안될까요? 시도해보세요. 하지만 왜 그런지 모르겠어요 ... :)


이벤트를 통해 수행하면 테스터에서 작동합니다.

이벤트를 통해? 단말기 간의 통신?

;)

 

네임드 파이프라인은 로컬 에이전트에서 작동하지만 클러스터에서는 비활성화됩니다.

즉, 개별 테스트와 대규모 로컬 에이전트 모두 타사(로컬뿐만 아니라) 핍 서버에 연결할 수 있습니다.

 
MetaDriver:
왜 안될까요? 시도해 볼 가치가 있습니다. 왜 그런지 모르겠습니다. :)


이벤트를 통해서요? 단말기 간 통신을 통해서요?

;)

질문의 본질로 들어가서 사람이 테스터의 프로그램간에 통신이 필요한 경우 한 터미널의 프로그램간에 데이터 전송 작업이 표시되고 이벤트를 통해 수행 할 수 있으며이 모든 말도 안되는 일을 생략하면 내 대답은 매우 논리적입니다.
 
Urain:
사람이 테스터의 프로그램간에 통신이 필요한 경우 한 터미널의 프로그램간에 데이터를 전송하는 작업은 분명하며이 모든 말도 안되는 일을 생략하고 이벤트를 통해 수행 할 수 있으며 내 대답은 매우 논리적입니다.
나는 그것에 들어갔고, 그는 외부 프로그램에서 테스트 프로세스를 모니터링하는 데 관심이있는 것 같았습니다.
 

간단히 두 가지 방법으로 사용할 수 있습니다:

이 주제에 대한 기사가 흥미로울 것입니다.

 
Rosh:

간단히 두 가지 방법으로 사용할 수 있습니다:

이 주제에 대한 기사는 흥미로울 것입니다.

불행히도 이것은 Windows 용 C로 프로그래밍하는 방법을 아는 사람들에게만 가능합니다:

Renat:
이것은 클라이언트 지원이며 터미널에서 서버 커넥터를 만들 수 없다는 점에 유의하세요.

즉, 클라이언트-서버 기술에서 두 클라이언트는 서버 중개 없이는 서로를 볼 수 없습니다. 다른 프로그래밍 언어로 명명 된 채널을 만드는 주제를 살펴 보았지만 안타깝게도 대부분의 경우 표준 방법으로 Windows 용 클라이언트를 만들 수 있지만 Unix 용 채널은 거의 모든 곳에서 문제없이 생성됩니다.

알고리즘에 따라 두 개의 명명된 채널을 전이중으로 연결할 수 있는 EXE 셸 형태의 게이트웨이가 필요합니다:

  1. 두 개의 명명된 채널 A와 B를 생성합니다.
  2. 연결을 위해 채널 A를 수신 대기하는 첫 번째 하위 프로세스를 만듭니다.
  3. 메시지를 대기 중인 클라이언트가 채널 A에 연결한 후 채널 B에서 연결을 수신 대기하는 두 번째 하위 프로세스를 만듭니다.
  4. 첫 번째 하위 프로세스가 켜져 채널 A에서 채널 B로 바이트 스트림을 반복해서 전송합니다.
  5. 클라이언트가 채널 B에 연결하자마자 두 번째 하위 프로세스가 시작되어 채널 B에서 채널 A로 루프에서 바이트 스트림을 읽습니다.
  6. 두 번째 클라이언트는 첫 번째 메시지를 채널 B에서 채널 A로 전송하기 시작합니다.
  7. 이런 식으로 일부 클라이언트가 끊어지면 두 채널이 모두 파괴되고 지점 1로 이동합니다. 1

물론 단일 작업 MQL 스크립트에서는 클라이언트가 비동기적으로 정보를 수신하고 전송할 수 없기 때문에 전이중이 필요하지 않습니다. 그러나 반이중은 서버가 교환 프로토콜을 알고 있고 반대 모드로 전환하기 위해 한 클라이언트에서 다른 클라이언트로의 수신 전송이 끝나는 위치를 쉽게 계산할 수있는 경우에만 적합합니다. 그가 텔레파시 능력이 없기 때문에 이것을 알지 못하고 자신에게만 알려진 프로토콜을 사용하여 서로 교환하는 클라이언트에게만 알려진 경우 두 개의 하위 프로세스가있는 전이중이 필요합니다. 이러한 게이트웨이는 각 클라이언트가 다른 클라이언트와 통신 할 수있는 채널이 하나만 있고 클라이언트 측의 연결 순서가 초기주기에서 연결 가능성을 확실히 확인하는 경우 어떤 역할도하지 않기 때문에 편리합니다. 게이트웨이 알고리즘은 프로토콜에 따라 첫 번째 클라이언트가 두 번째 클라이언트가 연결되기 전에 메시지를 전송해야하는 클라이언트의 연결 가능성을 배제하고 무효로 전송이 발생하지 않습니다.

이론적으로 명명된 채널의 수는 무제한이므로 알고리즘에 따라 단일 작업 단순 게이트웨이를 생성할 수 있습니다:

  1. 게이트웨이에서 클라이언트로 전송하기 위해 첫 번째 네임드 채널이 생성됩니다.
  2. 첫 번째 클라이언트가 연결되면 클라이언트로부터 메시지를 수신하기 위해 두 번째 채널이 생성됩니다.
  3. 송신 클라이언트가 두 번째 채널에 연결한 후, 프로세스는 수신 채널에서 송신 채널로 바이트 스트림을 반복합니다.
  4. 클라이언트가 탈락하는 즉시 두 채널을 모두 제거하고 1단계로 넘어갑니다.

이 경우 반이중으로 두 클라이언트를 연결하려면 두 개의 게이트웨이가 필요하고, 단면만 사용하는 경우에는 하나의 게이트웨이가 필요합니다. 전이중 게이트웨이에 비해 단점은 MQL 스크립트에서 두 개의 채널 (수신 및 전송 용)을 작성해야하며 연결 순서 (먼저 수신 및 전송 용)를 엄격하게 준수해야한다는 것입니다 (그렇지 않으면 두 번째 채널이 생성되지 않음). 이 게이트웨이의 알고리즘은 또한 프로토콜에 따라 첫 번째 클라이언트가 두 번째 클라이언트가 연결되기 전에 메시지를 전송해야하며 공백으로의 전송이 발생하지 않는 클라이언트를 연결할 가능성을 배제합니다.

당연히 게이트웨이는 예를 들어 시작 시 명령줄을 통해 클라이언트의 수신-송신 및 연결 순서에 따라 채널 이름을 구성할 수 있는 기능을 제공해야 합니다.

C로 프로그래밍하는 사람이 이러한 게이트웨이를 만들어 EXE로 컴파일하여 여기에 게시하면 다른 프로그래밍 언어의 탬버린 없이 표준 MQL5 도구를 사용하여 스크립트, Expert Advisor 및 인디케이터 간의 연결을 쉽게 만들 수 있습니다.

이론적으로 클라이언트를 이러한 게이트웨이와 올바르게 연결하는 방법에 대한 기사를 작성하여 MQL 이외의 언어로 서버를 만들지 않도록 (C로 프로그래밍 할 수없는 사람은 나뿐이 아닐 것입니다.) C 프로그래머와 공동 저자로 특정 예제를 사용하여 작성할 수도 있습니다. 즉, 제가 작성한 글의 텍스트와 예제는 MQL로, C 프로그래머가 작성한 게이트웨이의 소스는 C 및 EXE-shniki로 제공됩니다. 비용은 분담합니다.

 
서버는 /release 디렉터리에 컴파일된 exe 파일을 포함하여 모든 소스가 소스로 되어 있어 간단합니다. 테스트를 쉽게 반복할 수 있습니다.
 
Renat:
그런데 이 예제에서는 전이중 교환을 보여 주므로 다른 사람을 기다릴 필요가 없습니다.

서버는 /release 디렉터리에 컴파일된 exe 파일을 포함하여 모두 소스에 있는 간단한 서버입니다. 테스트는 쉽게 반복할 수 있습니다.

그게 중요한 게 아닙니다. 예제를 실행해 보았습니다. 작동합니다. 그러나 그것은 쓸모가 없습니다. 즉, 나는 그것을 시도했고 그게 다입니다. 더 이상 필요하지 않기 때문에 삭제할 수 있습니다.

한편으로는 dll을 제거했지만 다른 한편으로는 응용 프로그램 사용을 위해 다른 프로그래밍 언어로 된 목발이 필요합니다.

제안 된 방법의 단점은 MQL 이외의 언어로 응용 프로그램을 개발하고 Windows API를 지원하는 프로그래머에게만 적합하다는 것입니다. 즉, 제안된 예제는 보편적이지 않으며 수정 없이는 다른 작업에 적용할 수 없습니다. 그리고 모든 사람은 각기 다른 작업을 수행합니다. 즉, 사용자는 MQL 외에 다른 언어를 공부하기 위해 두 스크립트 간의 기본 정보 교환조차도 만들어야하므로 교환 프로토콜과 관련된 일부 로직을 작성해야하는 서버를 만들어야합니다.

모든 사용자가 표준 MQL 도구 만 사용하여 연결을 만들 수 있도록 게이트웨이를 한 번 만들고 컴파일하고 모든 사용자를 위해 배포 할 것을 제안합니다.

예를 들어, 저에게는 열려 있는 원시 파일이 C로 되어 있든 닫혀 있든 아무런 차이가 없습니다. 저는 C로 아무것도 작성하지 않기 때문에 항공편을 분류하는 데 시간이 걸립니다. 심지어 같은 원시 파일을 컴파일할 수도 없습니다. 그리고 다른 많은 프로그래밍 언어와 마찬가지로 Pure Java에서는 표준 도구를 사용하여 파일 스트림을 통한 클라이언트 연결만 만들 수 있습니다. 최소한 두 개의 명명된 채널을 심볼릭으로 연결하는 게이트웨이가 있다면 아무런 문제가 없을 것입니다. 클라이언트에 교환 프로토콜을 작성하고, 몇 개의 게이트웨이를 통해 연결하고, 디버깅하면 모든 것이 작동합니다. 즉, 각 작업에 대해 별도의 서버를 설계하고 만들 필요가 없습니다.

그리고 현재, 즉 게이트웨이가 없다면 많은 사람들이 C용 개발 환경을 설치하고 새로운 프로그래밍 언어 등을 배워야 할 것입니다.

게이트웨이는 한 클라이언트에서 받은 것을 다른 클라이언트로 보내는 것에는 전혀 신경을 쓰지 않습니다. 이 논리는 멍청하지만 추가 목발없이 두 클라이언트를 결합하고 탬버린과 춤을 출 수 있습니다. 즉, 정보 교환 프로토콜과 C 언어에 대한 지식과는 무관하고 보편적이며 독립적입니다.

여기서 그들이 말했듯이 먹이는 배고픈 사람을 이해하지 못합니다. C로 무언가를 개발하는 사람들은 문제를 보지 않을 것입니다. 그리고 나머지 우리는 원하는대로이 시스템을 다룰 수 있습니다.

1234567
새 코멘트