Remote method calls stop working

asked 2014-06-18 20:42:53 -0700

updated 2014-06-22 10:51:36 -0700

Greetings all seers! My PeerGroupManager based iOS app keeps a reference to a remote object around for the duration that the app is running. Frequently, the remote object will stop responding at which point, i'll nil it out and create a new one via:

self.myRemoteProxy = nil;
self.myRemoteProxy = [self.peerGroupManager getRemoteObjectWithClassName:className

This usually reestablishes the connection but we often have to quit the local or remote app in order to get them communicating again (the use case for our app makes it more convenient to force quit on the remote device.) Even though the remote object does not respond to method calls (they time out) both the local and remote devices still receive signals broadcast by a third device.

My questions are:

  • Am i doing this wrong by keeping the remote proxy around or should i call getRemoteObjectWithClassName: every time i want to call a method on a remote object?
  • Are broadcasted signals somehow more robust than point-to-point method calls? Should i implement this communication as a signal?
  • I shouldn't have to tear down the entire alljoyn stack on the local device, should i?

Thanks so much.

[Updating the original question as opposed to commenting on @bspencer's answer since comments are limited to 300 characters]

Thanks so much for your answer @bspencer, your support of the community is greatly appreciated! Earlier in our development cycle we found the didLoseAdvertisedName and didFindAdvertisedName PGMPeerGroupManager callbacks to be unreliable. If i recall correctly, we would only receive didFindAdvertisedName the first time that the device encountered the name. If the remote advertising device disappeared and came back, the didFindAdvertisedName notification would not fire. Instead we rely on manually reconnecting to the remote device (via the snippet included above) whenever a message to the remote device fails to send. I should note that the above snippet does not include where the peerID comes from. The remote peer advertises a name via PGMPeerGroupManager's createGroupWithName. This lets us look up the peerID for the remote device via PGMPeerGroupManager's getHostPeerIdOfGroup (we don't use the group for anything else and no one joins it.) Thus, even when our proxy object isn't valid anymore, we should be able to get a new proxy object pointing to the correct device.

I think that what we've implemented is equivalent to your suggestion with the exception that we create our new proxy object on demand, not in response to the session lifecycle callbacks. Do you think this should work such that we should always be able to reestablish communication with the remote device after recreating our proxy object? If not, would you recommend trying the lifecycle callbacks again? Do you have any other recommendations for how to make this communication more reliable or see any problems with our approach? Our fallback right now is to literally kill the app on either the local or remote device so that they will reestablish communication when the app returns.

Thanks again!

edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted

answered 2014-06-20 16:23:19 -0700

bspencer gravatar image

The proxy object you have is pointing to an old identifier. You can keep around the proxy object as long as the other side does not go away and come back. Broadcast signals work because they do not rely on a session, they rely on having the AllJoyn routers have a connection between each other. A BusMethod requires a destination, and the destination in this case, has changed from under you. I would recommend that you check if you receive any lostAdvertisedNames or sessionMemberRemoved. When these occur the proxy object is no longer valid and you should create it again when you receive a sessionMemberAdded or when you join a group again.

edit flag offensive delete publish link more


Commented above in the original question since comments are limited to 300 characters.

Keith Alperin ( 2014-06-22 20:23:37 -0700 )edit

Keith, the approach you're taking by recreating your proxy bus object on demand if using the old proxy bus object fails should work fine. It is essentially the same as what Brian described, the important part is you're recreating the proxy with the updated info.

mitchw ( 2014-06-26 11:04:57 -0700 )edit

Hi @mitchw, thanks for your answer. My further question becomes: if this should work why do we so often lose communication between the devices? We see communication breakdowns regularly after a few hours of use where the device's attempts to manually reconnect fail. Thanks!

Keith Alperin ( 2014-06-29 08:23:14 -0700 )edit

When you see "communication breakdowns" what is the cause of the breakdown? IE do you receive session lost? session member removed? lost advertised name? what callbacks and what do you see in the logs? Without this we cannot know why the connection broke down. Further are the handsets going into idle mode? If so then the handset may be disconnecting from WiFi which would cause a disconnect in the system.

bspencer ( 2014-07-10 10:05:40 -0700 )edit

We don't receive any notifications from PeerGroupManager (there may be lower level alljoyn notifications that we could try to listen for). Devices going idle is a possibility. Should losing wifi still yield a PeerGroupManager notification? We can work around it, but we don't see any notifications.

Keith Alperin ( 2014-07-13 20:04:52 -0700 )edit
Login/Signup to Answer

Question Tools

1 follower


Asked: 2014-06-18 20:42:53 -0700

Seen: 197 times

Last updated: Jun 22 '14