FIX & FEP 그리고 IT 이야기

오픈소스 라이선스에 대한 기본 상식

FIX & FEP — Wed, 22 Apr 2020 19:44:04 +0900

MIT License

- MIT 허가서는 미국의 매사추세츠 공과대학교에서 자기 학교의 소프트웨어 공학도들을 돕기 위해 개발한 허가서이다.
- MIT 허가서를 따르는 소프트웨어를 개조한 제품을 반드시 오픈 소스로 배포해야 한다는 규정이 없으며, GNU 일반 공중 허가서의 엄격함을 피하려는 사용자들에게 인기가 있다.
- MIT 허가서는 GNU 일반 공중 허가서(GPL)등과 달리 카피 레프트는 아니며, 오픈 소스 여부에 관계없이 재사용을 인정하고 있다.
- BSD 라이선스를 기초로 작성된 BSD계열 라이선스 중의 하나이다.
- 여러 가지 라이선스 중에서도 MIT 허가서는 매우 제한이 느슨한 라이선스라고 할 수 있다.
- 이 허가서를 따르는 대표적 소프트웨어로 X 윈도 시스템(X11)이 있다.
- MIT 라이선스는 미국 매사추세츠공과대학교(MIT)에서 해당 대학 SW 공학도들을 돕기 위해 개발한 라이선스다.
- 라이선스와 저작권 관련 명시만 지켜주면 되는 라이선스로, 가장 느슨한 조건을 가진 라이선스 중 하나이기 때문에 인기가 많다.
- 적용 사례 : 부트스트랩 , Angular.js, Backbone.js, jQuery

Apache License : 아파치 2.0 라이선스

- 아파치 라이선스(Apache License) 아파치 소프트웨어 재단에서 자체적으로 만든 소프트웨어에 대한 라이선스 규정이다.
- 아파치 2.0 라이선스는 누구나 해당 소프트웨어에서 파생된 프로그램을 제작할 수 있으며 저작권을 양도, 전송할 수 있는 라이선스 규정을 의미한다.
- 아파치 라이선스에 따르면 누구든 자유롭게 아파치 소프트웨어를 다운 받아 부분 혹은 전체를 개인적 혹은 상업적 목적으로 이용할 수 있음
- 재배포시에는 원본 소스 코드 또는 수정한 소스 코드를 반드시 포함시켜야 하는 것은 아니고, 아파치 라이선스, 버전 2.0을 포함시켜야 함
- 즉 아파치 소프트웨어 재단에 개발된 소프트웨어라는 것을 명확하게 밝혀야 한다.
- 소스코드 공개 의무도 없음
- 적용 사례 : 안드로이드(v2.0), 하둡(v2.0)

GPL

- GNU(Gnu is Not Unix, 그누) General Public License(GPL)
- 자유소프트웨어재단에서 만든 라이선스다.
- GNU 프로젝트로 배포하는 소프트웨어(Emacs, GNU 디버거(GDB), GNU 컴파일러 모음(GCC) 등)에 적용하기 위해 리처드 스톨만이 만들었다.
- Roughly, these licenses specify that GNU software may be copied, modified, and redistributed in any manner as long as the source code remains freely available.
- 가장 큰 특징은 자유소프트웨어재단답게 가장 강력한 제약 조건을 포함하고 있는 카피레프트 조항이다.
- GPL 프로그램은 어떤 목적으로, 어떤 형태로든 사용할 수 있지만 사용하거나 변경된 프로그램을 배포하는 경우 무조건 동일한 라이선스 즉, GPL로 공개해야 한다.
- 적용 사례 : 모질라 파이어폭스(v2.0), 리눅스 커널(v2.0), 깃(v2.0), 마리아DB(v2.0), 워드프레스(v2.0), 드루팔(v2.0)

AGPL

- GNU Affero GPL
- GPL을 기반으로 만든 라이선스로 버전1, 2는 아페로, 가장 최신 버전인 버전3은 자유소프트웨어재단에 의해 개발됐다.
- 수정한 소스코드를 서버에서만 사용하는 개발자가 그 프로그램을 배포하지 않을 경우 사용자는 소스코드를 가질 수가 없는 문제를 해결하기 위해 마련됐다.
- 서버에서 프로그램을 실행해 다른 사용자들과 통신하면, 실행되고 있는 프로그램의 소스코드를 사용자들이 다운로드할 수 있게 해야 한다는 독특한 조항을 담고 있다.
- 적용 사례 : 몽고DB(v3.0)

LGPL

- GNU Lesser GPL
- 자유소프트웨어재단의 강력한 철학이 담긴 GPL의 카피레프트 조항을 보완하기 위해 만든 라이선스다.
- GPL은 단순히 소프트웨어를 사용하기만 하더라도 해당 소스코드를 GPL로 공개해야 하는 부담감 때문에 상용 소프트웨어로 쓰기 부담스럽다는 단점이 있다.
- 그래서 좋은 자유 소프트웨어 제품이 더 많이 쓰이고 표준이 되도록 유도하기 위해 단순한 라이브러리·모듈 링크를 허용한 라이선스이다.
- 원래는 한정된 라이브러리에만 적용하려는 의도로 ‘Library GPL’이라는 이름을 붙였으나, 모든 라이브러리에 적용된다는 오해를 사 ‘Lesser GPL’로 변경됐다.
- 적용 사례 : 모질라 파이어폭스(v2.1)

Artistic License

- 펄 프로그래밍 언어를 사용하던 래리 월이 표준 펄 기능을 위해 만든 라이선스다.
- 이 단어의 어원은 문학에서 문법상 틀린 표현이라도 시적인 효과를 위해 허용한다는 걸 의미하는 'Articstic License'(시적 허용)를 참조해 만들어졌다.
- 적용 사례 : NPM(Node Package Manager)(v2.0)

Eclipse License

- 이클립스사에서 비즈니스 환경에 적합하도록 만든 기업 친화적인 라이선스로, 강력한 카피레프트 조항이 담긴 GPL보다 제약 조건이 완화된 라이선스이다.
- 적용 사례 : 이클립스(v1.0)

BSD License

- BSD : Berkeley Software Distribution
- 버클리의 캘리포니아대학에서 배포하는 공개 SW 라이선스다.
- BSD 자체가 공공기관에서 만들어낸 것이므로 공공의 몫으로 돌려주자는 의미가 강하므로, 라이선스 자체에는 아무런 제한 없이 누구나 자신의 용도로 사용할 수 있다.
- 라이선스 및 저작권 표시 조건 외엔 제약이 없는, 굉장히 자유로운 라이선스 중 하나이다.
- 적용 사례 : Nginx(The BSD 2-Clause License)

MPL

- Mozilla Public License
- 모질라 공용 허가서는 과거 넷스케이프 웹브라우저의 소스코드를 공개하기 위해 개발된 라이선스다.
- 초기 1.0버전은 넷스케이프 커뮤니케이션의 변호사였던 밋첼 베이커가 작성했고, 1.1과 2.0버전은 모질라재단이 작성했다.
- MPL의 특징은 소스코드와 실행파일의 저작권을 분리했다는 점이다.
- 수정한 소스코드는 MPL로 공개하고 원저작자에게 수정한 부분에 대해 알려야 하지만, 실행파일은 독점 라이선스로 배포할 수 있다.
- 즉 사용한 MPL 소프트웨어와 수정한 MPL 소프트웨어에 대한 공개 의무만 가지며, 별도의 소스코드와 실행파일은 독점 라이선스를 가질 수 있다.
- 적용 사례 : 모질라 파이어폭스(v1.1), 모질라 썬더버드(v1.1)

오픈소스 Software

- 1983년 9월 27일 리처드 스톨먼(Richard Stallman)이 GNU 프로젝트를 시작하면서 오픈소스 SW가 본격적으로 등장
- 주요 오픈소스 : 클라우드(오픈스택), 빅데이터(하둡), 모바일(안드로이드)
- SW개발시 오픈소스SW를 적절하게 사용한다면 비용절감과 개발시간 단축 등 다양한 측면에서 장점을 누릴 수 있음
- 소스코드가 공개되어 있고 무료로 이용,복제,배포,수정할 수 있지만 라이슨스가 존재함
- 오픈소스SW 라이슨스에서는 사용자가 오픈소스SW를 사용함에 있어서 누릴 수 있는 권리와 지켜야 할 의무사항들을 포함
- 오픈소스SW에 적용되는 라이슨스의 종류는 2,000종 이상으로 알려져 있음
- 대부분의 오픈소스SW는 OSI(Open Source Initiative)에서 인증한 라이슨스를 적용하고 있음
- 2012년 기준으로 OSI에서는 총 69종의 라이슨스를 인증함
- 69종의 오픈소스SW 라이슨스 중 상위 7종의 라이슨스가 전체의 90% 정도 차지
(이중 GNU GPL 계열의 라이슨스가 전체의 60% 이상을 차지)
- 오픈소스SW 라이슨스 종합정보제공 서비스 : www.OLIS.or.kr

오픈소스SW 라이슨스 사용조건 및 의무사항

구분	무료이용	배포허용	소스코드취득	소스코드수정	소스코드공개의무	독점(상용)SW와 결합
GNU GPL	O	O	O	O	O	X
GNU LGPL	O	O	O	O	O	O
MPL	O	O	O	O	O	O
BSD	O	O	O	O	X	O
Apache	O	O	O	O	X	O
Freeware	O	O	X	X	X	X

* BSD/Apache license가 가장 자유로운 규정

주요용어
- GPL v2 (GNU General Public License)
- LGPL v2 (GNU Library or Lesser General Public License)
- MPL (Mozilla Public License 1.1)
- BSD License
- MIT License

<라이슨스별 주요 소프트웨어 리스트>

1. GNU GPL : 리눅스 커널
2. GNU LGPL :
3. MPL : 모질라 어플리케이션 스위트, 모질라 파이어폭스, 모질라 선더버드, 미디어코더, 컴포저, 오픈솔라리스
4. BSD : sendmail
5. Apache 라이슨스 : Android, Hadoop(Apache v2 license), OpenStack
* 구글이 2007년 아파치 라이선스 기반으로 안드로이드를 오픈소스화함
6. MIT License : X-window

Open source groups

1. Apache Software Foundation
- Cassandra, Cordova, CloudStack, CouchDB, Geronimo, Hadoop, Hive, HTTP Server, Lucene, OpenOffice, Struts, Subversion and Tomcat

2. Linux Foundation

3. Free Software Foundation
- That is software that you can freely copy, use, modify, and redistribute as you wish.
- The only condition is that the source code of these programs must be freely available on demand.
- It is important to understand that the term Free in Free Software Foundation does not refer to price, but to freedom.
- These programs can be bought and sold, but there is always a legal way to obtain them gratis.
- Richard M. Stallman
- GNU 그래픽 데스크톱인 GNOME 1.0
- GNU Project

cf. W3C(World Wide Web Consortium) groups

블룸버그(Bloomberg) Fix Hub EMSxNET

FIX & FEP — Tue, 24 Dec 2019 12:39:49 +0900

FIX를 이용해서 해외 기관과 연결하기 위한 방법은 여러가지가 있을 수 있다. BT Radianz나 TNS 처럼 글로벌 네트웍 사업자를 통해서 상대기관(브로커, 거래소 등)에 직접 연결하는 방법이 있다. 이때에는 상대기관과 FIX 연결정보를 확인하고, 네트웍 사업자에서 제공하는 NAT IP를 기반으로 방화벽/라우팅 등을 설정하고 진행하면 된다.

블룸버그 처럼 중간에 Fix 허브 사업자를 경유해서 상대기관에 연결할 수도 있다. 이러한 허브 사업자들 중 대표적인 곳이 로이터, 블룸버그 등이 있다. Fix 허브에는 Fix 서버가 구성되어 있다고 보면 된다. 상대기관과 직접 FIX 세션을 연결할 필요가 없다. 단지 허브 사업자에게 연결정보를 받아서 FIX로 세션을 구성하면 된다. 상대기관도 동일하게 허브사업자와 FIX로 연결이 될 것이고, 허브사업자인 블룸버그에서 라우팅을 통해 연결을 해 주게 된다.

블룸버그 Fix Hub 시스템을 EMSxNET이라고도 부른다. 회원사와 상대기관이 모두 중간에 있는 Fix 허브에 FIX로 붙고, 블룸버그에서 라우팅을 해준다. 블룸버그에서는 하나의 FIX 세션으로 여러기관에 라우팅(Tag.128 DeliverToCompID 등으로 구분)을 할 수도 있다. 이렇게 라우팅이 가능한 구조로 설계가 되어서 그런지 블룸버그에서는 주문번호(Tag.11 ClOrdID)를 변환시켜 버린다. 네트웍 또는 기타 장애로 인해 상대기관과 주문/체결 내역을 대사할 경우 주문번호로 맞추기가 쉽지 않다. 이때에는 시간으로 맞추는 방법이 있고, 중간에 Fix 허브 사업자인 블룸버그도 같이 참조로 걸어서 주문번호 매핑 정보를 확인해도 된다. 대사에 따른 번거로운 절차를 회피하기 위해 별도로 상대기관과 추가 태그(예를들면 Tag.58 또는 사용자정의 태그)를 정의해서 해당 태그에 주문번호를 실어서 보내도 된다.

CME iLink 주문 개발 및 운영

FIX & FEP — Thu, 19 Dec 2019 09:20:31 +0900

CME는 서울에 허브를 두고 있기 때문에 거래소에 매매 라이선스가 있다면 직접 주문이 가능하다. 청산 라이선스는 발급받기가 어렵기 때문에 보통 국내 회원사들은 글로벌 청산회사(Clearing Firm)를 이용하면 된다.

CME 서울 허브 MDP 시세와 같이 주문 개발환경도 인터넷VPN으로 연결된다. 운영 환경은 목동/상암 데이터센터까지 전용선을 연결하면 된다. 주문과 시세 회선은 동일한 것을 사용하면 된다. 주문환경이 구성이 되면 개발 FIX 연결을 위한 SenderCompID와 TargetCompID 등 접속정보를 받아볼 수 있다. 개발환경은 크게 Cert 세션과 NRCert 세션으로 나눌 수 있다. MDP 시세 수신시에 언급했던 것과 유사하다. 현재 운영중인 시스템과 비슷한 환경으로 구성되어 있는 Cert와 CME에서 현재의 개편사항이 반영된 NRCert 세션이 있다고 보면 된다.

운영환경에 대한 세션 정보는 회원사가 지정한 청산회사를 통해서 받을 수 있다. 시스템은 직접 CME에 연결이 되지만 관리는 청산회사를 통해서 처리된다고 보면 된다. iLink(CME 직접 주문을 위한 FIX 시스템) FIX 접속을 위해 Access ID와 Secure Key를 필요로 한다. 해당 키 정보는 1년을 주기로 만기가 도래하며, 청산회사를 통해서 갱신할 수 있다. 하지만 대부분의 청산회사는 회원사 자체에서 처리할 수 있도록 권한을 이양하는 경우가 많다. 그러면 매매 회원사는 CME 웹사이트에 로그인 하여 Access ID와 Secure Key를 직접 발급받을 수 있다.

- 개발 : https://loginnr.cmegroup.com

- 운영 : https://login.cmegroup.com

* iLink 세션 정책 가이드 : https://www.cmegroup.com/globex/files/iLinkSessionIDPolicy.pdf

발급받은 키 정보는 FIX 로그인시(35=A) 함께 보내야 하는 정보로 FIX 엔진 제공업체를 통해서 해당 기능을 제공하는지 확인해보면 된다. 새로운 키를 발급받을 경우 기존키는 4주 후에 만기(Expired) 되므로 그 전에 적용을 끝마쳐야 한다. 키 적용은 주중에 적용해도 무방하다. 만기가 도래하기 전에 갱신될 수 있도록 일자 관리에 신경을 필요가 있다.

FIX 세션 운영시 주의해야 할 점

해외기관의 경우 써머타임(Summer time, DST)의 적용을 받기 때문에 상대 기관이 유럽DST 타임존인지 미국DST 타임존이지 확인해서 그에 맞게 조정을 해줘야 한다. CME FIX는 시퀀스 초기화가 일주일 단위(Weekly) 이므로 월요일 시작시간, 토요일 종료시간만 설정하면 되므로 DST의 영향은 덜 받는 편이다. 하지만 주의할 점이 있다. CME는 로그인 실패시 재로그인 시도를 너무 자주 하는 경우, 세션이 잠길 위험(Port Closure)이 있다. 이를 방지하기 위해서 FIX 엔진 제공업체에서 너무 빈번하게 로그인 시도를 막을 수 있는 옵션을 제공하는 경우도 있다.

써머타임(Summer Time, DST(Daylight Saving Time))

- 미국DST : 3월 둘째 일요일 ~ 11월 첫째 일요일

- 유럽DST : 3월 마지막주 일요일 ~ 10월 마지막주 일요일

CME MDP 시세 수신 개발

FIX & FEP — Tue, 17 Dec 2019 16:36:25 +0900

CME는 서울에 목동/상암 IDC 센터를 통해서 iLink FIX를 통해 직접 주문내고, MDP 시세도 수신받을 수 있도록 CME 허브(Hub)를 구축해 놓았다. CME와의 시세수신 계약이 끝나고 시세를 수신할 수 있도록 네트웍 구성이 완료되면 멀티캐스트 형태의 시세를 수신 받아서 개발할 수 있다. 개발환경은 인터넷 VPN으로 되어 있고, 운영은 전용선을 구축하면 된다.

시세 개발을 위해서는 먼저 환경설정 파일을 다운로드 받아야 한다. http://ftp.cmegroup.com 에서 다운 받아볼 수 있다. anonymous 계정으로 오픈되어 있다. FTP 사이트에서 SBEFix 디렉토리에 들어가 보면 Cert, CertAutoCertPlus, NRAutoCertPlus, NRCert, Production 디렉토리가 있다. Cert(Certificate)는 ASIS 개발 환경을 의미하고, NRCert(New Release Certificate)는 TOBE 개발환경을 의미한다. Production은 운영환경을 의미한다.

NRCert에 있던 것이 운영환경으로 이행이 되면, Cert에도 최신으로 업데이트 되고, Production도 변경되게 된다. 그러므로, Cert와 Production은 Template 입장에서는 비슷하다고 보면 된다. (Template는 동일하지만, config는 다름). AutoCertPlus는 자동으로 구성되는 환경이라고 보면 된다. 주문이던 시세이던 최초 구축 또는 제도변경으로 인한 변경 적용을 위해 CME에서 Certificate를 받도록 요구하는 경우가 있다. 이때 웹화면에서 자유롭게 Certificate를 받을 수 있게 자동화된 형태로 구축된 웹사이트가 있다. (https://autocert.cmegroup.com) 로그인을 위해서는 아이디와 계정이 필요한데 CME의 계좌 관리자(Account Manager)에게 문의하면 된다.

일반적으로 브로커들과 FIX 세션을 생성할 때에는 해당 브로커의 담당자와 스케줄을 정해서 적합성테스트(Certificate)를 진행하는 경우가 많다. 그런면에서 CME는 시스템을 잘 갖춰 놓았다고 볼 수 있다.

제도 개편 등으로 개발환경에 선 적용이 되면, CME에서 NRCert에 환경설정정보 및 Template 파일을 올려놓게 된다. 회원사들은 NRCert에서 필요한 파일들을 다운로드 받아서 개발을 시작하면 된다. 살펴봐야할 파일은 Configuration/config.xml과 Templates/templates_FixBinary.xml이다. config.xml은 아이피, 포트, 채널정보가 들어있는 설정파일이고, templates_FixBinary.xml은 SBE(Simple Binary Encoding) 파싱을 위한 템플릿 파일이다. 새로운 버전이 생기면 templates_FixBinary_v10.xml와 같은 식의 파일이 생성되어 있는 것을 확인해볼 수 있다.

템플릿 파일을 다운로드 받으면, 해당 템플릿 기반으로 SBE 파싱을 위한 cpp 클래스 헤더 파일들을 생성할 수 있다. 헤더 파일 생성을 위해서는 오픈소스로 되어 있는 sbe-all-1.4.2-RC4.jar를 사용할 수 있다.

https://jar-download.com/artifacts/uk.co.real-logic/sbe-samples/1.4.2-RC4/source-code

헤더파일을 생성할 수 있는 스크립트는 다음과 같이 할 수 있다. (java 1.8 이상 사용)

java -Dsbe.target.language=cpp -Dsbe.generate.ir=true -Dsbe.output.dir=$HOME/gensrc -Dsbe.keyword.append.token=_ -jar sbe-all-1.4.2-RC4.jar templates_FixBinary.xml

위 프로그램 실행이 되면 템플릿에 기반한 SBE 파싱을 위한 클래스들이 정의된 헤더(*.h) 파일들이 생성되어 있는 것을 확인할 수 있다. 생성된 헤더 파일을 include 하여 시세 수신을 개발하기 시작하면 된다. 수신된 MDP 데이터 전문에는 템플릿 버전이 포함되어 있는데 그 버전을 확인하고, 파싱을 진행하도록 코딩하는 것이 좋다.

CME 서울Hub에 대한 기본 지식

FIX & FEP — Wed, 11 Dec 2019 08:56:41 +0900

CME 거래소는 전세계 파생상품시장에서 차지하는 비율이 상당히 높은 거래소이다. 국내에서 해외파생을 거래하는 경우 90% 이상이 CME 거래소를 이용한다고 해도 무방한다. 해외주식의 경우 국가마다 상장된 종목이 틀리기 때문에 다양한 국가의 증권거래소가 나름의 경쟁력을 갖추고 있다고 볼수 있다. 하지만 실물자산이 한정되어 있는 해외파생의 경우 유동성 공급이 원활한 메이저 거래소에서 독식하는 경향이 뚜렷하다.

CME 거래소는 서울에 물리적으로 Hub를 구축하였다. 목동과 상암 데이터 센터에 허브가 구축이 되어 있어서 CME Globex (시카고)로 직접 연결할 수 있는 구조를 만들어 준 것이다. 실제로는 일본(AT도쿄, 일본NTT)을 거쳐서 태평양을 통과하게 되어 있다. 국내 증권/선물사들은 CME Hub에 연결해서 FIX로 직접 주문을 낼 수 있고, CME의 MDP 시세도 직접 받아볼 수 있다.

CME 상암데이터 센터는 Verizon 회선을 통해 일본 AT도쿄로 연결되고, 다시 Verizon 회선을 통해 시카고 CME Globex 시카고로 연결된다고 한다. CME 목동데이터 센터를 통하는 경우 NTT회선을 통해 일본NTT로 연결되고 NTT회선을 통해 다시 시카고로 연결되는 구조이다. 일본을 통해 시카고로 가는 회선 장애를 대비해서 영국 등 다른 나라를 경유할 수 있는 백업회선도 구축되어 있다고 한다.

보통 회원사들은 CME 상암/목동을 각각 연결해 놓는다. 시세의 경우 양쪽에서 동시에 수신하면 되니까 크게 문제가 될 것은 없다. 주문의 경우 문제가 발생할 소지가 조금은 있다. 회원사-CME Hub 구간은 당연히 확인이 가능하다. 확인이 가능하다는 것은 네트웍 장애 발생시 자동 테이크오버를 통해 정상적으로 서비스할 수 있음을 의미한다.

앞서 말한 것처럼 일본-시카고 구간은 네트웍 장애시 백업 대책이 있지만 서울-일본은 약간의 이슈가 발생할 수 있다. 서울-일본간 구간에 문제가 발생할 때 감지가 어렵기 때문이다. 해당 구간 문제 발생을 대비하여 BGP 프로토콜을 통해서 회선상태정보를 전송해 주게 되어 있지만, 테스트하기가 어렵고 정상 동작한다고 보장하기도 어렵다. 가장 좋은 방법은 각 회원사에서 FIX 연결 타임아웃 발생시 회선을 다른 CME Hub로 변경시키는 것이다.

CME FIX 주문

CME 거래소의 경우 일반적인 FIX엔진으로 주문을 내기가 어렵다. 최초 로그인시 Secure Logon 등 CME에서 요청하는 조건을 충족시키기 어렵기 때문이다. 전세계적으로 사용이 많은 거래소라 FIX 엔진 제공업체에서 CME 접속을 위한 환경을 제공해 주는 경우가 많다. 주문의 경우 회선을 크게 할 필요는 없어보인다. 대역폭이 1MB 정도면 충분하다고 판단된다. 시세도 같이 수신하는 경우 시세 회선은 최소 200MB 이상으로 크게 사용하기 때문에 함께 사용해도 무방하다.

FIX Secure Logon을 위해서 CME Customer Center에 로그인해서 Access ID와 Secret Key를 발급해야 한다. 만기는 1년 단위이며 갱신은 만기 몇일 전이든 관계는 없다. 단 새로운 키를 발급받았을 경우 4주 후에는 기존에 키는 자동으로 폐기(Expired) 된다고 한다. 키 발급에 대한 관리는 청산FCM에서 대신해 줄 수 있지만, 현재 대부분 회원사에서 직접 하고 있는 추세이다.

CME MDP 시세 수신

CME 시세는 멀티캐스트 형태로 제공해준다. 여러개의 다양한 채널을 가지고 있으며, CME 내부에서 채널별로 품목들을 할당해 놓았다. CME에서 제공하는 ftp 사이트에서 환경설정 정보를 내려받아 확인해볼 수 있다. CME 상암/목동 각각에서 변동분 실시간 시세와 스냅샷을 제공해 주고 있다. 스냅샷은 전품목에 대해 현시점에서의 시세를 제공해 주는 것으로 거의 실시간에 가깝게 느껴질 정도로 자주 많은 데이터가 발생한다.

UDP 시세의 특성상 유실의 가능성이 존재하기 때문에 넉넉한 회선을 확보할 필요가 있다. 선물/옵션을 다 하는 경우에는 최소 300MB 이상의 회선은 확보되어야 할 것으로 보인다. 회선장애에 대비하고, 패킷누락을 보정하기 위해 시세 수신을 목동/상암에서 동시에 수신하여 상호 보정하는 것을 추천한다. 또한 스냅샷 데이터도 받아서 누락분에 대한 이차 보정도 함께 수행하면 더 좋다. 스냅샷 데이터는 상암/목동 중 한 곳에서만 수신하고, 문제 발생시 다른쪽에서 수신을 시작하는 것이 좋다. 스냅샷 시세의 양도 상당하기 때문이다.

FIX 주문 관련 주요 태그

FIX & FEP — Tue, 10 Dec 2019 15:20:32 +0900

거래소코드(Exchange)
- 거래소코드를 사용, 거래소코드는 보통 SecurityExchange(207)태그를 사용하거나 ExDestination(100)태그를 사용함
- CME Hub를 통해 거래소 iLink에 직접 주문을 낼 때에는 거래소코드 사용하지 않음
- Execution destination as defined by institution when order is entered.

품목코드
1. Symbol(55)
- Ticker symbol. Common, "human understood" representation of the security.
- Use "[N/A]" for products which do not have a symbol.
- 선물의 경우 품목 결제월을 제외한 순수 품목코드(Contract code)
- 선물의 경우 MaturityMonthYear(200)과 함께 쓰임

2. SecurityID(48) / SecurityIDSource(22)
- SecurityID(48)이 설정되어 있으면 반드시 SecurityIDSource(22) 태그가 필요함
- SecurityID(48) value can be specified if no symbol(55) exists
(e.g. non-exchange traded Collective Investment Vehicles)
- SecurityIDSource(22) : 1(CUSIP), 2(SEDOL), 3(QUIK), 4(ISIN), ...

* ISIN 코드

- 국내주식/파생의 경우 예탁원 또는 한국거래소에서 ISIN 코드를 관리해줌

- 해외주식의 경우 예탁원에서 ISIN 코드를 관리해줌

- 해외파생의 경우 별도로 ISIN 코드를 관리해 주는 기관이 없음

. 해외주식에서 거래소 심볼을 키로 사용하여 주문을 내는 경우, 다른 거래소에서 동일 종목이 상장될 경우 문제가 발생할 소지가 있지만 해외파생의 경우 내부적으로 시스템코드를 관리하여 중목 이슈를 방지한다.

. 해외파생상품시장에서 사실상 국제표준코드 역할을 하고 있는 Bloomberg Ticker, 로이터코드(RIC)도 내부적으로 관리해서 사용하는 것을 권고 한다. 해당 코드들은 해외주식과 같이 중복의 이슈가 발생할 가능성이 없다.

가격(Price)
1. Price(44) : 주문가격, 지정가주문(40=2)의 경우 이곳에 가격을 넣는다.
2. LastPx(31) : 체결가격
3. AvgPx(6) : (체결)평균단가?, SUM(LastPx*LastQty)/CumQty
4. BidPx(132) : 매수호가
5. OfferPx(133) : 매도호가
6. StopPx(99) : Stop주문 stop 가격
7. StrikePrice(202) : 옵션에 대한 행사가격

수량(Quantity)
1. OrderQty(38) : 주문수량 => 체결시에 주문수량은 그대로 내려옴
2. LastQty(32) : 체결수량
3. CumQty(14) : 누적체결수량
4. LeavesQty(151) : 미체결잔량
※ 주문수량(OrderQty) = 누적체결수량(CumQty) + 미체결잔량(LeavesQty)

주문유형
1. OrdType(40)
1 - Market(시장가)
2 - Limit(지정가)
3 - Stop(손절)
4 - StopLimit(지정가손절)
5 - MarketOnClose
6 - WithOrWithout
7 - LimitOrBetter
8 - LimitWithOrWithout ...

TimeInForce(59)
0 - Day
1 - GoodTillCancel
2 - AtTheOpening
3 - ImmediateOrCancel(IOC)
4 - FillOrKill
5 - GoodTillCrossing
6 - GoodTillDate
7 - AtTheClose
- GTD주문의 경우 보통 432(ExpireDate) 또는 126(ExpireTime) 사용

주문번호 및 트레이딩 ID
1. ClOrdID(11) : 주문번호
2. OrigClOrdID(41) : 원주문번호
3. OrderID(37)
- FCM에서 거래소로 주문낼 때 사용하는 주문번호
- FCM에서 체결데이터 보내줄 때 이 주문번호를 보내줌
4. SecondaryOrderID(198)
5. ExecID(17) : 체결번호로 체결메시지에 있는 유일한 값 (FCM과 체결내역 대사할 때 사용)
6. ClientID(109) : 주문시 Client에서 보냄, 주문확인/주문체결내역 정보에는 안 쓰임, FIX4.3부터 사라짐

날짜 및 시간
1. SendingTime(52) : FIX 엔진에서 생성되는 전송시간, UTC 시간 사용
2. TransactTime(60) : 업무에서 보내주는 거래시각으로 UTC 시간 사용
3. OrigSendingTime(122)
4. OrigTime(42) : Time of message origination, 일반 메시지들의 발생시각이므로 주문관련 메시지에서는 미사용???
5. TradeDate(75)
- Indicates date of trade referenced in this message in YYYYMMDD format. Absence of this field indicates
current day (expressed in local time at place of trade).

HandlInst(21)
- FCM에서 개입을 할지여부를 결정하는 것으로 일반적으로 1로 설정
- DMA orders(low-touch) are sent directly to the exchange/MTF/ECN without any intervention. (21=1)
- CARE orders(high-touch) are sent to an OMS to be worked by the broker.(21=3)
- Used In
. Order Cancel/Replace Request  정정주문
. Order - List  신규주문(다건)
. Order - Single  신규주문(단건)
- 취소주문에는 21 태그가 없다.
- 태그 값
1=Automated execution order, private, no Broker intervention
2=Automated execution order, public, Broker intervention OK
3=Manual order, best execution

설명(상세기술)
1. Text(58)
- CME의 경우 Business Reject인 경우 35=3 메시지를 통해 거부처리하고, 58태그에 상세 내용 기입
예 : 58(Text)=Business Reject: Required Field Missing priceistoolarge:
2. OrdRejReason(108)
3. CxlRejReason(102)
- 취소거부(Cancel Rejection) 사유를 나타내기 위한 코드값, 35=8과 함께 쓰임
(0=Too late to cancel, 1=Unknown order, 2=Broker / Exchange Option ...)
4. CxlRejResponseTo(434)

- 취소거부에 대한 요청유형을 구분하기 위한 코드값 (1=Order Cancel Request, 2=Order Cancel/Replace Request)
5. ExecRestatementReason(378)
- 실행타입 변경을 나타내기 위한 코드값, 내용은 String(58) 태그 사용
(0=GT Corporate action, 1=GT renewal / restatement (no corporate action), 2=Verbal change, 3=Repricing of order ...)

Side(54)
- 1 : Buy
- 2 : Sell
- 3 : Buy minus
- 4 : Sell plus
- 5 : Sell short
- 6 : Sell short exempt

PutOrCall(201)
- PutOrCall(201) 0:Put, 1:Call, SecurityType(167)과 함께 쓰임
- FIX 4.3부터는 사라짐
- FIX 4.3부터 CFICode(461)을 가지고 구분
. CFI Code가 F로 시작하는 경우 선물
. CFI Code가 OP로 시작하는 경우 풋옵션, OC로 시작하는 경우 콜옵션

FIX 주문/접수/체결 시나리오

FIX & FEP — Tue, 10 Dec 2019 15:06:40 +0900

일반적인 주문은 다음과 같은 시나리오가 가정해 볼 수 있다.

1. 주문 시나리오

(1) 신규주문(35=D), 주문접수(35=8,39=0), 부분체결(35=8,39=1)
(2) 신규주문(35=D), 주문접수(35=8,39=0), 체결완료(35=8,39=2)
(3) 취소주문(35=F), 취소접수(35=8,39=6), 취소확인(35=8,39=4)
(4) 정정주문(35=G), 정정접수(35=8,39=E), 정정확인(35=8,39=5), 정정체결(35=8, 39=1 or 2)

MsgType(Tag.35)
8 = ExecutionReport (주문접수/확인/체결)
9 = OrderCancelReject (취소주문 거부)
D = NewOrderSingle (신규주문)
F = OrderCancelRequest (취소주문)
G = OrderCancelReplaceRequest (정정주문)

MsgType (Tag.150)	OrderStatus (Tag.39)
0 = New 3 = Done for Day 4 = Canceled 5 = Replaced 6 = Pending Cancel, ie result of order cancel Request 7 = Stopped 8 = Rejected 9 = Suspended C = Expired E = Pending Replace	0 = New 1 = Partially Filled 2 = Filled 3 = Done for Day 4 = Canceled 5 = Replaced (Deprecated FIX 4.3) 6 = Pending Cancel, ie result of order cancel Request 7 = Stopped 8 = Rejected 9 = Suspended E = Pending Replace

- 정정주문확인에서 가격은 정정주문가격이 아니라 원주문가격이 내려옴(Barclays)
- 주문시 Omni 계좌번호 외에 개별 계좌번호도 전송해주는데 FCM별로 필드가 상이함

2. 거부 시나리오

위에서는 정상적인 경우의 시나리오라고 볼 수 있다. 하지만 각 주문에 대해 거부가 발생할 경우가 있으므로 그에 대한 시나리오를 살펴본다.

(1) 신규주문(35=D), 주문접수(35=8,39=2), 주문거부(35=8,39=9)
(2) 취소주문(35=F), 취소확인(35=8,39=6), 취소거부(35=9)
(3) 정정주문(35=G), 정정접수(35=8,39=E), 정정거부(35=9)
(4) 신규/정정/취소주문, 비즈니스거부(35=j)

(5) 신규/정정/취소주문, 거부(35=3)

FIX 세션 메시지 - 테스트 및 거부

FIX & FEP — Tue, 10 Dec 2019 14:41:31 +0900

로그인과 리커버리 메시지 외에 테스트요청(35=1), 세션거부(35=3) 등의 메시지가 있다.

테스트 메시지

먼저 테스트요청 메시지를 살펴보겠다. 앞서 로그인 시나리오에서 세션이 비정상일때 송신한 적이 있다. 테스트 요청은 일반 Heartbeat와 유사하지만 MsgType(Tag.35)를 1(TestRequest)로 요청하고 0(Heartbeat)로 응답받는다. 한가지 다른 점은 테스트 요청시에 112 태그에 원하는 메시지를 넣어서 보낸다. 그러면 테스트 요청을 받은 곳에서는 112로 수신된 메시지를 112 태그에 실어서 Heartbeat(35=0)으로 응답한다.

<테스트 요청 (TestRequest(35=1))>
[out]8=FIX.4.4^A9=104^A35=1^A34=2294^A52=20111207-04:15:21.533^A49=ACOMPID^A56=BCOMPID^A112=This is
Test Request Message^A10=175^A

<테스트 응답 (Heartbeat(35=0))>
[in]8=FIX.4.4^A9=99^A35=0^A49=BCOMPID^A56=ACOMPID^A34=727^A52=20111207-04:15:22^A112=This is Test
Request Message^A10=146^A

거부 메시지

세션 메시지 중에 또 하나 중요한 메시지는 세션거부(35=3)이다. 최초 세션 생성시에 잘못된 정보로 로그인 시도를 할 경우에 로그인 거부를 위해서도 쓰이지만, 비즈니스 메시지에 잘못된 태그를 사용해서도 발생할 수 있다. 비즈니스 메시지의 경우 세션 거부될 경우에는 비즈니스적으로 해야할 일이 있을 수 있다. 예를들어 주문을 낼 경우 해당 주문시 발생한 증거금을 해지해 주는게 하나의 예일 것이다.

비즈니스에서 거부를 처리하기 위해서는 RefSeqNum(Tag.45)가 중요한 역할을 한다. 이것을 통해 어떤 메시지에 대한 거부인지 확인을 할 수 있기 때문이다. 세션거부 메시지 수신시 주문내역에서 해당하는 MsgSeqNum를 조회하여 주문내역을 확인할 수 있다. (주문내역을 확인할 수 있는 기능은 보통 FIX 엔진 기능에 포함되어 있다.)

주문/체결 송수신 매핑 프로세스를 관리하는 경우에는 거부메시지 수신시 45 태그에 있는 시퀀스 번호를 토대로 주문내역을 확인하여 주문번호 등을 설정해 줄 수 있다.

다음은 정정취소주문(35=G)에 대한 거부(35=3) 예제이다. 텍스트 필드(Tag.58)에 사유를 보내주다. 45=15440이 수신되었으므로 MsgSeqNum이 15440인 메시지에 대한 거부임을 알 수 있다.

<거부 메시지 수신>
[08/01 08:10:31.481990] SESSIO>> [S]-

[8=FIX.4.2^A9=269^A35=G^A49=ACOMPID^A56=BCOMPID^A34=15440^A50=220250368421^A142=KR^A57=G^A52=20180731-23:10:31.4

81^A369=21070^A1=725DAE03^A11=O20180801194220^A21=1^A38=1^A40=2^A44=1.1729000^A59=0^A41=O2018080119431^A54=1^A55
=M6E^A60=20180731-23:10:31.478^A167=FUT^A200=201809^A1028=Y^A107=M6EU8^A204=0^A9702=1^A9768=Y^A10=114^A]

[08/01 08:10:31.650341] SESSIO>> [R]-

[8=FIX.4.2^A9=181^A35=3^A34=21071^A369=15440^A52=20180731-23:10:31.565^A49=BCOMPID^A50=G^A56=ACOMPID^A57=2202503
68421^A143=KR^A45=15440^A58=OrderID (37) must be present on a Cancel or Cancel Replace
Request^A1028=Y^A10=036^A]

FIX 세션 메시지 - 로그인

FIX & FEP — Tue, 10 Dec 2019 13:48:27 +0900

FIX가 세션 정보를 바탕으로 구성을 완료했으면, 실제 메시지가 어떻게 흘러가는지 확인해 보자.

1. 재전송(Recovery)이 없는 경우 로그인

클라이언트 (예: ACOMPID)	서버 (예: BCOMPID)
로그인 요청(35=A)
	로그인 응답(35=A)
Heartbeat 전송(35=0)
	Heartbeat 응답(35=0)

시퀀스(Sequence)가 초기화 된 이후의 최초 로그인은 양쪽에서 MsgSeqNum(Tag.34)이 1번부터 시작하므로 재전송이 발생하지 않는다. 초기화 시점이 서로 틀린 경우에는 재전송이 발생할 수 있겠지만, 정상적인 상황을 가정하고 로그인 절차를 살펴보면 다음과 같다.

Case #1

<로그인 요청>

8=FIX.4.2^A9=70^A35=A^A49=ACOMPID^A56=BCOMPID^A128=ABC^A34=1^A52=20101109-22:00:09^A108=30^A98=0^A10=007^A

<로그인 응답>

8=FIX.4.2^A9=70^A35=A^A34=1^A49=ACOMPID^A56=BCOMPID^A52=20101109-22:00:09^A108=30^A98=0^A10=222^A

기관에 따라 로그인시에 Tag.128(DeliverToCompID) 등 특정 태그에 지정된 값을 요청하는 경우가 있다. 해당 기관에서 제공해준 값을 설정하면 된다. 보통 Heartbeat 주기는 30초(108=30) 또는 60초로 로그인 요청을 했다.

Case #2

<로그인 요청 - Sequence 초기화>
[06:57:07][out|8=FIX.4.4^A9=85^A35=A^A49=ACOMPID^A56=BCOMPID^A34=1^A52=20111218-21:57:06.999^A98=0^A108=60^A141=Y^A789=1^A10=074^A]

<로그인 응답 - Sequence 초기화>
[06:57:08][in|8=FIX.4.4^A9=75^A35=A^A49=BCOMPID^A56=ACOMPID^A34=1^A52=20111218-21:57:08^A108=60^A98=0^A141=Y^A10=091^A]

로그인시에 141=Y을 이용해서 강제로 Sequence 초기화 요청을 하였다. CME 거래소 처럼 기관에 따라 141=Y을 허용하지 않는 경우도 있다.

태그/값	태그명	설명
8=FIX.4.4	BeginString	FIX 버전 4.4 사용을 의미
9=85	BodyLength	FIX 전문 길이를 의미(Tag8,9,10 필드를 제외한 길이)
35=A	MsgType	로그온
49=ACOMPID	SenderCompID	송신 CompID
56=BCOMPID	TargetCompID	수신 CompID
34=1	MsgSeqNum	시퀀스 번호(최초 로그인시에는 1로 시작함)
52=20111218-21:57:06.999	SendingTime	전송시간(FIX 엔진에서 자동으로 시간 지정, UTC시간)
98=0	EncryptedMethod	전문을 암호화하지 않겠다는 의미
108=60	HeartBtInt	Heartbeat 주기를 지정(단위: 초)
141=Y	ResetSeqNumFlag	강제로 시퀀스를 초기화 할지 지정
789=1	NextExpectedMsgSeqNum	기대하는 FIX 시퀀스 번호를 보냄
10=074	CheckSum	FIX 메시지 정합성을 위한 체크섬

2. 재전송(Recovery)이 발생하는 경우 로그인

클라이언트 (예: ACOMPID)	서버 (예: BCOMPID)
로그인 요청(35=A)
	로그인 응답(35=A)
재전송 요청(35=2)	재전송 응답(35=4)
재전송 응답(35=4)	재전송 요청(35=2)

재전송 요청은 순차적으로 발생하는 것은 아니고 양쪽에서 동시에 요청할 수도 있다. 하지만 이해를 돕기 위해서 한쪽에서 요청하는 시나리오 예를 들어보자. 아래는 네트웍 단절 등 비정상 상황이 발생하여 응답이 없는 경우 테스트 요청을 보내고, 그래도 응답이 없어서 로그인 시도를 다시 하고 있는 예제이다.

[19:22:38][in|8=FIX.4.4^A9=60^A35=0^A49=BCOMPID^A56=ACOMPID^A34=5102^A52=20111222-10:22:38^A10=134^A|X|X]

정상적으로 Heartbeat이 수신되었다. 마지막으로 MsgSeqNum(Tag.34)가 5102임을 알 수 있다.

[19:22:56][out|8=FIX.4.4^A9=64^A35=0^A49=ACOMPID^A56=BCOMPID^A34=5069^A52=20111222-10:22:56.940^A10=097^A]

정상적으로 Heartbeat를 송신하였다.

[19:23:51][out|8=FIX.4.4^A9=90^A35=1^A49=ACOMPID^A56=BCOMPID^A34=5070^A52=20111222-10:23:51.285^A112=20111222-10:23:51.285^A10=078^A]

Heartbeat이 발생하지 않아 TestRequst(35=1)을 보내서 상태를 확인한다.

[19:24:51][out|8=FIX.4.4^A9=64^A35=0^A49=ACOMPID^A56=BCOMPID^A34=5071^A52=20111222-10:24:51.454^A10=087^A]

Heartbeat 송신 주기가 되어 발생된 Heartbeat이다.

<1. 로그인 요청 - 장애에 의한 재로그인>

[19:25:03][out|8=FIX.4.4^A9=85^A35=A^A49=ACOMPID^A56=BCOMPID^A34=5072^A52=20111222-10:25:03.581^A98=0^A108=60^A789=5103^A10=054^A]

TestRequest 요청에 대한 응답이 없어서 세션이 끊긴 것으로 판단한다. 세션이 끊겼으므로 로그인 요청(35=A)을 한다. NextExpectedMsgSeqNum(Tag.789)가 5103이라는 것은 위에서 마지막으로 수신받은 메시지의 MsgSeqNum이 5102이기 때문이다. 그래서 수신받을 MsgSeqNum을 789=5103로 지정한 것이다.

<2. 로그인 응답 - 장애에 의한 재로그인>

[19:25:13][in|8=FIX.4.4^A9=72^A35=A^A49=BCOMPID^A56=ACOMPID^A34=5105^A52=20111222-10:25:13^A108=60^A98=0^A10=181^A|X|X]

MsgSeqNum(Tag.32) 5103이 수신되어야 하는데 상대기관에서 MsgSeqNum(Tag.34)를 5105를 보냈다. 5103~5105까지 미수신 메시지가 존재한다는 것을 알 수 있다.

<3. 재전송 요청>

[19:25:13][out|8=FIX.4.4^A9=76^A35=2^A49=ACOMPID^A56=BCOMPID^A34=5073^A52=20111222-10:25:13.552^A7=5103^A16=0^A10=111^A]

미수신 메시지를 받기 위해서 BeginSeqNo를 7=5103으로 하고 EndSeqNo를 16=0 으로 요청한다. 16=0은 현재의 Sequence 번호를 EndSeqNo로 사용하라는 의미이다. 16=5105로 보내도 되지만 통상 16=0으로 보내게 된다.

<4. 재전송 응답 - Gap Fill mode>

[19:25:13][in|8=FIX.4.4^A9=79^A35=4^A49=BCOMPID^A56=ACOMPID^A34=5103^A52=20111222-10:25:13^A43=Y^A123=Y^A36=5107^A10=048^A|X|O]

5103부터 재전송 요청이 들어온 상태이므로 상대 기관에서는 5103부터 전송을 시작한다. 하지만 상대기관 입장에서는 이 메시지를 이미 보낸 것으로 판단하면 PossDupFlag(Tag.43)을 Y로 설정해서 보내게 된다. 이는 중복이 될 가능성이 있다는 것을 미리 알려주기 위함이다. 리커버리를 위해 송신하는 메시지로 GapFillFlag(Tag.123)을 Y로 설정해서 보내게 된다. NewSeqNo(Tag.36)을 5107로 보냈다는 것은 5104부터 5106까지는 세션메시지라 스킵하고 5107부터 보내겠다는 의미이다.

[19:26:13][out|8=FIX.4.4^A9=64^A35=0^A49=ACOMPID^A56=BCOMPID^A34=5074^A52=20111222-10:26:13.794^A10=097^A]

세션이 정상화 되었고 Heartbeat를 송신한다.

[19:26:13][in|8=FIX.4.4^A9=60^A35=0^A49=BCOMPID^A56=ACOMPID^A34=5107^A52=20111222-10:26:13^A10=136^A|X|X]

SequenceReset을 통해 최종 데이터는 5107부터 수신되는 것을 확인할 수 있다.

FIX 글로벌 네트웍 구성

FIX & FEP — Mon, 9 Dec 2019 16:33:19 +0900

해외 브로커 또는 거래소와 FIX 세션을 연결하기 위해서는 먼저 물리적 회선을 구성해야 한다. 글로벌 회선사업자로는 BT Radianz와 TNS가 있고, Fix Hub 사업자는 블룸버그 및 톰슨오텍스 등이 있다. 글로벌 사업자까지의 연결은 SKT, LGU+, KT 등 로컬 회선사업자를 통해 연결한다. 특별히 주문이 않은 경우를 제외하고는 보통 주문회선 용량은 1M 또는 그 이하로 많이 사용한다.

1. 회선사업자 이용 - BT Radianz, TNS 등

물리적 회선이 구성되어 있으면 해당 회선사업자에게 출발지와 목적지 아이피를 보내서 회선사업자 회선 연결을 요청한다. 회선사업자는 각 IP는 자체 라우팅 경로에 등록하고, 각 IP들을 NAT IP로 변경한다. 회선사업자에 의해 제공된 NAT IP를 바탕으로 상호 방화벽을 허용해 줄 수 있도록 등록해준다. 필요시 라우팅 설정도 확인한다.

회선사업자에 의해 출발지 및 목적지 IP가 모두 NAT에 의해서 바뀌기 때문에 실제 목적지에 연결하기 위해서는 브로커의 물리적 서버IP가 아닌 회선사업자에 의해 NAT된 목적지IP가 필요하다.

(출발지 서버IP) -> (NAT된 출발지IP) -> (NAT된 목적지IP) -> (목적지 서버IP)

즉, 출발지에서는 NAT된 목적지IP로 갈 수 있도록 Outbound 방화벽을 허용한다. 목적지에서는 NAT된 출발지IP를 허용하기 위해 Inbound 방화벽을 설정한다.

보통 비용은 인바운드 역할(Sell Side)을 하는 브로커에서 비용을 지불하기 때문에 회선사업자가 해당 브로커에서 인보이스를 발송한다.

2. FIX Hub 사업자 이용 - 블룸버그, 톰슨오텍스(로이터) 등

Buy Side / Sell Side 모두 블룸버그/톰슨오텍스 Fix 허브 서버에 클라이언트로써 접속한다. 해당 허브사업자에서 제공해 주는 서버IP를 사용하면 된다. 블룸버그의 경우 TLS 암호화 통신을 사용하기 때문에 stunnel 등으로 가상화 터널 구성이 필요하다. stunnel 구성에 대한 정보는 다음에서 확인해 볼 수 있다.

https://studioexitt.github.io/os/os-stunnel/

How to manage stunnel process without super daemon in linux

start/stop shell script to run stunnelShell script for managing stunnel (stunnel.sh)

studioexitt.github.io