```html

Konfiguracja Resellera Serwera CCcam: Przewodnik Techniczny i Architektura

Jeśli próbujesz zrozumieć, jak działa operacja resellera serwera cccam pod względem technicznym — nie prezentacja marketingowa, ale rzeczywista architektura — to jest rozbór, którego szukałeś. Większość treści na ten temat to ledwo ukryta reklama. To, co następuje, to techniczny przewodnik tego, jak panele resellera zarządzają liniami C, jak dystrybucja wieloskokowa wpływa na timing ECM i co odróżnia solidną infrastrukturę resellera od tej, która będzie gubić kanały o 21:00 w sobotę.

Przed rozpoczęciem: technologia card sharing znajduje się w szarej strefie prawnej, która się różni w zależności od jurysdykcji. Zanim uruchomisz lub zaprenumerujesz dowolną konfigurację card-sharing, zapoznaj się z prawami obowiązującymi w Twoim kraju. Nic tutaj nie stanowi porady prawnej.

Czym jest System Resellera Serwera CCcam i Jak Działa?

W swoim rdzeniu operacja resellera CCcam to warstwa dystrybucji między źródłem karty a użytkownikami końcowymi. Źródło karty obsługuje rzeczywiste deszyfrowanie dostępu warunkowego. Wszystko poniżej to tylko efektywne kierowanie żądaniami i odpowiedziami ECM.

Architektura CCcam: Od Serwera Głównego do Użytkownika Końcowego

Demon CCcam działa na serwerze Linux (lub odbiortniku Enigma2) i odczytuje swoją konfigurację z /etc/CCcam.cfg — chociaż na obrazach Enigma2 jest to często /var/etc/CCcam.cfg. Demon nasłuchuje na konfigurowalnym porcie (powszechnie 12000, 19000 lub port niestandardowy) i obsługuje dwa rodzaje połączeń: nadrzędne źródła kart (linie C, do których się łączy) i klientów podrzędnych (linie F, które obsługuje).

Typowa topologia resellera wygląda tak:

• Skok 0 — Fizyczny czytnik kart podłączony do serwera kart. To jest początek.
• Skok 1 — Główny serwer CCcam z bezpośrednim dostępem do źródła karty. Reseller łączy się tutaj.
• Skok 2 — Serwer resellera, do którego łączą się użytkownicy końcowi.
• Skok 3+ — Sub-reseller lub dodatkowe warstwy dystrybucji. Timing ECM zaczyna się tutaj zauważalnie degradować.

Każdy skok dodaje rzeczywiste opóźnienie do żądań ECM. Poniżej 300ms jest wygodny dla stabilnego odszyfrowania. Jeśli konsekwentnie przekroczysz 500ms, zobaczysz zawieszone klatki i upadki kanałów — szczególnie w przypadku treści sportowej premium, gdzie kryptografia zmienia się szybko.

Warstwa Resellera Wyjaśniona: Jak Dystrybuuje Się Linie C

Reseller nie wchodzi w interakcję z fizyczną kartą. Łączy się z serwerem głównym za pomocą linii C (która jest połączeniem klienta CCcam), a jego własny serwer następnie obsługuje linie F dla użytkowników końcowych. Jego instancja CCcam działa jednocześnie jako klient (nadrzędny) i serwer (podrzędny).

Gdy użytkownik końcowy wysyła żądanie ECM, podróżuje w górę łańcucha: użytkownik końcowy → serwer resellera → serwer główny → karta. Odszyfrowany kod kontrolny wraca tą samą ścieżką. Każde łącze w tym łańcuchu dodaje opóźnienie i potencjalny punkt awarii.

``````html Różnica między serwerem bezpośrednim a panelem resellera

Serwer bezpośredni oznacza, że Twoja linia C łączy się na skoku 1 — jesteś klientem właściciela kart. Panel resellera to oddzielna warstwa aplikacji internetowej, która automatyzuje zarządzanie liniami F na tym serwerze. Sam panel nie obsługuje żadnego ruchu protokołu CCcam. Po prostu zapisuje do CCcam.cfg, zarządza bazą danych kont użytkowników i sygnalizuje demonowi CCcam, aby przeładował jego konfigurację.

Pomyśl o tym w ten sposób: CCcam obsługuje protokół, panel obsługuje logikę biznesową. To są całkowicie oddzielne procesy, które wchodzą w interakcję tylko poprzez plik konfiguracyjny i sygnał Unix.

Jak wieloskokowe udostępnianie działa w łańcuchach resellera

CCcam śledzi liczbę skoków wewnętrznie i przekazuje ją w protokole. Gdy sprawdzisz statystyki ECM w interfejsie internetowym na porcie 16001, zobaczysz liczbę skoków zgłoszoną dla każdej połączonej karty. Jeśli Twój reseller znajduje się na skoku 2, Twoi użytkownicy końcowi są na skoku 3 — i tam musisz się zatrzymać. Dodanie warstwy sub-resellera oznacza skok 4, który jest funkcjonalnie bezużyteczny dla transmisji na żywo w większości przypadków.

Niektóre konfiguracje wykorzystują funkcję cacheex OScam, aby zmniejszyć efektywną liczbę skoków — omówimy to w sekcji 5. Ale żadne buforowanie nie naprawia fundamentalnie głębokich łańcuchów dystrybucji.

Komponenty techniczne panelu resellera CCcam

Panel resellera to zazwyczaj aplikacja internetowa PHP wspierana przez MySQL lub MariaDB. Obsługuje tworzenie kont, zarządzanie kredytami, wymuszanie wygaśnięcia i synchronizację konfiguracji. Demon CCcam nie wie ani nie obchodzi go istnienie panelu — po prostu czyta jego plik konfiguracyjny.

Zarządzanie użytkownikami: tworzenie, wygasanie i zawieszanie linii C

Każdy użytkownik końcowy odpowiada linii F w CCcam.cfg. Gdy reseller tworzy nowego użytkownika w panelu, panel wstawia rekord do swojej bazy danych i dołącza (lub przepisuje) linię F w pliku konfiguracyjnym. Gdy subskrypcja tego użytkownika wygasa, panel usuwa linię F i sygnalizuje przeładowanie.

Zawieszenie działa w ten sam sposób — panel albo usuwa linię F, albo ją komentuje, w zależności od implementacji. Niektóre panele przechowują wygasłych użytkowników w bazie danych dla celów archiwalnych, ale zapewniają, że nie mają odpowiadającej linii F w aktywnej konfiguracji.

Sierote linie F są rzeczywistym problemem, gdy dochodzi do uszkodzenia bazy danych. Jeśli baza danych panelu ulegnie uszkodzeniu, może stracić informacje o użytkownikach, ale ich linie F pozostają w CCcam.cfg na czas nieokreślony. Te konta nigdy nie wygasają i nie złapiesz tego bez okresowego auditowania pliku konfiguracyjnego względem bazy danych.

Auto-generowanie linii F w CCcam.cfg i przeładowanie konfiguracji

Składnia linii F w CCcam.cfg wygląda tak:

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

Rozkład: username i password to poświadczenia. max_connections to liczba całkowita określająca, ile równoczesnych połączeń to konto może

```hold — krytyczne dla zapobiegania udostępnianiu poświadczeń. Końcowe pola 0 0 :0:0:0 kontrolują, czy użytkownik może udostępniać innym poniżej (0 = nie) i ograniczenia CAID/serwisu (0:0:0 = bez ograniczeń).

Gdy panel generuje linię F, wykonuje zapytanie do bazy danych o parametry użytkownika i je zapisuje. Trudna część to przeładowanie konfiguracji. Ponowne uruchomienie CCcam powoduje rozłączenie wszystkich aktywnych połączeń. Prawidłowe podejście to:

kill -s SIGHUP $(pidof CCcam)

To zmusza CCcam do ponownego odczytania CCcam.cfg bez przerywania istniejących sesji. Większość paneli automatyzuje to po każdej modyfikacji konfiguracji. Ale jeśli nowo zapisana linia F zawiera błąd składniowy, CCcam po cichu odrzuca źle sformułowaną linię, a nowy użytkownik nie może się połączyć — podczas gdy panel raportuje powodzenie. Zawsze sprawdzaj składnię linii F przed sygnalizowaniem przeładowania lub sprawdź log CCcam natychmiast po.

System kredytów i warstwy resellera podrzędnego

System kredytów jest warstwą logiki biznesowej. Administrator główny przydzielaje kredyty resellerom. Każdy kredyt zazwyczaj reprezentuje jedno konto-miesiące (lub inną jednostkę zdefiniowaną przez administratora). Gdy reseller tworzy konto 3-miesięczne, panel odejmuje 3 kredyty z jego salda i zapisuje datę wygaśnięcia w bazie danych.

Resellery podrzędni działają w ten sam sposób rekurencyjnie. Reseller może przydzielić część swoich kredytów resellers podrzędnemu, który następnie tworzy konta użytkowników końcowych. Panel śledzi całą hierarchię — kto kogo stworzył, salda kredytów na każdym poziomie i całkowitą liczbę aktywnych połączeń na konto.

Baza danych zazwyczaj zawiera tabele takie jak: users (szczegóły konta, kredyty, parent_id), lines (szczegóły linii F, wygaśnięcie, przypisanie serwera) i servers (IP, port, poświadczenia upstream). Właśnie ta relacja parent_id umożliwia hierarchię kaskadową.

Struktura bazy danych panelu i punkty końcowe API

Bardziej zaawansowane panele resellera udostępniają API — zwykle REST przez HTTP/HTTPS — do programowego zarządzania kontami. Reseller może wywołać POST /api/create_user z parametrami JSON zamiast korzystać z interfejsu internetowego. API zapisuje w tej samej bazie danych i wyzwala to samo przeładowanie konfiguracji.

Jeśli budujesz lub oceniasz konfigurację panelu, API to gdzie integracja ma znaczenie. Zautomatyzowane systemy inicjowania obsługi (do obsługi płatności i natychmiastowego tworzenia konta) zależą od niezawodnego API. Panel bez API lub jeden, który oferuje tylko obejścia screen-scrapingu, będzie ci sprawiać problemy na dużą skalę.

Automatyzacja przeładowania konfiguracji bez ponownego uruchomienia serwera

Poza SIGHUP, niektóre konfiguracje używają wbudowanego interfejsu internetowego CCcam na porcie 16001 do programowego wyzwalania przeładowań — interfejs ma punkty końcowe, które można wywoływać za pośrednictwem curl. Zadanie cron uruchamiane co 5 minut może obsługiwać sprawdzenia wygaśnięcia i wyzwalacze przeładowania, jeśli panel tego nie robi w czasie rzeczywistym.

Na odbiornikach Enigma2 działających jako serwery CCcam (mniej powszechny, ale rzeczywisty scenariusz), ścieżka konfiguracji to i

s zwykle /var/etc/CCcam.cfg i zarządzanie procesami jest inne — używasz systemu wtyczek Enigma2 lub niestandardowego skryptu init zamiast standardowych sygnałów procesów Linux.

Infrastruktura serwerów i zagadnienia wydajności

Wymagania sprzętowe skalują się bezpośrednio w zależności od aktywnych połączeń i przepustowości ECM. Zużycie CPU przez CCcam jest skromne na połączenie, ale przepustowość sieciowa i koszty ogólne wielu równoczesnych żądań ECM szybko się sumują.

VPS vs serwer dedykowany dla operacji sprzedawcy

VPS z 1 vCPU i 1GB RAM może realistycznie obsługiwać 50-100 aktywnych użytkowników CCcam, jeśli sieć jest solidna. Poza tym zaczynasz napotykać problemy contention — szczególnie na instancjach VPS „burst-able", które ograniczają CPU przy trwałym obciążeniu.

W przypadku 300+ jednoczesnych użytkowników, dedykowany serwer lub odpowiednio zmieniony rozmiar VPS (4+ rdzenie, 4GB RAM) z gwarantowaną przepustowością sieci ma więcej sensu. Baza danych MySQL panelu nie stanowi wąskiego gardła na tej skali — to demon CCcam zarządzający setkami równoczesnych połączeń gniazd i związanymi z nimi limitami deskryptorów plików. Sprawdź ulimit -n i dostosuj /etc/security/limits.conf, jeśli widzisz niepowodzenia połączeń na dużą skalę.

Środowiska VPS wyłącznie IPv6 to prawdziwa agoniza. Domyślna konfiguracja CCcam wiąże się z IPv4. Jeśli Twój VPS ma tylko adres IPv6 (niektórzy dostawcy budżetowi to robią), musisz jawnie skonfigurować CCcam, aby wiązał się z adresem IPv6, a użytkownicy końcowi łączący się z połączeń wyłącznie IPv4 będą potrzebować bramy NAT64 lub tunelu. Większość konfiguracji sprzedawcy z tego powodu unika serwerów wyłącznie IPv6.

Czas odpowiedzi ECM i optymalizacja liczby przeskoków

Cel poniżej 300ms dla odpowiedzi ECM na połączeniach sprzedawcy. Możesz to zobaczyć w interfejsie internetowym CCcam na stronie http://server-ip:16001 w sekcji aktywnych klientów. Każdy klient pokazuje liczbę ECM i średni czas odpowiedzi.

Na odbiornikach Enigma2 wtyczka CCcamInfo wyświetla ECM w czasie rzeczywistym na kanał. Jeśli oceniasz resellera serwera cccam upstream przed zaangażowaniem się w niego, poproś o linię testową i sprawdź czasy ECM na wielu kanałach w godzinach szczytowego oglądania — nie o 3 rano, gdy obciążenie jest minimalne.

Matematyka jest prosta: jeśli Twoja linia upstream pokazuje 180ms na przeskoku 1, Twoi użytkownicy końcowi na przeskoku 2 powinni widzieć około 180ms + czas przetwarzania serwera + RTT sieci do użytkownika końcowego. Jeśli upstream wynosi już 350ms, Twoi użytkownicy końcowi otrzymują 450ms+ i jesteś w tarapatach.

Opóźnienie sieci, peering i lokalizacja serwera

Lokalizacja serwera ma znaczenie w dwóch kierunkach: bliskość źródłowego serwera kart zmniejsza opóźnienie przychodzącego ECM, a bliskość użytkowników końcowych zmniejsza ostateczny przeskok. Często są w napięciu — nie zawsze możesz zoptymalizować oba jednocześnie.

Ogólnie rozważ priorytet bliskości źródła upstream. Opóźnienie przychodzącego ECM jest zwykle czynnikiem dominującym. Serwer 10ms od źródła kart i 40ms od użytkowników końcowych będzie lepszy

wykonać serwer, który jest 5ms od użytkowników końcowych, ale 80ms od źródła karty.

Uważaj na dostawców chmury z agresywnym filtrowaniem ruchu wychodzącego. Niektórzy blokują porty niestandardowe domyślnie za pomocą reguł grupy bezpieczeństwa, które nie pojawiają się jako odrzucenie zapory — połączenie po prostu milczące upada. Zawsze testuj za pomocą telnet server-ip port lub nc -zv server-ip 12000 z maszyny zewnętrznej po konfiguracji. Reguły iptables blokujące twój port CCcam są najczęstszym powodem, dla którego nowa konfiguracja nie działa, nawet jeśli CCcam działa poprawnie.

Równoważenie obciążenia na wielu instancjach CCcam

W przypadku operacji na dużą skalę uruchamianie wielu instancji CCcam ma więcej sensu niż skalowanie jednej pionowo. Opcje obejmują:

• Okrężny DNS — Wiele rekordów A dla tej samej nazwy hosta wskazujących na różne serwery. Proste, ale bez sprawdzania kondycji. Martwy serwer nadal otrzymuje ruch.
• Wiele wpisów F-line — Użytkownicy końcowi otrzymują dwie linie C wskazujące na różne serwery. Ich klient próbuje obu i używa tego, który odpowiada pierwszy.
• OScam jako serwer proxy do równoważenia obciążenia — OScam akceptuje połączenia CCcam od użytkowników końcowych i rozprowadza żądania ECM na wiele backend instancji CCcam. To jest najbardziej niezawodne podejście i obsługuje sprawdzanie kondycji.

Uruchamianie wielu instancji CCcam na tym samym serwerze fizycznym przy użyciu różnych portów (np. jedno na 12000 dla jednej warstwy sprzedawcy, inne na 19000 dla innej) jest również ważne. Każda instancja ma swój własny plik CCcam.cfg — możesz zarządzać nimi za pomocą dowiązania symbolicznego lub osobno. Upewnij się tylko, że porty interfejsu internetowego nie kolidują (każda instancja potrzebuje własnego WEBINFO LISTEN PORT).

Monitorowanie kondycji serwera: Dzienniki, statystyki ECM i czas działania

CCcam rejestruje na stdout domyślnie, co przechwytywane jest przez system init, którego używasz. W ustawieniach systemd, journalctl -u cccam -f daje ci wyjście dziennika na żywo. Wspólne wzorce, które należy obserwować:

• Powtarzające się komunikaty „ECM timeout" wskazują na problemy z opóźnieniem upstream lub problemy z kartą
• „Zbyt wiele połączeń z IP" sugeruje udostępnianie poświadczeń przez użytkownika końcowego
• Błędy logowania w dzienniku, które nie odpowiadają żadnemu znanemu użytkownikowi — możliwe próby brute-force
• Nagły spadek liczby aktywnych klientów o określonej porze — zwykle problem z siecią lub rozłączenie upstream

Interfejs internetowy na porcie 16001 daje ci żywą tablicę rozdzielczą połączonych klientów, ich liczby ECM i wskaźniki trafień pamięci podręcznej. Trafienia pamięci podręcznej to dobry znak — oznaczają, że to samo słowo sterujące jest serwowane z pamięci, zamiast ponownie żądać z karty, co zmniejsza obciążenie i opóźnienie.

Ocena konfiguracji sprzedawcy CCcam: Kryteria techniczne

Jeśli oceniasz, czy kupić linie od sprzedawcy serwera cccam lub oceniasz operację sprzedawcy, którą chcesz zbudować na podstawie, oto kryteria techniczne, które faktycznie mają znaczenieter.

Benchmarki liczby przeskoków i czasu odpowiedzi ECM

Przeskok 1 jest idealny. Przeskok 2 jest akceptowalny. Przeskok 3 jest graniczny i go zauważysz. Przeskok 4+ jest praktycznie bezużyteczny dla transmisji premium na żywo.

Zweryfikuj liczbę przeskoków przez interfejs sieciowy CCcam (port 16001) po podłączeniu linii testowej. Na Enigma2, dzienniki debugowania odbiornika również pokazują liczbę przeskoków. Nie polegaj na twierdzeniu dostawcy, że jego linie są "hop 1" — zweryfikuj to sam. Jeśli sprzedawca odmawia pozwolenia na weryfikację liczby przeskoków podczas okresu testowego, to jest czerwona flaga.

Benchmarki odpowiedzi ECM: poniżej 200ms to doskonałe wyniki, 200-350ms to dobre wyniki, 350-500ms to akceptowalne, powyżej 500ms to problematyczne. Liczby te zakładają, że twoja własna sieć nie dodaje znacznych opóźnień.

Czas pracy serwera i architektura nadmiarowości

Pojedynczy serwer bez przełączania awaryjnego to pojedynczy punkt awarii. Dobra infrastruktura sprzedawcy detalicznego obejmuje co najmniej serwer główny i zapasowy z automatycznym przełączaniem awaryjnym. Z perspektywy użytkownika końcowego oznacza to otrzymanie dwóch linii C — głównej i zapasowej — zamiast jednej linii.

Zapytaj konkretnie, co się dzieje, gdy upstream się nie powiedzie. Czy sprzedawca ma wiele źródeł upstream? Jeśli ich pojedynczy serwer karty upstream ulegnie awarii, wszyscy ich użytkownicy jednocześnie stracą usługę. Nadmiarowe połączenia upstream są trudniejsze w utrzymaniu, ale rzeczywiście poprawiają niezawodność.

Bezpieczeństwo: zaszyfrowane połączenia i kontrola dostępu

CCcam domyślnie używa szyfrowania DES na warstwie protokołu — lepsze niż nic, ale DES jest archaiczny i nie powinien być uważany za silne szyfrowanie według współczesnych standardów. W przypadku ustawień sprzedawcy zajmujących się poufną łącznością, tunelowanie ruchu CCcam przez stunnel (kończące się na porcie 443) lub OpenVPN dodaje znaczące bezpieczeństwo i pomaga obejść zapory sieciowe blokujące porty niestandardowe.

Panel sprzedawcy detalicznego musi działać przez HTTPS. Panel na zwykłym HTTP ujawnia poświadczenia i sesje administracyjne w sieci. Każda poważna operacja używa Let's Encrypt lub podobnie — nie ma wymówki dla zwykłego HTTP w 2024 roku.

Limity połączeń na użytkownika (parametr max_connections w linii F) powinny być zawsze ustawione na 1 dla kont użytkowników indywidualnych. Jeśli widzisz użytkownika w max_connections stale, dzielą poświadczenia. Możesz to wykryć w dziennikach CCcam, obserwując żądania połączeń z wielu źródłowych adresów IP na tej samej nazwie użytkownika w krótkim przedziale czasowym.

Przejrzystość topologii sieci

Godna zaufania konfiguracja sprzedawcy detalicznego daje ci wystarczająco dużo informacji, aby zweryfikować, co dostajesz: rzeczywisty adres IP serwera (nie nazwę hosta proxy, która mogłaby wskazywać gdziekolwiek), możliwość sprawdzenia liczby przeskoków podczas okresu testowego i jasną dokumentację, jaki jest układ serwera zapasowego.

Brak przejrzystości = brak odpowiedzialności. Jeśli konfiguracja jest czarną skrzynką, w której po prostu otrzymujesz linię C i masz nadzieję na najlepsze, nie masz sposobu na zdiagnozowanie problemów lub weryfikację roszczeń dotyczących jakości.

Czego unikać: czerwone flagi w ponownym

seller Infrastructure

• 3+ linie sprzedane jako połączenia „bezpośrednie"
• Brak egzekwowania limitu połączeń (max_connections nie ustawiony lub ustawiony zbyt wysoko)
• Panel działający tylko na HTTP
• Jeden serwer, brak redundancji lub linii zapasowych
• Brak dostępnej linii testowej przed zakupem
• Niezgodności stref czasowych między panelem a serwerem powodujące wygaśnięcie linii w niewłaściwych godzinach — subtelna usterka, w której serwer panelu jest w UTC, a serwer CCcam znajduje się w innej strefie czasowej, więc kontrole wygaśnięcia są niedokładne o godziny
• Brak API do automatycznego inicjowania obsługi (sugeruje, że operacja jest zbyt manualna, aby skalować się niezawodnie)
• Współdzielone nazwy użytkowników lub hasła na wielu kontach (znak leniwego inicjowania obsługi)

CCcam vs OScam dla wdrożeń resellerów

Zarówno CCcam, jak i OScam mogą prowadzić operację resellera, ale mają znacząco różne mocne strony. Wiele produkcyjnych konfiguracji używa obu jednocześnie w konfiguracji hybrydowej.

Różnice protokołów i kompatybilność

CCcam to daemon jednoprotokołowy — mówi wyłącznie protokołem CCcam. OScam jest wieloprotokołowy: obsługuje CCcam, newcamd, camd35, radegast i inne. Dla resellera obsługującego klientów, którzy mogą używać różnego oprogramowania odbiorników, elastyczność protokołu OScam jest rzeczywistą zaletą.

Protokół newcamd używa innego systemu szyfrowania (DES ze statycznym kluczem negocjowanym przy uścisku dłoni) i jest obsługiwany przez szeroki zakres starszego sprzętu. Jeśli koniec użytkowników obejmuje osoby na starszym sprzęcie, obsługa newcamd przez OScam ma znaczenie.

OScam jako proxy przed CCcam

Powszechna architektura produkcyjna: OScam uruchamia się na serwerze resellera, akceptując połączenia protokołu CCcam od użytkowników końcowych. Definicja czytnika OScam (w /etc/oscam/oscam.server) łączy się z upstream'owym serwerem CCcam przy użyciu typu czytnika CCcam. Użytkownicy końcowi łączą się z OScam myśląc, że rozmawiają z CCcam — protokół jest identyczny z ich perspektywy.

Konfiguracja OScam dla tego rodzaju konfiguracji wygląda następująco:

# /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

A w /etc/oscam/oscam.user definiujesz użytkowników końcowych z filtrować CAID dla pojedynczych użytkowników, limitami połączeń i ograniczeniami usług znacznie bardziej szczegółowo niż pozwala na to składnia F-line CCcam:

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

To ustawienie uniq = 1 wymusza unikalność — tylko jedno połączenie na konto, gdzie najnowsze połączenie wyrzuca stare. Znacznie czystsze zapobieganie dzieleniu się danymi uwierzytelniającymi niż podstawowe liczanie połączeń CCcam.

Różnice w zarządzaniu użytkownikami

Zarządzanie użytkownikami CCcam to zasadniczo płaski plik tekstowy z liniami F. Działa, ale zarządzanie setkami użytkowników oznacza zarządzanie setkami o

f F-linie w jednym pliku. OScam używa oddzielnych plików konfiguracyjnych dla każdego typu użytkownika, a jego interfejs sieciowy zapewnia znacznie lepsze monitorowanie dla każdego użytkownika — możesz dokładnie zobaczyć, co żąda każdy użytkownik, jego współczynnik sukcesu ECM i historię połączeń.

Funkcja cacheex w OScamie zasługuje na osobne wyróżnienie. Wymiana pamięci podręcznej pozwala wielu instancjom OScama udostępniać swoją pamięć podręczną odpowiedzi ECM sobie nawzajem. W scenariuszu resellera z wieloma użytkownikami oglądającymi te same kanały, cacheex oznacza, że drugie żądanie ECM dla danego słowa sterowania trafia do pamięci podręcznej zamiast trafić do karty. To zmniejsza obciążenie upstream i może skutecznie poprawiać czasy odpowiedzi dla popularnych kanałów.

Kiedy używać każdego (lub obu razem)

Tylko CCcam: odpowiedni dla małych operacji poniżej 50 użytkowników, prosta konfiguracja, szeroka kompatybilność z odbiornikami użytkowników końcowych. Konfiguracja resellera serwera CCcam oparta na panelu jest prosta do zbudowania i utrzymania w tej skali.

Tylko OScam: lepszy dla operacji średnich do dużych, gdzie potrzebujesz filtrowania CAID dla każdego użytkownika, obsługi wielu protokołów lub korzyści z cacheex. Bardziej skomplikowany w prawidłowej konfiguracji, ale znacznie bardziej potężny.

Oba razem: OScam jako serwer skierowany do użytkownika (obsługujący połączenia użytkowników końcowych, stosujący zasady, buforujący ECMy) z CCcam lub inną instancją OScama jako backend upstream. Ta architektura dodaje złożoność, ale daje ci to co najlepsze z obu: kompatybilność CCcama i kontrolę OScama. Większość poważnych operacji resellera kończy się tutaj ostatecznie, gdy się skalują.

Ścieżka konfiguracji do zapamiętania: główna konfiguracja OScama to /etc/oscam/oscam.conf, definicje serwera znajdują się w /etc/oscam/oscam.server, a konta użytkowników w /etc/oscam/oscam.user. Interfejs sieciowy OScama domyślnie uruchamia się na porcie 8888 i jest znacznie bardziej informatywny niż interfejs portu 16001 CCcama.