[Xing API] 연속 TR API 오류

선물 tick 데이터를 연속으로 받는 중 발견한 오류입니다.

tick 데이터는 msec 해상도를 가지는데, msec까지 같은 경우가 가끔 있습니다. 그런데 연속 조회시 마지막 데이터와 다음 조회시에 받을 데이터가 같은 msec인 경우에 연속 조회시 받을 수 있는 두가지 오류가 발견되었습니다.

 

일단 원 데이터를 보겠습니다.

아래는 2024년 1월 29일 선물 tick 데이터입니다. 09:39:36초에 총 4번의 거래가 발생하였음을 알 수 있습니다.

 

첫 번째 오류는 최근에 받은 tick 자료에 msec이 같은 tick이 더 있는 경우에 발생하는 오류입니다. 

아래 자료 중 밑에 있는 것은 이전에 받은 tick 정보입니다. 09:39:36초에 2건의 거래가 있었음을 알려줍니다. querycnt 값이 차서 이 상태로 돌려줍니다. 이때 cts_time 정보는 0939363755가 돌아옵니다. API ref를 보면 돌려주는 cts_time 정보를 다음 연속 query할 때 입력으로 사용하라고 명시되어 있습니다.  다음 query의 결과값은 0939363755 보다 큰 값을 가진 tick 정보를 돌려주는 방식입니다. 이 가정에서 오류가 발생하는데요.

 

앞에서 설명하였듯이 09:39:36초에는 총 4건의 거래가 있습니다. 다음 query에서는 이 전에 몇 건을 보냈는 정보를 관리하지 않아서 무조건 cts_time보다 큰 값을 가진 tick을 돌려줍니다. 따라서 미처 받지 못한 2건은 사라지게 됩니다.

 

ebest api를 수정할 방법은 없으니 회피 방법을 찾아봅니다.

 

cts_time을 전달할 때 query에서 준 값이 아닌 tick 정보 중 최근 값보다 큰 값을 전달하면 될 듯합니다. 기본 가정은 최신 tick 시간에는 중복된 데이타가 있다고 가정을 하는 것이죠. 이렇게 해보니 msec이 중복된 tick 정보는 모두 받을 수 있는데  또 한가지 처리하여할 문제가 발생합니다. 바로 중복 저장 문제입니다.

 

수정한 방식으로 연속 query를 하면 아래와 같이 09:39:36초 데이터가 중복으로 받아집니다. api 입장에서는 0939363755 틱을 이전에 받았는지 알 수가 없는 것이죠. 그래서 중복된 모든 tick 정보를 다시 전달해줍니다. 

 

이 또한 어쩔 수 없는 것이므로, 중복된 tick을 제거하는 방식으로 처리하여야합니다.

 

방법은 간단한데요. 이전에 받은 자료 중 같은 시간에 해당하는 tick의 수를 계산해서 이번에 받은 자료에서 그 만큼 차감하여 저장하면 됩니다. 이렇게 하면 아래와 같이 중복된 자료가 사라짐을 알 수 있습니다.

 

결과적으로 msec이 같은 tick 정보를 모두 받을 수 있고, 중복된 tick 정보도 제거할 수 있었습니다.

 

이런 과정없이 tick을 저장하신 분들이 msec이 같은 경우에 이빨이 빠져있을 수 있으니 이점 참고하시기 바랍니다.