Job-Puffergroesse v. Avanti-W?

[Anando Eger]

Lieber Herr Berger,

> > > vermute einmal, dass Sie Ihren Log-Dateien entnehmen
> > > koennen, dass die Fehlermeldungen bzgl. fehlender
> > > Sprungmarke stets im Kontext der Datenbank "avdemo"
> > > mit User "opac" abgelaufen sind.
> >
> > nein, die stimmten. Interessant ist nur, dass im
> > Avanti-Log eben diese "Current database : ..."-Zeile
> > exakt 400(hex) Byte nach dem den Job einleitenden "&"
> > stand, wenn ein Fehler aufgetreten war.
> 
> exakt 1kB also, evtl. trunkiert Ihre avanti-Version
> den Jobtext beim Loggen, das muss nichts bedeuten.
> Wenn Datenbankname, Benutzer und Passwort stets
> stimmen, so ist das ein Zeichen dafuer, dass das
> Ende des Jobs vorhanden war, als er ausgefuehrt
> wurde, 

Genau.

> aber vielleicht war er verstuemmelt?

Die Frage ist: Wann oder Wo?

Natürlich prüft man erst, ob man selbst schuld ist - wenn der
an send() übergebene Puffer hinsichtlich Inhalt und Längenangabe
noch korrekt ist, muss man das untersuchen, was nach Auftruf dieser 
Funktion geschieht. Wenn send() ohne Fehler zurückkehrt, kann ich
als Programmierer nur davon ausgehen, dass das System alles
richtig abgeschickt hat.

> > > Spricht man mit avanti-w, so haengt es sich tatsaechlich
> > > auf, bei avantserv (avanti als Systemdienst) und
> > > avanti-x auf Solaris kehrt es jedoch zurueck.
> >
> > Das könnte die Erklärung für die von mir beobachteten Effekte
> > sein - mein Client ist ein Multithreaded-Programm, kann
> > also an beliebiger Stelle "aufgehalten" werden - und ich weiß
> > nicht, ob send() im system-context atomar ist...
> 
> Wenn send() nicht thread-safe ist, haben nicht nur Sie
> ein Problem. Ansonsten wuerde ich erwarten, dass send()
> ein "blocking" Systemaufruf ist, d.h. Sie uebergeben
> Daten im Buffer und die werden entsprechend der Blockgroesse
> der Verbindung vom System zerteilt und nacheinander
> gesendet, sobald gesendet werden kann. Spaetestens wenn
> dieser IO-Vorgang blockiert sollte ein Kontextwechsel erfolgen.
> Erst "ganz tief unten" sind atomare Vorgaenge, die auf
> Treiberebene dafuer sorgen, dass keine unvollstaendigen
> Pakete abgeschickt werden...

Genau: Ich hatte auch nicht erwartet, dass send() unteilbar ist - das
darf lt. Theorie auch nicht sein, (aber ich WEISS es nicht).

Also muss ich doch auf Sende- und auch auf Empfangsseite 
immer davon ausgehen, dass Daten verzögert und geteilt werden können 
und rechne mit der für mich ungünstigsten Variante.

So muss ich immer davon ausgehen, dass ich auf Empfangsseite,
da ich ja keine unbegrenzt großen Puffer habe, die Daten stückweise
lesen und dann geeignet zusammensetzen und entsprechend den Protokoll-
vereinbarungen (hier: AVANTI:EOJ/EOR-Verfahren) neu ordnen muss.
TCP/IP gewährleistet nur, dass alle gesendeten Daten vollständig und 
in der richtigen Reihenfolge ankommen, aber nicht eine bestimmte
"Stückelung" - die kann je nach Systembedingungen variieren.

Die Nagelprobe: Wenn Avanti bei Ansprache z.B. durch Telnet erst
bei Empfang eines "\nAVANTI:EOJ\n" beginnen würde (Timeout von 
einigen Sekunden müsste aber sein), wäre alles o.k. Dann könnte ich
sogar per Telnet einen Avanti-Job zeilenweise abschicken!
Das entspräche dann dem "worst case" in einer stark gestörten 
Umgebung - 
    
      wäre das nicht schön?

Eine Zusammenfassung dessen, was ich zum "avanti-Protokoll" 
(hier nur TCP/IP) kenne:

1. Der Client öffnet eine neue Verbindung zum Avanti-Server

2. Der Client schickt einen Job an Avanti; 
   Format: Text, Codierung variabel 
   Beginn: &-Zeile (ist der "virtuelle Aufruf-Pfad" noch von
           Bedeutung? Der Client sollte doch von den lokalen
           Einstellungen nichts wissen, oder?)
   Ende:   "@ DB=(dbname) ID=(user)/(password)\nAVANTI:EOJ\n"  
           (C-Notation) 
   unklar: gibt es eine Vereinbarung zur Codierung der 
           (dbname) und (user)/(password)-Angaben?
	   Ich habe bisher US-ASCII angenommen.

3. Avanti bearbeitet den Job und schickt die Ergebnisse über die 
   gleiche Verbindung zurück
   Beginn: nicht definiert (also erstes ankommendes Zeichen)
   Ende:   "\nAVANTI:EOR\n"
   Meldungen werden, so "echo on" gesetzt ist, in der Form
   "M<XNNN>Klartext\n" in den Ergebnisdatenstrom eingefügt
   und müssen aus diesem vor Weiterverarbeitung der Ergebnisse
   wieder entfernt werden.

4. Der Avanti-Server trennt die Verbindung

   Der Avanti-Server trennt die Verbindung auch, wenn 90s keine
   Daten empfangen wurden (die 90s sind der default-Wert in den
   Avanti-W-Settings, den man natürlich ändern kann)

Das ist das, was ich bisher aus den verschiedenen Doku's und
den Mailing-Listenbeiträgen herausgelesen habe. 

Ist das vollständig?

Viele Grüße
Anando Eger