sockets oder shared memory?
-
Hallo, für ein Programm das ich schreiben will stehe ich vor der Frage, ob ich die Kommunikation zwischen den Programmen (eins zur Bedienung, eins zur Berechnung) über shared Memory oder über sockets machen sollte.
Es geht dabei um diverse double und integervariabeln, teilweise als Array.Was ich bis jetzt mir so angesehen habe dazu ist mir noch nicht ganz so klar. Von daher würde ich gerne mal wissen ob eines von beiden weniger Aufwand ist? Mir sieht es fast so aus als wäre das shared Memory. Bei den Sockets wäre natürlich gut dass es dann auch über Netzwerk geht (wobei die Netzwerksache ziemlich unwichtig ist)
-
Shared Memory ist die schnellste Lösung. Allerdings musst du dich selbst um die Synchronisation kümmern (was passiert, wenn ein Prozess liest, während der andere schreibt?).
Sockets haben natürlich den Vorteil, dass sie - wie du selbst sagst - über's Netzwerk funktionieren würden. Aber sie sind eben deutlich langsamer! Wobei du für den Fall, dass beide Prozesse auf einem Rechner laufen, auch UNIX-Sockets nehmen könntest, die wenigstens ein bisschen schneller als TCP/IP wären.
-
interessant, bzgl. der Geschwindigkeit, ich glaube die ist nicht so entscheidend, was für einen Durchsatz/sek. kann man denn mit sockets erwarten?
Die Geschichte mit der Synchronisation bei shared Memory habe ich auch shcon gelesen, nur bin ich davon ausgegangen das das bei den sockets ja auch irgendwie gemacht werden muss. Wie ist es denn da gelöst?
Unix-Socket sind beondere? ich bin wie gesagt gerade erst am einarbeiten.
und was meinst Du welche Variante ist für den Anfänger einfacher?
-
Wie wärs denn mit fifo-pipes 2 Stück
Client > Server und
Server > client
Macht allerdings nur wirklich Sinn, wenn sich nur 2 unterhalten.
Bei mehreren Cients empfiehlt sich Socket.
-
Bei Sockets kümmert sich ja die TCP/IP-Implementierung darum, dass du nur "fertige" Daten lesen kannst. UNIX-Sockets arbeiten mit Dateien, verhalten sich aber ansonsten wie sockets.
Schau vielleicht mal hier: http://www.beej.us/guide/bgipc/output/html/singlepage/bgipc.html
-
also das mit den fifo pipes dachte ich ist nicht so passend für meine Anwendung, da ich das so verstanden hatte das ich dabei ja quasi immer den gesamten Datensatz durchschicken müsste auch wenn ur ein Parameter geändert werden soll?
die sockets beschäftige ich mich nochmal genauer mit, hab jetzt aber mal zum testen von shared memory ein ganz einfachs Beispiel gemacht, ein Programm schreibt ständig und eins liest ständig.
Da habe ich jetzt nichts synchronisiert/gesperrt und es funktioniert scheinbar? kann man die Synchronisation also auch weglassen wenn es nicht so wichtig ist? bzw was hätte es genau für Auswirkungen auf die Daten?
-
also ich hab noch nicht mit shared memory gearbeitet aber kritisch ist es glaube ich wenn du mit beiden programme schreiben und lesen willst. dann solltest du das schon irgendwie synchronisieren.
blan
-
das wiederum könnte ich also einfach übergehen indem ich wie bei dem Pipes Bsp. 2 Speicher anlege?
denn Grundsätzlich ist es:
Client ändert Parameter am Server
Server stellt Ergebnisse bereitAlso wenn es da keine Probleme geben kann wäre das für mich eine Lösung die ich wohl einigermaßen verstanden habe...
-
JJR schrieb:
also das mit den fifo pipes dachte ich ist nicht so passend für meine Anwendung, da ich das so verstanden hatte das ich dabei ja quasi immer den gesamten Datensatz durchschicken müsste auch wenn ur ein Parameter geändert werden soll?
TCP/IP-Sockets sind auch FiFos :). Aber du kannst natürlich ein Protokoll entwerfen, mit dem du angibst, welche Daten sich geändert haben. Aber das wird dann natürlich noch mal ein bisschen komplizierter und langsamer.
JJR schrieb:
Da habe ich jetzt nichts synchronisiert/gesperrt und es funktioniert scheinbar? kann man die Synchronisation also auch weglassen wenn es nicht so wichtig ist? bzw was hätte es genau für Auswirkungen auf die Daten?
Das Problem ist, dass du kaputte Daten lesen kannst. Und gerade solche Fehler sind halt sehr übel, weil es normalerweise immer funktioniert, außer im entscheidenden Moment :). Aber schau dir mal den Link von mir an. Da wird dir u.a. auch erklärt, wie du synchronisieren kannst.
-
JJR schrieb:
Hallo, für ein Programm das ich schreiben will stehe ich vor der Frage, ob ich die Kommunikation zwischen den Programmen (eins zur Bedienung, eins zur Berechnung) über shared Memory oder über sockets machen sollte.
Es geht dabei um diverse double und integervariabeln, teilweise als Array.Es gibt noch ein grundlegendes Argument gegen SharedMemory. Du bist darauf angewiesen, dass beide Programme auf dem gleichen physikalischen Rechner laufen. Der Aufwand ein SharedMemory-System für mehrere physikalische Knoten zu installieren lohnt sich für eine Privat-Person faktisch nicht.
Ich habe kürzlich ein ähnliches Projekt verwirklicht. Die GUI/Benutzer-Logik kommuniziert per Netzwerk mit der anderen Applikation. Als System war Suse-Linux vorgesehen, dank wxWidgets läuft die GUI auch auf Win32. Hat einige doch überrascht, was heutzutage möglich ist
Aufwand insgesamt war ca. 100h. davon für die Netzwerkkommunkation 5h. Mit Event-basierten Sockets kann man so ein System effektiv verwirklichen.
Ein SharedMemory-System lohnt sich erst ab ca. 2MB/sek aufwärts.
-
also ich tu mich noch ein bisschen schwer mit den sockets, bleibe da aber noch dran. 2MB/sek ist auch weit über dem was ich benötige.
die Synchronisation mit den Semaphoren ist wohl auch machbar, wobei ich da noch überlegen muss wie ich das vom Ablauf her genau mache, denn so wie ich das bis jetzt verstanden habe gibt es nicht noch prioritäten in den Semaphoren? Sperre ich also den Speicher weil mein Client darauf zugreifen will, kann der server nicht mit den Daten rechnen?
In dem Fall müsste ich wohl zwischen Shared Memory und se2rver nochmal Daten speichern so das der server mit diesen Daten rechnet und "bei Bedarf" diese Daten dann mit dem shared memory abgeglichen werden?