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).

However if you suffer from frequent dropouts here are two possibilities:

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
then 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). 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 of the cards to 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 discarded, 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. This 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.

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