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>
FAST: Sequence support introduced

The patch implements FAST Sequences' support.
The following features are valid:
* Sequence decoding engine
* Sequence xml parse engine
* Sequence message's formatted output

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: function to reset a message is added

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: Save a template id of the last parsed message

If a FAST message being parsed does not contain an explicit
template id declaration the previous one should be used.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: fill rx buffer with data once it is empty

Here is the way we parse incoming FAST messages now.
We are decoding the message field by field and if
the buffer is empty at some moment we actually perform
three steps: a) we move buffer's start pointer to the
beginning of the FAST message b) we fill buffer with
data and c) we try to parse the message again
starting from the very first field. This approach is
erroneous because once a particular field is parsed
it might change its value or state. The FAST parsing
result depends both on the incoming data and the
field's current state. Once the state is changed
the parsing result altered also which could lead to
incorrectly parsed message.

To cope with such a problem a modified approach is
proposed. If a particular field is unable to be
parsed we do not wait until we have another chance
to do that. Instead we try to fill the buffer with
data immediately.

A few additional moments are worth to be mentioned:
a) rx buffer's size must be at least 2 * FAST_MESSAGE_MAX_SIZE
b) If you take a look at data_read() code you might notice that
we are reading FAST_MESSAGE_MAX_SIZE from the socket no matter
how many bytes we actually need. This is done on purpose.
The fact is that a lot of FAST messages are distributed via
UDP datagrams which makes us impossible read a part of
the datagram without losing the remaining part. So, actually
we need to read not a FAST_MESSAGE_MAX_SIZE but the maximum
datagram size. Please, let me know if you have an idea how
to workaround it smoothly.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: a testing interpreter application is added

A testing application is added. It just joins a UDP multicast group,
gets the incoming FAST messages, parses them and printing out the parsed
result.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Merge branch 'marat'
FAST: Add parser to gitignore

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: message's and field's flags introduced

Flags are useful to store auxiliary information

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

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: skip sequence pmap decoding if necessary

If none of the sequence's fields requires PMAP
bit then PMAP is not transferred. Hence, it should
not be decoded.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: an optional sequence means that the length field is optional

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: Reset message is marked explicitly

The message is called 'Reset message' when its xml
definition has an attribute 'reset' set to 'T' value
i.e. 'reset="T"'. Such messages have flags bit raised
explicitly.

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