Bidirectional OSC


#1

Working on an application that requires arbitrary connections between any number of iPads and any number of apple tvs in a showroom. I’m using bonjour to handle all the service discovery and whatnot, and thought OSC might be the go for the actual command sending. There’s multiple channels of communication that need to happen which i thought OSC would be suited for. /handshake/* for anything related to pairing, /control/* to any control specific commands etc.

So i assume that the application will need both a osc::SenderTcp and a osc::ReceiverTcp to handle the incoming and outgoing messages. I can see that there’s a constructor for each of them that takes an externally created TCPSocketRef but I can’t for the life of me get it to work. It probably doesn’t help that I know next to nothing about either asio or osc itself. :confused:

tcp::endpoint endpoint = tcp::endpoint ( asio::ip::address_v4::from_string ( "127.0.0.1" ), definition.Port ); // Tried 0.0.0.0 as well

_tcpTransport = std::make_shared<tcp::socket>( App::get()->io_service() );
_tcpTransport->open( endpoint.protocol(), error );
_tcpTransport->bind( endpoint );

_receiver = std::make_unique<osc::ReceiverTcp>( _tcpTransport ); 
_sender = std::make_unique<osc::SenderTcp>( _tcpTransport, endpoint );

There’s an error upon construction that is sent to the callback, and then one upon each subsequent call to _sender->send ( ... ) which is Tcp Send: Socket is not connected - Code: 57

Am I missing something simple, or is this just not how OSC is intended to be used and I should write a custom communication layer directly on top of ASIO?

Thanks,

A.


#2

Hi,

I’m not so familiar with these neither, just some thoughts:
since the network environment sounds like pretty stable, any specific reason you have to use TCP?
I think if you go with UDP you should be able to have them setup easily.

*updated
And on a close look at your code, shouldn’t the sender/receiver use different ports?

-seph


#3

Indeed, just broadcast over UDP. That way you can also run sender and receiver on a single computer, making testing easier. OSC messages are usually small enough to not cause any bandwidth problems when broadcasted.

See also Cinder’s OSC samples for more information.


#4

I’m currently working on similar things, and also chose the UDP route with broadcasting. Seems to work fine so far.


#5

I’ll probably have to use a combination of TCP and UDP. There’s certain messages like remotely controlling a 3D camera position where reliability isn’t that important. but there’s other one’s like pairing that the messages absolutely have to get through. I’ve since found I was missing a call to ``::accept` that was the problem in this specific case, but there’s a host of other issues to work through. Thanks for your help, everyone.