[ - Answer - Quote - Direct link - ]

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.

---

[ - Answer - Quote - Direct link - ]

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 ?

---

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.

---

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

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.

---

Zitat:

---

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

---

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.

---

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.

---

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

--
---

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


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

[ - Answer - Quote - Direct link - ]

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

--
---

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

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

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

--
---

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

[ - Answer - Quote - Direct link - ]

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.

---

[ - Answer - Quote - Direct link - ]

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.

---

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

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

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?

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

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

[ - Answer - Quote - Direct link - ]

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.

---

[ - Answer - Quote - Direct link - ]

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

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

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.

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von MaikG:

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

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

---

[ - Answer - Quote - Direct link - ]

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.

---

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

---

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.

---

Zitat:

---

Auch beim 3. mal lesen nichts was darauf hinweisst das das was
man "liesst" in der größe begrenzt ist.

---

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.

---

Zitat:

---

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

---

Zitat:

---

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

---

[ - Answer - Quote - Direct link - ]

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.

---

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.

---

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.

---

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.

---

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.

---

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

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

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

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.

---

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.

---

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.

---

[ - Answer - Quote - Direct link - ]

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

---

[ - Answer - Quote - Direct link - ]

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...
--
http://www.norman-interactive.com

[ - Answer - Quote - Direct link - ]

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

---

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

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

[ - Answer - Quote - Direct link - ]

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.

---

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

---

basic code:

---

WHILE Recv(fd&,MyMemory&,maxlaenge&-1000,NULL%)
        WEND

---

basic code:

---

DO
        WHILE Recv(fd&,MyMemory&,maxlaenge&-1000,NULL%)

---

[ - Answer - Quote - Direct link - ]

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.

---

[ - Answer - Quote - Direct link - ]

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.

---

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.

---

Zitat:

---

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

---

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.

---

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.

---

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

---

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.

---

Zitat:

---

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

Wie kann ich bitte den timeout verkürzen?

---

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

--
---

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

[ - Answer - Quote - Direct link - ]

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!

---

Zitat:

---

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

---

[ - Answer - Quote - Direct link - ]

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

--
---

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

[ - Answer - Quote - Direct link - ]

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

---

[ - Answer - Quote - Direct link - ]