Que feriez-vous utiliser pour mettre en œuvre un serveur de fichiers rapide et léger?

Question

Je dois avoir dans le cadre d'une application de bureau, un serveur de fichiers qui devrait répondre le plus rapidement possible de déposer des demandes de transfert (de clients distants, généralement situés sur le même réseau local). Il y aura beaucoup de demandes de fichiers pour les petits fichiers de taille. Le serveur doit être en mesure de fournir à la fois des services de téléchargement et de téléchargement.

Je ne suis pas serré à une technologie particual donc je suis ouvert à tout langage de programmation, des boîtes à outils, les bibliothèques aussi longtemps qu'ils peuvent fonctionner sur Windows.

Mon point de départ est d'aller avec un C / C ++ en utilisant la mise en œuvre Sockets Windows ou utiliser les services offerts par les bibliothèques telles que Boost (ASIO ou tel). J'ai aussi pensé à Erlang, mais que je vais devoir apprendre et donc les avantages de performance devraient justifier le temps de développement a augmenté en raison d'avoir à apprendre la langue.

PLUS TARD EDIT: J'apprécie les réponses qui disent utiliser FTP ou HTTP ou essentiellement tout ce qui a déjà été créé, mais étant donné que vous voulez toujours écrire un à partir de zéro, que feriez-vous

?

Answer 1

Pour les envois fréquents de petits fichiers, le meilleur moyen serait de mettre en œuvre votre propre protocole propriétaire, mais cela nécessiterait une quantité considérable de travail - et aussi serait non standard, ce qui signifie l'intégration future serait difficile à moins que vous êtes capable de mettre en œuvre le protocole dans un client vous soutenez. Si vous choisissez de le faire de toute façon, c'est ma suggestion pour un protocole simple:

1. Commande: 1 octet pour identifier ce qui va être fait. (0x01 pour la demande de téléchargement, 0x02 de la demande de téléchargement, 0x11 pour la réponse de téléchargement, 0x12 pour la réponse de téléchargement, etc.)
2. Nom du fichier: peut être de taille fixe ou préfixé par un octet pour la longueur (en supposant que le nom est inférieure à 255 octets)
3. checksum, MD5 par exemple (si la demande de téléchargement ou d'une réponse de téléchargement)
4. Taille du fichier (si la demande de téléchargement ou d'une réponse de téléchargement)
5. charge utile (si la demande de téléchargement ou d'une réponse de téléchargement)

Cela pourrait être mis en œuvre sur une socket TCP simple. Vous pouvez également utiliser UDP, ce qui évite le coût d'établissement d'une connexion, mais dans ce cas, vous devez traiter le contrôle de retransmission.

Avant de décider de mettre en œuvre votre propre protocole, un coup d'oeil dans les bibliothèques HTTP comme libcurl, vous pouvez faire votre utilisation du serveur des commandes standard HTTP GET comme pour le téléchargement et POST pour le téléchargement. Cela permettrait d'économiser beaucoup de travail et vous serez en mesure de tester le téléchargement avec un navigateur Web.

Une autre suggestion pour améliorer la performance consiste à utiliser comme référentiel de fichiers non le système de fichiers, mais quelque chose comme SQLite. Vous pouvez créer une seule table contenant une colonne ombles le nom de fichier et une colonne blob pour le contenu du fichier. Étant donné que SQLite est léger et fait une mise en cache efficace, vous aurez la plupart du temps à éviter la surcharge d'accès au disque.

Je suppose que vous ne avez pas besoin d'authentification du client.

Enfin: bien que C ++ est votre préférence pour vous donner la vitesse brute de code natif, ce qui est rarement le goulot d'étranglement majeur dans ce type d'application. Sera très probablement l'accès au disque et la bande passante du réseau. Je mentionne cela parce que Java vous serez probablement en mesure de faire une servlet pour faire exactement la même chose (en utilisant HTTP GET pour le téléchargement et POST pour le téléchargement) avec moins de 100 lignes de code. Utilisez Derby au lieu de SQLite dans ce cas, mettez servlet dans un conteneur (Tomcat, Glassfish, etc.) et il est fait.

Answer 2

Pourquoi ne pas simplement aller avec FTP ? Vous devriez être en mesure de trouver une implémentation serveur adéquate dans toutes les langues et les bibliothèques d'accès client aussi.

On dirait que beaucoup de réinvention de la roue. Certes, FTP n'est pas idéal, et a quelques taches bizarres, mais ... il est là, il est standard, bien connu et déjà très largement mis en œuvre.

Answer 3

Si toutes les machines fonctionnent sous Windows sur le même réseau local, pourquoi ne vous besoin d'un serveur du tout? Pourquoi pas utiliser simplement le partage de fichiers Windows?

Answer 4

Je suggère de ne pas utiliser FTP ou SFTP, ou toute autre technique orienté connexion. Au lieu de cela, optez pour un protocole technique ou sans connexion.

La raison en est que, si vous avez besoin d'un bon nombre de petits fichiers à charger ou téléchargés, et la réponse doit être aussi rapide que possible, vous voulez éviter le coût de la mise en place et la destruction des connexions.

Je suggère que vous regardez soit en utilisant une implémentation existante ou la mise en œuvre de votre propre serveur HTTP ou HTTPS / service.

Answer 5

Vos goulots d'étranglement sont susceptibles de provenir de l'une des sources suivantes:

• Harddisk E / S - Le WD VelociRaptor est censé avoir une vitesse d'accès aléatoire d'environ 100 Mo / s. En outre, il est important que vous définissez comme RAID0,1,5 ou ce nots. Certains lisent rapidement, mais écrire lent. Compromis.

• E / S réseau - En supposant que vous avez les plus rapides harddisks dans une configuration RAID rapide, sauf si vous utilisez Gbit E / S, votre réseau sera lente. Si vos tuyaux sont grandes, vous avez encore besoin de lui fournir des données.

• cache de mémoire - La mémoire cache en système de fichiers devra être assez grand pour tout le tampon E / S réseau afin qu'il ne vous ralentit pas. Cela exigera de grandes quantités de mémoire pour le genre de travail que vous regardez.

• structure du système de fichiers - En supposant que vous avez gigaoctets de mémoire, le goulot d'étranglement sera très probablement la structure de données que vous utilisez pour le système de fichiers. Si la structure du système de fichiers est lourd, il vous ralentir.

En supposant que tous les autres problèmes sont résolus, alors vous inquiétez-vous au sujet de votre application elle-même. Notez que la plupart des goulots d'étranglement sont hors de votre contrôle logiciel. Par conséquent, si vous le code en C / C ++ ou utiliser des bibliothèques spécifiques, vous serez toujours à la merci du système d'exploitation et de matériel.

Answer 6

On dirait que vous devez utiliser un SFTP (SSH) , il est un pare-feu / sécurité NAT, sécurisé et déjà fait ce que vous voulez et plus. Vous pouvez également utiliser le fichier SAMBA ou Windows partage pour une mise en œuvre encore plus simple.

Answer 7

Pourquoi ne pas utiliser quelque chose qui existe, par exemple, un serveur Web normale gère un grand nombre de petits fichiers (images) très bien et rapide.

Et beaucoup de gens déjà passé du temps dans l'optimisation du code.

Le second avantage est que le transfert se fait avec HTTP qui est un protocole établi. Et est facilement à SSL si basculé vous avez besoin d'une plus grande sécurité.

Pour les téléchargements, ils sont également aucun problème avec un module de script ou sur mesure - avec la même méthode que vous pouvez également ajouter l'autorisation

.

Tant que vous n'avez pas besoin de rechercher dynamiquement les fichiers que je suppose que ce serait l'une des meilleures solutions.

Answer 8

Il est une nouvelle partie à une application de bureau existant? Quel est l'objectif du serveur? Est-il protéger les fichiers qui sont téléchargés / téléchargés et fournir l'authentification et / ou d'une autorisation? Prévoit-il une sorte de structure pour les ajouts à stocker dans?

Une option peut être d'installer Apache HTTP Server sur la machine et servir le fichier via ce. Utilisez POST pour télécharger et GET à télécharger.

Si les clients sont dans un réseau local, vous pouvez non seulement partager un lecteur?