[erlang-questions] Erlang and FIX protocol

[Max Lapshin]

On Thu, May 3, 2012 at 6:31 PM, Per Melin <per.melin@REDACTED> wrote:
>
> The problem with the syntax is that it is simplistic. It does not even give you enough information to be able to tokenize a message or to find message boundaries. See binary fields below.
>

It is not exactly so. Standard tells that whole packet must start from
field 8 with proto version and next field must be byte length without
checksum. So this is a good way to detect real byte length.

>
> It has been a few years since I last looked at FIX so I apologize if anything below is incorrect.
>
> When I run test cases that is suppose to fail on your code I mostly get {more, N} back, often {more, 0}. If I remember correctly, one pain of FIX is that when your code finds an error in what it received

But you must first recevie whole message before saying that it is broken.
However, {more, 0} is a problem.


> You are not verifying the message checksum, which in the end is not as straight forward as it may first seem.

What is bad with it?


>
> Your code works on the assumption that SOH (ASCII 01) can be used as a field separator in all contexts, right? That is not true, since it can also be part of a binary field. For example:

Yes, I haven't parsed data fields yet. But I know how to add this if I need =)

In fact a good test suite will really help.


>
> 1> fix:decode(<<"8=FIX.4.4",1,"9=23",1,"35=0",1,"93=10",1,"89=A",1,"89=234",1,"10=999",1>>).
> {ok,{heartbeat,undefined,undefined,undefined,undefined,
>               undefined,
>               [{signature_length,10},
>                {signature,<<"A">>},
>                {signature,<<"234">>}]},
>    <<>>}
>
> This is incorrect, as far as I can remember. The actual value of the signature is "A|89=234|1" here, not ["A", "234"] (not to mention that your signature length does not match the content). Field tag 89 (signature) is of type data, so you must look at tag 93 (signature_length) to know where the value ends. Because of binary fields I don't see how you can split or tokenize a message first and then parse it in the way you've done.
>

I understand you. But this can really be fixed.