Einfache persistente Nachrichtenwarteschlange in C# für einen einzelnen Prozess

Ich mache ein einfaches Messaging-System für ein Windows Mobile in C#. Die Anwendung besteht darin, einfache Textnachrichten über eine Web-Service-Kommunikation zu senden und zu empfangen. Die Nachrichtenwarteschlange sollte persistent sein und Datenverluste vermeiden, wenn die Verbindung mit dem Webdienst fehlschlägt oder die Anwendung abstürzt.Einfache persistente Nachrichtenwarteschlange in C# für einen einzelnen Prozess

Ich weiß über MSMQ, RabbitMQ, DotNetMQ, aber sie sollten in das Gerät installiert werden und das sind wirklich einfache Geräte, ich möchte kein anderes Tool in jedem der Handys nur für diese einfache Aufgabe zu installieren.

Ich habe bereits die Funktion zum Schreiben einer serialisierten XML-Warteschlange mit den Nachrichten in eine Datei implementiert und ich lese und schreibe die ganze Zeit aus dieser Datei.

Ich würde mich über jede bessere Idee freuen, um dieses Problem zu lösen. Danke

Quelle

2016-07-26 Maria Silvia

Windows Mobile ist seit Jahren veraltet. Meinst du Windows Phone oder Windows 10 Mobile? Wenn ja, warum nicht einfach Push-Benachrichtigungen verwenden? – EJoshuaS

Windows Mobile 6.5! und ja, sie sind alt! Sie werden für einige wenige Aufgaben verwendet, wie diese Messaging-Anwendung. –

Sicher, es gibt eine bessere Idee ist SQLite zu verwenden. Ich hoffe, dass dir das weiterhilft.

Quelle

2016-07-26 18:03:39

Ich weiß nicht wirklich, was für Windows Mobile verfügbar ist, aber Sie können versuchen, grundlegende Warteschlange (normale oder gleichzeitige, hängt von Ihrer App) begleitet von zwei Dateien. Schreiben Sie alles, was in eine "Enqueue log" -Datei eingereiht ist, und schreiben Sie alles, was aus einer anderen "Dequeue log" -Datei herausgenommen wurde. Diese beiden Dateien können Ihnen immer genügend Informationen geben, um Ihre Warteschlange wiederherzustellen, und Sie müssen Ihre Warteschlange nicht vollständig neu/vollständig serialisieren. Es muss jedoch von Hand implementiert werden.

Über dequeue: zum Beispiel, sagen wir, ich habe eine Warteschlange mit 3 Nachrichten: "eins", "zwei", "drei". Jetzt möchte ich die nächste (auch die erste) Nachricht "Eins" senden. Ich füge die Zeile "one - start remove from queue" an mein "dequeue log" an, entschalte dann "one" aus meinem Queue-Objekt und sende es an die Stelle, an die es gesendet werden soll. Wenn es gesendet wird, füge ich "- beendete das Entfernen aus der Warteschlange" an mein "Warteschlange löschen". Jetzt habe ich eine Zeile "one - Start Entfernen aus der Warteschlange - fertig aus der Warteschlange entfernt" in meiner Protokolldatei.

Es spielt keine Rolle, wann ich stürze, ich werde immer in der Lage sein, den Status des Queue-Objekts wiederherzustellen (zumindest für den Moment sehe ich keine logischen Fehler in diesem Prozess). Also imho ist es nicht schwierig, aber immer noch ... einige Code sollte codiert werden. Und es wären ein paar Seiten Code.

Quelle

2016-07-26 20:11:18

Auch diese zwei Dateien sollten von Zeit zu Zeit in einigen "Absturz persistent" Weg gereinigt werden. Wenn zum Beispiel "Protokoll entpacken" länger als 1000 Nachrichten wird, erstellen Sie das neue "Protokoll 2 aufheben" und löschen Sie dann das alte Protokoll. Das gleiche gilt für "Enqueue log" in Bezug auf Nachrichten müssen entfernt werden, bevor sie gelöscht werden können. –

danke für die Antwort, eigentlich mache ich etwas ähnliches wie deine Idee.Da meine Nachrichten vom SOAP Web Service als XML abgerufen werden, hänge ich die Nachrichten einfach in einer Datei an. Auf diese Weise ist die Enqueue und getTheFirstElement einfach. Der schwierige Teil ist die Dequeue. –

@MariaSilvia hat meine Antwort bearbeitet, nur für den Fall, dass ich meine Gedanken über den Auslagerungsprozess gelesen habe. Soweit ich mich erinnere, ist es, wie ich es getan habe (ich musste benutzerdefinierte persistente .Net MQ für Back-End-System implementieren). –

MSMQ muss nicht installiert werden wird nativ auf Windows Mobile 6.5-Geräten unterstützt. BTW: Es gibt immer noch viele Anbieter im Industriebereich, die WM65-basierte Geräte anbieten, daher ist dies noch nicht veraltet.

Die Windows Mobile (CE) basierte MSMQ ist persistent und einfach zu bedienen. Es wird normalerweise für die Interprozesskommunikation auf dem Gerät oder für die Client-Server-Kommunikation verwendet (für die MSMQ auf dem 'Server' installiert ist).

So erstellt der Haupt-Thread eine MSMQ, ein Thread in Ihrem Prozess füllt die MSMQ und ein anderer kann "Peek" und nach erfolgreicher Übertragung "Warteschlange" Nachrichten aus der gleichen MSMQ. Ein einfaches Beispiel finden Sie in here.

Quelle

2016-07-27 15:42:34 josef

Ich habe versucht, die Nachrichtenwarteschlange im Gerät zu erstellen, ohne es zu installieren, und es gab mir eine Ausnahme: "Message Queuing wurde nicht auf diesem Computer installiert." –

Vielleicht haben Sie die falsche msmq-Implementierung ausprobiert? Siehe Beispielcode unter https://github.com/hjgode/rdmInject/blob/master/RDM_msg_queue/msgqueue.cs. Dies ist ein Code zum Verarbeiten von Nachrichten, die durch den DLL-Code rdm_inject gepostet werden. Übrigens: Es laufen bereits viele MSMQ-Implementierungen beim WM-Start, damit Sie PowerNotifications oder PlugNPlay-Geräteänderungen usw. verfolgen können. Ich habe verschiedene davon in meinen auf github gehosteten Projekten verwendet (zB https://github.com/hjgode/logging_ce/blob) /master/PowerMsgLog/PowerMsgQueue.cpp und ihre in diesem logging_ce-Ordner) – josef

Einfache persistente Nachrichtenwarteschlange in C# für einen einzelnen Prozess

Antwort

Verwandte Themen