Mak 나는 대략 하나의 클라이언트에 대해 하나의 공통 세트 파일에서 데이터베이스를 구현하는 데 사용했습니다. :) 내 정의의 눈금에는 서버 시간, 클라이언트 시간, 현재 가격, 각각 8바이트, 총 24바이트의 세 가지 지표만 포함되어 있습니다. 128은 위치와 같은 파일의 선두 및 다음 위치에서 가져옵니다. 약 32바이트, 팩터당 8바이트, 다른 것을 조이면 더 많이 나옵니다. 실생활에서는 64를 넘지 않고, 완전히 최소화하면 그 이하도 가능합니다. 그러나 저는 글로벌 규모를 택합니다. 그렇지 않으면 예를 들어 하나의 파일에서 4GB로 제한될 위험이 있습니다. 내가 정확히 이 방법으로 무엇을 할 것인지에 대해 말하는 것이 아니라 일반적으로 틱당 파일에서 32바이트로 제한할 수 있지만 틱 뿐만 아니라 즉각적인 작업에 대해서만 생각해야 하는 경우 질문을 살펴보십시오. 왜 :)
또한 우리는 진드기에 대한 시스템을 구축하지 않고 진드기에 대한 거래가 아니라 진드기 분석에 종사하고 있습니다. 틱 거래를 어떻게 사용합니까? 중개인이 이 틱을 가지고 있지 않다면 그는 그것을 필터링했습니다. 실제 시세를 제공하는 것은 무엇이며 중개인이 필터링하면 이 중개인에서 거래하는 데는 전혀 도움이 되지 않지만 아무도 중개인과 틱의 분석을 취소하지 않았습니다. 다중 화폐와 선물 지수, 금과 같은 다양한 수단에 대해서는 이미 말할 것도 없고 :))))) 모든 것이 기본적으로 실시간이므로 실시간으로 작업하고 작업 규모를 작업합니다 :) 사실 각 클라이언트는 그가 필요하다고 생각하는 것만 사용하여 저에게 모든 견적은 한 클라이언트에서 서버로 보내지지 않을 것입니다. 왜냐하면 그는 그가 필요로 하는 것만 포함했기 때문입니다. 변덕, 그게 더 낫습니다. 모든 것이 실제 필요에서 이루어집니다.
Tiki는 조건부이며 임의적인 것입니다. 그들 모두는 정의에 따라 다르며 여기에는 시스템이 없습니다.
이것은 당신이 잘못 알고 있습니다. 정의상 그것들을 진드기라고 부르지 말자 :) 어떤 개념이 이 방향에서 당신에게 더 적합할까요? Point of Common Ground의 개념을 살펴보겠지만 'tick'이 더 단순하다고 생각합니다. 3번 항목에 대해서는 무의미한 추론을 멈추기 위해 이 사실, 불확실성을 확인하기 어렵게 만들자. 제 프로그램을 예로 들어 불확실성을 고려한 스크린샷을 제공하십시오.
("서버 시간" - "클라이언트 시간") --- 상수가 아닌가요? 틱당 가격 증분을 저장할 수 있는데 왜 가격을 저장합니까? 이 모든 것에 8바이트를 할당하는 이유는 무엇입니까? 예를 들어 가격 설정의 정확도는 4-5자리를 초과하지 않습니다. 틱 기록(틱 시간 제외)에서 틱과 함께 무엇을 저장할 수/저장해야 합니까?
답을 알고 싶어서 묻는 것이 아닙니다. 더 수사학적인 질문입니다. :)
브로커에게 이 틱이 없으면 틱 거래를 어떻게 사용할까요? :))))
나는 당신이 TIKS가 어디에서 왔는지 이해하지 못한다고 생각합니다. 그들은 본질적으로 존재하지 않으며 브로커는 이를 "필터링"할 수 없습니다. 필터링할 것이 없습니다.
틱은 클라이언트 중 한 명의 견적 요청에 대한 브로커의 응답입니다. 동시에 브로커가 제공하는 가격은 시장 상황뿐만 아니라 많은 것에 달려 있습니다. 브로커는 표시 인용문(필터링할 수 있음)에 중점을 둡니다. 그러나 그는 고객과 거래 방향에 따라 어느 쪽이든 몇 핍을 움직일 수 있습니다. 그는 인용하거나 잠시 동안 "생각"할 수 있습니다. ....
TIC는 중개인의 견적이며 중개인의 고객을 제외하고는 아무도 볼 수 없습니다. 그것이 내가 Tiki가 조건부이고 무작위적인 것이라고 말하는 이유입니다. . .
자신의 견적을 통신사에 보내는 초대형 중개인을 제외하고는 수백 개의 브로커 중 어떤 것이 암시적인 인용문을 형성하는지(종종 필터링됨).
클라이언트는 브로커의 서버에서 데이터를 수신하고 틱 가격과 서버 틱 시간을 마음대로 사용할 수 있습니다. 그는 또한 자신의 시간으로 티크에 스탬프를 찍습니다. 그러한 클라이언트는 하나도 없으며 서로 다른 서버의 모든 클라이언트는 최대 1초가 아니라 최대 밀리초까지 서로 다른 데이터를 수신합니다. 동시에 클라이언트와 서버의 시계가 늦거나 반대로 서두를 수 있습니다. 적어도 한 시간당 검색 덕분에 차이점을 찾는 방법이 있습니다. 이 모든 차이점을 왜 잊어 버리십니까? 클라이언트는 서버 시간을 동일한 밀리초로 조정하고 평균을 기반으로 서버 시간을 업데이트할 수 있지만 동일한 DC 서버의 둘 이상의 클라이언트 간의 차이는 초 단위가 아니라 밀리초 단위입니다. 다시 말하지만 가격 스탬프로 인해 시간의 틱 위치도 명확하게 중앙에 있습니다. 가장 정확한 데이터를 구축하는 데에는 이러한 요소가 많이 있으며 틱 가격 스탬프를 제외하고 이 모든 데이터를 염두에 둘 수 있습니다.
따옴표를 필터링하는 방법은 무엇입니까? 그들이 존재하는지 확인합니까? 그리고 데모 서버는 어떻습니까? :)
실제 인용문 분석을 위해 실제 인용문 뿐만 아니라 동일한 인용부호 등을 원하는 모든 사람에게 필요합니다. :) 나는 하나의 서버를 갖고 정보 기관을 구축할 것이라고 기대하지 않습니다. 내 자신의 :) 나는 단지 내 필요에 사용하고 내 필요는 당신의 것과 크게 다르지 않습니다 :) 또한 정보 기관을 가장 잘 묘사하는 방법은 이러한 기관에 경의를 표하지 않고 동일한 고통을 겪는 사람들로부터 정보를 수집하고 동시에 사용할 유용한 도구를 제공하면 클라이언트가 끝이 없을 것입니다. 그렇지 않으면 모두 공허한 생각입니다. :) 모든 것을 점진적으로 수행하기를 바랐지만 이 스레드에서 구독을 취소한 사람들 덕분에 모든 것을 한 번에 최대 규모로 수행하려면 다시 말하지만 모든 갈퀴가 빨려 들어가는 것처럼 보입니다. :)
Mak 나는 대략 하나의 클라이언트에 대해 하나의 공통 세트 파일에서 데이터베이스를 구현하는 데 사용했습니다. :) 내 정의의 눈금에는 서버 시간, 클라이언트 시간, 현재 가격, 각각 8바이트, 총 24바이트의 세 가지 지표만 포함되어 있습니다. 128은 위치와 같은 파일의 선두 및 다음 위치에서 가져옵니다. 약 32바이트, 팩터당 8바이트, 다른 것을 조이면 더 많이 나옵니다. 실생활에서는 64를 넘지 않고, 완전히 최소화하면 그 이하도 가능합니다. 그러나 저는 글로벌 규모를 택합니다. 그렇지 않으면 예를 들어 하나의 파일에서 4GB로 제한될 위험이 있습니다. 내가 정확히 이 방법으로 무엇을 할 것인지에 대해 말하는 것이 아니라 일반적으로 틱당 파일에서 32바이트로 제한할 수 있지만 틱 뿐만 아니라 즉각적인 작업에 대해서만 생각해야 하는 경우 질문을 살펴보십시오. 왜 :)
또한 우리는 진드기에 대한 시스템을 구축하지 않고 진드기에 대한 거래가 아니라 진드기 분석에 종사하고 있습니다. 틱 거래를 어떻게 사용합니까? 중개인이 이 틱을 가지고 있지 않다면 그는 그것을 필터링했습니다. 실제 시세를 제공하는 것은 무엇이며 중개인이 필터링하면 이 중개인에서 거래하는 데는 전혀 도움이 되지 않지만 아무도 중개인과 틱의 분석을 취소하지 않았습니다. 다중 화폐와 선물 지수, 금과 같은 다양한 수단에 대해서는 이미 말할 것도 없고 :))))) 모든 것이 기본적으로 실시간이므로 실시간으로 작업하고 작업 규모를 작업합니다 :) 사실 각 클라이언트는 그가 필요하다고 생각하는 것만 사용하여 저에게 모든 견적은 한 클라이언트에서 서버로 보내지지 않을 것입니다. 왜냐하면 그는 그가 필요로 하는 것만 포함했기 때문입니다. 변덕, 그게 더 낫습니다. 모든 것이 실제 필요에서 이루어집니다.
Tiki는 조건부이며 임의적인 것입니다. 그들 모두는 정의에 따라 다르며 여기에는 시스템이 없습니다.
이것은 당신이 잘못 알고 있습니다. 정의상 그것들을 진드기라고 부르지 말자 :) 어떤 개념이 이 방향에서 당신에게 더 적합할까요? Point of Common Ground의 개념을 살펴보겠지만 'tick'이 더 단순하다고 생각합니다. 3번 항목에 대해서는 무의미한 추론을 멈추기 위해 이 사실, 불확실성을 확인하기 어렵게 만들자. 제 프로그램을 예로 들어 불확실성을 고려한 스크린샷을 제공하십시오.
틱당 가격 증분을 저장할 수 있는데 왜 가격을 저장합니까?
이 모든 것에 8바이트를 할당하는 이유는 무엇입니까?
예를 들어 가격 설정의 정확도는 4-5자리를 초과하지 않습니다.
틱 기록(틱 시간 제외)에서 틱과 함께 무엇을 저장할 수/저장해야 합니까?
답을 알고 싶어서 묻는 것이 아닙니다. 더 수사학적인 질문입니다. :)
브로커에게 이 틱이 없으면 틱 거래를 어떻게 사용할까요? :))))
나는 당신이 TIKS가 어디에서 왔는지 이해하지 못한다고 생각합니다.
그들은 본질적으로 존재하지 않으며 브로커는 이를 "필터링"할 수 없습니다. 필터링할 것이 없습니다.
틱은 클라이언트 중 한 명의 견적 요청에 대한 브로커의 응답입니다.
동시에 브로커가 제공하는 가격은 시장 상황뿐만 아니라 많은 것에 달려 있습니다.
브로커는 표시 인용문(필터링할 수 있음)에 중점을 둡니다.
그러나 그는 고객과 거래 방향에 따라 어느 쪽이든 몇 핍을 움직일 수 있습니다.
그는 인용하거나 잠시 동안 "생각"할 수 있습니다. ....
TIC는 중개인의 견적이며 중개인의 고객을 제외하고는 아무도 볼 수 없습니다.
그것이 내가 Tiki가 조건부이고 무작위적인 것이라고 말하는 이유입니다. . .
자신의 견적을 통신사에 보내는 초대형 중개인을 제외하고는
수백 개의 브로커 중 어떤 것이 암시적인 인용문을 형성하는지(종종 필터링됨).
서버와 클라이언트의 시간은 아직 일정하지 않습니다 :) 클라이언트 자체가 자체 데이터를 기반으로 압축할 서버의 시간만 :)
증분 덕분에 동일한 따옴표와 지연을 어떻게 없앨 수 있는지 궁금합니다. 막대를 비교하는 것과 같습니다. :)
또한 지점은 "효과적인 거래 전략을 기반으로 ..."
서버와 클라이언트의 시간은 시간대의 차이에 의해서만 다릅니다 :))
클라이언트에게 진드기를 보내고 도착하는 시간은 실제로 다를 수 있습니다 ...
클라이언트는 브로커의 서버에서 데이터를 수신하고 틱 가격과 서버 틱 시간을 마음대로 사용할 수 있습니다. 그는 또한 자신의 시간으로 티크에 스탬프를 찍습니다. 그러한 클라이언트는 하나도 없으며 서로 다른 서버의 모든 클라이언트는 최대 1초가 아니라 최대 밀리초까지 서로 다른 데이터를 수신합니다. 동시에 클라이언트와 서버의 시계가 늦거나 반대로 서두를 수 있습니다. 적어도 한 시간당 검색 덕분에 차이점을 찾는 방법이 있습니다. 이 모든 차이점을 왜 잊어 버리십니까? 클라이언트는 서버 시간을 동일한 밀리초로 조정하고 평균을 기반으로 서버 시간을 업데이트할 수 있지만 동일한 DC 서버의 둘 이상의 클라이언트 간의 차이는 초 단위가 아니라 밀리초 단위입니다. 다시 말하지만 가격 스탬프로 인해 시간의 틱 위치도 명확하게 중앙에 있습니다. 가장 정확한 데이터를 구축하는 데에는 이러한 요소가 많이 있으며 틱 가격 스탬프를 제외하고 이 모든 데이터를 염두에 둘 수 있습니다.
따옴표를 필터링하는 방법은 무엇입니까? 그들이 존재하는지 확인합니까? 그리고 데모 서버는 어떻습니까? :)
:)))
글쎄, 또 다른 질문 - 왜이 모든 것이 필요합니까?
(따옴표를 밀리초로 바인딩)
실제 인용문 분석을 위해 실제 인용문 뿐만 아니라 동일한 인용부호 등을 원하는 모든 사람에게 필요합니다. :) 나는 하나의 서버를 갖고 정보 기관을 구축할 것이라고 기대하지 않습니다. 내 자신의 :) 나는 단지 내 필요에 사용하고 내 필요는 당신의 것과 크게 다르지 않습니다 :) 또한 정보 기관을 가장 잘 묘사하는 방법은 이러한 기관에 경의를 표하지 않고 동일한 고통을 겪는 사람들로부터 정보를 수집하고 동시에 사용할 유용한 도구를 제공하면 클라이언트가 끝이 없을 것입니다. 그렇지 않으면 모두 공허한 생각입니다. :) 모든 것을 점진적으로 수행하기를 바랐지만 이 스레드에서 구독을 취소한 사람들 덕분에 모든 것을 한 번에 최대 규모로 수행하려면 다시 말하지만 모든 갈퀴가 빨려 들어가는 것처럼 보입니다. :)