Why every cccam.io line runs on two parallel daemons

The single failure mode that kills most cardsharing services is the one we designed around first. Here's how — and the trade-offs we accepted to do it.

If you’ve used cardsharing services for any length of time, you know the pattern: things work for weeks, then one evening — usually right when a match starts — every channel goes black. You check the status page. It’s green. You restart your receiver. Still black. You email support. They tell you to wait. Two hours later it’s back.

What happened is almost always the same: a single backend daemon crashed, hung, or got knocked offline by an upstream change. Everyone hosted on that box dropped at the same time. And because there’s only one box per line, there’s nothing to fail over to.

We didn’t want to ship that service. So we didn’t.

One account, two hosts

Every line on cccam.io is provisioned as two accounts with the same username and password — one on a MultiCS host running the CCcam protocol, one on an OScam host running the OScam protocol. You configure both on your receiver. The receiver tries them in order. If the first one can decode, it does. If it can’t, it falls back to the second.

This isn’t a load balancer. It isn’t DNS failover. It isn’t a “high-availability cluster” — those words usually mean a shared storage layer that fails in interesting ways at 3am. It’s just two completely independent daemons, on two completely independent boxes, running two different codebases, written by two different teams. Both authoritative. Both authorized.

The failure modes we care about are:

• One process crashes. The other keeps decoding. You don’t notice.
• One host’s network drops. The other keeps decoding.
• A protocol-specific bug breaks decoding on one daemon for one provider. The other handles that provider with a different parser and keeps working.
• Someone pushes a bad config to one daemon. The other is untouched.

We didn’t invent this idea. Pair redundancy at the daemon level has been the standard answer in critical infrastructure for decades. It’s just unusual to see it applied to cardsharing, because most cardsharing services are run by one person on one box and adding a second daemon doubles the operational surface area.

Why both protocols

The next obvious question: if we’re doubling up, why not run two MultiCS hosts? Or two OScam hosts? Wouldn’t that be simpler?

It would. And we wouldn’t do it, because the failure modes we want to survive include protocol-level bugs. If your only defense against a CCcam parser bug is a second copy of the same CCcam parser, you don’t have a defense — you have two copies of the same broken thing.

Running one of each means:

• A regression in MultiCS doesn’t take you down — OScam doesn’t share the code.
• A new card variant that one daemon hasn’t been updated for yet still works through the other.
• An incompatibility between a specific receiver model and one protocol’s quirks has an obvious workaround: use the other one.

The cost is that we maintain two configuration pipelines, two reload procedures, two health-check stacks, and two sets of metrics. Worth it.

The hard part: reloads

Doubling daemons is the easy half. The interesting half is keeping them in sync when a line changes — when a reseller creates a new account, when an abuse rule blocks an existing one, when a customer renews — without dropping the clients that are connected right now.

Both daemons read their accounts from a flat config file. Both have to be told the file changed. Both have to reload without disconnecting the people watching a stream.

For MultiCS, the file is Cccam.cfg. The naive approach is to rewrite it — unlink the old file, write a new one, signal the daemon. That’s wrong: it changes the file’s inode, and MultiCS’s internal file handle now points at a file that no longer exists. The reload silently fails. Clients drop.

What we do instead is an in-place edit: open the existing file, modify the bytes, close it. The inode stays the same. The daemon’s handle stays valid. The reload signal does what it’s supposed to.

For OScam, the file is oscam.user, and the reload story is different — OScam supports oscam -d 4096, a documented runtime signal that re-reads the user file without restarting the process. Clients stay connected through it. We use it.

These are not exotic tricks. They are documented in the daemons’ own manuals. They are also the kind of thing that a service which throws together a control panel and a bash script will get wrong, because the bash script will use > and mv and call it done.

What this costs you

Nothing extra. Every line includes both. You don’t pick a protocol at checkout. You don’t pay for the second account separately. There is no “premium tier” that adds redundancy — redundancy is the product.

What it does ask of you is that you configure both on your receiver. The setup guides under /docs walk through how to add a second CAM entry on Enigma2, OpenATV, OpenPLi, OScam-direct configs, MAG boxes, and the common DreamBox clones. It takes about a minute longer than configuring one. After that you stop thinking about it.

What this costs us

A lot more. Concretely:

• Twice the host fleet. Every region runs at least one MultiCS box and one OScam box.
• Two health-check pipelines. Latency, ECM time, client count, and disconnects are tracked per host per protocol.
• Two retry queues. When an SSH write to one host fails, the failure has to be queued and re-driven without taking the matching write on the other host out of sync.
• Two reload procedures. With two distinct sets of failure modes that only show up under load.

We accepted those costs at the design stage because the alternative was a service that looks fine on a benchmark and then dies at the wrong moment. There are already plenty of those.

What you can verify

Talk is cheap. The things you can actually check yourself:

• The status page at /servers shows live pair load, last health-check timestamp per host, and any open incidents. We don’t redact this. If a MultiCS host is sick right now, you can see it.
• Both servers in your credentials email. When you start a trial or buy a line, the email contains two CAM entries — one MultiCS line and one OScam line, both with the same username and password. If one of them isn’t there, something is wrong; tell us.
• The setup guides are written assuming both daemons. If your receiver’s documentation only mentions one, the guide explains where the second goes.

A line that decodes when both daemons are healthy is the easy case. A line that keeps decoding when one of them isn’t — that’s the case we built for.

If you want to try it without paying, the 48-hour trial is free, no card. You get the same two-daemon setup the paying customers have. If it works, you’ll know. If it doesn’t, we want to hear about it.