UDP Tx/Rx problem between Juce Apps


#1

Hi all!

I couldn’t find anything useful - maybe it’s unusual to have two juce apps running simultaneously? Here’s the story:

I have an app JuceA sending udp heartbeat-packets every second to some recipients (embedded hardware) on Port 1000. This is working well for years now.
Also I can monitor the incoming packets with an app called “packet sender” (very handy third party networking utility) when I run JuceA with a 127.0.0.1 recipient configured.

Now I wrote a monitor app JuceB that can receive that same data to display it in a way as it would look on the hardware. (just for debugging and preparation of JuceA)

If I start JuceB and use the “packet sender” to generate and send it packets, it behaves exactly as expected.

So far so good, JuceA and JuceB seem to run correctly.

But when I use them both (on the same machine, SurfacePro4/W10), nothing happens at JuceB. Just no packets are received.

And here’s the funny part:
When I additionally kick in the “packet sender” and send dummy packets with it, then sometimes the content of a JuceA packet is displayed (visually distinguishable in JuceB).
Not proven, but it seems to take one third party packet to receive one juce packet.

Debugging JuceB, I could prove that socket.read(buf, 40, false) continuously returns 0 in the receiving thread’s run() loop, unless “packet sender” is talking.

The same happens if I use the local IP instead of 127.0.0.1.
Port numbers below 1024 are tricky (can’t bind without root on some systems), but cant’ be an issue here as it is receiving from the “packet sender”.

Any ideas of internal triggers that are excluding each other when run on the same machine? Some systemwide juce singletons or shared buffers that get scrambled when there is a second instance of juce (though a different app)?

Thanks for any hints!
Well, my main app is working flawlessly at least - but I’d like to start using my new tool :grin:


#2

Hmmm that’s odd. Are you sure you have all the ports correctly? With any IP packet (UDP or TCP) each participant has a source and destination port. There should be four port numbers in total (2 for JuceA, 2 for JuceB), right?


#3

Yes, but the outgoing port numbers are ignored in most use cases - at least I don’t care in my apps…
I guess the problem is on the receiving side as packets are sent obviously (can track packets, and my hardware gets them, too)


#4

is the receiver trying to connect to the same port that the broadcaster is sending them from, I’m fairly certain with JUCE these ports will need to be different when connecting a local host, whereas they wouldn’t have to be for an external device.


#5

As far as I know, it’s quite hard to even get influence on the outgoing port. It will be chosen by the OS at construction time.
What irritates me is that packets do get recognised when I crossfire with the “packet sender”…

Nobody else made apps locally communicating over UDP?


#6

I have, but only indirectly using the OSCSender and OSCReceiver classes. I thought I remembered seeing an issue regarding ports for local hosts only but I just created some test apps and I’m obviously remembering incorrectly.


#7

Ah ok… So it worked out of the box?
And did you use the osc stuff too in your recent test-apps, or DatagramSockets?
Would be a good trace if it worked for osc…


#8

Yeah I used OSC and it worked, however one odd thing I did notice when trying to use port 1000 is that it never reported that it didn’t connect the sender but it did the report that it couldn’t connect the receiver. When I switched to port 9001 both connected just fine.