Reliable communication

From XDIF

Jump to: navigation, search

This is part of OSC Plug And Play.

Contents

Introduction

The this part should discuss the solutions to ensure reliable communication over an unreliable transport layer.

Agreed standard

Possible implementations

Here is a list of some implementation solutions to keep the communication real-time (low latency) and still cope with lost packets in a graceful way.

A. Recovery Journal

Inspired by RTP midi. This implementation would require an increasing serial number for each communication channel (one for every direction).

The receiver periodically notifies the sender of the last received serial number (Extended Highest Serial Number Received EHSNR). The recovery journal (RJ) would contain all the messages from this number.

Every message sent would thus be a bundle with:

  • serial number
  • (timestamp)
  • url + parameters
  • recovery journal

Issues are:

  • packet size (approaching MTU)

Enhancements:

Only encode the last value for state changes instead of full history in the RJ (keep full history for events).

B. Continuous retransmit

Inspired by TUIO1, the state of a system would be continuously retransmitted. This means that a full state can be obtained by simply subscribing and waiting for all values to be obtained. A full retransmission should occur every T interval. This interval can be quite large depending on how long we can cope with missing events, in the order of a few seconds.

The main advantage of this solution is that clients can be kept really simple (no need to understand and parse a recovery journal).

Issues:

  • how do we retransmit events (midi notes on or off) without confusion ?
  • possibly high network traffic
  • battery powered devices could never enter "sleep" mode when there is no event to transmit

Enhancements:

  • data compression (citing Andy): adaptive sampling filter that only forwards a message if the minimum retransmit interval elapses, or if >n bits change in the data portion--for integer data usually it will be n=0 and for floating point one can use a moving estimate of the noise to determine when the signal portion changes.
  • minimum and maximum packet rates on stream subscriptions
  • retransmit recent events more often

other references

Personal tools