Frage: Methodendesign blocking call über 3 Ecken
-
ich habe eine Datenquelle, die mir unterschiedliche daten zu einem server sendet, von diesem server wiederum gehen die daten zu einem client ... das passiert permanent ABER unregelmäßig.
im server ist eine request-funktion implementiert, mit der ich eine anfrage wiederholt sende und die bestätigung darauf aus dem regulären datenverkehrt herausfiltere und dann zurückgebe.
dasselbe soll auch im client passieren, meine frage an euch wäre jetzt: wie soll ich diese funktion im client realisieren.
meine idee wäre gewesen, den datenverkehr wie üblich weiterzuleiten und denselben filter den ich im server verwende auch im client zu implementieren ... einfachste möglichkeit, was aber theoretisch speicherverschwendung darstellt ...
meine 2te idee war im client die "anfrage" abzuschicken, im server den request auslösen, derweil die methode zu blockieren bis der server einen erfolg(und das antwortpaket) oder einen misserfolg meldet.
!Problem! hierbei, die anwendungen die diesen client verwenden sind single threaded und blockieren fast vollständig solange keine antwort kommt und die antwortzeit des server kann u.U. enorm hoch werden, kommt auf die netzwerkbelastung, die datenquellen und clientnazahl an
(bitte keine kommentare zur netzwerklast, ich hab meine gründe das ich das schreibe)
-
Was genau muß man sich da unter der Request-Funktion vorstellen? Fragt da der Server die Datenquelle, ob sie ein (verlorenes) Paket nochmal senden kann? Oder fragt jemand von außen den Server?
Ich würde so eine Verarbeitung vermutlich über Multi-Threading lösen - wenn das nicht geht, könntest du das Verhalten auch nachbilden.
(die Request-Funktion sendet die Anfrage und trägt einige Daten dazu in einer global erreichbaren Liste ein, die normale Empfangsroutine filtert Request-Bestätigungen heraus und kümmert sich dann um die Nachbearbeitung)
-
naja es geht darum das auf ein bestimmtes anfrage paket auch eine antwort kommt ...
bisher: client startet anfrage (server über DCOM am lokalen rechner gestartet) der RPC vom client wird geblockt und der server filtert das antwort paket, gibt den call wieder frei und gibt antwortpaket an den client zurück.
jetzt: client und server sind getrennt, serverauslastung ist recht hoch (alle clients und die datenquellen sind auf diesen einen server konzentriert), latenzzeit des server ist signifikant größer als über DCOM und EVENTUELL kann die verbindung zum server während der anfrage unterbrochen werden
deswegen die frage, einfach die datenpakete zem client durchstellen und dort filtern oder im client den call blockieren bis der server den call über ein signal wieder freigibt mit entweder dem antwortpaket oder einem "fail".
problem, was wenn der die verbindung zum server abbricht ... der call würde dann in der luft hängen weil er theoretisch kein signal bekommt ...
by the way ... ich glaub ich werde eine etwa ältere version die ich für die DCOM variante des server konstruiert habe recyclen, das spart zeit und der filter sitzt auf clientseite.
für eine effizientere idee bin ich aber dennoch offen