Data protocols are an integral part of working with different Application inside IASpace. We are using a selection of easy to use and implementable data protocols for
- Light Control
- Motion Capture Data
- Timeline control
- inter application communication
- IOT communication
Data protocols are at the top of the so called network layers. They make use of underlying protocols that help to ‘Transport’ the data, make sure the data finds its way from the sender to the receiver (Internet), and tells the hardware on how to do its job (Link).
When using Data Protocols the only layer one has to be concerned about is the Transport layer:
The Transport layer protocol defines how the data needs to be transported. For our purpose only two protocols are of interest:
The main difference is that TCP makes sure the data arrives, while UDP doesn’t.
While the hardware our internet is based on is very reliable and fast, it can happen that a packets of data sent via the Internet Protocol (also know as IP – hence the name IP-address) are lost in the process. While TCP will realize this and request another packet from the sender, UDP doesn’t.
This means if you want to send a File to work further on it, TCP is used, because this is only usable if the complete file has arrived.
If you want to stream video or Audio, UDP is the preferred method, because it doesn’t have the overhead to check if all the packages have arrived in the correct sequence and is therefore faster. When during streaming realtime data a package is lost, it doesn’t matter, since the next one comes for sure. Thats why Ultragrid or Motive are sending their data via UDP.
An nice introduction to the internet protocols, starting with the structure of the electrical signal inside a Ethernet cable up to the IP protocol, can be found here.
OSC is the workhorse in the IASpace and usually our preferred method for sending data forth and pack.
- /address/subaddress <value> <value> value>
where each <value> can be s string, float, integer, …
An OSC connection is always only one way, from the sender to the receiver. If one requires a bidirectional connection, the user/programmer has to implement it him/herself.
- MaxMSP (native: [udpsend] [udpreceive])
- Processing (Menu > Sketch > Import Library… > search for ‘oscP5’)
- TouchDesigner (native)
- PureData (native)
- Supercollider (native)
- OpenFrameworks (native: ofxOSC)
It is a very simple and user friendly protocol that has native implementations in most software.
It is usually based on UDP, has therefore the disadvantage of the likelyhood of dropped packages (especially when used over Wifi) and can be unreliable when used to trigger certain events remotely.
OSCQuery is an OpenSource Protocoll developed by the libossia community, the same people that develop Score. It is not used by itself but rather in its implementation with libossia, a modern C++, cross-environment distributed object model for creative coding.
Based on the Model/View software architecture philosophy where the logic (model) and the user-interface (view) are developed inside separate code containers, this protocol allows to share the model of an application with another application (usually Score).
The different applications that talk OSCquery need to be inside the same LAN
If one desires to make the application one develops controllable via Score, libossia/OSCquery makes it easy.
It can currently only be used with Score.
It uses very lightweight implementations and uses a publish/subscribe paradigm. A device (or application) needs first to connect to a Message Broker (like shiftr.io) and then subscribe to specific addresses before it can receive them.
All devices connect with a Message Broker.
- It is easy to use and has a similar addresses like OSC.
- It is based on TCP and therefore relays data reliable from device to device.
- It is bidirectional, once a connection is established it can send and receive.
It requires running a central server (Message Broker) all the devices need access to.
MQTT Client Tool – download