Circucast

Circucast is project under development to provide a generic network path testing and monitoring capability. The initial focus for circucast will be on multicast group testing and monitoring, then I will focus on other protocols and features. The github repo for circucast is currently private, but I will make it public once I have the basic multicast send/receive capability established.

The development of circucast will use modern C++, Qt-v6 (GUI) and I will use Visual Studio 2022 community edition for initial development. The project will be open source (GPL) and available on github. Here’s a current screenshot:

I need to add a field to specify the protocol (and various other things), but right now everything is UDP multicast (which I’ll continue to focus on for a while). The app automatically determines the interfaces that are available and sorts them into the IPv4 and IPv6 drop-downs that you see. I’ve just worked on the send side so far. After I work on the receive side a little, I’ll open up the repo.

One of the novel features I am considering will be to propagate new network path tests via any existing connection. As long as a remote circucast instance can be reached by “any” network path, another instance can pass along instructions for new network paths to attempt to establish. This could have a somewhat viral nature (creating more paths than intended), so propagation will be limited via the use of pre-distributed security tokens, connectivity limits in configuration files, and optional/forced user interaction (user could have to explicitly allow remote requests to start new connections). The configuration will be managed via GUI controls, and I will not initially spend time on a headless mode. In a headless mode, the config would still be edited via a GUI, then applied to a headless instance – something like “circucast –headless –pathconfigfile circucast.config” and/or configured via the path propagation mechanism I described. In theory, any given/established TCP connection could also be used to perform throughput testing – and any given/established UDP connection could also be used to perform packet loss testing. There are lots of other interesting things (e.g. traceroute-like reporting) that could be considered as well, but I will focus on some basic functionality with multicast group testing and monitoring initially.

I have no timelines for this project beyond my own personal interest. It will be an open source project that anyone can use. I will use it as a shareable portfolio project, and as a backdrop for illustrating programming related topics.

I will update this page as I make progress. I will also likely use the wiki and artifact distribution capabilities at github (e.g. to distribute Windows installers, Linux RPM files, etc. (I will like to these when they are ready).

The domains circucast.com/net/org redirect to this page. I registered these domains in case I decide to post circucast info/downloads on its own website. But for now, this page will do.

Initial operational capability TODO

  • Implement AppState class that includes update time/count and two sets of NetworkPath objects; sent and received (direct).
  • Modify app to include an unordered map from UUID to AppState.
  • Modify MulticastSender to send NetworkPath (associated with the channel), followed by AppState map.
  • Implement MulticastReceiver class to receive NetworkPath and AppState map. Add newly discovered NetworkPath objects to local AppState. Add newly discovered AppStates to local AppState map.
  • In monitor tab, display app instances in a selectable table 1 (from AppState map).
    • When app is selected:
      • Display NetworkPath objects being sent in viewable table 2 indicating success or failure. For multicast connections, success is indicated by any other app’s receipt of a NetworkPath from the local app if any other apps are known to exist (otherwise failure is assumed). If no other apps are known to exist, success/failure is unknown.
      • Display successfully received NetworkPath objects in viewable table 3. This is simply known by direct receipt of a NetworkPath object.
      • Display expected but failed receive connections in viewable table 3. This will be determined indirectly (from NetworkPath objects occurring in remote AppState objects that should have been directly received). For multicast NetworkPath objects this includes any multicast NetworkPath object that is not in the local AppState.