Oh, it has been a while since I’ve talked about my pet project =). This time I’m talking about the fundamental issues I want to tackle in the project.
Client-Server Oriented Remote Actors
The regular Akka remote actors in Akka 1.2 have an almost ‘symmetric’ implementation. To get the full ‘send’, ‘reply’ behavior you have to start up a full Netty server on the ‘client’ and the ‘server’. And with the upcoming Akka 2.0 clustering this won’t change that much.
In a mobile-device scenario this is bit different. We have a clear distinction: A small, lightweight application which is the client and a server (-cluster) which runs the service. The client should be small and lightweight and usually maintains one connection to the server. The server can be large, but needs to maintain many connections to many devices.
Furthermore a connection is only in one way, from the client to the server. The server cannot directly contact a client. The client has almost certainly a dynamic, no public IP which changes a lot: Walking away from your Wi-Fi at home to a mobile network to another Wi-Fi hotspot. For an implementation that means the client needs to able to reconnect on network changes back to the server. And the server needs to use the latest connection when he wants to reply to a client.
The implementation needs to deal somehow with unreliable connections. I want to have a ‘supervisior’ hierarchy in place for this. For example the first layer just tries to reconnect immediately; the second layer waits a little to reconnect. The next layer it stores the message away for later or escalates the issue to the user etc. This should be configurable of course.
Push-Notifications/Message from the Server
One thing I want have in Akka-Mobile is ‘push-notification’ support. Basically I want be able to send a message to a mobile device and let the device react to it. The server maintains a database of known mobile devices. When he wants to notify a mobile device he grabs an Actor reference which represents that device and sends the message to the client. Then the implementation looks up if there’s an active connection available to that device. If that’s the case, it just sends the message to the device. Otherwise it will fall back to some other push-notification mechanism, for example the Android Cloud to Device Messaging Framework (C2MD).
Here’s a little sketch how it should work during active communication:
- The Mobile Device / Client connects to the server, gets a reference to a remote actor, for example the actor “John” and sends a message to it.
- The server associates TCP connection with the device id (here “Green Devil”) and the forwards the message to the right actor.
- The actor does its thing. The actor can send as many messages back to the ‘sender’. It also can pass the actor reference to other actors and those actors can answer.
- When a message has to go back to the mobile device the server implementation looks up if there still a connection to the mobile device…
- …and sends the answers to the right actor on the mobile device.
Now what happens when there’s no connection from the mobile device to the server? That’s when the C2MD service comes in. Then a message is send via that service to tell the mobile device that there are answers available on the server. Of course the has to be some kind of configuration which types of messages are important enough to cause this behavior. So the behaviors changes at step 4:
- The server detects that there is no active connection to the client. So he has to fall back to alternatives.
- He could issue a C2MD request to notify the client that there’s stuff available for him.
- Let’s Google do its job
- The client reconnects to get the answers/messages
Akka Mobile has to deal with the changing and unreliable network topography. That’s means tons of tedious implementation details and tons of work for me.
Anyway, next time I will show code and talk less =)
- Running Scala on Android
- TV-Series Reviews and Stuff?