Pour ce qui est du wording du site web etc, il y a en effet une volonté de rendre le produit accessible mais sachant qu'on veut aussi séduire les sysadmins, il y a également pas mal d'infos dans la FAQ et dans technology (https://infinit.sh/documentation/technology) pour les power users. Aussi, on est en train d'open sourcer les briques de toute notre techno côté client.
Pour le partage de données, on fournit un système de fichiers POSIX (dans la meme veine que NFS, ZFS, ext4 etc.). Tu peux donc tout a faire faire un fopen() sur un fichier qui est stocke via ce système de fichier. La difference avec les autres est que le fichier n’est concrètement pas nécessairement stocke localement, mais distribué entre plusieurs machines qui composent l’infrastructure de stockage: serveur, disque local, cloud etc.
On se base sur UDP ou TCP suivant lequel fonctione le mieux dans ton environnement: blocage par les routeurs etc. En particulier un utilise uTP; le meme algo que Bittorrent
On utilise OpenSSL. Nous n’avons pas redévelopper d’algorithmes maison. On utilise en particulier RSA, principalement en CBC, avec des tailles de clef variables.
Le cout est négligeable en effet. En mode normal, Infinit utilise 0.1% de ton CPU mais ca peut monter a 5-10% si tu effectues énormément d’operations. Pour la bande passante, et bien tout depend de ta capacité réseau. Notre système essaie de l’optimiser pour l’utiliser un maximum.
Tous les protocoles sont prévus pour tolérer les attaques MiM, en chiffrant le traffic avec une clef spécifique par noeud du réseau par exemple.
Tous les fichiers sont découpes en blocs. Chaque bloc est chiffre avec une clef unique puis le bloc est répliqué dans le réseau un nombre de fois dependant du facteur de replication défini par l’administrateur. Donc rien n’est en clair.
Dans un cas extreme où la très grande majorité des noeuds qui stockent sont injoignables, tous les clients vont effectuer leurs requêtes aux meme serveurs, qui vont potentiellement être surcharges fonction du nombre de clients. De la meme manière, dans un cas extreme, certains fichiers pourraient ne plus être accessibles si tous les serveurs qui stockent une réplique sont down. C’est à l’admin de concevoir son infrastructure pour pouvoir tolérer les fautes et continuer à avoir une bonne qualité de service. Infinit fournit la plateforme pour le faire mais chaque environnement (personnel, professionnel etc.) est different.
Le seul rapport c’est que nous utilisons des protocoles peer-to-peer comme Freenet. En revanche, nous fournissons un système de fichiers avec du contrôle d’accès etc. alors que Freenet se concentre sur du partage de fichiers, comme Bitorrent.
Merci pour developpez.com, je n'y avais pas pensé :)
Oui Infinit peut être utilisé par des VMs. D’ailleurs certaines entreprise de hosting l’utilise exactement de cette manière; pour partager un espace de stockage entre des VMs ou migrer des VMs plus rapidement (sans avoir à copier les données). Pour ce qui est de l’interface, nous fournissons du fichier et objet mais pas de bloc car cela nous limiterait en terme de flexibilité sur le contrôle d’accès par exemple.
Tu peux, via les command-line tools, définir plusieurs infrastructure de stockage très facilement. Par exemple, une qui agrege des resources de stockage local (disques et serveurs locaux etc.) ce qui te donnera une très bonne perf. De la meme manière tu pourrais définir une infrastructure basé sur un ou plusieurs clouds, auquel cas le temps d'accès sera moins bon que des ressources locales, mais tu auras d'autre avantages: moins de chance que ces resources deviennent inaccessible etc.
Un ensemble de composants informatiques fonctionnant de concert doivent gérer d'éventuelles défaillances parmi eux. Ces défaillances consisteront alors en la présentation d'informations erronées ou incohérentes. On s'intéresse ici à des problèmes de défaillances, aussi bien matérielles que logicielles, d'origine accidentelle ou malveillante, intervenant pendant l'établissement des informations ou pendant leurs transports d'un composant à l'autre. La gestion de ces composants défectueux est aussi appelée tolérance aux pannes.
Pour nous, prévoir que certains noeuds de stockage peuvent tomber ou être malicieux (pour la réplication par exemple) et les gérer pour que tout fonctionne quand même.
C'est gratuit pour des infrastructures < 30 personnes. On vise surtout les grosses entreprises pour la monétisation avec également des solutions spécifiques (https://infinit.sh/solutions).
Cela dépend de la configuration de ton infrastructure. Tu peux imaginer une infra où 10 personnes stockent localement l’ensemble des fichiers donc dans ce cas là oui. Tu peux aussi imaginer une configuration où les 10 personnes ne sont que des clients et ce sont 3 serveurs qui stockent les fichiers entre eux et dans ce cas là non.
L'identifiant est unique si tu utilises notre Hub oui, sachant que tu peux aussi rester complètement décentralisé (ne pas utiliser notre Hub) et dans ce cas l'identifiant sera unique seulement à l'intérieur de tes réseaux.
Les fichiers sont téléchargés à la volée lors de l'accès oui, d'où l'intérêt par rapport à des solutions comme Dropbox/Bittorrent Sync où tu as besoin de tout cloner sur ton PC et donc avoir suffisamment d'espace disque.
GlusterFS utilise un système de master/slave pour la réplication des données plutôt qu'un système complètement décentralisé comme le notre. Leurs ressources de stockage sont également uniquement locales. Du coup ils partent du principe qu'ils font confiance aux noeuds. Avec Infinit, comme on peut construire des infrastructures hybrides, par exemple avec un stockage local et un stockage cloud (S3, Google Cloud Storage…), on considère que chaque noeud peut tomber (un cloud que tu ne contrôles pas) ou être malicieux, donc notre réplication de données est tolérante aux fautes byzantines. Du coup, puisque tout est décentralisé (data et metadata) et qu’aucune hypothèse n’est faite sur les noeuds, il n’y a aucun single point of failure ou bottleneck.
Oui il y a de la redondance, le facteur de réplication des données est configurable. Tu peux voir plus d'infos sur la techno ici : https://infinit.sh/documentation/technology
Niveau performance, ca va dépendre du type de ton réseau (combien de noeuds, stockage cloud/local…) mais comme les opérations sont asynchrones, l'expérience ressemble vraiment à un système de fichiers natifs.
Tahoe-LAFS: plus ou moins le même concept que nous. On essaie de faire en sorte que ce soit plus facile d'accès pour les développeurs (dans l'utilisation, les interfaces etc) à la manière d'un docker par exemple. On est également plus orienté vers les entreprises.
MogileFS: je ne sais pas si c'est encore maintenu, il y a peu de documentation, liens morts etc. Je ne me lancerai pas dans son installation mais sinon c'est décentralisé de la même manière que nous.
[^] # Re: Forces du bouzin
Posté par cadeuh . En réponse au message On a développé un nouveau système de fichiers en peer-to-peer. Évalué à 2.
Pour ce qui est du wording du site web etc, il y a en effet une volonté de rendre le produit accessible mais sachant qu'on veut aussi séduire les sysadmins, il y a également pas mal d'infos dans la FAQ et dans technology (https://infinit.sh/documentation/technology) pour les power users. Aussi, on est en train d'open sourcer les briques de toute notre techno côté client.
Pour le partage de données, on fournit un système de fichiers POSIX (dans la meme veine que NFS, ZFS, ext4 etc.). Tu peux donc tout a faire faire un fopen() sur un fichier qui est stocke via ce système de fichier. La difference avec les autres est que le fichier n’est concrètement pas nécessairement stocke localement, mais distribué entre plusieurs machines qui composent l’infrastructure de stockage: serveur, disque local, cloud etc.
Merci pour developpez.com, je n'y avais pas pensé :)
[^] # Re: Groupe de stockage par site
Posté par cadeuh . En réponse au message On a développé un nouveau système de fichiers en peer-to-peer. Évalué à 1.
Oui Infinit peut être utilisé par des VMs. D’ailleurs certaines entreprise de hosting l’utilise exactement de cette manière; pour partager un espace de stockage entre des VMs ou migrer des VMs plus rapidement (sans avoir à copier les données). Pour ce qui est de l’interface, nous fournissons du fichier et objet mais pas de bloc car cela nous limiterait en terme de flexibilité sur le contrôle d’accès par exemple.
Tu peux, via les command-line tools, définir plusieurs infrastructure de stockage très facilement. Par exemple, une qui agrege des resources de stockage local (disques et serveurs locaux etc.) ce qui te donnera une très bonne perf. De la meme manière tu pourrais définir une infrastructure basé sur un ou plusieurs clouds, auquel cas le temps d'accès sera moins bon que des ressources locales, mais tu auras d'autre avantages: moins de chance que ces resources deviennent inaccessible etc.
[^] # Re: Manque d'info a vue de nez
Posté par cadeuh . En réponse au message On a développé un nouveau système de fichiers en peer-to-peer. Évalué à 1.
J'ai lu trop rapidement ta question, on ne gère pas encore ça. Les limites sont uniquement par ressource de stockage pour le moment.
[^] # Re: Manque d'info a vue de nez
Posté par cadeuh . En réponse au message On a développé un nouveau système de fichiers en peer-to-peer. Évalué à 2. Dernière modification le 01 février 2016 à 13:28.
https://en.wikipedia.org/wiki/Byzantine_fault_tolerance
Pour nous, prévoir que certains noeuds de stockage peuvent tomber ou être malicieux (pour la réplication par exemple) et les gérer pour que tout fonctionne quand même.
[^] # Re: Manque d'info a vue de nez
Posté par cadeuh . En réponse au message On a développé un nouveau système de fichiers en peer-to-peer. Évalué à 1.
Tu peux spécifier la capacité maximum de chaque ressource de stockage.
[^] # Re: Question
Posté par cadeuh . En réponse au message On a développé un nouveau système de fichiers en peer-to-peer. Évalué à 1.
C'est gratuit pour des infrastructures < 30 personnes. On vise surtout les grosses entreprises pour la monétisation avec également des solutions spécifiques (https://infinit.sh/solutions).
Cela dépend de la configuration de ton infrastructure. Tu peux imaginer une infra où 10 personnes stockent localement l’ensemble des fichiers donc dans ce cas là oui. Tu peux aussi imaginer une configuration où les 10 personnes ne sont que des clients et ce sont 3 serveurs qui stockent les fichiers entre eux et dans ce cas là non.
L'identifiant est unique si tu utilises notre Hub oui, sachant que tu peux aussi rester complètement décentralisé (ne pas utiliser notre Hub) et dans ce cas l'identifiant sera unique seulement à l'intérieur de tes réseaux.
Les fichiers sont téléchargés à la volée lors de l'accès oui, d'où l'intérêt par rapport à des solutions comme Dropbox/Bittorrent Sync où tu as besoin de tout cloner sur ton PC et donc avoir suffisamment d'espace disque.
[^] # Re: Manque d'info a vue de nez
Posté par cadeuh . En réponse au message On a développé un nouveau système de fichiers en peer-to-peer. Évalué à 2.
GlusterFS utilise un système de master/slave pour la réplication des données plutôt qu'un système complètement décentralisé comme le notre. Leurs ressources de stockage sont également uniquement locales. Du coup ils partent du principe qu'ils font confiance aux noeuds. Avec Infinit, comme on peut construire des infrastructures hybrides, par exemple avec un stockage local et un stockage cloud (S3, Google Cloud Storage…), on considère que chaque noeud peut tomber (un cloud que tu ne contrôles pas) ou être malicieux, donc notre réplication de données est tolérante aux fautes byzantines. Du coup, puisque tout est décentralisé (data et metadata) et qu’aucune hypothèse n’est faite sur les noeuds, il n’y a aucun single point of failure ou bottleneck.
Qu'entends-tu par quota? Quota d'écriture?
[^] # Re: Manque d'info a vue de nez
Posté par cadeuh . En réponse au message On a développé un nouveau système de fichiers en peer-to-peer. Évalué à 4.
Oui il y a de la redondance, le facteur de réplication des données est configurable. Tu peux voir plus d'infos sur la techno ici : https://infinit.sh/documentation/technology
Niveau performance, ca va dépendre du type de ton réseau (combien de noeuds, stockage cloud/local…) mais comme les opérations sont asynchrones, l'expérience ressemble vraiment à un système de fichiers natifs.
Tahoe-LAFS: plus ou moins le même concept que nous. On essaie de faire en sorte que ce soit plus facile d'accès pour les développeurs (dans l'utilisation, les interfaces etc) à la manière d'un docker par exemple. On est également plus orienté vers les entreprises.
MogileFS: je ne sais pas si c'est encore maintenu, il y a peu de documentation, liens morts etc. Je ne me lancerai pas dans son installation mais sinon c'est décentralisé de la même manière que nous.