Laden...

Einsteigerfrage: Client/Server mit Remoting oder Streams ?

Erstellt von Moe vor 18 Jahren Letzter Beitrag vor 18 Jahren 1.675 Views
M
Moe Themenstarter:in
2 Beiträge seit 2005
vor 18 Jahren
Einsteigerfrage: Client/Server mit Remoting oder Streams ?

Hallo,
ich mache zur Zeit mit 2 Kommilitonen ein kostenloses Praktikum in einem Unternehmen. Unsere Aufgabe ist es, ein Programm zu schreiben, dass ca. 8 Mitarbeiter bei der Produktions- und Tourenplanung unterstützt. Dazu möchten wir eine generierte .dbf aus dem WWS auf einem Server auslesen.
Auf dem Serverrechner haben wir uns vorgestellt, einen Server laufen zu lassen, der die .dbf ausliest und sie in unserer eigenen AccessDB speichert. Außerdem soll auf dem Server die Verarbeitungslogik den Clients zur Verfügung gestellt werden. Auf den Clients soll also nur das UI laufen.Das heißt, dass über die Leitung recht häufig nicht ganz kleine Objekte laufen. Soweit so gut...
Wie kann man jetzt am besten die Client-Server-Architektur in C# realisieren. Sollte man mit Remoting arbeiten, so dass man die Serverfunktionen bequem aus dem Client aufrufen kann oder ist die Performance zu schlecht ? Sollte man das ganze mit Streams realisieren oder ist es dann zu umständlich die Verarbeitunglogik aufzurufen ?
Für Hilfe sind wir sehr dankbar, weil so richtig leider keiner einen Ansatz weiß, wie man mehrere Clients bedienen und die Daten aktualisiert kann und dabei noch eine gescheite Perfomance hat.
Gruß
Moe

68 Beiträge seit 2005
vor 18 Jahren

[off]Fuer euch kostenlos oder fuer die firma? Schaetze mal fuer die Firma, dann muesstet ihr aber Strom usw. zahlen? Oder meinst du einfach: Ihr bekommt kein Geld fuer eure Arbeit?[/off]

Benutz einfach das .net remoting, so schlecht ist die performance nicht

F
529 Beiträge seit 2003
vor 18 Jahren

Zu dem Remoting kann ich nichts sagen, das habe ich noch nie gemacht.

Bisher habe ich immer nur mit Streams gearbeitet. Und ich weiß nicht, was dbf-Dateien sind. Aber im Prizip würde ich das so lösen:
Der Client baut beim Start eine Verbindung per TCP zum Server auf. Wenn dann eine Datei geändert/erzeugt wurde, wird diese Änderung zum Server übertragen. Ich würde dazu einfach ein Xml-Dokument erzeugen, welches verschiedene Daten des Clients und die Datei enthält. Das komprimiert man dann noch, falls es was bringt und schickt es zum Server.

Der Server wartet auf neue Verbindungen. Wenn ein Client verbindet, wird ein neuer Thread angelegt und zusammen mit einer ClientId in einer List abgelegt. Die ClientId wird dem Client geschickt. Der Client muss diese Id immer mitschicken, wenn er was zum Server überträgt. Der neu angelegte Thread macht eingentlich nur eins: Er wartet auf neue Daten vom Client. Wenn neue Daten empfangen wurden, wird das Packet mit dem Xml-Dokument zerlegt und die Datei daraus extrahiert. Dann kann man das Empfangene Packet auswerten in die Datenbank packen(, die anderen Clientes über Änderungen benachrichtigen) und dem Clienten sagen, dass alles gut verlaufen ist.

Besuchen sie das VisualC++ - Forum

100 Beiträge seit 2005
vor 18 Jahren

Hi!

Remoting ist ziemlich cool..

Damit kannst du die remote Objekte vom "Server" so verwenden als wären sie lokal bei dir.

Um die ganze Netzwerk sache brauchst du dich nicht kümmern !

Also machs mit Remoting (oder mit Webservices aber die sind langsamer) !
Ist viel einfacher als mit TcpSockets (weil eine Ebene darüber)..

Remoting verwendet im Hintergrund auch Sockets und HTTP oder TCP je nach einstellung, aber du brauchst nur das remote object am client und server registrieren und los gehts.

lg,
kakaomilch.

M
Moe Themenstarter:in
2 Beiträge seit 2005
vor 18 Jahren

Okay, vielen Dank, werden es mal mit Remoting versuchen. Habe auf http://support.microsoft.com/kb/307445/DE/ ein kleines Beispiel gefunden. Läuft auch alles bestens, nur benötigt man auf der Clientseite neben der .exe noch die .dll ?!? Ist das normal, oder haben wir was falsch gemacht, weil so ist es nicht gerade praktisch am Server später mal was zu ändern

S
8.746 Beiträge seit 2005
vor 18 Jahren

Remoting ist wohl die richtige Wahl. Nur Access solltet ihr mindestens gegen MSDE austauschen. Das kostet auch nix, hat aber mehr Features und Leistung. Als Produktivsystem sollte man vielleicht doch zu einem richtigen SQL-Server greifen. Backup und Restore oder gar Replikation wegen Failover werden im realen Betrieb auf einmal sehr wichtig.

Wenn dein Chef Probleme mit den Kosten hat, dann frage zurück, was er glaubt was es ihn kostet, wenn mit einem Crash das System für Stunden steht oder die Daten (mangels Backup im laufenden Betrieb) ganz weg sind. Hier auf eine Billig-Lösung zu setzen werdet ihr mit 100%iger Sicherheit bereuen.