CCcam Bedeutung: Protokoll, Architektur & Funktionsweise

Wenn Sie sich durch Forum-Threads, Enigma2-Receiver-Menüs oder Konfigurationsdateien wühlen und immer wieder auf den Begriff "CCcam" stoßen, ohne eine klare Erklärung zu finden, sind Sie nicht allein. Die Bedeutung von CCcam verwirrt viele Menschen, weil das Wort gleichzeitig auf zwei überlappende Dinge verweist — auf eine bestimmte Software und auf das proprietäre Protokoll, das diese Software eingeführt hat. Diese Unterscheidung zu klären, bevor Sie eine Konfigurationsdatei anfassen, spart Ihnen Stunden Fehlersuche.

Dieser Artikel erklärt genau, was CCcam im Inneren ist: wie das Protokoll funktioniert, wie die Konfigurationsdateien aussehen, wie es zu OScam steht, und was tatsächlich passiert, wenn eine Leitung abbricht oder ein Kanal nicht dekodiert werden kann.

Was CCcam bedeutet: Definition und Ursprung

CCcam ist ein Linux-basierter Daemon, der ursprünglich für DVB-Satellitenreceiver geschrieben wurde. Im Kern ermöglicht er es einem Gerät mit einer physischen Smartcard, die Dekodierungsfunktionen dieser Karte mit mehreren Clients über eine TCP-Netzwerkverbindung zu teilen. Das Protokoll, das es dazu verwendet, wird auch CCcam genannt — hier beginnt die Verwirung.

Die Namenerklärung: Wofür "CCcam" steht

Es gibt keine offizielle, veröffentlichte Erklärung des Namens von den ursprünglichen Entwicklern. Die allgemein akzeptierte Interpretation ist Card Client CAM — wobei "CC" für Card Client steht und "CAM" sich auf Conditional Access Module-Emulation bezieht. Diese Namensgebung ergibt funktional Sinn: Die Software emuliert, was ein physisches CAM tun würde, aber über ein Netzwerk.

Einige ältere Forum-Beiträge deuten darauf hin, dass "CC" für "CryptoCam" stehen könnte oder die Initialen des ursprünglichen Autors referenzieren könnten, aber nichts wurde offiziell bestätigt. Die Card Client CAM-Interpretation ist diejenige, die in der Community haften blieb und mit dem tatsächlichen Verhalten der Software übereinstimmt.

Ursprung und Entwicklungsgeschichte des Protokolls

CCcam entstand Mitte der 2000er Jahre als Alternative zu älteren Sharing-Lösungen wie Newcamd. Es wurde speziell für Linux-basierte DVB-Receiver entwickelt — die Art, die auf Dreambox und ähnlicher Enigma2-Hardware läuft. Die Software durchlief mehrere größere Versionszweige: 2.0.x, 2.1.x, 2.2.x und 2.3.x, von denen jede Funktionen wie verbesserte CAID-Filterung, Reshare-Kontrolle und besseres Protokoll-Handshaking hinzufügte.

Die Entwicklung stagnierte irgendwo um die 2.3.x-Serie. Die letzte weit verbreitete Binärdatei ist CCcam 2.3.0, das Jahre zurückliegt. Seitdem hat OScam die Rolle der aktiv gepflegten Alternative übernommen, obwohl das CCcam-Protokoll selbst noch immer intensiv genutzt wird, weil so viele Clients und Server darauf aufgebaut wurden.

CCcam als Software vs. CCcam als Protokoll

Dies ist die Unterscheidung, die die meisten Menschen übersehen. Wenn jemand sagt "Ich führe CCcam aus," meint er möglicherweise den tatsächlichen CCcam-Daemon-Binär — die auf seinem Receiver oder Server installierte Software. Aber wenn jemand über "CCcam-Protokoll" spricht, meint er das proprietäre TCP-basierte Kommunikationsformat, das

t der Software eingeführt.

Das Protokoll ist kein offener Standard. Es gibt keine RFC, kein öffentliches Spezifikationsdokument. Was wir darüber wissen, stammt aus Reverse Engineering und Community-Dokumentation. OScam konnte die CCcam-Protokollunterstützung genau deshalb implementieren, weil die Community genug davon reverse-engineert hatte, um eine kompatible Implementierung zu schreiben. Die beiden Dinge — Software und Protokoll — teilen sich einen Namen, und das ist eine ständige Quelle der Verwirrung für jeden, der neu im Ökosystem ist.

Wie das CCcam-Protokoll technisch funktioniert

Auf der Netzwerkebene ist CCcam ein TCP-basiertes Client-Server-Protokoll. Der Server hält eine echte physische Smartcard — entweder in einem CAM-Modul, einem CI-Slot oder einem direkt angeschlossenen Kartenleser an der Hardware. Wenn ein Client einen Kanal entschlüsseln muss, sendet er eine ECM (Entitlement Control Message) an den Server. Der Server leitet diese ECM an die physische Karte weiter, erhält das entschlüsselte CW (Control Word) zurück und sendet dieses CW an den Client zurück. Die ganze Hin- und Rückfahrt muss schnell genug stattfinden — innerhalb des Schlüsselrotationsintervalls des Kanals — oder das Bild friert ein.

Client-Server-Architektur: C-Linien und N-Linien erklärt

Die primäre Möglichkeit, eine CCcam-Client-Verbindung zu konfigurieren, ist eine C-Linie. Das Format ist unkompliziert:

C: hostname port benutzername passwort

Ein tatsächlicher Eintrag sieht also so aus:

C: myserver.example.com 12000 myuser mypassword

Diese Zeile befindet sich in /etc/CCcam.cfg auf Ihrem Receiver oder Client-Gerät. Sie teilt dem CCcam-Daemon mit, wo er sich verbinden soll, welche Anmeldedaten verwendet werden sollen, und impliziert, welcher Port zu verwenden ist. Sie können mehrere C-Linien haben, die auf verschiedene Server verweisen, und CCcam verwendet die erste verfügbare.

N-Linien sind für Newcamd-Peers — ein anderes, aber verwandtes Protokoll. Wenn Sie einen CCcam-Server mit einem Newcamd-Server verbinden, würden Sie eine N-Linie in der Konfiguration verwenden. N-Linien folgen diesem Format:

N: hostname port benutzername passwort 01 02 03 04 05 06 07 08 09 10 11 12 13 14

Die Hex-Zeichenfolge am Ende ist der Newcamd-DES-Schlüssel. Die meisten Leute kopieren dies aus der Konfiguration ihres Anbieters und müssen ihn nicht manuell konstruieren, aber es ist wichtig zu wissen, was er ist, wenn eine Verbindung fehlschlägt.

Die Rolle von Control Words (CW) bei der Entschlüsselung

Ein Control Word ist ein 8-Byte-Schlüssel, den der Descrambler Ihres Receivers verwendet, um den Videostrom in Echtzeit zu entschlüsseln. Rundfunkanstalten rotieren CWs alle wenige Sekunden (typischerweise alle 10 Sekunden, obwohl einige Dienste schneller rotieren). Jedes Mal, wenn sich das CW ändert, muss Ihr Client das neue abrufen, bevor das alte abläuft — andernfalls friert das Bild ein oder wird schwarz.

Deshalb ist die ECM-Antwortzeit so wichtig. Wenn Ihr Server 800ms braucht, um ein CW zurückzugeben, und das Rotationsintervall 10 Sekunden beträgt, sind Sie wahrscheinlich in Ordnung. Aber wenn die Antwortzeit auf 2000ms ansteigt oder der Server langsam ist, erhalten Sie Einfrierungen genau an der Schlüsselrotationsgrenze. Das CW i

selbst wird niemals langfristig gespeichert — es ist von Natur aus kurzlebig.

TCP Port 12000: Der Standard-CCcam-Kommunikationsport

CCcam lauscht standardmäßig auf TCP-Port 12000 auf eingehende Client-Verbindungen. Dies wird in /etc/CCcam.cfg über die Direktive PORT gesetzt:

PORT 12000

Wenn Ihr ISP Port 12000 blockiert — was einige tun, besonders in Regionen, wo Satellitenfreigaben aktiv eingeschränkt werden — können Sie ihn auf jeden anderen verfügbaren Port verschieben. Ports wie 8080, 4444 oder sogar 443 werden manchmal verwendet, um Filterung zu umgehen. Stellen Sie nur sicher, dass Ihre C-Line auf der Client-Seite die entsprechende Portnummer verwendet.

Die Web-Info-Schnittstelle läuft standardmäßig separat auf Port 16001. Sie greifen darauf unter http://serverip:16001 zu und sehen verbundene Clients, Share-Listen, ECM-Antwortzeiten und den aktuellen Kartenstatus. Dies ist Ihr primäres Diagnosetool — wenn etwas nicht stimmt, sagt Ihnen diese Seite normalerweise, was los ist.

Hop-Anzahl und Share-Entfernung in CCcam-Netzwerken

Die Hop-Anzahl ist eines der wichtigsten und am wenigsten erklärten Konzepte in CCcam-Netzwerken. Wenn ein CCcam-Server seine Karte an einen Client freigibt, kann dieser Client sie möglicherweise an einen anderen Client weitergeben — was bei jedem Hop eins hinzufügt. Eine Hop-Anzahl von 0 bedeutet, dass Sie direkt mit der physischen Karte verbunden sind. Eine Hop-Anzahl von 1 bedeutet, dass es einen Server zwischen Ihnen und der Karte gibt. Hop-Anzahl 2 bedeutet zwei Zwischenserver.

Jeder Hop addiert Latenz zur ECM-Antwort. In einem gut konfigurierten Netzwerk mit schnellen Servern könnte sogar Hop 2 akzeptabel sein. Aber in der Praxis neigt alles über Hop 3 hinaus zu instabiler Dekodierung. Serverbetreiber kontrollieren dies mit der Direktive RESHARE — RESHARE 1 bedeutet, dass Clients bis zu 1 Hop von der Karte weitergeben können, und so weiter.

Wie sich CCcam von Newcamd- und CS378x-Protokollen unterscheidet

Newcamd ist ein älteres Card-Sharing-Protokoll, das CCcam vorausgeht. Es verwendet standardmäßig Port 14000, verwendet N-Lines für die Konfiguration und verwendet einen DES-basierten Handshake für die Authentifizierung. Es unterstützt nicht nativ das auf Hops basierende Weitergabemodell, das CCcam einführte.

CS378x ist der Protokollmodulname, den OScam verwendet, um die CCcam-Serverfunktionalität zu emulieren. Wenn Sie [cs378x] in der OScam-Konfiguration aktivieren, weisen Sie OScam an, das CCcam-Protokoll für eingehende Client-Verbindungen zu sprechen. Aus Sicht des Clients sieht es wie ein nativer CCcam-Server aus. Der Name „cs378x" stammt aus OScams interner Modulbenennung — er hat nichts mit einem anderen Drahtprotokoll zu tun. Es IST CCcam-Protokoll, implementiert in OScam.

CCcam-Konfigurationsdateien und wichtige Parameter

Auf den meisten Linux-basierten DVB-Systemen, auf denen Enigma2 läuft — Dreambox, VU+, Zgemma und ähnliche Hardware — liest der CCcam-Daemon seine Konfiguration aus /etc/CCcam.cfg. Die Datei ist reiner Text, bei den meisten Direktiven Groß- und Kleinschreibung beachtet, und ignoriert stillschweigend Zeilen, die nicht analysiert werden können. Dieser letzte Punkt verursacht echte Kopfschmerzen.

CCcam.cfg

```html Speicherort und Dateistruktur

Der Standardpfad ist /etc/CCcam.cfg. Einige Enigma2-Images legen diese Datei anderswo ab – überprüfen Sie /var/etc/CCcam.cfg, falls der Standard nicht existiert. Die Log-Datei wird normalerweise auf eingebetteten Systemen, wo /tmp im RAM liegt, in /tmp/CCcam.log geschrieben, oder auf Systemen mit persistentem Speicher in /var/log/CCcam.log.

Ein häufiges Problem, das viel Zeit kostet: Wenn Sie CCcam.cfg auf einem Windows-Computer bearbeiten und auf Ihren Linux-Receiver übertragen, führen die Windows-Zeilenumbrüche (CRLF – Carriage Return + Line Feed) dazu, dass CCcam Direktiven nicht korrekt analysiert. Die Lösung besteht darin, nach der Übertragung dos2unix /etc/CCcam.cfg auszuführen oder die Datei direkt auf dem Receiver via SSH zu bearbeiten.

SERVER-, SHARE- und CLIENT-Direktiven

Hier ist eine minimale funktionierende CCcam.cfg mit den wichtigsten Direktiven:

# Listening Port für eingehende Client-Verbindungen
PORT 12000
# HTTP-Infoseite Port
HTTPPORT 16001
# Ausgehende Verbindung zu vorgelagertem Server
C: upstream.example.com 12000 myuser mypassword
# Definieren Sie einen lokalen Client, der sich verbinden darf
CLIENT 192.168.1.50 clientuser clientpassword
# Reshare-Level (wie viele Hops Clients weitergeben können)
RESHARE 1
# Log-Level
LOGLEVEL 5

Eine häufige Verwirrung: Menschen verwechseln C:-Zeilen (ausgehende Verbindungen zu einem Server, dessen Client Sie sind) mit CLIENT-Zeilen (eingehende Verbindungen von Benutzern, die Ihre Clients sind). Sie tun das Gegenteil. Eine C:-Zeile sagt „Verbinde mich mit diesem vorgelagerten Server." Eine CLIENT-Zeile sagt „Erlauben Sie diesem Benutzer, sich als Client mit mir zu verbinden."

Verstehen von SID, CAID und Provider-ID-Filterung

CCcam ermöglicht das Filtern auf mehreren Ebenen. CAID (Conditional Access ID) identifiziert das Verschlüsselungssystem – zum Beispiel verwendet Nagravision CAID 0x1800, Viaccess verwendet 0x0500, Irdeto verwendet 0x0600. SID ist die Service-ID für bestimmte Kanäle. Provider-ID ist eine Unterkennung innerhalb eines CA-Systems.

Sie können CAID-Filterung zu CLIENT-Zeilen hinzufügen, um einzuschränken, welche Kanäle ein bestimmter Client entschlüsseln kann. Dies ist nützlich, wenn Sie ein Multi-User-Setup betreiben und den Zugriff auf bestimmte Pakete begrenzen möchten. Die Syntax variiert leicht zwischen CCcam-Versionen – überprüfen Sie die Kommentare in der Sample-Konfiguration Ihrer spezifischen Version.

Log-Dateipfade und Debug-Ausgabe

Setzen Sie LOGLEVEL 8, um bei der Fehlerbehebung ausführliche Ausgaben zu erhalten. Das Log zeigt Verbindungsversuche, ECM-Anfrageergebnisse und Fehlermeldungen wie „Card nicht gefunden" oder „nicht erlaubt" – diese deuten direkt auf die Fehlerursache hin. Sobald alles funktioniert, reduzieren Sie es auf LOGLEVEL 5 oder niedriger, um zu vermeiden, dass Ihr RAM oder Datenträger überläuft.

Auf Enigma2-Boxen geht das Log oft zu /tmp/CCcam.log. Verfolgen Sie es live mit: tail -f /tmp/CCcam.log

CCcam vs OScam: Wann Sie welche verwenden

Die CCcam-Entwicklung stoppte vor Jahren. Die letzte weit verbreitete ```version (2.3.0) hat lange Zeit keine Updates erhalten, und es gibt kein aktives Entwicklungsteam, das es pflegt. OScam hingegen wird aktiv gepflegt mit regelmäßigen Commits, breiterer Hardware-Unterstützung und einem viel flexibleren Konfigurationssystem. Für die meisten modernen Setups ist OScam die bessere Wahl auf der Serverseite.

Warum OScam CCcam in den meisten modernen Setups ersetzt hat

OScam läuft auf der gleichen Enigma2-Hardware, unterstützt weit mehr Reader-Typen, verarbeitet mehrere Protokolle gleichzeitig und verfügt über eine ordnungsgemäße Weboberfläche auf Port 8888 als Standard. Es verwaltet auch Anti-Cascading-Funktionen, detailliertes ECM-Logging und granulare Benutzerverwaltung, die CCcams statische Konfigurationsdatei nicht bieten kann. Bei allem, das in den letzten Jahren gebaut wurde, gibt es wenig Grund, native CCcam-Serversoftware auszuführen.

Aber — und das ist der Schlüsselpunkt — das CCcam-Protokoll ist nicht tot. Viele Clients sprechen nur CCcam. Ihre alte Dreambox, Ihr billiger Android-Receiver, das Setup eines Freundes, das noch auf Firmware von 2010 läuft — diese unterstützen möglicherweise nur C-Line-Verbindungen. Also selbst wenn Sie OScam als Ihren Server betreiben, müssen Sie möglicherweise CCcam-Protokollverbindungen akzeptieren.

OScams CCcam-Emulationsmodus (cs378x und cccam-Protokoll-Reader)

OScam verwaltet CCcam in zwei Richtungen. Zuerst als Server: aktivieren Sie den [cs378x]-Abschnitt in /etc/oscam/oscam.conf:

[cs378x]
port = 12000
version = 2.3.0
reshare = 1

Dies bewirkt, dass OScam eingehende CCcam-Clientverbindungen auf Port 12000 akzeptiert und natives CCcam-Protokoll spricht. Aus Sicht eines verbindenden Clients ist es von einem echten CCcam-Server nicht zu unterscheiden.

Zweitens als Client-Reader: Falls Ihr OScam-Box sich mit einem vorgelagerten CCcam-Server verbinden muss, fügen Sie einen Reader in /etc/oscam/oscam.server hinzu:

[reader]
label = upstream_cccam
protocol = cccam
device = upstream.example.com,12000
user = myuser
password = mypassword
caid = 1800

Eine Sache, die Menschen überrascht: Falls OScam ohne das cs378x-Modul kompiliert wurde, erhalten Sie eine Verbindung verweigert auf Port 12000 auch mit korrekter Konfiguration. Überprüfen Sie, ob Ihr OScam-Build cs378x enthält, indem Sie oscam --build-info oder das Äquivalent für Ihr Image ausführen. Dies ist ein häufiges Problem bei einigen Enigma2-Images, die ausgedünnte OScam-Builds ausliefern.

Szenarien, in denen native CCcam-Software noch verwendet wird

Native CCcam tritt in einigen Situationen noch auf. Einige ältere Dreambox-Boxen und Images führen es aus, weil die Konfiguration für einfache Setups einfacher ist. Einige Benutzer haben bestehende Configs, die sie nicht migrieren möchten. Und in einigen Fällen ist ein sehr einfacher Single-Card-Server mit einer Handvoll Clients tatsächlich einfacher zu verwalten mit CCcams flacher Konfigurationsdatei als OScams Multi-File-Setup.

Interoperabilität: Verbindung von CCcam-Clients mit OScam-Servern

Mit aktivem OScam-cs378x-Modul verbindet sich ein Standard-CCcam-Client, der eine C-Line verwendet, ohne Änderungen. Der Handshake ist kompatibel. One thing to watch: the version parameter in OScam's [cs378x] section. Setting it to 2.3.0 ensures compatibility with clients that check server version during handshake. Some older CCcam client versions are picky about this — if you see handshake failures despite correct credentials, try matching the version string to what the client expects.

Similarly, if you're running a mix — native CCcam on one box, OScam on another — and they need to share cards between them, use the protocol = cccam reader in OScam's oscam.server to connect to the CCcam box. IPv6 addresses in C-lines are worth noting here: older CCcam versions (pre-2.2.x) don't handle IPv6 addresses in C-lines at all. If your server has an IPv6-only address, those old clients will fail to connect regardless of credentials.

Common Misconceptions About CCcam

A lot of the confusion around cccam meaning comes from how the term gets used commercially. People sell "CCcam lines" or "CCcam subscriptions" and the word starts to sound like a product category rather than a technical protocol. It's worth unpacking what's actually being described in those contexts.

CCcam Is Not a Subscription Service

CCcam is a protocol and a software daemon. What gets sold as a "CCcam subscription" is server access credentials — a username and password for a C-line that connects you to someone else's card sharing server. The thing you're buying is access to a service running on their hardware. CCcam itself is just the communication protocol those credentials get used with. Conflating the two is like confusing SSH with the server you're logging into.

Free CCcam Lines vs. Paid Lines: What Actually Differs

The technical difference usually comes down to server quality, not protocol differences. Free lines typically come from overloaded servers with high hop counts, inconsistent uptime, and no CAID coverage guarantees. Paid lines — if the provider runs decent infrastructure — should mean lower hop counts (ideally 0 or 1 from the physical card), faster ECM response times, and more stable uptime.

But the underlying C-line format and CCcam protocol are identical. A free C-line and a paid C-line look exactly the same in your config file. The difference is purely server-side quality.

Why CCcam Lines Expire or Stop Working

Lines fail for specific, diagnosable reasons. The log at /tmp/CCcam.log will usually tell you which one:

• Wrong credentials — username or password changed on the server
• IP restriction — server whitelists specific IPs, your IP changed (common with CGNAT or dynamic IPs)
• CAID not available — the card your server connects to doesn't have entitlement for what you're requesting
• Hop limit exceeded — the server's RESHARE setting doesn't allow your positionin der Kette
• Server offline — der Upstream-Server ist vollständig ausgefallen
• Abonnement abgelaufen — der Serverbetreiber hat dein Konto gelöscht

Ein spezifisches CGNAT-bezogenes Problem, das erwähnenswert ist: Wenn du hinter CGNAT (Carrier-Grade NAT) sitzt, kann die IP, die dein Server beim Verbinden sieht, deine gemeinsame NAT-Adresse des ISP sein und nicht etwas, das du erkennst. Wenn ein Server sich per IP-Adresse authentifiziert, können dir Authentifizierungsfehler entstehen, die wie falsche Passwörter aussehen, aber tatsächlich IP-Nichtübereinstimmungen sind. Überprüfe, welche externe IP du präsentierst, indem du ein Tool wie curl ifconfig.me verwendest und sie mit dem vergleichst, das der Server erwartet.

CCcam ist nicht dasselbe wie ein IPTV-Dienst

CCcam teilt Entschlüsselungsschlüssel für DVB-Satellitensignale. Dein Receiver stimmt sich immer noch auf einen echten Satelliten-Transponder ab und empfängt den Broadcast-Stream über HF — CCcam stellt nur die Entschlüsselung CWs bereit, damit der Descrambler deines Receivers es dekodieren kann. IPTV ist ein völlig anderes Modell, bei dem der Videostrom selbst über IP übertragen wird. Die beiden sind technisch unterschiedliche Systeme, verwenden unterschiedliche Hardware-Pfade und haben unterschiedliche Fehlermodi. Sie zu verwechseln führt zu falschen Troubleshooting-Ansätzen.

Worauf du bei der Bewertung eines CCcam-Servers achten solltest

Überspringe jeden Server, bei dem du keine Testleitung bekommen kannst, bevor du etwas bezahlst. Das ist das Minimum. Alles andere ist sekundär gegenüber dem tatsächlichen Testen der Leistung mit deinem spezifischen Setup und deinen spezifischen Kanalanforderungen.

Latenz- und ECM-Antwortzeitbenchmarks

ECM-Antwortzeit unter 200ms ist ausgezeichnet. Unter 500ms ist für die meisten Kanäle akzeptabel. Über 500ms wirst du anfangen, gelegentliche Einfrierungen zu sehen, besonders auf Kanälen mit schneller CW-Rotation. Über 1000ms konstant ist der Dienst Müll — zahle nicht dafür.

Du kannst die ECM-Antwortzeit über die CCcam-Infoseite unter http://serverip:16001 überprüfen. Suche nach dem Abschnitt "ECMs", der die Antwortzeitzeiten pro CAID zeigt. Auf OScam-Servern hat das Webif am Port 8888 entsprechende Informationen unter dem Readers-Abschnitt. Wenn ein Anbieter dir keinen Webif-Zugriff gibt oder keine Möglichkeit, dies zu überprüfen, ist das ein rotes Zeichen.

Unterstützte CAIDs und Anbieterverpackung

Frage nach oder überprüfe die CAID-Liste des Servers, bevor du dich verpflichtest. Verschiedene Verschlüsselungssysteme haben verschiedene CAIDs, und nicht jede Server-Karte hat Berechtigung für jedes Paket. Ein Server könnte umfangreiche Kanalabdeckung anzeigen, aber nur ein oder zwei Karten haben, die jeweils spezifische Berechtigungen haben. Die CCcam-Infoseite am Port 16001 zeigt die CAID-Liste im Abschnitt „Freigaben" — überprüfe, dass sie mit dem übereinstimmt, das du brauchst.

Reshare-Tiefe und Hop-Count-Limits

Auf der CCcam-Infoseite bedeutet Hop-Count 0 neben einer Freigabe direkten Kartenzugriff auf diesem Server. Das ist ideal. Hop 1 ist in Ordnung. Wenn die Infoseite deine CAID-Freigaben bei Hop 3 oder höher zeigt, erwarten Sie Latenzprobleme. Einige Server werben mit direktem Kartenzugriff, teilen aber eigentlich von woanders aus — die Infoseite m

macht dies sichtbar.

Wenn Sie RESHARE 0 in der Konfiguration eines Servers sehen (manchmal in Share-Informationen sichtbar), bedeutet dies, dass dieser Server Ihnen nicht erlaubt, das weiterzugeben, was Sie erhalten. Das ist eine serverseitige Richtlinie, die Sie vom Client aus nicht überschreiben können.

Indikatoren für Serverstabilität zum Überprüfen

Testen Sie während der Spitzenlastzeiten – typischerweise abends in der Prime Time der Serverregion. Ein Server, der um 2 Uhr morgens gut funktioniert, kann um 20 Uhr völlig überlastet sein. Überprüfen Sie die Anzahl der verbundenen Clients auf der Infoseite, falls sie zugänglich ist: Ein Server mit 500 Clients und einer Karte wird unter Last nicht gut funktionieren.

Uptime-Konsistenz ist wichtiger als rohe Geschwindigkeit. Ein Server mit 180 ms ECM-Zeit, der zweimal täglich abfällt, ist schlechter als ein 400 ms Server, der wochenlang läuft. Führen Sie Ihre Test-Leitung mindestens 48-72 Stunden lang zu verschiedenen Tageszeiten durch, bevor Sie Schlussfolgerungen ziehen.