amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > Http Post Request [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 -2- 3 4 [ - Beitrag schreiben - ]

29.04.2008, 17:47 Uhr

MaikG
Posts: 5172
Nutzer
>schaffen wirst Du es nicht, wenn Du es nicht kapierst:

Wieso? Es läuft doch schonlängst.




>Was macht MSG_PEEK?

Offensichtlich liefert es den Pufferfüllstand.
Und schreibt ohne Grund in meinen Puffer, weshalb ich
offensichtlich die Funktion der Option fehlinterpretiert habe.


>Dass Du die Daten nicht wirklich abholst.

Der Code stand lange da, warum sagst du nicht:
benutze MSG_PEEK um den Pufferfüllstand zu prüfen und anschließend
MSG_WAITALL weil es mit MSG_Peek alleine nicht geht ?

Dann hätte man sich die ganze Diskussion sparen können und ich
wäre etwas früher fertig gewesen.

So musste ich halt rumprobieren bis ich alleine die Lösung gefunden
hatte.

[ - Antworten - Zitieren - Direktlink - ]

29.04.2008, 17:54 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von Holger:

Zitat:
Da MSG_PEEK in meinen Puffer schreibt, gehe ich davon aus das
ich die Daten im gewissen sinne abhole.

Hallo? Hirn?
Was macht MSG_PEEK? Worin liegt der Unterschied zum normalen Aufruf ohne dieses Flag. Worin liegt der einzige Unterschied? Dass Du die Daten nicht wirklich abholst.


Vermutlich weiß er nicht, was der Unterschied ist.

Das kann man aber ganz leicht und für (hoffentlich) jeden verständlich anhand eines Stacks erklären:

Ein Stack ist (wie der Name schon vermuten lässt) ein Stapel.
Traditionell sind zwei Operationen für einen Stack definiert:

Push - Ein Element auf den Stapel legen
Pop - Das oberste Element vom Stapel nehmen

Neben dieses zwei elementaren Funktionen kann man auch noch folgende implementieren:

Peek - Das oberste Element des Stapels lesen, ohne es jedoch vom Stapel zu nehmen.

Es sei z.B. folgender Stapel gegeben:

3 8 9 0 1 7 2

Jetzt mache ich ein Push(6), dann habe ich:

3 8 9 0 1 7 2 6

Jetzt mache ich ein Peek, erhalte 6 und der Stapel bleibt der gleiche:

3 8 9 0 1 7 2 6

Jetzt mache ich ein Pop und erhalte die 6. Der Stapel reduziert sich um ein Element:

3 8 9 0 1 7 2

Mache ich noch ein Pop, erhalte ich die 2 und der Stapel sieht so aus:

3 8 9 0 1 7

Alles klar?

Wenn man jetzt also z.B. eine Schleife programmiert, deren Abbruchbedingung sein soll, daß kein Element mehr auf dem Stapel liegt, gleichzeitig aber versucht, die Elemente mit Peek und nicht mit Pop abzuholen, wird die Schleife ewig weiterlaufen, weil die Abbruchbedingung ja nie erfüllt sein wird, weil sich der Stapel ja nicht leert.

Und genau das ist es, was Holger Dir versucht, die ganze Zeit zu erklären.

Wenn Du was nicht verstehst, dann frag nach. Aber sag jetzt bitte nicht wieder, Du hättest das doch schon immer gewusst, denn daß dies nicht der Fall ist, sieht man daran, wie Du rumwurstelst.

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


[ Dieser Beitrag wurde von Mad_Dog am 29.04.2008 um 20:29 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

29.04.2008, 18:01 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von MaikG:
Der Code stand lange da, warum sagst du nicht:
benutze MSG_PEEK um den Pufferfüllstand zu prüfen und anschließend
MSG_WAITALL weil es mit MSG_Peek alleine nicht geht ?

Wer hat denn vor kurzem rumgeheult, weil der Aufruf nicht zurückkommt, bevor nicht wenigstens ein byte gelesen wurde?
Jetzt benutzt Du also ein Flag, bei dem die Funktion sogar erst dann zurückkommt, wenn alle angeforderten bytes gelesen wurden, und dass stellt dann also eine "Lösung" dar?
Zitat:
Dann hätte man sich die ganze Diskussion sparen können und ich
wäre etwas früher fertig gewesen.

So musste ich halt rumprobieren bis ich alleine die Lösung gefunden
hatte.

Du kleines Arschloch, anders kann man es ja nicht bezeichen. Du findest ja immer alleine die Lösung, weil Du absolut merkbefreit und lernresistent sind, und die Lösungen der anderen nie gut genug für Dich sind, während Dein Unsinn, der überhaupt nicht die Anforderungen erfüllt, die Du vorher gestellt hast, die "Lösung" darstellt. Die die ganz alleine gefunden hast, natürlich.

Wer hier wessen Zeit gestohlen hat, wie immer, dürfte jeder außer Dir schon bemerkt haben.
Aber: ab jetzt darfst Dir jede Diskussion hier sparen und früher fertig sein. Viel Glück.

[ - Antworten - Zitieren - Direktlink - ]

29.04.2008, 23:25 Uhr

Ralf27
Posts: 2779
Nutzer
Es tut jetzt zwar nichts direkt zur Sache, aber eins muß ich hier jetzt auch mal tippen:

MaikG, ich lese hier auch im Programmiererforum die einzelnen Threads mit durch(nicht alle, aber vermutlich die meisten), da ich so auch was lernen kann. Wir beide haben das "Problem" das wir die meisten Programme in MaxonBasic programmieren, was ja bekanntlich recht tot ist. Dazu kommt, das wir beide oft mit Problemen hier im Forum auftauchen und um Hilfe suchen. Ich bin für diese Hilfe hier im Forum sehr dankbar. Denn die User hier müssen ja keinem anderem helfen, sie machen es aber dennoch. Ich stand auch oft schon in dem einen oder anderen Thread von mir auf dem Schlauch und bin dann durch einen "Schubs" von den Profis wieder weiter gekommen,
aber wenn ich das hier lese was hier(unter anderem in diesem Thread) schon geschriebenn wurde...

Wieso ich das hier schreibe?
Ich wurde in einem Thread schon in einem Rutsch mit dir über einen Kamm geschoren und zwar in Sachen lernresistenz. Ich fand das auch nicht gerade sehr witzig. Ich hoffe wirklich inständig das ich nicht genau so "blockiert" bin. Sorry, ich wußte nicht wie ich es sonst schreiben sollte.
--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 29.04.2008 um 23:27 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

30.04.2008, 00:34 Uhr

MaikG
Posts: 5172
Nutzer
>Wenn man jetzt also z.B. eine Schleife programmiert,
>deren Abbruchbedingung sein soll, daß kein Element mehr auf
>dem Stapel liegt, gleichzeitig aber versucht, die Elemente mit
>Peek und nicht mit Pop abzuholen, wird die Schleife ewig
>weiterlaufen, weil die Abbruchbedingung ja nie erfüllt sein wird,
>weil sich der Stapel ja nicht leert.

Das ist sehr schön erklärt, an die assoziation mit dem
Stack hab ich gar nicht gedacht.


>Und genau das ist es, was Holger Dir versucht, die ganze Zeit zu
>erklären.

Naja, nicht wirklich oder es war so ausgedrückt das ich es nicht verstanden
habe bsp:

>Posts: 5280

> Zitat:
> Original von MaikG:
> code:
> position&=Recv(fd&,MyMemory&,maxlaenge&-1000,MSG_PEEK%)
> IF position&>0 AND positionold&=position& THEN EXIT WHILE
> positionold&=position&
>Recv liefert die Anzahl gelesener bytes zurück und keine Position (wie kommst Du darauf, dass es anders sein könnte?). Wenn Du Deinen Lesevorgang abbrichst, sobald Du zweimal hintereinander die gleiche Anzahl bytes liest, brauchst Du Dich auch nicht zu wundern.
>
>Du wirst allerdings auch nicht viel Spaß an den gelesenen Daten haben, wenn Du bei jedem Aufruf von Recv die gleiche Puffer-Adresse übergibst.


Er zitiert meinen Code und schreibt das ein Abbrechen des "Lesevorgang" stattfindet.

Also musste ich davon ausgehen das ich von dem prinzip her die
Daten richtig Lese.
Keine rede davon das peek nun gar kein regulärer Lesevorgang ist.

Auch das mit Daten, nicht bezogen auf die Peek Option. Denn
wenn ich die daten auf $10000 "lese" und dann nochmal auf $50000
hab ich so und so die selben Daten. Weil Peek liesst immer das
selbe.

>Wer hat denn vor kurzem rumgeheult, weil der Aufruf nicht
>zurückkommt, bevor nicht wenigstens ein byte gelesen wurde?

Ja, ausser komplizierte gibt es keine Lösung. Scheint mir.

>Jetzt benutzt Du also ein Flag, bei dem die Funktion sogar erst dann zurückkommt,
>wenn alle angeforderten bytes gelesen wurden, und dass stellt dann also eine "Lösung" dar?


Nee, nicht ganz.

Mit MSG_Peek wird bestimmt ob Daten im Puffer sind, sind 10 Sekunden
keinen Daten im Puffer wird recv+MSG_WAITALL niemals aufgerufen und
meine Funktion kommt zurück.

[ - Antworten - Zitieren - Direktlink - ]

30.04.2008, 08:51 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von MaikG:
>Und genau das ist es, was Holger Dir versucht, die ganze Zeit zu
>erklären.

Naja, nicht wirklich oder es war so ausgedrückt das ich es nicht verstanden
habe bsp:

>Posts: 5280

> Zitat:
> Original von MaikG:
> code:
> position&=Recv(fd&,MyMemory&,maxlaenge&-1000,MSG_PEEK%)
> IF position&>0 AND positionold&=position& THEN EXIT WHILE
> positionold&=position&
>Recv liefert die Anzahl gelesener bytes zurück und keine Position (wie kommst Du darauf, dass es anders sein könnte?). Wenn Du Deinen Lesevorgang abbrichst, sobald Du zweimal hintereinander die gleiche Anzahl bytes liest, brauchst Du Dich auch nicht zu wundern.
>
>Du wirst allerdings auch nicht viel Spaß an den gelesenen Daten haben, wenn Du bei jedem Aufruf von Recv die gleiche Puffer-Adresse übergibst.


Er zitiert meinen Code und schreibt das ein Abbrechen des "Lesevorgang" stattfindet.

Also musste ich davon ausgehen das ich von dem prinzip her die
Daten richtig Lese.


Ja, genau das ist Dein Problem... Du liest nicht richtig, was er Dir schreibt und nimmst dann irgendwas an, was er gemeint haben könnte. Da das oft beileibe nicht das ist, was sein Text bei genauem Lesen und Verbinden mit der jeweiligen Dokumentation aussagt, flippt er halt irgendwann aus. Manchmal ist seine Art nicht leicht zu verkraften, hab selbst ab und an mein Problem damit, aber: Er versteht was vom Thema und Du solltest trotz seiner polternden Art auf ihn hören. Im Gegensatz zu Dir weiß er nämlich, wovon er spricht.

Also nochmal ganz langsam:

Holger hat Dir bereits einige Male den Hinweis gegeben, daß recv() als Rückgabewert die Anzahl der gelesenen Bytes liefert, nicht die Position im zu holenden File. Dazu hat er Dir gesagt, warum MSG_PEEK als Option von recv() keine brilliante Idee ist und MadDog hat das nochmal etwas ausführlicher dargestellt. Noch dazu hat Holger Dir ganz definitiv und völlig unmißverständlich mitgeteilt, woran Du das Ende des Datenstroms erkennen kannst, nämlich daran, daß recv() ohne MSG_PEEK-Option den Wert 0 (keine Daten mehr) zurückgibt.

Also, wenn Du in diesem Licht Deinen Code betrachtest, müßtest sogar Du darauf kommen, daß Du da tatsächlich etwas falsch machst und auf die Art nie an die vollständige Datei herankommst.

Ok, inzwischen bist Du dazu übergegangen, einfach alle Daten anzufordern, aber jetzt kann es durchaus "blocken", wenn der Datenstrom "mittendrin" unterbrochen wird. Ein weiterer Grund für Holger, etwas pikiert zu schauen, denn das ist genau das, was Du ursprünglich nicht haben wolltest.

Dein Problem ist schlicht, daß Du, ähnlich wie gewisse andere Leute, einfach keine Lust hast, Dich etwas näher über die jeweilige Sache zu informieren oder etwas zu verstehen, was nicht Deinen Vorstellungen von "quick & easy" entspricht.

Denn:
Zitat:
Keine rede davon das peek nun gar kein regulärer Lesevorgang ist.

Was steht denn in der Dokumentation zu dieser Option, hm? Was meinst Du, warum Holger sagte, daß Du Mist baust, weil Du zwei Mal Deinen Puffer mit den gleichen Daten füllst, aber keine neuen Daten anforderst? Was bedeutet "to peek" eigentlich? Du weißt es offensichtlich nicht, was bedeutet, daß Du Dir das Lesen der Doku gespart hast. Wie willst Du aber verstehen, wenn Du gar nicht wirklich wissen willst?

Zitat:
Auch das mit Daten, nicht bezogen auf die Peek Option. Denn
wenn ich die daten auf $10000 "lese" und dann nochmal auf $50000
hab ich so und so die selben Daten. Weil Peek liesst immer das
selbe.


Wenn Du Dir die Doku genauer angesehen hättest wüßtest Du auch, warum das so ist! MSG_PEEK dient u.A. dazu nachzuschauen (to peek!), ob inzwischen Daten im Puffer stehen, die dann "abgeholt" (besser: verarbeitet) werden können (da gibts aber bestimmt eine passendere Funktion für). Man kann es auch dazu nutzen um zu überprüfen, ob die Daten im Puffer andere sind als die, die man zuletzt bekommen hat.

Was es aber nicht tut ist, neue Daten anzufordern.

Zitat:
>Wer hat denn vor kurzem rumgeheult, weil der Aufruf nicht
>zurückkommt, bevor nicht wenigstens ein byte gelesen wurde?

Ja, ausser komplizierte gibt es keine Lösung. Scheint mir.


Auf den ersten Blick nix "quick & easy" -> Scheiße. Willst Du uns das damit sagen? Wieso wunderst Du Dich eigentlich, daß man Dir extreme Faulheit vorwirft? Da muß man doch auf die Idee kommen, daß Du nur darauf wartest, daß Dir jemand die Komplettlösung im Geschenkpapier liefert...

Zitat:
>Jetzt benutzt Du also ein Flag, bei dem die Funktion sogar erst dann zurückkommt,
>wenn alle angeforderten bytes gelesen wurden, und dass stellt dann also eine "Lösung" dar?

Nee, nicht ganz.

Mit MSG_Peek wird bestimmt ob Daten im Puffer sind, sind 10 Sekunden
keinen Daten im Puffer wird recv+MSG_WAITALL niemals aufgerufen und
meine Funktion kommt zurück.


Mag sein, aber Du hättest es weit simpler und vor allem entsprechend Deinen ursprünglichen Vorstellungen haben können, wenn Du Dir die Mühe gemacht hättest, zu verstehen, was Holger Dir die ganze Zeit versucht hat zu erklären.

Die ganze Warterei mit Delay() und das Nachschauen, ob "schon" Daten im Puffer sind könntest Du Dir sparen, wenn Du einfach mal das anwendest, was er Dir gesagt hat. recv() liefert Dir Daten, sobald welche ankommen. Es kehrt auch zurück, wenn aus irgendeinem Grund voraussichtlich keine Daten (mehr) hereinkommen werden (sofern Du den socket richtig konfiguriert hast). Es sagt Dir, wie viele Daten das waren, die reinkamen. Beim nächsten Aufruf sagt es Dir, ob da noch mehr Daten "lauern" oder ob es das Ende der Datei war. Wenn etwas schiefgeht oder Du den Socket non-blocking "geschaltet" hast, bekommst Du -1 zurück.

Praktisch, oder? Einfach solange lesen, bis 0 oder -1 zurückkommt und alles ist easy. Sofern Du die Doku zum Thema sockets wenigstens im Groben liest und verstehst und dann auch anwendest.

Wenn Du etwas von dieser Doku nicht verstehst könntest Du im Grunde auch nachfragen, aber manchmal hat man das dumpfe Gefühl, daß Du Dein Nicht-Verstehen einfach ausblendest, lieber alle die, die das Thema verstanden haben und beherrschen, für blöd erklärst, selbst weiterwurschtelst und Dich bei einem scheinbaren Erolg in Deiner Ansicht über die Helfenden bestätigt fühlst ("mein Gott, sind die blöd... ICH hab die Lösung").

Daran solltest Du dringend arbeiten.

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 30.04.2008 um 09:08 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

30.04.2008, 09:42 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Ralf27:
Wieso ich das hier schreibe?
Ich wurde in einem Thread schon in einem Rutsch mit dir über einen Kamm geschoren und zwar in Sachen lernresistenz. Ich fand das auch nicht gerade sehr witzig. Ich hoffe wirklich inständig das ich nicht genau so "blockiert" bin. Sorry, ich wußte nicht wie ich es sonst schreiben sollte.


Wer immer das war, der Dir Lernresistenz vorwarf, er hat bisher wenig mit Dir zu tun gehabt. Nicht-auf-Anhieb-kapieren-und-das-offen-zugeben verbunden mit nicht-Englisch-können-und-das-auch-zugeben ist etwas völlig anderes als das, was Maik immer wieder an den Tag legt.

Er definiert seine Anforderungen, fragt nach Hilfe, verwirft die Hilfe, sobald es nicht so trivial ist, wie er sich das dachte, macht einen auf dicke Hose, definiert seine Anorderungen einfach neu und entsprechend dem, was er meint, entdeckt zu haben, und erklärt dann alle anderen für bescheuert wie Bürsten. Das ist Lernresistenz.

Alles andere ist schlicht "nicht auf Anhieb durchschauen und weitere Schubse brauchen". Nichts wirklich tragisches, aber für Leute mit schwachen Nerven nicht unbedingt ein Labsal. Mach Dir nichts draus, wenn die meckern, und programmiere weiter.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

30.04.2008, 10:51 Uhr

MaikG
Posts: 5172
Nutzer
>Ja, genau das ist Dein Problem... Du liest nicht richtig, was er
>Dir schreibt und nimmst dann irgendwas an, was er gemeint haben
>könnte. Da das oft beileibe nicht das ist, was sein Text bei
>genauem Lesen und Verbinden mit der jeweiligen Dokumentation aussagt,
>flippt er halt irgendwann aus.

Ich hab es vollständig gelesen.
Es scheint hier aber ein Problem zu sein wenn man etwas nicht versteht.
Und das ist das Problem.


>Holger hat Dir bereits einige Male den Hinweis gegeben, daß recv()
>als Rückgabewert die Anzahl der gelesenen Bytes liefert, nicht die
>Position im zu holenden File.

Hab ich auch gleich gesagt das die Variable aus dem 1. BSD Code
von ein paar Monaten stammt.
Ich könnte auch PI&= davor schreibeb...


>Dazu hat er Dir gesagt, warum MSG_PEEK als Option von recv() keine
>brilliante Idee ist

Ich habe aber nicht verstanden was er ausdrücken will.

> und MadDog hat das nochmal etwas ausführlicher
>dargestellt.

Ja, das war verständlich.


>Noch dazu hat Holger Dir ganz definitiv und völlig unmißverständlich
>mitgeteilt, woran Du das Ende des Datenstroms erkennen kannst,
>nämlich daran, daß recv() ohne MSG_PEEK-Option den Wert 0
>(keine Daten mehr) zurückgibt.

Ja, ohne Peek=Blocking.
Minimum 1 Minute Programmstillstand.


>Also, wenn Du in diesem Licht Deinen Code betrachtest, müßtest
>sogar Du darauf kommen, daß Du da tatsächlich etwas falsch machst
>und auf die Art nie an die vollständige Datei herankommst.

Das was am Code falsch sein muss hab ich relativ weit am Anfang
gesagt.


>Ok, inzwischen bist Du dazu übergegangen, einfach alle Daten
>anzufordern, aber jetzt kann es durchaus "blocken", wenn der
>Datenstrom "mittendrin" unterbrochen wird.

Kann passieren, aber kein Befehl ist "Nonblocking" ohne die
bsd config die ich nicht behersche ausser MSG_PEEK.
Deshalb habe ich diese option schon beim 1. mal gewählt.


>Ein weiterer Grund für Holger, etwas pikiert zu schauen, denn das
>ist genau das, was Du ursprünglich nicht haben wolltest.

Ich weiss nicht wonach bsd da geht, um zu wissen ob der Datenstrom
zu ende ist oder nicht(WaitAll).
Müsste man testen, vielleicht gibt es ja ein Timeout.

Erst fragen ob überhaupt Daten da sind bietet zumindest eine
gewisse Sicherheit.


>Dein Problem ist schlicht, daß Du, ähnlich wie gewisse andere Leute,
>einfach keine Lust hast, Dich etwas näher über die jeweilige Sache
>zu informieren oder etwas zu verstehen, was nicht Deinen
>Vorstellungen von "quick & easy" entspricht.

Ich versuche es, ich hab das komplette Doc von bsd gelesen
(ist aber Englisch).
Nun bin ich aber kein Einstein und muss nicht zwangsläufig alles
begreifen was ich lese.

Klar quick&easy ist mir lieber.
Denn wenn mir jemand einen kurzen codefetzen als beispiel Postet, ist
das wesentlich leichter zu verstehen als zwischen den Zeilen versteckte
hinweise.

Guck dir doch mal den C-Kurs an, da drin gibts Codes und Bilder ->
so kann man was begreifen. Nicht mit purer Therorie.




> Keine rede davon das peek nun gar kein regulärer Lesevorgang ist.

>Was steht denn in der Dokumentation zu dieser Option, hm?


Auch beim 3. mal lesen nichts was darauf hinweisst das das was
man "liesst" in der größe begrenzt ist.
Das die Daten auch da bleiben war mir schon immer klar, deswegen
wurde auch immer am Pufferstart eingelesen.



>Was es aber nicht tut ist, neue Daten anzufordern.

Ich denke mal um das zu verstehen müsste ich noch mehr
über TCP allgemein wissen.


>Auf den ersten Blick nix "quick & easy" -> Scheiße.

Ein Mini schnipsel in C würde mir reichen(nonblocking).
Ich sagt doch, das ganze Theorie zeug verstehe so nicht,
oder erst in Monaten.


>Mag sein, aber Du hättest es weit simpler und vor allem entsprechend
>Deinen ursprünglichen Vorstellungen haben können, wenn Du Dir die
>Mühe gemacht hättest, zu verstehen, was Holger Dir die ganze Zeit
>versucht hat zu erklären.

Ich möchte behaupten es steht hier nirgens wie mein Nonblocking
Socket öffnet.

Die ganze Warterei mit Delay() und das Nachschauen, ob "schon" Daten
im Puffer sind könntest Du Dir sparen, wenn Du einfach mal das
anwendest, was er Dir gesagt hat. recv() liefert Dir Daten, sobald
welche ankommen. Es kehrt auch zurück, wenn aus irgendeinem Grund
voraussichtlich keine Daten (mehr) hereinkommen werden (sofern Du
den socket richtig konfiguriert hast). Es sagt Dir, wie viele Daten
das waren, die reinkamen. Beim nächsten Aufruf sagt es Dir, ob da
noch mehr Daten "lauern" oder ob es das Ende der Datei war.

>Wenn etwas schiefgeht oder Du den Socket non-blocking "geschaltet"
>hast, bekommst Du -1 zurück.

Wenn gar keine Datei kommt kommt es ggf. niemals zurück. Also
ohne "non-blocking" zumindest.


>Wenn Du etwas von dieser Doku nicht verstehst könntest Du im Grunde
>auch nachfragen,

Na warum mache ich denn einen Threat auf? Ebend weil ich was
von der Doku nicht verstehe.

[ - Antworten - Zitieren - Direktlink - ]

30.04.2008, 10:59 Uhr

Der_Wanderer
Posts: 1229
Nutzer
@Ralf27
Ja, sorry, das war ich. Aber MaikG hat dich hier definitiv getoppt, wenn dir das eine Erleichterung sein sollte.

Meine Einstellung dazu ist, dass wenn mir hier jemand einen Tipp gibt, dann bin ich dankbar und setze mich damit auseinander. Erst wenn ich mir sicher bin, dass ich damit nicht zum Ziel komme, stelle ich weitere Fragen, aber mache keine aus der Luft gegriffenen Annahmen. Normalerweise sind die Tipps auch genau immer das Puzzle-Teil, was mir gefehlt hat, da Leute wie Holger etc. wirklich Ahnung von der Materie haben.
Aber hier im Forum gibt es Leute, die programmieren (bzw. denken) eher nach "Gut-Glück", und das funktioniert eben nicht wenn es um Mathematik oder Informatik geht.
Und das ärgert die Leute, die sich Mühe gegeben haben alles korrekt zu erklären. Das sieht dann arrogant aus, aber ist eigentlich nicht so gemeint.
Es nervt einfach, wenn man alles korrekt dargelegt hat und es wird trotzdem nicht angenommen, bzw. der Fragende ignoriert das und stochert in einer ganz anderen Richtung weiter.
So wie Leute, die z.B. einen mathematischen korrekten Beweis anzweifeln. Die haben einfach keine Ahnung von der Materie aber denken es besser zu wissen, bzw. nicht mal das, sondern sie verweigern einfach die Einsicht/Lernprozess.



--
Thilo Köhler, Author von:
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

30.04.2008, 12:41 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von MaikG:
>Ja, genau das ist Dein Problem... Du liest nicht richtig, was er
>Dir schreibt und nimmst dann irgendwas an, was er gemeint haben
>könnte. Da das oft beileibe nicht das ist, was sein Text bei
>genauem Lesen und Verbinden mit der jeweiligen Dokumentation aussagt,
>flippt er halt irgendwann aus.

Ich hab es vollständig gelesen.
Es scheint hier aber ein Problem zu sein wenn man etwas nicht versteht.
Und das ist das Problem.


Das ist eigentlich kein Problem. Zum Problem wird es erst, wenn man es nicht verstehen will. Er hat Dir geschrieben, daß Dein Code so, wie er da steht, nicht das tut, was Du erwartest. Du behauptest daraufhin, daß der Code das doch tut. Also was hast Du getan? Gelesen, aber nicht verstehen gewollt.

Also, nochmal zum Mitschreiben: Der Puffer eines Sockets hat eine bestimmte Größe (die Du auch konfigurieren kannst). Ist der Puffer voll oder das Ende des Datenstroms erreicht kehrt recv() mit der Anzahl der empfangenen Bytes zurück. Anzahl der Bytes und Puffergröße gleichen sich dann evtl., wenn der Puffer halt voll ist. Das dürfte doch verständlich sein, oder? Wenn dem so ist ist die Chance recht hoch, daß noch mehr Daten folgen, Du also ein weiteres Mal mittels recv() Daten übertragen mußt. Klingt auch logisch, oder? Kommt beim weiteren Mal Lesen eine 0 zurück bedeutet das, daß das Ende der Daten erreicht ist und damit bist Du fertig. Kommt eine positive Zahl zurück liegen weitere Daten vor. Das Spielchen treibst Du so lange, bis Du letztendlich eine 0 bekommst. Soweit klar?

Durch die Option MSG_PEEK erreichst Du, daß die aktuellen Daten aus dem socket-Puffer ggf. nochmal in einem Deiner eigenen Puffer landen, es wird aber kein weiterer Lesevorgang über den socket nach außen angestoßen, auch wenn das Ende des Datenstroms noch nicht erreicht ist. Das mußt DU machen, da Dein socket halt nicht non-blocked arbeitet. Zusätzlich bleiben die Daten im socket-Puffer erhalten.

Das bedeutet also, wenn Du zwei Mal hintereinander recv() mit MSG_PEEK benutzt bekommst Du zweimal identische Daten in Deinen Puffer geschrieben, weil Dein socket nicht non-blocked ist und daher nicht "mittendrin" neue Daten ankommen können, die Du dann mittels MSG_PEEK auslesen und ggf. sinnvoll mit vorher empfangenen Daten vergleichen kannst.

Und es ist logisch, daß das nie blockiert, weil es da nichts zu blockieren gibt, denn recv() mit der Option MSG_PEEK liest keine Daten aus dem Netzwerk, sondern nur aus dem socket-Puffer, und der ist beinahe immer sofort verfügbar.

Du siehst also (wenn Du es denn verstehen willst), daß MSG_PEEK zwar nicht blockt, aber Dir auch keine neuen Daten liefert sondern nur die, die Du beim 1. Mal eh schon hattest und daher für Deine Zwecke so ohne weiteres völlig unbrauchbar ist.

Und jetzt stell sinnvolle Fragen, z.B.: "Kann man ein blocked mode socket auch mit einem kürzerem timeout versehen und wenn ja, wie? Oder muß ich non-blocked benutzen und was muß ich dabei beachten? Was für einen Sinn hat MSG_PEEK noch?". Erwarte aber nicht, daß Du Antworten mit einer einzigen simplen Funktion bekommst, da wirst Du Pech haben.

Und noch ein kleiner Tipp: Schau doch mal, was select() tut...

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

30.04.2008, 13:55 Uhr

Mad_Dog
Posts: 1944
Nutzer
Ist vielleicht etwas off-topic, aber ich denke, an dieser Stelle muß ich mal was dazu schreiben...

Zitat:
Original von MaikG:
Ein Mini schnipsel in C würde mir reichen(nonblocking).
Ich sagt doch, das ganze Theorie zeug verstehe so nicht,
oder erst in Monaten.


Bei diesem Statement drängt sich mir der Verdacht auf, daß manche Leute einfach noch nicht verstanden haben, was man unter "Programmieren" überhaupt versteht. Das scheint das grundsätzliche Problem von manchen Leuten zu sein.

Der Code ist nur Mittel zum Zweck, dem Rechner mitzuteilen, was man sich gedacht hat. Ob man dann diese Gedanken dann in BASIC, C, Ada, Lisp oder sonst einer Programmiersprache verfasst. ist erstmal nebensächlich. Man kann auch einen Pseudocode schreiben und diesen dann auf einem Blatt Papier durchspielen - so ähnlich, wie ich das an dem Stack-Beispiel gemacht habe.

Die Idee muß man schon selbst haben. Und wenn man Funktionen von Dritten (z.B. Funktionen aus der Betriebssystem API) verwendet, muß man sich auch zwangsläufig damit befassen, was der Autor sich dabei gedacht hat.
Rumraten und Ausprobieren ist da nicht der richtige Ansatz.

"Copy & Paste Programmierung" + Rumraten + wilde Spekulationen führen eben nicht zum Ziel.
--
http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

30.04.2008, 14:32 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von MaikG:

Guck dir doch mal den C-Kurs an, da drin gibts Codes und Bilder ->
so kann man was begreifen. Nicht mit purer Therorie.


Ich nehme mal an, Du meinst meinen
Amiga C-Kurs für Einsteiger.

Ich habe in diesem Kurs ganz bewusst auf viel Theorie verzichtet und versucht, auf das Prinzip "Learning by Doing" zu setzen. Mir ist dabei voll und ganz bewusst, daß ohne diese fehlenden Theorie-Elemente keine fundierte Ausbildung zum Informatiker oder Programmierer möglich ist. Dies war auch nie die Zielsetzung dieses Kurses. Der genannte Kurs sollte - trotz seines mittlerweile beachtlichen Umfangs - eher als Schnupperkurs verstanden werden, bei dem auch der Laie mal ausprobieren kann, ob ihm die Thematik "Programmierung" überhaupt zusagt.

Dabei habe ich auch immer wieder Anfragen erhalten, ob ich nicht dieses oder jenes Thema bringen könnte (z.B. wurde nach Voxelspace-Grafik gefragt. Aber diese "fortgeschrittenen" Themen sind eben nichts für Anfänger, welche von Anfang an die Zielgruppe dieses Kurses waren.

"Fortgeschrittene Programmier-Themen" anzugehen, ohne sich mit ein wenig Theorie zu beschäftigen, wäre wie zum Mond fliegen zu wollen, ohne sich mit den Grundlagen der Physik (z.B. Kinetik, Gravitation usw.) befassen zu wollen.

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

[ - Antworten - Zitieren - Direktlink - ]

30.04.2008, 16:05 Uhr

MaikG
Posts: 5172
Nutzer
>Und das ärgert die Leute, die sich Mühe gegeben haben alles korrekt
>zu erklären. Das sieht dann arrogant aus, aber ist eigentlich nicht
>so gemeint.


Ich bin auch dankbar für jeden rat. Nur es hilft mir nichts
wenn die fortgeschrittenen/Profi Programmierer sich untereinander
verstehen, ich das aber nicht.


Der beste Lehrer, ist nicht der mit meisten Wissen, sondern
der der sein Wissen am besten weitergeben kann.

Ist jetzt nicht böse gemeint.
Ich rege mich auch oft über Leute auf die nicht verstehen was
ich erkläre. Für mich sind manche Sachen am Computer alltag,
aber es gibt z.B. Menschen die setzen sich da ebend nur einmal die
Woche vor.



>Das ist eigentlich kein Problem. Zum Problem wird es erst, wenn
>man es nicht verstehen will. Er hat Dir geschrieben, daß Dein Code
>so, wie er da steht, nicht das tut, was Du erwartest.
>Du behauptest daraufhin, daß der Code das doch tut.

Nee, ich sagte das der Code unter anderen umständen, in einem
anderen Programm schonmal so funktioniert hat wie er sollte.

Das der Code in dem fall nicht 100% Funktionierte war mir klar.


>Also, nochmal zum Mitschreiben: Der Puffer eines Sockets hat eine
>bestimmte Größe (die Du auch konfigurieren kannst).

Wo? Bei Genesis ist der Empfangs+Sendepuffer auf 8192, trotz
des verdoppelns blieb die Datei auf 7xxx bytes.





Bissher alles verständlich.

>Kommt beim weiteren Mal Lesen eine
>0 zurück bedeutet das, daß das Ende der Daten erreicht
>ist und damit bist Du fertig.

Problem ist die Zeit in der Recv(mit einer anderen als die Peek option)
zurückkehrt. Im schlimmsten fall ist das bis zum beenden des
TCP-Stacks(im falle von OS4 also nie).
Kann ja passieren das ein Server auf eine anfrage keine
Antwort gibt.



>Und jetzt stell sinnvolle Fragen, z.B.: "Kann man ein blocked mode
>socket auch mit einem kürzerem timeout versehen und wenn ja, wie?

Ja die nehm ich.

>Oder muß ich non-blocked benutzen und was muß ich dabei beachten?

Das wäre auch nicht schlecht.


>Die Idee muß man schon selbst haben. Und wenn man Funktionen von
>Dritten (z.B. Funktionen aus der Betriebssystem API) verwendet,
>muß man sich auch zwangsläufig damit befassen, was der Autor sich
>dabei gedacht hat.

Es geht ja nur um den Teil des Programms der eine Seite holt.
Der risige Rest drum rum ist ja meine eigene idee und creation.



>Rumraten und Ausprobieren ist da nicht der richtige Ansatz.

Wenn man die Docs durch hat und sonst keine möglichkeit,
bleibt nur noch das.

>"Copy & Paste Programmierung" + Rumraten + wilde Spekulationen
>führen eben nicht zum Ziel.

Copy&Paste werden auch die erfahrensten Programmierer verwenden.
Warum Subroutinen, die ich schonmal geschrieben habe nochmal Eintippen?
Das braucht nur Zeit und da schleichen sich auch mal fehler ein.


>Ich nehme mal an, Du meinst meinen
>Amiga C-Kurs für Einsteiger.

Ja.

>Ich habe in diesem Kurs ganz bewusst auf viel Theorie verzichtet
>und versucht, auf das Prinzip "Learning by Doing" zu setzen.
>Mir ist dabei voll und ganz bewusst, daß ohne diese fehlenden
>Theorie-Elemente keine fundierte Ausbildung zum Informatiker oder
>Programmierer möglich ist. Dies war auch nie die Zielsetzung dieses
>Kurses. Der genannte Kurs sollte - trotz seines mittlerweile
>beachtlichen Umfangs - eher als Schnupperkurs verstanden werden,
>bei dem auch der Laie mal ausprobieren kann, ob ihm die Thematik
>"Programmierung" überhaupt zusagt.

Soviel Theorie braucht man auch meistens nicht, diese Funktion hier
schreibe ich z.B. einmal. Danach wird diese vermutlich nie wieder
verändert. Das Programm gibt Host+Seite vor, die wird von der
Function in einen Puffer gelegt und alles ist bestens.

[ - Antworten - Zitieren - Direktlink - ]

30.04.2008, 16:32 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von MaikG:
Der beste Lehrer, ist nicht der mit meisten Wissen, sondern
der der sein Wissen am besten weitergeben kann.


Da gebe ich Dir vollkommen Recht. Vielleicht hattest Du aber auch in der Schule nur mieße Lehrer, die nicht im Stande waren, Dir einigermaßen selbständiges Lernen beizubringen... X(

Zurück zu Deinem Problem:

Mir scheint auch, daß Du die Sache mit dem "Puffer" noch nicht ganz verstanden hast. Du solltest Dir darüber klar werden, daß die Puffer von Betriebssystemroutinen häufig nicht nur einfach ein Speicherbereich sind, die gefüllt werden, sondern Queues oder Stacks. Und meist arbeiten die dann so, daß sie eben sicht beliebig viele Daten aufnehmen können, sondern nur bis zu einem eingestellten Wert. Erst wenn man diese Puffer dann wieder leert, werden neue Daten nachgeliefert. Dann solltest Du noch wissen, daß es verschiedene Arten von solchen Puffern gibt, jeweils mit unterschiedlichem Verhalten (Stichworte: FIFO, LIFO, Prioritätswarteschlangen).

Das klingt vielleicht alles etwas akademisch, ist aber nicht so schwierig, daß man eine Hochschulabschluß braucht, um das zu verstehen - einige dieser "Puffer" werden z.B. auch bei der Fließbandproduktion eingesetzt und dort arbeiten erfahrungsgemäß eher weniger gebildete Menschen...

Stell Dir einfach mal eine Schlange von Menschen vor, die am Postschalter anstehen. Nimm an, diese Leute seien alles Vollidioten, die nichts von sich aus tun, denen man alles sagen muss.
Stell Dir vor, Du seist der Beamte am Schalter. Wenn Du jetzt den ersten in der Reihe bedienst und ihm nicht sagst, er soll den Raum verlassen, entspricht das einem Peek. Damit würdest Du immer wieder den ersten bedienen und die Schlange würde nicht kleiner, solange bis der Laden voll ist und keine neuer Kunde sich mehr hinten anstellt, weil ihm die Schlange zu lang ist. Das entspricht dann der Situation, daß der Puffer voll ist. Damit sich wieder neue Kunden hinten anstellen, musst Du die Kunden, die Du bearbeitet hast, auch wieder rausschicken. Dies entspricht dann bei einem Stack einem Pop.

Ich hoffe, daß Du es anhand dieser Analogie verstanden hast? :dance3:

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

[ Dieser Beitrag wurde von Mad_Dog am 30.04.2008 um 16:34 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

30.04.2008, 17:18 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von MaikG:
Soviel Theorie braucht man auch meistens nicht, diese Funktion hier
schreibe ich z.B. einmal. Danach wird diese vermutlich nie wieder
verändert. Das Programm gibt Host+Seite vor, die wird von der
Function in einen Puffer gelegt und alles ist bestens.


Ich möchte ja nicht wieder mit dem bösen Wort Lernresistenz kommen, aber wenn Du nicht bereit bist, Dir gewisse Grundlagen anzueignen, wirst Du bei der nächstbesten Gelegenheit wieder voll auf die Schnautze fliegen und auch keine technischen Dokumentationen verstehen.

Hier man ein paar Links zu Texten, die Du durcharbeiten solltest:

http://de.wikipedia.org/wiki/Stapelspeicher
http://de.wikipedia.org/wiki/Warteschlange_%28Datenstruktur%29
http://de.wikipedia.org/wiki/Last_In_%E2%80%93_First_Out

Solange Du diese elementaren Grundbegriffe nicht kennst und verstanden hast, was damit gemeint ist, wirst Du immer wieder nur "Bahnhof" verstehen, wenn Dir jemand versucht, etwas aus der Informatik zu erklären.

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

[ - Antworten - Zitieren - Direktlink - ]

30.04.2008, 17:41 Uhr

MaikG
Posts: 5172
Nutzer
>Da gebe ich Dir vollkommen Recht. Vielleicht hattest Du aber auch
>in der Schule nur mieße Lehrer, die nicht im Stande waren, Dir
>einigermaßen selbständiges Lernen beizubringen... X(

:-P

Mehr als die Docs lesen und google bemühen geht halt nicht.
Beim letzteren findet man leider bzl. Amiga Programmierung
nicht soviel-




>Ich hoffe, daß Du es anhand dieser Analogie verstanden hast? :dance3:

Doch, doch. Wie ein Stack funktioniert weiss ich, hab es nur nicht
im zusammenhang mit dieser Option gebracht.


>Ich möchte ja nicht wieder mit dem bösen Wort Lernresistenz kommen,

Nenne es doch Lernschwäche, das klingt viel netter.

>aber wenn Du nicht bereit bist, Dir gewisse Grundlagen anzueignen,
>wirst Du bei der nächstbesten Gelegenheit wieder voll auf die
>Schnautze fliegen und auch keine technischen Dokumentationen
>verstehen.

Die meisten verstehe ich ja.


>Hier man ein paar Links zu Texten, die Du durcharbeiten solltest:

Okay.


[ - Antworten - Zitieren - Direktlink - ]

30.04.2008, 18:02 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von MaikG:

>Ich hoffe, daß Du es anhand dieser Analogie verstanden hast? :dance3:

Doch, doch. Wie ein Stack funktioniert weiss ich, hab es nur nicht
im zusammenhang mit dieser Option gebracht.


Wobei die Schlange am Postschalter nach dem FIFO-Prinzip funktioniert, wärend ein Stack nach dem LIFO-Prinzip arbeitet.

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

[ - Antworten - Zitieren - Direktlink - ]

30.04.2008, 19:13 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von MaikG:
Er zitiert meinen Code und schreibt das ein Abbrechen des "Lesevorgang" stattfindet.

Also musste ich davon ausgehen das ich von dem prinzip her die
Daten richtig Lese.
Keine rede davon das peek nun gar kein regulärer Lesevorgang ist.

Ist Dir eigentlich schon mal in den Sinn gekommen, dass man, wenn Du es schaffst, in fünf Zeilen Code ein halbes Dutzend Fehler einzubauen, einen Fehler übersehen könnte?

Nur weil Deine Leseroutine bei einer völlig unsinniges Bedingung abbricht, heißt das nicht, dass der Leseaufruf selber richtig liest. Auch wenn man es bei Dir eigentlich schon vermuten müsste, kommt man halt nicht auf die Idee, dass Du ein Flag, dass Du nicht kennst, und das NICHT_LESEN bedeutet, verwendest, um Dich dann zu wundern, dass es NICHT_LIEST.
Zitat:
Original von MaikG:
Hab ich auch gleich gesagt das die Variable aus dem 1. BSD Code
von ein paar Monaten stammt.
Ich könnte auch PI&= davor schreibeb...

Es geht nicht um den Namen, sondern darum, wie Du diesen Rückgabewert benutzt. Und das sagt vollkommen unabhängig vom Variablennamen aus, dass Du es entweder immer noch für einen Positionsangabe hältst, oder aber für etwas noch viel bescheuerteres.
Zitat:
Ich weiss nicht wonach bsd da geht, um zu wissen ob der Datenstrom
zu ende ist oder nicht(WaitAll).
Müsste man testen, vielleicht gibt es ja ein Timeout.

Zwei Sekunden logisches Denken: der Server teilt dem Client mit, wann die Datei zu Ende ist. Timeouts sind Fehler, die mit einem regulären Ende der Datei nichts zu tun haben.
Zitat:
Auch beim 3. mal lesen nichts was darauf hinweisst das das was
man "liesst" in der größe begrenzt ist.

Es steht in jeder Dokumentation, dass recv weniger Daten als angefordert zurückgeben kann, und wenn nicht da steht, wovon das abhängt, musst Du davon ausgehen, dass es nicht spezifiziert ist, unter welchen Umständen das passiert. Es kann in der Größe begrenzt sein, es kann aber auch sein, dass neue Puffer bei Bedarf angelegt werden, Du aber nur den ersten bekommst. Es kann aber auch sein, dass es von der vergangenen Zeit seit der letzen Server Kommunikation abhängt, kann bei einer Datei aber auch mal komplett alles lesen oder von der Mondphase abhängen.
Zitat:
Ein Mini schnipsel in C würde mir reichen(nonblocking).
Ich sagt doch, das ganze Theorie zeug verstehe so nicht,
oder erst in Monaten.

Google nach non-blocking socket read, erster Treffer:
http://www.kegel.com/dkftpbench/nonblocking.html
Zeit der Recherche: 4 Sekunden.
Wenn die der Artikel nicht gefällt, gibt's noch tausend andere zum Ausprobieren.
Zitat:
Ich möchte behaupten es steht hier nirgens wie mein Nonblocking
Socket öffnet.

Ich möchte behaupten, es stand bislang hier nirgends eine Frage, wie man einen Nonblocking Socket öffnet. Statt dessen wollte hier jemand gar nicht erst die Notwendigkeit dafür einsehen.
Zitat:
Mehr als die Docs lesen und google bemühen geht halt nicht.
Beim letzteren findet man leider bzl. Amiga Programmierung
nicht soviel-

Und was hat Socket-Programmierung über das bsd socket API mit Amiga Programmierung zu tun? Wie viele Webseiten brauchst Du zu dieser Thematik?

mfg


--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

30.04.2008, 20:00 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von MaikG:
>Und das ärgert die Leute, die sich Mühe gegeben haben alles korrekt
>zu erklären. Das sieht dann arrogant aus, aber ist eigentlich nicht
>so gemeint.


Ich bin auch dankbar für jeden rat. Nur es hilft mir nichts
wenn die fortgeschrittenen/Profi Programmierer sich untereinander
verstehen, ich das aber nicht.


Der beste Lehrer, ist nicht der mit meisten Wissen, sondern
der der sein Wissen am besten weitergeben kann.

Ist jetzt nicht böse gemeint.
Ich rege mich auch oft über Leute auf die nicht verstehen was
ich erkläre. Für mich sind manche Sachen am Computer alltag,
aber es gibt z.B. Menschen die setzen sich da ebend nur einmal die
Woche vor.


Du, darüber beschwert sich ja niemand. Ist Dir aber schon mal aufgefallen, daß fast alle Threads, die Du anleierst, immer wieder den gleichen Verlauf nehmen? Wenn nein, nimm alle Deine Threads und vergleiche. Achte vor allem auf Deine eigenen Reaktionen und was Du da genau sagst (Tip: "das kann ich scho seit ich 10 bin"). Der Ton macht die Musik (was man aber auch hin und wieder an uns durchreichen kann, keine Frage).

Zitat:
>Das ist eigentlich kein Problem. Zum Problem wird es erst, wenn
>man es nicht verstehen will. Er hat Dir geschrieben, daß Dein Code
>so, wie er da steht, nicht das tut, was Du erwartest.
>Du behauptest daraufhin, daß der Code das doch tut.

Nee, ich sagte das der Code unter anderen umständen, in einem
anderen Programm schonmal so funktioniert hat wie er sollte.


Genau das bringt manchen hier auf die Palme. Schau Dir Deine Anforderungen nochmal genau an und dann lies nochmal, was Holger zum Thema "Der Code funktioniert wie gewünscht - nicht!" schrieb. Im Groben hast Du schlicht ignoriert, was er Dir sagte. Dein erster Code funktionierte definitiv nicht wie gewünscht, und das zufällig erhaltene "richtige" Ergebnis war auch genau das: Zufälliges Aufeinandertreffen unwahrscheinlich günstiger Umstände und planloses Experimentieren. Mehr aber auch nicht.

Wenn Holger Dir zu einem Thema wie bsdsocket etwas sagt, dann ist da auf jeden Fall etwas dran. In (nach meiner Erfahrung) 99,999% aller Fälle ist sogar alles, was er schreibt, für den Fragenden extrem gehaltvoll. Nutz das doch und frag ihn einfach, was er genau meint und ob er dafür z.B. ein winzig kleines Codebeispiel hätte, wenn Dir ein Thema zu hoch erscheint!

Ich wette, wenn Du nicht gleich den Larry raushängen ließest und ihn bescheiden danach fragen würdest, daß er Dir dann gern mit ein paar einfach zu verstehenden Erläuterungen auf die Sprünge helfen würde. Ob er das in den nächsten Wochen tut steht auf einem anderen Blatt, ich schätze, Du hast seinen Blutdruck ein wenig zu sehr erhöht. Aber das legt sich auch wieder. Nur: schreib Dir die Sache mit der Bescheidenheit mal auf und klebs Dir an den Monitor...

Zitat:
>Also, nochmal zum Mitschreiben: Der Puffer eines Sockets hat eine
>bestimmte Größe (die Du auch konfigurieren kannst).

Wo? Bei Genesis ist der Empfangs+Sendepuffer auf 8192, trotz
des verdoppelns blieb die Datei auf 7xxx bytes.


Erstes Gebot des Feuerwerkers: Mische niemals etwas, von dem Du nicht wirklich weißt, ob es sich gefahrlos mischen läßt.

Die Puffer, die Du bei Genesis einstellen kannst, gehören vielleicht zu etwas völlig anderem als dem bsdsocket-Teil von Genesis. Dem SANA-Device-Interface evtl.? Schau doch mal ins Genesis-Guide...

Zitat:
>Kommt beim weiteren Mal Lesen eine
>0 zurück bedeutet das, daß das Ende der Daten erreicht
>ist und damit bist Du fertig.

Problem ist die Zeit in der Recv(mit einer anderen als die Peek option)
zurückkehrt. Im schlimmsten fall ist das bis zum beenden des
TCP-Stacks(im falle von OS4 also nie).
Kann ja passieren das ein Server auf eine anfrage keine
Antwort gibt.


Sicher, das ist allen Beteiligten klar. Aber wie willst Du asynchron über bsdsocket lesen lernen, wenn Du nicht einmal das synchrone Lesen richtig hinbekommst? Hast Du schon mal überlegt, daß asynchrones Lesen und Schreiben eventuell etwas komplexer ausfallen könnte, als Du vermuten würdest?

Zitat:
>Und jetzt stell sinnvolle Fragen, z.B.: "Kann man ein blocked mode
>socket auch mit einem kürzerem timeout versehen und wenn ja, wie?

Ja die nehm ich.


Gut. Dann frag doch mal direkt, aber höflich.

Zitat:
>"Copy & Paste Programmierung" + Rumraten + wilde Spekulationen
>führen eben nicht zum Ziel.

Copy&Paste werden auch die erfahrensten Programmierer verwenden.
Warum Subroutinen, die ich schonmal geschrieben habe nochmal Eintippen?
Das braucht nur Zeit und da schleichen sich auch mal fehler ein.


Dazu muß ich auch noch etwas loswerden: es ist ein gewaltiger Unterschied, ob man ohne Sinn und Verstand Codefragmente zusammenpappt oder sich die Fragmente im Bewußtsein, wie diese Fragmente genau funktionieren, heraussucht und nach konkreten Plänen zusammensetzt.

Letzteres tust Du eher selten.

Trotzdem: viel Erfolg!
--
---

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

[ - Antworten - Zitieren - Direktlink - ]

30.04.2008, 23:24 Uhr

MaikG
Posts: 5172
Nutzer
>Ist Dir eigentlich schon mal in den Sinn gekommen, dass man, wenn
>Du es schaffst, in fünf Zeilen Code ein halbes Dutzend Fehler
>einzubauen, einen Fehler übersehen könnte?

Ja, nur das führte ebend zu den Missverständnissen.


>Es geht nicht um den Namen, sondern darum, wie Du diesen
>Rückgabewert benutzt. Und das sagt vollkommen unabhängig vom
>Variablennamen aus, dass Du es entweder immer noch für einen
>Positionsangabe hältst, oder aber für etwas noch viel bescheuerteres.

In falle von Peek ist es die Anzahl der Bytes im Puffer.


>Es steht in jeder Dokumentation, dass recv weniger Daten als
>angefordert zurückgeben kann, und wenn nicht da steht, wovon das
>abhängt, musst Du davon ausgehen, dass es nicht spezifiziert ist,
>unter welchen Umständen das passiert. Es kann in der Größe begrenzt
>sein, es kann aber auch sein, dass neue Puffer bei Bedarf angelegt
>werden, Du aber nur den ersten bekommst. Es kann aber auch sein,
>dass es von der vergangenen Zeit seit der letzen Server
>Kommunikation abhängt, kann bei einer Datei aber auch mal komplett
>alles lesen oder von der Mondphase abhängen.

Das meine ich, wie soll man sowas verstehen wenn es nicht
genau dokumentiert ist.

>Google nach non-blocking socket read, erster Treffer:
>http://www.kegel.com/dkftpbench/nonblocking.html
>Zeit der Recherche: 4 Sekunden.

Gut, da hat Linux beim Socket ja gemeinsamkeiten.
Aber das ist Linux, also noch ein ende schwerer zu kapieren
als C, was ich ins Basic Portieren muss.

Deswegen ist in meinen suchen immer "Amiga" enthalten.
Ich hab noch nichtmal die vollständigen Includes zu bsd.
Nur die im Beispiel für Ralf auch dabei waren.


>Ich möchte behaupten, es stand bislang hier nirgends eine Frage,
>wie man einen Nonblocking Socket öffnet. Statt dessen wollte hier
>jemand gar nicht erst die Notwendigkeit dafür einsehen.

Okay.

>Und was hat Socket-Programmierung über das bsd socket API mit
>Amiga Programmierung zu tun? Wie viele Webseiten brauchst Du zu
>dieser Thematik?

Wenn da z.B. steht "is Broken on SUN XXX" überleg ich doch sowas
wie was ist damit überhaupt auf den Amiga.
Auch die Variablennamen bei Linux schon.


>Du, darüber beschwert sich ja niemand. Ist Dir aber schon mal
>aufgefallen, daß fast alle Threads, die Du anleierst, immer wieder
>den gleichen Verlauf nehmen?

Ich kann mich kaum noch an den letzten erinnern, da ging es
ums Drucken. War mangels OS3.5 Treibers nichts testbar und
blieb beim ursprünglichen Funktionsumfang mit den Softwarevorraussetzungen.

Davor weiss ich nicht mehr, an etwas was so lang her war kann ich mich
nicht mehr erinnern.
Aber ich speichere Threats in denen was steht wie man was bestimmtes
macht.


>Der Ton macht die Musik
>(was man aber auch hin und wieder an uns durchreichen kann,
>keine Frage).

Vielleicht kommt auch oft was falsch rüber, in einer gegend redet
man so, in einer anderen ganz anders.

Das mit den File I/O kam mir fast wie eine verarschung vor,
weil ohne scheiss jetzt sowas kann ich schon sehr lange.
Damit hab ich Jahrelang gearbeitet, mit Netzwerk habe ich grade
kürzlich angefangen.


>Wenn Holger Dir zu einem Thema wie bsdsocket etwas sagt, dann ist
>da auf jeden Fall etwas dran.

Glaub ich auch, nur ebend der erste kommentar zu dem code
war halt sehr irritierend.


>Schau doch mal ins Genesis-Guide...

Ähm? Genesis hat bei mir keine Dokumentation, wollte
ich mir ja immer mal durchlesen wofür die ganzen Einstellungen
gut sind...

Ist nur das da

/doc
telnet.doc 2522 ----rwed 02-Okt-96 00:17:36
Read Me socket.library 2710 ----rwed 12-Feb-97 05:11:28
inet-handler.doc 2406 ----rwed 12-Feb-97 05:11:28
GNU-GPL.txt 18110 ----rwed 12-Feb-97 05:11:28


>Sicher, das ist allen Beteiligten klar. Aber wie willst Du asynchron
>über bsdsocket lesen lernen, wenn Du nicht einmal das synchrone
>Lesen richtig hinbekommst? Hast Du schon mal überlegt, daß
>asynchrones Lesen und Schreiben eventuell etwas komplexer
>ausfallen könnte, als Du vermuten würdest?

Ja, deswegen zweifle ich ja dran das ich das schaffe und hab
daher den peek+waitall weg gewählt.


>Gut. Dann frag doch mal direkt, aber höflich.

Wie kann ich bitte den timeout verkürzen?



>Dazu muß ich auch noch etwas loswerden: es ist ein gewaltiger
>Unterschied, ob man ohne Sinn und Verstand Codefragmente
>zusammenpappt oder sich die Fragmente im Bewußtsein, wie diese
>Fragmente genau funktionieren, heraussucht und nach konkreten
>Plänen zusammensetzt.

Das ist klar, normalerweise funktionieren meine Unterprogramme
auch immer zu 100%. Diese hier wollte ich nun zum 2. mal Verwenden
und das schlug fehl.

Andere sind in sehr vielen Programmen fehlerfrei verwendet worden.
Eines davon läuft 24 Stunden/Tag und steuert sehr gefährliche
Sachen...

[ Dieser Beitrag wurde von MaikG am 30.04.2008 um 23:27 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

30.04.2008, 23:59 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von MaikG:

>Es geht nicht um den Namen, sondern darum, wie Du diesen
>Rückgabewert benutzt. Und das sagt vollkommen unabhängig vom
>Variablennamen aus, dass Du es entweder immer noch für einen
>Positionsangabe hältst, oder aber für etwas noch viel bescheuerteres.

In falle von Peek ist es die Anzahl der Bytes im Puffer.


Mit MSG_PEEK stellst Du recv auf den "Nur Hinschauen, aber nicht abholen-Modus".

Zitat:
MSG_PEEK - "Peek" at the data present on the socket; the
data are returned, but not consumed, so that
a subsequent receive operation will see the
same data.


Siehe auch: http://utilitybase.com/ref/?keyword=bsdsocket&funcgroup=GeekGadgets&action=Search


Aber recv liefert Dir immer die Anzahl der gelesenen Bytes, egal, ob Du mit oder ohne MSG_PEEK liest.

Zitat:
FUNCTION
s is a socket created with socket(). recv() and recvfrom(),
are used to receive messages from another socket. recv()
may be used only on a connected socket (see connect()),
while recvfrom() may be used to receive data on a socket
whether it is in a connected state or not.

If from is not a NULL pointer, the source address of the
message is filled in. fromlen is a value-result parameter,
initialized to the size of the buffer associated with from,
and modified on return to indicate the actual size of the
address stored there. The length of the message is
returned
. If a message is too long to fit in the upplied
buffer, excess bytes may be discarded depending on the type
of socket the message is received from (see socket()).

If no messages are available at the socket, the receive call
waits for a message to arrive, unless the socket is non-
blocking (see IoctlSocket()) in which case -1 is returned
with the external variable errno set to EWOULDBLOCK.

The select() call may be used to determine when more data
arrive.


Der Unterschied ist nur, daß Du mit MSG_PEEK die Daten NICHT vom Puffer nimmst und somit auch KEINE NEUEN DATEN nachrücken können.

Ich dachte, das hättest Du nach meinen Ausführungen verstanden?



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

[ - Antworten - Zitieren - Direktlink - ]

01.05.2008, 00:00 Uhr

woop
Posts: 67
Nutzer
Zitat:
Original von MaikG:

Andere sind in sehr vielen Programmen fehlerfrei verwendet worden.
Eines davon läuft 24 Stunden/Tag und steuert sehr gefährliche
Sachen...


Schafherden?

[ - Antworten - Zitieren - Direktlink - ]

01.05.2008, 00:03 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von woop:
Zitat:
Original von MaikG:

Andere sind in sehr vielen Programmen fehlerfrei verwendet worden.
Eines davon läuft 24 Stunden/Tag und steuert sehr gefährliche
Sachen...


Schafherden?


Die haben doch den Zug genommen... :shock2:
--
http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

01.05.2008, 00:16 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Mad_Dog:
Zitat:
Original von woop:
Zitat:
Original von MaikG:

Andere sind in sehr vielen Programmen fehlerfrei verwendet worden.
Eines davon läuft 24 Stunden/Tag und steuert sehr gefährliche
Sachen...


Schafherden?


Die haben doch den Zug genommen... :shock2:


Aber das ist sehr gefährlich... der teure Zug ist jetzt kaputt :nuke:
--
---

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

[ - Antworten - Zitieren - Direktlink - ]

01.05.2008, 00:28 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von MaikG:

Das mit den File I/O kam mir fast wie eine verarschung vor,
weil ohne scheiss jetzt sowas kann ich schon sehr lange.
Damit hab ich Jahrelang gearbeitet, mit Netzwerk habe ich grade
kürzlich angefangen.


Das habe ich nicht böse gemeint, sondern als ernsthafter Vorschlag.
Nachdem ich diesen aberwitzigen Codesausschnitt
basic code:
WHILE TIMER-t!<10 
	  delay 25
          position&=Recv(fd&,MyMemory&,maxlaenge&-1000,MSG_PEEK%)
          IF position&>0 AND positionold&=position& THEN EXIT WHILE
          positionold&=position&
        WEND


gesehen habe, habe ich mich ernsthaft gefragt, wie Du denn vorgehen würdest, wenn es darum ginge, eine Textdatei Zeilenweise einzulesen.

Alles, was Du in Deinem Programm machen musst, ist recv solange aufrufen, bis es irgendwann 0 liefert. Das ist alles. Basta, fertig. Aber solange Du recv mit MSG_PEEK aufrufst, wird es NIE UND NIMMER 0 liefern, weil Du den Puffer nie leerst. Das hat Dir Holger gebetsmühlenartig immer wieder vorgepredigt, aber Du wolltest es nicht hören...

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

Als kopfgesteuerte Schleife:
basic code:
WHILE Recv(fd&,MyMemory&,maxlaenge&-1000,NULL%)
        WEND


oder alternativ als fußgesteuerte Schleife:
basic code:
DO
        WHILE Recv(fd&,MyMemory&,maxlaenge&-1000,NULL%)


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

[ Dieser Beitrag wurde von Mad_Dog am 01.05.2008 um 00:41 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

01.05.2008, 00:37 Uhr

woop
Posts: 67
Nutzer
Zitat:
Original von Mad_Dog:

Nachdem ich diesen aberwitzigen Codesausschnitt
basic code:
WHILE TIMER-t!<10 
	  delay 25
          position&=Recv(fd&,MyMemory&,maxlaenge&-1000,MSG_PEEK%)
          IF position&>0 AND positionold&=position& THEN EXIT WHILE
          positionold&=position&
        WEND


gesehen habe, habe ich mich ernsthaft gefragt, wie Du denn vorgehen würdest, wenn es darum ginge, eine Textdatei Zeilenweise einzulesen.


Psst, nicht so laut! Immer daran denken, von diesem Codeschnipsel hängt unser aller Leben ab, weil er sehr gefährliche Sachen in Zaun hält.
Und schlafende Schäferhunde soll man ja nicht wecken!

[ - Antworten - Zitieren - Direktlink - ]

01.05.2008, 00:48 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von MaikG:

>Es steht in jeder Dokumentation, dass recv weniger Daten als
>angefordert zurückgeben kann, und wenn nicht da steht, wovon das
>abhängt, musst Du davon ausgehen, dass es nicht spezifiziert ist,
>unter welchen Umständen das passiert. Es kann in der Größe begrenzt
>sein, es kann aber auch sein, dass neue Puffer bei Bedarf angelegt
>werden, Du aber nur den ersten bekommst. Es kann aber auch sein,
>dass es von der vergangenen Zeit seit der letzen Server
>Kommunikation abhängt, kann bei einer Datei aber auch mal komplett
>alles lesen oder von der Mondphase abhängen.

Das meine ich, wie soll man sowas verstehen wenn es nicht
genau dokumentiert ist.


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.

Zitat:
>Google nach non-blocking socket read, erster Treffer:
>http://www.kegel.com/dkftpbench/nonblocking.html
>Zeit der Recherche: 4 Sekunden.

Gut, da hat Linux beim Socket ja gemeinsamkeiten.
Aber das ist Linux, also noch ein ende schwerer zu kapieren
als C, was ich ins Basic Portieren muss.


Das stimmt schon, viele Codes aus der Linux-Branche sind nicht leicht zu lesen, wenn man Linux/Unix nicht wirklich gut kennt. Andererseits: Der Mechanismus ist der Gleiche und daher haben die Quellcodes oftmals viele Gemeinsamkeiten. Vergleich das doch mal mit irgendwelchen Amiga-Sourcen, die bsdsocket verwenden. AmiTCP Dev ist da eine gute Wahl (und darauf baut Genesis auf!).

Zitat:
Wenn da z.B. steht "is Broken on SUN XXX" überleg ich doch sowas
wie was ist damit überhaupt auf den Amiga.


Steht da "is broken on Amiga"? Nein? Also. Mal davon ab solltest Du nicht erwarten, daß bei BSD/Linux-Quellcodes was über Amiga erwähnt wird. Schau dazu lieber in die Doku des Amiga-TCP/IP-Stacks, wie z.B. AmiTCP.

Zitat:
Das mit den File I/O kam mir fast wie eine verarschung vor,
weil ohne scheiss jetzt sowas kann ich schon sehr lange.
Damit hab ich Jahrelang gearbeitet, mit Netzwerk habe ich grade
kürzlich angefangen.


Wenn Dir die Sache mit dem Puffer so wenig sagt kann man getrost davon ausgehen, daß Du auch mit Dateien nur synchron und mit ungepufferten Funktionen gearbeitet hast. Das bedeutet aber noch lange nicht "Beherrschen".

Zitat:
>Wenn Holger Dir zu einem Thema wie bsdsocket etwas sagt, dann ist
>da auf jeden Fall etwas dran.

Glaub ich auch, nur ebend der erste kommentar zu dem code
war halt sehr irritierend.


Hm, das ist doch nicht das erste Mal... geh doch mal drauf ein und frag ihn, wie er das, was Dich irritierte genau gemeint hat.

Zitat:
>Schau doch mal ins Genesis-Guide...

Ähm? Genesis hat bei mir keine Dokumentation, wollte
ich mir ja immer mal durchlesen wofür die ganzen Einstellungen
gut sind...


Sry, mein Fehler... AmiTCP.

Zitat:
>Sicher, das ist allen Beteiligten klar. Aber wie willst Du asynchron
>über bsdsocket lesen lernen, wenn Du nicht einmal das synchrone
>Lesen richtig hinbekommst? Hast Du schon mal überlegt, daß
>asynchrones Lesen und Schreiben eventuell etwas komplexer
>ausfallen könnte, als Du vermuten würdest?

Ja, deswegen zweifle ich ja dran das ich das schaffe und hab
daher den peek+waitall weg gewählt.


Hmpf... Du definierst mittendrin Deine Anforderungen um. Man hat Dir gesagt, daß der Weg mit MSG_PEEK ins Leere läuft. Ich hab Dir gesagt "wirf mal einen Blick auf select()". Überlies nicht immer die Hälfte, auch wenns vielleicht mal anstrengend ist. So entgeht Dir immer und immer wieder das Entscheidende.

Zitat:
>Gut. Dann frag doch mal direkt, aber höflich.

Wie kann ich bitte den timeout verkürzen?


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.

So, die Antwort hast Du jetzt schonmal etwas deutlicher und zum wiederholten Male. Was mich an Dir aber mächtig stört ist Deine Faulheit. Ich hab Dir sogar schon gesagt, wonach Du mal in der Doku suchen könntest, nämlich "timeout". Du wirst Augen machen: Das Wort kommt in der Dokumentation zu select() vor!

Allerdings: das Lesen und Umsetzen solltest Du wirklich selbst machen (AmiTCP-Beispiele wälzen!) und nachfragen, wenn Du eine Passage nicht verstehst. Können wir uns darauf einigen?

Wenn Du das durchhältst kanns durchaus sein, daß Du z.B. Holger demnächst weit besser verstehst, Deine Fragen weit präziser stellst und nicht von einem Moment zum nächsten die Fragestellung hinter unserem Rücken veränderst.

Zitat:
>Dazu muß ich auch noch etwas loswerden: es ist ein gewaltiger
>Unterschied, ob man ohne Sinn und Verstand Codefragmente
>zusammenpappt oder sich die Fragmente im Bewußtsein, wie diese
>Fragmente genau funktionieren, heraussucht und nach konkreten
>Plänen zusammensetzt.

Das ist klar, normalerweise funktionieren meine Unterprogramme
auch immer zu 100%. Diese hier wollte ich nun zum 2. mal Verwenden
und das schlug fehl.

Andere sind in sehr vielen Programmen fehlerfrei verwendet worden.
Eines davon läuft 24 Stunden/Tag und steuert sehr gefährliche
Sachen...


Was das für gefährliche Sachen sind möchte ich eigentlich gar nicht wissen... Dein Unterprogramm paßte aber nicht zu dem, was Du vorhattest. Das zeigte allein schon der Variablenname position. Also etwas hergenommen, zusammengeklempnert und gebetet, das es vielleicht doch funktioniert. Und frohen Mutes an den Weidezaun gepackt...

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

01.05.2008, 00:50 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von woop:
Zitat:
Original von Mad_Dog:

Nachdem ich diesen aberwitzigen Codesausschnitt
basic code:
WHILE TIMER-t!<10 
	  delay 25
          position&=Recv(fd&,MyMemory&,maxlaenge&-1000,MSG_PEEK%)
          IF position&>0 AND positionold&=position& THEN EXIT WHILE
          positionold&=position&
        WEND


gesehen habe, habe ich mich ernsthaft gefragt, wie Du denn vorgehen würdest, wenn es darum ginge, eine Textdatei Zeilenweise einzulesen.


Psst, nicht so laut! Immer daran denken, von diesem Codeschnipsel hängt unser aller Leben ab, weil er sehr gefährliche Sachen in Zaun hält.
Und schlafende Schäferhunde soll man ja nicht wecken!


Ich zitiere an dieser Stelle mal Roland Barthes:

Zitat:
Ist die beste Subversion nicht die, Codes zu entstellen, statt sie zu zerstören?

Manchmal frage ich mich echt, ob MikeG uns hier nicht verscheißern möchte...

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

[ - Antworten - Zitieren - Direktlink - ]

01.05.2008, 00:56 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Mad_Dog:
Alles, was Du in Deinem Programm machen musst, ist recv solange aufrufen, bis es irgendwann 0 liefert. Das ist alles. Basta, fertig. Aber solange Du recv mit MSG_PEEK aufrufst, wird es NIE UND NIMMER 0 liefern, weil Du den Puffer nie leerst. Das hat Dir Holger gebetsmühlenartig immer wieder vorgepredigt, aber Du wolltest es nicht hören...


Vorsicht... selbst, wenn wir mal davon ausgehen, daß er das jetzt endlich kapiert hat: Du hast seine ursprüngliche Anforderung an die Geschichte vergessen. Sein Hauptproblem (neben dem Verständnis für gepuffertes I/O) ist, daß recv() ohne weitere Maßnahmen für längere Zeit blockieren kann, wenn keine Daten kommen (aus welchen Gründen auch immer). Mit dem blanken recv() käme er nicht weiter und das würde er Dir dann gleich wieder verbal um die Ohren hauen.

Laß ihn mal die AmiTCP-Dokumentation sowie die Beispiele wälzen, insbesondere Abteilung select()/Waitselect(), mit reichlich Glück erleben wir eine seiner Sternstunden.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

01.05.2008, 10:48 Uhr

MaikG
Posts: 5172
Nutzer
>Mit MSG_PEEK stellst Du recv auf den "Nur Hinschauen, aber nicht
>abholen-Modus".

Ja, ich habs wirklich kappiert.


>Der Unterschied ist nur, daß Du mit MSG_PEEK die Daten NICHT vom Puffer nimmst
>und somit auch KEINE NEUEN DATEN nachrücken können.

>Ich dachte, das hättest Du nach meinen Ausführungen verstanden?

Doch doch.
Ich verwende peek zum bestimmen ob daten gekommen sind, wenn ja
gehts sofort in einen regulären recv und holt die Daten auch tatsächlich ab.



>Das habe ich nicht böse gemeint, sondern als ernsthafter Vorschlag.
>Nachdem ich diesen aberwitzigen Codesausschnitt

Ich mein nur wenn man X nicht kann heissts nicht das man Y nicht
kann. Wie gesagt hab die Peek option nicht richtig verstanden.
Ich muss nochmal schaun warum das ganze im anderen Programm
funktioniert hat.



>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







>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.



>Wenn Dir die Sache mit dem Puffer so wenig sagt kann man getrost
>davon ausgehen, daß Du auch mit Dateien nur synchron und mit
>ungepufferten Funktionen gearbeitet hast. Das bedeutet aber noch
>lange nicht "Beherrschen".

Ausser meinen und den Dos Puffer gab es keinen weiteren.


>Hm, das ist doch nicht das erste Mal... geh doch mal drauf ein
>und frag ihn, wie er das, was Dich irritierte genau gemeint hat.

Okay.



>Hmpf...

Der Code steht oben.



>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?

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

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

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

[ - Antworten - Zitieren - Direktlink - ]


1 -2- 3 4 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Http Post Request [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.