docs/quickstart: Use higher-level headings

Use a level 1 heading as the top-level heading in the Quick Start guide.

Signed-off-by: Jussi Virtanen <jussi.k.virtanen@gmail.com>
docs/quickstart: Tweak Introduction section

Drop the first second level heading as superfluous. Note that the
listing of supported protocols is not actually exhaustive. In the
feature listing, group single thread and non-blocking I/O together.
Fix the name of SystemTap.

Signed-off-by: Jussi Virtanen <jussi.k.virtanen@gmail.com>
Merge pull request #13 from jvirtanen/features/quickstart

Revise Introduction in Quick Start Guide
Make 'omx_itch186_message_size' public

It is useful on its own right.

Signed-off-by: Jussi Virtanen <jussi.k.virtanen@gmail.com>
Fix 'struct omx_itch186_message' name

Rename 'struct omx_itch186_msg_message' to 'struct omx_itch186_message'.
The latter name is already used elsewhere.

Note that this change most likely breaks all applications depending on
Libtrading for Nordic Equity TotalView-ITCH version 1.86.

Signed-off-by: Jussi Virtanen <jussi.k.virtanen@gmail.com>
Merge pull request #20 from jvirtanen/features/omx-itch186-message-size

Make 'omx_itch186_message_size' public
Merge pull request #21 from jvirtanen/fixes/omx-itch186-message

Fix 'struct omx_itch186_message' name
Primitive financial exchange

I would like to introduce a primitive version of financial exchange. This is by
no means intended to be a full-featured exchange (although it may be extended to!)
Therefore, current implementation should not be considered as an individual project
but solely as a part of the library. I can think of several reasons why this should
be included into the project:

* A proof of concept. It may show that libtrading suits for various projects.
* A kind of template. Users may rely on existing implementation once running
  their own projects.
* A testing area. The more library is used, the greater chance we realize what
  feauters are to be implemented and what bugs are to be fixed.
* Performance measurment. Once we have a ready to use exchange simulator we can
  simulate real life activity to measure particular performance statistics.

Current implementation is very basic. It consists of primitive matching engine
which supports limit orders only. Once an order is matched the corresponding
trade details are printed out.

For the sake of simplicity all orders are stored in a linear array. On the one
hand it speeds up particular operations such a order cancellation on the other
hand it causes obvious problems such as maximum number of orders accepted. Active
orders are stored in bidirectional lists. A single list per order book level.

Not so much you can do at the moment but in order to have a try just run a market
and see whether limit orders are processed correctly e.g.

$ ./tools/sim/market -p 7070
Market is running on port 7070...
Buyer 0 Seller 1, price 10, size 50
Buyer 0 Seller 2, price 10, size 50

$ ./tools/sim/trader -h localhost -p 7070
Trader Logged on
Buy/Sell/Quit (1/2/0): 1
Price: 10
Quantity: 100

$ ./tools/sim/trader -h localhost -p 7070
Trader Logged on
Buy/Sell/Quit (1/2/0): 2
Price: 9
Quantity: 50

$ ./tools/sim/trader -h localhost -p 7070
Trader Logged on
Buy/Sell/Quit (1/2/0): 2
Price: 11
Quantity: 100
Buy/Sell/Quit (1/2/0): 2
Price: 8
Quantity: 100

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