DTC Protocol Discussion Forum
- DTC Protocol Discussion Forum |
- Search Board |
- Control Panel |
- View My Posts / Threads |
- Direct Messages
Date/Time: Fri, 29 Nov 2024 14:38:10 +0000
Request for Comments: TotalNumMessages, MessageNumber
View Count: 3179
| [2015-09-13 02:22:31] |
| |
|
We are proposing the following field changes for messages which use these: TotalNumMessages >> FirstMessageInBatch (boolean) MessageNumber >> LastMessageInBatch (boolean) |
| [2015-09-13 14:13:49] |
| vbmithr - Posts: 204 |
|
+1, great! With always the option to send an empty (dummy) message at the end signaling the end of the message stream. I use that in order to avoid coding the logic of figuring out which is the last message, which can be sometimes somewhat complex. |
| [2015-09-14 01:49:33] |
| |
|
If it is somewhat complex as to what the end of the message stream is, then that indicates an excellent example of why all of these REST trading interfaces out there are regarded by us as substandard. For example, in the case of when sending Open Orders, there must always be an indication of the first order and the last order in the ORDER_UPDATE response messages. All of those REST trading interfaces are all proprietary. They all are different Date Time Of Last Edit: 2015-09-14 01:53:47
|
| [2015-09-14 07:18:10] |
| vbmithr - Posts: 204 |
|
I think I exagerated. I remember that, at some point, I found it annoying to have to compute the number of messages I was going to send. But there is nothing complicated in it, just get the length of the filtered list of messages you want to send. If there is first/last message in batch, it's a bit simpler because I don't have to compute this length, I can just send all the messages and when done, send an empty one. But I can' say it's complicated :) Why do you want to change this in the first place ? I still agree that I prefer the new proposal, but it does not make an important difference to me. Date Time Of Last Edit: 2015-09-14 07:18:50
|
| [2015-09-14 07:25:42] |
| |
|
We were thinking of changing it because as we are writing a server ourselves, we see that it is more involved and less efficient to calculate the number of messages when sending Open orders and Positions. In the case of the FIX protocol, the Execution Report does support the number of messages in a batch: 911 TotNumReports @TotNumRpts
Can be used when responding to an Order Mass Status Request to identify the total number of Execution Reports which will be returned. This is helpful to determine the last message received. Date Time Of Last Edit: 2015-09-14 09:19:26
|
| [2015-09-14 07:32:42] |
| vbmithr - Posts: 204 |
|
I think - first/last message is more efficient for performance. Only one uint8_t is necessary, for example 0 = neither first or last, 1 = first, 2 last. BTW, you should not use 2 uint8_t to store this information, that takes exactly 2 bits (three different position) to be stored. - It seems to me that msg number / total number of messages is more fault tolerant, because you always know where you are in the message stream, and if you loose messages, you can always re-ask the specific number. When using first/last message, suppose you never get the last message because of a network issue, you're a bit stuck right ? |
| [2015-09-14 09:24:22] |
| |
|
Over a TCP/IP connection messages will not be lost. If they are, the connection will be closed, it will be reconnected and there will be new request to the Server. Thinking about this some more, we think these should remain: TotalNumMessages MessageNumber They do convey a lot of usable information. For example, the Client can maybe allocate memory or do something when it knows the total number of messages at the very start. Otherwise, it has no idea what is going to come. So in the end we do feel the current implementation is a good choice. |
To post a message in this thread, you need to log in with your Sierra Chart account: