Nicht ganz. Man braucht nur eine CE-Instanz. Ich formuliere anders ... CE ist gedacht extern CWs von einem anderen CE zu beziehen. Das ist hier aber nicht der Fall (ich habe keinen anderen CE Partner). Ziel ist, mit meinen 3 Proxies selber CWs generieren, und die CE-Instanz damit zu speisen. Problem ist, dass wenn ich eine Box benutze um die Proxies + CE-Instanz zu fragen, wird die Antwort des schnellsten Proxy benutzt. Die CWs kommen dann (wenn die Gruppen richtig gesetzt sind) sehr wohl in die CE Instanz, aber das bringt nichts mehr da das CW bereits (von einem Proxy) an die Box weitergeleitet wurde. In diesem Fall könnte eine Lösung so aussehen, die 4 Anfragen zu schicken, jedoch nur eine Antwort (die der CE-Instanz) in der Box zuzulassen. Man fragt 4 Reader gleichzeitig, akzeptiert aber nur einen Antwort.@geohei deine Überlegungen finde ich ganz interessant. Wenn ich das richtig verstanden habe, ...
Stimmt möglicherweise(!), aber ist jedenfalls besser als das was ich jetzt habe. Außerdem glaube ich nicht, dass bei mir alles aus einer Quelle kommt (aber das ist OT hier).Das bringt gar nichts weil sich hinter den Proxys die selben Quellen befinden können
wait_time = 09c4:290
cacheex_cw_check = 09c4:0:2
1. (ecm) cx_client (09C4@000000/0C28/007C/A7:070BF9CCE87127223C25D7BA66CE1E6E): cache3 (270 ms) by cx_prx1 (cw count 2)
2. (ecm) cx_client (09C4@000000/0C28/007C/A7:73E7E8A2B21E1CD64113DF6CECA216D1): cache3 (252 ms) by cx_prx1 (cw count 3)
3. (ecm) user1 (09C4@000000/0C28/007C/A7:EA5C343B74EE904DE7FC8AD6EF906F4B): found (263 ms) by cx
4. (ecm) user1 (09C4@000000/0C28/007C/A7:C59AA79359EF7E56983BE66DC97DA2AA): cache1 (272 ms) by prx1 (cw count 2)
Ist das nur in bestimmten Fällen so? Wenn ich meine Serverbox auf einen Sender stelle und eine Clientbox auch, sehe ich das die clientbox aus dem Cache versorgt wird. Stelle ich die Group der Clientbox nun um, bleibt das bild schwarz und es kommt "rejectet group" im Server Log und "not found" im Clienten Log. Wenn Cache nun keine Gruppenbegrenzung kennen würde, würde die Clientbox doch eigentlich weiter aus dem Cache versorgt werden müssen oder wie ist dein Satz zu verstehen?Cache 1/2 kennt keine Gruppenbegrenzung.
Aber ... CEX wird nur in der ersten Logzeile benutzt, nicht in der zweiten. Wieso das denn (nichts hat geändert)?Natürlich wird CEX zuerst genommen, weil du mit der Waittime alles Verzögerst.
Der cw count im log gibt an, wie oft das cw vorhanden ist. das hat nichts mit der Einstellung "cacheex_cw_check" zu tun.Wie kann cw count 3 sein wenn 2 als minimum CWs eingestellt ist?
Ich glaube du verwechselst hier Cache 1/2 und Cache 3.Wenn Cache nun keine Gruppenbegrenzung kennen würde, würde die Clientbox doch eigentlich weiter aus dem Cache versorgt werden müssen oder wie ist dein Satz zu verstehen?
Ich verwende kein CEX.Ich glaube du verwechselst hier Cache 1/2 und Cache 3.
Cache 1/2 ist der interne Cache von Oscam, dieser kennt keine Gruppenbegrenzung. Cache 3 (z.B. der CEX Cache) kennt sehr wohl Gruppenbegrenzungen.
Hmmm ... verstehe ich jetzt nicht. Für mich war es bisher immer so - Wenn die Anzahl der identischen CWs aus cacheex_cw_check erreicht ist geht der CW auf die Reise, auch wenn wait_time noch nicht erreicht ist. Das wären bei mir bei 2 CWs. Hier kommt dann der Logeintrag bei 270 ms (1. Eintrag im Log oben). Danach kann noch der dritte, vierte ... CW kommen, aber das spielt dann keine Rolle mehr (werden verworfen da CW schon verschickt wurde). Auslöser zum Versenden des CW an den Client (und des Logeintrags), ist der zweite (zum ersten identischen) CW. Somit sollte hier doch nie eine Zahl größer als cw count 2 stehen, da sonst das Versenden des CWs schon hätte früher passieren müssen.Der cw count im log gibt an, wie oft das cw vorhanden ist. das hat nichts mit der Einstellung "cacheex_cw_check" zu tun.
Das cw könnte auch einen count von 5 haben, wenn genug quellen vorhanden sind.
(ecm) user (09C4@000000/0BC0/007F/A7:274D23FCF4C82F0E30937CCA94ACF7C4): found (258 ms) by cx
...
(reader) o2cx_r [cs378x] TRACE: ecm answer for ecm hash 274D23FCF4C82F0E30937CCA94ACF7C4 rc=0
cache 1/2 und cache3 sind klar. Wenn cache1/2 keine Gruppenbegrenzung kennt, wieso kommt dann Eintrag 4. aus meinem Log oben zustande? user1 hat Gruppe 10 und cx auch Gruppe 10 . Beide haben sonst keine andere Gruppe. Wieso kann user1 etwas von prx1 bekommen? Außerdem hat @el_malto in #54 geschrieben, dass wenn der die Gruppe wechselt, serverseitig ein reject kommt, obwohl das CW im cache liegt (da Serverbox gleichen Sender hat wie Clientbox). Irgendwas passt da nicht.Ich glaube du verwechselst hier Cache 1/2 und Cache 3.
Cache 1/2 ist der interne Cache von Oscam, dieser kennt keine Gruppenbegrenzung. Cache 3 (z.B. der CEX Cache) kennt sehr wohl Gruppenbegrenzungen.
CEX ist zum pushen von CWs. Hast du nur eine Server- und eine Clientbox macht es wenig Sinn.Dann würde der Cache 1/2 doch auch keinen Sinn ergeben oder? Wenn man mehrere Clienten mit unterschiedlichen Gruppen hat, müsste ja nur ein Client einen Sender gucken den ein anderer aufgrund der unterschiedlichen Gruppen nicht sehen "darf" und schon könnten alle Clienten den Sender gucken obwohl diese in anderen Gruppen sind...?
Wenn ich das richtig deute, wird immer auf die wait_time gewartet. Also selbst wenn du 2 gleiche CWs nach 30ms hast, wird auf die wait_time gewartet.0 = when wait_time expires, serve highest counter's cw got anyway, even if no counter reached. 1 = never serve cw (coming from cacheex) stored in cache if its counter not reaches counter. When wait_time expires, requests will go to normal readers! Only when a cw reaches counter, it can be served to clients.
Wir verwenden Cookies und ähnliche Technologien für folgende Zwecke:
Akzeptieren Sie Cookies und diese Technologien?
Wir verwenden Cookies und ähnliche Technologien für folgende Zwecke:
Akzeptieren Sie Cookies und diese Technologien?