Ronald's emu met seca2 card sharing

[Ron]

Hoppy, dit verkeer moet eens in de +/- 30 seconden plaatvinden anders geen beeld. Vandaar ook even die freeze bij rdigital. Dat was waarschijnlijk gewoon een hickup in de internet verbinding.

 

Tox.

[Gast]

kwam door het rebooten van mijn ISA server (firewall).

Hierdoor is/was de verbinding van mijn DB server naar rdigital uitgevallen.

Anders was er dus geheel geen uitval geweest denk ik !

[Gast]

De freeze bleek achteraf gewoon de server die van MikeV die opnieuw opgestart werd ( dus er was eigenlijk helemaal geen freeze). En er is alleen dataverkeer als de client naar een coded channel kijkt, als de client naar een fta kanaal kijkt is er geen dataverkeer.

 

groeten,

rdigital

[Ronaldd]

Citaat:

Wat ik me ook afvraag is of je de client/server verbinding continu nodig hebt, met andere woorden: is er alleen dataverkeer tussen de client/server tijdens het decoderen van een kanaal (als je net zapt) of gaat dit door gedurende een langere tijd en als dat zo is om hoeveel dataverkeer gaat het dan ?
1 Kb/sec ? of 1 Mb/uur ?

Dit kan ook gevolgen hebben voor een server die meerdere clients aan zich heeft hangen ...
De upload is over het algemeen niet zo groot, de client zal daar geen last van hebben maar de server wel.

Op ned. kanalen wordt er ongeveer iedere 15 sec. een paketje gestuurd naar de server. Dit pakettje heeft ong. een grote van 100 bytes excl TCP/IP header. Het antwoord van de server is ongeveer 20 bytes.

De belasting voor de server valt dus wel mee.

Ronald

[Ronaldd]

Wat echt interesant is om te testen is hoeveel mensen kunnen op 1 seca2 kaart. In deze hoek zit de meest kritiche code. De kaart kan nl. maar 1 ECM tegelijk omzetten naar een DCW. De server locked de kaart zolang 1 client er naar schrijfd de andere clients wachten daarop.

 

Wat mij al opgevallen is dat de clients aanzienlijk lagere zap-snelheden krijgen als er meerdere mensen op de kaart 'zitten'. Ook het omzetten van eerste ECM naar DCW komt in de wachtrij, wat een extra 'zap-vertraging' opleverd. Daarna lijkt het allemaal we stabiel te draaien met 3 clients.

 

Ronald

[Romeo_]

Losse phoenix interface + PC als server zetten (windows/linux proggie ??)

En je eigen dreambox bombarderen tot een client is dan misschien stabieler ?

[tCC]

klinkt goed <img src="/ubbthreads/images/graemlins/smile.gif" alt="" />

[Gast]

Als er gekeken word door de client naar een kanaal dat niet gecodeerd is, valt de verbinding vanzelf netjes af. Dus er is geen verkeer als het niet nodig is !

Het testen van meerdere clients op 1 seca kaart willen/moeten we nog goed gaan testen. Huidige manier met 2 clients en codes uit de emu gaat prima.

[Gast]

Misschien maak je best een dedicated server van een dreambox :

 

*) een eerste process zapt continue over alle kanalen van een pakket heen omzo de laatste CW's te bekomen. Deze worden uiteraard gecached.

 

*) een ander process feed deze dan naar de clients op internet (via push of pull, valt nog te bezien)

 

Zo wordt de kaart "optimaal" benut. Enfin, misschien is dit idee al gepost. In that case, move along... <img src="/ubbthreads/images/graemlins/wink.gif" alt="" />

 

Greetz

[hemertje]

Puike gedachte Mcduff <img src="/ubbthreads/images/graemlins/biggthumpup.gif" alt="" />

 

Zo heb je ook geen extra zware belasting op de kaart met meerdere clients! CW's worden dan eens per bv 15sec. uitgelezen en via de cache van de server gerouteerd naar de clients zodat de belasting bij de server ligt en niet op de kaart...

 

Zie ik dit goed? <img src="/ubbthreads/images/graemlins/confused.gif" alt="" />

 

 

<img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" />

 

 

[Gast]

Citaat:

Zie ik dit goed?

Yep. Even een voorbeeld van een pull model:
*) de dedicated server maakt steeds een WWW pagina van de laatste CW's die hij heeft.

*) de clients pullen (of trekken) om de zoveel seconden die pagina

Een voorbeeld van een push systeem:
*) de client connect met de server en registreert zich op een bepaald kanaal.

*) de server zapt voorbij de kanalen. Wanneer hij een nieuwe CW tegenkomt stuurt hij deze door naar alle geregistreerde clients voor dat kanaal.

Ik prefereer persoonlijk het push model omdat de server zelf beslist hoeveel hij stuurt en wanneer. Dit wil zeggen dat hij minder snel overbelast kan geraken. Stel u voor (met het pull model) dat honderden clients tegelijk die pagina willen beginnen afhalen. Deze aanpak spaart trouwens ook een beetje bandbreedte: de client krijgt enkel wat die nodig heeft.

Greetz

[hemertje]

Werk aan de winkel dus <img src="/ubbthreads/images/graemlins/loldev.gif" alt="" />

 

 

 

[Ronaldd]

1 nadeel van het push model, de server moet zelf zappen om zo de ECM's te krijgen. Deze dreambox kan dus niet gebruikt worden om te kijken naar 1 kanaal. Je kan wel meekijken waar de server allemaal heen zapped.

 

Ronald

[Gast]

@Ronaldd,

 

idd het is dus een dedicated server. Ik zou de kijker zelfs niet mee laten kijken, de zap snelheid zou toch te hoog liggen.

 

In principe is het geen kijkdoos meer dan, het is puur een ECM logger en processor die via de kaart CW's decrypt en publiceert. Kan je evengoed doen met een PC in combi met een phoenix/season interface en DVB kaart (om de ECM stream vast te krijgen). De vraag is gewoon met welk platform en ontwikkel-omgeving de programmeur in kwestie het meest vertrouwd is...

 

BYe

[Gast]

Deze oproep is niet toegestaan op dit board.