WCF - schnellste Interprozesskommunikation

8

A haben einen WCF-Dienst, der über WCF erreichbar ist (via basicHttpBinding), auf den ich auch von anderen .NET-Diensten auf derselben Maschine mit einer höheren Leistung wie möglich zugreifen möchte. Ich verstehe, dass die netNamedPipeBinding dafür ideal ist, aber wundern Sie sich, was die beste Konfiguration wäre, dass ich nur mit anderen .NET-Prozessen kommunizieren werde.

Zum Beispiel muss ich nicht unbedingt eine Codierung wie SOAP verwenden, da dies vielleicht zu sperrig ist und ich die Kompatibilität mit anderen Clients als einem .NET-Client nicht benötige. Ich glaube auch nicht, dass ich irgendeine Sicherheit brauche.

Was wäre die beste verbindliche Konfiguration für diesen Zweck (oder andere Konfigurationen für diese Angelegenheit)

    
Barguast 19.12.2010, 23:05
quelle

3 Antworten

9
___ qstnhdr ___ WCF - schnellste Interprozesskommunikation ___ tag123c ___ C # (sprich "Cis") ist eine objektorientierte Programmiersprache auf hohem Niveau, die für die Erstellung einer Vielzahl von Anwendungen entwickelt wurde, die auf dem .NET Framework (oder .NET Core) ausgeführt werden. C # ist einfach, leistungsfähig, typsicher und objektorientiert. ___ tag123wcf ___ Windows Communication Foundation ist ein Teil von .NET Framework, das ein einheitliches Programmiermodell für die schnelle Erstellung von serviceorientierten Anwendungen bereitstellt. ___ answer47472577 ___

Ich verstehe, dass das eine ziemlich alte Frage ist, aber es lohnt sich immer noch zu antworten. Wie bereits erwähnt, sind Named Pipes am schnellsten und Sie müssen die Sicherheit deaktivieren, aber den dramatischsten Effekt erhalten Sie, wenn Sie die Serialisierung des Datenvertrags loswerden und in den Stream-basierten Übertragungsmodus wechseln.

Verwenden Sie etwa so etwas als verbindliche Konfiguration:

%Vor%

Definieren Sie Ihre Servicemeldungen wie folgt:

%Vor%

Der Nachteil dieser Methode ist, dass Sie jetzt Ihre Daten selbst serialisieren müssen. Ich bevorzuge die Verwendung von Protobuf-Serialisierung direkt zu MemoryStream. Platzieren Sie diesen Stream in Ihre CallRequestMessage.Parameters.

Vergessen Sie nicht, ParameterLen / ResultsLen im Nachrichtenheader zu übertragen, da Stream endlos ist (beim Lesen erhalten Sie zwar 0 Bytes, aber im Gegensatz zu normalen Streams sollten Sie weiterlesen).

    
___ qstntxt ___

A haben einen WCF-Dienst, der über WCF erreichbar ist (via basicHttpBinding), auf den ich auch von anderen .NET-Diensten auf derselben Maschine mit einer höheren Leistung wie möglich zugreifen möchte. Ich verstehe, dass die netNamedPipeBinding dafür ideal ist, aber wundern Sie sich, was die beste Konfiguration wäre, dass ich nur mit anderen .NET-Prozessen kommunizieren werde.

Zum Beispiel muss ich nicht unbedingt eine Codierung wie SOAP verwenden, da dies vielleicht zu sperrig ist und ich die Kompatibilität mit anderen Clients als einem .NET-Client nicht benötige. Ich glaube auch nicht, dass ich irgendeine Sicherheit brauche.

Was wäre die beste verbindliche Konfiguration für diesen Zweck (oder andere Konfigurationen für diese Angelegenheit)

    
___ answer4485771 ___

Wie Sie bereits festgestellt haben, ist die NetNamedPipeBinding -Bindung für dasselbe optimiert. Maschinenkommunikation:

  

Bietet eine sichere und zuverlässige Bindung   das ist für die Maschine optimiert   Kommunikation.

Ref. : vom System bereitgestellte Bindungen

Im ersten Kapitel von Juval Lowys Buch "Programming WCF Services" stellt er ein nützliches Entscheidungsaktivitätsdiagramm für die Wahl der richtigen Bindung zur Verfügung:

  

"Die erste Frage, die Sie stellen sollten   selbst ist, ob deine Dienstleistung benötigt   Interaktion mit Nicht-WCF-Clients. Ob   Die Antwort ist ja, und wenn der Kunde   ist ein Legacy-MSMQ-Client, wählen Sie die   MsmqIntegrationBinding, das aktiviert   Ihr Service für Interoperabilität über MSMQ   mit einem solchen Kunden. Wenn du musst   Interoperabilität mit einem Nicht-WCF-Client und   Dieser Client erwartet grundlegende Webdienste   Protokoll (ASMX Web Services), wählen Sie   die BasicHttpBinding, die aufdeckt   Ihr WCF-Service für die Außenwelt   als wäre es ein ASMX-Webservice   (das heißt, ein WSI-Basisprofil). Das   Nachteil ist, dass Sie nicht nehmen können   Vorteil der meisten modernen WS- *   Protokolle. Wenn jedoch die Nicht-WCF   Client kann diese Standards verstehen,   Wählen Sie eine der WS-Bindungen aus, z   WSHttpBindung,   WSFederationHttpBinding, oder   WSDualHttpBinding. Wenn Sie annehmen können   dass der Client noch ein WCF-Client ist   es erfordert offline oder getrennt   Interaktion, wählen Sie die NetMsmqBinding   das verwendet MSMQ zum Transportieren der   Mitteilungen. Wenn der Client es benötigt   verbundene Kommunikation, könnte aber sein   über Maschinengrenzen hinweg anrufen,   Wählen Sie die NetTcpBinding das   kommuniziert über TCP. Wenn der Kunde   ist auf der gleichen Maschine wie der Service,   Wählen Sie das NetNamedPipeBinding aus   Benutzt Named Pipes um zu maximieren   Performance. Sie können die Bindung feineinstellen   Auswahl basierend auf zusätzlichen   Kriterien wie die Notwendigkeit für   Rückrufe (WSDualHttpBinding) oder   Verbundsicherheit   (WSFederationHttpBinding). "

    
___ tag123namedpipes ___ Eine Named Pipe ist ein prozessübergreifender Kommunikationsmechanismus, der sowohl auf Unix- und Unix-ähnlichen Systemen (wo er auch als FIFO bekannt ist und Datei-ähnlich ist) als auch auf Microsoft Windows (wo er ein In ist) existiert -Memory-Kernel-Objekt). Die Semantiken und APIs unterscheiden sich wesentlich zwischen den Plattformen. ___ answer4490732 ___

Sicherlich ist der Named Pipe Transport die beste Wahl.

Transportsicherheit mit EncryptAndSign ist standardmäßig in der standardmäßigen NetNamedPipeBinding-Funktion aktiviert. Sie möchten dies sicherlich entfernen, da dies die Dinge ohne wirkliche Auswirkungen auf die Sicherheit beschleunigen wird, aus den Gründen, warum Ich diskutiere hier .

Ich vermute auch, aber habe noch nicht bestätigt, dass das Ändern des Nachrichtencodierungs-Bindungselements helfen kann. Dies liegt daran, dass der Standardwert das WCF-proprietäre "Binärcodierung mit In-Band-Wörterbuch" ist, das eine Codierung eines XML-Infosets ist, die darauf abzielt, redundante Bytes, z. beim Öffnen und Schließen von Element-Tags: ein wertvolles Ziel, wenn Netzwerk-IO betroffen ist, aber möglicherweise verschwendet CPU-Aufwand, wenn die Nachrichtenübertragung vollständig im Speicher ist (vorausgesetzt, die Nachrichten sind nicht zu groß). Daher könnte eine Änderung in einer reinen Textkodierung auch eine Geschwindigkeitsverbesserung ergeben.

    
___
Mitch Wheat 19.12.2010, 23:10
quelle
4

Sicherlich ist der Named Pipe Transport die beste Wahl.

Transportsicherheit mit EncryptAndSign ist standardmäßig in der standardmäßigen NetNamedPipeBinding-Funktion aktiviert. Sie möchten dies sicherlich entfernen, da dies die Dinge ohne wirkliche Auswirkungen auf die Sicherheit beschleunigen wird, aus den Gründen, warum Ich diskutiere hier .

Ich vermute auch, aber habe noch nicht bestätigt, dass das Ändern des Nachrichtencodierungs-Bindungselements helfen kann. Dies liegt daran, dass der Standardwert das WCF-proprietäre "Binärcodierung mit In-Band-Wörterbuch" ist, das eine Codierung eines XML-Infosets ist, die darauf abzielt, redundante Bytes, z. beim Öffnen und Schließen von Element-Tags: ein wertvolles Ziel, wenn Netzwerk-IO betroffen ist, aber möglicherweise verschwendet CPU-Aufwand, wenn die Nachrichtenübertragung vollständig im Speicher ist (vorausgesetzt, die Nachrichten sind nicht zu groß). Daher könnte eine Änderung in einer reinen Textkodierung auch eine Geschwindigkeitsverbesserung ergeben.

    
Chris Dickson 20.12.2010 14:53
quelle
1

Ich verstehe, dass das eine ziemlich alte Frage ist, aber es lohnt sich immer noch zu antworten. Wie bereits erwähnt, sind Named Pipes am schnellsten und Sie müssen die Sicherheit deaktivieren, aber den dramatischsten Effekt erhalten Sie, wenn Sie die Serialisierung des Datenvertrags loswerden und in den Stream-basierten Übertragungsmodus wechseln.

Verwenden Sie etwa so etwas als verbindliche Konfiguration:

%Vor%

Definieren Sie Ihre Servicemeldungen wie folgt:

%Vor%

Der Nachteil dieser Methode ist, dass Sie jetzt Ihre Daten selbst serialisieren müssen. Ich bevorzuge die Verwendung von Protobuf-Serialisierung direkt zu MemoryStream. Platzieren Sie diesen Stream in Ihre CallRequestMessage.Parameters.

Vergessen Sie nicht, ParameterLen / ResultsLen im Nachrichtenheader zu übertragen, da Stream endlos ist (beim Lesen erhalten Sie zwar 0 Bytes, aber im Gegensatz zu normalen Streams sollten Sie weiterlesen).

    
unclshura 24.11.2017 11:41
quelle

Tags und Links