Crypted channels - a small introduction to the problematic

Crypted channels - a small introduction to the problematic

I'd like to explain some things, because in the absence of information you can be confused ... I'd like to explain this problem a little better ...

Let's go one by one ...

How are coded channels when you have the appropriate card in your receiver?

Receiver send ECM / information card that should decode according to a pre-defined algorithms to return the CW / response to the items in the ECM. Repetition interval required for the decoding of these were the most frequently 8-10 sec although not necessarily the case, and the response time, mean maximum timeout, how can late, the answer of the card varies from system to system. The most critical is ttv from 350 ms to max 10 +10 sec (in most systems that support even/odd CW)

How CS works?

In CS all this happening in just the same way but card is not in your receiver, but in a distant location, assume on the server you are connected. We can use the LAN or WAN. You can be connected with "local" (in your private network-LAN) to the server or via the Internet (WAN). All emulator or camd's use cashe and/or set by default a validity period for the ECM, or how long ECM is valid after the its occurrence, or it can be set by you and optimize transport.

Why all this?

EVERY EMU USE CACHE

So if you watch channel-1 encoded in system XXX and the other user at the same time watch the same channel-1 encrypted in the same system XXX, it is not necessary to decode both ECM’s.Decode is done for only first, second or third and more get CW from cashe.This protect the card from uunecessery work and automatically frees time so that same card can decode a second channel from same package. ECM-decode time depends on the card/encoding system and it is in a range of 150ms (very overclocked NDS card, for best possible response) to 1000ms some old Conax card.

When the client receives the CW from cashe, it is very quick, so you have a good connection to the server (assume that you are on the same ISP) it can happen to get CW from cashe in ~ 30ms. In practice, even a good connection has latency of ~ 50ms, and there are those who have 100ms or more. If you have high-speed download does not mean that your latency is small, it depends on many conditions, starting from the interconnection of your ISP's and ...

Try a traceroute to the IP address of the server on which you are connected and you will be surprised over how many hops this small packet only 32 bytes travel to your connected server, each hope can be burdened out at the time of review and that means that if today you have a larger latency - tomorrow it can be fast as lightning (for traceroute <IP> Linux or tracert <IP> to win cmd)

Means, once again, please do not get confused by data: I have a 10Mbps connection – I must have ideal cs! Unfortunately this does not mean that. So do not mess wrong terms, the speed of access does not guarantee you a low latency to your cs server, even though reverse sounds logical.
Return to the ECM / CW and response time, means if you get cached CW, response time is directly related to the latency on your Internet connection. Not cached, real decoded CW, response time in such cases vary, for example, some of ideal 200ms (~ 150ms decoding time card + ~ 50ms latency of the Int ernet connection) to ~ 500ms-1000ms if your latency is ok and if the card is in the server to which you are connected.
All of this is valid if you are watching alone channel-1 on the XXX.

What happens if somebody watching same packet but a different channel, channel-2 on the XXX?

Depending on how the server is configured, there are several possibilities of reaction, but more often is a FIFO, or by our, who first starts the girl - gets girl (since you two guys/ECM’s looks exactly same to girl/server).

OK, to explain, if you channel ECM-1 first came to the XXX card, it will be first to decode, and ECM-2 channel for the same card is on hold, is now a table, and vice versa if you are those who wait?

The decoding time will be increased by as much as you need for ECM + the time required for decoding of the ECM1 (it can be more then one of them) that arrive before your ECM's. So if card really decode ECM for 300ms,and if only one ECM in front of yours - you will receive CW for 600ms. If there were 2 ECM’s in front of your ECM then logically it will be 900ms decoding time of your ECM and logically + delay on the internet connection + ~ 50-100.
But what happens if the card is not with in server you are connected but in server with whom he is sharing, that means distance 2! and not 1 as in the first case.

Distance of 2 means that the card is on another server and not the one on which you are connected, this implies that now we have even one more delay: server-1 latency on which you are connected and the latency server1 to server-2 which really have card.

Increased distance means greater latency and less control over the cards and greater instability, but will not now about it. The increased distance means greater card engagement, or as I explained above more ECM's in front of your which means it can happen on the very loaded card that the response time can be a few seconds, which in practice means that when you turn the channel – longer to wait for a picture.

It can also be the cause of freezes, why?

Because as I said above, there is max. period allowed for a delay CW, most worst cases ttv with 350ms, what then?
If the card is overclocked and CW for this card is 150 ms, and you get on server as the second, means that someone before you sent ECM from another channel of the package, then the decoding time is 150ms +150 ms +50 ms = 350ms which means that you are on the theoretical limits for decoding, if your ECM is the third in the row, you will then have a problem - overtime of 150ms, and a longer delay shutter picture, if you are a fourth - then come bigger problem - image stop for a sometime...

At end of this text brief:

If you have a 10Mbps internet access:
This does not guarantee to you low latency to the server and gives you no right to say something like: I should have ideal cs.
This does not guarantee that you'll have a better connection to the server from someone who has 1Mbps internet access.
This does not guarantee that you will have equal latency to all servers.
This does not guarantee that you will now and after 10 minutes have the same latency for the same server.

*CW you get for 100ms is from the cashe, and no additional processing is to be done by card to decode your ECM. Your ECM is pre-processed .Or which can be a case time you get is not measured correctly which can happen with old dbox2 receivers.

* For systems in which the time of response is critical, in addition to low latency is important that the card is on server with smaller distance, the best on the server on which you are connected.

To, and not to forget, at AZBox a currently have a small problem with the delay in forwarding the ECM and camd about 65ms, it requires additional optimization.It is known bug and hopefully will be solved in one of the future FW.

Orignaly posted by Telesat (azbox4yu)

Translated by Roger Rabbit (azbox4yu)

...shortest ban in the history of the board...

Debian with CCcam 2.0.11
AzboxHD