Why does OpenBMC use Avahi mDNS instead of SSDP?
Richard Hanley
rhanley at google.com
Fri Apr 17 10:42:37 AEST 2020
>
>
> > >> mDNS is used more in the UNIX world, SSDP is used more in Windows.
> > >>
> > Was on the Redfish call earlier and this forum thread was discussed. The
> > Redfish members on the call did not totally agree with this statement.
> > They believe SSDP has a wider adaption than just Windows. A wider
> > adaption than mDNS. Since SSDP is already in the Redfish specification
> > and has been adapted by Redfish implementations, adding a 2nd discovery
> > service would damage interoperability in Redfish.
>
> I'm not really interested in a debate on this point, but I'm not finding
> much evidence to back it up. Can anyone point to well-used OSS
> implementation of SSDP? The only thing I can find is gssdp, which seems
> to require a lot of Gnome components; not something we could easily pull
> in on the BMC.
>
> The only thing besides gssdp is this
https://github.com/troglobit/ssdp-responder, but that's only one
(presumably easier) half.
> > The members on the call really wanted to encourage OpenBMC to implement
> > SSDP instead.
>
> It probably isn't a bad thing to be able to support SSDP, don't get me
> wrong, but "instead"? Why would we want to take away service
> advertisement functionality, unless someone wants to explicitly disable it?
>
> I can understand if they don't want to document, in the standard, a way to
> advertise the Redfish service over mDNS, but isn't that a different
> problem from what we're asking for? Aren't we asking for a method to
> manage the enablement of services on the BMC, specifically our mDNS
> service? So, if we still have mDNS, don't we need a way to configure it
> through Redfish?
>
> I see your point here. I guess there might be some implicit assumption
that adding it to a schema implies endorsement elsewhere.
Discovery is probably an area where supporting a diversity of protocols is
better than making a single choice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200416/86a422fa/attachment.htm>
More information about the openbmc
mailing list