Unreliable UDP: crashes/freezes when sending at high frequency

[SomeFixItDude]

@psb777 Couldn't agree with you more.

@psb777

only UDP-compliant intention of those who specified the interface to the UDP class) that the purpose of the endPacket() call was to allow a packet to be assembled by multiple calls to UDP.write() and that nothing would be sent until endPacket() was called. Any other behaviour means that Spark UDP is fundamentally broken.

@SomeFixItDude

Anomaly 1: I don't seem to ever need to call Udp.endPacket(); If I call the Udp.write(char) method, I can not call it it multiple times to assemble the message I want. Instead each call to Udp.write(char) writes out a new datagram and it is delivered right away. I was expecting that... I would do beginPacket, write, write, write, endPacket and then the packet is sent. In this case you would have sent 3 packets. In order to send one datagram I need to have my own buffer/array and pass the Udp.write(buffer, size).

I think the frustrating part is that I don't perceive any movement. The core supports tcp and udp, and udp does not work as intended. That is a huge amount of functionality down the drain. I also am opposed to resetting the core when the core loses connection with cloud. There must be a more graceful way than stopping execution and starting over. Yes I understand it is only a temporary solution to keep code executing, but temporary becomes permanent all too quick. Many of my projects I am trying to use broadcast and discovery and it is very hard to implement when the boundaries are lost. This means I have to include source ip in the packet itself and I am not sure how many bytes each datagram is. So you have to send the exact same number of bytes for every datagram.

All I see is on waffle that these problems are way on the back burner for UDP under ideas. CFOD when you can't run for more than 15 minutes without a reset is a serious problem and makes the spark core unusable.