.NET Remoting TcpChannel, multi-homed Server

8 05 2009

In einem aktuellen Projekt bestand das Problem, dass wir einen .NET Remoting Server implementiert hatten, der den TcpChannel als Transport verwendet. Das Problem entstand dadurch, dass der Server mit mehreren Netzwerkadaptern (LAN und WLAN) ausgestattet war und die IP-Adresse des WLAN-Adapters sich dynamisch ändert weil der Server auf einem mobilen Gerät läuft, das herum getragen wird („roaming users“) und sich mit verschiedenen WLAN-(Sub)netzen verbindet. All das wäre noch kein Problem wenn es im Netzwerk des Kunden einen DNS-Server gäbe. In diesem Fall könnte man den TcpChannel so konfigurieren, dass er den Rechnernamen des mobilen Servers für die Bindung der Proxies verwendet. Da aber kein DNS zur Verfügung steht, mussten wir auf die Option useIpAddress=“true“ ausweichen. Dadurch entstand eine Reihe von Problemen:

  1. Wenn beim Start des Systems (Windows XP Embedded) kein Netzwerkkabel angesteckt ist und kein WLAN verfügbar ist, wird der Maschine keine IP-Adresse zugewiesen. Eine Kommunikation mit dem Gerät über den .NET Remoting TcpChannel ist dann auch nach dem Herstellen einer Netzwerkverbindung nicht möglich (der .NET Remoting Server läuft als Win32 Service und wird beim Systemstart automatisch gestartet).
  2. Wenn sich die IP-Adresse des WLAN-Adapters zur Laufzeit des .NET Remoting Service ändert, dann war keine Kommunikation mit dem .NET Remoting Service möglich. Selbst dann nicht, wenn der Client neu gestartet wurde. Der Client kennt zwar die neue IP-Adresse und kann den Server anpingen und sogar eine TCP Verbindung zum .NET Remoting Interface herstellen, eine Kommunikation über das .NET Remoting Protokoll war jedoch nicht möglich.

Ursächlich hierfür ist die Implementierung des TcpChannels im .NET Framework (2.0 SP1, neuere Versionen sind aber auch nicht besser). Bereits beim Registrieren des TcpChannels (z. B. via RemotingConfiguration.Configure) werden die IP-Adressen des Hosts ermittelt und der TcpChannel wird an die erstbeste(!) IP-Adresse (und zwar nur an diese!) gebunden. Diese Bindung bleibt bis zum Ende des Prozesses bestehen. Sie passt sich nicht dynamisch an. Ein nachträgliches Umkonfigurieren ist nicht möglich da die Klasse TcpChannel hierfür keine Properties/Methoden zur Verfügung stellt. Selbst ein explizites Deregistrieren (ChannelServices.UnregisterChannel) mit anschließender Neuinstanziierung und Neuregistrierung (ChannelServices.RegisterChannel) des TcpChannels ist nicht möglich weil das .NET Framework die Registrierung eines TcpChannels nur ein einziges Mal zulässt (warum?).

Zur Lösung des Problems haben wir eine eigene Implementierung des TcpChannels erstellt. Als Vorlage diente der Sourcecode von mono 2.4. Damit war es möglich, den TcpChannel zu de- und anschließend wieder zu registrieren. Im Gegensatz zum Standard-TcpChannel aus dem .NET Framework liefert unser TcpChannel nicht nur eine einzige URI für ein Objekt, sondern eine Liste von URIs, die einen Eintrag für jede dem System zugewiesene IP-Adresse (gefiltert auf IPv4) liefert. Parallel dazu haben wir einen „TcpAddressMonitor“ implementiert, der die dem System aktuell zugewiesenen IP-Adressen überwacht (mittels Polling im 5 s Takt) und bei einer Änderung den TcpChannel deregistriert, eine neue Instanz erstellt und diese wieder registriert. Damit waren sowohl das Problem mit nicht vorhandenen IP-Adressen beim Systemstart als auch das Roaming-Problem gelöst.

Allerdings wurden nun Exceptions, die beim Aufruf von Server-Methoden auftraten, nicht mehr an den Client durchgereicht. Die Option RemotingConfiguration.CustomErrorsMode=CustomErrorsMode.Off wurde ignoriert. Clientseitig kam lediglich eine RemotingException mit der Message „Server encountered an internal error“ an. Die Lösung für dieses Problem fand sich hier: Es muss im TcpChannel der RequestHeader __CustomErrorsEnabled=false gesetzt werden. Auf diese Lösung bin ich nur dadurch gekommen, dass ich mir den gesamten verfügbaren .NET Sourcecode über den NetMassDownloader heruntergeladen und nach „customErrors“ durchsucht habe.

Update, 13.05.2009: So ganz hat der oben beschriebene Weg doch nicht funktioniert. Wie sich gezeigt hat, gibt es Probleme mit bereits gemarshalten Objekt-Referenzen (ObjRef) wenn der TcpChannel neu registriert wird. Die Referenzen werden dann ungültig. Da hilft nicht einmal ein Neustart der Clients. Anhand eines Analyse des Quellcodes habe ich folgendes gelernt:

1. Jeder Channel enthält eine Liste von URIs (beim TcpChannel wird die Liste von der internen Klasse TcpServerChannel verwaltet).

2. Jede Objekt-Referenz enthält eine Liste von URIs (z. B. „tcp://hostname:port/xxxxxx.rem“).

Wird eine Referenz zum ersten Mal gemarshalt, wird ein ObjRef Objekt erzeugt. Dabei wird die Liste aller URIs aller in .NET Remoting registrierten Channels in das ObjRef Objekt kopiert.

Um unser Problem der sich ändernden IP-Adressen zu lösen, war nun folgendes nötig sobald sich die IP-Adressliste des Hosts geändert hat:

1. Die URI-Liste jedes TcpChannels muss aktualisiert werden.

2. Die URI-Liste sämtlicher Objekt-Referenzen muss aktualisiert werden.

Das ließ sich folgendermaßen implementieren:

1. Die Liste aller registrierten TcpChannels erhält man über ChannelServices.RegisteredChannels. Mit Hilfe von „… is TcpChannel“ wird überprüft, ob es sich um einen Channel vom Typ TcpChannel handelt. Um den TcpChannel aktualisieren zu können, wurde eine public Methode UpdateChannelData() hinzugefügt. Diese delegiert einfach an eine ebenfalls neue Methode UpdateChannelData() des internen TcpServerChannels. Damit waren die URIs des TcpChannels aktualisiert, was allerdings nur Auswirkungen auf zukünftige gemarshalte Objekt-Referenzen hat.

2. Die bereits gemarshalten Objekt-Referenzen können aktualisiert werden, indem die Schnittstelle ITrackingHandler von einer Klasse TrackingHandler implementiert wurde, und eine entsprechede Instanz beim TrackingService registriert wurde. ITrackingHandler wird benachrichtigt, wann immer eine Objekt-Referenz gemarshalt, unmarshalt oder disconnected wird. Beim Marshaling vermerkt unsere Klasse die erzeugte Objekt-Referenz in einer Liste, beim Disconnect wird die Objekt-Referenz aus der Liste entfernt. Anhand dieser Liste lässt sich leicht über alle bereits gemarshalten Objekt-Referenzen iterieren und deren URIs aktualisieren.


Aktionen

Information

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s




%d Bloggern gefällt das: