AW: Wunschzettel für Avanti

[Harald Schmid]

Lieber Herr Berger,

erstmal vielen Dank für's Mitdenken.

>
> HTTP 1.1 kennt dies als "chunked".
>
> Ich sehe aber ueberhaupt keinen Vorteil in dieser Geschichte
> (ausser den animierten Statusbalken): TCP ist ein Protokoll,
> wo nichts "zwischendurch" verloren gehen kann. Es kann
> natuerlich sein, dass etwas nicht vollstaendig uebertragen
> wird, an der Stelle helfen aber nur Timeouts und
> Verbindungsabbrueche.

Tja, wenn ich mir die Sache nochmal durchdenke, dann stimmt das mit dem
Ergebnis von Avanti natürlich. Solange kein AVANTI:EOR kommt, ist der Job
eben nicht ganz angekommen. Allerdings hilft mir das im konkreten Fall nicht
ganz weiter.

Der (animierte) Statusbalken ist hier nicht nur nette Unterhaltung. Man
stelle sich eine Anwendung vor, die es erlaubt eine Avanti-Ergebnismenge zu
bilden und diese per Download herunterzuladen. Da hat der User ja erstmal
keine Ahnung, ob er nun 5 Treffer erhält oder 5000. Und das kann bei einem
Download-Job mit einer entsprechenden Parameterdatei schon einen gewaltigen
Unterschied machen. Der User hingegen sieht nur (d.h. er sieht nichts), daß
sich nichts tut und denkt sich vielleicht, der Client oder Avanti sei
abgestürzt.

Man könnte jetzt ja auch die Anzahl der empfangenen Bytes anzeigen, aber da
weiß der User ja beim Stand von 2 MB (wenn ich denn den Ergebnisspeicher
z.B. auf 5 MB setze), ob jetzt gleich Schluß ist, oder ob sich ein Abbruch
doch lohnt, da noch 3 weitere MB kommen und ein Ergebnis in dieser Höhe
keinesfalls gewünscht war.

> Wann und wie soll denn etwa avanti
> einem Client mitteilen, dass er nicht die angekuendigte
> Anzahl Bytes empfangen hat? Was soll dann passieren?
> Umgekehrt dasselbe: Wenn nicht innerhalb einer gewissen
> Zeit das AVANTI:EOR kommt, muss ein Client davon ausgehen,
> dass er nicht alles bekommen hat. Avanti sollte natuerlich
> ein leeres Resultat oder eine Fehlermeldung schicken, wenn
> er beschliesst, einen Job (wg. Unvollstaendigkeit oder
> Syntaxfehlern) zu ignorieren.

Wenn Avanti den Job tatsächlich ignoriert, dann wird er auch keine
Fehlermeldung schicken, nehm ich mal an. - Da scheint mir der andere Weg
doch sicherer mit der Empfangsbestätigung. Wenn die innerhalb einer gewissen
Zeit nicht kommt, dann kann ich vom Client aus die Verbindung kappen und das
Ganze neu versuchen.

> Ausserdem sollte er in diesem
> Fall die Verbindung kappen, weil die Synchronisation zwischen
> Client und Server hoechst schwierig sein duerfte, falls sie
> erst einmal ausserhalb der regulaeren Uebertragungen
> angelangt ist.
>
> Vom "anderen Ende" geschlossene Verbindungen zu erkennen,
> ist uebrigens eine Kunst und wohl auch plattformabhaengig,
> sprich abhaengig vom jeweiligen TCP-Stack. Jedenfalls
> habe ich irgendwo einmal aufgeschnappt, dass es unter
> Win'95 besonders schwierig ist, bei anderen Win's ist
> es wohl besser.

Andere Frage: Was tut Avanti eigentlich, wenn die Verbindung vom Client
gekappt wird, während er gerade das Ergebnis zusammenstellt, oder bereits
einen Teil verschickt hat?

>
> viele Gruesse
> Thomas Berger
>

Langer Rede kurzer Sinn: Vielen Dank Herr Berger für Ihre kritische Antwort.
Da sind mir doch durch den Zwang zum nochmaligen Durchdenken meiner Wünsche
noch einige Möglichkeiten in den Sinn gekommen, den Client so zu verändern,
daß er mögliche Fehler eher erkennt und selbst damit umgehen kann.

Viele Grüße

Harald Schmid