Open ajanhalt opened 2 years ago
It's a long time since i read the MDNS RFC... Trying to remember how this fits together. Please feel free to nudge me in the right direction if i'm not getting this right.
So this would parse an mdns::Answer
object right?
And pull just the IP address from it?
Sounds like a useful helper function.
What about a new source file helpers.h
and helpers.cpp
Probably worth an example on how to use it in the examples
folder.
I don't think the source IP is in any of the data structures. This would get the source IP for the packet from Udp.remoteIP(). From what I got out of the spec, if the unicast response flag is set in the query, the answer packet may be sent as a unicast not multicast response.
Anyway, it's just a one line function so I was going to implement it right in the mins.cpp code. I could probably put it in the mdns_test example to show the source IP of the answer packet.
I sent before finishing the thought. Sending unicast responses will also require a separate SendUnicast(IPAddress) function. The library can't decide by itself whether the answer is unicast or what address to send it to.
ah. so the same packet format is used for unicast updates? that makes some sense. as long as this library gets access to the raw packet data, how it gets it should not matter. it should work for Unicast too.
for your getRemoteIP()
function though,
the MDNS server's Unicast address needs to be a different address to it's Multicast address.
if the Unicast source IP isn't in the MDNS packet how do you intend to get it?
i feel like i am missing a piece of your concept.
oh. the MDNS server might reply Unicast to the ESP's Multicast response? so you need to be listening for that?
i obviously need to go read the RFC again. give me a few days.
The original query packet has the real source IP address with a multicast destination address. The answer packet from the MDNS library can be sent either to the multicast address or the unicast address based on that flag. In the esp core implementation, if you start listening for multicast packets on a port, you also receive unicast packets as long as they're sent to the same port. Makes things simple There's actually a udp.destinationIP function that you can use to see if the packet was sent to the unicast or multicast address but we don't care in this case.
Section 5.4 of the RFC (6762) covers the unicast flag. It just says the querier is willing to accept unicast responses or multicast responses. Using the unicast response just cuts down on the number of machines on the network that have to look at the packet.
ok. sounds like a sane addition. And since you are using this project and i am not, i'm happy to have this in principal.
Thanks. I'll add an example of a simple MDNS responder that selects unicast or multicast response based on the flag.
i forgot all about this. i just merged your changes. apologies for taking so long.
The MDNS spec section 5.4 details the ability for queries to request a unicast reply to cut down on multicast traffic on the network. Add a function to send a unicast answer instead of multicast packet