[sugar] olpc-games osc protocol

Simon Schamijer simon
Tue Jun 12 03:23:06 EDT 2007

Simon McVittie wrote:
> Hash: SHA1
> On Mon, 11 Jun 2007 at 13:06:16 +0200, Simon Schamijer wrote:
>> memosono is using the osc protocol 
>> (http://opensoundcontrol.org/spec-1_0) to communicate with the game 
>> server and to talk to the csound server. I think it is an easy to use 
>> protocol and maybe some other games or activities want to use it as well.
> This protocol seems to be rather like D-Bus, but different. We're using
> D-Bus as the basis for most OLPC things - is there a compelling reason
> not to here?

Probably not. I am used to the osc protocol and successfully used it in 
another project. So it was easy for me to use it in memosono as well. I 
will read through the telepathy specs which probably has features I 
haven't thought of yet.

> In the Telepathy-based collaboration framework Collabora are developing for
> the OLPC (including the Presence Service), activities are shared over
> "tubes". These can currently transport a distributed D-Bus over reliable
> streams, with work in progress to do TCP-like reliable streams between
> peers too. Transporting UDP-like datagrams over tubes, using ICE or
> Jingle for NAT traversal, is a future enhancement.
> The advantage of using Tubes is that we're already thinking about issues
> which prevent peer-to-peer networks from working in practice, mainly NAT
> traversal. Tubes provide a consistent API which will remain consistent
> and transparent as we add additional NAT traversal methods and transport
> mechanisms; the API is also consistent between the server-based and
> link-local collaboration, and any future collaboration mechanisms. We will
> also transport instant messages related to an activity, and the necessary
> metadata to support the Buddy- and Activity-centric programming model used
> in Sugar.

cool. I have seen that this is used in the connect activity. I will read 
through this code then.

> I've only looked at the OSC spec briefly, but you seem to be assuming
> synchronized real-time clocks. Is this a requirement we can impose on XOs?
> If it *is*, we could use it for the link-local communication to provide
> additional ordering guarantees; but I suspect it isn't something we can
> assume.

I am not sure I get you right here - do you mean the deviation of 
distributed audio clocks? osc is only about control messages so this 
should not impose any problems here.

Thanks for the insights,


More information about the Sugar-devel mailing list