0

Developed a networking library using Android NDK (2.3 and above)

Scenerio

  1. Third-party application (TCP socket based ) communicates to our native library.
  2. Our library processes that data and in turns communicates to a server using TCP socket communication. The communication is bi-directional.

We have designed and implemented socket communication mechanism between third-party-app and our library for IPC. our-library is utilizing the third-party-app port (default: 6700) to establish the connection between server.

So, it is kind of loopback connection through which communication is happening between our library and third-party-app.

  int on = 1;
setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));
bind(s, (struct sockaddr *) &sin, sizeof (sin));

Problem Area

Everything works fine, but due to it, the performance is downgraded. If network library is not present , the communication is very fast. To verify that issue lies in loopback tcp socket, we removed all internal processing of library. The library just acting as pseudo-server (pass-through) for the application. The app sends data to localhost and socket, and the library just forwards it to server as it is.

> Queries

So is there any way to improve performance ?

1) What about UNIX-domain socket on the Android , can they be used between app and our library?

2) Can Binders be used to communicate between User level application and native Android library ?

3) Or Do we have something similar to IOCTL SIO_LOOPBACK_FASTPATH (The TCP loopback fast path is enabled by the socket IOCTL SIO_LOOPBACK_FASTPATH applied to the sending and receiving sockets.) Transmission Control Protocol (TCP) Loopback Optimization

Many Thanks in advance

Rohit
  • 6,941
  • 17
  • 58
  • 102
  • 2
    Yes, and yes. A unix domain socket will eliminate the need for network permission in a component which has not other need for it. In theory it might eliminate the TCP nagle algorithm latency, but hopefully a loopback interface is smart enough to avoid that anyway. Binder would be easier between java components than native components, but it's not impossible to use it natively. You'll have an easier time if this worker code is in a process which has standing with Android - say as an Android service, at which point hooking up Binder should be straightforward. – Chris Stratton Jan 31 '13 at 14:38
  • @Chris So do you mean to say tcp loopback might already be taking care of latency? – Rohit Jan 31 '13 at 15:34
  • The performance is downgraded compared to what? – user207421 Feb 01 '13 at 04:44
  • If network library is not present , the communication is very fast. Plz note that i removed all internal logic of library to verify the same. The library just acting as pseudo-server for the application. – Rohit Feb 01 '13 at 05:09
  • So why use networking if you have a better alternative? What's the question here? – user207421 Feb 01 '13 at 22:00
  • 1
    Since you already have sockets based code, switching to a unix domain socket would be an easy experiment to try and see what that does. It's not clear though in your tests how you have localized the time to the inter-process communication, since you are still talking to an external network server and that can be expected to take some time. To really test the IPC, you'd probably want to have the other local end reply immediately, without reaching out to a remote server. (The specific TCP loopback option you link is a recent windows server thing, not directly applicable to linux/android). – Chris Stratton Feb 02 '13 at 14:48

0 Answers0