Utiliser des files de messages POSIX au lieu de sockets TCP - comment établir une «connexion»?

Question

J'ai des programmes client et serveur qui communiquent maintenant via TCP. J'essaie plutôt d'utiliser des files de messages POSIX (dans les cas où le client et le serveur sont sur le même ordinateur, bien sûr). J'espère que cela améliorera les performances (notamment via une latence réduite).

J'ai travaillé à l'essentiel, mais je ne suis pas sûr d'une chose: comment établir la "connexion". Le serveur accepte les connexions de plusieurs clients simultanément. Je suis donc tenté d’émuler le processus d’établissement de connexion TCP comme suit:

1. Le serveur ouvre une file d’attente avec un nom connu et le lit en continu (il peut utiliser select (2) comme avec TCP).
2. Le client ouvre trois files d'attente: deux avec des noms arbitraires (y compris un caractère unique tel que le PID pour éviter les collisions) et une avec le nom connu utilisé par le serveur.
3. Le client poste un " connect " message à la file d'attente du serveur, y compris les noms de la file d'attente du client (l'un est désigné pour le trafic client-serveur et l'autre pour la conversation).
4. Le serveur ouvre les files d'attente nommées dans le message de connexion du client et commence à lire (sélectionner) à partir de celle du client à serveur.
5. Le client ferme la file d'attente du serveur avec le nom connu. La communication bidirectionnelle se poursuit à l’aide des deux files d’attente nommées par le client (une par direction).

Vous pouvez probablement voir en quoi ce schéma est similaire à la méthode TCP commune, et ce n’est pas un hasard. Cependant, j'aimerais savoir:

1. Pouvez-vous penser à un meilleur moyen de le faire?
2. Voyez-vous des problèmes potentiels avec ma méthode?
3. Avez-vous d'autres idées, notamment sur la probabilité que l'utilisation de files de messages au lieu de TCP sur le même ordinateur améliore réellement les performances (latence)?

N'oubliez pas que je n'avais jamais utilisé les files d'attente de messages POSIX (j'avais déjà utilisé IBM WebSphere MQ il y a quelque temps, mais c'est assez différent). La plate-forme est Linux.

Answer 1

J'ai fini par l'implémenter comme je l'ai décrit, avec quelques améliorations:

• À l'étape 2, j'ai utilisé les GUID pour les noms de file d'attente au lieu d'incorporer le PID du client.
• À l'étape 4, j'ai ajouté l'envoi d'un message "accepter". message du serveur au client.
• Lorsque l'une ou l'autre des parties souhaite mettre fin à la communication, elle envoie un "débranchement". message.

La prise de contact est plus simple que TCP, mais semble suffisante.

Quant à la latence: c’est bien mieux. Environ 75% de latence en moins avec les files de messages POSIX au lieu de TCP sur le même ordinateur Mes messages sont de l'ordre de 100 octets chacun.

Answer 2

1.   

   Pouvez-vous penser à un meilleur moyen de le faire?

   Peut-être jetez un coup d’œil à fifos (aka pipes nommées). Ils sont comme des sockets réseau mais pour la machine locale. Ils sont unidirectionnels et vous devrez peut-être en créer deux, un pour chaque direction. Votre question ne contient aucune raison pour pourquoi vous apportez ce changement de manière spécifique. Il n'y a rien de mal à utiliser des sockets pour que processus traite la communication. Ils sont bidirectionnels, efficaces, largement pris en charge et vous permettent de séparer les processus entre les machines ultérieurement.

2.   

   Voyez-vous des problèmes potentiels avec ma méthode?

   Les files de messages système V et les tubes nommés fifo conviennent parfaitement. Les pipes Fifo sont comme des pipes ordinaires, vous pouvez donc lire () et écrire () avec un minimum de modifications de code. Les files d'attente de messages System V nécessitent de placer les données dans une structure et d'appeler msgsnd (). L’une ou l’autre approche conviendrait cependant.

3.   

   Avez-vous d'autres idées, y compris sur la probabilité que l'utilisation de files de messages au lieu de TCP sur le même ordinateur améliore réellement les performances (latence)?

   Mes autres pensées sont que, comme vous l'avez dit, vous devez développer une technique afin que chaque client dispose d'un identifiant unique. Une solution consiste à ajouter le pid à la structure que vous transmettez ou à négocier un identifiant unique avec le parent / maître au début. L’autre chose à noter est que l’avantage des files de messages System V est que vous écoutez les messages "sélectifs". messages afin que vous puissiez utiliser idéalement une file d'attente du serveur vers tous les clients, chaque client attendant un message différent.

   Je n'ai aucune idée de la technique qui vous donne le débit optimal dans votre logiciel. Il n’est peut-être pas intéressant d’utiliser des files d’attente de messages System V, mais vous seul pouvez prendre cette décision.

Philluminati

Answer 3

J'ai comparé les performances de posix MQ et d'une paire de sockets TCP / IP.

Le programme de démonstration comporte deux threads, l’un pour l’écriture et l’autre pour la lecture.

Le résultat est que posix MQ est plus rapide,

• MQ 460000 tps
• socketpair 400000 tps

Answer 4

J'ai rencontré un problème similaire, je développe des applications en temps réel et j'ai besoin d'une technique IPC avec une fonctionnalité similaire à celle des sockets et une latence minimale.

Avez-vous comparé votre solution basée sur POSIX-MQ avec des sockets locaux UNIX ou TCP uniquement?

Merci

Answer 5

Comment avez-vous fait cela lorsque select () ne fonctionne pas sur les files de messages? Qu'est-ce que c'est Sys V ou POSIX? Pourquoi déployer des efforts supplémentaires pour créer une table de recherche GUID vers PID quand il est garanti que PID est unique et que le stockage est plus petit (entier)?

/ blee /

Answer 6

Vous pouvez également utiliser Message Queues for IPC dans des programmes résidant sur différentes machines. Dans ce cas, vous pouvez utiliser ZeroMQ ( http: //www.zeromq.org ) ou d’autres API de file d’attente de messages, je vous suggère également de les prendre en compte et de les tester également.