[OSC_dev] oscit registration complete !

[salsaman at xs4all.nl]

On Fri, January 30, 2009 17:28, Jamie Bullock wrote:
>
> 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
>
>
>


Agree 100 %, except that others have requested that ip address parameter
should come before port. So we would have:

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


Salsaman.
http://lives.sourceforge.net