The CYGFUN_MDNS_COMMON_NAME controls whether a single, common, name is used to announce the host and all registered services. This option reduces the RAM footprint required, at the expense of not supporting per-service labels.

For very simple target applications, where maybe only a single service is being announced, it may be deemed that it is not an issue if the hostname and service-label are the same. However, a conflict with either causing a renaming will therefore affect both the hostname and service-label.

The CYGFUN_MDNS_STATS option can be enabled to allow for information counts and sizes to be gathered during execution. These statistics can help with the tuning of the mDNS world during development, since monitoring the minimum and maximum usage counts of resources along with the error counts can indicate resource starvation issues.

For the network packet memory tracking, a common cyg_mdns_statistics_memory structure is defined and used for each of the packet size records being tracked:

struct cyg_mdns_statistics_memory {
  cyg_uint32 count; // number of tracked items
  cyg_uint16 min; // minimum size seen
  cyg_uint16 max; // maximum size seen
};

For example the basic statistics structure is defined as:

struct cyg_mdns_statistics {
    struct cyg_mdns_statistics_memory errors; // failed packet allocation information
    struct cyg_mdns_statistics_memory hostname; // hostname probe/announce packets
    struct cyg_mdns_statistics_memory service; // service probe/announce packets
    struct cyg_mdns_statistics_memory responses; // query response packets
    struct cyg_mdns_statistics_memory tx; // packets transmitted
};

The errors information records the number of failures to allocate a packet buffer, along with the smallest allocation attempt that failed reported in the min field and the largest allocation attempt that failed in the max field.

The hostname, service and responses elements record the number of buffer allocations made for each of the respective mDNS packet type generators along with the minimum and maximum sizes seen.

The tx field tracks the actual generated packet size as transmitted for all of the packet generators. The maximum recorded by this statistic will normally be smaller than the largest of the packet generator maximums since it tracks the size of packet actually transmitted after any name compression has been applied.

As an example, with careful tuning, it is possible to implement a simple mDNS Responder and webserver with a very small RAM footprint.

For a Cortex-M3 (STM32F207x) based platform, the default mDNS Responder configuration occupies ~14K of code and requires less than 512-bytes of RAM for the mDNS Responder specific state. If CYGFUN_MDNS_COMMON_NAME is enabled then the code occupies less than 14K and requires less than 300-bytes of RAM to hold the mDNS specific context.

The code (normally ROM) and RAM footprint for a complete application will be higher depending on the eCos features configured and application code requirements (e.g. number and size of thread stacks, network buffers, etc.).