MQL: 보안 대 기능
좋은 게시물.
Renat는 일반적으로 이것들에 와서 똥을 보지 않고 샌드 박스에서 이해하지 못한다고 말합니다.
좋은 게시물.
Renat는 일반적으로 이것들에 와서 똥을 보지 않고 샌드 박스에서 이해하지 못한다고 말합니다.
기다려보자 - 보자.
추신. 투표를 주선하는 것은 죄가 아니며 질문이 유휴 상태가 아닙니다.
Zy.ZY. 이것은 4에도 적용됩니다.
필요가 있습니다. 그리고 그러한 필요성은 가장 흥미로운 문제에서 발생합니다.
주제에서 벗어나지만 이번 기회에 그들이 한때 ResourceRead()를 만들겠다고 약속했음을 상기시켜 드리겠습니다. 이것은 최소한 터미널 내부의 전문가들에게 많은 양의 정보를 교환할 수 있는 기회를 제공할 것입니다.
모든 개발자는 스스로 결정을 내리고 _his_ 터미널로/에서 가능한 모든 것을 전송할 수 있습니다. 그러나 여기서 우리는 모든 터미널의 100%에 대한 전체 구멍의 규칙적인 구멍과 규칙적인 분포를 만들지 않을 것입니다. 또한 네트워크 http 연결을 만들지 않습니다.
다음 빌드에는 거래 서버와의 맞춤형 네트워크 상호 작용의 새로운 방법이 포함될 것이며, 이를 통해 브로커와 MQL4/5 개발자는 핸들러가 플러그인에 작성되는 서버에서 지원을 통해 터미널의 기능을 확장할 수 있습니다.
다음 빌드에는 거래 서버와의 맞춤형 네트워크 상호 작용의 새로운 방법이 포함될 것이며, 이를 통해 브로커와 MQL4/5 개발자는 핸들러가 플러그인에 작성되는 서버에서 지원을 통해 터미널의 기능을 확장할 수 있습니다.
양방향 채권의 구성은 본질적으로 MT5를 타사 응용 프로그램과 교환 간의 전송 링크로만 만들 것이라고 감히 제안합니다. 이 경우 터미널에 대한 소위 새로운 독립 애드온 프로그램의 출현은 불가피합니다. 사실 MQ의 직접적인 경쟁자는 기술에 기생하고 금융 시장에서 작업을 "더욱 편리하고 생산적으로" 만들겠다고 약속합니다. 월 $29.95.
정확히.
그리고 더욱 중요한 것은 모든 첫 번째 프로그램이 본질적으로 스파이웨어가 될 것이며 계정, 기록 및 계정 설정에 대한 중요한 정보를 많이 수집한다는 것입니다. 이 문제에서 타사 개발자에게는 브레이크가 없습니다. 보안 및 개인 정보 파괴에 신경 쓰지 않습니다. 그들은 진정으로 문제가 무엇인지 "이해하지 못합니다". 당신이 그들을 잡을 때, 그들은 마지막까지 잠금을 해제합니다. 그리고 그것은 모두 "당신은 우리에게서 한 푼의 노동력을 빼앗아갔지만 우리는 수년 동안 당신을 도왔습니다!"라는 사실로 귀결됩니다. 이것은 우리의 권리, 라이선스 및 직접적인 해킹에 대한 위반은 말할 것도 없습니다.
우리는 이미 그러한 "도움"을 충분히 보았으므로 규칙을 강화하고 있습니다.
그리고 여기에서 더 자세히 가능합니까?
브로커(또는 제3자 개발자)는 순수 MQL4/MQL5로 프로그램을 작성하고 합법적으로 배포판에 포함하고(우리는 배포판에 포함할 것입니다), 이미 작성된 지표와 전문가로 기본 차트를 설정할 수 있습니다. 우리는 브로커의 자체 배포판에 사용자 정의 프로그램(DLL이 없고 광신도 없는 순수한 MQL4/MQL5 코드만)을 포함하는 것을 반대하지 않습니다.
이 프로그램은 무역 서버에서 지원하는 자체 기능을 구현할 수 있습니다. 이를 위해 터미널의 MQL4/MQL5 프로그램에서 보낸 사용자 정의 명령 패키지를 수신하고 응답할 수 있는 MetaTrader 4/5 Server API를 기반으로 하는 서버용 플러그인이 작성되었습니다.
따라서 브로커는 클라이언트의 보안을 희생하지 않고 시스템 사용 라이센스를 위반하지 않고 터미널의 기능을 확장할 수 있습니다. 타사 개발자에게는 솔루션을 절대적으로 합법적이고 정기적으로 판매할 수 있는 새로운 기회가 있습니다.
MQL에 대한 다년간의 경험을 분석하고 그 기능을 요구 사항과 비교하려고 시도하면서 분명히 깨달았습니다.
작업에서 작업으로 나타나는 가장 일반적인 걸림돌은 양방향 정보 교환입니다 .
예, 모든 것이 간단합니다. 고대 MQL 도끼 - 전문가로부터 정보를 다운로드할 수 있는 옵션은 하나뿐입니다. 이것은 철판에 있는 파일입니다. 오늘날의 표준에 따르면 이것은 프로그래머의 고된 작업의 원시적인 도구입니다.
그리고 이 사실을 깨닫는 것만으로는 필요한 발전 방향을 이해하기에 충분하지 않습니다.
그러나 정보를 전송하기 위한 다른 옵션을 찾기 위해 얼마나 많은 코드가 삽질되었습니까!
그러나 그들은 모두 비 MQL 도구를 사용하는 것으로 귀결됩니다... 불행히도.
터미널 간, 터미널과 다른 응용 프로그램 간의 정보 교환, 사이트로 데이터 전송, 에이전트 또는 에이전트에서 전문가에게 정보 전송 - 친애하는 사용자 및 개발자인 우리 각자는 이 목록을 계속할 수 있습니다.
MQL에서 수년 간의 활발한 활동을 통해 거의 모든 가능한 시스템 도구가 조정되고 재확인되었습니다.
- 메일, FTP, 푸시 메시지의 법적 전송
- 터미널 폴더 외부에 있는 파일
- 매핑
- 파이프
- 소켓
정보 교환 기술에서 개발자는 우리에게 파이프를 제공했습니다. 그러나 어떤 이유로 잘린 형태로 제공됩니다. 기본적으로 MQL의 파이프는 클라이언트 측에서만 가능합니다.
이 기회에 나는 놀라움과 질문이 있습니다. 왜 고객에게만 있습니까? "한쪽 다리에 검은 색"으로 밝혀졌습니다 ...
보안에 대한 이러한 제한을 분석하려고 하면 아니오, MQL 서버 파이프가 보안에 어떤 식으로든 영향을 미치지 않는다는 결론에 도달했습니다. 현재 버전에서는 자체 작성 서버 exe 파일이 있어야 하므로 어쨌든 안전하지 않습니다.
개발자의 게으름 때문이 아닐까요? 그래서 그런것도 아니고 적극적으로 응원하고 발전시켜주는데...
------
1년 이상 전에 Renat 의 추천에 따라 자체 작성 dll 없이 시스템 winsock2를 MQL로 이식했습니다(이 기사 에서 이 작업을 수행하는 방법을 부분적으로 설명했습니다).
예, 즉, MQL 코드에서 이와 같이 서버를 올리고 + 비차단 모드로 전환하고 + 클라이언트를 수락하는 밀리초 타이머(그럼에도 여전히 이와 같이 )로 폴링하고 + 동일한 타이머로 서비스를 제공합니다. .
Renat는 "특정한" 기술적인 이유로 이것이 불가능하다고 말했습니다. 그러나 모든 것이 가능하고 가능한 한 최대로 가능합니다!
나는 Expert Advisor를 차트에서 바로 서버로 만들고 인터넷 상의 모든 컴퓨터에서 연결했습니다. 이것은 작업 기술의 돌파구였습니다. p2p 연결, 복사기, 동기화 장치, 최적화 장치, 분산 작업 등을 직접 대상으로 합니다.
------
따라서 MQL의 추가 개발에 대한 질문으로 돌아가서 다음과 같이 요약하고 싶습니다.
친애하는 개발자 여러분, 클라이언트/서버 기술로서 우리는 언제 고대 파일에서 훨씬 더 편안하고 빠르고 더 나은 도구로 한 걸음 더 나아가게 될까요?
결국 클라이언트 파이프를 자동으로 제공했다는 사실은 샌드박스에서 취소할 수 없는 종료 를 의미합니다. MQL의 클라이언트 파이프는 자체 작성 서버 파이프를 의미하며 그 이상입니다.
추신.
최근에는 지역 대리인에게 정보를 이전하는 것과 관련하여 중요한 주제가 하나의 예로 제기되었습니다. 이것은 당신을 위한 또 다른 모닝콜입니다. 이러한 주제가 많이 있으며 각 MQL 사용자는 지식 수준에 따라 해결하려고 합니다.
그때까지는 정보 교환을 위해 MQL에 내장된 도구의 중요성을 깨닫지 못했습니다. 그리고 특히 요구 수준을 조사하지 않았습니다.
그러나 그러한 주제를 분석한 후 명확한 결론이 나타났습니다 . 양방향 정보 교환이 있을 것입니다!
돌을 모을 때가 왔습니다.