Endlosschleife, Sockets

[StupidAttack]

Folgende Methode verlässt niemals die while-Schleife. Den Content empfängt sie problemlos, nur halt wird der String line niemals null. Hat jemand ne andere Idee, wie man ein Kriterium für ein Schleifenende findet?

    public String crawl() {
        try {
            InetAddress addr = InetAddress.getByName(this.host);
            Socket socket = new Socket(addr, this.PORT);

            /* Build Request */
            BufferedWriter wr = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream(), "UTF8"));
            wr.write("GET "+this.path+" HTTP/1.1\r\n");
            wr.write("Host: "+this.host+"r\n");
            wr.write("User-Agent: "+this.user_agent+"\r\n");
            wr.write("\r\n");

            wr.flush();

            // Get response
            BufferedReader rd = new BufferedReader(new InputStreamReader(socket.getInputStream()));
            String line = rd.readLine();
            while (line != null) {
                               
                this.html_content += line;
                line = rd.readLine();
            }
            
            
            wr.close();
            rd.close();


        } catch (Exception ex) {
            ex.printStackTrace();
        }
        return html_content;
    }

 

[SlaterB]

das Lesen endet nicht weil die andere Seite nicht geschlossen wird, das ist zunächst normal, kein Problem,

man könnte in die Kommunikation ein Protokoll einbauen, wenn ENDE gesendet wurde, dann ist Ende, auch wenn die Gegenseite zu faul ist, das selbst zu machen,
wenn man der Gegenseite nicht sagen kann was es senden soll und auch sonst keine Ahnugng zur Interpretation der Daten hat, dann kann man einfach nur warten,
wie lange man Leerlauf ohne neue Daten akzeptiert, muss man selber wissen, danach selber die Verbindung beenden,

dazu entweder einen Timeout setzen, dann dürfte der read()-Aufruf mit einer Exception unterbrochen werden, wenn ich mich nicht irre,
oder notfalls einen eigenen zweiten Thread nebenher laufen lassen der die Verbindung killt

 

[Murray]

In diesem speziellen Fall scheint es ja um HTTP zu gehen - da gibt es den Content-Length-Header, den man auswerten könnte, sobald er auftaucht. Bis dahin (oder wenn so ein Header nicht geschickt wird), kann man nur mit einem Timeout arbeiten, wie Slater schon schrieb.