fix: Fix buffer_find() for empty buffers

Marat explains:

  Consider the case: the buffer contains just

  8=FIX4.4\x01

  Then in first_three_fields() we successfully pass the function
  parse_begin_string() and reach the buffer's end.  Then the function
  parse_body_length() starts parsing the field which makes buffer_find()
  perform a "conditional jump or move depends on uninitialised value(s)".

  As far as I can understand the circumstances are rather rare
  to reproduce easily but not rare enough to be caught by Valgrind.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FIX: Introduce an explicit state of the message being parsed

When the FIX message that is stored in a buffer is being unparse
we should distinguish between two major cases: the message is
garbled and we should skip it when parsing the buffer's content
and the message is just partially delivered and we should wait
until it will be delivered completely.

Until now there was no reliable way to distinguish between these
two cases. The only thing we knew for sure is that if buffer's
size was greater than the maximum possible FIX message size we
shouldn't wait more data to come once we found out that some
part of the buffer contains a garbled field.

This patch suggests that we should explicitly track the FIX
message state while it is being parsed, namely every function
examining the incoming buffer's data explicitly returns the
value associated with the FIX message state.

For example, if the buffer's data are '8=FIX4.4\x019=-1\x01' we
know for sure that body length is corrupted because of the negative
value so we could skip this part of the message. But if the buffer's
data are '8=FIX4.4\x019=1' we should wait the next set of bytes
because the only thing we know is that body length begins with '1'.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: Introduction

Two minor changes were made:
* Remove buffer_put(). This functions  is a part of transferring patch.
Not needed in decoding FAST messages.
* Remove FAST_FIELD_SET_STATE macro. This macro remains from previous
versions. At the moment fast messages do not have their states (undefined,
assigned or empty) because is_none field is enough to handle different states.

This patch implements a generic function to decode the incoming data.
In order to support FAST to the full extent a few additional steps
have to be done. At this moment these steps include the following
points:

* Reset support
* Encoding support
* Sequences / Groups support
* Decimal and Unicode support
* Delta operation for strings

Moreover, it would be nice to have a pair of test client and server
as the other part of libtrading have.

This patch is a skeleton and once it is admitted the other steps
should be based on it.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
[ penberg@kernel.org: cleanups ]
Signed-off-by: Pekka Enberg <penberg@kernel.org>
README update

FAST protocol is included

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: Transferring Engine

This patch implements FAST transferring engine.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: Explicit dictionary states are introduced

Until now is_none was the proxy of a dictionary state.  While it was
suitable in the most of the cases it was not FAST Specification's exact
replica. For the purpose of being as close to the FAST Spec as possible
we are switching to three dictionary states: undefined, assigned and
empty. This should also make the code clearer for a side reader.

Essentially, the patch just uses the state variable which can be of
three values instead of is_none variable which could be of two values
only.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: Decimal support introduced

Individual operators for exponent and mantissa have not
been supported so far. This is to be implemented once
such necessity arises in practice.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
[ penberg@kernel.org: kill 'decimal' typedef ]
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: Increase optional values by 1 if no operator is applied

Optional values (NULL-able values) should be amended before
transferring. It was done for all cases except one by some
accident. The patch fixes this case.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: Do not set previous value to empty if delta operator is applied

FAST Spec says that in case of delta operator for optional integers
and decimals the previous value is not set to empty but is left
untouched if the value is absent

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: Testing suite

This commit introduces a new FAST-related testing suite. The main
idea is to test FAST functionality against the predetermined set
of test cases. Each test case contains of a number of FAST messages
involving two parties: a FAST server and a FAST client respectively.
Each message must be handled in accordance to FAST specification
and any deviation from the expected behavior is to be considered
as a violence to specification and points to the libtrading
implementation error.

Below are details to current FAST testing suite realization:
* Each test case involves two counterparts: the server and the client
* Server is an active side. Client is a passive one. That is to say
the server sends to the client a number of predetermined messages
which are handled by the client in accordance to FAST specification
* Each test case should have its own file
* Each test case file serves for both template and messages specification
* Each test case file specifies no more than one template
* Here are the template specification rules:
 - The first line specifies the number of fields within subsequent
 FAST messages
 - For each field there is a line which specifies the field's every
 parameter: type, presence, operator, pmap bit and reset value
 - Consider a template specification example:
	1
	int,mandatory,none,0,1
 Which defines a message with a single mandatory field of type 'int'
 that has no operator associated and the reset value set to 1 (such a
 field does not have pmap bit associated - so 0 is set). If there is
 no a reset value - 'none' are to be used.
* Once template is defined, FAST messages have to be specified.
Each message is a single line with a set of values separated with
delimiters. If an optional field has no value 'none' should be
indicated.

Consider an example of a test case file:
1
int,mandatory,none,0,1
1
2
3

This test case file will result in the following messages flow:
* Server will send three subsequent FAST messages each containing
a single field of integer type.
* This field will be equal to 1 in the first FAST message, 2 in the
second and 3 in the third.
* The client will receive data from the server and compare them
with the expected values. In case of any errors it will exit abnormally.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
A sample FAST test case is included

Run a sample FAST test case under the Makefile's 'check' target.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Update copyright and credits

Signed-off-by: Pekka Enberg <penberg@kernel.org>
Update README

Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: Do not use states explicitly outside the library

An application which is using libtrading FAST functionality
must not use FAST states explicitly. Moreover, essentially
it should not know about states at all because they are
implementation details which are to be hidden from others.

Instead, every application should use interface provided by
the library. For example, before sending or receiving a
message it should be initialized by fast_message_init().
If a FAST server would not like to transfer an optional
field, it should use field_set_empty() to let the library
know that a particular field is not present in an outcoming
message.

To achieve the aforementioned goal the patch slightly modifies
the testing suite implementation internals. Messages that are
to be sent/received are stored in a container with reference
numbers starting from 1. Zero element is used to store a "pure"
message i.e. a message which is based on a particular template
and which is initialized via fast_message_init. We need such a
message to correctly bind a template with an open fast session.
These manipulations are essential for delta operator.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: Fix delta operator problems while receiving a message

The patch was originally created to fix two problems while
a message is being received (Delta operator only):

a) For all numeric data types the delta which is being
transfered is always of type Signed Integer but fast_decode_uint()
now assumes it being Unsigned Integer which obviously lead to bad
consequences

b) It is possible to receive an optional field with delta operator
applied with absent value. In such a case FAST_STATE_EMPTY should
be set. Our code do not allow such a possibility at the moment.
The patch should fix this flaw.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: Fix delta operator problems while transferring a message

The patch was originally created to fix two problems while
a message is being transfered (Delta operator only):

a) For all numeric data types the delta which is being
transfered is always of type Signed Integer but fast_encode_uint()
now assumes it being Unsigned Integer which obviously lead to bad
consequences. Fix a function in a way to transfer Signed Integer
if a particular field has Delta operator applied.

b) Delta Operator assumes that delta is always present in a stream.
This means that Delta Operator encoding should always end with
transfer being made. Encoding functions must not return until
something is pushed into the stream. Fix all encoding functions.

Moreover, this patch slightly adjusts the code to make it easier
to read. The idea is that optional and mandatory fields are
handled in a similar way while being encoded except for a few
optional-specific cases. So the code is amended in a way to
get rid of undesirable 'if'-branches i.e. to arrange it in a
plain manner.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: clean encoding functions' code

The message that is in an undefined state (before anything
is transferred) must move to another state once the first
message goes out (either to assigned or empty states). It
must not leave in an undefined state.

This patch slightly adjusts the code to make it easier to read.
The idea is that optional and mandatory fields are handled in a
similar way while being encoded except for a few optional-specific
cases. So the code is amended in a way to get rid of undesirable
'if'-branches i.e. to arrange it in a plain manner

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: For each operator a new test case file is added

For each possible operator a new test case is added.
So, there are files for the followings operators:
None, Copy, Increment, Delta, Constant. Each file
contains fields of all supported types i.e. integer,
unsigned integer, decimal and string and of all
possible presence values i.e. mandatory and optional.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Add FAST client and server binaries to gitignore

Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: Introduce XML templates

It's quite usual to distribute FAST templates as an XML files. It's a
good idea to support them in a library.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>