Bei der Verwendung von WCF als Abstraktionsschicht für entfernte Methodenaufrufe bin ich auf das Problem gestoßen, dass sich die Dienstobjekte, die bei WCF verwendet werden, zwar nahtlos mit dem übrigen Code verbinden, aber die eigentliche Natur der Netzwerkkommunikation während den Methodenaufrufen und die damit verbundenen Fehlerquellen verschleiert werden. Dadurch werden Probleme wie z.B. Verbindungsabbrüche in Bereichen des Codes relevant, die keine Aspekte der Netzwerkkommunikation enthalten sollten. Auch die langen Zeitspannen die entfernte Methodenaufrufe mit sich bringen, werden bei einer WCF-Schnittstelle verschleiert.

Aus diesem Grund habe ich als Experiment NChannel begonnen. Dabei wählte ich einen konsequent asynchroner Ansatz für die API. NChannel unterstützt unterschiedliche Methoden für die Serialisierung (Serializable und XMLSerializer). Bei Bedarf kann eine eigene Methode für die Serialisierung verwendet werden.

Das Verhalten bei Verbindungsstörungen die sich oberhalb von TCP/IP bemerkbar machen, kann flexibel konfiguriert werden. Dabei wird für jeden Kommunkationskanal ein Stufenmodell für den Wiederaufbau der TCP-Verbindung definiert. Das kann z.B. bedeuten:

• Stufe 1: 3 mal sofortiger Verbindungsversuch dann Stufe 2
• Stufe 2: 5 mal 2 Minuten zwischen den Verbindungsversuchen warten dann Stufe 3
• Stufe 3: immer 1h Stunde zwischen Verbindungsversuchen warten

Bei erfolgreicher Kommunikation wird die Stufe auf 1 zurückgesetzt. Wird ein Objekt bis zu einer Verbindungsstörung nicht vollständig übertragen (das serialisierte Objekt kann auf der Netzwerkschicht aus vielen TCP-Paketen bestehen) wird es nach einem Verbindungswiederaufbau erneut übertragen. Dieses Verhalten erzeugt zwar einen gewissen Overhead, entlastet aber den Empfänger, der bei Verbindungsabbrüchen keine unvollständigen Objekte verwalten muss.

Bisher habe ich NChannel z.B. als universelle Netzwerkabstraktion für die Kommunikation zwischen DynamicNodes-Graphen eingesetzt.