Skip to content

udp recived packets number #2928

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
el3ctrician opened this issue Feb 4, 2017 · 10 comments
Closed

udp recived packets number #2928

el3ctrician opened this issue Feb 4, 2017 · 10 comments
Labels
waiting for feedback Waiting on additional info. If it's not received, the issue may be closed.

Comments

@el3ctrician
Copy link

hello,
i would like to know if there is a way to get the number of packets in udp buffer and also to set the packet len according to the payload ?

thanks in advance

@wuwx
Copy link
Contributor

wuwx commented Feb 6, 2017

did you mean this:

int packetSize = Udp.parsePacket();

@el3ctrician
Copy link
Author

nope, according to the header file WiFiUdp.h this wuold return the size of the packet in bytes. I think it's refearing to the first packet. So my question is how can i get the total number (and not size) of packets recived in the Udp buffer ?

@el3ctrician
Copy link
Author

@igrr if it's not implemented i can try to do if you can kindly guide me from where should i start ?

@igrr
Copy link
Member

igrr commented Feb 10, 2017

Take a look at UdpContext.h. There is a pbuf chain there, you can add a method to count the number of pbufs in the chain.

@devyte
Copy link
Collaborator

devyte commented Sep 9, 2017

@el3ctrician did you get around to implementing this? do you want to make a PR?

@devyte devyte added the waiting for feedback Waiting on additional info. If it's not received, the issue may be closed. label Sep 9, 2017
@el3ctrician
Copy link
Author

@devyte i didn't have enough time to do it since the project that i was working on got cancelled, but i would like to try to implement it so maby i'll fork the code for a try this weekend ...

@devyte
Copy link
Collaborator

devyte commented Mar 29, 2018

Ok, post results or ask questions here.

@el3ctrician
Copy link
Author

el3ctrician commented Mar 29, 2018

well actually i just saw that the pbuf in the udpContext, it is a linked list right ? i need to count by checking the pbuf.next right? or even here https://github.com/esp8266/Arduino/blob/4897e0006b5b0123a2fa31f67b14a3fff65ce561/tools/sdk/lwip/include/lwip/pbuf.h
i see a method for the length i think it would be enough ... well test any way

@d-a-v
Copy link
Collaborator

d-a-v commented Mar 30, 2018

The pbuf api is lwip's.

WiFiUdp through UdpContext makes use of it: _recv() is called when a packet is received, filling _rx_buf which is a pbuf, using pbuf_cat(). It makes the pbuf grow and it does not chain (in the linked list way) the new incoming data. So pbuf->len == pbuf->tot_len and next is always null.

The notion of packet is then wiped out showing udp's incoming data to the user as a stream, which is what it really is (class UDP: public Stream) but not compatible with the "datagram" way of thinking with udp.
Is that your initial concern ?

If this had to be changed, pbuf_chain() would have to be used instead of pbuf_cat() along with the linked list management. That would put malloc under less stress and restore the notion of packet if this had to be needed.

edit: the notion of packet bounds with the linked list would be trivial, albeit still doable in the current implementation with some way to remember these bounds.

edit2: you may check @me-no-dev's AsyncUDP implementation which keeps the notion of packet.

@devyte
Copy link
Collaborator

devyte commented May 14, 2020

I am closing this due to age and lack of feedback.
If there is still an idea to be contributed regarding this topic, please open a new issue, follow the template instructions, and explain the idea in detail.

@devyte devyte closed this as completed May 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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

5 participants