gabirel1 / epitech-principe-financier-de-base-et-architecture

Epitech-Principe-financier-de-base-et-architecture

CLI Client:

Command:

User:

logon -u UserId

Send a request to logon with the UserId passed in argument.

logout

Send a request to logout of the actual connected account, nothing is done if the user isn't connected.

status

Display the context's information (all the status).

epitech-principe-financier-de-base-et-architecture's Issues

OrderBook interface

Description:

Create an object to display the OrderBook separating Ask and Bid:

• Table: object to display column and row with Price and Quantity dynamically.

Market selector

Description:

Create a Selector to choose between any OrderBook available server side.

Global documentation

Description:

Add the documentation over the whole project.

Reference all the advancement on the document with the pull request in the comment under this issue.

Global testing

Description:

Create unit or functional test for the whole solution, targeting in priority the crucial part.

Cancel interface

Description:

Add to the interface a section to cancel Order place by the client:

• Id (NumericInput): of the Order to cancel.
• Send (Button): action to save and send the cancel to the server.

Documentation pipeline

Description:

Add the document for each pipeline (refered with the namespace pip) and the core Pipeline.

Error pipeline

Description:

Create a Pipeline to handle every error send over the whole solution and send them to the OutNetwork.

Better verification of header

Description:

The header of any fix request is verify only by the function fix::Header::Verify, but it doesn't verify the actual value of the different field.

Changed:

Verfiy this field:

• TargetCompId: verify that's the one of the user or the one of the server
• SenderCompId: same as TargetCompId
• BodyLenght: compare it to the actual body lenght received
• CheckSum: verify it's match the calculated one on the request

OrderBook add

Problem:

When adding a bid when taking their is an higher ask, it never sell.

Reason:

Because we use a template function (add<T>) to manage the OrderBook bid and ask, the condition when exiting the while is wrong when the order type is Ask:

    for (auto &[_key, _val] : _book) {
        if (_key > _price)  // this condition is wrong
            break;
        OrderList &ol = _book.at(_key);

Full code here

The actual reason of this behavior is because we use 2 differents sorting algorithm for BidBook and AskBook:

using AskBook = std::map<Price, OrderList, std::greater<Price>>;
using BidBook = std::map<Price, OrderList, std::less<Price>>;

ref here

UDP handling

Description:

Manage the UDP connection to receive and send request and connect them to the UI.

ThreadPool thread name

Description:

Being able to set the name of any std::thread contained by ThreadPool.

Order interface

Description:

Add to the interface a section to send Order with this elements:

• Type (Selector): choose between Ask or Bid.
• Price (NumericInput): quantity of the order.
• Quantity (NumericInput): quantity of the order.
• Send (Button): action to save and send the Order to the server.

It will display a small text to signal error

UDP Output

Description:

Implementation of the 2 UDP pipeline, to broadcast change on the OrderBook:

• UDP input: let any socket to connect to the server, when a message is receive disconnect then client.
• UDP output: broadcast the change on the OrderBook to every client connected via the UDP input

The format of the data send need to be determined

Main FIX protocol action

Description

Management of the FIX protocol action:

• Logon (A):
• Logout (5):
• NewOrder (D):
• OrderCancelReplaceRequest (G):
• OrderCancelRequest (9):

The different action need a global and short description and could change some pipeline behavior

Crash closing socket

Description:

When a c::Socket or an abstraction (net::Socket, net::tcp::Socket, net::Acceptor<T>,...) is close by any way (from the connected service or by the actual solution), the programme crash with a:

Segmentation fault (core dumped)

Multi market management

Description:

Make the server able to manage multiple OrderBook and Action pipeline.
The server is think to allow this with minimum impact on other pipeline behavior.

Modify interface

Description:

Make an interface to modify an Order made by the user:

• Id (NumericInput): target the OrderId.
• New quantity (NumericInput): new Quantity to set.
• New price (NumericInput): new Price to set.
• Send (Button): action to save and send the Order modification to the server.

UI object

Description:

Create interface object using SFML to simplify the develepoment:

• Button: simple button taking a sf::Texture or a std::string to be display, triggering a callback function.
• Selector: multiple choice selector.
• Input: a box where you can input any type of character.
• NumericInput: an input taking only numeric input.
• AlphaInput: an input taking only alphabetic input.

NumericInput and AlphaInput should be based on Input

Secondary FIX protocol action

Description:

Management of the FIX protocol action:

• ExecutionReport (8):
• MarketDataSnapshotFullRefresh (W):
• MarketDataIncrementalRefresh (X):

The different action need a global and short description and could change some pipeline behavior

Market sorting action

Description:

The Market must order action or the OrderBook due of the multithreading on previous the pipelines (Serializer, Action) with the seqNum from the FIX protocol.

First approche:

Use an std::queue to store action with a seqNum higher than the actual Market seqNum await.

Status management

Description:

Create more micromanagement on the status of each Pipeline in the main thread.

BUG : SERVER BLOCK : No longer accepting any request / connection

• Connect a client
  --> LOGON
  ---> NEW ORDER
  ---> WAIT FOR CLIENT 2 ORDER FILL
  ---> TEST FAIL -> SOCKET.CLOSE() without LOGOUT

• CLIENT 2 --> LOGON ---> NEW ORDER --> LOGOUT

CLIENT 2 --> BLOCKED at sending logout

--> Cannot send / connect to the server anymore

HOW TO REPRODUCE:

1. Start BLOCKING_TEST.py
2. start BLOCKING_TEST2.py
3. try to connect with every script --> CANNOT DO ANYTHING

Test OrderBook

Description:

Test every functionnality of the OrderBook.

Test FIX message

Description:

Create unit test on the fix::Message serializer and deserializer using gtest

TCP handling

Description:

Manage the TCP connection to receive and send request (certainly implementing the system of Pipeline?) and connect them to the UI.

Verify log

Description:

Verify each log to detail the behavior of the whole solution.

Fix warning

Description:

Fix all warning on the whole solution (mostly error handling return).