CSC 579 Class Project

This is my project log book for CSC579’s class project. CSC 579 is a peer to peer networking class offered at the University of Victoria. A large portion of this offering of the class was a project that I decided to work on as an individual. This project involved working on a networking topic and creating a final report/presentation.

I choose to work on a gossip protocol that would allow multiple, independent blockchains to communicate. This work will support my MSc research and is a contribution to that work

A link to my final report can be found below.

Thanks,

Joe

Project Report

Hello all:

Here is a link to my project report: https://drive.google.com/file/d/1CPFD3WFOvEWLs6joRQ3aTF73c-lMQqW9/view?usp=sharing

Thanks,

Joe

Project Demo

Hi all –

Here is a link to my project Demo video. Please let me know if you have any questions 🙂

https://drive.google.com/file/d/1-Fo2YKHwXIurGgJuE5TNQaGP0cXEn6Ez/view?usp=sharing

Thanks,

Joe

Project update three:

Hello all –

I’ve successfully completed the coding of the gossip protocol – testing it on my localhost and then on a local network the protocol works with four machines.

I have implemented a function that generates placeholder messages (one every minute) and adds them to the sets to share on the network.

I am currently working on the testing phase; I am working on how to create a tests with mininet. This is a change from my original plan – I would like to be able to measure how long it takes for a message to be distributed to each machine in the network and see how this increases as the network size increases.

I am hoping to run tests with 4, 10, 25, and 50 nodes in the network to see how long it takes to synchronies the network. I hope to get this completed this week!

Thanks,

Joe

Hello all –

I just wanted to add an addendum to my update – I have created some code to test my gossip server (a test client) and am able to synchronize messages between the client and the server.

Some background on the gossip protocol – I am trying to find a way to spread/share data between nodes in a network (that is tolerant of going offline). This gossip protocol is useful to my thesis because it will allow independent blockchains (running at separate hospitals/clinics etc) to be interlinked and allow a summary of the information stored on one chain to be referenced/witnessed by a message stored on another chain.

I chose a gossip protocol to send these messages after reading this paper: https://ieeexplore.ieee.org/abstract/document/8416377

Essentially the gossip protocol keeps track of the current message it has for every node (called a frontier set) in the network. When a node connects to another it is sent this frontier set. This allows the node who received the set to become up to date with the sender’s view of the world (received messages) and allows messages to be spread quickly…

An explanation/crude demonstration of my code is available here: https://drive.google.com/file/d/1ZJ85WAFsh88ZiAQy6R7U–GDjhW-7cmv/view?usp=sharing

I’ve still got plenty to do but am trying to make headway now that I am no longer sick 🙂

I hope my explanations are brief but make sense – if not I will try to answer questions and will be more thorough in my RS4.

Thanks for being patient through the long update,

Joe

Midterm update:

I have created a list of priorities for the gossip protocol and have worked on creating the required supporting classes for the protocol. I was intending to work on the concurrency problems this past week; however, I was sick and fell behind. I also failed to take our midterm into account for my scheduling. I have a living document of requirements (notes) to help me when implementing the protocol. The final copy will be included in the report but an export of the current status will also be attached here. Reading about protocols in a paper is much different from actually implementing them – this is a good learning outcome for me from this project.

Over the weekend, I was able to get most of the code written for the gossip server. I intend to finish this and the client code this week.

I would like to make the following updates to my project proposal:

I want to determine how often a node should try to send (as opposed to listening for) connections. A node can not gossip information out and update its information simultaneously because I do not want two threads causing concurrency errors. A mutex will ensure only one thread is accessing the data storage at a time. This may cause other nodes to block and take more time. Is there an amount of time a node should wait between connections out (ie to make sure other nodes can connect to it without blocking)? Also, is this waiting time impacted by the number of nodes in the network and how much information a node produces?
I still intend for the testing of the protocol to be small. The goal of my thesis and this project is to create a proof of concept system and thus the testing for this algorithm will be created accordingly. This could be easily expanded later. This proof of concept may involve a gossip network running locally and communicating with one other server on the internet (as opposed to the full internet impacts mentioned in the project proposal). The question above, about how often a node should try to send, as opposed to receiving data, is more fundamental and important at this point.

I hope to have the code files completed and tested by the end of this week. As Professor Pan mentioned, he likes being able to see things, I hope to be able to post a demonstration of the protocol running (with simple messages) this week.

I would like to remind everyone that I do not intend to have a fully functioning system at the end of this. I will just be having the gossip protocol (that can interface to a blockchain with an API). I have created a python storage class that allows me to easily test the protocol. This class has similar operations to the API that would be created by hyper ledger firefly.

Here is a more up-to-date, weekly schedule for the end of the project:

Week	Deliverables/Goals
Week of November 7th	Code finished; Protocol testing procedure started
Week of November 14th	Protocol testing completed
Week of November 21st	Start presentation and report. Finish testing if required
Week of November 28th	Project Demo
Week of December 5th	Project Demo submitted; Report Drafted
December 12th	Project Report Submitted
December 19th	Project Website/Logbook completed.

I intend to be more thorough in my updates as our midterm is now out of the way.

Thanks,

Joe 🙂

This page will be the page that I will update, as per the project requirements, for my course project for CSC579. This class is a networking class that is focusing on peer-to-peer networking ideas. For the class project each person has to select a topic, to do with computer networks, that they will do a research project on.

My idea is outlined in my project proposal.