Common Way of Making Trades

All calculations and other actions performed due to the execution of an application program can be divided into two groups by the location of their execution: those executed in the user's PC and those executed on the server side. A significant amount of calculations is performed on the user's side. This group includes the execution of application programs. Trades belong to the second group. Making trades implies data conversion on the server.

Considering trades, we will distinguish the following terms:

Market order - is an executed order to buy or sell assets for a symbol (security). A market order is displayed in the symbol window until the order is closed.

Pending order is a trade order to buy or sell assets for a security (a symbol) when the preset price level is reached. Pending order is displayed in the symbol window until it becomes a market order or is deleted.

Trade Request is a command made by a program or by a trader in order to perform a trade.

Trade is opening, closing or modification of market and pending orders.

Trade Making Diagram

Three constituents are involved in making trades: an application program, the client terminal and the server (see Fig. 65). A request is formed in the program (as we mentioned above, any application programs can be executed only in the user's PC; no application programs are installed on the server). The request formed by the program will be passed to the client terminal that, in its turn, sends the request to the server. At the server side, the decision on the request execution or rejection will be made. The information about the obtained results will be passed by the server to the client terminal and then to the program.

Fig. 65. Diagram of requesting for making trades.

Requesting

A trade request can be made by a trader or by a program. For a trader to be able to make a request the client terminal provides the "Orders" control panel (see the description of the client terminal). The requests are made in the program according to the algorithm, as a result of the execution of trade functions. Nowhere else (neither in the client terminal nor on the server) trade requests are formed spontaneously.

Program Features

Depending on the algorithm, a program can form different requests - for opening, closing or modification of market and pending orders. The following trade functions are used in a program to form trade requests:

• OrderSend() - to open market and pending orders;
• OrderClose() and OrderCloseBy() - to close market orders;
• OrderDelete() - to delete pending orders;
• OrderModify() - to modify market and pending orders.

The above trade functions can be used only in Expert Advisors and scripts; the use of these functions in indicators is prohibited (see also Table 2). There are other functions that belong to trade ones (see help file in MetaEditor and the section Trade Functions in this present book). However, their execution is attributed to calling for the terminal information environment in order to obtain reference information, so it does not result in forming requests and calling to the server.

Features of Client Terminal

A request made by the program as a result of the execution of a trade function is passed to the client terminal for processing. The client terminal analyzes the request contents and performs one of the following two actions: either sends the request to the server for it to be executed on the server, or rejects the request and sends nothing to the server.

The client terminal allows only correct requests to be sent to the server. If the program is coded in such a way that it forms, for example, a request for opening an order at a non-existing price, the client terminal will not send this request to the server. If the program forms correct requests (orders are opened and closed at the latest known price, the order value is within the range limited by the dealing center, etc.), then this request will be sent to the server.

Only one execution thread is provided in the client terminal to perform trades. This means that the client terminal can simultaneously work only with one request. If there are several Expert Advisors or scripts trading in the client terminal and no program has passed a trade request to the client terminal, the trade requests of all other Expert Advisors and scripts will be rejected until the client terminal completes processing the current request, i.e., until the trade thread is free.

Server Features

The information about trade history for each account (opening, closing, modifying orders) is highly secured by the server and is of a higher priority as compared to the history of trades stored in the client terminal. The right to execute trade requests is granted only to a dealer or to the server that processes requests automatically (if the dealing center provides the server with this feature for a certain period of time). A request that is delivered in the server can be either executed or rejected. If the trade request is executed (i.e., a trade is made), the server will make all necessary conversions of data. If the trade request is rejected, the server does not convert any data. No matter which decision (to execute or to reject a request) is made, the information about this decision will be passed to the client terminal to synchronize the history.

A trade request formed as a result of the program execution and a trade request formed by the trader manually are absolutely the same, from the viewpoint of the server, so the server makes no distinction between requests when processing them.

It is also possible at the server side to prohibit Expert Advisors to trade in the client terminal. It is sometimes necessary, if the program operation causes conflicts. For example, if the implementation of an incorrect algorithm results in that the program continuously forms alternating trade requests for opening and closing of orders with very small intervals in time (for example, at every tick), or if the requests for opening, deletion or modification of pending orders are too frequent.

Trading Procedure

The procedure of performing trades is interactive and realized in the real-time mode. The diagram (Fig. 66) shows all events related to performing a trade.

Fig. 66. Event sequence in making a trade.

Event 0. The program is launched for execution at the moment t0.

Event 1. At the moment t1, the program has formed a trade request as a result of the execution of a trade function. The trade request is passed to the client terminal. At that moment, the program passes the control to the client terminal and the execution of the program is stopped (the red point in the diagram).

Event 2. The client terminal has received the control and the information about the request contents. Within the period of time between t2 and t3, the client terminal analyzes the contents of the trade request and makes a decision on further events.

Event 3. The client terminal performs that made decision (one of two alternatives).

Alternative 1. If the trade request formed as a result of the execution of one of trade functions has turned out to be incorrect, the control is passed to the program. In this case, the next event will be Event 4 (this can happen if, for example, the program has sent the request for opening an order, the value of which exceeds the account equity available).

Event 4. The program has received the control (moment t4, green point) and can continue execution from the location where the request has previously been formed. At the same moment, the program has received the information about that the trade order has not been executed. You can find out about the reason, for which the trade request has not been executed, by analyzing the ode of the returned error. Below we will consider the matter of how to do this. Here, it must only be noted that not all requests result in execution of trades. In this case, the program has formed an incorrect request, which results in that the client terminal has rejected this request and returned the control to the program. In this case, no referencing to the server takes place. The time intervals between t1 - t2 - t3 - t4 are negligibly short and do not exceed several ms in total.

Alternative 2. If the program has formed a correct trade request, the client terminal sends this request to the server; the next event will be Event 5 (the moment of t5) - the server will receive the trade request. The connection between the client terminal and the server is established via Internet, so the time spent on sending of the trade request to the server (time interval between t3 and t5) is completely dependent on the connection quality. For a good-quality connection, this period of time can be approximately 5 to 10 ms, whereas it can be measured in whole seconds at bad connection.

Event 5. At the moment t5, the server has received the trade request. The server can execute or reject this received request. The decision on executing or rejecting of the request can be made at the server side within a certain period of time (at the moment t6). The time interval between t5 and t6 can range from some milliseconds to the dozens of seconds, depending on the situation. In some cases, if the server operates in the automated mode and there are no rapid movements in the market and other traders are not very active, the trade request can be executed or rejected within several milliseconds. In other cases, if the server is overloaded due to high activity of traders and if the decision on executing or rejecting of the request is made by a human dealer, the time taken by making the decision can be counted in the dozens of seconds.

Event 6. If no considerable changes take place on the market within the time interval from the moment of forming the trade request by the program (t1) to the moment of making decision by the server (t6), the trade request will be executed, as a rule. If the price of the symbol has changed within this time or the value of the order to be opened is exceeding free equity of the account at the moment of making the decision, or other impediments occur, then the server decides to reject the trade request.

The server's rejection of trade requests (though they have already been checked by the client terminal) is common. In general, the most trade requests that are delivered to the server are accepted to execution by the server. However, in some cases, a request can be rejected, so your application program must be coded in such a way that it takes such possibility into consideration and operates properly in such situations.

Whatever decision (to execute/reject a trade request, Event 6) is made by the server, the information about it is sent by the server to the client terminal that has delivered the request.

Event 7. The client terminal has received the server response. The server response follows the same path through the Internet as the request delivered to the server; so the time spent on receiving of the server response completely depends on the connection quality. According to the modifications made on the server, the client terminal will reflect the corresponding changes. For example, if the execution of a trade request results in closing or opening an order, the client terminal will display this event graphically in the symbol window and textually in the 'Terminal' window (the tabs 'Trade' and 'Account History'). If the server has rejected the trade request, no changes will be made in any windows of the client terminal.

Event 8. The client terminal has completed the displaying of changes and is passing the control to the program.

Event 9. The program has received the control and can continue operating.

Please note:

From the moment when the program sends a trade request (and simultaneously passes the control) to the client terminal, to the moment when the control is returned to the program, the latter one is in the waiting mode. No operations are made in the program during this period of time. The control is returned to the program according to the execution rule for call to the function that has formed the trade request.

If the trade request is incorrect, then the program isn't in the waiting mode for a long time (the interval between t1 and t4). However, if the trade request is 'approved' by the client terminal and sent to the server, the duration of the program waiting period (t1-t9) can be different and depends on both the connection quality and on the time taken by decision making of the server - for several milliseconds to minutes.

As soon as the program receives the control, it can continue operating. The operating program can analyze the code of the last error returned by the client terminal and, in this manner, find out about whether the trade request was executed or rejected.

Conflicts in Making Trades. Error 146

When considering above the features of the client terminal, we mentioned that the client terminal could process only one request in a time. Let's now consider what events will take place if several requests formed by different programs will be passed to the client terminal.

Fig. 67. Conflicts in passing several requests to the client terminal from different programs.

In Fig. 67, we can see that two trading Expert Advisors are launched for execution on the client terminal simultaneously. EA1 formed a trade request at the moment t1 and passed it the client terminal the moment t2.

EA2 has also created a request and refers to the client terminal when the client terminal is processing the first request (period from t2 to t3). In this situation, the client terminal cannot consider the request formed by EA2, so it will reject this request and return the control to EA2. Please note that, in this case, the request is rejected by the client terminal not for the request is incorrect, but because the terminal is busy with processing of the other request. EA2 will continue operating. It can analyze the error code that explains the reason why the request has been rejected (in our case, it is error 146).

If it is EA2 (in a general case, it can be one or several trading programs) that passes its request to the client terminal within the period of time between t1 and t4, then this request will be rejected (a group of events in the pink area). The client terminal becomes free at the moment t4 (green point). Starting from this moment, EA2 can successfully pass its request to the client terminal (a group of events in the green area). This request will be received and considered by the client terminal that can finally reject it, too, but for the reason of its incorrectness, or it can send this request to the server.

If the trade request created by EA1 is considered by the client terminal as correct, this request will be sent by the client terminal to the server at the moment t3. In this case, the client terminal switches to the waiting mode and cannot consider any other trade requests. The client terminal will only become free for considering of other trade requests at the moment t9. Thus, according to Variation 2, the client terminal cannot analyze trade requests within the period of time between t1 and t9. If within this period any program refers to the client terminal in order to pass a request for consideration, the client terminal will reject this event and pass the control to the program (a group of events in the pink area within the period of time between t6 and t7). The program that has received the control continues its operation and, by analyzing the error code, can find out about the reason, for which the request has been rejected (in this case, it is error 146).

Starting from the moment t9, the client terminal will be completely free for analyzing any other trade requests. EA2 can successfully pass the trade request to the client terminal within the period of time that follows the moment t9. According as the client terminal considers this request to be correct or not, the request will be passed by the client terminal to the server or rejected.

The analysis of errors that occur in making trades is considered in more details in the sections below.