Zu schnelle CWs vom Reader verwerfen

[tem_invictus]

Ich hatte genau das gleiche Problem vor 2 Wochen im Cache, ist dann aber von selber wieder verschwunden.
Lustigerweise ist nicht die Zeit extrem gering, sonder die Anzahl der CWs geht auch nach oben.

cacheex freezer - caid 09C4 - ecm zeit extrem niedrig


@el_malto , leider sind diese "zu schnellen" CWs auch als local generated markiert. Wodurch das erkennen noch schwerer wird.

Spoiler: log

Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

 

[el_malto]

@geohei deine Überlegungen finde ich ganz interessant. Wenn ich das richtig verstanden habe, versuchst du quasi alle ECM Anfragen erstmal zu sammeln, und dann die ECM die am meisten vorkommt zu nehmen (in der Hoffnung das diese dann kein Fake ist). Wenn ich deinen Beitrag dann richtig verstanden habe, könnte man das im Moment ja nur so umsetzen, dass man für jeden Reader eine extra Instanz hat und von den Instanzen dann alles in eine CE Instanz pusht (um dort zu sammeln). In der CE Instanz könnte man so dann mittels "wait_time" (um zu warten bis alle Reader die ECMs gepusht haben) und "cacheex_cw_check" (um dann die ECM zu nehmen die am häufigsten vorkommt) deinen überlegten "Filter" anwenden.
Interessante Idee, leider in der Praxis nur aufwendig umzusetzen da ja mehrere Instanzen nötig sind.

Wäre aber wirklich cool wenn sowas aber vielleicht in OSCam eingepflegt werden könnte. Also eine "wait_time" um -wenn man mehrere Reader hat- erstmal alle Anfragen bis zu einer bestimmten Zeit zu "sammeln" und dann mittels einen neuen Parameter ähnlich wie "cacheex_cw_check" die ECM zu verwenden die am häufigsten vorkommt.
Ich pinge einfach mal ganz dreist @pehedima und @w33dburner . Vielleicht findet ihr die Idee ja auch gar nicht so verkehrt.

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

Dann sieht es wohl so aus, dass man das lg Flag wohl schon mittels MultiCS faken kann.

 

[DarkStarXxX]

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

Das bringt gar nichts weil sich hinter den Proxys die selben Quellen befinden können

 

[el_malto]

@DarkStarXxX ja das habe ich in meinen Tests auch schon raus gefunden. Da hängt wirklich viel zusammen. Vielleicht könnte man das ganze auch umdrehen und dann sagen, nehmen die ECM die am wenigsten vorkommt. So kann man vielleicht die "guten" erwischen.
Klar, ist alles nur spekulation aber finde den Ansatz und die Idee trotzdem sehr interessant.

 

[DarkStarXxX]

Wenn du so eine Unsichere Sache haben willst, dann kannst du auch gleich: ECM Double Check benutzen.

 

[el_malto]

Was soll daran eine unsichere Sache sein? Es werden ja keine ECMs verworfen. Lediglich die ECM mit den meisten "matches" wird benutzt.
Man könnte das auch noch weiter mit einen Parameter "wait_time_per_caid" verfeinern. Man weiß ja wann die verschiedenen CAIDs freezen oder die durchschnittliche ECM time ist. So könnte man für die V13 z.B. wait_time_per_caid = 094C:400 machen und man würde bis 400ms alle ECMs von den Readern sammeltn und dann verglichen und los geschickt. So hätte man noch ca 200ms zum "senden" der ECM bevor die CAID ab ca. 600-650ms freezt.

Dein vorgeschlagener ECM "double_check" würde da nicht viel helfen weil der nur mit activierten Loadbalancer funktioniert. Man will ja nicht nur bestimmte Reader anfragen sondern gnadenlos von allen Readern ECMs anfordern.

 

[DarkStarXxX]

Zum letzten Satz: Solche Leute würden von meinen Share gnadenlos runterfliegen.

Weißt du wieviel unnötige Kartenlast wegen sowas entsteht?

 

[el_malto]

Kann dir da nur bedingt zustimmen.
Wenn der Client nur einen Reader hätte würde eh jede Anfrage zu dir kommen. Wenn der Client mehrere Reader (von verschiedenen Servern) hat, geht jede Anfrage zu allen Readern. Die Kartenlast bei dir bleibt die gleiche. Und wenn Anfragen doppelt kommen sollen (warum ich immer), werden diese eh aus dem Cache beantwortet. Der Client verursacht nur auf seiner Seite mehr traffic. Solange man also verschiedene Reader hat sehe ich da kein Problem.

 

[DarkStarXxX]

Die Kartenlast bleibt eben nicht die gleiche.

Nehmen wir mal an du hast 8x 09C4 über Proxys verteilt.
Dann gehen jetzt für einen einzigen Client 8 Anfragen an diese Proxys.
Bei 8 Clients die verschiedene Sender gucken sind es schon 64 Anfragen.

 

[tecfreak]

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

Dann ist der Loadbalancer aber nicht aktiv und die config damit Mist.

 

[DarkStarXxX]

Statt solche Kruden Sachen zu machen, sollte man sich vielleicht einfach überlegen ob es Sinn macht mit Clients zu tauschen die einen Fakes schicken.
Manchmal ist weniger einfach mehr.

 

[el_malto]

@DarkStarXxX wenn man als Client 8 Proxys hat gehen alle Anfragen an alle Proxys. Wenn man nur einen Proxy hat, nur an einen. Aber durch die 8 Proxys wird die Kartenlast bei jeden einzelnen Proxy selbst doch nicht höher. Da kommt so oder so nur eine Anfrage an.
Selbst wenn man ein "Mittelsmann" ist der Proxys und Clienten hat wird die Kartenlast (nicht der Traffic, der steigt natürlich) der einzelnen Proxys dadurch doch nicht höher. Egal wie viel Proxys du hättest, wenn alle Clients verschiedene Sender gucken muss der einzelne Proxy auch alle Anfragen beantworten. Wenn alle Clienten die gleich Sender gucken werden die ausn Cache beantwortet. Die Kartenlast (nicht Traffic) bleibt also gleich.

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

Ja das ist klar und da stimme ich dir auch zu. Sind ja jetzt auch nur Gedanken oder Ideen die mir durch den Post von @geohei so durch den Kopf gegangen sind da ich diesen interessant finde.

@tecfreak ja die Beispiele sind alle ohne aktiven LB.


Generell wäre das ja auch eher eine "Lösung" für reine Clienten die sich ein paar Lines "besorgt" haben.

 

[DarkStarXxX]

Beispiel:

1. 8x 09C4 (LB) = Anfrage geht an einen Proxy
2. 8X 09C4 (kein LB) = Anfrage geht an alle Proxys

1. 7 Proxys sind frei
2. alle 8 Proxys Dauerhaft (und unnötig in Benutzung)

Mit 2. werden ganz klar Ressourcen verschwendet, was möglichweise zu folge hat das die Karten anderen Sender nicht mehr mit Ausreichenden Zeiten entschlüsseln kann.

Und da immer noch nicht Ausgeschlossen ist das die dahinter stehenden Karten nicht ein und die selben sind, ist nicht mal was gewonnen.
Ist doch im Moment beim Trunk CEX nicht anders, cw count 8 bedeutet nur, dass das CW von 8 Verschiedenen CEX Proxys kam und nicht das es 8 Verschiedene Karten waren die mit diesen CW geantwortet haben, wenn es blöd lief war es genau 1 Karte die das CW in den Schwarm gehauen hat und du denkst jetzt durch den Count es waren 8 Karten und das wird dann schon passen, was aber möglicherweise nicht der Fall ist, weil es es 1 Karte war die das (Fake) CW rausgesendet hat.

Möglicherweise kommen diese CWs nicht mal von echten Karten, sondern irgendein Scherzkeks hat ein Random Generator laufen und beantwortet Anfragen mit solchen Müll CWs, das sind alles Möglichkeiten.

Gibt ja leider genug CWs die Quer durch alle Caids gesendet werden.

 

[el_malto]

Das es mit aktiven LB natürlich anders ist, ist mir auch bewusst und ja auch klar. Deswegen hatte ich es oben ja geschrieben, dass "double_check" da nicht viel helfen würde. Um alle ECMs von allen Readern zu vergleichen müsste man dann auch die Anzahl der Reader in "lb_nbest_readers" angeben. Somit wäre LB quasi ausser Kraft gesetzt und die Anfragen würden wieder an alle Proxys gehen. Dachte es wäre klar das wir hier alles ohne LB betrachten.

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

Da wissen wir ja nun schon das da alles kreuz und quer zusammenhängt.

Wie gesagt, fande ich Idee dahinter recht interessant.

 

[DarkStarXxX]

Sinnvoller wäre es dir Ursache zu bekämpfen, wenn jeder zum Beispiel sein CEX mehr Pflegen würde und hier schon bei sich die Quellen die zum Beispiel mit MCS zusammenhängen entfernen würde, dann wäre das ganze zumindest um einiges Sauberer.

Leider geht es vielen nur darum wer die meiste CEX Size hat.