Socket-Buffer nicht gecleart

[storock]

Ich übertrage Strings von einer Client-Anwendung per Socket an die iSeries. Dabei habe ich am Client ein Feld, in welchem beliebiger Inhalt (auch Sonderzeichen) liegen. Das klappt soweit auch ganz gut, nur beim Übertragen eines Satzes wird der Buffer nicht gecleart. Kann das an irgend welchen Sonderzeichen liegen?
PS: der String schließt immer korrekt mit NULL ab.

[BenderD]

da kann man an sovielen Stellen was verkehrt machen, dass man Hellseher sein müsste, um mit diesen sparsamen Informationen eine Diagnose abzugeben.

B*D

Ich übertrage Strings von einer Client-Anwendung per Socket an die iSeries. Dabei habe ich am Client ein Feld, in welchem beliebiger Inhalt (auch Sonderzeichen) liegen. Das klappt soweit auch ganz gut, nur beim Übertragen eines Satzes wird der Buffer nicht gecleart. Kann das an irgend welchen Sonderzeichen liegen?
PS: der String schließt immer korrekt mit NULL ab.

[storock]

Sehr viel mehr Informationen gibt es leider nicht.
Die Anwendung soll PC-Dateien zum Teil auch mit Memo-Feldern auf die iSeries übertragen. Diese werden per SQL erstellt, wobei die Memofelder in CLOB-Felder umgewandelt werden. Dieser Step funktioniert auch wunderbar. Im Step 2 sollen dann auch noch die Daten der Tabellen auf die iSeries runter. Beim betreffenden String sind in einem Memo-Feld irgendwelche Druckersteuerungen hinterlegt, also auch jede Menge Sonderzeichen. Daher mein Verdacht, das irgend ein Sonderzeichen den Buffer dazu veranlaßt, sich nicht zu clearen.

[BenderD]

da gibt es ein Programm, das in den Socket schreibt und eines das liest, da kann man verschiedene Funktionen benutzen, da kann man blockierend oder nicht blockierend lesen und überall kann man was falsch machen...

Sehr viel mehr Informationen gibt es leider nicht.
Die Anwendung soll PC-Dateien zum Teil auch mit Memo-Feldern auf die iSeries übertragen. Diese werden per SQL erstellt, wobei die Memofelder in CLOB-Felder umgewandelt werden. Dieser Step funktioniert auch wunderbar. Im Step 2 sollen dann auch noch die Daten der Tabellen auf die iSeries runter. Beim betreffenden String sind in einem Memo-Feld irgendwelche Druckersteuerungen hinterlegt, also auch jede Menge Sonderzeichen. Daher mein Verdacht, das irgend ein Sonderzeichen den Buffer dazu veranlaßt, sich nicht zu clearen.

[storock]

ok, also:
es gibt einen PC-Client, der in der sicherlich überall bekannten Sprache WinDev geschrieben wurde ;-). Dieser macht einen Socket-Connect mit den Optionen Nagle-Algorythmus = off und NoEndTag (also nichts hinten an den SendString anhängen).

Auf der Gegenseite gibt es auf der iSeries einen Server in RPG, der dieses Connect empfängt und bestätigt.

Im Weiteren unterhalten sich beide Programme/Systeme über normales SocketRead / SocketWrite, wobei die Strings auf der iSeries jeweils mittels CDRCVRT konvertiert werden.

Damit man auf der ganz sicheren Seite ist, wird der zu sendende String in Häppchen zu je Tausend Byte gesplittet. Das erste Häppchen wird an die iSeries geschickt, dort zwischengespeichert und ein ok an den Client gesendet. Hat der Client das OK bekommen, schickt er das nächste Häppchen, die iSeries bewertet es und speichert es wieder zwischen, usw.. Das ganze ist über diverse Mechanismen abgesichert(timestamp, Counter,...) und wie gesagt funktioniert es auch soweit ganz gut.

Im vorliegenden Fall werden aus einer PC-Datei 8 Sätze zu ca. 5000 Byte an die iSeries geschickt und dort auch komplett verarbeitet.
Beim 9. Satz werden die 1. Tausend Byte gesendet und auf der iSeries im Server gepuffert. Das ok kommt zum Client zurück. Dieser sendet die nächsten tausend Byte (es sind im Sendepuffer tatsächlich auch nur die nächsten tausend Byte). Der Server der iSeries empfängt nun jedoch nochmal die 1. tausend Byte, sendet das ok an den Client und hat gleich im Anschluß, ohne das der Client neu gesendet hat, die nächsten tausend Byte bereitstehen.

In den ersten Tausend Byte ist ein Teil des schon oben erwähnten Memo-Feldes mit Sonderzeichen enthalten.

So, nun - Ausführlicher gehts wirklich nicht mehr.

[kuempi von stein]

mh..

schwierige Kiste.
Ich würd mal versuchen einzukreisen, obs nen Programmfehler ist oder ob es wirklich an den Sonderzeichen liegt.

Dazu mal auf der Senderseite den 5. oder 6. oder siebten Umlauf nicht senden (sollte relativ leicht zu proggen sein) und dann müsste ja schon der achte statt der neunte Durchgang knallen.

Wenns dann nicht knallt, muss es wohl nen Programmfehler sein, aber auf welcher Seite ist noch unklar..

k.

[BenderD]

an dieser Stelle würde ich erst mal genau abprüfen (STRSRVJOB STRDBG) was da genau passiert, ob da tatsächlich drei mal erfolgreich aus dem Socket gelesen wurde, oder ob man hier einer Erwartung aufsitzt. Wenn das dann sicher ist, müsste man nochmal nachsehen wie die Socket Eigenschaften genau gesetzt sind (setSockOpt o.ä.), davon könnte das Verhalten auch noch beeinflusst sein. Eventuell könnte es auch Sinn machen sich eine Diagnostic Procedure einzubauen, die mit getSockOpt Eigenschaften ermittelt und für Debug Zwecke protokolliert.

D*B

Der Server der iSeries empfängt nun jedoch nochmal die 1. tausend Byte, sendet das ok an den Client und hat gleich im Anschluß, ohne das der Client neu gesendet hat, die nächsten tausend Byte bereitstehen.

In den ersten Tausend Byte ist ein Teil des schon oben erwähnten Memo-Feldes mit Sonderzeichen enthalten.

So, nun - Ausführlicher gehts wirklich nicht mehr.

[storock]

Hallo BenderD, danke für die Mühe. Das Problem lag am Client.
Es war der erste String über 10.000 Byte, der überhaupt über den Socket gelaufen ist. In diesem Fall wurde aufgrund der Architektur des Socketstrings die Variable des Senderstring nicht gecleart.

Wie gesagt, danke für die Unterstützung.