{"id":19674284,"url":"https://github.com/andreasmalling/chord","last_synced_at":"2026-05-15T03:35:37.208Z","repository":{"id":73194711,"uuid":"80432825","full_name":"andreasmalling/chord","owner":"andreasmalling","description":"Internet of Things/Peer-Networking","archived":false,"fork":false,"pushed_at":"2017-05-14T19:14:17.000Z","size":176,"stargazers_count":0,"open_issues_count":2,"forks_count":1,"subscribers_count":4,"default_branch":"master","last_synced_at":"2026-02-02T03:54:37.232Z","etag":null,"topics":["chord","internet-of-things","peer-to-peer"],"latest_commit_sha":null,"homepage":"http://kursuskatalog.au.dk/da/course/65737","language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/andreasmalling.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-01-30T15:17:20.000Z","updated_at":"2018-06-24T19:12:37.000Z","dependencies_parsed_at":null,"dependency_job_id":"82947dc6-37ad-4deb-a71c-6f2574ce6fd4","html_url":"https://github.com/andreasmalling/chord","commit_stats":null,"previous_names":[],"tags_count":4,"template":false,"template_full_name":null,"purl":"pkg:github/andreasmalling/chord","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/andreasmalling%2Fchord","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/andreasmalling%2Fchord/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/andreasmalling%2Fchord/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/andreasmalling%2Fchord/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/andreasmalling","download_url":"https://codeload.github.com/andreasmalling/chord/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/andreasmalling%2Fchord/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":33052743,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-13T13:14:54.681Z","status":"online","status_checked_at":"2026-05-15T02:00:06.351Z","response_time":103,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["chord","internet-of-things","peer-to-peer"],"created_at":"2024-11-11T17:17:46.888Z","updated_at":"2026-05-15T03:35:37.203Z","avatar_url":"https://github.com/andreasmalling.png","language":"Java","funding_links":[],"categories":[],"sub_categories":[],"readme":"# IoT / P2P\n- [Milestone 1](#milestone1)\n- [Milestone 2](#milestone2)\n- [Milestone 3](#milestone3)\n- [Milestone 4](#milestone4)\n\n\u003ca name=\"milestone1\"/\u003e\n# Milestone 1\n\nYou must implement the basic Chord-ring. Peers should be able to join the ring, and leave the ring in an orderly manner. You should implement the find_successor function, so that you can locate the peer responsible for a given id.\n\n## Requirements\n\nAll communication between peers should be RESTful. The individual peer should to a Web browser present a simple page, where the peer’s state (such as id, predecessor, and successor (the latter two presented as links to the respective peers)) can be inspected, and where actions, such as searching for an id, can be performed.\n\nYou must document your REST API in a PDF. This PDF must be uploaded to Blackboard, and brought to the milestone meeting.\n\nYou may assume that one Chord peer is initially known and available for bootstrapping purposes.\n\nBonus: Make your system more robust against churn using successor lists.\n\n## Elaboration\n\nThere is *no* centralised component in the system — the initial Chord peer is not different in *any way* from the others, it is merely the first to be launched. Similarly, communication between web browser and peer takes place *directly* and not through any central web server. *All* peers act as small web servers.\n\n## Hints\n\nYou should make the port of a peer configurable, so that you can run many peers on the same machine. This facilitates debugging, and enables you to launching many peers quickly through a script.\n\nIt is *completely* unnecessary for your purpose to use 160 bits long IDs. Use *m* bits, where *m* ≪ 160.\n\nRESTful interfaces can be debugged through browser tools such as [Postman](https://www.getpostman.com/) or command line tools such as [curl](https://curl.haxx.se/).\n\nAny HTTP request [header](https://en.wikipedia.org/wiki/List_of_HTTP_header_fields) features an Accept field, which enables you as developer to ensure that the same request returns, e.g., JSON (when called by a program) or HTML (when called by a browser). Supporting both eases debugging considerably.\n\n\n\n\u003ca name=\"milestone2\"/\u003e\n\n# Milestone 2\n\nHaving implemented the basic Chord-ring, you should now implement finger tables and use them for more efficient routing, as well as successor lists for increased robustness. The finger tables should be inspectable through your web user interface. Peers should build finger tables and successor lists upon joining Chord, and must maintain them over time.\n\nTest your system with and without finger tables with a non-trivial number of peers (e.g., over 50 peers), and compare the number of routing hops necessary.\n\nTry adding and killing nodes to test whether your Chord network adapts accordingly.\n\n## Requirements\n\nAll communication between peers must be RESTful. The individual peer shall to a Web browser present a simple page, where the peer’s state can be inspected, and where actions, such as searching for an id, can be performed.\n\nYou must document your REST API in a PDF. This PDF must be uploaded to Blackboard, and brought to the milestone meeting.\n\nYou may assume that one Chord peer is initially known and available for bootstrapping purposes.\n\n\n\n\u003ca name=\"milestone3\"/\u003e\n\n# Milestone 3\n\nHaving created the Chord-system, your attention should now turn to the Photon. You should build a setup that reports on a physical phenomenon, e.g., temperature, humidity, light levels. It should be accessible through the Particle.io cloud service.\n\nExtend your Chord peers so that you can register your Photon with your Chord system. Use the id of the Photon to associate the Photon with the matching Chord peer. The state of the Photon shall be visible in the UI of the responsible Chord peer. Thus, it should be possible to search for a particular Photon-id, the responsible peer found, and have its state presented.\n\nYou are welcome to add additional data sources to your system.\n\nBonus: Enable the control of some state on the Photon through the Web UI (on the Chord node responsible for that particular Photon), e.g., turning a LED on/off.\n\n## Requirements\n\nAll communication between peers must be RESTful. The individual peer shall to a Web browser present a simple page, where the peer’s state can be inspected, and where actions, such as searching for an id, can be performed.\n\nYou must document your REST API in a PDF. This PDF must be uploaded to Blackboard, and brought to the milestone meeting.\n\nYou may assume that one Chord peer is initially known and available for bootstrapping purposes.\n\nBonus: Have your peers check each other for liveness, and update routing information accordingly.\n\nSee [RESTful Best Practices](http://www.restapitutorial.com/media/RESTful_Best_Practices-v1_1.pdf) for a guide on how to formulate an API in accordance with the REST principles.\n\n\n\n\u003ca name=\"milestone4\"/\u003e\n\n# Milestone 4\n\nWith both Chord and Photon in place, it is time to ensure robust persistence of collected data. Your current design has one Chord peer responsible for the Photon's state, but what if that peer is lost? Or, a better matching peer joins the Chord network?\n\nYou must extend your Chord peers so that they save the data generated by the Photon they are responsible for. You are welcome to use a third-party library for persistence, e.g., SQLite or CouchDB. Extend your peers, so that all saved data can be displayed at the responsible peer.\n\nPersistence at one peer is not sufficiently safe—extend your peers to replicate data to *k* ( *k* \u003c 1) successors, so that the failure of one peer does not lead to data loss. You should also consider that data collection and replication must continue even if the originally responsible peer has been lost, or a new node is a better match for the Photon.\n\nBonus: Extend your Chord peer with a visualisation of the collected data, e.g., using [D3](https://d3js.org/).\n\n## Requirements\n\nAll communication between peers must be RESTful. The individual peer shall to a Web browser present a simple page, where the peer’s state can be inspected, and where actions, such as searching for an id, can be performed.\n\nYou must document your REST API in a PDF. This PDF must be uploaded to Blackboard, and be brought to the milestone meeting.\n\nFor this final milestone, you must *also* upload all your code along with instructions on how to get the system running. It would be *very* nice to have a single script that starts the system with a fair number of peers.\n\nYou may assume that one Chord peer is initially known and available for bootstrapping purposes.\n\nBonus: Have your peers check each other for liveness, and update routing information accordingly.\n\nSee [RESTful Best Practices](http://www.restapitutorial.com/media/RESTful_Best_Practices-v1_1.pdf) for a guide on how to formulate an API in accordance with the REST principles.","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fandreasmalling%2Fchord","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fandreasmalling%2Fchord","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fandreasmalling%2Fchord/lists"}