나는 이전에 trades와 level2가 각각 다른 데이터 구독이라고 썼습니다. 이들은 서로 다른 이벤트 핸들러입니다. 따라서 OnTick에서 거래를 호출하고 OnBook에서 볼륨이 있는 갱을 호출해야 합니다 . 그리고 OnBook 이벤트에서 거래를 호출하고 OnTick에서 갱을 호출하려고 합니다. 동시에 OnBuk이 거래에 더 빠를 것이라고 생각합니다. 각각의 데이터 스트림을 위해 설계된 두 개의 이벤트 핸들러를 비교하는 것은 더 빠르지 않을 것입니다. 이것은 착각인 것 같습니다. 이것이 모두 실험이라는 것을 이해하지만 소켓의 논리를 이해하지 못하면 이러한 OnTik 및 OnBuk 핸들러에서 끝없이 혼란스러울 것입니다.
나는 이미 당신이 보지 못했다면 "나를 위한 OnBookEvent()에 대한 대안이 없습니다"라고 썼습니다.
그리고 모든 코드, 결과, 설명 - 이유를 명확히 하기 위해.
귀하의 게시물로 판단-당신은 이해하지 못합니다 ... :)
아마도 당신은 메시지를 통해 읽고 있습니까?
OnBookEvent()를 통해 OnTick()을 사용하지 않고도 모든 데이터를 빠르게 얻을 수 있지만
여기 OnTick()을 통해 모든 데이터를 수신할 수 없습니다 . 그렇다면 왜 OnTick()을 사용해야 합니까?
나는 이미 당신이 보지 못했다면 "나를 위한 OnBookEvent()에 대한 대안이 없습니다"라고 썼습니다.
그리고 모든 코드, 결과, 설명 - 이유를 명확히 하기 위해.
귀하의 게시물로 판단-당신은 이해하지 못합니다 ... :)
아마도 당신 은 주제를 통해 읽었습니까?
예, 귀하의 경우에는 대안이 없다는 것을 이해하며 당연히 그렇습니다. 그리고 나는 그것이 무엇에 관한 것인지 이해합니다. 저는 거래와 레벨2가 서로 다른 데이터 스트림이라는 점에 초점을 맞추고 싶었습니다. 그리고 이것은 잊어서는 안되며, 모르는 사람들을 위해 알고 있습니다. 따라서 거래가 필요한 경우 이를 위해 필요한 기능을 OnTick에서 호출해야 하며, 볼륨 또는 주문서의 깊이로 입찰 요청이 필요한 경우 OnBook에서 해당 기능을 호출하십시오. OnBook에서 이벤트를 가져오고 거래를 얻고 OnTick 이벤트에서 볼륨이나 깊이를 얻으려고 하는 것은 올바르지 않습니다. 그래서 나는 당신이 다른 사람들에게 설명하고 그 과정에서 실험하고 있다는 것을 깨달았습니다.
이것이 주제와 어떤 관련이 있습니까? 나는 이것 때문에 막혔습니다. 왜냐하면 당신은 진드기를 얻기 위해 OnBook이 필요하지 않기 때문입니다. OnTick은 확실히 느리지 않습니다.
그리고 왜 온북의 필수불가결성에 대해 20번이나 이야기합니까? 그녀를 의심하는 사람이 있습니까?
터미널에 오는 모든 틱은 이미 기록입니다.
그러나 나는 이것에 대해 말하는 것이 아니라 간격이 없는 피드를 구축하는 것에 대해 이야기하고 있습니다(SymbolInfoTick은 이에 대해 도움이 되지 않을 것입니다).
어울리지 않으셨나보네요 :) 그는 당신에게 거래량과 함께 최고의 입찰가에 대해 이야기하고 당신은 거래와 거래 테이프에 대해 이야기합니다 :)) 좋아, 이제 알았다.
글쎄, 당신이 어떻게 보느냐에 따라 온 진드기는 이미 역사입니다. 교환 서버의 경우 예, 이것은 터미널에 대한 기록이지 실제로는 아닙니다. 결국, OnTik용 터미널은 핫 액세스를 위해 캐시에 마지막 4096개 항목을 저장한 다음 디스크의 기록에 덤프합니다. 그런 다음 이것은 아직 이야기가 아닙니다.)), 즉 긴급 종료 중에 캐시가 디스크에 저장되지 않을 수 있습니다. 그리고 터미널을 다시 시작하면 캐시에서 손실된 데이터가 이미 서버에서 로드됩니다. 그러나 이것은 OnTik 데이터에만 적용됩니다. OnBuk은 데이터를 로드하지 않을 가능성이 높습니다.
무슨 일이야?
나는 이전에 trades와 level2가 각각 다른 데이터 구독이라고 썼습니다. 이들은 서로 다른 이벤트 핸들러입니다.
따라서 OnTick에서 거래를 호출하고 OnBook에서 볼륨이 있는 갱을 호출해야 합니다 .
그리고 OnBook 이벤트에서 거래를 호출하고 OnTick에서 갱을 호출하려고 합니다. 동시에 OnBuk이 거래에 더 빠를 것이라고 생각합니다.
각각의 데이터 스트림을 위해 설계된 두 개의 이벤트 핸들러를 비교하는 것은 더 빠르지 않을 것입니다. 이것은 착각인 것 같습니다.
이것이 모두 실험이라는 것을 이해하지만 소켓의 논리를 이해하지 못하면 이러한 OnTik 및 OnBuk 핸들러에서 끝없이 혼란스러울 것입니다.
나는 이미 당신이 보지 못했다면 "나를 위한 OnBookEvent()에 대한 대안이 없습니다"라고 썼습니다.
그리고 모든 코드, 결과, 설명 - 이유를 명확히 하기 위해.
귀하의 게시물로 판단-당신은 이해하지 못합니다 ... :)
아마도 당신은 메시지를 통해 읽고 있습니까?
OnBookEvent()를 통해 OnTick()을 사용하지 않고도 모든 데이터를 빠르게 얻을 수 있지만
여기 OnTick()을 통해 모든 데이터를 수신할 수 없습니다 . 그렇다면 왜 OnTick()을 사용해야 합니까?
나는 이미 당신이 보지 못했다면 "나를 위한 OnBookEvent()에 대한 대안이 없습니다"라고 썼습니다.
그리고 모든 코드, 결과, 설명 - 이유를 명확히 하기 위해.
귀하의 게시물로 판단-당신은 이해하지 못합니다 ... :)
아마도 당신 은 주제를 통해 읽었습니까?
예, 귀하의 경우에는 대안이 없다는 것을 이해하며 당연히 그렇습니다.
그리고 나는 그것이 무엇에 관한 것인지 이해합니다. 저는 거래와 레벨2가 서로 다른 데이터 스트림이라는 점에 초점을 맞추고 싶었습니다.
그리고 이것은 잊어서는 안되며, 모르는 사람들을 위해 알고 있습니다.
따라서 거래가 필요한 경우 이를 위해 필요한 기능을 OnTick에서 호출해야 하며,
볼륨 또는 주문서의 깊이로 입찰 요청이 필요한 경우 OnBook에서 해당 기능을 호출하십시오.
OnBook에서 이벤트를 가져오고 거래를 얻고 OnTick 이벤트에서 볼륨이나 깊이를 얻으려고 하는 것은 올바르지 않습니다.
그래서 나는 당신이 다른 사람들에게 설명하고 그 과정에서 실험하고 있다는 것을 깨달았습니다.
그래서 나는 당신이 다른 사람들에게 설명하고 그 과정에서 실험하고 있다는 것을 깨달았습니다.
제대로 이해했습니다.
7년 전에 비슷한 실험을 해서 OnbookEvent()를 선택했을 뿐입니다.
그리고 이제 확인하기로 결정했습니다. 갑자기 무언가가 변경되었습니다 ... 변경되지 않았습니다.
사실 선도시장(FORTS)은 "고유동성" 상품에서도 매우 약합니다.
즉 , 적절한 가격 으로 매우 제한된 수 의 계약을 구매할 수 있으므로 가격뿐만 아니라
그러나 이 가격의 계약 수량은 매우 중요 합니다.
그리고 SymbolInfo는 이 가격의 볼륨을 제공하지 않습니다.
이와 관련하여 전체 주문서의 가격과 수량을 모두 제공하는 MarketBookGet ()을 사용해야 합니다.
이것이 주제와 어떤 관련이 있습니까? 나는 이것 때문에 막혔습니다. 왜냐하면 당신은 진드기를 얻기 위해 OnBook이 필요하지 않기 때문입니다. OnTick은 확실히 느리지 않습니다.
그리고 왜 온북의 필수불가결성에 대해 20번이나 이야기합니까? 그녀를 의심하는 사람이 있습니까?
그리고 OnTck()가 실행될 때 기록에서 틱을 얻을 수 있다는 데 동의하지 않습니다.
마지막 틱 시간을 기억하면 OnTck()가 실행될 때 틱을 얻을 수 있습니다.
새로운 틱이 실시간으로 왔습니다. OnTck()가 작동하면 즉시 계산했습니다. 즉, 이것은 history가 아닙니다 .
터미널에 오는 모든 틱은 이미 기록입니다.
그러나 나는 이것에 대해 말하는 것이 아니라 간격이 없는 테이프를 만드는 것에 대해 이야기하고 있습니다( SymbolInfoTick 은 이에 대해 도움이 되지 않을 것입니다).
시작하는 코드를 확인하고 싶었습니다.
그러나 어떤 이유로 나는 오프너의 데모 계정을 열 수 없습니다. 아마도 휴무 시간이거나 여전히 문제가 있습니까?
실시간 틱
2020.01.31 13:18
계정 : 1007932
이것이 주제와 어떤 관련이 있습니까? 나는 이것 때문에 막혔습니다. 왜냐하면 당신은 진드기를 얻기 위해 OnBook이 필요하지 않기 때문입니다. OnTick은 확실히 느리지 않습니다.
그리고 왜 온북의 필수불가결성에 대해 20번이나 이야기합니까? 그녀를 의심하는 사람이 있습니까?
터미널에 오는 모든 틱은 이미 기록입니다.
그러나 나는 이것에 대해 말하는 것이 아니라 간격이 없는 피드를 구축하는 것에 대해 이야기하고 있습니다(SymbolInfoTick은 이에 대해 도움이 되지 않을 것입니다).
어울리지 않으셨나보네요 :)
그는 당신에게 거래량과 함께 최고의 입찰가에 대해 이야기하고 당신은 거래와 거래 테이프에 대해 이야기합니다 :))
좋아, 이제 알았다.
글쎄, 당신이 어떻게 보느냐에 따라 온 진드기는 이미 역사입니다.
교환 서버의 경우 예, 이것은 터미널에 대한 기록이지 실제로는 아닙니다.
결국, OnTik용 터미널은 핫 액세스를 위해 캐시에 마지막 4096개 항목을 저장한 다음 디스크의 기록에 덤프합니다.
그런 다음 이것은 아직 이야기가 아닙니다.)), 즉 긴급 종료 중에 캐시가 디스크에 저장되지 않을 수 있습니다.
그리고 터미널을 다시 시작하면 캐시에서 손실된 데이터가 이미 서버에서 로드됩니다. 그러나 이것은 OnTik 데이터에만 적용됩니다.
OnBuk은 데이터를 로드하지 않을 가능성이 높습니다.
나는 모든 OnTik에 대해 적어도 하나의 OnBook이 있다고 생각했습니다. 그러나 나는 그것을 이해하지 못했다.
이 코드를 오프닝 데모에 넣고 평균과 최대값을 계산합니다. OnTick과 다음 OnBuk 사이의 지연.
코드는 무릎에, 아마도 곡선, 나는 결과를 볼 것입니다.
터미널에 오는 모든 틱은 이미 기록입니다.
그러나 나는 이것에 대해 말하는 것이 아니라 간격이 없는 피드를 구축하는 것에 대해 이야기하고 있습니다(SymbolInfoTick은 이에 대해 도움이 되지 않을 것입니다).
확인. 역사에 대한 당신의 관점은 아주 분명합니다.
그러나 나는 여전히 진드기를 얻는 방법이
(역사에서 또는 실시간으로) 읽기.
그리고 SymbolInfoTick 과 빈틈 없는 테이프에 대해 반대하지 않았습니다.
오늘의 사진입니다. 물론 OnBuk Tick이 일치하는지 여부는 확인되지 않았지만 OnTick이 OnBuk보다 앞서면 해당하는 것이 다음이거나 조금 늦을 것이라는 희망으로 다음을 찍은 것입니다.
물론 추가 확인 없이 최대값은 지표나 이상값이 아니거나 실제로 OnBuk이 어딘가에서 느려집니다.
그러나 이것을 누가 설명할 수 있습니까? 왜 그렇게 많은 OnTick이 인쇄되지 않고 그 사이에 OnBuk 하나가 들어맞지 않습니까?