Imported from previous forum
Hi,
I see there was/is a QuoteAcknowledgement (MsgType b) - but that does not seem to be current.
QuoteAck seems to be new/different. I don’t see it in the standard specs for 50sp2.
Is it from an expansion pack or similar?
Many Thanks,
Chris
The short answer is yes but it depends on your workflow. MsgType b is offically called MassQuoteAcknowledgement since FIX 4.3 and to be used to ack a MassQuote. The new QuoteAck message was added as EP143 to FIX 5.0 SP2, see http://www.fixtradingcommunity.org/pg/extensions/extension-pack?ExtensionID=EP143 for details and whether it really fits to your use case.
Regards,
Hanno.
Ok - that makes sense.
Cheers.
Hi guys,
I have a slightly related query 
The CME and ICE exchanges respond to a Quote Request (MsgType ‘R’)with a ‘b’ message.
We need to add support for Quote Requests in our FIX Gateway but I was expecting an ‘S’ message as a standard response to an ‘R’ msg?.
Is a MassQuoteAcknowledgement msg an acceptable response?
I’m assuming the exchanges respond with a ‘b’ msg for a reason?.
Any help would be greatly appreciated.
Many thanks
Graham Carter
Hi Graham,
it is probably for historic reasons as they started out with FIX 4.2. There “b” stood for the QuoteAcknowledgement message and was defined as “An optional response to Quote, Mass Quote, Quote Cancel, and Quote Request message is the Quote Acknowledgement message.” Later it was renamed and limited to mass quoting, i.e. “Mass Quote Acknowledgement is used as the application level response to a Mass Quote message.”
Regards,
Hanno.
Hi Hanno,
ah, that would explain it!
Many thanks for that.
cheers
Graham
In which format FIX messages are sent by the exchange? Whether as all ASCII characters or as decimal integer converted to hex value?
The exchange can choose one of the many FIX encoding standards. The list is quite long by now:
FIX tag=value (ASCII)
FIXML (ASCII)
FAST
Simple Binary Encoding
Google Protocol Buffers (work in progress)
ASN.1
JSON (ASCII)(work in progress)
…
Mass quoting probably benefits from a binary encoding.
Consider a part of FIX message below
8=FIX.5.0^9=7B^35=U20^
When I write into HEX format for sending it on a wire, the message would be the following
38 3D 46 49 58 2E 35 2E 30 5E 39 3D 37 42 5E 33 35 3D 55 32 30 5E.
In Bombay stock exchange documentation they have mentioned that MsgType Tag(35) should be of 4 bytes.But in the above message the value of TAG 35, i.e U20, gives only three bytes. So how will the exchange send it as 4 bytes???
Suman, I think your question should be directed to the Bombay Stock Exchange and their Rules of Engagement. There is no need for padding with spaces in tag=value encoding. This only applies to fixed length encodings such as FIX SBE (Simple Binary Encoding) where there is no explicit field delimiter or field length information on the wire.
Regards,
Hanno.
Thank Mr Hanno Klein for your answer,
I’m not using space for padding, i have added it for readability purpose only.
My question is, are they going to use ‘null’(0x00) character to make the number of bytes of VALUE field equal to number of bytes given in document.
For Example
35=U20^ will it be sent as
33 35 3D 00 55 32 30 5E
or just 33 35 3D 55 32 30 5E
Space was just an example, I meant padding with bytes of any kind. Can you provide a link to the document of the BSE if you cannot ask them directly?
Here is also a general rule. In FIX you should be as compliant as possible in your own messages and as flexible as possible when receiving messages from others. So your software should be prepared to read all (4) bytes even if less (3) are needed and discard byte(s) that have no relevance for the actual value within the field.
http://www.bseindia.com/downloads1/BSE_market_data_EOBI.zip
This is the link for BSE exchange.
I want to know whether they(BSE) will send that FIX field value as 4 byte or 3 bytes ?
Suman, since this interface (EOBI) stems originally from Eurex which is part of Deutsche Börse Group and the company I work for, I have made the effort and read the manual for you. Here is what I found:
Chapter 2, page 5: “Information is sent in form of fixed-length binary messages.”. This is the key information and it means that fields are always sent with the same length regardless of the actual content.
Chapter 7.2, page 27 (second to last row in the table): “35 MsgType U20 4 Fixed String U20 = Market Data Report”. This shows that “U20” is sent as fixed string with a length of 4 bytes. So the answer for your question is “They(BSE) will send that FIX field value as 4 bytes”. I can only assume that space padding is used because I have found no information on that in the manual. However, I know that BSE does that for the transactional interface (ETI).
Regards,
Hanno.
Thank you very much for your answer sir Hanno Klein.
Sir I have one more doubt.
I consider Zero padding for Int/Float.
Consider this example,
Specification says 2 bytes of unsigned Int for Templete ID(TAG=28500) Field and if the value of Templete ID is 13001(Heartbeat) , will they(BSE)send it as
31 33 30 30 31 (Which would be 5 bytes) or as
32 C9 (Which would be 2 bytes) ? (where 32 C9 is the hex equivalent of 13001).
The answer is 32 C9 (hex) which is 13001 as decimal and 01100101 1001001 as bytes. It is not ASCII but a binary encoding where padding only applies to strings. You cannot “pad” an integer value. 1 byte means you can represent numbers up 2 to the power of 8 = 256, 2 bytes means you can represent numbers up 2 to the power of 16 = 65526, and so on.
Thanks a lot sir. It was very useful information. For each of the message’s format table mentioned in the document, will the BSE send all the tags mentioned in each table or only req’d = Y fields will be sent?
Fixed length encoding means that messages always have the same length, i.e. all fields are sent. Req’d Y/N is used to denote whether the field (=bytes at a specific position) contain something meaningful or are logically absent although physically present.
Fixed length encoding requires the definition of special values for each data type which are reserved to express “no value”. See BSE ETI User Manual Chapter 7.2. For example strings starting with a null value 0x00 are to be considered absent (which is different than full of whitespaces such as blanks). You have to check the field for these special values to find out if an optional field has any content that you need to process in your application.