GHTS

Xing API 현물 주식 주문 TR 기능 구현 후,

테스트를 진행하던 중 정정 및 취소 주문에서 에러가 발생해서,

오랜 시간동안 디버깅을 진행했다.

증상

정상 주문TR 실행 후 즉시, 정정 및 취소 주문 TR을 실행할 경우 에러가 발생.

정상 주문TR 실행 후 0.5초 가량 지난 후, 정정 및 취소하면 에러가 없음.

이유

정상 주문TR을 실행한 후 증권사 서버에서 응답을 받았더라도,

거래소 서버에는 아직 등록이 되지 않은 상태에서,

정정 및 취소 주문 TR이 오면 에러가 발생함.

0.5초 가량 기다리면 거래소 서버에도 등록이 되므로,

에러가 발생하지 않음.

해결책 

1. 0.5초 기다린다.

   : 0.02초에 주문이 실행되는 컴퓨터 매매 세계에서 0.5초는 기다리고 있기에는 너무 긴 시간.

   : 뭐라도 해야 한다.

2. 주문 체결 실시간 정보 확인

  : 거래소 서버에 등록이 된 것을 확인해 주는

   실시간 정보(SC0, SC1, SC2, SC3, SC4)를 수신한 이후에 정정 및 취소하면 에러 없음.

  : 실시간 정보가 UDP로 전달되므로, 패킷 로스로 인해서 제대로 전달되지 않을 가능성 존재.

  : 알고리즘이 복잡해 짐.

3. 단순 무식 반복.

  : 정정 및 취소 주문을 낼 때, 

    '잘못된 원주문번호' 내지 '주문 등록 대기 상태'라는 에러가 발생하면,

    정정 및 취소 주문TR 재실행.

 : TR 실행 및 응답은 TCP로 전달되므로, 항상 정확하게 응답을 받을 수 있다.

 : 에러 메시지를 보고 단순 재실행하기에 알고리즘도 간단하다.

3번 '단순 무식 반복' 방식을 채택하여 정정 및 취소 주문 TR 에러 해결.

이로써, 현물 주식 주문에 대한 내부 테스트 및 디버깅을 완료하고,

안정적인 주문 실행을 확인하였다.

처음에 에러 메시지를 제대로 확인하지 않아서 원인을 알지 못해,

DLL방식과 COM방식을 모두 시도해 보다가,

COM방식에서 에러 메시지를 확인하면서 실마리가 풀렸고,

테스트 서버의 에러 메시지에 버그가 있었던 것을 뒤늦게 발견하고 증권사에 수정 요청을 하는 등,

온갖 우여곡절을 겪은 기나긴 디버깅 이었다.

현 상황 : 2018년 6월 25일자로하도록 수정 및 디버깅을 마치고, 소스코드 커밋 완료.

이제 데이터 수집 및 분석을 시작할 단계...

Xing API를 DLL 방식으로 사용할 경우, 

초기화 과정에서 LoadLibrary() 호출은 반드시 Xing API DLL파일이 존재하는 디렉토리에서 해야 한다.

풀어서 쓰자면,

1. Xing API DLL이 설치된 디렉토리로 이동 (기본값은 C:\eBEST\xingAPI\)

2. LoadLibrary() 호출

3. 원래 작업 디렉토리로 복귀.

이렇게 반드시 Xing API 디렉토리로 이동하는 과정이 필요하다.

그렇지 않으면, 서버 접속은 되는 데, 로그인이 안 된다.

(당해보면 상당히 갑갑하다.)

COM방식에서는 이런 문제가 없다.

CSPAT로 시작되는 주식 현물 주문 TR의 경우,

거래소에 주문이 등록되지 않은 상태에서도 

주문번호가 부여되고 TR에 대한 응답이 돌아온다.

그래서, 해당 주문번호에 대해서 정정 내지 취소 TR을 실행할 경우,

해당 주문번호가 존재하지 않는다는 에러가 발생하기도 한다.

그래서, 정정 내지 취소 주문 TR을 실행할 때는

SC0~4 실시간 정보를 확인하거나,

에러가 발생하면 재실행 하는 등의 보완이 필요하다.