Re: [Ftraq-devel] Resumes bei ASCII-Dateien

[Steffen S. <ste...@gm...>]

Erik Moeller wrote:

>Am Don, 2002-06-20 um 11.33 schrieb Steffen Sauder:
>  
>
>>Nach langen Überlegungen und nochmaligem Überschlafen bin ich zu dem 
>>Schluß gekommen,
>>daß sich ASCII-Transfers  nicht vernünftig vernünftig resumen lassen.
>>
>>    
>>
>
>Wollten wir es nicht so machen, dass wir in der Queue statt der
>transferredBytes die readBytes vom Server speichern, also die Zahl der
>übertragenen Bytes *vor* der Konvertierung? Dann könnte man doch einfach
>an dieser Position weitermachen. 
>
ich habs wohl blöd erklärt. das problem ist nicht die konvertierung die 
wir durchführen,
sondern die, die der server macht.

wenn eine Datei auf einem UNIX server z.B. 100 bytes groß ist, dann 
liefert der server
z.B. 110 bytes, weil zehn LFs von ihm hinzugefügt worden. Brechen wir 
nun nach 50 gelesenen
bytes ab(die wiederum 50 oder weniger bytes auf der lokalen platte 
beanspruchen, aber wir nehmen
ja wie du richtig gesagt hastdie info der übertragenenen bytes), und 
nehmen den transfer bei Byte 50 wieder
auf, so erhalten wir das 50.te Byte, auf der Server-Platte, da die 50 
übertragenen Bytes beispielsweise aber nur
die Information der ersten 45 Bytes auf der Server-Platte enthalten (da 
er vorher 5 LFS hinzugefügt hat) fehlen
uns damit die bytes 45-49.  Leider können wir vorher nicht feststellen, 
ob der Server die Bytes auf  siner Platte
im UNIX-Format speichert oder nicht, so daß wir nicht einfach generell 
die Anzahl der vorher eingefügten
Linefeeds von der gewünschten Resume-Position abziehen können

>Damit man dann bei unterschiedlicher
>Größe noch feststellen kann, ob ein Resume möglich ist, würde man dann
>0-100 Bytes zurückgehen und einfach nur auf Identität prüfen, wobei die
>Bytes vom Server bei dem Vergleich einmal durch die
>LF-Konvertierungs-Funktion gejagt werden müssten -- wenn kein LF drin
>ist, ist es auch kein Problem, wir gehen davon aus, dass die
>übertragenen Bytes korrekt konvertiert wurden.
>  
>
Naürlich geht das, allerdings wäre es bei sich Texten mit vielen 
wiederholenden Zeilen
(ich denke da z.B. an lange logfiles) eine sehr unsiche Entscheidung zu 
sagen, daß nur weil
100 Zeichen gleich waren, man wirklich die richtige Stelle im Dokumente 
gefunden hat.
Auch bei steigender Zahl der zu vergleichenden Zeichen geht die 
Wahrscheinlichkeit, das man
die richtige Stelle gefunden hat zwar gegen 1-  aber sicher sein kann 
man trotzdem nur wenn man alles liest.

>In der Ebook-Szene wäre ein solcher Resume sicher nett, da werden oft
>600K-Textfiles übertragen. Wenn es zuviel Aufwand ist, würde ich es aber
>erstmal unter "nice to have" abhaken.
>
Jo ich verschiebe es erstmal nach hinten, kämpfe gerade mit einigen 
Problemen beim
Abbrechen von Transfers.

Steffen