Model komunikasi¶
Pengantar ¶
FIX API menggunakan komunikasi berbasis sesi. Sesi didefinisikan sebagai komunikasi antara dua pihak: inisiator (klien), pihak yang memulai komunikasi, dan akseptor (server), pihak yang menerima permintaan koneksi dari inisiator.
Server memvalidasi permintaan klien menggunakan pesan Logon.
Protokol sesi FIX ¶
Setiap sesi mempertahankan pesan dua arah antara klien dan server cTrader. Sesi dapat mencakup beberapa koneksi fisik dan dipertahankan menggunakan nomor urut.
Setiap pesan baru dalam satu sesi menerima nomor urut unik dimulai dari 1 (satu). Kedua pihak bergantung pada nomor urut untuk mempertahankan komunikasi yang teratur. Pesan yang hilang dikirim ulang dengan kesepakatan bilateral antara kedua pihak.
Alur sesi tipikal:
- Klien memulai sesi dengan pesan Logon.
- Klien bertukar pesan aplikasi dengan server.
- Sesi berakhir dengan pesan Logout.
Kategori pesan protokol FIX cTrader ¶
Sebagaimana didefinisikan dalam Protokol FIX, server FIX cTrader menggunakan 2 level data yang berbeda: sistem dan aplikasi.
Harap dicatat bahwa ini adalah set minimum pesan yang diperlukan untuk mendukung alur kerja yang diperlukan dan dapat berubah seiring waktu seiring dengan perkembangan kebutuhan bisnis dan standar FIX.
Pesan sistem (admin) ¶
- Heartbeat (klien ↔ cTrader) – digunakan untuk memeriksa tautan komunikasi antara dua pihak.
- Test request (klien ↔ cTrader) – digunakan untuk menguji kesehatan tautan komunikasi.
- Logon (klien → cTrader) – pesan autentikasi klien.
- Logon (klien → cTrader) – penghentian normal sesi.
- Resend request (klien ↔ cTrader) – permintaan untuk mengirim ulang pesan aplikasi tertentu.
- Reject (klien ↔ cTrader) – kegagalan validasi tingkat sesi.
- Sequence reset (klien ↔ cTrader) – dalam kasus masalah komunikasi, pesan yang hilang dipulihkan atau urutan diatur ulang untuk mengabaikan pesan yang hilang.
Pesan aplikasi ¶
- Market data request (klien → cTrader) – permintaan umum untuk data pasar.
- Market data incremental refresh (klien ← cTrader) – respons terhadap pesan permintaan data pasar.
- New order single (klien → cTrader) – digunakan untuk mengirimkan order secara elektronik ke broker untuk dieksekusi.
- Execution report (klien ← cTrader) – digunakan untuk mengirim informasi status order ke klien FIX, seperti konfirmasi, pengisian, dan perubahan yang tidak diminta.
- Business message reject (klien ← cTrader) – digunakan untuk menolak permintaan klien FIX karena alasan non-sesi.
Struktur pesan FIX ¶
Bagian ini menjelaskan bagaimana pesan FIX API disusun, menjelaskan format pesan FIX, dan membantu pengguna memahami konsep pasangan tag dan nilai.
Setiap pesan harus berisi 3 bagian:
- Header – setiap pesan administratif atau aplikasi didahului oleh header standar. Header mengidentifikasi jenis pesan, versi FIX, panjang pesan, tujuan, nomor urut, asal, dan waktu.
- Body – konten dalam body pesan ditentukan oleh jenis pesan yang didefinisikan dalam header.
- Footer – setiap pesan, administratif atau aplikasi diakhiri dengan footer standar. Footer digunakan untuk memisahkan pesan dan berisi representasi karakter tiga digit dari nilai
CheckSum <10>.
Format pesan FIX ¶
Pesan FIX adalah kumpulan field. Setiap field adalah pasangan tag-nilai yang diformat sebagai {tag}={value}. Misalnya, 54=2, yang berarti jenis order adalah jual.
Tag ¶
- FIX menggunakan tag yang telah ditentukan sebelumnya.
- Setiap tag mewakili field tertentu.
- Setiap tag diberikan nomor yang telah ditentukan sebelumnya.
- Spesifikasi FIX cTrader menyediakan daftar field dan nomor tag yang sesuai.
Nilai ¶
- Nilai mewakili nilai dari tag yang ditetapkan padanya.
- Nilai hanya dapat berupa salah satu dari tipe data berikut: integer, floating point, karakter, waktu, tanggal, data, atau string.
Semua pesan dalam cTrader FIX API dimulai dengan 8=FIX.x.y, di mana x.y adalah versi Protokol FIX. Di akhir setiap pesan harus ada field 10=xyz, di mana xyz mewakili jumlah semua nilai biner dalam pesan yang disebut checksum.
Checksum membantu mengidentifikasi masalah transmisi, khususnya kehilangan paket dengan memungkinkan penerima mengetahui jika ada bagian pesan yang hilang.
Jika tag Symbol(55) digunakan dalam pesan FIX ke cTrader/cServer, Anda harus menentukan ID simbol FIX. Nilai tersebut dapat berbeda antar broker. Anda dapat menemukan field ID Simbol FIX dari aplikasi cTrader broker tersebut di jendela informasi simbol.
Contoh pesan ¶
8=FIX.4.4|9=126|35=A|34=1|49=theBroker.12345|57=TRADE|50=any_string|52=20170117-08:03:04|56=CSERVER|98=0|108=30|553=12345|554=passw0rd!|10=131|
| Tag # | Nama Tag | Nilai | Deskripsi |
|---|---|---|---|
| 8 | BeginString | 4.4 | Versi FIX |
| 9 | BodyLength | 102 | Panjang badan pesan adalah 102 karakter |
| 35 | MsgType | A | Jenis pesan adalah Logon |
| 34 | MsgSeqNum | 1 | Nomor urut pesan adalah 1 |
| 49 | SenderCompI | D | broker.1047 ID pihak trading, di mana "broker" adalah BrokerUID unik yang disediakan oleh cTrader dan "1047" adalah pengidentifikasi numerik dari akun trading. |
| 57 | TargetSubID | TRADE | Kualifikasi sesi tambahan. Nilai yang mungkin adalah: "QUOTE","TRADE". |
| 50 | SenderSubID | QUOTE | Nilai yang ditetapkan digunakan untuk mengidentifikasi pengirim pesan tertentu |
| 52 | SendingTime | 20131129- 15:40:10.276 | Waktu transmisi pesan adalah 29 November 2013 (YYYYMMDD) pada pukul 15:40:10 dan 276 milidetik |
| 56 | TargetCompID | CSERVER | Target pesan adalah CSERVER. Ini adalah satu-satunya nilai yang valid dalam cTrader FIX API. |
| 98 | EncryptMethod | 0 | Saat ini, satu-satunya nilai yang valid adalah "0" (nol)= NONE_OTHER (enkripsi tidak digunakan) |
| 108 | HeartBtInt | 30 | Interval detak jantung dalam detik. Nilai diatur dalam file "config.properties" (sisi klien) sebagai SERVER.POLLING.INTERVAL'. 30 detik adalah nilai interval default. Jika HeartBtInt diatur ke 0, tidak diperlukan pesan detak jantung. |
| 553 | Username | 1047 | ID pengguna numerik |
| 554 | Password | MyPassword1 | Kata sandi pengguna |
| 10 | CheckSum | 000 | Cara menghitung checksum adalah sebagai berikut: menjumlahkan setiap byte pesan hingga tetapi tidak termasuk bidang checksum itu sendiri, kemudian mengubahnya menjadi angka modulo 256 yang diawali dengan "0" untuk mendapatkan angka tiga digit. |