Project

tella_peer

0.0
No commit activity in last 3 years
No release in over 3 years
tella_peerkiwimanman/tella_peerDocumentationSource CodeBug TrackerWiki
Client for CSEtella P2P network created for UW CSE 552 Spring '13
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
 Popularity
Downloads
3,685
Stars
0
Forks
0
Watchers
2
 Releases
Current version
0.0.1
Total releases
1
First release
2013-06-06
Latest release
2013-06-06
 Development
Primary Language
JavaScript
Licenses
MIT
Average date of last 50 commits
2013-06-04
Reverse Dependencies
0

 Dependencies

Development

bundler
~> 1.3
rake
>= 0
 Project Readme

TellaPeer

Ruby peer client for the CSETella P2P network. CSE 552 Spring 2013 Keith Stone

To run

Requires Ruby 2.0

bundle install
bundle exec thor client:start

Default serves on port 9000 and serves a GUID as the text.

Available options:

  • --reply
    • Text to serve
  • --log_level
    • DEBUG, INFO, WARN, FATAL
  • --ttl
    • Message time to live
  • --public_ip
    • Public IP to communicate over the protocol (Stops auto-find of this value)
  • --port
    • Port to run our server on
  • --local
    • Run the server on localhost

Code structure

  • client.thor
    • Handles reading of command line options and starting the various threads that need to run and starts the server.
  • lib/tella_peer/message.rb
    • Subclass for all messages. Implements the marshalling and unmarshalling of the bits after they cross the wire. There is a implementation of each type of message that implements logic needed by those individual methods to pack and unpack themselves.
  • lib/tella_peer/connection.rb
    • Models a high level wrapper around the actual socket connection. Contains the logic for what to do when receiving various messages as well as how to watch the socket in a threaded way.
  • lib/tella_peer/connections.rb
    • Models the group of connections. Is responsible for keeping track of all currently open connections and to reach out to new potential connections. This class also hold most of the statistics my status page shows including overal message counts, potential connections, and active connections.

I was able to build a pretty solid test base around my own message creation, marshalling and unmarshalling. These were not to hard as they were essentually unit tests and could be stubbed out to test exactly the pieces I was unsure of. What was impossible to test and I think still broken is my interations with peers. Predicting how peers were going to drop or act was not something I could model out 100%. My answer to this was just logging and monitoring. When running log level DEBUG the output is very verbose so as to be able to see and fix issues that my tests missed.

Web server

I have screen caps of my status page in the sinatra_server folder. My NAT is open on 76.104.193.163:4567 but I am running on my laptop so I may not be available during the day as it comes to work with me.