Voici le scénario:
Un utilisateur a accès à deux machines
Ces machines ne peuvent pas communiquer avec des sockets réseau en raison de restrictions de pare-feu
mais, les deux ont accès à une part de réseau commun avec des autorisations de lecture / écriture sur une troisième machine
Ma question est la suivante: est-il possible d'écrire une petite application exécutée sur les deux machines permettant d'établir un canal de communication entre les deux en utilisant uniquement des fichiers sur la part du réseau? Idéalement, il émule le comportement des flux et des sockets.
J'imagine que:
1) Il impliquerait de disposer de deux fichiers utilisés pour la communication, une pour chaque direction
2) et avoir la possibilité de lire un fichier alors qu'un autre processus l'écrit ... sur le réseau.
Mais je ne suis pas sûr que si cela est réalisable, principalement parce que je doute du point 2). Peut-être que cela est possible dans des environnements de type UNIX avec NFS, cependant.
est-ce possible? Est-ce déjà existant?
5 Réponses :
Du de quoi ça se passe:
Lorsque la machine A veut envoyer un message à la machine B, il crée un fichier appelé _tobfroma_12782 (où 12782 est l'horodatage actuel). Il écrit le contenu au fichier, puis modifie le nom pour supprimer le premier soulignement.
Toutes les quelques secondes, chaque machine vérifie s'il existe des fichiers avec un nom de fichier qui commence par tox où x est leur propre nom. Si plusieurs messages sont trouvés, ils peuvent ensuite être commandés en fonction des horaires. Après avoir lu le fichier de message, le destinataire supprime le fichier.
Cela suppose que tous les participants ont une heure synchronisée, mais s'ils ne le font pas aussi, peut être élaboré (ou vraiment ignoré en fait).
Cela semble bien commencer. +1. Mais je pense que les problèmes de synchronisation apparaîtront trop rapidement avec plusieurs fichiers (problèmes d'horodatage). Avoir également un comportement "blocage" comme des flux et des sockets semble difficile.
Résolvez la synchronisation avec un identifiant d'incapacité automatique dans le nom de fichier. De cette façon, vous pouvez également détecter des messages perdus. Regardez les périphériques de médiation de Telcom. Celles-ci utilisent de telles techniques pour le traitement en vrac de chargement de fichiers de données à partir de commutateurs de réseau.
Je me suis vaguement rappelé quelque chose sur les fichiers FIFO sur UNIX. Une recherche sur le Web a confirmé qu'ils étaient ce que je me suis souvenu (un moyen d'effectuer la communication via des fichiers). Je n'ai pas testé pour voir s'ils travailleront entre deux machines distinctes, qui ont accès au même système de fichiers, mais je pense que cela le fera probablement. J'aurais peut-être une idée de se moquer de quelque chose plus tard lorsque j'ai accès à un système UNIX pour satisfaire ma curiosité.
Essentiellement, vous devez créer un fichier FIFO, en utilisant mkfifo . Ensuite, vous pouvez ouvrir le fichier et utiliser le blocage de lecture / écrit pour le traiter (chaque 'OUVERT' peut soit lire, soit écrire, pas les deux en même temps, vous devez donc en avoir besoin, un pour chaque direction). Certaines autres descriptions du processus, qui incluent certains échantillons de code peuvent être trouvées ici et J'ai testé MKFIFO, à l'aide de commandes UNIX standard: p> Créer le tuyau: p> cat mypipe
Comme vous l'avez trouvé, une FIFO sur une partition montée NFS ne sera pas comme un mécanisme IPC inter-machine.
Essayez peut-être si l'une de ces solutions fonctionne pour vous, dépend si votre système de réseau permet l'une des méthodes de surveillance mentionnées:
Surveillance d'un dossier pour les nouveaux fichiers sous Windows < / p>
Faire 2 dossiers, chaque processus écrit à l'un des dossiers, utilisez un horodatage pour le nom de fichier, écrivez en mode exclusif. Chaque processus surveille l'autre dossier et lorsqu'un fichier apparaît, vous attendez jusqu'à ce qu'il soit écrit complètement, puis lisez-le, puis supprimez-le.
Solution assez compliquée et non fiable lorsque nous pensons à la communication et à la synchronisation interprocession.
Je pense que c'est une bonne idée de diviser le flux en paquets en premier. Ensuite, ces paquets doivent apparaître comme fichiers dans le répertoire commun. Il doit y avoir deux "espaces de noms" pour les deux manières (A-> B et B-> A). Pour le débogage facile, les noms de fichiers doivent contenir un horodatage, pas seulement une partie incrémentielle.
Il n'y a qu'un seul problème avec les fichiers: même si le fichier est assez petit, le récepteur peut l'attraper quand il n'est pas complètement rincé, je veux dire que le fichier n'est qu'à mi-chemin (cas commun: 0 octet long), ou une erreur réseau eu lieu pendant le transfert. Évitez cette situation, l'expéditeur devrait:
Donc, le récepteur ne choisira que le fichier après le renommant, quand il est sûr de 100%, que c'est complètement écrit.
Avant d'envoyer un nouveau fichier, l'expéditeur peut vérifier le fichier temporaire, s'il existe, cela signifie que la dernière transmission a été abandonnée.
Lors de la création d'un nouveau fichier de transmission, l'expéditeur doit créer un fichier d'information, qui contient des informations sur le paquet de transmission envoyé, donc sur un avortement, il contiendra des informations sur le paquet ayant échoué. Peut-être que la seule information est l'heure de la transmission (rappelez-vous: le nom du fichier temporaire ne contient pas d'horodatage), mais c'est mieux que rien.
Merci, je pense que votre réponse est un bon début. Le fichier d'informations est une bonne idée aussi, agissant comme un mécanisme de détection d'erreur.
MMAP () peut Soyez utilisé pour partager un fichier entre deux processus et une stratégie classique IPC et historiquement, des implémentations de noyau d'API de mémoire partagée utiliseraient des inodes temporaires en tant que magasin de support.
du point de vue du noyau, la seule différence dans votre situation est que le fichier utilisé pour IPC utiliserait des inodes qui utilisent le Sous-système VFS pour se connecter à la part NFS.