Http Post Request - amiga-news.de Forum

amiga-news.de Forum > Programmierung > Http Post Request

[ - Suche - Neue Beiträge - Registrieren - Login - ]

1 2 3 -4-

[ - Beitrag schreiben - ]

04.05.2008, 15:29 Uhr

MaikG
Posts: 5172
Nutzer

>Wo ist das Problem? Du kannst, wenn Du willst auch sofort
>aussteigen, wenn Dir recv() -1 liefert:

Ja, schon. Aber ist es nicht besser es nochmal zu probieren?
Vielleicht kommt ja beim 2. mal etwas.

>Der Overhead, den ich angesprochen habe, bezieht sich nur auf den
>Speicherbedarf. Sicher, Du mußt bei derser Methode zur Laufzeit
>ständig Speicher beschaffen und die Knoten in die Liste einhängen.
>Aber der "Rechenaufwand" (es wird ja nicht wirklich etwas dabei
>gerechnet, sondern es finden nur ein paar Zuweisungen statt)
>ist zu verschmerzen.

Unter Basic könnte das im ungünstigsten Falle schon um einiges
länger dauern als in C.

[ Dieser Beitrag wurde von MaikG am 04.05.2008 um 15:29 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

04.05.2008, 16:02 Uhr

Mad_Dog
Posts: 1944
Nutzer

Zitat:
Original von MaikG:
>Wo ist das Problem? Du kannst, wenn Du willst auch sofort
>aussteigen, wenn Dir recv() -1 liefert:

Ja, schon. Aber ist es nicht besser es nochmal zu probieren?
Vielleicht kommt ja beim 2. mal etwas.

Du kannst es natürlich auch mehrmals versuchen, dann musst Du eben einen Zähler einführen, der die Anzahl Deiner Versuche zählt, in etwa so:

code:

try = 0  Rem Zähler für Versuche
t!=TIMER:laenge&=0
         WHILE TIMER-t!<5 AND try<5
          puffer&=Recv(fd&,MyMemory&+laenge&,1, MSG_PEEK%)
          IF puffer&>0 THEN
	    IF laenge&+puffer&>maxlaenge& THEN EXIT WHILE
            position&=Recv(fd&,MyMemory&+laenge&,puffer&, 0)
            
            Rem Falls recv fehlschlägt, Zähler hochzählen
            IF position%=-1 THEN try=try+1
            ELSE try=0

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

Zitat:
>Der Overhead, den ich angesprochen habe, bezieht sich nur auf den
>Speicherbedarf. Sicher, Du mußt bei derser Methode zur Laufzeit
>ständig Speicher beschaffen und die Knoten in die Liste einhängen.
>Aber der "Rechenaufwand" (es wird ja nicht wirklich etwas dabei
>gerechnet, sondern es finden nur ein paar Zuweisungen statt)
>ist zu verschmerzen.

Unter Basic könnte das im ungünstigsten Falle schon um einiges
länger dauern als in C.

Ein weitaus größeres Problem sehe ich in der Frage, ob Maxon Basic überhaupt die geeigneten Sprachmittel bietet, um sowas ohne Verrenkungen zu formulieren.

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

[ - Antworten - Zitieren - Direktlink - ]

04.05.2008, 16:42 Uhr

MaikG
Posts: 5172
Nutzer

>Du kannst es natürlich auch mehrmals versuchen, dann musst Du eben
>einen Zähler einführen, der die Anzahl Deiner Versuche zählt,
>in etwa so:

Das mehrfach versuchen ist ja jetzt schon drin.
Das beim recv/0, -1 rauskommt kann eigentlich nicht sein,
denn ich hole ja nur Daten aus dem bsd puffer.

>Ein weitaus größeres Problem sehe ich in der Frage, ob Maxon Basic
>überhaupt die geeigneten Sprachmittel bietet, um sowas ohne
>Verrenkungen zu formulieren.

Ohne Verrenkungen nicht.
-> Sowas gibts da z.B. nicht.

[ - Antworten - Zitieren - Direktlink - ]

04.05.2008, 22:00 Uhr

NoImag
Posts: 1050
Nutzer

Zitat:
Original von MaikG:
Ohne Verrenkungen nicht.
-> Sowas gibts da z.B. nicht.

Ralf27 hat mir hier mal gesagt, dass das nichts anderes als ein PEEK + Offset ist (zumindest ungefähr). Für den Test auf das Ende/den Anfang kannst Du Dir eine Funktion schreiben (für alles andere auch, vieles bietet auch schon die exec.library). Die Verrenkungen brauchst Du dann nur einmal für alle Deine zukünftigen Programme zu schreiben.

Tschüß

[ - Antworten - Zitieren - Direktlink - ]

04.05.2008, 22:47 Uhr

MaikG
Posts: 5172
Nutzer

>Ralf27 hat mir hier mal gesagt, dass das nichts anderes als ein
>PEEK + Offset ist (zumindest ungefähr). Für den Test auf das
>Ende/den Anfang kannst Du Dir eine Funktion schreiben (für alles
>andere auch, vieles bietet auch schon die exec.library).

Ja,

ListHead->lh_head wäre dann:

PEEKL(ListHead&+lh_head%)

Schlimmer(bzw. unübersichtlicher) wirds dann wenn man die Peeks
kaskadieren muss.

Bei Basic hat man an sich ja keine Pointer.
Das sind Long Intergers mit einem Wert.

Hat man sich dran gewöhnt ist das einfach, wenn man in Basic
und C Programmiert kommt man allerdings schnell durcheinander.

[ - Antworten - Zitieren - Direktlink - ]

05.05.2008, 21:03 Uhr

Mad_Dog
Posts: 1944
Nutzer

Zitat:
Bei Basic hat man an sich ja keine Pointer.
Das sind Long Intergers mit einem Wert.

Pointer sind ja (auf low-Level Ebene) auch nichts anderes, als Variablen , in denen eben eine Adresse steht. Bei modernen Hochsprachen gibts da natürlich noch einen "high-Level Überbau" zwecks Typprüfung usw - jedenfalls bei stark typisierten Sprachen wie z.B. C, C++, Ada usw..

Pointer sollten aber nicht DER Grund sein, der die Implementierung von verketteten Listen in Basic schwierig macht.

Viel schwieriger macht es die Tatsasche, daß es (zumindest in Elementar-Basic) nichts gibt, was einem struct in C oder einem Record in Pascal/Modula 2/Ada entspricht. Damit wird es äußerst schwierig, erstmal einen Knoten zu formulieren.

Sicher kann man das auch auf Low-Level Ebene machen, indem man maschinennahe Befehle wie PEEk, POKE, DEEK, DOKE, VARPTR usw. verwendet. Aber dann könnte man es fast schon wieder in Assembler machen...

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

[ Dieser Beitrag wurde von Mad_Dog am 05.05.2008 um 21:04 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

06.05.2008, 05:30 Uhr

Garg0n
Posts: 1
Nutzer

Servus,

ich bin ein (leider) ehemaliger amiga user und wollte nur mal kurz was loswerden.

Das ist der interessanteste thread den ich im letzten jahr gelesen habe ;-)
Ich hab schlicht keine schimmer von der thematik.
Aber ich "musste" mir alles durchlesen. Ich finde es wirklich klasse das trotz "einiger" widrigen umstände ihr euch immer noch soviel mühe gebt, es im zu erklären.
Hätte ich nach der ersten seite im leben nicht erwartet. kompliment an euch und an die community. Und "MaikG" viel Erfolg :-)

Mfg

[ - Antworten - Zitieren - Direktlink - ]

06.05.2008, 10:00 Uhr

MaikG
Posts: 5172
Nutzer

>Viel schwieriger macht es die Tatsasche, daß es (zumindest in
>Elementar-Basic) nichts gibt, was einem struct in C oder einem
>Record in Pascal/Modula 2/Ada entspricht. Damit wird es äußerst
>schwierig, erstmal einen Knoten zu formulieren.

Eine structur muss man mittels AllocVec und Poke anlegen.
Ist natürlich komplizierter als in C.

Vielleicht ist es besser einfach ein Dynamisches LONG Array zu
nehmen und da die Speicheradressen reinzupacken.

Am Ende dann ein Gesamtbereich Allocieren, umkopieren und
Speicher wieder freigeben.

[ - Antworten - Zitieren - Direktlink - ]

06.05.2008, 14:26 Uhr

Mad_Dog
Posts: 1944
Nutzer

Zitat:
Original von MaikG:

Vielleicht ist es besser einfach ein Dynamisches LONG Array zu
nehmen und da die Speicheradressen reinzupacken.

Wenn es in Maxon Basic dynamische Arrays gibt, dann nimm einfach diese und vergiß die verketteten Listen erstmal. Die verketteten Listen sollen ja hier nur einen dynamischen Speicher liefern. Aber wenn Deine Sprache schon "eingebaute" Sprachmittel bietet, die den selben Zweck erfüllen, brauchst Du das Rad ja nicht neu erfinden.

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

[ - Antworten - Zitieren - Direktlink - ]

06.05.2008, 20:05 Uhr

NoImag
Posts: 1050
Nutzer

Zitat:
Original von Mad_Dog:

Zitat:
Original von MaikG:

Vielleicht ist es besser einfach ein Dynamisches LONG Array zu
nehmen und da die Speicheradressen reinzupacken.

Wenn es in Maxon Basic dynamische Arrays gibt, dann nimm einfach diese und vergiß die verketteten Listen erstmal. Die verketteten Listen sollen ja hier nur einen dynamischen Speicher liefern. Aber wenn Deine Sprache schon "eingebaute" Sprachmittel bietet, die den selben Zweck erfüllen, brauchst Du das Rad ja nicht neu erfinden.

Ohne das beweisen zu können, vermute ich aber stark, dass dynamische Arrays von MaxonBASIC erheblich langsamer sind, als doppelt verkettete Listen.

Tschüß

[ - Antworten - Zitieren - Direktlink - ]

07.05.2008, 12:24 Uhr

Holger
Posts: 8116
Nutzer

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

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

Maik, ich versuch es mal mit einer Analogie, das scheint ja bei Dir doch noch am Besten zu funktionieren. Was Du damit sagst, ist, dass es eine gute Idee wäre, wenn ein Auto gegen den Baum gefahren ist, noch fünf Mal Gas zu geben, in der Hoffnung, das Problem könnte damit gelöst werden.

Wenn Du wissen willst, ob ein weiteres Lesen sinnvoll ist, musst Du den Fehlercode auswerten. Du wirst allerdings feststellen, dass so ziemlich jeder Fehler nach sich zieht, dass Du aus diesem Socket nichts mehr lesen kannst.

Wenn Du dann einen Retry einbauen willst, müsstest Du das auf einer höheren Protokoll-Ebene lösen, im Falle von HTTP z.B. nach dem Auftreten eines Fehlers die Verbindung schließen, eine neue aufbauen und einen HTTP1.1-Request mit If-Range senden. Wenn der Server das unterstützt, und die Datei sich nicht verändert hat, bekommst Du dann den Rest. Andernfalls hast Du keine andere Wahl als die gesamte Datei noch mal zu lesen.

Zu der Linked-List Problematik: das ist für Deine Zwecke vermutlich Overkill. Mir ging es Gewiss nicht darum, dass Dein Programm für alle zukünftigen Zwecke gerüstet sein muss. Wenn Dein Programm sich mit einer Fehlermeldung ala "Puffer voll" beenden würde, wäre das vollkommen ok. Keinesfall aber solltest Du jemals (und genau das war in Deinem Code das Problem) eine Startadresse und Länge an recv übergeben, die über den Puffer hinausgeht. Das ist leicht sicherzustellen:

code:

recv(socket, Pufferstart + Anzahl gelesener Bytes, Puffergröße - Anzahl gelesener Bytes, ...)

Und natürlich musst Du eben unterscheiden zwischen der Bedingung Puffergröße = Anzahl gelesener Bytes (bevor Du eine Länge von 0 an recv übergibst) und dem Rückgabewert 0 von recv.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

08.05.2008, 11:11 Uhr

MaikG
Posts: 5172
Nutzer

>Ohne das beweisen zu können, vermute ich aber stark, dass
>dynamische Arrays von MaxonBASIC erheblich langsamer sind,
>als doppelt verkettete Listen.

Ich denke schon, aber MB wird den zugriff auf Listen auch etwas
verlangsamen.

>Maik, ich versuch es mal mit einer Analogie, das scheint ja bei Dir
>doch noch am Besten zu funktionieren. Was Du damit sagst, ist,
>dass es eine gute Idee wäre, wenn ein Auto gegen den Baum gefahren
>ist, noch fünf Mal Gas zu geben, in der Hoffnung, das Problem
>könnte damit gelöst werden.

Das kommt aufs Auto an und wie groß der Baum ist.

Bei Disketten ist es aber so das es beim 2. 3. 4. oder 5. mal
klappen kann.

>Wenn Du wissen willst, ob ein weiteres Lesen sinnvoll ist, musst
>Du den Fehlercode auswerten. Du wirst allerdings feststellen,
>dass so ziemlich jeder Fehler nach sich zieht, dass Du aus
>diesem Socket nichts mehr lesen kannst.

Okay, muss ich die Fehlerroutine wieder einbauen.

[ - Antworten - Zitieren - Direktlink - ]

12.05.2008, 20:14 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von MaikG:
Bei Disketten ist es aber so das es beim 2. 3. 4. oder 5. mal
klappen kann.

In dem Moment, wenn das DOS an die Anwendung einen Fehlercode zurückgibt, hat das darunterliegende device bereits mehrere Versuche durchgeführt. Wenn die Anwendung dann noch mal trotz Fehlercodes lesen würde, könnte es sich zum einen mehrere Stunden hinziehen, bis endlich abgebrochen wird (weil das device ja auch bei jedem Versuch wieder mehrere Versuche durchführt), zum anderen wären die Daten mit Sicherheit nutzlos, wenn der Leseversuch mit demselben FileHandler (und der ungültig gewordenen Position) stattfinden würde.

Gleiches gilt für sockets. Wenn Dir ein Fehlercode zurückgeliefert wird, haben bereits mehrere Versuche stattgefunden. Du kannst es dann gerne trotzdem noch mal versuchen, wenn Du viel Zeit hast. Aber dann besser mit einem neuen socket.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

13.05.2008, 00:51 Uhr

Wishmaster
Posts: 140
Nutzer

Wenn C zu kompliziert ist, kann Mann auch mal einen Blick hierhin werfen.

http://aminet.net/search?query=fpc
http://aminet.net/search?query=Obrn-A

Wirths Programmiersprachen sind sehr strukturiert, schnell erlernbar und äußerst leistungsfähig.

Wenn das Objektformat kompatibel ist, kann Mann vorhandene C-Source-Codes auch einfach dazu linken.

[ Dieser Beitrag wurde von Wishmaster am 13.05.2008 um 00:52 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

1 2 3 -4-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Programmierung > Http Post Request

[ - Suche - Neue Beiträge - Registrieren - Login - ]