Take the 2-minute tour ×

My Android (2.3 and above) application needs to have TCP communication with 100 (maximum) embedded devices running TCP servers at same time.

The smartphone app should be robust enough to handle 100+ connection simultaneously. It needs to set/get information frequently. So for network module, we analyzed following options:

  • 1st alternative: Have a thread manager (ThreadPoolExecutor) and make connection for each device.
    • Possible Issue: Making 100's thread would not be feasible.
  • 2nd alternative: Using Java NIO selectors for maintaining each fd.
    • Issue: Java NIO seems to be slow. The more descriptors you ask them to check, the slower they get.

while (mMainSelector.select(SELECTOR_TIMEOUT) { .... stuff getting the selected keys .... SocketChannel socketChannel = channel.accept()

It takes about 1-3 seconds from the time the client begins to connect to when the above code gets to the last line (channel.accept()).

Also, to confirm my test, i referred some blogs, which support this.

Avoid NIO

NIO not faster than IO

  • 3rd alternative: epoll: is better than selector, but I guess it is not readily available in Android. Has anybody used epoll in Android? Do we have libev build for Android?

Is there any other alternative which can be best suitable for handing 100's of simultaneous connection, without compromising on speed?

share|improve this question
Selectors are not 'basically slow'. Where do you get this stuff? –  EJP Mar 11 '13 at 11:58
poll and select are basically the same speed-wise: slow. Refer daniel.haxx.se/docs/poll-vs-select.html –  PowerPC Mar 11 '13 at 12:00
No, hundreds of threads mostly blocking on recv() simultaneously in an Android app. You still haven't explained where you got this stuff about selectors being slow: the fact that select() and epoll() are 'basically the same speed' is obvious, but not proof that either of them is 'basically slow'. The reasoning in your citation is unimpressive. But if you prefer your preconceptions to knowledge and experiment why are you asking? –  EJP Mar 11 '13 at 12:11
When you use select() you are inherently moving scheduling out of the operating system into your code, so of course you will see a higher CPU usage there ... but lower elsewhere. I agree about event-driven APIs however, and there is certainly a strong school of thought that says NIO, select() etc, isn't really necessary. I've probably said it myself at some stage, as has @PeterLawrey. select() was designed when the multi-client mechanism was processes, not threads. –  EJP Mar 12 '13 at 3:44
@PowerPC - unless you are trying to write a high performing server that has 10000+ connections, you don't need epoll unless you just want it. select/poll will not add a noticeable impact to your app's performance with only a hundred sockets. On an Android mobile device with hundreds of sockets and threads, you've got much bigger performance problems to be concerned about than the socket selector API. You are better off just making your code single-threaded and using asynchronous (non-blocking IO). –  selbie Mar 14 '13 at 4:13

Your Answer



Browse other questions tagged or ask your own question.