Martin Peach wrote:
Roman Haefeli wrote:
Martin Peach wrote:
Yes, and [unpackOSC] has no way of knowing if it is getting data from UDP or TCP so it should probably assume the worst and go for TCP. In fact, to be unbreakably robust it should assume it is getting input one byte at a time and not output anything until either an entire OSC packet has been received or the packet is not valid OSC.
this is how i would like [unpackOSC] to behave. i don't see any other way to do OSC over tcp.
I think opening a bundle and putting all the simultaneous messages in it, then closing the bundle and sending it, will work over tcp.
i did some test sending a file (over localhost). the limit seems to be at 65536. my test file is 49474 but i usually received 2 packets, rarely one single packet with 49474 bytes, sometimes even 3 packets.
i guess this behaves the same for normal send messages (not whole files) it could be a real problem since we can't really tell if a bundle is complete.
eni