LINUX: La canalisation est-elle possible sur un réseau local? Si oui, est-ce souhaitable? Quelles sont les autres options?

Question

Je travaille actuellement sur la création d'une conception de serveur évolutive en C++ pour un serveur ubuntu. La tuyauterie sur un réseau local est-elle réalisable? Quelle est la meilleure option pour une communication inter-LAN rapide?

Informations de base pour ceux intéressés: Je fais un jeu multijoueur avec un ami. Ça va être basé sur TCP. La chose est pour Linux faire un serveur multi client semble signifier créer un nouveau processus par client ou sélectionner() à travers un fdset de clients connectés. Je veux combiner ces approches et avoir un processus de «gestionnaire» qui sélectionnera peut-être 100 clients et signalera toute modification de la chaîne à un processus «taskmaster» qui distribuera ensuite le changement aux autres processus du gestionnaire. Cela fonctionnera bien avec la tuyauterie si les gestionnaires et les chefs de projet sont sur la même case, mais si je veux l'adapter plus tard, j'ai besoin d'une méthode de communication inter-Lan rapide.

Answer 1

Un socket de flux (SOCK_STREAM, combiné avec AF_UNIX si strictement local ou AF_INET si sur TCP/IP) est l'équivalent réseau d'un tuyau bidirectionnel, avec toutes les données ordonnées.

Answer 2

Les réseaux locaux sont généralement des réseaux Ethernet. Cela signifie que tout protocole exécuté sur votre réseau doit être basé sur Ethernet. TCP/IP peut fonctionner sur les réseaux Ethernet, mais les canalisations et les sockets locaux sont uniquement conçus pour être une communication inter-processus sur un hôte unique, ce qui ne convient pas du tout aux applications multi-hôtes.

Si les différents composants s'exécutent sur un hôte différent, vous devrez les lier via un protocole basé sur TCP/IP. Il existe des protocoles hérités comme IPX et UUCP qui fonctionnent sur Ethernet, mais ils ont été totalement remplacés par TCP/IP.

Answer 3

Extrayez l'application netcat. Sur une machine, vous pouvez exécuter netcat comme serveur, redirigeant la sortie vers votre processus:

nc -l -p 1234 | myApp 

Cela écoute sur le port TCP 1234, et imprimer tout ce qu'il reçoit au-dessus stdout.

Et sur une deuxième machine:

myApp | nc 192.168.1.2 1234 

Où 192.168.1.2 est l'adresse IP de la première machine. Vous aurez besoin de rechercher la page de manuel nc pour les détails spécifiques - ce qui précède est tout de mémoire.

Answer 4

De la façon dont vous posez cette question, vous semblez avoir la perception que pour la communication entre processus connexes, les tuyaux sont la réponse nécessaire. La façon d'y penser est que vous avez besoin de communication entre deux processus, qu'il s'agisse de quelques composants dans votre système, d'une paire de serveurs clients, ou de n'importe quoi d'autre. Ensuite, vous choisissez un mécanisme qui fonctionne pour la géographie donnée. Les tuyaux fonctionnent si les processus sont locaux. Vous pouvez également utiliser des files d'attente de mémoire partagée pour un canal sans copie. Vous pouvez également utiliser IP (via des sockets) sur l'interface de bouclage. Pour aller à travers le réseau (WAN ou LAN) vous devez pratiquement utiliser IP. Enfin, en plus de TCP, envisagez d'utiliser UDP également, car vous obtenez des limites de message intégrées et une gestion plus facile des points de terminaison.