Menu

Random Transfer Behavior / Problem

2011-07-07
2013-05-17
  • Alexander Senf

    Alexander Senf - 2011-07-07

    Hi,

    I am using a UDT-Java server and client to transmit large files; at present I am just trying to get it to work on localhost. I have run into an issue where file transfers are randomly interrupted mid-transfer, always at different locations. To start out I am just transferring a 5 MB PDF test file. Transmission ends randomly anywhere after 19 KB to about 3 MB.

    If I place breakpoints at the beginning of the code and step through it (using Netbeans) the transfer usually completes without any problem. Just running the compiled jar causes interrupted transmissions. This happens both in Linux and Windows environments.

    The basic client/test code looks like this:

            int port = 10057;
            UDT_Server the_server = new UDT_Server(port);
           
            Thread x = UDTThreadFactory.get().newThread(the_server);
            x.start();

            UDTClient the_client = UDTClient(InetAddress.getLocalHost(), (port+1));
            the_client.connect("127.0.0.1", port);           

            File file = new File("received.pdf");
            FileOutputStream fout = new FileOutputStream(file);

            UDTInputStream in = the_client.getInputStream();
            InputStream in_ = in;
           
            byte xx = new byte; int yy = 0;
            while ((yy = in_.read(xx)) > 0) {
                fout.write(xx, 0, yy);
            }
            fout.close();       
            the_client.shutdown();

    And the relevant server code is:

            UDTSocket clientSocket = null;
            clientSocket = this.socket.accept();
            OutputStream out = clientSocket.getOutputStream();
            File file=new File("Newcomers_brochure.pdf");
            FileInputStream fis = FileInputStream(file);
            long size=file.length();
            Util.copy(fis, out, size, true);
            fis.close();
            clientSocket.close();

    As far as I can tell, what seems to happen is that the receiver thread closes down before before the entire file is transferred, leaving in the end one sender thread hanging indefinitely. In the sender thread it basically hangs at the flush() method in Util.copy(.

    This is a typical execution log generated by an interrupted transmission:

    run:
    Creating Server on Port: 10057
    07-Jul-2011 10:54:33 udt.UDTServerSocket <init>
    INFO: Created server endpoint on port 10057
    UDT Server Socket Created. 0.0.0.0
    Server thread started!
    07-Jul-2011 10:54:33 udt.UDPEndPoint start
    INFO: UDTEndpoint started.
    07-Jul-2011 10:54:33 udt.UDTClient <init>
    INFO: Created client endpoint on port 10058
    07-Jul-2011 10:54:33 udt.UDTSession <init>
    INFO: Using udt.UDTCongestionControl
    07-Jul-2011 10:54:33 udt.ClientSession <init>
    INFO: Created udt.ClientSession@1749757
    07-Jul-2011 10:54:33 udt.UDPEndPoint addSession
    INFO: Storing session <96>
    07-Jul-2011 10:54:33 udt.UDPEndPoint start
    INFO: UDTEndpoint started.
    07-Jul-2011 10:54:33 udt.ClientSession sendHandShake
    INFO: Sending ConnectionHandshake , mySocketID=96, initialSeqNo=1052671622, packetSize=1400, maxFlowWndSize=10240, socketType=1, destSocketID=0]
    07-Jul-2011 10:54:33 udt.UDTSession <init>
    INFO: Using udt.UDTCongestionControl
    07-Jul-2011 10:54:33 udt.ServerSession <init>
    INFO: Created udt.ServerSession@1960f05  talking to /127.0.0.1:10058
    07-Jul-2011 10:54:33 udt.UDPEndPoint addSession
    INFO: Storing session <97>
    07-Jul-2011 10:54:33 udt.ServerSession received
    INFO: Received ConnectionHandshake
    07-Jul-2011 10:54:33 udt.UDTSession setState
    INFO: udt.ServerSession@1960f05  connection state CHANGED to <1>
    07-Jul-2011 10:54:33 udt.ServerSession handleHandShake
    INFO: Sending reply ConnectionHandshake , mySocketID=97, initialSeqNo=1052671622, packetSize=1400, maxFlowWndSize=10240, socketType=1, destSocketID=96]
    07-Jul-2011 10:54:33 udt.UDTSession setState
    INFO: udt.ServerSession@1960f05  connection state CHANGED to <2>
    07-Jul-2011 10:54:33 udt.ClientSession received
    INFO: Received connection handshake from Destination
    ConnectionHandshake
    07-Jul-2011 10:54:33 udt.UDTSession setState
    INFO: udt.ClientSession@1749757  connection state CHANGED to <2>
    UDT Socket Accepted!
    07-Jul-2011 10:54:33 udt.UDTSender start
    INFO: Starting sender for udt.ServerSession@1960f05
    07-Jul-2011 10:54:34 udt.ClientSession connect
    INFO: Connected, 1 handshake packets sent
    07-Jul-2011 10:54:34 udt.UDTClient connect
    INFO: The UDTClient is connected
    Client connected! - udt.UDTClient@1b1aa65
    07-Jul-2011 10:54:34 udt.UDTSession setState
    INFO: udt.ServerSession@1960f05  connection state CHANGED to <4>
    07-Jul-2011 10:54:34 udt.ServerSession received
    INFO: Connection shutdown initiated by the other side.
    07-Jul-2011 10:54:34 udt.UDPEndPoint doReceive
    INFO: SocketException: socket closed
    07-Jul-2011 10:54:34 udt.UDTReceiver$1 run
    INFO: STOPPING RECEIVER for udt.ServerSession@1960f05
    07-Jul-2011 10:54:34 udt.UDTSender$1 run
    INFO: STOPPING SENDER for udt.ServerSession@1960f05
    07-Jul-2011 10:54:34 udt.UDTReceiver$1 run
    INFO: STOPPING RECEIVER for udt.ClientSession@1749757

    BUILD STOPPED (total time: 5 seconds)

    Any help is greatly Appreciated!

    Alex

     
  • Alexander Senf

    Alexander Senf - 2011-07-07

    OK - in retrospect, this was obvious: the receiving buffer is depleted faster than it is filled, so it reaches a length of 0 ocasionally, which causes this code to exit prematurely:

    while ((yy = in_.read(xx)) > 0) {
        fout.write(xx, 0, yy);
    }

    Solution: check for ">-1" in the loop; what I actually implemented is to send the size of the data to be expected first, and then read from the input stream until that number is reached.

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.