conflict resolve

atelier/src/data/README.md

@@ -0,0 +1,2 @@
+# Data Module
+

atelier/src/data/admin.rs

@@ -0,0 +1,9 @@
+/// Admin types and implementations
+
+#[derive(Debug, Clone, PartialEq, PartialOrd)]
+pub struct User {
+    pub first_name: String,
+    pub last_name: String,
+    pub email: String,
+}
+

atelier/src/data/hasher.rs

@@ -0,0 +1,23 @@
+/// Hashing generating functions
+///
+/// in order to create order_id, and, user_id hashed values with 
+/// unicity and atomicity operative properties.
+
+use crate::data::market::Order;
+use std::hash::{DefaultHasher, Hash, Hasher};
+use crate::data::admin;
+
+impl Hash for admin::User {
+    fn hash<H: Hasher>(&self, state: &mut H) {
+        self.first_name.hash(state);
+        self.last_name.hash(state);
+        self.email.hash(state);
+    }
+}
+
+fn hash_user(user: &admin::User) -> u64 {
+    let mut hasher = DefaultHasher::new();
+    user.hash(&mut hasher);
+    hasher.finish()
+}
+

atelier/src/data/mod.rs

@@ -1 +1,9 @@
+/// Administrative types like users, symbols, etc.
+pub mod admin;
+
+/// Market related types, like Order, Level, Orderbook.
 pub mod market;
+
+/// Hashing types and functions.
+pub mod hasher;
+

atelier/src/engine/README.md

@@ -1,14 +1,30 @@
 # Engine Module
 
-Is the one in charge from the definition of communication and processing channels, to the creation and management of the queues, the routers for async order management to the logic of the matching engine. It is comprehended by the following:
+Within this module exists the definition of the validation processes for income events, routers for async order management, the logic of the matching engine. This module is organized in the following files:
 
-1. `channels.rs`: Communication and Processing channels.
-2. `queues.rs`: Order Queues.
-3. `management.rs`: Order Management Interface.
-4. `routers.rs`: Order Routing Algorithms.
-5. `matching.rs`: Matching Engine.
+1. `validation.rs`:
+2. `routing.rs`: Order Routing Algorithms.
+3. `matching.rs`: Matching Engine.
 
-## Communication and Processing Channels `channels.rs`
+## System Design Taxonomy
+
+Concurrent Publisher/Subscriber Pattern that uses unbounded and multi-producer/multi-consumer channels, with atomic events as messages, A routing algorithm to gather and inject the event's data into an execution queue to be consumed by an execution engine that ultimately alters the state represented in the Limit Order Book data structure. 
+
+## General Description
+
+- Inbound Events Pipeline (connectors, channels, producers):
+
+An External Data Source produces data, then a connector acting as the Internal API endpoint fetches that data, either through a querie using a REST connector, or through a received data package using a WebSocket connector. Then data goes through a validation/pre-processing layer (to make it compliant with the event-message schema). After validation, data is pre-processed for compliance with the event-message schema and passed into a `Publisher` so it can publish the event into the corresponding channel. 
+
+- Internal Routing:
+
+Since there are different channels to take events from, an Order Routing Strategy will decide the order of the channels and the amount of events to be extracted from each of them, to then be sent to the Global Executable Tasks Queue.
+
+- Execution:
+
+From the Executable Tasks Queue, it will consume tasks acording to the Execution Strategy, and if successfully executed, it will effectively change the state of the Order Book.
+
+## Communication Channels `channels.rs`
 
 *(pending)*
 

atelier/src/engine/mod.rs

@@ -1,14 +1,8 @@
-/// Communication and Processing Channels
-pub mod channels;
-
-/// Queues for the order management
-pub mod queues;
-
-/// Order Management Interface
-pub mod management;
+/// Routers for the order flow
+pub mod validation;
 
 /// Routers for the order flow
-pub mod routers;
+pub mod routing;
 
 /// Matching engine logic
 pub mod matching;

atelier/src/events/README.md

@@ -1,28 +1,98 @@
-# Events
+# Events Module
 
-The current version supports 4 types of Market Events, as specified in the `MarketEventType` enum: 
+## Folder structure
+
+```
+Events/ 
+├── channels.rs
+├── mod.rs
+├── publishers.rs
+├── subscribers.rs
+└── templates.rs
+```
+
+1. `channels.rs`: Where events are published to, and/or, subscribed from.
+2. `publishers.rs`: The publishers of the events.
+3. `subscribers.rs` The subscribers of the events.
+4. `templates.rs`: Definition of templates for the events and other uses.
+
+## Market Event Types
+
+These are defined within the `src/events/templates.rs` script, as variants of the `MarketEventType` enum, which is being created dynamically with a macro:
 
 1. `CancelLimitOrder`: To cancel a single and specified limit order.
 2. `NewMarketOrder`: To create a single new market order.
-3. `ModifyLimitOrder`: To modify a single and identified limit order (only the amount).
+3. `ModifyLimitOrder`: To modify only the amount for a single and id-identified, limit order.
 4. `NewLimitOrder`: To create a single new limit order.
 
-Each of the events has a generation `random_<MarketEventType>_template` process that serves as a pseudo-random 
-generator of instances of events for testing purposes.
+## Market Event
+
+### Main structure
+
+The struct that is being carried as the container of the actual market event, defined in `src/events/templates.rs`, it has the 
+following structure: 
+
+```
+MarketEvent { 
+    event_info: EventInfo,
+    event_content: EventContent,
+}
+```
+### Event's information (kind of a meta-data) type structure
+
+```
+EventInfo {
+    event_received_ts,
+    event_type,
+    user_Id,
+}
+```
+
+### Event's content type symbolic structure
+
+```
+EventContent {
+    OrderCreation,
+    OrderCancelation,
+    OrderModification,
+}
+```
+
+The necessary contents to be included in the `EventContent` given each of the `MarketEventType` are defined like this:
+
+| EventInfo::event_type              | EventContent::event_object     | 
+|------------------------------------|--------------------------------|
+| MarketEventType::CancelLimitOrder  | order_id                       |
+| MarketEventType::NewMarketOrder    | market::Order                  |
+| MarketEventType::ModifyLimitOrder  | order_id, order_amount         |
+| MarketEventType::NewLimitOrder     | market::Order
+
+With both the `order_id` and `order_amount` being the same type as the one in the `market::Order` struct.
+
+
+# Channels
+
+Within the `src/engine/channels.rs`, for each `MarketEventType`, there will be one particular channel:
+
+1. A `CancelLimitOrder` event goes into the `cancel_lo_channel`.
+2. A NewMarketOrder event goes into the `new_mo_channel`.
+3. A `ModifyLimitOrder` event goes into the `modify_lo_channel`.
+4. A `NewLimitOrder` event goes into the `new_lo_channel`.
+
+Each channel will be unbounded and supports multiple-producers/multiple-consumers logic.
+
+# Publishers
 
-For each type of the above market events, there will be one channel:
+A market participant (exchange client) is the publisher of the MarketEvents, this interaction will be represented by the
+pseudo-random generation of such `MarketEvents` by a collection of `generator` instances. Any of these can generate MarketEvents 
+of any type, and thus, to publish in any of the corresponding channel.
 
-1. A `CancelLimitOrder` event goes into the `cancel_lo_channel`
-2. A NewMarketOrder event goes into the `new_mo_channel`
-3. A `ModifyLimitOrder` event goes into the `modify_lo_channel`
-4. A `NewLimitOrder` event goes into the `new_lo_channel`
+There can be more than 1 `Publisher` at/during any given point/period of time.
 
-There is an `event_stream` process that can produce any number of random instances for one or all of the 
-different market events (as specified by `event_template`), to then use the stream for for testing purposes
-of one or all of the created `channel` instances.
+# Subscribers
 
-Each channel will be unbounded, and also will support.
-
-- Multiple producers: Can receive multiple market events (of the same type).
-- Multi consumers: Can be queried by multiple execution processes (spawned by the matching engine).
+Every `MarketEvent` published by a `Publisher` will pass through an efficient `OrderValidity` process, then will be injected into a channel, 
+from which eventually it will be picked by an instance of an `OrderRouting` process (as a subscriber), which ultimately is in charge of 
+applying the `Routing Algorithm` to send the `MarketEvent` to the `ExecutionQueue` and have the `MatchingEngine` execute it and update 
+the state of the `LimitOrderBook`.
 

atelier/src/engine/channels.rs → atelier/src/events/channels.rs

@@ -1,4 +1,6 @@
-use crate::events::templates::MarketEventType;
+/// Channels
+
+use crate::events::message::MarketEventType;
 use crossbeam::channel::unbounded;
 
 pub fn create_channel() -> (
@@ -10,6 +12,11 @@ pub fn create_channel() -> (
 }
 
 fn main() {
-    let (cancel_lo_queue_s, cancel_lo_queue_r) = create_channel();
-    let (new_mo_queue_s, cancel_mo_queue_r) = create_channel();
+
+    let (cancel_lo_s, cancel_lo_r) = create_channel();
+    let (new_mo_s, new_mo_r) = create_channel();
+    let (modify_lo_s, modify_lo_r) = create_channel();
+    let (new_mo_s, new_mo_r) = create_channel();
+
 }
+

atelier/src/events/message.rs

@@ -0,0 +1,103 @@
+/// Market event generator module
+
+use crate::data::market;
+use crate::generators;
+use crate::messages::errors;
+
+use rand::seq::SliceRandom;
+use rand::thread_rng;
+use std::time::{SystemTime, UNIX_EPOCH};
+
+// ---------------------------------------------------------------------- EventType -- //
+// ---------------------------------------------------------------------- --------- -- //
+
+#[macro_export]
+macro_rules! enum_create {
+    ($enum_name:ident, $($variant:ident),+) => {
+
+        #[derive(Debug, Clone, PartialEq, PartialOrd)]
+
+        pub enum $enum_name {
+            $($variant),+
+        }
+
+        impl $enum_name {
+
+            fn variants() -> Vec<Self> {
+                vec![$(Self::$variant),+]
+            }
+
+            fn random_variants(n_choice:usize) -> Vec<Self> {
+                let mut rng = thread_rng();
+                Self::variants()
+                .choose_multiple(&mut rng, n_choice)
+                .cloned()
+                .collect()
+            }
+        }
+    }
+}
+
+// -- Instantiate a MarketEvent Type Enum -- //
+
+enum_create!(
+    MarketEventType,
+    CancelLimitOrder,
+    NewMarketOrder,
+    ModifyLimitOrder,
+    NewLimitOrder
+);
+
+// ------------------------------------------------------- Market Event Info Struct -- //
+// ------------------------------------------------------- ------------------------ -- //
+
+#[derive(Debug)]
+pub struct EventInfo {
+    pub event_received_ts: u128,
+    pub event_type: MarketEventType,
+    pub user_id: u32,
+}
+
+impl EventInfo {
+    pub fn new(
+        event_received_ts: u128,
+        event_type: MarketEventType,
+        user_id: u32,
+    ) -> Self {
+        EventInfo {
+            event_received_ts,
+            event_type,
+            user_id,
+        }
+    }
+}
+
+// ---------------------------------------------------- Market Event Content Struct -- //
+// ---------------------------------------------------- --------------------------- -- //
+
+// Different market events can have different structures for the event_object. 
+#[derive(Debug)]
+pub enum EventContent {
+    OrderCreation(market::Order),
+    OrderCancellation(u32),
+    OrderModification(u32, f64),
+}
+
+// ------------------------------------------------------------ Market Event Struct -- //
+// ------------------------------------------------------------ ------------------- -- //
+
+#[derive(Debug)]
+pub struct MarketEvent {
+    pub event_info: EventInfo,
+    pub event_content: EventContent,
+}
+
+impl MarketEvent {
+    pub fn new(event_info: EventInfo, event_content: EventContent) -> Self {
+        MarketEvent {
+            event_info,
+            event_content,
+        }
+    }
+}
+

atelier/src/events/mod.rs

@@ -1,2 +1,14 @@
-pub mod streams;
+/// channels where events are published to, and/or, subscribed from 
+pub mod channels;
+
+/// message struct and formation
+pub mod message;
+
+/// publisher of the events.
+pub mod publishers;
+
+/// subscriber of the events.
+pub mod subscribers;
+
+/// Definition of the base templates for the events and other uses.
 pub mod templates;

atelier/src/events/publishers.rs

@@ -0,0 +1,3 @@
+// Publishers
+
+

atelier/src/events/subscribers.rs

@@ -0,0 +1 @@
+// Subscribers