Andy's Workshop Forums

General Category => stm32plus C++ library => Topic started by: Ozflip on November 09, 2014, 06:35:14 pm

Title: Obtaining the IP of the sender of a UDP packet
Post by: Ozflip on November 09, 2014, 06:35:14 pm
First - If I'm asking too many questions, please let me know and I'll quiet down!

I'm wondering what the correct (anticipated by you) means of getting the sender of a UDP packet is? We need the sender to know who to reply to!  ;D

For a TCP packet you have provided the sender in the event, but not for the UDP asynchronous receive event.

At the moment the only obvious way I can see is to subscribe one level down to the network layer onReceive and then decode the packet and verify the type and port manually, or modify the source for the UdpdatagramEvent and udp to include the source address.

Or (more likely) am I just thick and missing something obvious?

Thanks,

Phil
Title: Re: Obtaining the IP of the sender of a UDP packet
Post by: Andy Brown on November 10, 2014, 02:53:23 pm
Nope, you're right, this is an omission. The IP header information should have been made available by the UDP module to both the async event API and the sync method API. I've fixed both APIs and pushed to master. See issue and commit (https://github.com/andysworkshop/stm32plus/issues/68"). The examples have been updated to report the sender IP address.

When you do send a reply, do make sure you're not doing it from the async UDP event handler because you're in an IRQ context there. It's best to take what you need from the incoming event and set a 'ready' flag for your main non-IRQ loop like the demo code does.

No such thing as too many questions; the library is improving because you're reporting your experiences. By all means keep them coming.
Title: Re: Obtaining the IP of the sender of a UDP packet
Post by: Ozflip on November 11, 2014, 12:28:25 am
Fantastic - thank you. It works like a charm.

QuoteWhen you do send a reply, do make sure you're not doing it from the async UDP event handler because you're in an IRQ context there
Definitely, and the other concern is that (like any interrupt) you want to keep it quick. A slow handler runs the risk of losing the next packet, too.

Again - thank you. I really love this stack implementation.

Phil