Define reply address schema for response and listen updates

[eirikblekesaune]

When sending a query to another computer it is not clear to which ip or port the response should be sent.
I suggest defining a schema for this.
I'm currently using this schema (JSON format):

{address: {ip:127.0.0.1, port:57120}}

For querying the monitor output indexes a message might look like this now:
/source/eirikMicrophone:monitorIndex> {address: {ip: 127.0.0.1, port:57120}}

Likewise with listen messages:
//To enable listening
/source/eirikMicrophone:monitorIndex! 1 {address: {ip: 127.0.0.1, port:57120}}
//To disable listening
/source/eirikMicrophone:monitorIndex! 0 {address: {ip: 127.0.0.1, port:57120}}

+Eirik

[bltzr]

This is the kind of things Bonjour/zeroconf manages in realtime - but I don't know how things should be done Bonjour-wise… like only the host name ? (e.g. Eirik.local) or ????

BTW, zeroconf is not yet implemented in 0.6, even if we have most tools available from the zeroconf repo that Tim forked from Rémy Muller's sourceforge svn onto github : https://github.com/tap/osctools

Le 12 juin 2013 à 17:17, Eirik Arthur Blekesaune notifications@github.com a écrit :

When sending a query to another computer it is not clear to which ip or port the response should be sent.
I suggest defining a schema for this.
I'm currently using this schema (JSON format):

{address: {ip:127.0.0.1, port:57120}}

For querying the monitor output indexes a message might look like this now:
/source/eirikMicrophone:monitorIndex> {address: {ip: 127.0.0.1, port:57120}}

Likewise with listen messages:
//To enable listening
/source/eirikMicrophone:monitorIndex! 1 {address: {ip: 127.0.0.1, port:57120}}
//To disable listening
/source/eirikMicrophone:monitorIndex! 0 {address: {ip: 127.0.0.1, port:57120}}

+Eirik

—
Reply to this email directly or view it on GitHub.

[tap]

Perhaps it would be worthwhile, in the wiki or as a part of our paper, to diagram what activities/services belong in which layer.

Since the OSNIP protocol is envisioned as a layer on top of OSC and Zeroconf, we can make it clear which things are our responsibility and which things are not.

[eirikblekesaune]

With SC I get the ip address when I receive the message. I would need to have the port I'm supposed to send the result for the query to.
Is this port number defined by the protocol then? Looking at http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
Maybe we should define a specific port number for OSNIP query and replies?

[bltzr]

does it have to have a port number at all if we're using zeroconf ?

Pascal Baltazar
pascal@baltazars.org
http://www.baltazars.org

Le 13 juin 2013 à 15:24, Eirik Arthur Blekesaune notifications@github.com a écrit :

With SC I get the ip address when I receive the message. I would need to have the port I'm supposed to send the result for the query to.
Is this port number defined by the protocol then? Looking at http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
Maybe we should define a specific port number for OSNIP query and replies?

—
Reply to this email directly or view it on GitHub.

[bltzr]

I mean, of course, the application has a port number, but does it have to be different from the one for the main OSC messaging ?

Pascal Baltazar
pascal@baltazars.org
http://www.baltazars.org

Le 13 juin 2013 à 15:44, Pascal Baltazar pascal@baltazars.org a écrit :

does it have to have a port number at all if we're using zeroconf ?

Pascal Baltazar
pascal@baltazars.org
http://www.baltazars.org

Le 13 juin 2013 à 15:24, Eirik Arthur Blekesaune notifications@github.com a écrit :

With SC I get the ip address when I receive the message. I would need to have the port I'm supposed to send the result for the query to.
Is this port number defined by the protocol then? Looking at http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
Maybe we should define a specific port number for OSNIP query and replies?

—
Reply to this email directly or view it on GitHub.

[eirikblekesaune]

Since the OSNIP protocol is envisioned as a layer on top of OSC and Zeroconf, we can make it clear which things are our responsibility and which things are not.

That would be helpful for me at least..

I'm curious though. What are the pros and cons again for having zeroconf/Bonjour as a base for OSNIP?
I mean, there aren't that many platforms supporting it yet, or?
Or maybe we just shouldn't care about that, rather focus on creating the standard, and then have other platforms implement it?

[bltzr]

I'd say that zeroconf is quite popular, plus it already manages all we need, plus RémyMuller has already done a lot of work to merge this with OSC, so why not using it…

Pascal Baltazar
pascal@baltazars.org
http://www.baltazars.org

Le 14 juin 2013 à 11:32, Eirik Arthur Blekesaune notifications@github.com a écrit :

Since the OSNIP protocol is envisioned as a layer on top of OSC and Zeroconf, we can make it clear which things are our responsibility and which things are not.

That would be helpful for me at least..

I'm curious though. What are the pros and cons again for having zeroconf/Bonjour as a base for OSNIP?
I mean, there aren't that many platforms supporting it yet, or?
Or maybe we just shouldn't care about that, rather focus on creating the standard, and then have other platforms implement it?

—
Reply to this email directly or view it on GitHub.