Zu schnelle CWs vom Reader verwerfen

[el_malto]

Ja so ist das leider.

Ich haue das jetzt einfach mal so raus.
Wenn ich mir ein paar Ali oder China (ist nicht rassistisch gemeint) Lines besorgen würde, hätte ich überhaupt kein Problem damit diese mit Anfragen zu bombadieren und für mich das beste daraus zu ziehen und evtl. fake CWs zu "erkennen". Ich weiß, klingt ein doof und egoistisch. Aber das ist für die eh nur Business und geldmacherei. Die haben zu 90% eh alle keine lokalen Karten. Die interessieren sich auch nicht um die Clients die ganz hinten dran hängen. Da denkt jeder nur an sich und das würde ich dann auch nur machen.

 

[DarkStarXxX]

Gerade über diese Lines (die eigentlich nur aus MCS Cache bestehen) kommen eine Menge von diesen Fakes.

 

[geohei]

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

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.

Eine andere Möglichkeit wäre 2 Boxen einzuspannen, die auf dem gleichen Sender laufen. Box_1 befragt (wie oben) die 3 Proxies und die CE-Instanz. Box_2 befragt nur die CE-Instanz. Somit bekommt man nach wait_time die bearbeiteten (mehr oder weniger sauberen) CWs zurück. Die Box_1 hat sich somit die Fakes eingefangen und Box_2 hat keine (oder weniger) Fakes.

Noch eine andere Möglichkeit wäre, nur die CE-Instanz zu befragen, die seinerseits dann die Proxies sofort (ohne wait_time) fragen. Im Moment ist es so (cacheex_cw_check = x:1:z), dass die Proxies nur nach Ablauf befragt werden wenn die benötigte Anzahl z an CWs nicht erreicht ist. Wenn oscam jedoch die Möglichkeit vorsähe, die Proxies sofort nach Eingang des ECMs zu befragen, um so den CE mit CWs zu füllen, dann könnte man die Vorteile des CE nutzen um mögliche Fakes zu eliminieren. oscam befragt die Proxies aber erst nach wait_time, also geht das auch nicht!

Man braucht für all das also nur einen CE Instanz.

Das mit den 2 Boxen habe ich übrigens getestet. Läuft 1A, aber wie gesagt, nicht sehr elegant die Lösung und CE zweckentfremdet.

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

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).

Bleibt die Frage, ob ich eine Option übersehen habe.
Wäre das ...
1. kann man Anfragen (ECMs) an Reader verschicken und Antworten (CW´s) von einen spezifischen Reader ablehnen?
2. kann man den CE überreden die Proxies sofort zu befragen?
Programmiertechnisch sollte beides ein leichtes sein.

Beides wären meine 99% Lösung!
Mit AIO möglicherweise 99.9%,
Die perfekte Lösung brauche ich nicht.

 

[DarkStarXxX]

1. Nein, man kann keinen Reader sagen lehne ab.
2. Nein, den CE befragt keine Proxys.

 

[el_malto]

@geohei ah ok, dann habe ich es jetzt verstanden. Wusste auch nicht das CE keine Proxys befragen kann.

 

[DarkStarXxX]

Was ihr vielleicht meint ist: allow request

Aber dann ist es auch kein reines CEX mehr, sowas muss allerdings der CEX Partner elauben.

Aber bringt euch auch nicht groß weiter.

 

[geohei]

Habe jetzt einige Tests gefahren.
Box_1, die 3 Proxies und CE-Instanz anfragt, fängt sich die Fakes ein (klar).
Box_2, die nur an der CE-Instanz hängt, bekommt die "sauberen" CWs.
Box_2 hat (fast) keine Freezer mehr.

Zwei Verständnisfragen zu Logeinträgen die mir aufgefallen sind.
(haben nicht miteinander zu tun)

1. CE-Instanz:

Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!

Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!

Wie kann cw count 3 sein wenn 2 als minimum CWs eingestellt ist?

2. User-Instanz

Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!

user1 und cx haben die gleiche Gruppe, und sonst keine (also nur eine Gruppe für user1 und cx). Reader prx1 hat eine andere Gruppe. Meinem Verständnis nach sollte user1 die CWs nur von cx beziehen. Das gewünschte CW ist im cache von oscam da user2 den gleichen Sender zeitgleich hat. Wegen der Gruppeneinteilung sollte aber doch nur cx als Quelle von CWs für user1 benutzt werden, oder? Wenn das nicht so ist (= cache wird trotz Gruppeneinteilung immer benutzt), dann stellt sich die Frage warum cx (erste Zeile im Log) als Quelle vom CW benutzt wird?

 

[DarkStarXxX]

Cache 1/2 kennt keine Gruppenbegrenzung.
Natürlich wird CEX zuerst genommen, weil du mit der Waittime alles Verzögerst.

 

[el_malto]

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

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?

 

[geohei]

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

Aber ... CEX wird nur in der ersten Logzeile benutzt, nicht in der zweiten. Wieso das denn (nichts hat geändert)?

 

[tem_invictus]

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

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.

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

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.

 

[el_malto]

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

Ich verwende kein CEX.

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...?

 

[geohei]

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

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.

Egal ob wait_time erreicht ist oder nicht, cw count sollte nie > sein als cacheex_cw_check.

Wenn hier jetzt mal cw count = cacheex_cw_check +1 steht, nehme ich an (Vermutung meinerseits), dass es sich hier um Timing Fehler (im ms Bereich) zwischen den verschiedenen // laufenden Tasks gibt. Das würde auch erklären warum ich im Log manchmal das Versenden eines CWs sehe welches erst 3 Zeilen später geschickt wird.

Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

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.

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

CEX ist zum pushen von CWs. Hast du nur eine Server- und eine Clientbox macht es wenig Sinn.

 

[tem_invictus]

Zum "cacheex_cw_check", folgendes steht im Streamboard Wiki dazu:

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

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.
Somit kann der CW Count auch deutlich über 2 steigen.

 

[DarkStarXxX]

So isses.