code:

---

t!=TIMER:laenge&=0
         WHILE TIMER-t!<5
          puffer&=Recv(fd&,MyMemory&+laenge&,1, MSG_PEEK%)
          IF puffer&>0 THEN
            position&=Recv(fd&,MyMemory&+laenge&,MIN(puffer&,maxlaenge&-1000), 0)
	    laenge&=laenge&+position&
	  ELSEIF puffer&=0 AND laenge&>0 THEN EXIT WHILE
          ELSE delay 1
          END IF
         WEND

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
Ich hab das mit dem waitselect prinzip mal auf msg_peek
adaptiert:

code:

---

t!=TIMER:laenge&=0
         WHILE TIMER-t!<5
          puffer&=Recv(fd&,MyMemory&+laenge&,1, MSG_PEEK%)
          IF puffer&>0 THEN
            position&=Recv(fd&,MyMemory&+laenge&,MIN(puffer&,maxlaenge&-1000), 0)
	    laenge&=laenge&+position&
	  ELSEIF puffer&=0 AND laenge&>0 THEN EXIT WHILE
          ELSE delay 1
          END IF
         WEND

---

Das müsste jetzt im Empfangsbereich NONBlocking sein.

---

Zitat:

---

Original von MaikG:
>Indem Du Dir die Dokumentation zur Funktion select() anschaust
>und dann Dein Socket damit "anstubst", damit es Dir sagt,
>ob überhaupt Daten da sind, die Du lesen könntest.
>Wenn ja, dann mach recv() und vergiß dabei dieses MSG_PEEK,
>das sich in Dein Hirn gebrannt hat. Wenn nein, warte nochmal
>mittels select() oder gar Waitselect() und evtl. nochmal.
>Wenn das einige Male fehlgeschlagen ist und keine Daten ankamen
>kannst Du Dein Socket schließen und das Programm mit ner
>Fehlermeldung beenden, dann kommt wahrscheinlich nichts mehr.
>Schlägt es nicht fehl, lies die Daten mit recv() ohne
>MSG_PEEK-Option und beginne wieder bei select() bzw. Waitselect(),
>bis recv() 0 zurückgibt, was bedeutet, daß das Dateiende erreicht
>ist.


Das würde dann fast das selbe machen wie der Code oben oder?

---

Zitat:

---

n = WaitSelect(nfds, readfds, writefds, exceptfds, timeout, signals)

Das einzige wäre wirklich, dann genau nur den >n< Wert zu lesen.

---

Zitat:

---

Da wüsste ich bei den vielen Parametern nicht was ich da übergeben
sollte.

---

Genau deswegen gibt es Dokumentation. Die solltest Du lesen. Was ein Descriptor ist, solltest Du eigentlich wissen, den hast Du bei connect() bereits benutzt. Das einzige Problem, daß ich sehe, sind die Macros, die für select() verwendet werden. Aber glaub mir, wenn Du das auseinandergepfriemelt hast, verstehst Du es auch. Also gib Dir Mühe.

Und was Holger Dir unter anderem sagen will, ist: Funktionen, die Rückgabewerte liefern, tun das nicht just for fun. Die Rückgabewerte sollen Dir etwas sagen! Und bei 3 Möglichkeiten, was recv() zurückliefern kann, kann es doch nicht so schwer sein, das Programm entsprechend zu gestalten.

Positive Zahl: Daten sind angekommen, nämlich genau so viel, wie die positive Zahl angibt.

0 bedeutet: Das wars, da kommt nichts mehr, mach Feierabend.

Negative Zahl bedeutet: Ey, hier ist was schiefgegangen, ich hab Dir ne Nachricht hinterlassen, was genau schiefgegangen ist.

Dein Problem ist, daß Du das ignorierst und Holger möchte Dich eigentlich nur davor bewahren, daß Du Dich (wie sonst auch üblich) verzettelst, weil Du mit abenteuerlichen Annahmen hantierst.

Also: Hör auf ihn, bau Deinen Code entsprechend um und dann zeig ihm den.
--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:

Ich mein nur wenn man X nicht kann heissts nicht das man Y nicht
kann. Wie gesagt hab die Peek option nicht richtig verstanden.

---

Zitat:

---

Ich muss nochmal schaun warum das ganze im anderen Programm
funktioniert hat.

---

Zitat:

---

>Ich weiß jetzt nicht, ob Dein Basic Compiler/Interpreter das so
>verdaut, aber ich schreib es mal für Dich hin...


Ich habe es NONENTRYBLOCKING das ist besser:

code:

---

t!=TIMER
    WHILE TIMER-t!<5
     IF Recv(fd&,MyMemory&,1, MSG_PEEK%)<>0 THEN
      position&=Recv(fd&,MyMemory&,maxlaenge&-1000, MSG_WAITALL%)
      EXIT WHILE
     ELSE delay 1
     END IF
    WEND

---

---

Zitat:

---

>Was wiederum zeigt, daß Du Dich mit I/O nie wirklich beschäftigt
>hast. Auch bei Dateien kann sowas auftreten, vor allem, wenn Du
>die gepuffert liest/schreibst.

Bissher habe ich keine Datei asyncron gelesen. Also wenn die datei
offen war konnte ich diese auch immer Lesen.
Gut, wenn man mit einer alten kaputten Diskette arbeitet könnte es
schon sein das was hängen bleibt.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
Und was hält WaitSelect vom Buffer Overlow ab?

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
>Du übergibst eine Speicheradresse und eine Länge an recv, wenigstens
>diese zwei Parameter solltest Du verstanden haben. Und jetzt guck
>Dir Deinen Code an.

Ja, die Parameter habe ich verstanden. Ich weiss auch das der Code
bei Negativen Rückgabewerten nicht korrekt funktioniert.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
Dann sprich doch nicht in Rätzeln, dann weiss ich evtl. was
du meinst.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
>BUFFER OVERFLOW
>Du hast geschrieben, Du wüsstest was das ist.

Ja, ein Puffer überlauf. Die Daten kommen schneller als erwartet
und der Puffer ist voll und kann keine neuen Daten aufnehmen.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:

Meiner ist 12 mal so groß wie die größte Datei die kommen kann.

---

[ - Antworten - Zitieren - Direktlink - ]

code:

---

t!=TIMER:laenge&=0
         WHILE TIMER-t!<5
          puffer&=Recv(fd&,MyMemory&+laenge&,1, MSG_PEEK%)
          IF puffer&>0 THEN
	    IF laenge&+puffer&>maxlaenge& THEN EXIT WHILE
            position&=Recv(fd&,MyMemory&+laenge&,puffer&, 0)
	    laenge&=laenge&+position&
	  ELSEIF puffer&=0 AND laenge&>0 THEN EXIT WHILE
          ELSE delay 1
          END IF
         WEND

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
Meiner ist 12 mal so groß wie die größte Datei die kommen kann.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

@MaikG:

Wir tasten uns langsam weiter vor... ok, select() ist Dir zu kompliziert, hab verstanden, lassen wirs halt.

Tu mir nur einen Gefallen und jammere nicht, wenn die Klamotte irgendwann trotzdem mal hängenbleibt, weil weitere Daten nach ein paar anfänglichen Bytes ausbleiben...

Ich hab Dir gesagt, was Dein Code tut, und das er das nur ein Mal tut, nämlich ganz zu Anfang, und daß das in einem für Dich ungünstigen Fall nicht ausreichend sein wird. Denk einfach dran, daß Du den Code eines schönen Tages vielleicht in ein anderes Projekt reindengelst und Dich dann nicht wundern willst, weshalb es mittendrin hängenleibt.

Jetzt gibts aber vor allem erst einmal 2 Sachen, die Du auf jeden noch zu erledigen hast, damit Holger zumindest wieder etwas gelassener tippen kann:

1. Der Fall n = recv()... mit n = -1
2. Der Fall, daß die Datei (wider Erwarten) größer wird, als Dein Puffer derzeit ist (buffer overflow). Dein Abbruch tut zwar seinen Dienst, aber machs Dir nicht immer ganz so einfach. Du hast ganz am Anfang gesagt, Du wolltest lernen... dann tus auch!

Wenn Du den Sinn dieser "Erweiterung" der Aufgabe nicht erfassen solltest: Wenn der Code dann auch in dieser Situation fehlerfrei funktioniert, kannst Du ihn in anderen Programmen problemlos verwenden um Dateien via http zu lesen, auch wenn Dir deren Größe nicht im Voraus bekannt ist.

Noch dazu kanns Dir helfen zu verstehen, wie buffered I/O funktioniert (was ja nicht nur bei Netzwerkzugriffen von Nutzen sein kann).

Komm nicht wieder mit "in der Firmwareversion kann die Datei gar nicht größer sein, weil blablabla...", mach einfach.

Zeig uns ein Mal, daß Du verstanden hast, was Holger Dir seit ner kleinen Ewigkeit näherbringen will: sauberes Programmieren inkl. guter Fehlerbehandlung und wenigstens einer kleinen Prise Vorausdenken.

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
>ok, select() ist Dir zu kompliziert, hab verstanden,
>lassen wirs halt.

Wenn mir jemand halt in in Deutsch sagen würde was
der 2. Parameter ist wäre das wohl nicht so kompliziert.

---

Zitat:

---

>Tu mir nur einen Gefallen und jammere nicht, wenn die Klamotte
>irgendwann trotzdem mal hängenbleibt, weil weitere Daten nach
>ein paar anfänglichen Bytes ausbleiben...

Wenn Recv/NULL nur jeweils die Anzahl Daten aus dem Puffer
holt die Recv/Peek als vorhanden angibt?

---

Zitat:

---

>1. Der Fall n = recv()... mit n = -1

Indirekt müsste das berücksichtigt sein.
Wenn -1 zurückkommen sollte, beginnt die Schleife von
vorn bis 5 sek um sind.
Weiss ich nicht wie sich das verhält, wenn -1 zurückkommt könnte
es theroretisch beim nächsten mal klappen.
Ansonsten könnte man in dem Fall gleich rausgehen.

---

Zitat:

---

>2. Der Fall, daß die Datei (wider Erwarten) größer wird, als
>Dein Puffer derzeit ist (buffer overflow).

Dann müsste ich einen weiteren Puffer anlegen, was aber einen erheblicher
mehraufwand wäre.

---

Zitat:

---

Denn wenn sich der html Inhalt grundlegend ändert
funktioniert der Rest des Programmes ohnehin nicht mehr.

Wenn ich irgendwann mal beliebig große htmls benutzen will werde
ich das entsprechend anpassen.

---

Genau vor dieser Aussage hatte ich Angst... wetten, daß Du Dich dann nicht mehr an diesen Thread erinnern wirst? Tu es jetzt, dann hast Du für laaaange Zeit ein ziemlich universell einsetzbares Teilprogramm, mit dem Du, ohne viel Grübeln, wie was funktioniert, arbeiten kannst.

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:

Zitat:

---

>In der Dokumentation steht, unter welchen Umständen -1 zurückkommen
>kann...

---

Hab ich gelesen. In diesem Fall (blocking mode, übergabe parameter
werden geprüft) kommt da eigentlich keiner in frage.

---

Zitat:

---

Original von Holger:

Wenn der Rückgabewert von recv (mit MSG_PEEK) 0 ist, kann das heißen, das die Datei zu Ende ist, aber auch, dass keine Daten gelesen wurden, Das findest Du aber definitiv nicht dadurch raus, dass Du die bisher gelsene byte-Zahl mit 0 vergleichst. Eine Datei kann die Länge 0 haben, und eine Verbindung kann auch dann langsamer werden, wenn Du schon ein byte gelesen hast, ohne dass die Datei schon zu Ende ist.

recv, sowohl mit als auch ohne MSG_PEEK kann -1 zurückliefern, wenn ein Fehler aufgetreten ist. Dein Code wartet dann bis in alle Ewigkeit. Wenn Dir schon die timeouts Deine TCP/IP Stacks zu lang sind, was ist dann mit Deinem Code?

---

Zitat:

---

>Eigentlich nicht. Doppelt verkettete Listen sind Deine Freunde...

Kein schimmer was das wieder ist.

---

Zitat:

---

Also müsste man höchstens einen 2.(3...) Puffer beim Überlauf
anfordern und die am Ende in einem neuen der groß genug ist
umkopieren.

---

Zitat:

---

Andere Methoden wärend des Empfangs wären zu komplex

---

Zitat:

---

und würden zum BSD-Pufferüberlauf führen.

---

Du hast noch immer nicht verstanden, was man unter einem Pufferüberlauf versteht. Schade.

--
http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:

Die Fehler die im Doc beschrieben sind, scheinen im vorliegenden
Fall nicht(unter keinen umständen) auftreten zu können.
Wenn ich das richtig verstanden habe.

---

Zitat:

---

Nodes, ja kenn ich vom Listview.
Trotzdem alles andere als Leicht zu implementieren und
erheblicher Rechenaufwand.

---

Zitat:

---

>Du hast noch immer nicht verstanden, was man unter einem
>Pufferüberlauf versteht. Schade.

Ich weiss was ich darunter verstehe und das meine ich auch.

Nehmen wir einen Wassertonne, in die kontinuierlich Wasser reinläuft.
Wenn ich nicht immer mit der Gießkanne Wasser abnehme läuft diese
Über.

---

O.k. ich hätte wohl korrekterweise schreiben müssen: Was man in der Informatik unter einem Pufferüberlauf versteht.

Aber von der Analogie her passt das Beispiel mit dem Bank-Überweisungsformular eben doch besser.

Also auf ein neues: Pufferüberlauf (Buffer Overflow) für Dummies:

Nehmen wir an, Du hättest ein Array fester Größe definiert, welches, sagen wir für 8 Elemente Platz bietet:

code:

---

[ ][ ][ ][ ][ ][ ][ ][ ]

---

code:

---

[H][a][l][l][o][!][ ][ ]

---

code:

---

[H][a][l][l][o][ ][W][e] l t !

---

[ - Antworten - Zitieren - Direktlink - ]

@Mad_Dog:

Prinzipiell hat er das mit dem Pufferüberlauf verstanden, er hat nur noch nicht realisiert, daß es uns ausschließlich um den von ihm angelegten Puffer geht und daß dieser (bis auf die Tatsache, daß er später Daten vom socket hineinkopiert bekommt) wenig bis gar nichts mit dem socket-Puffer zu tun hat.

@MaikG:

Mag sein, daß ich da nicht richtig liege, der absolute Held in Sachen bsdsocket bin ich nicht, aber was ich bisher an Code und Doku zu sehen bekam sagt mir, daß der socket-Puffer im "Normalbetrieb" nicht überläuft, sondern die Verbindung "stalled" (also stehenbleibt). bsdsocket.library wartet dann mit weiteren Forderungen an die Außenwelt nach neuen Daten, bis Du den socket-Puffer "geräumt" hast.

Anders sieht das wohl aus, wenn Du den Socket im non-blocked mode betreibst und zusätzlich Datenblöcke haben willst, die als Vielfaches die Größe des socket-Puffers teilweise überschreiten können. Aber selbst für den Fall scheint bsdsocket gerüstet.

Wichtigste Frage ist aber, bevor ich mir die Mühe mache, select() zu erklären: Willst Du überhaupt den sauberen Weg gehen?

Ich habe jetzt schon wieder den Eindruck, daß Du mit aller Gewalt an Deiner gefundenen "Lösung" festhältst und keinen Millimeter mehr davon abweichst. Das Gequängel um den Fall, daß recv() -1 zurückgibt, stimmt mich da arg nachdenklich, dabei brichst Du Dir nun wirklich keinen Zacken aus der Krone, wenn Du diesen Fall sauber abfängst. Ein oder zwei IF-Klauseln mehr, ist doch eigentlich ein Klacks, oder?

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
Nodes, ja kenn ich vom Listview.
Trotzdem alles andere als Leicht zu implementieren und
erheblicher Rechenaufwand.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
Nehmen wir einen Wassertonne, in die kontinuierlich Wasser reinläuft.
Wenn ich nicht immer mit der Gießkanne Wasser abnehme läuft diese
Über.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Maja:

Zitat:

---

Original von MaikG:
Nehmen wir einen Wassertonne, in die kontinuierlich Wasser reinläuft.
Wenn ich nicht immer mit der Gießkanne Wasser abnehme läuft diese
Über.

---

Jetzt nehme noch an, dieser Wassertonne gehört einem Wirt und neben der Wassertonne steht ein Weinfass. Das überlaufende Wasser läuft aus der Wassertonne in das Weinfass. Der Wein verwässert und der Wirt wird wegen Panscherrei verklagt.

---

Auch eine sehr schöne Analogie.

Fehlt nurnoch daß jemand kommt und mittels Typecast das Wasser zu Wein macht, dann passt wieder alles.

--
http://www.norman-interactive.com

[ Dieser Beitrag wurde von Mad_Dog am 04.05.2008 um 01:07 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Mad_Dog:
Fehlt nurnoch daß jemand kommt und mittels Typecast das Wasser zu Wein macht, dann passt wieder alles.

---

Der wurde vor etwas mehr als 2000 Jahren auf Wunsch des Volkes ans Kreuz genagelt. Allerdings gibt es Stimmen die behaupten, in der Zeitrechnung hätte sich ein Bug eingeschlichen. Demnach haben wir jetzt 2001 oder 2004 n.Chr. und 2008 ist ein Buffer Overflow.

So, Spass gehabt. Back to Topic, please.

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:

>Das Gequängel um den Fall, daß recv() -1
>zurückgibt, stimmt mich da arg nachdenklich, dabei brichst Du
>Dir nun wirklich keinen Zacken aus der Krone, wenn Du diesen
>Fall sauber abfängst. Ein oder zwei IF-Klauseln mehr, ist
>doch eigentlich ein Klacks, oder?

Kann ich machen. Aber ist das wirklich besser?
So probiert das Programm weiter, ist das nicht evtl. besser
als beim 1. Fehler abzubrechen?
Beim Lesen eine Diskette macht ADos auch 5 Retrys.

---

basic code:

---

t!=TIMER:laenge&=0
         WHILE TIMER-t!<5
          puffer&=Recv(fd&,MyMemory&+laenge&,1, MSG_PEEK%)
          IF puffer&>0 THEN
	    IF laenge&+puffer&>maxlaenge& THEN EXIT WHILE
            position&=Recv(fd&,MyMemory&+laenge&,puffer&, 0)
            
            Rem Falls recv fehlschlägt, aus der Schleife aussteigen
            IF position%=-1 THEN EXIT WHILE

	    laenge&=laenge&+position&
	  ELSEIF puffer&=0 AND laenge&>0 THEN EXIT WHILE
          ELSE delay 1
          END IF
         WEND

---

Zitat:

---

>Implementier es einfach. Wenn Du es einmal wirklich benutzt hast,
>dann wirst Du es schätzen lernen.

Ich glaube mit dem overhead würde ich den Support von langsameren
Prozessoren einfach killen.

---

[ - Antworten - Zitieren - Direktlink - ]