2009-08-25 2 views
0

Ich arbeite an einem kleinen verteilten System, das komplett nachrichtengesteuert ist. Im Moment öffne ich normalerweise jedes Mal eine Steckdose, wenn ich etwas senden muss und schließe es direkt danach. Der Status wird nur auf der Serverseite gepflegt (wenn zum Beispiel keine Nachricht von einem Client für 5 Minuten eintrifft, halte sie für tot).Robuster Weg, Nachrichten für ein verteiltes System zu senden und zu bearbeiten

Ich muss jedoch auch eine Low-Level-Planung von Nachrichten auf dem Client vornehmen (wenn eine Statusnachricht den Server nicht erreichen kann, versuchen Sie es erneut, wenn es immer noch fehlschlägt, gehen Sie davon aus, wechseln Sie zu einem anderen Server usw.)), sowie sowohl auf dem Client als auch auf dem Server manuell zu hören (und die Informationen auszutauschen, wie der Client vom Server erreicht wird). Ich plane auch, irgendeine Art von Broadcast-System hinzuzufügen, aber das beginnt sich zu häufen ... so ist die Frage, ob es ein existierendes Bus-/Messaging-System für .NET gibt, das mit Mono und Microsoft arbeitet, das diese Nachrichten verarbeitet Sachen? Ich schaute auf NServiceBus, aber es hängt von MSMQ (noch wahr?), Die mehr oder weniger auf Mono unterstützt wird; Alles in allem sieht NServiceBus schon etwas zu schwergewichtig aus. Idealerweise würde das System 1: 1- und 1: N-Verbindungen unterstützen, Fehler zuverlässig handhaben und sie melden und auch einige erweiterte Funktionen (Warteschlangen-Nachrichten, Sicherheit) aufweisen.

Antwort

2

Haben Sie nach RabbitMQ gesucht?

+0

Scheint jetzt in Beta zu sein (die C# -Schnittstelle, das ist). – Anteru

+0

Das ist nur die Schnittstelle, ich würde mir keine Sorgen machen. Im schlimmsten Fall wäre es besser, denke ich, als ein handgeschriebenes Ding. Vor allem, wenn Sie die Quelle überprüfen können. –

+0

FWIW, Monos (Alpha) Implementierung von System.Messaging verwendet RabbitMQ. http://www.mono-project.com/SystemMessaging –

0

Haben Sie sich Mono-Olive angesehen? Ich weiß, dass sie WCF implementiert haben, das wäre wahrscheinlich die beste Option, wenn sie inzwischen genug implementiert haben, um nützlich zu sein.

+0

Sieht Work-in-Progress im besten Fall; Problem ist, es sollte robust sein - zumindest einige freigegebene Versionen. – Anteru

Verwandte Themen