Announce/ObjectFound is not received after ObjectLost/SessionLost

asked 2016-01-06 10:46:03 -0700

diskonnect gravatar image

updated 2016-01-07 16:42:53 -0700

praveenb gravatar image

I had 2 different classes. One class is derived from ajn::Observer::Listener, other - from ajn::AboutListener and ajn::SessionListener. I am trying to handle the lifetime of BusObjects using these classes. If I use second (with AboutListener and SessionListener), I establish session when I receive Announced callback (device is online for me) and I delete device (set it offline) when I receive SessionLost(). For first class (Observer::Listener) I am using ObjectDiscovered and ObjectLost respectively.

The problem appears when I have following scenario:

  1. Device come up online - ObjectDiscovered() and Announced() are called.
  2. I simulate network problems - for example, turn off network cable from one of the devices.
  3. After some time ObjectLost() and SessionLost() are called (because of timeout). For now device is offline
  4. I put back cable back. But I don't receive neither ObjectDiscovered(), neither Announced(). But alljoyn can see the second device (I can see from alljoyn debug logs that alljoyn receives some information from remote device).

Is there any way to handle such situations, or may be there is a better way to track device online/offline status instead of described ones?

edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted

answered 2016-01-07 17:22:50 -0700

praveenb gravatar image


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).


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).

edit flag offensive delete publish link more
Login/Signup to Answer

Question Tools

1 follower


Asked: 2016-01-06 10:46:03 -0700

Seen: 109 times

Last updated: Jan 07 '16