mrdunk / esp8266_mdns

mDNS queries and responses on esp8266
MIT License
77 stars 16 forks source link

Need ability to send unicast MDNS answers #18

Open ajanhalt opened 2 years ago

ajanhalt commented 2 years ago

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

mrdunk commented 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.

ajanhalt commented 2 years ago

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.

ajanhalt commented 2 years ago

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.

mrdunk commented 2 years ago

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.

mrdunk commented 2 years ago

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.

ajanhalt commented 2 years ago

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.

ajanhalt commented 2 years ago

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.

mrdunk commented 2 years ago

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.

ajanhalt commented 2 years ago

Thanks. I'll add an example of a simple MDNS responder that selects unicast or multicast response based on the flag.

mrdunk commented 9 months ago

i forgot all about this. i just merged your changes. apologies for taking so long.