Sending and Receiving with UDP

Question

I am trying to implement data transfer between a back-end server and the android device which is a request from device to server for information and the server responds(UDP use because it is faster and the functionality of TCP isn't needed, I guess...)

Where do I begin for implementing this? I have looked at the Android Docs for DatagramSocket/Packet/SocketImplFactory as well as InetAddress and SocketAddress.

Is this the right direction? Right now I am using HTTP Post requests, is any of that code recyclable?

HttpClient httpclient = new DefaultHttpClient();
            HttpPost httppost = new HttpPost(url);
            List<NameValuePair> nameValuePairs = new ArrayList<NameValuePair>(2);
            if (fleetID != null) {
                nameValuePairs.add(new BasicNameValuePair("fleetID", fleetID));

            }
            nameValuePairs.add(new BasicNameValuePair("user", username));
            nameValuePairs.add(new BasicNameValuePair("password", password));

            httppost.setEntity(new UrlEncodedFormEntity(nameValuePairs));
            HttpResponse response = httpclient.execute(httppost);
//TODO: response failure? need to ensure success
            HttpEntity resEntity = response.getEntity();

            String strEntity = EntityUtils.toString(resEntity);
            //Log.i("RESPONSE", strEntity);
            return (strEntity);

AFAIK HTTP uses TCP. If you want to use HTTP/UDP, then you have to write your own server, then you'll have to re-implemented HTTP via UDP. Is that really what you want to do? http://stackoverflow.com/questions/323351/does-http-use-udp — Neil, Jul 15 '13 at 15:29
HTTP is simply the method we are using now. Since we want to save on server-load and data transmission we are going to do UDP. I just don't know anything about UDP and I was wondering if I could get some guidance. The HTTP part is just asking if any part of that old code is reusable(i am asking because i know nothing of UDP!) — benzabill, Jul 15 '13 at 15:34
I know this doesn't answer your question, but why do you think HTTP is too slow? Has it been measured? Implementing a client/server protocol from scratch is hard to get right. If you use UDP, you need to implement error checking and retry mechanisms. At least using HTTP means you have working tested APIs at both ends. — Neil, Jul 15 '13 at 15:51
I can bring that up with my adviser but if we operate under the assumption that it must be UDP, where do I begin? — benzabill, Jul 15 '13 at 15:54
just for your information, i talked to my adviser and he said that they already use UDP and they do not ever have corrupted packets. Maybe there is internal testing or something but that's that. — benzabill, Jul 15 '13 at 20:48
Just because you've never seen packet loss/corruption during test, doesn't mean as soon as you deploy, you won't see it. Can you guarantee the quality of the network you will run this app on? I can't find the link now, but an ex-colleague (VoIP expert) of mine liked to tell everyone about how often the CRC on Ethernet packets would be correct, but the data was wrong. TCP/UDP use a simple 16-bit checksum, so their error detection is even worse. Your protocol needs to handle so many issues, I suspect it just isn't worth the effort to re-implement this particular wheel. — Neil, Jul 16 '13 at 10:24

score 2 · Accepted Answer · answered Jul 15 '13 at 15:54

2

The server and Android components can both be written in Java using the the standard Java DatagramSocket class. A quick example can be found here (in this instance it is sending a String from the command prompt: http://systembash.com/content/a-simple-java-udp-server-and-udp-client/. Basically, you make a DatagramSocket instance with a given port number and you send/recieve the data as a byte[]. However, I would be careful with using UDP. TCP ensures that no data is lost when the file is sent, and therefore ensures that data is not corrupted as it is sent.

answered Jul 15 '13 at 15:54

Tom C

232
1
6
17

Thank you, that is a helpful link. @Neil said that (possibly) HTTP uses TCP. Does that mean if we did TCP I wouldn't have to change implementation? Also, what type of corruption? Like third party or just 'bad' files – benzabill Jul 15 '13 at 15:58
1

If you are trying to send a file, the file could definitively be corrupted if any packets are lost or arrive in the wrong order and rendered unopenable. UDP is meant for things like streaming. HTTP does use TCP and so anything you send is guaranteed to arrive correctly (so long as there are no connection exceptions or things of that nature). You could use the implementation you have to send files by getting the input stream from the response. – Tom C Jul 15 '13 at 16:09
just for your information, i talked to my adviser and he said that they already use UDP and they do not ever have corrupted packets. Maybe there is internal testing or something but that's that. – benzabill Jul 15 '13 at 20:47

Sending and Receiving with UDP

1 Answers1