Modularer Aufbau

Das ich das unter Linux und Windows jeweils anders machen muss ist schon klar.

wxWindows ist ja auch eine Api einmal geschrieben und dann entweder für Windows oder Linux Compiled.

Um das vielleicht zu verdeutlichen, was ich vorhabe.
Mein Entwicklungssystem ist ein Linux Server,

makefile für Linux gcc 3.2.2 wxWindows2.4.1 Linuxprog directory -> /prog/linux

makefile für Windows mingw-gcc 3.2.2 wxWindows2.4.1 Windowsprog directory -> /prog/windows

Ich stelle mir das so vor, das später unter /prog/BS die jewiligen Module ligen die sich der Client dann holt in ein Verzeichniss kopiert und ausführt.

Er prüft bei jedem Modulstart ab ob eine neue Version des Moduls vorliegt,
falls ja, neues Modul holen.

Ich hoffe ihr könnt damit was anfangen.

PAD

Für diesen Fall ist die Interprocess Communication über names Pipes eine typische Lösung.

Als Vorschlag:
Schau dir die named Pipes unter Windows und Linux an

Schreib dir Wrapper Funktionen so das dein Pogramm die Functionen mit den gleichen Parametern aufruft.

Schreib eine Bibliothek die diese Wrapperfunktionen alla Windows
und eine Bibliothek die diese Wrapperfunktionen alla Linux löst.

Je nachdem welches Betriebssystem du benutzt binde die passende Bibliothek beim compileren und linken ein.

Ich weis das ich für diesen Lösungsvorschlag von einigen geprügelt werde Wenn du einigermaßen fit bist kann man das auch mit #ifdef in einem Satz von Source files losen.

Ich tendiere eher zu einem anderen Ansatz.
Ich habe ein Unterverzeichnis Linux und Unterverzeichnis Windows
in jedem steht der entsprechende Sourcecode

wrapper.c sieht wie folgt aus

#ifdef LINUX
 #include "\linux\wrappersrc.c"
#endif
#ifdef Windows
 #include "\windoes\wrappersrc.c"
#endif

Ich halte das für übersichtlicher, speziell wenn mit Erweiterungen zu rechnen ist.

Macht man das echt alles über named pipes

Ich dachte das es da villeicht geschicktere Lösungen gibt !

Ich werd mir das mal genauer anschauen !

Für weitere bzw. andere vorschläge bin ich offen !

Hab schon mal vielen Dank !

MfG

rüdiger

ich würde dann lieber ein Modul System nehmen, was auf dynamisch geladenen Librarys basiert, unter Linux solltest du dir dlopen(3) angucken. Dann musst du dir eben deinen eigenen Wrapper für schreiben um mit Windoze kompatibel zu sein

HumeSikkins

Hallo,
ich denke das passt besser nach Rund um...

PAD

Ich bin nicht so tief in der Unix-Programmierung/Codierung drin (genauer gesagt gar nicht).
Wenn es die Dll-Fähigkeit hat sollte man diese benutzen, die dynamische Bindung ist hier auf jeden Fall bequemer als eine statische. Das ändert aber nicht an den Konzepten der Modularisierung

Was ist am PipeVerfahren ungeschickt?
Zu Pipes:
in Unix ein grundlegendes Betriebssystemkonzept das von der Performance sehr schnell arbeitet
in Windows von der Performance sehr schnell, wird aber von MS$ ''versteckt'' um deren darüberliegende Konzepte zun verkaufen. Die meisten der von MS$ propagierten InterProcess Konzepte werden wahrscheinlich auf diesem Arbeitsprinzip aufbauen.

rüdiger

aber man braucht doch gar keine Pipes, wenn man dynamisch ladbare librarys benutzt!

Unix-Tom

Was haben Module mit Named Pipes zu tun ?

Will man eine Funktion eines Modules nutzen kann dies nur in einer DLL/SO stehen.

Jenachdem welches BS es ist die entsprechende DLL/SO laden.

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

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...