AW: Diskussionsthread zum How-To Filtermöglichkeiten in OScam
Ich hätte da noch ergänzend einen Punkt zu den ganzen Filter-Regeln.
Oscam Filter - weniger ist meist mehr!
Wir haben nun die Möglichkeit unsere Filter auf die verschiedensten Arten zu definieren bzw. dies sogar an mehreren Stellen zu tun. Oft werden diese Filter jedoch unnötigerweise mehrfach definiert, was selten einen Sinn ergibt und oscam nur unnötigt beschäftigt. Dadurch nimmt jedes ECM-Request mehr Rechenzeit/Systemresourcen in Anspruch und benötigt je nach System und dessen Auslastung ein wenig mehr an Zeit um verarbeitet zu werden.
Grundsätzlich haben wir zwei Stellen an denen wir filtern können - bei den Readern (oscam.server) und bei den User-Accounts (oscam.user).
1. Bei physischen Readern (locals) weiß oscam bereits welche CAID und ProviderID dieser Reader bedient da es diese Info von der Smartcard selbst bekommt. CAID oder Ident (CAID+ProviderID) in der Reader Konfiguration zu definieren macht deshalb in den allermeisten Fällen keinen Sinn bzw. ist einfach unnötig.
Sind am Reader auch noch positive Services definiert (samt CAID und ProviderID falls nötig), so kann man sich die Angabe der CAID oder Ident erst recht sparen und das gilt in dem Fall auch für Proxy-Reader.
2. Sonderfall Proxy-Reader:
Bei Readern welche das cccam Protokoll nutzen erhalten wir von der Gegenseite eine share-list übermittelt in der die einzelnen Smartcards mit der Angabe von CAID und ProviderID und, je nach cccam-server (gilt ab cccam 2.2.0 und bei cccam-ext) der Gegenseite und dessen Konfiguration, auch die positiven und negativen Services gelistet sind. Hier setzen wir nur dann Filter, wenn wir bestimmte Smartcards der Gegenseite in unseren eigenen share nicht aufnehmen möchten oder wir wissen, dass eine bestimmte Smartcard nicht alle Services bedient (kein Vollabo) und wir Anfragen verhinder möchten die eh nicht beantwortet/verarbeitet werden können.
3. Für andere Protokolle ist die Angabe von CAID(s) und ggf. ProviderID(s) empfehlenswert bzw. besser gesagt zwingend. Sonst würde oscam in dem Fall seine Anfragen einfach "auf Verdacht" losschicken.
4. Filter welche wir bei den Readern definiert haben müssen nicht nocheinmal beim User definiert werden, außer wir wollen weiter einschränken als es schon durch die Reader-Filter geschieht.
Werden z.B. die Services bei den Readern bereits korrekt gefiltert/behandelt, dann müssen wir dies bei den Usern nur dann machen, wenn weitere Beschränkungen nötig sind und ein bestimmter User z.B. bestimmte Services oder Smartcards (CAIDs) nicht nutzen darf.
5. Bei services müssen wir uns überlegen was mehr Sinn macht - negative oder positive services definieren bzw. ob das denn überhaupt nötig ist.
Bei Sky z.B. haben wir neben den dauerhaft gebuchten Sendern auch noch PPV Sender. Da ist es sinnvoller und vor allem resourcenschonender nur die Sender als negative Services zu definieren, welche von unserer Smartcard nicht bedient werden. So erhalten wir einen recht kurzen Filter die oscam bei jeder Anfrage abarbeiten muss. Bei Verwendung von positiven services müsste oscam dagegen jedesmal eine weitaus längere Liste abarbeiten und das muss nicht sein. Dabei muss man aber bedenken, dass auch ORF auf die Sky Smartcards buchbar ist und wir in dem Fall auch diese Sender in die negative Service-Liste mit aufnehmen sollten.
Beispiel:
Sky # (Alle Services des Vollabos)
!Sky # (Sky PPV + ORF)
6. ECM length/header Whitelist benötigen wir nur wenn irgend ein Client uns ungültige ECMs schickt die meist die falsche Länger oder einen falschen Header haben. Bei reinem homesharing wäre das z.B. total sinnfrei.
7. Der loadbalancer, wenn aktiviert, ist an sich ein selbst lernender Filter und verhindert, dass Anfragen ständig zu Readern geschickt werden welche von diesen nicht beantwortet werden. Definierte Services hebeln diese Funktion an dieser Stelle für die jeweiligen Reader aus.
8. Kombinationen von CAID, Ident und positiven Services sind unnötig. Haben wir z.B. positive Services definiert die nebst den einzelnen Services CAID und ProviderID enthalten, dann können wir uns die zusätzliche Angabe von CAID und Ident sparen. Bei Ident (Kombi aus CAID und ProviderID) erübrigt sich auch die zusätzliche Angabe der CAID.
9. Weitere und spezielle Filtermöglichkeiten wären noch die cccam-hops zu erwähnen. Diese sind ein Sonderfall, denn sie können teils sogar gleich an drei Stellen definiert werden (oscam.conf, oscam.server, oscam.user).
Die Verwendung von Groups sowie der EMM-Filter muss man an dieser Stelle denke ich mal nicht erläutern. Zu Groups sein nur soviel gesagt, dass sowohl Reader als auch User "Mitglieder" einzelner Gruppen sein können. Ob man nun jeden Reader einer Gruppe zuweist und den User den Zugriff auf die einzelnen Gruppen erlaubt oder dies umgekehrt macht ist Geschmacksache.