xnsnet : 여기 Alexey, 나는 당신의 생각을 좋아합니다 :) 128바이트의 최대 데이터 정의로 10만 틱, 12미터를 곱하고, 하루에 한 클라이언트에서 100클라이언트, 기가바이트로 곱하겠습니다. 내 자신의 리소스 백 명의 고객과 몇 달 동안 이력을 유지할 수 있습니다. 필요한 하드웨어를 제공하면 몇 년 동안 자신있게 봉인할 수 있습니다.
더 좋을 수 있습니다. 서버는 아무 것도 저장하지 않고 요청만 처리하고 현재 온라인 상태인 클라이언트의 필요한 데이터를 검색하거나 이전에 이 데이터를 가지고 있었던 온라인 사용자를 기다리는 것입니다. 이것은 pia to pia(당나귀 또는 kazy) 시스템과 비슷하지만 따옴표용입니다. ;) 서버가 여러 클라이언트에서 요청된 데이터를 찾은 경우 하나만 다운로드하지 않도록 여러 클라이언트에서 요청된 기록의 다양한 섹션 다운로드를 배포합니다. 이 서버에서 자주 요청되는 기록 조각을 캐시할 수 있습니다.
그러나 먼저 역사의 저장으로해야 할 일, 두 번째로 역사의 질로 해충을 식별하기가 어려울 것입니다. 이것들은 널리 배포되는 파일이 아니며, P2P 네트워크의 이것조차도 haskod에 대한 정보의 신뢰성에서 벗어날 수 없습니다. 백업 옵션으로 클라이언트와 함께 작업 내역을 저장할 수 있으며, 서버 자체의 추락입니다. 단기 중단을 신속하게 복원합니다. 그러나 나는 그것을 클라이언트의 리포지토리로 만드는 요점을 알지 못합니다. 보안에 영향을 미칠 것입니다. 그리고 모든 데이터를 함께 수집하기 위해 연결해야 하는 클라이언트의 수와 더불어 많은 클라이언트가 청각 장애인 보호를 받고 있으며 모든 사람이 전용 IP를 갖고 있는 것은 아니며 LAN에 있지 않습니다. 많은 사람들이 트래픽의 강력한 흡수에 동의하지 않을 것입니다. 옵션으로 여러 서버를 고려할 수 있으며 어떤 경우에도 서버에 데이터 위임이 있어야 합니다.
많은 거래자들은 DSL이나 인터넷에 빠르고 영구적으로 연결할 수 있는 다른 방법을 가지고 있습니다. ADSL이 연결되면 동적 IP를 변경할 계획입니다. 일반적으로 처음에는 클라이언트, 당신, 나, 그리고 아마도 다른 열성팬이 있을 수 있습니다. 모두가 그들로부터 다운로드할 것이지만, 다운로드하면 다른 사람에게도 데이터를 제공해야 합니다. 이것은 자동으로 발생합니다. 시간이 지남에 따라 당신과 마찬가지로 많은 고객이 있어야한다고 생각합니다. OpenQuotes 프로젝트 와 같습니다. :) 좌파 데이터가 미끄러지면 사고가 날 수 있습니다. 프로그래밍 방식으로도 두 개 이상의 서로 다른 클라이언트의 데이터를 비교하여 해결할 수 있습니다. 그러나 일반적으로 보안 측면에서 서버가 더 안정적이라고 생각합니다. 랩톱을 서버로 사용할 수 있습니다. 소음이 크지 않고 비교적 저렴합니다. 하지만 그 다음에는 누구와 함께 할 것인지 결정해야 합니다. :) 누군가가 자신의 컴퓨터를 기증할 수도 있지만. 그러나 서로 다른 사람을 위해 최소 두 대의 서버를 보유하는 것이 바람직합니다. 그렇지 않으면 따옴표가 있는 한 서버가 사라질 수 있습니다. 아마도 MQ는 프로젝트가 인기 있는 것을 보고 서버를 제공할 것입니다 ;) MQ 담당자는 말할 것입니다 - History Center에 우리의 솜털 같은 인용문이 있는 경우 DC의 이력이 왜 필요합니까? 인용문에 민감하지 않도록 강력한 조언자를 사용하고 작성하십시오. 이것은 정확하지만 Expert Advisor가 다른 DC의 데이터에서도 허용 가능한지 빠르게 확인하는 방법 - 예를 들어 1년 동안 이러한 DC의 큰 기록을 갖는 것이 바람직합니다. 그리고 DC가 제공하는 3개월의 분으로는 충분하지 않을 것이고, 역사에서 그것들은 아름다움을 위해 일종의 이미지로 걸러질 수 있습니다.
나는 전용 회선, 인터넷에 대한 100 메가 비트 채널을 가지고 있으며 트래픽은 제한적이며 측면에서 발신하며 실험에 충분합니다 :) 그렇다면 본격적인 서버가 아닌 본격적인 서버를 구입하여 사이트에 올릴 수 있습니다 아이디어가 성공하면 :) 그들이 말했듯이, 그것은 무엇을 위해서일 것입니다, 다른 모든 것은 중요하지 않습니다 :) 결과와 감각이 있다면 투자자 스스로,이 기업을 위해 투자자를 찾을 것입니다 :) 나는 진드기로 일합니다. 이유는 그들이 말했듯이 전 세계적으로 생각해야하며 모든 것이 이해가 될 것입니다 :) 틱은 하나의 명확한 가치, 시간 및 가격, 음, 클라이언트의 시간을 더한 것이고 막대는 이미 여러 값입니다. 그 사이에는 무엇이든 될 수 있습니다. 막대를 결합하고 비교하는 방법을 상상조차 할 수 없습니다. 모든 단계에서 오류가 있기 때문에 이것은 어리석은 일입니다. 진드기를 비교할 수 있다면 막대는 주교를 마우스, 특히 DC 간에 비교하는 것과 같습니다.
어떤 종류의 metaquote 따옴표 서버에 대해 이야기하고 있는지, 데모에 대해, 데모 서버에 관한 것이라면 사소한 따옴표도 필터링합니다. 다른 사람은 모릅니다 :) 다양한 서버를 비교했지만 모든 곳에서 필터링합니다. , 이것이 필터가 아니라는 것을 이해하지 못한다면 단순히 정보를 전달할 시간이 없지만 문제는 초당 틱의 차이와 그 미만의 차이뿐만 아니라 더 많은 경우 거기에 시간이 없을 것입니다. , 특성별 필터가 명확하게 정의됩니다.
엘리트모 : Piligrimm, mt를 사용하여 다른 통화 쌍의 차트에 모든 쌍의 종가 차트를 표시하는 방법을 알려주세요.
iClose 기능을 사용하여 필요한 모든 도구가 포함된 파일을 만든 다음 각 도구에 대해 평균 계수를 얻습니다. 예를 들어 각 도구의 마지막 100개 막대를 합하고 100으로 나눕니다. 결과적으로 각 악기는 계수에 따라 1을 중심으로 변동하는 모든 악기의 값을 얻을 수 있습니다. 다른 차트에 표시하려는 상품의 값에 차트를 표시할 상품에서 얻은 계수를 곱합니다.
알겠습니다. iClose를 통해 선택한 쌍을 닫는 방법을 이해합니다. 그런 다음 이 값을 파일에 씁니다. (어떤 파일이고 어떤 형식인지 궁금합니다.) 그러다가 어떻게든 MT4에서 이 파일을 열어보면 다양한 도구들의 Close를 연결하는 선의 형태로 모든 값을 그립니다. 따라서 어떤 종류의 알고리즘에 따라 작성된 추세선을 계산하지 않고 GBPUSD, AUDUSD 및 EURUSD 종가를 연결하는 선이 그려지는 스크린샷이 있습니다. 저는 처음에 관심이 있습니다. 어드바이저나 인디케이터에 이 선을 그리지 않고 어떻게 세 쌍 모두를 서로 다른 색상의 선으로 가깝게 연결하여 표시할 수 있었습니까?
우리가 그리는 창에서 악기에 대한 닫기 선은 MT에서 녹색으로 그려집니다. 나머지는 리스케일링 후 부과합니다. 첨부파일 예시에서는 창에 코드로 로드할 수 없었습니다. 파일 자체가 약간 다른 작업을 위해 설계되었으므로 약간의 독창성을 가지고 있으며, 게다가 MQL을 모르고 아주 서투른 글을 씁니다.
내 데이터는 각각 형성된 막대에 따라 로드되며 중첩된 차트는 한 막대씩 이동해야 합니다. (누군가 프로그램을 설정한 후 1시간 이내에 다운로드한 경우 수정: ExtMapBuffer1[155-iw+ip] to ExtMapBuffer1[156-iw+ip] 및 기타 버퍼 유사).
그건 그렇고, 내 손은 다중 통화에 도달하지 못했습니다. 부수적 인 요인이 발생하고 방문에서 모든 것을 빨리하기 때문에 버그 만 수정하면 서버 작성이 그렇게 긴 작업이 아닙니다. 방문은 그것을 하고자 하는 열망에 의해 결정됩니다. 나는 종종 몇 시간 또는 하루 만에 주요 작업을 수행하고 그것에 대해 생각합니다. 더 많은 일을 계속하기 전에 때로는 단순히 존재하지 않는 의미가 필요하기 때문입니다. 이상주의 또는 극대주의라고 하며 일반적으로 거의 동일합니다. :) 처음에 데이터에 신경을 쓰면 출력 일정을 잊어버리는 경우가 있습니다. 필요, 이것 또는 저것 선택. 아마 제가 처음 쓰고 생각했다면 이미 다중통화와 수치지표가 있는 차트가 있을텐데 데이터가 필터링된다면 얼만큼 정확하고 정확할지는 한 눈에 알 수 없습니다 :) 필터링이 감지되었습니다. 이 문제가 해결될 때까지 다른 문제는 내 눈앞에 나타나지 않을 것입니다 :)
Pilgrim이 올바르게 지적했듯이 초기 데이터의 정확성이 중요한 역할을 합니다 :) 그런데 틱의 동기화에 대해서는 시장이 이벤트에 일관되게 반응하기 때문에 이 문제에서 모든 것이 결정됩니다. 즉, 틱에 반응한다는 의미입니다. 같은 방식으로 일관되게 각 틱이 중요하지만 데이터가 없으면 다른 틱이 쌍으로 되어 데이터가 동일한 그래픽 표현에 정확하게 반영되지 않습니다. 또는 영향이 정확히 무엇에서 오는지 확실하지 않습니다. 1초보다 더 정확한 시간을 얻지는 못하지만 이것은 클라이언트 흡수 시간에 의해 보상됩니다. 이러한 클라이언트가 많을수록 나노초의 정확도로 시간을 더 정확하게 결정할 수 있습니다. 이것이 틱 동기화의 정확도입니다. :) 1초에 천만 틱은 통과하지 않습니다. 이것은 시간 번호의 8바이트 구조로 충분하므로 순서가 순차적입니다. 우리의 경우 틱의 차이, 주요 조건은 틱이 선행 틱과 가격 차이가 없는 경우 가장 먼저 주의해야 할 사항입니다. 정의상 이것은 가격의 변화가 아니라 단순하게 단어, 서버 또는 클라이언트 오류.
Piligrimm : 우리가 그리는 창에서 악기에 대한 닫기 선은 MT에서 녹색으로 그려집니다. 나머지는 리스케일링 후 부과합니다. 첨부파일 예시에서는 창에 코드로 로드할 수 없었습니다. 파일 자체는 약간 다른 작업을 위해 설계되었으므로 약간의 독창성을 가지고 있습니다. 게다가 MQL을 몰라서 아주 서투르게 씁니다.
1. 중개인은 시스템 구축을 허용하지 않으며 이러한 시스템으로부터 자신을 보호할 수 있는 여러 가지 방법이 있습니다. 2. Tiki는 조건부이며 임의적인 것입니다. 그들 모두는 정의에 따라 다르며 여기에는 시스템이 없습니다. 3. 진드기의 경우 양자 역학에서와 같이 불확정성 원리의 영향이 있습니다. 즉, 측정 과정이 결과에 영향을 미칩니다. (데모에서) 관찰자라면 틱의 흐름에 영향을 미치지 않습니다. 실생활에서 작업을 시작하면(측정 - 견적 요청) 시장 상황, 중개인의 기분, 작업 결과에 따라 틱의 흐름을 직접 생성하게 됩니다. .
다음으로, 아마도 많이 놓쳤을 것입니다. 전체 분기를 읽지 않았지만 틱당 128바이트가 필요한 이유는 무엇입니까? IMHO, 2는 눈에 충분합니다. 델타 코딩을 사용합니다. 첫 번째 바이트는 시간 증가분(예: 초 단위)을 제공하고 두 번째 가격 증가분은 핍 단위로 제공합니다. 한 틱에서 가격이 한 수치 이상 변할 가능성은 없고, 인접한 두 틱 사이에 4분 이상 있을 가능성도 없습니다. 결과 시리즈는 주로 0에 가까운 값으로 구성되며 모든 압축 알고리즘에 의해 현저하게 압축됩니다. 또한 하루에 진드기가 그렇게 많지 않습니다. 예를 들어 Alpari의 EURUSD는 현재 하루 약 5000틱입니다.
여기 Alexey, 나는 당신의 생각을 좋아합니다 :) 128바이트의 최대 데이터 정의로 10만 틱, 12미터를 곱하고, 하루에 한 클라이언트에서 100클라이언트, 기가바이트로 곱하겠습니다. 내 자신의 리소스 백 명의 고객과 몇 달 동안 이력을 유지할 수 있습니다. 필요한 하드웨어를 제공하면 몇 년 동안 자신있게 봉인할 수 있습니다.
더 좋을 수 있습니다. 서버는 아무 것도 저장하지 않고 요청만 처리하고 현재 온라인 상태인 클라이언트의 필요한 데이터를 검색하거나 이전에 이 데이터를 가지고 있었던 온라인 사용자를 기다리는 것입니다.
이것은 pia to pia(당나귀 또는 kazy) 시스템과 비슷하지만 따옴표용입니다. ;) 서버가 여러 클라이언트에서 요청된 데이터를 찾은 경우 하나만 다운로드하지 않도록 여러 클라이언트에서 요청된 기록의 다양한 섹션 다운로드를 배포합니다. 이 서버에서 자주 요청되는 기록 조각을 캐시할 수 있습니다.
좌파 데이터가 미끄러지면 사고가 날 수 있습니다. 프로그래밍 방식으로도 두 개 이상의 서로 다른 클라이언트의 데이터를 비교하여 해결할 수 있습니다. 그러나 일반적으로 보안 측면에서 서버가 더 안정적이라고 생각합니다. 랩톱을 서버로 사용할 수 있습니다. 소음이 크지 않고 비교적 저렴합니다. 하지만 그 다음에는 누구와 함께 할 것인지 결정해야 합니다. :) 누군가가 자신의 컴퓨터를 기증할 수도 있지만. 그러나 서로 다른 사람을 위해 최소 두 대의 서버를 보유하는 것이 바람직합니다. 그렇지 않으면 따옴표가 있는 한 서버가 사라질 수 있습니다.
아마도 MQ는 프로젝트가 인기 있는 것을 보고 서버를 제공할 것입니다 ;)
MQ 담당자는 말할 것입니다 - History Center에 우리의 솜털 같은 인용문이 있는 경우 DC의 이력이 왜 필요합니까? 인용문에 민감하지 않도록 강력한 조언자를 사용하고 작성하십시오. 이것은 정확하지만 Expert Advisor가 다른 DC의 데이터에서도 허용 가능한지 빠르게 확인하는 방법 - 예를 들어 1년 동안 이러한 DC의 큰 기록을 갖는 것이 바람직합니다. 그리고 DC가 제공하는 3개월의 분으로는 충분하지 않을 것이고, 역사에서 그것들은 아름다움을 위해 일종의 이미지로 걸러질 수 있습니다.
나는 전용 회선, 인터넷에 대한 100 메가 비트 채널을 가지고 있으며 트래픽은 제한적이며 측면에서 발신하며 실험에 충분합니다 :) 그렇다면 본격적인 서버가 아닌 본격적인 서버를 구입하여 사이트에 올릴 수 있습니다 아이디어가 성공하면 :) 그들이 말했듯이, 그것은 무엇을 위해서일 것입니다, 다른 모든 것은 중요하지 않습니다 :) 결과와 감각이 있다면 투자자 스스로,이 기업을 위해 투자자를 찾을 것입니다 :) 나는 진드기로 일합니다. 이유는 그들이 말했듯이 전 세계적으로 생각해야하며 모든 것이 이해가 될 것입니다 :) 틱은 하나의 명확한 가치, 시간 및 가격, 음, 클라이언트의 시간을 더한 것이고 막대는 이미 여러 값입니다. 그 사이에는 무엇이든 될 수 있습니다. 막대를 결합하고 비교하는 방법을 상상조차 할 수 없습니다. 모든 단계에서 오류가 있기 때문에 이것은 어리석은 일입니다. 진드기를 비교할 수 있다면 막대는 주교를 마우스, 특히 DC 간에 비교하는 것과 같습니다.
어떤 종류의 metaquote 따옴표 서버에 대해 이야기하고 있는지, 데모에 대해, 데모 서버에 관한 것이라면 사소한 따옴표도 필터링합니다. 다른 사람은 모릅니다 :) 다양한 서버를 비교했지만 모든 곳에서 필터링합니다. , 이것이 필터가 아니라는 것을 이해하지 못한다면 단순히 정보를 전달할 시간이 없지만 문제는 초당 틱의 차이와 그 미만의 차이뿐만 아니라 더 많은 경우 거기에 시간이 없을 것입니다. , 특성별 필터가 명확하게 정의됩니다.
나는 tiki도 훔치는 프로그램을 작성할 것이라고 생각합니다 - 그것은 오래 걸리지 않을 것입니다. 그런 다음 문제가 있는 경우 틱을 교환합니다. 견적 서버가 지루하고 길다고 생각합니다. 하지만 그렇게 하면 내 클라이언트를 귀하의 서버에 연결하겠습니다.
Piligrimm, mt를 사용하여 다른 통화 쌍의 차트에 모든 쌍의 종가 차트를 표시하는 방법을 알려주세요.
iClose 기능을 사용하여 필요한 모든 도구가 포함된 파일을 만든 다음 각 도구에 대해 평균 계수를 얻습니다. 예를 들어 각 도구의 마지막 100개 막대를 합하고 100으로 나눕니다. 결과적으로 각 악기는 계수에 따라 1을 중심으로 변동하는 모든 악기의 값을 얻을 수 있습니다. 다른 차트에 표시하려는 상품의 값에 차트를 표시할 상품에서 얻은 계수를 곱합니다.
알겠습니다. iClose를 통해 선택한 쌍을 닫는 방법을 이해합니다. 그런 다음 이 값을 파일에 씁니다. (어떤 파일이고 어떤 형식인지 궁금합니다.)
그러다가 어떻게든 MT4에서 이 파일을 열어보면 다양한 도구들의 Close를 연결하는 선의 형태로 모든 값을 그립니다. 따라서 어떤 종류의 알고리즘에 따라 작성된 추세선을 계산하지 않고 GBPUSD, AUDUSD 및 EURUSD 종가를 연결하는 선이 그려지는 스크린샷이 있습니다. 저는 처음에 관심이 있습니다. 어드바이저나 인디케이터에 이 선을 그리지 않고 어떻게 세 쌍 모두를 서로 다른 색상의 선으로 가깝게 연결하여 표시할 수 있었습니까?
내 데이터는 각각 형성된 막대에 따라 로드되며 중첩된 차트는 한 막대씩 이동해야 합니다. (누군가 프로그램을 설정한 후 1시간 이내에 다운로드한 경우 수정:
ExtMapBuffer1[155-iw+ip] to ExtMapBuffer1[156-iw+ip] 및 기타 버퍼 유사).
Pilgrim이 올바르게 지적했듯이 초기 데이터의 정확성이 중요한 역할을 합니다 :) 그런데 틱의 동기화에 대해서는 시장이 이벤트에 일관되게 반응하기 때문에 이 문제에서 모든 것이 결정됩니다. 즉, 틱에 반응한다는 의미입니다. 같은 방식으로 일관되게 각 틱이 중요하지만 데이터가 없으면 다른 틱이 쌍으로 되어 데이터가 동일한 그래픽 표현에 정확하게 반영되지 않습니다. 또는 영향이 정확히 무엇에서 오는지 확실하지 않습니다. 1초보다 더 정확한 시간을 얻지는 못하지만 이것은 클라이언트 흡수 시간에 의해 보상됩니다. 이러한 클라이언트가 많을수록 나노초의 정확도로 시간을 더 정확하게 결정할 수 있습니다. 이것이 틱 동기화의 정확도입니다. :) 1초에 천만 틱은 통과하지 않습니다. 이것은 시간 번호의 8바이트 구조로 충분하므로 순서가 순차적입니다. 우리의 경우 틱의 차이, 주요 조건은 틱이 선행 틱과 가격 차이가 없는 경우 가장 먼저 주의해야 할 사항입니다. 정의상 이것은 가격의 변화가 아니라 단순하게 단어, 서버 또는 클라이언트 오류.
우리가 그리는 창에서 악기에 대한 닫기 선은 MT에서 녹색으로 그려집니다. 나머지는 리스케일링 후 부과합니다. 첨부파일 예시에서는 창에 코드로 로드할 수 없었습니다. 파일 자체는 약간 다른 작업을 위해 설계되었으므로 약간의 독창성을 가지고 있습니다. 게다가 MQL을 몰라서 아주 서투르게 씁니다.
1. 중개인은 시스템 구축을 허용하지 않으며 이러한 시스템으로부터 자신을 보호할 수 있는 여러 가지 방법이 있습니다.
2. Tiki는 조건부이며 임의적인 것입니다. 그들 모두는 정의에 따라 다르며 여기에는 시스템이 없습니다.
3. 진드기의 경우 양자 역학에서와 같이 불확정성 원리의 영향이 있습니다. 즉, 측정 과정이 결과에 영향을 미칩니다. (데모에서) 관찰자라면 틱의 흐름에 영향을 미치지 않습니다. 실생활에서 작업을 시작하면(측정 - 견적 요청) 시장 상황, 중개인의 기분, 작업 결과에 따라 틱의 흐름을 직접 생성하게 됩니다. .
다음으로, 아마도 많이 놓쳤을 것입니다. 전체 분기를 읽지 않았지만 틱당 128바이트가 필요한 이유는 무엇입니까?
IMHO, 2는 눈에 충분합니다. 델타 코딩을 사용합니다. 첫 번째 바이트는 시간 증가분(예: 초 단위)을 제공하고 두 번째 가격 증가분은 핍 단위로 제공합니다. 한 틱에서 가격이 한 수치 이상 변할 가능성은 없고, 인접한 두 틱 사이에 4분 이상 있을 가능성도 없습니다. 결과 시리즈는 주로 0에 가까운 값으로 구성되며 모든 압축 알고리즘에 의해 현저하게 압축됩니다. 또한 하루에 진드기가 그렇게 많지 않습니다. 예를 들어 Alpari의 EURUSD는 현재 하루 약 5000틱입니다.