Installation Networking – Part 2

Picking up where we left off in our part 1, we’re going to look at some common terms and communication protocols. While some brains may melt when thinking about computer networking (mine included!), I guarantee that these concepts and pieces of knowledge will be used in your career working on interactive technology and immersive media experiences, otherwise I wouldn’t have ended up learning them myself!

If you’re just starting this series, I recommend you check out part 1 here:

Installation Networking – Part 1

What’s a port?

We finished the last post by talking about IPs and how you might address different systems and devices on a network. One last part of that puzzle are ports. In the previous post, we mentioned that public IPs were like your apartment building address, and then private IPs were like your unit number inside the building. We can take this a step forward by thinking about ports as the name you write on the package you’re sending. So we could send all different kinds of packages to unit 201, but they might be meant for totally different people (or pieces of software in the case of our computer). All kinds of softwares use different ports to communicate. Some of them are well-defined, and you should avoid them, while other ranges of ports are pretty much open for you to take over. Some common ports you may have heard of would be:

• SSH – port 22
• FTP – port 20
• HTTP – port 80
• HTTPS – port 443
• Steam (yup the game app/store) – port 1725

And that’s just a tiny tiny tiny short-list of some of the common ports that are used daily by your system that you might not even realize. We don’t need to worry too much other than the fact that usually when we’re talking about communicating with different systems we’ll likely both need an IP address but also a port number. If you’re new to networking, your software will likely already suggest port numbers to use in its default parameters/settings, so you don’t often need to worry. One great tip here is to not use the same port for everything. If you take a look at the example diagram below, even though everything is using OSC to communicate, it’s more reliable to keep ports separate for different usages.

In this case, the two machines are communicating on port 10002 and the iOS device is communicating on port 10001 to computer 1.

Common troubleshooting tip

Because of how ports work, they are “opened” and “closed” as applications use them. If you ever find that you’ve opened and closed an application a few times and your communication pipes stop working, you might be experiencing a problem with the ports getting confused between being open/closed. The easiest thing to do is to just reboot your system. That will flush all the port states, and opening your application again should start functioning again.

What are TCP and UDP?

Ok, without getting into a whole tutorial on the layers of networking, there are two common terms you’re going to hear a lot: TCP and UDP. These are the infrastructure pipes that most common protocols use to send their messages back and forth. You can think about these as two different types of highways (TCP and UDP), and on those highways we can send all kinds of different kinds of vehicles types or enforce different driving rules (FTP, SMTP, DNS, OSC, WebSockets, JSON, etc, etc).

Some communication protocols that we use were built to specifically use only TCP or only UDP while others are more flexible and can actually communicate freely over both. There are pros and cons to both, but you’ll often find your application makers will help you navigate which to use when and for what purposes. So in this scope of troubleshooting installations, the best thing to know is that it’s important to specify if we’re trying to speak over TCP or UDP when we’re troubleshooting network communication. A good example is that if you’re sending JSON messages from your system to another collaborator, it’ll be impossible to troubleshoot unless you tell them all the info below:

• Private IP of your system
• Private IP you’re sending to
• Port number you’re sending to
• Whether you’re speaking over TCP or UDP

That’s kind of the most basic amount of information you can provide a collaborator when troubleshooting networking problems (I know…it feels like a lot and required 2 blog posts to explain, but now you know!)

Pro tip: if you’re communicating on a WiFi network, you might want to avoid spamming UDP messages (especially broadcast messages), as they can flood the network and greatly diminish the overall network performance and bring it to a halt.

What’s a firewall?

A firewall is a software process on your computer or device that can block communication of certain types. It does this by filtering what traffic is coming in (inbound) or going out (outbound) on a variety of ports and protocols. It’s a common misconception that once you’re connected to a network that everything is communicating openly and freely between all the devices, but this isn’t true. Every end of a communication pathway need to have their firewalls setup to allow the type of communication you’re trying to achieve.

And this is why we spent so much time talking about ports and protocols here. All firewall rules are based on ports and protocols. If you have the bullet point list I mentioned above, then it’s VERY easy to make custom firewall rules. If you don’t, it’s impossible. By default, your system firewall is set up to allow outgoing connections for most of the common ports for things like HTTP, HTTPS, etc. Most firewalls (especially as time goes on) are becoming more and more prone to blocking most incoming connections. This results in your normal (and comparatively secure) computer experience, where you’re able to communicate with the outside world over the network, but other strangers aren’t able to just dive into your system over the network and have a good time in there.

The common problem

Firewalls are probably the most common reason developers have problems when using network communications. It’s almost always the 2nd step of troubleshooting for me (after the first being to verify the bullet points above about IPs and ports are actually correct!!). In the next post, we’ll look at things like making firewall rules, but one thing I suggest is if you ever have communication problems, if you want to confirm or deny if it is your firewall, you can temporarily fully disable your system’s firewall. If communication starts flowing, then you can re-enable your firewall and make a new firewall rule for whatever you’re doing. If communication doesn’t start, then you can re-enable your firewall and know that it’s not the firewall.

VERY IMPORTANT TO ONLY TEMPORARILY DISABLE YOUR FIREWALL AND RE-ENABLE IT AFTER THE TEST . That was important enough to require caps and bold and italics and underline.

Quick instructions for temporarily disabling your firewall on macOS and Windows:

Windows

Here’s a quick guide on how to disable the firewall on Windows 10 and 11:

https://www.lifewire.com/turn-off-and-disable-firewall-in-windows-11-5192308

macOS

Here’s the documentation from Apple on getting to the firewall settings on macOS, where there is a big button to turn the firewall on and off:

https://support.apple.com/guide/mac-help/change-firewall-preferences-on-mac-mh11783/mac

Part 3!

Here’s a link to the last post in this series:

Installation Networking – Part 3

Wrap up

We’re finally nearing the end of needing to learn all these concepts and terms and can finally dive into real troubleshooting steps in the next part of this series. There is an alternate universe where we don’t need all this information to be successful on projects, but at least in this one, I’ve had to learn all these things as things aren’t working during installations. That’s why it’s best to take a proactive stance to learning a lot of these things, especially ports, protocols, and firewalls, as they’ll make up the large portion of the troubleshooting we’ll be diving into next time.