Revision history [back]

Let me try to provide some system level design details that are relevant for this discussion. NGNS reflects enhancements done to the AJ discovery and presence framework in 14.06. Lot of design changes are to provide a faster and more reliable message delivery over IP multicast over Wi-Fi which is the primary transport used by AJ applications. Since SLS framework uses IP multicast to send the SLS advertised name, we expect to see improved performance for Announcement, Notifications etc as well.

  • At the API level, impacts are listed here:

    • bus attachment APIs add the functionality to detect presence by the Ping method; all existing discovery APIs will continue to be supported to provide backwards compatibility
    • AnnouncementRegistrar is a helper class enable the Application to register AnnounceHandlers to receive org.alljoyn.about Announce signals. This is extremely valuable since it allows the client to discover specific interfaces.

    • We also migrated to DNS-SD service discovery mechanism (RFC 6763) which relies on multicast DNS (RFC 6762). There are few key points in this adoption: (a) since multicast packet reliability over Wi-Fi could be an issue, we add redundancy in the transmit schedule and rely on unicast responses. The primary performance objective is to provide a reliable and fast discovery protocol (b) we make use of DNS TXT records in the query to narrow down the search context.

    • Presence APIs were added and it is up to the client application to drive the frequency of presence experience. In general, discovery and presence are supposed to be consumer application driven i.e. there is no persistent ongoing equivalent of is-at message. mDNS query and response packets follow a finite transmit schedule when transmitted over mDNS designated multicast IP address. mutlicast mDNS query triggers a unicast response to favor reliability over network traffic.