Networking Basics and a Quantum Simulation Experiment
The goal of this article is to explain networking fundamentals through a practical ESP32 server-client experiment, then apply those communication concepts to build a quantum-inspired simulation exploring measurement, probability, and the Quantum Zeno Effect.
IP Address and Port Basics
An IP address is a numerical label assigned to a device by the router on a network. It allows devices to identify and communicate with each other.
A router typically assigns local IP addresses using DHCP(a network managing protocol) when devices join a network. IP addresses can also be configured manually.
An IP address helps data reach the correct device.
A port is a logical endpoint that directs network data to the correct application or service on a device. While an IP address identifies the device, the port identifies where the data should go.
For example, your microcontroller can listen on port 8888, allowing a client to connect using the microcontroller’s IP address and that port number. Once connected, both devices can send and receive data.
Servers and Clients: The Basics
A server is a program that listens for incoming connections on a specific port that it has opened. A client is a program that connects to that server using its IP address and port number.
Once connected, they can exchange data. The server can receive requests and send responses, while the client initiates the connection.
Servers and clients don’t have to be on the same network. They can communicate over a local network or across different networks.
Think of a port as a pipe opened by the server. The client connects to it using the server’s IP address and port number. Once connected, the pipe allows two-way communication: both the server and client can send and receive data.
TCP vs UDP
TCP and UDP are two protocols used to send data over a network.
TCP (Transmission Control Protocol) establishes a connection and ensures data arrives reliably and in the correct order. If data is lost, TCP can retransmit it.
UDP (User Datagram Protocol) sends data without establishing a connection or guaranteeing delivery or order. This makes it faster and simpler, but packets can be lost.
In short, TCP prioritizes reliability, while UDP prioritizes speed.
Experiment: Two Way TCP Communication Between Server and Client
For this experiment, my main goal was to demonstrate a two way communication between the Server(ESP32) and a Client. I used nc(netcat), which is a command line networking tool that can read and send data over TCP or UDP connections. I used nc as a TCP client to communicate with my ESP32.
How my project would work:
The user types a message, such as “Hello,” into nc, which sends it through port 8888 to the ESP32. The server prints the message in the Serial Monitor. The user can also type a message into the Serial Monitor, which the ESP32 sends back through the same port to be displayed in nc.
How It Works
1. Connecting to Wi-Fi
The ESP32 first connects to the Wi-Fi network using its SSID and password. Once connected, the router assigns it a local IP address, which other devices on the network can use to reach it.
2. Starting the TCP Server
The ESP32 creates an AsyncServer on port 8888 and starts listening for incoming TCP connections. An AsyncServer allows the server to wait for clients to connect without repeatedly polling for new connections in the main loop.
3. Connecting the Client
On Ubuntu, the user runs nc with the ESP32's IP address and port number. Netcat establishes a TCP connection to the server, creating a communication channel between the two endpoints.
4. Receiving Messages on the ESP32
When a client connects, a callback runs. The ESP32 registers an data callback for that client, which runs whenever data arrives.
Get Shivangsh Roy’s stories in your inbox
Join Medium for free to get updates from this writer.
The callback receives the incoming data and its length. The ESP32 prints the received bytes to the Serial Monitor.
5. Sending Messages Back
When the user types a message into the Serial Monitor, the ESP32 reads it and sends it through the existing TCP connection.
Netcat receives the bytes and displays the message in the terminal.
6. Two-Way Communication
Both endpoints use the same TCP connection to send and receive data. TCP provides reliable, ordered delivery of bytes, while AsyncTCP uses callbacks to handle incoming network data without requiring continuous polling.
This creates a simple two-way messaging system between the Ubuntu terminal and the ESP32.
Link to code : https://github.com/Quantum-Shivi/Arduino-Projects/tree/main/server-clienttrial
BONUS: The Quantum Simulation
My quantum simulation proves 2 main concepts:
1: “A Watched Pot Never Boils” The Quantum Zeno Effect
A phenomenon in quantum mechanics where repeatedly measuring(observing) a quantum system can completely prevent it from changing.
2: Quantum Probability vs Classical Certainty
Unlike regular coin-flip probability where things are either heads or tails, quantum probability handles things that exist in multiple possibilities at once.
My quantum simulation was a game in which there was one server and two clients. I used my ESP32 as the server, serial monitor as client 1, and nc as client 2.
The server simulated a “infiltrator” trying to creep past a security perimeter. The clients each simulated radar operators that must fire radar pings to reset the infiltrator’s progress back to 0%. Every second, the infiltrator creeped up 2%. Once the infiltrator reached 100%, it was game over.
The Wave State
The infiltrator isn’t a solid object. Instead, they exist as a ghost-like probability wave stretched between the start line and their current progress.
When a user types “ping radar” into the serial monitor or nc, the client alerts the ESP32 server to fire the radar at the start line.
Let’s look an example:
- The 84% Chance (Radar Wins): If the infiltrator has crept to 16%, there is an 84% chance the radar confirms they are still at the start. In quantum physics, finding “nothing” down the hallway instantly collapses the wave, erasing the spy’s progress and snapping them back to 0%. This works just like the counter-intuitive math used in quantum physics.
- The 16% Chance (Infiltrator Wins): This is the probability that the infiltrator wins the digital dice roll. If they win, the quantum wave collapses forward. The spy solidifies at 16%, their progress is not reset, and 16% becomes your new permanent start line.
Conclusion
By building this project, we proved two massive physics principles:
- The Quantum Zeno Effect: If you constantly spam the radar, the infiltrator can never leave the 0% mark. You freeze them in place simply by looking at them.
- Quantum Probability: Before you check the radar, the infiltrator physically exists at both 0% and 16% at the exact same time.
Link to code : https://github.com/Quantum-Shivi/Arduino-Projects/tree/main/QuantumInfiltrator
Code Issues
The first time I tested out my code, I ran into an issue.
Every time the Infiltrator reached 100%, the ESP32 crashed. The issue was simple: I broke the golden rule of interrupts. An Interrupt Service Routine (ISR) must be lightning-fast, but mine was slowed down trying to print to the serial monitor and transmit data over Wi-Fi. It hogged the processor, triggering a watchdog timeout crash. To fix it, I stripped the heavy lifting out of the ISR entirely. Now, the timer simply flips a true/false flag, and my main loop checks for that flag to safely handle the serial prints and network messages.
Conclusion
Networking allows devices to communicate and exchange data using IP addresses, ports, and protocols such as TCP and UDP. Understanding these basics makes it easier to see how clients connect to servers and how data moves across a network. Building a two-way messaging system with an ESP32 was a practical way to put these concepts into action.
