Ich entwickle eine Master-Slave-Anwendung. Die Master-Anwendung sendet Statusdaten an die Slave (s), um sie mit einer konstanten Rate zu verarbeiten und anzuzeigen. Die Zustandsdaten sind in einer einzigen Klasse zusammengefasst, die viele Felder enthält. Diese Feldtypen bestehen aus Primitiven, Klassen, Schnittstellen, Schnittstellenlisten usw. Alle Typen sind entweder BCL- oder benutzerdefinierte Typen, sodass die benutzerdefinierten Typen bei Bedarf geändert werden können. Sowohl die Master- als auch die Slave-Anwendungen werden .NET 4.0 sein. Ich bin nicht mit der Versionalisierung der Serialisierung beschäftigt, da die Master- und Slave-Anwendungen als Paar geliefert werden.
Ich brauche einen "schnellen" Weg, um die Zustandsdaten auf dem Master zu serialisieren und auf den Slaves zu deserialisieren. Wenn ich "schnell" sage, spreche ich mehr über Entwicklungszeit (aber die Verarbeitungszeit könnte ein Faktor sein, wenn die Lösung schrecklich war). Der Master und die Slaves werden jedoch über ein WAN verteilt, daher wäre auch ein gewisses Maß an Kompaktheit wünschenswert.
Für eine schnelle Lösung, überlege ich gerade, einfach BinaryFormatter zu verwenden und dann den Stream mit GZipStream zu komprimieren. Ist das der Weg für .NET 4.0?
Wenn die Geschwindigkeit der Entwicklung der Schlüssel ist (vor allem, weil Sie Interfaces usw. haben, die Sie für einige Serialisierer passend konfigurieren müssen), dann vielleicht. Denken Sie daran, alle Ereignisse als:
zu markieren %Vor%Bei jeder anderen Maßnahme (CPU-Leistung, Bandbreite, Robustheit bei Ihrer Version, Interoperabilität, Wartungskosten usw.) würde ich andere Formate wählen:)
Hier ist eine Auswahl profiliert:
Performance-Tests von Serialisierungen, die von WCF-Bindungen verwendet werden
Vielleicht keine Überraschung (seit ich es geschrieben habe), aber ich lehne mich dem Protobuf-Netz zu ...
Sehen Sie sich Protokollpuffer hier an: Schnelle und kompakte Objektserialisierung in. NET
Tags und Links .net c# serialization performance binary-serialization