mDNS for device discovery in IOT Protocols - Step-by-Step Execution

Process Flow - mDNS for device discovery

Device powers on

↓

Device sends mDNS query

↓

Network receives query

↓

Devices with matching service respond

↓

Original device collects responses

↓

Device lists discovered devices

↓

Discovery complete

This flow shows how a device uses mDNS to find other devices by sending a query and collecting responses on the local network.

Execution Sample

IOT Protocols

1. Device sends mDNS query for '_http._tcp.local'
2. Devices with HTTP service respond with their info
3. Device receives responses and lists devices

This example shows a device discovering HTTP services on the local network using mDNS queries and responses.

Process Table

Step	Action	Message Type	Content	Result
1	Device powers on	N/A	N/A	Device ready to discover
2	Send mDNS query	Query	Service: _http._tcp.local	Query broadcast on local network
3	Network receives query	Query	Service: _http._tcp.local	Devices check if they offer this service
4	Matching device responds	Response	Device name: Printer.local, Service: _http._tcp.local	Response sent back to querying device
5	Another device responds	Response	Device name: Camera.local, Service: _http._tcp.local	Response sent back to querying device
6	Device collects responses	N/A	2 responses received	Device updates discovered devices list
7	Discovery complete	N/A	Discovered devices: Printer.local, Camera.local	Device ready to use discovered devices

💡 All responses received or timeout reached, discovery ends

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 5	After Step 6	Final
discovered_devices	[]	[]	[Printer.local]	[Printer.local, Camera.local]	[Printer.local, Camera.local]	[Printer.local, Camera.local]
query_sent	False	True	True	True	True	True
responses_received	0	0	1	2	2	2

Key Moments - 3 Insights

Why does the device send a query instead of just listening for devices?

The device actively sends a query (see Step 2 in execution_table) to ask who offers the service, because devices only respond when asked, not continuously broadcasting.

How does the device know when discovery is complete?

Discovery ends after receiving all responses or a timeout (exit_note). Step 7 shows the device listing all discovered devices after collecting responses.

Can devices respond if they do not offer the requested service?

No, only devices that match the service in the query respond (Step 4 and 5). Others ignore the query.

Visual Quiz - 3 Questions

Look at the execution_table at Step 4, what does the responding device send back?

A A response with device name and service info

B A query for services

C An error message

D No message

💡 Hint

Check the 'Message Type' and 'Content' columns at Step 4 in execution_table

At which step does the device update its list of discovered devices?

A Step 2

B Step 3

C Step 6

D Step 7

💡 Hint

Look at the 'Result' column in execution_table for when responses are collected

If no devices respond to the query, what will the 'discovered_devices' variable contain after Step 6?

A List with one device

B An empty list []

C List with two devices

D Null value

💡 Hint

Refer to variable_tracker row for 'discovered_devices' and consider no responses received

Concept Snapshot

mDNS lets devices find others on the local network by sending queries.
Devices respond only if they offer the requested service.
The querying device collects responses to build a list of available devices.
Discovery ends after responses or timeout.
Used for zero-configuration device discovery.

Full Transcript

mDNS for device discovery works by a device sending a multicast DNS query on the local network asking for devices offering a specific service, such as HTTP. Devices that provide this service respond with their name and details. The querying device collects these responses and lists the discovered devices. This process ends after all responses are received or a timeout occurs. This allows devices to find each other without manual setup.

Practice

1. What is the main purpose of mDNS in device discovery?

easy

A. To assign IP addresses to devices on the internet

B. To allow devices to find each other automatically on the same local network

C. To encrypt communication between devices

D. To connect devices over long distances using satellites

Solution

1. Step 1: Understand mDNS function

   mDNS stands for multicast DNS and is used for local network device discovery without a central DNS server.

2. Step 2: Identify the correct purpose

   It helps devices find each other automatically on the same local network using multicast messages and .local names.

3. Final Answer:

   To allow devices to find each other automatically on the same local network -> Option B

4. Quick Check:

   mDNS = local device discovery [OK]

Hint: mDNS is for local network device discovery only [OK]

Common Mistakes:

• Confusing mDNS with DHCP for IP assignment
• Thinking mDNS encrypts data
• Assuming mDNS works over the internet

2. Which of the following is the correct syntax to query a device named printer.local using mDNS on a Linux terminal?

easy

A. mdns-query printer.local

B. mdns-scan printer.local

C. dnslookup printer.local

D. ping printer.local

Solution

1. Step 1: Identify common mDNS query commands

   On Linux, mDNS names like printer.local can be resolved using standard commands like ping or avahi-resolve, but ping is simplest.

2. Step 2: Check command validity

   Only ping printer.local is a valid and common way to test mDNS name resolution; others are not standard commands.

3. Final Answer:

   ping printer.local -> Option D

4. Quick Check:

   Use ping with .local names for mDNS queries [OK]

Hint: Use ping with .local names to test mDNS resolution [OK]

Common Mistakes:

• Using non-existent commands like mdns-query
• Confusing DNS lookup tools with mDNS
• Forgetting the .local suffix

3. Given this Python snippet using zeroconf library to discover mDNS services, what will be printed if a device named 'lamp.local' is found?

from zeroconf import Zeroconf
zeroconf = Zeroconf()
services = zeroconf.get_service_info('_http._tcp.local.', 'lamp._http._tcp.local.')
if services:
    print(services.server)
else:
    print('No device found')

medium

A. No device found

B. lamp.local

C. lamp.local.

D. lamp._http._tcp.local.

Solution

1. Step 1: Understand zeroconf get_service_info output

   The get_service_info method returns a ServiceInfo object with a 'server' attribute that ends with a dot, e.g., 'lamp.local.'

2. Step 2: Analyze the print statement

   If the device is found, services.server prints the full hostname with trailing dot, so output is 'lamp.local.'

3. Final Answer:

   lamp.local. -> Option C

4. Quick Check:

   zeroconf server attribute ends with dot [OK]

Hint: zeroconf server names end with a dot '.' [OK]

Common Mistakes:

• Omitting the trailing dot in hostname
• Confusing service type with hostname
• Assuming no device found when device exists

4. You tried to discover devices using mDNS but got no results. Which of these is the most likely cause?

medium

A. The devices are on a different subnet without multicast routing

B. The devices have static IP addresses

C. The devices use HTTPS instead of HTTP

D. The devices have firewalls disabled

Solution

1. Step 1: Understand mDNS network scope

   mDNS works only within the same local network segment (subnet) because multicast packets are not routed across subnets by default.

2. Step 2: Identify why no devices found

   If devices are on a different subnet, mDNS queries won't reach them, causing no discovery results.

3. Final Answer:

   The devices are on a different subnet without multicast routing -> Option A

4. Quick Check:

   mDNS limited to local subnet without routing [OK]

Hint: mDNS only works within the same subnet [OK]

Common Mistakes:

• Thinking static IPs block mDNS
• Confusing protocol type with discovery issues
• Assuming firewalls off always helps discovery

5. You want to set up a smart home device to be discoverable via mDNS with the name smartlight.local. Which configuration step is essential to ensure correct mDNS discovery?

hard

A. Configure the device to advertise its service using the mDNS protocol with the hostname smartlight.local

B. Assign a public IP address to the device

C. Disable multicast on the device's network interface

D. Set the device's DNS server to 8.8.8.8

Solution

1. Step 1: Understand mDNS advertisement

   For a device to be discoverable via mDNS, it must broadcast its hostname and service on the local network using mDNS protocol.

2. Step 2: Identify correct configuration

   Setting the device to advertise as smartlight.local via mDNS is essential; public IP or external DNS settings do not affect local mDNS discovery.

3. Final Answer:

   Configure the device to advertise its service using the mDNS protocol with the hostname smartlight.local -> Option A

4. Quick Check:

   mDNS requires local service advertisement [OK]

Hint: Device must advertise its mDNS hostname locally [OK]

Common Mistakes:

• Assigning public IP instead of local mDNS name
• Disabling multicast which breaks mDNS
• Using external DNS servers for local discovery