I'm developing an app to receive data from C++ program every second. The app also need to send data to C++ program sometimes. Is it suitable to use socket as communication between both instances? For each instance, does it have to run socket server and client at the same time?
0
votes
Are the Android and C++ apps running on different machines/devices? If so, then yes, sockets would be a viable communication option. You don't need two sockets, though. Sockets are bidirectional, you can use a single socket for both sending and receiving. But, if the two apps are on the same machine/device, you might consider a different communication, such as Android Intents.
– Remy Lebeau
Sockets are the way to go. And of course the server socket has to be active/listening when the client socket tries to connect.
– greenapps
Yes, both on different machine. So on single socket, how do i implement bidirectional comm. Both instances have to listen at the same time?
– hellilyntax
1 Answers
2
votes
I think there would be different ways of accomplishing this depending on required timing behavior (does the device have to receive messages synchronously, should messages that cannot be delivered in time be cached till they can be delivered, etc.), public reachability of the android device (if they are connected over mobile networks they are behind NAT in many mobile networks) and if the devices could go into standby mode or not.
Using stream sockets (TCP) if the mobile device stays awake the whole time or processing has to happen always synchronously.
In this case one end would have to be the "server" and one end to be the "client". Because mobile devices tend to go into standby mode i'd use the C++ program (if it runs on a non-mobile device) to be the server - this would be the end that creates a socket, binds it and then uses listen to wait for incoming connections. Whenever the client connects to the server it has to accept the connection which then can be used bidirectionally by using the same handle for send and receive.
The mobile device then would create a socket and connect to the server and could transmit data to it (it does not have to bind or listen). Over the same connection the device could receive data from the server.
If the server is required to send data to the mobile device even when the mobile device has not established a connection and the mobile device is able to go into standby mode one could either periodically wake the device and poll the server or use the firebase cloud messaging system or even short message service or - if the device is not able to go into standby mode - simply create a listening socket too that accepts incoming connections from the C++ application.
Using datagram sockets (UDP)
In this case both the C++ application and the Android application would create and bind a socket to a specific port. Then they can both simply send packets (unreliable) to other clients or even multicast them in a local area network by sending them a multicast address. Of course the mobile device would miss packets that have been sent from the C++ application during periods where it's in standby mode and the C++ application would miss packets during times it's not running.
Using a message queue (if the mobile device may go to standby mode and has to receive messages asynchronously)
In this case both programs would not have to run at the same time if the queues are persistent, but a message broker would have to (for example RabbitMQ). The C++ application could simply push messages into the queue and any subscribed mobile device would receive them either immediately or (for persistent queues) later whenever the devices connects to the server.
Messaging from the mobile device to the server could also be realized over a message queue if synchronous behavior is not required or over a traditional webservice or even a socket.
