On Android, what should a complete UDP communication module look like?

Comparative Analysis of the Differences between TCP and UDP

In this article, the differences between the two are analyzed in terms of reliability, data transmission, applicable scenarios, etc. The purpose of this article is to introduce how to connect one phone to another phone via a hotspot on an Android device. In this scenario, what aspects should be considered in the complete UDP communication module, how should it be optimized, and how to avoid some pitfalls?

[[206556]]

Using UDP in Java

We all know that most Android applications are developed using Java. How do you use the UDP protocol in Java?

We didn't talk about Socket in the previous article. In fact, Socket can be understood as the encapsulation of TCP and UDP protocols at the program usage level, providing some APIs for programmers to call and develop. This is the most superficial meaning of Socket.

In Java, the classes related to UDP include DatagramSocket, DatagramPacket, etc. Their usage will not be introduced in detail here.

OK, assuming that everyone has a general understanding of their use, we can officially start the content of this article.

Initialize a UDPSocket

First create a class called UDPSocket.

 public UDPSocket(Context context) {
        this.mContext = context;
 int cpuNumbers = Runtime.getRuntime().availableProcessors();
 // Initialize the thread pool according to the number of CPUs
        mThreadPool = Executors.newFixedThreadPool(cpuNumbers * POOL_SIZE);
 //Record the time when the object was created
        lastReceiveTime = System.currentTimeMillis();
 }

In the construction method, we perform some initialization operations. Simply put, we create a thread pool and record the current time in milliseconds. As for what they are used for, see below:

 public void startUDPSocket() {
        if (client != null ) return ;
 try {
 // Indicates that this Socket listens for data on the set port.
            client = new DatagramSocket(CLIENT_PORT);
            if (receivePacket == null ) {
 // Create a packet to receive data
                receivePacket = new DatagramPacket(receiveByte, BUFFER_LENGTH);
 }
            startSocketThread();
        } catch (SocketException e) {
            e.printStackTrace();
 }
 }

Here we first create a DatagramSocket as a "client". In fact, UDP itself does not have the concept of client and server, but only the concept of sender and receiver. Let's temporarily regard the sender as a client.

When creating a DatagramSocket object, a port number is passed in. This port number can be defined within a range, indicating that this DatagramSocket listens for data on this port.

Then a DatagramPacket object is created as the receiving packet of the data.

***Call startSocketThread to start the thread that sends and receives data.

 /**
 * Start the thread to send data
 */
    private void startSocketThread() {
        clientThread = new Thread(new Runnable() {
 @Override
 public void run() {
                Log.d(TAG, "clientThread is running..." );
                receiveMessage();
 }
 });
        isThreadRunning = true ;
 clientThread.start();
        startHeartbeatTimer();
 }

First, the purpose of the clientThread thread is to call the DatagramSocket receive method. Since the receive method is blocked, it cannot be placed in the main thread, so a child thread is naturally started. receiveMessage is used to process the received UDP datagram. We will not look at this method for receiving data first, after all, no one has sent a message yet, so there is naturally no question of receiving it.

Heartbeat packets maintain a "long connection"

Coming to the first point of this article, we all know that UDP itself has no concept of connection. The scenario of applying UDP and TCP on the Android side is that one mobile phone connects to the hotspot of another mobile phone, and the two are in the same local area network. When the two do not know the existence of each other, how can they find each other?

Through the heartbeat packet method, both parties send a UDP packet at regular intervals. If the other party receives it, they can know the other party's IP and establish communication.

 private static final long TIME_OUT = 120 * 1000;
    private static final long HEARTBEAT_MESSAGE_DURATION = 10 * 1000;
 /**
 * Start heartbeat, timer interval is ten seconds
 */
    private void startHeartbeatTimer() {
        timer = new HeartbeatTimer();
        timer.setOnScheduleListener(new HeartbeatTimer.OnScheduleListener() {
 @Override
 public void onSchedule() {
                Log.d(TAG, "timer is onSchedule..." );
                long duration = System.currentTimeMillis() - lastReceiveTime;
                Log.d(TAG, "duration:" + duration);
 if (duration > TIME_OUT) {//If I don't receive my heartbeat packet for more than two minutes, I will assume that the other party is not online.
 Log.d(TAG, "Timeout, the other party has gone offline" );
 // Refresh time and re-enter the next heartbeat cycle
                    lastReceiveTime = System.currentTimeMillis();
 } else if (duration > HEARTBEAT_MESSAGE_DURATION) {//If he doesn't receive my heartbeat packet within ten seconds, send another one.
                    String string = "hello, this is a heartbeat message" ;
                    sendMessage(string);
 }
 }
 });
        timer.startTimer(0, 1000 * 10);
 }

The purpose of this heartbeat is to send a message via sendMessage every ten seconds to see if the other party can receive it. If the other party receives the message, the lastReceiveTime time is refreshed.

Here I send a string to the other party every ten seconds.

 private static final String BROADCAST_IP = "192.168.43.255" ;
 /**
 * Send heartbeat packet
 *
 * @param message
 */
 public void sendMessage(final String message) {
        mThreadPool. execute (new Runnable() {
 @Override
 public void run() {
 try {
                    InetAddress targetAddress = InetAddress.getByName(BROADCAST_IP);
                    DatagramPacket packet = new DatagramPacket(message.getBytes(), message.length(), targetAddress, CLIENT_PORT);
                    client.send(packet);
 Log.d(TAG, "Data sent successfully" );
                } catch (UnknownHostException e) {
                    e.printStackTrace();
                } catch (IOException e) {
                    e.printStackTrace();
 }
 }
 });
 }

Here is the code to send a message. When I first filled in the parameters of DatagramPacket, I had a question. The targetAddress is actually my own IP address. The question is, if I fill in my own IP address and the other party's port, how can I find the other party? You may wonder where the "192.168.43.255" IP address comes from and why it is defined like this?

First, turn on the hotspot on your Android phone, which can be understood as a gateway with a default IP address: "192.168.43.1"

This IP address is not made up by me. It is defined in the Android source code as follows:

WifiStateMachine

 ifcg = mNwService.getInterfaceConfig(intf);
                        if (ifcg != null ) {
                            /* IP/netmask: 192.168.43.1/255.255.255.0 */
                            ifcg.setLinkAddress(new LinkAddress(
                                    NetworkUtils.numericToInetAddress( "192.168.43.1" ), 24));
                            ifcg.setInterfaceUp();
                            mNwService.setInterfaceConfig(intf, ifcg);
 }

So I know the IP address of the party that opens the hotspot, and UDP has another feature when sending messages, that is, the messages sent out can be received by all devices in the entire gateway, so my own IP address is set to "192.168.43.255", so this IP address and "192.168.43.1" are in the same gateway, and the messages you send can be received by it.

As for how to determine whether two IP addresses are in the same network segment:

Determine the size of two IPs and whether they are in the same network segment

Let’s make a stage summary:

First, we created a sending DatagramSocket and started a heartbeat program to send a heartbeat packet at a certain interval.

Because I know that the IP address of the hotspot is the default "192.168.43.1", and the characteristic of UDP is that all devices in the same network segment can receive the sent message. So the sender's IP address is set to "192.168.43.255" in the same network segment as the hotspot.

Events and data

The two modules, event and data, are closely related to the business.

Let's talk about data first. The data format sent by both parties can be defined at will. Of course, I think it is better to define it in the conventional Json format. It can include some key event fields: such as broadcast heartbeat packets, response packets to the other party when receiving heartbeat packets, timeout offline packets, and various business-related data, etc.

Of course, the data is converted into a binary array when it is sent. There is no problem sending Chinese characters, pictures, etc., but there may be some details that need attention. Just google it at any time.

Let's talk about the incident:

What are the non-business related events?

for example:

• The DatagramSocket.send method is followed by an event where data is sent successfully;
• The DatagramSocket.receive method is followed by an event indicating successful data reception;
• If there is no reply after sending the heartbeat packet for a period of time, it is a connection timeout event;
• Business-related events are related to the data types mentioned above, such as device online, heartbeat packet response, etc.

How are events sent out and notified to each page? You can use Listener or other third-party libraries of event bus, it’s up to you to choose.

Processing received messages

 /**
 * Process the received message
 */
   private void receiveMessage() {
       while (isThreadRunning) {
 try {
               if (client != null ) {
                   client.receive(receivePacket);
 }
               lastReceiveTime = System.currentTimeMillis();
               Log.d(TAG, "receive packet success..." );
           } catch (IOException e) {
 Log.e(TAG, "UDP data packet reception failed! Thread stopped" );
               stopUDPSocket();
               e.printStackTrace();
 return ;
 }
           if (receivePacket == null || receivePacket.getLength() == 0) {
 Log.e(TAG, "Unable to receive UDP data or the received UDP data is empty" );
 continue ;
 }
           String strReceive = new String(receivePacket.getData(), 0, receivePacket.getLength());
           Log.d(TAG, strReceive + " from " + receivePacket.getAddress().getHostAddress() + ":" + receivePacket.getPort());
 //Parse the received json information
 // After receiving UDP data each time, reset the length. Otherwise, the next received data packet may be truncated.
           if (receivePacket != null ) {
               receivePacket.setLength(BUFFER_LENGTH);
 }
 }
 }

There are several points worth noting when processing received messages:

• The receive method is blocking, and will remain blocked until a data packet is received, so it must be placed in a child thread;
• After each message is received, call receivePacket.setLength again;
• After receiving the message, refresh the value of lastReceiveTime and suspend sending heartbeat packets;
• The specific business of processing received data is the issue of sending data we just talked about, which depends on the business.

The concept of "user"

We have discussed the characteristics of UDP above. If a mobile phone has turned on the hotspot and multiple mobile phones are connected to it, it can receive messages sent by multiple mobile phones. If the sender's port is the same as the receiver's port, even the message you sent yourself can be received by yourself. This is very embarrassing, that is, we have to exclude messages sent to ourselves and distinguish messages sent from different mobile phones. At this time, there should be a concept of "user".

Create a User object and check which attributes you can use to view your business. The examples in this article include ip, imei, and softversion.

 /**
 * Create local user information
 */
   private void createUser() {
       if (localUser == null ) {
           localUser = new Users();
 }
       if (remoteUser == null ) {
           remoteUser = new Users();
 }
       localUser.setImei(DeviceUtil.getDeviceId(mContext));
       localUser.setSoftVersion(DeviceUtil.getPackageVersionCode(mContext));
 if (WifiUtil.getInstance(mContext).isWifiApEnabled()) {// Determine whether the hotspot is currently enabled
           localUser.setIp( "192.168.43.1" );
 } else {// Currently, wifi is turned on
           localUser.setIp(WifiUtil.getInstance(mContext).getLocalIPAddress());
           remoteUser.setIp(WifiUtil.getInstance(mContext).getServerIPAddress());
 }
 }
 /**
    * <p><b>IMEI.</b></p> Returns the unique device ID, for example, the IMEI for GSM and the MEID
    * or ESN for CDMA phones. Return   null if device ID is   not available.
 * <p>
    * Requires Permission: READ_PHONE_STATE
 *
 * @param context
 * @return  
 */
 public synchronized static String getDeviceId(Context context) {
       if (context == null ) {
 return   "" ;
 }
 String imei = "" ;
 try {
           TelephonyManager tm = (TelephonyManager) context.getSystemService(Context.TELEPHONY_SERVICE);
           if (tm == null || TextUtils.isEmpty(tm.getDeviceId())) {
 // Dual SIM dual standby needs to obtain IMEI through phone1 and phone2, and the IMEI of phone1 is taken by default.
               tm = (TelephonyManager) context.getSystemService( "phone1" );
 }
 if (tm != null ) {
               imei = tm.getDeviceId();
 }
       } catch (SecurityException e) {
           e.printStackTrace();
 }
 return imei;
 }</p>

I won't expand all the codes here. If you have the IMEI number of the mobile phone, it is easy to distinguish the identity. You can distinguish different senders and remove the messages sent to yourself. Of course, if more information is needed, you can distinguish it according to your own business and send it as a messge through Socket.

Written at the end:

Up to now, most of the contents of this article have been introduced. Some students may ask, you need to use a heartbeat to maintain a fake "long connection", which is troublesome to use, and you may also suffer from the pain of packet loss caused by UDP, why not choose TCP? Good question, in fact, this version was the first version made at that time, and then the TCP+UDP method was used to complete this module. Let's take a look at the improved version with TCP in the next article.