С большими проблемами удалось это сделать (начальник отдела по работе с профессиональными клиентами ДЦ Открытие Евгений Сергеевич,. - Страница 37 - Категория: автоматические торговые системы
그러나 실제로 보내지 않았다(지연). 그러면 이것이 모든 것을 설명합니다(터미널에서 MT5 서버로 ping이 큰 이유).
터미널은 서버와 하나의 TCP 연결을 유지하며 로그, 차트 및 거래 주문이 서버와 교환됩니다. 거래 주문은 당연히 더 높은 우선 순위를 갖습니다. 거래 주문을 발행하기 위해 별도의 연결을 생성하는 시간이 몇 초로 매우 길기 때문에 하나의 연결에서 작업이 수행됩니다.
따라서 터미널에서 일어나는 일은 다음과 같습니다.
터미널의 거래 부분은 터미널의 내부 연결 관리자에게 데이터를 보냅니다.
연결 관리자는 데이터를 운영 체제에 전달합니다.
운영 체제는 인터넷으로 데이터를 전송합니다.
인터넷에서 데이터가 도착하면 운영 체제는 해당 데이터가 터미널로 왔다고 판단하고 터미널 연결 관리자를 호출하며 내부 프로토콜에 따라 이 데이터가 사용되는 터미널 구성 요소를 결정합니다.
연결의 모든 TCP 패킷에는 순차적으로 번호가 지정됩니다. 수신된 각 패킷에 대해 OS는 수신 확인을 보냅니다. OS는 또한 수신 된 패킷을보고 이러한 번호의 패킷이 수신되지 않은 것으로 확인되면 발신자에게 특수 메시지를 보냅니다. 이러한 번호로 패킷을 다시 보냅니다. 따라서 " 도중에" 패킷이 손실되더라도 애플리케이션은 이에 대한 정보를 수신하지 않습니다. 운영 체제는 양쪽에서 패킷 손실을 보충합니다. 그러나 전송에는 시간이 걸리며 OS는 모든 "이전" 패킷을 순서대로 수신할 때까지 수신된 "새" 패킷을 보내지 않습니다. 따라서 애플리케이션 측면에서 OS가 복구한 패킷 손실은 지연으로 표시됩니다.
오프닝 측면에서 트레이드 서버가 "문제" 트레이드 실행을 1-2ms 내에 수정하는 것을 볼 수 있습니다. 이는 다른 트레이드의 경우와 동일합니다. 오프닝에서 받은 현재 정보에 따르면 "교환" - "게이트웨이", "게이트웨이 거래 서버", "거래 서버 - 액세스 포인트" 섹션에서 문제가 발견되지 않았습니다. 이제 우리는 액세스 포인트와 "액세스 포인트 - 터미널"섹션을 다루고 있습니다.
2014년 12월 16일에 이 스레드를 시작했습니다.
벌써 2015년 9월입니다.
공정하게 말하면 플랫폼의 초기 개념으로 인한 전반적인 지연,
매우 빠르게 수정 되었지만 개발자가 "플로팅 싱글" 지연을 심각하게 받아들이지 않은 것은 무한한 유감입니다.
결과적으로 거래에서 치명적인 결과를 초래할 수 있습니다 ( 데모 및 실제에서 다른 브로커와 함께 수행 된 테스트에서
MT5 백엔드에서 지연이 발생하는 것은 매우 분명합니다 .
그리고 오류를 식별하는 작업을 사용자가 직접 수행한 점은 무한히 안타깝고,
Renat는 2014년 12월 29일에 작업이 계속될 것이라고 확신했지만 개발자 자신이 아닙니다.
" 때때로 단말에 대한 응답 전달의 부동 시간이 아직 차단되지 않은 경우, 우리는 이에 대해 계속 작업할 것입니다. "
마이클, 지연이 장비 결함 때문일 수도 있나요? 아니면 장비가 항상 고장없이 작동한다고 생각하십니까? 서버 하드웨어 개발자를 작성하는 것이 합리적일 수 있습니까?
블라디미르!
위의 게시물과 로그를주의 깊게 읽으십시오!
다른 브로커 - 데모와 실생활 모두에서 하나의 동일한 효과!
블라디미르!
위의 게시물과 로그를주의 깊게 읽으십시오!
다른 브로커 - 데모와 실생활 모두에서 하나의 동일한 효과!
매우 자주 전문 사무실은 중개 사업의 생성 / 유지 보수에 종사하며, 이는 차례로 거의 동일한 서버를 설치합니다. 즉, 중개인은 다르고 장비는 동일합니다 ...
다른 브로커의 서버가 동일한 랙에 있는 경우가 발생합니다...
매우 자주 전문 사무실은 중개 사업의 생성 / 유지 보수에 종사하며, 이는 차례로 거의 동일한 서버를 설치합니다. 즉, 중개인은 다르고 장비는 동일합니다 ...
다른 브로커의 서버가 동일한 랙에 있는 경우가 발생합니다...
블라디미르!
당신에게 큰 부탁이 있습니다.
환상을 가지지 마시기 바랍니다.
블라디미르!
당신에게 큰 부탁이 있습니다.
환상을 가지지 마시기 바랍니다.
이 비즈니스가 어떻게 작동하는지 모른다고 누군가가 환상을 가지고 있다는 의미는 아닙니다. 중개소를 구성하기 위해 연락처가 필요합니까?
좋아, 이것은 가사입니다. https://www.mql5.com/en/forum/38456/page37#comment_1869077 에서 고문과 함께 서버를 테스트하고 있다는 것을 정확히 이해합니다.
관심이 있으시면 여기 내 로그가 있습니다
분당 또는 초당 몇 대의 MT5 서버가 요청을 처리할 수 있는지 궁금합니다...
오늘 아침 (실제) 서버 4에 액세스:
이것을 "단일" 지연이라고 할 수 있습니까?
따라서(대기 제한 초과) 대체 검사 기능( CheckOrders() )이 활성화되었습니다.
오늘 아침 (실제) 서버 4에 액세스:
디스커버리의 정보에 따르면 AS 4는 사용하지 않는 것이 가장 좋습니다.
AS2를 사용하는 것이 좋습니다.
Michael, Discovery 액세스 포인트의 로그인 로그 분석을 바탕으로 다음과 같이 말할 수 있습니다.
1) 연결할 때 데이터 센터는 터미널에 핑을 기록합니다. 이 핑은 약 10ms 동안 지속되지만 최대 500ms의 스파이크가 있습니다.
Access Server2 2015.08.25 08:48:15.666 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 10.89 ms)
Access Server3 2015.08.25 00:07:19.069 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 500.40 ms)
Access Server3 2015.08.25 08:48:28.696 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 12.03 ms)
Access Server3 2015.08.26 04:10:52.879 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 506.13 ms)
Access Server3 2015.08.27 01:08:15.820 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 8.12 ms)
Access Server2 2015.08.27 01:08:18.776 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 7.12 ms)
Access Server2 2015.08.27 02:32:48.278 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 7.07 ms)
Access Server2 2015.08.27 09:05:51.324 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 11.65 ms)
Access Server3 2015.08.27 09:06:04.272 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 11.75 ms)
이것은 액세스 포인트에서 터미널로의 ping입니다. 전체 경로는 다음과 같습니다.
| зона ответственности Биржи | | зона ответственности Открытия | | интернет | | клиент |
[биржа (ФОРТС)] <==> [шлюз Plaza2] <===> [шлюз в MOEX] <=> [MT5 торговый сервер] <=> [Точка доступа] <================> [Терминал]
즉, MT5 터미널 - MT5 액세스 포인트에서 거래에 도달하지 않는 문제가 이미 표시됩니다.
2) 다른 클라이언트의 ping을 분석했는데 변동이 있습니다. 그러나 안정적인 패턴을 찾지 못했습니다(예: 동시에 ping이 크게 증가한 경우).
그것에 대해 무엇을 해야 합니까?
1) 터미널에 핑 로깅을 추가했으며 이 기능은 다음 베타 릴리스에서 사용할 수 있습니다. 나오면 여기에 올리겠습니다. 미래에는 (가능한) 네트워크 문제를 찾기 위해 구성 요소 간의 주기적 핑 측정을 플랫폼에 통합할 것입니다.
2) 디스커버리에서 추가 네트워크 정보를 요청했습니다. 이것이 원인을 찾는 데 도움이 되는지 봅시다.
3) 당분간 Access Server 4를 통해 작업을 해보길 권장합니다. - Access Point(2,3)가 아닌 다른 공급자를 통해 인터넷에 연결되고 Otkritie 네트워크 내의 거래 서버와 다른 방식으로 연결됩니다.
예감이 들었다...
터미널이 주문(주문)을 보냈다는 로그 를 기록하면 어떨까 하는 생각이 들었습니다.
그러나 실제로 보내지 않았다(지연). 그러면 이것이 모든 것을 설명합니다(터미널에서 MT5 서버로 ping이 큰 이유).
Михаил :
터미널이 주문(주문)을 보냈다는 로그 를 기록하면 어떨까 하는 생각이 들었습니다.
그러나 실제로 보내지 않았다(지연). 그러면 이것이 모든 것을 설명합니다(터미널에서 MT5 서버로 ping이 큰 이유).
터미널은 서버와 하나의 TCP 연결을 유지하며 로그, 차트 및 거래 주문이 서버와 교환됩니다. 거래 주문은 당연히 더 높은 우선 순위를 갖습니다. 거래 주문을 발행하기 위해 별도의 연결을 생성하는 시간이 몇 초로 매우 길기 때문에 하나의 연결에서 작업이 수행됩니다.
따라서 터미널에서 일어나는 일은 다음과 같습니다.
- 터미널의 거래 부분은 터미널의 내부 연결 관리자에게 데이터를 보냅니다.
- 연결 관리자는 데이터를 운영 체제에 전달합니다.
- 운영 체제는 인터넷으로 데이터를 전송합니다.
인터넷에서 데이터가 도착하면 운영 체제는 해당 데이터가 터미널로 왔다고 판단하고 터미널 연결 관리자를 호출하며 내부 프로토콜에 따라 이 데이터가 사용되는 터미널 구성 요소를 결정합니다.연결의 모든 TCP 패킷에는 순차적으로 번호가 지정됩니다. 수신된 각 패킷에 대해 OS는 수신 확인을 보냅니다. OS는 또한 수신 된 패킷을보고 이러한 번호의 패킷이 수신되지 않은 것으로 확인되면 발신자에게 특수 메시지를 보냅니다. 이러한 번호로 패킷을 다시 보냅니다. 따라서 " 도중에" 패킷이 손실되더라도 애플리케이션은 이에 대한 정보를 수신하지 않습니다. 운영 체제는 양쪽에서 패킷 손실을 보충합니다. 그러나 전송에는 시간이 걸리며 OS는 모든 "이전" 패킷을 순서대로 수신할 때까지 수신된 "새" 패킷을 보내지 않습니다. 따라서 애플리케이션 측면에서 OS가 복구한 패킷 손실은 지연으로 표시됩니다.
오프닝 측면에서 트레이드 서버가 "문제" 트레이드 실행을 1-2ms 내에 수정하는 것을 볼 수 있습니다. 이는 다른 트레이드의 경우와 동일합니다. 오프닝에서 받은 현재 정보에 따르면 "교환" - "게이트웨이", "게이트웨이 거래 서버", "거래 서버 - 액세스 포인트" 섹션에서 문제가 발견되지 않았습니다. 이제 우리는 액세스 포인트와 "액세스 포인트 - 터미널"섹션을 다루고 있습니다.