Modello di comunicazione¶

Introduzione ¶

Il FIX API utilizza una comunicazione basata su sessioni. Una sessione è definita come la comunicazione tra due parti: l'iniziatore (client), la parte che avvia la comunicazione, e l'accettore (server), la parte che riceve la richiesta di connessione dall'iniziatore.

Il server convalida le richieste del client utilizzando il messaggio di Logon.

Protocollo di sessione FIX ¶

Ogni sessione mantiene messaggi bidirezionali tra il client e il server cTrader. Una sessione può includere più connessioni fisiche ed è mantenuta utilizzando numeri di sequenza.

Ogni nuovo messaggio all'interno di una singola sessione riceve un numero di sequenza univoco a partire da 1 (uno). Entrambe le parti si basano sui numeri di sequenza per mantenere una comunicazione ordinata. I messaggi mancanti vengono ritrasmessi con un accordo bilaterale tra entrambe le parti.

Flusso tipico di una sessione:

1. Il client avvia la sessione con un messaggio di Logon.
2. Il client scambia messaggi applicativi con il server.
3. La sessione termina con un messaggio di Logout.

Categorie di messaggi del protocollo FIX di cTrader ¶

Come definito nel protocollo FIX, il server FIX di cTrader utilizza 2 diversi livelli di dati: di sistema e applicativo.

Si prega di notare che questo è il set minimo di messaggi necessari per supportare i flussi di lavoro necessari ed è soggetto a modifiche nel tempo in base all'evoluzione delle esigenze aziendali e dello standard FIX.

Messaggi di sistema (admin) ¶

• Heartbeat (client ↔ cTrader) – utilizzato per verificare il collegamento di comunicazione tra le due parti.
• Test request (client ↔ cTrader) – utilizzato per testare lo stato del collegamento di comunicazione.
• Logon (client → cTrader) – messaggio di autenticazione del client.
• Logon (client → cTrader) – terminazione normale della sessione.
• Resend request (client ↔ cTrader) – richiesta di ritrasmissione di determinati messaggi applicativi.
• Reject (client ↔ cTrader) – fallimento della validazione a livello di sessione.
• Sequence reset (client ↔ cTrader) – in caso di problemi di comunicazione i messaggi mancanti vengono recuperati o la sequenza viene reimpostata per ignorare i messaggi mancanti.

Messaggi applicativi ¶

• Market data request (client → cTrader) – richiesta generale di dati di mercato.
• Market data incremental refresh (client ← cTrader) – risposte a un messaggio di richiesta di dati di mercato.
• New order single (client → cTrader) – utilizzato per inviare elettronicamente gli ordini a un broker per l'esecuzione.
• Execution report (client ← cTrader) – utilizzato per inviare informazioni sullo stato dell'ordine a un client FIX, come conferme, esecuzioni e modifiche non sollecitate.
• Business message reject (client ← cTrader) – utilizzato per rifiutare una richiesta del client FIX per motivi non relativi alla sessione.

Struttura del messaggio FIX ¶

Questa sezione spiega come è composto il messaggio FIX API, descrive il formato del messaggio FIX e aiuta gli utenti a comprendere il concetto di coppia tag e valore.

Ogni messaggio deve contenere 3 parti:

• Header – ogni messaggio amministrativo o applicativo è preceduto da un'intestazione standard. L'intestazione identifica il tipo di messaggio, la versione FIX, la lunghezza del messaggio, la destinazione, il numero di sequenza, l'origine e l'ora.
• Body – il contenuto nel corpo del messaggio è specificato dal tipo di messaggio definito nell'intestazione.
• Footer – ogni messaggio, amministrativo o applicativo, è terminato da un piè di pagina standard. Il piè di pagina viene utilizzato per separare i messaggi e contiene la rappresentazione a tre cifre del valore CheckSum <10>.

Formato del messaggio FIX ¶

Un messaggio FIX è una raccolta di campi. Ogni campo è una coppia tag-valore formattata come {tag}={valore}. Ad esempio, 54=2, che significa che il tipo di ordine è vendita.

Tag ¶

• FIX utilizza tag predefiniti.
• Ogni tag rappresenta un campo specifico.
• Ad ogni tag viene assegnato un numero predefinito.
• La specifica FIX di cTrader fornisce un elenco di campi e i corrispondenti numeri di tag.

Valore ¶

• I valori rappresentano il valore del tag assegnato ad esso.
• I valori possono essere solo uno dei seguenti tipi di dati: intero, virgola mobile, carattere, ora, data, dati o stringa.

Tutti i messaggi all'interno del FIX API di cTrader iniziano con 8=FIX.x.y, dove x.y è la versione del protocollo FIX. Alla fine di ogni messaggio dovrebbe esserci un campo 10=xyz, dove xyz rappresenta la somma di tutti i valori binari nel messaggio chiamata checksum.

Il checksum aiuta a identificare eventuali problemi di trasmissione, in particolare la perdita di pacchetti, consentendo al destinatario di sapere se manca una parte del messaggio.

Se il tag Symbol(55) viene utilizzato in un messaggio FIX verso cTrader/cServer, è necessario specificare l'ID simbolo FIX. Questo valore può essere diverso tra i broker. Puoi trovare il campo ID simbolo FIX nell'applicazione cTrader di quel broker nella finestra delle informazioni sul simbolo.

Esempio di messaggio ¶

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|