2010-12-05 5 views
2

Ich arbeite derzeit an der Erstellung eines skalierbaren Server-Design in C++ für einen Ubuntu-Server. Ist das Piping über ein LAN möglich? Was ist die beste Option für schnelle Inter-LAN-Kommunikation?LINUX: Ist eine Verbindung über ein LAN möglich? Wenn ja, ist es wünschenswert? Was sind andere Optionen?

Hintergrund Info für Interessierte: Ich mache ein Multiplayer-Spiel mit einem Freund. Es wird TCP-basiert sein. Die Sache ist für Linux, einen Server zu machen, Multi-Client zu sein bedeutet, einen neuen Prozess pro Client zu erstellen oder() durch einen fdset von verbundenen Clients auszuwählen. Ich möchte diese Ansätze kombinieren und habe einen "Manager" -Prozess, der über vielleicht 100 Kunden auswählen und alle Änderungen in der Kette an einen "Taskmaster" -Prozess melden wird, der dann die Änderung an die anderen Managerprozesse verteilt. Dies wird gut mit Piping funktionieren, wenn die Manager und Taskmaster auf der gleichen Box sind, aber wenn ich später skalieren möchte, brauche ich eine schnelle Inter-Lan-Kommunikationsmethode.

+3

Das ist nicht wirklich was Rohre tun. Sie müssen Sockets verwenden. Und Sie brauchen nicht unbedingt einen neuen Prozess, um Multi-Client zu sein. Wenn jeder Client einen neuen Prozess hervorbringt, können Sie nicht sehr gut skalieren. – Falmarri

+0

@Falmarri: Auf jeden Fall dachte ich an einen neuen Prozess, um bis zu 100 Kunden zu betreuen. – returneax

Antwort

1

Ein Stream-Socket (SOCK_STREAM, kombiniert mit AF_UNIX, falls lokal oder AF_INET, wenn über TCP/IP) ist das Netzwerk-Äquivalent einer bidirektionalen Pipe, mit allen Daten geordnet.

+0

Ok, danke.Dies wäre streng lokal. Einige Vorschläge, die ich auf reddit erhalten habe, waren die Implementierung einer Art von Multicast-System und die vollständige Entfernung des Taskmasters. – returneax

0

LANs sind in der Regel Ethernet-basierte Netzwerke. Dies bedeutet, dass jedes Protokoll, das in Ihrem Netzwerk ausgeführt wird, Ethernet-basiert sein muss. TCP/IP kann und wird in Ethernet-Netzwerken ausgeführt, aber Pipes und Local-Sockets sind nur für eine prozessübergreifende Kommunikation auf einem einzelnen Host ausgelegt und eignen sich daher nicht für Multi-Host-Anwendungen.

Wenn die verschiedenen Komponenten auf einem anderen Host laufen, müssen Sie sie über ein TCP/IP-Protokoll verbinden. Es gibt einige ältere Protokolle wie IPX und UUCP, die über Ethernet laufen, aber diese wurden vollständig durch TCP/IP ersetzt.

2

Überprüfen Sie die Netcat-Anwendung. Auf einer Maschine können Sie netcat als Server, kochend die Ausgabe auf Ihren Prozess auszuführen:

nc -l -p 1234 | myApp 

Das auf TCP-Port 1234 hören, und alles drucken Sie es über stdout erhält aus.

und auf einer zweiten Maschine:

myApp | nc 192.168.1.2 1234 

Wo 192.168.1.2 die Adresse der ersten Maschine IP ist. Sie müssen die nc man page für die spezifischen Details nachschlagen - das obige ist alles aus dem Speicher.

+0

cool, danke für die Info Ill check it out – returneax

1

Genau wie Sie diese Frage stellen, scheinen Sie die Wahrnehmung zu haben, dass für die Kommunikation zwischen verwandten Prozessen Pipes die notwendige Antwort ist.

Der Weg, darüber nachzudenken, ist, dass Sie die Kommunikation zwischen zwei Prozessen benötigen, ob sie ein paar Komponenten in Ihrem System, Client-Server-Paar oder was auch immer sind. Dann wählen Sie einen Mechanismus, der für die gegebene Geographie funktioniert. Pipes funktionieren, wenn die Prozesse lokal sind. Sie können auch Warteschlangen für gemeinsam genutzte Speicher für einen No-Copy-Kanal verwenden. Sie können auch IP (über Sockets) über die Loopback-Schnittstelle verwenden. Um über das Netzwerk (WAN oder LAN) zu gehen, müssen Sie ziemlich viel IP verwenden.

Zu guter Letzt sollten Sie zusätzlich zu TCP auch die Verwendung von UDP in Erwägung ziehen, da Sie integrierte Nachrichtengrenzen und eine einfachere Endpunktverwaltung erhalten.

Verwandte Themen