Mit POSIX message queues anstelle von TCP - sockets, wie Sie, um "Verbindung"?
Ich habe client-und server-Programmen, die jetzt die Kommunikation über TCP. Ich versuche mit POSIX message queues statt (in den Fällen, in denen der client und server auf der gleichen Maschine natürlich). Meine Hoffnung ist, dass die Leistung verbessert wird (insbesondere durch geringere Latenz).
Ich gearbeitet habe, die meisten davon, aber bin mir nicht sicher über eine Sache: wie schafft man die "Verbindung". Akzeptiert der server verbindungen von mehreren clients gleichzeitig, so bin ich versucht zu emulieren, die TCP-Verbindung herzustellen Prozess etwa so:
- Server öffnet eine queue mit einem bekannten Namen und liest es ständig (es kann
select(2)wie bei TCP). - Client öffnet drei queues: zwei mit frei wählbaren Namen (darunter einige Einzigartigkeit, wie PID, um Kollisionen zu vermeiden), und eine mit dem bekannten Namen, den der server verwendet.
- Client sendet eine "connect" - Meldung an der server-Warteschlange, einschließlich der client-queue-Namen (die eine ist bezeichnet für die client-zu-server-Datenverkehr und die andere für das Gegenteil).
- Server öffnet den Warteschlangen namens in der client-connect-Nachricht und beginnt zu Lesen (select) vom client-zu-server ein.
- Client schließt, der server-Warteschlange mit dem bekannten Namen. Zwei-Wege-Kommunikation erfolgt über die zwei Warteschlangen namens durch den Kunden (eine für jede Richtung).
Können Sie wahrscheinlich sehen, wie dieses Schema ist ähnlich wie eine gewöhnliche TCP-Methode, und das ist kein Zufall. Allerdings würde ich gerne wissen:
- Können Sie denken an einen besseren Weg, es zu tun?
- Sehen Sie alle potenziellen Probleme mit meiner Methode?
- Haben Sie noch andere Gedanken, auch über die Wahrscheinlichkeit, dass die Verwendung von message queues anstelle von TCP auf der gleichen Maschine wird tatsächlich verbessern, performance (Latenz)?
Beachten Sie, dass ich noch nicht verwendet POSIX message queues vor (ich habe IBM WebSphere MQ eine Weile zurück, aber das ist eher anders). Die Plattform ist Linux.
InformationsquelleAutor der Frage John Zwinck | 2009-01-03
Du musst angemeldet sein, um einen Kommentar abzugeben.
Vielleicht haben Sie einen Blick auf fifos (auch als benannte pipes). Sie sind wie Netzwerk-sockets, aber für die lokale Maschine. Sie sind uni-direktional, so dass Sie eventuell benötigen, um erstellen Sie zwei, eine für jede Richtung. Ihre Frage fehlt jeder Grund, der warumdass Sie machen diese änderung ausdrücklich. Es ist nichts falsch mit der Verwendung von sockets für die Prozess-zu-Prozess-Kommunikation. Sie sind bi-direktional, effizient, umfassend unterstützt und Ihnen die Freiheit zu trennen, die Prozesse zwischen den Maschinen später.
System V message queues und fifo named pipes sind beide absolut in Ordnung. Fifo-pipes sind wie normale Rohre, so dass Sie können, read() und write() mit minimalen änderungen am code. System-V-message queues verlangen, wenn die Daten in einer Struktur und die Berufung msgsnd(). Entweder Ansatz wäre in Ordnung, aber.
Meine anderen Gedanken sind, wie Sie gesagt haben, Sie brauchen eine Technik zu entwickeln, damit jeder client hat eine eindeutige id. Ein Ansatz wäre, die pid zu der Struktur, die Sie passieren oder über Sie zu verhandeln, die eine eindeutige id mit den Eltern /master am Anfang. Die andere Sache zu beachten ist, dass der nutzen von System-V-message queues, die Sie hören, die "selektive" Nachrichten, so könnte man im Idealfall verwenden Sie eine queue, die vom server an alle clients, die mit jedem client zu warten, für eine andere Botschaft.
Habe ich keine Ahnung über welche Technik gibt Ihnen den optimalen Durchsatz Ihrer software. Es ist wirklich möglicherweise nicht Wert sein, die mit System V message queues aber nur Sie können diese Entscheidung treffen.
Philluminati
InformationsquelleAutor der Antwort Philluminati
Ich landete Umsetzung ist es grundsätzlich so, wie ich beschrieben habe, mit ein paar Verbesserungen:
Dem Händeschütteln ist einfacher als TCP, aber scheint ausreichend.
Als der Latenz: es ist viel besser. Etwa 75% weniger Latenz mit POSIX message queues anstelle von TCP auf der gleichen Maschine. Meine Botschaften sind in der Größenordnung von 100 bytes.
InformationsquelleAutor der Antwort John Zwinck
Ich verglich die Leistung von posix MQ und ein paar TCP/IP-sockets.
Dem demo-Programm hat zwei threads, einer zum schreiben und der andere zum Lesen.
Dem Ergebnis, dass die posix-MQ ist schneller,
InformationsquelleAutor der Antwort lxyfirst
Ich habe ähnliches Problem, ich habe die Entwicklung von Echtzeit-Anwendung und müssen IPC-Technik mit ähnlichen Steckdosen Funktionalität und minimaler Latenz.
Haben Sie gegenüber Ihrem POSIX-MQ-basierte Lösung mit lokalen UNIX-sockets oder TCP-sockets nur?
Dank
InformationsquelleAutor der Antwort
Wie haben Sie dies tun, wenn select() funktioniert nicht auf message queues? Was ist es Sys-V-oder POSIX?
Warum nehmen Sie den zusätzlichen Aufwand bei der Erstellung GUID PID-lookup-Tabelle, wenn die PID ist garantiert einzigartig, und ist kleiner Speicher (integer)?
/blee/
InformationsquelleAutor der Antwort
Können Sie auch verwenden, Message Queues zum IPC-in Programme, die sich auf verschiedenen Maschinen, in solchen Fällen können Sie verwenden, ZeroMQ(http://www.zeromq.org) oder andere message-queue-APIs, außerdem schlage ich vor Sie, um Sie zu betrachten, und testen Sie auch.
InformationsquelleAutor der Antwort gst