RPG Socket Serverinstanz

[kuempi von stein]

Hallo again,

heute habe ich mal eine knackige Frage denke ich.
Folgendes Szenario:
Auf der einen Seite ein Programm, welches am Port lauscht und innerhalb einer Schleife solange Accept(Socket) versucht, bis Daten anliegen. Immer wenn ein neuer Satz anklopft, wird der Socket per GiveDescriptor an eine von mehreren Serverinstanzen übergeben.
Auf der anderen Seite laufen nun eben mehrere Serverinstanzen und holen sich sich innerhalb einer Schleife per TakeDescriptor die Zuordnung, lesen die anklopfenden Daten, reagieren entsprechend drauf und schliessen den Socket danach.

Nun meine Fragen:
Was würde passieren, wenn ich den Socket nicht schliesse sondern einfach die Schleife wieder neu beginne und den "abgearbeiteten" Socket per TakeDescriptor "überklatsche"? Geht das überhaupt? Was hätte das für Konsequenzen?
Und angenommen, wir reden hier von einem Mengengerüst von sagen wir mal > 10000 (oder wieviel auch immer) Schleifendurchgänge - könnte das ressourcentechnisch Konsequenzen haben?

Ich hoffe, ich habe mich verständlich genug ausgedrückt?

Schönen regnerischen Tag noch

kuempi

[kuempi von stein]

boh ej....

nicht alle auf einmal bitte.

[kuempi von stein]

hello @all,

diese socketgeschichte mit takedescriptor und givedescriptor ist noch nicht wirklich ausgestanden.
programm scheint zu laufen, ob es denn auch so ist, wird die erfahrung zeigen.

ich mache den thread nochmal auf, um mal zu hören, ob hier einer erfahrung unter ile-rpg damit hat, weil ich mich einfach mal austauschen möchte um zukünftige überraschungen zu vermeiden.

also die frage ist: hat hier einer erfahrung mit sowas und ist diese(r) jenige welche(r) willens und in der lage sich mal mit mir auszutauschen...(mail,telefon was weiss ich)???

kuempi

[Rincewind]

Hi,

Erfahrung mit Socket Server & Client sind vorhanden, ebenso natürlich der Wille zum Austausch...

Aber leider kann ich dir bei deinen flexiblen Sockets nicht so richtig helfen, wir haben nämlich pro Server die Clientanzahl auf 2 Begrenz (1 für die wirklichen Daten & 1 Zum Beenden/Testen etc).

Ich lausche auch einfach auf den Port wo die daten herkommen sollen, lese was mir der Client schickt... entscheide je nach Datensatzart in welche DTAQ ich die Daten schreibe und pro DTAQ läuft wieder 1 Programm dass auf die Daten wartet.

Bei meinem Client läufts ähnlich... er lauscht den ganzen tag auf 1 DTAQ und wenn da was reinkommt schickt ers an den Server.

Schönen Sonnigen Tag

Rince

P.s. Ich stehe mehr auf Mail/Forumsdiskussionen

[kuempi von stein]

Hi,

Erfahrung mit Socket Server & Client sind vorhanden, ebenso natürlich der Wille zum Austausch...

Aber leider kann ich dir bei deinen flexiblen Sockets nicht so richtig helfen, wir haben nämlich pro Server die Clientanzahl auf 2 Begrenz (1 für die wirklichen Daten & 1 Zum Beenden/Testen etc).

Ich lausche auch einfach auf den Port wo die daten herkommen sollen, lese was mir der Client schickt... entscheide je nach Datensatzart in welche DTAQ ich die Daten schreibe und pro DTAQ läuft wieder 1 Programm dass auf die Daten wartet.

Bei meinem Client läufts ähnlich... er lauscht den ganzen tag auf 1 DTAQ und wenn da was reinkommt schickt ers an den Server.

Schönen Sonnigen Tag

Rince

P.s. Ich stehe mehr auf Mail/Forumsdiskussionen

japp...

ich habe die programme erstmal wieder auf den grossen haufen gelegt.
grund war, dass im testbetrieb immer nur ein anklopfender satz abgearbeitet und weitergereicht werden konnte.
folgesätze verursachten dann auf der gegenseite eine mauszeigersanduhr,
obwohl aus meiner sicht das takeprogramm den socket sauber behandelt hatte.
ob das nun an meiner programmierung oder an der gegenstelle lag, konnte auf die schnelle so nicht festgestellt werden.
ich wollte die gegenstelle nun auch nicht mit der nase drauf stossen, dass bei mir "rumgetestet" wird.
um die laufende produktion nicht zu gefährden wurde deshalb wieder zurück auf die alte konventionelle lösung geschaltet.

der anlass für mich mit take und give rumzuprobieren war ein mögliches datenaufkommen in der zukunft.
mit der einfachen lösung kann es ja theoretisch irgendwann mal nen "stau" geben wenn mehrere datensätze gleichzeitig (bzw. innerhalb kürzester zeit) auflaufen und von den folgeprogrammen über die dtaq nicht mehr rechtzeitig "in time" abgearbeitet werden können.
dies ist aber zur zeit nicht gegeben, deshalb reicht eben zur not die standardlösung.

sollte sich in zukunft ein performanceengpass ergeben krame ich eben meine lösung wieder raus und teste bis zum erbrechen.

die redbooks haben btw. da auch nicht weitergeholfen, wobei ich seinerzeit auf grundlage von scott klement seiner vorgestellten lösung entwickelt hatte.

anyway...

wenn sich mal wieder was ergibt können wir uns ja abgleichen.

kuempi

[Rincewind]

Hi,

An Scott Klement habe ich mich auch orientiert, ist einfach eine schöne (und schön dokumentierte) Lösung.

Das mit dem "Stau" ist natürlich eine Gefahr wenn mehrere Clients an einen Server senden.
Bei uns muss sichergestellt sein dass alle Sätze in der Reihenfolge abgearbeitet werden wie sie ankommen (Karton muss erst von A->B fahren bevor er von B->C fahren kann).

Da hab ichs definitiv leichter.

Ich habe bisher auch nur mit 2 Clients getestet, wobei 1 Server halt immer nur 1 Client zurselben Zeit bedienen kann, selbst wenn die bearbeitung nur Millisekunden braucht.

Aber meine Daten sind , wie gesagt, auch zwingend voneinander abhängig.

Schönen Tag noch

Rince

[Fuerchau]

Dabei ist eine DTAQ (ggf. Keyed) per ActiveX so schön einfach (und auch schnell).
Zumal durchaus mehrere Job's auf der selben DTAQ horchen und somit quasi parallel arbeiten können.
Einfache Schnittstellen, schnell und flexibel, zu verwenden von fast allen ClientSprachen von VB/VBA/C++/Java/VisualRPG u.v.m.

Wenn die DTAQ auch noch auf Disk gesichert wird (Attribut bei Erstellung) ist sogar eine nachgelagerte Verarbeitung (also asynchron) möglich, was bei einer Socket-Verbindung nun mal nicht möglich ist.

[BenderD]

japp...

der anlass für mich mit take und give rumzuprobieren war ein mögliches datenaufkommen in der zukunft.
mit der einfachen lösung kann es ja theoretisch irgendwann mal nen "stau" geben wenn mehrere datensätze gleichzeitig (bzw. innerhalb kürzester zeit) auflaufen und von den folgeprogrammen über die dtaq nicht mehr rechtzeitig "in time" abgearbeitet werden können.
dies ist aber zur zeit nicht gegeben, deshalb reicht eben zur not die standardlösung.

sollte sich in zukunft ein performanceengpass ergeben krame ich eben meine lösung wieder raus und teste bis zum erbrechen.

die redbooks haben btw. da auch nicht weitergeholfen, wobei ich seinerzeit auf grundlage von scott klement seiner vorgestellten lösung entwickelt hatte.

anyway...

wenn sich mal wieder was ergibt können wir uns ja abgleichen.

kuempi

Hallo,

da brauchts dann Multithreading und das geht mit RPG/COBOL nicht, deren runtime ist nicht Thread sicher und die H Option schaltet das threading faktisch ab. Mit C sollte das gehen, oder mit Java, ob letzteres allerdings auf der AS rennt, das hängt von den GigaHertz und GigaByte ab.

mfg

Dieter Bender