i’ve got a simple patch acting as a receiver for simple OSC messages arriving with high frequency (around 50 fps) over wired ethernet connection. works totally fine but after a few hours the server seems to queue up messages and spit them out with a very noticable delay (increasing with time and growing from seconds to minutes).
it looks like the problem is on the VVVV side as even after a phyiscal disconnect of the sender the messages arrive (until the internal queue is empty?). or might it even be the OS doing these things?
interestingly, dis/enabling the OSC Server does not help - a noticable delay stays there even after all messages have arrived, no messages are being send and i restart sending. however, with a restart ( F8/F5) all is good again.
i looked inside the nodes but could not really see where this queuing up would happen. UDP messages keep arriving at the UDPServer even after disconnecting the sender. my understanding also would be that udp messages not processed immediately would just be dismissed.
what would you suggest to further debug this (which is quite timeconsuming because one has to wait a few hours until this happens)?
what are possible workarounds? putting the whole receiver logic in a ManageProcess region and periodically restart the receiver?
some clarifications to the post before:
usually when de/enabling the oscserver one can see the port closing/opening in TCPView. not this last time, the port stayed open even when oscserver was disabled. reenabling it opened it a second time…
well, this also happens when the sending framerate is slower than the patch framerate (initially had 50fps send rate vs. 60fps patch rate (but several messages that are sent at once with each transmission).
my mental model of all this that the patch is supposed to process all received messages in a frame (that’s what the reactive sampler does). if, for some reason, the receiver cannot keep up i’d expect the receiver to discard the messages (like it is common with UDP messages on the internet) and not queue them up. if this was the case, i’m missing some kind of flush option to clear the queue. also there is no indication that arrived messages are “out-of-sync”.
still, i’m not 100% sure where this “queuing” like behaviour happens (network, OS or patch level) and would have to do more experiments to rule out possible responsible components.
switching to a UDPServer and looking at the raw OSC data shows that the messages arrive immediately (i kind of manually filtered and decoded the OSC messages to have proof)
when switching back to the OSCServer the delay is still there. however i noticed the following: reducing the no of simultanously sent OSC messages with different topics (on the sending device) to only one makes the delay disappear. increasing the number of sent topics again makes the delay appear again.
my takes from this are:
UDPServer works fine
OSC receiving logic has some issues when it has to process several different OSC messages with different topics arriving at the same time (after a while).
for now i will probably fall back to sending raw UDP messages and do manual decoding on VVVV side because of this behaviour (which is unfortunate as using OSC would make life much easier for some scenarios…)
edit: still have to check whether sending only one topic does not cause any problems…
here is a little stress-test for sending and receiving osc messages.
watch the received messages and see how the reception quality degrades over time. on my machine first the no of received messages in higher topics drops, (much later) this applies to all topics and even a delay becomes apparent.
please check and also look at the test-design (whether it makes sense). OSC_Stresstest.vl (39.5 KB)
thanks for the extensive report. we may have found the issue. please try with latest VL.IO.OSC 1.0.7. with it, when receiving more messages than can be handled, you should see a “dropping” rather than a “queueing” behavior (as you initially also anticipated). please report if this solves your issue.
(unrelated: also added an “Address” output to the OSCReceiver nodes, where you can see the learned address)
thanks for the quick fix, will run a longer test tomorrow and report!
regarding the address learning: for me there is no address output pin but rather the learned topic is written into the addres INPUT pin of the OSCReceiver. what’s odd: rightclick->configure->“show address” does not have an effect (pin is not shown/hidden). may be some kind of internal conflict?