Leere Zeilen bei Socket-Verbindung

Da muss ich Dennis zustimmen. Haste recht ;)

Bei mir war der gedanke... wenn gelesen wird... und sowieso NIX zurück gegeben wird kanns auch weg gehaun werden... aber mitm String wäre es wirklich am besten.

Ansonsten könnte man ein String nutzen und im nachhinein aus dem String ein Array machen mit den werten. Dann hat er sein Array (warum auch immer er es so brauch) ohne leere werte.
 
Das mit if( fgets($socketConnection) != "") habe ich natürlich schon mal gemacht.
Das Problem ist, dass ich oft 100.000 leere Zeilen bekommen und die Abfrage dementsprechend 2-3 Minuten dauert.

Ich möchte nicht in ein String einlesen, da jede Zeile ein Datensatz ist und ich
sonst wieder alles parsen muss. (zudem eben die Performance Sache wie oben beschrieben)
Wenn ich das machen wollte, wie sehe einen Zeilenumbruch beim nachträglichen parsen
(Daten werden als ASCI auf der Seite ausgegeben)

Ich persoenlich finde diese Herangehensweise naemlich recht unpraktisch wenn es dann an die Auswertung der Antwort vom Server geht.
Zum Vergrößern anklicken....
versteh gerade nicht was du damit meinst.



Zu meiner Frage hat noch keiner Stellung genommen:
Für was wird denn eigentlich das fputs bzw. fwrite benötigt.
Muss man unbedingt einen header mitschicken und wofür steht das \r \n
ohne diese Zeile sehe ich keinen Unterschied.
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
Okay, wenn bei Dir eine Zeile einen Datensatz darstellt kann ich verstehen warum Du mit einem Array arbeitest.
.Andernfalls waere aber, meiner Meinung nach, ein String besser da zur ich es zur Auswertung besser finde die Server-Antwort in einem String zu haben und dann zerlege wie ich es fuer richtig halte.

Das fputs()/fwrite() ist noetig um ueberhaupt erstmal die Anfrage an den Server zu schicken. Der faengt ja nicht einfach an zu senden nur weil Du Dich verbindest.
Entsprechend musst Du eine Anfrage an den Server schicken, ihm eben mitteilen was Du denn ueberhaupt von ihm willst.

Ich denke einen marginalen Header sollte man schon mitschicken. Ich bin nicht sicher wie weit der gekuerzt werden kann, moeglicherweise wuerde GET / reichen, bin grad nicht sicher. Ist was her dass ich das RFC gelesen hab.
\r\n ist ein Zeilenumbruch, genauer gesagt ein Windows-Zeilenumbruch.
\r ist ein Carriage-Return, \n ist New-Line. Diese "heilige Zweifaltigkeit" stammt noch aus der Zeit der Schreibmaschinen wo man am Zeilenende eben in die naechste Zeile gesprungen ist und dann den "Klotz" (sorry, mir faellt der Begriff grad nicht ein, und ich will auch nicht einfach Carriage sagen ;) ) wieder zum Beginn der Spalte schiebt.
Auch fuer Unix-Server wird, meines Wissens nach, in HTTP \r\n genutzt, obwohl ein Unix-Zeilenumbruch lediglich aus \n besteht.
Grund duerfte wohl sein dass das \r unter Unix-Systemen einfachen nicht beachtet wird, aber unter Windows eben noetig sein duerfte.

Wie gesagt, ist was her dass ich die entsprechenden RFCs gelesen hab, koennte mich also in Details irren.
 
Also wenn ich mir die html Seite direkt anschaue und den Quellcode anzeigen lasse bekomme ich folgendes (zensierte Version)

Code: 
<html>
<head><title>Dlis</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body>
<pre>
[HOST used]serverx from {serverx,servery}	no of Screens: 1	no of lots: 4	sessionId 0a14021622b84df1a36ef3804618801bb41871e79f2d
SYS  5/05/09 15:01:19
TEGHN               xx                      xxxx 1-4 OF 4 
xxx xxx x: xxxx     xxxxxxx xxxx:   3 xxx:   64     xxxx xxxx:   1 xxx:   13     xxxxxx xxxx:   0 QTY:    0                     
                                                                                                                                  
XXX XXX    XXX.   XXX.  XXXX XXXX XXXXXXXX                 XXXX-XX XXXXXXXXXX                                xx xx xxx x x  
--- ------ ------- ----- ---- ---- ----------------------------------- ----------------------------------------- -- -- --- - -  
 XXX 64845 XXXXXXX bla 1234 XY01 Text123             150XX 1234/567 XY011 XY012                               25 X  0     N  
     62927 XXXXXXX bla 1234 XY01 Text123             150XX 1234/567 XY011 XY012                               15 X  0     N  
count: 2
</pre>
</body></html>


Die Zeilen unter den Stichen sind dann die Datenzeilen.
 
Wie gesagt:
Dennis Wronka hat gesagt.:
Ich koennte mir hier eher vorstellen dass das Problem ist dass PHP eben anfaengt zu lesen, aber noch nix zurueckkommt, aber eben auch kein EOF, sodass eben PHP weiterhin liest bis der Server nun auch wirklich seine Antwort und das anschliessende EOF sendet.
Zum Vergrößern anklicken....

Wenn man also in einen String liest faellt das nicht auf, bei einem Array scheinbar schon.
Wie gesagt, ich koennte das mit meiner Klasse mal probieren, hab's bislang aber noch nicht gemacht.
 
Danke für das bisherige Feedback,
aber was ich brauche ist eine Lösung und kein Workarround.

Denn 100.000 mal einen String einzulesen dauert immer noch mehrere Minuten und so lange kann ich nicht bei jeder Abfrage warten.

Was mir noch aufgefallen ist:
wenn ich eine html Datei mit dem oben genannten Code bei meinem Apache ablege bekomme ich nur wenige leere Zeilen.
Auf dem Server auf dem ich mir die Daten über dieses Java Servlet hole bekomme ich die genannten 100.000 Zeilen, obwohl der gleiche html Quellcode in Firefox ausgegeben wird.
 
Dauert's im Firefox denn auch so lange?

Ansonsten, vielleicht ist ja irgendeine kuenstliche Bremse gegen Downloader drin, versuch doch mal den User-Agent vom Firefox vorzutaeuschen. Manchmal kann sowas helfen.
 
Gut, also koennen wir wohl ausschliessen dass die Dauer irgendwie mit dem PHP-Script zusammenhaengt wenn es eben so viele Daten sind und eben auch im FF so lang dauert.

Dann ist eben noch die Sache mit den leeren Zeilen. Ich denk mal ich werd gleich mal kurz meine Klasse anpassen und es dann damit testen ob ich auch leere Zeilen kriege.

Edit: So, hab grad mal kurz getestet und meine Klasse so umgebaut dass sie in ein Array liest. Anders als bei Dir sehe ich aber keine leeren Zeilen am Anfang des Arrays, bei mir geht es gleich zur Sache.
Aber vielleicht ist das ja auch weil der Server nicht so lang auf sich warten laesst.

Wenn Du 'ne URL fuer mich hast wo Du das Problem hast dann koennte ich ja da mal testen.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück