Laden...

MVC, Remoting u.a.

Erstellt von citizen.ron vor 18 Jahren Letzter Beitrag vor 18 Jahren 2.555 Views
citizen.ron Themenstarter:in
432 Beiträge seit 2005
vor 18 Jahren
MVC, Remoting u.a.

hallo zusammen,

rainbird hat unter dem thread Tree(Node) Collection als Zwischenschicht bauen

im november ein beispiel zu mvc veröffentlicht, in dem auch .net remoting zum einsatz kommt.

hierzu sind mir ein paar fragen gekommen, die ich per mail an an rainbird geschickt habe, deren beantwortung ich aber nicht dem forum vorenthalten wollte:


hallo rainbird (hagen?)

sorry für das direkte eindringen in deine mailbox, aber ich habe leider nicht mehr den thread im mycsharp-forum gefunden, unter dem du dein mvc sample angeboten hast.

da du es ja zusätzlich mit einem (remotefähigen) servicehost implementiert hast, habe ich dazu folgende frage:

das statement
TcpServerChannel channel = new TcpServerChannel(9200);

wieso ausgerechnet port 9200?

wenn man einen solche remotedienst erstellen möchte (und das noch nie gemacht hat...), welche ports stehen denn hierfür überhaupt zur verfügung und nach welchen kriterien sucht man sich davon einen aus?


Antwort:

Mit den Ports verhält es sich so, dass Ports bi 1024 fürs System belegt sind. Ansonsten kannst Du jeden Port verwenden, der frei ist. Du solltest aber die Portnummer nie "hart" eincodieren. Es kann immer sein, dass eine andere Anwendung diesen Port bereits belegt.

citizen.ron Themenstarter:in
432 Beiträge seit 2005
vor 18 Jahren
.net Remoting und Console

jetzt die weiteren fragen, die mir im rahmen des beispiels und beim versuch, ähnliches zu implementieren, in die quere kommen:
1.welches format verwendet remoting hinter den kulissen eigentlich für den transport der objekte vom dienst zum client? ist das implizit xml?

1.

Du solltest aber die Portnummer nie "hart" eincodieren. Es kann immer sein, dass eine andere Anwendung diesen Port bereits belegt.

kann ich denn zur laufzeit rausfinden, welche ports noch frei sind?

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo citizen.ron,

welches format verwendet remoting hinter den kulissen eigentlich für den transport der objekte vom dienst zum client? ist das implizit xml?

Erstmal gibt es ja by-Value und by-Reference. In letzterem Fall werden die Objekte gar nicht transportiert. Und bei by-Value wird das Objekt serialisert. Es kommt also darauf an, wie ISerializable implementiert ist. Siehe auch Remotefähige und nicht remotefähige Objekte

kann ich denn zur laufzeit rausfinden, welche ports noch frei sind?

Es müssen sich ja beide Seiten auf einen gemeinsamen Port einigen. Wie tun sie das? Mit Remoting? 🙂 Also ich denke, ein fester Port ist erstmal nichts völlig abwegiges.

herbivore

citizen.ron Themenstarter:in
432 Beiträge seit 2005
vor 18 Jahren

hi herbivore,

Es müssen sich ja beide Seiten auf einen gemeinsamen Port einigen. Wie tun sie das?

der server dienst müsste ja der erste sein der startet; was ist dagegen einzuwenden, dass er den port, den er sich ausgesucht hat, in die zentrale datenbank schreibt?
jeder client liest den port aus und eröffnet die sitzung auf dem port.

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo citizen.ron,

dagegen ist nichts einzuwenden, außer dass man sich so oder zu auf eine Stelle einigen muss, die Client und Server kennen müssen, und die dann belegt und für andere Server nicht mehr verwendbar ist. Ob das eine Datenbankzelle oder eine Portnummer ist, macht keinen prinzipiellen Unterschied (außer vielleicht, dass es nicht so viele Portnummern gibt).

herbivore

3.728 Beiträge seit 2005
vor 18 Jahren

Original von citizen.ron
welches format verwendet remoting hinter den kulissen eigentlich für den transport der objekte vom dienst zum client? ist das implizit xml?
.NET Remoting kann mit verschiedenen Formatierern (z.B. für XML oder binäre Serialisierung) arbeiten. Außerdem besteht die Möglichkeit selbstprogrammierte "Senken" (English: sinks) in den Kommunikationsprozess einzuklinken (um z.B. Funktionen wie Authentifizierung und Verschlüsselung einzubauen). Beim .NET Framework 2.0 sind da allerdings einige neue Features hinzugekommen (Die sollte man sich ansehen, bevor man sich in die Entwicklung eigener .NET Remoting Erweiterungen stürtzt).

Zukünftig wird .NET Remoting von WCF (Windows Communication Foundation) abgelöst werden. Momentan ist WCF als Beta verfügbar. Es soll zusammen mit Windows Vista veröffentlicht werden. Allerdings ist es noch nicht Bestandteil des .NET Frameworks. Mit Remoting ist man also momentan noch sehr gut beraten. Ich habe mir WCF schon genauer angesehen. .NET Remoting Anwendungen lassen sich sehr einfach migrieren (Eigentlich müssen nur Attribute angepasst werden). Zumindest wenn man brav die Schnittstellen der Remote-Objekte in separaten Assemblies untergebracht hat.

Hier ein Überblick über WCF (allerdings in english):
http://msdn.microsoft.com/webservices/indigo/default.aspx?pull=/library/en-us/dnlong/html/introtowcf.asp

Noch eine Anmerkung zur Portnummer:
Die Einstellung der Ports in den Konfigurationsdateien (bzw. der Registry, wenn man die lieber benutzt) ist in einer Produktivumgebung der Job des Administrators. Nur der weiß, welche Anwendungen welche Ports belegen. Deshalb ist es wichtig dem Admin eine einfache (und automatisierbare; z.B. per Script oder AD Policy) Möglichkeit an die Hand zu geben, um die Portnummer anzupassen. Der Admin hat weder mit dem Quellcode der Anwendung noch mit den genauen Details der Architektur was am Hut. Besonders wenn die Anwendungen aus vielen kleinen Komponenten/Diensten besteht sollte man solche Konfigurationseinstellungen nicht an 20 verschiedenen Stellen machen müssen (Als Entwickler vergisst man oft an solche Sachen zu denken).