Unreliable About for late joiners

asked 2014-08-07 03:20:55 -0700

praetp gravatar image

updated 2014-08-08 01:44:58 -0700


When using About, I often notice that my client does not receive the Announce() for About if the server was already running. If you start the server after the client, it works fine. It's not always (although really a lot), so could this be a timing issue ? Could this be impacted by the fact you use the daemon or the builtin router ?

Edit: I am suspecting a timing issue at the sender side. When I send an Announce, it is not received by a late joiner AboutClient (from the samples).

Code snippet below:

static AboutPropertyStoreImpl aboutPropertyStore;

static QStatus AdvertiseApplication(BusAttachment& ba, const char* guid)
    QStatus status = FillAboutPropertyStoreImplData(&aboutPropertyStore, guid);
    if (status != ER_OK) {
        std::cerr << "Could not fill propertystore" << std::endl;
        return status;

    AboutServiceApi::Init(ba, aboutPropertyStore);
    if (!AboutServiceApi::getInstance()) {
        std::cerr << "Could not get instance" << std::endl;
        return ER_FAIL;

    status = ba.RegisterBusObject(*AboutServiceApi::getInstance());
    if (status != ER_OK) {
        std::cerr << "Could not register about bus object" << std::endl;
        return status;

    status = AboutServiceApi::getInstance()->Announce();
    if (status != ER_OK) {
        std::cerr << "Could not announce" << std::endl;
        return status;

    return ER_OK;
int main(int arg, char** argv)

    BusAttachment ba("secstub");

    do {

        if (ba.Start() != ER_OK) {
            std::cerr << "Could not start" << std::endl;

        if (ER_OK !=
            ba.EnablePeerSecurity(ECDHE_KEYX, new ECDHEKeyXListener(), "/.alljoyn_keystore/s_ecdhe.ks", false)) {
            std::cerr << "BusAttachment::EnablePeerSecurity failed." << std::endl;

        if (ba.Connect() != ER_OK) {
            std::cerr << "Could not connect" << std::endl;
        //Putting a sleep here does not help
        if (AdvertiseApplication(ba, guid) != ER_OK) {
            std::cerr << "Could not advertise" << std::endl;
edit retag flag offensive close merge delete


Can you post your setup code that uses the AllJoyn APIs? I'm guessing you may have a timing issue on how you are using the APIs.

bspencer ( 2014-08-07 13:17:55 -0700 )edit

Are you using 14.02 or 14.06? And if you're using 14.02 are you using any other services that use sessionless signals?

tmalsbar ( 2014-08-07 14:58:46 -0700 )edit

@tmalsbar: I am using 14.06 (not the latest and greatest though, a version from early July) @bspencer: I have edited my answer with more information.

praetp ( 2014-08-08 01:37:59 -0700 )edit

@praetp Sorry but can you show the receiving side? Does the issue still occur in the AboutClientSample: https://git.allseenalliance.org/cgit/core/alljoyn.git/tree/services/about/cpp/samples/AboutClientSample

bspencer ( 2014-08-08 06:46:21 -0700 )edit

@bspencer Well, that is exactly my point. Even the AboutClientSample does not see the About announce when it is a late joiner. Please note the apparent difference in behaviour when using the bundled router vs alljoyn-daemon

praetp ( 2014-08-08 07:42:47 -0700 )edit

2 answers

Sort by ┬╗ oldest newest most voted

answered 2014-09-30 10:24:09 -0700

Issue filed as ASACORE-821.

edit flag offensive delete publish link more

answered 2014-09-23 16:13:42 -0700

borromeotlhs gravatar image

updated 2014-09-23 16:14:56 -0700

Receiving an announce from a sender that doesn't exist yet (in the case of a router that is started after 'clients' exist) seems to be a perfectly valid expectation, no?

Why would I want someone to announce their presence in a room if the 'room' only exists in light of the person that creates it?

Put another way: An alljoyn router creates a BusAttachment that other clients can then attach to. An announce() only makes sense in the context of being sent and received via a BusAttachment (sessionless or not). If a client exists, but is not attached to a Bus, then the Announce being sent on the Bus of that newly instantiated router would _never_ be heard by that unattached client.

The fact that this _sometimes_ works is probably indicative of the fact that your client polls for any 'new' routers (and their Buses), and then coincidentally receives an announce due to joining at just the right interval such as to hear an Announce().

More specifics about your setup would help, in any case. This is just conjecture. Please correct me if I have't yet far enough into the docs to realize that my conceptualization is completely offbase.

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

Question Tools

1 follower


Asked: 2014-08-07 03:20:55 -0700

Seen: 240 times

Last updated: Sep 30 '14