= DistribuStream
Welcome to DistribuStream! (https://distribustream.org)
DistribuStream is a fully open peercasting system which allows on-demand
or live streaming media to be delivered at a fraction of the normal cost. 
== Usage
The DistribuStream gem includes three config files that can be located in
the conf directory of the gem:
* example.yml  - A standard example file, configuring for 5kB chunks
* debug.yml    - Same as example.yml, but configured for additional debug info
* bigchunk.yml - An example config file, using 250kB chunks
Chunk size controls how large the segments which are exchanged between peers
are.  Larger chunk sizes reduce the amount of control traffic the server
sends, but increase the probability of errors.
To begin, copy one of these config file and edit it to your choosing.  Be
sure to set the host address to bind to and optionally the vhost you wish
to identify as.
Next, start the DistribuStream server:
  dstream --conf myconfig.yml
You can think of the DistribuStream server like a regular web or FTP server.
It looks through the specified directory and makes the files underneath it
available to the peer-to-peer network.
You can see what's going on through the web interface, which runs one port
above the port you configured the server to listen on.  If the server is
listening on the default port of 6086, you can reach the web interface at:
  https://myserver.url:6087/status/
To test your server, use the DistribuStream client:
  dsclient pdtp://myserver.url/file.ext
This will download file.ext from your DistribuStream server.
The client also supports non-seekable output such as pipes.  To play streaming 
media as it downloads, you can:
  dsclient -o pdtp://myserver.url/file.ext | mediaplayer -
== Roadmap
Short-term goals focus on improving the efficiency of peer-to-peer traffic
routing, by incorporating all of the following constraints:
1. Does the potential "giver" peer have chunks the "taker" peer is requesting?
2. Are the peers in the same prefix? (at least the same /16, if not the same /24)
3. Are the peers firewalled? (the server could do a connect test as soon as a 
   client registers their listen port)
4. What is the trust between peers? (the "random" connecting of untrusted peers 
   could be replaced by something that operates on the above two bits of data)
5. Does the "giver" have enough bandwidth? (modeled over time)
6. Are total inbound and outbound links minimized? (to improve TCP congestion)
Long-term goals include a move to UDP to reduce protocol latency and overhead
as well as encrypting all traffic to ensure privacy and security of the
data being transmitted.