De plus en plus, pour pallier aux super-calculateurs, on utilise les
ressources de milliers de PC volontaires pour effectuer les calculs
consommateurs.
Cette idée ne pourrait-elle pas être reprise au niveau de l'hébergement des
sites ? Je m'explique : pourquoi ne pas créer une association à but non
lucrative ou chacun de ses membres mettrait à disposition certaines
ressources de son ordinateur afin de créer un super serveur virtuel, en
contrepartie d'un hébergement gratuit sur ce derbnier.
Techniquement, je ne sais pas si cette idée est viable, mais cela me parait
un concept interessant en théorie...
Techniquement, c'est très inadapté au WWW, car les contenus devraient être répartis aussi. Les calculs par GRID exploitent le fait que le ratio temps-de-calcul/données-transférées est très haut. C'est exactement l'inverse pour un serveur WWW classique.
Sam
Et donc on ne peux pas imaginer de repartir et compresser le contenu ?
Au risque de me répéter, techniquement c'est faisable il suffit de trouver une bonne solution.
Techniquement, c'est très inadapté au WWW, car les contenus devraient
être répartis aussi. Les calculs par GRID exploitent le fait que le
ratio temps-de-calcul/données-transférées est très haut. C'est
exactement l'inverse pour un serveur WWW classique.
Sam
Et donc on ne peux pas imaginer de repartir et compresser le contenu ?
Au risque de me répéter, techniquement c'est faisable il suffit de
trouver une bonne solution.
Techniquement, c'est très inadapté au WWW, car les contenus devraient être répartis aussi. Les calculs par GRID exploitent le fait que le ratio temps-de-calcul/données-transférées est très haut. C'est exactement l'inverse pour un serveur WWW classique.
Sam
Et donc on ne peux pas imaginer de repartir et compresser le contenu ?
Au risque de me répéter, techniquement c'est faisable il suffit de trouver une bonne solution.
Eriam Schaffter
À la différence du modèle d'Akamai, il faut alors utiliser un protocole différent de l'HTTP classique en installant un logiciel supplémentaire. Les logiciels de P2P vérifient tous la cohérence des données reçues par l'utilisation de sommes de contrôle et permettent de récupérer les données de plusieurs sources en parallèle, ce qu'HTTP ne permet pas dans sa version actuelle.
Sam
Est ce que Http-Range ne permet pas de récupérer une partie d'un fichier depuis un serveur ? Et donc d'envisager des telechargement en parallelle ?
Je ne vois pas en quoi Http ne pourrait pas être utilisé dans ce cas, et quand bien meme, si il faut un protocole maison ou est le soucis ?
Je vois un intérêt évident à répartir/distribuer le stockage sur un réseau P2P, le fait est qu'il faut une passerelle entre ce P2P et le web mais ca c'est faisable non ?
À la différence du modèle d'Akamai, il faut alors utiliser un
protocole différent de l'HTTP classique en installant un logiciel
supplémentaire. Les logiciels de P2P vérifient tous la cohérence des
données reçues par l'utilisation de sommes de contrôle et permettent
de récupérer les données de plusieurs sources en parallèle, ce qu'HTTP
ne permet pas dans sa version actuelle.
Sam
Est ce que Http-Range ne permet pas de récupérer une partie d'un fichier
depuis un serveur ? Et donc d'envisager des telechargement en parallelle ?
Je ne vois pas en quoi Http ne pourrait pas être utilisé dans ce cas, et
quand bien meme, si il faut un protocole maison ou est le soucis ?
Je vois un intérêt évident à répartir/distribuer le stockage sur un
réseau P2P, le fait est qu'il faut une passerelle entre ce P2P et le web
mais ca c'est faisable non ?
À la différence du modèle d'Akamai, il faut alors utiliser un protocole différent de l'HTTP classique en installant un logiciel supplémentaire. Les logiciels de P2P vérifient tous la cohérence des données reçues par l'utilisation de sommes de contrôle et permettent de récupérer les données de plusieurs sources en parallèle, ce qu'HTTP ne permet pas dans sa version actuelle.
Sam
Est ce que Http-Range ne permet pas de récupérer une partie d'un fichier depuis un serveur ? Et donc d'envisager des telechargement en parallelle ?
Je ne vois pas en quoi Http ne pourrait pas être utilisé dans ce cas, et quand bien meme, si il faut un protocole maison ou est le soucis ?
Je vois un intérêt évident à répartir/distribuer le stockage sur un réseau P2P, le fait est qu'il faut une passerelle entre ce P2P et le web mais ca c'est faisable non ?
Samuel Tardieu
"Eriam" == Eriam Schaffter writes:
Eriam> Au risque de me répéter, techniquement c'est faisable il suffit Eriam> de trouver une bonne solution.
Tout à fait. Le problème réside dans l'interactivité (et pas le temps-réel contrairement à ce qui a été écrit, ce concept ayant une définition bien précise qui ne correspond pas au web aujourd'hui). Les systèmes P2P permettent une augmentation du débit, pas une augmentation de l'interactivité.
Sam -- Samuel Tardieu -- -- http://www.rfc1149.net/sam
Eriam> Au risque de me répéter, techniquement c'est faisable il suffit
Eriam> de trouver une bonne solution.
Tout à fait. Le problème réside dans l'interactivité (et pas le
temps-réel contrairement à ce qui a été écrit, ce concept ayant une
définition bien précise qui ne correspond pas au web aujourd'hui). Les
systèmes P2P permettent une augmentation du débit, pas une
augmentation de l'interactivité.
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam
Eriam> Au risque de me répéter, techniquement c'est faisable il suffit Eriam> de trouver une bonne solution.
Tout à fait. Le problème réside dans l'interactivité (et pas le temps-réel contrairement à ce qui a été écrit, ce concept ayant une définition bien précise qui ne correspond pas au web aujourd'hui). Les systèmes P2P permettent une augmentation du débit, pas une augmentation de l'interactivité.
Sam -- Samuel Tardieu -- -- http://www.rfc1149.net/sam
F. Senault
Techniquement, c'est très inadapté au WWW, car les contenus devraient être répartis aussi. Les calculs par GRID exploitent le fait que le ratio temps-de-calcul/données-transférées est très haut. C'est exactement l'inverse pour un serveur WWW classique.
Et donc on ne peux pas imaginer de repartir et compresser le contenu ?
C'est vrai, rajoutons du temps de calcul pour rien, ça fera plaisir au client final...
Fred -- Ocean pulls me close And whispers in my ear The destiny I've chose all becoming clear The currents have their say The time is drawing near washes me away Makes me disappear And I descend from grace In arms of undertow I will take my place In... (Nine Inch Nails, The Great Below)
Techniquement, c'est très inadapté au WWW, car les contenus devraient
être répartis aussi. Les calculs par GRID exploitent le fait que le
ratio temps-de-calcul/données-transférées est très haut. C'est
exactement l'inverse pour un serveur WWW classique.
Et donc on ne peux pas imaginer de repartir et compresser le contenu ?
C'est vrai, rajoutons du temps de calcul pour rien, ça fera plaisir au
client final...
Fred
--
Ocean pulls me close And whispers in my ear The destiny I've chose all
becoming clear The currents have their say The time is drawing near
washes me away Makes me disappear And I descend from grace In arms of
undertow I will take my place In... (Nine Inch Nails, The Great Below)
Techniquement, c'est très inadapté au WWW, car les contenus devraient être répartis aussi. Les calculs par GRID exploitent le fait que le ratio temps-de-calcul/données-transférées est très haut. C'est exactement l'inverse pour un serveur WWW classique.
Et donc on ne peux pas imaginer de repartir et compresser le contenu ?
C'est vrai, rajoutons du temps de calcul pour rien, ça fera plaisir au client final...
Fred -- Ocean pulls me close And whispers in my ear The destiny I've chose all becoming clear The currents have their say The time is drawing near washes me away Makes me disappear And I descend from grace In arms of undertow I will take my place In... (Nine Inch Nails, The Great Below)
Eriam Schaffter
C'est vrai, rajoutons du temps de calcul pour rien, ça fera plaisir au client final...
Pour rien ?
Bah
C'est vrai, rajoutons du temps de calcul pour rien, ça fera plaisir au
client final...
C'est vrai, rajoutons du temps de calcul pour rien, ça fera plaisir au client final...
Pour rien ?
Bah
Eriam Schaffter
Tout à fait. Le problème réside dans l'interactivité (et pas le temps-réel contrairement à ce qui a été écrit, ce concept ayant une définition bien précise qui ne correspond pas au web aujourd'hui). Les systèmes P2P permettent une augmentation du débit, pas une augmentation de l'interactivité.
Oui nous sommes d'accord, pour distribuer du contenu statique pas de soucis mais dès que cela devient dynamique c'est compliqué.
C'est pourquoi je pense que dans un premier temps c'est plus simple de le considerer comme un medium de stockage.
D'ailleurs alléger un serveur web de sa charge de contenu statique c'est deja beaucoup. Je pense qu'il est envisageable ensuite de servir du contenu dynamique derriere une petite ligne adsl.
Pour ce qui est des applications il y a des hollandais qui font du travail dans ce sens http://www.globule.org/
Cependant ils ont fait le choix de coller a apache ce qui est un peu dommage, en meme temps c'est deja compliqué de distribuer des applications mais alors si en plus elle doivent pouvoir se lancer sur différentes plateformes ca devient chaud et contraignant pour les gens qui ecrivent les applications.
Tout à fait. Le problème réside dans l'interactivité (et pas le
temps-réel contrairement à ce qui a été écrit, ce concept ayant une
définition bien précise qui ne correspond pas au web aujourd'hui). Les
systèmes P2P permettent une augmentation du débit, pas une
augmentation de l'interactivité.
Oui nous sommes d'accord, pour distribuer du contenu statique pas de
soucis mais dès que cela devient dynamique c'est compliqué.
C'est pourquoi je pense que dans un premier temps c'est plus simple de
le considerer comme un medium de stockage.
D'ailleurs alléger un serveur web de sa charge de contenu statique c'est
deja beaucoup. Je pense qu'il est envisageable ensuite de servir du
contenu dynamique derriere une petite ligne adsl.
Pour ce qui est des applications il y a des hollandais qui font du
travail dans ce sens http://www.globule.org/
Cependant ils ont fait le choix de coller a apache ce qui est un peu
dommage, en meme temps c'est deja compliqué de distribuer des
applications mais alors si en plus elle doivent pouvoir se lancer sur
différentes plateformes ca devient chaud et contraignant pour les gens
qui ecrivent les applications.
Tout à fait. Le problème réside dans l'interactivité (et pas le temps-réel contrairement à ce qui a été écrit, ce concept ayant une définition bien précise qui ne correspond pas au web aujourd'hui). Les systèmes P2P permettent une augmentation du débit, pas une augmentation de l'interactivité.
Oui nous sommes d'accord, pour distribuer du contenu statique pas de soucis mais dès que cela devient dynamique c'est compliqué.
C'est pourquoi je pense que dans un premier temps c'est plus simple de le considerer comme un medium de stockage.
D'ailleurs alléger un serveur web de sa charge de contenu statique c'est deja beaucoup. Je pense qu'il est envisageable ensuite de servir du contenu dynamique derriere une petite ligne adsl.
Pour ce qui est des applications il y a des hollandais qui font du travail dans ce sens http://www.globule.org/
Cependant ils ont fait le choix de coller a apache ce qui est un peu dommage, en meme temps c'est deja compliqué de distribuer des applications mais alors si en plus elle doivent pouvoir se lancer sur différentes plateformes ca devient chaud et contraignant pour les gens qui ecrivent les applications.
Patrick Mevzek
Les logiciels de P2P vérifient tous la cohérence des données reçues par l'utilisation de sommes de contrôle et permettent de récupérer les données de plusieurs sources en parallèle, ce qu'HTTP ne permet pas dans sa version actuelle.
Plusieurs sources en parallèle, c'est un problème côté client (il peut ouvrir plusieurs connexions simultanées vers le même serveur et/ou faire du pipelining).
Pour les sommes de contrôle, même en HTTP, ca existe, cf Content-Digest (sous-développé et sous-utilisé, d'accord, mais il existe)
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Les logiciels de P2P vérifient tous la cohérence des
données reçues par l'utilisation de sommes de contrôle et permettent
de récupérer les données de plusieurs sources en parallèle, ce qu'HTTP
ne permet pas dans sa version actuelle.
Plusieurs sources en parallèle, c'est un problème côté client (il peut
ouvrir plusieurs connexions simultanées vers le même serveur et/ou faire
du pipelining).
Pour les sommes de contrôle, même en HTTP, ca existe, cf Content-Digest (sous-développé et
sous-utilisé, d'accord, mais il existe)
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Les logiciels de P2P vérifient tous la cohérence des données reçues par l'utilisation de sommes de contrôle et permettent de récupérer les données de plusieurs sources en parallèle, ce qu'HTTP ne permet pas dans sa version actuelle.
Plusieurs sources en parallèle, c'est un problème côté client (il peut ouvrir plusieurs connexions simultanées vers le même serveur et/ou faire du pipelining).
Pour les sommes de contrôle, même en HTTP, ca existe, cf Content-Digest (sous-développé et sous-utilisé, d'accord, mais il existe)
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Patrick Mevzek
Est ce que Http-Range ne permet pas de récupérer une partie d'un fichier depuis un serveur ? Et donc d'envisager des telechargement en parallelle ?
C'est ce que font les ``accélérateurs'' de téléchargement, en se connectant plusieurs fois en parallèle et en demandant des bouts différents (ce qui n'accélère réellement au final que si on ne sature pas la bande passante)
Cependant un serveur web n'est pas obligé d'honorer les requêtes partielles, il me semble.
Je vois un intérêt évident à répartir/distribuer le stockage sur un réseau P2P, le fait est qu'il faut une passerelle entre ce P2P et le web mais ca c'est faisable non ?
Je crois que HP ou IBM, dans ses laboratoires de recherche avait fait exactement cela. Je l'ai lu il y a bien un an, impossible de vous resortir plus de détails de mon cerveau.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Est ce que Http-Range ne permet pas de récupérer une partie d'un fichier
depuis un serveur ? Et donc d'envisager des telechargement en parallelle ?
C'est ce que font les ``accélérateurs'' de téléchargement, en se
connectant plusieurs fois en parallèle et en demandant des bouts
différents (ce qui n'accélère réellement au final que si on ne sature
pas la bande passante)
Cependant un serveur web n'est pas obligé d'honorer les requêtes
partielles, il me semble.
Je vois un intérêt évident à répartir/distribuer le stockage sur un
réseau P2P, le fait est qu'il faut une passerelle entre ce P2P et le web
mais ca c'est faisable non ?
Je crois que HP ou IBM, dans ses laboratoires de recherche avait fait
exactement cela. Je l'ai lu il y a bien un an, impossible de vous resortir
plus de détails de mon cerveau.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Est ce que Http-Range ne permet pas de récupérer une partie d'un fichier depuis un serveur ? Et donc d'envisager des telechargement en parallelle ?
C'est ce que font les ``accélérateurs'' de téléchargement, en se connectant plusieurs fois en parallèle et en demandant des bouts différents (ce qui n'accélère réellement au final que si on ne sature pas la bande passante)
Cependant un serveur web n'est pas obligé d'honorer les requêtes partielles, il me semble.
Je vois un intérêt évident à répartir/distribuer le stockage sur un réseau P2P, le fait est qu'il faut une passerelle entre ce P2P et le web mais ca c'est faisable non ?
Je crois que HP ou IBM, dans ses laboratoires de recherche avait fait exactement cela. Je l'ai lu il y a bien un an, impossible de vous resortir plus de détails de mon cerveau.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Eriam Schaffter
C'est ce que font les ``accélérateurs'' de téléchargement, en se connectant plusieurs fois en parallèle et en demandant des bouts différents (ce qui n'accélère réellement au final que si on ne sature pas la bande passante)
Cependant un serveur web n'est pas obligé d'honorer les requêtes partielles, il me semble.
Oui mais on peut télécharger plein de morceaux depuis plein de serveurs web je pense (non testé).
Je crois que HP ou IBM, dans ses laboratoires de recherche avait fait exactement cela. Je l'ai lu il y a bien un an, impossible de vous resortir plus de détails de mon cerveau.
Comme quoi c'est pas tout a fait idiot comme idée. Je pense que les hébergeurs pourraient s'y intéresser.
C'est ce que font les ``accélérateurs'' de téléchargement, en se
connectant plusieurs fois en parallèle et en demandant des bouts
différents (ce qui n'accélère réellement au final que si on ne sature
pas la bande passante)
Cependant un serveur web n'est pas obligé d'honorer les requêtes
partielles, il me semble.
Oui mais on peut télécharger plein de morceaux depuis plein de serveurs
web je pense (non testé).
Je crois que HP ou IBM, dans ses laboratoires de recherche avait fait
exactement cela. Je l'ai lu il y a bien un an, impossible de vous resortir
plus de détails de mon cerveau.
Comme quoi c'est pas tout a fait idiot comme idée. Je pense que les
hébergeurs pourraient s'y intéresser.
C'est ce que font les ``accélérateurs'' de téléchargement, en se connectant plusieurs fois en parallèle et en demandant des bouts différents (ce qui n'accélère réellement au final que si on ne sature pas la bande passante)
Cependant un serveur web n'est pas obligé d'honorer les requêtes partielles, il me semble.
Oui mais on peut télécharger plein de morceaux depuis plein de serveurs web je pense (non testé).
Je crois que HP ou IBM, dans ses laboratoires de recherche avait fait exactement cela. Je l'ai lu il y a bien un an, impossible de vous resortir plus de détails de mon cerveau.
Comme quoi c'est pas tout a fait idiot comme idée. Je pense que les hébergeurs pourraient s'y intéresser.
Mickaël Wolff
Et alors ? Je peux citer un paquet d'applications temps réel fonctionnant sur la base d'une architecture distribuée. La notion a bien changée depuis qu'on me l'a enseignée en cours
Et alors ? Je peux citer un paquet d'applications temps réel
fonctionnant sur la base d'une architecture distribuée.
La notion a bien changée depuis qu'on me l'a enseignée en cours
Et alors ? Je peux citer un paquet d'applications temps réel fonctionnant sur la base d'une architecture distribuée. La notion a bien changée depuis qu'on me l'a enseignée en cours
