AW: Laberthread für aktuelle und nicht aktuelle OScam Versionen
Wo ich Dich grad an der Strippe
habe, kann ich ja mal ein paar der ausstehenden und m.E. entscheidenden Neuerungen sagen:
Korrekturen:
- Fallback von IPv6 auf IPv4 bei "no route to host"
- ggf. generell Fallback von IPv6 auf IPv4, wenn keine öffentliche IPv6 vorhanden ist, fd00::/8 ist jedenfalls nicht öffentlich und trotzdem versucht oscam dann, IPv6-taugliche Server per IPv6 zu kontaktieren und das ohne Fallback ...
- die Felder für Idents bei den Readern sind zu kurz dimensioniert
Würde z.B. abgeschnitten, dabei ist das weniger als man denkt:
HD01/HD02, alle Sky DE, alle ORF/AustriaSat, SRF, Sky UK, Canal Digitaal, die gängigen XXX sowie etwas Kram auf 23,5°O
Vielleicht kann man manches kürzen, aber dann kommt Sky IT dazu und schon reicht es wieder nicht ...
Ich habe mir diese Ident-Liste mal zusammengestellt, um von allen Proxies allen Schrott auszufiltern, den ich nicht brauche (Manche erschlagen einen mit Tonnen von nutzlosem Kram).
Durch das zu kurze Ident-Feld muß ich die Ident-Liste nun an jeden Proxy einzeln anpassen, indem ich die Idents einspare, die er absolut nicht hat, damit ich hinten die wieder dazunehmen kann, die er hat, aber durch das Abschneiden gefiltert werden.
- Obwohl die von irgendwelchen Servern dazuerfundene CAID:Ident 0500:000000 nirgendwo in o.g. Liste auftaucht wird sie doch immer wieder importiert und zwar dann, wenn eine der gewünschten 0500-Idents auf demselben Share eingetragen ist wie die 0500:000000.
Irgendwas muß man doch tun können, um diese Rotz-Ident quitt zu werden, denn irgendwelche Müll-Clients fragen die auch munter ab.
Features:
Es muß doch irgendwie möglich sein, die ECM
Header Whitelist auch irgendwie zentral abarbeiten zu können.
Momentan muß ich sie für jeden Reader einzelne eintragen und pflegen und vor allem werde ich so keine Schrottanfragen der Clients los, sondern reiche sie nur nicht an Reader/Proxies weiter.
Wenn die Header Whitelist mit in die oscam.whitelist eingepflegt würde, könnte man den Schrott gleich als invalid abbügeln und müßte nur noch eine Stelle pflegen.
D: in oscam.dvbapi ist irgendwie obskur:
Es wird nirgendwo dokumentiert, z.B. ob die Verzögerung
auf oder
um den eingestellten Wert erfolgt.
Es macht aber einen Unterschied, ob
D: 0500 150
die binnen 80 ms reinkommenden Antworten
auf 150ms oder auf 230ms (also
um 150ms) verzögert ...
M.E. macht D: nur als "delay
auf xxx ms" Sinn, denn bei jedem Cryptosystem will man ja nicht über die obere Freeze-Grenze hinaus verzögern, sondern immer nur über die untere ...
Und nach meiner Beobachtung funktioniert
D: CAID Verzögerung
gar nicht.
Egal was ich da einstelle, ich habe noch nie eine Verzögerung im Log gefunden, auch nicht im höchsten Log-Level und wenn S02-Antworten binnen 150ms aufschlagen und 500ms delay eingestellt sind.
Problem: Ich kriege teilweise schon nach 0ms Antworten aus dem Cache ...
Ich kann zwar oscam die Antworten auf einen Wert x verzögern lassen, aber nur allgemein und nicht nach CAID getrennt.
Also kann ich nicht wesentlich über die 150ms hinausgehen die da derzeit eingestellt sind damit z.B. 098E nicht freezt, aber bei 150ms freezt S02 immer noch, weil die Antworten zu schnell sind.
Außerdem würde es Sinn machen, diese Verzögerung für jeden Client getrennt einstellen zu können.
Ein zentraler Wert funktioniert hier (Im Gegensatz zur header whitelist) nicht wirklich gut, denn meine lokalen Clients bräuchten logischer Weise einen viel höhere Verzögerung als irgendwelche Clients mit UMTS-Anbindung oder fremde Server ...
Es kann auch nicht jeder Client selber verzögern, z.B. vPlug nicht.
Ein Wert für alle ist also immer ein Kompromiss zwischen "die lokalen Clients freezen beim langsamsten Cryptosystem (z.B. S02) so
gerade eben nicht mehr wegen zu schneller Antwort" und "die am langsamsten angebundenen Clients freezen beim schnellsten Cryptosystem (z.B. V23) so gerade eben nicht mehr wegen zu später Antwort", vor allem weil man nicht nach CAIDs unterscheiden kann.
Bei per CAID/User-Konfiguration könnten entfernte User haarscharf (10ms) unter der unteren Freezegrenze eingestellt werden (Dann kriegen diese die Antworten mit Latenz trotzdem frühestens genau passend), lokale Clients genau auf die untere Freeze-Grenze und andere Server ohne Verzögerung (Die müssen sich dann selber drum kümmern, aber Verzögerungsfreiheit hilft hier beim Weiterverteilen).
