Ich habe einen Serverprozess mit bis zu ca. 10 Clientprozessen, auf dem selben Computer am laufen. Es soll eine extrem hohe(!) Kommunikation in Form vom Nachrichten von 30-1000 Bytes stattfinden. Alle Prozesse haben KEIN Window.
Ein paar Geschwindigkeitsmessungen auf einem AMD 1,3 Ghz, Windows XP:
Windowsmessages von per PostThreadMessage():
ca. 150.000 Messages pro Sekunde
ca. 50.000 Messages pro Sekunde mit Warten auf Antwort
Faziz: Sehr schnell, kann aber "nur" zwei 32-Bit-Zahlen transportieren
Memory Mapped Files(Shared Memory)
Es gibt für jede Sprachrichting eine Memory Mapped File, zu sendende Daten werden hinein geschrieben und eine Windowsmessage gesendet mit Offset und Länge des Datenpacketes in der Remote-Datei um den Remoteprozess über ein neues Datenpacket zu benachrichtigen
ca. 12.000 Nachrichten(Länge 20-100 Bytes) pro Sekunde mit Warten auf Antwort
Wie lange das Senden ohne zu Warten dauert habe ich "vergessen"
Problematiken: Die "selbstgeschribene" Pipeline muss regelmäßig rotiert bzw. geleert werden.
Anomymous Pipes
2 Pipes, eine für jede Richtung. Auf beiden Seiten wird mit Hilfe von ReadFile() "gelauscht". Eine Zeitmessung habe ich noch nicht durchgeführt. Etwas anderes macht mir da "mehr" Sorgen: Serverseiting wird für jeden Client ein sperater Thread benötigt, da ReadFile() sich auf nur ein File-
Handle bezieht.
Named Pipes
Ist mir ne Nummer zu "hoch", und meine Bedenken sind dass Named Pipes einen zu großen "Overhead" haben.
Mail Slots
Nachriten basiertes System. Vorteil: Es sind Broatcast-Nachrichten möglich. Nachteil: Es wird NICHT garantiert dass das Packet angekommen ist.
In meiner Anwenund gibt es folgende Nachrichtentypen:
Send Only
Beispiel: Ein Protokollierungseintrag wird abgeschickt, Der Client arbeitet sofort weiter, eine Benachrichtigung ob Erfolgreich ist nicht notwenidg
Mein Vorschlag zu Realisierung: Mail Slot oder Anonymouse Pipe in einer Richting.
Send And Notify
Beispiel: Der Client aktualisiert einen Wert auf dem Server. Als Benachrichtigung nach der Aktualisierung wäre eine Windowsmessage denkbar.
GetData
Beispiel: Ein Wert wird abgefragt. Die Anfrage wird gestellt(ca. 20-100 Bytes), es wird gewartet bis der Server Antwortet.
Mein Vorschlag zur Realisierung: zwei Anoymous Pips oder eine Named Pipe, Mail Slot oder Memory Mapped File mit windowsmessage-Benachrichtigung
Die Wahl der Transportmöglichkeit ist durch folgende Dinge zu überlegen:
- Transportgeschwindigkeit
- Effizienz beim Abfragen der ankommenden Daten
Da ich in der Regel immer in 2 Richtiungen kommunizieren muss("Send Only" ist extrem seltend, daher mache ich mir darüber jetzt keine Gedanken) ist die Situation folgende:
Die Lösung mit Memory Mapped Files-Lösung benötigt auf der Clientseiete eine MMF und eine Messagequeue, auf Serverseite ebenfalls. Auf Serverseite jedoch könnte ein einziger Thread(MessageQueue) an mehreren Verbindungen lauschen.
Für Anomous Pipes wird IMMER pro Sprachrichtung ein Thread zum lauschen benötigt.
Named Pipes sind mir ne Nummer zu "hoch"
Mit Mailslots habe ich noch nicht gearbeitet.
Nächste Problematik wäre dann das Bearbeiten der Packete auf der Serverseite. Ich bin am überlegen ob für jede Anfrage geschaut werden soll wie "zeitaufwendig" sie ist. Ist sie vorraussichtilich "zeitaufwendig" soll sie in einem neuen Thread bzw. in einem Thread im Threadpool ausgeführt werden.
Nun, was ist die schnellste und effzienteste Lösung?
Mir fehlt es halt ein bisschen an Erfahrung bei der "High Performance" Inter Process Communikation
Ist als "Benachrichtiung" ein WaitHandle bzw. Event(per
Handle) schneller/effizienter als eine Windowsmessage?
Gibt es eigentlich 3rd-Party Lösungen für
IPC?