0

I'm using sockets for data transfer from one android phone and PC, I am using DataInputStream.

But it takes a long time in data transfer, about 10 minutes to transfer a 4 MB file.

Could anyone suggest any better way to do that?

I did some changes in my code and now it is taking 15 seconds to read about 1 Mb of data. I want to improve its performance. My Code is:

InputStream is= socket.getInputStream();
DataInputStream inChannel= new DataInputStream(new BufferedInputStream(in));
ByteArrayOutputStream baos = new ByteArrayOutputStream();
int oneByte;
while ((oneByte = inChannel.read()) != -1) {
        if (oneByte == 0) {
            break;
        }        
        baos.write(oneByte);
        byteCount++;
    }
byte[] inData = baos.toByteArray();
baos.close();
Azmat
  • 393
  • 3
  • 15

1 Answers1

-1

Are you sure you are not sending empty packets in between there or packets doing something else? If you are using TCP if a packet doesn't reach its destination (a buffer is overfilled with other packets somewhere in between your connection on the router or on one of the devices) the packet will have to be resent. This might be because of your setup. Given the little information you have given us, I can give the the following advice:

Look into more advanced typologies, I am going to assume you are not using any of these:

A send a receive thread; the send thread pushes out packets which you put into a queue:

|P| - packet held inside a Que part of your program

send out thread <-| P | P | P | <-App/program

reveive -> | P | P | P| P -> App/Program deques and analyses data

because your send and receive queuing system works along side each other they are constantly buffering up the received and sent packets. What seems to be happening with your setup (as far as I assume) is that you have a loop which grabs the latest packets and analyses them. This means that the hardware (part of your network hardware) buffer is overfilling with packets which your program is doing other things and by the time your program comes around to collect them, some of them are missing. This causes one side to go "I didn't get those packets, send them again", in other words, your resending the packets you should of sucked up into a Que which are waiting to be dequeued and analysed. The queue can grow regardless of how quickly the program is back to grab that data and do stuff with it (of course you are confined to the RAM). That way you ensure that you have possession of packets that you are supposed to receive rather than rely on your network card/receiver to hold on to them for you, possibly overflowing its buffer.

Another approach is to do a handshake system were one of the programs waits until the last packet is trasmitted, recieved and the other side goes "Cool, send me the next one". This slows down your download/upload speed but is a little bit quicker than packets falling off the end of the end of one of the buffers (each node, such as your router buffers your packets in case more come in than it can handle at a cycle) in the network.

You should utilize a state machine if you can on one or both ends. When your app is downloading the file, lock it into a receive state so its not trying to send/receive other stuff at the same time. Once the download is complete, switch to any other state (say, open file state). If you don't know much about state machines, I recommend you look at the wikipedia article:

http://en.wikipedia.org/wiki/Finite-state_machine

Serguei Fedorov
  • 7,763
  • 9
  • 63
  • 94
  • This is mostly incorrect. TCP stops sending data when there isn't room in the receiver's receive buffer. – user207421 Jun 22 '12 at 23:48
  • The packets will fall of the end of the buffer if they are still in transit to the buffer and there is no space. Send/receive will stop but that doesn't completely solve the problem. Overflow of the buffer can happen by anything including the application your sending from and a number of other applications. This can happen at any point in the network route, sometimes with no route-around. Once the buffer opens up, the other side starts sending again however the same problem arises instantly because it fills up again and in transit packets fail to queue into the hardware buffer... once again – Serguei Fedorov Jun 23 '12 at 21:16