Revision history [back]

click to hide/show revision 1
initial version

Solution

What you are looking for, is a mechanism to query / maintain / check the presence of the remote peer. The way to do this is to use BusAttachment::Ping. This API takes in the name of the remote peer as an argument (the name of the remote peer is one of the pieces of information made available with the ajn::AboutListener::Announced callback).

Even better, you might want to use the ajn::AutoPinger helper class to keep track of the remote peer's presence information (it is a kind of polling for presence status).

Background

Peers (leaf nodes) in AllJoyn can be:

  1. Providers of functionality - These expose functionality via adding Interfaces that contain Methods / Signals / Properties into a Bus Object hierarchy and advertising this information via About announcements.
  2. Seekers of functionality - These discover other peers via Who-Implements queries, introspect relevant peers and exercise their provided functionality by making method calls, sending / receiving signals, setting/getting properties through Proxy Bus Objects.
  3. Both of the above.

ajn::AboutListener informs the seeker application of any remote peers, that provide the functionality it is interested in. Information about a peer P is provided only once (callback is invoked only once).

What distinguishes two remote peers? Unique name. That means, as long as the unique name of the remote peer stays the same, the callback ajn::AboutListener::Announced gets invoked only once on the seeker application. The network problem (link up / link down) you simulated wouldn't change the unique name of the remote peer and thus the callback your seeker application, ajn::AboutListener::Announced , isn't going to get invoked again. This is expected behavior.

Remote Peer Discovery in AllJoyn takes place in a connectionless manner (via UDP multicast). Hence, the functionality associated with Discovery, viz. About announcements and Who-Implements queries also exhibit this nature (application wouldn't immediately know that the remote peer is unreachable).

Actual communication between two peers (method calls, signals and property accesses), takes place over a session which is connection-oriented (via TCP or AllJoyn Reliable Datagram Protocol). Likewise, functionality associated with Sessions, viz SessionLost, exhibit this nature (application needn't poll).