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

24.04.2008, 15:22 Uhr

MaikG
Posts: 5172
Nutzer

Hat jemand eine Beispieldatei wie ein Browser einen POST Request aufbaut?
Also Komplett was zum ziel gesendet wird?
Wiki gibt nicht viel her und der einzige http Logger der bei
mir lief gibt nur ein entschlüsseltes Format aus aber nicht
den kompletten POST.

[ - Antworten - Zitieren - Direktlink - ]

26.04.2008, 14:27 Uhr

Mad_Dog
Posts: 1944
Nutzer

@MaikG:

Guckst Du hier: http://de.wikipedia.org/wiki/Http#HTTP_POST

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

[ - Antworten - Zitieren - Direktlink - ]

26.04.2008, 17:48 Uhr

MaikG
Posts: 5172
Nutzer

Also ich hab die Anweisungen jetzt per GET übertragen.

Aber bei einer Seite hab ich das Problem das statt 15kb
nur 7 kb kommen. Hab bei bsd socket an etlichen stellen
(risige)delays gesetzt ohne erfolg.

evtl. muss ich einen HTTP-X mit der Browser kennung, Referer etc.
aufbauen.
Informationen dazu sind aber noch viel schwieriger zu finden
als zu POST.

[ Dieser Beitrag wurde von MaikG am 26.04.2008 um 17:49 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

26.04.2008, 18:02 Uhr

Mad_Dog
Posts: 1944
Nutzer

@MaikG:

Was willst Du überhaupt machen? Welche Daten möchtest Du mit was wohin übertragen?

Bedenke bitte auch, dass man mit GET nicht beliebig viele Parameter übertragen kann.

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

[ - Antworten - Zitieren - Direktlink - ]

26.04.2008, 18:08 Uhr

Mad_Dog
Posts: 1944
Nutzer

Hier noch ein Link zum RFC 2616:

http://tools.ietf.org/html/rfc2616

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

[ Dieser Beitrag wurde von Mad_Dog am 26.04.2008 um 18:09 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

26.04.2008, 18:21 Uhr

MaikG
Posts: 5172
Nutzer

>Was willst Du überhaupt machen? Welche Daten möchtest Du mit was wohin übertragen?

Die spezielle Seite enthält wieviel Trafic ich schon versurft
habe(Router).

Normal kann die mit AWeb nicht angezeigt werden.
Da ist die Seite jedoch vollständig(Quelltext Speichern).
Parameter sind die gleichen wie ich verwende per Hand.

>Bedenke bitte auch, dass man mit GET nicht beliebig viele Parameter
>übertragen kann.

In dem falle ist es nur

?next_file=usage/usage_data.html

Wesentlich mehr Parameter gingen schon durch.

>Hier noch ein Link zum RFC 2616:

>http://tools.ietf.org/html/rfc2616

Den hab ich auch schon gelesen, aber es ist da nicht
so erklärt als das man es als Anfänger versteht(oder gar nicht).

Code hab ich folgenden:

code:

FUNCTION GetASite&(host$, url$, mywin&, rp&)
STATIC i%, fh&, b%, task&, x&, laenge&, MyMemory&, i&, char%, a%
STATIC start1&, end1&, proxstart&, TMPL$, maxlaenge&, positionold&, position&, t!
STATIC hostent&,addrSize&,addrType&, host$, aPtr&, fd&, a&, res&

GetASite&=0

maxlaenge&=190000

MyMemory&=AllocVec(maxlaenge&+1000, MEMF_CLEAR&)
IF MyMemory& THEN

      address%(0) = AF_INET%
      address%(1) = 80 REM Port 80 == http
     

      hostent& = GetHostByName&(SADD(Host$+CHR$(0)))


      IF hostent&=0& THEN Fehlerausgabe("DNS lookup Fail"):GOTO GPP
      addrSize& = PEEKL(hostent&+12)
      addrType& = PEEKL(hostent&+8)
      IF addrSize&<>4 OR addrType&<>AF_INET% THEN Fehlerausgabe("Unknown address type"):GOTO GPP
      aPtr&=PEEKL(PEEKL(hostent&+16))
      address%(2) = PEEKW(aPtr&)
      address%(3) = PEEKW(aPtr&+2)

    fd&=Socket&(PF_INET%, SOCK_STREAM%, 0)
    IF fd&<>-1 THEN
      a&=VARPTR(address%(0))
      res&=Connect(fd&, a&, 16)
      IF NOT res& THEN
        junk&=SendStr&(fd&,"GET "+URL$+" HTTP/1.0"+CHR$(10)+CHR$(10))
        t!=TIMER:positionold&=0
        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
        laenge&=position&
      ELSE
        Fehlerausgabe("Couldn't connect"):GOTO GPP
      END IF
      x&=CloseSocket&(fd&)
    ELSE
     Fehlerausgabe("Failed to create Socket")
    END IF

[ Dieser Beitrag wurde von MaikG am 26.04.2008 um 18:25 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

26.04.2008, 18:59 Uhr

Mad_Dog
Posts: 1944
Nutzer

Warum machst Du es Dir denn so schwer?

Nimm doch einfach Wget: http://aminet.net/search?query=wget

Das kannst Du bei Bedarf auch aus Deinem BASIC-Programm, Shell-Skript oder sonst was aufrufen.

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

[ Dieser Beitrag wurde von Mad_Dog am 26.04.2008 um 18:59 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

26.04.2008, 19:43 Uhr

MaikG
Posts: 5172
Nutzer

>Warum machst Du es Dir denn so schwer?

Manchmal ist es besser etwas zu verstehen als das Problem zu umgehen.
Ich finde es auch eine "unsaubere" art so zu programmieren das
man zig externe Programme braucht. Z.b. Wget, die exe hat schon
1,6 MB manch einer hat nicht allzuviel Ram.

>Nimm doch einfach Wget: http://aminet.net/search?query=wget

>Das kannst Du bei Bedarf auch aus Deinem BASIC-Programm, Shell-Skript oder sonst was aufrufen.

Probiert hab ichs. Wget ist sehr unsauber Programmiert, fragt
nach Assigns die nur einer mit einer gcc Installation hat.

Ja dann kommt als ausgabe irgendwas mit unsupported und dann
"giving up".

[ - Antworten - Zitieren - Direktlink - ]

26.04.2008, 22:02 Uhr

Mad_Dog
Posts: 1944
Nutzer

Zitat:
Original von MaikG:
Manchmal ist es besser etwas zu verstehen als das Problem zu umgehen.

Dann musst Du Dich eben doch mit dem HTTP Reference Manual beschäftigen. Ist natürlich mühsam sich da reinzuarbeiten und auch nichts für Anfänger. Aber wenn Du alles selbst ausprogrammieren möchtest, dann mußt Du Dich zwangsläufig damit beschäftigen. Anders geht es leider nicht.

Ganz allgemein rate ich Dir, Dich mit Deinen Programmierübungen nicht zu überfordern. Fang mit einfachen Sachen an. Erst wenn Du einigermaßen fit bist, kannst Du Dich dann an kompliziertere Sachen wagen. Sich selbst am Anfang schwierige Aufgaben zu stellen und dann frustriert aufgeben und sagen "es geht nicht" bzw. "ich bin zu blöd dafür" halte ich didaktisch nicht gerade sinnvoll.

Zitat:
Ich finde es auch eine "unsaubere" art so zu programmieren das
man zig externe Programme braucht. Z.b. Wget, die exe hat schon
1,6 MB manch einer hat nicht allzuviel Ram.

Was Du als "unsauber" bezeichnest, ist schlicht und einfach die hirarchische Struktur eines Betriebssystems. Und da dieser Wget-Port ein schlichter GNU/Linux Port ist, setzt es eben die entsprechende Umgebung voraus. Mit etwas Aufwand könnte man sicher auch einen Port machen, der auf eine "reine" AmigaOS Umgebung aufsetzt - wobei dies auch wieder fast ein Paradoxon ist, da ja eigentlich alle Amiga TCP/IP Stacks mehr oder weniger auf bsd basieren...

Vielleicht rührt Dein Wunschdenken, daß es für alles und jedes einfache, fertige "aut of the Box" Funktionen gibt auch von Deinen Basic-Erfahrungen her. Ich habe selbst damals auch mit Basic (AMOS) angefangen. Da war ich auch begeistert, daß man mit den "eingebauten Funktionen" schnell tolle Sachen hinbekommen konnte. Allerdings haben diese "eingebauten Basic-Funktionen" auch ihre Grenzen, wie Du ja schon sicher selbst erkannt hast. Und da muß man eben zwangsläufig selbst anfangen, kreativ zu werden.

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

[ - Antworten - Zitieren - Direktlink - ]

26.04.2008, 22:04 Uhr

thomas
Posts: 7717
Nutzer

Zitat:
?next_file=usage/usage_data.html

Hast du schon mal probiert, einfach die Datei usage/usage_data.html zu laden, ohne das Script aufzurufen ?

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

26.04.2008, 22:36 Uhr

MaikG
Posts: 5172
Nutzer

>Dann musst Du Dich eben doch mit dem HTTP Reference Manual
>beschäftigen. Ist natürlich mühsam sich da reinzuarbeiten und auch
>nichts für Anfänger.

Hab ich mir schon durchgelesen.
Gibts nicht sowas schönes mit Blöcken, Bildern und Diagrammen
was man auch Verstehen kann?

Also bei POST sendet man eine Datei, bei GET kann man Parameter
in die URL Packen. Aber wo kommt die HTTP_X hin?
Da gibt es ja referer, host, forwarded usw.
Wenn das auch nur per URL übergeben wird, brauche ich nur ein
Beispiel.
Ansonsten bleibt ja nur die TCP-Stack umgebung um dies auf
andere weise zu übergeben.
Wobei mir nicht einleuchtet warum eine halbe Seite kommt,
wärend bei einem Parameterfehler sonst immer eine eindeutige
Fehlermeldung erscheint.

>Ganz allgemein rate ich Dir, Dich mit Deinen Programmierübungen
>nicht zu überfordern. Fang mit einfachen Sachen an.

Ich Programmiere ja das was ich grade benötige, bissher hab
ich es letztendlich immer hinbekommen.

>Allerdings haben diese "eingebauten Basic-Funktionen" auch ihre
>Grenzen, wie Du ja schon sicher selbst erkannt hast. Und da muß
>man eben zwangsläufig selbst anfangen, kreativ zu werden.

Von Basic benutze ich eigentlich nur noch die String Funktionen,
evtl. noch Datei Funktionen zum Debuggen. Der Rest sind alles
Systemfunktionen.

>Hast du schon mal probiert, einfach die Datei usage/usage_data.html
>zu laden, ohne das Script aufzurufen ?

Ja, damit bekomme ich die vollständige Template.
Also das ist die Datei die der Router später mit den real Werten
ausstattet. Die bringt natürlich nichts.

[ Dieser Beitrag wurde von MaikG am 26.04.2008 um 22:37 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

26.04.2008, 23:52 Uhr

MaikG
Posts: 5172
Nutzer

Hab erfolgreich den HTTPX Header nachgebildet.

Der spass wird einfach dem GET Linienweise angehangen.

Leider kommt die Datei immernoch unvollständig rüber.
Da muss ein fehler im geposteten Source sein, den wiederum
hab ich von Ralfs Threat.

[ - Antworten - Zitieren - Direktlink - ]

28.04.2008, 09:57 Uhr

Holger
Posts: 8116
Nutzer

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.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

28.04.2008, 11:29 Uhr

MaikG
Posts: 5172
Nutzer

>Recv liefert die Anzahl gelesener bytes zurück und keine Position
>(wie kommst Du darauf, dass es anders sein könnte?).

Die Variable stammt noch aus einer Zeit als ich dachte es wäre so.

>Wenn Du Deinen Lesevorgang abbrichst, sobald Du zweimal
>hintereinander die gleiche Anzahl bytes liest, brauchst Du Dich
>auch nicht zu wundern.

Deswegen habe ich ein Delay 25 dazwischen.
Ich denke es ist nicht sehr warscheinlich das innerhalb einer
halben Sekunde nichteinmal ein Byte mehr kommt oder?

>Du wirst allerdings auch nicht viel Spaß an den gelesenen Daten
>haben, wenn Du bei jedem Aufruf von Recv die gleiche Puffer-Adresse
>übergibst.

Ich benutze ja die PEEK funktion:

1. Bytes gekommen 50 Bytes, im Puffer = 50 Position=50 von Puffer anfang bis 50
2. Bytes gekommen 90 Bytes, im Puffer = 90 Position=90 von Puffer anfang bis 90

Das mehrfache lesen ist eigentlich nur dafür da, das ende der einkommen
Daten herraus zu finden.
Dabei wird der Puffer beim 2. mal natürlich nochmal unnötig von 0-50
gefüllt.

Oder sehe ich da was komplett falsch?

[ Dieser Beitrag wurde von MaikG am 28.04.2008 um 11:30 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

28.04.2008, 11:39 Uhr

Der_Wanderer
Posts: 1229
Nutzer

> Ich denke es ist nicht sehr warscheinlich das innerhalb einer
> halben Sekunde nichteinmal ein Byte mehr kommt oder

Das ist ein echter MaikG!
--
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 - ]

28.04.2008, 12:07 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von MaikG:
Oder sehe ich da was komplett falsch?

Muss man darauf wirklich noch antworten?

Zitat:
>Recv liefert die Anzahl gelesener bytes zurück und keine Position
>(wie kommst Du darauf, dass es anders sein könnte?).
Die Variable stammt noch aus einer Zeit als ich dachte es wäre so.

Es ist vollkommen egal, was Du denkst. Solange der Code falsch ist, wird er nicht funktionieren. Selbst wenn Du inzwischen wirklich wissen solltest, wie es richtig sein müsste, was ich bezweifele. Du musst auch den Code korrigieren.

Zitat:
Deswegen habe ich ein Delay 25 dazwischen.
Ich denke es ist nicht sehr warscheinlich das innerhalb einer
halben Sekunde nichteinmal ein Byte mehr kommt oder?

Was zur Hölle hat das damit zu tun?!
Wenn Du beim ersten Mal fünf bytes liest und beim zweiten Mal wieder fünf, dann bricht Deine Code ab. Wenn Du beim ersten Mal fünfzig bytes liest und beim zweiten Mal wieder fünfzig, dann bricht Deine Code ab. Wenn Du beim ersten Mal fünfhundert bytes liest und beim zweiten Mal wieder fünfhundert, dann bricht Deine Code ab. Wenn Du beim ersten Mal fünftausend bytes liest und beim zweiten Mal wieder fünftausend, dann bricht Deine Code ab.

Du kannst an dem sinnlosen Delay rumschrauben, so viel Du willst, die Anzahl gelesener bytes mit der Anzahl gelesener bytes aus einem anderen Lesevorgang zu vergleichen, bleibt Schwachsinn.

Zitat:
>Du wirst allerdings auch nicht viel Spaß an den gelesenen Daten
>haben, wenn Du bei jedem Aufruf von Recv die gleiche Puffer-Adresse
>übergibst.
Ich benutze ja die PEEK funktion:

Ich befürchte, die bsdsocket-Funktionen interessieren sich nicht im Geringsten für Deine PEEK-Funktion. Wenn Du ihnen beim zweiten Mal dieselbe Speicheradresse übergibst, überschreiben sie die Daten in diesem Speicherbereich.

Zitat:
Das mehrfache lesen ist eigentlich nur dafür da, das ende der einkommen
Daten herraus zu finden.
Dabei wird der Puffer beim 2. mal natürlich nochmal unnötig von 0-50
gefüllt.

Aha.
Wenn also der Puffer beim 2.Mal von 0-50 gefüllt wird, dann werden also die ersten 50 bytes im Puffer nicht überschrieben? Oder benutzt Du ein spezielles PEEK, das Restladungen in den RAM-Chips aufspüren kann, um die bytes vom ersten Mal wiederherzustellen?

Wie Du das Ende der Datei herausfinden willst, wenn Du die Anzahl gelesener bytes als Position interpretierst, wissentlich sogar, wie Du jetzt andeutest, aber nirgendwo eine korrekte Abbruchbedingung für das Ende der Datei auswertest, gehört zu den Mythen der MaikG-Programmierung.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

28.04.2008, 13:52 Uhr

MaikG
Posts: 5172
Nutzer

>Wenn also der Puffer beim 2.Mal von 0-50 gefüllt wird, dann werden
>also die ersten 50 bytes im Puffer nicht überschrieben?

Nein, so wie ich das verstehe kopiert die bsd-peek Funktion(nicht
zu verwechseln mit der Basic Peek Funktion den bsd Internen
Puffer. Bereits gelesende Daten bleiben innerhalb dieses Puffers.
Zumindest wenn ich die Anleitung richtig interpretiert habe.
Damit habe ich auch schonmal (aus dem Internet) Seiten
geholt welche wesentlich länger als 15 kb waren.

>Wie Du das Ende der Datei herausfinden willst, wenn Du die Anzahl
>gelesener bytes als Position interpretierst, wissentlich sogar,
>wie Du jetzt andeutest, aber nirgendwo eine korrekte
>Abbruchbedingung für das Ende der Datei auswertest, gehört zu den
>Mythen der MaikG-Programmierung.

Problem ist, Internet ist eine instabiele sachen. Seiten können
offline sein, oder kurzzeitig mittendrin gestört.
Das hiesse das der Code nicht, oder eine lange Zeit nicht zurück
käme. Also z.B. wenn ich auf &h0D0A0D warten würde, was nun
zufällig nicht kommt.

Ich mach nochmal eine Debug Version fertig und gebe alle "Position"
werte und Puffer aus.

Okay, scheint so zu sein, wie ich es in erinnerung hatte:

POSITON: 17HTTP/1.0 200 OK

POSITON: 1085HTTP/1.0 200 OK

Content-type: text/html

Es könnte vielleicht sein der der bsd eigene puffer sehr klein ist
und dadurch das die daten übers lokale Netz sehr schnell kommen
dieser überläuft?

[ Dieser Beitrag wurde von MaikG am 28.04.2008 um 14:00 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

28.04.2008, 15:46 Uhr

Mad_Dog
Posts: 1944
Nutzer

@MaikG:

Mike, mach mal langsam...

Dein grundlegendes Problem scheint zu sein, daß Du immer den zweiten Schritt vor dem erstem machen möchtest. Wenn Dir das dann nicht gelingt, fängst Du mit wilden Spekulationen an. So wird das nichts.

Programmieren ist wie Mahematik. Wenn Du gerade mal die Gundrechenarten kennst kannst Du noch keine Differentialgleichungen lösen - schon garnicht durch Raten.

Versuch doch mal, folgende, einfache Aufgabe zu lösen und zeige uns dann das Ergebnis: Schreibe ein Programm, welches eine Textdatei von einem Datenträger einlist und am Bildschirm ausgibt.

Wenn Du diese Aufgabe erfolgreich gelöst hast, wirst Du hoffentlich auch folgende Sachen gelernt haben:

- Wie man eine Datei öffnet
- Wie man das Ende einer Datei und Fehler beim Auslesen erkennt
- Welche Klauseln für die Abbruchbedingung einer Schleife sinnvoll sind.

Falls Du das nicht hinbekommst, solltest Du nicht wieder mit wilden Spekulationen ala "Speicherung von Daten auf Magnetischen Datenträgern ist eine heikle Sache, wegen dem Erdmagnetfeld, Sonnenstürmen und der gleichen" anfangen.

Wenn Du erst einmal gelernt hast, wie man eine (Text-)Datei einliest und am Bildschirm ausgibt, wirst Du hoffentlich selbst erkennen, was an Deinem Code falsch ist und was Dir Holger versucht hat, zu erklären.

Als nächstes solltest Du mal Dein Verständnis von "Puffer" hinterfragen. Wenn Du ein Array nimmst und immer wieder ab dem 1. Element anfängst, darin etwas einzutragen, wird der Inhalt eben überschrieben.
--
http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

28.04.2008, 16:17 Uhr

MaikG
Posts: 5172
Nutzer

>Wenn Du erst einmal gelernt hast, wie man eine (Text-)Datei einliest
>und am Bildschirm ausgibt, wirst Du hoffentlich selbst erkennen,
>was an Deinem Code falsch ist und was Dir Holger versucht hat, zu
>erklären.

Ist heute schon der 1.Mai oder hast du sicherheitshalber schon
früher begonnen?

Eine blöde Datei einlesen und Ausgeben konnte ich schon als
ich 10 Jahre alt war oder so.

Also MSG_PEEK% liefert mir in dem Falle grundsätzlich nur 7kb,
MSG_WAITALL% ist die einzige Option mit der ich 15kb erhalte.

Schlecht daran ist das ich die Abbruchkontrolle verliere.
Sprich geht irgendwo beim übertragen etwas schief bleibt das
Programm stehen.

Das kennt sicherlich noch jeder von YAM, pop3 server mal nicht
Verfügbar/bereit und schon kann es passieren das YAM bis zum beenden
der Internetsitzung hängt.

[ - Antworten - Zitieren - Direktlink - ]

28.04.2008, 16:18 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von MaikG:
Nein, so wie ich das verstehe kopiert die bsd-peek Funktion(nicht
zu verwechseln mit der Basic Peek Funktion den bsd Internen
Puffer. Bereits gelesende Daten bleiben innerhalb dieses Puffers.

Aha.
Jetzt wird einiges klarer. Du weist also die Funktion an, Dir die immer gleichen Daten in Deinen Puffer zu schreiben, holst die Daten aber selber nie ab. Und erwartest aufgrund wilder Spekulationen über die zurückgegebene Anzahl von bytes, ob zwischendurch neue Daten angekommen sind. Obwohl Du gar keine neuen Leseanfragen verschickst, sondern Dir immer nur das Ergebnis der alten Anfrage in Deinen Puffer kopieren lässt. Bzw. abbrichst, weil die Anzahl bytes ja gleich geblieben ist.

Zitat:
Problem ist, Internet ist eine instabiele sachen. Seiten können
offline sein, oder kurzzeitig mittendrin gestört.
Das hiesse das der Code nicht, oder eine lange Zeit nicht zurück
käme. Also z.B. wenn ich auf &h0D0A0D warten würde, was nun
zufällig nicht kommt

Herr im Himmel, wer sagt, dass Du auf &h0D0A0D warten sollst? Wenn Du eine Leseanfrage geschickt hast, sagt Dir der Rückgabewert, ob die Datei zu Ende ist. Ein Rückgabewert von 0 besagt, dass die Datei zu Ende ist. Solange Du den Rückgabewert aber wider besseren Wissens als Position interpretierst, wird das nicht funktionieren.
Wenn Du nicht willst, dass der Aufruf bis um Eintreffen von Daten blockiert, musst den den Socket als non-Blocking markieren und den entsprechenden Fehler E_AGAIN (=E_WOULDBLOCK) richtig behandeln.

Zitat:
Es könnte vielleicht sein der der bsd eigene puffer sehr klein ist
und dadurch das die daten übers lokale Netz sehr schnell kommen
dieser überläuft?

Nein.
Wenn Du die Daten nicht abholst, sondern immer wieder dieselben Daten anfragst, wirst Du natürlich auch keine neuen bekommen. Selbst wenn der gesamte RAM Deines Rechners inzwischen zu einem socket-Puffer umfunktioniert worden wäre.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

28.04.2008, 16:23 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von MaikG:
Ist heute schon der 1.Mai oder hast du sicherheitshalber schon
früher begonnen?

Ja, so wird es sein. Mad_Dog ist schon mal demonstrieren gegangen.
Iss aber noch nicht so viel los, deshalb hat er sich noch mal an den Rechner gesetzt und einen guten Ratschlag gegeben.

[ - Antworten - Zitieren - Direktlink - ]

28.04.2008, 16:29 Uhr

MaikG
Posts: 5172
Nutzer

>Aha.
>Jetzt wird einiges klarer. Du weist also die Funktion an, Dir die
>immer gleichen Daten in Deinen Puffer zu schreiben, holst die Daten
>aber selber nie ab.

Recv speichert IMMER neue Daten und holt wohlt auch die Daten
ab.
Siehe Debugausgabe.

Noch ein Beispiel:

Server: Ha
Puffer: Ha
Server: Hallo
Puffer: Hallo

Peek liesst also neue daten, nur die alten werden halt
nicht gelöscht. Also die neuen Daten werden den Puffer hinzugefügt.

>Herr im Himmel, wer sagt, dass Du auf &h0D0A0D warten sollst? Wenn
>Du eine Leseanfrage geschickt hast, sagt Dir der Rückgabewert,
>ob die Datei zu Ende ist.
>Ein Rückgabewert von 0 besagt, dass die Datei zu Ende ist.

PEEK liefert grundsätzlich kein NULL mehr nachdem mindestens
ein Byte gelsen wurde.
Das geht nur mit anderen Optionen, dann kann die Funktion
jedoch wieder hängen bleiben.

>Wenn Du nicht willst, dass der Aufruf bis um Eintreffen von Daten
>blockiert, musst den den Socket als non-Blocking markieren und
>den entsprechenden Fehler E_AGAIN (=E_WOULDBLOCK) richtig behandeln.

Weil das mir schwer erscheint hatte ich ja peek verwendet.

>Wenn Du die Daten nicht abholst, sondern immer wieder dieselben
>Daten anfragst, wirst Du natürlich auch keine neuen bekommen.

Es kommen doch neue, guck doch das beispiel.

1.Abfrage:

POSITON: 17HTTP/1.0 200 OK

2.Abfrage:

POSITON: 1085HTTP/1.0 200 OK

Content-type: text/html
...

[ Dieser Beitrag wurde von MaikG am 28.04.2008 um 16:31 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

28.04.2008, 16:37 Uhr

MaikG
Posts: 5172
Nutzer

>Ja, so wird es sein. Mad_Dog ist schon mal demonstrieren gegangen.

Ist da nicht auch Männertag? Das bezog sich auf das saufen.

Aber wenns jemanden hilft:
Datei mit Open öffnen, länge mittels seek bestimmen,
läge mittels Read in den Puffer lesen
Datei schliessen.

Oder Datei locken, größe mit dem FIB bestimmen,
datei vom Lock öffnen usw.

[ - Antworten - Zitieren - Direktlink - ]

28.04.2008, 16:50 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von MaikG:
Recv speichert IMMER neue Daten und holt wohlt auch die Daten
ab.
Siehe Debugausgabe.

Junge, Du hast ein Problem. Das hast Du selbst geschrieben. Wenn Du damit glücklich bist, dass Deine Software in bestimmten Situationen nicht das tut, was sie soll, dann hör auf, uns damit zu belästigen.

Zitat:
Noch ein Beispiel:

Server: Ha
Puffer: Ha
Server: Hallo
Puffer: Hallo

Ja, dann beschränk Dich darauf, nur "Hallo" zu versenden und zu empfangen, statt Dateien von mehreren kByte. Das wäre Deinem Programmierstil wohl auch angemessen.

Zitat:
PEEK liefert grundsätzlich kein NULL mehr nachdem mindestens
ein Byte gelsen wurde.

recv liefert eine Zahl zurück. Und das ist =>0<=, wenn die Datei zu Ende ist, nicht NULL und auch keine Position oder irgendwelcher anderer Quatsch. Wenn Du die Daten auch abholst, also verdammt noch mal, vergiss MSG_PEEK Wenn Du die Daten nicht abholst, kann die Datei auch nicht zu Ende sein.

Lern endlich programmieren, also die richtige Funktion zu benutzen, statt irgendwelchen totalen Unsinn mit dafür ungeeigneten Funktionen und zusammengereimten falschen Annahmen anzustellen.

Zitat:
Weil das mir schwer erscheint hatte ich ja peek verwendet.

Siehe oben.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

28.04.2008, 16:51 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von MaikG:
Aber wenns jemanden hilft:
Datei mit Open öffnen, länge mittels seek bestimmen,
läge mittels Read in den Puffer lesen
Datei schliessen.

So, und jetzt lerne, wie man es macht, ohne vorher die Größe zu bestimmen.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

28.04.2008, 17:02 Uhr

Mad_Dog
Posts: 1944
Nutzer

Zitat:
Original von Holger:

Zitat:
Original von MaikG:
Ist heute schon der 1.Mai oder hast du sicherheitshalber schon
früher begonnen?

Ja, so wird es sein. Mad_Dog ist schon mal demonstrieren gegangen.
Iss aber noch nicht so viel los, deshalb hat er sich noch mal an den Rechner gesetzt und einen guten Ratschlag gegeben.

So ist es!

Aber ich hatte auch noch keine so richtige Idee, für oder gegen was ich demonstrieren soll. Jetzt ist mir ein Motto eingefallen: "Herr, laß Hirn regnen!
--
http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

28.04.2008, 17:07 Uhr

MaikG
Posts: 5172
Nutzer

>Junge, Du hast ein Problem. Das hast Du selbst geschrieben.

Ja.

>Wenn Du damit glücklich bist, dass Deine Software in bestimmten
>Situationen nicht das tut, was sie soll, dann hör auf, uns damit
>zu belästigen.

Einerseits zwinge ich keinen auf meine fragen zu Antworten,
andererseits gibts du mir keine Antwort die in der Praxis
funktioniert.

>recv liefert eine Zahl zurück. Und das ist =>0<=, wenn die Datei zu
>Ende ist, nicht NULL und auch keine Position oder irgendwelcher
>anderer Quatsch.

PEEK gibt sowas wie den Pufferfüllstand zurück.
Und wenn du dich auf den Kopf stellst bei Peek gibt es in der
ganzen Debugausgabe, wo mehrere Seiten geladen werden NIEMALS
den zustand 0.

>Wenn Du die Daten auch abholst, also verdammt noch mal, vergiss
>MSG_PEEK Wenn Du die Daten nicht abholst, kann die Datei auch nicht
>zu Ende sein.

Da MSG_PEEK in meinen Puffer schreibt, gehe ich davon aus das
ich die Daten im gewissen sinne abhole.
Wenn MSG_PEEK nur eine funktion ist um ausschließlich den
Pufferfüllstand zu bestimmen dann sollte die aber auch nicht
in meinen Puffer schreiben.

Dann wäre die alternative Peek wenn <> 0 dann MSG_OOB% mit
der zurückgegebenen zahl im Loop bis Peek=0.
Ist natürlich jetzt reine Theorie.

>Lern endlich programmieren, also die richtige Funktion zu benutzen,
>statt irgendwelchen totalen Unsinn mit dafür ungeeigneten Funktionen
>und zusammengereimten falschen Annahmen anzustellen.

peek ist eine OPTION von bsdsocked und keine Funktion.

>So, und jetzt lerne, wie man es macht, ohne vorher die Größe zu
>bestimmen.

Entweder du liesst bis Read Null zurückgibt oder du lässt
z.B. 100kb lesen, wenn die Datei nur 20kb groß ist gibt
es trotzdem kein Problem.

[ - Antworten - Zitieren - Direktlink - ]

28.04.2008, 17:13 Uhr

Mad_Dog
Posts: 1944
Nutzer

Zitat:
Original von Holger:

Zitat:
Original von MaikG:
Aber wenns jemanden hilft:
Datei mit Open öffnen, länge mittels seek bestimmen,
läge mittels Read in den Puffer lesen
Datei schliessen.
So, und jetzt lerne, wie man es macht, ohne vorher die Größe zu bestimmen.

Zur Übung würde ich auch noch die Varianten Zeichenweise und Zeilenweise lesen epfehlen. Das ist ein ernstgemeinter Ratschlag.

Etwas nicht können oder nicht zu wissen, ist keine Schande. Aber Fragen stellen, dann alles besser wissen und beleidigt weiter rumwursteln ist ziemlich kindisch.

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

[ - Antworten - Zitieren - Direktlink - ]

28.04.2008, 17:52 Uhr

MaikG
Posts: 5172
Nutzer

>Zur Übung würde ich auch noch die Varianten Zeichenweise und
>Zeilenweise lesen epfehlen. Das ist ein ernstgemeinter Ratschlag.

Sorry, aber es bringt jetzt nichts hier weiterhin was reinzuschreiben
was ich seit Jahrzehnten blind kann.

>Etwas nicht können oder nicht zu wissen, ist keine Schande.

Manchmal kommt mir das hier anders vor.

>Aber Fragen stellen, dann alles besser wissen und beleidigt weiter
>rumwursteln ist ziemlich kindisch.

Nicht besserwissen, ich probiere die vorgeschlagenen sachen
schon aus, soweit es mir möglich ist. Und besagtes funktioniert
nunmal nicht auf besagte weise.

Wenn Funktion X nunmal nicht Null liefert, was soll ich
hier schreiben? Soll ich lügen, damit sich irgendjemand besser
fühlt, ich aber keinen schritt weiter komme?

Peek liefert nur Null wenn noch keine Daten angekommen sind,
danach incrementiert sich das Ergebniss und wird nie wieder
Null, auch wenn seit ewigkeiten keine Daten mehr gekommen sind bzw.
die Datei vollständig ist.

Erst beim schliessen des Sockets gehts wieder bei Null los.

Kann sein das ich die peek Option für was missbrauche für was
diese nicht gedacht ist aber Ergebniss ist Ergebniss.

[ - Antworten - Zitieren - Direktlink - ]

29.04.2008, 16:51 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von MaikG:
PEEK gibt sowas wie den Pufferfüllstand zurück.
Und wenn du dich auf den Kopf stellst bei Peek gibt es in der
ganzen Debugausgabe, wo mehrere Seiten geladen werden NIEMALS
den zustand 0.

VERDAMMT NOCHMAL, LERN LESEN, LERN DENKEN UND VERSTEHEN.
Ich schreib es Dir noch ein letztes Mal, dann kannst Du Deinen Scheiß alleine rumprobieren, schaffen wirst Du es nicht, wenn Du es nicht kapierst:
Es funktioniert so nicht, es funktioniert nicht mit MSG_PEEK.
Hast Du's jetzt?!
Dann kannst Du versuchen, es richtig zu machen: ohne MSG_PEEK. Und dann und auch nur dann, wenn Du die Daten wirklich liest, wird Dir recv ein Dateiende melden. In dem es 0 zurückgibt.

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.

Zitat:
Dann wäre die alternative Peek wenn <> 0 dann MSG_OOB% mit
der zurückgegebenen zahl im Loop bis Peek=0.
Ist natürlich jetzt reine Theorie.

Hör auf, absurde Theorien aufzustellen. Lerne Programmieren!

Zitat:
peek ist eine OPTION von bsdsocked und keine Funktion.

Du bist echt ein Held. Du weißt wirklich, worauf es ankommt. Nur weiter so.

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

[ - Antworten - Zitieren - Direktlink - ]

-1- 2 3 4

[ - Beitrag schreiben - ]

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

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