```html

CCcam Server Reseller Setup: Technischer Leitfaden & Architektur

Wenn Sie verstehen möchten, wie eine cccam server reseller Operation tatsächlich unter der Haube funktioniert — nicht das Marketing-Pitch, sondern die echte Architektur — das ist die Aufschlüsselung, die Sie gesucht haben. Die meisten Inhalte zu diesem Thema sind dünn verschleierte Werbung. Was folgt, ist eine technische Anleitung, wie Reseller-Panels C-Lines verwalten, wie Multi-Hop-Verteilung die ECM-Timing beeinflusst und was eine solide Reseller-Infrastruktur von einer unterscheidet, die um 21 Uhr an einem Samstagabend die Kanäle abbricht.

Bevor wir anfangen: Card-Sharing-Technologie existiert in einer rechtlichen Grauzone, die je nach Gerichtsbarkeit variiert. Verstehen Sie die Gesetze in Ihrem Land, bevor Sie ein Card-Sharing-Setup betreiben oder abonnieren. Nichts hier stellt Rechtsberatung dar.

Was ist ein CCcam Server Reseller System und wie funktioniert es?

Im Kern ist eine CCcam Reseller Operation eine Verteilungsschicht zwischen einer Kartaquelle und Endbenutzern. Die Kartaquelle verwaltet die tatsächliche Conditional Access Entschlüsselung. Alles, was danach kommt, ist nur das effiziente Weiterleiten von ECM-Anfragen und Antworten.

CCcam Architektur: Vom Hauptserver zum Endbenutzer

Der CCcam Daemon läuft auf einem Linux-Server (oder Enigma2-Receiver) und liest seine Konfiguration aus /etc/CCcam.cfg — obwohl dies auf Enigma2-Images oft /var/etc/CCcam.cfg ist. Der Daemon lauscht auf einem konfigurierbaren Port (normalerweise 12000, 19000 oder ein benutzerdefinierter Port) und verwaltet zwei Arten von Verbindungen: Upstream-Kartquellen (C-Lines, zu denen es sich verbindet) und Downstream-Clients (F-Lines, die es bereitstellt).

Eine typische Reseller-Topologie sieht wie folgt aus:

• Hop 0 — Physischer Kartenleser am Kartserver angebracht. Das ist der Ursprung.
• Hop 1 — Hauptserver mit direktem Zugriff auf die Kartaquelle. Reseller verbindet sich hier.
• Hop 2 — Reseller Server, zu dem sich Endbenutzer verbinden.
• Hop 3+ — Sub-Reseller oder zusätzliche Verteilungsschichten. Die ECM-Timing beginnt hier deutlich zu verschlechtern.

Jeder Hop fügt echte Latenz zu ECM-Anfragen hinzu. Unter 300ms ist komfortabel für stabiles Descrambling. Sobald Sie konsistent über 500ms gehen, sehen Sie eingefrorene Bilder und Kanalabbrüche — besonders bei Premium-Sportinhalten, wo sich die Kryptografie schnell ändert.

Die Reseller-Ebene erläutert: Wie C-Lines verteilt werden

Der Reseller interagiert nicht mit der physischen Karte. Sie verbinden sich mit dem Hauptserver über eine C-Line (das ist eine CCcam-Clientverbindung), und ihr eigener Server bedient dann F-Lines für Endbenutzer. Ihre CCcam-Instanz fungiert gleichzeitig als Client (Upstream) und Server (Downstream).

Wenn ein Endbenutzer eine ECM-Anfrage sendet, reist sie die Kette hinauf: Endbenutzer → Reseller Server → Hauptserver → Karte. Das entschlüsselte Kontrollwort kommt den gleichen Weg herunter. Jede Verbindung in dieser Kette fügt Latenz und einen potenziellen Fehlerpunkt hinzu.

```

Unterschied zwischen einem direkten Server und einem Reseller-Panel

Ein direkter Server bedeutet, dass sich Ihre C-Line auf Hop 1 verbindet — Sie sind ein Client desjenigen, der die Karten besitzt. Ein Reseller-Panel ist eine separate Web-Anwendungsschicht, die die Verwaltung der F-Lines auf diesem Server automatisiert. Das Panel selbst verarbeitet keinen CCcam-Protokoll-Verkehr. Es schreibt nur in CCcam.cfg, verwaltet eine Datenbank von Benutzerkonten und signalisiert dem CCcam-Daemon, seine Konfiguration neu zu laden.

Denken Sie es sich so: CCcam verarbeitet das Protokoll, das Panel verarbeitet die Geschäftslogik. Es sind völlig separate Prozesse, die nur über die Konfigurationsdatei und ein Unix-Signal miteinander interagieren.

Wie Multi-Hop-Sharing in Reseller-Ketten funktioniert

CCcam verfolgt die Hop-Anzahl intern und übergibt sie im Protokoll weiter. Wenn Sie Ihre ECM-Statistiken in der Weboberfläche auf Port 16001 überprüfen, sehen Sie die für jede verbundene Karte gemeldete Hop-Anzahl. Wenn Ihr Reseller auf Hop 2 ist, befinden sich Ihre Endbenutzer auf Hop 3 — und dort müssen Sie stoppen. Das Hinzufügen einer Sub-Reseller-Ebene bedeutet Hop 4, was in den meisten Fällen für Live-TV funktionell unbrauchbar ist.

Einige Setups verwenden OScams Cacheex-Funktion, um die effektive Hop-Anzahl zu reduzieren — wir werden das in Abschnitt 5 behandeln. Aber kein Caching behebt eine grundlegend tiefe Verteilungskette.

Technische Komponenten eines CCcam-Reseller-Panels

Das Reseller-Panel ist typischerweise eine PHP-Webanwendung, die von MySQL oder MariaDB unterstützt wird. Es verarbeitet die Kontoerstellung, Kreditverwaltung, Verfallsdurchsetzung und Konfigurationssynchronisierung. Der CCcam-Daemon weiß nicht und interessiert es nicht, dass das Panel existiert — er liest einfach seine Konfigurationsdatei.

Benutzerverwaltung: Erstellen, Verfallen und Sperren von C-Lines

Jeder Endbenutzer entspricht einer F-Line in CCcam.cfg. Wenn ein Reseller einen neuen Benutzer im Panel erstellt, fügt das Panel einen Datensatz in seine Datenbank ein und hängt (oder schreibt um) eine F-Line in die Konfigurationsdatei. Wenn das Abonnement dieses Benutzers abläuft, entfernt das Panel die F-Line und signalisiert ein Reload.

Die Sperrung funktioniert genauso — das Panel entfernt entweder die F-Line oder kommentiert sie aus, abhängig von der Implementierung. Einige Panels behalten abgelaufene Benutzer in der Datenbank für Datensätze, stellen aber sicher, dass sie keine entsprechende F-Line in der aktiven Konfiguration haben.

Verwaiste F-Lines sind ein echtes Problem, wenn eine Datenbankbeschädigung auftritt. Wenn die Datenbank des Panels beschädigt wird, kann es die Verfolgung von Benutzern verlieren, aber ihre F-Lines bleiben in CCcam.cfg auf unbestimmte Zeit erhalten. Diese Konten laufen nie ab, und Sie werden es nicht bemerken, ohne regelmäßig die Konfigurationsdatei gegen die Datenbank zu prüfen.

CCcam.cfg F-Line Auto-Generierung und Konfiguration Reload

Die F-Line-Syntax in CCcam.cfg sieht so aus:

F: username password max_connections 0 0 :0:0:0

Aufschlüsselung: username und password sind die Anmeldedaten. max_connections ist eine Ganzzahl, die definiert, wie viele gleichzeitige Verbindungen dieses Konto haben kann

halten — entscheidend zur Verhinderung von Anmeldedaten-Sharing. Die nachfolgenden 0 0 :0:0:0 Felder steuern, ob der Benutzer mit anderen nachgelagerten Benutzern teilen kann (0 = nein) und CAID/Service-Beschränkungen (0:0:0 = unbeschränkt).

Wenn das Panel eine F-Line generiert, fragt es die Datenbank nach Benutzerparametern ab und schreibt sie aus. Der knifflige Teil ist das Neuladen der Konfiguration. Das Neustarten von CCcam beendet alle aktiven Verbindungen. Der richtige Ansatz ist:

kill -s SIGHUP $(pidof CCcam)

Dies zwingt CCcam, CCcam.cfg neu zu lesen, ohne bestehende Sitzungen zu beenden. Die meisten Panels automatisieren dies nach jeder Konfigurationsänderung. Aber wenn die neu geschriebene F-Line einen Syntaxfehler hat, lehnt CCcam die fehlerhafte Zeile stillschweigend ab und der neue Benutzer kann sich nicht verbinden — während das Panel Erfolg meldet. Validieren Sie immer die F-Line-Syntax, bevor Sie ein Neuladen signalisieren, oder überprüfen Sie sofort nach dem Neuladen das CCcam-Protokoll.

Gutschriftsystem und Sub-Reseller-Ebenen

Das Gutschriftsystem ist die Geschäftslogik-Schicht. Der Hauptadministrator verteilt Gutschriften an Wiederverkäufer. Jede Gutschrift stellt typischerweise einen Benutzermonat dar (oder eine andere vom Administrator definierte Einheit). Wenn ein Wiederverkäufer ein 3-Monats-Konto erstellt, zieht das Panel 3 Gutschriften von seinem Guthaben ab und verzeichnet das Ablaufdatum in der Datenbank.

Sub-Wiederverkäufer funktionieren rekursiv auf die gleiche Weise. Ein Wiederverkäufer kann einen Teil seiner Gutschriften an einen Sub-Wiederverkäufer vergeben, der dann Endbenutzerkonten erstellt. Das Panel verfolgt die vollständige Hierarchie — wer wen erstellt hat, Gutschriftguthaben auf jeder Ebene und insgesamt aktive Verbindungen pro Konto.

Die Datenbank hat typischerweise Tabellen wie: users (Kontodetails, Gutschriften, parent_id), lines (F-Line-Details, Ablaufdatum, Serverzuweisung) und servers (IP, Port, vorgelagerte Anmeldedaten). Diese parent_id-Beziehung ist das, was die kaskadierende Hierarchie ermöglicht.

Panel-Datenbankstruktur und API-Endpunkte

Anspruchsvollere Wiederverkäufer-Panels stellen eine API bereit — üblicherweise REST über HTTP/HTTPS — für programmatische Kontoverwaltung. Ein Wiederverkäufer könnte POST /api/create_user mit JSON-Parametern aufrufen, anstatt die Web-Benutzeroberfläche zu verwenden. Die API schreibt in die gleiche Datenbank und löst das gleiche Neuladen der Konfiguration aus.

Wenn Sie ein Panel-Setup erstellen oder auswerten, ist die API entscheidend für die Integration. Automatisierte Bereitstellungssysteme (für die Handhabung von Zahlungen und sofortiger Kontoerstellung) hängen von einer zuverlässigen API ab. Ein Panel ohne API oder eines, das nur Screen-Scraping-Workarounds bietet, wird bei großem Maßstab Probleme verursachen.

Automatisierung von Konfigurationsreloads ohne Server-Neustart

Über SIGHUP hinaus verwenden einige Setups CCcams integrierte Web-Oberfläche auf Port 16001, um Reloads programmatisch auszulösen — die Oberfläche hat Endpunkte, die über curl aufgerufen werden können. Ein Cron-Job, der alle 5 Minuten läuft, kann Ablaufprüfungen und Reload-Auslöser handhaben, wenn das Panel dies nicht in Echtzeit tut.

Auf Enigma2-Receivern, die als CCcam-Server fungieren (ein weniger häufiges, aber reales Szenario), ist der Konfigurationspfad is typischerweise /var/etc/CCcam.cfg und die Prozessverwaltung ist unterschiedlich — Sie würden das Enigma2-Plugin-System oder ein benutzerdefiniertes Init-Skript verwenden, anstatt Standard-Linux-Prozesssignale zu verwenden.

Server-Infrastruktur und Leistungsüberlegungen

Die Hardwareanforderungen skalieren direkt mit aktiven Verbindungen und ECM-Durchsatz. Der CPU-Verbrauch von CCcam ist pro Verbindung bescheiden, aber die Netzwerk-E/A und der Overhead vieler gleichzeitiger ECM-Anfragen summieren sich schnell auf.

VPS vs. dedizierter Server für Reseller-Operationen

Ein VPS mit 1 vCPU und 1GB RAM kann realistische 50-100 aktive CCcam-Benutzer verarbeiten, wenn das Netzwerk solide ist. Danach treten Sie in Konfliktsituationen ein — besonders bei "burstable" VPS-Instanzen, die die CPU unter anhaltender Last drosseln.

Für 300+ gleichzeitige Benutzer ist ein dedizierter Server oder ein richtig dimensionierter VPS (4+ Kerne, 4GB RAM) mit garantiertem Netzwerkdurchsatz sinnvoller. Die MySQL-Datenbank des Panels ist bei dieser Größenordnung nicht der Engpass — es ist der CCcam-Daemon, der Hunderte von gleichzeitigen Socket-Verbindungen verwaltet und die damit verbundenen Dateideskriptor-Limits. Überprüfen Sie ulimit -n und passen Sie /etc/security/limits.conf an, wenn Sie bei großen Mengen Verbindungsfehler sehen.

Nur-IPv6-VPS-Umgebungen sind hier ein echtes Kopfzerbrechen. CCcams Standardkonfiguration bindet an IPv4. Wenn Ihr VPS nur eine IPv6-Adresse hat (einige Budget-Anbieter tun dies), müssen Sie CCcam explizit so konfigurieren, dass es sich an die IPv6-Adresse bindet, und Endbenutzer, die sich von nur-IPv4-Verbindungen verbinden, benötigen ein NAT64-Gateway oder einen Tunnel. Die meisten Reseller-Setups vermeiden nur-IPv6-Server aus diesem Grund.

ECM-Antwortzeit und Hop-Count-Optimierung

Ziel sind unter 300ms für ECM-Antwort auf den Verbindungen Ihres Resellers. Sie können dies in der CCcam-Weboberfläche unter http://server-ip:16001 im Abschnitt aktive Clients sehen. Jeder Client zeigt ECM-Anzahl und durchschnittliche Antwortzeit.

Auf Enigma2-Receivern zeigt das CCcamInfo-Plugin die Echtzeit-ECM-Antwort pro Kanal. Wenn Sie einen CCcam-Server-Reseller upstream evaluieren, bevor Sie sich festlegen, bitten Sie um eine Testleitung und überprüfen Sie ECM-Zeiten über mehrere Kanäle zu Stoßzeiten — nicht um 3 Uhr morgens, wenn es minimal Last gibt.

Die Mathematik ist einfach: Wenn Ihre upstream-Leitung 180ms bei Hop 1 zeigt, sollten Ihre Endbenutzer bei Hop 2 ungefähr 180ms + die Verarbeitungszeit Ihres Servers + die Netzwerk-RTT zum Endbenutzer sehen. Wenn der upstream bereits bei 350ms liegt, erhalten Ihre Endbenutzer 450ms+ und Sie sind in Schwierigkeiten.

Netzwerk-Latenz, Peering und Server-Standort

Der Server-Standort ist in zwei Richtungen wichtig: Die Nähe zum upstream Card-Server reduziert Ihre eingehende ECM-Latenz, und die Nähe zu Endbenutzern reduziert den finalen Hop. Diese befinden sich oft in Spannung — Sie können nicht immer beide gleichzeitig optimieren.

Generell sollten Sie die Nähe zur upstream-Quelle priorisieren. Die eingehende ECM-Latenz ist normalerweise der dominierende Faktor. Ein Server 10ms von der Card-Quelle entfernt und 40ms von Endbenutzern entfernt wird übertreffen

einen Server bereitstellen, der 5ms von den Endbenutzern entfernt ist, aber 80ms von der Kartenquelle entfernt ist.

Passen Sie auf Cloud-Provider auf, die aggressives Filtern des ausgehenden Datenverkehrs durchführen. Einige blockieren standardmäßig nicht standardisierte Ports mit Sicherheitsgruppenregeln, die nicht als Firewall-Ablehnung angezeigt werden – die Verbindung wird einfach stillschweigend getrennt. Testen Sie immer mit telnet server-ip port oder nc -zv server-ip 12000 von einer externen Maschine aus nach der Einrichtung. iptables-Regeln, die Ihren CCcam-Port blockieren, sind der häufigste Grund, warum ein neues Setup nicht funktioniert, auch wenn CCcam korrekt ausgeführt wird.

Lastverteilung über mehrere CCcam-Instanzen

Für großflächige Operationen ist die Ausführung mehrerer CCcam-Instanzen sinnvoller als die vertikale Skalierung einer einzelnen Instanz. Optionen sind:

• DNS Round-Robin – Mehrere A-Datensätze für denselben Hostnamen zeigen auf verschiedene Server. Einfach, aber ohne Zustandsprüfung. Ein inaktiver Server erhält weiterhin Traffic.
• Mehrere F-Zeilen-Einträge – Endbenutzer erhalten zwei C-Zeilen, die auf verschiedene Server zeigen. Ihr Client versucht beide und verwendet diejenige, die zuerst reagiert.
• OScam als Lastverteilungs-Proxy – OScam akzeptiert CCcam-Verbindungen von Endbenutzern und verteilt ECM-Anforderungen auf mehrere Backend-CCcam-Instanzen. Dies ist der robusteste Ansatz und unterstützt Zustandsprüfungen.

Das Ausführen mehrerer CCcam-Instanzen auf dem gleichen physischen Server mit verschiedenen Ports (z. B. eine auf 12000 für eine Wiederverkäufer-Ebene, eine andere auf 19000 für eine andere) ist ebenfalls gültig. Jede Instanz hat ihre eigene CCcam.cfg-Datei – Sie können diese symlinken oder separat verwalten. Stellen Sie nur sicher, dass die Web-Interface-Ports nicht in Konflikt geraten (jede Instanz benötigt ihren eigenen WEBINFO LISTEN PORT).

Überwachung der Serverintegrität: Protokolle, ECM-Statistiken und Betriebszeit

CCcam protokolliert standardmäßig auf stdout, was Sie über Ihr Init-System erfassen. Bei systemd-Setups gibt Ihnen journalctl -u cccam -f Live-Protokollausgabe. Häufige Muster, auf die Sie achten sollten:

• Wiederholte „ECM timeout"-Meldungen deuten auf Upstream-Latenzprobleme oder Kartenprobleme hin
• „Zu viele Verbindungen von IP" deutet auf Anmeldedatenaustausch durch einen Endbenutzer hin
• Anmeldefehler im Protokoll, die nicht einem bekannten Benutzer entsprechen – mögliches Brute-Force-Probing
• Plötzlicher Rückgang der Anzahl aktiver Clients zu einem bestimmten Zeitpunkt – normalerweise ein Netzwerkproblem oder eine Upstream-Trennung

Das Web-Interface an Port 16001 bietet Ihnen ein Live-Dashboard verbundener Clients, ihrer ECM-Zählungen und Cache-Hit-Raten. Cache-Hits sind ein gutes Zeichen – sie bedeuten, dass das gleiche Steuerwort aus dem Speicher bereitgestellt wird, anstatt es von der Karte neu anzufordern, was die Auslastung und Latenz verringert.

Bewertung eines CCcam-Wiederverkäufer-Setups: Technische Kriterien

Wenn Sie bewerten, ob Sie Leitungen von einem cccam-Server-Wiederverkäufer kaufen möchten oder ein Wiederverkäufer-Unternehmen bewerten, das Sie aufbauen möchten, finden Sie hier die technischen Kriterien, die tatsächlich relevant sind

ter.

Hop-Anzahl und ECM-Antwortzeit-Benchmarks

Hop 1 ist ideal. Hop 2 ist akzeptabel. Hop 3 ist grenzwertig und Sie werden es bemerken. Hop 4+ ist praktisch unbrauchbar für Live-Premium-Inhalte.

Überprüfen Sie die Hop-Anzahl über die CCcam-Weboberfläche (Port 16001) nach dem Verbinden einer Testleitung. Auf Enigma2 zeigen Receiver-Debug-Protokolle auch die Hop-Anzahl. Verlassen Sie sich nicht auf die Aussage eines Anbieters, dass seine Leitungen "Hop 1" sind — überprüfen Sie es selbst. Wenn ein Wiederverkäufer Ihnen nicht erlaubt, die Hop-Anzahl während eines Testzeitraums zu überprüfen, ist das ein Warnsignal.

ECM-Antwort-Benchmarks: unter 200ms ist ausgezeichnet, 200-350ms ist gut, 350-500ms ist akzeptabel, über 500ms ist problematisch. Diese Zahlen setzen voraus, dass Ihr eigenes Netzwerk keine signifikante Latenz hinzufügt.

Server-Verfügbarkeit und Redundanzarchitektur

Ein einzelner Server ohne Failover ist ein Single Point of Failure. Eine gute Wiederverkäufer-Infrastruktur umfasst mindestens einen primären und einen Backup-Server mit automatischem Failover. Aus Endbenutzerperspektive bedeutet dies, zwei C-Leitungen zu erhalten — eine primäre und eine Backup-Leitung — anstelle einer einzelnen Leitung.

Fragen Sie spezifisch, was passiert, wenn der Upstream ausfällt. Hat der Wiederverkäufer mehrere Upstream-Quellen? Wenn ihr einzelner Upstream-Kartserver ausfällt, verlieren alle ihre Benutzer gleichzeitig den Dienst. Redundante Upstream-Verbindungen sind schwieriger zu warten, machen aber einen großen Unterschied in der Zuverlässigkeit.

Sicherheit: Verschlüsselte Verbindungen und Zugriffskontrolle

CCcam verwendet standardmäßig DES-Verschlüsselung auf seiner Protokollebene — besser als nichts, aber DES ist uralt und sollte nach modernen Standards nicht als starke Verschlüsselung betrachtet werden. Für Wiederverkäufer-Setups, die empfindliche Konnektivität verarbeiten, bietet das Tunneln von CCcam-Traffic durch stunnel (mit Terminierung auf Port 443) oder OpenVPN sinnvolle Sicherheit und hilft auch, Firewalls zu umgehen, die nicht-standardisierte Ports blockieren.

Das Wiederverkäufer-Panel selbst muss über HTTPS laufen. Ein Panel auf reinem HTTP setzt Anmeldedaten und Admin-Sitzungen dem Datenfluss aus. Jede seriöse Operation nutzt Let's Encrypt oder Ähnliches — es gibt keine Entschuldigung für reines HTTP im Jahr 2024.

Verbindungslimits pro Benutzer (der max_connections-Parameter in der F-Leitung) sollten für Single-User-Konten immer auf 1 gesetzt werden. Wenn ein Benutzer ständig bei max_connections ist, teilt er Anmeldedaten. Sie können dies in CCcam-Protokollen erkennen, indem Sie auf Verbindungsanfragen von mehreren Quell-IPs unter gleichem Benutzernamen in einem kurzen Zeitfenster achten.

Transparenz der Netzwerktopologie

Ein vertrauenswürdiges Wiederverkäufer-Setup gibt Ihnen genügend Informationen, um zu überprüfen, was Sie erhalten: die tatsächliche Server-IP (nicht einen Proxy-Hostnamen, der überall hin zeigen könnte), die Möglichkeit, die Hop-Anzahl während eines Testzeitraums zu überprüfen, und eine klare Dokumentation des Backup-Server-Arrangements.

Keine Transparenz = keine Verantwortlichkeit. Wenn das Setup eine Black Box ist, bei der Sie einfach eine C-Leitung erhalten und hoffen, das Beste zu hoffen, haben Sie keine Möglichkeit, Probleme zu diagnostizieren oder die Qualitätsansprüche zu überprüfen.

Was Sie vermeiden sollten: Warnsignale beim Wiederverkauf

Verkäufer-Infrastruktur

• 3+ Hop-Leitungen werden als "direkte" Verbindungen verkauft
• Keine Durchsetzung von Verbindungsgrenzen (max_connections nicht gesetzt oder zu hoch gesetzt)
• Panel läuft nur auf HTTP
• Einzelner Server, keine Redundanz oder Backup-Leitungen
• Keine Test-Leitung vor dem Kauf verfügbar
• Zeitzonenkonflikte zwischen Panel und Server, die dazu führen, dass Leitungen zur falschen Zeit ablaufen — ein subtiler Fehler, bei dem der Panel-Server in UTC ist, aber der CCcam-Server in einer anderen Zeitzone, so dass die Ablaufprüfungen um Stunden daneben liegen
• Keine API für automatisierte Bereitstellung (deutet darauf hin, dass der Betrieb zu manuell ist, um zuverlässig zu skalieren)
• Gemeinsame Benutzernamen oder Passwörter über mehrere Konten hinweg (ein Zeichen für nachlässige Bereitstellung)

CCcam vs OScam für Wiederverkäufer-Bereitstellungen

Sowohl CCcam als auch OScam können einen Wiederverkäuferbetrieb durchführen, haben aber bedeutsam unterschiedliche Stärken. Viele Produktionssetups verwenden beide gleichzeitig in einer Hybrid-Konfiguration.

Protokollunterschiede und Kompatibilität

CCcam ist ein Single-Protocol-Daemon — es spricht nur das CCcam-Protokoll. OScam ist Multi-Protokoll: es unterstützt CCcam, newcamd, camd35, radegast und andere. Für einen Wiederverkäufer, der Kunden bedient, die unterschiedliche Receiver-Software verwenden könnten, ist OScams Protokollflexibilität ein echter Vorteil.

Das newcamd-Protokoll verwendet ein anderes Verschlüsselungsschema (DES mit einem statischen Schlüssel, der beim Handshake ausgehandelt wird) und wird von einer breiten Palette älterer Hardware unterstützt. Wenn Ihre Endbenutzer Personen auf Legacy-Hardware einschließen, ist die newcamd-Unterstützung über OScam wichtig.

OScam als Proxy vor CCcam

Eine häufige Produktionsarchitektur: OScam läuft auf dem Wiederverkäufer-Server und akzeptiert CCcam-Protokollverbindungen von Endbenutzern. OScams Reader-Definition (in /etc/oscam/oscam.server) verbindet sich mit dem CCcam-Upstream-Server unter Verwendung eines CCcam-Reader-Typs. Endbenutzer verbinden sich mit OScam und denken, dass sie mit CCcam sprechen — das Protokoll ist aus ihrer Perspektive identisch.

Die OScam-Konfiguration für diese Art von Setup sieht wie folgt aus:

# /etc/oscam/oscam.server
[reader]
label = upstream_cccam
protocol = cccam
device = upstream-server-ip,12000
user = reseller_username
password = reseller_password
cccversion = 2.3.0
cccmaxhops = 2

Und in /etc/oscam/oscam.user definieren Sie Endbenutzer mit benutzerabhängiger CAID-Filterung, Verbindungsgrenzen und Dienstbeschränkungen, die viel differenzierter sind als die F-Line-Syntax von CCcam:

[account]
user = enduser1
pwd = userpassword
uniq = 1
maxconn = 1
caid = 0500,1800

Diese uniq = 1-Einstellung erzwingt Eindeutigkeit — nur eine Verbindung pro Konto, wobei die neueste Verbindung die alte ersetzt. Viel sauberer zur Verhinderung der Anmeldedatenfreigabe als CCcams grundlegendes Verbindungszählen.

Unterschiede in der Benutzerverwaltung

CCcams Benutzerverwaltung ist im Wesentlichen eine flache Textdatei mit F-Lines. Sie funktioniert, aber das Verwalten von Hunderten von Benutzern bedeutet, Hunderte von

f F-lines in einer Datei. OScam verwendet separate Konfigurationsdateien pro Benutzertyp, und seine Weboberfläche bietet viel bessere benutzerspezifische Überwachung — Sie können genau sehen, was jeder Benutzer anfordert, ihre ECM-Erfolgsquote und ihre Verbindungsverlauf.

OScams cacheex-Funktion verdient besondere Erwähnung. Der Cache-Austausch ermöglicht es mehreren OScam-Instanzen, ihren ECM-Response-Cache miteinander zu teilen. In einem Reseller-Szenario mit vielen Benutzern, die die gleichen Kanäle ansehen, bedeutet cacheex, dass die zweite ECM-Anfrage für ein bestimmtes Steuerwort den Cache trifft, anstatt die ganze Strecke zur Karte zu gehen. Dies reduziert die Upstream-Last und kann die Antwortzeiten für beliebte Kanäle effektiv verbessern.

Wann man jede verwenden sollte (oder beide zusammen)

CCcam allein: geeignet für kleine Operationen unter 50 Benutzern, einfache Konfiguration, weit verbreitet kompatibel mit Benutzer-Receivern. Das Panel-basierte CCcam-Server-Reseller-Setup ist in diesem Maßstab einfach zu erstellen und zu warten.

OScam allein: besser für mittlere bis große Operationen, bei denen Sie benutzerspezifische CAID-Filterung, Multi-Protokoll-Unterstützung oder cacheex-Vorteile benötigen. Komplexer korrekt zu konfigurieren, aber viel leistungsstarker.

Beide zusammen: OScam als der Benutzer zugewandte Server (Behandlung von Endbenutzerverbindungen, Anwendung von Richtlinien, ECM-Caching) mit CCcam oder einer anderen OScam-Instanz als Upstream-Backend. Diese Architektur erhöht die Komplexität, bietet Ihnen aber das Beste aus beiden: CCcams Kompatibilität und OScams Kontrolle. Die meisten ernsthaften Reseller-Operationen landen hier schließlich, wenn sie skaliert werden.

Der Konfigurationspfad zum Merken: OScams Hauptkonfiguration ist /etc/oscam/oscam.conf, Serverdefinitionen gehen in /etc/oscam/oscam.server und Benutzerkonten in /etc/oscam/oscam.user. OScams Weboberfläche läuft standardmäßig auf Port 8888 und ist wesentlich informativer als CCcams Port-16001-Oberfläche.

```