ESP8266 Community Forum

- Sun Mar 25, 2018 11:24 am #74907 I admit my contact with multicast was not in the local segment but rather ip-tv streaming and I recall we even had to run special proxies on our routers, the standard fw would not suffice to bring the incoming packets to the connected clients. So maybe depending on your wifi-router-modem firmware your local experience may vary.
But definitely, for the mentioned purpose, broadcast is the intended protocol.
Maybe this aritcle sheds some light
https://en.m.wikipedia.org/wiki/Multicast

- Sun Mar 25, 2018 12:19 pm #74908

I admit my contact with multicast was not in the local segment but rather ip-tv streaming

And that is one application of multicast, with a lot more layers. It is not how multicast works on a packet basis.

https://en.m.wikipedia.org/wiki/Multicast

Ethernet frames with a value of 1 in the least-significant bit of the first octet of the destination address are treated as multicast frames and are flooded to all points on the network. This mechanism constitutes multicast at the data link layer. This mechanism is used by IP multicast to achieve one-to-many transmission for IP on Ethernet networks. Modern Ethernet controllers filter received packets to reduce CPU load, by looking up the hash of a multicast destination address in a table, initialized by software, which controls whether a multicast packet is dropped or fully received.

But definitely, for the mentioned purpose, broadcast is the intended protocol.

https://en.wikipedia.org/wiki/User_Datagram_Protocol

Broadcasts - being connectionless, UDP can broadcast - sent packets can be addressed to be receivable by all devices on the subnet.

mDNS uses multicast udp because of the broadcast capability. It puts out a query and then devices that are looking at that designated IP and port see the message and they respond. It is a partyline. When a mDNS query goes out there is no single recipient. It is an IP and port that can be watched if any device chooses to.

In an above post I included a full sketch that watches and prints out all packets received on the IP and port used by the mDNS protocol. There was no registration or notification to a transmitter for it to be allowed to receive the packets. It is the same as a radio tuning into a frequency of a radio station. The transmitter is unaware of the receiver.

UPnP is another protocol that uses multicast UDP as a service discovery protocol because of the broadcast capability.

- Sun Mar 25, 2018 2:23 pm #74911 especially your analogy with the radio station makes me again think of ... tada ... broadcast.

there is a difference between ethernet-multicast and IP-multicast.
[part deleted, here your mDNS based argument as multicast example was missunderstood by me for doing datatransfer]

but every article I find on the net on the topic of multicast vs. broadcast boils down to:
The transmission technologies broadcast and multicast are different from each other in a context that in the broadcast, the packet is forwarded to all the hosts connected to the network whereas, in multicast, the packet is forwarded only to intended recipients.

Edit: ah, this sheds some light (at least for me) on the "register/subscribe" topic
A multicast IP address is in the range 224.x.x.x-239.x.x.x. The server picks an address in this range to send to, and each client registers to listen on that multicast address. Also, when a client registers to listen to a multicast address, the network stack automatically sends out an IGMP message to inform the local router. If the router is so configured, it will propagate that message to other routers. Then, when the server send out a multicast packet, the LAN sends it to any local host that is listening, and the local router will also pass it on if it knows of any listeners beyond it. In practice, most routers won't route multicast packets or IGMP messages, so multicast is typically restricted to the local LAN unless you configure the routers to allow it.
this is what I had in mind on my previous post, the process of "subscribing" to the transmitter or its proxy (closest to you: your router), but as it is done by the (ip)stack, it is transparent but still: needs the router to be able to cope with for e.g. ip-tv streaming

- Sun Mar 25, 2018 6:13 pm #74916

what I had in mind on my previous post, the process of "subscribing" to the transmitter or its proxy (closest to you: your router), but as it is done by the (ip)stack, it is transparent

I'm glad we cleared up the fact that the transmitter is totally unaware of any receivers listening.

When I first looked at UDP multicast I couldn't figure out where the addresses of the receivers were supposed to go in the sent packet. I thought maybe it was in a lower level and somehow managed with the subscriptions. But I still couldn't find it, then I found out that there is no connection between the sender and the receiver. That the subscription is all done at the receiving end.

What also makes things confusing is that most of the information tends to be in terms of public networks and not as much about a local only implementation.