140 seconds remaining...

par **agité** » 05 nov. 2009, 11:25

Comme dit Fuzzyline, ils ont beaucoup plus de succès que tu penses

Mais à leur place, je mettrais un système d'attente aléatoire.
Exemple: un rand() entre 30 secondes et une minute.
Comme ça, au moins, cela servira vraiment a quelque-chose...

++ Bon Week-end

[EDIT]
Petit bémol au sujet du système d'attente aléatoire.
Cela demanderait surtout a être testé...

Oui et d'autre pars celui qui ne souhaite pas attendre 1 minute va refresh 1 fois et retombe sur la moitié du temps, tu me diras c'est débile car tu gagne quelque secondes au final, mais du coup ça fait encore plus de demande au niveau serveur etc ...

par **MainMa** » 01 nov. 2009, 13:36

Ah oui, c'est bien noté sur les robots. J'ai pas du tout pensé à ça, mais c'est vrai que c'est une solution très efficace (surtout qu'on ne peut télécharger ou attendre à télécharger plusieurs fichiers en même temps depuis une même adresse IP).

par **Hywan** » 01 nov. 2009, 13:13

Hey

,

Pour deux raisons principales.
La première est qu'on te propose un lien direct si tu es membre (et que tu payes), et un lien actif n secondes plus tard. Le but est de te rendre impatient et de te faire passer membre.
La seconde est de faire craquer les robots. Les robots doivent avoir du rendement et donc ils vont vite. Ils cliquent/suivent tous les liens actifs et quittent la page. Cette opération prend moins d'une seconde. Donc si tu fais attendre ne serait-ce que 5 sec, tu as sauvé le lien du robot.

C'est un double enjeu. Mais c'est surtout pour la première raison qu'un tel dispositif existe

.

par **thehawk** » 26 oct. 2009, 17:32

Tout a un cout ! le rajout de matériel nécessite un investissement , de la gestion etc.

Donc bref, c'est une histoire de sous

@ Drake , sous rapidShare le temps d'attente n'est pas fixe ou du moins je ne l'es pas remarqué.

Bye Hawk

par **MainMa** » 24 oct. 2009, 18:59

Pardon, j'ai mal formulé mon message précédent.
Qu'ils ont du succès, ça, je m'en doute pas du tout. Par contre, pour eux, le succès, ça doit pas poser de problèmes de nature à les inciter à limiter l'accès des utilisateurs au service pour ne pas être surchargés. Juste ça.

par **Dr@ke** » 24 oct. 2009, 18:01

Comme dit Fuzzyline, ils ont beaucoup plus de succès que tu penses

Mais à leur place, je mettrais un système d'attente aléatoire.
Exemple: un rand() entre 30 secondes et une minute.
Comme ça, au moins, cela servira vraiment a quelque-chose...

++ Bon Week-end

[EDIT]
Petit bémol au sujet du système d'attente aléatoire.
Cela demanderait surtout a être testé...

par **FuZZyLine** » 24 oct. 2009, 17:45

Bonjour.
Merci d'avoir répondu.
J'en déduis donc que c'est bel et bien l'incitation aux offres payantes qui en est la cause. [*]Quant au fait d'être victime de son succès, j'imagine que ça peut difficilement être le cas pour des sites comme ça (et pour des gros sites en général), vu que un, c'est justement le but d'avoir la plus grande quantité de visiteurs, et deux, le plus souvent, lorsqu'ils ont plus d'utilisateurs qu'ils ne peuvent gérer matériellement, ils ajoutent du matériel, point.
Bon, merci encore et bon week-end à tous.

[*]Détrompe toi... ca peut arriver et c'est peut-être même le cas lol

@+ bon we

par **MainMa** » 24 oct. 2009, 17:22

Bonjour.

Merci d'avoir répondu.
J'en déduis donc que c'est bel et bien l'incitation aux offres payantes qui en est la cause. Quant au fait d'être victime de son succès, j'imagine que ça peut difficilement être le cas pour des sites comme ça (et pour des gros sites en général), vu que un, c'est justement le but d'avoir la plus grande quantité de visiteurs, et deux, le plus souvent, lorsqu'ils ont plus d'utilisateurs qu'ils ne peuvent gérer matériellement, ils ajoutent du matériel, point.

Bon, merci encore et bon week-end à tous.

par **Dr@ke** » 24 oct. 2009, 13:26

J'avais réfléchis à un système similaire pour un script mails.
Système que j'ai vite abandonné car finalement complètement inefficace comme protection anti-flood.

Exemple:
Si 1000 personnes veulent envoyer un mail à 10h00
-> le script les fait tous attendre 1 minute
-> conséquence: 1000 personnes enverront le mail à 10h01 en même temps.
Même chose pour un système de téléchargement, cela ne préserve donc au final rien au niveau de la bande passante.
Par contre, dans une boucle utilisée pour envoyer une newsletter, l'utilisation de la fonction sleep prend toute sa puissance et devient vraiment efficace.

C'est donc pour cette raison, qu'il sont obligés d'ajouter des restrictions supplémentaires, comme restriction par adresse IP sur le nombre de téléchargements simultanés et le nombre de téléchargements maximum en un temps déterminé...
Ces restrictions, par contre, préserve un peu la bande passante...
Mais au final, elles gênent considérablement les utilisateurs, donc la création d'un espace membre protégé libre de toutes restrictions devient quasiment obligatoire.

Tout ca pour dire, que je pense qu'à la base, victime de leur succès, ils n'ont pas eu vraiment le choix.
Seul bémol, la restriction qui fait attendre 1 minute ne sert a rien en dehors d'une boucle, enfin elle sert juste a gêner l'utilisateur en réalité et donc peut-être a l'inciter a prendre un compte payant.

Enfin , c'est juste mon avis.

par **FuZZyLine** » 24 oct. 2009, 09:19

Bonjour.
Il y a une chose que je ne comprend pas et j'aimerai avoir vos explications sur ce point.
Un certain nombre de sites, notamment des sites communautaires de téléchargement type Rapidshare et compagnie, font attendre l'utilisateur un certain nombre de secondes ou minutes avant de lui faire bénéficier de ses services (type on attend deux minutes avant de pouvoir télécharger un fichier).
Qu'est-ce qui motive une telle politique ? Est-ce que c'est juste pour inciter l'utilisateur à payer ?
Car j'ai réfléchis dessus, mais à part ça (et encore, je sais pas si ça incite tellement), je ne vois que des inconvénients à la chose (frein à la popularité du site, baisse de l'utilisation, etc.). Et vous ?

Salut,

Je ne sais si cela peut t'apporter un soupcon de réponse:

Source http://fr.wikipedia.org/wiki/RapidShare

Les utilisateurs du service gratuit doivent attendre pour pouvoir télécharger (en général 2 ou 3 minutes).

L'enregistrement payant offre de nombreux avantages, tels que la possibilité de procéder à
plusieurs téléchargements simultanés ou encore d'interrompre puis de redémarrer rapidement
et facilement les transferts. Les comptes payants sont limités à un maximum sur une période
glissante de 5 jours, dans le but de freiner le partage de comptes, particulièrement à travers
l'utilisation de sites web dédiés. Autrefois de 20 Go, cette limitation est cependant régulièrement
rehaussée (25 Go à partir du 9 février 2007[5] puis 50 Go à partir du 3 juin 2008[6]).

Tu as plus ou moins raison. Les 2/3 minutes est un temps de latence (j'imagine) permétant une
certaine préservation de la BP côte gratuit, bande passante qui est bien plus élevée côté payant.
Ca permet à ceux en cours de DL de finir puis quand c'est fait un autre vient prendre la place.
Système de pile... (peu ou pas controllée) - je ne suis pas spécialiste donc c'est juste mon avis qui,
du reste, est probablement faux mais c'est possible.

Sur cette piste... @+ et bon DL

par **MainMa** » 24 oct. 2009, 04:30

Bonjour.

Il y a une chose que je ne comprend pas et j'aimerai avoir vos explications sur ce point.

Un certain nombre de sites, notamment des sites communautaires de téléchargement type Rapidshare et compagnie, font attendre l'utilisateur un certain nombre de secondes ou minutes avant de lui faire bénéficier de ses services (type on attend deux minutes avant de pouvoir télécharger un fichier).

Qu'est-ce qui motive une telle politique ? Est-ce que c'est juste pour inciter l'utilisateur à payer ?

Car j'ai réfléchis dessus, mais à part ça (et encore, je sais pas si ça incite tellement), je ne vois que des inconvénients à la chose (frein à la popularité du site, baisse de l'utilisation, etc.). Et vous ?

140 seconds remaining...

Répondre

Étendre la vue Revue du sujet : 140 seconds remaining...

Re: 140 seconds remaining...

Re: 140 seconds remaining...

Re: 140 seconds remaining...

Re: 140 seconds remaining...

Re: 140 seconds remaining...

Re: 140 seconds remaining...

Re: 140 seconds remaining...

Re: 140 seconds remaining...

Re: 140 seconds remaining...

Re: 140 seconds remaining...

140 seconds remaining...