3

I'm developing an none market appliction which run on 20-30 android devices (target specific to tablets with android honeycomb / ICS OS) maintaining connection over local WIFI network for a 1-2 hours period of time, and need to exchange data (simple objects representing commands) between them.

most of the time one specific tablet behave like a server which sending the commands, and the other devices like clients which receives the commands, but the "clients" also sending commands to the "server" sometimes.

as solution to this communication demand - I'm using for a while an open source
library which encapsulates TCP client/server protocol, called - Kryonet. I found it very easy to use, and basically doing the job, although it sometimes "unstable" - a lot of disconnections accrues. I can't afford this disconnections, it's dammege the whole flow and use-case, causing the client's to lose commands.

I'm doing some recovery logic which re-connect the clients and send them what they have missed, but it's not good enough for the use-case.

recently I've heard about multicast broadcast protocol, and found even an open source library calls - JGroups which implement this protocol optimally, and expose easy and simple to use interface. still didn't tried it, but got advice from someone who knows, saying it should be better the the TCP client/server for my purpose.

  • what is the best approach I should use for implement the behavior I described ? (not necessarily one of the two I suggested)

TIA

Tal Kanel
  • 10,475
  • 10
  • 60
  • 98

1 Answers1

3

Although JGroups has promise as a better solution for your situation, you may want to experiment a bit more to determine why the disconnects are happening. Since your clients and server are all tablets, there are a few other causes that are unrelated:

1) If the connections are not being maintained in a Service then they will be extremely unreliable by default. (See this question about singletons being destroyed in Android)

2) If the sockets have not been set to 'keepalive' then they will time out after an arbitrary number of seconds.

3) The devices you are using may shut down some persistent connections when they go to sleep.

4) The tablets may be exiting WiFi range, and switching over to a mobile network.

Try the network portion of your code on a number of desktop machines to determine if the problem is with Kryonet or your code, or if the problem is in running it on Android.

Community
  • 1
  • 1
Greyson
  • 3,598
  • 1
  • 21
  • 22
  • 1
    you surely raised some important points. some of them already crossed my mind, and been investigating these days. about (1) - why holding instance of kryo's Server class inside android's Service class should be better then holding it inside some other singeltone class I've created? – Tal Kanel Jul 19 '12 at 20:10
  • 2
    The `Service` class (and associated entry in the manifest, as well as actually starting the service with an `Intent`) has more lasting priority than an `Activity` (the top-most unit of UI interaction). If your application contains only `Activity`s, then it may be terminated or suspended when there is no UI to show. A service may keep your process alive even if your application is not in the foreground. – Greyson Jul 19 '12 at 20:15
  • first of all - thank you very much for the help, about (2) - how can I set this "keepalive" thing? do you know any good guide/link explaining how kryo should be use in android the right way? – Tal Kanel Jul 19 '12 at 20:24
  • I'm not familiar enough with Kryonet to give you a good answer to that (Though, the `Connection` class appears to have a `setKeepAliveTCP` method). It sounds like that may be a non-issue, or at least a problem for another day if you haven't started using an Android service yet. – Greyson Jul 19 '12 at 20:36
  • Actually I've already started refactor all the code a few days ago, and moved the kryo's Client and Server classes and callbacks to android's Services. I did it from other reasons, so I'm glad to here it can also contribute to the communication stability issue. I'm reading now about the - setKeepAliveTCP() method. felling bit stupid I didn't think about that before.. – Tal Kanel Jul 19 '12 at 20:45
  • if you've got any other ideas about what can cause to my disconnections - I'll be glad to here them – Tal Kanel Jul 20 '12 at 07:58