C# Software mit angebundenem Webservice

[StefanDinslaken]

Hallo Leute,

Ich habe eine Software programmiert, an die ich gern einen Webservice anbinden würde.

D.h. ich möchte das der Webservice auf Dateien auf der Festplatte zugreifen kann und über eine Webseite aufrufbar sind.

Allerdings habe ich keinen blassen Schimmer, wie ich das umsetzen soll. Hat jemand von euch dazu einen "Denkanstoss"?

Wichtig ist mir, das die Dateien des Users nicht auf dem Windows Server, sondern auf den Computern der nutzer bleiben und nur über den Webserver aufrufbar sind.

lg Stefan

 

[Krik]

Wie jetzt? Die Daten sollen beim Client liegen, aber darauf soll nur mit dem Webdienst, der auf dem Server läuft, zugegriffen werden? Das geht so nicht, das verstößt gegen die geläufigen Sicherheitsmechanismen.

Da musst du eine Clientsoftware programmieren, die die lokalen Daten an den Websever weiterreicht, sofern sie abgefragt werden.

 

[Marguth]

also dein plan ist das du übers internet auf die daten von deinem pc zugreiffen kannst (über ne website) aber diese dann nur öffnen und nicht speichern kannst. Hab ich das jetzt richtig verstanden?

 

[StefanDinslaken]

Die Software, die ich gemacht habe ich eine Art Musikverwaltung.

Jetzt möchte ich, das auf dem Server eine Website läuft, über die man die Musik wiedergeben kann. Allerdings sollen die mp3s dann halt nicht auf dem Server gespeichert werden, sondern idealerweise nur über den Server vom PC des Users gestreamt werden.

Der Server soll sozusagen nur als Verbindungsstück dienen, der die Informationen (also die mp3s) so anzeigt, das man sie über die Website abspielen kann.

 

[Krik]

Ah, jetzt verstehe ich.

Wie viele User soll das System später mal verwalten können? Wenn es mehr als eine Hand voll sind, dann wird die Netzverbindung zum Nadelöhr. Und der Traffic unbezahlbar.
Angenommen die MP3s haben 320 kBits/s, dann könnte ein Server mit 100 MBits/s Anbindung maximal 156 User im Idealfall mit Musik versorgen. Und der Webservice müsste die Musik vorhalten, denn wenn alle dieselbe MP3 hören wollen, dann reicht der Upload eines Clients bei weitem nicht aus, um so viele Leute bedienen zu können.

Ich rate dir hier dringend auf p2p auszuweichen. Und selbst da musst du dir dann Gedanken machen, was in dem Fall passieren soll, wenn der Upload eines Users nicht ausreicht. Allerdings hat man dann hier das Problem dass auf dem Quellclienten (dann eigentlich ein Server) eine Anwendung laufen muss. Dein Webservice hat dann an der Stelle nichts mehr zu melden und du verlierst die Kontrolle. Und was soll eigentlich in dem Fall passieren, wenn ein Quellclient die Verbindung zum Netz unterbricht (Rechner aus etc.)?

Überdenke das ganze Projekt noch einmal. Du hast hier Pandoras Büchse und bist kurz davor sie zu öffnen. Das ganze kann dier sehr schnell über den Kopf wachsen.

 

[lynxx]

Angenommen die MP3s haben 320 kBits/s, dann könnte ein Server mit 100 MBits/s Anbindung maximal 156 User im Idealfall mit Musik versorgen...

Du hast es imho leider total falsch verstanden, der Server soll nur Seiten anbieten die eine Auflistung der Titel des Users darstellt, z.B sortiert nach Interpret o.ä .. die Dateien liegen aber auf dem gleichen Rechner der auch die Webseiten anzeigt und die Musikstücke wiedergeben soll.

Ist nur die Frage was der Webservice alles an möglichkeiten bieten soll, auf jeden Fall brauchst Du eine Client-Seitige Software die dem Server die Titelnamen, Interpret, Ordnerstrukturen usw schickt. Serverseitig eine Datenbank die diese ganzen Informationen aufnimmt und dann so darstellt wie Du das möchstest (php o.ä). Soll der Server auch Änderungen am Client vornehmen können (z.B verschieben von Musikstücken in einen anderen Ordner) so müsste Deine Clientsoftware (die die Namen usw überträgt) eben auch auf Kommandos des Users reagieren können. Vielleicht wäre es aber einfacher alles als Clientlösung zu schreiben und nur optional eine Datenablage in Deinem Server ?

 

[Krik]

Er schrieb, die Musik soll über den Webservice gestreamt werden. Das heißt für mich, die Musik muss hoch- und dann wieder runtergeladen werden.

 

[lynxx]

Er schrieb, die Musik soll über den Webservice gestreamt werden. Das heißt für mich, die Musik muss hoch- und dann wieder runtergeladen werden.

Das kann ja aus den von Dir genannten Gründen schon nicht klappen .. Upload-Bandbreite des Clients, Datenvolumen bzw Traffickosten usw usf .. deswegen ging ich davon aus das der Server nur die Verwaltung übernehmen soll.

Es wäre allerdings auch noch möglich das er sich das so gedacht hat:

Client A hat die Dateien, Server zeigt Client B Inhalt von Client A, Client B fordert Musikstück xy an und Client B bekommt vom Server Streaming-Url zu Client A, dadurch hätte der Server keine Trafficprobleme, allerdings bleibt noch die maximale Uploadrate von Client A als Beschränkung, das kann für ein Musikstück noch genug sein (kommt eben auf die Anbindung von A an), aber wenn auch noch mehrere Clients gleichzeitig auf A zugreifen können sollen gehts spätestens dann irgendwann in die Hose, oder der Server müsste die Dateien dann von A anfordern und an die Clients verteilen, dann gibts aber wieder Traffickostenprobleme.

 

[StefanDinslaken]

Genau so:

Home-Client A hat die Dateien, Server zeigt Entferntem-Client B Inhalt (als Website) von Home-Client A, Entfernter-Client B fordert Musikstück xy an und bekommt vom Server Streaming-Url zu Home-Client A

Die beschränkte Uploadrate bei A ist denke ich kein Problem, da jeder User einen eigenen Home-Client hat, von dem er Musik anfordert.

 

[Krik]

Ok, also ist der Server als eine Art Tracker bzw. Inhaltsverzeichnis wie bei Torrent gedacht. Du hattest das erst anders formuliert. Da klang das so, also ob der Server das Streaming weiterrouten soll.

Da du die Clientsoftware zur Verwaltung schon fertig hast, würde ich an deiner Stelle jetzt mit der Serversoftware weitermachen. Also Kommunikationsprotokoll ausdenken/anderes zweckemfremden (zB XML RPC, oder auch über HTTP mit eigenen Headern). Dann musst du dir noch überlegen, ob du das mit Accounts machen willst. Einige haben ja eine recht umfangreiche Musiksammlung, da will man doch nicht jedes Mal die komplette Liste sondern nur die Veränderungen übertragen.
Und dann solltest du dir noch überlegen, ob es wirklich Streaming (Übertragung + gleichzeitiges Abspielen, such dir ein gängiges Protokoll aus, das die Browser/Mediaplayer unterstützen) oder eine simples Dateiübertragung (Abspielen erst nach dem Download) sein soll.

Und ganz wichtig: Mach dir Gedanken über die rechtlichen Aspekte. Ich glaube kaum, dass jeder die Musik schon gekauft hat, die er zu seinem Rechner streamen lässt. Denn wenn ja, dann wäre das Übertragen ja sinnlos. Er hat die Musik ja dann schon.




Edit:


Ein derartiges Netzwerk würde ich in etwa so aufziehen:

Der Vorteil hier besteht darin, dass alles auf Seiten des Request Clients schon vorhanden ist (Browser & Player) und nicht noch extra programmiert werden muss.
Das verlangt natürlich noch Detailplanung, aber als Grobentwurf sollte die Grafik brauchbar sein.

 

[StefanDinslaken]

Es läuft auf jeden Fall mir Accounts. Es soll nur jeder die Musik, die er zu Hause auf dem Rechner liegen hat, auch auf anderen PCs über die Website wiedergeben können. Es ist sozusagen nur ein "Fernzugriff" auf die eigene Musiksammlung. Das sollte also keine rechtlichen Probleme geben.

Das, wozu ich gar keine Ahnung habe ist, wie der Server auf den Home-Client zugreifen kann. In diesem Fall fragt ja der Server die Daten vom Home-Client ab, und nicht umgekehrt. Aber Home Clients haben ja keine feste IP, über die man Sie immer wieder finden könnte. Noch dazu stehen die meisten hinter Routern, für den nicht jeder ein Port-Forwarding einstellen müssen sollte.

 

[Krik]

Port forwarding ist zwingend nötig, wenn du den Stream nicht über den Server laufen lassen willst. Vielleicht kannst du da was mit UPNP machen. Sofern das im Router aktiviert ist, kann man damit Ports im Router aufmachen.

Die dynamische IP ist kein Problem. Die Clientsoftware meldet sich bei jedem Online-Gehen am Server an und damit ist die IP bekannt.

 

[StefanDinslaken]

Dann würde das aber nicht mehr klappen, wenn mehrere Home-Clients hinter einem Router stehen, oder?

Übrigens danke für die Grafik, so stelle ich mir das vor.

-- Sent from my Palm Pre3 using Forums

 

[Krik]

Doch doch, das sollte klappen. Server und Clientsoftware-Instanz müssen nach der ersten Kontaktaufnahme einen Port aushandeln, über den die zukünftige Kommunikation läuft (machen viele Protokolle auch so). Bei Streams kann man auch einen Port angeben.

 

[StefanDinslaken]

Okay, das heisst der erste Schritt wäre, den Home Client dazu zu bringen eine Verbindung mit dem Server aufzubauen, in der er seine IP mitteilt, und einen Port aushandelt, der dann geöffnet wir. Richtig?

-- Sent from my Palm Pre3 using Forums

 

[Krik]

Richtig. Die IP muss aber nicht mitgeteilt werden, das geschieht beim Verbindungsaufbau automatisch. Muss man sich nur aus den Verbindungsdaten herausziehen. Außer du willst das IP-Protokoll nicht verwenden, was ich aber nicht glaube.

Dein nächster Schritt sollte es sein, dir ein Kommunikationsprotokoll zu überlegen, sowie auf dem Server eine kleine Software mit Datenbankanbindung zu programmieren. Dann hast du immerhin schon etwas, womit du das Protokoll austesten kannst.

 

[roker002]

hmm das ganze klingt wie meine BA Arbeit!

also, ich schlage vor, wenn sich ein Client anmeldet, solltest du seinen PORT und IP auch mit abspeichern (PORT FORWARDING nicht notwendig). Da dein Programm wie eine P2P Anwendung verhalten soll, ist es verständlich, dass du die IP und Port von dem anderen Peer brauchst.

Nachdem die Musikliste abgeholt wurde mit der IP und Port des anderen Clients, machst du von dem Client eine neue Verbindung auf zu der IP und Port des Clients mit den Musiktiteln.

@Trouble

-Du muss den Benutzer deines Programms vorher fragen, dass man die Dateien Freigeben darf/muss. Wenn nicht, dann können die dich verklagen!
-P2P Netzwerk funktioniert nicht immer. Es hängt stark vom Router ab, der ans Internet angeschlossen ist. Alle andere Router/Switches sind irrelevant im internen Netzwerk.


Ich empfehle dir auf jeden Fall auf P2P zu setzen. Mit Client/Server bzw Routing über den Server, wirst du ab bestimmte Anzahl der Benutzer einfach auf Traffic-schwierigkeiten treffen. Da auch eine Netzwerktraffic auch die CPU Ressourcen verbrauchen kann, wirst du auch mit Nebenläufigen Programmen Probleme bekommen, wenn du viel mit CPU machen willst (z.B. Kopieren von Dateien, nicht verschieben )

Hier brauchst du das auf jeden Fall!

Und ja vergiss TCP Hole Punching.. Streamen!=Datenkonsistenz