udp->endPacket() is silently dropping packets

[everslick]

This issue is a followup from #1009 (comment)

when rapidly sending UDP packets, udp_sendto() (called from libraries/ESP8266WiFi/src/include/UdpContext.h:286 will not report an error, if it silently drops the packet for whatever reason (buffer allocation?).

even though UDP is inherently 'unreliable', the API should still report internal errors if possible, so users of the API can deal with them.

[electron1979]

May be related to my problem. Issue #2340

[lovelesh]

@igrr @everslick
I am trying to send only 64 Byte packets, only first 37 bytes gets transmitted. But sometimes I am able to read all 64 Bytes.

I tried yield() and delay(1) as per your suggestion. Is there any definite for reliable transmission atleast from the device side.

[everslick]

IMHO there is something else wrong with your code. even though the UDP
stack does not report errors when sending packets too fast, it always sends
complete datagrams as long as they are below the max frame size (~1400
bytes ???). I use UDP a lot and I have never seen shortened or corrupted
datagrams. nevertheless UDP is unreliable per definition (packets might get
lost on the wire) and if you need reliability you should switch to TCP.

[devyte]

@everslick is this issue still valid in latest git? Does PR #3362 (lwip2) help?

[igrr]

Yes it is still valid. The root cause is in the SDK, but i would like to keep this open for now.

[everslick]

This will need some time for me to check. I completely switched to ESP32. But I will have a look.

[d-a-v]

The udp.endPacket() always returning 1 problem seems to be fixed with lwip2 (see #3481)
@lovelesh If you could post your sketch in which you don't receive all your sent data, we can test it with lwip2.

[lovelesh]

@d-a-v i solved this problem by increasing the buffer in the lwip library based on solution provided in some discussion. Its working fine, so i didnot bother much.