Revision as of 19:50, 4 September 2010 by Gbucher (Talk | contribs)
(diff) ← Older revision | Current revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This is part of OSC Plug And Play.



The this part should discuss the required transport layers that a client or server must implement.

Agreed standard


OSCit currently uses oscpack for OSC encoding and decoding and is therefore bound to UDP. We have a project to remove oscpack dependency and build our own OSC parser in Ragel to directly encode oscit::Value instead of going through the osc::ReceivedMessage and then decode again.

The decoder will be as simple as possible, without any network knowledge (it will just receive raw bytes, eventually with information on whether the bytes are network ordered or not). This could enable binary read/write of osc packets.


When a client sends a query to a server, the client is automatically registered.

A meta query is answered to the source only.

A control change query is notified to all registered sources.

Data streams are sent to the clients that have asked for the specific stream (could use client multicast group). If the stream can be encoded in OSC (midi, matrix, floats, strings), we could use a single TCP/IP connection for each client.

For audio or video streams, the connection type depends on the compression scheme used.


AVBC distinguishes clients and server (a device can be both). Both should support OSC Bundles. Multicast addresses have not been allocated for this protocol. Future versions of AVBC may specify these addresses.


Must implement:

  • IPv4 UDP Unicast (one-to-one)
  • IPv4 UDP Multicast (one-to-many, distribution handled by the network switch)

May implement:

  • TCP/IP
  • IPv6 unicast and multicast



  • listen to UDP port 17220
  • implement IPv4 UDP Unicast
  • implement IPv4 UDP Multicast support (join IGMP group)
  • implement TCP/IP support

May implement:

  • IPv6 unicast and multicast

TCP/IP encoding

The messages sent over TCP/IP should be "SLIP Frame Encoded" as per OSC v1.1.

Both request and response should be pipelined in the reply (see return values).


The port used to send requests and listen to replies MUST be the same.

When a server receives a request, it MUST respond th the message via unicast to the originating source (IP and port).

Client requests

  • UDP requests sent through unicast or multicast are answered through unicast.
  • When a client starts a TCP request, the connection is kept open until the client closes. The client can test the connection with "/osc/ping" (see meta query).


They use XMLRPC for query and OSC for low latency parameter update.

Personal tools