The OSI model.
The layers of our common networking system are dense, complicated and not worth digging into at this time.
Each connected computer or microcontroller in a given network is considered a “device” or “host“. Each device in a given network will have an IP address. The IP address can be assigned by the device itself (setting a Static IP) or the address can be given to the device by a router using a process called DHCP. DHCP is most common in large wifi networks and is probably what your laptop is using now. We call this “dynamic.”
When communicating with an application on a different computer, you’ll need to know that computer’s IP address. If both computers are on the same network (same router or same large institutional network like CMU), connecting shouldn’t be a problem.
Networks almost always regulate how their devices access the internet. This means that directly communicating with a device outside of your immediate network can be tricky.
For most applications in this class, you’ll be working with devices on the same router. To make sure you have a clear communication path between devices, check the IP address on each. You can check this by typing
ifconfig in the command line. Look for an
inet address that is not
127.0.0.1 (which is your ‘localhost’ address, used for talking to other applications on the same device). The
inet address may have an adddress such as
192.168.1.56. Communication shouldn’t be a problem if both devices are on the same subnet, which means the first 4 numbers of the IP address. Keep in mind, this only holds true if both devices are on the same network; so if Kim is in Indiana and his router gives him an IP of
192.168.1.56 and Pat is in Oregon and her router gives her an IP of
192.168.1.26, that doesn’t mean they can communicate, since their routers are on different networks (assuming no VPN, etc).
If you imagine that and IP address is like a device’s street address, the Port is like a given application’s apartment number within the device. When setting up a networking path on two applications, the listening application will need to declare which port it is listening to. This is usually a 4 or 5 digit number
5555, etc. The sending application will also need to declare, along with the IP address, which port in the destination device its packets are intended to reach.
Port numbers less than 1000 are generally reserved and should not be used in your application. You should be aware of some specific ports, like 80 (which is the default port for HTTP) and 22 (which is reserved for SSH).
User Datagram Protocol is a “transport level” protocol we often use for streaming continuous data. UDP is low latency and it does not require that the sender of UDP receive confirmation of receipt from the receiver. This means that UDP messages can get lost and nobody will know. We use UDP for streaming continuous information (people tracking, continuous sensor data, etc) because we want to get that information as soon as possible and we don’t care if packets are lost along the way because another packet will be coming right behind it.
Open Sound Control is an “application level” protocol that sits on top of UDP and allows users to send formatted, human-readable messages. An example of an OSC message may be
/sensors/A/value 54.2145 or
/heartbeat "I'm alive" 20170206 0.15. We often use OSC to stream sensor data between applications, as it is easier to read and route than plain UDP. OSC does have some overhead, so if you need to send a ton of data and bandwidth is an issue, you may want to develop a protocol based on straight UDP.
- In Processing, install the
- Open the oscP5sendReceive example (
- Find your IP address (on macOs, hold the option key while clicking the wifi icon)
- Give your IP address to a friend, get an IP address from a friend.
- on line 26 of the example,
myRemoteLocation = new NetAddress("127.0.0.1",12000);change
127.0.0.1to your friend’s IP address.
- Run the example.
- Modify the messages and protocol that you send each other.
Transmission Control Protocol is the “transport level” protocol on which HTTP runs. TCP is slower than UDP because it requires a confirmation of receipt for each message. We use TCP for sending information that MUST reach its destination. For example if we want to send updates from our FitBit to a server every 10 minutes, we would use a protocol based on TCP because if one of those FitBit update packets didn’t arrive, our system might fail. We usually do not use TCP for streaming continuous data.
At Home OSC Exercise
Build a closed system with a partner in which two computers speak to each other using OSC.
– One computer must read a sensor.
– Send the sensor data to the other computer.
– The other computer must use that data to control a physical output.
– Post a video of your system to the blog.