Skip to content

udp->endPacket() is silently dropping packets #2285

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
everslick opened this issue Jul 16, 2016 · 12 comments
Closed

udp->endPacket() is silently dropping packets #2285

everslick opened this issue Jul 16, 2016 · 12 comments
Assignees
Labels
component: libraries type: bug waiting for feedback Waiting on additional info. If it's not received, the issue may be closed.
Milestone

Comments

@everslick
Copy link
Contributor

everslick commented Jul 16, 2016

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
Copy link

electron1979 commented Sep 29, 2016

May be related to my problem. Issue #2340

@lovelesh
Copy link

lovelesh commented Nov 2, 2016

@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
Copy link
Contributor Author

everslick commented Nov 2, 2016

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
Copy link
Collaborator

devyte commented Oct 15, 2017

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

@devyte devyte added the waiting for feedback Waiting on additional info. If it's not received, the issue may be closed. label Oct 15, 2017
@igrr
Copy link
Member

igrr commented Oct 15, 2017

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

@everslick
Copy link
Contributor Author

everslick commented Oct 15, 2017 via email

@d-a-v
Copy link
Collaborator

d-a-v commented Nov 18, 2017

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
Copy link

@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.

@devyte devyte modified the milestones: 2.5.0, 2.6.0 Jan 7, 2018
@albymor
Copy link

albymor commented Feb 1, 2019

@lovelesh could you specify which buffer did you modify?

@everslick
Copy link
Contributor Author

I'm good with closing this issue. I can confirm, that LwIP2 has this fixed.

@d-a-v
Copy link
Collaborator

d-a-v commented Feb 7, 2019

I'm good with closing this issue. I can confirm, that LwIP2 has this fixed.

Thanks for your feedback!

@lovelesh Which buffer did you modify ?

@d-a-v
Copy link
Collaborator

d-a-v commented Aug 28, 2019

Closing for the same reason as for #1988.
Please open a new issue if it is still relevant with current git master version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: libraries type: bug waiting for feedback Waiting on additional info. If it's not received, the issue may be closed.
Projects
None yet
Development

No branches or pull requests

7 participants