After completing a really fun and challenging project involving multicast flow between AWS EC2 cloud instances and bare-metal servers at a datacenter in the UK, there arose a need to be able to test out multicast connectivity between different nodes, in any direction. Rather than have to rely on developers to get their applications installed and tweaked on their servers, I scoured the Internet for easy-to-use tools to test, for example, a Windows-based multicast receiver, and a Linux-based multicast sender. Aside from a few more obscure downloadable packages in Linux that suit their purpose well if testing is done between Linux computers, I had no such luck with Windows. The precompiled binaries currently out there are either very old (16- or 32-bit) and are not supported by the newest Windows DLL libraries, or are written as proprietary testing tools for specific vendors, or are written very well for Windows, but do not have their Linux counterpart. For example, Singlewire developed their Emergency Mass Notification System, with a Windows-based testing tool that can run as either a server or client, but no compatible equivalent exists for Linux, so that was out.

I received my BS in Computer Science back in 1997, the days when Cobol and Pascal were living out their final years from their glorious days of yore. It seems that as of this writing, Cobol simply refuses to die! Whatever I learned over 30 years ago is completely outdated, and I cannot say that my college of half-assed choice was good for computer studies, because it was not. Thinking I was getting ahead by taking a Borland Turbo Pascal 101 course over the summer before sophomore year, I should not have had to volunteer to help the professor (more like an instructor) install a bunch of floppy disks. He was either lazy, or too old to be teaching, and the guy smoked in class (pre-Bloomberg days). In any case, here I am in 2021 and I need to write my own testing tool.

I’ve programmed in C++ a long time ago, I’ve dabbled in Python over the past few years, getting my feet wet with DevOps and Arista switches and FortiGate firewalls, and I played around with C a long time ago to manipulate my computer’s display, for geeky fun. However, I always knew that C was designed for fast and efficient execution, and so I immediately gravitated towards C as the language of choice here. Naturally, I searched for existing C code out there, and there are decent resources available, but none packaged in quite the way I wanted.

As I write this post, I am teaching myself C from scratch so that I can go back to all the code I’ve reused and tweaked from top to bottom so that I can fully understand every function call like the back of my hand–particularly, as they relate to pointer referencing and de-referencing, two topics that are somewhat confusing at first. After a few weeks of trial and error, hundreds of Google searches and many code samples, I happily came up with (admittedly flat) code that accepts multiple command-line parameters based on whether it will run as a client or server, with all necessary lines to check for whether the OS is running winsock, and if so, execute those blocks of code that are winsock-compatible. What I ended up with is code that can be compiled on any OS, including MacOS, and will run without issue. Below is the source code. I have many knowledge gaps here to fill, and one goal, once I am proficient enough in C as a whole as well as network socket programming, is to make a second version of this tool that allows for bidirectional testing from both endpoints at the same time. No idea if this requires two threads running at the same time or what, but from my understanding so far, this should require two open sockets at a bare minimum.