[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:
Hm, zu früh gefreut. Ich bekomme das laden der kompletten Datei nicht geregelt. Zum einen finde ich nicht richtig den Anfang, zum anderen fehlt mir unterwegs immer wieder ein paar Bytes, sodas halt auch die Dateilänge zu kurz ist. Alles nicht so einfach...

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Hab eben denn Fehler gefunden. Der lag woanderst. So kanns kommen.

Ich werd erst mal noch ein paar weitere Tests machen.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

So, läuft recht gut. Interesse am Code? Aber vorsicht, ist MaxonBasic.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:
Die dos.library bietet das leider nicht. Du kannst dir natürlich eigene gepufferte I/O-Routinen schreibem, aber ob das sinnvoll ist, wenn Basic das bereits bietet ?

---

Indirekt scheint die dos.library das aber auch zu liefern, wenn man sich wirklich ansieht was der Read-Befehl liefert. Ist der Inhalt gleich, so ist das Ende erreicht. Somit kann man das als EOF ansehn.

Eine gepufferte IO-Routine ist somit eigentlich nicht nötig. Jedenfalls finde ich keinen Grund sowas zu machen, bzw. wüßte ich auch gar nicht wie.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:

---

Bzw, in Worten, was meinst du?
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

Ok, ich seh schon das dieses seltsam EOF bei TCP: die verwirrung bringt. Bzw. ist mir das jetzt zuerst aufgefallen? Na, das wäre ja mal wirklich was neues

Ok, hier mal der Code, der hier eigentlich läuft, aber real umgebaut werden sollte, damit man es wirklich nutzen kann:

code:

---

c$=SPACE$(256)

tcp&=xOpen&(SADD("TCP:home.pages.at/80"+CHR$(0)),MODE_NEWFILE&)
IF tcp& THEN 
 b$="GET http://home.pages.at/a1260/EigenePage/Dateien/Sudoku.lha HTTP/1.0"+CHR$(10)+CHR$(10)
 junk=xWrite(tcp&,SADD(b$),LEN(b$))
 junk=xRead(tcp&,SADD(c$),256)
 a=INSTR(c$," ")
 IF a THEN
  IF MID$(c$,a,5)=" 200 " THEN
   a=0
   WHILE a=0
    a=INSTR(c$,CHR$(13)+CHR$(10)+CHR$(13)+CHR$(10))
    IF a=0 THEN junk=xRead(tcp&,SADD(c$),256)
   WEND
   IF a THEN
    file&=xOpen&(SADD("ram:Sudoku.lha"+CHR$(0)),MODE_NEWFILE&)
    IF file& THEN
     a$=MID$(c$,a+4):b$="":size=0
     WHILE a$<>b$
      size=size+LEN(a$)
      b$=a$
      junk=xWrite(file&,SADD(a$),LEN(a$))
      a$=MID$(c$,1,xRead(tcp&,SADD(c$),256))
     WEND
     junk=xClose(file&)
     PRINT"Länge:"size
    ELSE
     PRINT"Konnte Ausgabefile nicht anlegen"
    END IF
   ELSE
    PRINT"Konnte Anfang der Daten nicht finden"
   END IF
  ELSE
   PRINT"Konnte Datei nicht finden"
  END IF
 ELSE
  PRINT"Fehlerhafter Request"
 END IF
 junk=xClose(tcp&)
ELSE
 PRINT"Konnte Server nicht finden"
END IF

---

Erklärung:
Includes am Anfang weg gelassen und auch einige & für die "ich mag keine & in Basic" entfernt.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:
Ich kann's nur noch mal wiederholen: Read() liefert die Anzahl gelesener bytes zurück und nicht irgendwelches Herumwühlen in dem Puffer, der eventuell gar nicht gefüllt wurde, bringt Dir die Erkenntnis, was gelesen wurde, sondern ausschließlich der Rückgabewert von Read(). Und die Datei ist zu Ende, wenn Read() 0 zurückliefert und zwar nur dann. Kein Rumtricksen mit String-Operatoren in einem Puffer sagt Dir das, sondern nur der Rückgabewert von Read().

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

---

code:

---

a$=MID$(c$,1,xRead(tcp&,SADD(c$),256))

---

code:

---

laenge=xRead(tcp&,SADD(c$),256)
a$=MID$(c$,1,laenge)

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

@Ralf27:

Hm, so ganz blicke ich das hier noch nicht, MBasic ist eigentlich nicht mein Metier, mit TCP: habe ich auch noch nicht experimentiert. Mir fällt aber auf, daß Du den kompletten Request-Return in c$ unterbringen willst... ob das klappt? Ich denke nicht, daß Strings in MBasic "unendlich" lang sein können, noch dazu sind die wohl eher selten mit einer NULL abgeschlossen, oder?

Desweiteren sieht mir der "Effekt" mit dem "xRead() gibt auch am Dateiende ständig den selben Wert aus" so danach aus, als würde xRead nicht wirklich am Ende der Datei 0 ausgeben, sondern wäre nur in der Lage, Teile einer Datei zu lesen und die Länge der tatsächlich gelesenen Bytes zurückgeben. Soweit ich mich erinnere, war das auch bei AmigaBASIC der Fall, da stand die Länge im Rückgabewert von OPEN (glaube ich. Ist schon lange her). Damit könnte man also das tatsächliche Dateiende gar nicht ermitteln sondern wäre darauf angewiesen, daß der Request-Return die korrekte Dateilänge beinhaltet (was auch meist der Fall ist).

Da könntest Du dann so vorgehen, daß Du "große Happen" liest (z.B. immer 1024 Bytes auf ein Mal) und den zum Schluß übrigbleibenden Rest aus der Länge ermittelst, die mit dem Request-Return übermittelt wurde (Länge % 1024). Dann wüßtest Du, daß das Dateiende erreicht ist und schreibst nur noch die restlichen Bytes.

Kann aber gut sein, daß ich mich da irre, weil ich MBasic halt nicht wirklich gut kenne...

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Hm, so ganz blicke ich das hier noch nicht, MBasic ist eigentlich nicht mein Metier, mit TCP: habe ich auch noch nicht experimentiert. Mir fällt aber auf, daß Du den kompletten Request-Return in c$ unterbringen willst... ob das klappt? Ich denke nicht, daß Strings in MBasic "unendlich" lang sein können, noch dazu sind die wohl eher selten mit einer NULL abgeschlossen, oder?

---

Zitat:

---

Desweiteren sieht mir der "Effekt" mit dem "xRead() gibt auch am Dateiende ständig den selben Wert aus" so danach aus, als würde xRead nicht wirklich am Ende der Datei 0 ausgeben, sondern wäre nur in der Lage, Teile einer Datei zu lesen und die Länge der tatsächlich gelesenen Bytes zurückgeben. Soweit ich mich erinnere, war das auch bei AmigaBASIC der Fall, da stand die Länge im Rückgabewert von OPEN (glaube ich. Ist schon lange her). Damit könnte man also das tatsächliche Dateiende gar nicht ermitteln sondern wäre darauf angewiesen, daß der Request-Return die korrekte Dateilänge beinhaltet (was auch meist der Fall ist).

Da könntest Du dann so vorgehen, daß Du "große Happen" liest (z.B. immer 1024 Bytes auf ein Mal) und den zum Schluß übrigbleibenden Rest aus der Länge ermittelst, die mit dem Request-Return übermittelt wurde (Länge % 1024). Dann wüßtest Du, daß das Dateiende erreicht ist und schreibst nur noch die restlichen Bytes.

Kann aber gut sein, daß ich mich da irre, weil ich MBasic halt nicht wirklich gut kenne...

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:
Die gelesene Zeichenkette im Puffer wird übrigens durch den Rückgabewert in der Länge beschnitten.

---

Zitat:

---

Wennn ich z.b. als xRead mach, dann liefert er wirklich nie 0, auch wenn das Ende erreicht ist, sondern zeigt mir immer wieder das Ende vom Buffer.

---

Zitat:

---

Ich hab das da oben schon mit einigen Dateien getestet und es läuft ohne Probleme.

---

Zitat:

---

code:

---

a$=MID$(c$,1,xRead(tcp&,SADD(c$),256))

---

kann man auch so schreiben, damit es verständlich ist:

code:

---

laenge=xRead(tcp&,SADD(c$),256)
a$=MID$(c$,1,laenge)

---

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:
Ich lese das ganze in Happen, was ich auf 256Bytes pro Happen beschränkt habe. Wenn der Header nicht ganz rein passt.. was solls, beim nächsten mal ist vielleicht das Ende drin oder beim nächsten mal lesen... ich lese so lange, bis ich das Ende vom Header habe ...

---

Das "Ende vom Header" besteht offenbar aus den vier bytes "rnrn", nach denen Du suchst. Was machst Du, wenn ein bis drei davon im ersten "Happen" und der Rest im zweiten "Happen" gelesen werden?

Zitat:

---

Also, das Programm da oben läuft so wie es ist ohne Probleme. Jedenfalls finde ich jetzt keine Probleme mehr.

---

Zitat:

---

Da ich da oben quasi fast nur dos.library-Befehle benutze, sollte man das ganze auch recht leicht in C übersetzen können. Die anderen Befehle wie MID$ oder INSTR sind wohl auch in einer C-Library vorhanden, nur dort mit einem anderen Namen.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von Ralf27:
Die gelesene Zeichenkette im Puffer wird übrigens durch den Rückgabewert in der Länge beschnitten.

---

Ich sehe drei Aufrufe, von denen zwei den Rückgabewert von Read() komplett ignorieren. Vor allem beim Lesen des Headers, und Du hast selbst geschrieben, das das nicht richtig funktioniert. Brauchst Dich aber auch nicht darüber zu wundern.

---

Zitat:

---

Zitat:

---

Wennn ich z.b. als xRead mach, dann liefert er wirklich nie 0, auch wenn das Ende erreicht ist, sondern zeigt mir immer wieder das Ende vom Buffer.

---

Das ist Blödsinn, dann würde copy TCP:... datei nicht funktionieren.

Zitat:

---

Ich hab das da oben schon mit einigen Dateien getestet und es läuft ohne Probleme.

---

Du hattest laut eigener Aussage Probleme. Was Du jetzt machst, ist Herumraten und Probieren, aber kein Programmieren.

---

Zitat:

---

Zitat:

---

code:

---

a$=MID$(c$,1,xRead(tcp&,SADD(c$),256))

---

kann man auch so schreiben, damit es verständlich ist:

code:

---

laenge=xRead(tcp&,SADD(c$),256)
a$=MID$(c$,1,laenge)

---

---

Es geht aber darum, dass Du den Inhalt von a$ mit irgendetwas vergleichst, und das ist einfach nur Banane. Read() liefert beim Dateiende 0 zurück, und bei einem Fehler -1. Das muss man abfragen. Und wenn dann nicht das richtige passiert, muss man den Fehler suchen, statt irgendwelchen Unsinn hinzuschreiben und zu behaupten, dass wäre jetzt richtig, macht halt "nur" ein paar Probleme...

---

Hm, versuch es doch bitte mal nicht mit Dateien auf der Festplatte, sondern über TCP: , denn da scheint es wohl etwas anderst zu sein. Dieses 0 bekommst du nicht beim ende, sondern es wird immer das gleiche ende übertragen. Das hab ich einfach damit errausgefunden, das ich eine dumme schleife ganz am anfang geschrieben habe, die alles was sie liest auf dem Bildschirm ausgibt. Und da, wo eigentlich der Schluss sein sollte, wurd einfach immer wieder der letzte Block Daten ausgegben und zwar endlos(!).

Ich will hier jetzt nichts steif und fest behaupten. Ich kann euch nur bitte es einfach auch mal zu versuchen. Schaut euch mal an was da passiert.

Ich hab schon einige Dateien (auch ausführbare) geladen und diese dann ausgeführt. Es lief problemlos.

Nochmal:
Ich wunder mich ja auch, weil es ja auch anderst in den AutoDocs steht, bzw. anderst ist als ich den Befehl kenne. Das scheint wohl wirklich mit TCP: zusammen zu hängen. Da scheint Read() einfach immer denn schluss nochmal zu lesen und das so oft wie ich will. Und ich vergleiche auch keine Äpfel und Birnen sondern das, was ich mit Read() lese. Wenn es gleich ist, dann ist das das Ende.


Und nochmal:
Das Problem am Anfang war folgender:
Das ende vom Header wird durch eine Leerzeile eingeläutet, was aber durch die ASCII-Code 13,10,13,10 zu erkennen ist und nicht durch 10,10, was ich am Anfang dachte. Das hab ich übrigens nicht durch testen, sondern durch einfach lesen in einem HEXEditor gesehen.

Das zweite Problem war einfach der, das ich den Buffer falsch behandelt habe, sodas ich nicht richtig lesen konnte. Erklärung:
Die Speicheranforderung von 256 Bytes mach ich noch am Anfang über einen leerstring. Wenn ich aber in diese variable einen kürzeren String übergebe, dann wird er kürzer und das lesen wird fehlerhaft. Das war alles.



Mir ist klar das ich hier den Read()-Befehl bzw. das eigentlich das EndOfFile hier seltsam löse, aber aus denn erkenntnissen die ich mit TCP: gesammelt habe.


Wenn ihr es mir nicht glaubt, dann testet es bitte doch einfach.
Oder ist der Code da oben so einfach, das es einfach nicht sein kann das er läuft?
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:
Das "Ende vom Header" besteht offenbar aus den vier bytes "rnrn", nach denen Du suchst. Was machst Du, wenn ein bis drei davon im ersten "Happen" und der Rest im zweiten "Happen" gelesen werden?

---

Zitat:

---

Also, das Programm da oben läuft so wie es ist ohne Probleme. Jedenfalls finde ich jetzt keine Probleme mehr.

---

Glückssache.
[/quote]
Nicht so pesimistisch.

Zitat:

---

Nein, diese Art von Funktionen gibt es dort nicht, weil diese String-Funktionen einer Basic-eigenen Speicherverwaltung unterliegen.

---

code:

---

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

---

Zitat:

---

Deine Abbruchbedingung würde eh nur funktionieren, wenn die letzten beiden Read()-Vorgänge die gleiche Länge zurückgeben, da aber nur sehr selten die Dateilänge ein Vielfaches von 256 ist, kann das gar nicht funktionieren. (Falls die Stringvergleiche überhaupt das machen, was Du willst. Ansonsten passiert halt etwas anderes, was zufällig ab und an das richtige machen könnte.)

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:
Das ist Blödsinn, dann würde copy TCP:... datei nicht funktionieren.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:
Nun, im Code vom Thomas sind diese Befehle drin. Die liegen in den folgenden Includes:

code:

---

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

---

---

Zitat:

---

Dies ist eine Annahme von Dir. In der hier getesteten Version unterscheiden sich die Längen von jedem Block. Gerade so, wieviel gerade zu diesem Zeitpunkt geladen werden konnte.

---

Zitat:

---

Theoretisch(!)(Achtung, eine Annahme!) könnten auch 0 Bytes drin liegen, dann wird auch ein string von 0 Bytes gelesen, bis wieder was rein kommt.

---

Zitat:

---

Aber ist es nicht seltsam, das man am Schluss (hier bei TCP: (!) ) plötzlich das gleiche nochmal laden kann, das auch genau so lang ist wie am Anfang?

---

Zitat:

---

Aber bitte, testet es doch einfach mal, was Read() bei TCP: liefert...

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

C code:

---

#include <proto/exec.h>
#include <proto/dos.h>

#define SIZE 200
int main (int argc,char **argv)
{
  char buf[SIZE];
  BPTR f=Open("tcp:www.amiga-news.de/80", MODE_NEWFILE);
  if(f)
  {
    int x;
    PutStr("Opened tcp:www.amiga-news.de/80n");
    FPuts(f, "GET / HTTP/1.0nn");
    PutStr("Request sentn");
    do
    {
      ULONG arg[2];
      arg[1]=(ULONG)buf;
      x=Read(f, buf, SIZE);
      if(x>=0)
      {
        arg[0]=x;
        if(x<=50) buf[x]=0;
        else { buf[47]=buf[48]=buf[49]='.'; buf[50]=0; }
        VPrintf("33[32mRead %ld bytes:33[39m %sn", arg);
      }
    } while(x>0);
    if(x<0) PrintFault(IoErr(), "Reading www.amiga-news.de:80n");
    Close(f);
  } else PrintFault(IoErr(), "Failed to open tcp:www.amiga-news.de/80n");
  return 0;
}

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:
@Holger:
Ich muß gestehn das ich gerade nix versteh. Bzw. kann ich mir gerade nicht vorstellen was das Programm da oben genau macht. Bzw. was da mit dem Buffer gemacht wird.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:
Lass einfach mal zweimal hintereinander genau ein byte reinkommen und beide bytes haben zufällig denselben Wert. Perfekt, für Ralf ist das Ende der Datei erreicht, logisch.

---

Zitat:

---

Nein! Read() kommt erst zurück, wenn mindestens ein byte gelesen wurde. Man programmiert nicht, in dem man Annahmen macht, sondern mit der Anwendung dessen, was man in der Dokumentation liest.

---

Zitat:

---

Wozu?
Es funktioniert mit copy, mit type und auch sonst allen Programmen, die nach der Spezifikation gehen. Du kannst Dir sicher sein, dass copy blockweise kopiert. Aber extra für Dich habe ich den Test gemacht, funktioniert exakt so, wie erwartet. Da ich ja nicht weiss, welche Version Du benutzt, ich habe die von amitcp benutzt, inet-handler 1.64 (16.11.93), aber letztendlich funktioniert auch jede andere Version, wenn type und copy funktionieren. Und das haste doch getestet, oder?

---

[ - Antworten - Zitieren - Direktlink - ]