("서버 시간" - "클라이언트 시간") --- 상수가 아닌가요? 틱당 가격 증분을 저장할 수 있는데 왜 가격을 저장합니까?
그리고 의사소통이 단절되거나 방해가 된다면 어떤 증분부터 시작하시겠습니까?
글쎄, 또 다른 질문 - 왜이 모든 것이 필요합니까? (따옴표를 밀리초로 바인딩)
다른 도구 및 다른 브로커의 틱을 추가로 동기화합니다.
xnsnet - 제 생각에는 정보를 틱(인코딩 시간, 간격 등)으로 압축하면 훨씬 더 어려워집니다. 후속 처리. 서로 다른 도구와 브로커, 그리고 더 나은 정보 기관에 대해 시간이 동기화된 단일 틱 스트림을 생성하는 것이 필요합니다. 이렇게 하면 저장된 정보의 양이 크게 증가하지만 분석 및 예측에 중점을 둔 기존 표준 패키지로 처리할 수 있습니다. 그렇지 않으면 처리 중에 다시 디코딩되어 단일 스트림으로 배포되어야 합니다. 인코딩된 정보를 이해하고 이를 체계화하는 것 외에 작업은 훨씬 더 어려울 것입니다.
예, Pilgrim, 정보를 압축한다는 것은 동일한 DC 서버 또는 데모 서버를 사용하여 여러 클라이언트의 데이터를 최종적으로 수렴하는 것을 의미했습니다. 당연히 압축 알고리즘을 사용하지 않을 예정입니다. :) 앞으로는 이 작업을 축소라고 부를 것입니다. 예를 들어 꽤 오래 전에 처리된 한 달 전의 이력입니다. 실시간 롤업된 데이터가 다시 롤업될 수 있다고 생각한다고 가정해 보겠습니다. 예를 들어 데이터를 제공하는 클라이언트의 품질이 좋지 않은 경우 이 데이터는 불필요한 것으로 버려질 수 있습니다. 좋은 품질 테스트를 거쳐 좋은 품질은 다른 여러 클라이언트(예: 다른 IP 주소 및 다른 주소 범위를 사용하여 고려할 옵션)로부터 동일한 데이터를 수신함으로써 확인됩니다. 이 모든 것이 보기보다 어렵지는 않습니다. 개발자인 저는 이러한 모든 조치를 잘 알고 있으므로 안심하셔도 됩니다.
댓글: 그런 서버의 타당성에 대한 또 다른 결론이 있습니다. 처음에는 스스로 할 수 있는 것, 즉 스스로 정보를 수집하는 것에 대해 생각한 다음 데이터를 사용하여 이를 처리할 글로벌 서버에 대한 결론에 도달했습니다. 따라서 우리는 여러 브로커와 서버에 대한 독립적인 모니터링을 제거하고 이러한 책임을 동일한 클라이언트에 할당하고 필요한 범위 내에서 서버를 돕는 정보를 대가로 제공합니다. 결과적으로 우리는 우리 자신의 노력에 의지하지 않고 다른 DC를 모니터링할 수 있는 기회를 얻습니다. 동시에 모든 클라이언트로부터 정보를 흡수하는 것이 아니라 서버 자체에서 선택한 정보만 소스 선택 방법은 클라이언트의 수와 차이, 갑옷 피어싱(흡수 및 전달 속도)에 따라 다릅니다. , 일반적으로 가장 중요한 매개변수입니다.
하나의 서버가 여러 벤더 클라이언트를 감당할 수 없다는 것을 알기 때문에 위임에 대해서도 같은 방식으로 생각하거나 클러스터를 사용하여 구현해야 합니다. 그러나 이것은 그들이 말하는 것처럼 지금은 그렇게 중요한 작업이 아닙니다 :) 요점은 분명합니다 :) 나는 프로젝트 가 아직 존재하지 않고 시작되지도 않았다는 점에 주목합니다. 나는 머리 속에서 일반적인 아이디어를 형성하는 동시에 동시에 이 주제에서 그렇지 않으면 그들은 이미 여기에서 저를 규정합니다. 아, 프로젝트 시작? 예? 응. 흥미롭습니다 :) 오히려 시작하기 전에 가치를 결정합니다. 많은 것이 이미 명확하지만 이미 많은 것이 명확합니다 :) 이미 여러 번 시작하고 지연되었지만 플러스가 있지만 조만간 다른 사람의 과일을 대신 사용합니다. 오랜 시간이 지난 후에야 :) 아마도 내가 처음이 아니고 마지막이 아닐 것입니다 :) 어떤 프로젝트를 수행하기 전에 모든 것을 자세히 생각해야 하므로 걸려 넘어지는 것이 이미 역겹습니다. , 특히 "죽은"과 같은 단어가 이런저런 이유로 습관이 되었을 때 :) 그렇기 때문에 주제를 개발하고, 참여하고, 논쟁하고, 진실을 밝히고, 다양한 모순을 처리해야 합니다. 이 모든 것에 감사드립니다. 아마도 우리는 함께 프로젝트의 중요성을 결정할 것입니다. :) 주제에 대한 모든 의견은 내용을 연구했다면 중요하다는 것을 상기시켜 드리겠습니다. 이 프로젝트가 비상업적인 용도로 공개되고 공개적으로 사용 가능하다면 서버 부분은 확실합니다 :) 저는 일반적으로 최근에 거의 모든 것을 공개적으로 하고 있습니다. 이에 대한 기대가 큽니다 :) 그럴 필요가 없습니다 라이선스를 제어하고, 하나의 프로그램만 지원하면 기부, 모든 참가자는 기부금의 일부로 보상을 받게 됩니다. 기부금이 있다면 기부를 의미합니다 :) 무언가를 판매하려면 이 사실을 배제하지 않고 생성해야 합니다. 회사, 사람 유치 등 비즈니스 환경에서 이 프로젝트는 거래자가 지원하거나 지원하지 않을 수 있습니다. 그렇지 않으면, 나는 당신 자신이 모든 것을 완벽하게 이해한다고 생각합니다. 열린 프로젝트가 더 빨리 개발되고 더 빨리 구현됩니다. 특히 개시자가 하나만 있고 지원이 없는 경우에 그렇습니다. 솔직히 누가, 어떻게 하느냐가 중요한 작업의 수준이 아니라 하는 것이 가장 중요합니다 :)
순례자 : 우리가 그리는 창에서 악기에 대한 닫기 선은 MT에서 녹색으로 그려집니다. 나머지는 리스케일링 후 부과합니다. 첨부파일 예시에서는 창에 코드로 로드할 수 없었습니다. 파일 자체가 약간 다른 작업을 위해 설계되었으므로 약간의 독창성을 가지고 있으며, 게다가 MQL을 모르고 아주 서투른 글을 씁니다.
글쎄, 이제 이해합니다. 이것은 표시기 코드의 모든 것을 그리는 표시기 창입니다.
맞아요, 악기 해도가 표시되는 창과 같은 창을 직접 만드는 것이 더 좋겠지만 어떻게 해야할지 모르겠습니다. 이것은 다양한 계측기의 스케일 차트 를 하나의 창에 표시할 뿐만 아니라 시간에 동기화하기 위해 필요합니다. 하나의 척도는 완전한 객관적인 그림을 제공하지 않습니다. 다른 도구에 대한 다른 위치의 간격으로 인해 다른 도구의 차트가 서로 상대적으로 이동하며 이는 인식 그림과 추가 계산의 정확성을 모두 위반합니다. 이제 막 동기화 프로그램을 만들기 시작했는데 아쉽게도 오늘 디버깅을 끝낼 시간이 없었고 내일부터 인터넷이 일주일간 꺼져서 일주일만에 결과를 올리겠습니다. 이 때 나는 당신에게 작별인사를 합니다.
내가 확장 프로그램에서 무엇을 하고 있는지 보고 싶지 않은 사람들을 위해, 실제로 특별한 것은 없습니다. 틱은 다른 각도에서만 틱입니다. :) 그렇지 않으면 사이트의 비디오 기능을 확인했습니다 :) 마지막으로 확인했습니다 :) 솔직히 말해서 snagit은 서비스로 과부하가 걸리고 프로세서의 지속적인 부하가 20에서 20 사이이기 때문에 내 컴퓨터에서 마지막 리소스를 제거합니다. 50% 또는 두 개의 모니터가 있기 때문에 일반적으로 악마는 알고 있습니다. 녹화를 시작하는 것으로 충분하고 모든 것이 알 수 없는 것처럼 지연됩니다. 영역이나 화면의 크기에 관계없이 마치 전체 데스크탑을 캡처하는 것처럼 항상 동일하게 지연됩니다. 원칙적으로는 그렇습니다. 하지만 다른 방법은 어떻게 되나요? :)
글쎄, 나는 당신이하는 종류의 "틱 분석"이 무엇인지 이해하지 못합니다 ... :))
또한 지점은 "효과적인 거래 전략을 기반으로 ..."
xnsnet 이 하는 일은 주제에 어긋나는 것이 아니라 건설적으로 보완하는 것입니다.
("서버 시간" - "클라이언트 시간") --- 상수가 아닌가요?
틱당 가격 증분을 저장할 수 있는데 왜 가격을 저장합니까?
그리고 의사소통이 단절되거나 방해가 된다면 어떤 증분부터 시작하시겠습니까?
(따옴표를 밀리초로 바인딩)
xnsnet - 제 생각에는 정보를 틱(인코딩 시간, 간격 등)으로 압축하면 훨씬 더 어려워집니다.
후속 처리. 서로 다른 도구와 브로커, 그리고 더 나은 정보 기관에 대해 시간이 동기화된 단일 틱 스트림을 생성하는 것이 필요합니다. 이렇게 하면 저장된 정보의 양이 크게 증가하지만 분석 및 예측에 중점을 둔 기존 표준 패키지로 처리할 수 있습니다. 그렇지 않으면 처리 중에 다시 디코딩되어 단일 스트림으로 배포되어야 합니다. 인코딩된 정보를 이해하고 이를 체계화하는 것 외에 작업은 훨씬 더 어려울 것입니다.
예, Pilgrim, 정보를 압축한다는 것은 동일한 DC 서버 또는 데모 서버를 사용하여 여러 클라이언트의 데이터를 최종적으로 수렴하는 것을 의미했습니다. 당연히 압축 알고리즘을 사용하지 않을 예정입니다. :) 앞으로는 이 작업을 축소라고 부를 것입니다. 예를 들어 꽤 오래 전에 처리된 한 달 전의 이력입니다.
실시간 롤업된 데이터가 다시 롤업될 수 있다고 생각한다고 가정해 보겠습니다. 예를 들어 데이터를 제공하는 클라이언트의 품질이 좋지 않은 경우 이 데이터는 불필요한 것으로 버려질 수 있습니다. 좋은 품질 테스트를 거쳐 좋은 품질은 다른 여러 클라이언트(예: 다른 IP 주소 및 다른 주소 범위를 사용하여 고려할 옵션)로부터 동일한 데이터를 수신함으로써 확인됩니다. 이 모든 것이 보기보다 어렵지는 않습니다. 개발자인 저는 이러한 모든 조치를 잘 알고 있으므로 안심하셔도 됩니다.
댓글: 그런 서버의 타당성에 대한 또 다른 결론이 있습니다. 처음에는 스스로 할 수 있는 것, 즉 스스로 정보를 수집하는 것에 대해 생각한 다음 데이터를 사용하여 이를 처리할 글로벌 서버에 대한 결론에 도달했습니다. 따라서 우리는 여러 브로커와 서버에 대한 독립적인 모니터링을 제거하고 이러한 책임을 동일한 클라이언트에 할당하고 필요한 범위 내에서 서버를 돕는 정보를 대가로 제공합니다. 결과적으로 우리는 우리 자신의 노력에 의지하지 않고 다른 DC를 모니터링할 수 있는 기회를 얻습니다. 동시에 모든 클라이언트로부터 정보를 흡수하는 것이 아니라 서버 자체에서 선택한 정보만 소스 선택 방법은 클라이언트의 수와 차이, 갑옷 피어싱(흡수 및 전달 속도)에 따라 다릅니다. , 일반적으로 가장 중요한 매개변수입니다.
하나의 서버가 여러 벤더 클라이언트를 감당할 수 없다는 것을 알기 때문에 위임에 대해서도 같은 방식으로 생각하거나 클러스터를 사용하여 구현해야 합니다. 그러나 이것은 그들이 말하는 것처럼 지금은 그렇게 중요한 작업이 아닙니다 :) 요점은 분명합니다 :) 나는 프로젝트 가 아직 존재하지 않고 시작되지도 않았다는 점에 주목합니다. 나는 머리 속에서 일반적인 아이디어를 형성하는 동시에 동시에 이 주제에서 그렇지 않으면 그들은 이미 여기에서 저를 규정합니다. 아, 프로젝트 시작? 예? 응. 흥미롭습니다 :) 오히려 시작하기 전에 가치를 결정합니다. 많은 것이 이미 명확하지만 이미 많은 것이 명확합니다 :) 이미 여러 번 시작하고 지연되었지만 플러스가 있지만 조만간 다른 사람의 과일을 대신 사용합니다. 오랜 시간이 지난 후에야 :) 아마도 내가 처음이 아니고 마지막이 아닐 것입니다 :) 어떤 프로젝트를 수행하기 전에 모든 것을 자세히 생각해야 하므로 걸려 넘어지는 것이 이미 역겹습니다. , 특히 "죽은"과 같은 단어가 이런저런 이유로 습관이 되었을 때 :) 그렇기 때문에 주제를 개발하고, 참여하고, 논쟁하고, 진실을 밝히고, 다양한 모순을 처리해야 합니다. 이 모든 것에 감사드립니다. 아마도 우리는 함께 프로젝트의 중요성을 결정할 것입니다. :) 주제에 대한 모든 의견은 내용을 연구했다면 중요하다는 것을 상기시켜 드리겠습니다. 이 프로젝트가 비상업적인 용도로 공개되고 공개적으로 사용 가능하다면 서버 부분은 확실합니다 :) 저는 일반적으로 최근에 거의 모든 것을 공개적으로 하고 있습니다. 이에 대한 기대가 큽니다 :) 그럴 필요가 없습니다 라이선스를 제어하고, 하나의 프로그램만 지원하면 기부, 모든 참가자는 기부금의 일부로 보상을 받게 됩니다. 기부금이 있다면 기부를 의미합니다 :) 무언가를 판매하려면 이 사실을 배제하지 않고 생성해야 합니다. 회사, 사람 유치 등 비즈니스 환경에서 이 프로젝트는 거래자가 지원하거나 지원하지 않을 수 있습니다. 그렇지 않으면, 나는 당신 자신이 모든 것을 완벽하게 이해한다고 생각합니다. 열린 프로젝트가 더 빨리 개발되고 더 빨리 구현됩니다. 특히 개시자가 하나만 있고 지원이 없는 경우에 그렇습니다. 솔직히 누가, 어떻게 하느냐가 중요한 작업의 수준이 아니라 하는 것이 가장 중요합니다 :)
우리가 그리는 창에서 악기에 대한 닫기 선은 MT에서 녹색으로 그려집니다. 나머지는 리스케일링 후 부과합니다. 첨부파일 예시에서는 창에 코드로 로드할 수 없었습니다. 파일 자체가 약간 다른 작업을 위해 설계되었으므로 약간의 독창성을 가지고 있으며, 게다가 MQL을 모르고 아주 서투른 글을 씁니다.
맞아요, 악기 해도가 표시되는 창과 같은 창을 직접 만드는 것이 더 좋겠지만 어떻게 해야할지 모르겠습니다. 이것은 다양한 계측기의 스케일 차트 를 하나의 창에 표시할 뿐만 아니라 시간에 동기화하기 위해 필요합니다. 하나의 척도는 완전한 객관적인 그림을 제공하지 않습니다. 다른 도구에 대한 다른 위치의 간격으로 인해 다른 도구의 차트가 서로 상대적으로 이동하며 이는 인식 그림과 추가 계산의 정확성을 모두 위반합니다.
이제 막 동기화 프로그램을 만들기 시작했는데 아쉽게도 오늘 디버깅을 끝낼 시간이 없었고 내일부터 인터넷이 일주일간 꺼져서 일주일만에 결과를 올리겠습니다. 이 때 나는 당신에게 작별인사를 합니다.
그렇지 않으면 사이트의 비디오 기능을 확인했습니다 :) 마지막으로 확인했습니다 :) 솔직히 말해서 snagit은 서비스로 과부하가 걸리고 프로세서의 지속적인 부하가 20에서 20 사이이기 때문에 내 컴퓨터에서 마지막 리소스를 제거합니다. 50% 또는 두 개의 모니터가 있기 때문에 일반적으로 악마는 알고 있습니다. 녹화를 시작하는 것으로 충분하고 모든 것이 알 수 없는 것처럼 지연됩니다. 영역이나 화면의 크기에 관계없이 마치 전체 데스크탑을 캡처하는 것처럼 항상 동일하게 지연됩니다. 원칙적으로는 그렇습니다. 하지만 다른 방법은 어떻게 되나요? :)