README

PROJECT 3 PART 1

THIS PROJECT DONE BY:
--James Eriksen
--Alan Thompson

NOTE: we had another group member, Kevin Song, who never got in touch with us
	to do this project. This project was 100% done by us two.

OUR CODE:
	1) initialization
	2) parse the config file
	3) find out your neighbors
	4) initialize your cost and routing tables. They will start with how to get to your
		neighbors and the cost associated with that
	5) make a thread that will write to the path specified in the config file.
	6) start up the sockets that will listen for new information (new thread for each one)
		NOTE: There are 2 sockets for each neighboring link: One that listens, and when
				necessary one that connects to the neighbor.
	7) sleep(30). We apologize, but this is necessary because the run tool in CORE was
			unreliable for us. This sleep(30) allows the user to manually start the program
			on each node, so that each node is listening for connections before any attempts
			at connecting are made.
	8) send to each of your neighbors your initial cost table.
	9) BEGINNING OF INFINITE LOOP
	10) check to see if your neighbors have sent you any new information
		10a) first, we check to see if that neighbor is telling you to dump (more on that later)
				if you are being instructed to dump, then you do step 4 again before going on to
				step 11.
		10b) then, you check if that neighbor has sent you a new table. If they did, you check to
				see if you needed to update your table with the info they gave you
	11) Find out if your neighbors need to be given your table
		11a) first, we check if you dumped. If you did, your neighbors need to dump as well
		11b) then, we check if you updated your table. If you did, your neighbors need to see
				your updated information to see if they can get somewhere faster through you
	12) sleep(routing_update_interval). This makes it so tables are updated according to the time
			given in the config file.
	13) Check to see if we need to dump.
		13a) The dump condition is whether the links between your neighbors have been
				changed since you started making your tables. If they have, then your
				tables need to be destroyed (hence, dumped) and started from scratch, as
				no weight information is reliable anymore.
		13b) If we did dump here, then we need to remake our tables by repeating step 4
	14) END OF INFINITE LOOP: GO BACK TO STEP 9

A note on our 'server' sockets: They take a message and parse it to see if the data
	contained within is important. Right now, the only control messages we accept
	'CIRCUIT' (for being given a table to help build the circuit) and 'DESTROY' (for when
	we need to dump what we have in the trash and start over). In the future, they will
	handle other control messages.

HOW TO RUN:
The files necessary to run this project are as follows (and should be included in our
	.zip file):
--node.rb
--A config file with data formatted as detailed below
--A nodes-to-addrs file
--An addrs-to-links file
--gen_weights.rb

We have been running our code by intializing the proper CORE configuration (utilizing the
	given 417-s1.imn), then running gen_weights in a terminal window behind the scenes,
	then running our code on each node as 'ruby <path to node.rb> <path to config_file>'
	(without the quotes of course). We have been running them manually instead of using
	the Run tool because of inconsistency with the tool. We apologize for the inconvenience,
	but hope you will bear with us.

We have provided a shell script, as per the prompt. However, all it does is run
	'ruby /home/core/project3/node.rb /home/core/project3/config_file'. If this does
	not work for you, running it as we do in the previous step should be satisfactory.

The config file needs to be properly configured. It consists of these lines:
max_packet_size
nta_file_location
atl_file_location
weights_location
routing_update_interval
routing_table_dump_path
dump_interval

Which are defined as below:
max_packet_size: this is the max size of the message sockets can send to each other.
	We recommend a large size, as cost tables need to be sent in these messages.
nta_file_location: the location of the nodes-to-addrs.txt file. Does not need to be called
	nodes-to-addrs.txt.
atl_file_location: the location of the addrs-to-links.txt file. Does not need to be called
	addrs-to-links.txt.
weights_location: the location of the weights file that gen_weights.rb is filling
routing_update_interval: the amount of time between updates of the routing tables
routing_table_dump_path: the directory that the program will make a file containing the
	routing table for this node at that time.
	NOTE: each node is going to have its own file, and that file's name will be the hostname
		i.e. node n1 will have a file named n1 that will hold the latest routing table.
dump_interval: the amount of time between the writing of routing tables into a file

An example config file is provided, and can be modified to suit the user's needs.


Any questions with the running of this program can be asked via email, to:
--James Eriksen: jimbo_1993@msn.com
--Alan Thompson: athomps2@terpmail.umd.edu