In recent days, there have been occasional complaints about frequent dropouts
when using cardspider. We feel this is not the fault of cardspider but of the
way the networks are run. First of all, cardspider is not and never will be
designed for running huge networks with 100 connected people or more. The
internet traffic it causes for each connected node is just too big, if you build
such huge networks. cardspider is designed to share in small groups of trusted
friends, giving everybody access to all and don't allow any kinds of
restrictions, because such restrictions would only be used by commerical pirates
to sell access to card sharing. For this reason the "no restrictions" policy
was a major design goal of cardspider and this will not be changed.

To understand the following measures to avoid dropouts, you should keep in mind
the cardspider protocol has no concept of routing messages whatsoever. Every
time, someone on the network request control words from a specific ECM, this
request is send to all participants on the network, regardless if they share a
card suitable for this ECM or not. In fact, cardspider doesn't know where in
the network it can find a suitable card, or if there even is one. This is also
the reason cardspider produces huge amounts of data traffic, if a great number
of people is connected to it, each request from each participant is sent to
every other participant. This also means, that if there are several cards of
the same provider in a network, all of those cards decrypt any ECM sent on
the network on parallel, without additional configuration, there is no ecm load
balancing between the cards (remember, cardspider doesn't know, if there are
other cards for the same provider anywhere else on the network). Load balancing
between cards is possible however, but it requires careful configuration and
communication between the owners of those cards.

So, what can you do if you suffer from frequent dropouts on certain channels?
Here's a couple of things you should consider:

1. cardspider is using the udp protocol to forward ECMs and Control Word
responses. The udp protocol by design doesn't guarantee that every packet sent
will reach it's destination. If for any reason a packet can't reach it's
destination, it's simply discarded without notification to the sender. Reasons
can be bad Internet connections (a poorly performing backbone from your ISP)
or network congestions either at your ISP or at your own site (because you're
producing a lot of other internet traffic at the same time). There are several
ways to fix this: Avoid other high volume internet traffic at your own site
(huge downloads etc) while using sharing or setup some traffic shaping that
prefers sharing packets over other internet traffic. If however the cause of 
the packet losses is outside of your area of influence (bad ISP), setup more
than one peer from you to the rest of the network. Remember, each packet is sent
to all your peers, so if you have 2-3 peers you double/triple the chance of one
the packages making it through to the network. Of course, you also double/triple
your cardspider caused internet traffic, so having too many peers is not a good
idea either. You have to experiment to find the number of peers that's right for
you.

2. On big networks, you will at some point overload the cards. 8 people watch
8 different channels of one provider, so all the cards of that provider must
manage to decrypt 8 ECMs in 10 seconds. At some point, the load will be to
much to handle, in this case cardspider starts to discard ECM requests without
ever sending them to the card (specifically, if an ECM request resides in the
queue of a particular card for more than 8 seconds, while the card is busy with
other ECM requests). This is done for two reasons: First, to avoid build up of
a huge ECM queue for one particular card. Second, to avoid sending ECMs to the
card that are now longer necessary to decrypt because the time when the control
words from that ECM were actually meaningful has passed already.
Now, if you have more than one card of a particular provider in the network and
the two people with the cards know each other, you can setup load balancing:
Send ECMs for one set of channels to one card and for another set of channels to
the other card. If you set it up right, you can avoid either card be overloaded
with ECMs as they would be, if you do nothing. This load balancing is sid-based
(service id, some also call it program number), which means you have to pull-up
your channel settings files, look up the service ids of the channels you want to
share from your card and add all of them at the end of the CWS line in
cardspider.cfg.

Example for Canal Digital Nordic:
# This would share:
# SVT1, SVT2, TV4, Kanal 5, TV4 plus, 24, Barnkanalen, med i tv,
# Canal+, Canal+ Film1, Canal+ Film2, C More Film, Canal+ Sport
# basically all channels, that are available on a Swedish Canal+ subscription
CWS = localhost 10000 blah blub 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e lan cardservname 012d:012e:0134:0135:0139:0193:0642:083b:083c:0a8e:0a8f:0bb9:0bc4

Now, cardspider would only ask this card for ECMs that originate from one of the
named channels. All other requests will be ignored, which means they won't
allocate execution time on your card, which in turn gives more time to decrypt
the above channels only. To use it for load balancing, you need a second (or
more) card of course elsewhere in the network that decrypt the other channels,
but not the ones above. There is a second benefit from this feature, you can
avoid your card being asked to decrypt channels, you know it can't, because
you don't subscribe to them. This feature can also be combined with the
EXCLUDE_SERVICE feature of cardserver. The cardspider feature offers an
opt-in list so to speak (decrypt listed channels only, no others), while the
EXCLUDE_SERVICE feature of cardserver offers an opt-out list (decrypt all but
the excluded).
Make sure to write a complete CWS line including the reverse login parameters,
which are usually optional, but not, if you want to use this feature.

* New in cardspider v6.05 and above *
You can also enter a whole range of service ids, for example 0801-0803:080b
would allow sids 0801, 0802, 0803 and 080b.

The sids will also be shown on the debug report from DEBUG_PORT, so you can
check, if everything is setup correctly.

3. cardserver, while capable to handle several cards in one instance, is not
   designed to talk to multiple cards in parallel. This means, while obtaining
   control words from one card, requests to all the other cards handled by the
   same cardserver instance have to wait until the access on the first card is
   finished. This applies also when sending EMM messages to a card. We've seen 
   Conax cards that took as long as 3.3 seconds to process a single EMM message.
   This of course seriously affects how many ECM requests can be handled in a
   limited amount of time. So, in an environment where you expect a lot of ECM
   requests to your cards like when using cardspider in a large spider network,
   you should:
   a) start cardserver multiple times using multiple config files, one for each
      card you're sharing
   b) disable EMM processing (AU) when it is not needed

   Of course when using a sc8in1 device, you have no choice but to use one
   cardserver to access all 8 cards. In this case however, the hardware design
   of the sc8in1 imposes exactly the same restrictions as a single cardserver
   instance used for multiple cards does, so the use of cardserver does not
   introduce any additional restrictions in this case. In high volume card
   sharing applications it's therefore recommended to avoid using the sc8in1.
