Network related stuff.
Network controller.
Network controller.
The controller starts 3 threads:
Parameters: |
|
---|
Network initialization.
Network initializer.
Initilizer works as following:
Parameters: |
|
---|
Initializer thread.
See also
For constructor parameters check Initializer.
Network components responsible for publishing stock messages.
Channel publishers thread.
Parameters: |
|
---|
Pub-sub proxy thread.
Parameters: |
|
---|
Network components responsible for a single channel parsing/publishing.
Channel publisher.
Parses a single channel and publishes StockMessage messages.
Parameters: |
|
---|
Channel publisher thread.
Stock messages generator from the channel.
Parameters: |
|
---|
Factories for stock messages.
These factories take messages from oxberrypis.parsing.messages and turn them into instances of proto.stock_pb2.StockMessage.
Factory for add order stock message.
Factory for delete order stock message.
Factory for execution order stock message.
Generic factory for stock message.
Factory for modify order stock message.
Network communcation happening at Raspberry Pi.
Raspberry Pi stock messages subscriber/handler.
Stock messages subscriber.
Parameters: |
|
---|
Handlers for stock data.
Simple printing handler.
Prints stock message to the console on arrival.
Stock messages handler that Sends stock evnets to visualisation.
Parameters: |
|
---|
Stock messages handler for updating matching engines.
Parameters: | matching_engines (list of MatchingEngine) – Mapping stock_index -> matching_engine. |
---|
Reusable network components.
Publisher-Subscriber proxy.
Based on:
Synchronized publisher.
This publisher and SynchronizedSubscriber are generally based on http://zguide.zeromq.org/py:all#Node-Coordination. However docs notes that:
We can’t assume that the SUB connect will be finished by the time the REQ/REP dialog is complete. There are no guarantees that outbound connects will finish in any order whatsoever, if you’re using any transport except inproc. So, the example does a brute force sleep of one second between subscribing, and sending the REQ/REP synchronization.
A more robust model could be:
- Publisher opens PUB socket and starts sending “Hello” messages (not data).
- Subscribers connect SUB socket and when they receive a Hello message they tell the publisher via a REQ/REP socket pair.
- When the publisher has had all the necessary confirmations, it starts to send real data.
Therefore we implement above mentioned “more robust model”, basin on http://thisthread.blogspot.co.uk/2012/03/pub-sub-coordination-by-req-rep.html.
Parameters: |
|
---|
Perform handshake with subscriber if available.
This function checks for subscribers synchronization on the REP socket.
Parameters: | sub_id – Subscriber-to-be id. |
---|
Broadcast a ping message.
A “ping” message is sent on the PUB socket to show the subscribers that the publisher is up and waiting for them.
Sends PING_MSG.
Send enveloped data to subscribers.
Based on http://zguide.zeromq.org/py:all#Pub-Sub-Message-Envelopes
Synchronized subscriber.
See also
Check SynchronizedPublisher for implementation details.
Parameters: |
|
---|
Receive messages and proccess them using msg_handler in a loop.
Stops when SynchronizedPublisher.END_MSG is received.
Receive mulitpart messages and process them using msg_handler in a loop.
Stops when SynchronizedPublisher.END_MSG is received.
To be used with pub-sub message envelopes; based on http://zguide.zeromq.org/py:all#Pub-Sub-Message-Envelopes