My favorites | Sign in
Project Home Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
Implementation  
This page will contain the project implementation details.
Updated Apr 4, 2013 by Arkin...@gmail.com

T-Man Live-Streaming TCS Implementation

I. Table of Terms

Term Meaning
Component Reactive state machines that execute concurrently and communicate by passing events through ports connected by channels
Port They are bi-direction component interfaces and act as filters for passing messages
Channel Channels are bindings between component ports
Event Events are data objects that are passed from one component to the other
Handlers A handler, as it name implies, handles a particular type of event received by the component and executes reactively
Subscription Binding of an event handler to a particular port

1. Introduction

This wiki entry will comprise all the implementation details of our project. We'll first start by describing our simulation framework, defining our component architecture and then listing all the main events and their corresponding handlers. Lastly, we'll use sequence diagrams to describe the general flow of our main processes.

2. Simulation Framework

For our project, we utilized the Kompics component model . The kompics framework facilitates building and simulating distributed systems by allowing us to create components (that execute concurrently) and have them launch and receive events.

For more information, please refer to Kompics' official website http://kompics.sics.se for samplers and tutorials.

3. Component Architecture


Due to the frequency of changes and the ongoing code restructuring of our project, this section is still under development.


4. Events

In this section, we'll describe the main types of events that are used throughout our simulations. The diagram shown below contains the types of events that are initiated by our main architectural components (as described in section 2.0 of the design wiki entry).

These events are used to perform a wide array of functionality for our distributed system. A description of each event's purpose is provided in the table below:

Event Description
Cyclon Join Initiated by the simulator to allow peer to join the cyclon network and acquire its attributes
Cyclon Initiation The initiation event triggers a schedule event to the timer
Initiate Shuffle Triggered by the timer at every cycle to start the peer's active thread
Shuffle Request Peer initiates this event to request another peer's cyclon buffer (while sending its own)
Shuffle Response Initiated by peer that receives a request, in order to send its buffer to the requester
Partners Request Initiated by a T-Man peer to receive its own cyclon partners from the cyclon component
Partners Response Response to a Partners request event
T-Man Initiation Triggers a schedule event to the timer
T-Man Schedule This event is trigger by the timer to start the peer's active thread
Exchange Request Peer initiates this event to request another peer's T-Man buffer (while sending its own in the process)
Exchange Response Response to an exchange request
Acquire Child Sent to a peer to request the initiation of an inbound connection
Child Response Send by the prospective child to either accept or deny the request
Update Self Sent to a parent or a child to update the requester's descriptor in their views
Orphan Self Sent by a child to gracefully disconnect from a parent
Orphan Child Sent by a parent to gracefully disconnect from a child

5. Flow

In this section, we'll describe the main processes that occur throughout the simulation. We'll try to summarily describe them using sequence diagrams.

5.1. Simulation Initiation Process

This process comprises the flow of the simulation from when it's initiated by the user, to the resultant T-Man & Cyclon interactions that take place henceforth. It's important to point out that the Cyclon shuffles and T-Man exchanges occur concurrently after the T-Man component is initiated.

Also, after a peer receives an exchange request, the handler merges the sender's buffer along with the peer's current T-Man & Cyclon buffers. The resultant view is then sorted according to our ranking function (defined in section 3.3.2 of the design wiki entry). The highest n (where n is the T-Man view size) peer descriptors are then extracted from the list and placed in the peer's T-Man buffer.

5.2. Child/Parent Interactions

This processes includes all possible interaction scenarios between children, parents and prospective children. The sequence diagram below shows these interactions.

Please note that a child accepts or rejects a parent based on three factors:

  1. The acquirer's bandwidth.
  2. The acquirer's path-length (or hop-count) to the source node.
  3. The child's total number of parents compared to its maximum allowable in-bound connections.

If the acquiring node has a lower bandwidth or a less than or equal hop-count to the child's, then it's instantly rejected. Whilst if the child has already reached its maximum number of in-bound connections, it will start search through its current parents, to see if any of them is expendable. If the acquiring node's bandwidth or hop-count is less than that of one of the child's current parents, it accepts the request and sends an "Orphan Self" event to the expendable parent to remove it.

Powered by Google Project Hosting