[OSC_dev] oscit registration complete !

[Jamie Bullock]

On 28 Jan 2009, at 07:23, Gaspard Bucher wrote:

> On Wed, Jan 28, 2009 at 4:37 AM, Jeff Glatt <jgglatt at roadrunner.com>  
> wrote:
>> Questions about oscit:
>>
>> 1) Why is it limited to UDP?
> UDP is a first step. Network protocols are the only ones that enable
> zero configuration (plug & play) for the moment so this is the
> priority. All other connections can be handled through an application
> that acts as proxy.
>
>>
>> 2) Why do you need the /.reply_to message? A UDP datagram includes  
>> the
>> sender's reply address, so you just pull that out of the UDP  
>> datagram if you
>> want to reply. So too, you can get the sender's address from a TCP  
>> (ie,
>> connected) socket. I imagine that most other multi-bus protocols  
>> include the
>> sender information with any "message", for example, with USB. So  
>> why don't
>> you just leave it up to the underlying protocol to supply the  
>> sender's
>> address (in the same way that OSC itself leaves it up to the  
>> underlying
>> protocol to supply the size of each received OSC message)?
> Because it doesn't work ! Most implementations of OSC I have tried do
> not let you define the outgoing port when creating a connection. This
> means packets are sent with something like "10.0.0.5:90002" and
> sending messages back to this IP:port pair is of no use because the
> application does not listen at this port. The obvious solution to
> ignore "/.reply_to" is to use mdns to get the reply port of an IP. But
> even this solution would break when you have multiple applications at
> the same IP.
>
> I don't like the "/.reply_to" thing and will do my best to get rid of
> it, but I am afraid it will have to stay...

This was the original reason for the semantics of '/register' in  
Integra instead of '/reply_to', i.e. '/register' without any arguments  
can be interpreted as a *request for registration* in the context of a  
bi-directional transport. You are saying 'register me (the client) for  
replies'. '/reply_to' doesn't make any sense in the context of bi- 
directional UDP because you're not supplying any arguments.

I do think we need a mechanism for clients to 'opt in'  to server  
responses. I therefore suggest we change '/reply_to' to '/register'  
and allow zero arguments:

/register       				 	- register this client for replies in bi- 
directional context
/register <port>  				- register client on same host (address/port not  
in datagram)
/register <port> <ip address> 	- register client on remote host  
(address/port not in datagram)

This gives oscit the flexibility to support situations where the  
sender's reply address is encoded in the datagram or supplied by the  
client.

Jamie



Jamie