Contact

[pre-vail]

How can i contact you? I'd like to learn a little more about FAST and possibly work on this project. It would be nice if we can have a short phone conversation.

[vekonyz]

You find the specification here https://www.fixtrading.org/standards/fast/

[pre-vail]

Thanks I’m aware of that page. Can you give a brief description of how you would go about implementing support for streaming?

On Sep 1, 2019, at 6:46 AM, Zoltan Vekony notifications@github.com wrote:

You find the specification here https://www.fixtrading.org/standards/fast/

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[vekonyz]

streaming with or without additional framing?

[pre-vail]

What do you think is the best option?

On Sep 1, 2019, at 1:30 PM, Zoltan Vekony notifications@github.com wrote:

streaming with or without additional framing?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[vekonyz]

What is your use case?

[pre-vail]

https://gainfutures.com/wp-content/uploads/FIX.pdf Pages 49 to the end explain what I’m using FAST for.

On Sep 1, 2019, at 4:26 PM, Zoltan Vekony notifications@github.com wrote:

What is your use case?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[pre-vail]

Have you had a chance to take a look at the pdf?

[vekonyz]

Yes, I didn't found any references in regards of additional framing, but found an issue: in MarketDataSnapshotFullRefresh message the field MDEntryPx uses exponent/mantissa operator for encoding decimal values - and this is still not implemented here ...

[pre-vail]

How should it be implemented? Can you give some insight? Maybe it will be the first thing I work on.

On Sep 7, 2019, at 2:57 AM, Zoltan Vekony notifications@github.com wrote:

Yes, I didn't found any references in regards of additional framing, but found an issue: in MarketDataSnapshotFullRefresh message the field MDEntryPx uses exponent/mantissa operator for encoding decimal values - and this is still not implemented here ...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[vekonyz]

The idea in this FAST implementation is that after loading the xml specification the message structures are stored in memory and each time a message is encoded or decoded, the program iterates over the stored data 'model'. In order to support handling exponent and mantissa individually, you have to add special processing rules in encoder as well as in decoder part. The problem with individual matissa and exponent is that each of them can have potentially individual operators and constraints...

[pre-vail]

Thank you for that explanation. A little background on my knowledge of FAST up to this point: I first heard of both FIX and FAST about 2-3 months ago so I’m very new to both of them. FIX is not that hard to understand, I view it as name/value pairs joined by a separator. I’m using the fixparser https://www.npmjs.com/package/fixparser package to handle FIX messages. FAST is a different story. I have a list https://www.fixtrading.org/standards/fast of documents that I want to read in order to understand it. In particular, the documents are:

1 FAST Specification Version 1.1 (reading now) 2 FAST Session Control Protocol (SCP) 1.1 3 Basic FAST User's Guide 4 FAST Protocol Technical Overview (quickly reviewed it but will read it again) 5 FIX Over FAST Implementation Guide (done) 6 FAST Extension Version 1.2 (not needed but i’ll read it anyway)

At this point, I honestly don’t understand what you mean by “each of them can have potentially individual operators and constraints” but that’s probably due to the fact that I don’t understand FAST well enough yet. I’ll continue reading from my list. If you can clarify that statement, I’d appreciate it. If you feel that I just need to learn more about FAST, I understand that too. Either way, thank you for answering my questions so far, I look forward to adding any necessary functionality to this package as I need it to continue with the project that I’m working on.

On Sep 8, 2019, at 2:51 PM, Zoltan Vekony notifications@github.com wrote:

The idea in this FAST implementation is that after loading the xml specification the message structures are stored in memory and each time a message is encoded or decoded, the program iterates over the stored data 'model'. In order to support handling exponent and mantissa individually, you have to add special processing rules in encoder as well as in decoder part. The problem with individual matissa and exponent is that each of them can have potentially individual operators and constraints...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/vekonyz/fast-protocol/issues/4?email_source=notifications&email_token=AHWJCP2OF7B2FSHILTJNIYTQIVCRRA5CNFSM4ISVMQVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6FW3DY#issuecomment-529231247, or mute the thread https://github.com/notifications/unsubscribe-auth/AHWJCP7LSYOTAO7SE33X373QIVCRRANCNFSM4ISVMQVA.

[pre-vail]

Hello. Can you clarify your statement or should I just keep learning about FAST?

[vekonyz]

Studying the FAST specification is the right way to become more insights into the protocol. You will find also the definition of the mantissa/exponent handling there.

[pre-vail]

Hello. OK, so I've read up on FAST and its Session Control Protocol. There is still a lot of understanding left for me to do. Hopefully you can help by providing an example of the file that is being read on line 5, and the template from line 7, of samples/decode.js? Can you also provide an example of the file that is being read on line 14, and the template from line 19, of samples/gw/gwlogreader.js?