Job-Puffergroesse v. Avanti-W?

[Thomas Berger]

Liebe Frau Koczian,

> >Client und Server haben keinen Einfluss auf die maximale
> >Paketgroesse ihrer Verbindung und es gibt keine Methode,
> >die garantieren wuerde, dass der Server unmittelbar nach
> >Auslesen des ersten Pakets das zweite Paket bereits
> >empfangen hat. Eine errechnete Laengenangabe am Anfang
> >des Jobs oder eben - wie eingebaut - ein explizites
> >Ende-Element auf Protokollebene sind die einzigen
> >Moeglichkeiten, vollstaendige Kommunikation zu
> >gewaehrleisten.
> 
> m.W. gilt eigentlich die errechnete Längenangabe als "State of the Art" und
> das explizite Ende-Elemente als zweite Wahl, richtig? (Die Probleme mit
> einem potentiell zerrupften AVANTI:EOR sprechen ja dafür)

Schwer zu sagen. Im Bereich von WWW/HTTP gibt es auch noch
ein Zwischending: "chunked" encoding: Der Inhalt kommt
portionsweise, vor jeder Portion steht, wie gross sie ist.

Laengenangaben sind gut, wenn man ein Transportprotokoll
(etwa HTTP) hat, das sich nicht darauf verlassen kann,
wie die Inhalte (HTML-Seiten mit Ende-Kennung, Graphiken
mit impliziter Groesse, Text- oder Binaerdateien ganz
ohne) strukturiert sind: man kann nicht einfach ein
"HTTP:END-OF-TRANSMISSION" hinten anhaengen, weil 
insbesondere nicht klar sein kann, wo der uebertragene
Inhalt endet. Wichtig ist das immer dann, wenn eine
Verbindung fuer mehrere "Transaktionen" genutzt
wird: Da ist nicht mehr das (einseitige) Trennen der 
Verbindung Kriterium dafuer, dass die Uebertragung
beendet ist, sondern der Empfaenger muss erkennen,
an welcher Stelle ein Wechsel von Protokoll- zu 
Anwendungsdaten (einfach) und zurueck (schwer) erfolgt.

"Chunked" Laengenangaben sind gut, wenn man anfangs
nicht weiss, wieviel gesendet wird (etwa bei dynamisch
generierten Inhalten oder Streaming, wo es ja ueberhaupt
kein Ende als solches gibt). Ohne Laengenangabe ist
aber auch nicht schlimm, wenn am anderen Ende jemand
sitzt, der die Struktur der empfangenen Daten kennt.
Laengenangaben sind auch gut in dem Sinne, dass man 
auf einer Ebene oberhalb von IP eine weitere
Moeglichkeit hat, die empfangenen Daten auf
Vollstaendigkeit hin zu ueberpruefen.

Nachteil bei Laengenangaben ist allerdings, dass 
sie eine Eigenschaft des Transportprotokolls sind,
nicht der Anwendung: Avanti beispielsweise duerfte
die von ihm selbst generierten Texte nicht einfach
so 'rausschieben, es muesste - auf der Ebene, die
derzeit nur das "AVANTI:EOR\n" generiert - hier
eine zusaetzliche Schicht eingebaut werden, die
Ergebnisse zwischenpuffert und ab und zu mit
Laengenangaben versehen weiterverschickt. Umgekehrt
muesste jeder selbstprogrammierte Avanti-Client 
nicht einfach ein "AVANTI:EOJ" anhaengen und auf
ein empfangenes "AVANTI:EOR" achten, sondern ebenfalls
eine zweite Schicht implementieren, die fuer
selbsterzeugte Texte die Laenge berechnet und
bei empfangenen Texten die Laengenangaben ausfiltert.
Das gibt dann einen ziemlichen Spass mit den
verschiedenen Zeilenendekonventionen und auch 
mit den ASCII-0, die avanti angeblich nicht liefert.

Wuerde man "avanti ueber http" sprechen, so wuerde
diese Arbeit die eingebundene HTTP-Library machen,
weil man aber "avanti uber avanti" transportiert,
macht das alles wenig Sinn (solange man aufpasst,
die Zeichenkette "AVANTI:EOR" in einer Zeile fuer
sich nicht mutwillig mitten im Resultat zu generieren...)

viele Gruesse
Thomas Berger