Question

Here is what I have right now.

Receiver:

public static void read(Socket socket, ObjectInputStream in) {
    try {
        String separator = in.readUTF();
        while (in.readByte() == -3) {
            String path = in.readUTF().replaceAll(separator, System.getProperty("file.separator"));
            File file = new File(new File(path).getParent());
            if (!file.exists()) {
                file.mkdirs();
            }
            FileOutputStream fos = new FileOutputStream(path);
            int b = 0;
            while ((b = in.readByte()) != -4) {
                fos.write(b);
            }
            fos.close();
        }
    } catch (Exception e) {
        e.printStackTrace();
    }
}

Sender:

public static void send(String[] path) {
    Socket socket;
    try {
        socket = new Socket(ip, port);
        socket.setKeepAlive(true);
    } catch (UnknownHostException e) {
        return;
    } catch (IOException e) {
        return;
    }
    try {
        ObjectOutputStream out = new ObjectOutputStream(socket.getOutputStream());
        out.writeUTF(Devbox.getSeparator());
        for (String s : path) {
            send(s, out);
            out.writeByte(-2);
        }
        out.close();
        socket.close();
    } catch (Exception e) {
        e.printStackTrace();
    }
}

private static void send(String path, ObjectOutputStream out) {
    File file = new File(path);
    if (file.isDirectory()) {
        File[] files = file.listFiles();
        for (File f : files) {
            send(path + f.getName(), out);
        }
    } else {
        try {
            out.writeByte(-3);
            out.writeUTF(path);
            FileInputStream fis = new FileInputStream(file);
            int b = 0;
            while ((b = fis.read()) != -1) {
                out.writeByte(b);
            }
            fis.close();
            out.writeByte(-4);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

This is the error I get in the sender.

java.net.SocketException: Software caused connection abort: socket write error
    at java.net.SocketOutputStream.socketWrite0(Native Method)
    at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
    at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
    at java.io.ObjectOutputStream$BlockDataOutputStream.writeBlockHeader(ObjectOutputStream.java:1874)
    at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1855)
    at java.io.ObjectOutputStream$BlockDataOutputStream.writeByte(ObjectOutputStream.java:1895)
    at java.io.ObjectOutputStream.writeByte(ObjectOutputStream.java:760)

It points to

                out.writeByte(b);

It sends about 25 files successfully, then throws this error. The file it throws it on is different each time, but it is in the same range of about 5 files. The receiver stops after one specific file which is usually a couple before the file the sender stops on. It stops because in.readByte() == -3 is false. When it happens, I got numbers like -85 and 16. I tried it on another computer, since it said something about software, and it was the exact same. Does anyone know why this is happening? I’ve spent a day trying to figure it out, and gotten nowhere. Any help is greatly appreciated.

Answer 1

Please read this answer, I don’t think anything else can be said beyond that, also I don’t see anything in your code which will close the connection.

From OTN Discussion

WinSock description: The error can occur when the local network system
aborts a connection. This would occur if WinSock aborts an established
connection after data retransmission fails (receiver never
acknowledges data sent on a datastream socket).

TCP/IP scenario: A connection will timeout if the local system doesn’t
receive an (ACK)nowledgement for data sent. It would also timeout if a
(FIN)ish TCP packet is not ACK’d (and even if the FIN is ACK’d, it
will eventually timeout if a FIN is not returned).

It seems to happen more with WindowsXP and it seems also to be
possibly related to Windows firewall settings. In any case the salient
point is that the abort has originated inside the local machine.