{"id":24737466,"url":"https://github.com/engineersbox/routers","last_synced_at":"2026-08-03T14:34:24.888Z","repository":{"id":109327900,"uuid":"308519186","full_name":"EngineersBox/Routers","owner":"EngineersBox","description":"A self mapping message routing network in GoLang","archived":false,"fork":false,"pushed_at":"2020-11-09T03:00:58.000Z","size":664,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-10-20T12:59:42.721Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Go","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/EngineersBox.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":"2020-10-30T03:51:37.000Z","updated_at":"2020-11-09T03:01:01.000Z","dependencies_parsed_at":"2023-03-26T16:20:38.746Z","dependency_job_id":null,"html_url":"https://github.com/EngineersBox/Routers","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/EngineersBox/Routers","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/EngineersBox%2FRouters","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/EngineersBox%2FRouters/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/EngineersBox%2FRouters/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/EngineersBox%2FRouters/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/EngineersBox","download_url":"https://codeload.github.com/EngineersBox/Routers/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/EngineersBox%2FRouters/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":36240877,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-07-20T02:08:10.276Z","status":"online","status_checked_at":"2026-08-03T02:00:06.975Z","response_time":56,"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":[],"created_at":"2025-01-27T22:08:26.175Z","updated_at":"2026-08-03T14:34:24.749Z","avatar_url":"https://github.com/EngineersBox.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Routers\n\n---\n\n## Note\n\nBase implementation of framework for CLI argument parsing and intial router gorouting instantiation by Uwe R. Zimmer of the ANU. All other implementation details are my own. \n\n---\n\n## Overview\n\nImplementing a network of routers with arbitrary topology requires dynamic identification ofnetwork structure and neighbour mappings. This implementation is based around DistanceVector Routing (DVR) with local only tables. Each of the routers implements a IPv4 dynamicaddress for managing subnet changes locally, and also re-pathing for dynamic topologychanges.\n\n## Message Types\n\nIn order to communicate network structure, self identification and actual message passing, thereare three types of messages implemented. \n\nFirstly, is the Topology Update, which is designed tostore the path the message took whilst travelling around the network. At each node, the pathingis updated in the DVR table and forwarded to neighbours. It is invalidated when it reaches acycle, such that the current node has been previously visited and is in the path list.\n\nSecond type of message is the Neighbour Update. Here, the routers send this message to theirneighbours to identify which channel maps to the connection between them, and the ID thatshould correspond. Without circulating this message, routers cannot identify which of their neighbours to send a given message to when finding the shortest path.\n\nThe last type of message is the Envelope, provided alongside the framework. No modificationsare made to this message and it is purely for sending through the network until reaching itsstored destination\n\n## Network Mapping\n\nIn order to route messages, knowledge of the network topology is required. Routers utilise theTopologyUpdate​ message to spread through each path starting from themselves in order tomap the network connections.\n\nIn order to reduce cyclic redundancy, at each branching traversal, the message is passed onlyto routers who haven’t yet received the message. It is important to note that since every router is passing these messages this reduces the stress to the network but also doesn’t lose theguarantee of each router having knowledge of the network (assuming all routers have at leastone connection.\n\nBelow is an example network with the topology update pathing tree for each message split.Note the lack of looping in the tree, guaranteeing acyclic pathing until invalidation, at which pointthere is no alternative.\n\n![images/Topology%20Update.svg](images/Topology%20Update.svg)\n\n## Identifying Neighbours\n\nIn order to send messages to routers by ID, the router needs to map the channel addresses torouter IDs. This is the job of the ​NeighbourUpdate​ message, which contains the incomingchannel address and the routers ID. When another router receives this message it checks its listof channels and finds the matching one, which tells it the mapping of router ID to channel, thuscompleting the indexing.\n\nIn this implementation of routing, the channel IDs act kind of like MAC addresses (of differentformat), as they identify physical existence of network destinations. However, the usage ofthese channels is not like that of MAC addresses in typical routing implementations.\n\n## Pathfinding\n\nIt’s all well and good to know what the network looks like, but without being able to traverse it, itbecomes redundant. Here Dijkstra’s shortest path algorithm is used to path through the mappednetwork for a given destination. Note the efficiency of this algorithm drops with larger quantities of routers, however for most networks it is sufficient.\n\n## CIDR Block Addressing\n\nEach router is assigned a random dynamic IPv4 address at startup, and a CIDR prefix based onthe amount of neighbours it has. Using classless subnets allows for immediate identification of neighbouring nodes and also relative addressing changes based on topology changes.Using the CIDR prefix, routing messages within a given subnet becomes a matter of deterministic connectivity, and also provides instantaneous invalidation of the current subnetprefix. Given any changes, a recalculation can be done in one of three ways:\n\n* Static addressing\n* Dynamic addressing\n* DNS configuration\n\nThis implementation uses dynamic addressing as it was the happy medium of the three,however not complete as you will note with the inconsistent subnet overlap. Implementing DNSservers would have been optimal, but time constraints permitted otherwise.\n\n![images/CIDR%20subnets.svg](images/CIDR%20subnets.svg)\n\n### Static Addressing\n\nIf the host address is required to be static, then a re-assignment can be made with a subsequent re-calculation of CIDR prefixes and updated to the supernet. However, this can be costly and should be reserved for full topological supernet changes.\n\n### Dynamic Addressing\n\nIf the host address is dynamic then the subnet can be reconfigured and an update to the CIDR prefix can be made to reflect these changes. This allows the global supernet addressing toremain intact whilst having localised changes propagate as and when needed. This does notaffect the ability to send and receive messages.\n\n### DNS configuration\n\nIn the last situation, a DNS server sits as an intermediary between the supernet and subnet. Here we can make localised addressing changes and update the DNS records on the fly without losing actively queued messages or currently processing messages. A downside to this is that it does have a small dropout time when records are switched over, which can create isolated messages in a dead channel. However, this is extremely rare with DNS updates being microseconds at worst in this case.\n\n### Router Processing Sequence\n\n![images/Routers%20sequence.svg](images/Routers%20sequence.svg)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fengineersbox%2Frouters","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fengineersbox%2Frouters","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fengineersbox%2Frouters/lists"}