Modularer Aufbau

[PAD]

dakjono hat zwei fragen gestellt:

Das ganze soll dan auch noch unter Windows und Linux funktionieren.

Die Programme müssen aber alle mit dem Server interagieren !
Meine Frage ich, wie bekomm ich das am dümmsten hin. Quasi Interprozesskommunikation!

Modularer Aufbau mit einer dll die den Windows spezifischen Code enthält und einer zweiten die den Unix spezifischen Code für die Pipes enthält.
Pipes als Möglichkeit in beiden OS die Interprocesskommunication aufzusetzen

[rüdiger]

die schnellste IPC Methode ist Shared Memory. Wenn die IPC aber nicht auf einem Rechner durchgeführt werden soll, dann bleiben einem eigentlich nur TCP/IP Sockets.

[PAD]

Prinzipell gebe ich dir recht, die Logik sagt shared Memory ist schneller

(Vermutlich wird in den named Pipes (NT) mit shared Memory gearbeitet, weist du da genaueres?)

Ich habe beide Methoden unter Windows NT codiert
Named Pipes anhand des MSDN Beispiels (multithreaded pipe server aus der MSDN)
Shared Memory anhand der Informationen in der MSDN

Für mich war es wichtig die Fähigkeit zu haben, von mehreren Programmen mit mehreren Threads,
auf ein anderes Programm unabhängig voneinander zuzugreifen.
Dabei habe ich dann festgestellt das durch den Verwaltungsaufwand den ich für die Shared Memory Lösung hatte diese ca. einen Faktor 5 langsamer war als mit named pipes.
Den Verwaltungsaufwand darf ich eigentlich nicht dem Shared Memory Koncept in die Schuhe schieben.

Aber für mich zählte das Resultat: IPC mit 'Named Pipes' Faktor 5 schneller als IPC mit 'Shared Memory'

Das ist auch der Grund warum ich zu den Pipes geraten habe

[rüdiger]

natürlich kann es sein, dass in einigen Fällen eine andere Lösung besser ist, als Shared Memory. Aber theoretisch sollte SharedMemory das schnellste sein.

Naja, ich würde eh erstmal gucken, was mir wxWindows zur Verfügung stellt als IPC Methode und dann entscheiden

[dakjono]

Ich probiere das ganze erst über named pipes, dann Intern über TCP/IP.

wxWindows bittet zwar einiges aber nicht das was ich brauch

TCP/IP ist ja schon drin, Connection Server <-> Client.

Jetzt nochmal ne Frage, sind named Pipes schneller oder Locale TCP/IP Sockets ??

Ich habe keine Ahnung !

[rüdiger]

Named Pipes sollten schneller sein, da ein Protokoll Overhead vermieden wird (was gerade bei TCP enorm ist!)

[PAD]

Ich weis es nicht, wills aber auch wissen

[frenki]

Ich habe sowas auch mal gemacht. Bei mir für Windows/OS2.

Meine Lösung ist die mit den DLL's für die Module. Auf dem Server gibt es für jedes BS ein Verzeichnis, und je nach Client-Plattform werden die Module halt aus dem richtigen Verzeichnis geladen.

Zur Kommunikation biete ich sowohl Named Pipes als auch TCP/IP an. Das kann man bei der Anmeldung am Client jederzeit umstellen. Es hat sich herauskristallisiert, das Named Pipes im LAN schneller sind als TCP/IP, wohingegen im WAN TCP/IP die schnellere Lösung ist (getestet über völlig überlastete 64-KBit Standleitungen).

Zu Beachten ist dabei nur, dass wenn dein Server auch unter Win9x laufen soll, die Named Pipes ausscheiden, weil die dort nur Client-Seitig zur Verfügung stehen.

[PAD]

@frenki Gilt deine Aussage auch für Unix/Linux Server

[frenki]

Keine Ahnung. Mit Linux habe ich noch nie was gemacht (ausser es mal testweise zu installieren).

Aber da die Pipes offenbar Plattformunabhängig sind (ich kann einen Windows-Server per Pipe mit einem OS/2-Client verwenden) denke ich mal, dass die Pipes unter Linux dasselbe Protokoll verwenden. Ist aber nur Vermutung...