Đặc tả kỹ thuật của hệ thống giao dịch sàn chứng khoán TP hồ chí minh

Giao thức ứng dụng được thiết kế theo tiêu chí sau: - Có khả năng quản lý tốc độ chuyển tải dữ liệu giữa 2 điểm Flow control - Đảm bảo độ tin cậy ngay cả khi xuất hiện sự cố - Đáp ứng cá

Trang 1

Phụ lục 02: Đặc tả kỹ thuật Hệ thống giao dịch của SGDCK TPHCM

Ban hành kèm theo Quy định giao dịch trực tuyến của Sở Giao dịch Chứng khoán TP HCM

ngày 24 tháng 11 năm 2008

ĐẶC TẢ KỸ THUẬT

HỆ THỐNG GIAO DỊCH CỦA

SGDCK TPHCM

Trang 2

Mục Lục

I/ Thuật ngữ 5

II/ Giao thức Auto-T 6

1 Định nghĩa: 6

2 Nguyên tắc họat động 6

3 Giao thức Auto-T 7

a Truyền dữ liệu: 12

b Ngắt kết nối: 13

c Yêu cầu về khả năng xử lý của ứng dụng: 14

4 Bảng mô tả mã code 15

Phụ lục Các biểu đồ 16

III/ Giao thức Broadcast 18

1 Phương thức truyền thông điệp: 18

a Khái niệm Sequence Numbers 18

b Khái niệm Timestamp 18

c Định dạng của gói dữ liệu được truyền theo dạng broadcast 18

d Định dạng của content 18

2 Truyền lại các thông điệp bên đường UDP : 19

a Truyền tự động: 19

b Truyền thủ công : 20

IV/ Mô tả các message: 21

1 Message CTCI: 21

Message 1C: Thông tin hủy lệnh 21

Message 1D: Thông tin thay đổi lệnh 22

Message 1E: Thông tin quảng cáo GDTT 23

Message 1F: Thông tin lệnh GDTT của khách hàng cùng công ty 24

Message 1G: Thông tin lệnh GDTT của khách hàng khác công ty 25

Message 1I: Thông tin lệnh đặt 26

Message 2B: Xác nhận lệnh đặt 27

Message 2C: Xác nhận hủy lệnh 28

Message 2D: Xác nhận thay đổi lệnh 29

Message 2E: Xác nhận khớp lệnh của khách hàng khác công ty 30

Message 2F: Thông tin lệnh GDTT cho bên mua 31

Message 2G: Thông tin từ chối từ HOSE 32

Message 2I: Xác nhận khớp lệnh của khách hàng cùng công ty 33

Message 2L: Xác nhận khớp GDTT 34

Message 3A - Admin 35

Message 3B: Thông tin trả lời lệnh GDTT của bên mua hoặc HOSE 36

Message 3C: Thông tin yêu cầu hủy lệnh 37

Message 3D: Thông tin trả lời yêu cầu hủy lệnh của bên mua hoặc HOSE 38

Message RN - Retransmission Nack 39

Message RP - Retransmission Reply 40

Message RQ - Retransmission Request 41

2 Message PRS: 42

Message AA – Thông báo về giao dịch thỏa thuận 42

Message BR – Thông tin xác nhận kết quả giao dịch của một công ty chứng khoán 43

Trang 3

Message OL – lệnh đặt lô lẻ 53

Message OS – Thông tin xác định giá mở cửa 54

Message PD – Thông báo về khớp lệnh của giao dịch thỏa thuận 55

Message PO – Thông báo giá mở cửa dự kiến 56

Message SC – thông điệp điều khiển hệ thống 57

Message SI 58

Message SR – Tổng kết thông tin từng mã chứng khoán 59

Message SS – Thông báo thay đổi trạng thái của một mã chứng khoán 60

Message SU – Cập nhật mã chứng khoán 61

Message TC – Thay đổi trạng thái của trader 63

Message TP – 3 giá trị tốt nhất 64

Message TR – room của đầu tư nước ngoài 65

Message TS 66

3 Ý nghĩa của các trường trong các message: 67

Accumulate Value 67

Accumulate Volume 67

Add/Cancel Flag 67

Advances 67

Automatch Halt Flag 68

Benefit 68

Board 68

Board Lot 68

Broker Client Volume, Broker Foreign Volume, Broker Portfolio Volume 69

Cancel Confirm 69

Cancel Shares 69

Ceiling Price 69

Client ID 69

Client ID Required 70

Confirm Number 70

Contact 70

Contra Firm 71

Current Room 71

Deal ID 71

Declines 71

Delist 71

Down Volume 72

Error code 72

Filler 72

Firm 73

Floor Price 73

Halt / Resume Flag 73

Highest Price 73

Index – HOSE 74

Index Time 74

Last Sale Price 74

Lot Volume 74

Lot Volume 1,2,3 74

Lowest Price 75

Market ID 75

Message Type 75

Meeting 75

Mutual Fund Volume 75

No Change 75

No Change Volume 76

Notice 76

Open Price 76

Trang 4

Order Entry Date 77

Order Number 77

Original Message Text 77

Par Value 77

Port/Client Flag 77

Price 78

Price 1,2,3 78

Prior Close Date 78

Prior Close Price 78

Projected Open Price 79

Published Volume 79

Putthrough Halt Flag 79

Reject Reason Code: 79

Reply Code 81

SDC Flag 81

Sector Number 81

Security Name 81

Security Number, Security Number (New) 82

Security Symbol 82

Security Type 82

Side 82

Split 83

Suspension 83

System Control Code 83

Time 84

Timestamp 84

Total Room 84

Total Shares Traded 84

Total Trades 84

Total Values Traded 85

Trader ID 85

Trader Status 85

Up Volume 85

Volume 86

Số lượng cổ phiếu hay chứng chỉ quỹ, trái phiếu được giao dịch trong giờ giao dịch 86

4 Lưu đồ các message: 87

Lưu đồ của message điều khiển (SC) 87

Lưu đồ của các message từ pre-open sang open 87

Lưu đồ của các message với các lệnh đặt ATO/ATC 88

Lưu đồ xử lý lệnh đặt 88

Lưu đồ xử lý lệnh thị trường (MP) 89

Lưu đồ message thay đổi lệnh 89

Lưu đồ message yêu cầu huỷ lệnh 90

Lưu đồ khớp giao dịch thoả thuận cùng công ty 90

Lưu đồ huỷ một giao dịch thoả thuận cùng công ty 90

Lưu đồ khớp giao dịch thoả thuận khác công ty 90

Lưu đồ hủy lệnh thoả thuận (chỉ dành cho trường hợp khác công ty) 91

Trang 5

I/ Thuật ngữ

1 HOSE: Sở giao dịch chứng khoán Tp.HCM

2 Front-End: Hệ thống đầu cuối, là hệ thống trung gian giữa hệ thống giao dịch của Sở và CTCK

3 Back-End: Hệ thống sau cuối, chính là hệ thống giao dịch của Sở

4 Message: Thông điệp

5 Flow control: Là tiến trình của việc quản lý tốc độ chuyển tải dữ liệu giữa 2 điểm

6 TCP(Transmission control protocol): Là một giao thức giao vận Đây là một trong những giao thức cốt lõi của bộ giao thức internet

7 UDP(User datagram protocol): là 1 giao thức giao vận Đây là một trong những giao thức cốt lõi của bộ giao thức internet

8 Sliding window: Là một kỹ thuật cho phép bên gửi có thể gửi nhiều gói tin mà không cần thiết phải nhận ACK (phản hồi ) từ bên nhận, miễn là số gói tin không được vượt quá một giá trị nhất định, gọi là window size

9 full-duplex: Trao đổi dữ liệu 2 chiều

10 buffer window: bộ đệm chứa các gói tin nhận được từ mạng hay các gói tin chuẩn bị được gửi đi, đây là một thành phần trong kỹ thuật sliding window

11 Server: là hệ thống phần mềm phục vụ cho giao dịch trực tuyến, đặt tại HOSE

12 Client: là hệ thống phần mềm đặt tại các công ty chứng khoán thành viên, nhằm phục vụ cho giao dịch trực tuyến Phần mềm này do các CTCK tự phát triển hoặc mua từ các nhà cung cấp giải pháp phần mềm

13 Sequence number: số thứ tự kế tiếp của gói dữ liệu truyền

14 Acknowledge sequence number: số sequence xác nhận giá trị mong muốn nhận trong lần kế tiếp

15 ClientAck: viết tắt của client acknowledge sequence number, có nghĩa là số Acknowledge sequence phía client

16 ServerSeq: viết tắt của server sequence number, là số sequence phía server

17 Window size: kích thước của kỹ thuật sliding window, là số gói dữ liệu tối đa một bên có thể gửi liên tiếp mà không cần phải chờ phản hồi từ bên nhận Khuyến cáo cho ứng dụng đang phát triển là 7

18 Broker: Công ty Chứng khoán thành viên ( dùng trong mô tả các message)

19 Trader: Người môi giới

20 Packet sequence: Thứ tự của gói dữ liệu

Trang 6

Sở có thể nhập lệnh từ hệ thống máy tính của CTCK thành viên đến máy chủ giao dịch của Sở

22 PRS (Price report system) : Hệ thống báo giá

23 Alphabet : Ký tự chữ cái

24 Numeric String: Chuỗi chỉ bao gồm các ký tự số

25 Alphanumeric String: Chuỗi bao gồm các ký tự chữ cái và số

II/ Giao thức Auto-T

Định nghĩa:

Giao thức Auto-T là giao thức 2 lớp ở tầng ứng dụng, được sử dụng trong việc chuyển tải các giao dịch giữa Hệ thống giao dịch của HOSE và Hệ thống giao dịch của CTCK thành viên Các message được sử dụng để giao tiếp giữa 2 hệ thống

Nguyên tắc họat động

Hệ thống giao dịch tại HOSE về logic có thể chia thành 2 thành phần: Front-End và Back-End Hệ thống Back-End chính là Hệ thống giao dịch của HOSE Các giao dịch được chuyển tải theo dạng Message giữa Hệ thống Back-End tại HOSE và Hệ thống giao dịch của CTCK thành viên Hệ thống Front-End sẽ đảm nhận tác vụ này nhằm xử lý các Message theo đúng tiêu chuẩn của giao thức giao vận tầng dưới

Giao thức ứng dụng được thiết kế theo tiêu chí sau:

- Có khả năng quản lý tốc độ chuyển tải dữ liệu giữa 2 điểm (Flow control)

- Đảm bảo độ tin cậy ngay cả khi xuất hiện sự cố

- Đáp ứng các chức năng của hệ thống Front-End Trạng thái của một message được xác định bởi packet sequence Thông thường, Packet sequence không nhất thiết phải duy nhất cho cả session nhưng đối với giao thức Auto-T, packet sequence bắt buộc phải duy nhất để dùng cho mục đích tham chiếu khác Xem xét trạng thái của một ứng dụng, sẽ có 3 chế độ kết nối:

- Mode A(New connection): tất cả các trạng thái đều ở tình trạng ban đầu

- Mode C(Continued connection): Ứng dụng sẽ sử dụng trạng thái trước đó để phục hồi dữ liệu nếu cần thiết

- Mode B(Blindly continued connection): Khi ứng dụng mất trạng thái nhưng cố gắng phục hồi dữ liệu chỉ với một phần thông tin trạng thái còn lưu lại được Ví

Trang 7

được lưu trên đĩa cứng chia sẻ Tuy nhiên, đĩa cứng chia sẻ có thể không khả thi nếu như

2 máy chủ được đặt tại các vùng địa lý khác nhau

Cả hai bên (CTCK và SGDCK TPHCM) phải thống nhất về mode kết nối khi giai đoạn thiết lập hoàn tất, nếu không kết nối không thể tiếp tục Ví dụ: sẽ không khả thi nếu Server mong muốn kết nối ở mode A trong khi Client lại muốn tạo kết nối ở mode C Trong Auto-T, Sở đóng vai trò như là Server và CTCK có vai trò là Client Mối quan hệ

là 1-1 Tóm lại, giao thức ứng dụng sẽ bao gồm 3 giai đoạn chính:

- Thiết lập kết nối: trong giai đoạn này, Client sẽ yêu cầu kết nối tới Server Trước

khi Server chấp nhận kết nối, nó sẽ thẩm định yêu cầu của client và thực hiện phục hồi dữ liệu cho client nếu cần thiết Dựa trên sự chấp thuận kết nối từ Server, Client phải kiểm tra dữ liệu phục hồi từ phía Server nếu được yêu cầu và sau đó phải gửi một xác nhận về cho Server để kết thúc quá trình thiết lập kết nối

- Truyền dữ liệu: Một khi kết nối được thiết lập một cách hợp lệ, cả server và

client có thể gửi các gói dữ liệu cho nhau Giai đoạn này là full-duplex, nhưng hoat động theo sliding window, flow control Flow control sẽ giới hạn số gói dữ liệu mà mỗi bên có thể gửi cho nhau mà không cần nhận bất cứ phản hồi nào Trong giai đọan này cũng sẽ có các yêu cầu phản hồi của giao thức phụ

- Ngắt kết nối: Khi cả 2 bên chuẩn bị ngưng kết nối, client nên tuân theo giao thức

ứng dụng trước khi đóng kết nối

Ngoài những vấn đề về độ tin cậy đã nêu trên, flow control phải có khả năng quản lý như:

- Số gói tin có thể mất trong quá trình bị sự cố sẽ không được quá kích thước của buffer window Thời điểm phục hồi có thể được điều khiển ở mức ứng dụng

- Nếu bên nhận không thể nhận bất kỳ gói tin nào vì bất kỳ lý do gì thì giai đoạn truyền dữ liệu nên ngừng nếu không bên nhận có thể bị quá tải dẫn đến sụp đổ hệ thống

Giao thức Auto-T Định dạng Auto-T Message:

2 bytes 4 bytes 4 bytes 2 bytes 2 bytes N bytes 1 byte

Bảng 1 : Định dạng Auto-T message

Trang 8

Mô tả chi tiết:

( mod96+32)

Độ dài của cả gói tin không bao gồm trường này

sequence 4 bytes ASCII (mod96+32) Seq kế tiếp của bên

gửi

ack sequence 4 bytes ASCII (mod96+32) Seq mong muốn kế

tiếp của bên gửi

ứng dụng có khả năng xử lý tương ứng, đồng thời định

rõ được định dạng

và ý nghĩa của những trường còn lại

Link-ID 2 bytes ASCII (mod96+32) Id của đường kết

nối giúp server xác định được dữ liệu đến từ client nào

thuộc vào loại gói tin được chỉ ra trong Opcode

(ASCII code 03)

Bảng 2 : Mô tả chi tiết các trường

Trang 9

Định dạng phần nội dung của gói tin, phụ thuộc vào opcode:

Nội dung Opcode hay là kiểu gói

tin (2 chars)

A = new connection

B = blindly continued connection

market-ID 1 byte (alphabet)

message-count 1 byte (mod96+32)

message, mỗi message sẽ được ngăn cách bởi ký tự US)

LO(LEFTOVER) LL(LEFTOVER_LAST) Của RP

RP Packet “RP” = 2 bytes

Link id = 2 bytes Market-ID = 1 byte Broadcast message = N bytes

broadcast request message N bytes

Trang 10

broadcast message N bytes

EOS (ASCII code 00 ) 1 byte

¾ Server sẽ kiểm tra để biết client có cần khôi phục dữ liệu nào không

 Nếu CliAck +WindowSize >= ServSeq > CliAck: client bị mất một số

message và cần được truyền lại các message bị mất

 Nếu ServSeq == CliAck : Client đã nhận đủ các message

 Nếu ServSeq > CliAck+WindowSize: gần như không thể xảy ra Nếu

có giao thức nên ngừng để phối hợp xử lý

 Nếu ServSeq < CliAck: có thể là do server bị sự cố hoặc server và

client kết nối ở 2 mode khác nhau Nếu là trường hợp thứ hai, chỉ cần tắt client và khởi động lại ở mode giống với server

¾ Sau khi đã kiểm tra và quá trình khôi phục dữ liệu (nếu có) hoàn tất, server

sẽ gửi message HELLO_REPLY, client cũng phải thực hiện các bước kiểm tra tương tự server

 Nếu ServAck+WindowSize >= CliSeq > ServAck: server bị mất

Trang 11

kết nối ở 2 mode khác nhau Nếu là trường hợp thứ hai, chỉ cần tắt client và khởi động lại ở mode giống với server

¾ Sau khi đã kiểm tra và quá trình khôi phục dữ liệu (nếu có) hoàn tất, client gửi message CONFIRM để hoàn tất giai đoạn 1 giai đoạn kết nối Bảng dưới thể hiện tất cả các khả năng kết nối và thao tác cần thực hiện tương ứng

Exchange Broker Action(s)

phục hồi dữ liệu

<< HELLO (1,1) HELLO_REPLY (1,1) >>

<< CONFIRM(1,1)

A B Sai mode kết nối << HELLO

(any,any) NACK (any,any)>>

A C Sai mode kết nối << HELLO

B A Sai mode kết nối << HELLO

<<

HELLO(seq1,ackSeq1) HELLO_REPLY (seq1,ackSeq1) >>

<<CONFIRM(seq1,ackSeq1)

C A Sai mode kết nối << HELLO

C B Không cần quá trình

<< HELLO(1,1) HELLO_REPLY (seq1,ackSeq1) >>

<<CONFIRM(ackSeq1,seq1)

Trang 12

C C Có thể có quá trình phục

hồi dữ liệu

<< HELLO(any,any) LEFTOVER/LEFTOVER_LAST

>>

HELLO_REPLY(any,any)>>

<<LEFTOVER/LEFTOVER_LAST <<CONFIRM(any,any)

* Ghi chú: Trong gói HELLO, client có thể gửi danh sách các thị trường muốn giao dịch Tuy nhiên, HOSE chỉ có 1 thị trường duy nhất

a Truyền dữ liệu:

• Quá trình này bao gồm cả truyền message và dịch vụ phản hồi yêu cầu:

♦ Giao thức truyền message sẽ phải dựa vào cơ chế sliding window để truyền

♦ Dịch vụ phản hồi yêu cầu thì có thể lấy ví dụ trong trường hợp server gửi ACK, NACK khi nhận được message từ client

♦ Ngoài ra, client còn có thể có các giao thức phụ khác như gửi yêu cầu đến server, yêu cầu truyền lại thông tin bên broadcast hoặc là gửi ECHO message khi không có dữ liệu cần truyền Bất cứ thông điệp nào gửi đến server có lỗi, server sẽ gửi NACK về để thông báo

• Kỹ thuật sliding window: chỉ dùng để điều khiển dòng dữ liệu truyền giữa server

và client Nó không có nhiệm vụ sắp xếp thứ tự các gói tin, phát hiện việc mất hay trùng lắp gói tin Đó là việc của giao thức truyền dữ liệu Kỹ thuật này cho phép mỗi bên có thể gửi nhiều gói tin mà không cần thiết phải nhận ACK từ phía nhận, miễn là số gói tin nằm trong khoảng window size Mỗi gói dữ liệu được gửi kèm theo số ack sequence, chứng nhận với bên nhận rằng bên gửi đã nhận được dữ liệu đến giá trị sequence = ack sequence -1 Có nghĩa là khi gửi thông điệp DATA, bên gửi đã bao gồm thông tin ACK trong đó Và điều kiện sau phải luôn được thỏa mãn:

theirAckSeq < ourNextSeq <= theirAckSeq+WindowSize

• Yêu cầu truyền lại dữ liệu broadcast: client nếu muốn có thể yêu cầu server truyền lại dữ liệu bên broadcast Server sẽ gửi lại ACK nếu yêu cầu hợp lệ, ngược lại, gửi

Trang 13

retran request message

RETRAN_REQ Mkt

ID

ACK/CTCI-RN RETRAN_REQ

retran broadcast message

RETRAN_REPLY Mkt

ID

When a broker wants to request broadcast message retransmission.

When an exchange wants to send broadcast retransmission data.

Hình 1 : Quy trình yêu cầu gửi lại dữ liệu

• Lệnh ECHO: bên nào cũng có thể gửi ECHO message để kiểm tra tính sẵn sàng của bên nhận Khi đó, bên nhận phải gửi ECHO REPLY để xác nhận tính sẵn sàng

b Ngắt kết nối:

Giao thức truyền:

Bất kỳ bên nào cũng đều có quyền gửi FN để báo hiệu ý muốn ngắt kết nối

* Đối với bên gửi yêu cầu ngắt kết nối (gửi FN):

- Khi bên gửi nhận được ACKFIN trả lời, nó kiểm tra điều kiện theirAckSeq < ourNextSeq <= (theirAckSeq+window_size) Nếu không thoả sẽ gửi NACK và khi

đó quá trình ngắt kết nối không được hoàn tất Và quá trình khôi phục dữ liệu sẽ phải thực hiện trong lần thiết lập kết nối sau đó

- Bên nhận FN có thể gửi DT nếu vẫn muốn tiếp tục Bên gửi FN sau khi nhận DT, nếu muốn ngắt kết nối, phải gửi FN lại Cũng có thể cả hai bên đều gửi FN cùng lúc

để báo hiệu việc muốn ngắt kết nối

Vì ACKFIN cũng bao gồm cả DATA ACK, nên input và output window phải được cập nhật Sau đó, nó cũng gửi ngược lại ACKFIN để kết thúc quá trình ngắt kết nối

* Đối với bên nhận được yêu cầu ngắt kết nối (nhận FN):

- Khi nhận được FN, nó sẽ kiểm tra điều kiện theirAckSeq < ourNextSeq <= (theirAckSeq+window_size) Nếu không thoả sẽ gửi NACK về Khi đó quá trình ngắt

kết nối xem như chưa hoàn tất

Vì FN cũng bao gồm cả DATA ACK, nên bên nhận FN sẽ cập nhật giá trị output window Sau đó, khi gửi ACKFIN, nó sẽ cập nhât input window và chờ đến khi nhận

Trang 14

Lược đồ mô tả các trạng thái của giao thức AutoT:

rcv: HELLO

snd: NACK snd: LEFTOVER rcv: ACK

snd: HELLO_REPLY snd: LEFTOVER_LAST

snd: LEFTOVER rcv: ACK snd: HELLO_REPLY

rcv: LEFTOVER snd: ACK

rcv: LEFTOVER rcv: LEFTOVER_LAST

snd: ACK rcv: CONFIRM

rcv: CONFIRM

rcv:

FINISH snd: FINISH

snd: ACKFIN

rcv: ACKFIN

rcv/snd: DATA, ACK, NACK

snd: NACK

rcv: NACK

START STOP

STOP STOP STOP STOP

Protocol State Diagram

rcv: FINISH

rcv: DATA, ACK

4 5

6

9 10

data transfer

server command

client command

snd: ACK, NACK, ECHO_REPLY

snd: COMAND ECHO

rcv: COMMAND, ECHO

rcv: ACK, NACK, ECHO_REPLY

rcv: FINISH snd: FINISH

Trang 15

♦ Nó nhận được một gói tin không hợp lệ, ví dụ : sai định dạng Nhưng cũng có thể cho ứng dụng bỏ qua gói tin đó để nhận gói tin tiếp theo

♦ Sau một khoảng thời gian xác định, nó không nhận được bất kỳ tín hiệu nào từ phía đối ứng Khoảng thời gian này là tuỳ ý, nhưng không được nhỏ hơn một vòng truyền dữ liệu của gói tin HOSE khuyến cáo thời

gian tối thiểu là 15 giây

♦ Khi giao thức truyền nhận bị đứt vì một lý do nào đó, ví dụ : bị mất trạng thái

♦ Khi gói tin gửi đến có số sequence không liền kề với gói tin trước

• Kích thước của input window và output window phải giống nhau Kích thước này ảnh hưởng nhiều đến khả năng xử lý, độ trễ và thời gian khôi phục dữ liệu của ứng dụng HOSE khuyến cáo window side 17 là 7

• Có thể chọn cho mỗi gói DATA chứa một hay nhiều message, nhưng phải

có sự thống nhất giữa HoSE và CTCK

• Để việc truyền dữ liệu trên mạng được đảm bảo an toàn, không bị mất mát

dữ liệu, gói AutoT nên có kích thước lớn nhất là 536 bytes (đã bao gồm

TCP packet header và AutoT packet header)

'A' "HOSE"

Trang 16

Mode kết nối Mô tả

Bảng 4 : Bảng mô tả mã code

Phụ lục Các biểu đồ

HELLO LEFTOVER

CONFIRM DATA/ACK/NACK

Server (Exchange)

Client (Broker)

Connection Setup Hình 4 : Quá trình thiết lập kết nối

DATA DATA( Piggybacked Ack)

(Explicit) ACK NACK FINISH

ororor

If Input Window

is full

If an exchange has any data to send

If a received data

is invalid

If an exchange wants to terminate the session

Trang 17

FINISH ACKFIN

NACK Transport Disconnect

ACKFIN

Server or Client

Trang 18

III/ Giao thức Broadcast

Giới thiệu: giao thức này dùng để truyền các thông tin chung về thị trường đến tất

cả các thành viên tham gia giao dịch

1 Phương thức truyền thông điệp:

- Các message broadcast được truyền dưới hình thức các gói broadcast Một gói broadcast có thể chứa một hay nhiều message broadcast và gói này được truyền bằng giao thức UDP

a Khái niệm Sequence Numbers

- Một gói broadcast được xác định bằng một số sequence kèm theo HOSE gửi các gói broadcast này kèm theo chuỗi các số sequence tương ứng, bắt đầu

từ 1 Bên nhận sẽ dựa vào số sequence này để phát hiện message bị trùng lặp hay bị mất và dựa vào đó để gửi yêu cầu truyền lại broadcast đến HOSE

- Trường hợp HOSE phải thiết lập lại số sequence (trở lại bằng 1), bên nhận cũng phải có chức năng hỗ trợ để thiết lập lại số sequence tương ứng Trong trường hợp không thể phục hồi được các gói dữ liệu bị mất, chương trình nhận phải có khả năng bỏ qua các gói mất này, để tiếp tục nhận các gói tiếp theo của phiên giao dịch hiện tại

b Khái niệm Timestamp

- Khi không có thông điệp nào được gửi, HOSE sẽ gửi timestamp (TS) message theo một thời gian định kỳ nhất định Hiện tại thời gian là sau mỗi 30 giây không có message được gửi

c Định dạng của gói dữ liệu được truyền theo dạng broadcast

- Một gói dữ liệu broadcast có định dạng chung như sau:

Trang 19

Tên field Kích

cỡ (bytes)

Bảng 6 : Định dạng nội dung của message broadcast

2 Truyền lại các thông điệp bên đường UDP :

Khi sử dụng UDP gói dữ liệu có thể bị trùng lắp hoặc bị mất Nếu số sequence nhận được nhỏ hơn số sequence mà chương trình nhận mong muốn thì có nghĩa là nó bị trùng lắp và chương trình phải bỏ những packets này Nếu số sequence bị cách biệt, có thể 1 số packet bị mất khi đó chương trình nên thiết lập quá trình retransmission

- Số sequence tối đa của mỗi yêu cầu là 600 sequences

- Số sequence bắt đầu của yêu cầu retransmission hiện tại phải lớn hơn số

sequence kết thúc của quá trình retransmission thành công lần trước

Nếu yêu cầu hợp lệ, HOSE sẽ gửi lại Broadcast message chứa trong những message CTCI-RP Ký tự UnitSeparator (US) trong Broadcast packet sẽ thay thành ký tự BELL Nếu các message bị mất là các message Timestamp(CTCI-TS), thì hệ thống sẽ không gửi lại Message Timestamp trong trường hợp này được sử dụng để thông báo kết thúc quá trình retransmission Lưu ý : trường Timestamp trong message TS có giá trị là mod96( số sequence kết thúc của quá trình

Retransmission) chứ không phải là Mod96(HHMMSS) Những message màu xám trong hình 7 là tùy chọn

Trang 20

Hình 7 : Lượt đồ quá trình gửi lại thành công

Hình 8: Lượt đồ quá trinh gửi lại bị từ chối

b Truyền thủ công :

Công ty Chứng khoán thành viên cũng có thể yêu cầu gửi lại các gói UDP đã bị mất bằng cách gọi điện thoại cho HOSE và nói rõ packet sequence cần truyền lại

: :

TP Broker

Broadcast packet lost detected

Trang 21

IV/ Mô tả các message:

Message CTCI:

Message 1C: Thông tin hủy lệnh

1 Message Type 2 "1C"

3 Order Number 8 Numeric String

4 Order Entry Date 4 Numeric String

Total 17Message này dùng để hủy lệnh trong Hệ thống giao dịch HOSE, được xác định bởi số hiệu lệnh (Order number) và ngày nhập lệnh (Order Entry Date) Message xác nhận lệnh hủy (2C) sẽ được trả về cho công ty bởi Hệ thống giao dịch HOSE nếu lệnh đó được hủy Ngược lại Message từ chối (2G) sẽ được gửi lại cho công ty đó với mã lý do giải thích tại sao việc hủy lệnh đó không được chấp nhận

Trang 22

Message 1D: Thông tin thay đổi lệnh

1 Message Type 2 "1D"

5 Client ID 10 Alphanumeric String

Total 44Message này dùng để thay đổi những giá trị có thể chỉnh sửa của lệnh đã được nhập vào trước đó trong hệ thống giao dịch trên Bảng giao dịch khớp lệnh Nếu 1 trường được điền trong message này nó sẽ thay thế một giá trị đã tồn tại của trường đó trong lệnh đã đặt Message xác nhận thay đổi lệnh (2D) sẽ được gửi nếu nếu lệnh thay đổi này hợp lệ Ngược lại Message từ chối (2G) sẽ được gửi lại cho công ty đó với mã lý do giải thích tại sao lệnh đó không được chấp nhận

Trang 23

Message 1E: Thông tin quảng cáo GDTT

1 Message Type 2 "1E"

4 Security Symbol 8 Alphanumeric String

10 Add/Cancel Flag 1 Alpha String

Total 66 Message này dùng để thêm hoặc hủy một quảng cáo của mã chứng khoán Quảng cáo giao dịch thoả thuận không phải là lệnh đặt mà là thông tin được đưa lên biểu hiện ý muốn giao dịch một loại chứng khoán nào đó với giá và khối lượng thoả thuận Broker phản hồi quảng cáo GDTT này bằng cách liên lạc với broker đăng quảng cáo và thực hiện thỏa thuận giao dịch Nếu broker đó chấp nhận thỏa thuận thì lệnh giao dịch thỏa thuận khác thành viên (1G) sẽ được nhập vào bởi broker bán Trường thời gian (Time) được định bởi Hệ thống của broker và gửi cho Hệ thống giao dịch của HOSE khi thêm hoặc hủy một quảng cáo GDTT

Trang 24

Message 1F: Thông tin lệnh GDTT của khách hàng cùng công ty

1 Message Type 2 "1F"

4 Client ID (Buyer) 10 Alphanumeric string

5 Client ID (Seller) 10 Alphanumeric String

6 Security Symbol 8 Alphanumeric string

11 Broker Portfolio Volume (Buyer)

8 Numeric String

12 Broker Client Volume (Buyer) 8 Numeric String

13 Mutual Fund Volume (Buyer) 8 Numeric String

14 Broker Foreign Volume (Buyer)

17 Broker Client Volume (Seller) 8 Numeric String

18 Mutual Fund Volume (Seller) 8 Numeric String

19 Broker Foreign Volume (Seller)

8 Numeric String

Total 191Message này được dùng khi công ty chứng khoán thực hiện một giao dịch thỏa thuận cùng thành viên và được chấp nhận bởi HOSE Lệnh GDTT của khách hàng cùng công

ty (1F) chỉ có khi công ty chứng khoán vừa là người mua và người bán

Trang 25

Message 1G: Thông tin lệnh GDTT của khách hàng khác công ty

1 Message Type 2 "1G"

2 Firm (Seller) 3 Numeric String

3 Trader ID (Seller) 4 Alphanumeric String

4 Client ID (Seller) 10 Alphanumeric String

5 Contra Firm (Buyer) 3 Numeric String

6 Trader ID (Buyer) 4 Alphanumeric String

14 Mutual Fund Volume (Seller) 8 Numeric String

15 Broker Foreign Volume (Seller)

8 Numeric String

Total 120Message này được sử dụng khi 2 công ty chứng khoán làm giao dịch thỏa thuận và được chấp nhận bởi HOSE Sau khi thỏa thuận, người bán sẽ gửi lệnh GDTT của khách hàng khác công ty tới HOSE Khi thỏa thuận đã được thương lượng thì người bán phải có đuợc trader ID của người mua và nhập thông tin đó vào Hệ thống HOSE sẽ ấn định confirm number để giao dịch và gửi Message xác nhận giao dịch thỏa thuận (2F) cho người mua Người mua phải gửi lại message trả lời giao dịch thỏa thuận (3B) cho Hệ thống giao dịch của HOSE Sau khi người mua chấp nhận và HOSE chấp nhận thì một Message xác nhận khớp thỏa thuận (2L) sẽ được gửi về 2 phía Nếu người mua hoặc HOSE không chấp nhận thỏa thuận thì một message trả lời giao dịch thỏa thuận (3B) sẽ được gửi cho 2 phía

Trang 26

Message 1I: Thông tin lệnh đặt

1 Message Type 2 "1I"

4 Order number 8 Numeric String

9 Published volume 8 Numeric String

13 Port/Client Flag 1 Alpha string

Total 70Message này được gửi đến HOSE bởi công ty chứng khoán để nhập một lệnh Lưu ý : Published volume phải bằng với Volume

Trang 27

Message 2B: Xác nhận lệnh đặt

1 Message Type 2 "2B"

Total 17Message này được gửi bởi HOSE đến broker để xác nhận lệnh đó đã được nhận Order number được gửi ngược lại để xác định lệnh đã được nhận

Trang 28

Message 2C: Xác nhận hủy lệnh

3 Cancel Shares 8 Numeric String

6 Order Cancel Status 1 Alpha String

Lệnh hủy được xác định bởi Order number Message này được gửi khi :

- CTCK yêu cầu hủy lệnh và được HOSE chấp thuận

- Lệnh MP không được khớp

- Lệnh MP của nhà đầu tư nước ngoài (Bên mua), không được khớp hết

- Lệnh ATO, ATC không được khớp

Trang 29

Message 2D: Xác nhận thay đổi lệnh

6 Port/Client Flag 1 Alpha string

7 Published Volume 8 Numeric String

Total 50Đối với mỗi lệnh thay đổi được chấp nhận bởi HOSE, message xác nhận thay đổi lệnh sẽ đuợc gửi đến công ty yêu cầu thay đổi lệnh Order Number và Order Entry Date sẽ xác định lệnh được thay đổi Những trường khác trong message này sẽ chứa giá trị hiện tại cho lệnh đó bao gồm cả những thông tin lệnh mới được cập nhật Message này cũng được dùng để thông báo đến broker khi một lệnh thị trường chỉ mới khớp một phần, phần chưa khớp sẽ đổi lại thành lệnh giới hạn Khi đó, Published Volume để trống, price chuyển thành giá giới hạn

Trang 30

Message 2E: Xác nhận khớp lệnh của khách hàng khác công ty

1 Message Type 2 "2E"

9 Confirm Number 6 Numeric String

Total 40

Lệnh khớp của khách hàng khác công ty sẽ được gửi cho mỗi bên khi lệnh từ 2 broker khác nhau khớp

Trang 31

Message 2F: Thông tin lệnh GDTT cho bên mua

1 Message Type 2 "2F"

3 Trader ID (Buy) 4 Alphanumeric String

5 Contra Firm (Sell) 3 Numeric String

6 Trader ID (contra side-Sell) 4 Alphanumeric String

Total 52

Message này sẽ được gửi cho broker đối ứng khi mà một giao dịch thỏa thuận 2 bên Two Firm Put-through Deal Message) được nhận bởi HOSE Message này được gửi cho bên mua Chi tiết của giao dịch có thể đã được kiểm tra Người mua nên gửi Put-Through Deal Reply để chấp nhận hoặc không chấp nhận giao dịch này

Trang 32

(1G-Message 2G: Thông tin từ chối từ HOSE

1 Message Type 2 "2G"

3 Reject Reason Code 2 Numeric String More codes

message type Total 240

Lệnh từ chối sẽ được trả về cho công ty khi HOSE nhận một message không hợp lệ Trường Reject Reason code giải thích vì sao HOSE không thể thực hiện yêu cầu Trong

trường hợp message nguyên thủy vượt quá 233 byte, chỉ 233 byte đầu được đính kèm

Trang 33

Message 2I: Xác nhận khớp lệnh của khách hàng cùng công ty

1 Message Type 2 "2I"

3 Order Number (Buy) 8 Numeric String

4 Order Entry Date (Buy) 4 Numeric String

5 Order Number (Sell) 8 Numeric String

6 Order Entry Date (Sell) 4 Numeric String

Total 49

Lệnh khớp của khách hàng cùng công ty sẽ được gửi cho công ty chứng khoán khi 2 lệnh khớp được tạo bởi cùng 1 công ty chứng khoán

Trang 34

Message 2L: Xác nhận khớp GDTT

1 Message Type 2 "2L"

5 Contra Firm 3 Numeric String

Total 40

Message này được gửi để xác nhận cùng công ty hoặc khác công ty giao dịch thỏa thuận Nếu là bên mua Side=’B’, nếu là bên bán Side=’S’ Nếu mà giao dịch thỏa thuận cùng công ty Side=’X’

Trang 35

Message 3A - Admin

1 Message Type 2 "3A"

3 Trader ID (sender) 4 AlphaNumeric String

4 Trader ID (receiver) 4 AlphaNumeric String

6 Admin Message Text 66 AlphaNumeric String

Total 82

Admin Message là một message định dạng tự do, nó có thể được gửi từ công ty chứng khoán này đến 1 công ty chứng khoán khác, từ công ty chứng khoán đến HOSE hoặc từ HOSE đến công ty chứng khoán Trường Contra Firm sẽ là rỗng nếu message được truyền từ HOSE Trường Trader ID (sender) được yêu cầu và phải chứa ID của người gửi cho admin Trường Trade ID (receiver) là tùy chọn và được sử dụng để nói với admin người nhận sẽ là ai tại công ty chứng khoán khác

Trang 36

Message 3B: Thông tin trả lời lệnh GDTT của bên mua hoặc HOSE

5 Client ID (Buyer) 10 Alphanumeric

String

8 Broker Portfolio Volume 8 Numeric String

9 Broker Client Volume 8 Numeric String

10 Broker Mutual Fund Volume 8 Numeric String

11 Broker Foreign Volume 8 Numeric String

Total 95

Message này được gửi bởi người mua để cho biết là chấp nhận hay không chấp nhận của GDTT khác công ty sau khi nhận được Put-through Acknowledgment Message từ HOSE Nếu người mua đồng ý giao dịch thì Client ID, Port/Client Flag phải được nhập vào Sau khi giao dịch đó được chấp nhận hay không chấp nhận bởi người mua, HOSE sẽ gửi message này cho người bán Nếu giao dịch không chấp nhận bởi HOSE, HOSE sẽ gửi message này cho cả người mua và bán

Reply Code

A = Chấp nhận

C = Đối tác không chấp nhận

S = HOSE không chấp nhận

Trang 37

Message 3C: Thông tin yêu cầu hủy lệnh

Total 27

Message này được gửi bởi người mua để yêu cầu hủy một giao dịch thỏa thuận Nó cũng được HOSE sử dụng để chuyển yêu cầu này cho người bán Người bán sẽ phản hồi lại message 3D Khi message này xuất phát từ người bán gửi đến HOSE , trường Contra Firm ý chỉ người mua và trường Trader ID là Trader ID của người bán khởi tạo message này Trường hợp message này gửi từ HOSE đến người mua, trường Firm là người mua, Contra Firm là người bán và Trader ID là Trader ID của người mua

HOSE sẽ không kiểm tra trường Side trong message 3C nếu trường khác đã được HOSE xác nhận chính xác Trường Side trong message thuần của người bán được chuyển qua cho người mua

Trang 38

Message 3D: Thông tin trả lời yêu cầu hủy lệnh của bên mua hoặc HOSE

Total 12

Message này sẽ được gửi bất cứ khi nào thỏa thuận bị hủy, đối với những thỏa thuận được thực hiện bởi 2 broker khác nhau, người mua sẽ gửi message này đến HOSE để trả lời message yêu cầu hủy (3C) được gửi bởi người bán HOSE sẽ gửi message này đến người bán để báo cho người bán biết yêu cầu của người mua và phản hồi của HOSE với việc hủy giao dịch Nếu giao dịch được thực hiện bởi 1 broker, HOSE sẽ gửi message này đến broker đó để trả lời yêu cầu hủy (3C)

Trang 39

Message RN - Retransmission Nack

1 Message Type 2 "RN"

4 Original Message Text 478 Alpha string

Total 484

Message này sẽ được gửi ngược lại công ty chứng khoán bao gồm mã lỗi và message gốc khi yêu cầu truyền lại không hợp lệ Lý do từ chối được miêu tả trong error code

Trang 40

Message RP - Retransmission Reply

4 Previous Sequence Number 3 Mod-96

7 Original Broadcast Message 472 Alpha string

Total 484

Message này dùng để truyền lại Broadcast message đến công ty dựa trên yêu cầu (RQ) Market ID là mã thị trường Trường Sequence Number chứa số sequence của khối message broadcast thuần Trường Previous Sequence Number cho biết số Sequence của khối Broadcast đã được gửi trước khối sẽ được gửi lại trong message này Trường Message Count chỉ ra cho biết số message trong khối được gửi lại Đối với message đầu tiên của quá trình gửi lại này, trường Previous Sequence Number sẽ là 0 Để duy trì sự toàn vẹn của dữ liệu truyền lại, ký tự Unit-Separator (US) trong message broadcast thuần

sẽ được thay thế bởi ký tự BELL

Định dạng
Số trang	95
Dung lượng	903,99 KB