Can GigPerformer send and receive OSC messages over TCP rather than UDP?
I would like to build something browser based that interacts with GP over OSC, but browsers can’t send UDP packets, only TCP, at least not without going via some kind of proxy that translates a TCP based WebSockets connection to UDP datagrams which completely spoils the benefits of a simple browser-based implementation.
The application I have in mind would benefit from a TCP based connection that guarantees delivery and doesn’t necessarily need the fast latency that UDP otherwise gives.
Most implementations use UDP. Problem is that OSC itself is only a message-format specification and there are(/were?) no guidelines what the transport should look like. The messages itself are(/were?) also not standardized. Not that that would be easy to do: General Midi tried to do that, and was not too successful imho.
The main reason for using UDP is (I think) that most overhead is stripped away (no three-way handshake like TCP). The listener is also very simple to implement in the host. The client is even more simple. Furthermore, it enhances the notion that all bundles are and should be independent. So no session management and state is needed in the host. It also makes broadcast possible, but I think most hosts do not set the right socketoptions to their listening-sockets (SO_BROADCAST) to do this.
But you could create a simple converter service to repackage http to UDP. Chances are that somebody else already did this.
I’m afraid this doesn’t help, but maybe it explains it a little
OSC was intended for real time continuous control and so UDP made more sense though I must admit I never quite understood what one was supposed to do if a lost packet was in fact the packet to stop a sound.
That is indeed the problem with OSC. There are not really protocols how to handle these issues. However, in wired LANs the packet loss is really very low, especially since nowadays only switches instead of hubs are being used, and when it comes to local addresses (the same host), the network equipment is not being used at all and there is no packet-loss.
BTW, The original midi (serial 31250 baud) doesn’t have countermeasures for bit-loss either.
The only protocol to make-up for these shortcomings is procedural: When something fails, the user has to press the button or move the pedal again.
The advantage using tcp would be that the client would eventually get noticed that the message transfer failed. Could take easily 30 seconds. That would ruin the real-time characteristics anyway. Midi tried to solve this by sending heartbeats (0xFE ‘active sensing’ I think). (Oh happy days, cause many(?) midi-receivers do not handle these somewhere-in-between-messages too well, and thereby causing loss of midi messages).
One important characteristic of UDP if forgot to mention: UDP datagrams are not guaranteed to be received in the same order as they were sent originally. That means that OSC messages that should be processed in a particular order should be in the same bundle.
This is however, not a big problem: when there is just one path from the client to the host (as in most home networks), messages are not likely to be reordered. Home LANs are mostly only layer 2 of the OSI model (except for the connection to the internet), so between the clients and hosts in the home network there are no routers involved.
Over the internet is a whole different thing: a provider may choose to route one message using upstream router A and the next using router B. In that case, when router A follows a path that takes longer than the path followed by router B, the second message will arrive before the first. TCP, within the same connection that is, uses a serialnumber for the packets and will present the messages in the original order.
And now you know several things you never really wanted to know.
@dhj Does Gigperformer send each OSC message in its own bundle, does it use no bundle at all, or are they bundled in some way, for instance bundling all messages that are submitted during one event/callback (in a script) by Gigperformer?
Thanks for the feedback, everyone. My main reason for desiring OSC over TCP in GP is much less to di with the guaranteed delivery of packets and much more so that I could program an app in a browser without needing to create some kind of proxy to convert from WebSockets to UDP. I’ll likely have to re-evaluate how exactly I’m going to best achieve what I’m after.
Just thinking off the top of my head here. Is there possible win here if I created a GP extension that listened for WebSockets over TCP and forwarded the command internally and replied with the resulting data? I realise this might require some mapping of the existing GP OSC commands to the extension API equivalents. I’m mostly thinking about convenience and not having to run a proxy program alongside everything else.
In a wired LAN environment I wouldn’t worry too much about guaranteed delivery. When you want to collaborate with other musicians over the internet, that would be an entirely different case that could be solved by using a shared vpn (which might introduce its own can of worms).
BTW, creating a local webserver for converting OSC messages in http-posts to plain UDP is not very hard to do. The other way around is more difficult.
As far as I know GP doesn’t send OSC bundles, but of course the OSC bundles like those sent by the RME audio interface virtual mixer, TotalMix Fx, are perfectly received.
Yeah, some stuff is sent as bundles - it’s a bit haphazard though - really depended on what was being sent. There are some things that are not sent as bundles but should be — for example the SongList is not sent as a bundle but should be. I’ve been quietly changing some of these things as I notice them.
I probably focused on the GPScript ability to send OSC bundles. But whatever, with or without OSC bundles, my tests have shown that GP is very solid even with a very high OSC traffic (when not using a faulty hardware ). And as mentioned by @Frank1119, the way we usually use OSC is most of time almost equivalent to a direct straight peer-to-peer IP connection where we shouldn’t be faced to issues where OSC bundles are very necessary. But, well, if at a time we get the possibility to use OSC bundles with GPScript, I will make use of them for controlling my mixers.
Maybe sending bundles could be implemented by sending arrays of OSCmessage-s (when sending messages from script). But in a wired LAN environment I think bundles aren’t very important, I agree.
Thank you @Frank1119. I have seen those whilst Googling the issue. I may well end up using a bridge, but was hoping to avoid the use of an extra item of intermediate software.
I understand that. As few layers as possible. However, when you want to receive also incoming OSC messages, like Vu-meters, you need an in-between anyway to keep track of the state. The only other option would be GP acting like a webserver, but that would complicate things a lot and is not really the main business of GP.
In the software realm it is not unusual to separate responsibilities in separate programs or services. In the end most of the time the drawbacks of a layered approach does not outweigh the benefits and stability it offers. OS-es take the same approach. It is stunning when you realize how many software layers a byte goes through before it is stored on your disk, but still, despite of these layers, disks are not too slow. (Of course disks are always too slow from a user-perspective .) This comparison is a bit lame, I’m afraid, but I hope you get what I’m trying to say.
). And as mentioned by 
.) This comparison is a bit lame, I’m afraid, but I hope you get what I’m trying to say.