The development notes are to be used for reference while developing GroundLift. Keep in mind that when this page was created the library and command line application were almost finished. More specifically we were in commit dda76fe. For reference, the last commit before the Windows port was commit 35c5c88.
Apparently in order to send any sort of general broadcast or multicast packet outside of very strict mDNS (or Bonjour as Apple likes to call it) rules you are required to request an entitlement from Apple, namely com.apple.developer.networking.multicast. This will only be required when porting our library to more strict platforms like iOS or sandboxed macOS, but we need to perform some tests in order to ensure that Xcode won't block us by default even when not targeting the App Store for macOS deployments.
The worst part about all of this is that the entitlement is required even for development! This is the dumbest move ever, but let's ignore it for now. Maybe, since Apple apparently takes its sweet time processing requests, we could wrap the network discovery code behind a preprocessor flag and ensure that we have an alternative mechanism for doing “manual discovery” (i.e. something like asking your buddy to tell you their IP).
If we ever need more information on the subject, the great eskimo has blessed us with a summary of everything we may want to know about the entitlement.
All of this is part of Apple's Local Network Privacy initiative, which is just some bullshit to restrict things in the name of privacy.
If we still want to test the discovery code before or during the entitlement requisition process the only option we have available is to use a real iOS device running iOS <= 14.5.
Take a look into these deprecated functions as maybe a portability path for functionality like getaddrinfo(3) on much older, pre-IPv6, systems. One quick example of such a function would be gethostbyname(3).
According to Microsoft:
Additional functions have been added over time to enhance Winsock for use by developers. For example, new name service functions (getaddrinfoandgetnameinfo, for example) were added that support both IPv6 and IPv4 on Windows XP and later. Some of the older IPv4-only name service functions (thegetXbyYclass of functions, for example) have been deprecated.
Currently, we have implemented our peer discovery mechanism by sending a simple UDP broadcast message to the generic broadcast address (255.255.255.255). This means that the OS is choosing one interface to send this broadcast message through, we have no control over which network interface is chosen, and we desperately need to start working on changing this since we've already started bumping into the OS choosing the wrong interface to send the message through when porting the software to Windows.
Since our Windows machines usually have Hyper-V or some other type of virtualization software that creates virtual network interfaces installed, the OS was choosing the wrong interface to send the broadcast message through (either this or Windows has some issue with using the generic broadcast address). This was verified by hardcoding the local network's broadcast address in the peer discovery code, which immediately sprung back to life and started working.
We must implement a way of, on modern platforms, to iterate over the network interfaces available, figure out the broadcast address of each one, send the broadcasts on each network, and combine the replies into a single pool. We must also provide a fallback mechanism for older systems to still just broadcast to the generic address since some of the functions to support multiple network interfaces might not be available on such older or constrained systems.
Whenever we go down the path of iterating over multiple network interfaces we must take special consideration of the fact that we may end up in a weird situation where two network interfaces might be connected to the same physical network (i.e. Ethernet and Wi-Fi are both connected on the same home network) and we'll be duplicating the peers discovered. We still need to research how we can address this issue and check if both interfaces are connected to the same physical network.
Instead of having to tell your friend that wants to share some data with you your entire IP address, which a lot of people will not do and is extremely cumbersome, we could encode this data in such a way that it is small enough for people to be comfortable speaking it out loud. Look into Base36 and Base64 as possible ways to encode the binary representation of the IP address.
General topics of this section have been moved to devnotes:msvc-porting.
Since we already have a lot of experience developing Win32 applications, our first GUI application will be created for it. Here we'll catalog a bunch of resources required to finish the Windows version of our application.
Our application will live most of its life as a simple tray icon (also known as the system tray or notification area), guaranteeing that the server is running and providing quick access to some of the application's functionality. Here are some resources to help us implement this feature: