โมเดลการสื่อสาร¶

บทนำ ¶

FIX API ใช้การสื่อสารแบบเซสชัน เซสชันถูกกำหนดเป็นการสื่อสารระหว่างสองฝ่าย: ผู้เริ่มต้น (ไคลเอนต์) ฝ่ายที่เริ่มการสื่อสาร และผู้รับ (เซิร์ฟเวอร์) ฝ่ายที่รับคำขอการเชื่อมต่อจากผู้เริ่มต้น

เซิร์ฟเวอร์ตรวจสอบคำขอของไคลเอนต์โดยใช้ข้อความ Logon

โปรโตคอลเซสชัน FIX ¶

แต่ละเซสชันรักษาข้อความสองทิศทางระหว่างไคลเอนต์และเซิร์ฟเวอร์ cTrader เซสชันสามารถรวมการเชื่อมต่อทางกายภาพหลายรายการและถูกรักษาไว้โดยใช้หมายเลขลำดับ

ทุกข้อความใหม่ภายในเซสชันเดียวจะได้รับหมายเลขลำดับที่ไม่ซ้ำกันเริ่มจาก 1 (หนึ่ง) ทั้งสองฝ่ายอาศัยหมายเลขลำดับเพื่อรักษาการสื่อสารที่เป็นระเบียบ ข้อความที่หายไปจะถูกส่งใหม่ด้วยข้อตกลงสองฝ่ายระหว่างทั้งสองฝ่าย

ลำดับการทำงานของเซสชันทั่วไป:

1. ไคลเอนต์เริ่มเซสชันด้วยข้อความ Logon
2. ไคลเอนต์แลกเปลี่ยนข้อความแอปพลิเคชันกับเซิร์ฟเวอร์
3. เซสชันจบลงด้วยข้อความ Logout

หมวดหมู่ข้อความโปรโตคอล FIX ของ cTrader ¶

ตามที่กำหนดไว้ในโปรโตคอล FIX เซิร์ฟเวอร์ FIX ของ cTrader ใช้ข้อมูล 2 ระดับที่แตกต่างกัน: ระบบและแอปพลิเคชัน

โปรดทราบว่านี่เป็นชุดข้อความขั้นต่ำที่จำเป็นเพื่อรองรับขั้นตอนการทำงานที่จำเป็นและอาจมีการเปลี่ยนแปลงเมื่อเวลาผ่านไปตามความต้องการทางธุรกิจและมาตรฐาน FIX ที่พัฒนาขึ้น

ข้อความระบบ (ผู้ดูแลระบบ) ¶

• Heartbeat (ไคลเอนต์ ↔ cTrader) – ใช้เพื่อตรวจสอบการเชื่อมต่อระหว่างสองฝ่าย
• Test request (ไคลเอนต์ ↔ cTrader) – ใช้เพื่อทดสอบสุขภาพของการเชื่อมต่อ
• Logon (ไคลเอนต์ → cTrader) – ข้อความยืนยันตัวตนของไคลเอนต์
• Logon (ไคลเอนต์ → cTrader) – การยุติเซสชันตามปกติ
• Resend request (ไคลเอนต์ ↔ cTrader) – คำขอให้ส่งข้อความแอปพลิเคชันบางอย่างใหม่
• Reject (ไคลเอนต์ ↔ cTrader) – การตรวจสอบระดับเซสชันล้มเหลว
• Sequence reset (ไคลเอนต์ ↔ cTrader) – ในกรณีที่มีปัญหาการสื่อสาร ข้อความที่หายไปจะถูกกู้คืนหรือลำดับจะถูกรีเซ็ตเพื่อละเว้นข้อความที่หายไป

ข้อความแอปพลิเคชัน ¶

• Market data request (ไคลเอนต์ → cTrader) – คำขอทั่วไปสำหรับข้อมูลตลาด
• Market data incremental refresh (ไคลเอนต์ ← cTrader) – การตอบสนองต่อข้อความคำขอข้อมูลตลาด
• New order single (ไคลเอนต์ → cTrader) – ใช้เพื่อส่งคำสั่งทางอิเล็กทรอนิกส์ไปยังโบรกเกอร์เพื่อดำเนินการ
• Execution report (ไคลเอนต์ ← cTrader) – ใช้เพื่อส่งข้อมูลสถานะคำสั่งไปยังไคลเอนต์ FIX เช่น การยืนยัน การเติมเต็ม และการเปลี่ยนแปลงที่ไม่ได้ร้องขอ
• Business message reject (ไคลเอนต์ ← cTrader) – ใช้เพื่อปฏิเสธคำขอของไคลเอนต์ FIX ด้วยเหตุผลที่ไม่เกี่ยวกับเซสชัน

โครงสร้างข้อความ FIX ¶

ส่วนนี้อธิบายวิธีการประกอบข้อความ FIX API อธิบายรูปแบบข้อความ FIX และช่วยให้ผู้ใช้เข้าใจแนวคิดของคู่แท็กและค่า

แต่ละข้อความต้องประกอบด้วย 3 ส่วน:

• ส่วนหัว – ข้อความการจัดการหรือแอปพลิเคชันแต่ละรายการจะมีส่วนหัวมาตรฐานนำหน้า ส่วนหัวระบุประเภทข้อความ เวอร์ชัน FIX ความยาวข้อความ ปลายทาง หมายเลขลำดับ ต้นทาง และเวลา
• เนื้อหา – เนื้อหาในส่วนเนื้อหาของข้อความถูกกำหนดโดยประเภทข้อความที่ระบุในส่วนหัว
• ส่วนท้าย – ข้อความแต่ละรายการ ทั้งการจัดการหรือแอปพลิเคชัน จะจบลงด้วยส่วนท้ายมาตรฐาน ส่วนท้ายใช้เพื่อแยกข้อความและประกอบด้วยตัวแทนอักขระสามหลักของค่า CheckSum <10>

รูปแบบข้อความ FIX ¶

ข้อความ FIX คือการรวมกันของฟิลด์ แต่ละฟิลด์เป็นคู่แท็ก-ค่าที่มีรูปแบบเป็น {tag}={value} ตัวอย่างเช่น 54=2 ซึ่งหมายความว่าประเภทคำสั่งคือขาย

แท็ก ¶

• FIX ใช้แท็กที่กำหนดไว้ล่วงหน้า
• แต่ละแท็กแทนฟิลด์เฉพาะ
• แต่ละแท็กได้รับหมายเลขที่กำหนดไว้ล่วงหน้า
• ข้อกำหนด FIX ของ cTrader ให้รายการฟิลด์และหมายเลขแท็กที่เกี่ยวข้อง

ค่า ¶

• ค่าแทนค่าของแท็กที่กำหนดให้กับมัน
• ค่าสามารถเป็นได้เพียงหนึ่งในประเภทข้อมูลต่อไปนี้เท่านั้น: จำนวนเต็ม ทศนิยม อักขระ เวลา วันที่ ข้อมูล หรือสตริง

ข้อความทั้งหมดภายใน cTrader FIX API จะเริ่มต้นด้วย 8=FIX.x.y โดย x.y คือเวอร์ชันของโปรโตคอล FIX ท้ายทุกข้อความควรมีฟิลด์ 10=xyz โดย xyz แทนผลรวมของค่าไบนารีทั้งหมดในข้อความที่เรียกว่า checksum

Checksum ช่วยในการระบุปัญหาการส่งข้อมูลใดๆ โดยเฉพาะการสูญหายของแพ็คเก็ตโดยอนุญาตให้ผู้รับทราบว่ามีส่วนใดของข้อความหายไปหรือไม่

หากแท็ก Symbol(55) ถูกใช้ในข้อความ FIX ไปยัง cTrader/cServer คุณต้องระบุ FIX symbol ค่านั้นอาจแตกต่างกันไปในแต่ละโบรกเกอร์ คุณสามารถหาฟิลด์ ID สัญลักษณ์ FIX ได้จากแอปพลิเคชัน cTrader ของโบรกเกอร์นั้นในหน้าต่างข้อมูลสัญลักษณ์

ตัวอย่างข้อความ ¶

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|